2、
缺乏文檔測試、檢查。
文檔是項目的重要產品之一，產品需求、功能分析、架構設計、詳細設計、用戶手冊、維護手冊等等，對于項目的測試、上線、維護等過程起到至關重要的參考、指導作用，所以它們的質量應該是項目重點關注點之一。令人遺憾的是，許多軟件項目對于文檔的重視只停留在口頭上，“編碼第一”的觀念似乎根深蒂固。
隨著需求不斷變更、補充，業務、技術人員忙于應付，無法騰出精力來進行文檔內容的修改及完善，往往是將包含需求變更內容的工作聯系單往需求文檔后一附了事，而不去更新需求與其他相關文檔；另一方面，項目變更管理還不夠完善，管理重點往往集中于開發，而輕視文檔質量管理，未留出充分的文檔更新時間，導致文檔更新嚴重滯后于編碼進度。為保證文檔質量，必須定期進行文檔測試，但測試要花成本，項目高層不愿意付此代價。
文檔若可讀性低，便會影響用戶的理解；若與編碼不一致，便起不到參考作用，編碼測試就沒有可靠的測試依據。路都看不清楚，怎么往前走呀？所以，強烈建議進行文檔測試，并將其置于測試管理的首位。
當前文檔測試的方法沒有什么特別的形式，還缺乏測試工具支持，通常是通過靜態審查方式――“走查”來進行的，主要查看文檔的可讀性，內容真實性、可靠性、全面性。另外，在項目里程碑時期召集相關領域專家對重要文檔進行集中審核，也是一種檢查方式。
單元測試是對軟件基本組成單元進行的測試，測試對象是軟件模塊。通常，單元測試是由開發人員來完成，而且往往是各人測各人的。這存在問題隱患。
為什么呢，技術人員是軟件模塊的制造者，自己來測自己的軟件的話，角色便從制造者變成了審查者，而前一個角色的目的是為了保證軟件正確，后一個角色的目的是為了發現更多的缺陷，讓一個人同時來扮演兩種目的不同的角色，好比讓他既當裁判員又當運動員，怎么能做好呢？解決方法通常有兩種，一種是：由測試人員來進行單元測試，這種方式要求測試人員要有較高的軟件技術知識；另一種是：將軟件人員分組，在模塊開發告一段落時進行交叉測試，這種方法只需要測試者了解被測方的軟件需求，不需要另外的知識培訓，而且測試出發點較為客觀，所以被較普遍的推廣使用。
4、
測試在開發基本完成才啟動；
在傳統的瀑布型開發模式中，軟件測試位于編碼階段之后，是作為一個獨立階段存在的，許多人便一刀切地認為應該將所有的測試工作在編碼完成后再開始。這個觀點要不得，原因有二：
首先，若將測試工作細分，有許多工作是可以提前先期執行的，如：需求書與設計書的學習、測試計劃的制定、測試人員的培訓、測試腳本的建立、測試資源的搭建、測試模板的創建、測試工具的選擇等等，都是可以與其他階段并行處理的，這將大大縮短項目開發時間，為測試提供充分的時間保障，提高測試質量。
其次，軟件缺陷發現的越晚，修改、補救所耗費的成本越高。引用Boehm在《Software Engineering Economics》一書中的話――“平均而言，如果在需求階段修證一個錯誤的代價是1，那么，在設計階段就是它的3－6倍，在編程階段是它的10倍，在內部測試階段是它的20—40倍，在外部測試階段是它的30－70倍，而到了產品發布出去時，這個數字就是40－1000倍�！庇纱丝梢�，測試目標的最佳定位應該是：在錯誤第一次出現的時候就捕捉到它。所以，在盡可能的情況下，測試越早展開越好。
在項目的各個進行階段，都有不同的項目產品產生，他們質量的好壞，對后續開發影響重大，所以，現在國際上比較流行的做法是：將測試融合到各個開發環節中去，盡早測試。
傳統的測試過程，測試管理不嚴密，測試人員未建立完整的測試庫，未將測試案例、測試程序、測試方案進行有效保存，等到回歸測試時，相關測試程序等往往已不知所終，無處可尋了；即使能找到這些程序、案例，可往往因為回歸測試過于頻繁、項目期限日益迫近，已經沒有時間余量來修改、完善這些程序及案例，只能憑借經驗、記憶及技術人員的口述對程序修改過的地方草草重測一遍而已，缺乏正規化的測試過程，造成測試的虎頭蛇尾。
正常的測試案例使用方式如上圖，測試設計階段，相關測試設計人員會對測試對象進行了解、分析，為保證測試順利進行，保證測試覆蓋盡量多的測試對象，會設計測試案例、測試方案，在測試期間進行使用；測試發現錯誤時，軟件技術人員會根據測試的缺陷反饋結果及技術人員的軟件修改信息對測試程序進行修改，完畢后再進行回歸測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
