摘要：在欧洲中世纪的传说中，有一种叫“人狼”的妖怪，就是人面狼身。它们会讲人话，专在月圆之夜去袭击人类。而且传说中对“人狼”用一般的枪弹是不起作用的，普通子弹都伤不到也打不死它，只有一种用银子作成的特殊子弹才能把它杀死。
作者简介：武小平（平晓），阿里巴巴测试专家，在CICD、自动化测试工具和质量管理方面有较多的经验，目前负责阿里巴巴研发协同平台阿里云RDC的测试。
转载来源：研发协同RDC微信公号（alirdc）
在欧洲中世纪的传说中，有一种叫“人狼”的妖怪，就是人面狼身。它们会讲人话，专在月圆之夜去袭击人类。而且传说中对“人狼”用一般的枪弹是不起作用的，普通子弹都伤不到也打不死它，只有一种用银子作成的特殊子弹才能把它杀死。Brooks在他最著名的随笔文章《No Silver Bullet》里引用了这个典故 ，说明在软件开发过程里是没有万能的终杀性武器的，只有各种方法综合运用，才是解决之道。
那么在软件研发过程中，哪怕没有银弹，如何用各种方法去解决这些“人狼”带来的威胁呢？阿里巴巴在多年的研发过程中，又是如何对付这头“人狼”？这一路走来，又有哪些方法和实践被沉淀？
1.阿里巴巴的研发平台是一个怎样的平台？
阿里巴巴研发协同平台(AONE)是云上企业级一站式智能研发协同平台，目前为阿里巴巴集团，下属子公司以及生态合作伙伴提供从“需求->编码->测试->发布->反馈”端到端的持续交付服务，并解决研发过程中跨角色、跨组织、跨地区的协作问题，在此基础上通过数据驱动度量分析为组织效能提升提供决策依据，目前这一平台已经上云对外提供服务，称为阿里云研发协同RDC。(以下简称为RDC)
删除
(选填) 图片描述
上图是整个RDC的业务框架，RDC采用微服务的架构，从规划到运营提供了业务全生命周期的服务，众多的服务造成了RDC的复杂度，另一方面作为一个面向用户的平台，RDC又涵盖了阿里三个层次的技术服务栈。
第一层，基础资源层，包括idc机房、网络设施、OS、Docker、数据库等。
第二层，平台服务层，包括中间件、调度层、应用服务器等。
第三层，RDC研发协同平台，包括 项目、代码、应用、测试、交付、运营的管理。
三个层次加起来涉及的核心应用达50+，随便一个风吹草动就会对系统的稳定性造成影响，这些影响最终体现到面向用户的RDC，因此好的质量保障才能为用户提供一个稳定，高可用性的研发协同平台。
2.质量保障策略
删除
(选填) 图片描述
总体采用 “事前预防”，“事中控制”，“事后总结改进”的思想，主要做的三件事情：
测试驱动持续交付测试驱动持续交付，每一次的持续集成和发布都从单元测试，API测试，集成测试，UI测试进行自动化测试覆盖；具体包括：单元测试，集成测试，WebUI测试，移动端UI测试，压测，线上引流的API测试，线上冒烟测试。
线上质量监控对线上质量的保障，主要采用监控的方式，希望一有问题就能及时发现解决，避免问题的大面积扩大。主要包括：
（1） 机器监控报警，业务数据监控。
（2） 对线上运行日志的聚合分析，发现存在的错误。
（3） SLA数据质量提升，将业务数据可视化，指导改进方向。
（4） 面向业务的监控和故障演练，通过对线上7*24的监控提前发现问题保障系统的稳定运行。
研发质量提升通过代码审核，集团规约扫描，规范代码和提升研发质量。
3. 持续交付流程
删除
(选填) 图片描述
上图是测试驱动的的持续交付流程，也是RDC各个应用在发布时的持续交付流程，通过RDC的发布功能实现。
（1） 开发在变更(Change Request)中提交代码后，触发单元测试，检查代码中基本的逻辑问题，实践中单测的覆盖率和维护由开发同学自己保证，目前RDC核心应用的单测行覆盖率在50%左右。
（2） 部署测试环境，开发进行自测，主要对新的功能进行基本的验证。测试环境与生产环境完全隔离，具有独立的网络环境，单独的数据库和中间件等依赖环境。
（3） 自测完成后发布预发环境，由测试同学进行集成测试，包括回归测试和新功能的验证，以及对核心接口的小压测。预发环境与生产环境在同一个网络中，共享同一个数据库，数据隔离采用逻辑隔离，但是它具有一个独立的依赖环境，如独立的上下游和中间件。
（4） 接着进入Beta测试环节，通过截取一部分生产环境的流量到Beta环境回放来对核心接口做进一步的验证。Beta环境与线上环境完全相同，不同的是Beta环境不对外提供服务。
（5） Beta测试完成后，正式发布生产环境并对生产环境执行冒烟测试。
以上是一个变更的生命周期，也是一次完整的持续交付流程。得益于RDC发布系统和RDC实验室的集成，我们可以在持续交付的流程中实现测试的卡点，测试不通过，无法进入下一个阶段的发布。
4.测试技术和方法
以下内容重点讨论测试方法和实现方案，以及如何通过RDC完成持续交付，不涉及代码实现，部分服务也会在未来上云提供给外部用户试用。
4.1 分层的自动化测试
原文链接