就目前來說，很多的公司都不是很規范。一種情況：變更了軟件需求，相應的測試用例，沒有及時增加，測試人員測試時，完全憑個人的理解和經驗，想到哪里就測到哪里，隨便測試。在這種情況下，不同的人在不同的時間測試時，就會發現并提出不同的缺陷，這樣混亂的測試就導致測試輪數較多，效率自然低下。另外一種情況就是測試人員設計測試用例的水平不高，測試用例質量較差，導致測試反復進行，也測試不出Bug。這就要求測試部門主管，加大測試用例評審的力度，力爭以最少的測試用例，測試出較多的Bug。
8、部門員工進行模塊交叉測試，避免漏測提高測試效率：
測試主管在安排測試的時候，也要注意“用人之長，避人之短”。測試啟動階段，要對這個系統集中培訓，讓測試部門的成員對整個系統達成一致意見，最好在第一輪測試時，盡可能發現較多缺陷，開發人員盡早修復。第二輪測試就可以進行模塊交叉測試。一方面我們可以避免個人原因造成的漏測試，另外一方面也可以利用每個人不同的思維方式，很容易發現其它模塊的缺陷，避免多次重復測試，提高測試人員的積極性。測試效率提高了，發現的問題多了，后面測試的輪次自然要減少。
9、加強項目成員的管理，定期報告發現缺陷的情況，增加督促力度：
加強項目成員的管理，同樣能夠減少版本的發布和測試的輪次。測試人員每天都編寫測試日志，郵件抄送給項目部成員和公司領導報告每天測試情況，加強不同層次的領導對開發人員的督促力度。這就對應了第一條，如果公司領導不重視測試，也就無所謂。如果公司領導很重視測試結果，馬上作出反應，給各個部門的經理施加壓力，軟件質量被重視了，自然測試版本減少。如果哪個開發人員開發的模塊每天都有很多缺陷，開發人員自然很不光彩，畢竟大家都很要面子，開發人員也敢輕而易舉，開發的模塊功能不測試就直接扔給測試部。這也是一種有效的方法，當然也可以把缺陷的數量、嚴重程度作為開發人員的績效考核標準，提高開發人員的“質量意識”，缺陷自然很少。我們公司就是這樣做的，一般在2到3個版本時，就很難發現缺陷，測試人員也相互看看其它成員發現的缺陷，一旦有的測試人員發現了較多的Bug，發現缺陷很少的測試人員很急，比較有個比較嗎?特別是測試半天都沒發現Bug的測試人員，就經常給我講自己測試過程中的苦衷，我也很理解他們，多給他們鼓勵鼓勵。
10、嚴格控制需求變更的流程，減少后期的需求變動：
在項目開發中，經常碰到這樣的情況，客戶代表中有產品部、科技部、業務部等等部門的人員，很難通過某個客戶代表戶講清需求�？蛻舸�，隨著對開發系統的不斷深入了解，有可能客戶不斷的提出新的需求，或者說是不斷修改需求，所以對于需求的變更，我們一定要有一個嚴格的標準流程。通過開發方和客戶的評審后，再編寫相應需求文檔，最后開始開發。很多時候，繁瑣的需求變更流程和領導的多級審批簽字，并且需求的變更請求，也有相關的記錄，很多客戶都怕承擔需求變更帶來風險。也讓業務人員覺得變更比較麻煩，不得不放棄需求的變更。嚴格控制需求的變更流程，做到有效的需求變更，這也許是一種減少測試版本的方法。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
