本文的目的不是將軟件測(cè)試流程優(yōu)化的話題闡述的面面俱到，而是從管理角度談?wù)劀y(cè)試用例在測(cè)試活動(dòng)中的重要性，以及測(cè)試用例管理流程的一些改進(jìn)思路。
    常聞軟件測(cè)試者的如此抱怨：
    測(cè)試用例在實(shí)際中根本沒(méi)有起多大作用？
    測(cè)試人員在實(shí)際測(cè)試時(shí)都沒(méi)有按測(cè)試用例來(lái)執(zhí)行？
    測(cè)試執(zhí)行后沒(méi)有把需要更新的測(cè)試用例補(bǔ)充到用例庫(kù)中？
    …… 　　

    當(dāng)前國(guó)內(nèi)軟件企業(yè)測(cè)試流程不規(guī)范的原因分析：
    1） 從事物的發(fā)展規(guī)律看，軟件測(cè)試行業(yè)在我國(guó)還是新興行業(yè)，目前還處于起步和探索期，雖然國(guó)外的同行業(yè)發(fā)展到了一定階段，但事實(shí)上他們也在不斷的否定自我并探索著更成熟的方法、尋求著更有效的方案；而國(guó)內(nèi)的測(cè)試行業(yè)發(fā)展期不過(guò)10來(lái)年，所謂的測(cè)試管理流程不規(guī)范，也就情有可原了。

    2） 從企業(yè)個(gè)體角度講，測(cè)試部門(mén)的整頓和加強(qiáng)，按照企業(yè)自身發(fā)展的優(yōu)先層次，還沒(méi)有被納入優(yōu)先解決的程度，開(kāi)拓市場(chǎng)、簽訂定單才是首要問(wèn)題，也是維系企業(yè)生存發(fā)展的命脈。當(dāng)然國(guó)內(nèi)很多的大中型軟件公司的測(cè)試部門(mén)相對(duì)完善，如神州數(shù)碼、用友、聯(lián)想等，他們和大型跨國(guó)軟件公司的合作，也從中汲取了寶貴的管理經(jīng)驗(yàn)。

    3） 還有一個(gè)普遍存在的問(wèn)題。近幾年國(guó)內(nèi)軟件企業(yè)為了加強(qiáng)企業(yè)的競(jìng)爭(zhēng)優(yōu)勢(shì)和名氣提升，通常大搞特ISO/CMM認(rèn)證；筆者也很支持這么做，但更關(guān)注的是通過(guò)這些認(rèn)證后的企業(yè)有多少真正按照那些規(guī)范、設(shè)計(jì)的標(biāo)準(zhǔn)在后續(xù)的測(cè)試或軟件開(kāi)發(fā)管理工作中著手開(kāi)展下去呢？社會(huì)上流傳著這樣的話：任何認(rèn)證到中國(guó)，都免不了砸牌兒！筆者讀書(shū)時(shí)很多高校搞的MCSE認(rèn)證，有培訓(xùn)機(jī)構(gòu)明目張膽聲稱"百分百通過(guò)率"！當(dāng)年也有專門(mén)媒體報(bào)道此事。聽(tīng)到這樣的話，我們都會(huì)寒心，這里真心希望我們的軟件企業(yè)通過(guò)ISO/CMM后真正為企業(yè)的內(nèi)部軟件開(kāi)發(fā)流程帶來(lái)一點(diǎn)新生的曙光。

    4） 一個(gè)原因，我想是企業(yè)內(nèi)部測(cè)試管理人員和技術(shù)人員技能的不足，還有自身工作態(tài)度的不夠端正。有了再好的規(guī)范標(biāo)準(zhǔn)，沒(méi)人遵守不行！沒(méi)人實(shí)施不行！應(yīng)該說(shuō)，很多中小軟件企業(yè)的高層都或多或少的逐漸意識(shí)到軟件測(cè)試的重要性和必要性，以及它的標(biāo)準(zhǔn)化、流程化改革的緊迫性，但也有很多的工程師、技術(shù)人員并不理會(huì)這套，常常在實(shí)際工作中投機(jī)取巧；也有很多測(cè)試管理人員后天的經(jīng)驗(yàn)不足、技能不夠，對(duì)公司測(cè)試管理工作考慮不到位，和開(kāi)發(fā)工程師交流不充分，和上層領(lǐng)導(dǎo)反映不及時(shí)等等。

    總之，任何問(wèn)題的出現(xiàn)都不是單方面的原因，從宏觀的社會(huì)形勢(shì)到微觀的企業(yè)個(gè)人，都有無(wú)可推卸的責(zé)任；正因?yàn)槿绱耍鉀Q問(wèn)題也要對(duì)癥下藥，如何完善軟件測(cè)試流程，就要從小處出發(fā)；本文不可能將軟件測(cè)試流程優(yōu)化的話題闡述的面面俱到，因此只從管理角度談?wù)劀y(cè)試用例在測(cè)試活動(dòng)中的重要性，以及測(cè)試用例管理流程的一些改進(jìn)思路。

    強(qiáng)化測(cè)試用例在測(cè)試活動(dòng)中的作用
    測(cè)試用例在實(shí)際中沒(méi)有起多大作用,在實(shí)際測(cè)試時(shí)根本沒(méi)有按測(cè)試用例執(zhí)行，測(cè)試執(zhí)行后沒(méi)有把新的測(cè)試用例補(bǔ)充到用例庫(kù)中……為何如此？我們分析認(rèn)為，根本原因是對(duì)測(cè)試用例重要性的認(rèn)識(shí)不夠，測(cè)試流程不完善，針對(duì)測(cè)試用例的管理流程更不完善，從三個(gè)方面具體來(lái)說(shuō)：

    1） 測(cè)試用例的重要性是毋庸置疑的，它是軟件測(cè)試全部過(guò)程的核心，是測(cè)試執(zhí)行環(huán)節(jié)的基本依據(jù)，如果這個(gè)依據(jù)不能足夠發(fā)揮它應(yīng)起的作用，那是不是說(shuō)這個(gè)依據(jù)不明確、依據(jù)設(shè)計(jì)的不合理呢？答案是肯定的！

    2） 制定了完備有效的測(cè)試用例，為什么不按測(cè)試用例執(zhí)行測(cè)試呢？首先是因?yàn)槠髽I(yè)沒(méi)有嚴(yán)格和良好的機(jī)制促使和保證測(cè)試執(zhí)行者這樣做；其次是個(gè)別測(cè)試人員投機(jī)取巧心理作祟的表現(xiàn)。

    3） 測(cè)試用例設(shè)計(jì)得不可能天衣無(wú)縫，不可能完全滿足軟件需求的覆蓋要求，測(cè)試執(zhí)行過(guò)程里肯定會(huì)發(fā)現(xiàn)有些測(cè)試路徑或數(shù)據(jù)在用例里沒(méi)有體現(xiàn)，那么事后該將其補(bǔ)充到用例庫(kù)里，以方便他人和后續(xù)版本的測(cè)試；如果沒(méi)有這樣做，那么測(cè)試部門(mén)負(fù)責(zé)人和每個(gè)測(cè)試員都難辭其疚，是該重新坐下來(lái)思考一下公司的測(cè)試用例管理規(guī)范和測(cè)試流程了。

    改進(jìn)測(cè)試用例執(zhí)行過(guò)程
    那么究竟如何做，才能盡量避免上述問(wèn)題呢？我們不妨從軟件開(kāi)發(fā)周期的每個(gè)階段就把這些問(wèn)題考慮進(jìn)去，以便從初始就力爭(zhēng)將問(wèn)題縮到小，將其扼殺在萌芽階段，以防后期階段出現(xiàn)問(wèn)題時(shí)互相推卸責(zé)任或干脆束手無(wú)策！

    1） 軟件需求分析階段，筆者從來(lái)認(rèn)為測(cè)試人員從軟件生命周期的需求階段就開(kāi)始介入。通常測(cè)試人員的測(cè)試工作開(kāi)展在開(kāi)發(fā)周期的末尾，如果前期不涉入，如何通曉整個(gè)系統(tǒng)的需求和架構(gòu)而對(duì)其充分測(cè)試呢？雖然該觀點(diǎn)被大多數(shù)同行所認(rèn)可，但我知道依然有很多公司為了節(jié)省費(fèi)用，不讓測(cè)試人員參與前期調(diào)研或制定需求，經(jīng)常的做法是等到系統(tǒng)開(kāi)發(fā)完畢或?qū)⒔瓿桑鷾y(cè)試經(jīng)理說(shuō)一聲"這邊有個(gè)項(xiàng)目，你找?guī)讉€(gè)人來(lái)測(cè)試一下吧！"經(jīng)驗(yàn)表明，這樣的做法實(shí)不可取。

    測(cè)試人員（指項(xiàng)目的測(cè)試負(fù)責(zé)人和測(cè)試工程師）在需求階段的任務(wù)有：
    參與軟件需求調(diào)研，以測(cè)試角度分析需求的可測(cè)性，可構(gòu)思將來(lái)對(duì)其測(cè)試的方法、原則等；更重要的是，對(duì)不可測(cè)或難以測(cè)試性問(wèn)題要及時(shí)與客戶或項(xiàng)目經(jīng)理協(xié)調(diào)解決。

    全面了解系統(tǒng)需求，從客戶角度考慮軟件測(cè)試需要達(dá)到的驗(yàn)證狀態(tài)，即何些功能點(diǎn)需重點(diǎn)測(cè)試、何些無(wú)需，以便將來(lái)制定測(cè)試計(jì)劃。

    推薦企業(yè)采用類似于IBM Rational Requisitepro的需求管理工具來(lái)制定和管理軟件需求，同時(shí)需要測(cè)試人員的配合，保證對(duì)軟件測(cè)試環(huán)節(jié)的充分考慮。

    2） 軟件分析設(shè)計(jì)階段，測(cè)試人員除制定測(cè)試計(jì)劃書(shū)等基本工作外，筆者認(rèn)為還有一個(gè)相當(dāng)必要的任務(wù)，那就是將系統(tǒng)的可測(cè)性落實(shí)到書(shū)面文檔，以備將來(lái)編寫(xiě)測(cè)試用例。

    之所以要這么做，是因?yàn)榭紤]到很多企業(yè)編寫(xiě)測(cè)試用例直接參考需求規(guī)格說(shuō)明書(shū)或者分析流程圖，這樣跨度大，難度也大，是造成測(cè)試用例不完備、覆蓋范圍小的重要原因。

    如果公司采用類似于IBM Rational Rose的建模分析工具和IBM Rational Rose XDE Developer的可視化設(shè)計(jì)開(kāi)發(fā)環(huán)境，這個(gè)工作更好執(zhí)行；如果沒(méi)有，那么測(cè)試人員更有必要編寫(xiě)一份《軟件功能點(diǎn)測(cè)試描述書(shū)》，它是軟件的詳細(xì)測(cè)試分析文檔，其主旨是將系統(tǒng)分析人員的開(kāi)發(fā)分析文檔加工成以測(cè)試為角度的功能點(diǎn)分析文檔，重要的是描述對(duì)系統(tǒng)分解后每個(gè)功能點(diǎn)逐一的校驗(yàn)描述，包括何種方法測(cè)試、何種數(shù)據(jù)測(cè)試、期望測(cè)試結(jié)果等，這些信息都是描述性的，無(wú)須具體數(shù)據(jù)；它的作用是據(jù)此編寫(xiě)測(cè)試用例，以及測(cè)試執(zhí)行時(shí)的參考依據(jù)，基于它直接來(lái)源于需求，覆蓋當(dāng)然全，也能貼近客戶要求。

    當(dāng)然該文檔不是非要不可，筆者只是提倡一種原則，如果有類似的替代文檔或有工具可自動(dòng)實(shí)現(xiàn)此功能，則會(huì)倍加受推崇！

    筆者之所以推薦IBM Rational系列產(chǎn)品在軟件項(xiàng)目中的應(yīng)用，是因?yàn)镮BM Rational倡導(dǎo)的RUP（Rational Unified Process）方法論采用了用例驅(qū)動(dòng)的原則。所謂用例驅(qū)動(dòng)，是以體系結(jié)構(gòu)為中心，采用迭代、增量方式的開(kāi)發(fā)過(guò)程；而其Rational工具系列正是將這一理念進(jìn)行行為表述，是當(dāng)前軟件工程領(lǐng)域一套無(wú)可比擬的強(qiáng)大工具集，從需求到測(cè)試，它都以用例為基本模型，全面貫穿軟件開(kāi)發(fā)的每個(gè)環(huán)節(jié)。

    3） 軟件開(kāi)發(fā)階段，編寫(xiě)測(cè)試用例。我不想從技術(shù)角度探討到底如何編寫(xiě)功能強(qiáng)大、質(zhì)量的測(cè)試用例（可參考筆者主頁(yè)轉(zhuǎn)載的"如何設(shè)計(jì)編寫(xiě)軟件測(cè)試用例"），這里只想從管理角度和大家談?wù)勅绾斡行Э刂坪驮鰪?qiáng)測(cè)試用例在測(cè)試活動(dòng)中的應(yīng)用。應(yīng)該遵守的原則是：

    首先，從覆蓋率來(lái)說(shuō)，測(cè)試用例庫(kù)的用例要達(dá)到覆蓋軟件系統(tǒng)的功能點(diǎn)。按照我上述所言的方式，測(cè)試工程師從前期階段順次下來(lái)，編寫(xiě)測(cè)試用例時(shí)，基本上就是將《軟件功能點(diǎn)測(cè)試描述書(shū)》中的每個(gè)功能點(diǎn)進(jìn)行操作上的細(xì)化：一是從步驟上描述到達(dá)校驗(yàn)點(diǎn)的方式，二是從內(nèi)容上描述以何種數(shù)據(jù)校驗(yàn)功能點(diǎn)；如此可實(shí)現(xiàn)趨向需求覆蓋率。

    其次，從數(shù)量來(lái)講，筆者覺(jué)得很多公司的測(cè)試用例太少，甚至遠(yuǎn)遠(yuǎn)不能覆蓋系統(tǒng)需求，這也是很多測(cè)試人員在測(cè)試工作開(kāi)展初期按照用例執(zhí)行、而后漸漸憑"意念"去執(zhí)行測(cè)試的原因。應(yīng)該說(shuō)測(cè)試用例的數(shù)量很難用數(shù)學(xué)模型來(lái)模擬，更沒(méi)辦法衡量，但憑借個(gè)人經(jīng)驗(yàn)來(lái)說(shuō)，一個(gè)多于半年開(kāi)發(fā)周期（指從編碼開(kāi)始直到提交客戶的時(shí)間段）的軟件系統(tǒng)，它的用例數(shù)量不要低于4000個(gè)，甚至更多！也許有人驚訝這一數(shù)字，不過(guò)了解IBM等大公司測(cè)試過(guò)程的人士會(huì)認(rèn)為4000還是很少的數(shù)目。我們?cè)囅耄瑢?duì)于一個(gè)中小型軟件系統(tǒng)，如果設(shè)計(jì)出5000個(gè)用例，那它的測(cè)試覆蓋率還怕不高么！

    再次，如此眾多測(cè)試用例的管理問(wèn)題。是的，需要管理工具軟件！筆者從來(lái)都反對(duì)以word或excel來(lái)編寫(xiě)測(cè)試用例：格式上難于編寫(xiě)--通常方式是企業(yè)自己設(shè)計(jì)表格模版，但編輯上始終存在不便，尤其對(duì)于一些共性內(nèi)容，如測(cè)試目標(biāo)、測(cè)試環(huán)境、參考說(shuō)明等，每次都要大量的復(fù)制、粘貼。

    其次難于管理--如果把幾千個(gè)文檔文件放在一個(gè)共享文件夾里，即便以子目錄方式管理，但是每次查找一個(gè)特定用例，你的眼睛也必將飽受煎熬！

    更是難于執(zhí)行--莫非真要針對(duì)幾千個(gè)用例都是打開(kāi)一個(gè)word-執(zhí)行測(cè)試-輸入測(cè)試結(jié)果-關(guān)閉word嗎？

    重要的是，根本沒(méi)辦法追蹤測(cè)試結(jié)果--在本輪回歸測(cè)試輸入完測(cè)試結(jié)果，但是下一輪結(jié)果輸入到哪里？輸入了這些測(cè)試結(jié)果什么用？能方便的根據(jù)其結(jié)果統(tǒng)計(jì)軟件質(zhì)量嗎？還有，可以用它追蹤發(fā)現(xiàn)的軟件缺陷嗎？有辦法追蹤嗎？

    使用word等軟件編寫(xiě)測(cè)試用例的種種不便大致如上，但換個(gè)思路思考一下使用集成工具的種種優(yōu)勢(shì)便更加一見(jiàn)分曉。測(cè)試同業(yè)者們都了解的測(cè)試用例管理工具便是IBM Rational TestManager，它是專業(yè)的測(cè)試用例管理和測(cè)試管理工具，其設(shè)計(jì)出發(fā)點(diǎn)就已經(jīng)考慮到了我們上述的種種困境，因此給予了良好的解決方案。以其為測(cè)試管理平臺(tái)，測(cè)試人團(tuán)隊(duì)成員可以計(jì)劃、管理、組織、執(zhí)行、評(píng)詁以及報(bào)告等縱向測(cè)試活動(dòng)，如果與IBM Rational Clearquest集成使用，還可即時(shí)跟蹤軟件的需求變更，從而增強(qiáng)整個(gè)軟件團(tuán)隊(duì)的橫向溝通與合作。

    而且，個(gè)人覺(jué)得測(cè)試行業(yè)的快速發(fā)展，必將帶來(lái)從每個(gè)環(huán)節(jié)都逐漸向自動(dòng)化和標(biāo)準(zhǔn)化方向邁進(jìn)，盡早適應(yīng)這一趨勢(shì)，不僅提高了工作效率，也提高了企業(yè)的信譽(yù)和名譽(yù)。

    ，說(shuō)一下測(cè)試用例格式上一般內(nèi)容以外的幾個(gè)要點(diǎn)：
    一是在測(cè)試管理工具中制定適合本公司的測(cè)試用例模版
    二是用例模版里要有關(guān)鍵字索引，以方便按關(guān)鍵字分類查找，如測(cè)試方法（分手工/自動(dòng)兩種）
    三是測(cè)試用例要有狀態(tài)跟蹤，可根據(jù)用例執(zhí)行狀態(tài)索引用例（測(cè)試通過(guò)、測(cè)試失敗、測(cè)試中斷等）
    四是執(zhí)行失敗的用例要鏈接到相應(yīng)的缺陷報(bào)告，如有根據(jù)缺陷報(bào)告檢索測(cè)試用例的試圖更妙，可評(píng)估該缺陷影響范圍的大小
    五是測(cè)試用例的修改，以及每個(gè)測(cè)試周期的運(yùn)行都有日志記錄，以便后期追蹤和新員工參考。

    4） 軟件測(cè)試階段，測(cè)試負(fù)責(zé)人劃分不同的測(cè)試階段（如集成測(cè)試、系統(tǒng)測(cè)試、回歸測(cè)試、性能測(cè)試等），再劃分不同的子測(cè)試周期（如前兩個(gè)星期做冒煙測(cè)試，測(cè)試方式是手工/自動(dòng)，測(cè)試版本是**，測(cè)試環(huán)境是**，包括服務(wù)器端與客戶端等；接著做模塊功能測(cè)試；如此順次。），再為項(xiàng)目組測(cè)試人員分配測(cè)試用例（通常原則是每個(gè)人負(fù)責(zé)幾塊區(qū)域的測(cè)試任務(wù)），測(cè)試人員則按照詳細(xì)的用例文檔去執(zhí)行測(cè)試，測(cè)試失敗則提交軟件缺陷報(bào)告。這里要遵循的幾個(gè)原則是：

    A）有健全且嚴(yán)格的體制保證測(cè)試執(zhí)行者嚴(yán)格按照測(cè)試用例執(zhí)行測(cè)試。這并不妨礙測(cè)試者創(chuàng)造力的發(fā)揮，因?yàn)榍捌谟美脑O(shè)計(jì)和編寫(xiě)就是項(xiàng)目全體測(cè)試人員智慧的結(jié)晶！我們一直苦苦追尋眾多測(cè)試工程師加班加點(diǎn)辛苦工作的原因，其實(shí)大都發(fā)生這一階段；如此實(shí)施，即便沒(méi)有解決根本問(wèn)題，也會(huì)大大提高測(cè)試執(zhí)行效率。

    B）如有對(duì)測(cè)試用例認(rèn)識(shí)模糊或內(nèi)容遺漏的地方，可暫做記錄待后期解決，或經(jīng)測(cè)試負(fù)責(zé)人與項(xiàng)目其他管理人員同意方可更新用例庫(kù)。

    C）測(cè)試負(fù)責(zé)人每日負(fù)責(zé)跟蹤本測(cè)試子周期或階段的測(cè)試用例執(zhí)行情況，以及每日提交的缺陷報(bào)告，根據(jù)執(zhí)行進(jìn)展?fàn)顟B(tài)以及缺陷數(shù)量或嚴(yán)重等級(jí)與項(xiàng)目高層或其他人員展開(kāi)交流，商議解決途徑，并確定或調(diào)整未來(lái)時(shí)間的測(cè)試任務(wù)。

    D）測(cè)試執(zhí)行者負(fù)責(zé)執(zhí)行自己區(qū)域的測(cè)試用例，還要負(fù)責(zé)跟蹤該區(qū)域軟件缺陷的修改進(jìn)展，根據(jù)其狀態(tài)不斷驗(yàn)證軟件功能點(diǎn)。

    E）應(yīng)該提及的是，大多數(shù)軟件公司都采用集成的缺陷管理工具來(lái)管理軟件缺陷，如IBM Rational ClearQuest（變更管理與缺陷管理工具）等，這是值得稱頌的好跡象；這樣的集成工具都提供了清晰的報(bào)告模版及強(qiáng)大的追蹤功能，測(cè)試團(tuán)隊(duì)的每一成員按照自己的角色和權(quán)限訪問(wèn)缺陷管理工具，并不斷跟蹤軟件缺陷的狀態(tài)。

    F）對(duì)于自動(dòng)測(cè)試（包括自動(dòng)化功能測(cè)試和性能、壓力測(cè)試），有一些特殊要點(diǎn)。本人的原則是自動(dòng)化測(cè)試無(wú)須編寫(xiě)測(cè)試用例，只要在編寫(xiě)時(shí)將用例庫(kù)里適合或需要自動(dòng)測(cè)試的用例的測(cè)試方法（不同工具可能名稱不同）設(shè)為自動(dòng)即可，故而到此階段才提及自動(dòng)化測(cè)試。自動(dòng)化測(cè)試的實(shí)施方案有所不同，每款測(cè)試工具的使用和測(cè)試流程也不同，但都可以從在這一階段編寫(xiě)測(cè)試腳本，并運(yùn)行自動(dòng)測(cè)試。例如IBM Rational Robot（參考官方說(shuō)明http://www-900.ibm.com/cn/software/rational/products/robot/index.shtml）或XDE Tester（http://www-900.ibm.com/cn/software/rational/products/xde_tester/index.shtml，現(xiàn)更名為Rational Functional Tester）。針對(duì)自動(dòng)化測(cè)試原則，可參閱筆者的"自動(dòng)化測(cè)試要點(diǎn)"譯文，這里要提的其他幾個(gè)基本原則是：

    一是選擇恰當(dāng)?shù)臏y(cè)試工具品牌，并要求提供培訓(xùn)；
    二是項(xiàng)目的自動(dòng)化測(cè)試工作有專人負(fù)責(zé)跟蹤，以保證工作質(zhì)量，他們可不參與日常測(cè)試；
    三是確定自動(dòng)化測(cè)試成員在項(xiàng)目中的角色，一般自動(dòng)化測(cè)試成員隸屬于項(xiàng)目測(cè)試負(fù)責(zé)人，負(fù)責(zé)人同樣跟蹤其工作狀態(tài)；
    四是選擇簡(jiǎn)單、重用的測(cè)試用例使用自動(dòng)測(cè)試方法；

    五是使用工具廠商提供的測(cè)試框架編寫(xiě)腳本，千萬(wàn)別采用單純錄制-加校驗(yàn)點(diǎn)-回放的方式，以開(kāi)發(fā)出健壯且重用性強(qiáng)的測(cè)試腳本；
    六是有專人更新腳本，也有專人跟蹤自動(dòng)測(cè)試結(jié)果；
    七是一般選擇的測(cè)試工具品牌和缺陷管理工具品牌是同一廠商，以方便不同類型缺陷的集中管理；

    八是在多人協(xié)作開(kāi)發(fā)測(cè)試腳本、代碼量相對(duì)較大情況下，應(yīng)考慮使用配置管理工具來(lái)管理測(cè)試腳本，IBM Rational ClearCase是當(dāng)前業(yè)界功能強(qiáng)大的配置管理工具，可以將開(kāi)發(fā)代碼和測(cè)試代碼都集中管理，進(jìn)行高效的版本控制和工作空間管理，保證多人開(kāi)發(fā)大量代碼的穩(wěn)定性。對(duì)于局域網(wǎng)范圍內(nèi)的開(kāi)發(fā)工作，使用ClearCase LT版足夠。

    G），由于不同公司開(kāi)發(fā)產(chǎn)品的特殊性，也許需要特殊類型的測(cè)試，如安全測(cè)試、甚至代碼級(jí)單元測(cè)試等，這些內(nèi)容需要酌情考慮測(cè)試用例的編寫(xiě)，以及測(cè)試的執(zhí)行。

    5） 軟件驗(yàn)收階段，除了提交軟件測(cè)試評(píng)估報(bào)告（各種類型測(cè)試結(jié)果的評(píng)估都應(yīng)有報(bào)告）這些基本工作外，對(duì)于測(cè)試用例，此時(shí)要集中時(shí)間更新，更新整個(gè)測(cè)試周期中一切需要更新的內(nèi)容，以方便未來(lái)新版本的測(cè)試。即便您開(kāi)發(fā)的是項(xiàng)目軟件--提交客戶后沒(méi)有新版本--那也需要后期維護(hù)，維護(hù)階段需要重新測(cè)試某功能點(diǎn)，然而用例如果不準(zhǔn)確，碰巧又是一個(gè)新員工來(lái)做，那就死翹翹了！

    退一步說(shuō)，如果您公司的測(cè)試部門(mén)經(jīng)歷一次這樣重大的洗禮，有一個(gè)項(xiàng)目真正按照此原則實(shí)施一次，也必將對(duì)未來(lái)測(cè)試工作的開(kāi)展發(fā)揮推波助瀾的作用、起到事半功倍的效果。

    6） 其他說(shuō)明：加強(qiáng)測(cè)試部門(mén)內(nèi)部人員的培訓(xùn)教育很重要，包括工作技能與個(gè)人素質(zhì)兩方面，可通過(guò)國(guó)內(nèi)主要的培訓(xùn)機(jī)構(gòu)，也可是購(gòu)買(mǎi)工具廠商的直接培訓(xùn)。應(yīng)該說(shuō)，很多測(cè)試新人對(duì)于測(cè)試用例的書(shū)寫(xiě)還存在問(wèn)題，更別提及測(cè)試用例的管理或執(zhí)行；以此可見(jiàn)，我們的測(cè)試工程師需要培訓(xùn)的空間還很大。

    另外，筆者不贊成對(duì)人員的強(qiáng)制性管理，例如大張旗鼓整頓公司測(cè)試部門(mén)的管理，采取缺陷報(bào)告數(shù)和人員績(jī)效掛鉤、不按測(cè)試規(guī)范執(zhí)行就適當(dāng)懲罰等手段；個(gè)人認(rèn)為切不可急功近利，當(dāng)以人為本，鼓勵(lì)+促進(jìn)甚善然、甚妙哉！

    總結(jié)
    綜上所述，我們得出結(jié)論-- 測(cè)試用例在測(cè)試中沒(méi)起到應(yīng)有的作用，是因?yàn)闇y(cè)試用例編寫(xiě)質(zhì)量不高，覆蓋不夠，執(zhí)行不利；測(cè)試執(zhí)行時(shí)不遵循測(cè)試用例，執(zhí)行后不更新用例庫(kù)，是測(cè)試部門(mén)的整體工作流程不健全、不規(guī)范；至于如何解決，筆者提出了微薄建議，供業(yè)界朋友參考與交流。

    國(guó)內(nèi)軟件測(cè)試行業(yè)目前仍處在群雄逐鹿、百家爭(zhēng)鳴的時(shí)期，蕓蕓紛說(shuō)，不如從企業(yè)自身出發(fā)，確立適合自我的測(cè)試管理解決方案，整頓自身的測(cè)試工作流程，那才是金玉良言的上上策！