食之无味,弃之可惜
在企业级应用的“季度或月度发布”被认为是领域最佳实践的时候,在应用部署到生产环境之前维护一个完整的环境来进行集成测试是非常必要的。但是,集成测试环境和集成测试本身有着如下的问题:
集成测试成为了持续交付的瓶颈,犹如鸡肋。因此,最新一期ThoughtWorks技术雷达建议企业暂缓搭建企业级集成测试环境,而是采用增量的方式发布关键组件到生产环境。
增量发布涉及到一些重要的技术包括契约测试、将发布与部署解耦、专注于平均恢复时间和生产环境下的QA 。
下面分别介绍技术雷达建议的这四项技术,以及在没有集成测试的情况下如何保证应用的质量、如何帮助企业做到独立增量发布。
消费端驱动的契约测试
消费端驱动的契约测试是微服务测试的重要组成部分,主要用来覆盖两两服务之间的契约关系,下面举个例子来说明什么是契约测试以及契约测试与API测试的区别。
家里有个插座,买电器的时候需要考虑插头跟插座是能配对的,也就是说插座和插头之间需要有契约。
这里的契约测试就是插座跟插头的配套性测试,包括
API测试:对于插座本身功能的测试,需要覆盖
也就是说API测试需要测试API本身功能的各个方面,而契约测试重点在覆盖API调用的格式、参数数量、参数类型等,不一定需要涉及API本身的功能和具体的数据。(更多关于消费端驱动的契约测试,请点击【阅读原文】查看)
发布与部署解耦
部署,就是把组件或者基础设施部署到生产环境,不对用户可见,不会影响业务和用户的使用。发布,则是将部署的组件让用户可见,对业务会产生影响。
可以通过采用Feature toggle的方式实现部署与发布的解耦,做到持续部署和可控制的发布,减少组件改变带来的风险。这样,产品经理可以根据业务需求灵活控制发布给最终用户的功能组件,帮助企业业务价值最大化。
关注平均恢复时间
先看这样两种情况,思考哪种更好:
对于第一种,平均失败间隔很长,但是一旦失败对用户的影响不言而喻;第二种虽然会频繁的失败,但是平均恢复时间很短,用户体验不受影响,当然是第二种更好。
传统的Ops团队比较关注失败发生的频率,随着持续交付和监控技术的发展,“快速恢复”成为可能。不用担心错误、失败的发生,而是利用对这些错误和失败的监控和分析,让系统做到快速恢复,可以省掉一些复杂的集成测试,也可以减少无处不在的安全攻击的影响。
生产环境下的QA
生产环境是真实用户使用的环境,通常都不能跟测试环境一样可以在上面直接测试产品的功能,不能简单的把测试环境所用的QA技术直接后延到生产环境,而其中一项在生产环境使用的技术就是监控。采用监控技术来获取生产环境的信息,对其进行分析,然后优化开发、测试过程,同时优化企业业务。更多关于生产环境下QA的内容,请参看文章《生产环境下的QA》。
对上面四种技术的解释,我们可以看到:契约测试是对持续独立部署有帮助的,监控技术则是缩短平均恢复时间和做好生产环境下的QA共同的关键技术之一。
接下来主要分享项目在围绕契约测试和日志监控这两块所做的实践,一起来看系统级集成测试的断舍离该如何实现。
项目是一个开发了七八年的老项目,团队对集成测试也是进行了多次的调整,经历了“七年之痒”后依然觉得是鸡肋:
可以看出,集成测试已经严重阻碍了项目持续交付的进行,不得不对其断舍离了。
断舍离的第一个部分是从集成测试本身入手,调整测试策略。步骤如下:
整体策略调整思路是根据测试金字塔的结构进行调整,把测试尽量往下层移,但并没有全部去掉集成测试,只是缩减到非常关键的路径覆盖,最终测试结构调整如下图所示:
没有了Pipeline上的集成测试,直接上到QA或者prod环境,那么加强日志监控变得尤其重要。因此,断舍离的第二个部分是日志的监控、分析和优化。
日志数据采集
项目使用的日志分析工具是Splunk,使用该工具从下面几个方面来着手采集日志数据:
日志数据利用
利用前面几种方式采集到的日志数据,从下面几个方面进行分析和优化:
项目对集成测试断舍离才刚刚开始,正在不断摸索着前进,目前能看到的最直接的影响是pipeline出包明显加快,由以前的好几天出不来一个包变成一天能出好几个包。最振奋人心的是本周刚刚发生的事情:前一天下班前报的bug,第二天上午就已经修复出包可以测试了。
系统级集成测试虽然有各种问题,不一定会因为集成测试挂掉而发现很多问题,前面也讨论了断舍离的可行性,分析了项目断舍离的实践,但集成测试并不是用来发现问题的,而是一道对质量把关的屏障,关键路径的必要测试是不可替代的。因此,我们提倡减少集成测试的数量,合理调整各层测试的比例。
系统级集成测试的断舍离需要团队有持续、递进、稳定的交付能力,需要保证用户不会受此影响,企业业务能够正常运转。系统级集成测试的断舍离过程不是一蹴而就的,凝结在集成测试上的心血也不是那么容易放弃的,需要很多的平衡和取舍,并在整个过程中要不断的关注系统的质量和风险,及时作出相应的调整。