Day 4 | 軟體測試的原則 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

2022 iThome 鐵人賽

DAY 4

自我挑戰組

開始系統測試系列第 4 篇

Day 4 | 軟體測試的原則

14th鐵人賽

Pancy

2022-09-19 22:37:25

1587 瀏覽

分享至

所有的測試都應追溯到客戶需求
1. 缺陷的源頭 - 根據相關調查，缺陷出現最多的地方是需求規格說明書而非程式碼。
2. 如何應用此原則
  - 測試的第一個任務是需求分析
  - 時刻都要提醒自己考慮使用者需求
  - 做好需求評估，確認所做的內容是否符合用戶的需求
盡早啟動測試工作
1. 測試雪崩
2. 測試的成本
3. 如何應用此原則
  1. 測試應盡早開始
  2. 測試應該是與開發或維護並進的過程，並需要持續進行。
提早做測試計畫
1. 軟體測試不僅僅是測試執行。
2. 應該在測試工作開始前就進行測試計畫
窮盡測試不可能&軟體測試有風險
1. 無法窮盡測試的原因 - 測試數據輸入量太大、時間不足等等。
2. 如何應用此原則
  1. 使用風險分析，確定測試的重點和優先序，控制測試的成本(時間、成本、資源)
  2. 風險分析需要判斷的技能、常識、感覺和經驗。
測試工作的Good-enough原則
1. 既不做過多測試，也不做不充分的測試
2. 解決辦法是通過需求分析和風險分析找到測試重點，制定最低測試通過標準和測試內容。
Pareto法則應用於軟體測試
1. 一般情況下80%的缺陷聚集在20%的關鍵核心業務模組中
2. 在分析、設計、開發階段可以避免掉80%的缺陷，而測試時又能找出剩餘缺陷中的80%，最後的4%缺陷可能只有在用戶大範圍、長時間使用後才會暴露出來。
盡可能使用分階段測試
1. 單元測試⇒模組測試⇒系統測試⇒驗收測試
為了達到最佳效果，應該由獨立的第三方來測試
1. 「最佳效果」指最有可能發現錯誤的測試，因為自己寫的需求或測試常常有盲區或侷限性。
測試的目的在發現存在的缺陷
1. 即使在測試過程中未發現軟體的缺陷，也不能證明被測試的軟體沒有錯誤。
為了保證測試的有效性與高效性，測試必須是破壞性、系統化的
1. 充分、有效、系統化的測試可以減少軟體中未被發現缺陷的可能性
2. 測試既要驗證軟體正確性，更要通過破壞軟體發現缺陷的不正確性
找到的軟體缺陷越多，說明軟體隱含的缺陷越多
1. 缺陷具有群聚效應，應該在發現缺陷的地方繼續找找。
殺蟲劑怪事
1. 用於描述軟體測試越多，對其測試免疫力越強的現象 => 開發人員已經可以避開測試人員的主要測試方式了。
2. 測試人員需要不斷編寫不同的、新的測試腳本，對程式的不同部分進行測試，以找出更多軟體缺陷
並非所有的缺陷都要修復
1. 時間不足
2. 不算真正的軟體缺陷
3. 修復的風險太大
4. 不值得修復
使用木桶原理
1. 一隻木桶盛水的多少，並不取決於桶壁上最高的那塊木塊，而恰恰取決於桶壁上最短的那塊。
2. 在軟體方面就是全面品質管理(QTM)的概念，所有單位、所有人員都參與品質改進，而且都為品質負責。
前近兩步，後退一步
1. 測試中一個基本問題是缺陷修復總會以(20~50)%的機率引入新的缺陷。
2. 每次修復後都需要做確認測試和回歸測試
  1. 確認測試 - 缺陷修復後需再次檢驗先前提出的缺陷是否已經被修復。
  2. 回歸測試 - 缺陷修復後需重新測試，確保程式修改後沒有改壞其他未改動的部分。軟體修改或環境變更後須進行回歸測試。
軟體測試是一個迭代的過程
1. 無論用哪一種開發方式，測試人員總是一個版本接一個版本的測試，測試活動是迭代向前的