軟件測試缺陷報告實用寫作技術

因此，軟件測試工程師必須認識到書寫軟件缺陷報告是測試執行過程的一項重要任務，首先要理解缺陷報告讀者的期望，遵照缺陷報告的寫作準則，書寫內容完備的軟件缺陷報告。本文將闡述軟件測試缺陷報告的讀者，描述軟件缺陷報告的主要組成部分和各部分的書寫要求，指出某些常見錯誤和實用改進方法，最后總結了缺陷報告的寫作要點。

1. 缺陷報告的讀者對象

在書寫軟件缺陷報告之前，需要明白誰是缺陷報告的讀者對象，知道讀者最希望從缺陷報告中獲得什么信息。通常，缺陷報告的直接讀者是軟件開發人員和質量管理人員，除此之外，來自市場和技術支持等部門的人也可能需要查看缺陷情況。每個閱讀缺陷報告的人都需要理解缺陷針對的產品和使用的技術。另外，他們不是軟件測試人員，可能對于具體軟件測試的細節了解不多。

概括起來，缺陷報告的讀者最希望獲得的信息包括：

• 易于搜索軟件測試報告的缺陷；
• 報告的軟件缺陷進行了必要的隔離，報告的缺陷信息更具體、準確；
• 軟件開發人員希望獲得缺陷的本質特征和復現步驟；
• 市場和技術支持等部門希望獲得缺陷類型分布以及對市場和用戶的影響程度。

軟件測試人員的任務之一就是需要針對讀者的上述要求，書寫良好的軟件缺陷報告。

2. 缺陷報告的寫作準則

書寫清晰、完整的缺陷報告是對保證缺陷正確處理的最佳手段。 它也減少了工程師以及其它質量保證人員的后續工作。
為了書寫更優良的缺陷報告，需要遵守“5C”準則：

• Correct（準確）：每個組成部分的描述準確，不會引起誤解；
• Clear（清晰）：每個組成部分的描述清晰，易于理解；
• Concise（簡潔）：只包含必不可少的信息，不包括任何多余的內容；
• Complete（完整）：包含復現該缺陷的完整步驟和其他本質信息；
• Consistent（一致）：按照一致的格式書寫全部缺陷報告。

3. 缺陷報告的組織結構

盡管不同的軟件測試項目對于缺陷報告的具體組成部分不盡相同，但是基本組織結構都是大同小異的。一個完整的軟件缺陷報告通常由下列幾部分組成：

• 缺陷的標題；
• 缺陷的基本信息；
  • 測試的軟件和硬件環境；
  • 測試的軟件版本；
  • 缺陷的類型；
  • 缺陷的嚴重程度；
  • 缺陷的處理優先級。
• 復現缺陷的操作步驟；
• 缺陷的實際結果描述；
• 期望的正確結果描述；
• 注釋文字和截取的缺陷圖像。

對于具體測試項目而言，缺陷的基本信息通常是比較固定的，也是很容易描述的。實際書寫軟件缺陷報告容易出現問題的地方就是標題、操作步驟、實際結果、期望結果和注釋部分。下面針對這些“事故多發地帶”具體論述如何提供完整的信息，由于英文是軟件開發的主要語言，以下的軟件缺陷報告的信息都使用英文書寫。

4. 缺陷報告的寫作技術

4.1 標題（Title）

標題應該保持簡短、準確，提供缺陷的本質信息，并且便于讀者搜索查尋。

良好的缺陷標題應該按照下列方式書寫：

• 盡量按缺陷發生的原因與結果的方式書寫（“執行完A后，發生B，”或者“發生B，當A執行完后”）；
• 避免使用模糊不清的詞語，例如“功能中斷，功能不正確，行為不起作用，”等。應該使用具體文字說明功能如何中斷，如何不正確，或如何不起作用；
• 為了方便搜索和查詢，請使用關鍵字；
• 為了便于他人理解，避免使術語、俚語或過分具體的測試細節。

請查看下面的表格，該表格列出了有問題的標題，給出了如何改進的示例。

clearcase/" target="_blank" >cccccc>

原始描述	錯誤原因	改進的標題
Hyphenation does not work	描述太籠統。什么時候不起作用？	Text breaks at line's end, but no hyphen appears
Incorrect behavior with paragraph alignment	描述太籠統。不正確的行為是什么？	Justified alignment leaves gaps in text composition when tracking is also applied
Assert:CmdAssertHereInsertSomethingBad-Happens	沒有包含原因與結果信息。斷言（Assert）太長。	Assert, "SomethingBad" when attempting to update linked bitmap stored on server
After each launch then clicking edit and then copy/paste, there is too much delay	沒有指明原因與結果，包含了過分詳細的細節信息。	Performance slows noticeably after ?rst launch and copy/paste
Quotes appear as symbols when they are imported	信息沒有充分隔離。所有的引號都如此嗎？什么類型的符號？	Imported smart quotes from Word appear as unrecognized characters

提示

使用"after"，"when"或"during"等連結詞有助于描述缺陷的原因和結果，例如：

• Application crashes after input any letters in numeric field.
• Internal error occurs when closing application.
• Application suspended during email transmission."

4.2 復現步驟（Reproducible Steps）

復現步驟包含如何使別人能夠很容易的復現該缺陷的完整步驟。為了達到這個要求，復現步驟的信息必須是完整的、準確的、簡明的、可復現的。

但是實際軟件測試過程中，總是存在一些不良的缺陷報告，主要的問題在于以下三個方面：

• 復現步驟包含了過多的多余步驟，而且句子結構混亂，可讀性很差，難于理解；
• 復現步驟包含了過少的信息，丟失操作的必要步驟。由于提供的步驟不完整，開發人員經常需要種種猜測，努力嘗試復現的步驟，浪費了大量時間。由于缺少關鍵步驟，這些缺陷通常被工程師以“不能復現”為由再次發送給測試人員；
• 測試人員沒有對軟件缺陷發生的條件和影響區域進行隔離，軟件開發人員無法判斷該缺陷影響的軟件部分，不能進行徹底修正。

為了避免出現這些問題，良好的復現步驟應該包含本質的信息，并按照下列方式書寫：

• 提供測試的預備步驟和信息；
  • 環境變量。例如，如果默認項或預設、調試版本或發布版本等存在問題，請指明使用的操作系統和應用程序的環境變量；
  • 設置變量：指明哪種打印機、字體或驅動程序是復現Bug所必需的信息；
  • 復現路徑。如果有多種方法觸發該缺陷，請在步驟中包含這些方法。同樣地，如果某些路徑不觸發該缺陷，也要包含這些路徑。
• 簡單地一步一步地引導復現該缺陷；
• 每一個步驟盡量只記錄一個操作；
• 每一個步驟前使用數字對步驟編號；
• 盡量使用短語和短句，避免復雜句型和句式；
• 復現的操作步驟要完整，準確，簡短；
• 沒有缺漏任何操作步驟；
• 每個步驟都是準確無誤的；
• 沒有任何多余的步驟；
• 將常見步驟合并為較少步驟，例如：

  1. Create text frame.
  2. Add text.

可以簡單的合并成一步：

1. Create a new text frame and add text.

• 只記錄各個操作步驟是什么，不要包括每個操作步驟執行后的結果

需要再次引起注意的是，缺陷報告的讀者對技術有基本的了解，但是對軟件測試的細節可能所知有限。因此，一方面，沒有必要在缺陷報告中告訴啟動產品或者如何打開一個文件等簡單操作方法。另一方面，不要包含軟件測試過分詳細的技術細節，除非這些是缺陷至關重要的信息。

4.3 實際結果（Actual result）

實際結果是執行復現步驟后軟件的現象和產生的行為。

實際結果的描述很像缺陷的標題，是標題信息的再次強調，要列出具體的表現行為，而不是簡單的指出“不正確”或“不起作用”。

如果一個動作產生彼此不同的多個缺陷結果。為了易于閱讀，這些結果應該使用數字列表分隔開來。例如：

Actual result:

1. Assert “CmdLineofCodeHere…”
2. Assert “AlsoBrokenHere…”

有時，一個動作將產生一個結果，而這個結果又產生另一個結果。這種情況可能難以清晰、簡潔地總結。例如：

Actual Result：

1. Assert:“CmdLineofCodeBlahBlah…”
2. When this assert is dismissed, app becomes active but all text is unrecognizable.
3. After selecting the text by dragging the text tool, the text appears normally once again.

對于這些較難處理的情況，有多種使之易于閱讀的解決方法：

• 盡可能將缺陷分解成多個缺陷報告，并使用交叉引用說明彼此之間的聯系。這些動作的結果通常比較相似但缺陷不同。首先進行更多的隔離測試，縮小產生缺陷的范圍，查看是否產生多個缺陷；
• 在實際結果部分，僅列出缺陷的一到兩個表現特征。使用注釋（Notes）部分列出缺陷的其它問題；
• 在缺陷的第一個表現特征后，將隨后的步驟和缺陷表現特征移到注釋部分。重要的信息幾乎總是包含在第一個斷言或錯誤里，其它錯誤都是第一個錯誤的變種。

4.4 期望結果（Expected result）

期望結果的描述應該與實際結果的描述方式相同。通常需要列出期望結果的應該是什么，并且給出期望結果的原因，可能是引用的規格說明書、前一版本的表現行為、客戶一般需求、排除雜亂信息的需要等等。

為了更清楚地理解良好的期望結果應該包含什么信息，請看下面的例子：

Expected result：

The text that appears should be fully highlighted so that if the user wishes to make changes, they don’t have to manually highlight and then type (as in Mac OS 10.x and Windows behavior.)

為什么說這個例子很好呢？因為它包含了如下內容：

• 應該產生的正確現象：The text that appears should be fully highlighted
• 為什么應該產生：…so that if the user wishes to make changes, they don’t have to manually highlight and then type.
• 給出了具體得參考對象：As in OS 10.x and Windows behavior.

4.5 注釋（Notes）

注釋應該包括復現步驟中可能引起混亂的補充信息，是對操作步驟的進一步描述，這些補充信息是復現缺陷或隔離缺陷的更詳細的內容。

注釋部分可以包含以下各方面的內容：

• 截取缺陷特征圖像文件（Screenshots）；
• 測試過程需要使用的測試文件；
• 測試附加的打印機驅動程序；
• 再次描述重點，避免開發人員將缺陷退回給測試人員補充更多信息；
• 再次指明該缺陷是否在前一版本已經存在；
• 多個平臺之間是否具有不同表現；
• 注釋包含缺陷的隔離信息，指出缺陷的具體影響范圍。

例如，缺陷的注釋可能包含下面的內容：

Notes：

1. Text displays outside frame in Win2000 and WinXP, but not Win98.
2. Does not happen after screen has redrawn.
3. Does not occur when two documents are open.
4. Refer to attached screenshots and testing file

5. 缺陷報告的寫作注意事項

提高缺陷報告的寫作水平是不斷積累經驗，循序漸進的過程。在正式提交缺陷報告前，請對缺陷報告的內容和格式進行自我檢查，避免很多不必要的錯誤。

5.1 自我檢查和提問

• 缺陷報告已經向讀者包含完整、準確、必要的信息了嗎？
• 一個缺陷報告中是否之報告了一種缺陷？
• 讀者是否能容易的搜索該缺陷？
• 步驟是否可以完全復現而且表達清楚嗎？
• 是否包含了復現該缺陷需要的環境變量或測試所用的數據文件？
• 缺陷的標題是按照原因與結果的方式書寫的嗎？
• 實際結果和期望結果是否描述不夠清楚而容易引起歧義嗎？

5.2 避免常見的錯誤

• 使用“I（我）”、“You（你）”等人稱代詞?？梢灾苯邮褂脛釉~或必要時使用“User（用戶）”代替；
• 使用情緒化的語言和強調符號，例如黑體、全部字母大寫、斜體、感嘆號、問號等。只要客觀地反映出缺陷的現象和完整信息即可，不要對軟件的質量優劣做任何主觀性強烈的批評、嘲諷；
• 使用諸如“Seems（似乎）”、“Appears to be（看上去可能）” 等含義模糊的詞匯，而需要報告確定的缺陷結果；
• 包含認為比較幽默的內容，因為不同讀者的文化和觀念不同，很多幽默內容在別人看來，往往難以準確理解，甚至可能引起誤解。只需客觀地描述缺陷的信息即可；
• 將不確定的測試問題（Issues）放在缺陷管理數據庫中。如果對測試軟件的某個現象不確定是否是軟件缺陷，可以通過電子郵件或口頭交流，確認是缺陷后再報告到數據庫中。避免查詢和統計結果的不準確性。

原文轉自：http://www.anti-gravitydesign.com