Testing In Production 在生产环境中进行测试 摘要

　　Testing In Production 的概念大约出现3年前，那时候Web Service正在风靡Internet，各种系统都走向更加可扩展的架构，这使得A/B Testing和后期的数据分析更加容易。同时，整个互联网应用对用户体验提出了更高的要求，对算法的精准性的要求更加严格。另外，软件开发的节奏明显加快，这使得测试无法在发布前做的非常完善。快节奏的软件发布，对测试有了更高的要求。 “先发布，后测试”成为一种加快发布节奏的一种必要的方法。

　　动物学家达尔文说过 ”世界上进化下来的动物，并不是那些最强大的动物，也不是那些最聪明的动物，而是那些最能够适应变化(Responsive to change)的动物”，例如说老鼠，人，蚂蚁等等。软件系统也一样，能够传承发扬的软件，能够快速适应变化化。

　　TiP的核心思想就是通过在生产环境里面测试，最小化产品风险，加快发布节奏。TiP通过暴露新代码给有限用户，减少缺陷可能带来的负面影响，通过在产品中暴露这些新代码，可以快速获得这些新代码的反馈，这些反馈来之于真实的用户，而不是少量的测试人员和有限的测试用例。另外，一旦发现新代码有严重的缺陷，那么TiP需要快速修复这些缺陷，通过发布新版本或则滚回到老版本。

　　那么这是不是对软件质量的一种妥协呢? 我觉得不是，相反在生产环境中测试可以更好的满足用户,它是传统发布前测试的一个积极的补充。例如，TiP可以帮我们提高测试覆盖率，找到一些平时无法测试到的场景。

　　我相信，所有的互联网软件都需要支持TiP，这是互联网软件的特性决定的：灵活的软件架构，快速的发布周期。

　　考虑一下几个问题可以帮助我们思考什么类型的软件最适合TiP方法。

　　用户体验和经济利益影响的程度

　　如果产品有问题，是否有能力快速检查产品中的问题，并且快速回退到没有问题的版本?

　　软件发布的频率?

　　进行TiP 所带来的成本和收益

　　这里有几个TiP的例子

　　1) 微软：在互联网的产品开发过程中，微软也大量利用了TiP的方法

　　a. 很多用户场景的改进，都是通过A/B测试获得最好的效果

　　b. 算法实验，在灵活的平台中进行算法的调优和筛选

　　2) Facebook : Facebook如何发布代码的 Link

　　a. Facebook有多个级别的代码部署 (内部的，少量外部的，全部外部的等等..),

　　b. 如果有问题出现，工程师马上修复问题;然后重新发布

　　c. Ops负责部署的实际过程，包括检测产品的健康状态(错误日志，CPU，内存，甚至包括用户的行为变化等)

　　3) Google： 非常善于做A/B测试

　　a. 谷歌在算法改进方面，就是利用在产品中的实验平台。一个搜索结果中可能包括多个算法的结果，另外不同的搜索可能触发不同的算法。最后通过用户的反馈，对算法进行评价和挑选。

　　一些参考资料：

　　人物：

　　Seth Eliot 微软测试经理，Testing in Production的倡导者 Blog

　　参考文章:

　　1) Testing in Production, Your key to Engaging Customers, Seth Eliot (QASIG 2011 论文：Link

　　2) Why testing in production is a common and costly technical malpractice (IBM Mahesh Rathi, Link)

　　我总结一下他的主要观点，详细的请看Link:

　　1) 需要一个专用的测试环境进行测试，并且尽量模拟产品环境，否则容易引起产品的灾难性

　　2) 在生产环境中测试的复杂性和不可控性

　　3) 注意：他所谈的更多的传统的软件企业(ERP,MIS)，并非真正的需要快节奏的互联网企业。

原文转自：http://www.ltesting.net