六、測試部門要獨立，最好不受開發的制約。
其實真正要重視，就應該有否決的權利。我們公司就是項目承包，要拿最后的項目尾款，就要測試部簽字通過，這樣就避免了很多的問題。其實只要自己盡到心就可以了，管別人怎么說呢。
七、我們使用的狀態有：程序員處理的狀態（由測試員提交的Action）：等待處理的，再次出現的。測試員處理的狀態（由程序員提交的Action）：已經修改的，暫不修改的，系統限制的，使用錯誤的，無法再現的。測試員可以修改記錄。經理處理的狀態（由測試員提交Action）：管理員處理的。經理還可以刪除記錄。按照比較標準的說法，其實對于缺陷還應該有“等待確認的”、“已經確認的”和“重復提交的”的狀態，我們為了省事，統一使用了“等待處理的”。最后結項的時候，缺陷的狀態對我們來說有兩種，“已經關閉的”（由測試員或經理確認）和“暫不修改的”（比如下一個版本處理等）。呵呵，狀態多，有些煩瑣，特別是程序員很多的時候都不清楚應該回復什么狀態，但我個人覺得對測試人員來說，這些狀態比較清晰明了，容易處理。
八、一個叫doer_ljy(可戰)的網友回復了一些內容，我個人認為不很妥當，就回復了一些內容，綠顏色的是doer_ljy(可戰)的內容：
關于“無法重現”我看是有這么個問題存在。首先如果你在測試之前有嚴格的測試計劃，就很難出現“無法重現”這種現象�！盁o法重現”的意思是不知道怎么操作才能再次看見這個BUG。那么這個BUG多半是“計劃外”的。不清楚你是否是測試人員�！坝媱澩狻边@個詞，對測試員來說應該不存在。測試用例的粒度一直是個在討論中的問題，測試人員很難有時間和精力寫出包含內容、數據、步驟等等全部操作一切的測試用例（說白了，只要一個長手識字的人，按照測試單做，就能發現所有的問題，呵呵，有軟件藍領的感覺了）。即使真的有，意義也不大，測試很多的時候，是發散性的思維，帶點創造性，想事先考慮完全，很難。所以更多時候，是在測試過程中逐步對用例等進行完善，所以說“計劃外”最好不要提。說說我現在測試的一個項目，有一個業務，首先查詢出人員，有個“全選”按鈕，“全選”后，再用鼠標一個一個取消選擇，這個時候進行業務辦理的時候，就會提示“沒有選擇人員”，至今為止一切都正常，但是這個時候再次點選人員進行業務處理，仍然會提示“沒有選擇人員”，這就是一個缺陷了。這個問題我想一般人都不會在測試用例中考慮到吧，因為發生的條件很苛刻：不用“全選”按鈕的時候不會發生；全選后點擊“取消全選”按鈕再辦理業務不會發生；全選全消后，先點擊人員再辦理業務也不會發生。其次，成熟的測試人員及時無法再現BUG，也能準確的描述出BUG發生之前幾個步驟的操作方法，測試用例情況。這些對開發人員分析BUG原因很重要。所謂的BUG發現環境。呵呵，看來我不是成熟的測試人員。手工測試，比較熟練的時候，和打字可以說差不多，應該進行到哪里，心中是有數的，但讓我完全從頭到尾的重復，不容易呀。寫測試缺陷報告單的時候，也只是說明操作步驟和發生的現象。其實無法重現的問題，既然說“無法重現”，也就是測試人員已經對這個現象進行了多次的驗證，一般從程序外部來說，測試人員的操作比程序員要熟練的。最后，我不同意測試人員不假思索把發現的“問題”直接推給編碼人員的做法。畢竟是大家合作，目標是一致的。測試人員總是處在BUG發生的第一現場，應該幫助分析出現問題的原因。確認是不是自己的此時Miss. 測試人員提交任何一個問題，都會經過反復的驗證，如果容易重現，早就提出來了。絕對不是在推脫責任，還是那句話，對程序的結構，做的人當然比不做的人要清楚。另外，除非程序員詢問，否則我不會給程序員提出修改分析和建議��！測試人員的任務是發現問題，解決問題是程序員的事情。這么做可能會影響程序員思考問題的思路；而且測試人員做的多了，程序員不但不感激，可能反而會反感（好像程序員對測試人員有好印象的不多）。再說兩個我這兩天遇到的問題。第一個就是我們的程序有一個鎖定數據的功能。鎖定后，在其它的業務，此數據將不能再使用。我當時發現這個功能無效，而且經過了幾次的驗證都不行，我當然就提出了。但是程序員那里說此功能好使，我再驗證的時候，就沒有問題了，這個問題當時可以重現（但是我不可能遇到問題就拉程序員來看吧），后來卻沒有了，只能放在那里，最后關閉掉。第二個就是在一個界面中，錄入有順序要求，必須先選擇一個ListBox（必填）再進行Edit的錄入，但一次操作我沒有選擇 ListBox就錄入的Edit，也正常保存了。后來無論我怎么操作此問題都沒有出現（不夠成熟呀），我就放棄了，也沒有提交記錄（為了避免麻煩）。測試人員的時間是有限的，進度給的都很少，一般連用例都沒有時間寫，還要去花很多時間驗證“無法重現”的問題？反正10分鐘如果試驗不出來，我就會放棄。嚴重的就提交，不影響的就當不知道。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
