軟體測試基礎——功能測試

一、測試項目啟動與研讀需求文檔

（一） 組建測試團隊

1 測試團隊中的角色

2 測試團隊的基本責任

• 盡早地發現軟體程式、系統或産品中所有的問題。
• 督促和協助開發人員盡快地解決程式中的缺陷。
• 幫助項目管理人員制定合理的開發和測試計劃。
• 對缺陷進行跟蹤、分析和分類總結，以便讓項目的管理人員和相關的負責人能夠及時、 清楚地了解産品目前的品質狀态。
• 幫助改善開發流程、提高産品開發效率。
• 促程序式編寫的規範性、易讀性、可維護性等

3 測試團隊與開發團隊的 3 種模式

• （1）以開發為核心，測試隻是開發隊伍的一部分，也就是開發團隊中有測試人員，但 沒有形成獨立的團隊

  

• （2）以項目經理為核心，開發小組和測試小組并存，隸屬于項目經理上司。

  

• （3）項目經理、開發組長和測試組長“三足鼎立”，測試團隊具有獨立的、權威的地 位。

  

（二）軟體品質需求

1 軟體品質需求的分類

• 軟體品質需求用于确定測試目标。
• 測試目标包括：功能、性能、界面、易用性、相容性、安全性、可用性/可靠性、可維 護性、可擴充性等。
• 功能以外統稱非功能。

2 功能

• 軟體能做什麼？
• -需要做什麼？
• 怎麼做是正确的？
• 哪些功能要測試、哪些功能不需要測試？
• 哪些功能重要，哪些不重要？
• 哪些功能先實作或先測試？

3 性能

• 反映軟體運作時的效率和占用資源情況的能力。

   時間特性：時間短、速度快、效率高。

   資源特性：占用資源（CPU、記憶體、硬碟、網絡）少。

4 界面（UI）

• 布局合理；
• 控件位置恰當；
• 文字沒有亂碼、字型大小合适；
• 顔色使用恰當；
• 圖檔、表格恰當、舒适、美觀。

5 易用性

• 在指定條件下使用時，軟體産品被了解、學習、使用和吸引使用者的能力。

6 相容性/可移植性

• 指軟體産品從一種環境遷移到另一個環境的能力，反映一個軟體與不同的硬體環境、操 作平台、其他軟體的共同使用的能力。

   包括與不同硬體、平台、軟體自身不同版本、其他軟體、資料的相容。

7 安全性

• 指軟體産品保護資訊和資料的能力。

8 可用性/可靠性

• 指系統正常運作的能力或程度，可用性=正常運作時間/（正常運作時間+非正常運作時 間）×100%。

   可用性名額一般要求達到 4 個 9 即 99.99%（全年 52 分鐘不正常工作）或 5 個 9 即 99.999%（全年 5 分鐘），對一些軍事系統，可用性高達 7 個 9（99.99999%（全年 失效時間不超過兩秒）。

   一般測試時間不足，可以采用空間換時間的辦法，如在高負載情況下進 行為期一周 或一個月的測試，以判斷其可靠性。

   關注 MTTF（平均無故障時間）、MTTR（平均恢複時間）、MTBF（平均失效間 隔時間）。

9 可維護性

• 指軟體産品可被修改的能力。

   修改可能包括修正、改進或軟體對環境需求和功能規格說明變化的适應。

   可維護性的軟體應該是易改變的、穩定的、易測試的。

10 可擴充性/可伸縮性測試

• 通過很少的改動就能實作整個系統處理能力的增長。

   如在部署兩台伺服器時測試系統性能（容量，即最大負載），再部署四台、八台服 務器時分别進行系統容量的測試，看其容量是否為上次（兩台、四台）實驗值的兩 倍或接近兩倍。如果是，系統就具有良好的可伸縮性。

（三）研讀需求文檔

1 測試需求分析的過程

• 收集與研讀文檔，提出并解決問題，整理需求資訊
• 功能拆分、功能描述/需求整理
• 編寫測試點
• 需求評審

2 研讀需求文檔

2.1 研讀文檔主要任務

• 提取有用的需求資訊

• 提出需求中不清晰、不了解、不明白的問題

   和使用者、業務人員、産品經理或産品設計人員、開發人員等溝通

2.2 怎麼研讀文檔

• 分析思路

   分析軟體的使用者群，分析使用者的實際需要；

   分析軟體的開發環境、開發語言、資料類型；

   分析軟體架構、軟體的運作環境和平台、資料庫類型；

   分析軟體要實作哪些目标（功能、性能、界面、易用性、相容性、安全性）以 及具體的要求是什麼；

   分析軟體有哪些功能，每種功能要完成什麼業務，這些業務應該怎麼實作，業 務邏輯是什麼，業務流程是怎樣的，業務規則有何要求；

   分析功能或業務間的聯系，哪些業務更關鍵或重要；

   明确測試周期，測試目标，測試範圍。

• 細節上

   分析每個子產品或功能上實作的功能

   設計的開發原理包括資料類型

   從使用者使用場景角度分析業務流程

   記錄業務規則

• 實施

   以情景再現的形式寫出需求資訊。

2.3 研讀需求文檔案例

• 拿到一個項目，怎麼入手？

  – 即時貼程式部分需求說明

   便簽的數量最多為 50 個

   便簽标題字數最多為 40 個位元組

   便簽的正文文字數量最多為 200 個

   年份隻能設定在 1900－2100 之間

(四)需求評審

1 意義

• 對軟體需求進行正确性的檢查。
• 保證軟體需求的可測試性。
• 通過産品需求文檔的評審，與市場、産品、開發等各部門相關人員溝通，使得大家 認識一緻，避免在後期産生不同的了解，引起争吵。
• 通過産品需求文檔的評審，更好地了解産品的功能性和非功能性需求
• 在需求文檔評審通過後，測試的目标和範圍就确定了。雖然此後會有需求的變更， 但可以得到有效的控制，這樣可降低測試的風險。

• 評審是否完成是以需求文檔獲得多方“郵件确認”或“簽字”通過為标志的。這不 應該隻展現在“簽字”形式上，更重要的是達到下面的結果。

   所有參與方達成一緻。

   已發現的問題被闡述清楚、被修正。

2 需求評審的品質要求

• 正确性
• 完備性
• 易了解性
• 一緻性
• 可行性
• 易修改性
• 可測試性
• 可追溯性

3 需求評審的參加人員

• 使用者代表
• 需求人員
• 産品經理
• 項目經理
• 開發人員
• 開發經理
• 測試人員
• 測試經理
• 市場經理
• 品質保證人員

4 測試人員參與評審時的注意事項

• 明确自己的角色和責任。
• 熟悉評審内容，為評審做好準備，做細做到位。
• 在評審會上，針對問題闡述觀點，而不是針對個人。
• 可以分别讨論主要的問題和次要的問題。
• 在會議前或會議後可以就存在的問題提出自己建設性的意見。
• 提高自己的溝通能力，采取适當的、靈活的表述方式。
• 對發現的問題跟蹤下去。
• 應該在需求形成的過程中進行分階段的多次評審，而不是一次評審。

• 測試人員要善于提問，多思考

   這些需求都是使用者提出來的嗎？

   有沒有畫蛇添足的需求？沒有漏掉什麼需求嗎？

   和競争對手的産品做過比較嗎？我們的産品優勢展現在哪裡？

   是否正确地描述了每個需求？這條描述是否存在二義性的問題？

   我的了解和文檔作者的了解一緻嗎？

二、測試需求分析與測試用例設計

（一） 界面中的控件知識

1 文本框和密碼框

2 單選按鈕、組合清單框、數位框

3 複選框

4 清單框

5 指令按鈕

6 其他界面元素

三、 測試需求分析與測試用例設計方法

1 場景法

1.1 測試點/檢查點

• 測試時應該考慮可以測試的諸多方面。

1.2 場景法概述

• 場景法模拟使用者操作軟體時的情景，主要用于測試系統的業務流程。
• 當拿到一個測試任務時，我們先要關注它的主要功能和業務流程是否正确實作，這 就需要使用場景法來完成測試。

1.3 場景的定義

• 場景用來描述軟體操作的路徑。
• 基本流
• 按照正确的業務流程來實作的一條操作路徑（模拟正确的操作流程）。
• 備選流
• 導緻程式出現錯誤的操作流程（模拟錯誤的操作流程）。

1.4 場景法的分析步驟

• 分析軟體需求
• 從使用者使用情景角度，寫出業務流程和業務規則
• 寫出基本流場景和備選流場景

1.5 場景法案例：ATM 機取款

• 步驟一：分析業務流程（可以繪制流程圖）

  

  

  步驟二：描述程式的基本流及備選流

  • 1、基本流（正确的流程）

    （1）插入銀行卡：客戶将銀行卡插入 ATM 機的讀卡器

    （2）驗證銀行卡：ATM 機從銀行卡的磁條中讀取賬戶代碼，并檢查它是 否屬于可以接受的銀行卡

    （3）輸入密碼：ATM 機要求客戶輸入密碼

    （4）驗證密碼：确定該密碼是否正确 

    （5）進入 ATM 主界面：ATM 顯示在本機中可用的各種選項

    （6）選擇取款并輸入金額：客戶選擇“取款”，并選擇取款金額

    （7）ATM 機驗證：ATM 機進行驗證賬戶餘額是否滿足以及總取款金額 是否滿足要求，驗證 ATM 機内現金是否夠用

    （8）更新賬戶餘額、出鈔：驗證成功，更新賬戶餘額，輸出現金，提示 使用者收取現金

    （9）傳回主界面

• 2、備選流（各種錯誤情況）

  （1）銀行卡無效：提示錯誤并退卡

  （2）密碼錯誤：提示錯誤，并判斷是否 3 次錯誤

  （3）密碼 3 次錯誤：吞卡

  （4）賬戶餘額不足：提示錯誤并退卡

  （5）總取款金額超出當日可取限額：提示錯誤并退卡

  （6）ATM 機餘額不足：提示錯誤并退卡

步驟三：根據基本流和備選流生成不同的場景

2 等價類劃分

2.1 案例引入

測試兩位數加法器（學生思考、讨論、陳述）

2.2 等價類劃分核心思想

• 通過需求分析，找出程式的輸入域。
• 将輸入域劃分成若幹類。

• 每一類中選取代表性資料等價于這一類中的其他值。

  2.3 等價類劃分的步驟

• 需求分析

• 劃分等價類（根據需求，有效等價類、無效等價類）并細化（根據計算機知識）

  2.4 等價類劃分案例

• 步驟 1：需求分析

  • 閱讀文檔 ：

     借助開發知識

     與開發或使用者溝通

     了解使用者群及行業知識

  • 寫出需求：

     -99~99 之間的整數

• 步驟 2：劃分等價類并細化

• 有效類

   -99 到 99 之中的整數

   細化 ：負數、0 、正數

• 無效類

   超範圍 ：<-99 或 >99

   非法類型 ： 浮點數 、 字元（串）

2.5等價類劃分注意事項

• 不但要考慮有效等價類，也要考慮無效等價類

• 兩塊劃成一塊（等價類劃分過粗），結果？

   遺漏一種測試情況

• 一塊劃成兩塊（等價類劃分過細），結果？

   備援測試

• 仔細劃分，審查劃分

   過于粗略可能會漏掉軟體缺陷

   積累經驗

3邊界值分析

3.1 邊界值分析的思想與步驟

• 分析需求，找出邊界。

• 寫出邊界值

   最小值

   小于最小值

   最大值

   大于最大值

  3.2邊界值分析案例

• 兩位數加法電腦的邊界值 ： -99 、-100、99 、100

  3.3 為什麼分析邊界值

  看看下面的代碼有錯誤嗎？

  

   輸入或輸出的邊界最容易産生錯誤。

4 決策表

前面測試兩位數加法電腦的測試沒有考慮輸入組合。

4.1 決策表的分析步驟

• 需求分析

  • 分析輸入和輸出

     用等價類劃分分析輸入的各種情況、輸出的各種情況

• 畫判定表
• 分析與簡化判定表

4.2 決策表案例

• 分析輸入條件和輸出條件
  • 輸入

    

  • 輸出

     正确計算

     錯誤提示

• 原始決策表/判定表

  

• 優化決策表

  

  • 優化政策

     測試基本功能的保留；

     一個輸入錯誤，另外輸入無所謂，可以整合；

     所有輸入都要錯誤過。

• 最終的決策表

  

4.3 決策表的局限性與優化政策

導緻測試量爆炸。

5 錯誤推測

5.1 測試若幹原則回顧

• 測試不是驗證軟體正确，而是攻擊軟體，發現錯誤。
• 測試要時刻保持懷疑的态度，具有缺陷預防意識。
• 測試要尋求系統設計、功能設計的弱點。
• 設計負面的、異常的測試，如考慮錯誤的或者異常的輸入，往往可以發現更多的軟體缺陷。

5.2 什麼是錯誤推測

在測試程式時，人們可以根據經驗或直覺推測程式中可能存在的各種錯誤，進而有針對 性地編寫檢查這些錯誤的測試方法。

• 錯誤推測分類

   輸入資料測試方面

   輸出資料測試方面

   資料結構測試方面

   檔案系統方面

5.3 輸入資料方面的錯誤推測

輸入非法資料

• 一般用于鍵盤輸入資料時。

  • 測試方法

     輸入非法類型

     輸入非法範圍/長度

     輸入非法格式

• 注意
• 錯誤資訊的檢查：需要額外考慮錯誤提示資訊的内容
• 錯誤資訊和錯誤要對應一緻
• 錯誤資訊不能為空
• 錯誤資訊的内容不能隻是錯誤代碼，不能包含開發資訊
• 錯誤資訊不能中英文混合

5.4 錯誤推測

• 輸入非法類型
• 輸入非法範圍（數值）
• 輸入非法長度（個數）
• 輸入非法格式
• 輸入預設值
• 輸入特殊字元
• 輸入合法資料的非法組合
• 粘貼強制輸入
• 一個輸入多個輸出不要遺漏
• 輸出結果（含資料庫）要正确
• 上溢、下溢（含結果）
• 操作數與操作符不符
• 檔案超載
• 檔案權限不足
• 媒體忙或不可用
• 媒體損壞

輸入預設值

• 适用于有預設值的地方。

• 測試方法

   接受軟體的預設值

   鍵入空值

   将預設值改為另外一個值

   将預設值改為另外一個值，再變為空值

輸入特殊字元（集）

• 适用于不能輸入有特殊含義的字元時。

• 測試方法

   根據被測軟體所處的作業系統、程式設計語言、背景資料庫以及具體業務 等資訊列出表格，進行讨論，标明哪些需要測試，哪些需要剔除。

   了解具體行業知識，具體問題具體分析。

• 案例

  • 檔案命名下列特殊字元（33 個）

     不能使用：\ /<>|“😗?，com0-com9，lpt0-lpt9，prn、aux、nul、 con。

  • 思考

     使用者名有哪些特殊字元？

     QQ 昵稱、聊天内容有哪些特殊字元？

輸入合法資料的非法組合

• 适用于輸入值之間存在依賴關系時。

• 測試方法

   輸入可能是出現問題的組合值。

• 案例

  

  輸出資料方面的錯誤推測

  1)同一個輸入産生多種輸出

• 案例
  • 輸入：一個電話打來

  • 輸出：

     狀态一：等待接聽。

     狀态二：占線。

     狀态三：停機。

     狀态四：無法接通。

     狀态五：關機。

     狀态六：空号。

• 測試方法
  • 詳細測試每一種輸出，不要有遺漏。
  • 熟悉被測軟體業務知識，閱讀各種程式文檔，明确輸入可能産生的輸出， 列出關于程式輸入于輸出的一個清單，然後進行測試。

2)驗證輸出結果的正确性

測試方法

• 不僅測試輸入的正确性，還要檢查結果的正确性。
• 測試人員要盡可能多地學習所涉及問題的領域。

資料結構方面的錯誤推測

1)資料結構溢出

• 适用于程式中存在變量、數組等資料結構時。
• 測試方法

  • 變量 ：

    上溢：值太大

    下溢：值太小

  • 數組

     上溢：資料量太多

     下溢：資料量太少

2)計算結果溢出

• 測試方法

   輸入非法值或很大與很小資料，強制結果産生上溢或下溢。

3)操作數和操作符不符

• 适用于需要進行數值計算程式和圖形操作程式的測試時，如加、減、乘、除等。

• 測試方法

   找到程式中容易引起操作數和操作符不符的計算、表達式等

檔案系統方面的錯誤推測

1)使檔案系統超載

• 适用于資料存儲到硬碟中時。

• 案例

   假設“軟體測試工程師管理系統”要儲存 10000 個工程師資訊，則儲存時 engineer.txt檔案可能會有20M大小，如果此時磁盤隻有10M可用空間了， “軟體測試工程師管理系統”會如何動作呢？

• 測試方法

   建立滿容量或近乎滿容量的檔案系統，然後強制執行各種通過輸入或輸出 通路檔案系統的操作。

   打開足夠多的檔案，檔案打開時會強制建立備份副本，進而占用雙倍的存 儲空間。

   使用工具 CannedHeat，模拟檔案系統超載。

2)更改檔案通路權限

• 适用于對檔案進行讀寫的應用程式。
• 測試方法

  • 不同的使用者對相同檔案具有不同的通路權限，需要考慮登入同一台機器的 多個使用者操作相同檔案的權限問題。

     打開一個檔案，在作業系統中修改該檔案的通路權限。有些作業系統 允許權限高的使用者控制一般使用者已經打開的檔案。

  • 兩個應用程式打開，關閉同一個檔案。

     如把同一應用程式的不同版本安裝在同一機器上，在不同版本的應用 程式中打開和關閉同一檔案；

     試着在某個應用程式中打開在另一個程式中已打開的檔案，這可能會 導緻檔案通路權限上出現沖突。

3)使媒體忙或不可用

• 适用于應用程式的運作需要消耗大量記憶體或運作時需求其他相關軟體同時運 行的情況。

   大多數作業系統能同時運作多個應用程式，但互相切換時會有延遲，但是 沒有對錯誤響應。

• 測試方法

   通過啟動大量應用程式，強制它們都打開并儲存檔案來使檔案系統處于忙 的狀态；或者同時下載下傳大量檔案也可以使背景擁擠。

   使用一些測試工具來模拟磁盤的狀況。

4)媒體損壞

• 使用場合

   損壞的媒體可能使作業系統傳回錯誤代碼，這些錯誤代碼可能沒有在應用 程式中程式設計處理。

• 測試方法

   損壞媒體的方法使用不很多，隻有少數公司采用，大多是開發作業系統、 裝置驅動程式以及以安全為主的應用程式的公司會采用這種測試方法。确 定是否使用該方法，主要要考慮資料對使用者的重要性。

   該方法可以使用實際損壞了的媒體。檢查應用程式對錯誤的處理能力，應 用程式可以對錯誤進行處理或者将問題告訴使用者，并且要確定使用者資料文 件不丢失、不損壞。

   也可以通過軟體模拟。

6 編寫測試點

将測試點寫入測試需求分析說明書，或者 XMind 等，留存下以供将來編寫測試用例使

用。

四、編寫測試用例

1.編寫測試用例（一般公司都有固定模闆）

2 測試用例的寫作說明

2.1 用例編号/序号

簡單、唯一。

2.2 用例說明

• 也稱測試點、檢查點、測試概述、用例概述、測試說明；
• 用一句話對測試用例進行概述；
• 可以總結測試目的；
• 可以用疑問句表示；
• 可以用“檢查、驗證、測試”等字眼（如驗證 QQ 預設安裝）；
• 最好看到這句話就能知道如何測試；
• 盡量唯一（決策表可能會有重複的測試說明）；
• 用例執行多輪時，越往後執行可能越快，如果用例寫得好，直接看概述就行。

2.3 初始條件

• 也稱預置條件、前提條件；
• 初始條件要是一個狀态，而且是靜态的，如管理者已登入背景；
• 初始條件是第一步操作步驟之前的狀态，不能太遠，不用從頭寫到尾
• 很多項目中不寫預置條件。

2.4 操作步驟

• 若對資料要求高，需要把資料分離出來；
• 步驟要都有序号；
• 每一步用分号分開，最後用一個句号；
• 每一步必須換行；
• 參數前加冒号（如使用者名：admin）；
• 涉及按鈕界面用【】、“”等成對符号間隔；
• 功能的詳細用例步驟 4-6 步左右；
• 最後一步一定是個動作，不能寫結果。

2.5 預期結果

• 是一個狀态；
• 如果參考文檔中有描述，原封不動的抄過來；如果文檔中沒有具體要求，則點要一 緻，可以有幾個點，如 QQ 預設安裝，應能啟動、預設選項比對等。

2.6 用例狀态

• 通過、失敗、阻塞、未執行、擱置、無效用例…
• 初始條件達不到時，一般用例狀态設定為阻塞。
• 看如何執行用例，執行完關心什麼來定。

2.7 優先級

• 用例的執行順序。

3.測試用例的評審和管理

• 保證測試用例品質的方法

   首先，要對使用者需求、服務品質要求、産品特性有深刻且全面的了解

   其次，采取正确、恰當的方法進行用例設計；

   再者，按照測試用例的标準格式或規範的模闆來書寫測試用例；

   最後，對測試用例的檢查、評審，也是提高測試用例品質的主要且有效的手段。

五、送出缺陷報告

一） 軟體缺陷的判定

1 什麼是缺陷

軟體存在着不符合品質需求或違背軟體使用者、客戶、企業意願的問題，這就是軟體缺陷 （Defect），又叫“Bug（臭蟲）”。

2 軟體缺陷的判定準則

• 軟體未達到産品說明書标明的功能；

   産品說明書簡稱為說明（spec）或産品說明（productspec），是軟體開發小組 的一個協定。它對開發的産品進行定義，給出産品的細節、如何做、做什麼、 不能做什麼。這種協定從簡單的口頭說明到正式的書面文檔有多種形式。

• 軟體出現了産品說明書指明不會出現的錯誤；

   如金融軟體 7*24 工作不能當機

• 軟體功能超出産品說明書指明範圍；

• 軟體未達到産品說明書雖未指出但應達到的目标；

   如軟體在斷電時的意外處理

• 軟體測試員認為軟體難以了解、不易使用、運作速度緩慢，或者最終使用者認為不好。

   主要展現在易用性方面。

  3 軟體缺陷的表現形式

• 使用者要求的功能、特性沒有實作或部分實作。
• 運作出錯，包括運作中斷、系統崩潰、界面混亂等。
• 資料結果不正确、精度不夠、不完整或格式不統一。
• 文字顯示内容不正确或拼寫錯誤。

• 系統性能低下、系統資源浪費。

  4 分離和再現軟體缺陷

• 發現缺陷後，應該做好分離和再現，排查發現的“缺陷”是不是軟體本身的問題， 然後才能送出。

• 再現 3 次

   重制

   複現

  5 避免送出缺陷的缺陷和重複缺陷

• 缺陷的缺陷

   是測試人員送出的不是缺陷的缺陷；

   是一種無效缺陷；

   此類缺陷常使測試人員遭受指責。

  • 怎麼辦 ： 正确了解需求； 做好複現。

• 重複缺陷

   同一個缺陷 A 測試工程師送出後，B 測試工程師又送出或者自己送出的缺陷 與之前送出的缺陷相同或類似；

   是一種無效缺陷；

  • 怎麼辦 ： 盡量避免兩個人同時測試同一子產品； 自己送出的缺陷與自己的重複，送出前查找一下，增強開發知識。

6 處理無法再現的缺陷

• 首先，對這樣的缺陷進行詳細的記錄，使用不同辦法去嘗試複現。
• 其次，要合理地安排時間，要考慮到測試項目的整體進度，對一時難以再現的缺陷 可以暫時擱置，以保證項目的正常進度，并盡快送出給開發人員。

• 最後，在測試過程中對未再現缺陷予以關注。

  7 處理有争議的缺陷

• 跟有關人員進行溝通、讨論；
• 擱置。

二） 送出缺陷報告

1 什麼是缺陷報告

缺陷報告是對缺陷進行記錄、分類和跟蹤的文檔。

2 缺陷報告的讀者對象

• 軟體開發人員

   報告缺陷是為了缺陷得到修複。

   希望獲得缺陷的本質特征和複現步驟。

• 品質管理人員、市場人員、技術支援人員

•  希望獲得缺陷的嚴重程度和分布情況，以及對市場和使用者的影響程度。

  3 缺陷報告的寫作準則（5C）

• Correct（準确）

   每個組成部分的描述準确，不會引起誤解；

• Clear（清晰）

   每個組成部分的描述清晰，易于了解；

• Concise（簡潔）

   隻包含必不可少的資訊，不包括任何多餘的内容；

• Complete（完整）

   包含複現該缺陷的完整步驟和其他本質資訊；

• Consistent（一緻）

   按照一緻的格式書寫全部缺陷報告。

  4 缺陷報告的組織結構

• 缺陷的标題/缺陷摘要/缺陷概述/缺陷基本資訊
• 預處理
• 複現步驟
• 期望結果
• 實際結果
• 缺陷的嚴重程度
• 缺陷的優先級
• 測試的軟體和硬體環境
• 測試的軟體版本
• 缺陷的類型

• 注釋文字和缺陷截圖

  5 缺陷報告的寫作要求

  5.1 缺陷标題

• 盡量按缺陷發生的原因與結果的方式書寫；

   執行完 A 後，發生 B；

   在什麼地方，做了什麼事情，出了什麼結果；

  使用“在…以後”，“在…時候”或“在…期間”等連結詞有助于描 述缺陷的原因和結果。

• 避免使用模糊不清的詞語；
• 為了友善搜尋和查詢，盡量使用關鍵字；

• 為了便于他人了解，避免使術語、俚語或過分具體的測試細節。

  5.2 複現步驟

• 提供測試的預備步驟和資訊；
• 步驟完整，準确，簡短，沒有缺漏任何操作步驟，沒有任何多餘的步驟；
• 将常見步驟合并為較少步驟；
• 簡單地一步一步地引導複現該缺陷；
• 每一個步驟盡量隻記錄一個操作；
• 每一個步驟前使用數字對步驟編号；

• 盡量使用短語和短句，避免複雜句型和句式；

   隻記錄各個操作步驟是什麼，不要包括每個步驟的執行結果。

  5.3 預期結果

   軟體應該具有的結果，或者說正确結果應該是什麼樣子。

  5.4 實際結果

• 實際結果的描述要列出具體的表現行為，而不是簡單的指出“不正确”或“不起作 用”。

• 如果一個動作産生彼此不同的多個缺陷結果，或者一個動作将産生一個結果，而這 個結果又産生另一個結果。為了易于閱讀，這些結果應該使用數字清單分隔開來。 如實際結果：

   1.顯示“指令代碼行…錯誤”；

   2.顯示“并且終止…服務”。

  5.5 注釋/截圖

• 可以包含以下各方面的内容：

   截取缺陷特征圖像檔案；

   測試過程所使用的測試檔案；

   測試附加的列印機驅動程式；

   再次描述重點，避免開發人員将缺陷退回給測試人員補充更多資訊；

   再次指明該缺陷是否在前一版本已經存在；

   多個平台之間是否具有不同表現；

   注釋包含缺陷的隔離資訊，指出缺陷的具體影響範圍。

• 如，缺陷的注釋可能包含下面的内容：

   能在 Win2000 和 WinXP 文本框中顯示文本内容，但不支援 Win98

   螢幕重新整理後，現象會消失。

   使用二進制檔案，不存在該錯誤。

   參見附加的使用說明書和測試檔案。

  6 怎麼送出高品質的缺陷報告

• 盡早送出缺陷報告。
• 清楚地說明此問題對使用者價值的危害。  提供盡可能多的技術資訊（如包含複現該缺陷需要的環境變量或測試所用的資料文 件），友善程式員調試。
• 報告的軟體缺陷進行了必要的隔離，報告的缺陷資訊具體、準确。
• 易于搜尋軟體測試報告的缺陷。
• 一個缺陷報告中隻報告了一種缺陷。
• 缺陷報告中不要提問題。

• 避免常見的錯誤

   我（I）、你（You）、他/她（He/She）

   情緒化的語言和強調符号！！！

   似乎（Seems）、看上去可能（Appearstobe）

   認為比較幽默的内容  不确定的測試問題（Issues）/不确定是否是缺陷

三） 缺陷的分類

1 缺陷的分類标準

2 根據缺陷類型對缺陷分類

• 功能缺陷
• 界面缺陷
• 文檔缺陷
• 代碼缺陷
• 算法錯誤
• 性能缺陷

3 根據缺陷的等級對缺陷分類

• A 類—緻命缺陷，包括以下各種錯誤：

   由于程式所引起的當機，非法退出；

   死循環；

   資料庫發生死鎖；

   因錯誤操作導緻的程式中斷；

   功能錯誤；

   與資料庫連接配接錯誤；

   資料通訊錯誤

• B 類—嚴重缺陷，包括以下各種錯誤：

   程式錯誤；

   程式接口錯誤；

   資料庫的表、業務規則、預設值未加完整性等限制條件

• C 類一般缺陷，包括以下各種錯誤：

   操作界面錯誤（包括資料視窗内列名定義、含義是否一緻）；

   列印内容、格式錯誤；

   簡單的輸入限制未放在前台進行控制；

   删除操作未給出提示；

   資料庫表中有過多的空字段

• D 類—較小缺陷，包括以下各種錯誤：

   界面不規範；

   輔助說明描述不清楚；

   輸入輸出不規範；

   長操作未給使用者提示；

   提示視窗文字未采用行業術語；

   可輸入區域和隻讀區域沒有明顯的區分标志

• E 類—意見或建議

  4 根據缺陷處理的優先級對缺陷分類

  

5 根據缺陷狀态對缺陷分類

缺陷狀态	描述
Submitted/已送出	已送出的缺陷
Open/打開	确認"送出的缺陷"，等待處理
Rejected/已拒絕	拒絕"送出的缺陷"，不需要修複或不是缺陷
Resolved/已解決	缺陷被修複
Verified/已驗證	确認缺陷确實被修正
Closed/已關閉	确認被修複的缺陷，将其關閉

四、 缺陷報告的處理

1 缺陷報告的簡單處理流程/缺陷的生命周期

• 軟體測試人員送出缺陷報告；
• 測試負責人稽核後将缺陷報告配置設定給相關的開發人員修改；
• 缺陷被修改後由測試人員根據缺陷報告中的修改記錄進行返測；
• 返測通過的缺陷報告由負責人關閉，返測未通過的缺陷報告直接傳回開發人員重新 修改，缺陷報告直到缺陷被修複以後才關閉；
• 關閉或已解決的缺陷報告可能會被階段性的複審重新打開，這些報告一旦被再次打 開應該立即處理。

2 缺陷報告的标準處理流程

• 正常缺陷
• 重複缺陷
• 無效缺陷
• 推遲修改
• 驗證不通過
• 描述不清楚

  

3 缺陷跟蹤管理系統/缺陷管理工具

3.1 缺陷管理工具的功能

• 缺陷送出
• 缺陷跟蹤

• 缺陷分析

   有效的缺陷分析不僅可以評價軟體品質，同時可以幫助項目組很好地掌握和評 估軟體的研發過程，進而改進研發過程，未對缺陷進行分析就無法對研發流程 進行改進。

   缺陷分析還能為軟體新版本的開發提供寶貴的經驗，進而在項目開展之前，指 定準确、有效的項目控制計劃，為開發高品質的軟體産品提供保障。

  3.2 常見缺陷管理工具

• Bugzilla
• Bugfree
• Mantis
• Jira
• ZenTao（禅道）
• QualityCenter/Application Lifecycle Management

這隻是一篇學習筆記，學習源：https://www.bilibili.com/video/BV1EJ41147fN，

感興趣的小夥伴們可以去學學，就是講得有些太詳細了