背景
　　尽管"小步快跑"的快速迭代开发方式早已成为互联网软件开发的主流指导思想，但大量开发团队在落地这一开发方式时常遇到的问题是"如何QA"，因为，传统软件行业的QA方式(手动测试，回归测试等)无法适应每天多次上线的迭代节奏。这时，开发团队往往会面临这两种窘境: 要么是为了速度不顾质量，导致线上故障频发；要么是为了质量而固定发布窗口，导致业务不够敏捷。
　　那么，在快速迭代的开发方式下，究竟应该采用怎样的QA实践才既能控制住风险又能跟上节奏？
　　本文对小博无线技术团队在2014-2016三年间的QA实践之路进行了总结，并对上面的问题给出如下的答案:
　　QA无法作为业务变更发布前的一个独立环节存在，它必须被渗透在开发，运维和数据分析的过程中。
　　采用这种"渗透式"的QA实践方法，我们的线上生产环境可以每天发布数十次变更，并且风险可控。
　　开发中的QA
　　由于引入专门的测试人员会带来额外的沟通成本以及在多个系统并行开发上线时在测试人力资源上会形成瓶颈，我们并没有设置专职测试人员。功能测试主要由开发人员自测，上线前的验证流程如下：
　　1、在自己的开发环境中测试；
　　2、在预发布环境中测试， 如有必要，请产品功能设计人员协助测试，主要看对业务功能理解是否正确；
　　3、提出合并变更到发布分支的merge request；
　　4、和另一位开发人员共同逐行阅读该change，向TA说明每一行change的原因。如发现功能实现上的问题，需修改后才能上线；如只是风格方面的问题，则可先上线再重构，重构后再上线一次。
　　预发布环境的意义
　　1、方便集成测试
　　2、方便开发和产品之间的沟通
　　3、在代码共阅时方便开发之间的沟通
　　运维中的QA
　　当merge request通过code review，确认可以上线后，由开发人员自己上线。为了降低风险，提升效率和舒适度，整个上线动作只需要开发人员在CI系统中一键部署即可全自动完成无感知漂移上线[1]. 除了一键部署外，运维基础设施至少还需要提供下面几个基础功能:
　　一键回滚
　　原则上，能不回滚则不回滚，一般只有在出现影响可用性的严重问题，万不得已才会回滚。虽然回滚极少发生，但保证可回滚的变更设计却非常重要，任何一个变更都要尽可能设计为可回退的。当新版本上线后发现未预见的严重问题时，可以一键回退到上一个能正常工作的版本。
　　错误监控和告警推送
　　使用运维机器人收集并分析系统日志，监控错误日志的数量变化趋势，当某个服务的错误日志数量变化率明显增大时，向该服务的开发和运维人员推送告警。这样，如果新版代码存在问题，开发人员在其上线后的几分钟内能收到告警，并决定是快速修复还是回滚。
　　灰度发布
　　如果发布的某个变更位于影响全局的基础功能模块，为了降低风险，可采用灰度发布，先使用新版本代码处理一小部分流量，观察一段时间，确认无异常后再将新版代码应用到全网。
　　数据驱动QA
　　数据驱动QA是一种通过查看，分析或统计数据来确认当前系统状态是否正常，或确定新版代码的实现效果和旧版相比是有提高还是下降的测试办法。
　　从这个意义上说，上面的"错误监控和告警推送"亦可算是数据驱动QA的方法之一，另外，常用的数据驱动QA的方法还有:
　　1、使用运维机器人周期性检查关键业务数据之间的不变式约束是否成立，例如记账系统中的账目始终要保持平衡，一旦发现不平衡要及时告警并查出原因
　　2、检查关键业务指标是否平稳，例如上一个小时的成单量，不应偏移平均值太多，如果下降太多，有可能是系统可用性下降；如果上涨太多，则有可能存在恶意刷单
　　3、统计和比较不同版本的关键性能指标，利用数据来判断究竟哪个版本的质量更好