高效的缺陷報告和測試計劃的編寫

文章目錄

- 缺陷報告
- - 缺陷标題
  - 缺陷概述
  - 缺陷影響
  - 環境配置
  - 前置條件
  - 缺陷重制步驟
  - 期望結果和實際結果
  - 優先級 (Priority) 和嚴重程度（Severity）
  - 變通方案 (Workaround)
  - 根原因分析 (Root Cause Analysis)
  - 附件 (Attachment)
- 測試計劃
- - 測試範圍
  - 測試政策的話題
  - - - 第一，功能測試
      - 第二，相容性測試
      - 第三，性能測試
  - 測試資源
  - 測試進度
  - 測試風險預估
- 小結

缺陷報告

缺陷報告的生成是測試人員利用對需求的了解、嚴密的邏輯推理能力，迅速找出軟體中的潛在缺陷，并以缺陷報告的形式遞交給開發團隊，開發工程師可以根據缺陷報告快速了解缺陷，并精确定位問題。同時，通過這個缺陷報告，開發經理可以準确預估缺陷修複的優先級、産品經理可以了解缺陷對使用者或業務的影響以及嚴重性。

常見的寫法：

缺陷标題

對缺陷的概括性描述，通常采用“在什麼情況下發生了什麼問題”的模式。楚地表述發生問題時的上下文。盡可能描述問題本質，

“搜尋功能有問題”和“使用者資訊頁面的位址欄位置不正确”等，這樣的描述會給人“說了等于沒說”的感覺。這樣的描述，很容易引發開發工程師的反感和抵觸情緒，進而造成缺陷被拒絕修改（reject）

避免隻停留在問題的表面。

比如，“商品金額輸入框，可以輸入英文字母和其他字元”這個描述就隻描述了問題的表面現象，而采用諸如“商品金額輸入框，沒有對輸入内容做校驗”的方式，就可以透過标題看到缺陷的本質，這樣可以幫助開發人員快速掌握問題的本質。

最後，缺陷标題不易過長，對缺陷更詳細的描述應該放在“缺陷概述”裡。

缺陷概述

更多概括性的缺陷本質與現象的描述，是缺陷标題的細化。這部分内容通常是開發工程師打開缺陷報告後最先關注的内容，是以用清晰簡短的語句将問題的本質描述清楚是關鍵。

還會包括缺陷的其他延展部分，比如你可以在這部分列出同一類型的缺陷可能出現的所有場景；再比如，你還可以描述同樣的問題是否會在之前的版本中重制等。在這裡，你應該盡量避免以缺陷重制步驟的形式來描述，而應該使用概括性的語句。

缺陷概述的目的是，清晰簡潔地描述缺陷，使開發工程師能夠聚焦缺陷的本質。

缺陷影響

缺陷引起的問題對使用者或者對業務的影響範圍以及嚴重程度。

缺陷影響決定了缺陷的優先級（Priority）和嚴重程度（Severity），開發經理會以此為依據來決定修複該缺陷的優先級；而産品經理會以此為依據來衡量缺陷的嚴重程度，并決定是否要等該缺陷被修複後才能釋出産品。

測試工程師準确描述缺陷影響的前提是，必須對軟體的應用場景以及需求有深入的了解，這也是對測試工程師業務基本功的考驗。

環境配置

環境配置用以較長的描述測試環境的配置細節。比如，作業系統的類型與版本、被測軟體版本、浏覽器的種類和版本、被測軟體的配置資訊、叢集的配置參數、中間件的版本資訊等等。

需要注意的是，環境配置的内容通常是按需描述，也就是說通常隻描述那些重制缺陷的環境敏感資訊。

比如，“菜單欄上某個條目缺失的問題”隻會發生在 Chrome 浏覽器，而其他浏覽器都沒有類似問題。那麼，Chrome 浏覽器就是環境敏感資訊，必須予以描述，而至于 Chrome 浏覽器是運作在什麼作業系統上就無關緊要了，無需特意去描述了。

前置條件

指測試步驟開始前系統應該處在的狀态，其目的是減少缺陷重制步驟的描述。

比如，某個業務操作需要先完成使用者登入，你在缺陷重制步驟裡就沒有必要描述登入操作的步驟細節，可以直接使用 “前置條件：使用者已完成登入”的描述方式；

再比如，使用者在執行登入操作前，需要事先在被測系統準備好待登入使用者，你在描述時也無需增加“用測試資料生成工具生成使用者”的步驟，可以直接使用 “前置條件：使用者已完成注冊”的描述方式。

缺陷重制步驟

是整個缺陷報告中最核心的内容，其目的在于用簡潔的語言向開發工程師展示缺陷重制的具體操作步驟。操作步驟通常是從使用者角度出發來描述的，每個步驟都應該是可操作并且是連貫的，是以往往會采用步驟清單的表現形式。

在寫缺陷重制步驟前，需要反複執行這些步驟 3 次以上：一是，確定缺陷的可重制性；二是，找到最短的重制路徑，過濾掉那些非必要的步驟，避免産生不必要的幹擾。

對于缺陷重制步驟的描述應該盡量避免以下 3 個常見問題：

籠統的描述，缺乏可操作的具體步驟。

出現與缺陷重制不相關的步驟。

缺乏對測試資料的相關描述。

期望結果和實際結果

期望結果和實際結果通常和缺陷重制步驟綁定在一起，在描述重制步驟的過程中，需要明确說明期待結果和實際結果。期待結果來自于對需求的了解，而實際結果來自于測試執行的結果。

通常來講，當你描述期望結果時，需要說明應該發生什麼，而不是什麼不應該發生；而描述實際結果時，你應該說明發生了什麼，而不是什麼沒有發生。

優先級 (Priority) 和嚴重程度（Severity）

缺陷優先級是指缺陷必須被修複的緊急程度，而缺陷嚴重程度是指因缺陷引起的故障對軟體産品的影響程度。

可見，嚴重程度是缺陷本身的屬性，通常确定後就不再變化，而優先級是缺陷的工程屬性，會随着項目進度、解決缺陷的成本等因素而變動。那麼，缺陷的優先級和嚴重程度又有什麼關系呢？

缺陷越嚴重，優先級就越高；

缺陷影響的範圍越大，優先級也會越高；

有些缺陷雖然從使用者影響角度來說不算嚴重，但是會妨礙測試或者是自動化測試的執行，這類缺陷屬于典型的嚴重程度低，但是優先級高；

有些缺陷雖然嚴重程度比較高，但是考慮到修複成本以及技術難度，也會出現優先級較低的情況。

變通方案 (Workaround)

提供一種臨時繞開目前缺陷而不影響産品功能的方式,變通方案的有無以及實施的難易程度，是決定缺陷優先級和嚴重程度的重要依據。如果某個嚴重的缺陷沒有任何可行的變通方案，那麼不管修複缺陷代價有多大，優先級一定會是最高的，但是如果該缺陷存在比較簡單的變通方案，那麼優先級就不一定會是最高的了。

根原因分析 (Root Cause Analysis)

如果你能在發現缺陷的同時，定位出問題的根本原因，清楚地描述缺陷産生的原因并回報給開發工程師，那麼開發工程師修複缺陷的效率就會大幅提升。

附件 (Attachment)

是為缺陷存在提供必要的證據支援，常見的附件有界面截圖、測試用例日志、服務端日志、GUI 測試的執行視訊

測試計劃

軟體測試計劃的制定通常是在需求分析以及測試需求分析完成後開始，并且是整個軟體研發生命周期中的重要環節。

采用了靈活開發模式，較少去制定傳統意義上的測試計劃了，而測試計劃的表現形式已經不再是傳統意義上龐大的、正式的測試計劃文檔了，而更多的是展現在每個疊代（sprint）的計劃環節，而且這樣的短期測試計劃可以非常迅速地根據項目情況實時調整。

測試計劃依舊存在，隻是從原來的一次性集中制定測試計劃，變成了以疊代的方式持續制定測試計劃。

測試範圍

被測對象以及主要的測試内容。比如，對于使用者登入子產品，功能測試既需要測試浏覽器端又需要測試移動端，同時還考慮登入的安全和并發性能相關的非功能性需求的測試等。

測試範圍的确定通常是在測試需求分析完成後進行，是以确定測試範圍的過程在一定程度上也是對測試需求分析的進一步檢驗，這将有助于在早期階段就發現潛在的測試遺漏。

同時，由于不可能進行窮盡測試，而且測試的時間和資源都是有限的，是以必須有所取舍，進行有針對性的測試。是以，測試範圍中需要明确“測什麼”和“不測什麼”。

測試政策的話題

需要明确“先測什麼後測什麼”和“如何來測”這兩個問題。還要說明采用什麼樣的測試類型和測試方法。需要注意的是，不僅要給出為什麼要選用這個測試類型，還要詳細說明具體的實施方法。

測試政策會要求我們明确測試的重點，以及各項測試的先後順序。對使用者登入子產品來講，“使用者無法正常登入”和“使用者無法重置密碼”這兩個潛在問題，對業務的影響孰輕孰重一目了然，是以，應該按照優先級來先測“使用者正常登入”，再測“使用者重置密碼”。

還需要說明采用什麼樣的測試類型和方法，要詳細說明具體的實施方法。

第一，功能測試

根據測試需求分析的思維導圖來設計測試用例。主線業務的功能測試由于經常需要執行回歸測試，是以需要考慮實施自動化測試，并且根據項目技術棧和測試團隊成員的習慣與能力來選擇合适的自動化測試架構。

通常應該先實作主幹業務流程的測試自動化。實操時，通常需要先列出主要的功能測試點，并決定哪些測試點适合采用自動化測試，并且決定具體使用什麼樣的架構和技術。對于需要手工測試的測試點，要決定采用什麼類型的測試用例設計方法，以及如何準備相關的測試資料。

另外，你還要評估被測軟體的可測試性，如果有可測試性的問題，需要提前考慮切實可行的變通方案，甚至要求開發人員提供可測試性的接口。

第二，相容性測試

Web 測試需要确定覆寫的浏覽器類型和版本，移動裝置測試需要确定覆寫的裝置類型和具體 iOS/Android 的版本等。

怎麼确定需要覆寫的移動裝置類型以及 iOS/Android 的版本清單呢？

如果是既有産品，你可以通過大資料技術分析産品的曆史資料得出 Top 30% 的移動裝置以及 iOS/Android 的版本清單，那麼相容性測試隻需覆寫這部分即可。
如果是一個全新的産品，你可以通過 TalkingData 這樣的網站來檢視目前主流的移動裝置，分辨率大小、iOS/Android 版本等資訊來确定測試範圍。

相容性測試的實施，往往是在功能測試的後期，也就是說需要等功能基本都穩定才會進行

當然也有特例，比如，對于前端引入了新的前端架構或者元件庫，往往就會先在前期做相容性評估，以確定不會引入後期無法解決的相容性問題。

相容性測試用例的選取，往往來自于已經實作的自動化測試用例。道理很簡單，因為相容性測試往往要覆寫最常用的業務場景，而這些最常用的業務場景通常也是首批實作自動化測試的目标。

是以，我們的 GUI 自動化架構，就需要能夠支援同一套測試腳本在不做修改的前提下，運作于不同的浏覽器。

第三，性能測試

需要在明确了性能需求（并發使用者數、響應時間、事務吞吐量等）的前提下，結合被測系統的特點，設計性能測試場景并确定性能測試架構。

比如，是直接在 API 級别發起壓力測試，還是必須模拟終端使用者行為進行基于協定的壓力測試。再比如，是基于子產品進行壓力測試，還是發起全鍊路壓測。

如果性能是背景資料敏感的場景，還需要确定背景資料量級與分布，并決定産生背景資料的技術方案，比如是通過 API 并發調用來産生測試資料，還是直接在資料庫上做批量 insert 和 update 操作，或者是兩種方式的結合。

最後，無論采用哪種方式，都需要明确待開發的單使用者腳本的數量，以便後續能夠順利組裝壓測測試場景。

性能測試的實施，是一個比較複雜的問題。首先，需要根據你想要解決的問題，确定性能測試的類型；然後，根據具體的性能測試類型開展測試。

性能測試的實施，往往先要根據業務場景來決定需要開發哪些單使用者腳本，腳本的開發會涉及到很多性能測試腳本特有的概念，比如思考時間、集合點、動态關聯等等。
腳本開發完成後，你還要以腳本為機關組織測試場景（Scenario），場景定義簡單來說就是百分之多少的使用者在做登入、百分之多少的使用者在做查詢、每個使用者的操作步驟之間需要等待多少時間、并發使用者的增速是 5 秒一個，還是 5 秒 2 個等等。
最後，才是具體的測試場景執行。和自動化功能測試不同，性能測試執行完成後性能測試報告的解讀，是整個測試過程中最關鍵的點。

測試資源

包括測試人員和測試環境，這兩類資源都是有限的。測試計劃的目的就是，保證在有限資源下的産出最大化。是以，測試資源就是需要明确“誰來測”和“在哪裡測”這兩個問題。測試人員的資源通常有兩個次元：一是，測試工程師的數量；二是，測試工程師的個人經驗和能力。

測試環境對于不同的項目，可能會使用共享的測試環境，也可能使用專用的測試環境，甚至還會直接使用生産環境。另外，對于目前一些已經實作容器化部署與釋出的項目，測試環境就會變得更簡單與輕量級。

測試進度

測試進度主要描述各類測試的開始時間，所需工作量，預計完成時間，并以此為依據來建議最終産品的上線釋出時間。

比如，版本接受測試（Build Acceptance Test）的工作量，冒煙測試（Smoke Test）的工作量，自動化腳本開發的工作量，缺陷修複的驗證工作量，需要幾輪回歸測試、每一輪回歸測試的工作量等等。

在傳統瀑布模型中，測試進度完全依賴于開發完成并遞交測試版本的時間。如果開發送出測試版本發生了延誤，那麼在不裁剪測試需求的情況下，産品整體的上線時間就同樣會延期。

然而在靈活模式下，測試活動貫穿于整個開發過程，很多測試工作會和開發工作同步進行，比如采用行為驅動開發（Behavior-Driven Development）模式，這樣測試進度就不會完全依賴于開發遞交可測試版本的時間。

行為驅動開發，就是平時我們經常說的 BDD，指的是可以通過自然語言書寫非程式員可讀的測試用例，并通過 StepDef 來關聯基于自然語言的步驟描述和具體的業務操作，最典型的架構就是知名“Cucumber”。

測試風險預估

預估整個測試過程中可能存在的潛在風險，以及當這些風險發生時的應對政策

對于需求變更，比如增加需求、删減需求、修改需求等，一定要重新進行測試需求分析，确定變更後的測試範圍和資源評估，并與項目經理和産品經理及時溝通是以引起的測試進度變化

小結

一份高效的軟體缺陷報告，應該包括缺陷标題、缺陷概述、缺陷影響、環境配置、前置條件、缺陷重制步驟、期望結果和實際結果、優先級和嚴重程度、變通方案、根原因分析，以及附件這幾大部分。

缺陷報告的每一部分内容，都會因為目的、表現形式有各自的側重點，是以想要寫出高效的軟體缺陷報告，需要對其組成有深入的了解。
一份成功的測試計劃，必須清楚地描述：測試範圍、測試政策、測試資源、測試進度和測試風險預估這五個最重要的方面。

測試範圍需要明确“測什麼”和“不測什麼”；

測試政策需要明确“先測什麼後測什麼”和“如何來測”；

測試資源需要明确“誰來測”和“在哪測”；

測試進度是需要明确各類測試的開始時間，所需工作量和預計完成時間；

測試風險預估是需要明确如何有效應對各種潛在的變化。