軟件測試規(guī)范[陜西華商數(shù)碼信息股份有限公司] 軟件測試資料大全

1、軟件測試規(guī)范陜西華商數(shù)碼信息股份有限公司目 錄一.概述1二 軟件測試理論21.什么是軟件測試22.軟件測試的目標(biāo)2三.軟件測試流程31.軟件測試流程圖32.軟件測試流程細則43.軟件測試注意事項5四.軟件測試類型61.模塊測試62.子系統(tǒng)測試63.系統(tǒng)測試64.驗收測試6五.黑盒測試方法71.等價類劃分72.因果圖83.邊值分析法84.猜錯法85.隨機數(shù)法9六.白盒測試方法101.語句覆蓋102.判定理蓋103.條件覆蓋114.判定條件覆蓋115.條件組合覆蓋11七.測試錯誤類型12八.測試標(biāo)準(zhǔn)13附錄一 單元測試報告14附錄二 集成測試報告15附錄三 測試大綱16附錄四 測試大綱附錄17附錄

2、五 測試計劃18附錄六 程序錯誤報告19附錄七 測試分析報告20一.概述本規(guī)范是對項目軟件測試的一份指導(dǎo)性文件，對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標(biāo)準(zhǔn)、測試流程以及軟件產(chǎn)品開發(fā)單位所承擔(dān)的職責(zé)進行總體規(guī)范，以有效保證軟件產(chǎn)品的質(zhì)量。二 軟件測試理論1.什么是軟件測試 無論怎樣強調(diào)軟件測試的重要性和它對軟件可靠性的影響都不過分。在開發(fā)大型軟件系統(tǒng)的漫長過程中，面對著極其錯綜復(fù)雜的問題，人的主觀認識不可能完全符合客觀現(xiàn)實，與工程密切相關(guān)的各類人員之間的通信和配合也不可能完美無缺，因此，在軟件生命周期的每個階段都不可避免地會產(chǎn)生差錯。我們力求在每個階段結(jié)束之前通過嚴格的技術(shù)

3、審查，盡可能早地發(fā)現(xiàn)并糾正差錯；但是，經(jīng)驗表明審查并不能發(fā)現(xiàn)所有差錯，此外在編碼過程中還不可避免地會引入新的錯誤。如果在軟件投入生產(chǎn)性運行之前，沒有發(fā)現(xiàn)并糾正軟件中的大部分差錯，則這些差錯遲早會在生產(chǎn)過程中暴露出來，那時不僅改正這些錯誤的代價更高，而且往往會造成很惡劣的后果。測試的目的就是在軟件投入生產(chǎn)性運行之前，盡可能多地發(fā)現(xiàn)軟件中的錯誤。目前軟件測試仍然是保證軟件質(zhì)量的關(guān)鍵步驟，它是對軟件規(guī)格說明、設(shè)計和編碼的最后復(fù)審。軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對它做必要的測試(稱為單元測試)，模塊的編寫者和測試者是同一個人，編碼和單元測試屬于軟件生命周期的同一個階段

4、。在這個階段結(jié)束之后，對軟件系統(tǒng)還應(yīng)該進行各種綜合測試，這是軟件生命周期中的另一個獨立的階段，通常由專門的測試人員承擔(dān)這項工作。大量統(tǒng)計資料表明，軟件測試的工作量往往占軟件開發(fā)總工作量的40以上，在極端情況，測試那種關(guān)系人的生命安全的軟件所花費的成本，可能相當(dāng)于軟件工程其他開發(fā)步驟總成本的三倍到五倍。因此，必須高度重視軟件測試工作，絕不要以為寫出程序之后軟件開發(fā)工作就接近完成了，實際上，大約還有同樣多的開發(fā)工作量需要完成。僅就測試而言，它的目標(biāo)是發(fā)現(xiàn)軟件中的錯誤，但是，發(fā)現(xiàn)錯誤并不是我們的最終日的。軟件工程的根本目標(biāo)是開發(fā)出高質(zhì)量的完全符合用戶需要的軟件。2.軟件測試的目標(biāo)下面這些規(guī)則也可以看

5、作是測試的目標(biāo)或定義： (1)測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程； (2)好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案； (3)成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。從上述規(guī)則可以看出，測試的正確定義是“為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程”。這和某些人通常想象的“測試是為了表明程序是正確的”，“成功的測試是沒有發(fā)現(xiàn)錯誤的測試”等等是完全相反的。正確認識測試的目標(biāo)是十分重要的，測試目標(biāo)決定了測試方案的設(shè)計。如果為了表明程序是正確的而進行測試，就會設(shè)計一些不易暴露錯誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯誤，就會力求設(shè)計出最能暴露錯誤的測試方案。由于測試的目

6、標(biāo)是暴露程序中的錯誤，從心理學(xué)角度看，由程序的編寫者自己進行測試是不恰當(dāng)?shù)?。因此，在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外，應(yīng)該認識到測試決不能證明程序是正確的。即使經(jīng)過了最嚴格的測試之后，仍然可能還有沒被發(fā)現(xiàn)的錯誤潛藏在程序中。測試只能查找出程序中的錯誤，不能證明程序中沒有錯誤。三.軟件測試流程1.軟件測試流程圖參與需求分析，了解項目需求內(nèi)容了解需求變更制定測試計劃 編寫測試大綱編寫單元測試報告項目組進行修改配合開發(fā)人員進行單元測試 n編寫集成測試報告 y項目組進行修改配合開發(fā)人員進行集成測試 n y收集待測軟件的各種相關(guān)文檔及需求分析、軟件設(shè)計規(guī)范和上一級測試報告復(fù)合

7、n項目組進行修改對待測軟件進行測試 y填寫錯誤報告編寫測試分析報告提交測試分析報告所有文件存檔編寫用戶操作手冊（幫助文件）與用戶方協(xié)商測試相關(guān)事宜向用戶方提供內(nèi)部測試匯總報告配合用戶方進行軟件測試用戶方簽字確認錯誤報告項目經(jīng)理與用戶方測試進行確認2.軟件測試流程細則需求階段：測試人員了解項目需求收集結(jié)果包括項目需求規(guī)格說明、功能結(jié)構(gòu)及模塊劃分等。測試人員了解項目需求變更。測試人員會同項目主管根據(jù)軟件需求制定并確認測試計劃（附錄五）。設(shè)計編碼階段：測試人員制定測試大綱（附錄三、附錄四）。項目開發(fā)組對完成的功能模塊進行單元測試，測試人員參與單元測試過程；單元測試完成，產(chǎn)生單元測試報告。所有單元測試

8、及相應(yīng)的修改完成后，項目開發(fā)組組織進行集成測試，測試人員參與集成測試過程；集成測試完成后，產(chǎn)生集成測試報告。測試階段：項目開發(fā)組完成集成測試后，提交測試所要求的待測軟件及各種文檔、手冊、前期測試報告（需求分析、軟件設(shè)計規(guī)范和上一級測試報告附錄一、附錄二）。測試組安排和協(xié)調(diào)測試設(shè)備、環(huán)境等準(zhǔn)備工作。測試組按測試計劃、測試大綱的要求對待測軟件進行有效性測試、集成測試。填寫錯誤報告（附錄六）。對修改后的情況進行復(fù)合。測試結(jié)束后，測試人員對測試結(jié)果進行匯總；測試主管審核測試結(jié)果，得出測試結(jié)論；測試組進行測試分析和評估，編寫測試分析報告（附錄七）。提交測試分析報告。將所有文件存檔。對測試未通過的待測軟件

9、，測試人員匯總并向項目開發(fā)組提交測試錯誤報告。項目開發(fā)組對測試錯誤報告進行確認，對有爭議的問題可由上一級技術(shù)負責(zé)人確認和仲裁；項目開發(fā)組針對測試錯誤報告進行逐項修改，修改完成后再將待測軟件及錯誤修改情況提交及測試組進行回歸測試。待測軟件測試通過后，項目測評結(jié)束。制作用戶操作手冊（幫助文件）。用戶測試階段：項目開發(fā)組與用戶方商定測試計劃、測試內(nèi)容、測試環(huán)境等。項目測試組向用戶方提供項目內(nèi)部測試匯總報告。由項目開發(fā)組或測試組配合用戶進行用戶方測試。由用戶方編制用戶方軟件測試報告（程序錯誤報告和測試分析報告），若用戶方不愿或無法編制測試報告，則經(jīng)與用戶方協(xié)商由我方測試人員編制用戶方測試報告，經(jīng)用戶方

10、簽字后即可生效。項目經(jīng)理與用戶方對用戶方測試進行確認。3.軟件測試注意事項根據(jù)軟件開發(fā)規(guī)范仔細檢查軟件的界面是否合乎要求。（每一個子界面也應(yīng)如此） 其中，應(yīng)注意提示信息和軟件開發(fā)商信息是否正確。小的圖標(biāo)是否合乎要求。檢查菜單當(dāng)中的各項功能和功能按鈕是否能正確使用。根據(jù)軟件開發(fā)規(guī)范和用戶需求及軟件詳細設(shè)計設(shè)計測試用例。（以邊界值法、等價類劃分法為主）。對功能界面要求注意與功能相關(guān)的信息顯示及顯示位置是否正確。數(shù)據(jù)輸入界面應(yīng)注意文字格式及數(shù)字和文字的區(qū)別。是否能夠正確保存信息。數(shù)據(jù)查詢（顯示）界面應(yīng)注意顯示信息是否正確和完整。是否能正確查詢。對打印功能要求注意打印出的報表是否正確。（包括報表各項信

11、息、數(shù)據(jù)信息和報表字體等）。這一項測試主要是對軟件的錯誤處理功能進行測試。就是進行錯誤的操作或輸入錯誤的數(shù)據(jù)，檢查軟件對這些情況是否能做出判斷并予以提示。特殊情況下要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系。對測試錯誤結(jié)果一定要有一個確認的過程。一般有a測試出來的錯誤，一定要有一個b來確認，嚴重的錯誤可以召開評審會進行討論和分析。制定嚴格的測試計劃，并把測試時間安排得盡量寬松，不要希望在極短的時間內(nèi)完成一個高水平的測試?；貧w測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現(xiàn)的現(xiàn)象并不少見。

12、妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。四.軟件測試類型除非是測試一個小程序，否則一開始就把整個系統(tǒng)作為一個單獨的實體來測試是不現(xiàn)實的。與開發(fā)過程類似，測試過程也必須分步驟進行，每個步驟在邏輯上是前一個步驟的繼續(xù)。大型軟件系統(tǒng)通常由若干個子系統(tǒng)組成，每個子系統(tǒng)又由許多模塊組成。因此，大型軟件系統(tǒng)的測試基本上由下述幾個步驟組成：1.模塊測試在設(shè)計得好的軟件系統(tǒng)中，每個模塊完成一個清晰定義的子功能，而且這個子功能和同級其他模塊的功能之間沒有相互依賴關(guān)系。因此，有可能把每個模塊作為一個單獨的實體來測試，而且通常比較容易設(shè)計檢驗?zāi)K正確性的測試方案。模塊測試的目的是保

13、證每個模塊作為一個單元能正確運行，所以模塊測試通常又稱為單元測試。在這個測試步驟中所發(fā)現(xiàn)的往往是編碼和詳細設(shè)計的錯誤。2.子系統(tǒng)測試子系統(tǒng)測試是把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試。模塊相互間的協(xié)調(diào)和通信是這個測試過程中的主要問題，因此這個步驟著重測試模塊的接口。3.系統(tǒng)測試系統(tǒng)測試是把經(jīng)過測試的于系統(tǒng)裝配成一個完整的系統(tǒng)來測試。在這個過程中不僅應(yīng)該發(fā)現(xiàn)設(shè)計和編碼的錯誤，還應(yīng)該驗證系統(tǒng)確實能提供需求說明書中指定的功能，而且系統(tǒng)的動態(tài)特性也符合預(yù)定要求。在這個測試步驟中發(fā)現(xiàn)的往往是軟件設(shè)計中的錯誤，也可能發(fā)現(xiàn)需求說明中的錯誤。不論是子系統(tǒng)測試還是系統(tǒng)測試，都兼有檢測和組裝兩重含義，通

14、常稱為集成測試。4.驗收測試驗收測試把軟件系統(tǒng)作為單一的實體進行測試，測試內(nèi)容與系統(tǒng)測試基本類似，但是它是在用戶積極參與下進行的，而且可能主要使用實際數(shù)據(jù)(系統(tǒng)將來要處理的信息)進行測試。驗收測試的目的是驗證系統(tǒng)確實能夠滿足用戶的需要，在這個測試步驟中發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。五.黑盒測試方法 黑盒測試(blackbox testing)又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)范的測試(即ec顛cationbased testing)。用這種方法進行測試時，被測程序被當(dāng)作看不見內(nèi)部的黑盒。在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者僅依據(jù)程序功能的需求規(guī)范考慮確定測試用例和推斷測試結(jié)

15、果的正確性。因此黑盒測試是從用戶觀點出發(fā)的測試，黑盒測試直觀的想法就是既然程序被規(guī)定做某些事，那我們就看看它是不是在任何情況下都做的對。完整的“任何情況”是無法驗證的，為此黑盒測試也有一套產(chǎn)生測試用例的方法，以產(chǎn)生有限的測試用例而覆蓋足夠多的“任何情況”。由于黑盒測試不需要了解程序內(nèi)部結(jié)構(gòu)，所以許多高層的測試如確認測試、系統(tǒng)測試、驗收測試都采用黑盒測試。黑盒測試首先是程序通常的功能性測試。要求：每個軟件特性必須被一個測試用例或一個被認可的異常所覆蓋。用數(shù)據(jù)類型和數(shù)據(jù)值的最小集測試。用一系列真實的數(shù)據(jù)類型和數(shù)據(jù)值運行，測試超負荷、飽和及其他“最壞情況”的結(jié)果；用假想的數(shù)據(jù)類型和數(shù)據(jù)值運行，測試排

16、斥不規(guī)則輸入的能力；對影響性能的關(guān)鍵模塊，如基本算法、應(yīng)測試單元性能(包括精度、時間、容量等)。不僅要考核“程序應(yīng)該做什么?”還要考察“程序是否做了不該做的2”同時還要考察程序在其他一些情況下是否正常。這些情況包括數(shù)據(jù)類型和數(shù)據(jù)值的異常等等。下述幾種方法：(a)等價類劃分，(b)因果圖方法，(c)邊值分析法，(d)猜錯法，(e)隨機數(shù)法，就是從更廣泛的角度來進行黑盒測試。每一個方法都力圖能涵蓋更多的“任何情況”，但又各有長處，綜合使用這些方法，會得到一個較好的測試用例集。1.等價類劃分 等價類劃分是一種典型的黑盒測試方法。等價類是指某個輸入域的集合。它表示對揭露程序中的錯誤來說，集合中的每個輸

17、入條件是等效的。因此我們只要在一個集合中選取一個測試數(shù)據(jù)即可。等價類劃分的辦法是把程序的輸入域劃分成若干等價類，然后從每個部分中選取少數(shù)代表性數(shù)據(jù)當(dāng)作測試用例。這樣就可使用少數(shù)測試用例檢驗程序在一大類情況下的反映。 在考慮等價類時，應(yīng)該注意區(qū)別以下兩種不同的情況：有效等價類：有效等價類指的是對程序的規(guī)范是有意義的、合理的輸入數(shù)據(jù)所構(gòu)成的集合。在具體問題中，有效等價類可以是一個，也可以是多個。無效等價類：無效等價類指對程序的規(guī)范是不合理的或無意義的輸入數(shù)據(jù)所構(gòu)成的集合。對于具體的問題，無效等價類至少應(yīng)有一個，也可能有多個。確定等價類有以下幾條原則：如果輸入條件規(guī)定了取值范圍或值的個數(shù)，則可確定一

18、個有效等價類和兩個無效等價類。例如，程序的規(guī)范中提到的輸入條包括“項數(shù)可以從1到999”，則可取有效等價類為“l(fā)考項數(shù)999”，無效等價類為“項數(shù)l，及“項數(shù)999”。輸入條件規(guī)定了輸入值的集合，或是規(guī)定了“必須如何”的條件，則可確定一個有效等價類和一個無效等價類。如某程序涉及標(biāo)識符，其輸入條件規(guī)定“標(biāo)識符應(yīng)以字母開頭”則“以字母開頭者”作為有效等價類，“以非字母開頭”作為無效等價類。如果我們確知，已劃分的等價類中各元素在程序中的處理方式是不同的，則應(yīng)將此等價類進一步劃分成更小等價類。輸入條件有效等價類無效等價類。 根據(jù)已列出的等價類表，按以下步驟確定測試用例：為每個等價類規(guī)定一個唯一的編號；

19、設(shè)計一個測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復(fù)這一步，最后使得所有有效等價類均被測試用例所覆蓋；設(shè)計一個新的測試用例，使其只覆蓋一個無效等價類。重復(fù)這一步，使所有無效等價類均被覆蓋。這里強調(diào)每次只覆蓋一個無效等價類。這是因為一個測試用例中如果含有多個缺陷，有可能在測試中只發(fā)現(xiàn)其中的一個，另一些被忽視。等價類劃分法能夠全面、系統(tǒng)地考慮黑盒測試的測試用例設(shè)計問題，但是沒有注意選用一些“高效的”、“有針對性的”測試用例。后面介紹的邊值分析法可以彌補這一缺點。2.因果圖等價類劃分法并沒有考慮到輸入情況的各種組合。這樣雖然各個輸入條件單獨可能出錯的情況已經(jīng)看到了，但多個輸入情況組合起來可

20、能出錯的情況卻被忽略。采用因果圖方法能幫助我們按一定步驟選擇一組高效的測試用例，同時，還能為我們指出程序規(guī)范的描述中存在什么問題。利用因果圖導(dǎo)出測試用例需要經(jīng)過以下幾個步驟：分析程序規(guī)范的描述中哪些是原因，哪些是結(jié)果。原因常常是輸入條件或是輸入條件的等價類。結(jié)果是輸出條件。分析程序規(guī)范的描述中語義的內(nèi)容，并將其表示成連接各個原因與各個結(jié)果的“因果圖”。由于語法或環(huán)境的限制，有些原因和結(jié)果的組合情況是不可能出現(xiàn)的。為表明這些特定的情況，在因果圖上使用持殊的符號標(biāo)明約束條件。把因果圖轉(zhuǎn)換成判定表。把判定表的每一列寫成一個測試用例。3.邊值分析法 邊值分析法是列出單元功能、輸入、狀態(tài)及控制的合法邊界

21、值和非法邊界值，設(shè)計測試用例，包含全部邊界值的方法。典型地包括if語句中的判別值，定義域、值域邊界，空或畸形輸入，末受控狀態(tài)等。邊值分析法不是一類找一個例子的方法，而是以邊界情況的處理作為主要目標(biāo)專門設(shè)計測試用例的方法。另外，邊值分析不僅考查輸入的邊值，也要考慮輸出的邊值。這是從人們的經(jīng)驗得出的一種有效方法。人們發(fā)現(xiàn)許多軟件錯誤只是在下標(biāo)、數(shù)據(jù)結(jié)構(gòu)和標(biāo)量值的邊界值及其上、下出現(xiàn)，運行這個區(qū)域的測試用例發(fā)現(xiàn)錯誤的概率很高。用邊值分析法設(shè)計測試用例時，有以下幾條原則：如果輸入條件規(guī)定了取值范圍，或是規(guī)定了值的個數(shù)，則應(yīng)以該范圍的邊界內(nèi)及剛剛超出范圍的邊界外的值，或是分別對最大、最小及稍小于最小、稍

22、大于最大個數(shù)作為測試用例。如有規(guī)范“某文件可包含l至255”個記錄“，則測試用例可選1和255及0和256等。針對規(guī)范的每個輸出條件使用原則a。如果程序規(guī)范中提到的輸入或輸出域是個有序的集合(如順序文件、表格等)就應(yīng)注意選取有序集的第一個和最后一個元素作為測試用例。分析規(guī)范，盡可能找出可能的邊界條件。一個典型的邊值分析例子是三角形分類程序。選取a，b，c構(gòu)成三角形三邊，“任意兩邊之和大于第三邊”為邊界條件。邊值分析相等價類劃分側(cè)重不同，對等價類劃分是一個補充。如上述三角形問題，選取a3，b4，c5，a2，b4，c7則覆蓋有效和無效等價類。如果能在等價類劃分中注入邊值分析的思想。在每個等價類中不

23、只選取一個覆蓋用例，而是進而選取該等價類的邊界值等價類劃分法將更有效，最后可以用邊值分析法再補充一些測試用例。4.猜錯法 猜錯法在很大程度上是憑經(jīng)驗進行的，是憑人們對過去所作的測試工作結(jié)果的分析，對所揭示的缺陷的規(guī)律性作直覺的推測來發(fā)現(xiàn)缺陷的。一個采用兩分法的檢索程序，典型地可以列出下面幾種測試情況：被檢索的表只有一項或為空表；表的項數(shù)恰好是2的冪次；表的項數(shù)比2的冪次多1等。猜錯法充分發(fā)揮人的經(jīng)驗，在一個測試小組中集思廣益，方便實用，特別在軟件測試基礎(chǔ)較差的情況下，很好地組織測試小組 (也可以有外來人員)進行錯誤猜測，是有效的測試方法。5.隨機數(shù)法即測試用例的參數(shù)是隨機數(shù)。它可以自動生成，因

24、此自動化程度高。使用大量隨機測試用例測試通過的程序會提高用戶對程序的信心。但其關(guān)鍵在于隨機數(shù)的規(guī)律是否符合使用實際。六.白盒測試方法白盒法測試，是以程序的內(nèi)部邏輯為基礎(chǔ)，有選擇地執(zhí)行程序中最有代表性的通路。因此，白盒法也叫邏輯覆蓋法(bgic mm陰e)。最徹底的邏輯覆蓋法，是覆蓋程序巾的誨一條通路。但當(dāng)程序中含有大量循環(huán)時，要執(zhí)行每一條通路是44可能的。因此，我們只能寄希望于程序的覆蓋度盡可能高一些。目前常用的一些覆蓋標(biāo)準(zhǔn)有：語句覆蓋、判定覆蓋、條件澄蓋、判定滌件覆蓋、條件組合覆蓋、路徑覆蓋等。白盒法考慮的是測試用例對程序內(nèi)部邏輯的覆蓋程度，所以又稱為邏輯覆蓋法。最徹底的白盒法是覆蓋程序中的

25、每一條路徑，但這不可能，我們希望覆蓋的路徑盡可能多一些。為了衡量測試的覆蓋程度，需要建立一些標(biāo)準(zhǔn)，目前常用的一些覆蓋標(biāo)準(zhǔn)是：(1)語句覆蓋；(2)判定覆蓋；(3)條件覆蓋；(4)判定條件覆蓋；(5)條件組合覆蓋。1.語句覆蓋程序的某次運行一般并不能執(zhí)行到其中的每一個語句，因此，如果某語句含有一個錯誤，而它在測試中沒執(zhí)行，這個錯誤就不可能被發(fā)現(xiàn)。為了提高發(fā)現(xiàn)錯誤的可能性，應(yīng)該在測試時至少要執(zhí)行程序中的每一個語句。所謂“語句覆蓋”測試標(biāo)準(zhǔn)，它的含義是：選擇足夠的測試用例，使得程序中每個語句至少都能執(zhí)行一次。例子：procedure example(var a,b,c:real)beginif(a1

26、)and(b=0)then x:=x/a；if(a=2)or(x1)then x:=x+lend;為了使程序中每個語句至少執(zhí)行一次，只需設(shè)計一個能通過路徑ace的例子就可以了。例如選擇輸入數(shù)據(jù)為：a=2，b=0，x=3就可達到“語句覆蓋”標(biāo)準(zhǔn)。顯然，語句覆蓋是一個比較弱的覆蓋標(biāo)準(zhǔn)。如果第一個條件語句中的and錯誤地寫成or，上面的測試用例是不能發(fā)現(xiàn)這個錯誤的，或者是第二個條件語句中x1誤寫成x0，這個測試用例也不能暴露它。我們還可以舉出許多錯誤情況是上述測試數(shù)據(jù)不能發(fā)現(xiàn)的。所以，一般認為“語句覆蓋”是很不充分的最低的一種覆蓋標(biāo)準(zhǔn)。2.判定理蓋比“語句覆蓋”稍強的覆蓋標(biāo)準(zhǔn)是“判定覆蓋”(或稱分支

27、覆蓋)。這個標(biāo)準(zhǔn)是：執(zhí)行足夠的測試用例，使得程序中每個判定至少都獲得一次“真”值和“假”值，即使得程序中的每一個分文至少都通過一次。對上面那個例子，如果設(shè)計兩個測試用例，就可以達到“判定覆蓋”的標(biāo)難。為此，我們可以選擇輸人數(shù)據(jù)為：(1)a=3，b=0，x=l(2)a=2，b=1，x=3“判定覆蓋”比“語句覆蓋”嚴格，因為如果每個分支都執(zhí)行過了，自然每個語句也就執(zhí)行了。3.條件覆蓋它的含義是：執(zhí)行足夠的測試用例，使得判定中每個條件獲得各種可能的結(jié)果。對于例子程序,我們只需設(shè)計以下兩個測試用例就可滿足這標(biāo)準(zhǔn)：(1)a2，bo，x4(沿路徑ace執(zhí)行)(2)a1，bl，xl(沿路徑an執(zhí)行)雖然同樣

28、只要兩個測試用例，但它比判定覆蓋中兩個測試用例更有效。一般來說，“條件覆蓋”比“判定覆蓋”強，但是，并不總是如此，滿足“條件覆蓋”不一定滿足“判定覆蓋”。例如對語句。 if(a and b)then s設(shè)計兩個測試用例：a“真”b“假”和a“假”b“真”。對于上例我們設(shè)計兩個測試用例為： (1)a1，bo，x3 (2)a2，bl，x1亦是如此，它們能滿足“條件覆蓋”但不滿足“判定覆蓋”。4.判定條件覆蓋 針對上面的問題引出了另一種覆蓋標(biāo)準(zhǔn)，這就是“判定條件覆蓋”，它的含義是：執(zhí)行足夠的測試用例，同時滿足判定覆蓋和條件覆蓋的要求。顯然，它比“判定覆蓋”和“條件覆蓋”都強。 對于例子程序，我們選取

29、測試用例： (1)a=2，b=0，x=4 (2)a=1，b=l，x=l它滿足判定條件覆蓋標(biāo)準(zhǔn)。值得指出，看起來“判定條件覆蓋”似乎是比較合理的，應(yīng)成為我們的目標(biāo)，但是事實并非如此，因為大多數(shù)計算機不能用一條指令對多個條件作出判定，而必須將源程序中對多個條件的判定分解成幾個簡單判定。這個討論說明了，盡管“判定條件覆蓋”看起來能使各種條件取到所有可能的值，但實際上并不一定能檢查到這樣的程度。針對這種情況，有下面的條件組合覆蓋標(biāo)準(zhǔn)。5.條件組合覆蓋“條件組合覆蓋”的含義是：執(zhí)行足夠的測試用例，使得每個判定中條件的各種可能組合都至少執(zhí)行一次。這是一個最強的邏輯覆蓋標(biāo)準(zhǔn)。再看例子程序，必須使測試用例覆蓋

30、八種組合結(jié)果(1)a1，b=0 (5)a=2，x1(2)a1，b0 (6)a=2，x1(3)al，b=0 (7)a2，x1(4)a1，b0 (8)a2，x1必須注意到，(5)、(6)、(7)、(8)四種情況是第二個條件語句的條件組合，而x的值在該語句之前是要經(jīng)過計算的，所以我們還必須根據(jù)程序的邏輯推算出在程序的人口點x的輸入值應(yīng)是什么。要測試八個組合結(jié)果并不是意味著需要八種測試用例，事實上，我們能用四種測試用例來覆蓋它們：(1)a2，bo，x4；(2)a2，b1，xl；(3)al，bo，x2；(4)a1，b1，xl。上面四個例子雖然滿足條件組合覆蓋，但并不能覆蓋程序中的每一條路徑，可以看出條件

31、組合覆蓋仍然是不徹底的，在白盒測試時，要設(shè)法彌補這個缺陷。七.測試錯誤類型本規(guī)范定義以下五類測試錯誤類型。a類嚴重錯誤，包括以下各種錯誤：由于程序所引起的死機,非法退出死循環(huán)數(shù)據(jù)庫發(fā)生死鎖因錯誤操作導(dǎo)致的程序中斷功能錯誤與數(shù)據(jù)庫連接錯誤數(shù)據(jù)通訊錯誤b類較嚴重錯誤，包括以下各種錯誤： 程序錯誤程序接口錯誤數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件c類一般性錯誤，包括以下各種錯誤：操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）打印內(nèi)容、格式錯誤簡單的輸入限制未放在前臺進行控制刪除操作未給出提示數(shù)據(jù)庫表中有過多的空字段d類較小錯誤，包括以下各種錯誤：界面不規(guī)范輔助說明描述不清楚輸入輸出不

32、規(guī)范長操作未給用戶提示提示窗口文字未采用行業(yè)術(shù)語可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志e類測試建議八.測試標(biāo)準(zhǔn)黑盒測試的通過準(zhǔn)則一般有：單元功能同設(shè)計需求一致；規(guī)定的路徑覆蓋率及覆蓋類達到要求，且單元執(zhí)行正確；所規(guī)定的黑盒測試手段被使用，且單元執(zhí)行正確；對殘留錯誤有合法解釋或被認可暫留；雖然路徑覆蓋率不能達到，但其他各測試的錯誤查出率趨產(chǎn)0或穩(wěn)定(時間的長短視情況而定)。各類軟件測試合格須符合以下標(biāo)準(zhǔn)。a類錯誤b類錯誤c類錯誤d類錯誤e類建議無無1%5%暫不作要求以上比例為錯誤占總測試模塊的比例。軟件產(chǎn)品未經(jīng)測試合格，不允許出公司。附錄一 單元測試報告1 測試過程與結(jié)果1.1 （某程序模塊/文

33、檔名稱）測試測試對象：（某程序模塊/文檔）測試方面：（設(shè)計規(guī)范/應(yīng)用功能及流程/程序代碼）責(zé)任人：測試人及測試時間：問題及影響、處理結(jié)果：1.2 （某程序模塊/文檔名稱）測試測試對象：（某程序模塊/文檔）測試方面：（設(shè)計規(guī)范/應(yīng)用功能及流程/程序代碼）責(zé)任人：測試人及測試時間：問題及影響、處理結(jié)果：2 測試結(jié)論對單元測試的結(jié)果評價。 測試負責(zé)人： 審核（項目經(jīng)理）： 年 月 日 年 月 日附錄二 集成測試報告項目名稱項目編號測試人測試時間問題類型： 程序代碼 數(shù)據(jù)庫 項目文檔問題及影響描述、處理結(jié)果（可加附頁）測試結(jié)論測試負責(zé)人： 年 月 日 審核（項目經(jīng)理）： 年 月 日附錄三 測試大綱1

34、概述1.1 編寫目的可照抄下列語句，也可適當(dāng)修改。本文檔的編寫目的在于為xxxx（軟件名稱）軟件測試人員提供詳細的測試步驟和測試數(shù)據(jù)，以保證測試人員對軟件測試的正確性和完整性。1.2 參考資料說明軟件測試所需的資料（需求分析、設(shè)計規(guī)范等）。1.3 術(shù)語和縮寫詞說明本次測試所涉及到的專業(yè)術(shù)語和縮寫詞等。1.4 測試內(nèi)容和測試種類2 系統(tǒng)結(jié)構(gòu)圖表形式表示。3 測試目的4 測試環(huán)境4.1 硬件列出進行本次測試所需的硬件資源的型號、配置和廠家。4.2 軟件列出進行本次測試所需的軟件資源，包括操作系統(tǒng)和支持軟件（不含待測軟件）的名稱、版本、廠家。5 人員列出一份清單,說明在整個測試期間人員的數(shù)量、時間、

35、技術(shù)水平的要求。6 測試說明可以把整個測試過程按邏輯劃分為幾個組（包括測試計劃中描述的總體測試要求的每個方面），并給每個組命名一個標(biāo)識符。6.1 測試1名稱及標(biāo)識符說明6.1.1 測試概述對測試1進行一個總體描述,主要說明這組測試的基本內(nèi)容。6.1.2 測試準(zhǔn)備描述本測試開始前系統(tǒng)必須具備的狀態(tài)和數(shù)據(jù)。6.1.3 測試步驟對各測試操作按先后順序進行編號。具體操作和數(shù)據(jù)見附錄。6.2 測試2名稱及標(biāo)識符說明 測評組： 年 月 日附錄四 測試大綱附錄本附錄描述了各測試步驟的詳細說明，在填入測試結(jié)果后，可直接作為測試記錄。內(nèi)容較多時，可一頁只放一個測試說明。測試名稱：標(biāo)識符：測試時間：測試人：操作序

36、號錯誤等級測試輸入說明輸入的具體數(shù)據(jù)或動作預(yù)期輸出說明預(yù)期的輸出或結(jié)果實際輸出說明實際的輸出或結(jié)果操作序號錯誤等級測試輸入說明輸入的具體數(shù)據(jù)或動作預(yù)期輸出實際輸出附錄五 測試計劃1 概述1.1 編寫目的可照抄下列語句，也可適當(dāng)修改。本文檔的編寫目的在于為整個測試階段的管理工作和技術(shù)工作提供指南；確定測試的內(nèi)容和范圍，為評價系統(tǒng)提供依據(jù)。1.2 參考資料說明軟件測試所需的資料（需求分析、設(shè)計規(guī)范等）。1.3 術(shù)語和縮寫詞說明本次測試所涉及到的專業(yè)術(shù)語和縮寫詞等。1.4 測試種類說明本次測試所屬的測試種類（單元測試、集成測試、有效性測試、系統(tǒng)測試、用戶測試）及測試的對象。2 系統(tǒng)描述簡要描述被測軟

37、件系統(tǒng)，可用圖表加解釋的形式，說明被測系統(tǒng)的輸入、基本處理功能及輸出，為進行測試提供一個提綱。3 測試環(huán)境3.1 硬件列出進行本次測試所需的硬件資源的型號、配置和廠家。3.2 軟件列出進行本次測試所需的軟件資源，包括操作系統(tǒng)和支持軟件（不含待測軟件）的名稱、版本、廠家。4 測試安排4.1 （子系統(tǒng)1名稱和項目唯一標(biāo)識號）4.1.1 測試總體要求描述本次測試的要求，如：對所有功能進行正確性測試；使用一些虛假值、最大值和錯誤值對軟件進行測試；對軟件進行錯誤檢測和出錯恢復(fù)的測試；對特定環(huán)境條件的組合，用模擬測試數(shù)據(jù)對軟件進行測試；使用從環(huán)境中提取的“真實數(shù)據(jù)”作為輸入，對軟件進行測試。4.1.2 主

38、要測試內(nèi)容列出提綱。4.1.3 測試進度安排給出進行測試工作的時間安排。4.2 （子系統(tǒng)2名稱和項目唯一標(biāo)識號）5 測試數(shù)據(jù)的記錄、整理和分析說明對本次測試得到數(shù)據(jù)的記錄、整理和分析的方法和存檔要求。 審核： 年 月 日 批準(zhǔn)： 年 月 日附錄六 程序錯誤報告（系統(tǒng)名稱） 測試項目項目名稱測試類型模塊名稱模塊名稱版本測試時間測試批次序號錯誤等級錯 誤 描 述修改情況復(fù) 核測試人： 附錄七 測試分析報告1 概述1.1 編寫目的編寫本文檔的目的在于通過對測試結(jié)果的分析得到對軟件的評價；為糾正軟件缺陷提供依據(jù)；使用戶對系統(tǒng)運行建立信心。1.2 參考資料說明軟件測試所需的資料（需求分析、設(shè)計規(guī)范等）。1.3 術(shù)語和縮寫詞說明本次測試所涉及到的專業(yè)術(shù)語和縮寫詞等。2 測試對象包括測試項目、測試類型、測試批次（本測試類型的第幾次測試）、測試時間等。3 測試分析3.1 測試結(jié)果分析列出測試結(jié)果分析記錄,并按下列模板產(chǎn)生bug分布表和bug分布圖。分析模版：從軟件測試中發(fā)現(xiàn)的并最終確認的錯誤點等級數(shù)量來評估：從以上提出的bug等級來統(tǒng)計等級和數(shù)量的一個分布情