讓使用者幫你做測試（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，目前網易，百度，阿里都有廣泛應用。想詳細瞭解可以參見下面網站：   功能測試的實現手段根據被測系統的技術架構不同會有很大區別，根據被測系統的業務流程不同也會有很大區別，根據測試的意圖也會有很大區別。後續我將舉一個詳細的例子來描述生產引流的測試方法。

 

• 黑暗部署

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