如果您的錯誤報告是有效的，那麼它得到修復的機會就會更高。因此，修復bug取決於您如何有效地報告它。報告錯誤只是一種技能，我將解釋如何實現這一技能。
「編寫問題報告(bug報告)的目的是修復bug」-由cemkaner編寫。如果測試人員沒有正確報告錯誤，程式設計師很可能會拒絕此錯誤，稱其為不可複製的。
這會傷害測試員的道德，有時也會傷害自我。(我建議不要保持任何自我。自我就像「我正確地報告了錯誤」、「我可以複製它」、「為什麼他/她拒絕了這個錯誤？」、「這不是我的錯」等等)。
任何人都可以寫錯誤報告。但並不是每個人都能寫出有效的bug報告。
您應該能夠區分一般的bug報告和好的bug報告。如何區分好的和壞的錯誤報告？非常簡單，應用以下特性和技術報告錯誤。
特點和技術包括：
始終為每個bug報告分配乙個唯一的編號。這反過來將幫助您識別錯誤記錄。如果您正在使用任何自動錯誤報告工具，則每次報告錯誤時都會自動生成此唯一編號。
請注意您報告的每個bug的數量和簡要描述。
如果您的錯誤是不可複製的，那麼它將永遠不會被修復。
您應該清楚地提到重現bug的步驟。不要假設或跳過任何複製步驟。一步描述的bug很容易複製和修復。
不要寫關於這個問題的文章。
具體點，切中要害。試著用最少的詞來概括這個問題，但要用一種有效的方法。不要將多個問題結合在一起，即使它們看起來是相似的。為每個問題寫不同的報告。
有效的bug報告
錯誤報告是軟體測試的乙個重要方面。乙份有效的bug報告與開發團隊進行了良好的溝通，避免了混亂或錯誤溝通。
**乙個好的bug報告應該是簡明扼要沒有遺漏關鍵點。**任何不明確的情況都會導致誤解，也會減緩開發過程。缺陷寫入和報告是測試生命週期中最重要但卻被忽略的領域之一。
好的寫作對於錯誤的歸檔是非常重要的。測試人員應該記住的最重要的一點是不要用威嚴的語氣在報告裡。這破壞了士氣，造成了一種不健康的工作關係。用暗示的語氣。
別以為開發人員犯了乙個錯誤，因此您可以使用嚴厲的話。在報告之前，同樣重要的是檢查是否報告了相同的bug。
重複的錯誤是測試週期中的乙個負擔。檢查所有已知bug的清單。有時，開發人員可能已經知道了這個問題，並在以後的版本中忽略了這個問題。也可以使用bugzilla這樣的工具自動搜尋重複的bug。但是，最好手動搜尋任何重複的bug。
錯誤報告必須通訊的匯入資訊是「怎麼做？」和「在**？」報告應該清楚地回答測試是如何進行的，缺陷發生在**。讀者應該很容易地複製錯誤，並找到錯誤所在。
記住編寫錯誤報告的目的就是讓開發人員視覺化這個問題。他/她應該清楚地理解錯誤報告中的缺陷。請記住提供開發人員正在尋找的所有相關資訊。
另外，請記住，bug報告將保留下來供以後使用，並且應該用所需的資訊很好地編寫。使用有意義的句子和簡單的單詞來描述你的蟲子。不要使用令人費解的語句來浪費審閱者的時間。
將每個bug報告為乙個單獨的問題。在單個錯誤報告**現多個問題時，除非所有問題都得到解決，否則無法關閉它。
所以最好是把問題分成不同的錯誤。這確保了每個bug都可以單獨處理。乙個寫得很好的bug報告可以幫助開發人員在他們的終端複製bug。這也有助於他們診斷問題。
使用以下簡單的bug報告模板：
這是乙個簡單的錯誤報告格式。根據您正在使用的bug報告工具，它可能會有所不同。如果您正在手動編寫bug報告，那麼需要特別提到一些字段，比如bug編號，應該手動分配。
產品：你在哪種產品裡發現了這個漏洞。
版本： 產品版本(如果有的話)。
構成部分：這些是產品的主要子模組。
平台：提到你發現這個錯誤的硬體平台。各種平台如「pc」、「mac」、「hp」、「sun」等。
作業系統： 提到所有你發現錯誤的作業系統。作業系統，如windows，linux，unix，sunos，macos。提到不同的作業系統版本，如windows nt，windows 2000，windowsxp等，如果適用的話。
優先事項：什麼時候應該修復bug？優先順序通常從p1設定為p5。p1為「以最高優先順序修復錯誤」，p5為「時間允許時的修正」。
嚴重程度：
這描述了bug的影響。
嚴重程度型別：
現狀：
當您將錯誤記錄到任何bug跟蹤系統中時，預設情況下，bug狀態將是『new』。
後來，這個bug經歷了不同的階段，比如修復、驗證、重新開啟、不會修復等等。
分配給：
如果您知道哪個開發人員負責bug發生的特定模組，那麼您可以指定該開發人員的電子郵件位址。否則保持空白，因為這樣會將錯誤分配給模組所有者，如果不是，manager將錯誤分配給開發人員。可能在cc列表中新增經理的電子郵件位址。
url：
錯誤發生的頁面url。
摘要：乙個簡要的錯誤摘要，大部分是在60個字或以下。確保你的總結反映了問題所在。
描述：對錯誤的詳細描述。
對description欄位使用以下字段：
複製步驟：顯然，請提到重現bug的步驟。
預期結果：應用程式在上述步驟上的行為方式。
實際結果：執行上述步驟的實際結果是什麼，即錯誤行為。
這些是bug報告中的重要步驟。您還可以新增「報告型別」作為另乙個欄位來描述錯誤型別。
報告型別包括：
bug報告中的重要特徵
以下是bug報告中的重要特性：
bug編號或標識號(如swb 001)使錯誤報告和引用bug變得更加容易。開發人員可以很容易地檢查某個特定的bug是否已經修復。它使整個測試和再測試過程更加順暢和簡單。
bug標題比bug報告的任何其他部分都更頻繁地被讀取。它應該能說出bug的全部內容。
bug標題應該具有足夠的暗示性，使讀者能夠理解它。乙個清晰的bug標題可以讓讀者更容易理解，並且讀者可以知道錯誤是先前報告的還是已經修復的。
根據bug的嚴重程度，可以為其設定優先順序。乙個bug可以是乙個積木，批評，主要，小，瑣碎，或乙個建議。可以給出從p1到p5的bug優先順序，以便首先檢視重要的錯誤。
作業系統和瀏覽器配置對於明確的錯誤報告是必要的。這是最好的方式來溝通的錯誤如何可以被複製。
如果沒有確切的平台或環境，應用程式的行為可能會有所不同，測試端的錯誤可能不會在開發人員端複製。因此，最好清楚地提到檢測bug的環境。
bug描述有助於開發人員理解bug。它描述了遇到的問題。糟糕的描述會造成混亂，也會浪費開發人員和測試人員的時間。
有必要在描述中清楚地說明效果。使用完整的句子總是有幫助的。乙個很好的做法是分開描述每個問題，而不是把它們完全分解。不要使用「我認為」或「我相信」這樣的術語。
乙個好的bug報告應該清楚地提到複製的步驟。這些步驟應該包括導致錯誤的操作。不要做一般的陳述。在接下來的步驟中要明確。
下面是乙個很好的書面程式的例子
步驟：選擇產品abc 01。
單擊「新增到購物車」。
單擊「移除」將產品從購物車中移除。
乙個錯誤描述是不完整的，沒有預期的和實際的結果。有必要概述測試的結果和使用者應該期望的結果。讀者應該知道測試的正確結果是什麼。很明顯，提到在測試期間發生了什麼以及結果是什麼。
一幅畫勝過千言萬語。以失敗例項的截圖為例，配上適當的標題，突出顯示缺陷。用淺紅色高亮顯示意外錯誤訊息。這提請注意所需的領域。
如果在測試過程中發現任何錯誤，則不必等待稍後編寫詳細錯誤報告。相反，請立即編寫錯誤報告。這將確保乙個良好的和可重複的錯誤報告。如果稍後決定編寫bug報告，那麼很有可能錯過報告中的重要步驟。
你的***應該是可複製的。確保您的步驟足夠健壯，可以在沒有任何歧義的情況下重現bug。如果您的bug不是每次都可以複製，那麼您仍然可以提交乙個bug，其中提到了bug的週期性。
有時，開發人員對不同的相似模組使用相同的**。因此，乙個模組中的bug也更有可能發生在其他類似模組中。您甚至可以嘗試找到您發現的更嚴重版本的bug。
bug摘要將幫助開發人員快速分析bug的性質。質量不佳的報告會不必要地增加開發和測試時間。與錯誤報告摘要進行良好的溝通。請記住，bug摘要被用作在bug目錄中搜尋bug的參考。
閱讀錯誤報告中使用的所有句子、單詞和步驟。看看是否有任何句子會造成歧義，從而導致誤解。為了有乙個清晰的錯誤報告，應該避免誤導性的詞語或句子。
很好，你做了乙個很好的工作，發現了乙個bug，但不要用這個信用來批評開發人員或×××任何個人。
結語毫無疑問，你的錯誤報告應該是乙份高質量的檔案.
專注於編寫好的bug報告，並花一些時間在這個任務上，因為這是測試人員、開發人員和管理人員之間的主要交流點。管理者應該讓他們的團隊意識到，編寫乙個好的bug報告是任何測試人員的首要責任。
您為編寫乙個好的bug報告所做的努力不僅可以節省公司的資源，而且還可以在您和開發人員之間建立良好的關係。
軟體測試 測試用例 如何寫好乙個用例
測試用例 test case 是為某個測試目標而編制的一組測試輸入 執行步驟以及預期結果的集合，以便測試某 個程式的路徑或驗證軟體是否滿足某個特定需求，那麼怎麼寫好乙個用例呢？測試用例 test case 是為某個測試目標而編制的一組測試輸入 執行步驟以及預期結果的集合，以便測試某 個程式的路徑或驗...
如何寫好乙個BUG報告？
為什麼是好的bug報告？如果您的錯誤報告是有效的，那麼它得到修復的機會就會更高。因此，修復bug取決於您如何有效地報告它。報告錯誤只是一種技能，我將解釋如何實現這一技能。編寫問題報告 bug報告 的目的是修復bug 由cemkaner編寫。如果測試人員沒有正確報告錯誤，程式設計師很可能會拒絕此錯誤，...
如何寫好乙個基礎的BaseActivity
public abstract class baseactivity extends activity 初始化載入布局 public abstract int initlayout 初始化布局view public abstract void initview 初始化資料及呼叫方法 public a...