軟件系統(tǒng)測試規(guī)范

1、 上海興漢科技公司軟件測試規(guī)范 目 錄 TOC o 1-4 h z HYPERLINK l _Toc536327309 一.概述 PAGEREF _Toc536327309 h 1 HYPERLINK l _Toc536327310 二 軟件測試理論 PAGEREF _Toc536327310 h 2 HYPERLINK l _Toc536327311 1.什么是軟件測試 PAGEREF _Toc536327311 h 2 HYPERLINK l _Toc536327312 2.軟件測試的目標 PAGEREF _Toc536327312 h 2 HYPERLINK l _Toc53632731

2、3 三.軟件測試流程 PAGEREF _Toc536327313 h 3 HYPERLINK l _Toc536327314 1.軟件測試流程圖 PAGEREF _Toc536327314 h 3 HYPERLINK l _Toc536327315 2.軟件測試流程細則 PAGEREF _Toc536327315 h 4 HYPERLINK l _Toc536327316 3.軟件測試注意事項 PAGEREF _Toc536327316 h 5 HYPERLINK l _Toc536327317 四.軟件測試類型 PAGEREF _Toc536327317 h 6 HYPERLINK l _T

3、oc536327318 1.模塊測試 PAGEREF _Toc536327318 h 6 HYPERLINK l _Toc536327319 2.子系統(tǒng)測試 PAGEREF _Toc536327319 h 6 HYPERLINK l _Toc536327320 3.系統(tǒng)測試 PAGEREF _Toc536327320 h 6 HYPERLINK l _Toc536327321 4.驗收測試 PAGEREF _Toc536327321 h 6 HYPERLINK l _Toc536327322 五.黑盒測試方法 PAGEREF _Toc536327322 h 7 HYPERLINK l _Toc

4、536327323 1.等價類劃分 PAGEREF _Toc536327323 h 7 HYPERLINK l _Toc536327324 2.因果圖 PAGEREF _Toc536327324 h 8 HYPERLINK l _Toc536327325 3.邊值分析法 PAGEREF _Toc536327325 h 8 HYPERLINK l _Toc536327326 4.猜錯法 PAGEREF _Toc536327326 h 8 HYPERLINK l _Toc536327327 5.隨機數(shù)法 PAGEREF _Toc536327327 h 9 HYPERLINK l _Toc53632

5、7334 七.測試錯誤類型 PAGEREF _Toc536327334 h 12 HYPERLINK l _Toc536327335 八.測試標準 PAGEREF _Toc536327335 h 13 HYPERLINK l _Toc536327336 附錄一 單元測試報告 PAGEREF _Toc536327336 h 14 HYPERLINK l _Toc536327337 附錄二 集成測試報告 PAGEREF _Toc536327337 h 15 HYPERLINK l _Toc536327338 附錄三 測試大綱 PAGEREF _Toc536327338 h 16 HYPERLINK

6、 l _Toc536327339 附錄四 測試大綱附錄 PAGEREF _Toc536327339 h 17 HYPERLINK l _Toc536327340 附錄五 測試計劃 PAGEREF _Toc536327340 h 18 HYPERLINK l _Toc536327341 附錄六 程序錯誤報告 PAGEREF _Toc536327341 h 19 HYPERLINK l _Toc536327342 附錄七 測試分析報告 PAGEREF _Toc536327342 h 20一.概述本規(guī)范是對項目軟件測試的一份指導(dǎo)性文件，對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標準

7、、測試流程以及軟件產(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ù)審查，盡可能早地發(fā)現(xiàn)并糾正差錯；但是，經(jīng)驗表明審查并不能發(fā)現(xiàn)所有差錯，此外在編碼過程中還不可避免地會引入新的錯誤。如果在軟件投入生產(chǎn)性運行之前，沒有發(fā)現(xiàn)并糾正軟件中的大部分差錯

8、，則這些差錯遲早會在生產(chǎn)過程中暴露出來，那時不僅改正這些錯誤的代價更高，而且往往會造成很惡劣的后果。測試的目的就是在軟件投入生產(chǎn)性運行之前，盡可能多地發(fā)現(xiàn)軟件中的錯誤。目前軟件測試仍然是保證軟件質(zhì)量的關(guān)鍵步驟，它是對軟件規(guī)格說明、設(shè)計和編碼的最后復(fù)審。軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對它做必要的測試(稱為單元測試)，模塊的編寫者和測試者是同一個人，編碼和單元測試屬于軟件生命周期的同一個階段。在這個階段結(jié)束之后，對軟件系統(tǒng)還應(yīng)該進行各種綜合測試，這是軟件生命周期中的另一個獨立的階段，通常由專門的測試人員承擔(dān)這項工作。大量統(tǒng)計資料表明，軟件測試的工作量往往占軟件開發(fā)

9、總工作量的40以上，在極端情況，測試那種關(guān)系人的生命安全的軟件所花費的成本，可能相當(dāng)于軟件工程其他開發(fā)步驟總成本的三倍到五倍。因此，必須高度重視軟件測試工作，絕不要以為寫出程序之后軟件開發(fā)工作就接近完成了，實際上，大約還有同樣多的開發(fā)工作量需要完成。僅就測試而言，它的目標是發(fā)現(xiàn)軟件中的錯誤，但是，發(fā)現(xiàn)錯誤并不是我們的最終日的。軟件工程的根本目標是開發(fā)出高質(zhì)量的完全符合用戶需要的軟件。2.軟件測試的目標下面這些規(guī)則也可以看作是測試的目標或定義： (1)測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程； (2)好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案； (3)成功的測試是發(fā)現(xiàn)了至今為止尚

10、未發(fā)現(xiàn)的錯誤的測試。從上述規(guī)則可以看出，測試的正確定義是“為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程”。這和某些人通常想象的“測試是為了表明程序是正確的”，“成功的測試是沒有發(fā)現(xiàn)錯誤的測試”等等是完全相反的。正確認識測試的目標是十分重要的，測試目標決定了測試方案的設(shè)計。如果為了表明程序是正確的而進行測試，就會設(shè)計一些不易暴露錯誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯誤，就會力求設(shè)計出最能暴露錯誤的測試方案。由于測試的目標是暴露程序中的錯誤，從心理學(xué)角度看，由程序的編寫者自己進行測試是不恰當(dāng)?shù)?。因此，在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外，應(yīng)該認識到測試決不能證明程序是正

11、確的。即使經(jīng)過了最嚴格的測試之后，仍然可能還有沒被發(fā)現(xiàn)的錯誤潛藏在程序中。測試只能查找出程序中的錯誤，不能證明程序中沒有錯誤。三.軟件測試流程1.軟件測試流程圖參與需求分析，了解項目需求內(nèi)容了解需求變更制定測試計劃 編寫測試用例回歸測試執(zhí)行測試用例填寫錯誤報告編寫測試總結(jié)報告提交測試總結(jié)報告提交bug，項目組進行修改項目組進行修改 No Yes Y2.軟件測試流程細則需求階段：測試人員了解項目需求收集結(jié)果包括項目需求規(guī)格說明、功能結(jié)構(gòu)及模塊劃分等。測試人員了解項目需求變更。測試人員會同項目主管根據(jù)軟件需求制定并確認測試計劃（附錄五）。設(shè)計編碼階段：測試人員制定測試用例（附錄三、附錄四）。項目開

12、發(fā)組對完成的功能模塊進行單元測試所有單元測試及相應(yīng)的修改完成后，項目開發(fā)組組織進行集成測試測試階段：項目開發(fā)組完成集成測試后，提交測試所要求的待測軟件及各種文檔、手冊、前期測試報告（需求分析、軟件設(shè)計規(guī)范。測試組安排和協(xié)調(diào)測試設(shè)備、環(huán)境等準備工作。測試組按測試計劃、測試用例的要求對被測系統(tǒng)進行系統(tǒng)測試。填寫錯誤報告對修改后的情況進行回歸測試。測試結(jié)束后，測試人員對測試結(jié)果進行匯總；測試主管審核測試結(jié)果，得出測試結(jié)論；測試組進行測試分析和評估，編寫測試總結(jié)報告提交測試總結(jié)報告。對測試未通過的待測軟件，測試人員匯總并向項目開發(fā)組提交測試錯誤報告。項目開發(fā)組對測試錯誤報告進行確認，對有爭議的問題可由

13、上一級技術(shù)負責(zé)人確認和仲裁；項目開發(fā)組針對測試錯誤報告進行逐項修改，修改完成后再將待測軟件及錯誤修改情況提交及測試組進行回歸測試。待測軟件測試通過后，項目測評結(jié)束。3.軟件測試注意事項根據(jù)軟件開發(fā)規(guī)范仔細檢查軟件的界面是否合乎要求。（每一個子界面也應(yīng)如此） 其中，應(yīng)注意提示信息和軟件開發(fā)商信息是否正確。小的圖標是否合乎要求。檢查菜單當(dāng)中的各項功能和功能按鈕是否能正確使用。根據(jù)軟件開發(fā)規(guī)范和用戶需求及軟件詳細設(shè)計設(shè)計測試用例（以邊界值法、等價類劃分法為主）。對功能界面要求注意與功能相關(guān)的信息顯示及顯示位置是否正確。數(shù)據(jù)輸入界面應(yīng)注意文字格式及數(shù)字和文字的區(qū)別。是否能夠正確保存信息。數(shù)據(jù)查詢（顯示

14、）界面應(yīng)注意顯示信息是否正確和完整。是否能正確查詢。對打印功能要求注意打印出的報表是否正確。（包括報表各項信息、數(shù)據(jù)信息和報表字體等）。這一項測試主要是對軟件的錯誤處理功能進行測試。就是進行錯誤的操作或輸入錯誤的數(shù)據(jù)，檢查軟件對這些情況是否能做出判斷并予以提示。特殊情況下要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系。對測試錯誤結(jié)果一定要有一個確認的過程。一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。制定嚴格的測試計劃，并把測試時間安排得盡量寬松，不要希望在極短的時間

15、內(nèi)完成一個高水平的測試?；貧w測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現(xiàn)的現(xiàn)象并不少見。妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。四.軟件測試類型除非是測試一個小程序，否則一開始就把整個系統(tǒng)作為一個單獨的實體來測試是不現(xiàn)實的。與開發(fā)過程類似，測試過程也必須分步驟進行，每個步驟在邏輯上是前一個步驟的繼續(xù)。大型軟件系統(tǒng)通常由若干個子系統(tǒng)組成，每個子系統(tǒng)又由許多模塊組成。因此，大型軟件系統(tǒng)的測試基本上由下述幾個步驟組成：1.模塊測試在設(shè)計得好的軟件系統(tǒng)中，每個模塊完成一個清晰定義的子功能，而且這個子功能和同級其他模塊的功能之間沒有相互依賴關(guān)系。因此

16、，有可能把每個模塊作為一個單獨的實體來測試，而且通常比較容易設(shè)計檢驗?zāi)K正確性的測試方案。模塊測試的目的是保證每個模塊作為一個單元能正確運行，所以模塊測試通常又稱為單元測試。在這個測試步驟中所發(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)的往

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

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

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

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

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

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

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

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

25、超出范圍的邊界外的值，或是分別對最大、最小及稍小于最小、稍大于最大個數(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則覆蓋有效和無效等價類

26、。如果能在等價類劃分中注入邊值分析的思想。在每個等價類中不只選取一個覆蓋用例，而是進而選取該等價類的邊界值等價類劃分法將更有效，最后可以用邊值分析法再補充一些測試用例。4.猜錯法 猜錯法在很大程度上是憑經(jīng)驗進行的，是憑人們對過去所作的測試工作結(jié)果的分析，對所揭示的缺陷的規(guī)律性作直覺的推測來發(fā)現(xiàn)缺陷的。猜錯法充分發(fā)揮人的經(jīng)驗，在一個測試小組中集思廣益，方便實用，特別在軟件測試基礎(chǔ)較差的情況下，很好地組織測試小組 (也可以有外來人員)進行錯誤猜測，是有效的測試方法。六.測試錯誤類型本規(guī)范定義以下五類測試錯誤類型。A類嚴重錯誤，包括以下各種錯誤：由于程序所引起的死機,非法退出死循環(huán)因錯誤操作導(dǎo)致的程

27、序中斷頁面鏈接不正確B類較嚴重錯誤，包括以下各種錯誤： 功能實現(xiàn)錯誤數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件列在說明中的需求未在最終系統(tǒng)中實現(xiàn)瀏覽器兼容性錯誤C類一般性錯誤，包括以下各種錯誤：頁面刷新錯誤編碼時數(shù)據(jù)類型、長度定義錯誤簡單的輸入限制未放在前臺進行控制刪除操作未給出提示D類較小錯誤，包括以下各種錯誤：界面不規(guī)范輔助說明描述不清楚可編輯區(qū)和不可編輯區(qū)不明顯按鈕或標簽上有拼寫錯誤的單詞、不正確的大小寫滾動條無效E類測試建議 容易給用戶誤解和岐議的提示 界面需要改進的 對有疑慮的文檔，提出修改建議七.bug提交規(guī)則Bug提交到Bugzilla，點new進行新建，Component

28、選擇模塊內(nèi)容 ，severity選擇相應(yīng)問題嚴重性，summary輸入問題簡要描述，Description寫入操作步驟，預(yù)期結(jié)果，實際結(jié)果，如圖：點擊Add an Attachment可以插入附件八.測試通過標準黑盒測試的通過準則一般有：單元功能同設(shè)計需求一致；規(guī)定的路徑覆蓋率及覆蓋類達到要求，且單元執(zhí)行正確；所規(guī)定的黑盒測試手段被使用，且單元執(zhí)行正確；對殘留錯誤有合法解釋或被認可暫留；雖然路徑覆蓋率不能達到，但其他各測試的錯誤查出率趨產(chǎn)0或穩(wěn)定(時間的長短視情況而定)。各類軟件測試合格須符合以下標準。A類錯誤B類錯誤C類錯誤D類錯誤E類建議無無1%5%暫不作要求以上比例為錯誤占總測試模塊的比

29、例。軟件產(chǎn)品未經(jīng)測試合格，不允許出公司。九.后記軟件測試規(guī)范的目的是使測試報告易于閱讀和理解、易于PM對Bug的分配管理、易于開發(fā)人員處理測試中出現(xiàn)的Bug，而不是用過份的約束和絕對的限制來束縛測試人員的測試過程。標準是人定的，它并不是神圣不可侵犯的。所以，測試的規(guī)范是簡潔、完整和便于管理性的。而且這個規(guī)范需要在我們的實際工作當(dāng)中繼續(xù)修改直到完善。附錄一 單元測試報告1 測試過程與結(jié)果1.1 （某程序模塊/文檔名稱）測試測試對象：（某程序模塊/文檔）測試方面：（設(shè)計規(guī)范/應(yīng)用功能及流程/程序代碼）責(zé)任人：測試人及測試時間：問題及影響、處理結(jié)果：1.2 （某程序模塊/文檔名稱）測試測試對象：（某

30、程序模塊/文檔）測試方面：（設(shè)計規(guī)范/應(yīng)用功能及流程/程序代碼）責(zé)任人：測試人及測試時間：問題及影響、處理結(jié)果：2 測試結(jié)論對單元測試的結(jié)果評價。 測試負責(zé)人： 審核（項目經(jīng)理）： 年 月 日 年 月 日附錄二 集成測試報告項目名稱項目編號測試人測試時間問題類型： 程序代碼 數(shù)據(jù)庫 項目文檔問題及影響描述、處理結(jié)果（可加附頁）測試結(jié)論測試負責(zé)人： 年 月 日 審核（項目經(jīng)理）： 年 月 日附錄三 測試計劃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)描述簡要描述被測軟件系統(tǒng)，可用圖表加解釋的形式，說明被測系統(tǒng)的輸入、基本處理功能及輸出，為進行測試提供一個提綱。3 測試環(huán)境3.1 硬件列出進行本次測試所需的硬件資源的型號、配置和廠家。3.2 軟件列出進行本次測試所需的軟件資源，包括操作