問題單是版本測試過程中發現問題問題，也可以稱作為bug、缺陷。提單是每一個測試人員必備技能之一。但是並不是所有的測試人員都會很好的完成這一項工作。當發現問題時如何提單、如何確保自己提單內容合理，可以減少與開發溝通工作量，甚至後續測試人員重新驗證該同步單時可以直接從問題單中獲取到有效信息。本文主要從問題單提單規範、提單內容規範和回歸問題單內容規範這三個方面來描述。

問題單提單規範

1、提單正確性。當版本測試過程中，發現疑似問題時，需要自己分析問題根因。如果分析不出來，也需要找開發定位確認問題。不能將未經分析的問題直接提單。

2、提單及時性。發現問題時並確認已經是問題時，請及時提單。盡早提單也可以給開發留有足夠的修改時間，也可以避免自己忙於手頭工作時將之遺忘。

3、不要合並問題提單。盡量不要在一個問題單中合入多個問題。容易造成開發漏改或者測試回歸時遺漏。因為有可能不同的問題涉及多個開發，版本經理容易忽略轉給某個開發。

4、問題單內容描述規範。通常會包括測試版本、所屬特性或類別、發現階段、問題定級、問題描述等。

問題單提單內容規範

每個公司都會有固定使用的問題單跟蹤管理系統。通常問題單都會包括如下幾塊主要方面：

1、問題單簡要描述。通常包括局點、特性、簡要描述。

2、測試版本。包括業務包括、主要依賴的平臺版本。

3、預置條件。用例涉及的主要參數或者特殊參數。

4、操作步驟。可復現操作的主要步驟即可。

5、預期結果。

6、實際結果。

7、問題初步分析。提單前需要對問題根因進行分析。如果分析不出，找開發協助。

8、問題相關截圖、日誌、消息等。為問題單分析提供依據。

問題單回歸內容規範

當問題單修改走回測試回歸時，測試需要將回歸場景、過程結果提交到系統。問題單回歸內容規範主要如下：

1、測試版本。版本號中帶叠代版本。

2、測試思路。主要描述回歸問題單的測試方案。

3、測試過程。將回歸問題單驗證的用例結果保存上傳。

4、測試結論。回歸驗證通過、不通過、部分通過等。

5、其他。如果用例是自動化腳本用例，可以將腳本打包一並放置。如果該問題單需要在其他版本修改，可以方便獲取。

問題單提單和回歸規範