傳統(tǒng)的測試過程，測試管理不嚴密，測試人員未建立完整的測試庫，未將測試案例、測試程序、測試方案進行有效保存，等到回歸測試時，相關測試程序等往往已不知所終，無處可尋了；即使能找到這些程序、案例，可往往因為回歸測試過于頻繁、項目期限日益迫近，已經沒有時間余量來修改、完善這些程序及案例，只能憑借經驗、記憶及技術人員的口述對程序修改過的地方草草重測一遍而已，缺乏正規(guī)化的測試過程，造成測試的虎頭蛇尾。

　　正常的測試案例使用方式如上圖，測試設計階段，相關測試設計人員會對測試對象進行了解、分析，為保證測試順利進行，保證測試覆蓋盡量多的測試對象，會設計測試案例、測試方案，在測試期間進行使用；測試發(fā)現錯誤時，軟件技術人員會根據測試的缺陷反饋結果及技術人員的軟件修改信息對測試程序進行修改，完畢后再進行回歸測試。

　　6、 測試人員素質低，缺乏相關知識培訓

　　項目管理人員對測試存有偏見，對于測試的重要性認識不足，導致其嚴重忽略測試人員的選拔和知識培訓。許多軟件項目讓軟件用戶或新招收的技術人員來完成測試工作，他們認為測試人員的工作很簡單，就是技術人員讓測什么就測什么，它基本是一個動手不動腦的工作。

　　這樣做的后果進一步導致了測試工作的無序和混亂，測試過程缺乏計劃性，測試人員缺乏技術能力，缺乏對架構的了解，相關素質的缺失使他們成為技術人員的附庸。測試對于他們來說，是一種枯燥的“手＋眼”式的工作，他們唯一渴望的，是將無聊的測試盡快完成，從而遠遠的逃離。這樣的測試結果可想而知。

　　其實，軟件工程對測試人員的素質要求是很嚴格的，比如：要有相關計算機知識背景、具備軟件工程基本知識、熟悉項目編程語言、熟悉項目技術架構及需求內容、工作有責任感、獨立分析能力及團隊精神等等。真正規(guī)范的軟件項目對于測試人員的要求是不會低于技術人員的，而且會為測試人員提供進一步的知識培訓機會，以應對各種項目的復雜情況。

　　7、 測試進度的錯誤估算

　　在項目開發(fā)中，領導為督促測試的進程，往往會讓項目組匯報工作進度，了解已經完成的工作占比，從而對工作進度做出判斷。我對這種工作方式完全擁護，只是覺得這種方式還有不足。

　　測試進程不是簡單的1＋1過程，不能武斷地認為“我用8天干完了80％的工作，那么，剩余工作便能在2天內干完”。著名的Pareto80/20規(guī)律告訴我們：測試發(fā)現的所有錯誤中的80％很可能集中在20％的程序模塊中，另外20％很可能集中在80％的程序模塊中。

　　所以，沒有對測試對象認真分析的基礎，單憑工作完成數量而對工作進度做出的的判斷往往是錯誤的。

　　 我認為，“工作實際進度＝工作完成量占比＋測試對象的錯誤占比分析”才是一個較合理的測試進度估算方式。

　　測試新思路

　　項目的開發(fā)風險來自于對需求的誤解，來自于設計與開發(fā)過程及產品的缺陷，只有盡早發(fā)現這些缺陷，才能降低并控制項目風險?；谶@種思想，軟件業(yè)出現了一些新的測試思路，主要有二：

　　1、測試驅動開發(fā)（Test-Driven Development，簡稱TDD）。這種測試思想被最近流行的XP（Extreme Programming）極限編程方式所大力提倡。它的基本思想是，通過測試來為編程做指導，在某個要開發(fā)的需求對象明確之后，在編碼之前，先進行相關測試代碼（測試代碼的內容和需求規(guī)格說明書描述是相同的，有人把它稱為“可執(zhí)行的需求規(guī)格說明書”）的編寫工作，完成之后針對測試代碼進行編程，然后再用測試程序對開發(fā)代碼進行測試，驗證其正確性，若程序通過了測試，就說明它是符合需求規(guī)格說明書要求的。周而復始，通過這樣的過程，開發(fā)進程得以層層深入，直到開發(fā)完成。而這時單元測試也基本完成了。

　　這種測試方式的最大的好處是，盡早地發(fā)現設計、開發(fā)中存在的問題，避免傳統(tǒng)開發(fā)模式中的“測試過程中發(fā)現代碼不能滿足需求而導致的大量返工”。降低項目風險；同時可以盡早地將“半成品”展示給客戶，使客戶對需求進行驗證、補充及完善，另外測試代碼的表達方式相對準確、無二義性，可以降低因需求理解錯誤而導致的項目風險。

　　2、迭代測試。這種測試是IBM所推崇測試方式之一，它從迭代式開發(fā)模式演變而來。在迭代開發(fā)模式中，每個迭代都包含需求、設計、編碼、集成、測試等過程。在每一次迭代完成之后，便會開始新的迭代過程。通過一次次迭代的累進，系統(tǒng)會增量式集成一些新的功能，直至整個系統(tǒng)功能的完成。其中，每個迭代周期的測試工作由兩方面內容構成：
　　· 對當前迭代周期產品的增量測試。
　　· 對前迭代周期已完成功能的回歸測試

　　 隨著迭代周期的累進，測試工作內容隨之不斷變化。早期迭代測試重點在于新功能的測試，后期迭代測試重點在于累積功能的回歸測試。

　　有的人不喜歡XP編程的開發(fā)方式，認為其沒有明確的階段性劃分，不利于計劃管理，模式過于靈活，不好掌握。迭代式開發(fā)模式為這些人提供了新的選擇。這種開發(fā)方式繼承了瀑布式開發(fā)模式的優(yōu)點――全面、嚴謹、有計劃性、易管理，更重要的是，這種模式將測試工作分布到每個迭代周期中，使測試工作提前進行，從而使將發(fā)現軟件缺陷的周期提前，大大降低軟件風險及開發(fā)成本。

　　測試過程的衡量

　　測試過程在不斷地改進，但效果如何，如何來衡量測試的效果呢？我們需要引入一把尺子，一個度量標準，這樣才能把握測試過程的改進方向。那么，怎樣來收集數據，如何來度量？這是我們長久以來一直困惑的地方。

　　我們不妨借助“他山之石”來想想辦法，CMMI是當今國際流行的軟件過程衡量模型，它在這方面是有自己的獨到之處的：

　　1、 面向全局。CMMI的測試度量面向的不僅僅是測試過程的改進，測試效果的加強，它面向的是整個開發(fā)過程，并始終將質量監(jiān)督放在工作首位。比如，它度量工作產品規(guī)模（例如代碼行數），度量工作量和成本（例如人工小時數）。我們從中搜集的數據對整個開發(fā)過程的改進都有指導作用。更高的起點可使我們避免項目管理改進過程中常見的“頭痛醫(yī)頭、腳痛醫(yī)腳”毛病。

　　2、 建立度量數據庫，從而對搜集的數據、分析的方式及結果進行完整、規(guī)范的保存。這個數據庫面向的是軟件開發(fā)過程的持續(xù)改進，它的數據是可復用的，可供多個項目參考使用，不隨當前項目的結束而消失，而是會作為歷史信息持續(xù)保存，從而為測試及其他軟件過程的改進提供更客觀、更全面的度量數據。

　　3、 關注度量、分析過程的改進。度量過程是為了對測試及其他軟件過程的改進提供參考依據，它自身運作方式的合理性直接會影響度量結果的準確性。CMMI避免了“燈下黑”現象的出現，它沒有忽略測量分析度量過程的改進，它會定期召集受影響的受益者一起審查初始分析結果，總結本過程運作中遇到的經驗教訓，從而對度量過程方式進行改進，保證度量結果的正確性，可參考性。

　　CMMI度量方式的優(yōu)點往往是我們所忽略的，我們應盡力學習它的這些長處，這對軟件測試過程的改進會很有幫助。

　　結束語

　　測試很重要，它是檢驗開發(fā)結果是否接近預期目標的重要手段，但我們應清楚地認識到：它畢竟只是一種信息反饋過程，作為軟件質量的守護者，它可以發(fā)現缺陷，但無法避免缺陷的發(fā)生，我們不能將軟件質量的安危都押在測試這個砝碼上。

　　曾看過一個比喻，還記憶猶新，它將軟件開發(fā)比喻成制作一桌盛宴，項目經理比作大廚，測試人員比作品嘗師，用戶則比作就餐者。為保障飯菜質量，上菜之前，先由品嘗師對滿桌的半成品、準成品逐個品嘗，發(fā)現不足的地方要及時通知大廚進行改進，完善質量，直至品嘗師覺得：全部的飯菜已經色、香、味俱佳，滿足用戶要求了，才通過審查，允許飯菜上桌，供就餐者品嘗。我想說的是：飯菜質量靠品嘗師的監(jiān)督，但主要靠的是大廚的技術，同理，軟件的質量則是靠各個項目管理過程的互相配合及項目經理的整體控制和把握，測試只是其中的一份子。所以，請不要將軟件的質量都交給測試過程來承擔，那樣將是“生命不能承受之重”。