正常的測試案例使用方式如上圖，測試設計階段，相關測試設計人員會對測試對象進行了解、分析，為保證測試順利進行，保證測試覆蓋盡量多的測試對象，會設計測試案例、測試方案，在測試期間進行使用;測試發現錯誤時，軟件技術人員會根據測試的缺陷反饋結果及技術人員的軟件修改信息對測試程序進行修改，完畢后再進行回歸測試。
6、 測試人員素質低，缺乏相關知識培訓
項目管理人員對測試存有偏見，對于測試的重要性認識不足，導致其嚴重忽略測試人員的選拔和知識培訓。許多軟件項目讓軟件用戶或新招收的技術人員來完成測試工作，他們認為測試人員的工作很簡單，就是技術人員讓測什么就測什么，它基本是一個動手不動腦的工作。
這樣做的后果進一步導致了測試工作的無序和混亂，測試過程缺乏計劃性，測試人員缺乏技術能力，缺乏對架構的了解，相關素質的缺失使他們成為技術人員的附庸。測試對于他們來說，是一種枯燥的“手+眼”式的工作，他們唯一渴望的，是將無聊的測試盡快完成，從而遠遠的逃離。這樣的測試結果可想而知。
其實，軟件工程對測試人員的素質要求是很嚴格的，比如：要有相關計算機知識背景、具備軟件工程基本知識、熟悉項目編程語言、熟悉項目技術架構及需求內容、工作有責任感、獨立分析能力及團隊精神等等。真正規范的軟件項目對于測試人員的要求是不會低于技術人員的，而且會為測試人員提供進一步的知識培訓機會，以應對各種項目的復雜情況。
7、 測試進度的錯誤估算
在項目開發中，領導為督促測試的進程，往往會讓項目組匯報工作進度，了解已經完成的工作占比，從而對工作進度做出判斷。我對這種工作方式完全擁護，只是覺得這種方式還有不足。
測試進程不是簡單的1+1過程，不能武斷地認為“我用8天干完了80%的工作，那么，剩余工作便能在2天內干完”。著名的Pareto80/20規律告訴我們：測試發現的所有錯誤中的80%很可能集中在20%的程序模塊中，另外20%很可能集中在80%的程序模塊中。
所以，沒有對測試對象認真分析的基礎，單憑工作完成數量而對工作進度做出的的判斷往往是錯誤的。
我認為，“工作實際進度=工作完成量占比+測試對象的錯誤占比分析”才是一個較合理的測試進度估算方式。
測試新思路
項目的開發風險來自于對需求的誤解，來自于設計與開發過程及產品的缺陷，只有盡早發現這些缺陷，才能降低并控制項目風險�；谶@種思想，軟件業出現了一些新的測試思路，主要有二：
1、測試驅動開發(Test-Driven Development，簡稱TDD)。這種測試思想被最近流行的XP(Extreme Programming)極限編程方式所大力提倡。它的基本思想是，通過測試來為編程做指導，在某個要開發的需求對象明確之后，在編碼之前，先進行相關測試代碼(測試代碼的內容和需求規格說明書描述是相同的，有人把它稱為“可執行的需求規格說明書”)的編寫工作，完成之后針對測試代碼進行編程，然后再用測試程序對開發代碼進行測試，驗證其正確性，若程序通過了測試，就說明它是符合需求規格說明書要求的。周而復始，通過這樣的過程，開發進程得以層層深入，直到開發完成。而這時單元測試也基本完成了。
這種測試方式的最大的好處是，盡早地發現設計、開發中存在的問題，避免傳統開發模式中的“測試過程中發現代碼不能滿足需求而導致的大量返工”。降低項目風險;同時可以盡早地將“半成品”展示給客戶，使客戶對需求進行驗證、補充及完善，另外測試代碼的表達方式相對準確、無二義性，可以降低因需求理解錯誤而導致的項目風險。
文章來源于領測軟件測試網 http://www.kjueaiud.com/