傳統測試方式和ABTest的區別究竟在哪裡？如果一個產品功能有兩個解決方案，兩個方案孰優孰劣我們不清楚，那該怎麼辦呢？來自新浪新聞客戶端的測試專家韓明豹通過傳統測試方式與ABTest的對比分析為你進行解答！

1、AB Test Framework產生的背景

新浪新聞客戶端視訊聯播頁面現存兩種介面，第一種是依次往下聯播，另一種則是以列表的形式展示未來播放的視訊。

以上兩種聯播介面哪個是最好的，我們不知道。首先沒有資料幫助我們進行分析，其次沒有實踐以及使用者來論證，所以需要向使用者拿資料。我們應該怎樣獲取使用者資料呢？在不傷害使用者的前提下，在小範圍影響下，利用一個渠道將部分功能投向使用者，然後獲取統計資料，進行相關調研，再決定哪個方案更優。
普通的實現方法：第一個是分渠道包，第二個是做出伺服器可配置的功能，將一部分使用者灰度開啟。經過客戶端來判斷，把程式碼寫在客戶端裡面，根據時間、機型等條件部分開啟灰度功能。
但是這些方法都具有弊端，第一不夠靈活，技術實現複雜度比較高，成本也比較高；我們一旦將這個功能拋向市場有些是不可控，釋出之後出現問題是不可能立刻將它下線的，風險比較大；再一個實驗的週期比較長，至少需要一個版本才能拿到有益的資料；
基於這些問題提出瞭解決方案：
第一個是縮短試錯週期。每個功能如果都需要兩個版本反覆測試，效率會很低。
第二個是減少使用者的傷害。因為一旦傷害了使用者，會造成使用者對應用的解除安裝。
第三個是降低製作成本。降低開發成本，減少不必要的人力投入。
需要資料反應速度快，然後保證APP正常功能的穩定性。

2、AB Test 系統架構

AB Test系統架構主要分為以下幾個方面：第一個策略的制定者即AB Test策略伺服器，還有執行到我們客戶端裡面的AB Test SDK，它是管理整個策略對上層業務升調機制的，再有我們的資料統計機制，我們採用的是現在比較成熟的sima日誌系統。主要的流程就是我們的AB Test SDK通過攜帶一些機型、座標及其他類引數上報給我們的AB Test測試伺服器，然後由AB Test測試伺服器經過運算對指定使用者產生一個指定策略，然後下發給AB Test SDK，SDK經過處理加工之後會對上層業務提供策略，上層業務根據策略執行相關的邏輯程式碼之後，會產生一些行為日誌，通過sima來上報，我們會通過sima後臺匯出資料。通過資料分析得出一些結論，如果需要其它的嘗試，我們可以重新配置我們的伺服器，進行下一輪的灰度測試。

3、AB Test 決策流程

AB Test決策的一般流程，首先從一個功能提出，一般會預想兩個方案，經過AB Test系統決策，對小規模的使用者進行分統，確定出哪個方案應用到哪些使用者上。AB Test系統經過一系列的比對，綜合這些後臺配置資訊，還有各種策略的維度，計算出對應策略，下發給SDK，SDK會通過會控制一些上層業務邏輯的執行邏輯程式碼統計資料，根據統計資料的收集系統初步得出結論。灰度可能在很短的時間就可以得出結論了，把這個結論直接反饋到AB系統裡，然後通過後臺的配置直接將全部使用者切到我們已經論證過的方案上。如果對樣本不太滿意，可以通過動態改變後臺的配置，重新分統並且重新進行第二輪的灰度實驗。

4、AB Test 策略維度

AB Test目前已可以對包括新聞資訊、地理座標、版本資訊、釋出渠道、城市、網路型別等進行判斷，更多的維度正在持續擴充中。

5、AB Test 生效機制

AB Test有一個生效機制，可以根據策略伺服器下發的生效機制對某些策略進行生效。一般分為立即生效，在拿到伺服器下發的策略後，會將策略立即生效，並通知相關策略的使用者，
立即生效主要用於使用者不會及時感知的行為。
還有熱啟生效以及冷啟生效。熱啟生效就是退出介面，重新進入生效（可用於調整介面，但需使用者注意業務邏輯，防止出現異常），冷啟生效就是殺死程式之後，重新進入生效（用於調整介面，風險低）。兩個啟動之間區別不是很大，熱啟會比冷啟實時一些；冷啟會比熱啟更加安全一些，可以防止一些程式碼初始化造成異常。

6、AB Test SDK技術實現
AB Test SDK的實現幾乎不佔用系統什麼資源，主要包括ABTestCore，主要功能是完成策略快取、策略讀取、會根據上層對介面的實現來判斷策略的有效性，再執行上層已經註冊過來的對應策略的程式碼塊；再上層是一個ABTestManager，主要用來拉取策略，上報各個維度資訊，做一些策略快取，根據不同時機進行立即、熱啟、冷啟生效，在某些時機對策略進行生效。
再往上一層是AB Test SDK要用到的一些泛型Bean，還有APP使用者要用到的介面（Interface），這些介面是ABTestCore來使用的，主要作用是根據上層判斷邏輯來判斷對應策略的有效性。

7、AB Test 後臺

AB Test 後臺伺服器根據後臺配置以及維度匹配生成對應的策略。後臺配置是後臺管理人員來干預的；維度匹配，當一個策略提出的時候，會明確出覆蓋到哪些人，這些都會經過後臺配置，包括它的範圍、時間以及生效方式。當客戶端帶著我們的維度資訊上報的時候，經過運算對相應的客戶端產生相應的策略，然後策略下發到AB Test SDK，AB Test SDK進行處理再對上層的業務邏輯進行生效。

8、資料統計（sima）

日誌上報並不複雜，AB Test SDK在獲取策略時會上報灰度資訊到日誌伺服器，AB Test在執行灰度功能的時候也會進行上報，這兩者的上報會彙總到sima，通過sima資料的比對分析可以大致判斷每個功能的使用情況。

9、案例分析

在新浪新聞客戶端現有兩個重新整理功能，一個是正在上線的下拉重新整理功能，還有一個是正在灰度中的重新整理功能，還沒有完全放開，影響範圍比較小。
另一個是明日頭條功能，這功能陸陸續續已經做了有100個左右，包括那些已經確定和正線上上進行灰度實驗的功能。
AB Test與傳統方式相比，測試、定型週期只需一個版本，比傳統測試方式相比至少需要少一個版本測試；AB Test對使用者的影響比較小，可以隨時下線，而傳統的測試方式一旦上線，將會持續一個版本； AB Test實現起來相對簡化，而傳統方式需要專人跟蹤，實現起來比較複雜；傳統方式的統計資料需要經過一個版本才會有意義，AB Test可以進行實時更改；
傳統方式不支援個性化定製，一個APP對應一個使用者展現不同的組合，在傳統方式裡無法實現的， AB測試支援個性化定製。

10、AB Test未來規劃

1、加入智慧的資料的演算法，以及多維度的分析；
2、加入多策略分析，進行大資料的挖掘，分析各個策略之間的相互影響。
3、加入推送生效機制，通過AB Test SDK進行策略獲取，實效比較低，加入推送策略機制，會推送給相關使用者，實現立即生效。
4、完善AB Test平臺機制，將sima日誌進行上報，策略配置進行整合。