第一篇：小議軟件測試用例的設(shè)計論文

白盒測試技術(shù)中測試用例的設(shè)計方法研究

白盒測試方法的主要作用有：

（1）至少測試一次程序子模塊的所有獨立執(zhí)行路徑；

（2）針對所有可能的邏輯判定，至少一次取“真”或“假”兩種情況；（3）在運行界限內(nèi)和循環(huán)邊界處執(zhí)行循環(huán)體；

（4）測試程序內(nèi)部的數(shù)據(jù)結(jié)構(gòu)的有效性。在實際的數(shù)據(jù)測試中，如果程序具有多種循環(huán)嵌套的情況，不同的執(zhí)行路徑數(shù)目可能是天文數(shù)字，例如一個有5條路徑的嵌套20次循環(huán)的小程序，包含不同執(zhí)行路徑條數(shù)為520次方，如果每一條路徑測試1ms，全年無休時要測試完所有路徑需要約3170年的時間。因此，我們必須采用一些替代辦法，典型的方法是有選擇的執(zhí)行程序中某些最有代表性的通路。白盒測試的主要技術(shù)有：

1根據(jù)程序內(nèi)部的邏輯結(jié)構(gòu)設(shè)計測試用例的技術(shù)—邏輯覆蓋

（1）語句覆蓋，選擇足夠多的測試數(shù)據(jù)以使被測程序中每條語句都至少執(zhí)行一次。語句覆蓋不考慮對程序的邏輯覆蓋，它主要關(guān)心表達(dá)式的結(jié)果，卻對每個條件取不同值的情況不做測試。因此，語句覆蓋是比較弱的邏輯覆蓋標(biāo)準(zhǔn)。在圖論中和語句覆蓋對應(yīng)的是點覆蓋。

（2）判定覆蓋，又叫分支覆蓋，它首先滿足語句覆蓋的條件，同時對每個判定的每種可能的結(jié)果都至少執(zhí)行一次，即對每個分支都至少執(zhí)行一次每個判定，判定覆蓋對程序的邏輯覆蓋程度也不高。在圖論中和判定覆蓋相對應(yīng)的是邊覆蓋。

（3）條件覆蓋，指的是不僅每個語句至少執(zhí)行一次，而且使判定表達(dá)式中的每個條件都取到各種可能的結(jié)果，條件覆蓋中可能不包含判定覆蓋。

（4）判定/條件覆蓋，指選取足夠多的測試數(shù)據(jù)，使得判定表達(dá)式中的每個條件都取到各種可能的值，每個判定表達(dá)式也取到各種可能的結(jié)果。

（5）條件組合覆蓋，要求選擇足夠多的測試數(shù)據(jù)，使得每個判定表達(dá)式中條件的各種可能組合都至少出現(xiàn)一次。條件組合覆蓋是邏輯覆蓋標(biāo)準(zhǔn)中最強的。

（6）路徑覆蓋，指的是選取足夠多的測試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次。測試用例設(shè)計舉例1：如下圖1所示程序段流程，實現(xiàn)語句覆蓋需要設(shè)計的測試數(shù)據(jù)有：X=0，Y=3和X=-1，Y=2；實現(xiàn)條件覆蓋至少采用的測試數(shù)據(jù)有：X=0，Y=3和X=3，Y=1；實現(xiàn)判定覆蓋至少應(yīng)用的測試數(shù)據(jù)有X=0，Y=3，X=1，Y=2和X=-1，Y=2。

2測試程序的控制結(jié)構(gòu)，主要包括條件測試，循環(huán)測試和基本路徑測試。

其中基本路徑測試是由TomMcCabe提出的一種白盒測試技術(shù)，這種技術(shù)在設(shè)計測試用例時需要首先計算程序的環(huán)形復(fù)雜度，并用該復(fù)雜度為指南定義執(zhí)行路徑的基本集合。在實際測試中，僅靠基本路徑測試還不能滿足要求，還需要結(jié)合條件測試技術(shù)來檢查程序模塊中包含的邏輯條件，還有循環(huán)測試來專門測試循環(huán)結(jié)構(gòu)的有效性。

黑盒測試技術(shù)中的測試用例設(shè)計方法研究

黑盒測試主要用來測試軟件的功能特點，通過黑盒測試可以發(fā)現(xiàn)：（1）是否有遺漏了的功能或者不正確的功能；（2）能否有正確的接收輸入和正確的輸出結(jié)果，這主要針對接口而言；（3）是否有外部信息訪問錯誤或數(shù)據(jù)結(jié)構(gòu)錯誤，同時，軟件運行時能否滿足性能上的要求；（4）軟件在初始化或者退出時有無錯誤等；使用黑盒測試同樣不可能將所有可能的輸入條件和輸出條件用于測試，因為測試用例的組合是天文數(shù)字。例如一個程序有兩個輸入量和一個輸出量，在32位計算機上運行，若X，Y取整數(shù)，按窮舉測試時需要232×232=264組，如果一組數(shù)據(jù)需要1ms，全年無休，需要5億年的時間。顯然，我們必須設(shè)計合理的方案來減少測試用例的數(shù)量。目前黑盒測試的主要測試用例設(shè)計技術(shù)有：

1等價類劃分

等價類劃分是把程序的輸入域劃分成若干個數(shù)據(jù)類，據(jù)此導(dǎo)出測試用例，因為對于同一類中的數(shù)據(jù)而言其作用是相同的[3]。等價類劃分可以分為有效等價類和無效等價類。有效等價類是指符合程序功能要求的數(shù)據(jù)類，該類中包含的都是有意義的數(shù)據(jù)；而無效等價類指不能滿足程序正確運行或者預(yù)期結(jié)果的數(shù)據(jù)類的集合。我們在設(shè)計測試用例時，要同時考慮有效等價類和無效等價類的設(shè)計方案。等價類的劃分有自己的原則。在具體使用等價類劃分設(shè)計測試用例時有兩個步驟：（1）設(shè)計一個新的測試方案以盡可能多地覆蓋尚未被覆蓋的有效等價類，重復(fù)這一步驟直到所有有效等價類都被覆蓋為止；（2）設(shè)計一個新的測試方案，使它覆蓋一個而且只覆蓋一個尚未被覆蓋的無效等價類，重復(fù)這一步驟直到所有無效等價類都被覆蓋為止。

2邊界值分析

使用邊界值分析方法來設(shè)計測試用例時需要開發(fā)者具有一定的經(jīng)驗和創(chuàng)造性，通常根據(jù)劃分的輸入等價類和輸出等價類的邊界來確定邊界值的結(jié)果，即選取剛剛等于、剛剛小于和剛剛大于邊界值的測試數(shù)據(jù)，而不是選擇等價類內(nèi)部的數(shù)據(jù)作為測試用例。

3錯誤推測法

錯誤推測法主要依靠直覺和經(jīng)驗，需要有一定開發(fā)大型軟件工程的經(jīng)驗，其基本思想是通過列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況，并根據(jù)這些情況來選擇測試方案。

小結(jié)

測試用例的設(shè)計方法并不是獨立使用的，而是經(jīng)常會進行一些不同設(shè)計方案的組合，如黑盒測試中的等價類劃分和邊界分析方法可以結(jié)合使用，進步設(shè)計更加合理的測試用例，找出更多的軟件運行錯誤。

第二篇：測試用例設(shè)計步驟

測試用例設(shè)計步驟

設(shè)計測試案例的時候，需要有清晰的測試思路，對要測試什么，按照什么順序測試，覆蓋哪些需求做到心中有數(shù)。測試用例編寫者不僅要掌握軟件測試的技術(shù)和流程，而且要對被測軟件的設(shè)計、功能規(guī)格說明、用戶試用場景以及程序/模塊的結(jié)構(gòu)都有比較透徹的理解。測試用例設(shè)計一般包括以下幾個步驟：

1、測試需求分析

從軟件需求文檔中，找出待測試軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點是：包含軟件需求，具有可測試性。測試需求應(yīng)該在軟件需求基礎(chǔ)上進行歸納、分類或細(xì)分，方便測試用例設(shè)計。測試用例中的測試集與測試需求的關(guān)系是多對一的關(guān)系，即一個或多個測試用例集對應(yīng)一個測試需求。

2、業(yè)務(wù)流程分析

軟件測試，不單純是基于功能的黑盒測試，還需要對軟件的內(nèi)部處理邏輯進行測試。為了不遺漏測試點，需要清楚的了解軟件產(chǎn)品的業(yè)務(wù)流程。建議在做復(fù)雜的測試用例設(shè)計前，先畫出軟件的業(yè)務(wù)流程。如果設(shè)計文檔中已經(jīng)有業(yè)務(wù)流程設(shè)計，可以從測試角度對現(xiàn)有流程進行補充。如果無法從設(shè)計中得到業(yè)務(wù)流程，測試工程師應(yīng)通過閱讀設(shè)計文檔，與開發(fā)人員交流，最終畫出業(yè)務(wù)流程圖。業(yè)務(wù)流程圖可以幫助理解軟件的處理邏輯和數(shù)據(jù)流向，從而指導(dǎo)測試用例的設(shè)計。

從業(yè)務(wù)流程上，應(yīng)得到以下信息：

A、主流程是什么

B、條件備選流程是什么

C、數(shù)據(jù)流向是什么

D、關(guān)鍵的判斷條件是什么

3、測試用例設(shè)計

完成了測試需求分析和軟件流程分析后，開始著手設(shè)計測試用例。測試用例設(shè)計的類型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等。在用例設(shè)計中，除了功能測試用例外，應(yīng)盡量考慮邊界、異常、性能的情況，以便發(fā)現(xiàn)更多的隱藏問題。

黑盒測試的測試用例設(shè)計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用例設(shè)計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里主要討論黑盒測試。在設(shè)計測試用例的時候可以使用軟件測試用例設(shè)計方法，結(jié)合前面的需求分析和軟件流程分析進行設(shè)計：

功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。

適合的技術(shù)：由業(yè)務(wù)需求和設(shè)計說明導(dǎo)出的功能測試、等價類劃分

邊界測試：對某個功能的邊界情況進行測試。

適合的技術(shù)：邊界值劃分

異常測試：對某些功能來說，其邊界情況無法簡單的了解或某些操作不完全是正確的但又是

可能發(fā)生的，類似這樣的情況需要書寫相關(guān)的異常測試。

適合的技術(shù)：由業(yè)務(wù)需求和設(shè)計說明導(dǎo)出的特殊業(yè)務(wù)流程、錯誤猜測法、邊界值

分析、內(nèi)部邊界值測試。

性能測試：檢查系統(tǒng)是否滿足在需求中所規(guī)定達(dá)到的性能，性能主要包括了解程序的內(nèi)外部

性能因素。內(nèi)部性能因素包括測試環(huán)境的配置，系統(tǒng)資源使用狀況；外部因素包

括響應(yīng)時間，吞吐量等。

適合的技術(shù)：業(yè)務(wù)需求和設(shè)計說明導(dǎo)出的測試

壓力測試：壓力測試又稱強度測試，主要是檢查系統(tǒng)運行環(huán)境在極限情況下軟件運行的能力，比如說給一個相當(dāng)大的負(fù)荷或網(wǎng)絡(luò)流量給應(yīng)用軟件兼容測試：測試軟件產(chǎn)品在不

同的平臺，不同的工具，相同工具的不同版本下功能的兼容性。

4、測試用例評審

測試用例設(shè)計完成后，為了確認(rèn)測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設(shè)計者、測試leader、項目經(jīng)理、開發(fā)工程師、其它相關(guān)開發(fā)測試工程師。測試用例評審?fù)戤叄瑴y試工程師根據(jù)評審結(jié)果，對測試用例進行修改，并記錄修改日志。

5、測試用例更新完善

測試用例編寫完成之后需要不斷完善，軟件產(chǎn)品新增功能或更新需求后，測試用例必須配套修改更新；在測試過程中發(fā)現(xiàn)設(shè)計測試用例時考慮不周，需要對測試用例進行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應(yīng)隨之編制升級更新版本。測試用例是“活”的，在軟件的生命周期中不斷更新與完善。

第三篇：軟件測試中報表測試用例設(shè)計方法總結(jié)

軟件測試中報表測試用例設(shè)計方法總結(jié)

報表的測試主要分為以下幾個方面:界面,安全性,準(zhǔn)確性,展示速度(性能)

數(shù)據(jù)統(tǒng)計方面

1、報表統(tǒng)計數(shù)據(jù)的正確性；

2、報表統(tǒng)計數(shù)據(jù)的完整性；

3、報表統(tǒng)計數(shù)據(jù)的合法性；比如，統(tǒng)計金額字段需求要求有“$”等；

報表格式

1、表頭字段表示的正確性；

2、表頭字段表示的完整性；

3、表頭字段表示的字體，字號，美觀程度；

4、各統(tǒng)計字段的顯示是否滿足需求；比如：數(shù)據(jù)過長時要求折行還是縮小；

5、頁眉和頁角的表示；

報表的預(yù)覽和印刷

1、預(yù)覽中的顯示完整性；

2、多頁情況下，第2頁的表頭顯示；

3、能否實現(xiàn)需求要求的特定印刷情況；（比如，印刷使用指定的模板）

4、預(yù)覽后印刷；

5、不預(yù)覽，直接印刷

6、需求規(guī)定各類打印機的測試；

數(shù)據(jù)準(zhǔn)確性測試，帶有報表測試的系統(tǒng)分為兩類，一類是業(yè)務(wù)系統(tǒng)中，帶有統(tǒng)計分析功能模塊，該模塊中包含分析報表，這個系統(tǒng)的主體是業(yè)務(wù)系統(tǒng)，報表是為辦理業(yè)務(wù)的而提供幫助的。

比如說，應(yīng)年檢統(tǒng)計報表，某月應(yīng)交罰款車輛統(tǒng)計報表，這樣的報表數(shù)據(jù)準(zhǔn)確與否，可通過增加、刪減、修改相關(guān)業(yè)務(wù)或相關(guān)業(yè)務(wù)的參數(shù)，查看統(tǒng)計報表數(shù)據(jù)變化，檢查數(shù)據(jù)準(zhǔn)確性。

另一類是系統(tǒng)只有統(tǒng)計功能，就是我說的數(shù)據(jù)倉庫展現(xiàn)這類，它與業(yè)務(wù)系統(tǒng)分離，并且經(jīng)過多層處理，比如數(shù)據(jù)倉庫的數(shù)據(jù)，經(jīng)過抽取，清洗，展現(xiàn)前會經(jīng)過數(shù)據(jù)挖掘，數(shù)據(jù)再處理，有些字段在原始數(shù)據(jù)表中根本就沒有。這樣的數(shù)據(jù)準(zhǔn)確性測試比較復(fù)雜，當(dāng)然檢查出數(shù)據(jù)錯誤，修改定位也是很不容易的。

從整個項目節(jié)約成本看，逐層測試效果是最好的。完全修改率也是最高的。

首先建立測試數(shù)據(jù)模型，模擬所有應(yīng)用表，建立簡單易跟蹤的數(shù)據(jù)用例，底層的數(shù)據(jù)表測試，方法很原始，嘿嘿，通過SQL語句和手工計算，對數(shù)據(jù)進行比對。對系統(tǒng)中的報表數(shù)據(jù)準(zhǔn)確性測試方法較為靈活，①系統(tǒng)中報表重疊的進行比對

②對子報表匯總與父報表比對，就是對月報表匯總與年報表比對，日報表匯總與月報表比對，這只是一個方面，可以從維度關(guān)系考慮，地域，行政級別、時間，個人等方面下手，進行匯總比對

③這個方法如果延伸點呢，可以將報表間的業(yè)務(wù)邏輯關(guān)系作為比對依據(jù)。呵呵，這要看測試人員的需求了解深度個人能力了。插幾句不想干的話，做測試工作總讓我保持快樂狀態(tài)，前兩天我的一個同事說，公司里一直沒有人喜歡做測試工作，這個工作太枯燥。嘿嘿，我當(dāng)時就說我做了這么多年的測試工作從來沒有感覺到枯燥。重復(fù)性工作不代表枯燥，編程其實不也是重復(fù)嘛，人每天誰不重復(fù)昨天的事啊，吃飯，吃這個動作重復(fù)一生，有誰覺得麻煩枯燥啦？

④使用SQL和手工計算進行比對。以上是差錯方式，接下來講一下查什么錯？哪些地方容易出錯

●原始表使用錯誤：因為表比較多，又加上沒有統(tǒng)一的數(shù)據(jù)關(guān)系對應(yīng)表，很容易表使用錯誤，當(dāng)然這應(yīng)該是單元測試檢查出來的錯誤。

●數(shù)據(jù)處理邏輯錯誤：這一點容易因為測試人員和開發(fā)人員對需求理解有偏差造成爭執(zhí)，所以在需求評審時，對數(shù)據(jù)處理規(guī)則用表達(dá)式或偽代碼表示清楚。還有就是程序員失誤，邏輯編寫有偏差，邊界值、特殊情況處理不當(dāng)。

●數(shù)據(jù)權(quán)限：不同用戶對數(shù)據(jù)有著不同的查看權(quán)限。這關(guān)系到數(shù)據(jù)的安全性。

●數(shù)據(jù)誤差：數(shù)據(jù)的保留位數(shù)，數(shù)據(jù)是否是處理計算是否是最后一次計算使用了位數(shù)保留和四舍五入。

●由于字典表，數(shù)據(jù)錯誤，而造成的數(shù)據(jù)錯誤，如，根據(jù)性別統(tǒng)計，購買量，表中的男女顛倒，或者沒有考慮性別缺失項，用了ifelse,這樣就是把表中缺失該項內(nèi)容的算成了else條件里?；蛘哌壿嬛袘?yīng)該考慮用戶狀態(tài)，數(shù)據(jù)狀態(tài)類似的字段，容易被忽略，測試應(yīng)該考慮到。

●最后一項，當(dāng)數(shù)據(jù)量相當(dāng)大的時候，統(tǒng)計應(yīng)該考慮，切割速度，也就是數(shù)據(jù)的完整性，由于數(shù)據(jù)切割的滯后，帶來的數(shù)據(jù)不完整，而造成統(tǒng)計結(jié)果不完整。如統(tǒng)計昨天的銷售情況，而昨天的數(shù)據(jù)并沒有完全從業(yè)務(wù)系統(tǒng)數(shù)據(jù)到數(shù)據(jù)池，再者月底數(shù)據(jù)，由于最后一天的數(shù)據(jù)切割不完整而造成的正月統(tǒng)計數(shù)量不準(zhǔn)確。

報表的界面和輸入輸出測試

界面分為輸入界面和輸出界面；統(tǒng)一的界面要求：美觀、統(tǒng)一、易操作。

輸入界面要求是：

①輸入項字段長度不允許超過字段長度；

②輸入不符合字段要求的，不允許查詢。如money類型，在輸入漢字，字母、特殊字符等不允許查詢，并有友好的操作提示。

③用戶權(quán)限范圍外的輸入，不允許查詢。如用戶輸入不是其權(quán)限范圍內(nèi)的客戶號，不允許查詢，并有友好的操作提示。

對于選項，應(yīng)不出現(xiàn)可選擇的用戶權(quán)限以外的選項。

對于漢字模糊查詢，考慮不常見字，如“?”即漢字因譯碼問題，造成的漢字存儲出現(xiàn)亂碼問題。

輸出界面要求：

①因為是報表所以應(yīng)該有打印、打印預(yù)覽、報表導(dǎo)出等功能。不能因為報表導(dǎo)出丟失數(shù)據(jù)，不能因為打印缺少了報表表格框

②報表排列方式可調(diào)，用戶可按任意列升序或降序排列，或者，按某一關(guān)鍵列的一定規(guī)則排序

③報表標(biāo)題明確，不能含糊誤導(dǎo)用戶

④報表內(nèi)可關(guān)聯(lián)查詢的項，應(yīng)能特殊顯示，如鼠標(biāo)有箭頭變?yōu)槭终?，子報表格式與父報表格式統(tǒng)一，數(shù)據(jù)統(tǒng)一。

報表測試根據(jù)項目的定義有大有小,有時只是作為軟件的一個部分進行測試,有時整個項目都是測試各種報表.但不論如何,報表的作用始終都是將系統(tǒng)中已經(jīng)存在的數(shù)據(jù)根據(jù)用戶的設(shè)置計算加工/整理匯總/最終以清晰的格式展示給用戶,以便用戶進一步做數(shù)據(jù)分析或統(tǒng)計.軟件中的報表實現(xiàn)一般分為定義報表的所需數(shù)據(jù)(一般可以通過選擇或手工輸入條件來縮小數(shù)據(jù)范圍)和定義報表格式兩個部分.報表格式除了如國家各行業(yè)標(biāo)準(zhǔn)中規(guī)定的報表使用固定格式外,大多是根據(jù)企業(yè)或用戶的需要定制報表.所以,做報表測試時要注意以下方面:

1.數(shù)據(jù)的正確

用戶使用報表就是期望通過一個簡單方便的平臺能快速的查找到他所需要的數(shù)據(jù).所以在測試報表時首先就要檢查報表中的數(shù)據(jù)是不是用戶需要的數(shù)據(jù),如果沒有加工的數(shù)據(jù),是否保持了原貌;加工過的數(shù)據(jù)查看加工的結(jié)構(gòu)是否和手工加工的結(jié)果一致.簡言之,需要測試以下內(nèi)容.數(shù)據(jù)的來源：來源于哪張表,哪個字段,數(shù)據(jù)庫中的數(shù)值與界面數(shù)據(jù)的對應(yīng).如數(shù)據(jù)庫中性別的數(shù)據(jù)可能是0或1,但界面顯示為男或女,這個對應(yīng)關(guān)系是否正確.數(shù)據(jù)的范圍：是否只顯示了報表設(shè)置的對應(yīng)范圍；特別要注意邊界數(shù)據(jù),要清楚報表的需求,是否需要過濾掉被選擇的數(shù)據(jù).如時間選擇為200627~200727,那么是否應(yīng)該包含9-27這天.數(shù)據(jù)的對應(yīng)關(guān)系：數(shù)據(jù)庫中的字段是否與報表中的信息對應(yīng)

數(shù)據(jù)的格式：小數(shù)位,千位符,四舍五入等是否與報表設(shè)置一致；單位或稅率轉(zhuǎn)換是否正確；組合顯示的數(shù)據(jù)是否合理

數(shù)據(jù)的排序：排序方式是否與報表設(shè)置一致(如果沒有設(shè)置,是否有一個清晰的默認(rèn)排序方式,如按字母或數(shù)字排序)

流水號：如報表有使用流水號,流水號的生成和格式是否正確.取消操作是否會生成流水號.明細(xì)與合計的一致性：各部分明細(xì)或小節(jié)是否與最后總和一致

其他

測試這一部分內(nèi)容需要對業(yè)務(wù)邏輯相當(dāng)熟悉,對數(shù)據(jù)庫的設(shè)計也要非常了解.必要時可以通過自己寫查詢語句查看數(shù)據(jù).有些報表的條件有多有少,但測試方法都是一樣.根據(jù)條件通過等價類劃分和排列組合設(shè)置各種條件組合.千萬不要盲目的測試,否則會導(dǎo)致該測的沒測,多余的測試做了一堆..一般來說有類別劃分的(一般界面表現(xiàn)為下拉框),每個類別都要測試到,如性別中的男,女都要測試.輸入的可以用等價類來劃分要測試的數(shù)據(jù).2.格式的正確

數(shù)據(jù)驗證正確后,就需要看看報表的輸出格式是否符合要求.可以從以下幾方面來檢查.報表的整體風(fēng)格：報表是否符合規(guī)定的或用戶設(shè)置的格式

報表標(biāo)題：報表的標(biāo)題是否是正確的報表名稱；如報表中有嵌入的數(shù)據(jù)(會跟隨用戶的選擇而變化的).需要檢查數(shù)據(jù)是否正確,如XX企業(yè)9月份財務(wù)報表,這個9月就是用戶選擇的;或者XX公司200627~200727的網(wǎng)站訪問量,這個時間段也是用戶選擇的.公司的一些標(biāo)志：如logo,名稱,地址之類的是否正確

報表的頁首與頁尾：是否采用了一致的規(guī)則.分頁：當(dāng)輸出的內(nèi)容多時,分頁是否正確.翻頁功能是否正確

友好性：數(shù)據(jù)或圖表是否清晰,一目了然,數(shù)據(jù)的展示符合用戶的習(xí)慣；需要特別提醒的數(shù)據(jù)(如合計,異常數(shù)據(jù))是否突出顯示；復(fù)雜算法處,用戶不明白或容易混淆處是否有注釋；一些默認(rèn)的格式是否讓人感覺舒服,如對齊,邊界,間隔等

3.權(quán)限的控制

對于有權(quán)限控制的系統(tǒng)，報表當(dāng)然也應(yīng)該和用戶所具有的權(quán)限相一致。需要從兩方面校驗權(quán)限的控制。

報表的條件定義:在條件選擇區(qū)域，有些下拉框中應(yīng)該不能顯示用戶權(quán)限范圍外的數(shù)據(jù)。如普通文員在使用報表時，報表名稱下拉框中是不可以顯示管理者才能查看的報表的。有些以輸入的文本框有級別的劃分時，都應(yīng)該要測試輸入超越權(quán)限的數(shù)據(jù)的相應(yīng)。

注意這里一定要測試每個條目。

報表內(nèi)容：報表中的內(nèi)容不能顯示用戶本沒有權(quán)限查看的數(shù)據(jù)。

4.報表的輸出

報表在電腦上生成后，并不是報表的結(jié)束。報表一般都需要打印出來他用，如開會或者提交審批之類。所以報表的打印功能也是非常重要的。測試主要分成三部分：

●打印設(shè)置

●打印預(yù)覽

●實際打印效果

除了打印之外，用戶有可能需要導(dǎo)出報表做進一步的分析或用于和其他報表的比較。所以也應(yīng)該提供導(dǎo)出報表的功能。一般可以導(dǎo)出為CSV,Excel,pdf,html,xml格式。

第四篇：軟件測試用例的設(shè)計心得

1、了解軟件的原始需求（測試目的）

在編寫一個軟件或者模塊的測試用例時候，一定要明白這個功能的原始需求，也就是軟件的使用者（客戶）的需求。理解原始需求后，編寫的測試用例才更有目的性。

2、熟悉軟件的功能需求（測試點）

這個功能需求是指軟件的細(xì)化需求點，這個一般在需求文檔里面都會體現(xiàn)。這里要做的是把 “粗略”的需求，細(xì)化成一個個小需求點。熟悉功能需求后，要知道軟件是怎么使用的，這也才能覆蓋到各種操作。

總之，測試用例一定要全部覆蓋所有的需求點，這是最基本的一點。

3、熟悉軟件的實現(xiàn)原理（測試點）

在理解原始需求和軟件的功能需求后，根據(jù)需求編寫的測試用例，基本上都能覆蓋得比較全面了。

在此基礎(chǔ)上，熟悉軟件的實現(xiàn)原理，理解軟件的內(nèi)部處理。

（1）熟悉原理的過程是進一步深入熟悉軟件的過程。如果單單是從需求點上面覆蓋案例，測試用例只能覆蓋“表面”的一層。一些內(nèi)部的處理流程也許沒有覆蓋到，而這些沒有覆蓋到的代碼很可能就是一個風(fēng)險點。

（2）熟悉模塊原理后，還有一點就是易于分析軟件模塊的關(guān)聯(lián)性。一個大型的軟件，都是一些小模塊的組合而成。軟件越是大型，耦合就越大，“互相影響”就會越多，若設(shè)計用例單單從模塊本身考慮的話，很可能就會對其他模塊造成風(fēng)險。

4、用戶場景和網(wǎng)上問題（測試點）

從用戶的使用場景考慮，這在一些網(wǎng)絡(luò)設(shè)備比較重要，比如軟件后期在一些真實的使用環(huán)境中使用。

還要就是從一些網(wǎng)上問題總結(jié)出來的，那些地方容易出錯，在設(shè)計案例的時候需要考慮進去。

5、測試用例的框架

一個測試用例的框架體現(xiàn)了一個測試人員在設(shè)計測試用例的整體思路。框架也是從大到小劃分下來，可以是：

UI界面，功能，容錯，兼容，性能等幾大類，每個大類在根據(jù)軟件的邏輯等進行劃分成小類，最后細(xì)分到測試點。

6、測試步驟（測試技巧方法）

前面4點都是從測試點的角度考慮，測試用例在完成測試點外，接下來就是測試步驟和測試結(jié)果啦。

測試用例可以寫的很詳細(xì)，也可以寫的比較簡單。這要看公司的要求，有些公司要求測試步驟很細(xì)很細(xì)，包括測試結(jié)果和測試步驟一一對應(yīng)。

要求測試步驟寫的很詳細(xì)的公司，一般是怕執(zhí)行人員的執(zhí)行力不到位，導(dǎo)致沒有理解案例的目的，導(dǎo)致漏測。一般出現(xiàn)在新員工對軟件系統(tǒng)的不熟悉。如果測試步驟寫的很詳細(xì)的話，會很耗時間，而且過于詳細(xì)的會限制執(zhí)行人員的思維。個人認(rèn)為測試用例的重點在于測試點上。

7、測試用例的一些思路

在設(shè)計測試用例中，通常較多使用的是邊界值，等價類，通過和不通過測試。下面從單個模塊或者單個功能點考慮：（結(jié)合一些網(wǎng)上文章的觀點）

（1）UI界面：易用性，提示信息，整體布局，按鈕圖標(biāo)，色彩，中英文標(biāo)點錯別字。

（2）數(shù)據(jù)的多樣性：有效數(shù)據(jù)，合法的無效數(shù)據(jù)（邊界值），非法的異常數(shù)據(jù)，產(chǎn)生錯誤輸出的合法數(shù)據(jù)組合等各種數(shù)據(jù)的組合。

（3）操作多樣性：添加刪除編輯查詢，多用戶的操作。

（4）容量測試

（5）用戶權(quán)限：使用權(quán)限，各種操作的權(quán)限。

（6）升級安裝卸載：平滑升級

（7）日志相關(guān)（包括調(diào)試日志）

（8）軟件功能的邏輯劃分：功能上劃分未能覆蓋的代碼邏輯，可以添加白盒灰盒用例。

（9）可靠性，容錯性

（10）兼容性：瀏覽器，系統(tǒng)，支撐軟件。

（11）安全性

（12）性能（這里的性能是指，單個模塊或者子系統(tǒng)的性能）

總之測試用例首先要能覆蓋所有功能需求點，然后搞懂軟件處理邏輯，可以找開發(fā)一起看測試用例，把沒有覆蓋到的代碼流程相應(yīng)的用例補充，至此，用例基本不會出現(xiàn)基本功能的問題。

在此基礎(chǔ)上，可以進行一些可靠性，容錯性，兼容性等用例的設(shè)計，測試下軟件的穩(wěn)定性。

第五篇：業(yè)務(wù)流程類測試用例的設(shè)計

業(yè)務(wù)流程類測試用例的設(shè)計

最近做的這個系統(tǒng)是強調(diào)業(yè)務(wù)流程的，感覺和以前的純功能的系統(tǒng)還是有區(qū)別，首先要做的是對業(yè)務(wù)需求的理解，在流程一致的前提下，再確定功能模塊的正確與否。在網(wǎng)上也參考了一些前輩的經(jīng)驗，感覺很有道理的。

業(yè)務(wù)流程測試用例編寫原則以需求分析中的流程圖做為編寫測試用例的模型，堅持“試驅(qū)動開發(fā)，用例指導(dǎo)結(jié)果，數(shù)據(jù)記錄變化”的原則，靈活使用不同的方法制定測試用例。業(yè)務(wù)用例的構(gòu)造要先于程序?qū)崿F(xiàn)，與需求和開發(fā)人員溝通一致，并以此作為一個基準(zhǔn)，保證程序?qū)崿F(xiàn)不會錯，還能對整個軟件的進度和質(zhì)量有一個很好的估計和度量。業(yè)務(wù)用例可以不關(guān)注程序的界面，但一定要有數(shù)據(jù)的支持。

測試用例編寫時要分開寫，在編碼前就應(yīng)該確定業(yè)務(wù)流程用例，編碼時進行系統(tǒng)功能測試用例的設(shè)計編寫。系統(tǒng)測試業(yè)務(wù)流程用例的目的在于驗證軟件最終數(shù)據(jù)的準(zhǔn)確性.我們的軟件體現(xiàn)為,手工數(shù)據(jù)與報表數(shù)據(jù)的一直性.用例與用例之間有著一定的關(guān)系,目的性十分明確。

在業(yè)務(wù)流程的分析上，我們應(yīng)該得到以下信息：

1）系統(tǒng)的主流程是什么

2）條件備選流程是什么

3）數(shù)據(jù)流向是什么

4）關(guān)鍵的判斷條件是什么

作為測試人員，在測試過程中要關(guān)注的是流程的走向是否正確，同時關(guān)注流程節(jié)點數(shù)值和輸出值的變化來設(shè)計用例。

我覺得一個測試人員首先應(yīng)該具有需求分析人員的能力（或者說要承擔(dān)起需求分析的責(zé)任來），只有這樣才會在整個項目中貫穿始終，而且最重要的是有助于測試的進行，測試時會更多的站在用戶的角度去考慮，這樣的系統(tǒng)才會是實際可用的。