軟件測試文章精選

1、軟件測試從零開始【摘要】本文面向軟件測試新手，從測試前的準(zhǔn)備工作、測試需求收集、測試用例設(shè)計(jì)、測試用例 執(zhí)行、測試結(jié)果分析幾個(gè)方面給出建議和方法。鑒于國內(nèi)的軟件開發(fā)、測試不規(guī)范的現(xiàn)狀，本文為 軟件測試新手提供了若干個(gè)軟件測試的關(guān)注點(diǎn)?！娟P(guān)鍵詞】軟件測試、測試用例、測試需求、測試結(jié)果分析引言幾年前，從學(xué)校畢業(yè)后，第一份工作就是軟件測試。那時(shí)候，國內(nèi)的軟件企業(yè)大多對軟件測試 還沒有什么概念，書店里除了鄭人杰編寫的計(jì)算機(jī)軟件測試技術(shù)之外，幾乎沒有其它的軟件測 試相關(guān)書籍，軟件測試僅僅在軟件工程的教材中作為一個(gè)章節(jié)列出來，因此，我對軟件測試一無所 知。不過，在正式走上工作崗位之前，公司提供了為期兩周的

2、系統(tǒng)的軟件測試技術(shù)專題培訓(xùn)，對接 下來的軟件測試工作有很大的指導(dǎo)意義。現(xiàn)在，我繼續(xù)從事軟件測試的培訓(xùn)與咨詢服務(wù)，在這個(gè)過 程中，親眼目睹了很多軟件測試新手面對的困惑，他們初涉軟件測試行業(yè)，沒有接受系統(tǒng)的培訓(xùn)， 對軟件測試一無所知，既不知道該測試什么，也不知道如何開始測試。下面針對上述情況，給出若 干解決辦法。?測試準(zhǔn)備工作在測試工作伊始，軟件測試工程師應(yīng)該搞清楚軟件測試工作的目的是什么。如果你把這個(gè)問題 提給項(xiàng)目經(jīng)理，他往往會這樣回答：“發(fā)現(xiàn)我們產(chǎn)品里面的所有BUG ,這就是你的工作目的 作為一名軟件測試新手，如何才能發(fā)現(xiàn)所有的BUG ?如何開始測試工作？即便面對的是一個(gè)很小的軟件項(xiàng)目，測試需

3、要考慮的問題也是方方面面的，包括硬件環(huán)境、操作系統(tǒng)、產(chǎn)品的軟件配置環(huán) 境、產(chǎn)品相關(guān)的業(yè)務(wù)流程、用戶的并發(fā)容量等等。該從何處下手呢？?向有經(jīng)驗(yàn)的測試人員學(xué)習(xí)如果你進(jìn)入的是一家運(yùn)作規(guī)范的軟件公司，有獨(dú)立的軟件測試部門、規(guī)范的軟件測試流程、軟 件測試技術(shù)有一定的積累，那么，恭喜你！你可以請求測試經(jīng)理委派有經(jīng)驗(yàn)的測試人員作為你工作 上的業(yè)務(wù)導(dǎo)師，由他列出軟件測試技術(shù)相關(guān)書籍目錄、軟件測試流程相關(guān)文檔目錄、產(chǎn)品業(yè)務(wù)相關(guān) 的文檔目錄，在業(yè)務(wù)導(dǎo)師的指導(dǎo)下逐步熟悉軟件測試的相關(guān)工作。其實(shí)，在很多運(yùn)作規(guī)范的軟件公 司，已經(jīng)把上述的師父帶徒弟的方式固化到流程中。如果你進(jìn)入的是一個(gè)軟件測試一片空白的軟件企業(yè)，那么，

4、也恭喜你！你可以在這里開創(chuàng)一片 自己的軟件測試事業(yè)，當(dāng)然，前提是老板確實(shí)認(rèn)識到軟件測試的重要性，實(shí)實(shí)在在需要提高產(chǎn)品的 質(zhì)量。這時(shí)候，可以到國內(nèi)的軟件測試論壇和相關(guān)網(wǎng)站上尋找軟件測試資源，這種情況下，自學(xué)能 力和對技術(shù)的悟性就至關(guān)重要了。?閱讀軟件測試的相關(guān)書籍現(xiàn)在，中文版的軟件測試書籍越來越多，有的是國人自己寫的，有的是翻譯國外經(jīng)典之作。可 以到 http:/www 。 chinapub 。 com/ 或者 http:/www 。 dangdang 。 com/ 等網(wǎng)絡(luò)購書的站點(diǎn)查找軟 件測試相關(guān)的書籍。目前，從國外引入的軟件測試書籍有很多經(jīng)典之作，但是，翻譯成中文后，翻 譯質(zhì)量對閱讀效果有

5、很大的影響。?走讀缺陷跟蹤庫中的問題報(bào)告單如果您所在的公司已經(jīng)有軟件缺陷跟蹤庫了，無論采用的是商用工具，如ClearQuest 、TestDirecter 等工具，還是采用的 Bugzilla、 Mantis等開源工具，這都無關(guān)緊要，缺陷跟蹤庫中 的缺陷報(bào)告單才是有價(jià)值的。缺陷跟蹤庫中的問題報(bào)告單是軟件測試工程師工作績效的集中體現(xiàn)， 同時(shí)也是軟件產(chǎn)品問題的集中體現(xiàn)。一般來說，缺陷報(bào)告單中最關(guān)鍵的幾個(gè)部分包括：第一部分是 發(fā)現(xiàn)缺陷的環(huán)境，包括軟件環(huán)境、硬件環(huán)境等；第二部分是缺陷的基本描述；第三部分是開發(fā)人員 對缺陷的解決方法。通過對上述缺陷報(bào)告單的三個(gè)部分作仔細(xì)分析，不知不覺你已經(jīng)吸收了其他軟

6、件測試人員的工作經(jīng)驗(yàn)，并掌握了軟件產(chǎn)品常見的基本問題。這是迅速提高軟件測試經(jīng)驗(yàn)的好方法。?走讀相關(guān)產(chǎn)品的歷史測試用例如果你所在的公司有測試用例管理系統(tǒng)，那么，走讀相關(guān)產(chǎn)品的軟件測試用例是迅速提高測試 用例設(shè)計(jì)水平的一條捷徑。走讀測試用例也是有技巧的。測試用例寫作一般會包括測試用例項(xiàng)和根 據(jù)測試用例項(xiàng)細(xì)化的測試用例，下面舉例說明。“測試用戶登錄的功能 ”是一個(gè)測試項(xiàng)，該測試項(xiàng)的目的是測試用戶登錄功能是否正確，是否能夠完成正常的登錄功能，是否能夠?qū)Ψ欠ㄓ脩裘兔?碼做異常處理等等。因此，根據(jù)該用例項(xiàng)，可以設(shè)計(jì)出若干個(gè)測試用例，大多數(shù)情況下，測試用例 項(xiàng)和測試用例是一對多的關(guān)系。通過走讀測試用例項(xiàng)目

7、，你可以掌握應(yīng)該從哪些功能點(diǎn)著手未來的測試工作；通過走讀軟件測 試用例，你可以了解如何根據(jù)被測試的功能點(diǎn)開展軟件測試用例的設(shè)計(jì)工作，包括如何確定測試用 例的輸入、測試用例的操作步驟和測試用例的輸出結(jié)果等。總之，走讀其他軟件測試人員設(shè)計(jì)的優(yōu)秀軟件測試用例，是提高自身用例設(shè)計(jì)水平的好方法。?學(xué)習(xí)產(chǎn)品相關(guān)的業(yè)務(wù)知識軟件測試人員不僅要掌握軟件測試技術(shù)相關(guān)知識，對產(chǎn)品相關(guān)的業(yè)務(wù)知識也要學(xué)習(xí)。這很好理 解，如果從事財(cái)務(wù)軟件的測試工作，一定要學(xué)習(xí)財(cái)務(wù)知識；如果從事通訊產(chǎn)品測試工作，那么相關(guān) 的通訊理論知識也是必須的；如果從事銀行軟件的測試，銀行的業(yè)務(wù)流程也是不可或缺的知識點(diǎn)。因此，在學(xué)習(xí)軟件測試技術(shù)的同時(shí)，

8、千萬不要忽略產(chǎn)品相關(guān)業(yè)務(wù)知識的學(xué)習(xí)。如果你是一個(gè)軟 件測試技術(shù)專家，但是對產(chǎn)品業(yè)務(wù)知識一無所知，那么也只能測試出來純粹的軟件缺陷，而面對眼 前出現(xiàn)的產(chǎn)品業(yè)務(wù)相關(guān)的缺陷，很可能是視而不見，如此這般，軟件測試的效果會大打折扣。?識別測試需求識別測試需求是軟件測試的第一步。如果開發(fā)人員能夠提供完整的需求文檔和接口文檔，那固 然好?？梢愿鶕?jù)需求文檔中描述的每個(gè)功能項(xiàng)目的輸入、處理過程和輸出，來設(shè)計(jì)測試用例。如果 開發(fā)人員沒有提供軟件需求文檔，那該如何是好？下面給出幾個(gè)有效的方法：?主動獲取需求開發(fā)人員通常不會更好地考慮軟件測試，如果沒有開發(fā)流程的強(qiáng)制規(guī)定，他們通常是不愿意提 供任何開發(fā)文檔，即便有強(qiáng)制

9、規(guī)定，需求文檔也未必能夠真正指導(dǎo)軟件系統(tǒng)測試工作。因此，需要 測試人員發(fā)揮主觀能動性，與相關(guān)的軟件開發(fā)項(xiàng)目經(jīng)理和軟件開發(fā)人員保持溝通，了解軟件實(shí)現(xiàn)的 主要功能是什么，并記錄得收集到的信息。一般來說，開發(fā)人員即便沒有提供相關(guān)需求文檔，也會 保存一些簡單的過程文檔，主動向開發(fā)人員索要這些文檔，可以作為測試的參考。此外，可以與公 司的技術(shù)支持人員交流，技術(shù)支持人員是最貼近用戶的人，因此，通過交流可以獲取第一手的用戶 使用感受，在測試的過程中會更加貼近用戶。當(dāng)拿到相關(guān)的資料后，從哪些方面分析需求？如何與開發(fā)人員交流需求？其實(shí)，只要把握需求 分析的幾個(gè)關(guān)鍵的點(diǎn)就可以解決問題：輸入、處理過程、輸出、性能要

10、求、運(yùn)行環(huán)境，下面針對每 一個(gè)項(xiàng)目逐一分析：軟件輸入：與該需求相關(guān)的一切可能輸入，可以從這幾方面考慮，輸入來源、輸入?yún)?shù)的數(shù)量、 輸入?yún)?shù)的度量單位、輸入?yún)?shù)的時(shí)間要求、輸入?yún)?shù)的精度和輸入?yún)?shù)的有效輸入范圍。在測試 用例設(shè)計(jì)中，這部分內(nèi)容作為測試用例輸入的依據(jù)。處理過程：描述對輸入數(shù)據(jù)所執(zhí)行的所有操作和如何獲得輸出的過程。測試人員了解處理過程即可，在測試過程中發(fā)現(xiàn) BUG時(shí)候，如果對處理過程了解的深入， 對定位問題根源有很大的幫助。軟件輸出： 描述每個(gè)需求的輸出結(jié)果，包括輸出的位置（如計(jì)算機(jī)顯示器、打印機(jī)，文件）， 輸出參數(shù)的數(shù)量、輸出參數(shù)的度量單位、輸出參數(shù)的時(shí)序、輸出參數(shù)精確度、輸出參數(shù)

11、的有效輸出 范圍、錯(cuò)誤消息。在測試用例設(shè)計(jì)中，這部分內(nèi)容作為測試用例的預(yù)期輸出。性能要求： 與該需求相關(guān)的性能要求，比如“插入ATM取款卡后，3秒鐘內(nèi)彈出提示用戶取款的圖形界面 ”。3秒鐘這一限制，就是對需求的基本性能要求。運(yùn)行環(huán)境： 軟件的運(yùn)行所需的環(huán)境，包括硬件平臺的要求、操作系統(tǒng)的要求、數(shù)據(jù)庫的要求， 以及其它相關(guān)支撐軟件的要求。?確認(rèn)需求的優(yōu)先級確認(rèn)需求的優(yōu)先級是很必要的，如果在產(chǎn)品進(jìn)度比較緊的情況下，測試人員可以考慮優(yōu)先測試 優(yōu)先級高的需求項(xiàng)，如果進(jìn)度允許，那么在測試優(yōu)先級低的需求項(xiàng)，如果進(jìn)度不允許，那么就放棄 測試優(yōu)先級低的需求項(xiàng)。如果軟件公司有規(guī)范的流程支撐，開發(fā)人員在提供軟件需

12、求文檔的時(shí)候， 應(yīng)該在文檔中確定需求的優(yōu)先級。但是，如果開發(fā)人員連基本的軟件需求文檔都沒有提供，又怎能 指望他們確定軟件需求的優(yōu)先級？如果是這樣，需求的優(yōu)先級只能由測試人員完成了。?加入開發(fā)小組的郵件群組測試人員需要通曉被測試產(chǎn)品，但是，產(chǎn)品在開發(fā)的過程中往往是不斷變化的。如果軟件開發(fā) 團(tuán)隊(duì)有一套變更控制流程，測試人員會對產(chǎn)品的變更了如指掌。如果沒有變更控制，那就要采用其 他的土方法了。如果公司里面有自動化辦公系統(tǒng)，也許采用的是Lotus Notes系統(tǒng)，也許使用的是E-mail系統(tǒng)，測試人員應(yīng)該加入到開發(fā)人員的郵件群組中。當(dāng)開發(fā)人員通過郵件討論問題、通知召 開技術(shù)會議的時(shí)候，測試人員可以及時(shí)

13、知曉，如果必要，可以參加開發(fā)人員的技術(shù)會議。即便公司 里面有了軟件變更控制流程，加入到開發(fā)郵件群組也是一個(gè)很好的習(xí)慣。?與開發(fā)人員為鄰建議測試人員與開發(fā)人員為鄰。我所在的測試組曾經(jīng)與開發(fā)組是在相鄰的寫字間里，開發(fā)人員 與測試人員的關(guān)系非常融洽，拋去同事關(guān)系，大家還是不錯(cuò)的朋友。不管開發(fā)人員有什么樣的活動， 測試人員都能第一時(shí)間獲得信息。無論從事軟件測試工作，還是從事其它的工作，與工作中上下游 環(huán)節(jié)的同事保持良好的個(gè)人關(guān)系對工作有很大便利。一般的公司內(nèi)部都存在部門墻，良好的人際關(guān) 系是打通部門墻的手段之一。向領(lǐng)導(dǎo)建議測試人員與開發(fā)人員為鄰，這很必要。?測試用例設(shè)計(jì)測試需求收集完畢后，開始測試設(shè)計(jì)

14、。測試用例是什么？測試用例就是一個(gè)文檔，描述輸入、 動作、或者時(shí)間和一個(gè)期望的結(jié)果，其目的是確定應(yīng)用程序的某個(gè)特性是否正常的工作。設(shè)計(jì)測試 用例需要考慮以下問題：?測試用例的基本格式軟件測試用例的基本要素包括測試用例編號、測試標(biāo)題、重要級別、測試輸入、操作步驟、預(yù) 期結(jié)果，下面逐一介紹。用例編號：測試用例的編號有一定的規(guī)則，比如系統(tǒng)測試用例的編號這樣定義規(guī)則：PROJECT1-ST-001 ,命名規(guī)則是項(xiàng)目名稱+測試階段類型（系統(tǒng)測試階段）+編號。定義測試用 例編號，便于查找測試用例，便于測試用例的跟蹤。測試標(biāo)題：對測試用例的描述，測試用例標(biāo)題應(yīng)該清楚表達(dá)測試用例的用途。比如“測試用戶登錄時(shí)輸

15、入錯(cuò)誤密碼時(shí)，軟件的響應(yīng)情況”。重要級別：定義測試用例的優(yōu)先級別，可以籠統(tǒng)的分為“高”和“低”兩個(gè)級別。一般來說，如果軟件需求的優(yōu)先級為“高”，那么針對該需求的測試用例優(yōu)先級也為“高”；反之亦然，測試輸入：提供測試執(zhí)行中的各種輸入條件。根據(jù)需求中的輸入條件，確定測試用例的輸入。 測試用例的輸入對軟件需求當(dāng)中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸 入，那么測試用例設(shè)計(jì)中會遇到很大的障礙。操作步驟：提供測試執(zhí)行過程的步驟。對于復(fù)雜的測試用例，測試用例的輸入需要分為幾個(gè)步驟完成，這部分內(nèi)容在操作步驟中詳細(xì)列出。預(yù)期結(jié)果：提供測試執(zhí)行的預(yù)期結(jié)果，預(yù)期結(jié)果應(yīng)該根據(jù)軟件需求中的輸出得出

16、。如果在實(shí)際 測試過程中，得到的實(shí)際測試結(jié)果與預(yù)期結(jié)果不符，那么測試不通過；反之則測試通過。軟件測試用例的設(shè)at主要從上述6個(gè)域考慮，結(jié)合相應(yīng)的軟件需求文檔， 在掌握一定測試用例設(shè)計(jì)方法的基礎(chǔ)上，可以設(shè)計(jì)出比較全面、合理的測試用例。具體的測試用例設(shè)計(jì)方法可以參見相 關(guān)的測試書籍，白盒測試方法和黑盒測試方法在絕大多數(shù)的軟件測試書籍中都有詳細(xì)的介紹，這里 不作贅述。?重用同類型項(xiàng)目的測試用例如果我看得遠(yuǎn)，那是因?yàn)槲艺驹诰奕说募缟?牛頓。一般來說，每個(gè)軟件公司的項(xiàng)目可以分為固定的幾大類?？梢园礃I(yè)務(wù)類型劃分，比如ERP軟件、產(chǎn)品數(shù)據(jù)管理軟件、通信軟件、地理信息系統(tǒng)軟件等等；可以按軟件結(jié)構(gòu)來劃分，比如B

17、/S架構(gòu)的軟件、C/S架構(gòu)的軟件、嵌入式軟件等等。參考同類別軟件的測試用例，會有很大的借鑒意義。如果，公司中有同類別的軟件系統(tǒng)，千萬別忘記把相關(guān)的測試用例拿來參考。如果，系統(tǒng)非常接近， 甚至經(jīng)過對測試用例簡單修改就可以應(yīng)用到當(dāng)前被測試的軟件?！澳脕碇髁x”可以極大的開闊測試用例設(shè)計(jì)思路，也可以節(jié)省大量的測試用例設(shè)計(jì)時(shí)間。?利用已有的軟件 Checklist在上面一個(gè)小節(jié)中，按照不同的規(guī)則劃分了不同的軟件類型。每種類型的軟件都有一定的測試 規(guī)范，比如， WEB軟件系統(tǒng)在系統(tǒng)測試過程中，會有一系列的范式，比如針對Cookie就會有很多測試點(diǎn)。在設(shè)計(jì)測試用例的時(shí)候，不妨到網(wǎng)上去搜索相關(guān)的Checkli

18、st ,不過國內(nèi)外的網(wǎng)站很少有這方面的資料，即便有，也不是特別系統(tǒng)?？梢韵日乙环荽植诘腃hecklist ,然后，在設(shè)計(jì)測試用例的時(shí)候不斷的去完善它，以作為下次測試用例設(shè)計(jì)的基礎(chǔ)。?加強(qiáng)測試用例的評審測試用例設(shè)計(jì)完畢后，最好能夠增加評審過程。同行評審是CMM3級的一個(gè) KPA ,如果因?yàn)楣緵]有通過 CMM3級，就不開展同行評審是不恰當(dāng)?shù)?。測試用例應(yīng)該由產(chǎn)品相關(guān)的軟件測試 人員和軟件開發(fā)人員評審，提交評審意見，然后根據(jù)評審意見更新測試用例。如果認(rèn)真操作這個(gè)環(huán)節(jié)，測試用例中的很多問題都會暴露出來，比如用例設(shè)計(jì)錯(cuò)誤、用例設(shè)計(jì)遺漏、用例設(shè)計(jì)冗余、用 例設(shè)計(jì)不充分等等；如果同行評審不充分，那么，在測試

19、執(zhí)行的過程中，上述本應(yīng)在評審階段發(fā)現(xiàn) 的測試用例相關(guān)問題，會給測試執(zhí)行帶來大麻煩，甚至導(dǎo)致測試執(zhí)行掛起。?定義測試用例的執(zhí)行順序在測試用例執(zhí)行過程中，你會發(fā)現(xiàn)每個(gè)測試用例都對測試環(huán)境有特殊的要求，或者對測試環(huán)境 有特殊的影響。因此，定義測試用例的執(zhí)行順序，對測試的執(zhí)行效率影響非常大。比如某些異常測 試用例會導(dǎo)致服務(wù)器頻繁重新啟動，服務(wù)器的每次重新啟動都會消耗大量的時(shí)間，導(dǎo)致這部分測試 用例執(zhí)行也消耗很多的時(shí)間。那么在編排測試用例執(zhí)行順序的時(shí)候，應(yīng)該考慮把這部分測試用例放 在最后執(zhí)行，如果在測試進(jìn)度很緊張的情況下，如果優(yōu)先執(zhí)行這部分消耗時(shí)間的異常測試用例，那 么在測試執(zhí)行時(shí)間過了大半的時(shí)候，測試

20、用例執(zhí)行的進(jìn)度依然是緩慢的，這會影響到測試人員的心 情，進(jìn)而導(dǎo)致匆忙地測試后面的測試用例，這樣測試用例的漏測、誤測就不可避免，嚴(yán)重影響了軟 件測試效果和進(jìn)度。因而，合理地定義測試用例的執(zhí)行順序是很有必要的。?測試用例執(zhí)行測試用例設(shè)計(jì)完畢后，接下來的工作是測試執(zhí)行，測試執(zhí)行中應(yīng)該注意以下幾個(gè)問題：?搭建軟件測試環(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 等等，

21、此外，應(yīng)該給出被測試軟件 產(chǎn)品的詳細(xì)安裝指導(dǎo)書，包括安裝的操作步驟、相關(guān)配置文件的配置方法等等。對于復(fù)雜的軟件產(chǎn) 品，尤其是軟件項(xiàng)目，如果沒有安裝指導(dǎo)書作為參考，在搭建測試環(huán)境過程中會遇到種種問題。如果開發(fā)人員拒絕提供相關(guān)的安裝指導(dǎo)書，搭建測試中遇到問題的時(shí)候，測試人員可以要求開 發(fā)人員協(xié)助，這時(shí)候，一定要把開發(fā)人員解決問題的方法記錄下來，避免同樣的問題再次請教開發(fā) 人員，這樣會招致開發(fā)人員的反感，也降低了開發(fā)人員對測試人員的認(rèn)可程度。?測試執(zhí)行過程應(yīng)注意的問題測試環(huán)境搭建之后，根據(jù)定義的測試用例執(zhí)行順序，逐個(gè)執(zhí)行測試用例。在測試執(zhí)行中需要注 意以下幾個(gè)問題：全方位的觀察測試用例執(zhí)行結(jié)果：測試

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

23、%。如果觀察點(diǎn)單一，這個(gè)嚴(yán)重消耗資源的問題就無從發(fā)現(xiàn)了。加強(qiáng)測試過程記錄：測試執(zhí)行過程中，一定要加強(qiáng)測試過程記錄。如果測試執(zhí)行步驟與測試用例中描述的有差異，一定要記錄下來，作為日后更新測試用例的依據(jù)；如果軟件產(chǎn)品提供了日志功 能，比如有軟件運(yùn)行日志、用戶操作日志，一定在每個(gè)測試用例執(zhí)行后記錄相關(guān)的日志文件，作為 測試過程記錄，一旦日后發(fā)現(xiàn)問題，開發(fā)人員可以通過這些測試記錄方便的定位問題。而不用測試 人員重新搭建測試環(huán)境，為開發(fā)人員重現(xiàn)問題。及時(shí)確認(rèn)發(fā)現(xiàn)的問題：測試執(zhí)行過程中，如果確認(rèn)發(fā)現(xiàn)了軟件的缺陷，那么可以毫不猶豫的提交問題報(bào)告單。如果發(fā)現(xiàn)了可疑問題，又無法定位是否為軟件缺陷，那么一定要保留

24、現(xiàn)場，然后知 會相關(guān)開發(fā)人員到現(xiàn)場定位問題。如果開發(fā)人員在短時(shí)間內(nèi)可以確認(rèn)是否為軟件缺陷，測試人員給 予配合；如果開發(fā)人員定位問題需要花費(fèi)很長的時(shí)間，測試人員千萬不要因此耽誤自己寶貴的測試 執(zhí)行時(shí)間，可以讓開發(fā)人員記錄重新問題的測試環(huán)境配置，然后，回到自己的開發(fā)環(huán)境上重現(xiàn)問題， 繼續(xù)定位問題。與開發(fā)人員良好的溝通：測試執(zhí)行過程中，當(dāng)你提交了問題報(bào)告單， 可能被開發(fā)人員無情駁回，拒絕修改。這時(shí)候，只能對開發(fā)人員曉之以理，做到有理、有據(jù)，有說服力。首先，要定義軟件缺 陷的標(biāo)準(zhǔn)原則，這個(gè)原則應(yīng)該是開發(fā)人員和測試人員都認(rèn)可的，如果沒有共同認(rèn)可的原則，那么開 發(fā)人員與測試人員對問題的爭執(zhí)就不可避免了。此

25、外，測試人員打算說服開發(fā)人員之前，考慮是否 能夠先說服自己，在保證可以說服自己的前提下，再開始與開發(fā)人員交流。?及時(shí)更新測試用例測試執(zhí)行過程中，應(yīng)該注意及時(shí)更新測試用例。往往在測試執(zhí)行過程中，才發(fā)現(xiàn)遺漏了一些測 試用例，這時(shí)候應(yīng)該及時(shí)的補(bǔ)充；往往也會發(fā)現(xiàn)有些測試用例在具體的執(zhí)行過程中根本無法操作， 這時(shí)候應(yīng)該刪除這部分用例；也會發(fā)現(xiàn)若干個(gè)冗余的測試用例完全可以由某一個(gè)測試用例替代，那 么刪除冗余的測試用例。總之，測試執(zhí)行的過程中及時(shí)地更新測試用例是很好的習(xí)慣。不要打算在測試執(zhí)行結(jié)束后，統(tǒng) 一更新測試用例，如果這樣，往往會遺漏很多本應(yīng)該更新的測試用例。?提交一份優(yōu)秀的問題報(bào)告單軟件測試提交的問題

26、報(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í)輸出設(shè)備的相關(guān)輸出信息和相關(guān)的日志等。軟件配置：包括操作系統(tǒng)類型版本和補(bǔ)丁版本、當(dāng)前被測試軟件的版本和補(bǔ)丁版本、相關(guān)支撐 軟件，比如數(shù)據(jù)庫軟件的版本和補(bǔ)丁版本等。硬件配置： 計(jì)算機(jī)的配置情況，主要包括CPU、內(nèi)存和硬盤的相關(guān)參數(shù)，其它硬件參數(shù)根據(jù)測試用例的實(shí)際情況添加。如果測試中使用網(wǎng)絡(luò)，那么網(wǎng)絡(luò)的組網(wǎng)情況，網(wǎng)

27、絡(luò)的容量、流量等情況。 硬件配置情況與被測試產(chǎn)品類型密切相關(guān)，需要根據(jù)當(dāng)時(shí)的情況，準(zhǔn)確翔實(shí)的記錄硬件配置情況。測試用例輸入 操作步驟 輸出：這部分內(nèi)容可以根據(jù)測試用例的描述和測試用例的實(shí)際執(zhí) 行情況如實(shí)填寫。輸出設(shè)備的相關(guān)輸出信息：輸出設(shè)備包括計(jì)算機(jī)顯示器、打印機(jī)、磁帶等等輸出設(shè)備，如果是顯示器可以采用抓屏的方式獲取當(dāng)時(shí)的截圖，其他的輸出設(shè)備可以采用其它方法獲取相關(guān)的輸出， 在問題報(bào)告單中提供描述。日志信息： 規(guī)范的軟件產(chǎn)品都會提供軟件的運(yùn)行日志和用戶、管理員的操作日志，測試人員應(yīng) 該把測試用例執(zhí)行后的軟件產(chǎn)品運(yùn)行日志和操作日志作為附件，提交到問題報(bào)告單中。根據(jù)被測試軟件產(chǎn)品的不同，需要在“問

28、題描述”中增加相應(yīng)的描述內(nèi)容，這需要具體問題具 體分析。?測試結(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)自己提交的問題只有固定的幾個(gè)類別； 然后，再把一起完成測試執(zhí)行工作的其他測試人員發(fā)現(xiàn)的問題也匯總起來，你會發(fā)現(xiàn)，你所提交問 題的類別與他們有差異。這很正常，人的思維是有局限性，在測試的過程中，每個(gè)測試人員都有自 己思考

29、問題的盲區(qū)和測試執(zhí)行的盲區(qū)，有效的自我分析和分析其他測試人員，你會發(fā)現(xiàn)自己的盲區(qū)，有針對性的分析盲區(qū)，必定會在下一輪測試用避免盲區(qū)?？偨Y(jié)：限于文章的篇幅，本文不可能給出一個(gè)類似于checklist的指導(dǎo)性的軟件測試新手入門。無論從事軟件測試還是從事其它的工作，技術(shù)上的和技巧上的問題都可以通過查詢相關(guān)的軟件測試技術(shù) 書籍獲取，掌握一套基本的方法論是最重要的。以上文字，都是作者從事軟件測試工作積累的經(jīng)驗(yàn) 之談，如發(fā)現(xiàn)謬誤之處請不吝指出。軟件測試過程的持續(xù)完善.引言隨著軟件技術(shù)的迅猛發(fā)展，軟件的質(zhì)量愈來愈受到廣泛的重視。而測試又是保證軟件質(zhì)量的重要手段。根據(jù)IEEE/ANSI標(biāo)準(zhǔn)，軟件測試的定義是：

30、使用為發(fā)現(xiàn)錯(cuò)誤所選擇的輸入和狀態(tài)的組合而 執(zhí)行代碼的過程”。這就非常明確地提出了 軟件測試 是以發(fā)現(xiàn)錯(cuò)誤，檢驗(yàn)是否滿足需求為目標(biāo)。軟件測試在軟件生命周期中占有非常突出的重要地位，是保證軟件質(zhì)量的重要手段。根據(jù)Boehm的統(tǒng)計(jì),軟件開發(fā)總成本中，用在測試上的開銷要占 40哌IJ 50%軟件測試 的目的就是在軟件投入生產(chǎn)性運(yùn)行 之前，盡可能多地發(fā)現(xiàn)軟件中的錯(cuò)誤，以提高軟件的質(zhì)量。現(xiàn)代的軟件測試不僅僅是在軟件開發(fā)完成以后來做測試工作，而是將測試滲入到軟件開發(fā)的各個(gè)階段，而且提高自動化軟件測試手段，來提高測試效率。有些項(xiàng)目的主持人，認(rèn)為以盡快的速度把測試之前的所有開發(fā)階段完成（實(shí)際并沒有完成）， 早日

31、開始測試，以圖達(dá)到快速和高質(zhì)量（因?yàn)樗坪跤懈L的時(shí)間可用于測試）。實(shí)際的效果將會是 俗語所說的欲速則不達(dá)。從常識就可以知道，花開發(fā)時(shí)間去繼續(xù)擴(kuò)大發(fā)展前面階段引入的錯(cuò)誤， 得出的只能是更大量的需要耗時(shí)修正的錯(cuò)誤。因此，正確分析與利用測試的結(jié)果，我們可以非常有 效地進(jìn)行軟件過程改進(jìn)。.完善測試過程策略雙效合一，不斷進(jìn)步公司的管理層和質(zhì)量控制小組通常進(jìn)行軟件過程的改善，并編寫出了一系列的企業(yè)的標(biāo)準(zhǔn)與規(guī) 范，經(jīng)過一系列的評審、培訓(xùn)，然后讓開發(fā)人員去執(zhí)行。但是在執(zhí)行過程中常常碰到阻力，多數(shù)是 來自于開發(fā)人員，除了緊張的開發(fā)工作，他們往往會抱怨又多出許多其它工作，比如按照一定的規(guī) 范的文檔的撰寫；制定的企

32、業(yè)開發(fā)規(guī)范不符合企業(yè)的實(shí)際情況，標(biāo)準(zhǔn)太高，無法達(dá)到。這一種做法， 費(fèi)時(shí)費(fèi)力不討好，大家的意見都比較大，規(guī)范定的比較完美，而且在評審時(shí)還要大家表面上都要認(rèn) 可，制定規(guī)范的人花費(fèi)了很大的精力，對規(guī)范的評審浪費(fèi)了大家的很多的時(shí)間，執(zhí)行時(shí)還難以貫徹 下去。這種方式肯定收效甚微。這是一種效率比較低的做法。通常，還會有另外一種做法：降低要求，暫時(shí)拋棄各種標(biāo)準(zhǔn)與規(guī)范，采用一種簡單易行的策略, 即由質(zhì)量控制小組找開發(fā)人員、項(xiàng)目經(jīng)理讓他們自我發(fā)現(xiàn)問題：你有什么缺點(diǎn)？你將如何改進(jìn)？在 開發(fā)人員、項(xiàng)目管理人員講自己的改進(jìn)措施后，讓他們確保能做到。在這種辦法中，不需要管理人 員花費(fèi)太多的精力進(jìn)行標(biāo)準(zhǔn)的制定，改進(jìn)的推動

33、，這些工作都是由開發(fā)人員自己去做的，管理人員 僅僅是起到了監(jiān)督的作用，只要開發(fā)人員自己說到做到就可以了。但是，我們做了一個(gè)嘗試，如果 僅僅從開發(fā)人員的角度出發(fā)制定標(biāo)準(zhǔn)，每個(gè)人的習(xí)慣不同，開發(fā)人員往往傾向于按照平日自己的編 程習(xí)慣制定符合自己需要的規(guī)范，這樣做的隨意性比較大，難以形成統(tǒng)一的、正規(guī)的文檔體系結(jié)構(gòu)。 而且，開發(fā)人員往往利用這一點(diǎn)，給自己留有充分的彈性。往往自己制定的規(guī)范都有自己不同的解 決辦法，這樣會造成編程風(fēng)格的不統(tǒng)一。既然是規(guī)范，總得有一定的強(qiáng)制性，而如果單單從下而上, 放權(quán)給開發(fā)人員，實(shí)施的過程中可能會發(fā)生更大的問題。綜上所述，我們就采取了一個(gè)折中的辦法，即，根據(jù)開發(fā)人員的要求

34、，先擬訂一份開發(fā)規(guī)范， 然后提交給開發(fā)人員或者項(xiàng)目管理人員評審。允許他們提出自己的意見，如果意見合理，可以對規(guī) 范實(shí)施修改。舉例來說，假設(shè)公司原來的文檔體系中本身有一套編程規(guī)范，但是在實(shí)際開發(fā)的時(shí)候, 其中的某些規(guī)則不是很實(shí)用，所以，公司就根據(jù)每個(gè)項(xiàng)目組所使用的開發(fā)工具和語言的不同，制定 不同的編程標(biāo)準(zhǔn)，而這些編程標(biāo)準(zhǔn)的修改意見，基本上來自于開發(fā)人員，但是是經(jīng)過公司的管理人 員和質(zhì)量控制部審核過的。這種做法的好處就是可以主動提高公司全體員工的質(zhì)量意識。對于高層管理人員而言，所有的 規(guī)范都是經(jīng)過他們審核批準(zhǔn)的，他們起到監(jiān)督作用；對于開發(fā)人員而言，很多規(guī)則是他們提出的， 他們會自覺遵守。這樣雙管齊

35、下，雙效合一，不僅會大大提高軟件的質(zhì)量，而且不用將發(fā)現(xiàn)錯(cuò)誤的 責(zé)任全部推給測試人員，而是提前預(yù)防錯(cuò)誤、減少潛在危險(xiǎn)的發(fā)生、減輕測試人員負(fù)擔(dān)、培養(yǎng)開發(fā) 人員良好的編程習(xí)慣。重視文檔，需要技巧軟件文檔也稱文件，通常指的是一些記錄的數(shù)據(jù)和數(shù)據(jù)媒體，它具有固定不變的形式，可被人 和計(jì)算機(jī)閱讀。它和計(jì)算機(jī)程序共同構(gòu)成了能完成特定功能的計(jì)算機(jī)軟件（有人把源程序也當(dāng)作文 檔的一部分）。硬件產(chǎn)品和產(chǎn)品資料在整個(gè)生產(chǎn)過程中都是有形可見的，軟件生產(chǎn)則有很大不同， 文檔本身就是軟件產(chǎn)品。沒有文檔的軟件，不稱其為軟件，更談不上軟件產(chǎn)品。軟件文檔的編制在 軟件開發(fā)工作中占有突出的地位和相當(dāng)?shù)墓ぷ髁俊８咝?、高質(zhì)量地開發(fā)

36、、分發(fā)、管理和維護(hù)文檔 對于轉(zhuǎn)讓、變更、修正、擴(kuò)充和使用文檔，對于充分發(fā)揮軟件產(chǎn)品的效益有著重要的意義。然而，在實(shí)際工作中，文檔在編制和使用中存在著許多問題，有待于解決。軟件開發(fā)人員中較 普遍地存在著對編制文檔不感興趣的現(xiàn)象。從用戶方面看，他們又常常抱怨：文檔售價(jià)太高、文檔 不夠完整、文檔編寫的不好、文檔已經(jīng)陳舊難于使用等等。眾所周知，文檔的編寫對于開發(fā)人員來說是一個(gè)十分頭疼的任務(wù)，本來開發(fā)周期就很緊，還要 按照要求的格式撰寫文檔。所以，這樣結(jié)果往往就是文檔不全，或者文檔過于簡單致使測試人員看 不懂。甚至于，有時(shí)候項(xiàng)目需求早就更新了，而文檔的內(nèi)容依然不變。換個(gè)角度想想看，如果文檔不全，測試人員

37、遇到不理解的地方肯定會去問相應(yīng)的開發(fā)人員，那 么開發(fā)人員肯定要花費(fèi)時(shí)間做解釋。如果測試人員和開發(fā)人員處在不同的工作地，這將造成十分的 不便。在軟件開發(fā)過程中，文檔十分重要，書寫文檔工作量也是相當(dāng)大的。但是，只要掌握住技巧， 還是可以緩解這令人頭疼的問題的。首先，要站在別人的角度上看待這個(gè)問題。自己是做開發(fā)當(dāng)然 必須十分清楚程序的流程及功能，但是其他人就不一定，包括測試人員。所以，不要排斥寫文檔， 先要換個(gè)角度想問題。再次，闡述基本功能，要做到重點(diǎn)突出。就是說，用簡單的語言把功能簡要 介紹。對于其中的重點(diǎn)部分，要突出，要詳細(xì)。不是說語言上要十分詳細(xì)，而是理解的角度要詳細(xì)。 為了讓測試人員快速理解

38、模塊的功能，最好的辦法就是：功能流程圖、數(shù)據(jù)流程圖和例子。尤其是 對于那些有相當(dāng)強(qiáng)邏輯的程序而言，數(shù)據(jù)流程圖和例子是非常好的方法，它不僅可以幫助指明數(shù)據(jù) 的流向，還可以幫助測試人員理解測試用例的類型，以及結(jié)果形式。制作簡明扼要的流程圖和例子 對開發(fā)人員而言是一項(xiàng)理清思路、省時(shí)省力的工作。而對于測試人員而言則是一份理解程序邏輯和 功能的重要文檔。在開發(fā)過程的后期，可以繼續(xù)細(xì)化和完善文檔。結(jié)隊(duì)編程，提前測試為了提高軟件的質(zhì)量，公司可以嘗試實(shí)行先結(jié)隊(duì)編程，這其中也貫穿著質(zhì)量意識。因?yàn)閳F(tuán)隊(duì)的 兩個(gè)開發(fā)人員輪流編程、輪流寫文檔、互相監(jiān)督、互相測試。這樣不僅可以有精力把文檔寫好寫全， 而且可以提前單元測試

39、，互相監(jiān)督對方養(yǎng)成好的編程習(xí)慣。最終提高工作效率。結(jié)隊(duì)編程后，單元模塊先由項(xiàng)目組配備的測試人員首先進(jìn)行測試，然后質(zhì)量控制部的人員按照 項(xiàng)目計(jì)劃檢查項(xiàng)目是否按照預(yù)定計(jì)劃正常進(jìn)行，相關(guān)文檔是否撰寫，并進(jìn)行集成測試。善于總結(jié)，提高效率總結(jié)是一種非常好的學(xué)習(xí)方法，它可以節(jié)省精力、節(jié)約時(shí)間達(dá)到事半功倍的效果。在項(xiàng)目的開 發(fā)過程中，可以將碰到的重要的技術(shù)方面的問題要及時(shí)記錄并將解決方案也記錄下來，以便于其他 相關(guān)人員的參考。同樣，在測試的過程中，測試人員應(yīng)該及時(shí)總結(jié)發(fā)現(xiàn)的錯(cuò)誤并歸類，標(biāo)明經(jīng)常容 易出錯(cuò)的地方，將意見提交項(xiàng)目經(jīng)理，審核后，制定出一份統(tǒng)一標(biāo)準(zhǔn)并提供給開發(fā)人員，這樣就可 以提前避免錯(cuò)誤、避免重復(fù)

40、錯(cuò)誤和重復(fù)測試，提高測試效率。不僅如此，項(xiàng)目結(jié)束后的各項(xiàng)總結(jié)報(bào) 告將是項(xiàng)目的后期維護(hù)或二次開發(fā)的寶貴參考資料。.結(jié)論軟件開發(fā)作為一種復(fù)雜的智力密集型的活動，同一般產(chǎn)品的設(shè)計(jì)和生產(chǎn)過程有相當(dāng)大的差別， 人的因素占的比例很大，控制也更為復(fù)雜。例如軟件的正確性無法證明、測試也很困難，如果希望 通過最終的測試確保產(chǎn)品的質(zhì)量是完全做不到的；生命周期的各個(gè)階段的轉(zhuǎn)化無法確保百分之百的 正確和完整，等等。實(shí)踐證明，如果不從本公司的實(shí)際情況出發(fā)，盲目地套用一些好高鷲遠(yuǎn)的開發(fā) 體系或者質(zhì)量體系文件是行不通的，所建立的體系對提高管理水平非但不能起到多大的促進(jìn)作用， 而且可能會對正常的開發(fā)活動起阻礙作用，引起開發(fā)人

41、員的反感。這樣建立的體系或者難于維持下 去，或者要花費(fèi)寶貴的資源去維持一套無用的體系。所以，建議根據(jù)公司的實(shí)際量身定做，建立起 一套符合本公司情況的切實(shí)可行的標(biāo)準(zhǔn)和規(guī)范，真正的改善軟件過程，加強(qiáng)測試，提高軟件質(zhì)量。軟件測試的常識軟件開發(fā)和使用的歷史已經(jīng)留給了我們很多由于軟件缺陷而導(dǎo)致的巨大財(cái)力、物力損失的經(jīng)驗(yàn) 教訓(xùn)。這些經(jīng)驗(yàn)教訓(xùn)迫使我們這些測試工程師們必須采取強(qiáng)有力的檢測措施來檢測未發(fā)現(xiàn)的隱藏的 軟件缺陷。生產(chǎn)軟件的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟件質(zhì)量的標(biāo)準(zhǔn)，認(rèn)為軟 件缺陷(Software Bug )的具體含義包括下面幾個(gè)因素：?軟件未達(dá)到客戶需求的功能和性能;?軟件超

42、出客戶需求的范圍；?軟件出現(xiàn)客戶需求不能容忍的錯(cuò)誤；?軟件的使用未能符合客戶的習(xí)慣和工作環(huán)境?？紤]到設(shè)計(jì)等方面的因素，我們還可以認(rèn)為軟件缺陷還可以包括軟件設(shè)計(jì)不符合規(guī)范，未能在 特定的條件（資金、范圍等）達(dá)到最佳等?？上У氖牵覀冎械暮芏嗳烁鼉A向于把軟件缺陷看成運(yùn) 行時(shí)出現(xiàn)問題上來，認(rèn)為軟件測試僅限于程序提交之后。在目前的國內(nèi)環(huán)境下， 我們幾乎看不到完整準(zhǔn)確的客戶需求說明書，加以客戶的需求時(shí)時(shí)在變，追求完美的測試變得不太可能。因此作為一個(gè)優(yōu)異的測試人員，追求軟件質(zhì)量的完美固然是我們的 宗旨，但是明確軟件測試現(xiàn)實(shí)與理想的差距，在軟件測試中學(xué)會取舍和讓步，對軟件測試是有百益 而無一弊的。下面是一些

43、軟件測試的常識，對這些常識的理解和運(yùn)用將有助于我們在進(jìn)行軟件測試時(shí)能夠更 好的把握軟件測試的尺度。?測試是不完全的（測試不完全）很顯然，由于軟件需求的不完整性、軟件邏輯路徑的組合性、輸入數(shù)據(jù)的大量性及結(jié)果多樣性 等因素，哪怕是一個(gè)極其簡單的程序，要想窮盡所有邏輯路徑，所有輸入數(shù)據(jù)和驗(yàn)證所有結(jié)果是非 常困難的一件事情。我們舉一個(gè)簡單的例子，比如說求兩個(gè)整數(shù)的最大公約數(shù)。其輸入信息為兩個(gè) 正整數(shù)。但是如果我們將整個(gè)正整數(shù)域的數(shù)字進(jìn)行一番測試的話，從其數(shù)目的無限性我們便可證明 是這樣的測試在實(shí)際生活中是行不通的，即便某一天我們能夠窮盡該程序，只怕我們乃至我們的子 孫都早已作古了。為此作為軟件測試，我

44、們一般采用等價(jià)類和邊界值分析等措施來進(jìn)行實(shí)際的軟件 測試，尋找最小用例集合成為我們精簡測試復(fù)雜性的一條必經(jīng)之道。?測試具有免疫性（軟件缺陷免疫性）軟件缺陷與病毒一樣具有可怕的“免疫性”，測試人員對其采用的測試越多，其免疫能力就越強(qiáng)，尋找更多軟件缺陷就更加困難。由數(shù)學(xué)上的概率論我們可以推出這一結(jié)論。假設(shè)一個(gè)50000行的程序中有500個(gè)軟件缺陷并且這些軟件錯(cuò)誤分布時(shí)均勻的，則每 100行可以找到一個(gè)軟件缺 陷。我們假設(shè)測試人員用某種方法花在查找軟件缺陷的精力為X小時(shí)/100行。照此推算，軟件存在500個(gè)缺陷時(shí)，我們查找一個(gè)軟件缺陷需要X小時(shí)，當(dāng)軟件只存在 5個(gè)錯(cuò)誤時(shí)，我們每查找一個(gè)軟件缺陷需要1

45、00X小時(shí)。實(shí)踐證明，實(shí)際的測試過程比上面的假設(shè)更為苛刻，為此我們必須更 換不同的測試方式和測試數(shù)據(jù)。該例子還說明了在軟件測試中采用單一的方法不能高效和完全的針 對所有軟件缺陷，因此軟件測試應(yīng)該盡可能的多采用多種途徑進(jìn)行測試。?測試是“泛型概念”（全程測試）我一直反對軟件測試僅存在于程序完成之后。如果單純的只將程序設(shè)計(jì)階段后的階段稱之為軟 件測試的話，需求階段和設(shè)計(jì)階段的缺陷產(chǎn)生的放大效應(yīng)會加大。這非常不利于保證軟件質(zhì)量。需 求缺陷、設(shè)計(jì)缺陷也是軟件缺陷，記住 “軟件缺陷具有生育能力”。軟件測試應(yīng)該跨越整個(gè)軟件開發(fā)流程。需求驗(yàn)證（自檢）和設(shè)計(jì)驗(yàn)證（自檢）也可以算作軟件測試（建議稱為：需求測試和

46、 設(shè)計(jì)測試）的一種。軟件測試應(yīng)該是一個(gè)泛型概念，涵蓋整個(gè)軟件生命周期，這樣才能確保周期的 每個(gè)階段禁得起考驗(yàn)。同時(shí)測試本身也需要有第三者進(jìn)行評估（信息系統(tǒng)審計(jì)和軟件工程監(jiān)理）， 即測試本身也應(yīng)當(dāng)被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。另外還需指出的是軟件測試是提高軟件產(chǎn)品質(zhì)量的必要條件而非充分條件，軟件測試是提高產(chǎn)10 品質(zhì)量最直接、最快捷的手段，但決不是一個(gè)根本手段。? 80 -20原則80%的軟件缺陷常常生存在軟件20%的空間里。這個(gè)原則告訴我們，如果你想使軟件測試有效地話，記住常常光臨其高危多發(fā)“地段”。在那里發(fā)現(xiàn)軟件缺陷的可能性會大的多。這一原則對于軟件測試人

47、員提高測試效率及缺陷發(fā)現(xiàn)率有著重大的意義。聰明的測試人員會根據(jù)這個(gè)原則很 快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。80-20原則的另外一種情況是，我們在系統(tǒng)分析、系統(tǒng)設(shè)計(jì)、系統(tǒng)實(shí)現(xiàn)階段的復(fù)審，測試工作 中能夠發(fā)現(xiàn)和避免 80%的軟件缺陷，此后的系統(tǒng)測試能夠幫助我們找出剩余缺陷中的80% ,最后的5%的軟件缺陷可能只有在系統(tǒng)交付使用后用戶經(jīng)過大范圍、長時(shí)間使用后才會曝露出來。因?yàn)?軟件測試只能夠保證盡可能多地發(fā)現(xiàn)軟件缺陷，卻無法保證能夠發(fā)現(xiàn)所有的軟件缺陷。80-20原則還能反映到軟件測試的自動化方面上來，實(shí)踐證明80%的軟件缺陷可以借助人工測試而發(fā)現(xiàn)，20%的軟件缺陷可以借助自

48、動化測試能夠得以發(fā)現(xiàn)。由于這二者間具有交叉的部分，因 此尚有5%左右的軟件缺陷需要通過其他方式進(jìn)行發(fā)現(xiàn)和修正。?為效益而測試為什么我們要實(shí)施軟件測試，是為了提高項(xiàng)目的質(zhì)量效益最終以提高項(xiàng)目的總體效益。為此我 們不難得出我們在實(shí)施軟件測試應(yīng)該掌握的度。軟件測試應(yīng)該在軟件測試成本和軟件質(zhì)量效益兩者 間找到一個(gè)平衡點(diǎn)。這個(gè)平衡點(diǎn)就是我們在實(shí)施軟件測試時(shí)應(yīng)該遵守的度。單方面的追求都必然損 害軟件測試存在的價(jià)值和意義。一般說來，在軟件測試中我們應(yīng)該盡量地保持軟件測試簡單性，切 勿將軟件測試過度復(fù)雜化，拿物理學(xué)家愛因斯坦的話說就是：Keep it simple but not too simple ,?缺

49、陷的必然性軟件測試中，由于錯(cuò)誤的關(guān)聯(lián)性，并不是所有的軟件缺陷都能夠得以修復(fù)。某些軟件缺陷雖然 能夠得以修復(fù)但在修復(fù)的過程中我們會難免引入新的軟件缺陷。很多軟件缺陷之間是相互矛盾的， 一個(gè)矛盾的消失必然會引發(fā)另外一個(gè)矛盾的產(chǎn)生。比如我們在解決通用性的缺陷后往往會帶來執(zhí)行 效率上的缺陷。更何況在缺陷的修復(fù)過程中，我們常常還會受時(shí)間、成本等方面的限制因此無法有 效、完整地修復(fù)所有的軟件缺陷。因此評估軟件缺陷的重要度、影響范圍，選擇一個(gè)折中的方案或 是從非軟件的因素（比如提升硬件性能）考慮軟件缺陷成為我們在面對軟件缺陷時(shí)一個(gè)必須直面的 事實(shí)。?軟件測試必須有預(yù)期結(jié)果沒有預(yù)期結(jié)果的測試是不可理喻的。軟件

50、缺陷是經(jīng)過對比而得出來的。這正如沒有標(biāo)準(zhǔn)無法進(jìn) 行度量一樣。如果我們事先不知道或是無法肯定預(yù)期的結(jié)果，我們必然無法了解測試正確性。這很 容易然人感覺如盲人摸象一般，不少測試人員常常憑借自身的感覺去評判軟件缺陷的發(fā)生，其結(jié)果 往往是把似是而非的東西作為正確的結(jié)果來判斷，因此常常出現(xiàn)誤測的現(xiàn)象。?軟件測試的意義-事后分析軟件測試的目的單單是發(fā)現(xiàn)缺陷這么簡單嗎？如果是“是”的話，我敢保證，類似的軟件缺陷在下一次新項(xiàng)目的軟件測試中還會發(fā)生。古語說得好，“不知道歷史的人必然會重蹈覆轍”。沒有對軟件測試結(jié)果進(jìn)行認(rèn)真的分析，我們就無法了解缺陷發(fā)生的原因和應(yīng)對措施，結(jié)果 是我們不得不耗費(fèi)的大量的人力和物力來再

51、次查找軟件缺陷。很可惜，目前大多測試團(tuán)隊(duì)都沒有意 識到這一點(diǎn)，測試報(bào)告中缺乏測試結(jié)果分析這一環(huán)節(jié)。11軟件測試的復(fù)雜性與經(jīng)濟(jì)性人們常常以為，開發(fā)一個(gè)程序是困難的，測試一個(gè)程序則比較容易。這其實(shí)是誤解。設(shè)計(jì)測試 用例是一項(xiàng)細(xì)致并需要高度技巧的工作，稍有不慎就會顧此失彼，發(fā)生不應(yīng)有的疏漏。不論是黑盒測試方法還是白盒測試方法，由于測試情況數(shù)量巨大，都不可能進(jìn)行徹底的測試。 所謂徹底測試，就是讓被測程序在一切可能的輸入情況下全部執(zhí)行一遍。通常也稱這種測試為“窮 舉測試”?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查 出程序中所有的錯(cuò)誤。實(shí)際上測試情況有無窮多個(gè)，人

52、們不僅要測試所有合法的輸入，而且還要對 那些不合法但是可能的輸入進(jìn)行測試?！鞍缀小狈ㄊ歉F舉路徑測試，貫穿程序的獨(dú)立路徑數(shù)是天文數(shù)字，但即使每條路徑都測試了仍 然可能有錯(cuò)誤。第一，窮舉路徑測試決不能查出程序違反了設(shè)計(jì)規(guī)范，即程序本身是個(gè)錯(cuò)誤的程序。 第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯(cuò)。第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些 與數(shù)據(jù)相關(guān)的錯(cuò)誤。E. W Dijkstra 的一句名言對測試的不徹底性作了很好的注解：“程序測試只 能證明錯(cuò)誤的存在，但不能證明錯(cuò)誤不存在”。在實(shí)際測試中，窮舉測試工作量太大，實(shí)踐上行不通，這就注定了一切實(shí)際測試都是不徹底的。 當(dāng)然就不能夠保證被測試程序中不存在

53、遺留的錯(cuò)誤。軟件工程的總目標(biāo)是充分利用有限的人力和物 力資源，高效率、高質(zhì)量地完成測試。為了降低測試成本，選擇測試用例時(shí)應(yīng)注意遵守“經(jīng)濟(jì)性” 的原則。第一，要根據(jù)程序的重要性和一旦發(fā)生故障將造成的損失來確定它的測試等級；第二，要認(rèn)真研究測試策略，以便能使用盡可能少的測試用例，發(fā)現(xiàn)盡可能多的程序錯(cuò)誤。掌握好測試量是至關(guān)重要的，一位有經(jīng)驗(yàn)的軟件開發(fā)管理人員在談到軟件測試時(shí)曾這樣說過： “不充分的測試是愚蠢的，而過度的測試是一種罪孽”。測試不足意味著讓用戶承擔(dān)隱藏錯(cuò)誤帶來 的危險(xiǎn)，過度測試則會浪費(fèi)許多寶貴的資源。測試是軟件生存期中費(fèi)用消耗最大的環(huán)節(jié)。測試費(fèi)用除了測試的直接消耗外，還包括其它的相 關(guān)費(fèi)

54、用。能夠決定需要做多少次測試的主要影響因素如下：、系統(tǒng)的目的系統(tǒng)的目的的差別在很大程度上影響所需要進(jìn)行的測試的數(shù)量。那些可能產(chǎn)生嚴(yán)重后果的系統(tǒng) 必須要進(jìn)行更多的測試。一臺在boeing 757上的系統(tǒng)應(yīng)該比一個(gè)用于公共圖書館中檢索資料的系統(tǒng)需要更多的測試。一個(gè)用來控制密封燃?xì)夤艿赖南到y(tǒng)應(yīng)該比一個(gè)與有毒爆炸物品無關(guān)的系統(tǒng)有更高 的可信度。一個(gè)安全關(guān)鍵軟件的開發(fā)組比一個(gè)游戲軟件開發(fā)組要有苛刻得多的查找錯(cuò)誤方面的要求。、潛在的用戶數(shù)量一個(gè)系統(tǒng)的潛在用戶數(shù)量也在很大程度上影響了測試必要性的程度。這主要是由于用戶團(tuán)體在 經(jīng)濟(jì)方面的影響。一個(gè)在全世界范圍內(nèi)有幾千個(gè)用戶的系統(tǒng)肯定比一個(gè)只在辦公室中運(yùn)行的有兩

55、三 個(gè)用戶的系統(tǒng)需要更多的測試。如果不能使用的話，前一個(gè)系統(tǒng)的經(jīng)濟(jì)影響肯定比后一個(gè)系統(tǒng)大。 除此而外，在分配處理錯(cuò)誤的時(shí)候，所花的代價(jià)的差別也很大。如果在內(nèi)部系統(tǒng)中發(fā)現(xiàn)了一個(gè)嚴(yán)重 的錯(cuò)誤，在處理錯(cuò)誤的時(shí)候的費(fèi)用就相對少一些，如果要處理一個(gè)遍布全世界的錯(cuò)誤就需要花費(fèi)相 當(dāng)大的財(cái)力和精力。12、信息的價(jià)值在考慮測試的必要性時(shí)，還需要將系統(tǒng)中所包含的信息的價(jià)值考慮在內(nèi)，一個(gè)支持許多家大銀行或眾多證券交易所的客戶機(jī) /服務(wù)器系統(tǒng)中含有經(jīng)濟(jì)價(jià)值非常高的內(nèi)容。很顯然這一系統(tǒng)需要比一個(gè)支持鞋店的系統(tǒng)要進(jìn)行更多的測試。這兩個(gè)系統(tǒng)的用戶都希望得到高質(zhì)量、無錯(cuò)誤的系統(tǒng)，但是 前一種系統(tǒng)的影響比后一種要大得多。因此

56、我們應(yīng)該從經(jīng)濟(jì)方面考慮，投入與經(jīng)濟(jì)價(jià)值相對應(yīng)的時(shí) 間和金錢去進(jìn)行測試。、開發(fā)機(jī)構(gòu)一個(gè)沒有標(biāo)準(zhǔn)和缺少經(jīng)驗(yàn)的開發(fā)機(jī)構(gòu)很可能開發(fā)出充滿錯(cuò)誤的系統(tǒng)。在一個(gè)建立了標(biāo)準(zhǔn)和有很 多經(jīng)驗(yàn)的開發(fā)機(jī)構(gòu)中開發(fā)出來的系統(tǒng)中的錯(cuò)誤不會很多，因此，對于不同的開發(fā)機(jī)構(gòu)來說，所需要 的測試的必要性也就截然的不同。然而，那些需要進(jìn)行大幅度改善的機(jī)構(gòu)反而不大可能認(rèn)識到自身的弱點(diǎn)。那些需要更加嚴(yán)格的 測試過程的機(jī)構(gòu)往往是最不可能進(jìn)行這一活動的，在許多情況下，機(jī)構(gòu)的管理部門并不能真正地理 解開發(fā)一個(gè)高質(zhì)量的系統(tǒng)的好處。、測試的時(shí)機(jī)測試量會隨時(shí)間的推移發(fā)生改變。在一個(gè)競爭很激烈的市場里，爭取時(shí)間可能是制勝的關(guān)鍵， 開始可能不會在測試上

57、花多少時(shí)間，但幾年后如果市場分配格局已經(jīng)建立起來了，那么產(chǎn)品的質(zhì)量 就變得更重要了，測試量就要加大。測試量應(yīng)該針對合適的目標(biāo)進(jìn)行調(diào)整?；?Web的系統(tǒng)測試方法張友生摘要隨著Internet 和Intranet/Extranet的快速增長， Web已經(jīng)對商業(yè)、工業(yè)、銀行、財(cái)政、教育、政府和娛樂及我們的工作和生活產(chǎn)生了深遠(yuǎn)的影響。許多傳統(tǒng)的信息和數(shù)據(jù)庫系統(tǒng)正在被移植到互聯(lián)網(wǎng)上，電子商務(wù)迅速增長，早已超過了國界。范圍廣泛的、復(fù)雜的分布式應(yīng)用正在 Web環(huán)境中出現(xiàn)。Web的流行和無所不在，是因?yàn)樗芴峁┲С炙蓄愋蛢?nèi)容連接的信息發(fā)布，容易為最終用戶存取。正文Yogesh Deshpande和Stev

58、e Hansen 在1998年就提出了 Web工程的概念。 Web工程作為一門新 興的學(xué)科，提倡使用一個(gè)過程和系統(tǒng)的方法來開發(fā)高質(zhì)量的基于Web的系統(tǒng)。它使用合理的、科學(xué)的工程和管理原則，用嚴(yán)密的和系統(tǒng)的方法來開發(fā)、發(fā)布和維護(hù)基于Web的系統(tǒng)。目前，對于 web工程的研究主要是在國外開展的，國內(nèi)還剛剛起步。在基于 Web的系統(tǒng)開發(fā)中，如果缺乏嚴(yán)格的過程，我們在開發(fā)、發(fā)布、實(shí)施和維護(hù)Web的過程中，可能就會碰到一些嚴(yán)重的問題，失敗的可能性很大。而且，隨著基于Web的系統(tǒng)變得越來越復(fù)雜，一個(gè)項(xiàng)目的失敗將可能導(dǎo)致很多問題。當(dāng)這種情況發(fā)生時(shí)，我們對Web Internet的信心可能會無法挽救地動搖，從

59、而引起Web危機(jī)。并且， Web危機(jī)可能會比軟件開發(fā)人員所面對的軟件危機(jī)更加嚴(yán)重、更加廣泛。在Web工程過程中，基于 Web系統(tǒng)的測試、確認(rèn)和驗(yàn)收是一項(xiàng)重要而富有挑戰(zhàn)性的工作。基于 Web的系統(tǒng)測試與傳統(tǒng)的軟件測試不同，它不但需要檢查和驗(yàn)證是否按照設(shè)計(jì)的要求運(yùn)行，而且還13要測試系統(tǒng)在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進(jìn)行安全性 和可用性測試。然而，Internet和Web媒體的不可預(yù)見T使測試基于Web的系統(tǒng)變得困難。因此，我們必須為測試和評估復(fù)雜的基于Web的系統(tǒng)研究新的方法和技術(shù)。一般軟件的發(fā)布周期以月或以年計(jì)算，而Web應(yīng)用的發(fā)布周期以天計(jì)算甚至以小時(shí)計(jì)算

60、。Web測試人員必須處理更短的發(fā)布周期，測試人員和測試管理人員面臨著從測試傳統(tǒng)的C/S結(jié)構(gòu)和框架環(huán)境到測試快速改變的Web應(yīng)用系統(tǒng)的轉(zhuǎn)變。一、功能測試1、鏈接測試鏈接是Web應(yīng)用系統(tǒng)的一個(gè)主要特征，它是在頁面之間切換和指導(dǎo)用戶去一些不知道地址的頁 面的主要手段。鏈接測試可分為三個(gè)方面。首先，測試所有鏈接是否按指示的那樣確實(shí)鏈接到了該 鏈接的頁面；其次，測試所鏈接的頁面是否存在；最后，保證Web應(yīng)用系統(tǒng)上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。鏈接測試可以自動進(jìn)行，現(xiàn)在已經(jīng)有許多工具可以采用。鏈接測試必須在集成測試階段完成， 也就是說，在整個(gè) Web