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
2）Why testing in production is a common and costly technical malpractice
我总结一下他的主要观点：
1）需要一个专用的测试环境进行测试，并且尽量模拟产品环境，否则容易引起产品的灾难性
2）在生产环境中测试的复杂性和不可控性
3）注意：他所谈的更多的传统的软件企业（ERP，MIS），并非真正的需要快节奏的互联网企业。
佚名 
2012-8-19 10:31:55 
