快速疊代的開發方式中的QA實踐方法

盡管"小步快跑"的快速疊代開發方式早已成為網際網路軟體開發的主流指導思想，但大量開發團隊在落地這一開發方式時最常遇到的問題就是"如何qa"，因為，傳統軟體行業的qa方式(手動測試，回歸測試等)無法适應每天多次上線的疊代節奏。這時，開發團隊往往會面臨這兩種窘境: 要麼是為了速度不顧品質，導緻線上故障頻發；要麼是為了品質而固定釋出視窗，導緻業務不夠靈活。

那麼，在快速疊代的開發方式下，究竟應該采用怎樣的qa實踐才既能控制住風險又能跟上節奏？

本文對小博無線技術團隊在2014-2016三年間的qa實踐之路進行了總結，并對上面的問題給出如下的答案:

qa無法作為業務變更釋出前的一個獨立環節存在，它必須被滲透在開發，運維和資料分析的過程中。

采用這種"滲透式"的qa實踐方法，我們的線上生産環境可以每天釋出數十次變更，并且風險可控。

由于引入專門的測試人員會帶來額外的溝通成本以及在多個系統并行開發上線時在測試人力資源上會形成瓶頸，我們并沒有設定專職測試人員。功能測試主要由開發人員自測，上線前的驗證流程如下：

在自己的開發環境中測試；

在預釋出環境中測試, 如有必要，請産品功能設計人員協助測試，主要看對業務功能了解是否正确；

提出合并變更到釋出分支的merge request；

和另一位開發人員共同逐行閱讀該change，向ta說明每一行change的原因。如發現功能實作上的問題，需修改後才能上線；如隻是風格方面的問題，則可先上線再重構，重構後再上線一次。

友善內建測試

友善開發和産品之間的溝通

在代碼共閱時友善開發之間的溝通

當merge request通過code review，确認可以上線後，由開發人員自己上線。為了降低風險，提升效率和舒适度，整個上線動作隻需要開發人員在ci系統中一鍵部署即可全自動完成無感覺漂移上線[1]. 除了一鍵部署外，運維基礎設施至少還需要提供下面幾個基礎功能:

原則上，能不復原則不復原，一般隻有在出現影響可用性的嚴重問題，萬不得已才會復原。雖然復原極少發生，但保證可復原的變更設計卻非常重要，任何一個變更都要盡可能設計為可回退的。當新版本上線後發現未預見的嚴重問題時，可以一鍵回退到上一個能正常工作的版本。

使用運維機器人收集并分析系統日志，監控錯誤日志的數量變化趨勢，當某個服務的錯誤日志數量變化率明顯增大時，向該服務的開發和運維人員推送告警。這樣，如果新版代碼存在問題，開發人員在其上線後的幾分鐘内就能收到告警，并決定是快速修複還是復原。

如果釋出的某個變更位于影響全局的基礎功能子產品，為了降低風險，可采用灰階釋出，先使用新版本代碼處理一小部分流量，觀察一段時間，确認無異常後再将新版代碼應用到全網。

資料驅動qa是一種通過檢視，分析或統計資料來确認目前系統狀态是否正常，或确定新版代碼的實作效果和舊版相比是有提高還是下降的測試辦法。

從這個意義上說，上面的"錯誤監控和告警推送"亦可算是資料驅動qa的方法之一，另外，常用的資料驅動qa的方法還有:

使用運維機器人周期性檢查關鍵業務資料之間的不變式限制是否成立，例如記賬系統中的賬目始終要保持平衡，一旦發現不平衡要及時告警并查出原因

檢查關鍵業務名額是否平穩，例如上一個小時的成單量，不應偏移平均值太多，如果下降太多，有可能是系統可用性下降；如果上漲太多，則有可能存在惡意刷單

統計和比較不同版本的關鍵性能名額，利用資料來判斷究竟哪個版本的品質更好