互聯網經濟的今天，一個想法就是一桶金，很多時候想法有了，已經做好了開發產品的計劃，但是開發速度有的時候影響了產品的上線時間，導致桶里就剩下半桶金了，這樣的案例不在少數，所以現在產品開發速度，迭代速度激增，今天就為大家講解一下快速迭代下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、統計和比較不同版本的關鍵性能指標，利用資料來判斷究竟哪個版本的質量更好
end
最后感謝每一個認真閱讀我文章的人，看著粉絲一路的上漲和關注，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：
這些資料，對于【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴上萬個測驗工程師們走過最艱難的路程，希望也能幫助到你!
在我的QQ技術交流群里（技術交流和資源共享，廣告勿擾）
可以自助拿走，群號：310357728群里的免費資料都是筆者十多年測驗生涯的精華，還有同行大神一起交流技術哦
如果對你有一點點幫助，各位的「點贊」就是小編創作的最大動力，我們下篇文章見！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/299169.html
標籤：其他
上一篇：java拼團小程式原始碼(畢設)