七、我們使用的狀態有： 程序員處理的狀態（由測試員提交的Action）：等待處理的，再次出現的。 測試員處理的狀態（由程序員提交的Action）：已經修改的，暫不修改的，系統限制的，使用錯誤的，無法再現的。測試員可以修改記錄。 經理處理的狀態（由測試員提交Action）：管理員處理的。經理還可以刪除記錄。 按照比較標準的說法，其實對于缺陷還應該有“等待確認的”、“已經確認的”和“重復提交的”的狀態，我們為了省事，統一使用了“等待處理的”。 最后結項的時候，缺陷的狀態對我們來說有兩種，“已經關閉的”（由測試員或經理確認）和“暫不修改的”（比如下一個版本處理等）。 呵呵，狀態多，有些煩瑣，特別是程序員很多的時候都不清楚應該回復什么狀態，但我個人覺得對測試人員來說，這些狀態比較清晰明了，容易處理。 八、一個叫doer_ljy(可戰)的網友回復了一些內容，我個人認為不很妥當，就回復了一些內容，綠顏色的是doer_ljy(可戰)的內容：
關于“無法重現”我看是有這么個問題存在。 首先如果你在測試之前有嚴格的測試計劃，就很難出現“無法重現”這種現象�！盁o法重現”的意思是不知道怎么操作才能再次看見這個BUG。那么這個BUG多半是“計劃外”的。 不清楚你是否是測試人員�！坝媱澩狻边@個詞，對測試員來說應該不存在。測試用例的粒度一直是個在討論中的問題，測試人員很難有時間和精力寫出包含內容、數據、步驟等等全部操作一切的測試用例（說白了，只要一個長手識字的人，按照測試單做，就能發現所有的問題，呵呵，有軟件藍領的感覺了）。即使真的有，意義也不大，測試很多的時候，是發散性的思維，帶點創造性，想事先考慮完全，很難。所以更多時候，是在測試過程中逐步對用例等進行完善，所以說“計劃外”最好不要提。 說說我現在測試的一個項目，有一個業務，首先查詢出人員，有個“全選”按鈕，“全選”后，再用鼠標一個一個取消選擇，這個時候進行業務辦理的時候，就會提示“沒有選擇人員”，至今為止一切都正常，但是這個時候再次點選人員進行業務處理，仍然會提示“沒有選擇人員”，這就是一個缺陷了。這個問題我想一般人都不會在測試用例中考慮到吧，因為發生的條件很苛刻：不用“全選”按鈕的時候不會發生；全選后點擊“取消全選”按鈕再辦理業務不會發生；全選全消后，先點擊人員再辦理業務也不會發生。 其次，成熟的測試人員及時無法再現BUG，也能準確的描述出BUG發生之前幾個步驟的操作方法，測試用例情況。這些對開發人員分析BUG原因很重要。所謂的BUG發現環境。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
