系统级集成测试的断舍离

always_fly

在企业级应用的“季度或月度发布”被认为是领域最佳实践的时候，在应用部署到生产环境之前维护一个完整的环
境来进行集成测试是非常必要的。但是，集成测试环境和集成测试本身有着如下的问题：

环境本身脆弱，而且通常存在手动配置部分，环境维护成本很高；
环境因素导致集成测试不稳定、不可靠、反馈慢，测试失败不易定位问题，同时还会重复测试隔离组件已经测过
的功能。
集成测试成为了持续交付的瓶颈，犹如鸡肋。因此，最新一期（2017年第16期）ThoughtWorks技术雷达建议企
业暂缓搭建企业级集成测试环境，而是采用增量的方式发布关键组件到生产环境。增量发布涉及到一些重要的技
术包括契约测试、将发布与部署解耦、专注于平均恢复时间和生产环境下的QA。


断舍离之技术可行性

下面分别介绍技术雷达建议的这四项技术，以及在没有集成测试的情况下如何保证应用的质量、如何帮助企业做
到独立增量发布。

消费端驱动的契约测试

消费端驱动的契约测试是微服务测试的重要组成部分，主要用来覆盖两两服务之间的契约关系，下面举个例子来
说明什么是契约测试以及契约测试与API测试的区别。

家里有个插座，买电器的时候需要考虑插头跟插座是能配对的，也就是说插座和插头之间需要有契约。


这里的契约测试就是插座跟插头的配套性测试，包括

三相/三头还是两相/两头的；
电压是220V还是110V；
插孔的形状：英式 or 中式？
等等
API测试：对于插座本身功能的测试，需要覆盖

插座能够正常通电；
电压是预期的220v；
接地的插孔真的能够接地
等等
也就是说API测试需要测试API本身功能的各个方面，而契约测试重点在覆盖API调用的格式、参数数量、参数类型
等，不一定需要涉及API本身的功能和具体的数据。

发布与部署解耦

部署，就是把组件或者基础设施部署到生产环境，不对用户可见，不会影响业务和用户的使用。发布，则是将部
署的组件让用户可见，对业务会产生影响。可以通过采用Feature toggle的方式实现部署与发布的解耦，做到持续
部署和可控制的发布，减少组件改变带来的风险。这样，产品经理可以根据业务需求灵活控制发布给最终用户的
功能组件，帮助企业业务价值最大化。

关注平均恢复时间

先看这样两种情况，思考哪种更好：

系统宕机次数很少，可能每年也就一到两次，但是恢复能力很弱，一旦宕机，得花至少24个小时恢复正常；
系统宕机频率较高，不过每次宕机都能快速恢复，用户甚至感觉不到。
对于第一种，平均失败间隔很长，但是一旦失败对用户的影响不言而喻；第二种虽然会频繁的失败，但是平均恢
复时间很短，用户体验不受影响，当然是第二种更好。


传统的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，第二天上午就已经修复出包可以测试了。

写在最后

系统级集成测试虽然有各种问题，不一定会因为集成测试挂掉而发现很多问题，前面也讨论了断舍离的可行性，
分析了项目断舍离的实践，但集成测试并不是用来发现问题的，而是一道对质量把关的屏障，关键路径的必要测
试是不可替代的。因此，我们提倡减少集成测试的数量，合理调整各层测试的比例。

系统级集成测试的断舍离需要团队有持续、递进、稳定的交付能力，需要保证用户不会受此影响，企业业务能够
正常运转。系统级集成测试的断舍离过程不是一蹴而就的，凝结在集成测试上的心血也不是那么容易放弃的，需
要很多的平衡和取舍，并在整个过程中要不断的关注系统的质量和风险，及时作出相应的调整。