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

1、上海興漢科技公司軟件測試規(guī)范一.概述 TOC o 1-5 h z HYPERLINK l bookmark2 o Current Document 軟件測試?yán)碚? HYPERLINK l bookmark4 o Current Document .什么是軟件測試 2 HYPERLINK l bookmark6 o Current Document .軟件測試的目標(biāo) 2 HYPERLINK l bookmark8 o Current Document .軟件測試流程4 HYPERLINK l bookmark10 o Current Document .軟件測試流程圖 4 HYPERLINK l

2、 bookmark12 o Current Document .軟件測試流程細(xì)則 5 HYPERLINK l bookmark14 o Current Document .軟件測試注意事項(xiàng) 6 HYPERLINK l bookmark16 o Current Document .軟件測試類型8 HYPERLINK l bookmark18 o Current Document .模塊測試8 HYPERLINK l bookmark20 o Current Document .子系統(tǒng)測試8 HYPERLINK l bookmark22 o Current Document .系統(tǒng)測試8 HYPE

3、RLINK l bookmark24 o Current Document .驗(yàn)收測試8 HYPERLINK l bookmark26 o Current Document .黑盒測試方法10 HYPERLINK l bookmark28 o Current Document .等價(jià)類劃分10 HYPERLINK l bookmark30 o Current Document .因果圖12 HYPERLINK l bookmark32 o Current Document .邊值分析法12 HYPERLINK l bookmark34 o Current Document .猜錯(cuò)法13.隨機(jī)數(shù)

4、法錯(cuò)誤!未定義書簽。 HYPERLINK l bookmark36 o Current Document 七.測試錯(cuò)誤類型14 HYPERLINK l bookmark40 o Current Document 八.測試標(biāo)準(zhǔn)16附錄一 單元測試報(bào)告17附錄二 集成測試報(bào)告18附錄三 測試大綱.錯(cuò)誤!未定義書簽。附錄四 測試大綱附錄22附錄五 測試計(jì)劃.錯(cuò)誤!未定義書簽。附錄六 程序錯(cuò)誤報(bào)告23附錄七 測試分析報(bào)告24一.概述本規(guī)范是對項(xiàng)目軟件測試的一份指導(dǎo)性文件，對軟件測試過程中所涉及到的測試?yán)碚?、測試類 型、測試方法、測試標(biāo)準(zhǔn)、測試流程以及軟件產(chǎn)品開發(fā)單位所承擔(dān)的職責(zé)進(jìn)行總體規(guī)范，以有效保

5、證軟件產(chǎn)品的質(zhì)量。二 軟件測試?yán)碚?什么是軟件測試無論怎樣強(qiáng)調(diào)軟件測試的重要性和它對軟件可靠性的影響都不過分。在開發(fā)大型軟件系統(tǒng)的漫 長過程中，面對著極其錯(cuò)綜復(fù)雜的問題，人的主觀認(rèn)識不可能完全符合客觀現(xiàn)實(shí)，與工程密切相關(guān) 的各類人員之間的通信和配合也不可能完美無缺，因此，在軟件生命周期的每個(gè)階段都不可避免地 會產(chǎn)生差錯(cuò)。我們力求在每個(gè)階段結(jié)束之前通過嚴(yán)格的技術(shù)審查，盡可能早地發(fā)現(xiàn)并糾正差錯(cuò)；但 是，經(jīng)驗(yàn)表明審查并不能發(fā)現(xiàn)所有差錯(cuò)，此外在編碼過程中還不可避免地會引入新的錯(cuò)誤。如果在 軟件投入生產(chǎn)性運(yùn)行之前，沒有發(fā)現(xiàn)并糾正軟件中的大部分差錯(cuò)，則這些差錯(cuò)遲早會在生產(chǎn)過程中 暴露出來，那時(shí)不僅改正這些

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

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

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

9、，仍然可能還有沒被發(fā)現(xiàn)的錯(cuò)誤潛藏在程序中。 測試只能查找出程序中的錯(cuò)誤，不能證明程序中沒有錯(cuò)誤。三.軟件測試流程1.軟件測試流程圖參與需求分析，了解項(xiàng)目需求內(nèi)容了解需求變更制定測試計(jì)劃編寫測試用例回歸測試2.軟件測試流程細(xì)則需求階段：測試人員了解項(xiàng)目需求收集結(jié)果包括項(xiàng)目需求規(guī)格說明、功能結(jié)構(gòu)及模塊劃分等。測試人員了解項(xiàng)目需求變更。測試人員會同項(xiàng)目主管根據(jù)軟件需求制定并確認(rèn)測試計(jì)劃（附錄五）。設(shè)計(jì)編碼階段：測試人員制定測試用例（附錄三、附錄四）。項(xiàng)目開發(fā)組對完成的功能模塊進(jìn)行單元測試所有單元測試及相應(yīng)的修改完成后，項(xiàng)目開發(fā)組組織進(jìn)行集成測試測試階段：項(xiàng)目開發(fā)組完成集成測試后，提交測試所要求的待測

10、軟件及各種文檔、手冊、前期測試報(bào)告（需 求分析、軟件設(shè)計(jì)規(guī)范。測試組安排和協(xié)調(diào)測試設(shè)備、環(huán)境等準(zhǔn)備工作。測試組按測試計(jì)劃、測試用例的要求對被測系統(tǒng)進(jìn)行系統(tǒng)測試。填寫錯(cuò)誤報(bào)告對修改后的情況進(jìn)行回歸測試。測試結(jié)束后，測試人員對測試結(jié)果進(jìn)行匯總；測試主管審核測試結(jié)果，得出測試結(jié)論；測試組 進(jìn)行測試分析和評估，編寫測試總結(jié)報(bào)告提交測試總結(jié)報(bào)告。對測試未通過的待測軟件，測試人員匯總并向項(xiàng)目開發(fā)組提交測試錯(cuò)誤報(bào)告。項(xiàng)目開發(fā)組對測試錯(cuò)誤報(bào)告進(jìn)行確認(rèn)，對有爭議的問題可由上一級技術(shù)負(fù)責(zé)人確認(rèn)和仲裁；項(xiàng) 目開發(fā)組針對測試錯(cuò)誤報(bào)告進(jìn)行逐項(xiàng)修改，修改完成后再將待測軟件及錯(cuò)誤修改情況提交及測試組 進(jìn)行回歸測試。待測軟件

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

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

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

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

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

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

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

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

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

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

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

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

23、則應(yīng)以該范圍的邊界內(nèi)及剛剛超出范圍 的邊界外的值，或是分別對最大、最小及稍小于最小、稍大于最大個(gè)數(shù)作為測試用例。如有規(guī)范“某 文件可包含l至255”個(gè)記錄“，則測試用例可選1和255及0和256等。針對規(guī)范的每個(gè)輸出條件使用原則a。如果程序規(guī)范中提到的輸入或輸出域是個(gè)有序的集合（如順序文件、表格等）就應(yīng)注意選取有序 集的第一個(gè)和最后一個(gè)元素作為測試用例。分析規(guī)范，盡可能找出可能的邊界條件。一個(gè)典型的邊值分析例子是三角形分類程序。選取a， b，c構(gòu)成三角形三邊，“任意兩邊之和大于第三邊”為邊界條件。邊值分析相等價(jià)類劃分側(cè)重不同， 對等價(jià)類劃分是一個(gè)補(bǔ)充。如上述三角形問題，選取a = 3,b =

24、4,c = 5,a = 2,b = 4,c = 7則覆 蓋有效和無效等價(jià)類。如果能在等價(jià)類劃分中注入邊值分析的思想。在每個(gè)等價(jià)類中不只選取一個(gè) 覆蓋用例，而是進(jìn)而選取該等價(jià)類的邊界值等價(jià)類劃分法將更有效，最后可以用邊值分析法再補(bǔ)充 一些測試用例。4.猜錯(cuò)法猜錯(cuò)法在很大程度上是憑經(jīng)驗(yàn)進(jìn)行的，是憑人們對過去所作的測試工作結(jié)果的分析，對所揭示 的缺陷的規(guī)律性作直覺的推測來發(fā)現(xiàn)缺陷的。猜錯(cuò)法充分發(fā)揮人的經(jīng)驗(yàn)，在一個(gè)測試小組中集思廣益，方便實(shí)用，特別在軟件測試基礎(chǔ)較差 的情況下，很好地組織測試小組（也可以有外來人員）進(jìn)行錯(cuò)誤猜測，是有效的測試方法。六.測試錯(cuò)誤類型本規(guī)范定義以下五類測試錯(cuò)誤類型。A類一嚴(yán)

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

26、bug提交規(guī)則Bug提交到Bugzilla，點(diǎn)new進(jìn)行新建，Component選擇模塊內(nèi)容，severity選擇相應(yīng)問題嚴(yán)重性，summary輸入問題簡要描述，Description寫入操作步驟，預(yù)期結(jié)果，實(shí)際結(jié)果，如圖：操作步驟；L用管理員帳號登陸系統(tǒng) 乙點(diǎn)管理員，進(jìn)入管理員模式 m .點(diǎn)管理者，再點(diǎn)學(xué)員.點(diǎn)目錄中的“Coursecontent內(nèi)容范圍”.點(diǎn)“在線課程：黃芳的測試二前面的注冊按鈿，點(diǎn)提交 預(yù)期結(jié)果；注冊成功，不提示系統(tǒng)錯(cuò)誤信息 實(shí)際結(jié)果：注冊成功，提示系統(tǒng)錯(cuò)誤信息，見截圖點(diǎn)擊Add an Attachment可以插入附件八.測試通過標(biāo)準(zhǔn)黑盒測試的通過準(zhǔn)則一般有：單元功能同設(shè)

27、計(jì)需求一致；規(guī)定的路徑覆蓋率及覆蓋類達(dá)到要求，且單元執(zhí)行正確；所規(guī)定的黑盒測試手段被使用，且單元執(zhí)行正確；對殘留錯(cuò)誤有合法解釋或被認(rèn)可暫留；雖然路徑覆蓋率不能達(dá)到，但其他各測試的錯(cuò)誤查出率趨產(chǎn)0或穩(wěn)定（時(shí)間的長短視情況而定）。各類軟件測試合格須符合以下標(biāo)準(zhǔn)。A類錯(cuò)誤B類錯(cuò)誤C類錯(cuò)誤D類錯(cuò)誤E類建議無無1%5%暫不作要求以上比例為錯(cuò)誤占總測試模塊的比例。軟件產(chǎn)品未經(jīng)測試合格，不允許出公司。九.后記軟件測試規(guī)范的目的是使測試報(bào)告易于閱讀和理解、易于PM對Bug的分配管理、易于開發(fā) 人員處理測試中出現(xiàn)的Bug，而不是用過份的約束和絕對的限制來束縛測試人員的測試過程。標(biāo)準(zhǔn) 是人定的，它并不是神圣不可侵

28、犯的。所以，測試的規(guī)范是簡潔、完整和便于管理性的。而且這個(gè) 規(guī)范需要在我們的實(shí)際工作當(dāng)中繼續(xù)修改直到完善。測試過程與結(jié)果（某程序模塊/文檔名稱）測試測試對象：（某程序模塊/文檔）測試方面：（設(shè)計(jì)規(guī)范/應(yīng)用功能及流程/程序代碼）責(zé)任人：測試人及測試時(shí)間：問題及影響、處理結(jié)果：（某程序模塊/文檔名稱）測試測試對象：（某程序模塊/文檔）測試方面：（設(shè)計(jì)規(guī)范/應(yīng)用功能及流程/程序代碼）責(zé)任人：測試人及測試時(shí)間：問題及影響、處理結(jié)果：測試結(jié)論對單元測試的結(jié)果評價(jià)。測試負(fù)責(zé)人：審核（項(xiàng)目經(jīng)理）：附錄二 集成測試報(bào)告測試結(jié)論測試負(fù)責(zé)人：年 月 日審核（項(xiàng)目經(jīng)理）：年 月日附錄三 測試計(jì)劃概述編寫目的可照抄下

29、列語句，也可適當(dāng)修改。本文檔的編寫目的在于為整個(gè)測試階段的管理工作和技術(shù)工作提供指南；確定測試的內(nèi)容和范 圍，為評價(jià)系統(tǒng)提供依據(jù)。參考資料說明軟件測試所需的資料（需求分析、設(shè)計(jì)規(guī)范等）。術(shù)語和縮寫詞說明本次測試所涉及到的專業(yè)術(shù)語和縮寫詞等。測試種類說明本次測試所屬的測試種類（單元測試、集成測試、有效性測試、系統(tǒng)測試、用戶測試）及 測試的對象。系統(tǒng)描述簡要描述被測軟件系統(tǒng)，可用圖表加解釋的形式，說明被測系統(tǒng)的輸入、基本處理功能及輸出， 為進(jìn)行測試提供一個(gè)提綱。測試環(huán)境硬件列出進(jìn)行本次測試所需的硬件資源的型號、配置和廠家。軟件列出進(jìn)行本次測試所需的軟件資源，包括操作系統(tǒng)和支持軟件（不含待測軟件）的名稱、版本、 廠家。測試安排4.1（子系