從測試流程角度,對產品質量的一些總結思考

兩個熟悉的場景:

  1. 生產環境出現問題,解決問題,原因覆盤、責任分配到人;
  2. 無休止的測試-迴歸-再測試-再回歸測試,已經投入了很大精力,但仍對項目質量不信心;

如果自己所負責或參與的項目經常遇到上面的兩種情況,不妨從項目測試流程角度,去思考原因以及破開瓶頸的方法。

測試流程拆解

需求評審

通過參與技術設計評審,可以爲測試方案提供依據。例如:核心業務是否需要接口測試、新老數據兼容問題、測試場景的數據構造以及測試所需的工具等,都可以在這個階段進行思考和產出。

另外,可以有效的評估需求影響範圍和風險點,避免遺漏。

此階段是質量的基石,通過測試左移,儘早發現需求設計缺陷、技術方案風險、關聯方依賴影響等方面,瞭解測試關注點,需求可測試性以及預留排期等問題。

舉例:

  • 接口測試:權益覈銷&&退款,接口都需要對前端傳入的參數進行校驗。

  • 新老數據兼容,比如說小程序的發版,一般會滯後於接口發佈,一定要測試舊版本的兼容性;

測試方案設計

  1. 測試用例設計:需要從整體入手,而不僅僅侷限於待測功能本身的業務邏輯。 好的測試用例,是質量保證的核心;

  2. 測試用例評審:避免三方需求不一致,減少測試執行階段做無效工作,如執行無效用例、提交無效BUG等;

  3. 測試數據準備;

此階段是質量的骨架,通過測試設計,覆蓋更多的測試點、模擬更多的場景、做好更充分的測試準備,爲質量保駕護航,爲測試贏得更多寶貴的時間。

測試用例這一步不能忽略,即使改動很小,排期很緊,也建議要畫出思維導圖;要想提高測試用例設計能力,就需要平時就要多積累,對常見的缺陷模式、典型的錯誤類型以及遇到過的缺陷,要不斷地總結、歸納,才能逐漸形成體系化的用例設計思維。

同時,對於高質量的測試活動,用例設計不僅需要考慮明確的顯式功能性需求,還要涉及兼容性、安全性和性能等一系列的非功能性需求。

好的測試用例是如何定義的?

不應該從是否能發現BUG的維度去定義,而是應該從集合的完備性角度去思考,也就是測試用例是否能夠覆蓋所有等價類以及各種邊界值爲維度去衡量。

如果把被測系統看作一個池塘,BUG是池塘中的魚,設計測試用例集的過程就像是在編織一張捕漁網。好的用例集就是一張能夠覆蓋整個池塘的大漁網,只要池塘裏有魚,這個大漁網就一定能把魚給撈上來。如果漁網本身是完整的且合格的,那麼撈不到魚,就證明池塘中沒有魚,而漁網的好壞與池塘中是否有魚無關。漁網眼就是測試用例的粒度,粒度越大,意味着網眼越大,這就只能捕撈大魚,一些小魚就會漏網。這也是一些項目通用的現狀,測試活動由於受限於時間成本和經濟成本,只能採用基於風險驅動的模式,選擇合適的測試粒度,即有所側重地選擇測試範圍和設計測試用例,以尋求缺陷風險和研發成本之間的平衡。

  • 整體完備性: “好的”測試用例一定是一個完備的整體,是有效測試用例組成的集合,能夠完全覆蓋測試需求;

  • 等價類劃分的準確性: 指的是對於每個等價類都能保證只要其中一個輸入測試通過,同子集下其他輸入也一定測試通過;

  • 等價類集合的完備性: 需要保證所有可能的邊界值和邊界條件都已經正確識別。做到了以上三點,就可以肯定測試是充分且完備的,即做到了完整的測試需求覆蓋。

線下測試(含灰度)

  1. 橫向覆蓋:對於一個場景,從開始到結束涉及到的關鍵節點,都要進行檢查點覆蓋,包括功能實現、數據讀取、數據計算、數據寫入等的正確性;

  2. 縱向覆蓋:正常場景、異常場景、補償場景都要覆蓋;

  3. 探索性測試:憑個人經驗進行探索性測試;

  4. 迴歸測試:拉取回歸測試集,手動測試和自動化測試相結合,在測試環境驗證新功能對原有功能是否產生影響;

此階段是質量的成型,通過測試設計的充分準備、線下測試的嚴格、立體的執行,發現和解決絕大部分問題。

探索性測試

根據需求描述來設計最初的測試用例,然後執行測試;在執行過程中,如果得到的輸出和預期輸出不完全一致,於是會猜測這種不一致是否可能是軟件的缺陷造成的;爲了驗證想法,你會根據錯誤輸出,設計新的測試用例,然後採用不同的輸入再次檢查軟輸出。經過幾輪這樣的猜測和驗證,進行反覆“探索”,最終確定了一個軟件的缺陷。

而識別缺陷的思路和測試用例的設計,並沒有出現在最初的測試設計和測試用例文檔中。探索性測試是一種測試風格,並且強調依據當前項目上下文選擇最適合的測試技術。同樣的測試風格,由不同的人來具體執行,得到的結果可能會差別巨大,一直強調測試分析能力是最重要的技能。

線上測試

  1. 迴歸測試:拉取線上迴歸測試集,並結合自動化測試,保證核心流程測試通過;

  2. 新功能測試:拉取新功能快速驗證測試集,並確保覆蓋新功能核心測試點;

此階段是版本質量終態,線上測試主要是爲了確保代碼部署、生產配置、生產環境對質量的影響。

測試覆盤

在發佈上線後,對測試過程進行復盤,總結遇到的問題,對當時的解決方案進行探討。通過覆盤,從而達到指導後續工作,減少重複踩坑。並在可以在個人覆盤完成後,在部門內進行信息共享。每個人負責的項目雖然不同,但是測試思想確有共通之處。通過覆盤分享,可以有效提升團隊整體測試經驗。

此階段是測試經驗累積階段,也是容易被忽略的階段。通過信息共享,大大降低重複踩坑的概率。

線上監控

通過選取業務流程中優先級高的測試用例,作爲心跳測試用例定時運行,並持續進行補充完善。

接口測試用例的開發進度落後於新功能的發佈節點。自動化不是跟着新需求走,而是測變化的東西對不變東西的影響。

此階段是測試活動右移,質量補償,快速響應和解決,降低生產事故造成的損失。

總結

  1. 通過規範測試流程,全覆蓋產品生命週期,量化測試產出,在有限測試資源下的提升產出;

  2. 推動力是衡量測試角色能力的重要指標,特別是一些需求不明確的項目,在各個階段都要保證信息在團隊成員間的一致性;

目前的不足之處:

  1. 測試用例評審流程:郵件or會議, 需要產研給出積極響應;

  2. 測試各階段的准入準出條件模糊:進入測試、進入開發,要有基本的要求,一環連着一環,在某些階段確實可以加入一些提交基線,比如進入測試階段,之前增加提測基線(類似冒煙);

  3. 技術沉澱不足,異常場景模擬依賴開發人員;

【To Be Continue...】

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章