天天看點

如何做到測試場景不遺漏?

測試分析與設計

測試是一門精細的學科,新人同學很容易有的誤區是認為做測試主要就是編寫測試用例和執行測試用例,進階能力是寫自動化腳本或研發工具。而實際上,測試人員最難修煉的是測試分析能力,測試分析能力是衡量一位測試同學是否專業的分水嶺。分析除了使用方法,還需要有對業務、經驗、品質的深度了解。自動化或工具實際是對分析和設計結果的一種實作,分析和設計的有效會決定實作的效果。

分析與設計過程

測試分析要從業務需求最開始就要介入,流程覆寫業務整個生命周期。在做分析的過程要想清楚,整體後續的設計怎麼做。

測試分析可總結為四步:

  • 模組化 - 輸出業務/系統流程(分析:業務流程 - 系統流程)
  • 設計 - 測試場景(設計:測試場景)
  • 細分 - 測試用例/資料(設計:測試用例)
  • 擴充 - 多類型測試(性能,安全,異常等等)(基于經驗)
如何做到測試場景不遺漏?

測試場景分析實施

測試場景和測試用例差別是什麼?為什麼先要設計測試場景?

上圖也描述了,測試場景對應的是實際的業務場景,業務場景是業務流程中因不同的事件觸發後的業務情景。比如銀行取款的業務辦理流程,會因為使用者的身份(VIP與否)、取款金額(大額,小額)、卡内餘額(足額取,不足額取)等諸多因素,導緻最後取款的結果和過程分支産生不同。測試場景就是對這類事件觸發時的業務情景在品質角度的描述。而測試用例是對測試場景在測試範圍和測試點的詳細覆寫。

第一步:根據業務的目标(價值)、類别、技術等輸入,确定業務場景分析的範圍。

業務分析就是需求分析的過程。這裡不僅僅考慮需求的功能邏輯,還需要結合不同業務類型,根據曆史業務經驗沉澱和風險沉澱進行綜合考慮。可以參考用下圖進行前期梳理。

如何做到測試場景不遺漏?

第二步:業務流程梳理(業務場景)

将需求說明轉化為業務流程,完成事件流(基本流+備選流)以及業務分析過程和技術分析過程的梳理。細化出原子級别的場景分支。

事件流: 同一事件不同的觸發順序和處理結果形成事件流,事件流分為基本流和備選流

基本流: 程式從開始執行直到成功結束所經過的最短路徑。

備選流: 一個備選流可能從基本流開始,在特定條件下執行,然後重新加入基本流中;也可起源于另一個備選流,執行後加入基本流或終止用例。根結點的備選流要具備原子性。

基本流和備選流:如下圖所示,圖中經過用例的每條路徑都用基本流和備選流來表示,直黑線表示基本流,是經過用例的最簡單的路徑。備選流用不同的色彩表示,一個備選流可能從基本流開始,在某個特定條件下執行,然後重新加入基本流中(如備選流2和4);也可能起源于另一個備選流(如備選流4),或者終止用例而不再重新加入到某個流(如備選流1和3)。

如何做到測試場景不遺漏?
如何做到測試場景不遺漏?

第三步:場景串聯

通過第二步中拆解的場景,根據沉澱後的場景集,用組合,合并等方法梳理出所有的事件流。事件流必須100%覆寫所有的基本流+備選流組合。

如何做到測試場景不遺漏?

測試用例設計

測試用例的設計很多時候是測試資料設計的過程,根據事件流(基本流+備選流)、資料和根據不同的角色,進行用例覆寫。需要確定所有場景100%覆寫。

如何做到測試場景不遺漏?

非功能性設計擴充

測試用例在設計上除了考慮功能性品質屬性,還需要對非功能性進行覆寫,推薦一個四字法進行設計。

  • 多:針對測試用例進行大資料量覆寫測試
  • 并:針對測試用例進行大資料量同時執行,驗證并發下的測試結果
  • 複:重複的參數對同一用例進行執行測試。驗證幂等結果是否符合預期。
  • 異:用非正常輸入值進行用例測試。驗證結果的正确性。

    測試政策

政策其實考慮兩個問題,過程和方法:“測什麼”,“怎麼測”。

  • 你的測試對象是什麼?
  • 本次測試的目标是什麼?
  • 測試中重點、難點、風險是什麼?
  • 測試要覆寫的深度和廣度
  • 如何安排各種測試計劃(先測什麼,再測什麼,時間資源安排)
  • 如何準出(測試結果)

    測試政策可參考模版&樣例

1. 業務整體概述

1.1 業務背景

業務背景介紹若幹字……

1.2 産品目标

産品目标介紹若幹字……

1.3 架構目标

架構目标介紹若幹字……

1.4 業務目标

業務目标介紹若幹字……

2. 項目整體分析

2.1 功能性需求拆解

核心業務子產品介紹,複雜度,測試點分析對應清單(此步驟為關鍵分析步驟)。測試分析功能點,要從産品品質标準的角度思考,針對品質特性進行功能點覆寫。

如何做到測試場景不遺漏?

2.2 測試覆寫範圍(涉及針對哪些品質要求的測試方法)

功能性、性能效率、相容性、易用性、可靠性、安全性、易維護性、可移植性

如何做到測試場景不遺漏?

2.3 測試對設計方案覆寫範圍(根據開發設計文檔羅列)

如何做到測試場景不遺漏?
3. 業務流程分析

3.1 被測功能總體概述

介紹若幹字……

3.2 整體業務流程

介紹若幹字

3.3 業務模型圖

3.4 風險分析

4. 測試場景覆寫範圍

4.1 測試場景

根據上一步的業務或者系統流程圖,完成測試用例場景的設計

4.2 測試用例設計(完善測試用例,補充測試資料)

根據測試場景細化測試用例,測試用例必須對測試場景和測試覆寫範圍進行100%的覆寫

4.3 測試資料要求

介紹若幹

4.4 其他測試補充

5. 測試執行計劃

這部分資訊通常也會放在最前面。

5.1 人員組織

包括哪些人參與,測試邊界等

5.2 測試實施計劃

包括提測時間,聯調時間等

5.3 傳遞計劃

主要是裡程碑和大的時間點

測試報告

測試報告實際就是一個品質評估的過程。内容的關鍵在于表達清晰兩點:報告的對象是誰?報告的内容是什麼?測試報告不是一個項目整體結束之後的産物,而是應該在項目整個生命周期随時同步的。

測試報告至少需要包括的資訊:

  • 項目背景資訊
  • 項目人員
  • 測試覆寫度(需求、功能性、非功能性)
  • 測試過程分析(執行情況)
  • 缺陷分析
  • 品質目标是否達到
  • 遺留風險以及應對措施

文章來源:AlibabaTechQA

開發者社群整理

繼續閱讀