【移动应用开发技术】让用户帮你做测试（AB测试）

【移动应用开发技术】让用户帮你做测试（AB测试）

我们知道，只要有软件就会有bug。一者，再严格的测试也只是抽样活动，总会有bug被遗留下来。再者，做软件也是一种商业行为，对质量的投入要看ROI。基于以上两种原因，软件或者系统发布时总会或多或少带点bug。对于这些bug，我们要看它的影响程度是什么样的。对于生命周期比较长的系统，这些bug只要产生了影响都是要修改的。要知道，bug的检测也是需要成本的，并且检测成本也会随着时间向后推移水涨船高。对于开发者来说，已发布版本的bug如何检测才能成本低且有效呢？显然已发布的软件会直面用户，从用户身上打主意是正途。再鸡贼一些，如何让用户在发布前就参与测试呢？在IT行业蓬勃发展的几十年间，涌现了大量让用户帮助开发者做测试的方法。下面就让我们一一道来。

α测试和β测试是上个世纪较为流行的两种用户测试方法。两者都是请用户真实的来使用系统，并反馈错误。两者最大的不同是，前者是请用户到开发者的环境中做测试；后者是用户在自己的环境中做测试。由于不同的用户所有的软硬件环境千差万别，因此在β测试中可能发现更多的兼容性问题。另一个稍小的区别就是α测试有可能是开发公司内部人员（微软流行的“吃你自己的狗食”），β测试则更倾向于外部的真实用户。β测试的测试成本较高，尤其是在互联网普及以前。我中学时代就做过β测试，那时候某家软件厂商在《电脑报》上招聘测试人员，被选中后会把被测软件寄来，你把测试结果写信寄回去，测试几乎不会给钱。但是当时唯一吸引我的是：软件装在6张3.5寸软盘里，当时对于我可是笔客观的财富。

但不这么做的成本会更高！在互联网能够几乎无成本分发软件之前，未经测试的软件需要以光盘或者软盘的形式发布，如果出现大错误，那损失可就大了。这错误就连伟大的暴雪公司也犯过，他们的游戏《魔兽争霸1》，没有经过很好的测试就在圣诞节发布了。由于兼容性等问题，很多客户拿到光盘后连装都装不上，这让暴雪赔了几百万美刀，差点丢了命微软臭名昭著的

有效做法。那自己或者自己的兄弟当小白鼠。内部人发现bug理应反馈，还不能拿酬劳，大家都是命运共同体嘛。这样，上班是员工，下班就变成了最终用户，甚至上班时候也变成了最终用户。原来有个同学在网易，有段时间工作时间联系他只能用网易泡泡，据说QQ被强制卸载了（不过泡泡现在还活着么？）。互联网时代来了。用户报bug的成本低了，因为错误信息可以很方便的传回去。所以在非常多的软件中你可以在它们崩溃后得到一个提示框：“您愿意帮助我们改进产品么？您的反馈对我们非常重要blablabla。。。”只要一点，调试信息就回传到开发者那里了。当然会有客户以在论坛，微博等平台上吐槽的形式推送bug。

发布特性、版本上有些许不同的软件给不同的用户。然后比较这些特性的造成的不同影响。A/B测试其实取自科学实验中的对照法。在实践中A/B测试的主要目的是为了改进软件特性、提高转化率等，发现bug反倒在其次了。想对A/B测试有跟深入了解可以googleA/B测试的网站，或者买这本书。

灰度发布本质上是A/B测试的一种变种。其实施方法是：某个软件的新特性推出或者特性进行升级的时候不是一下子发布给所有用户，而是按照一定的策略，逐步发布给所有用户。例如：某电商网站的推荐算法升级，先发布到一个二级城市，然后比较这个城市的推荐转化率是否提高了。当然现在很多互联网公司利用灰度发布来快速发布软件，比如某游戏升级，先选取一定比例的ip，比如1%的ip发布。如果出现问题，客户很快会在平台上以各种形式反馈（包括在游戏大厅或者论坛内吐槽），这时候开发者就知道有问题了，马上进行修复，然后继续灰度发布。等功能或者性能稳定了以后，继续提高发布比率，直至100%。这样做的好处是：能够迅速得到真实用户的反馈，且如果出现问题，不会大面积影响用户。

灰度发布是一种非常好的策略，但是它有时候也对少量用户造成了影响。有没有不影响用户，还能让用户做测试的方案么？这就是生产引流：从生产系统上将用户所有请求复制下来，引入到测试系统进行测试。这种方法尤其适合互联网软件，客户端越瘦，就越不用关注客户端的软硬件环境。生产引流可以用作性能测试和功能测试。现在性能测试用得比较广泛的是TCPCOPY，目前网易，百度，阿里都有广泛应用。想详细了解可以参见下面网站：

http://changelog.ca/log/2012/07/19/dark_launching_software_features

功能测试的实现手段根据被测系统的技术架构不同会有很大区别，根据被测系统的业务流程不同也会有很大区别，根据测试的意图也会有很大区别。后续我将举一个详细的例子来描述生产引流的测试方法。

黑暗部署的词是facebook的工程团队起的，但其实很多团队早已经这么做了，只是没有总结出来而已。其主要思路是：把