第十章軟件測試案例10.1C程序測試案例10.2Robot功能測試10.3某縣政府網(wǎng)站的測試10.4服務(wù)器接口功能測試案例10.5手機(jī)測試計劃案例第十章軟件測試案例10.6參數(shù)化測試10.7使用VisualStudio2010實現(xiàn)敏捷驅(qū)動測試開發(fā)10.8超市管理系統(tǒng)測試計劃本章小結(jié)

下面是一組對一段包含賦值、判斷和循環(huán)語句等簡單C程序進(jìn)行測試的功能性測試用例。該測試采用白盒與黑盒測試相結(jié)合。10.1C程序測試案例按照功能模塊測試分為9個模塊：注釋功能的實現(xiàn)、聲明語句的實現(xiàn)、賦值語句的實現(xiàn)、運(yùn)算符優(yōu)先級的實現(xiàn)、選擇語句if-else的實現(xiàn)、循環(huán)語句while的實現(xiàn)、嵌套功能的實現(xiàn)、輸入輸出功能的實現(xiàn)和數(shù)組功能的實現(xiàn)。前期的測試數(shù)據(jù)很多，沒有全列出來。9個模塊對應(yīng)的功能測試的測試用例，編號依次為001～009。還有一個綜合功能測試，編號為000，綜合了對本編譯器所有功能的測試。各測試用例分別見表10.1～表10.10。表10.1001號用例表10.2002號用例表10.3003號用例表10.4004號用例表10.5005號用例表10.6006號用例表10.7007號用例表10.8008號用例表10.9009號用例表10.10000號綜合性測試用例

在成功安裝和建立測試項目以后，就可以利用TestManager和Robot進(jìn)行軟件測試。下面以一個Windows自帶的計算器測試?yán)?，展示Rational的功能。10.2Robot功能測試

(1)啟動Robot，登錄窗口默認(rèn)用戶名是admin，輸入在建立測試項目時指定的密碼(默認(rèn)為空)，即可進(jìn)入Robot主界面；

(2)點擊工具欄上的“GUI”按鈕，錄制GUI腳本，在窗口中輸入腳本名稱；

(3)在GUIRecord工具欄上點擊第四個按鈕，在GUIInset工具欄點擊“StartApplication”按鈕，點擊“browse…”按鈕，選擇計算器程序；

(4)從鍵盤輸入“1+1=”，然后在GUIRecord工具欄上點擊第四個按鈕，在GUIInset工具欄點擊“Alphanumeric校驗點”，選擇第三項NumericEquivalence；

(5)關(guān)閉計算器，點擊GUIRecord工具欄上的“STOP”按鈕，完成腳本的錄制。

錄制完的腳本如下：

SubMain

DimResultAsInteger

StartApplication"c:\windows\system32\calc.exe"

WindowSetContext,"Caption=計算器",""

PushButtonClick,"Text=7"

PushButtonClick,"Text=+"

PushButtonClick,"Text=6"

PushButtonClick,"Text=="

Result=EditBoxVP(CompareNumeric,"ObjectIndex=1","VP=Alphanumeric;Value=130000")

WindowCloseWin,"",""

EndSub

這個腳本并不能正確回放，需要將Result

=

EditBoxVP(CompareNumeric,"ObjectIndex=1",

"VP

=

Alphanumeric;Value=130000")改為：Result=EditBoxVP(CompareNumeric,"ObjectIndex=1","VP=Alphanumeric;Value=13")。這樣就可以點擊工具欄上的回放按鈕進(jìn)行回放。這個腳本只能驗證一組數(shù)據(jù)，并不能體現(xiàn)出自動測試帶來的便利。需要對腳本進(jìn)行手工修改，在腳本加入循環(huán)結(jié)構(gòu)和數(shù)據(jù)池(DATAPOOL)，這樣就可以實現(xiàn)一個腳本測試大量的數(shù)據(jù)，腳本易于維護(hù)而且功能強(qiáng)大。

修改后的腳本如下：

'$Include"sqautil.sbh"http://datapool必須寫的第一句話

SubMain

DimResultAsInteger

dimmasstring

dimxasinteger

dimnasstring

dimsumasvariant

dimdpaslong

StartApplication"c:\windows\system32\calc.exe"

dp=SQADatapoolOpen("Book1")

forx=1to5

CallSQADatapoolFetch(dp)

CallSQADatapoolValue(dp,1,m)

CallSQADatapoolValue(dp,2,n)

CallSQADatapoolValue(dp,3,sum)

WindowSetContext,"Caption=計算器","" InputKeysm&"{+}"&n&"{ENTER}“

Result=EditBoxVP(CompareNumeric,"ObjectIndex=1","VP=Alphanumeric;Value="&sum&"")

WindowResetTestContext,"",""

ifResult<>1then

SQALogMessagesqaFail,"測試失敗","設(shè)計測試失敗"

else

SQALogMessagesqaPass,"測試成功",""

endif

msgboxResult//提示信息

next

CallSQADatapoolClose(dp)

WindowCloseWin,"",""

EndSub

注：SQADatapoolOpen("Book1")中，Book1為數(shù)據(jù)池(DATAPOOL)名稱，需要在testmanager中手工創(chuàng)建。

經(jīng)過簡單的編輯后，測試時只需要將測試數(shù)據(jù)導(dǎo)入數(shù)據(jù)池(DATAPOOL)回放腳本即可，通過查看測試log檢查哪些錯誤，在開始測試時就可以使用，而不是等到回歸，也不是手工過程的簡單重復(fù)。在測試之前，可以先準(zhǔn)備好測試數(shù)據(jù)備用。

Web網(wǎng)站的網(wǎng)頁是由文字、圖形、音頻、視頻和超級鏈接組成的文檔。對網(wǎng)站的測試主要包括：配置測試、兼容測試、可用性測試、文檔測試、文字測試、鏈接測試、圖像測試、表單測試、動態(tài)內(nèi)容測試、數(shù)據(jù)庫測試、服務(wù)器性能及負(fù)載測試、安全性測試?？赡懿捎玫姆椒ㄓ泻诤袦y試、白盒測試、靜態(tài)測試和動態(tài)測試等。10.3某縣政府網(wǎng)站的測試下面以對某縣政府網(wǎng)站測試為例，介紹實際Web網(wǎng)站界面測試過程中如何發(fā)現(xiàn)Bug。

一、登錄界面測試用例

網(wǎng)站登錄界面測試用例見表10.11。表10.11登錄界面測試用例二、測試過程中發(fā)現(xiàn)的Bug

1．水務(wù)局網(wǎng)頁測試結(jié)果

測試時間：2009-12-14，測試人：ANDY

存在問題：

(1)位于“工作動態(tài)”下面的四張圖片，間距沒有對齊。

(2)郵箱內(nèi)沒有信息時，無法添加信息，也無法顯示郵箱添加信息的頁面，無法進(jìn)入靜態(tài)化郵箱頁面(易犯的錯誤)。

(3)信息頁面在信息很多的情況下，網(wǎng)頁過長，沒有分頁(易犯的錯誤)。

(4)三級頁面中，在只有一篇文檔的情況下，仍然顯示“上一篇下一篇”功能。

(5)首頁和二級頁面中，頁頭圖片與導(dǎo)航欄沒有對齊。

(6)進(jìn)入郵箱，選擇添加信息頁面，顯示留言信息的表格高度調(diào)整不靈活，在只有一、兩條信息的情況下，表格顯示不夠美觀。

(7)郵箱無法正常添加信息，在添加信息后跳轉(zhuǎn)不正常，出現(xiàn)“WARNING”提示。

(8)在郵箱三級頁面，顯示無法讀取“right.html”的提示。

水務(wù)局網(wǎng)頁測試完成時間：2009-12-14,11:53:28

2．審計局網(wǎng)頁測試結(jié)果

測試時間：2009-12-14；測試人：ANDY

存在問題：

(1)首頁中，F(xiàn)lash標(biāo)題字沒對齊。

(2)導(dǎo)航欄的位置不夠準(zhǔn)確、美觀。

(3)各頁腳不統(tǒng)一。

(4)首頁中，“局長信箱”、“舉報信箱”，以及右下角“咨詢信箱”都連接到同一個信箱。

(5)首頁中，審計信息模塊顯示的是后臺“圖片新聞”的內(nèi)容，后臺“審計信息”的內(nèi)容，不能顯示?！皩徲嬓畔ⅰ焙汀皥D片新聞”控制名相同，都是“shengjixingxi”。

(6)二級頁面的頁腳位置不對。

(7)郵箱無信息時，不能添加信息，也無法顯示郵箱添加信息頁面，無法進(jìn)入靜態(tài)化郵箱頁面（易犯的錯誤）。

(8)首頁中，“審計知識”后臺名字為“審計動態(tài)”，不一致。

審計局網(wǎng)頁測試完成時間：2009-12-14,12:10:54

3．廣電局網(wǎng)頁測試結(jié)果

測試時間：2009-12-14；測試人：ANDY

存在問題：

各頁腳的位置不對。

廣電局網(wǎng)頁測試完成時間：2009-12-14,13:45:20

4．供電局網(wǎng)頁測試結(jié)果

測試時間：2009-12-14；測試人：ANDY

存在問題：

(1)首頁，臨近尾部的“工作動態(tài)”模塊位置不對。如圖10.1所示。

圖10.1網(wǎng)頁中模塊位置出錯

(2)首頁，二級頁面，三級頁面，頁尾部位置不對。

(3)“工作動態(tài)”下面文字未居中。如圖10.2所示。

(4)后臺不能正常操作郵箱，數(shù)據(jù)庫中表名為dl_mailht_info，此處字母應(yīng)改為小寫。如圖10.3所示。

圖10.2頁面文字未居中

圖10.3后臺代碼錯誤

(5)

Flash圖片未居中，F(xiàn)lash與文字中間距離太大，需要把圖片居中放，或以其他方式調(diào)整一下位置，如圖10.4所示。圖10.4Flash圖片與文字間距過大

(6)二級頁面右下角沒有對齊，如圖10.5所示。圖10.5二級頁面右下角未對齊

(7)郵箱的二級頁面頁腳有問題。如圖10.6所示。圖10.6郵箱二級頁面頁腳中有問題

(8)郵箱分頁條數(shù)過多，二級郵箱頁面過長。如圖10.7所示。圖10.7郵箱頁面過長

(9)三級頁面圖片大小不合適。如圖10.8所示。

(10)圖片上沒有號碼，圖片本身也沒有鏈接。應(yīng)修改圖片，或給圖片加上熱線電話的鏈接。如圖10.9所示。

圖10.8三級頁面中圖片過大

圖10.9缺少必要鏈接和文本

(11)二級頁面的顯示條數(shù)沒有達(dá)到分頁時，這個白條應(yīng)讓其不顯示或固定在下面。如圖10.10所示。圖10.10二級頁面顯示供電局網(wǎng)頁測試完成時間：2009-12-14,14:55:20

5．政務(wù)服務(wù)中心網(wǎng)頁測試文檔

測試時間2009-12-14測試人ANDY

存在問題：

(1)用IE7顯示時，F(xiàn)lash尺寸有問題。如圖10.11所示。

(2)首頁CSS有問題，沒有邊框。如圖10.12所示。

圖10.11不同瀏覽器顯示有誤

圖10.12CSS制作頁面缺少邊框

(3)“單位簡介”頁腳位置有問題。

(4)郵箱二、三級頁面，頁腳沒有CSS效果。如圖10.13所示。

(5)郵箱二級頁面沒有提交按鈕。如圖10.14所示。

圖10.13頁腳缺少CSS效果

圖10.14郵箱無提交按鈕

(6)后臺沒有郵箱管理模塊。

政務(wù)服務(wù)中心網(wǎng)頁測試完成時間：2009-12-14,15:31:24

6．陶瓷產(chǎn)業(yè)集中區(qū)網(wǎng)頁測試結(jié)果

測試時間：2009-12-14，測試人：ANDY

存在問題：

多個模塊存在IE6及IE7顯示兼容問題，多個模塊IE6及IE7顯示不同。如圖10.15所示。

圖10.15不同瀏覽器顯示不兼容陶瓷產(chǎn)業(yè)集中區(qū)網(wǎng)頁測試完成時間：2009-12-14,15:54:24

7．縣國稅局集中區(qū)網(wǎng)頁測試結(jié)果

測試時間：2009-12-14，測試人：ANDY

存在問題：

后臺回復(fù)郵箱中，有內(nèi)容時也會顯示ALERT請求顯示內(nèi)容。

該縣國稅局測試完成時間：2009-12-14,16:06:17

8．縣氣象局網(wǎng)頁測試結(jié)果

測試時間：2009-12-14，測試人：ANDY

存在問題：

(1)首頁“工作動態(tài)”模塊，IE6與IE7顯示不同。如圖10.16所示。

(2)二級頁面，三級頁面，左邊存在IE6兼容問題。如圖10.17所示。

(3)三級頁面，上一篇位置，有多條線。如圖10.18所示。

(4)頭導(dǎo)航欄右邊顯示為空。如圖10.19所示。

圖10.16瀏覽器顯示不兼容

圖10.17二、三級頁面中IE6不兼容

圖10.18三級頁面顯示有多余線條

圖10.19頭導(dǎo)航欄右邊顯示為空

(5)三級頁面標(biāo)題未居中。如圖10.20所示。

(6)首頁中，許多二級頁面鏈接未在新窗口中彈出。

(7)不能正確加入收藏。如圖10.21所示。

(8)

Flash字顯示不完整。如圖10.22所示。

圖10.20三級頁面標(biāo)題未居中

圖10.21“加入收藏”功能不能實現(xiàn)

圖10.22Flash字顯示不完整氣象局網(wǎng)頁測試完成時間：2009-12-14

9．縣金融辦網(wǎng)頁測試結(jié)果

測試時間：2009-12-14，測試人：ANDY

存在問題：

(1)三級郵箱頁面，分頁條數(shù)太多。如圖10.23所示。

(2)首頁下方，圖片沒有對齊。如圖10.24所示。

(3)“領(lǐng)導(dǎo)信箱”按鈕應(yīng)居中。如圖10.25所示。

圖10.23分頁條數(shù)太多

圖10.24圖片未對齊

圖10.25按鈕未居中

(4)后臺郵箱回復(fù)，JS驗證有問題。

金融辦網(wǎng)頁測試完成時間：2009-12-14,17:45:20

由于平臺服務(wù)器是通過接口來與客戶端交互數(shù)據(jù)提供各種服務(wù)，因此服務(wù)器測試工作首先需要進(jìn)行的是接口測試工作。測試人員需要通過服務(wù)器接口功能測試確保接口功能實現(xiàn)正確，那么其他測試人員在進(jìn)行客戶端與服務(wù)器結(jié)合的系統(tǒng)測試過程中，就能夠排除由于服務(wù)器接口缺陷所導(dǎo)致的客戶端問題，便于開發(fā)人員定位問題。以下是個人平臺服務(wù)器接口功能測試方案。10.4服務(wù)器接口功能測試案例

1.接口測試范圍

根據(jù)服務(wù)器的測試需求，接口測試范圍主要分為

(1)新增接口；

(2)新增業(yè)務(wù)功能接口；

(3)整個服務(wù)器的接口。

所需測試接口依次增多，在測試時間足夠的條件下，需要對所有接口進(jìn)行測試用例的設(shè)計，但如果測試時間較短，則應(yīng)該首先根據(jù)用戶的典型操作對測試接口進(jìn)行優(yōu)先級劃分，對調(diào)用頻繁接口需要優(yōu)先進(jìn)行測試。

2.接口測試策略

在進(jìn)行平臺服務(wù)器接口測試之前，首先需要整理服務(wù)器接口的測試方案，分析接口測試的要點，平臺服務(wù)器的接口測試內(nèi)容主要有以下幾種：

(1)接口設(shè)計檢查。接口用于服務(wù)器與客戶端的數(shù)據(jù)交互，客戶端通過網(wǎng)絡(luò)協(xié)議傳遞的數(shù)據(jù)為服務(wù)器接口的輸入數(shù)據(jù)，因此應(yīng)該首先通過服務(wù)器接口文檔及客戶端數(shù)據(jù)約束文檔進(jìn)行交互數(shù)據(jù)的有效性檢查：

●整數(shù)型數(shù)據(jù)位數(shù)檢查；

●浮點型數(shù)據(jù)精度檢查；●字符串?dāng)?shù)據(jù)范圍值檢查。

要求客戶端的整數(shù)型、浮點型、字符串?dāng)?shù)據(jù)以及其最大值和最小值都能作為服務(wù)器接口的有效輸入。這些工作在服務(wù)器設(shè)計評審時就可以進(jìn)行，以便確保不會出現(xiàn)客戶端上傳數(shù)據(jù)被服務(wù)器自動進(jìn)行截斷或四舍五入的操作。

(2)接口依賴關(guān)系檢查。以上策略只談到單個接口的測試方法，對于用戶來說，一個操作可能會造成服務(wù)器調(diào)用多個接口來進(jìn)行完成，因此還需要從業(yè)務(wù)處理的角度，對各種業(yè)務(wù)操作所涉及的多個接口之間依賴調(diào)用進(jìn)行測試。接口依賴關(guān)系檢查主要是通過接口的輸出值為另一接口的輸入值來實現(xiàn)的，因此在進(jìn)行接口測試之前，需要分析所測試接口的輸入值是通過客戶端還是其他接口輸出來獲取的，在設(shè)計測試用例時，加入接口的依賴關(guān)系說明以便于測試。

(3)接口輸入/輸出驗證。服務(wù)器接口功能測試類似于單元測試，在設(shè)計測試用例時，側(cè)重點在于接口模塊輸入/輸出項的正確性驗證，根據(jù)服務(wù)器接口處理方式，對各種接口進(jìn)行分類，分為條件判斷接口、數(shù)據(jù)查詢接口和邏輯運(yùn)算接口三類：第一類：條件判斷接口。

這類接口在接收到請求數(shù)據(jù)后，會根據(jù)輸入?yún)?shù)進(jìn)行條件判斷，然后返回相應(yīng)結(jié)果碼，通常涉及條件判斷的接口有：用戶鑒權(quán)接口、升級狀態(tài)上報、密碼修改/重置等接口。因此輸入/輸出項驗證的側(cè)重點主要集中在：

(1)判斷條件的驗證。要對判斷條件進(jìn)行驗證，則需要知道接口是根據(jù)哪些輸入項來進(jìn)行判斷的，以密碼重置接口為例：

『接口功能』：用戶登錄之后發(fā)起找回密碼操作，用戶輸入郵箱信息后，游戲中心將向平臺服務(wù)器發(fā)送請求，平臺服務(wù)器將隨機(jī)為用戶生成新的密碼，發(fā)到用戶的郵箱中。

『接口方向』：游戲中心→平臺服務(wù)器。

『遵循協(xié)議』：HTTPS，請求消息使用Post方式(見表10.12)。表10.12請求消息使用Post方式響應(yīng)消息(sendMessageRes)(見表10.13)。

表10.13響應(yīng)消息此接口根據(jù)輸入的userID、email參數(shù)來進(jìn)行數(shù)據(jù)正確性的判斷(key是接口名稱，如果錯誤服務(wù)器將不會處理，version是版本號，其值只是用于記錄，不參與判斷)，設(shè)計接口測試用例時，應(yīng)該首先對接口的判斷參數(shù)進(jìn)行驗證，這些輸入項不能為空，然后利用等價類劃分、邊界值方法來根據(jù)userID、email輸入項設(shè)計各種合法的數(shù)據(jù)，驗證接口是否可以正常處理。

(2)異常數(shù)據(jù)的響應(yīng)。只考慮正常情況，而不考慮異常場景是無法保證接口功能運(yùn)行正常，對于密碼重置接口，用戶ID不存在、不合法，郵箱輸入格式錯誤、用戶郵箱信息不存在或未激活就是測試時需要考慮的異常場景，設(shè)計這類輸入值，并且檢查接口返回的響應(yīng)碼，響應(yīng)碼的正確才能保證客戶端根據(jù)異常情況來顯示相應(yīng)的提示信息。簡而言之，條件判斷的接口其測試策略就是根據(jù)判斷條件來設(shè)計各種輸入值來檢驗接口的功能。第二類：數(shù)據(jù)查詢接口。

這類接口接收到請求數(shù)據(jù)后，首先會驗證請求是否合法，然后會根據(jù)請求項查詢數(shù)據(jù)庫相應(yīng)中數(shù)據(jù)返回給客戶端，通常涉及數(shù)據(jù)查詢的接口有：用戶基本資料/經(jīng)驗值/賽事信息查詢、游戲列表獲取、在線人數(shù)查詢等接口，以用戶經(jīng)驗值查詢接口為例：

『接口功能』：用戶登錄游戲中心后，可以查詢自己每個游戲項目的經(jīng)驗值信息，包括此項目的經(jīng)驗值等級、等級稱號、今日經(jīng)驗值上限等。

『接口方向』：游戲中心→平臺服務(wù)器。

『遵循協(xié)議』：HTTP+XML，請求消息使用Post方式(見表10.14)。表10.14請求消息使用Post方式表10.15響應(yīng)消息此接口首先會根據(jù)webkey來判斷請求是否合法，然后根據(jù)請求參數(shù)中的userID、isAll、sportItemID來查詢數(shù)據(jù)表中相應(yīng)數(shù)據(jù)。除了像條件判斷接口一樣根據(jù)判斷項webkey、請求參數(shù)userID、isAll、sportItemID設(shè)計合法/不合法和正常/異常測試值之外，還需要結(jié)合數(shù)據(jù)庫來對查詢結(jié)果進(jìn)行驗證：

(1)是否根據(jù)正確的關(guān)聯(lián)數(shù)據(jù)表進(jìn)行查詢；

(2)驗證查詢結(jié)果是否從數(shù)據(jù)表中正確項中獲取，涉及到多表聯(lián)合查詢時，不同表中的相同項設(shè)計不同測試數(shù)據(jù)進(jìn)行驗證；

(3)修改查詢結(jié)果在數(shù)據(jù)表中對應(yīng)項中的數(shù)據(jù)，使其為空值或客戶端相應(yīng)項的范圍值的最大和最小值，查看接口輸出是否正確。

第三類：邏輯運(yùn)算接口。

這類接口在收到請求數(shù)據(jù)之后，會進(jìn)行一系列邏輯運(yùn)算，然后根據(jù)處理結(jié)果更新數(shù)據(jù)庫中的數(shù)據(jù)，通常涉及邏輯運(yùn)算的接口有：比賽成績同步、商品支付、各種數(shù)據(jù)報表等接口，以比賽成績同步接口為例：

『接口功能』：游戲服務(wù)器將用戶每次的比賽成績傳給平臺服務(wù)器，平臺服務(wù)器根據(jù)用戶的比賽成績更新此用戶的賽事排名，然后存入數(shù)據(jù)庫。

『接口方向』：游戲服務(wù)器→平臺服務(wù)器。

『遵循協(xié)議』：HTTPS+XML，請求消息使用Post方式(見表10.16)。表10.16請求消息使用Post方式表10.17響應(yīng)消息參數(shù)說明此接口比數(shù)據(jù)查詢接口又更加復(fù)雜，除了用條件判斷和數(shù)據(jù)查詢類接口的策略對此接口進(jìn)行測試用例設(shè)計之外，還需要驗證對接口的算法規(guī)則進(jìn)行檢查，因為此接口涉及根據(jù)用戶比賽成績(record)進(jìn)行排名然后返回其得分及排名情況(score、rank、upRankFlag、exp)，通過對相關(guān)數(shù)據(jù)表中的數(shù)據(jù)進(jìn)行查看方式，接口算法規(guī)則驗證包括：

(1)用戶勝利、失敗、中途主動/被動退出、規(guī)定時間內(nèi)未完成比賽情況下，此場比賽得分(scroe)是否正確；

(2)用戶比賽成績比上次成績花費(fèi)時間短/長/持平情況下，排名情況(upRankFlag)是否正確；

(3)用戶比賽成績處于第一名、最后一名、比上次成績花費(fèi)時間短/長/持平情況下，用戶積分排名(rank)是否正確；

(4)用戶勝利、失敗、中途主動/被動退出、規(guī)定時間內(nèi)未完成比賽，并且用戶經(jīng)驗值在各種經(jīng)驗等級范圍下，經(jīng)驗值根據(jù)得分進(jìn)行計算的公式是否正確。

邏輯運(yùn)算接口由于還涉及插入或更新數(shù)據(jù)庫操作，因此測試時還需要考慮數(shù)據(jù)庫特性，如數(shù)據(jù)精度問題，在MySQL數(shù)據(jù)庫中，如果是浮點型數(shù)據(jù)，存入時會有精度誤差(131072.32插入float(10,2)類型的數(shù)據(jù)會變?yōu)?31072.31)，因此對于需要用于金額計算、數(shù)據(jù)統(tǒng)計、成績比較的數(shù)據(jù)，最好使用定點型。

最后服務(wù)器接口的測試如果有足夠條件的話，還需要通過白盒測試來對接口代碼做進(jìn)一步的測試，通過編寫關(guān)鍵代碼的測試樁，可以有效查找將字符數(shù)組當(dāng)成字符串使用造成的讀越界這類不易通過黑盒測試發(fā)現(xiàn)的Bug。接下來的工作就是如何通過測試工具來執(zhí)行服務(wù)器接口功能測試。

手機(jī)測試案例描述各版本移動終端產(chǎn)品定義對終端軟件功能測試所需的測試環(huán)境、測試內(nèi)容和測試結(jié)果的要求。測試內(nèi)容涵蓋了終端基本功能、基本功能交叉、業(yè)務(wù)功能、部分協(xié)議支持測試等方面，并對測試結(jié)果的要求做了詳細(xì)的規(guī)定。對于進(jìn)一步的網(wǎng)絡(luò)交叉測試、現(xiàn)場測試和穩(wěn)定性測試本方案中不提供測試項。下面以基本通話作為測試對象給出測試案例分析，包括來電響鈴、來電通話和呼叫功能等。10.5手機(jī)測試計劃案例

1．來電響鈴

來電響鈴測試過程見表10.18～表10.21。

表10.18來電響鈴測試過程1表10.19來電響鈴測試過程2表10.20來電響鈴測試過程3表10.21來電響鈴測試過程4

2．來電通話

來電通話測試過程見表10.22～表10.24。

表10.22來電通話測試過程1表10.23來電通話測試過程2表10.24來電通話測試過程33．呼出功能

呼出功充測試過程見表10.25～表10.29。

表10.25呼出功能測試過程1表10.26呼出功能測試過程2表10.27呼出功能測試過程3表10.28呼出功能測試過程4表10.29呼出功能測試過程5

QTP(QuicktestProfessional)是一種自動測試工具。使用QTP的目的是執(zhí)行重復(fù)的手動測試，主要是用于回歸測試和測試同一軟件的新版本。在QTP中，可以通過把測試腳本中固定的值替換成參數(shù)的方式來擴(kuò)展測試腳本，這個過程也叫參數(shù)化測試，能有效地提高測試的靈活性。10.6參?數(shù)?化?測?試在QTP中，可以使用多種方式來對測試腳本進(jìn)行參數(shù)化，數(shù)據(jù)表參數(shù)化是其中一種重要的方式，還有環(huán)境變量參數(shù)化、隨機(jī)數(shù)參數(shù)化等。下面以QTP自帶的“Flight”程序為例，介紹如何對測試腳本進(jìn)行參數(shù)化。假設(shè)在名為“FlightReservation”的訂票界面中，輸入航班信息后，插入訂票記錄；然后希望重新打開該記錄，檢查航班信息中的終點的設(shè)置是否正確，錄制的測試腳本如圖10.26所示。

圖10.26QTP中測試腳本界面

1．參數(shù)化測試步驟

把測試步驟中的輸入數(shù)據(jù)進(jìn)行參數(shù)化，例如航班日期、航班始點和終點等信息。下面以“輸入終點”的測試步驟的參數(shù)化過程為例，介紹如何在關(guān)鍵字視圖中對測試腳本進(jìn)行參數(shù)化。

(1)選擇“FlyTo:”所在的測試步驟行，單擊“Value”列所在的單元格，如圖10.27所示。

圖10.27參數(shù)化測試步驟中“Value”列界面

(2)單擊單元格旁邊的“<#>”按鈕，或按快捷鍵“Ctrl

+

F11”，則出現(xiàn)如圖10.28所示的界面。

圖10.28“Value”配置界面提示：在這個界面中，選擇“Parameter”，在旁邊的下拉框中選擇“DataTable”，在“Name”中輸入?yún)?shù)名，也可接受默認(rèn)名，在“LocationinDataTable”中可以選擇“Globalsheet”，也可以選擇“Currentactionsheet(local)”，它們的區(qū)別是參數(shù)存儲的位置不同。

(3)單擊“OK”按鈕，在關(guān)鍵字視圖中可看到，“Value”值已經(jīng)被參數(shù)化，替換成了如圖10.29所示內(nèi)容。

圖10.29“Value”值參數(shù)化界面

(4)這時，選擇菜單“View|DataTable”，則可看到如圖10.30所示的界面。

圖10.30選擇數(shù)據(jù)表項后的界面在圖10.30中可以看到，在“p_Item”列中有一個默認(rèn)數(shù)據(jù)“Frankfurt”，這是參數(shù)化之前錄制的腳本中的常量，可以在“p_Item”列中繼續(xù)添加更多的測試數(shù)據(jù)。

(5)把其他幾個數(shù)據(jù)也參數(shù)化后，結(jié)束如圖10.31所示。

圖10.31其他幾個數(shù)據(jù)參數(shù)化后的界面

QTP運(yùn)行時，會從如圖10.32所示的數(shù)據(jù)表中提取數(shù)據(jù)來對測試過程中的各項輸入進(jìn)行參數(shù)化。

圖10.32數(shù)據(jù)表提取數(shù)據(jù)進(jìn)行參數(shù)化界面

2．使用隨機(jī)數(shù)來進(jìn)行參數(shù)化

對于選擇航班這個測試步驟的參數(shù)化來說會有所不同，因為航班會隨所選擇的起點和終點而變化，因此，需要做特殊的處理。操作代碼如下：

'取得航班列表的行數(shù)

ItemCount=Window("FlightReservation").Dialog("FlightsTable").WinList("From").GetItemsCount

'隨機(jī)選取其中一項

SelectItem=RandomNumber(0,ItemCount)

'選擇航班

Window("FlightReservation").Dialog("FlightsTable").WinList("From").SelectSelectItem

先通過訪問GetItemsCount屬性，獲取航班列表的行數(shù)，然后使用RandomNumber隨機(jī)選取其中一項，最后，再通過Select方法選擇航班。參數(shù)化后的測試步驟如圖10.33所示。

圖10.33航班主列表參數(shù)化后的測試界面

提示：使用隨機(jī)數(shù)也是測試腳本參數(shù)化的一種重要方法，在QTP的測試代碼中，可用RandomNumber來實現(xiàn)。關(guān)鍵字視圖編輯的界面如圖10.34所示，其效果與在腳本中直接編輯是一樣的。

圖10.34關(guān)鍵字視圖編輯界面

3．參數(shù)化檢查點

測試腳本的最后一個測試步驟是檢查訂票記錄中的航班終點是否正確，同樣需要進(jìn)行適當(dāng)?shù)膮?shù)化，方法如下：

(1)單擊檢查點所在測試步驟的“Value”列中的單元格，如圖10.35所示。

圖10.35選取“Value”列后的界面

(2)單擊旁邊的按鈕，則出現(xiàn)如圖10.36所示的界面。

(3)在“Configurevalue”中選擇“Parameter”后，可單擊“OK”按鈕接收默認(rèn)的設(shè)置，也可單擊旁邊的編輯按鈕，在如圖10.37所示的界面中，進(jìn)行參數(shù)化的詳細(xì)設(shè)置。

在“Parametertypes”中，選擇“DataTable”；可在“Name”欄修改參數(shù)名，或接受默認(rèn)的命名，產(chǎn)生如圖10.38所示的數(shù)據(jù)列。也可以選擇“Fly_To”，因為檢查點所指的航班終點得到的預(yù)期值應(yīng)該與測試步驟中選擇航班終點時的輸入數(shù)據(jù)一致，否則認(rèn)為錯誤。

圖10.36檢查點屬性設(shè)置界面

圖10.37參數(shù)選項配置界面

圖10.38數(shù)據(jù)表中航班終點測試界面

4．設(shè)置數(shù)據(jù)表格迭代方式

測試步驟和檢查點的參數(shù)化工作都完成后，可得到如圖10.39所示的測試步驟。

圖10.39檢查點參數(shù)化后界面

圖10.40專家視圖下的測試腳本界面運(yùn)行這個測試腳本之前，還要做一些必要的設(shè)置。選擇菜單“File|Settings”，出現(xiàn)如圖10.41所示的測試設(shè)置界面，切換到“Run”頁，在“DataTableiterations”中，可設(shè)置數(shù)據(jù)表格的迭代方式。

圖10.41測試設(shè)置界面

提示：“Runoneiterationonly”是指僅運(yùn)行一次迭代，也就是說，即使DataTable中有多條測試數(shù)據(jù)，也僅執(zhí)行一次；“Runonallrows”則是指按數(shù)據(jù)表格中的所有數(shù)據(jù)都運(yùn)行一次；選擇“Runfromrow_torow_”可設(shè)置運(yùn)行的測試數(shù)據(jù)范圍。

選擇“Runonallrows”，得到如圖10.42所示測試結(jié)果。

圖10.42選擇“Runonallrows”后的測試結(jié)果界面

在VisualStudio2010中，敏捷測試驅(qū)動開發(fā)功能非常強(qiáng)大，微軟把Scrum和XP敏捷思想融入到Agile過程框架之中(XP只是敏捷過程框架中的一種)。VS2010中增強(qiáng)了團(tuán)隊源碼版本管理、迭代開發(fā)和驅(qū)動測試開發(fā)模型等，從而給微軟.Net開發(fā)人員非常大的幫助。10.7使用VisualStudio2010實現(xiàn)敏捷驅(qū)動測試開發(fā)

Scrum和XP中的需求是以“用戶故事”(UserStory)的形式描述的，用戶故事實質(zhì)上就是一種軟件“特性”(Feature)。TDD是指如何通過編寫“測試”，尤其是單元測試，來驅(qū)動軟件的設(shè)計和編程。在敏捷XP中，是采用TDD驅(qū)動軟件的設(shè)計和編程實踐，即測試驅(qū)動開發(fā)。VisualStudio2010測試和單元測試過程，如圖10.43所示。

圖10.43VisualStudio測試過程圖中，IUT——在生產(chǎn)環(huán)境中最終交付而開發(fā)的軟件。

TestEnvironment——測試環(huán)境。

測試驅(qū)動開發(fā)(TDD)的基本過程：

(1)明確當(dāng)前要完成的功能。可以記錄成一個初始化測試清單(TODO)列表。

(2)快速完成針對一個功能的測試用例編寫。

(3)測試代碼編譯通過，但測試用例通不過。

(4)編寫對應(yīng)的功能代碼。

(5)測試通過。

(6)對代碼進(jìn)行重構(gòu)，并保證測試通過。

(7)循環(huán)完成所有功能的開發(fā)。

應(yīng)用&實踐：VisualStudio2010實現(xiàn)敏捷測試驅(qū)動開發(fā)——圖書收藏實例。

(1)確定好Backlog，進(jìn)行SprintBacklog，把Story拆分成更小的故事，再把故事拆分成任務(wù)，即圖書收藏Story索引卡片，在為圖書借閱集合初始化測試清單時，要將案例分成任務(wù)，以便實現(xiàn)讀者個人借閱圖書的收藏集合。

當(dāng)讀者到圖書館進(jìn)行圖書借閱時，會查詢圖書庫所有相關(guān)類圖書封面并選取其中自己最需要的幾本書。這個過程叫做“書簽”，圖書系統(tǒng)將通過圖書管理來支持這個活動。圖書借閱集合初始化測試清單如下：

①

Count==0②添加(Collection)Count==1

③添加(Collection)，移除(Collection)，Count==0

④添加(Collectionl)，移除(Collection2)，Count==2

⑤添加(Collection)，移除(Collection)，應(yīng)該返回trse

……

圖書借閱集合初始化測試重點放在確保添加和移除圖書收藏夾的時候計數(shù)是正確的，以及集合的內(nèi)容和是否可以恢復(fù)集合，在驅(qū)動測試時間持續(xù)1到2小時的驅(qū)動編程實踐中完成這個測試清單，并確保這個測試清單實現(xiàn)測試目標(biāo)，不需要再次分解這個任務(wù)。

(2)實現(xiàn)第一個測試。打開MicrosoftVisualStudio2010，創(chuàng)建一個C#測試項目，項目名稱為LocalBookCollectionsTests。清除原項目方案自動生成的unit的C#測試文件，建立一個新的名稱為CollectionsTests單元測試類，如圖10.44所示。

圖10.44使用Visualstdio建立單元測試類先用一些函數(shù)代碼替換第一個測試中的語句，這樣做驅(qū)動了產(chǎn)品代碼Collections類的創(chuàng)建，并運(yùn)行其Count屬性。在CollectionsTests.cs類添加代碼：

///<summary>，創(chuàng)建一個測試清單，</summary>

[TestMethod]

publicvoidEmptyCollectionsCountShouldBeZero()

{Collctionscollctions=newCollctions();

Assert.AreEqual(0,collctions.Count);}

重新編譯生成這個解決方案，將看到一個錯誤，因為沒有為Collections類定義Count。創(chuàng)建Collections類，填入如下代碼：

///<summary>，定義Count，</summary>

privateintcount;

publicintCount

{get

{returncount;}}

運(yùn)行這個測試，輸出EmptyCollectionsCountShouldBeZero()單元測試成功界面，如圖10.45所示。

圖10.45單元測試后成功界面

(3)擱置測試清單代碼。為此次操作添加一個版本控制擱置，這樣就可以在將來常常返回到這個點(版本控制)，在VS2010菜單打開View|OtherWindows|PendingChanges，如圖10.46所示。

圖10.46打開“View|OtherWindows

|

PendingChanges”后的界面

圖10.47擱置窗口界面“Unshelve”按鈕可以進(jìn)行版本回卷。單擊“Shelve”按鈕進(jìn)行版本擱置，建立一個TesttheShouldBeZero的版本擱置，如圖10.48所示。

圖10.48版本回卷界面

(4)修復(fù)一個失敗的測試和重構(gòu)。它們在Collections對象中添加和刪除各種Collection項，并驗證Count熟悉返回正確的值。首先在CollectionsTests.cs類中添加如下代碼：

///<summary>，修復(fù)一個失敗的測試，</summary>

[TestMethod]

publicvoidEmptyCollctionsCountShouldIsOne(

{Collectionscollections=newCollections();

collections.Add(newCollection("Label",newUri("db://book0001")));

Assert.AreEqual(1,collections.Count);}

生成這個項目(生成|生成項目)，生成報錯是因為Collection類缺少參數(shù)。

添加一個unit新類Collection.cs，加入以下代碼：

privatestringlabel;

privateUriuri;

publicCollection(stringlabel,Uriuri)

{this.label=label;

this.uri=uri;}

publicstringLabel

{get{returnlabel;}} publicUriUri

{get{returnuri;}}

替換Collections.Add()方法，修改Count屬性返回count變量值。

///<summary>,增加一個Count實例變量,</summary>,<paramname="collction"></param>

publicvoidAdd(Collectioncollction){count++;}

再次生成這個項目，輸出結(jié)果顯示成功。再次重復(fù)上面操作，創(chuàng)建一個版本擱置。

(5)構(gòu)建驗證測試(BVT)。生成確認(rèn)測試(BVT)是通過產(chǎn)生測試列表來檢查軟件，它通常作為一個生成任務(wù)在團(tuán)隊生成結(jié)束的時候執(zhí)行。當(dāng)編寫好一個unit測試時，可以加入到BVT中，確保任何時候在生存庫環(huán)境下運(yùn)行集成生成，相同的測試程序都可以依次執(zhí)行。這樣，由VS2010的單元測試(Unittest)→每日構(gòu)建→集成構(gòu)建驗證(BVT)，形成保證軟件質(zhì)量安全的網(wǎng)。把上面的EmptyCollctionsCountShouldBeZero()和EmptyCollctionsCountShouldIsOne()測試方法創(chuàng)建生成測試。打開MicrosoftVisualStudio2010菜單，單擊Test|Windows，如圖10.49所示：

單擊菜單項Test|Windows|TestListEditor，打開TestListEditor界面，如圖10.50所示。

圖10.49VS構(gòu)建驗證測試窗口界面

圖10.50測試列表編輯界面單擊界面“here”或者菜單Test|CreateNewTestList，創(chuàng)建一個新的測試列表，測試列表名稱為BookCollectionBVT，如圖10.51所示。

圖10.51創(chuàng)建新的測試列表同理，打開菜單項Test|Windows|TestView，打開TestView瀏覽框，從而顯示驅(qū)動單元測試程序，從TestView把EmptyCollctionsCountShouldBeZero和EmptyCollctionsCountShouldIsOne拖放到TestListEditor面板中，為了確保這個測試是作為集成測試的一部分運(yùn)行，單擊BookCollectionBVT中所要測試程序的復(fù)選框。

單擊RunCheckedTests按鈕，運(yùn)行這個測試程序，如圖10.52所示。

圖10.52運(yùn)行檢查測試程序

圖10.53測試結(jié)果界面這樣，安裝了MicrosoftVisualStudio2010的團(tuán)隊成員，在每個人的本機(jī)開發(fā)環(huán)境上運(yùn)行自己的單元測試之后，就可以添加并測試完成余下的那些索引卡下分解出來的測試列表單元測試程序清單，加入到BookCollectionBVT集成測試集合之中。

Scrum專注于聚焦找到一個最小的迭代式項目管理框架，注重敏捷的計劃、跟蹤和管理，而沒有把它強(qiáng)行綁定在某一種具體的工程技術(shù)和做法之上，這也是它非常聰明的地方。既然沒有明確限定和約束，那么就代表著開放，可以適用于不同類型和不同環(huán)境的項目。提示：順序測試(OrderedTest)。

在VS2010版本中，微軟把WebTest改為WebPerformanceTest。可以在VS2010解決方案資源管理器，打開一個測試項目，右鍵菜單Add/OrderedTest或者在VS2010IDE菜單Test/NewTes/OrderedTest進(jìn)行創(chuàng)建。

順序測試可以對單元、Web、load等測試集執(zhí)行順序手動排序，可以是BVT中的一部分。順序測試是為了按一個指定的順序(有序)運(yùn)行集成測試。在測試管理和測試視圖窗口顯示為單一測試，其結(jié)果顯示在單行的測試結(jié)果窗口，可以獲取每個被測試的一部分并有序運(yùn)行測試單獨的結(jié)果，如圖10.54所示。

圖10.54順序測試界面

超市管理系統(tǒng)的測試計劃，包括七個方面。

1．簡介

(1)目的?！俺泄芾硐到y(tǒng)測試計劃”文檔有助于實現(xiàn)以下目標(biāo)：

●

確定超市管理系統(tǒng)的信息和超市管理系統(tǒng)測試的軟件構(gòu)件。10.8超市管理系統(tǒng)測試計劃●

針對超市管理系統(tǒng)推薦可采用的超市管理系統(tǒng)測試策略，并對這些策略加以說明。

●

確定所需的資源，并對超市管理系統(tǒng)測試的工作量進(jìn)行估計。

●

列出超市管理系統(tǒng)測試項目的可交付元素。

(2)背景。對超市管理系統(tǒng)(構(gòu)件、應(yīng)用程序、系統(tǒng)等)及其目標(biāo)進(jìn)行簡要說明，包括的信息有：主要的功能和性能、超市管理系統(tǒng)的構(gòu)架以及項目的簡史。

(3)范圍。描述超市管理系統(tǒng)測試的各個階段(如單元超市管理系統(tǒng)測試、集成超市管理系統(tǒng)測試或系統(tǒng)超市管理系統(tǒng)測試)，并說明本計劃所針對的超市管理系統(tǒng)測試類型(如功能超市管理系統(tǒng)測試或性能超市管理系統(tǒng)測試)。

簡要地列出超市管理系統(tǒng)中將接受超市管理系統(tǒng)測試或?qū)⒉唤邮艹泄芾硐到y(tǒng)測試的那些性能和功能。如果在編寫此文檔的過程中做出的某些假設(shè)可能會影響超市管理系統(tǒng)測試設(shè)計、開發(fā)或?qū)嵤?，則列出所有這些假設(shè)。

列出可能會影響超市管理系統(tǒng)測試設(shè)計、開發(fā)或?qū)嵤┑乃酗L(fēng)險或意外事件及所有約束。

2．超市管理系統(tǒng)測試參考文檔和超市管理系統(tǒng)測試提交文檔

1)超市管理系統(tǒng)測試參考文檔

表10.30列出了制訂超市管理系統(tǒng)測試計劃時所使用的文檔，并標(biāo)明了各文檔的可用性。表10.30超市管理系統(tǒng)測試文檔

2)超市管理系統(tǒng)測試提交文檔

下面列出在超市管理系統(tǒng)測試階段結(jié)束后，所有可提交的文檔見表10.31。

表10.31超市管理系統(tǒng)測試提交文檔3．超市管理系統(tǒng)測試進(jìn)度

超市管理系統(tǒng)測試進(jìn)度見表10.32。

表10.32超市管理系統(tǒng)測試進(jìn)度表4．超市管理系統(tǒng)測試資源

1)超市管理系統(tǒng)測試環(huán)境

超市管理系統(tǒng)測試的系統(tǒng)環(huán)境：

軟件環(huán)境(相關(guān)軟件、操作系統(tǒng)等)：WindowsXP、VisualC++、VisualBasic。

硬件環(huán)境(網(wǎng)絡(luò)、設(shè)備等)：32位機(jī)。

2)超市管理系統(tǒng)測試工具

此項目將列出超市管理系統(tǒng)測試使用的工具(見表10.33)。表10.33超市管理系統(tǒng)測試工具表

5．超市管理系統(tǒng)測試策略

超市管理系統(tǒng)測試策略提供了對超市管理系統(tǒng)進(jìn)行超市管理系統(tǒng)測試的推薦方法。

對于每種超市管理系統(tǒng)測試，都應(yīng)提供超市管理系統(tǒng)測試說明，并解釋其實施的原因。

制訂超市管理系統(tǒng)測試策略時所考慮的主要事項有將要使用的技術(shù)以及判斷超市管理系統(tǒng)測試何時完成的標(biāo)準(zhǔn)。

下面列出了超市管理系統(tǒng)測試時需考慮的事項，除此之外，超市管理系統(tǒng)測試還應(yīng)在安全的環(huán)境中使用已知的、有控制的數(shù)據(jù)庫來執(zhí)行。注意：不實施某種超市管理系統(tǒng)測試，則應(yīng)該用一句話加以說明，并陳述理由。如“將不實施該超市管理系統(tǒng)測試。該超市管理系統(tǒng)測試本項目不適用”。

1)超市管理系統(tǒng)數(shù)據(jù)和數(shù)據(jù)庫完整性測試

在超市管理系統(tǒng)中，數(shù)據(jù)庫和數(shù)據(jù)庫進(jìn)程應(yīng)作為一個子系統(tǒng)來進(jìn)行超市管理系統(tǒng)測試。在超市管理系統(tǒng)測試這些子系統(tǒng)時，不應(yīng)將超市管理系統(tǒng)的用戶界面用作數(shù)據(jù)的接口。對于數(shù)據(jù)庫管理系統(tǒng)(DBMS)，還需要進(jìn)行深入的研究，以確定可以支持表10.34所示的超市管理系統(tǒng)測試的工具和技術(shù)。表10.34數(shù)據(jù)和數(shù)據(jù)庫完整性測試目標(biāo)2)超市管理系統(tǒng)接口測試

超市管理系統(tǒng)接口測試要求見表10.35。表10.35超市管理系統(tǒng)接口測試內(nèi)容

3)超市管理系統(tǒng)集成測試

超市管理系統(tǒng)集成測試主要目的是檢測系統(tǒng)是否達(dá)到需求，對業(yè)務(wù)流程及數(shù)據(jù)流的處理是否符合標(biāo)準(zhǔn)，對業(yè)務(wù)流處理是否存在邏輯不嚴(yán)謹(jǐn)及錯誤，檢測需求是否存在不合理的標(biāo)準(zhǔn)及要求(見表10.36)。此階段超市管理系統(tǒng)測試基于功能完成的超市管理系統(tǒng)測試。表10.36超市管理系統(tǒng)集成測試目標(biāo)

4)超市管理系統(tǒng)功能測試

對超市管理系統(tǒng)的功能測試應(yīng)側(cè)重于所有可直接追蹤到用例或業(yè)務(wù)功能及業(yè)務(wù)規(guī)則的超市管理系統(tǒng)測試需求。這種測試的目標(biāo)是核實數(shù)據(jù)的接收、處理和檢索是否正確，以及業(yè)務(wù)規(guī)則的實施是否恰當(dāng)。此類測試基于黑盒技術(shù)，該技術(shù)通過圖形用戶界面(GUI)與應(yīng)用程序進(jìn)行交互，并對交互的輸出或結(jié)果進(jìn)行分析，以此來核實應(yīng)用程序及其內(nèi)部進(jìn)程。表10.37為各種應(yīng)用程序列出了推薦使用的超市管理系統(tǒng)測試概要。表10.37超市管理系統(tǒng)功能測試目標(biāo)5)超市管理系統(tǒng)用戶界面測試

超市管理系統(tǒng)用戶界面(UI)測試用于核實用戶與軟件之間的交互。該測試的目標(biāo)是確保用戶界面為用戶提供相應(yīng)的訪問或瀏覽功能。另外，超市管理系統(tǒng)UI測試還可確保UI中的對象按照預(yù)期的方式運(yùn)行，并符合公司或行業(yè)的標(biāo)準(zhǔn)(見表10.38)。表10.38超市管理系統(tǒng)用戶接口測試目標(biāo)

6)性能測試

性能測試是對超市管理系統(tǒng)的響應(yīng)時間、事務(wù)處理速率和其他與時間相關(guān)的需求進(jìn)行評測和評估。性能評測的目標(biāo)是核實性能需求是否都已滿足。實施和執(zhí)行性能評測的目的是將超市管理系統(tǒng)的性能行為當(dāng)做條件(例如工作量或硬件配置)的一種函數(shù)來進(jìn)行評測和微調(diào)(見表10.39)。

注：以下所說的事務(wù)是指“邏輯業(yè)務(wù)事務(wù)”。這種事務(wù)被定義為將由系統(tǒng)的某個Actor通過使用超市管理系統(tǒng)來執(zhí)行的特定用例，添加或修改給定的合同。表10.39性能測評目標(biāo)7)超市管理系統(tǒng)負(fù)載測試

超市管理系統(tǒng)負(fù)載測試是一種性能測試。在這種測試中，將使超市管理系統(tǒng)承擔(dān)不同的工作量，以評測和評估超市管理系統(tǒng)在不同工作量條件下的性能行為，以及持續(xù)正常運(yùn)行的能力。超市管理系統(tǒng)負(fù)載測試的目標(biāo)是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外，該測試還要評估性能特征，如響應(yīng)時間、事務(wù)處理速率和其他與時間相關(guān)的方面(見表10.40)。注：以下所說的事務(wù)是指