首先，確保你所發現的問題是確實是一個bug,不要出現因為測試人員操作錯誤或配置錯誤所引起的”bug”,這樣會降低你在開發人員心中的可信度。在測試的時候，如果發現測試的實際結果與預期測試結果不符時，不要著急馬上報bug,先想想為什麼會出現錯誤。作為專業的測試人員，應該能夠對出現的問題進行跟蹤，確認了在配置、操作沒有錯誤的前提下，通過追蹤分析確認所測試的業務流程確實是存在bug,並能大概對bug的產生原因進行定位。測試人員，需要做到專業，儘量少給開發找麻煩，不要製造實際上並不存在的bug.

確認了所發現的問題是一個bug之後，按照測試步驟再執行一次，確保bug是可重現的而不是隨機的。如果bug不能重現，應該儘量找到bug重現的規律，在一些比較難重現的問題可以找開發配合一起查詢原因，如果還是無法重現則需要在bug report中對出現的問題描述清楚並說明出現的隨機性。

接下來就是填寫bug report了，在填寫bug report的時候，最重要的是bug的標題和bug描述。在bug報告中，首先用一句話對bug進行簡要精確的描述作為bug的標題，讓開發或專案經理一看就知道存在什麼問題，比如"XX模組在壓力測試2小時後出現記憶體洩露".而在bug的描述中，需要使用簡明準確的語言描寫出現bug的測試步驟、實際的測試結果、預期的測試結果和結論；也就是說描述導致出現bug的操作步驟是怎樣，由測試步驟所做的操作引起的測試結果是什麼，而預期的結果應該是怎樣，並由實際結果與預期結果相對比說明問題所在。比如："在管理網頁新增使用者，當新增的使用者登入名名稱很長（例如登入名長度為輸入框允許的最大長度），按'新增'按紐新增後系統提示已經有該使用者存在，而事實上該使用者並不存在，建議對超長的使用者名稱進行處理。"

在測試人員發現了一個已隔離的，可重現的問題後，應該對問題進行歸納。同一個問題是否出現在其他的模組或其他的流程？同一個故障是否會引起更加嚴重的問題？如果存在，也需要提出來讓開發一併處理。

在開發對bug進行修改之後，測試需要報著懷疑的態度認真地對問題進行驗證，需要嚴格按照測試步驟來進行測試，檢查開發是否已經正確修改了所出現的問題，以及開發對bug進行了修復之後是否會引進新的問題。不要相信開發說"已經修改好了，肯定沒問題了"就不對問題進行細緻的檢查了，如果開發修改得不徹底，問題仍然會存在的，或者可能會由於開發在修改bug的時候忽略了另一些細節導致了新bug的出現。儘量不要在關閉bug之後，才發現這個問題還沒有修改徹底；也不要出現bug關閉之後，出現了新的bug.

測試對bug進行驗證確認已經修改ok之後，關閉bug.在關閉的時候，應該對Bug最終修改結果進行簡要描述，如果bug的修改引起配置或資料庫或業務流程的變更，也需要在bug關閉描述中進行說明。
 

效能測試，負載測試，壓力測試有什麼區別

效能測試（或稱多使用者併發效能測試）、負載測試、強度測試、容量測試是效能測試領域裡的幾個方面，但是概念很容易混淆。下面將幾個概念進行介紹。

效能測試（Performance Test）：通常收集所有和測試有關的所有效能，通常被不同人在不同場合下進行使用。
關注點：how much和how fast

負載測試（Load Test）：負載測試是一種效能測試，指資料在超負荷環境中執行，程式是否能夠承擔。
關注點：how much

強度測試（Stress Test）： 強度測試是一種效能測試，他在系統資源特別低的情況下軟體系統執行情況，目的是找到系統在哪裡失效以及如何失效的地方。包括
Spike testing：短時間的極端負載測試
Extreme testing：在過量使用者下的負載測試
Hammer testing：連續執行所有能做的操作

容量測試(Volume Test)：確定系統可處理同時線上的最大使用者數
關注點：how much（而不是how fast）
容量測試，通常和資料庫有關，容量和負載的區別在於：容量關注的是大容量，而不需要表現實際的使用。

其中，容量測試、負載測試、強度測試的英文解釋為：
Volume Testing = Large amounts of data
Load Testing = Large amount of users
Stress Testing = Too many users, too much data, too little time and too little room

可能大家角色效能測試、負載測試和強度測試比較混淆。沒錯，這三個概念是比較容易使人糊塗。負載測試和強度測試，都屬於效能測試的子集。下面舉個跑步的例子進行解釋。
效能測試，表示在一個給定的基準下，能執行的最好情況。例如，在沒有負重的情況下，你跑100米需要花多少時間（這邊，沒有負重是基準）？
負載測試，也是效能測試，但是他是在不同的負載下的。對於剛才那個例子，如果擴充套件為：在50公斤、100公斤……等情況下，你跑100米需要花多少時間？
強度測試，是在強度情況下的效能測試。對於剛才那個例子，如果改為：在一陣強風的情況下，你在負重或沒有負重的情況下，跑100米需要花多少時間？

效能測試是動力，負載測試載重，壓力測試強度

壓力測試stresstest是在一定的負荷條件下，長時間連續執行系統給系統性能造成的影響。

負載測試Loadtest：在一定的工作負荷下，給系統造成的負荷及系統響應的時間。

壓力測試主要是為了發現在一（任意）定條件下軟體系統的效能的變化情況，通過改變應用程式的輸入以對應用程式施加越來越大的負載（併發，迴圈操作，多使用者）並測量在這些不同的輸入時效能的改變，也就是通常說的概念：壓力測試考察當前軟硬體環境下系統所能承受的最大負荷並幫助找出系統瓶頸所在。其實這種測試也可以稱為負載測試，但是負載測試通常描述一種特定型別的壓力測試——增加使用者數量以對應用程式進行壓力測試。比如實際中我們說從比較小的負載開始，逐漸增加模擬使用者的數量， 直到應用程式響應時間超時，就是說的負載測試。

壓力測試的目標是測試在一定的負載下系統長時間執行的穩定性，尤其關注大業務量情況下長時間執行系統性能的變化（例如是否反應變慢、是否會記憶體洩漏導致系統逐漸崩潰、是否能恢復）；壓力測試是測試系統的限制和故障恢復能力，它包括兩種情況：
穩定性壓力測試：在選定的壓力值下，長時間持續執行。通過這類壓力測試，可以考察各項效能指標是否在指定範圍內，有無記憶體洩漏、有無功能性故障等；
破壞性壓力測試：在穩定性壓力測試中可能會出現一些問題，如系統性能明顯降低，但很難暴露出其真實的原因。通過破壞性不斷加壓的手段，往往能快速造成系統的崩潰或讓問題明顯的暴露出來；

負載測試的目標是測試在一定負載情況下系統性能（不關注穩定性，也就是說不關注長時間執行，只是得到不同負載下相關效能指標即可）；實際中我們常從比較小的負載開始，逐漸增加模擬使用者的數量（增加負載）， 觀察不同負載下應用程式響應時間、所耗資源，直到超時或關鍵資源耗盡，這就是所說的負載測試，它是測試系統的不同負載情況下的效能指標。

——————————————————————————————

最簡單來說：

負載測試是測試軟體本身最大所能承受的效能測試；

壓力測試就是一種破壞性的效能測試；

只要理解這兩點區別，就非常好理解效能測試了