讓用戶幫你做測試（A/B測試）

我們知道，只要有軟件就會有bug。一者，再嚴格的測試也只是抽樣活動，總會有bug被遺留下來。再者，做軟件也是一種商業行為，對質量的投入要看ROI。基于以上兩種原因，軟件或者系統發布時總會或多或少帶點bug。對于這些bug，我們要看它的影響程度是什么樣的。對于生命周期比較長的系統，這些bug只要產生了影響都是要修改的。要知道，bug的檢測也是需要成本的，并且檢測成本也會隨著時間向后推移水漲船高。對于開發者來說，已發布版本的bug如何檢測才能成本低且有效呢？顯然已發布的軟件會直面用戶，從用戶身上打主意是正途。 再雞賊一些，如何讓用戶在發布前就參與測試呢？在IT行業蓬勃發展的幾十年間，涌現了大量讓用戶幫助開發者做測試的方法。下面就讓我們一一道來。

• α測試和β測試

     α測試和β測試是上個世紀較為流行的兩種用戶測試方法。兩者都是請用戶真實的來使用系統，并反饋錯誤。兩者最大的不同是，前者是請用戶到開發者的環境中做測試；后者是用戶在自己的環境中做測試。由于不同的用戶所有的軟硬件環境千差萬別，因此在β測試中可能發現更多的兼容性問題。另一個稍小的區別就是α測試有可能是開發公司內部人員（微軟流行的“吃你自己的狗食”），β測試則更傾向于外部的真實用戶。β測試的測試成本較高，尤其是在互聯網普及以前。我中學時代就做過β測試，那時候某家軟件廠商在《電腦報》上招聘測試人員，被選中后會把被測軟件寄來，你把測試結果寫信寄回去，測試幾乎不會給錢。但是當時唯一吸引我的是：軟件裝在6張3.5寸軟盤里，當時對于我可是筆客觀的財富。 但不這么做的成本會更高！在互聯網能夠幾乎無成本分發軟件之前，未經測試的軟件需要以光盤或者軟盤的形式發布，如果出現大錯誤，那損失可就大了。這錯誤就連偉大的暴雪公司也犯過，他們的游戲《魔獸爭霸1》，沒有經過很好的測試就在圣誕節發布了。由于兼容性等問題，很多客戶拿到光盤后連裝都裝不上，這讓暴雪賠了幾百萬美刀，差點丟了命

• 吃自己的狗食

微軟臭名昭著的 有效做法。那自己或者自己的兄弟當小白鼠。內部人發現bug理應反饋，還不能拿酬勞，大家都是命運共同體嘛。這樣，上班是員工，下班就變成了最終用戶，甚至上班時候也變成了最終用戶。原來有個同學在網易，有段時間工作時間聯系他只能用網易泡泡，據說QQ被強制卸載了（不過泡泡現在還活著么？）。

• 故障推送

互聯網時代來了。用戶報bug的成本低了，因為錯誤信息可以很方便的傳回去。所以在非常多的軟件中你可以在它們崩潰后得到一個提示框：“您愿意幫助我們改進產品么？您的反饋對我們非常重要blablabla。。。” 只要一點，調試信息就回傳到開發者那里了。當然會有客戶以在論壇，微博等平臺上吐槽的形式推送bug。

• A/B測試

發布特性、版本上有些許不同的軟件給不同的用戶。然后比較這些特性的造成的不同影響。A/B測試其實取自科學實驗中的對照法。在實踐中A/B測試的主要目的是為了改進軟件特性、提高轉化率等，發現bug反倒在其次了。想對A/B測試有跟深入了解可以google A/B測試的網站，或者買這本書。

• 灰度發布

      灰度發布本質上是A/B測試的一種變種。其實施方法是：某個軟件的新特性推出或者特性進行升級的時候不是一下子發布給所有用戶，而是按照一定的策略，逐步發布給所有用戶。例如：某電商網站的推薦算法升級，先發布到一個二級城市，然后比較這個城市的推薦轉化率是否提高了。當然現在很多互聯網公司利用灰度發布來快速發布軟件，比如某游戲升級，先選取一定比例的ip，比如1%的ip發布。如果出現問題，客戶很快會在平臺上以各種形式反饋（包括在游戲大廳或者論壇內吐槽），這時候開發者就知道有問題了，馬上進行修復，然后繼續灰度發布。等功能或者性能穩定了以后，繼續提高發布比率，直至100%。這樣做的好處是：能夠迅速得到真實用戶的反饋，且如果出現問題，不會大面積影響用戶。

• 生產引流

       灰度發布是一種非常好的策略，但是它有時候也對少量用戶造成了影響。有沒有不影響用戶，還能讓用戶做測試的方案么？這就是生產引流：從生產系統上將用戶所有請求復制下來，引入到測試系統進行測試。這種方法尤其適合互聯網軟件，客戶端越瘦，就越不用關注客戶端的軟硬件環境。生產引流可以用作性能測試和功能測試。現在性能測試用得比較廣泛的是TCPCOPY，目前網易，百度，阿里都有廣泛應用。想詳細了解可以參見下面網站： http://changelog.ca/log/2012/07/19/dark_launching_software_features  功能測試的實現手段根據被測系統的技術架構不同會有很大區別，根據被測系統的業務流程不同也會有很大區別，根據測試的意圖也會有很大區別。后續我將舉一個詳細的例子來描述生產引流的測試方法。

• 黑暗部署

黑暗部署的詞是facebook的工程團隊起的，但其實很多團隊早已經這么做了，只是沒有總結出來而已。其主要思路是：把新開發的特性部署到生產系統上，并有一個開關來快速的控制這個特性是否讓用戶可見，在部署的初期，這個開關是關閉的。有人要問，這么做有啥用？其實可以結合生產引流配合測試，也可以查看新上的特性是否影響原有系統的正常運行。