項目測試操作過程及方法項目測試操作過程及方法項目測試操作過程及方法xxx公司項目測試操作過程及方法文件編號：文件日期：修訂次數(shù)：第1.0次更改批準(zhǔn)審核制定方案設(shè)計，管理制度項目測試操作過程及方法擬制：楊冬日期：2016-2-16審核：日期：修訂記錄日期修訂版本描述作者目錄1概述 42軟件測試?yán)碚?4什么是軟件測試 4軟件測試的目標(biāo) 53軟件測試流程 6軟件測試流程圖 6軟件測試流程細(xì)則 7需求分析 7測試計劃 8測試設(shè)計 8測試軟/硬件環(huán)境搭建 9測試數(shù)據(jù)準(zhǔn)備 9用例執(zhí)行 10測試變更 10測試匯報 11驗收測試 11軟件測試注意事項 114軟件測試分類 13模塊測試 13子系統(tǒng)測試 13.系統(tǒng)測試 13驗收測試 14回歸測試 14Alpha測試 14Beta測試 145黑盒測試方法 14等價類劃分 15邊值分析法 17因果圖 18猜錯法 18隨機數(shù)法 196白盒測試方法 19語句覆蓋 20.判定理蓋 20.條件覆蓋 21.判定／條件覆蓋 21條件組合覆蓋 227標(biāo)準(zhǔn)文檔 231概述本規(guī)范是對軟件測試的一份指導(dǎo)性文件，對軟件測試過程中所涉及到的測試?yán)碚?、測試類型、測試方法、測試標(biāo)準(zhǔn)、測試流程以及軟件產(chǎn)品開發(fā)單位所承擔(dān)的職責(zé)進行總體規(guī)范，以有效保證軟件產(chǎn)品的質(zhì)量。2軟件測試?yán)碚撌裁词擒浖y試無論怎樣強調(diào)軟件測試的重要性和它對軟件可靠性的影響都不過分。在開發(fā)大型軟件系統(tǒng)的漫長過程中，面對著極其錯綜復(fù)雜的問題，人的主觀認(rèn)識不可能完全符合客觀現(xiàn)實，與工程密切相關(guān)的各類人員之間的通信和配合也不可能完美無缺，因此，在軟件生命周期的每個階段都不可避免地會產(chǎn)生差錯。我們力求在每個階段結(jié)束之前通過嚴(yán)格的技術(shù)審查，盡可能早地發(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ù)審。軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對它做必要的測試(稱為單元測試)，模塊的編寫者和測試者是同一個人，編碼和單元測試屬于軟件生命周期的同一個階段。在這個階段結(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ì)量的完全符合用戶需要的軟件。軟件測試的目標(biāo)下面這些規(guī)則也可以看作是測試的目標(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)錯誤的測試”等等是完全相反的。正確認(rèn)識測試的目標(biāo)是十分重要的，測試目標(biāo)決定了測試方案的設(shè)計。如果為了表明程序是正確的而進行測試，就會設(shè)計一些不易暴露錯誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯誤，就會力求設(shè)計出最能暴露錯誤的測試方案。由于測試的目標(biāo)是暴露程序中的錯誤，從心理學(xué)角度看，由程序的編寫者自己進行測試是不恰當(dāng)?shù)摹Ｒ虼?，在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外，應(yīng)該認(rèn)識到測試決不能證明程序是正確的。即使經(jīng)過了最嚴(yán)格的測試之后，仍然可能還有沒被發(fā)現(xiàn)的錯誤潛藏在程序中。測試只能查找出程序中的錯誤，不能證明程序中沒有錯誤。3軟件測試流程軟件測試流程圖軟件測試流程細(xì)則需求分析測試人員和開發(fā)人員均應(yīng)參加需求評審、設(shè)計評審。對《需求說明書》、《系統(tǒng)界面原型》和《軟件設(shè)計說明書》等進行閱讀和審查，與產(chǎn)品經(jīng)理、項目經(jīng)理溝通，了解并熟悉系統(tǒng)業(yè)務(wù)邏輯，同時根據(jù)系統(tǒng)功能復(fù)雜度，系統(tǒng)業(yè)務(wù)復(fù)雜度估算開發(fā)時間和有效測試執(zhí)行時間，為項目總計劃和測試計劃的制定提供參考和依據(jù)。通過對文檔分析，分解各功能模塊，各功能點，為測試用例設(shè)計提供數(shù)據(jù)依據(jù)。測試人員了解項目需求變更。重點明確需求如下：1、功能測試需求2、性能測試需求3、壓力測試需求4、系統(tǒng)容量需求5、系統(tǒng)安全性需求6、安裝測試需求7、數(shù)據(jù)轉(zhuǎn)換需求8、兼容性需求9、項目文檔1）產(chǎn)品溝通郵件2）客戶、售前人員，產(chǎn)品溝通記錄3）項目文檔資料4）業(yè)務(wù)背景資料測試計劃根據(jù)需求文檔和項目計劃制定測試計劃。測試計劃旨在說明各測試階段任務(wù)、人員分配、時間安排、測試要點、工作規(guī)范等。測試計劃在策略和方法方面說明如何計劃、組織和管理測試項目。測試計劃完成后應(yīng)該在項目組內(nèi)進行評審。測試人員會同項目主管根據(jù)軟件需求制定并確認(rèn)《測試計劃》。測試設(shè)計在設(shè)計測試方案時，首先分解測試內(nèi)容，對于一個復(fù)雜系統(tǒng)，通?？梢苑纸獬蓭讉€互相獨立的子系統(tǒng)，正確地劃分這些子系統(tǒng)及其邏輯組成部分和相互間的關(guān)系，可以降低測試的復(fù)雜性，減少重復(fù)和遺漏，也便于設(shè)計和開發(fā)測試用例，有效的組織測試，將系統(tǒng)分析人員的開發(fā)分析文檔加工成以測試為角度的功能點分析文檔，重要的是描述對系統(tǒng)分解后每個功能點逐一的校驗描述，包括何種方法測試、何種數(shù)據(jù)測試、期望測試結(jié)果等。然后以功能點分析文檔作為依據(jù)進行測試用例的設(shè)計，設(shè)計測試用例是關(guān)系到測試效果以至軟件質(zhì)量的關(guān)鍵性一步，也是一項非常細(xì)致的工作，根據(jù)對具體的北側(cè)系統(tǒng)的分析和測試要求，逐步細(xì)化測試的范圍和內(nèi)容，設(shè)計具體的測試過程和數(shù)據(jù)，同時將結(jié)果寫成可以按步執(zhí)行的《測試用例》文檔。每個測試用例必須包括以下幾個部分：（1）

編號和模塊（2）

測試的任務(wù)項和功能點（3）

輸入和使用的數(shù)據(jù)和操作過程（4）

期望的輸出結(jié)果（5）

其他特殊的環(huán)境要求、次序要求、時間要求等（6）輸出《測試用例》文檔測試用例是為實施測試而向被測試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置以及期望結(jié)果的一個特定的集合。解決要測什么、怎么測和如何衡量的問題。依據(jù)用戶需求分析說明書、測試方案來設(shè)計測試用例，發(fā)現(xiàn)需求與設(shè)計中的問題后，與項目經(jīng)理及時溝通確認(rèn)。1）測試用例設(shè)計方法a)測試用例的設(shè)計方法有等價類測試、邊界值分析、基于判定表的測試、基于因果圖的測試、基于狀態(tài)圖的測試、基于場景的測試。b)在設(shè)計測試用例時常用的設(shè)計方法有等價類測試、邊界值分析兩種方法。2）測試用例操作步驟a)在設(shè)計編寫測試用例時，根據(jù)需求文檔和開發(fā)文檔設(shè)計用例，評審?fù)ㄟ^后將使用該測試用例測試被測系統(tǒng)。b)在測試期間，發(fā)現(xiàn)用例描述不清、需求變更或用例設(shè)計錯誤，及時在統(tǒng)一文檔中記錄，待本輪測試結(jié)束后，更新基線用例。3）測試用例選擇準(zhǔn)則a)測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等；b)測試結(jié)果的可判定性：即測試執(zhí)行結(jié)果的正確性是可判定的或可評估的；c)測試結(jié)果的可再現(xiàn)性：即對同樣的測試用例,系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。測試軟/硬件環(huán)境搭建根據(jù)需求文檔提供的內(nèi)容，和開發(fā)部溝通確定測試項目所需的軟硬件環(huán)境，完成對測試項目所需軟硬件資源的準(zhǔn)備工作，使軟硬件資源得到滿足。測試數(shù)據(jù)準(zhǔn)備完成對測試項目基本數(shù)據(jù)的準(zhǔn)備操作，包括數(shù)據(jù)庫連接、用戶信息、用戶角色權(quán)限、單位組織等信息和測試相關(guān)的測試數(shù)據(jù)。用例執(zhí)行a)測試準(zhǔn)入條件項目開發(fā)組完成編碼后，提交測試所要求的待測軟件及各種設(shè)計文檔、手冊（附錄一、二）。同時開發(fā)人員經(jīng)過自測通過，至少保證程序可以正常運行；對應(yīng)的功能在正常流程下是可以正常使用。測試進行冒煙測試通過，開始進行正式測試。b)項目測試階段測試人員依據(jù)測試計劃和測試用例進行測試活動。測試一般分為兩個階段：(1)測試執(zhí)行階段：該階段測試人員測試出bug后將缺陷提交至缺陷管理庫JIRA。在缺陷的描述上，至少要包括以下一些方面內(nèi)容：標(biāo)題、模塊、重要程度、優(yōu)先級、操作描述；(2)回歸問題單：開發(fā)修改完bug之后，測試進行驗證回歸。c）測試退出標(biāo)準(zhǔn)功能需求覆蓋100%。所有用例全部執(zhí)行分析缺陷的趨勢的收斂的，且遺留問題符合公司定義的度量標(biāo)準(zhǔn)。測試過程中缺陷率達(dá)到公司系統(tǒng)測試質(zhì)量標(biāo)準(zhǔn)。測試變更當(dāng)需求變更，功能變化，測試人員根據(jù)變更情況，評估測試變更所需時間，提出變更風(fēng)險。如變更情況被項目組通過，測試人員將按上述流程進行變更測試。測試匯報測試結(jié)束后，測試人員對測試結(jié)果進行匯總；測試主管審核測試結(jié)果，得出測試結(jié)論；測試組進行測試分析和評估，編寫《測試分析報告》。提交《測試分析報告》。將所有文件存檔。對測試未通過的待測軟件，測試人員匯總并向項目開發(fā)組提交測試錯誤報告。項目開發(fā)組對測試錯誤報告進行確認(rèn)，對有爭議的問題可由上一級技術(shù)負(fù)責(zé)人確認(rèn)和仲裁；項目開發(fā)組針對測試錯誤報告進行逐項修改，修改完成后再將待測軟件及錯誤修改情況提交及測試組進行回歸測試。待測軟件測試通過后，項目測評結(jié)束。制作《用戶操作手冊》（幫助文件）。驗收測試a)項目經(jīng)理與實施人員溝通驗收事項。b)實施人員在客戶指定的環(huán)境下參照《安裝維護手冊》進行產(chǎn)品安裝調(diào)試，并把合同約定的文檔、源程序等交給客戶。c)實施人員對客戶進行系統(tǒng)操作方法培訓(xùn)。d)客戶試用系統(tǒng)開展業(yè)務(wù)，測試人員收集客戶反饋的問題；e)測試人員在驗收中發(fā)現(xiàn)或收集到用戶反饋的缺陷并告知項目經(jīng)理，并將缺陷記錄到JIRA中分派給適合的開發(fā)人員。f)開發(fā)人員分析缺陷的原因及解決該缺陷，并將該缺陷的解決方法及解決狀態(tài)更新JIRA。并將修改的代碼給予實施人員部署，待用戶驗證，直到交付。軟件測試注意事項根據(jù)《軟件開發(fā)規(guī)范》仔細(xì)檢查軟件的界面是否合乎要求。（每一個子界面也應(yīng)如此）其中，應(yīng)注意提示信息和軟件開發(fā)商信息是否正確。小的圖標(biāo)是否合乎要求。檢查菜單當(dāng)中的各項功能和功能按鈕是否能正確使用。根據(jù)《軟件開發(fā)規(guī)范》和《用戶需求》及《軟件詳細(xì)設(shè)計》設(shè)計測試用例。（以邊界值法、等價類劃分法為主）。對功能界面要求注意與功能相關(guān)的信息顯示及顯示位置是否正確。數(shù)據(jù)輸入界面應(yīng)注意文字格式及數(shù)字和文字的區(qū)別。是否能夠正確保存信息。數(shù)據(jù)查詢（顯示）界面應(yīng)注意顯示信息是否正確和完整。是否能正確查詢。對打印功能要求注意打印出的報表是否正確。（包括報表各項信息、數(shù)據(jù)信息和報表字體等）。這一項測試主要是對軟件的錯誤處理功能進行測試。就是進行錯誤的操作或輸入錯誤的數(shù)據(jù)，檢查軟件對這些情況是否能做出判斷并予以提示。特殊情況下要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系。對測試錯誤結(jié)果一定要有一個確認(rèn)的過程。一般有A測試出來的錯誤，一定要有一個B來確認(rèn)，嚴(yán)重的錯誤可以召開評審會進行討論和分析。制定嚴(yán)格的測試計劃，并把測試時間安排得盡量寬松，不要希望在極短的時間內(nèi)完成一個高水平的測試?；貧w測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現(xiàn)的現(xiàn)象并不少見。妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。4軟件測試分類除非是測試一個小程序，否則一開始就把整個系統(tǒng)作為一個單獨的實體來測試是不現(xiàn)實的。與開發(fā)過程類似，測試過程也必須分步驟進行，每個步驟在邏輯上是前一個步驟的繼續(xù)。大型軟件系統(tǒng)通常由若干個子系統(tǒng)組成，每個子系統(tǒng)又由許多模塊組成。因此，大型軟件系統(tǒng)的測試基本上由下述幾個步驟組成：模塊測試在設(shè)計得好的軟件系統(tǒng)中，每個模塊完成一個清晰定義的子功能，而且這個子功能和同級其他模塊的功能之間沒有相互依賴關(guān)系。因此，有可能把每個模塊作為一個單獨的實體來測試，而且通常比較容易設(shè)計檢驗?zāi)K正確性的測試方案。模塊測試的目的是保證每個模塊作為一個單元能正確運行，所以模塊測試通常又稱為單元測試。在這個測試步驟中所發(fā)現(xiàn)的往往是編碼和詳細(xì)設(shè)計的錯誤。子系統(tǒng)測試子系統(tǒng)測試是把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試。模塊相互間的協(xié)調(diào)和通信是這個測試過程中的主要問題，因此這個步驟著重測試模塊的接口。.系統(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)測試，都兼有檢測和組裝兩重含義，通常稱為集成測試。驗收測試驗收測試把軟件系統(tǒng)作為單一的實體進行測試，測試內(nèi)容與系統(tǒng)測試基本類似，但是它是在用戶積極參與下進行的，而且可能主要使用實際數(shù)據(jù)(系統(tǒng)將來要處理的信息)進行測試。驗收測試的目的是驗證系統(tǒng)確實能夠滿足用戶的需要，在這個測試步驟中發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤?；貧w測試

回歸測試是在軟件維護階段，對軟件進行修改之后進行的測試。其目的是檢驗對軟件進行的修改是否正確。這里，修改的正確性有兩重含義：一是所作的修改達(dá)到了預(yù)定目的，如錯誤得到改正，能夠適應(yīng)新的運行環(huán)境等等；二是不影響軟件的其他功能的正確性。Alpha測試在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試；測試后，仍然會有少量的設(shè)計變更。這種測試一般由最終用戶或其他人員員完成，不能由程序員或測試員完成。Beta測試當(dāng)開發(fā)和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其他人員員完成，不能由程序員或測試員完成。5黑盒測試方法黑盒測試(black—boxtesting)又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)范的測試(即ec顛cation—basedtesting)。用這種方法進行測試時，被測程序被當(dāng)作看不見內(nèi)部的黑盒。在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者僅依據(jù)程序功能的需求規(guī)范考慮確定測試用例和推斷測試結(jié)果的正確性。因此黑盒測試是從用戶觀點出發(fā)的測試，黑盒測試直觀的想法就是既然程序被規(guī)定做某些事，那我們就看看它是不是在任何情況下都做的對。完整的“任何情況”是無法驗證的，為此黑盒測試也有一套產(chǎn)生測試用例的方法，以產(chǎn)生有限的測試用例而覆蓋足夠多的“任何情況”。由于黑盒測試不需要了解程序內(nèi)部結(jié)構(gòu)，所以許多高層的測試如確認(rèn)測試、系統(tǒng)測試、驗收測試都采用黑盒測試。黑盒測試首先是程序通常的功能性測試。要求：每個軟件特性必須被一個測試用例或一個被認(rèn)可的異常所覆蓋。用數(shù)據(jù)類型和數(shù)據(jù)值的最小集測試。用一系列真實的數(shù)據(jù)類型和數(shù)據(jù)值運行，測試超負(fù)荷、飽和及其他“最壞情況”的結(jié)果；用假想的數(shù)據(jù)類型和數(shù)據(jù)值運行，測試排斥不規(guī)則輸入的能力；對影響性能的關(guān)鍵模塊，如基本算法、應(yīng)測試單元性能(包括精度、時間、容量等)。不僅要考核“程序應(yīng)該做什么”還要考察“程序是否做了不該做的2”同時還要考察程序在其他一些情況下是否正常。這些情況包括數(shù)據(jù)類型和數(shù)據(jù)值的異常等等。下述幾種方法：(a)等價類劃分，(b)因果圖方法，(c)邊值分析法，(d)猜錯法，(e)隨機數(shù)法，就是從更廣泛的角度來進行黑盒測試。每一個方法都力圖能涵蓋更多的“任何情況”等價類劃分等價類劃分是一種典型的黑盒測試方法。等價類是指某個輸入域的集合。它表示對揭露程序中的錯誤來說，集合中的每個輸入條件是等效的。因此我們只要在一個集合中選取一個測試數(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ù)，則可確定一個有效等價類和兩個無效等價類。例如，程序的規(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ī)定一個唯一的編號；設(shè)計一個測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復(fù)這一步，最后使得所有有效等價類均被測試用例所覆蓋；設(shè)計一個新的測試用例，使其只覆蓋一個無效等價類。重復(fù)這一步，使所有無效等價類均被覆蓋。這里強調(diào)每次只覆蓋一個無效等價類。這是因為一個測試用例中如果含有多個缺陷，有可能在測試中只發(fā)現(xiàn)其中的一個，另一些被忽視。等價類劃分法能夠全面、系統(tǒng)地考慮黑盒測試的測試用例設(shè)計問題，但是沒有注意選用一些“高效的”、“有針對性的”測試用例。后面介紹的邊值分析法可以彌補這一缺點。邊值分析法邊值分析法是列出單元功能、輸入、狀態(tài)及控制的合法邊界值和非法邊界值，設(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)及剛剛超出范圍的邊界外的值，或是分別對最大、最小及稍小于最小、稍大于最大個數(shù)作為測試用例。如有規(guī)范“某文件可包含l至255”個記錄……“針對規(guī)范的每個輸出條件使用原則〔a〕。如果程序規(guī)范中提到的輸入或輸出域是個有序的集合(如順序文件、表格等)就應(yīng)注意選取有序集的第一個和最后一個元素作為測試用例。分析規(guī)范，盡可能找出可能的邊界條件。一個典型的邊值分析例子是三角形分類程序。選取a，b，c構(gòu)成三角形三邊，“任意兩邊之和大于第三邊”為邊界條件。邊值分析相等價類劃分側(cè)重不同，對等價類劃分是一個補充。如上述三角形問題，選取a＝3，b＝4，c＝5，a＝2，b＝4，c＝7則覆蓋有效和無效等價類。如果能在等價類劃分中注入邊值分析的思想。在每個等價類中不只選取一個覆蓋用例，而是進而選取該等價類的邊界值等價類劃分法將更有效，最后可以用邊值分析法再補充一些測試用例。因果圖等價類劃分法并沒有考慮到輸入情況的各種組合。這樣雖然各個輸入條件單獨可能出錯的情況已經(jīng)看到了，但多個輸入情況組合起來可能出錯的情況卻被忽略。采用因果圖方法能幫助我們按一定步驟選擇一組高效的測試用例，同時，還能為我們指出程序規(guī)范的描述中存在什么問題。利用因果圖導(dǎo)出測試用例需要經(jīng)過以下幾個步驟：分析程序規(guī)范的描述中哪些是原因，哪些是結(jié)果。原因常常是輸入條件或是輸入條件的等價類。結(jié)果是輸出條件。分析程序規(guī)范的描述中語義的內(nèi)容，并將其表示成連接各個原因與各個結(jié)果的“因果圖”。由于語法或環(huán)境的限制，有些原因和結(jié)果的組合情況是不可能出現(xiàn)的。為表明這些特定的情況，在因果圖上使用持殊的符號標(biāo)明約束條件。把因果圖轉(zhuǎn)換成判定表。把判定表的每一列寫成一個測試用例。猜錯法猜錯法在很大程度上是憑經(jīng)驗進行的，是憑人們對過去所作的測試工作結(jié)果的分析，對所揭示的缺陷的規(guī)律性作直覺的推測來發(fā)現(xiàn)缺陷的。一個采用兩分法的檢索程序，典型地可以列出下面幾種測試情況：被檢索的表只有一項或為空表；表的項數(shù)恰好是2的冪次；表的項數(shù)比2的冪次多1等。猜錯法充分發(fā)揮人的經(jīng)驗，在一個測試小組中集思廣益，方便實用，特別在軟件測試基礎(chǔ)較差的情況下，很好地組織測試小組(也可以有外來人員)進行錯誤猜測，是有效的測試方法。隨機數(shù)法即測試用例的參數(shù)是隨機數(shù)。它可以自動生成，因此自動化程度高。使用大量隨機測試用例測試通過的程序會提高用戶對程序的信心。但其關(guān)鍵在于隨機數(shù)的規(guī)律是否符合使用實際。6白盒測試方法白盒法測試，是以程序的內(nèi)部邏輯為基礎(chǔ)，有選擇地執(zhí)行程序中最有代表性的通路。因此，白盒法也叫邏輯覆蓋法(bgicMM陰e)。最徹底的邏輯覆蓋法，是覆蓋程序巾的誨一條通路。但當(dāng)程序中含有大量循環(huán)時，要執(zhí)行每一條通路是44可能的。因此，我們只能寄希望于程序的覆蓋度盡可能高一些。目前常用的一些覆蓋標(biāo)準(zhǔn)有：語句覆蓋、判定覆蓋、條件澄蓋、判定滌件覆蓋、條件組合覆蓋、路徑覆蓋等。白盒法考慮的是測試用例對程序內(nèi)部邏輯的覆蓋程度，所以又稱為邏輯覆蓋法。最徹底的白盒法是覆蓋程序中的每一條路徑，但這不可能，我們希望覆蓋的路徑盡可能多一些。為了衡量測試的覆蓋程度，需要建立一些標(biāo)準(zhǔn)，目前常用的一些覆蓋標(biāo)準(zhǔn)是：(1)語句覆蓋；(2)判定覆蓋；(3)條件覆蓋；(4)判定／條件覆蓋；(5)條件組合覆蓋。語句覆蓋程序的某次運行一般并不能執(zhí)行到其中的每一個語句，因此，如果某語句含有一個錯誤，而它在測試中沒執(zhí)行，這個錯誤就不可能被發(fā)現(xiàn)。為了提高發(fā)現(xiàn)錯誤的可能性，應(yīng)該在測試時至少要執(zhí)行程序中的每一個語句。所謂“語句覆蓋”測試標(biāo)準(zhǔn)，它的含義是：選擇足夠的測試用例，使得程序中每個語句至少都能執(zhí)行一次。例子：ProcedureExample(VarA,B,C:real)beginif(A>1)and(B=0)thenx:=x/A；if(A=2)or(x>1)thenx:=x+lend;為了使程序中每個語句至少執(zhí)行一次，只需設(shè)計一個能通過路徑ace的例子就可以了。例如選擇輸入數(shù)據(jù)為：A=2，B=0，x=3就可達(dá)到“語句覆蓋”標(biāo)準(zhǔn)。顯然，語句覆蓋是一個比較弱的覆蓋標(biāo)準(zhǔn)。如果第一個條件語句中的and錯誤地寫成or，上面的測試用例是不能發(fā)現(xiàn)這個錯誤的，或者是第二個條件語句中x>1誤寫成x>0，這個測試用例也不能暴露它。我們還可以舉出許多錯誤情況是上述測試數(shù)據(jù)不能發(fā)現(xiàn)的。所以，一般認(rèn)為“語句覆蓋”是很不充分的最低的一種覆蓋標(biāo)準(zhǔn)。.判定理蓋比“語句覆蓋”稍強的覆蓋標(biāo)準(zhǔn)是“判定覆蓋”(或稱分支覆蓋)。這個標(biāo)準(zhǔn)是：執(zhí)行足夠的測試用例，使得程序中每個判定至少都獲得一次“真”值和“假”值，即使得程序中的每一個分文至少都通過一次。對上面那個例子，如果設(shè)計兩個測試用例，就可以達(dá)到“判定