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

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

　　6、 測試人員素質(zhì)低，缺乏相關(guān)知識(shí)培訓(xùn)

　　項(xiàng)目管理人員對(duì)測試存有偏見，對(duì)于測試的重要性認(rèn)識(shí)不足，導(dǎo)致其嚴(yán)重忽略測試人員的選拔和知識(shí)培訓(xùn)。許多軟件項(xiàng)目讓軟件用戶或新招收的技術(shù)人員來完成測試工作，他們認(rèn)為測試人員的工作很簡單，就是技術(shù)人員讓測什么就測什么，它基本是一個(gè)動(dòng)手不動(dòng)腦的工作。

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

　　其實(shí)，軟件工程對(duì)測試人員的素質(zhì)要求是很嚴(yán)格的，比如：要有相關(guān)計(jì)算機(jī)知識(shí)背景、具備軟件工程基本知識(shí)、熟悉項(xiàng)目編程語言、熟悉項(xiàng)目技術(shù)架構(gòu)及需求內(nèi)容、工作有責(zé)任感、獨(dú)立分析能力及團(tuán)隊(duì)精神等等。真正規(guī)范的軟件項(xiàng)目對(duì)于測試人員的要求是不會(huì)低于技術(shù)人員的，而且會(huì)為測試人員提供進(jìn)一步的知識(shí)培訓(xùn)機(jī)會(huì)，以應(yīng)對(duì)各種項(xiàng)目的復(fù)雜情況。

　　7、 測試進(jìn)度的錯(cuò)誤估算

　　在項(xiàng)目開發(fā)中，領(lǐng)導(dǎo)為督促測試的進(jìn)程，往往會(huì)讓項(xiàng)目組匯報(bào)工作進(jìn)度，了解已經(jīng)完成的工作占比，從而對(duì)工作進(jìn)度做出判斷。我對(duì)這種工作方式完全擁護(hù)，只是覺得這種方式還有不足。

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

　　所以，沒有對(duì)測試對(duì)象認(rèn)真分析的基礎(chǔ)，單憑工作完成數(shù)量而對(duì)工作進(jìn)度做出的的判斷往往是錯(cuò)誤的。

　　 我認(rèn)為，“工作實(shí)際進(jìn)度＝工作完成量占比＋測試對(duì)象的錯(cuò)誤占比分析”才是一個(gè)較合理的測試進(jìn)度估算方式。

　　測試新思路

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

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

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

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

　　 隨著迭代周期的累進(jìn)，測試工作內(nèi)容隨之不斷變化。早期迭代測試重點(diǎn)在于新功能的測試，后期迭代測試重點(diǎn)在于累積功能的回歸測試。

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

　　測試過程的衡量

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

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

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

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

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

　　CMMI度量方式的優(yōu)點(diǎn)往往是我們所忽略的，我們應(yīng)盡力學(xué)習(xí)它的這些長處，這對(duì)軟件測試過程的改進(jìn)會(huì)很有幫助。

　　結(jié)束語

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

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