測試用例范例

討論用TestDirector管理測試用例編制時間:2007-03-16編制部門:測試組編制人:郭宏元“測試用例”雖有國標作藍本，但實際中，一直以來“測試用例”是所有測試人員有爭議的地方，此所謂“仁者見仁，智者見智”。而“法無定法，則無定則”，所有的規(guī)范與標準都是圍繞更適應人們的工作環(huán)境而創(chuàng)建。在此，我就我的一些體會在此與大家分享。一般來說，“測試用例”的編寫主要分三大類，貫徹的原則與基本架構如下：分類：1、 對驗證過程的一個記錄；2、 展現(xiàn)一個功能；3、描述一個場景步驟；原則：1、有“對象”屬性的描述；2、闡述了某個“對象”的方法或事件。3、對屬性、方法或事件有詳細的定義?；炯軜嫞?、目的；2、 前提條件；3、輸入步驟（輸入動作或數(shù)據(jù)，預期結果）以下總結了一些針對測試用例的“編寫要點”作出一些較簡單的規(guī)范。以方便統(tǒng)一測試用例的編寫，并保證使用最用效的測試用例來保證測試質(zhì)量。我們都知道根據(jù)詳細設計文檔編寫測試用例的目的不在于驗證軟件達到的功能，而在于驗證軟件應該達到的功能，這樣可以去除軟件開發(fā)過程中的隨意性。所以下面就明確測試用例的“目的”、“范圍”、“原則”是什么？以及采用的方法做了一點描述。1、目的：圍繞測試名稱或滿足實現(xiàn)測試功能而進行。2、范圍：適用于所要測試的質(zhì)檢項目。3、功能測試用例編寫原則3.1單元測試功能用例的編寫目的單元測試用例的目的在于驗證單個模塊是否達到了詳細設計說明書中規(guī)定的功能，由于是單個模塊所以無法檢驗關聯(lián)性，可能會牽扯到數(shù)據(jù)庫的操作，例如：刪除時，需要查看數(shù)據(jù)庫是否完全刪除了數(shù)據(jù)。3.2集成測試功能用例的編寫目的集成測試功能用例的目的在于驗證軟件連接時，模塊的連接是否正確（及數(shù)據(jù)的傳遞是否正確）。.我們的軟件中體現(xiàn)出來的是，是否正確調(diào)用界面，界面之間顯示的數(shù)據(jù)是否正確，特別是財務、費用、數(shù)據(jù)方面的。集成測試用例的編寫過程中，經(jīng)常將功能用例與業(yè)務流程混合編寫，因為在集成測試時需驗證業(yè)務流程中的數(shù)據(jù)正確性，以及界面之間的數(shù)據(jù)傳遞的準確無誤。3.3系統(tǒng)測試業(yè)務流程用例的編寫目的系統(tǒng)測試業(yè)務流程用例的目的在于驗證軟件最終數(shù)據(jù)的準確性，我們的軟件體現(xiàn)為，手工數(shù)據(jù)與報表數(shù)據(jù)的一直性。用例與用例之間有著一定的關系，目的性十分明確。4、測試用例設計的原則全面性指編寫的測試用例應該覆蓋所有的“概要設計文檔”或“需求文檔”以及“測試申請文檔”中描述的功能。數(shù)據(jù)庫程序基本的增、刪、改功能增、改測試用例重點在于數(shù)據(jù)合法性、正確性的檢驗和提示信息的正確性的檢驗。輸入的數(shù)據(jù)可能有無限種組合，此時可以采用等價類劃分和邊界值法，下面有較詳細的說明。刪除的測試用例比較簡單，只有操作沒有數(shù)據(jù)的輸入，但是應該在“備注”中注明，刪除的限制條件，以及數(shù)據(jù)庫中應該刪除的表的情況，有條件限制時，測試用例應該包含各種刪除條件，必要時在添加或修改的測試用例后面或中間緊跟刪除的測試用例。對于無輸入的操作，應該詳細描述其具體的操作步驟和結果例如：選擇“用戶帳號”，可以通過多種途徑進行，此時應具體描述程序從何處進入，通過何種操作，達到查看“用戶帳號”界面。對于報表的測試用例，最好緊跟在輸入數(shù)據(jù)的后面，并且應該給出報表輸出的數(shù)據(jù)的界面圖（含數(shù)據(jù)）。對于不便書寫測試用例的情況，應該在備注中說明，并寫出可能的操作步驟。例如：對于文件夾的拖動，說明左右拖還是上下拖，結果如何就可以了。單元測試用例的書寫是使用一條數(shù)據(jù)，多種可能的情況考慮。但是對于其余各階段的測試用例，必須考慮多條數(shù)據(jù)時的情況，此時主用是針對新增多條數(shù)據(jù)后，進行刪、改、拖等情況的考慮。針對有結算的測試用例，數(shù)據(jù)的應考慮存在跨年、跨月的數(shù)據(jù)。正確性包括數(shù)據(jù)的正確性和操作的正確性。首先保證測試用例的數(shù)據(jù)正確。其次預期的輸出結果應該與測試數(shù)據(jù)發(fā)生的業(yè)務吻合。操作的預期結果應該與業(yè)務流程在程序執(zhí)行的結果吻合。4.3符合正常業(yè)務慣例測試數(shù)據(jù)應符合用戶實際工作業(yè)務流程，實際就是測試用例的先后順序，先新增，后修改或刪除，不能將刪除放在第一位。仿真性人名、地名、電話號碼等應具有模擬功能，符合一般的命名慣例；可操作性測試用例中應寫清測試的操作步驟，不同的操作步驟相對應的操作結果不同，達到的目的是，任何人，均可以根據(jù)測試用例，單獨進行測試。5、測試用例設計的方法測試用例的核心是輸入數(shù)據(jù)。預期輸出是依據(jù)輸入數(shù)據(jù)和程序功能來確定的，也就是說，對于某一程序，輸入數(shù)據(jù)確定了，預期輸出也就可以確定了，至于生成/銷毀被測試對象和測試的方法等，是所有測試用例都大同小異的，一般只有操作而沒有輸入。因此，我們討論測試用例設計方法時，重在輸入數(shù)據(jù)。而我們都知道，輸入數(shù)據(jù)包括四類：參數(shù)、成員變量、全局變量、IO媒體。IO媒體是指文件、數(shù)據(jù)庫或其他儲存或傳輸數(shù)據(jù)的媒體，例如，被測試函數(shù)要從文件或數(shù)據(jù)庫讀取數(shù)據(jù)，那么，文件或數(shù)據(jù)庫中的原始數(shù)據(jù)也屬于輸入數(shù)據(jù)。這四類數(shù)據(jù)中，只要所測試的程序需要執(zhí)行讀操作的，就要設定其初始值，顯然，把輸入數(shù)據(jù)的所有可能取值都進行測試，是不可能也是無意義的，我們應該用一定的規(guī)則選擇有代表性的數(shù)據(jù)作為輸入數(shù)據(jù)，主要有三種：正常輸入、邊界輸入、非法輸入。每種輸入還可以分類，也就是平常說的等價類法，每類取一個數(shù)據(jù)作為輸入數(shù)據(jù)，如果測試通過，可以肯定同類的其他輸入也是可以通過的。下面舉例說明：（1）正常輸入例如“字符串Trim函數(shù)”功能是將字符串前后的空格去除，那么正常的輸入可以有四類：前面有空格；后面有空格；前后均有空格；前后均無空格。（2） 邊界輸入上例中空字符串可以看作是邊界輸入。再如一個表示年齡的參數(shù)，它的有效范圍是0-100，那么邊界輸入有兩個：0和100。（3） 非法輸入非法輸入是正常取值范圍以外的數(shù)據(jù)，或使代碼不能完成正常功能的輸入，如上例中表示年齡的參數(shù)，小于0或大于100都是非法輸入，再如一個進行文件操作的函數(shù)，非法輸入有這么幾類：文件不存在；目錄不存在；文件正在被其他程序打開；權限錯誤。如果函數(shù)使用了外部數(shù)據(jù)，則正常輸入是肯定會有的，而邊界輸入和非法輸入不是所有函數(shù)都有。一般情況下，即使沒有設計文檔，考慮以上三種輸入也可以找出函數(shù)的基本功能點。實際上，一個合格的功能模塊測試，編碼時對上述三種輸入都是必須考慮的，否則代碼的健壯性就會成問題。下面詳細介紹一下“等價類劃分法”與“邊界值分析法”的原則與測試用例的編寫。5.1等價類劃分法5.1.1確定等價類的原則1） 如果輸入條件決定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。2） 如果輸入條件規(guī)定了輸入值的集合，或者規(guī)定了“必須如何”的條件，此時可確立一個有效等價類和一個無效等價類.3）如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類4）如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序?qū)γ總€輸入值分別進行處理，此時可為每一個輸入值確立一個有效等價類，此外，針對這組值確立一個無效等價類，它是所有不允許輸入值的集合5）如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同的角度違反規(guī)則）6）如果確知，已劃分的等價類中各元素在程序中的處理方式不同，則應將此等價類進一步劃分成更小的等價類測試用例的編寫1）為每一個等價類規(guī)定一個唯一的編號2）設計一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復這一步，直至所有的有效等價類都被覆蓋過3）設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直至所有的無效等價類都被覆蓋為止邊界值分析法5.2.1測試用例的編寫1）如果輸入條件規(guī)定了值的范圍，則應取剛達到這個范圍的邊界值，以及剛剛超越這個邊界范圍的值作為測試輸入數(shù)據(jù)2）如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最大多1、比最小的小1的數(shù)作為測試輸入數(shù)據(jù)3）根據(jù)詳細設計說明書的每個輸出條件，使用前面的原則4）如果程序的詳細設計說明書給出的輸入輸出域是有序集合，則應選取集合的每一個元素和最后一個元素作為測試用列5）如果程序中使用了一個內(nèi)部數(shù)據(jù)結構，則應當選擇這個內(nèi)部數(shù)據(jù)結構的邊界上的值作為測試用例6）分析詳細設計說明書，找出其他可能的邊界條件6、測試用例編寫格式細則舉例用TestDirector生成的測試用例。下面有兩份樣式舉例，其中一份是摘錄的別人的“測試用例”，希望在此可以“拋磚引玉”，對大家對測試用例的具體編寫有一定的啟示。另一份是根據(jù)自己編寫的“概要設計文檔”寫的“操作員新增開戶帳號“”測試用例”，以供大家參考分析。TestDirector中沒有關于測試用例的“目的”，以及該用例的“前提條件”等字段，因此，可以將用例的目的和前提條件等在“描述”字段中進行描述，注意事項等也可以在此描述，如果有測試數(shù)據(jù)的話，可以在描述字段中對測試數(shù)據(jù)進行描述，具體的測試數(shù)據(jù)以文本或Excel方式保存，作為該測試用例的“附件”。樣式舉例：用例名稱:啟動客戶端程序路徑:……主題：ZJ2006……設計狀態(tài):Design設計者:***創(chuàng)建日期:2006-06-11用例類型:MANUAL描述:目的：檢查服務程序能否以設計的五種方式正確啟動客戶端程序菜單啟動快捷鍵啟動1.3.鼠標雙擊啟動定時啟動隔時啟動前提條件：服務程序已經(jīng)運行；客戶端程序尚未運行；Steps:StepNameDescriptionExpectedResultStep1運行服務程序Server.exe服務程序運行；服務程序在系統(tǒng)托盤中顯示為圖標；Step2在服務程序圖標上單擊右鍵；在彈出的懸浮菜單中選擇【啟動在線升級程序】1.彈出懸浮菜單，包括【啟動在線升級程序】、【啟動定時服務】、【啟動隔時服務】和【關閉服務程序】四個菜單項；2.1如果柜臺系統(tǒng)需要更新，則彈出窗口提示

是否更新，選擇“Yes”按鈕則啟動客戶端程序進行更新，選擇“No”則關閉提示窗口；2.2如果柜臺系統(tǒng)不需要更新，則彈出窗口提示不需要更新，點擊“OK”按鈕關閉提示窗口；3服務程序下載version.txt并生成DownLoadList.ini文件到服務端程序的安裝目錄下的temp目錄中；4version.txt文件的內(nèi)容與服務器端的version.txt文件的內(nèi)容一樣；5服務程序根據(jù)version.txt文件的內(nèi)容與本地對應的文件進行比較，將需要升級的文件生成下載清單DownLoadList.ini6如果需要更新并確定要更新，則下載更新文件并解壓縮到Download目錄中；Step3雙擊服務程序圖標1如果柜臺系統(tǒng)需要更新，則彈出窗口提示是否更新，選擇“Yes”按鈕則啟動客戶端程序進行更新，選擇“No”則關閉提示窗口；2如果柜臺系統(tǒng)不需要更新，則彈出窗口提示不需要更新，點擊“0K”按鈕關閉提示窗口；3服務程序下載version.txt并生成DownLoadList.ini文件到服務端程序的安裝目錄下的temp目錄中；4version.txt文件的內(nèi)容與服務器端的version.txt文件的內(nèi)容一樣；5服務程序根據(jù)version.txt文件的內(nèi)容與本地對應的文件進行比較，將需要升級的文件生成下載清單DownLoadList.ini6如果需要更新并確定要更新，則下載更新文件并解壓縮到Download目錄中；Step4按啟動服務快捷鍵(Ctrl+F12)1如果柜臺系統(tǒng)需要更新，則彈出窗口提示是否更新，選擇“Yes”按鈕則啟動客戶端程序進行更新，選擇“No”則關閉提示窗口；2如果柜臺系統(tǒng)不需要更新，則彈出窗口提示不需要更新，點擊“0K”按鈕關閉提示窗口；3服務程序下載version.txt并生成DownLoadList.ini文件到服務端程序的安裝目錄下的temp目錄中；4version.txt文件的內(nèi)容與服務器端的version.txt文件的內(nèi)容一樣；5服務程序根據(jù)version.txt文件的內(nèi)容與本地對應的文件進行比較，將需要升級的文件生成下載清單DownLoadList.ini6如果需要更新并確定要更新，則下載更新文件并解壓縮到Download目錄中；

Step5修改配置文件Config.ini中的定時啟動時間(SpecifyTime)到啟動時間后，如果柜臺系統(tǒng)需要更新，則彈出窗口提示是否更新，選擇“Yes”按鈕則啟動客戶端程序進行更新，選擇“No”則關閉提示窗口；到啟動時間后，如果柜臺系統(tǒng)不需要更新，則彈出窗口提示不需要更新，點擊“OK”按鈕關閉提示窗口；3服務程序下載version.txt并生成DownLoadList.ini文件到服務端程序的安裝目錄下的temp目錄中；4version.txt文件的內(nèi)容與服務器端的version.txt文件的內(nèi)容一樣；5服務程序根據(jù)version.txt文件的內(nèi)容與本地對應的文件進行比較，將需要升級的文件生成下載清單DownLoadList.ini6如果需要更新并確定要更新，則下載更新文件并解壓縮到Download目錄中；Step6修改配置文件Config.ini中的隔時啟動時間長度(IntervalTime)每間隔隔時啟動時間長度后，如果柜臺系統(tǒng)需要更新，則彈出窗口提示是否更新，選擇“Yes”按鈕則啟動客戶端程序進行更新，選擇“No”則關閉提示窗口；每間隔隔時啟動時間長度后，如果柜臺系統(tǒng)不需要更新，則彈出窗口提示不需要更新，點擊“0K”按鈕關閉提示窗口；如果尚未對上一次的提示進行操作，而在此之間，升級狀態(tài)發(fā)生了變化，到新一次隔時啟動時間長度后，正確顯示提示信息；4服務程序下載version.txt并生成DownLoadList.ini文件到服務端程序的安裝目錄下的temp目錄中；5version.txt文件的內(nèi)容與服務器端的version.txt文件的內(nèi)容一樣；6服務程序根據(jù)version.txt文件的內(nèi)容與本地對應的文件進行比較，將需要升級的文件生成下載清單DownLoadList.ini7如果需要更新并確定要更新，則下載更新文件并解壓縮到Download目錄中；用例名稱：操作員新增開戶帳號路徑:……主題：ZJ2007……設計狀態(tài):Design設計者:***創(chuàng)建日期:2007-06-11用例類型:MANUAL描述:目的：檢查操作員是否能正常新增開戶帳號1.1.新登記開戶預受理開戶開戶卡開戶前提條件：1.用戶已在自服務進行了預受理注冊；批量開戶模塊已有批量開戶卡帳號；《概要設計文檔》——操作員新增開戶帳號案例：登陸進入操作員模塊點擊“開戶”，進行開戶操作：DOCASECASE新登記開戶1、打開“帳號開戶”界面；2、帳號ID自動加1；3、錄入必填字段；4、依次錄入其它界面內(nèi)容5、檢查判斷界面錄入字符的合理、合法性；IF錄入字符不符合數(shù)據(jù)表結構約束THEN系統(tǒng)給出提示6、點擊“確認提交”按鈕；IF必填字填==NULLTHEN系統(tǒng)判斷，并一一給出提示；檢查判斷用戶帳號、用戶名稱、安裝地址是否有重復值IF有重復值THEN系統(tǒng)給出提示保存界面錄入內(nèi)容CASE預受理開戶（用戶已在自服務進行了預受理注冊；）1、打開“預登記受理”查詢界面；2、按條件查詢或模糊查詢出要進行預受理的帳號；3、點擊“受理”按鈕，受理成功，進入“帳號開戶”界面重復“新登記開戶”的2—6的操作；CASE開戶卡開戶（批量開戶模塊已有批量開戶卡帳號；）1、打開“開戶卡受理”查詢界面；2、按查詢條件或模糊查詢出要進行受理的帳號；3、選中要受理的帳號；IF帳號“受理標志”=“1”

Then“受理”按扭激活，可以受理

點擊“受理”按鈕，進入“帳號開戶”界面Else“受理”按鈕灰色，不可以受理4、進入“帳號開戶界面”；重復“新登記開戶”的2—6的操作；EndCASESteps:StepNameDescriptionExpectedResultStep1登陸進入操作員模塊1） 帳號/密碼都正確；2） 能正常登陸；Step2點擊“開戶”進行開戶操作可以看到三