iT邦幫忙

2024 iThome 鐵人賽

DAY 19
0
Software Development

測試工程師的上線時間:從分析到實戰的刻意練習系列 第 19

Day 19:總結測試分析的進化:從建模到啟發式策略的實戰運用

  • 分享至 

  • xImage
  •  

前言

終於來到「測試分析」的最後一篇!雖然我平常很喜歡用各種方法來設計測試案例,甚至會把日常生活中的情境套用進來分析,不過今天我們先來停下腳步,回頭看看這幾天都做了些什麼、用了哪些技術,來好好總結一下吧。

在軟體測試的世界裡,測試分析 是一個不可或缺的核心活動。無論是在初期的測試設計,還是在後續的測試執行過程中,測試分析都在決定測試效果的成敗。要達到高效的測試效果,我們需要結合兩個關鍵要素:測試建模測試技術。這兩者相輔相成,最終推導出具體且實用的測試案例,幫助我們覆蓋關鍵功能、控制風險,並提升系統的穩定性。

這篇文章將深入探討如何透過測試建模和測試技術,形成有效的測試策略,並在實戰中運用這些技術來應對需求變動和各種挑戰。


測試分析的定義

測試分析 是針對系統需求、業務規格或功能進行深度研究,識別出系統中潛在的風險與可能的問題點,並設計具體的測試案例來覆蓋這些風險。它涉及到對需求的精確解讀、系統設計的深刻理解,以及可能的實際運營場景模擬。測試分析的最終目標是確保所有關鍵功能和風險點被充分覆蓋並進行測試,降低軟體發布時的風險。


測試建模:測試分析的第一步

測試建模的目的

測試建模 是測試分析的基石,它提供了一個視覺化的框架,幫助我們更好地理解系統的運作邏輯。透過建模,我們能夠有效劃分系統的功能、輸入與輸出,並找出每一個關鍵測試點。這不僅能系統化地規劃測試範圍,還能確保所有功能需求和邊界條件都得到完整測試。

常見的測試建模方法

  1. 功能列表(Feature List):功能列表通常包含系統中所有的主要功能和子功能,幫助測試人員掌握測試範圍的全貌。
  2. 狀態機模型:適合用來表示系統中不同狀態之間的轉換,特別適用於處理狀態變更頻繁的系統,如電子錢包的交易狀態。
  3. 決策表測試:將輸入條件劃分成不同組合,適合處理多變數邏輯系統,如信用卡支付的授權流程。
  4. 使用案例測試 (Use Case Testing):根據具體的業務情境來模擬使用者操作,特別適合複雜業務流程的測試,如銀行轉帳或購物車結帳的流程。
  5. 流程圖模型 (Flowchart Model):流程圖是用圖形方式描述系統或業務流程的工作流程,顯示每個步驟和決策點。通過流程圖,我們可以可視化地識別測試點。

透過這些建模方法,我們能精確掌握測試重點,確保覆蓋所有必要功能與風險點。


測試技術:從建模到實際測試的橋樑

測試技術是將測試建模轉化為具體測試案例的過程。這些技術幫助我們針對每一個測試點設計具體的測試步驟,並最大化測試覆蓋率。常見的測試技術包括:

  1. 等價類劃分:將輸入資料劃分為不同的等價類,每個等價類代表相似輸入範疇,如將年齡劃分為不同範圍進行身分驗證測試。
  2. 邊界值分析:針對輸入資料的邊界條件進行測試,因為邊界通常是錯誤容易發生的高頻區域,如價格範圍中的最大和最小值測試。
  3. 因果圖:透過分析輸入條件與結果之間的因果關係來設計測試案例,確保每個條件變化都會引發正確的結果,如在折扣計算中驗證不同條件組合。
  4. 錯誤推測:基於經驗和系統理解,預測系統可能出現的錯誤,並設計針對性測試,如根據過往缺陷來預測新功能可能會重現的問題。
  5. 組合測試 (Pairwise Testing):針對多變數的系統,組合測試方法利用一種名為「Pairwise」的技術來測試所有參數組合中的每對變數。這能有效降低測試案例數量,同時確保多組合的覆蓋率。

啟發式測試策略模型(Heuristic Test Strategy Model):應對快速開發的利器

啟發式測試策略模型(Heuristic Test Strategy Model,簡稱 HTSM)是測試專家 James Bach 提出的一組幫助測試設計的指南(guideline)

隨著開發週期的縮短,測試時間也經常被壓縮。我們需要一種靈活且高效的測試策略來應對這樣的挑戰,這時候 啟發式測試策略模型 就能發揮其最大作用。這種模型強調基於經驗、風險評估和直覺設計出最具價值的測試案例。

啟發式測試策略模型的應用

  1. 快速迭代:當時間有限時,啟發式模型能幫助我們快速找到最具風險的區域,並集中測試資源在這些地方。
  2. 風險導向:根據對系統的理解,將測試重點放在最具風險的部分,如支付系統中的金融交易。
  3. 靈活調整:隨著需求變更,測試策略也能快速適應,確保測試結果與最新需求保持一致。

啟發式測試策略模型實際上是測試技術的一種延伸,專門針對快速變動的開發環境設計,能更靈活應對需求變更和風險控制。

使用啟發式測試策略的例子

假設你是一位外送平台的 QA 人員,你要測試這個平台的外送功能。隨著開發週期越來越短,給你的測試時間也越來越少,但你仍然需要在有限的時間內確保關鍵功能的正常運作。這時候,你就可以採用 HTSM 來高效地完成這項任務。

  1. 場景一:外送平台新增了一項功能,提供用戶在下雨天可以選擇不加外送費的優惠服務。
  2. 時間壓力:開發團隊明天就要上線這項新功能,但你的測試時間只有半天。

這時,你得快速決定哪些部分是重點,哪些可以省略。這就是啟發式測試策略模型發揮作用的地方:

  1. 針對風險高的部分優先測試:你知道最關鍵的部分是下雨天能否觸發「免外送費」的優惠,這是新功能的核心。於是,你首先集中精力測試這部分,確保功能正常。
  2. 忽略低風險的部分:例如,你可以略過針對已經測試多次、且與此次改動無關的其他支付方式(如信用卡付款、第三方支付等)的重複測試,因為這些部分在前面的迭代中已經通過測試,風險較低。
  3. 靈活調整測試策略:如果在測試過程中發現某些場景有潛在問題(比如不同天氣狀況下,系統的優惠計算可能出錯),你可以即時調整測試策略,針對這個情況進行更深入的測試。
  4. 基於直覺和經驗進行測試:啟發式測試策略依賴於你對系統和功能的理解,根據過去的經驗來猜測哪裡最容易出問題。像是以往天氣相關的功能,可能會因為天氣 API 的延遲導致優惠沒能及時生效,你可以提前針對這類場景進行測試。

啟發式測試策略模型並不追求「測試一切」,而是透過經驗、系統知識和風險評估,靈活應對快速變動的需求和限制的資源。這樣的策略不僅能確保核心功能的質量,還能大幅提高測試效率,在開發週期短、時間有限的情況下特別有用。

為什麼測試技術需要隨需求變動而調整?

在軟體開發中,需求變動是常見現象。測試技術必須隨著需求的改變進行調整,以下是幾個原因:

  1. 業務知識的增長:隨著對產品的深入理解,測試技術可能需要調整來涵蓋新發現的風險。
  2. 需求變更:需求的變更常常會導致功能新增或改動,測試技術需要隨之更新,以確保測試覆蓋。
  3. 新風險的出現:測試過程中可能發現新風險,這時需要調整測試技術來解決這些新風險。

測試案例設計:從模型和技術提煉測試方案

一旦完成了測試建模和技術選擇,我們接下來要做的就是編寫具體的測試案例。這些案例不僅要清晰明確,還需要有足夠的重現性,以確保不同測試人員執行時結果一致。

測試案例範例

假設我們正在測試一個家庭開銷管理應用程式,以下是一些針對不同場景的測試案例:

測試名稱 初始條件 測試步驟 預期結果 重要檢查點
案例 1:記錄有效開銷 無開銷記錄 1. 使用者新增一筆有效開銷2. 輸入正確金額和項目名稱 成功記錄開銷 1. 檢查開銷是否正確記錄
案例 2:無效金額輸入 無開銷記錄 1. 使用者輸入金額為負數2. 提交表單 顯示錯誤提示,記錄失敗 1. 確認是否出現錯誤提示
案例 3:記錄重複開銷 已有開銷記錄 1. 使用者嘗試記錄相同的開銷項目2. 提交表單 顯示重複項目提示,記錄失敗 1. 檢查重複檢測機制是否運作

結論

測試分析 是一個需要不斷調整和優化的過程,透過測試建模和測試技術,我們能夠準確覆蓋系統的關鍵風險點,並生成高效的測試案例。在實際工作中,隨著需求變更和系統風險的演變,我們需要靈活運用各種測試技術,尤其是 啟發式測試策略模型,來確保即使在開發週期壓縮的情況下,也能夠進行有效的測試,提升產品的質量與穩定性。


上一篇
Day 18:情緒左右球技?用狀態機解析隊友情緒波動的測試案例!
下一篇
Day 20:效能分析的基礎: The USE Method 和 The TSA Method
系列文
測試工程師的上線時間:從分析到實戰的刻意練習26
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言