🍅 點擊文末小卡片，免費獲取軟件測試全套資料，資料在手，漲薪更快?

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

（一） 組建測試團隊

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、根據缺陷狀態對缺陷分類

四）缺陷報告的處理

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

軟件測試人員提交缺陷報告；
測試負責人審核后將缺陷報告分配給相關的開發人員修改；
缺陷被修改后由測試人員根據缺陷報告中的修改記錄進行返測；
返測通過的缺陷報告由負責人關閉，返測未通過的缺陷報告直接返回開發人員重新 修改，缺陷報告直到缺陷被修復以后才關閉；
關閉或已解決的缺陷報告可能會被階段性的復審重新打開，這些報告一旦被再次打 開應該立即處理。?

2、缺陷報告的標準處理流程

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

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

3.1 缺陷管理工具的功能

缺陷提交
缺陷跟蹤
缺陷分析
? 有效的缺陷分析不僅可以評價軟件質量，同時可以幫助項目組很好地掌握和評 估軟件的研發過程，進而改進研發過程，未對缺陷進行分析就無法對研發流程 進行改進。
? 缺陷分析還能為軟件新版本的開發提供寶貴的經驗，進而在項目開展之前，指 定準確、有效的項目控制計劃，為開發高質量的軟件產品提供保障。

3.2 常見缺陷管理工具

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

最后感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：

這些資料，對于做【軟件測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！凡事要趁早，特別是技術行業，一定要提升技術功底。