第2章-測試用例課件

1、軟件測試 本章介紹網(wǎng)上購物系統(tǒng)的測試用例的設(shè)計與編寫。測試用例設(shè)計的目的是為每一個測試需求確定測試用例集（Test Case Suite）。本章重點：測試用例編寫規(guī)范測試用例設(shè)計方法測試用例是為有效發(fā)現(xiàn)軟件缺陷而編寫的包含測試目的、測試步驟、期望測試結(jié)果的特定集合，是測試的基礎(chǔ)。設(shè)計測試用例是在了解軟件業(yè)務(wù)流程的基礎(chǔ)上進行的。設(shè)計測試用例的原則是受最小的影響提供最多的測試信息，設(shè)計測試用例的目標(biāo)是一次盡可能的包含多個測試要素。這些測試用例必須是測試工具可以實現(xiàn)的，不同的測試場景將測試不同的功能。工作任務(wù)2.1 Test Suite用戶管理2.1.1 Test Suite添加注冊信息1工作任務(wù)描

2、述用戶管理是網(wǎng)上購物系統(tǒng)的基本模塊，而添加用戶注冊信息是用戶管理模塊中的基本功能，也是必需的功能。當(dāng)用戶在瀏覽器的地址欄中輸入本系統(tǒng)的網(wǎng)址時，系統(tǒng)彈出如圖2-1所示的主頁面。單擊注冊按鈕，轉(zhuǎn)到如圖2-2所示的頁面中，用戶填寫用戶名、姓名、密碼和郵寄地址等信息進行注冊，填寫完之后單擊提交按鈕進行注冊。如果注冊成功則會跳轉(zhuǎn)到如圖2-3所示的頁面。由于系統(tǒng)會對注冊信息進行一個簡單的驗證，如果驗證注冊信息失敗，則系統(tǒng)會提示注冊失敗信息。圖2-2 用戶注冊界面圖2-3 注冊成功界面本節(jié)任務(wù)就是對添加注冊信息功能進行測試，編寫測試用例集。在此我們使用了場景法、邊界值法、錯誤推測法等測試用例設(shè)計方法。2工作

3、過程編寫測試用例集：以下是用戶管理模塊中添加注冊信息功能的測試用例集。詳細測試用例參見教材25-32頁.2.1.2 Test Suite管理員登錄1工作任務(wù)描述在本系統(tǒng)中，管理員可以對商品信息和商品的類別信息進行管理。管理員登錄界面如圖2-4所示，當(dāng)管理員成功登錄后，則進入后臺管理主界面如圖2-5所示。圖2-4 登錄界面圖2-5 后臺管理主界面本節(jié)任務(wù)就是對管理員登錄功能進行測試，編寫測試用例集。在此我們使用了場景法、錯誤推測法等測試用例設(shè)計方法。2工作過程編寫測試用例集。以下是用戶管理模塊的子功能管理員登錄的測試用例集。詳細測試用例參見書33-35頁2.1.3 Test Suite注冊用戶登

4、錄1工作任務(wù)描述用戶注冊成功后，就可以登錄網(wǎng)站了，用戶登錄的頁面如圖2-6所示。登錄成功后進入商品購買主界面如圖2-7所示。本節(jié)任務(wù)就是編寫已注冊過的用戶登錄功能的測試用例集。在此我們使用了場景法、錯誤推測法、邊界值法等測試用例設(shè)計方法。圖2-6 主頁面圖2-7 商品購買主界面2工作過程編寫測試用例集。以下是注冊用戶登錄的測試用例集。詳細測試用例參見書36-40頁。2.1.4 Test Suite修改注冊信息1工作任務(wù)描述用戶成功登錄系統(tǒng)后，可以對自己的信息進行修改。修改注冊信息的界面如圖2-8所示。本節(jié)任務(wù)就是編寫修改注冊信息功能的測試用例集。在此我們使用了場景法、錯誤推測法、邊界值法等測試

5、用例設(shè)計方法。圖2-8 修改注冊信息2工作過程編寫測試用例集。以下是修改注冊信息的測試用例集。詳細測試用例參見書41-45頁2.1.5 應(yīng)知應(yīng)會1什么是測試用例測試用例（Test Case）是按一定的順序執(zhí)行的并與測試目標(biāo)相關(guān)的測試活動的描述，它確定“怎樣”測試。測試用例是有效發(fā)現(xiàn)軟件缺陷的最小測試執(zhí)行單元，是軟件的測試規(guī)格說明書。目前也沒有測試用例這個詞匯的經(jīng)典定義，常見的說法是：指對一項特定的軟件產(chǎn)品進行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略，內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。在測試工作中，測試用例的設(shè)計是非常重要的，是測試執(zhí)行的正確

6、性、有效性的基礎(chǔ)。如何有效地設(shè)計測試用例一直是測試人員所關(guān)注的問題，設(shè)計好的測試用例是保證測試工作的最關(guān)鍵的因素之一。如果問測試工程師測試用例如何編寫，就像是問程序員如何編寫代碼得到的答案一樣，每個人都會給出不同的編寫方法，但實用的測試用例卻像優(yōu)秀的程序一樣難以編寫。目前在國內(nèi)，測試工程師卻時常要面對“已經(jīng)延期幾倍計劃時間的項目”，測試用例如何發(fā)揮更大的作用，是一個迫切需要解決的問題。事實上，完全可以把測試用例看成是測試工程師編寫的程序：這個“程序”是為了輔助測試工作的進行而開發(fā)的，目的是為了發(fā)現(xiàn)軟件問題，同時“順便”證明軟件功能是否符合要求。測試用例主要用在集成測試、系統(tǒng)測試以及回歸測試中。

7、測試人員按照已規(guī)定好的測試用例實施測試，而不得做隨意的變動。因為測試用例是分測試等級的，集成測試應(yīng)測試哪些用例，系統(tǒng)測試應(yīng)包含哪些用例，以及回歸測試又該實施什么樣的測試用例，在設(shè)計測試用例時都是由專門人員明確規(guī)定并形成文檔的。在實施測試時測試用例作為測試的標(biāo)準(zhǔn)，測試人員一定要按照測試用例嚴(yán)格按用例項目和測試步驟逐一實施測試，并且要把測試結(jié)果詳細記錄下來，以便形成測試結(jié)果文檔，等下一輪測試時作為參考之用。在本書給出的測試用例中，測試數(shù)據(jù)是給定的，但是有時候在實踐當(dāng)中，測試數(shù)據(jù)與測試用例是分離的，根據(jù)測試用例設(shè)計，需要準(zhǔn)備大量原始數(shù)據(jù)及標(biāo)準(zhǔn)測試期望的結(jié)果，這些 數(shù)據(jù)包括各種情況下的輸入數(shù)據(jù)尤其是必

8、須設(shè)計出大量的邊緣數(shù)據(jù)和錯誤數(shù)據(jù)，這些設(shè)計用例的方法在后續(xù)內(nèi)容中會有詳細介紹。當(dāng)測試實施完成后，對測試結(jié)果的評估是非常重要的。要判斷軟件測試是否完成，衡量測試質(zhì)量需要一些量化的結(jié)果（測試覆蓋率多少、測試合格率多少、重要測試合格率多少），這樣把測試用例及實施結(jié)果作為度量標(biāo)準(zhǔn)使測試更加準(zhǔn)確有效。通過實施測試用例，將系統(tǒng)缺陷（Bug）盡量收集全面，把測試用例和缺陷數(shù)據(jù)進行對比，分析是漏測還是缺陷復(fù)現(xiàn)，最終使系統(tǒng)逐步完善軟件質(zhì)量。當(dāng)然，測試用例本身在形成文檔后也是在不斷修改更新與完善，原因有三個：第一，在測試過程中發(fā)現(xiàn)設(shè)計測試用例時考慮不周，需要完善；第二，在軟件交付使用后反饋的軟件缺陷，而缺陷又是因

9、測試用例存在漏洞造成的；第三，軟件自身的新增功能以及軟件版本的更新，測試用例也必須配套修改更新。一些小的修改直接在原測試用例文檔里更正就可以了，但是文檔中要有此次更正的記錄。軟件的版本是會升級更新的，測試用例也一樣，隨著軟件的升級而編制新的版本。測試用例的形成可以分為簡單的七個步驟：1理清模塊需求2提出測試需求3設(shè)計測試思路4測試用例編寫5測試用例評審6執(zhí)行用例7用例效率計算在本書后續(xù)應(yīng)知應(yīng)會中會有詳細用例編寫的介紹，在此不再贅述。2測試的階段和種類性能測試、壓力測試、負載測試、強度測試、穩(wěn)定性測試、健壯性測試、功能測試、接口測試，這么多眼花繚亂的測試類型名稱，估計很少有人能準(zhǔn)確地區(qū)分并說出定

10、義來，至于對應(yīng)的測試用例如何編寫和執(zhí)行，就更不用說了。這里給讀者做一下較為系統(tǒng)的說明。2測試的階段和種類性能測試、壓力測試、負載測試、強度測試、穩(wěn)定性測試、健壯性測試、功能測試、接口測試，這么多眼花繚亂的測試類型名稱，估計很少有人能準(zhǔn)確地區(qū)分并說出定義來，至于對應(yīng)的測試用例如何編寫和執(zhí)行，就更不用說了。這里給讀者做一下較為系統(tǒng)的說明。（1）軟件測試階段軟件的測試階段就是測試將按照什么樣的思路和方式進行。通常，軟件測試要經(jīng)過單元測試、集成測試、確認(rèn)測試、系統(tǒng)測試以及驗收測試。這些階段和開發(fā)過程是相對應(yīng)的。關(guān)于測試階段的叫法有多種，比如測試類型，測試策略等。 單元測試：單元測試是針對軟件設(shè)計的最小

11、單位程序模塊甚至代碼段進行正確性檢驗的測試工作，通常由開發(fā)人員進行。 集成測試：集成測試是將模塊按照設(shè)計要求組裝起來進行測試，主要目的是發(fā)現(xiàn)與接口有關(guān)的問題。由于在產(chǎn)品提交到測試部門前，產(chǎn)品開發(fā)小組都要進行聯(lián)合調(diào)試，因此在大部分企業(yè)中集成測試是由開發(fā)人員來完成的。時常有這樣的情況發(fā)生，每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是，模塊相互調(diào)用時接口會引入許多新問題。例如，數(shù)據(jù)經(jīng)過接口可能丟失；一個模塊對另一模塊可能造成不應(yīng)有的影響；幾個子功能組合起來不能實現(xiàn)主功能；誤差不斷積累達到不可接受的程度；全局?jǐn)?shù)據(jù)結(jié)構(gòu)出現(xiàn)錯誤，等等。綜合測試是組裝軟件的系統(tǒng)測試技術(shù)，按設(shè)計要

12、求把通過單元測試的各個模塊組裝在一起之后，進行綜合測試以便發(fā)現(xiàn)與接口有關(guān)的各種錯誤。某設(shè)計人員習(xí)慣于把所有模塊按設(shè)計要求一次全部組裝起來，然后進行整體測試，這稱為非增量式集成。這種方法容易出現(xiàn)混亂。因為測試時可能發(fā)現(xiàn)一大堆錯誤，為每個錯誤定位和糾正非常困難，并且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程序一段一段地擴展，測試的范圍一步一步地增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。a自頂向下集成自頂向下集成是構(gòu)造程序結(jié)構(gòu)的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結(jié)構(gòu)，以深度優(yōu)

13、先或廣度優(yōu)先的策略，逐步把各個模塊集成在一起。深度優(yōu)先策略首先是把主控制路徑上的模塊集成在一起，至于選擇哪一條路徑作為主控制路徑，這多少帶有隨意性，一般根據(jù)問題的特性確定。以圖2-9為例，若選擇了最左一條路徑，首先將模塊M1，M2，M5和M8集成在一起，再將M6集成起來，然后考慮中間和右邊的路徑。廣度優(yōu)先策略則不然，它沿控制層次結(jié)構(gòu)水平地向下移動。仍然以圖2-9為例，它首先把M2、M3和M4與主控模塊集成在一起，再將M5和M6和其他模塊集成起來。由于下文用到樁模塊的概念，在此先向讀者介紹一下。在集成測試前要為被測模塊編制一些模擬其下級模塊功能的“替身”模塊，以代替被測模塊的接口，接受或傳遞被測

14、模塊的數(shù)據(jù)，這些專供測試用的“假”模塊稱為被測模塊的樁模塊。自頂向下綜合測試的具體步驟為： 以主控模塊作為測試驅(qū)動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代； 依據(jù)所選的集成策略（深度優(yōu)先或廣度優(yōu)先），每次只替代一個樁模塊； 每集成一個模塊立即測試一遍； 只有每組測試完成后，才著手替換下一個樁模塊； 為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地重復(fù)已做過的測試）。從第二步開始，循環(huán)執(zhí)行上述步驟，直至整個程序結(jié)構(gòu)構(gòu)造完畢。圖2-9中，實線表示已部分完成的結(jié)構(gòu)，若采用深度優(yōu)先策略，下一步將用模塊M7替換樁模塊S7，當(dāng)然M7本身可能又帶有樁模塊，隨后將被對應(yīng)的實際模塊替

15、代。最后直至樁模塊S4被替代完畢為止。自頂向下集成的優(yōu)點在于能盡早地對程序的主要控制和決策機制進行檢驗，因此較早地發(fā)現(xiàn)錯誤。缺點是在測試較高層模塊時，低層處理采用樁模塊替代，不能反映真實情況，重要數(shù)據(jù)不能及時回送到上層模塊，因此測試并不充分。解決這個問題有幾種辦法，第一種是把某些測試推遲到用真實模塊替代樁模塊之后進行，第二種是開發(fā)能模擬真實模塊的樁模塊；第三種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法，使錯誤難于定位和糾正，并且失去了在組裝模塊時進行一些特定測試的可能性；第二種方法無疑要大大增加開銷；第三種方法比較切實可行，下面專門討論。b自底向上集成自底向上測試是從“原子”模塊

16、（即軟件結(jié)構(gòu)最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。自底向上綜合測試的步驟分為： 把底層模塊組織成實現(xiàn)某個子功能的模塊群（cluster）； 開發(fā)一個測試驅(qū)動模塊，控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出； 對每個模塊群進行測試； 刪除測試使用的驅(qū)動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個程序構(gòu)造完畢。圖2-10說明了上述過程。首先“原子”模塊被分為三個模塊群，每個模塊群引入一個驅(qū)動模塊進行測試。因模塊群1、模塊群2中的模塊均隸屬于模塊Ma，因此在驅(qū)動模塊D1、D2去掉后，模塊群1與模

17、塊群2直接與Ma接口，這時可將D3去掉，將Mb與模塊群3直接接口，對Mb進行集成測試。這樣繼續(xù)下去，直至最后將驅(qū)動模塊D4、D5也去掉，最后Ma、Mb和Mc全部集成在一起進行測試。自底向上集成方法不用樁模塊，測試用例的設(shè)計亦相對簡單，但缺點是程序最后一個模塊加入時才具有整體形象。它與自頂向下綜合測試方法優(yōu)缺點正好相反。因此，在測試軟件系統(tǒng)時，應(yīng)根據(jù)軟件的特點和工程的進度，選用適當(dāng)?shù)臏y試策略，有時混和使用兩種策略更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。此外，在綜合測試中尤其要注意關(guān)鍵模塊，所謂關(guān)鍵模塊一般都具有下述一或多個特征： 對應(yīng)幾條需求； 具有高層控制功能； 復(fù)雜、易

18、出錯； 有特殊的性能要求。關(guān)鍵模塊應(yīng)盡早測試，并反復(fù)進行回歸測試。 系統(tǒng)測試：系統(tǒng)測試是在集成測試通過后進行的，目的是充分運行系統(tǒng)，驗證各子系統(tǒng)是否都能正常工作并完成設(shè)計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產(chǎn)品的質(zhì)量有重大的影響。計算機軟件是基于計算機系統(tǒng)的一個重要組成部分，軟件開發(fā)完畢后應(yīng)與系統(tǒng)中其他成分集成在一起，此時需要進行一系列系統(tǒng)集成和確認(rèn)測試。對這些測試的詳細討論已超出軟件工程的范圍，這些測試也不可能僅由軟件開發(fā)人員完成。在系統(tǒng)測試之前，軟件工程師應(yīng)完成下列工作： 為測試軟件系統(tǒng)的輸入信息設(shè)計出錯處理通路； 設(shè)計測試用例，模擬錯誤數(shù)據(jù)和軟件界面可能發(fā)生的

19、錯誤，記錄測試結(jié)果，為系統(tǒng)測試提供經(jīng)驗和幫助； 參與系統(tǒng)測試的規(guī)劃和設(shè)計，保證軟件測試的合理性。系統(tǒng)測試應(yīng)該由若干個不同測試組成，目的是充分運行系統(tǒng)，驗證系統(tǒng)各部件是否都能正常工作并完成所賦予的任務(wù)。下面簡單討論幾類系統(tǒng)測試。a恢復(fù)測試恢復(fù)測試主要檢查系統(tǒng)的容錯能力。當(dāng)系統(tǒng)出錯時，能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)?；謴?fù)測試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復(fù)。對于自動恢復(fù)需驗證重新初始化（reinitialization）、檢查點（checkpointing mechanisms）、數(shù)據(jù)恢復(fù)（data recovery）和重新啟動（restart）等機制的正確性

20、；對于人工干預(yù)的恢復(fù)系統(tǒng)，還需估測平均修復(fù)時間，確定其是否在可接受的范圍內(nèi)。b安全測試安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如， 想方設(shè)法截取或破譯口令； 專門定做軟件破壞系統(tǒng)的保護機制； 故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機非法進入； 試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統(tǒng)。因此系統(tǒng)安全設(shè)計的準(zhǔn)則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。c強度測試強度測試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強度測試總是迫使系統(tǒng)在異常的資源配置下運行。例如， 當(dāng)中斷的正常

21、頻率為每秒一至兩個時，運行每秒產(chǎn)生十個中斷的測試用例； 定量地增長數(shù)據(jù)輸入率，檢查輸入子功能的反應(yīng)能力； 運行需要最大存儲空間（或其他資源）的測試用例； 運行可能導(dǎo)致操作系統(tǒng)崩潰或磁盤數(shù)據(jù)劇烈抖動的測試用例，等等。d性能測試對于那些實時和嵌入式系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當(dāng)系統(tǒng)真正集成之后，在真實環(huán)境中才能全面、可靠地測試運行操作系統(tǒng)，性能測試就是為了完成這一任務(wù)。性能測試有時與強度測試相結(jié)合，經(jīng)常需要其他軟硬件的配套支持。 驗收測試：驗收測試（acceptance testing）以需求階段的需求規(guī)格說明書為驗收

22、標(biāo)準(zhǔn)，測試時要求模擬實際用戶的運行環(huán)境。對于實際項目可以和客戶共同進行，對于產(chǎn)品來說就是最后一次的系統(tǒng)測試。測試內(nèi)容為對功能模塊的全面測試，尤其要進行文檔測試。驗收測試是系統(tǒng)開發(fā)生命周期方法論的一個階段，這時相關(guān)的用戶和/或獨立測試人員根據(jù)測試計劃和結(jié)果對系統(tǒng)進行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。它是一項確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試。這是管理性和防御性控制。驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。驗收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計把所有

23、的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)該進一步驗證軟件的有效性，這就是驗收測試的任務(wù)，即軟件的功能和性能如同用戶所期待的那樣。通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一步確認(rèn)測試即可開始。確認(rèn)測試應(yīng)檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認(rèn)標(biāo)準(zhǔn)。實現(xiàn)軟件確認(rèn)要通過一系列黑盒測試。確認(rèn)測試同樣需要制訂測試計劃和過程，測試計劃應(yīng)規(guī)定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無論是計劃還是過程，都應(yīng)該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準(zhǔn)確，人機

24、界面和其他方面（例如，可移植性、兼容性、錯誤恢復(fù)能力和可維護性等）是否令用戶滿意。確認(rèn)測試的結(jié)果有兩種可能，一種是功能和性能指標(biāo)滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發(fā)現(xiàn)嚴(yán)重錯誤和偏差一般很難在預(yù)定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。確認(rèn)測試的另一個重要環(huán)節(jié)是配置復(fù)審。復(fù)審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節(jié)。事實上，軟件開發(fā)人員不可能完全預(yù)見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設(shè)計者自認(rèn)明了的輸出信息迷惑不解，等等

25、。因此，軟件是否真正滿足最終用戶的要求，應(yīng)由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統(tǒng)的測試。有時，驗收測試長達數(shù)周甚至數(shù)月，不斷暴露錯誤，導(dǎo)致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為a、b測試的過程，以便發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。a測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶對即將面市的軟件產(chǎn)品（稱為a版本）進行測試，試圖發(fā)現(xiàn)錯誤并修正。a測試的關(guān)鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。經(jīng)過a測試調(diào)整的軟件產(chǎn)品稱為b版本。緊隨其后的b測試是指軟件開發(fā)

26、公司組織各方面的典型用戶在日常工作中實際使用b版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對b版本進行改錯和完善。a驗收測試過程過程如下：（a）軟件需求分析：了解軟件功能和性能要求、軟硬件環(huán)境要求等，并特別要了解軟件的質(zhì)量要求和驗收要求。（b）編制驗收測試計劃和項目驗收準(zhǔn)則：根據(jù)軟件需求和驗收要求編制測試計劃，制定需測試的測試項，制定測試策略及驗收通過準(zhǔn)則，并經(jīng)過客戶參與的計劃評審。（c）測試設(shè)計和測試用例設(shè)計：根據(jù)驗收測試計劃和項目驗收準(zhǔn)則編制測試用例，并經(jīng)過評審。（d）測試環(huán)境搭建：建立測試的硬件環(huán)境、軟件環(huán)境等（可在委托客戶提供的環(huán)境中進行測試）。（e）測試實施：測試并

27、記錄測試結(jié)果。（f）測試結(jié)果分析：根據(jù)驗收通過準(zhǔn)則分析測試結(jié)果，做出驗收是否通過及測試評價。（g）測試報告：根據(jù)測試結(jié)果編制缺陷報告和驗收測試報告，并提交給客戶。b驗收測試的總體思路用戶驗收測試是軟件開發(fā)結(jié)束后，用戶對軟件產(chǎn)品投入實際應(yīng)用以前進行的最后一次質(zhì)量檢驗活動。它要回答開發(fā)的軟件產(chǎn)品是否符合預(yù)期的各項要求，以及用戶能否接受的問題。由于它不只是檢驗軟件某個方面的質(zhì)量，而是要進行全面的質(zhì)量檢驗，并且要決定軟件是否合格，因此驗收測試是一項嚴(yán)格的正式測試活動。需要根據(jù)事先制定的計劃，進行軟件配置評審、功能測試、性能測試等多方面檢測。用戶驗收測試可以分為兩個大的部分：軟件配置審核和可執(zhí)行程序測試

28、，其大致順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、可執(zhí)行程序測試。要注意的是，在開發(fā)方將軟件提交用戶方進行驗收測試之前，必須保證開發(fā)方本身已經(jīng)對軟件的各方面進行了足夠的正式測試（當(dāng)然，這里的“足夠”，本身是很難準(zhǔn)確定量的）。用戶在按照合同接收并清點開發(fā)方的提交物時（包括以前已經(jīng)提交的），要查看開發(fā)方提供的各種審核報告和測試報告內(nèi)容是否齊全，再加上平時對開發(fā)方工作情況的了解，基本可以初步判斷開發(fā)方是否已經(jīng)進行了足夠的正式測試。用戶驗收測試的每一個相對獨立的部分，都應(yīng)該有目標(biāo)（本步驟的目的）、啟動標(biāo)準(zhǔn)（著手本步驟必須滿足的條件）、活動（構(gòu)成本步驟的具體活動）、完成標(biāo)準(zhǔn)（完

29、成本步驟要滿足的條件）和度量（應(yīng)該收集的產(chǎn)品與過程數(shù)據(jù)）。在實際驗收測試過程中，收集度量數(shù)據(jù)，不是一件容易的事情。（a）軟件配置審核對于一個外包的軟件項目而言，軟件承包方通常要提供如下相關(guān)的軟件配置內(nèi)容： 可執(zhí)行程序、源程序、配置腳本、測試程序或腳本。 主要的開發(fā)類文檔：需求分析說明書、概要設(shè)計說明書、詳細設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、測試計劃、測試報告、程序維護手冊、程序員開發(fā)手冊、用戶操作手冊、項目總結(jié)報告。 主要的管理類文檔：項目計劃書、質(zhì)量控制計劃、配置管理計劃、用戶培訓(xùn)計劃、質(zhì)量總結(jié)報告、評審報告、會議記錄、開發(fā)進度月報。在開發(fā)類文檔中，容易被忽視的文檔有程序維護手冊和程序員開發(fā)手冊

30、。程序維護手冊的主要內(nèi)容包括：系統(tǒng)說明（包括程序說明）、操作環(huán)境、維護過程、源代碼清單等，編寫目的是為將來的維護、修改和再次開發(fā)工作提供有用的技術(shù)信息。程序員開發(fā)手冊的主要內(nèi)容包括：系統(tǒng)目標(biāo)、開發(fā)環(huán)境使用說明、測試環(huán)境使用說明、編碼規(guī)范及相應(yīng)的流程等，實際上就是程序員的培訓(xùn)手冊。不同大小的項目，都必須具備上述的文檔內(nèi)容，只是可以根據(jù)實際情況進行重新組織。對上述的提交物，最好在合同中規(guī)定階段提交的時間，以免發(fā)生糾紛。通常，正式的審核過程分為5個步驟：計劃、預(yù)備會議（可選）、準(zhǔn)備階段、審核會議和問題追蹤。預(yù)備會議是對審核內(nèi)容進行介紹并討論。準(zhǔn)備階段就是各責(zé)任人事先審核并記錄發(fā)現(xiàn)的問題。審核會議是最

31、終確定工作產(chǎn)品中包含的錯誤和缺陷。審核要達到的基本目標(biāo)是：根據(jù)共同制定的審核表，盡可能地發(fā)現(xiàn)被審核內(nèi)容中存在的問題，并最終得到解決。在根據(jù)相應(yīng)的審核表進行文檔審核和源代碼審核時，還要注意文檔與源代碼的一致性。在實際的驗收測試執(zhí)行過程中，常常會發(fā)現(xiàn)文檔審核是最難的工作，一方面是由于市場需求等方面的壓力使這項工作常常被弱化或推遲，造成持續(xù)時間變長，加大文檔審核的難度；另一方面，文檔審核中不易把握的地方非常多，每個項目都有一些特別的地方，而且也很難找到可用的參考資料。（b）可執(zhí)行程序的測試在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成后，就可以進行驗收測試的最后一個步驟可執(zhí)行程序

32、的測試，它包括功能、性能等方面的測試，每種測試也都包括目標(biāo)、啟動標(biāo)準(zhǔn)、活動、完成標(biāo)準(zhǔn)和度量等五部分。要注意的是不能直接使用開發(fā)方提供的可執(zhí)行程序用于測試，而要按照開發(fā)方提供的編譯步驟，從源代碼重新生成可執(zhí)行程序。在真正進行用戶驗收測試之前一般應(yīng)該已經(jīng)完成了以下工作（也可以根據(jù)實際情況有選擇地采用或增加）： 軟件開發(fā)已經(jīng)完成，并全部解決了已知的軟件缺陷。 驗收測試計劃已經(jīng)過評審并批準(zhǔn)，并且置于文檔控制之下。 對軟件需求說明書的審查已經(jīng)完成。 對概要設(shè)計、詳細設(shè)計的審查已經(jīng)完成。 對所有關(guān)鍵模塊的代碼審查已經(jīng)完成。 對單元、集成、系統(tǒng)測試計劃和報告的審查已經(jīng)完成。 所有的測試腳本已完成，并至少執(zhí)行

33、過一次，且通過評審。 使用配置管理工具且代碼置于配置控制之下。 軟件問題處理流程已經(jīng)就緒。 已經(jīng)制定、評審并批準(zhǔn)驗收測試完成標(biāo)準(zhǔn)。具體的測試內(nèi)容通?？梢园ǎ喊惭b（升級）、啟動與關(guān)機、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負載、容量變化）、壓力測試（臨界的負載、容量變化）、配置測試、平臺測試、安全性測試、恢復(fù)測試（在出現(xiàn)掉電、硬件故障或切換、網(wǎng)絡(luò)故障等情況時，系統(tǒng)是否能夠正常運行）、可靠性測試等。性能測試和壓力測試一般情況下是在一起進行，通常還需要輔助工具的支持。在進行性能測試和壓力測試時，測試范圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由于

34、開發(fā)方已經(jīng)事先進行過性能測試和壓力測試，因此可以直接使用開發(fā)方的輔助工具。也可以通過購買或自己開發(fā)來獲得輔助工具。具體的測試方法可以參考相關(guān)的軟件工程書籍。如果執(zhí)行了所有的測試案例、測試程序或腳本，用戶驗收測試中發(fā)現(xiàn)的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在用戶驗收測試中所發(fā)生的變化，用戶驗收測試就完成了。盡管測試階段的劃分十分明確，但是在具體的項目和產(chǎn)品的測試中，尤其在執(zhí)行測試時，會根據(jù)實際需要來開展。關(guān)于軟件測試階段的理論可以參看朱少民寫的全程軟件測試一書中軟件測試過程和開發(fā)過程的V模型關(guān)系。測試的各個階段所用時間比例是不同的，根據(jù)該階段的性質(zhì)，確定時間長短

35、。當(dāng)然，具體情況要具體掌握，根據(jù)不同項目不同情況，各測試階段所用時間長短可隨時調(diào)節(jié)。圖2-11直觀地描述出了測試各階段所用的時間對比。圖2-11 測試各階段所用的時間（2）軟件測試的種類對于測試種類的說法很多，最多的能達到幾十種測試種類。但是實際工作中很多測試是互相包含的。按照企業(yè)中實際工作需要，通常主要進行下面幾種類型的測試：功能測試、健壯性測試、接口測試、強度測試、壓力測試、性能測試、用戶界面測試、可靠性測試、安裝/反安裝測試、幫助文檔測試。下面介紹幾種重要的測試種類及其測試的內(nèi)容： 功能測試：功能測試主要針對產(chǎn)品需求說明書的測試，是驗證功能是否適合需求，包括原定功能的檢驗、是否有冗余功能

36、、遺漏功能。這類測試應(yīng)由測試員做，這并不意味著程序員在發(fā)布前不必檢查他們的代碼能否工作，他們也需要進行基本功能的測試。 接口測試：程序員對各個模塊進行系統(tǒng)聯(lián)調(diào)的測試，包含程序內(nèi)接口和程序外接口測試。這個測試，在單元測試階段進行了一部分工作，而大部分都是在集成測試階段完成的。由開發(fā)人員進行。 性能測試：在交替進行負荷和強迫測試時常用的術(shù)語。性能測試關(guān)注的是系統(tǒng)的整體。它和通常所說的強度、壓力/負載測試有密切關(guān)系。所以壓力和強度測試應(yīng)該與性能測試一同進行。 用戶界面測試：對系統(tǒng)的界面進行測試，測試用戶界面是否友好、是否方便易用、設(shè)計是否合理、位置是否正確等一系列界面問題。 安裝/反安裝測試：安裝測

37、試主要檢驗軟件是否可以正確安裝，安裝文件的各項設(shè)置是否有效，安裝后能否影響原系統(tǒng)；反安裝是逆過程，測試是否刪除干凈，是否影響原系統(tǒng)等。 文檔測試：主要測試開發(fā)過程中針對用戶的文檔，以需求、用戶手冊、安裝手冊等為主，檢驗文檔是否和實際應(yīng)用存在差別。文檔測試不需要編寫測試用例。測試種類的劃分不要拘泥于上面的形式，總體來說應(yīng)該服從于測試策略，可以根據(jù)具體工作的特點進行安排，為了工作更容易開展，完全可以把一些測試合并在一起進行。在后面的性能測試用例的編寫上，充分體現(xiàn)了這一思想。綜合上面的分析，測試種類、測試階段以及執(zhí)行人員具體的關(guān)系如表2-1所示。表2-1 測試的種類、階段和執(zhí)行人員的關(guān)系測 試 階

38、段測 試 類 型執(zhí) 行 者單元測試模塊功能測試，包含部分接口測試、路徑測試開發(fā)工程師集成測試接口測試、路徑測試，含部分功能測試開發(fā)工程師（如果測試人員水平較高，可以由測試人員執(zhí)行）系統(tǒng)測試功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試測試工程師驗收測試對于實際項目來說基本同上，并包含文檔測試；對于軟件產(chǎn)品，主要測試相關(guān)的技術(shù)文檔測試工程師（根據(jù)實際需要，可能包含用戶）總之，測試的種類應(yīng)該盡量的少，這樣每次都可以執(zhí)行更多的測試內(nèi)容。例如在進行功能測試的同時，完全可以進行健壯性的測試（當(dāng)然如果產(chǎn)品健壯性方面要求較高，就可以把健壯性測試作為獨立的測試

39、）。也就是說測試各個階段中對執(zhí)行不同的測試種類采用不同的測試技術(shù)。關(guān)于測試技術(shù)下面進行講解。3黑盒測試中設(shè)計測試用例的基本方法白盒測試和黑盒測試是軟件測試中的兩大方法，有時也將兼具兩者特點的方法叫做灰盒測試。但傳統(tǒng)的軟件測試活動基本上都可以劃到這兩類方法當(dāng)中。黑盒測試注重于測試軟件的功能性需求，也就是說黑盒測試要求軟件工程師列出程序所有功能需求的輸入條件。黑盒測試并不是白盒測試的替代品，而是用于輔助白盒測試發(fā)現(xiàn)其他類型的錯誤。黑盒測試主要用于測試的后期，一般由專門的測試人員來做。本課程主要來學(xué)習(xí)黑盒測試，培養(yǎng)專門的測試人員。黑盒測試概括起來主要用來發(fā)現(xiàn)下面這些類型的錯誤： 功能錯誤或遺漏； 界

40、面錯誤； 數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤； 性能錯誤； 初始化和終止錯誤。測試用例可以分為基本事件、備選事件和異常事件。設(shè)計基本事件的用例，應(yīng)該參照用例規(guī)約（或設(shè)計規(guī)格說明書），根據(jù)關(guān)聯(lián)的功能、操作按路徑分析法設(shè)計測試用例。而對孤立的功能則直接按功能設(shè)計測試用例?；臼录臏y試用例應(yīng)包含所有需要實現(xiàn)的需求功能，覆蓋率達100%。設(shè)計備選事件和異常事件的用例，則要復(fù)雜和困難得多。例如，字典的代碼是唯一的，不允許重復(fù)。測試需要驗證：字典新增程序中已存在有關(guān)字典代碼的約束，若出現(xiàn)代碼重復(fù)必須報錯，并且報錯文字正確。往往在設(shè)計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全

41、部非基本事件，并同時盡量發(fā)現(xiàn)其中的軟件缺陷?？梢圆捎密浖y試常用的基本方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設(shè)計測試用例。視軟件的不同性質(zhì)采用不同的方法。如何靈活運用各種基本方法來設(shè)計完整的測試用例，并最終實現(xiàn)暴露隱藏的缺陷，全憑測試設(shè)計人員的豐富經(jīng)驗和精心設(shè)計。黑盒測試方法主要有五種，分為等價類劃分法、邊界值劃分法、錯誤推測法、因果圖法和場景法。在實際測試用例設(shè)計過程中，不僅根據(jù)需要、場合單獨使用這些方法，常常綜合運用多個方法，使測試用例的設(shè)計更為有效。等價類法（1）等價類定義等價類劃分法是黑盒測試的典型方法，是指某個輸入域的子集合。在該集合中，各個輸入數(shù)據(jù)對于

42、揭露程序中的錯誤都是等效的。有效等價類：符合需求規(guī)格說明書，合理地輸入數(shù)據(jù)集合。無效等價類：不符合需求規(guī)格說明書，無意義地輸入數(shù)據(jù)集合。（2）等價類劃分的步驟劃分有效等價類和無效等價類根據(jù)上面等價類的劃分，確定測試用例例1：請用等價類和邊界值方法編寫163郵箱注冊模塊（簡化版）的測試用例（假設(shè)沒有重復(fù)的用戶名），如下圖所示。請注意帶*的項目必須填寫。輸入條件有效等價類無效等價類用戶名長度(1).318 之間(2).大于18(3).小于3用戶名類型(4).用戶名由字母，數(shù)字，點，減號或下劃線組成 只能以數(shù)字或字母開頭和結(jié)尾(5).用戶名中含有空格 (6).用戶名中含有特殊字(7) 用戶名為空(8

43、)不以數(shù)字和字母開頭(9) 不以數(shù)字和字母結(jié)尾是否區(qū)分大小寫(10)不區(qū)分大小寫(11)區(qū)分大小寫 （1）用戶名：劃分等價類并編號，下表等價類劃分的結(jié)果：（2）用戶名：設(shè)計測試用例序號所屬等價類輸入數(shù)據(jù)預(yù)期輸出結(jié)果11 a122333 該用戶可以注冊22123456aaaaaaaabbbb 提示請輸入3-18個字符3312提示請輸入3-18個字符46 12345 提示用戶名格式不正確55 空格提示用戶名格式不正確 66 漢字提示用戶名格式不正確78 _234a 只能以數(shù)字或字母開頭和結(jié)尾87 用戶名不能為空99 A123456- 只能以數(shù)字或字母開頭和結(jié)尾1010Aaaaaa（用戶名為aaaa

44、aa）登陸成功輸入條件有效等價類無效等價類密碼長度 (1)618 (2).大于18(3).小于6 密碼類型(4).以數(shù)字，字母，特殊字符組成(5).用戶名中含有空格 密碼是否為明文(6).不是明文(7)是明文輸入密碼和再次輸入密碼是否一致(8).輸入密碼和再次輸入密碼一致(9).密碼和在次輸入密碼不一致（3）密碼：劃分等價類并編號，下表等價類劃分的結(jié)果：序號輸入數(shù)據(jù)所屬等價類預(yù)期結(jié)果1 1 a122333 該用戶可以注冊2 3 a1 提示請輸入6-18個字符3 2 123456aaaaaaaajkkfhj 提示請輸入6-18個字符45 空格提示密碼格式不正確 5 4 1234a 該用戶可以登錄

45、66 A1234123 該用戶可以登錄78密碼和輸入密碼一致可以注冊89密碼和輸入密碼不一致不可以注冊97*可以登錄例2：設(shè)有一個檔案管理系統(tǒng)，要求用戶輸入以年月表示的日期，假設(shè)日期限定在2011年1月2099年12月，并規(guī)定日期由6位數(shù)字字符組成，前4位表示年，后兩位表示月?，F(xiàn)用等價類劃分法設(shè)計測試用例，來測試程序的“日期檢查功能”。輸入條件有效等價類無效等價類日期的類型及長度6位數(shù)字組成的字符有非數(shù)字字符少于6位數(shù)字字符多于6位數(shù)字字符年份范圍在2011-2099之間小于2011大于2099月份范圍在01-12之間等于00大于12（1）劃分等價類并編號，下表等價類劃分的結(jié)果：序號輸入數(shù)據(jù)所

46、屬等價類測試方法預(yù)期輸出結(jié)果1123456等價類可查詢2A12346等價類日期格式不正確3122等價類日期格式不正確41234567等價類日期格式不正確52012等價類可查詢62000等價類請輸入2011-2099范圍內(nèi)的年份73000等價類請輸入2011-2099范圍內(nèi)的年份806等價類可查詢900等價類請輸入01-12月份的數(shù)字1013等價類請輸入01-12月份的數(shù)字（2）設(shè)計測試用例2邊界值法邊界值分析法是一種非常實用的測試用例設(shè)計技術(shù)，具有很強的發(fā)現(xiàn)程序錯誤的能力，它的測試用例來自于等價類的邊界。大量測試工作的經(jīng)驗會告訴我們，大量的錯誤發(fā)生在輸入或輸出范圍的邊界上，而不是輸入或輸出范圍

47、的內(nèi)部。邊界值分析就是假定錯誤發(fā)生在輸入或輸出區(qū)間的邊界上，因此使用邊界值法設(shè)計測試用例，可以發(fā)現(xiàn)更多的錯誤。在使用邊界值法設(shè)計測試用例時，應(yīng)該首先確定好輸入邊界和輸出邊界情況，然后選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù)。一般情況下，可以遵循以下幾個規(guī)則來設(shè)計測試用例： 如果輸入條件規(guī)定了值的范圍，應(yīng)取剛達到這個范圍的邊界值，以及剛剛超過這個范圍邊界的值作為測試輸入的數(shù)據(jù)。 如果輸入條件規(guī)定了值的個數(shù)，應(yīng)用最大個數(shù)、最小個數(shù)、比最小個數(shù)少一、比最大個數(shù)多一的數(shù)作為測試輸入的數(shù)據(jù)。 根據(jù)每個輸入條件，使用規(guī)則一或二。 如果程序的規(guī)格說

48、明給出的輸入域或輸出域是有序集合，則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例數(shù)據(jù)。 如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，應(yīng)當(dāng)選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值來作為測試用例。 分析規(guī)格說明，找出其他可能的邊界條件。下面舉個例子讓大家更深入地理解邊界值法。用戶登錄網(wǎng)上購物系統(tǒng)要購買某種商品，假設(shè)該商品剩余數(shù)量為100件，且用戶只會輸入整數(shù)。則用戶只能購買1100范圍內(nèi)的商品件數(shù)。使用邊界值法設(shè)計測試用例，測試用戶輸入商品數(shù)量Q后，系統(tǒng)反應(yīng)是否合乎標(biāo)準(zhǔn)。提出邊界時，一定要測試鄰近邊界的合法數(shù)據(jù)，即測試最后一個可能合法的數(shù)據(jù)，以及剛剛超過邊界的非法數(shù)據(jù)。越界測試通常簡單地加1或者用最小的數(shù)減1。

49、圖2-12中，輸入分區(qū)將1100分成三個區(qū)間，再考慮上恰好等區(qū)間邊界的情況，我們可以考慮商品數(shù)量Q的輸入?yún)^(qū)間如下：圖2-12 邊界值分析 Q1 Q=1 1Q100根據(jù)上面的分析可以設(shè)計六個用例： Test Case 1：輸入0，返回錯誤信息“您必須輸入大于等于一個數(shù)量值”。 Test Case 2：輸入1，頁面正確運行。 Test Case 3：輸入2，頁面正確運行。 Test Case 4：輸入99，頁面正確運行。 Test Case 5：輸入100，頁面正確運行。 Test Case 6：輸入101，返回錯誤信息“您所選購的商品數(shù)量僅剩100件”。測試員可以將上面的信息填入用例設(shè)計表格中，

50、形成標(biāo)準(zhǔn)的測試用例。3錯誤推測法錯誤推測法就是根據(jù)經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性地設(shè)計測試用例的方法。使用錯誤推測法時，可以憑經(jīng)驗列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，幫助猜測錯誤可能發(fā)生的位置，提高錯誤猜測的有效性，根據(jù)他們選擇測試用例。例如：輸入表格為空格；輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況。4場景法場景是通過描述經(jīng)過用例的路徑來確定的過程，這個過程要從用例開始到結(jié)束遍歷其中所有基本流和備選流。場景法就是根據(jù)這些基本流和備選流的流動過程來設(shè)計測試用例。目前的軟件幾乎都是由事件觸發(fā)來控制流程的，事件觸發(fā)時的情景便形成了場景，而同一事件不同的觸發(fā)順序和處理結(jié)

51、果形成事件流。這種在軟件設(shè)計方面的思想也可被引入到軟件測試中，生動地描繪出事件觸發(fā)時的情景，有利于測試設(shè)計者設(shè)計測試用例，同時測試用例也更容易的得到理解和執(zhí)行。提出這種測試思想的是Rational公司。下面使用網(wǎng)上購物系統(tǒng)的購物場景舉例說明。 場景描述用戶進入網(wǎng)上購物系統(tǒng)網(wǎng)站進行購物，選好物品后進行購買，這時需要使用賬號登錄，登錄成功后付款，交易成功后生成訂單，完成此次購物活動。 使用場景法設(shè)計測試用例a確定基本流和備選流事件表2-2列出了用戶購物活動中的基本流和備選流。基 本 流登錄網(wǎng)上購物系統(tǒng)網(wǎng)站，選擇物品，登錄賬號，付錢交易，生成訂單備選流1賬號不存在備選流2賬號或密碼錯誤備選流3用戶賬

52、號余額不足備選流4用戶賬號沒有錢備選流5用戶退出系統(tǒng)表2-2 基本流和備選流b根據(jù)基本流和備選流來確定場景表2-3列出了每個場景中包括的基本流和備選流，需要特別說明的是，由于場景1中用戶成功購買了物品，所以只有基本流而不需經(jīng)過備選流。場景1：成功購物基本流場景2：賬號不存在基本流備選流1場景3：賬號或密碼錯誤基本流備選流2場景4：用戶賬號余額不足基本流備選流3場景5：用戶賬號沒有錢基本流備選流4表2-3 場景c設(shè)計用例對每一個場景都要做測試用例，可以使用矩陣（表格）來管理用例。用行表示各個測試用例，列表示測試用例的信息。首先將測試用例的ID、條件、涉及的數(shù)據(jù)元素以及預(yù)期結(jié)果列在矩陣中，然后將這

53、些數(shù)據(jù)確定下來，填寫在表格中。在表2-4中，“有效”表示這個條件必須是有效的才可執(zhí)行基本流，而“無效”用于表示這種條件下將激活所需備選流?！安贿m用”表示這個條件不適用于測試用例。測試用例ID場景/條件賬 號密 碼用戶賬號余額預(yù) 期 結(jié) 果1場景1：成功購物有效有效有效成功購物2場景2：賬號不存在無效不適用不適用提示賬號不存在3場景3：賬號或密碼錯誤（賬號正確，密碼錯誤）有效無效不適用提示賬號或密碼錯誤，返回基本流步驟34場景3：賬號或密碼錯誤（賬號錯誤，密碼正確）無效有效不適用提示賬號或密碼錯誤，返回基本流步驟35場景4：用戶賬號余額不足有效有效無效提示賬號余額不足請充值6場景5：用戶賬號沒有

54、錢有效有效無效提示賬號余額請充值表2-4 測試用例信息d設(shè)計數(shù)據(jù)，填入表2-4，結(jié)果如表2-5所示測試用例ID場景/條件賬號密碼用戶賬號余額預(yù)期結(jié)果1場景1：成功購物wangshPassw0rd193成功購物，用戶賬號余額正確2場景2：賬號不存在song不適用不適用提示賬號不存在3場景3：賬號或密碼錯誤（賬號正確，密碼錯誤）wangsh666666不適用提示賬號或密碼錯誤，返回基本流步驟34場景3：賬號或密碼錯誤（賬號錯誤，密碼正確）songpassw0rd不適用提示賬號或密碼錯誤，返回基本流步驟35場景4：用戶賬號余額不足wshpass0rd2提示賬號余額不足請充值6場景5：用戶賬號沒有錢s

55、unxx8172170提示賬號余額請充值表2-5 測試用例數(shù)據(jù)2.1.6 拓展任務(wù)獨立編寫天天超市管理系統(tǒng)用戶管理模塊的測試用例集。工作任務(wù)2.2 Test Suite商品管理2.2.1 Test Suite商品類別管理1工作任務(wù)描述管理員成功登錄系統(tǒng)后，進入圖2-13所示的商品類別瀏覽界面，單擊相應(yīng)類別的修改或刪除按鈕進行商品類別的管理。其中商品類別添加界面如圖2-14所示，商品類別修改界面如圖2-15所示。本節(jié)任務(wù)是編寫商品類別管理功能的測試用例集，分別設(shè)計瀏覽商品類別，添加商品類別和修改商品類別的測試用例。設(shè)計測試用例的基本方法為場景法、邊界值法和錯誤推測法。圖2-13 商品類別瀏覽界面

56、圖2-14 商品類別添加界面圖2-15 商品類別修改界面工作過程：（1）編寫商品類別添加的測試用例集Test Case 047：必填項是否允許為空Summary：檢驗系統(tǒng)是否對必填項為空的情況做了處理Steps：1單擊商品類別添加按鈕2什么都不輸入，直接單擊添加按鈕Expected Results：1彈出“商品類別添加界面”2提示“類別名稱不能為空”場景法Pass/Fail：Test Notes：Author adminTest Case 049：輸入字符數(shù)大于域允許的最大字符數(shù)Summary：檢驗系統(tǒng)是否對域輸入長度進行了驗證Steps：1單擊商品類別添加按鈕2在“類別名稱”中輸入“國產(chǎn)電腦

57、主機配件”，單擊添加按鈕Expected Results：1彈出“商品類別添加界面”；2提示“您輸入的字符數(shù)過多，請限制在5個漢字?！边吔缰捣≒ass/Fail：Test Notes：Author admin詳細測試用例參見63-67頁.2.2.2 Test Suite商品管理1工作任務(wù)描述網(wǎng)上購物網(wǎng)站必然包含大量的商品信息，管理員不僅要管理商品的類別，還要對商品本身進行管理，需要添加和修改商品信息。商品管理模塊可以為商品設(shè)定不同的屬性，如商品的名稱、規(guī)格、售價、生產(chǎn)廠商及商品的圖片等，可以方便地編輯豐富的商品信息呈現(xiàn)方式，及時調(diào)整商品信息。商品信息添加的界面如圖2-16所示，商品信息修改的界

58、面如圖2-17所示。圖2-17 商品信息修改界面2工作過程（1）編寫商品添加的測試用例集Test Case 063：必填項是否允許為空Summary：檢驗系統(tǒng)是否對必填項為空的情況做了處理Steps：1單擊商品添加按鈕2什么都不輸入，直接單擊添加按鈕；Expected Results：1彈出“商品添加界面”2提示“商品名稱、商品類別、商品規(guī)格、商品售價、生產(chǎn)商、圖片不能為空”場景法Pass/Fail：Test Notes：Author admin詳細測試用例參見68-73頁.2.2.3 應(yīng)知應(yīng)會1黑盒測試中測試用例設(shè)計的其他方法在第一節(jié)中，我們詳細介紹了邊界值分析法、錯誤推測法和場景法，這里我

59、們介紹等價類劃分法和因果圖法。（1）等價類劃分法等價類劃分法是黑盒測試的典型方法，只需按照需求文檔中對系統(tǒng)的要求和說明對輸入的范圍進行劃分，然后從每個區(qū)域內(nèi)選取一個有代表性的測試數(shù)據(jù)，完全不用考慮系統(tǒng)的內(nèi)部結(jié)構(gòu)。如果等價類劃分得合理，選取的這個數(shù)據(jù)就代表了這個區(qū)域內(nèi)所有的數(shù)據(jù)。具體來講，等價類劃分法就是把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分（子集），然后從每一個子集中選取少數(shù)具有代表性的數(shù)據(jù)作為測試用例。其中每個輸入域的集合（子集）就是等價類，在這個集合中每個輸入條件都是等效的，如果其中一個的輸入不導(dǎo)致問題發(fā)生，那么這個等價類中其他輸入也不會發(fā)生錯誤。等價類分為有效等價類和無效等價

60、類。有效等價類就是由那些對程序的規(guī)格說明有意義的、合理的輸入數(shù)據(jù)所構(gòu)成的集合，利用有效等價類可檢驗程序是否實現(xiàn)了需求文檔中所規(guī)定的功能和性能。無效等價類就是那些對程序的規(guī)格說明不合理的或無意義的輸入數(shù)據(jù)所構(gòu)成的集合。劃分等價類最重要的是集合的劃分。集合要劃分為互不相交的子集，而子集的并是整個集合。確定等價類的原則如下： 在輸入條件規(guī)定了取值范圍（閉區(qū)間）或值的個數(shù)的情況下，則可以確定一個有效等價類和兩個無效等價類。 在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下，可確定一個有效等價類和一個無效等價類。 在輸入條件是一個布爾量的情況下，可確定一個有效等價類。 在規(guī)定了輸入數(shù)據(jù)的