測試用例設(shè)計(jì)問題報(bào)告

軟件測試提交的問題報(bào)告單和測試日報(bào)一樣，都是軟件測試人員的工作輸出，是測試人員績效的集中體現(xiàn)。因此，提交一份優(yōu)秀的問題報(bào)告單是很重要的。軟件測試報(bào)告單最關(guān)鍵的域就是 “ 問題描述 ” ，這是開發(fā)人員重現(xiàn)問題，定位問題的依據(jù)。問題描述應(yīng)該包括以下幾部分內(nèi)容：軟件配置、硬件配置、測試用例輸入、操作步驟、輸出、當(dāng)時輸出設(shè)備的相關(guān)輸出信息和相關(guān)的日志等。

測試用例設(shè)計(jì)軟件配置

包括操作系統(tǒng)類型版本和補(bǔ)丁版本、當(dāng)前被測試軟件的版本和補(bǔ)丁版本、相關(guān)支撐軟件，比如數(shù)據(jù)庫軟件的版本和補(bǔ)丁版本等。

測試用例設(shè)計(jì)硬件配置

計(jì)算機(jī)的配置情況，主要包括 CPU 、內(nèi)存和硬盤的相關(guān)參數(shù)，其它硬件參數(shù)根據(jù)測試用例的實(shí)際情況添加。如果測試中使用網(wǎng)絡(luò)，那么網(wǎng)絡(luò)的組網(wǎng)情況，網(wǎng)絡(luò)的容量、流量等情況。硬件配置情況與被測試產(chǎn)品類型密切相關(guān)，需要根據(jù)當(dāng)時的情況，準(zhǔn)確詳實(shí)的記錄硬件配置情況。

測試用例設(shè)計(jì)輸出

這部分內(nèi)容可以根據(jù)測試用例的描述和測試用例的實(shí)際執(zhí)行情況如實(shí)填寫。

測試用例設(shè)計(jì)相關(guān)輸出信息

輸出設(shè)備包括計(jì)算機(jī)顯示器、打印機(jī)、磁帶等等輸出設(shè)備，如果是顯示器可以采用抓屏的方式獲取當(dāng)時的截圖，其他的輸出設(shè)備可以采用其它方法獲取相關(guān)的輸出，在問題報(bào)告單中提供描述。

測試用例設(shè)計(jì)日志信息

規(guī)范的軟件產(chǎn)品都會提供軟件的運(yùn)行日志和用戶、管理員的操作日志，測試人員應(yīng)該把測試用例執(zhí)行后的軟件產(chǎn)品運(yùn)行日志和操作日志作為附件，提交到問題報(bào)告單中。

根據(jù)被測試軟件產(chǎn)品的不同，需要在 “ 問題描述 ” 中增加相應(yīng)的描述內(nèi)容，這需要具體問題具體分析。

軟件測試用例

軟件測試用例的設(shè)計(jì)主要從上述 6 個域考慮，結(jié)合相應(yīng)的軟件需求文檔，在掌握一定測試用例設(shè)計(jì)方法的基礎(chǔ)上，可以設(shè)計(jì)出比較全面、合理的測試用例。具體的測試用例設(shè)計(jì)方法可以參見相關(guān)的測試書籍，白盒測試方法和黑盒測試方法在絕大多數(shù)的軟件測試書籍中都有詳細(xì)的介紹，這里不作贅述。

重用同類型

如果我看得遠(yuǎn)，那是因?yàn)槲艺驹诰奕说募缟?－－牛頓。

一般來說，每個軟件公司的項(xiàng)目可以分為固定的幾大類?？梢园礃I(yè)務(wù)類型劃分，比如 ERP 軟件、產(chǎn)品數(shù)據(jù)管理軟件、通信軟件、地理信息系統(tǒng)軟件等等；可以按軟件結(jié)構(gòu)來劃分，比如 B/S 架構(gòu)的軟件、 C/S 架構(gòu)的軟件、嵌入式軟件等等。參考同類別軟件的測試用例，會有很大的借鑒意義。如果，公司中有同類別的軟件系統(tǒng)，千萬別忘記把相關(guān)的測試用例拿來參考。如果，系統(tǒng)非常接近，甚至經(jīng)過對測試用例簡單修改就可以應(yīng)用到當(dāng)前被測試的軟件。 “ 拿來主義 ” 可以極大的開闊測試用例設(shè)計(jì)思路，也可以節(jié)省大量的測試用例設(shè)計(jì)時間。

利用已有的

在上面一個小節(jié)中，按照不同的規(guī)則劃分了不同的軟件類型。每種類型的軟件都有一定的測試規(guī)范，比如， WEB軟件系統(tǒng)在系統(tǒng)測試過程中，會有一系列的范式，比如針對 Cookie 就會有很多測試點(diǎn)。在設(shè)計(jì)測試用例的時候，不妨到網(wǎng)上去搜索相關(guān)的 Checklist ，不過國內(nèi)外的網(wǎng)站很少有這方面的資料，即便有，也不是特別系統(tǒng)?？梢韵日乙环荽植诘?Checklist ，然后，在設(shè)計(jì)測試用例的時候不斷的去完善它，以作為下次測試用例設(shè)計(jì)的基礎(chǔ)。

加強(qiáng)測試用例

測試用例設(shè)計(jì)完畢后，最好能夠增加評審過程。同行評審是 CMM3 級的一個 KPA ，如果因?yàn)楣緵]有通過 CMM3 級，就不開展同行評審是不恰當(dāng)?shù)?。測試用例應(yīng)該由產(chǎn)品相關(guān)的需求人員、軟件測試人員和軟件開發(fā)人員評審，提交評審意見，然后根據(jù)評審意見更新測試用例。 如果認(rèn)真操作這個環(huán)節(jié)，測試用例中的很多問題都會暴露出來，比如用例設(shè)計(jì)錯誤、用例設(shè)計(jì)遺漏、用例設(shè)計(jì)冗余、用例設(shè)計(jì)不充分等等；如果同行評審不充分，那么，在測試執(zhí)行的過程中，上述本應(yīng)在評審階段發(fā)現(xiàn)的測試用例相關(guān)問題，會給測試執(zhí)行帶來大麻煩，甚至導(dǎo)致測試執(zhí)行掛起。

定義測試用例

在測試用例執(zhí)行過程中，你會發(fā)現(xiàn)每個測試用例都對測試環(huán)境有特殊的要求，或者對測試環(huán)境有特殊的影響。因此，定義測試用例的執(zhí)行順序，對測試的執(zhí)行效率影響非常大。比如某些異常測試用例會導(dǎo)致服務(wù)器頻繁重新啟動，服務(wù)器的每次重新啟動都會消耗大量的時間，導(dǎo)致這部分測試用例執(zhí)行也消耗很多的時間。那么在編排測試用例執(zhí)行順序的時候，應(yīng)該考慮把這部分測試用例放在最后執(zhí)行，如果在測試進(jìn)度很緊張的情況下，如果優(yōu)先執(zhí)行這部分消耗時間的異常測試用例，那么在測試執(zhí)行時間過了大半的時候，測試用例執(zhí)行的進(jìn)度依然是緩慢的，這會影響到測試人員的心情，進(jìn)而導(dǎo)致匆忙地測試后面的測試用例，這樣測試用例的漏測、誤測就不可避免，嚴(yán)重影響了軟件測試效果和進(jìn)度。因而，合理地定義測試用例的執(zhí)行順序是很有必要的。

測試用例執(zhí)行

測試用例設(shè)計(jì)完畢后，接下來的工作是測試執(zhí)行，測試執(zhí)行中應(yīng)該注意以下幾個問題：

搭建軟件測試環(huán)境，執(zhí)行測試用例

測試用例執(zhí)行過程中，搭建測試環(huán)境是第一步。一般來說，軟件產(chǎn)品提交測試后，開發(fā)人員應(yīng)該提交一份產(chǎn)品安裝指導(dǎo)書，在指導(dǎo)書中詳細(xì)指明軟件產(chǎn)品運(yùn)行的軟硬件環(huán)境，比如要求操作系統(tǒng)系統(tǒng)是 Windows 2000 pack4 版本，數(shù)據(jù)庫是 Sql Server 2000 等等，此外，應(yīng)該給出被測試軟件產(chǎn)品的詳細(xì)安裝指導(dǎo)書，包括安裝的操作步驟、相關(guān)配置文件的配置方法等等。對于復(fù)雜的軟件產(chǎn)品，尤其是軟件項(xiàng)目，如果沒有安裝指導(dǎo)書作為參考，在搭建測試環(huán)境過程中會遇到種種問題。

如果開發(fā)人員拒絕提供相關(guān)的安裝指導(dǎo)書，搭建測試中遇到問題的時候，測試人員可以要求開發(fā)人員協(xié)助，這時候，一定要把開發(fā)人員解決問題的方法記錄下來，避免同樣的問題再次請教開發(fā)人員，這樣會招致開發(fā)人員的反感，也降低了開發(fā)人員對測試人員的認(rèn)可程度。

應(yīng)注意的問題

測試環(huán)境搭建之后，根據(jù)定義的測試用例執(zhí)行順序，逐個執(zhí)行測試用例。在測試執(zhí)行中需要注意以下幾個問題：

全方位的觀察測試用例執(zhí)行結(jié)果： 測試執(zhí)行過程中，當(dāng)測試的實(shí)際輸出結(jié)果與測試用例中的預(yù)期輸出結(jié)果一致的時候，是否可以認(rèn)為測試用例執(zhí)行成功了？答案是否定的，即便實(shí)際測試結(jié)果與測試的預(yù)期結(jié)果一致，也要查看軟件產(chǎn)品的操作日志、系統(tǒng)運(yùn)行日志和系統(tǒng)資源使用情況，來判斷測試用例是否執(zhí)行成功了。全方位觀察軟件產(chǎn)品的輸出可以發(fā)現(xiàn)很多隱蔽的問題。以前，我在測試嵌入式系統(tǒng)軟件的時候，執(zhí)行某測試用例后，測試用例的實(shí)際輸出與預(yù)期輸出完全一致，不過在查詢 CPU 占用率地時候，發(fā)現(xiàn) CPU 占用率高達(dá) 90 %，后來經(jīng)過分析，軟件運(yùn)行的時候啟動了若干個 1ms 的定時器，大量的消耗的 CPU 資源，后來通過把定時器調(diào)整到 10ms ， CPU 的占用率降為 7 %。如果觀察點(diǎn)單一，這個嚴(yán)重消耗資源的問題就無從發(fā)現(xiàn)了。

加強(qiáng)測試過程記錄： 測試執(zhí)行過程中，一定要加強(qiáng)測試過程記錄。如果測試執(zhí)行步驟與測試用例中描述的有差異，一定要記錄下來，作為日后更新測試用例的依據(jù)；如果軟件產(chǎn)品提供了日志功能，比如有軟件運(yùn)行日志、用戶操作日志，一定在每個測試用例執(zhí)行后記錄相關(guān)的日志文件，作為測試過程記錄，一旦日后發(fā)現(xiàn)問題，開發(fā)人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環(huán)境，為開發(fā)人員重現(xiàn)問題。

及時確認(rèn)發(fā)現(xiàn)的問題： 測試執(zhí)行過程中，如果確認(rèn)發(fā)現(xiàn)了軟件的缺陷，那么可以毫不猶豫的提交問題報(bào)告單。如果發(fā)現(xiàn)了可疑問題，又無法定位是否為軟件缺陷，那么一定要保留現(xiàn)場，然后知會相關(guān)開發(fā)人員到現(xiàn)場定位問題。如果開發(fā)人員在短時間內(nèi)可以確認(rèn)是否為軟件缺陷，測試人員給予配合；如果開發(fā)人員定位問題需要花費(fèi)很長的時間，測試人員千萬不要因此耽誤自己寶貴的測試執(zhí)行時間，可以讓開發(fā)人員記錄重現(xiàn)問題的測試環(huán)境配置，然后，回到自己的開發(fā)環(huán)境上重現(xiàn)問題，繼續(xù)定位問題。

與開發(fā)人員良好的溝通： 測試執(zhí)行過程中，當(dāng)你提交了問題報(bào)告單，可能被開發(fā)人員無情駁回，拒絕修改。這時候，只能對開發(fā)人員曉之以理，做到有理、有據(jù)，有說服力。首先，要定義軟件缺陷的標(biāo)準(zhǔn)原則，這個原則應(yīng)該是開發(fā)人員和測試人員都認(rèn)可的，如果沒有共同認(rèn)可的原則，那么開發(fā)人員與測試人員對問題的爭執(zhí)就不可避免了。此外，測試人員打算說服開發(fā)人員之前，考慮是否能夠先說服自己，在保證可以說服自己的前提下，再開始與開發(fā)人員交流。

及時更新測試

測試執(zhí)行過程中，應(yīng)該注意及時更新測試用例。往往在測試執(zhí)行過程中，才發(fā)現(xiàn)遺漏了一些測試用例，這時候應(yīng)該及時的補(bǔ)充；往往也會發(fā)現(xiàn)有些測試用例在具體的執(zhí)行過程中根本無法操作，這時候應(yīng)該刪除這部分用例；也會發(fā)現(xiàn)若干個冗余的測試用例完全可以由某一個測試用例替代，那么刪除冗余的測試用例。

總之，測試執(zhí)行的過程中及時地更新測試用例是很好的習(xí)慣。不要打算在測試執(zhí)行結(jié)束后，統(tǒng)一更新測試用例，如果這樣，往往會遺漏很多本應(yīng)該更新的測試用例。

軟件測試用例的基本要素包括測試用例編號、測試標(biāo)題、重要級別、測試輸入、操作步驟、預(yù)期結(jié)果，下面逐一介紹。

測試用例設(shè)計(jì)用例編號

測試用例的編號有一定的規(guī)則，比如系統(tǒng)測試用例的編號這樣定義規(guī)則： PROJECT1-ST-001 ，命名規(guī)則是項(xiàng)目名稱 測試階段類型（系統(tǒng)測試階段） 編號。定義測試用例編號，便于查找測試用例，便于測試用例的跟蹤。

測試用例設(shè)計(jì)測試標(biāo)題

對測試用例的描述，測試用例標(biāo)題應(yīng)該清楚表達(dá)測試用例的用途。比如 “ 測試用戶登錄時輸入錯誤密碼時，軟件的響應(yīng)情況 ” 。

測試用例設(shè)計(jì)重要級別

定義測試用例的優(yōu)先級別，可以籠統(tǒng)的分為 四個不同的等級

測試用例設(shè)計(jì)輸入限制

提供測試執(zhí)行中的各種輸入條件。根據(jù)需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當(dāng)中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測試用例設(shè)計(jì)中會遇到很大的障礙。

測試用例設(shè)計(jì)操作步驟

提供測試執(zhí)行過程的步驟。對于復(fù)雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內(nèi)容在操作步驟中詳細(xì)列出。

測試用例設(shè)計(jì)預(yù)期結(jié)果

提供測試執(zhí)行的預(yù)期結(jié)果，預(yù)期結(jié)果應(yīng)該根據(jù)軟件需求中的輸出得出。如果在實(shí)際測試過程中，得到的實(shí)際測試結(jié)果與預(yù)期結(jié)果不符，那么測試不通過；反之則測試通過。

軟件測試執(zhí)行結(jié)束后，測試活動還沒有結(jié)束。測試結(jié)果分析是必不可少的重要環(huán)節(jié)， “ 編筐編簍，全在收口 ” ，測試結(jié)果的分析對下一輪測試工作的開展有很大的借鑒意義。前面的 “ 測試準(zhǔn)備工作 ” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發(fā)現(xiàn)的軟件缺陷。測試結(jié)束后，也應(yīng)該分析自己發(fā)現(xiàn)的軟件缺陷，對發(fā)現(xiàn)的缺陷分類，你會發(fā)現(xiàn)自己提交的問題只有固定的幾個類別；然后，再把一起完成測試執(zhí)行工作的其他測試人員發(fā)現(xiàn)的問題也匯總起來，你會發(fā)現(xiàn)，你所提交問題的類別與他們有差異。這很正常，人的思維是有局限性，在測試的過程中，每個測試人員都有自己思考問題的盲區(qū)和測試執(zhí)行的盲區(qū)，有效的自我分析和分析其他測試人員，你會發(fā)現(xiàn)自己的盲區(qū)，有針對性的分析盲區(qū)，必定會在下一輪測試中避免盲區(qū)。

（1）逐級細(xì)分法（2）輸入域測試法 （3）輸出域分析法 （4）正交試驗(yàn)設(shè)計(jì)法 （5） 業(yè)務(wù)流程分析法 （6）狀態(tài)遷移法 （7）因果圖法 （8）判定表法 （9）錯誤猜測法 (10)等價類劃分法 （11）邊界值分析法2100433B

UTP是UNIT TEST CASE SPECIFICATIONS的簡稱，單元測試用例描述，指軟件開發(fā)中的測試用例。2100433B