隨手扎

【閱讀筆記】軟體測試的藝術

《軟體測試的藝術》，寫過筆記的人也不少，但筆記畢竟主要是給自己看的，就還是紀錄一下自己認為值得反覆咀嚼的內容。值得意外的有點多，尤其是第六章節。很多我無法用一兩句話去記憶、帶過，自己尚未內化或許是原因之一，所以這篇筆記會很亂。總之，雖然剛開頭覺得有些無趣，但是強烈推薦去完整讀讀第六章節。

測試是為發現錯誤而執行程序的過程。
軟體測試更適宜被視為試圖發現程序中錯誤（假設其存在）的破壞性的過程。軟體做了其應該做的，未做其不應該做的。

推薦指數：★★★☆☆ 閱讀日期：2020/04/24

以下為筆記內容

第六章、更高級別的測試

軟體開發週期：

  1. 最終用戶轉換為書面需求（最終實現目標）(需求分析)
  2. 評估可行性與成本，消除相牴觸的用戶需求，建立優先級別和平衡關係，轉換為具體目標。(WPS、干特圖)(設計)
  3. 轉換為規格說明（外部格說明）
  4. 如果該產品是一個系統，接著就是系統設計。拆分成多的獨立的子程序、部件或子系統，並定義接口。
  5. 通過定義的每個模塊功能、模塊層次結構與接口，來設計程式或程式集合的結構。
  6. 設計一份 準確的規格說明 ，定義每個模塊的功能與接口。
  7. 經過一個或多個子步驟，將模塊接口規格說明轉換為每個模塊的原始碼。(開發)
  • 需求規格 說明定義了為什麼要開發程序。
  • 目標定義 了程序要做什麼，以及應做的怎樣。
  • 外部規格說明 定義了程序對用戶的準確表現。
  • 與後續階段相關的文檔越來越詳細地規定了程序是如何建立起來的。

測試方法、階段：

程式設計師應當避免測試自己編寫的程序。（除了單元測試外）

  • 黑箱/白箱測試、覆蓋率測試、由上而下/由下而上測試、ɑ/β測試(公測/封測)
  • 單元測試
  • 模塊測試
  • 功能測試
  • 系統測試
    • 能力測試
    • 容量測試
    • 強度測試
      在短的時間間隔內達到的數據或操作的數量峰值
    • 易用性測試
      ……「程式預到了一個錯誤，必須重新啟動」這樣無用的訊息。自己寫的程式是由自己控制的，不應加入這些無用的訊息。即時我們不開發軟體，如果在測試小組工作，那麼可以推動人機界面這個領域的改進。
    • 安全性測試
    • 性能測試
    • 存儲測試
    • 配置測試
    • 兼容性/配置/轉換測試
    • 安裝測試
    • 可靠性測試
      平均故障間隔時間(MTBF)、可靠性測試及軟體可靠性工程(SRE)
    • 可恢復性測試
      我們可以故意將程序錯誤置入某個系統中，判斷系統是否可以從中恢復。
    • 適用性測試
    • 文檔測試
    • 過程測試
    • 系統測試的執行
  • 驗收測試 這是一種不尋常的測試類型，因為開測試通程式由客戶或最終用戶來進行，一般不認為是軟體開發機構的職責。
  • 安裝測試
  • 測試的計畫與控制 在計畫測試過程中最常出現的主要錯誤是默認為不會發現軟體缺陷。

測試結束準則（其中一種）

除了非常小的軟體，期望所有錯誤最終都會被發現是不切實際的。……那麼人們就會下意識地朝著這個目標編寫測試用例，避開有用的、高效的和具有破壞性的測試用例。

一般程式中的錯誤數量大致是每100行語句中含4~8個錯誤。……
……。大型測試中，約有40%的錯誤是編碼和邏輯設計錯誤，剩下的錯誤則產生於早期設計階段。
以下顯示了何時發現錯誤的近似合理的預測：

編碼和邏輯設計錯誤設計錯誤
模塊(單元)測試65%0%
功能測試30%60%
系統測試3%35%
總計98%95%

一個良好的測試計畫包含：

  1. 目標
  2. 結束準則
  3. 進度
  4. 責任
  5. 測試用力庫和標準
  6. 工具
  7. 計算機時間
  8. 硬體配置
  9. 集成
  10. 跟蹤步驟
  11. 調試步驟
  12. 回歸測試

第七章、調試

調試包含兩個步驟：

  1. 測試發現問題後，找到性質與位置。(可能解決95%問題)
  2. 修改錯誤

調試方法：

重點：調試的原則

  • 暴力法測試
  • 歸納法測試
  • 演算法調試
    1. 列舉所有可能原因與假設
    2. 利用數據排除可能原因
    3. 提煉剩下假設
    4. 證明剩下假測
  • 回歸法調試
  • 測試法調試
  • 調試的原則
    • 定位錯誤的原則
      1. 動腦筋
      2. 如果遇到僵局，就留到之後解決
      3. 如果與到困境，就把問題描述給其他人聽
      4. 僅將測試工具作為第二種手段
      5. 避免使用試驗法，僅將其作為最後的手段
    • 修改錯誤的技術
      1. 存在一個缺陷的地方，很有可能還存在其他缺陷
      2. 應糾正錯誤本身，而不是僅其症狀
      3. 正確糾正錯誤的可能性並非100%
      4. 正確修改錯誤的可能性隨著程序規模增加而降低
      5. 應亦是改正錯誤會引入新錯誤的可能性
      6. 修改錯誤的過程也是臨時回到設計階段的過程
      7. 應修改原始碼，而不是目標碼。
    • 錯誤分析(像專案結束會議)
      調試除了有消滅程式中的錯誤外，他可以告訴我們軟體錯誤的一些本質。
      • 錯誤珠現在何處？
      • 誰製造了這個錯誤？(不是為了懲罰，而是為了培訓)
      • 哪些做得不正確？
      • 如何避免該錯誤的出現？
      • 為什麼錯誤沒有早些發現？
      • 該如何更早的發現錯誤？

第八章、極限測試

20世紀90年代出現了一種名為極限編成(XP)的新型軟體開發方法。……一位名叫Kent Beck的項目經理設計了這種輕量、敏捷的開發過程。…儘管此後還出現了其他種敏捷開發的方式，但XP是到目前為止最流行的敏捷開發方式。

lag: 最近比較長聽到 scrum

  1. 聆聽客戶和其他程式開發人員的談話
  2. 與可互合作，開發應用程序規格說明和測試用例。
  3. 結對編程
  4. 測試程式函式庫

XP的12個實踐：

  1. 計畫與需求分析
  2. 小規模遞增
  3. 紀統隱喻
  4. 簡要設計
  5. 連續測試
  6. 重構
  7. 結對編程
  8. 程式碼的集體所有權
  9. 持續集成
  10. 每週40小時工作（不允許加班）
  11. 客戶在現場
  12. 按標準編碼

延伸閱讀

comments powered by Disqus