談談測試中的常見問題及解決意見

　　1、 測試人員需要何時參加需求分析？

　　原則上，測試人員對需求了解得越深入對測試工作越有利，所以最好一開始就應該參加需求分析工作。這樣可以帶來如下好處：

　　測試人員全程參與需求分析，對需求了解很深刻，減少了很多與開發人員的交互，節省了時間。測試人員參與前期開發討論，直接掌握了不清晰的需求點；

　　早期確定測試用例的編寫思路，為項目（產品）測試打好了基礎；

　　可以獲取一些測試數據，為測試用例設計提供幫助；

　　可以發現需求不合理的地方，降低了測試成本。

　　測試人員主要的工作之一就是確認系統是否正確實現了需求。測試人要不參與前期的工作，就只能依賴最后形成的需求文檔，甚至由開發人員來講解需求，而這些需求可能發生了“問題”，因為這個需求是已經經過分析的需求，很多的內容可能與用戶的真正要求發生了偏差。同時如果只看最后形成的需求文檔，對需求也會有理解上的偏差。因此作為測試人員要盡可能的獲取到“第一線”的需求資料，才能真正地了解用戶的業務，從而更好的對系統進行測試。

　　當然，如果測試人員不能參與需求環節，一定要通過其他途徑保證需求的正確性，例如和開發人員進行集中討論需求疑問的項目 會議，并且一定要加強測試案例評審，甚至于是測試需求的評審。

　　2、 系統測試階段低級缺陷較多怎么辦？

　　在系統測試階段，如果仍有很多低級缺陷，說明測試對象是不合格的，沒有達到測試 標準。如果系統階段發現的簡單缺陷（也就是不應該有的缺陷）較多，最好停止測試，反饋給開發人員進行測試，發現問題立刻修改，因為這種由測試人員進行測試的成本較高，反復交互還會耽誤項目進度。

　　建議建立預測試制度：系統測試前對核心模塊進行抽查測試，如果問題較多（例如核心功能存在20個以上的缺陷），就可以停止本次測試，反饋給開發組進行測試，直到抽測后問題較少才可以啟動系統測試。

　　3、 缺陷流落到客戶那里有什么后果？

　　如果軟件缺陷被遺落到客戶那里，結果就是代價高昂的電話或現場支持費用，還可能需要修復、重新測試和發布新的產品，更糟糕的情況是產品要被召回甚至被客戶起訴。這種成本付出非常高，幾乎是在內部修改缺陷的幾倍，甚至十幾倍。

　　質量之父PhilipCrosby把質量的費用分為整合費用和非整合費用兩類，整合費用是指與一次性計劃和執行測試相關的全部費用，用于保證軟件按照預期方式進行。如果發現缺陷，經過一系列的缺陷處理流程而解決缺陷，這種費用就是非整合費用。PhilipCrosby在自己的作品中詳細論述了內部的整合費用和內部的非整合費用之和遠遠小于外部也就是客戶引起的非整合費用。

　　 軟件測試是保證軟件質量的有效手段，但不是唯一手段。高質量的軟件不是測試出來的，而是設計出來。這就需要全員一起參與，提高全員的質量意識，共同提高軟件的質量。

　　總之，軟件缺陷一定要盡可能的在內部解決，這對節約成本、提高產品知名度都大有意義的。

　　4、 狀態為已經修改的缺陷沒有修改怎么辦？

　　首先對這類缺陷進行分析：

　?。?）有些問題在開發環境下沒有重現，而開發人員迫于進度壓力，往往會把它標記為已經修改。這種條件下測試人員應該和開發人員進行直接 溝通；

原文轉自：http://www.anti-gravitydesign.com