如何有效地描述軟體缺陷 Defect ？

最近乙個月偷懶了，剛看到一篇博文很不錯。最近也是碰到一樣的問題，由於我記錄bug的描述不夠清晰。導致開發看不懂我描述的bug，還有一些配置資訊沒記錄好。出現一問三不知的情況，還被領導訓。下面的博文是來自的。

作為軟體測試人員，最基本的一項技能就是如何把所發現的缺陷(defect)準確無歧義的表達出來，尤其還是全英文表達的時候。

其實從缺陷的描述也可以看出乙個軟體測試人員的基本功，甚至可以看出測試人員在做一些自由測試的時候的投入程度。

本文主要以缺陷出現的頻率來說明測試人員在遇到不同頻率的缺陷的時候如何做?

缺陷的頻率主要有：always, usually(>50%), sometimes(<50%), once

對於所有的缺陷，都需要做到的是：

1，檢視當前測試環境和測試資料，並記錄下來。

2，記錄與該缺陷相關的配置等條件

3，記錄出現缺陷時候log資訊

4，描述盡量做到每個步驟最多兩個動作，一連串的操作盡量分句說明。

5，英語表達盡量用主動句型，體現操作性。

6，缺陷出現時候的現象一定要描述詳細，不要和步驟混在一起描述，乙個步驟最好對應乙個相應的輸出結果

7，缺陷出現之後若可以繼續進行操作，也盡量多做幾個步驟，這樣更容易發現當前缺陷周圍的缺陷，8/2原則或許在這裡可以起到作用。

8，盡量把缺陷出現時候的相關功能運**況也都描述詳細

9，對於一些比較難描述清楚、或者不能穩定重現的缺陷，在缺陷中需要新增出錯時截圖，所謂有圖有真相。

10，缺陷描述的終極目的，先拋開缺陷記錄的管理意義不說，主要是能讓開發人員根據缺陷描述，輕鬆地重現缺陷

對於always和usually這類容易重現的缺陷，除了以上必須做到的，還需要做到

1，按照缺陷重現的步驟重複做3次以上，這樣可以尋找最短的重現路徑，可以做到把不必要的過程過濾。(注意：不確定的步驟一定不能過濾)

2，同一缺陷現象出現在不同的地方，盡量能夠做總結，可以把不同的步驟分別寫出。

3，缺陷描述以及缺陷出現的各種環境等盡量做到簡介且全面，不需要總等到開發人員問。

對於sometimes的缺陷，理論上來說缺陷都能重現出來，所以我們遇到的sometime只是目前還沒有找到必然的那個路徑。

若與開發人員是在一起工作的比較好，遇到這類缺陷的時候，可以和開發人員溝通，簡單描述一下，共同推測必然出現的路徑。找出更多重現的路徑就有可能轉為always或usually，開發人員解決起來就容易些了。重現不出來，至少也需要把所有遇到缺陷的相關環境都詳細描述出來。

若與開發人員不在一起工作的，那就盡量把缺陷出現時候的各種log資訊作為缺陷附件提交。

對於once的缺陷：偶爾出現一次的缺陷，就是短時間內測試人員自己沒有重現出來的，測試時間有限，考慮成本問題，也不可能允許你一直去分析。

這樣的缺陷，我們測試人員能做到的首先跟開發人員溝通，有時候開發人員看一眼log就知道問題所在甚至推測出必然路徑的。否則，我們能做到的就是把上述1-10條把缺陷記錄在庫，在後續多個版本進行驗證(verify)。

作為測試人員，遇到缺陷的時候除了把缺陷描述簡潔明瞭之外，我們更需要做到的是：

1.盡量做到及時和開發人員溝通(尤其對需求不確定的情況)

2.立刻檢查當前狀態並做記錄(不要間隔時間太長，發現的時候立刻記錄，好記憶不如爛筆頭)

3.如果同樣的步驟連續發生好幾個缺陷，需要把每個缺陷的頻率都標註好

4. 如果有外部網路或者裝置等因素的影響，也盡量把外部環境描述清楚(這樣有助於開發人員fix缺陷)

作為測試人員的我們，目標只有乙個——軟體產品質量。我們不但要發現問題還要協助開發人員解決問題