食之无味，弃之可惜
在企业级应用的“季度或月度发布”被认为是领域最佳实践的时候，在应用部署到生产环境之前维护一个完整的环境来进行集成测试是非常必要的。但是，集成测试环境和集成测试本身有着如下的问题：
1.环境本身脆弱，而且通常存在手动配置部分，环境维护成本很高；
2.环境因素导致集成测试不稳定、不可靠、反馈慢，测试失败不易定位问题，同时还会重复测试隔离组件已经测过的功能。
集成测试成为了持续交付的瓶颈，犹如鸡肋。因此，最新一期（2017年第16期）ThoughtWorks技术雷达建议企业暂缓搭建企业级集成测试环境，而是采用增量的方式发布关键组件到生产环境。增量发布涉及到一些重要的技术包括契约测试、将发布与部署解耦、专注于平均恢复时间和生产环境下的QA
。
断舍离之技术可行性
下面分别介绍技术雷达建议的这四项技术，以及在没有集成测试的情况下如何保证应用的质量、如何帮助企业做到独立增量发布。
消费端驱动的契约测试
消费端驱动的契约测试是微服务测试的重要组成部分，主要用来覆盖两两服务之间的契约关系，下面举个例子来说明什么是契约测试以及契约测试与API测试的区别。
家里有个插座，买电器的时候需要考虑插头跟插座是能配对的，也就是说插座和插头之间需要有契约。
这里的契约测试就是插座跟插头的配套性测试，包括
1.三相/三头还是两相/两头的；
2.电压是220V还是110V；
3.插孔的形状：英式 or 中式？
4.等等
API测试：对于插座本身功能的测试，需要覆盖
1.插座能够正常通电；
2.电压是预期的220v；
3.接地的插孔真的能够接地
4.等等
也就是说API测试需要测试API本身功能的各个方面，而契约测试重点在覆盖API调用的格式、参数数量、参数类型等，不一定需要涉及API本身的功能和具体的数据。
更多关于消费端驱动的契约测试，请参看文章《Consumer-Driven Contracts: A
Service Evolution Patter》。
发布与部署解耦
部署，就是把组件或者基础设施部署到生产环境，不对用户可见，不会影响业务和用户的使用。发布，则是将部署的组件让用户可见，对业务会产生影响。可以通过采用Feature
toggle的方式实现部署与发布的解耦，做到持续部署和可控制的发布，减少组件改变带来的风险。这样，产品经理可以根据业务需求灵活控制发布给最终用户的功能组件，帮助企业业务价值最大化。
关注平均恢复时间
先看这样两种情况，思考哪种更好：
1.系统宕机次数很少，可能每年也就一到两次，但是恢复能力很弱，一旦宕机，得花至少24个小时恢复正常；
2.系统宕机频率较高，不过每次宕机都能快速恢复，用户甚至感觉不到。
对于第一种，平均失败间隔很长，但是一旦失败对用户的影响不言而喻；第二种虽然会频繁的失败，但是平均恢复时间很短，用户体验不受影响，当然是第二种更好。
传统的Ops团队比较关注失败发生的频率，随着持续交付和监控技术的发展，“快速恢复”成为可能。不用担心错误、失败的发生，而是利用对这些错误和失败的监控和分析，让系统做到快速恢复，可以省掉一些复杂的集成测试，也可以减少无处不在的安全攻击的影响。
生产环境下的QA
生产环境是真实用户使用的环境，通常都不能跟测试环境一样可以在上面直接测试产品的功能，不能简单的把测试环境所用的QA技术直接后延到生产环境，而其中一项在生产环境使用的技术就是监控。采用监控技术来获取生产环境的信息，对其进行分析，然后优化开发、测试过程，同时优化企业业务。更多关于生产环境下QA的内容，请参看文章《产品环境下的QA》。
对上面四种技术的解释，我们可以看到：契约测试是对持续独立部署有帮助的，监控技术则是缩短平均恢复时间和做好生产环境下的QA共同的关键技术之一。接下来主要分享项目在围绕契约测试和日志监控这两块所做的实践，一起来看系统级集成测试的断舍离该如何实现。
断舍离之项目实践
项目是一个开发了七八年的老项目，团队对集成测试也是进行了多次的调整，经历了“七年之痒”后依然觉得是鸡肋： Pipeline上执行非常不稳定，总是“随机挂”，不能真实反映问题；
系统复杂，集成测试自然也不简单，每次顺利执行的时间都需要半个小时以上，何况还有很不稳定的情况，最严重的时候导致QA超过一周拿不到包部署；
通过集成测试发现的应用程序的缺陷半年也难得出现一个；
随着系统逐渐变得复杂，集成测试维护的成本也不断增加。
可以看出，集成测试已经严重阻碍了项目持续交付的进行，不得不对其断舍离了。
（一）测试策略调整
断舍离的第一个部分是从集成测试本身入手，调整测试策略。步骤如下: 不再添加新的功能层面的自动化测试，原有的集成测试部分能用底层的UT、API测试覆盖的尽量下移；
UT和API测试不能cover的服务间的契约关系通过增加契约测试来保证；
从CI上摘掉原来的集成测试，加速pipeline出包，然后添加Smoke测试到QA环境执行；
不管是在测试环境还是生产环境发现缺陷，都添加对应的测试。
整体策略调整思路是根据测试金字塔的结构进行调整，把测试尽量往下层移，但并没有全部去掉集成测试，只是缩减到非常关键的路径覆盖，最终测试结构调整如下图所示：
（二）日志监控、分析和优化
没有了Pipeline上的集成测试，直接上到QA或者prod环境，那么加强日志监控变得尤其重要。因此，断舍离的第二个部分是日志的监控、分析和优化。
日志数据采集
项目使用的日志分析工具是Splunk，使用该工具从下面几个方面来着手采集日志数据：
在Splunk上设置日志监控的Dashboard，主要用来监控API的请求失败、错误的日志，还有API执行时间等性能相关内容。如下图所示：
设置预警邮件提醒：对于一些存在严重性能问题的API请求，通过邮件的方式进行预警提醒，如下图：
主动查找错误日志：对于一些生产环境中用户反馈回来的问题，通过主动查找错误日志的方式去定位。
前面的几个机制同样应用于QA和Staging等测试环境，以通过日志分析尽量提前发现问题。
日志数据利用
利用前面几种方式采集到的日志数据，从下面几个方面进行分析和优化： 发现和定位系统功能问题，分析系统用户的行为习惯，优化业务；
发现和定位安全、性能等非功能问题，进行修复和优化；
发现和分析日志记录本身的不足，规范日志记录，从而进一步增强日志给问题诊断带来的帮助，形成良性循环。规范日志记录主要涉及这些点：统一日志输出路径、统一日志记录格式、清晰定义日志级别，并且把添加必要日志作为story开发流程的一部分，QA会参与日志评审。下图是Splunk里看到的项目最新优化的日志记录格式：
项目对集成测试断舍离才刚刚开始，正在不断摸索着前进，目前能看到的最直接的影响是pipeline出包明显加快，由以前的好几天出不来一个包变成一天能出好几个包。最振奋人心的是本周刚刚发生的事情：前一天下班前报的bug，第二天上午就已经修复出包可以测试了。
写在最后
系统级集成测试虽然有各种问题，不一定会因为集成测试挂掉而发现很多问题，前面也讨论了断舍离的可行性，分析了项目断舍离的实践，但集成测试并不是用来发现问题的，而是一道对质量把关的屏障，关键路径的必要测试是不可替代的。因此，我们提倡减少集成测试的数量，合理调整各层测试的比例。
系统级集成测试的断舍离需要团队有持续、递进、稳定的交付能力，需要保证用户不会受此影响，企业业务能够正常运转。系统级集成测试的断舍离过程不是一蹴而就的，凝结在集成测试上的心血也不是那么容易放弃的，需要很多的平衡和取舍，并在整个过程中要不断的关注系统的质量和风险，及时作出相应的调整。
|
