一、背景

盡管"小步快跑"的快速叠×××發方式早已成為互聯網軟件開發的主流指導思想，但大量開發團隊在落地這一開發方式時最常遇到的問題就是"如何QA"，因為，傳統軟件行業的QA方式(手動測試，回歸測試等)無法適應每天多次上線的叠代節奏。這時，開發團隊往往會面臨這兩種窘境: 要麽是為了速度不顧質量，導致線上故障頻發；要麽是為了質量而固定發布窗口，導致業務不夠敏捷。

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

本文樂搏教師團隊多年的測試經驗進行了總結，並對上面的問題給出如下的答案:

QA無法作為業務變更發布前的一個獨立環節存在，它必須被***在開發，運維和數據分析的過程中。

采用這種"***式"的QA實踐方法，我們的線上生產環境可以每天發布數十次變更，並且風險可控。

二、開發中的QA

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

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

2、在預發布環境中測試， 如有必要，請產品功能設計人員協助測試，主要看對業務功能理解是否正確；

3、提出合並變更到發布分支的merge request；

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

三、預發布環境的意義

1、方便集成測試

2、方便開發和產品之間的溝通

3、在代碼共閱時方便開發之間的溝通

四、運維中的QA

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

　一鍵回滾

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

錯誤監控和告警推送

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

灰度發布

　　如果發布的某個變更位於影響全局的基礎功能模塊，為了降低風險，可采用灰度發布，先使用新版本代碼處理一小部分流量，觀察一段時間，確認無異常後再將新版代碼應用到全網。

五、數據驅動QA

數據驅動QA是一種通過查看，分析或統計數據來確認當前系統狀態是否正常，或確定新版代碼的實現效果和舊版相比是有提高還是下降的測試辦法。

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

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

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

3、統計和比較不同版本的關鍵性能指標，利用數據來判斷究竟哪個版本的質量更

好了，你們看完了文章，我也給你們分享一下資料。

接口測試相關資料

鏈接：https://pan.baidu.com/s/1ojpoWnpxxReR1sO2Gxy_YQ 密碼：dgfa

性能測試相關資料

鏈接：https://pan.baidu.com/s/1_oZhvOIRvcz0JGcCWUGT-g 密碼：d82b

軟件測試入門提升電子書

鏈接：https://pan.baidu.com/s/1Fp8CFE0D2p0uAZk6xcexhQ 密碼：exna

自動化測試相關資料

鏈接：https://pan.baidu.com/s/1yeD1EMg-HalNuRBDODGx7g 密碼：ofdg

【軟件測試】軟件測試工程師——如何“跑”在項目的最前面！！！