互聯網經濟的今天，一個想法就是一桶金，很多時候想法有了，已經做好了開發產品的計劃，但是開發速度有的時候影響了產品的上線時間，導致桶裏就剩下半桶金了，這樣的案例不在少數，所以現在產品開發速度，迭代速度激增，今天就爲大家講解一下快速迭代下QA的生存之道！
一、背景
儘管"小步快跑"的快速迭×××發方式早已成爲互聯網軟件開發的主流指導思想，但大量開發團隊在落地這一開發方式時最常遇到的問題就是"如何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
自動化測試相關資料