如何玩轉基于風險的測試

看到标題，很多同學可能會認為本文倡導“立即進入追蹤極端”的測試，其實不然，基于風險的測試需要qa與産品、開發等項目角色有更多的切磋。我們還是遵守事物發展規律，從頭說起。源起各項目的商業化發展，所有項目開發過程都轉向靈活，qa作為其中一員必然加入靈活大軍，順勢轉變工作方式。基于風險的測試可以簡單了解為問題驅動。那麼如何發現問題呢？答案就是“測試向前”，這也是靈活測試的核心，适用于所有類型的項目。

我們雲計算項目多年來一直遵循scrum的項目模式（這裡不對scrum進行介紹，可以問谷歌），疊代周期固定，釋出時間固定，面向企業使用者，品質一直是懸挂在頭頂上的利劍。今年，随着産品策劃團隊在團隊的不斷壯大，需求越來越多，項目流程必須做出改變，qa不能再等待開發通知疊代計劃和測試任務，而是要積極推動需求評審，圍繞需求的可行性、正确性和影響進行充分讨論，這時qa是對系統總體業務了解最多的角色，能夠分析出很多新需求對系統的影響，為需求的完整性提供建議。如果，此時預估到新需求會影響老功能，那麼qa會對這個需求重點分析，完成詳細測試分析。綜述，在需求澄清和确認環節，産出物是需求文檔和測試分析文檔(基于需求)，測試分析文檔除了進行功能點梳理，重要的是挖掘潛在風險。通過需求評審後，項目進入互動設計、開發設計、開發編碼、再次測試分析、測試用例設計、開發冒煙等環節，每個環節我們都指定品質負責人，owner制讓大家更有責任感，環環相扣的品質追蹤，最大程度的降低在測試過程中爆發新問題的可能性。受六道網測試體系的啟發，我們制定了七層品質保障體系，目前正在網易蜂巢（雲計算基礎服務）大團隊推行：

經過大家層層的品質把關，在項目後期正式轉交給qa測試時，主流程走通基本沒有問題。在産品化、商業化的今天，大家都努力追求産品的快速疊代，測試執行周期越來越短，如何利用有限的時間，保障系統的健壯性成為qa工作的重頭戲。具體做法：

一、我們不斷完善測試基礎部件：萬物都遵循從簡單到複雜的發展過程，(手工或自動化)測試也是一樣，一定是從簡單入手，逐漸增加深入和複雜程度。我們推薦持續內建的實施，盡可能的将可以自動化測試的功能用自動化覆寫，并把這些測試交給開發同學以便他們在開發過程中随時驗證（當然，最好還要有單元測試護駕）。另外我們的項目特别重視接口測試，而接口測試又特别依賴接口定義文檔，如果能在提測前給出接口定義文檔，那麼qa就會在上線前完成接口測試自動化開發。我們從api主流程測試入手，逐漸完善api測試，包括并發、邊界值、異常等。測試執行從純手工變成全自動化，測試效率提升n個檔。

二、我們在制定測試政策的時候，特别關注服務故障恢複能力、特别關注多方合作的功能、特别關注應用服務異常、特别關注大并發、大壓力的場景。

有時，用被害妄想症的思維去測試。比較理想的測試覆寫如下圖所示，項目組成員可以通力合作，根據系統特征打出一套漂亮的測試組合拳。

三、将異常注入、穩定性等測試平台化。通常，這類型的測試需要測試人員對被測系統和業務邏輯有很深入的清晰的了解，同時，需要掌握專業的測試工具，很多同學望而生畏（如，學習成本，測試效率）。是以，為了提高系統異常、穩定性測試的效率，降低測試門檻，我們逐漸開發了taas平台，将故障注入、異常、穩定性測試服務平台化，測試場景持久化。

四、品質評估，qa随時根據測試情況進行品質評估，針對發現的問題進行風險分析，必要時與産品、開發一起讨論問題的嚴重程度和解決方案，提供客觀的測試資料和品質評價，讓項目組成員對上線内容的品質有清晰的認識，這一工作也會持續指導下個疊代的工作内容或重點。

五、上線後持續跟蹤使用者使用情況，根據使用者使用場景反補測試場景，精确測試重點。常用的做法有url打點、全鍊路監控（log分析）、引流測試等，但對一些産品，這些方法還不夠，我們推薦qa走近使用者，與使用者進行交流訪談，了解其使用姿勢，挖掘需求，幫助qa更好的成為産品第一道使用者。

六、故障或線上bug回顧總結，這其實是問題驅動的典型案例。我們不害怕出現線上問題，重要的是正式問題，解決問題，舉一反三，避免重複出現類似的問題。

七、全民驗收，在時間緊任務重的情況下，發動更多的人進行測試是一個很好的方法。如組織bugbash，衆測等，都能降低上線後的品質風險。

當然，疊代過程中，我們還會遇到很多情況，如需求變更，任務優先級變更，設計變更等等，沒有關系，不要慌，relax，冷靜為什麼要分析變更，變更後需要哪些角色做出響應，哪些工作需要做出調整，迅速響應變更也是靈活裡面比較倡導的方面，積極應對這些變更，時刻保持風險意識，化繁為簡。

最後，提一下基于風險的測試用例設計。qa工作的直覺産出就是測試用例，也是應用文檔的核心，我們要求測試用例分層、分級、覆寫全面，不斷維護更新，在基于風險的用例設計過程中，我們用例編寫必須細緻，全面覆寫業務場景，并加大執行力度。測試用例的品質是不單是qa工作的門面，更是幫助項目組成員更好了解和保障品質的必要物件。毋庸置疑，測試用例的owner是qa，我們會根據需求和架構設計進行用例設計，如，先進行功能用例設計，再進行接口用例設計，最後進行端到端場景用例設計。通常，開發編碼與測試用例編寫齊頭并進，qa要盡可能早的提供測試用例并組織評審。qa根據需求或功能的重要性，發起平台線上用例評審或組織會議的用例評審，讓開發同學更好的了解測試和需求了解是否一緻的同時，也希望開發同學能提供一些測試建議，更好的保障測試覆寫的全面性。隻有産品、開發同學一起參與的用例評審才是有效的評審，才能更好的保障測試用例的品質，三方協作的力量不可小觑。

總而言之，“測試向前”很好的将問題提前發現、曝光，并降低風險或得以徹底解決。風險分析已經成為靈活開發的一部分，高風險的故事會受到更多的關注和讨論，團隊在制定疊代計劃和釋出時，也會根據風險考慮事項的優先級和釋出方式等。測試更應如此，因為我們沒有時間面面俱到的測試，是以需要利用風險分析評估需要做哪些測試才恰到好處。而這裡的“測試”不是狹義的測試，不單單是qa人員的工作，而是人人都是品質保障者，人人都參與項目建構過程。每個産品雖然所處環境不同，但目标都是高品質的為使用者提供服務，這就需要qa同學牽頭做好品質保障體系，采用靈活式的測試思維，調動團隊整體參與。切記“産品品質不是測試出來的”。

網易雲計算基礎服務深度整合了 iaas、paas 及容器技術，提供彈性計算、devops 工具鍊及微服務基礎設施等服務，幫助企業解決 it、架構及運維等問題，使企業更聚焦于業務，是新一代的雲計算平台，點選可免費試用。