第一篇：軟件測試用例的設計心得

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

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

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

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

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

3、熟悉軟件的實現原理（測試點）

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

在此基礎上，熟悉軟件的實現原理，理解軟件的內部處理。

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

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

4、用戶場景和網上問題（測試點）

從用戶的使用場景考慮，這在一些網絡設備比較重要，比如軟件后期在一些真實的使用環境中使用。

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

5、測試用例的框架

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

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

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

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

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

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

7、測試用例的一些思路

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

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

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

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

（4）容量測試

（5）用戶權限：使用權限，各種操作的權限。

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

（7）日志相關（包括調試日志）

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

（9）可靠性，容錯性

（10）兼容性：瀏覽器，系統，支撐軟件。

（11）安全性

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

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

在此基礎上，可以進行一些可靠性，容錯性，兼容性等用例的設計，測試下軟件的穩定性。

第二篇：常見的軟件測試用例設計方法

常見的軟件測試用例設計方法有以下幾種：

一、等價類劃分

1）確定等價類

有效等價類代表對程序的有效輸入；無效等價類代表的是其他不正確的任何輸入。如果需要，我們還可以將一個等價類劃分為更小的一些等價類。

比如，規格說明規定了“請輸入書籍的數量（1~99）以及書籍的類型（硬皮、軟皮或活頁）”。它們對應的等價類分別如下：

書籍數量

書籍類型

2）生成測試用例

1.為每個等價類設置編號。

2.編寫測試用例，盡可能多的覆蓋尚未被覆蓋的有效等價類。直到所有的有效等價類都被測試用例覆蓋。測試用例及其覆蓋的有效等價類如下：

3.編寫測試用例，覆蓋一個且僅一個尚未被覆蓋的無效等價類。直到所有的無效等價類都被測試用例所覆蓋。測試用例及其覆蓋的無效等價類如下：

用單個的測試用例覆蓋無效等價類，是因為有些輸入的錯誤檢查可能會屏蔽或取代其他輸入的錯誤檢查。比如②⑦，也許程序提示“非法的書籍數量”后，就不會執行對書籍類型的檢查了。

二、邊界值分析

經驗證明，考慮了邊界條件的測試用例比其他沒有考慮邊界條件的測試用例，具有更高的測試回報率。所謂邊界條件，是指輸入和輸出等價類中恰好處在邊界、或超過邊界、或在邊界以下的狀態。

上例中的書籍數量范圍是1~99，那么應該針對0，1和99，100的情況分別設計測試用例。

從定義可以看出，等價劃分只關注輸入空間（輸入等價類）的不同，邊界值分析還需要從輸出空間（輸出等價類）設計測試用例。

舉例來說：

某個程序按月計算個人所得稅的速算扣除數，且最小金額是0，最大金額是13,505。使用邊界值分析法，應該設計測試用例測試速算扣除數結果為0和13505的情況。此外，還應觀察是否可能設計出導致速算扣除數為負數，或者超過13505的測試用例。

邊界值分析法和等價劃分重要的區別是，等價劃分是從等價類中挑選任意一個元素作為測試數據；邊界值分析法考察正處于等價劃分邊界或在邊界附近的狀態。

三、因果圖

邊界值分析和等價劃分的缺點是，未對輸入條件的組合情況、輸入條件之間的相互制約關系進行分析。

1）因果圖的基本關系

?恒等（Identify）:若a為1，則b為1；否則b為0。

?非（NOT）:若a為1，則b為0；否則b為1。

?或（OR）:若a或b或c為1，則d為1；否則d為0。

?與（AND）:若a和b和c都為1，則d為1；否則d為0。

2）因果圖的約束條件

1、對于輸入條件的約束有E、I、O、R四種：

?異（E）:E必須總為真，而a、b最多只有一個為1。

?或（I）:I為真時，a、b和c中至少有一個必須為1。

?唯一（O）:a、b中，有且僅有一個必須為1。

?要求（R）:如果a為1，b也必須為1。

2、對于輸出結果的約束只有M一種：

屏蔽（M）:如果結果a為0，則b強制為0。

一、假設有一規格說明：

“第一列中的字符必須是‘A’或‘B’，第二列中的字符必須是一個數字。在這種情況下，對文件進行更新。如果第一個字符不正確，產生提示信息X12。如果第二個字符不是數字，產生提示信息X13。”

（1）將規格說明分解為可執行的片段，確定“因”和“果”，為每個“因”和“果”都賦予唯一的編號。“因”是條件，是指一個明確的輸入條件等價類。“果”是動作，是指一個輸出或系統轉換（輸入對程序或系統狀態的延續影響）。

（2）分析規格說明的語義，轉換為因果圖。原因①和原因②不可能同時成立，為因果圖添加對應的約束條件，得到右圖。

因果圖和添加了約束條件后的因果圖

（3）將因果圖轉換為判定表，每一列代表一個測試用例。

判定表

（4）將判定表中的列轉換為測試用例。

二、將因果圖轉換為判定表的思路（以上述的例子來說明）

1.選擇一個“果”作為當前狀態。例：71。

2.對因果圖回溯，找出導致該“果”為1的所有因的組合（需要考慮到約束條件）。例：001，000。

3.在判定表中為每個“因”的組合生成一列。例：（列3）和（列4）。

4.對于每種“因”的組合，判斷所有其他“果”的狀態，并放置在對應的每一列中。例：已得在001，000兩種組合下結點71的結果為1。判斷在“因”為001的組合下，得到70和72的結果為0。判斷在“因”為000的組合下，得到70的結果為0，72的結果為1。將“果”的狀態填入其對應的列。

對因果圖進行回溯時，需要做到以下考慮：

1.當回溯經過一個結果為1的OR結點時，不要將OR結點的1個以上的輸入同時設為1。

2.當回溯經過一個結果為0的AND結點時，應列舉出導致該結果為0的所有輸入情況的組合。然而，當該AND結點的一個輸入條件為0時，其他輸入有一個或更多的1，則不必考慮其他輸入為1的所有情況。

3.當回溯經過一個結果為0的AND結點時，所有輸入皆為0的這一種情況應當列舉出來。

找出因果圖中，所有導致輸出狀態為0的輸入條件

(1)根據上述第c)條思路，我們只需列出使得結點⑤和結點⑥皆為0的情況。結點①②③④的取值狀態為：

0，0，0，0（5=0，6=0）

(2)根據第b)條思路，對于結點⑤為1而結點⑥為0的情況，應該列出導致⑥為0的所有輸入情況組合。同時，只需列出一種使得⑤為1的情況即可，不需要列出⑤為1時的所有輸入情況組合。又根據第a)條思路，當結點⑤為1時，我們不應將結點①和②同時設為1。于是，得到結點①②③④的取值狀態：

1，0，0，0（5=1，6=0）

1，0，0，1（5=1，6=0）

1，0，1，0（5=1，6=0）

同樣的，對于⑤為0而⑥為1的情況，也只需要列出⑥為1的一種情況即可（盡管在本例中也只有這一種）。

0，0，1，1（5=0，6=1）

因果圖有助于用一個系統的方法選擇出高效的測試用例集。它還有一個額外的好處，就是可以指出規格說明的不完整性和二義性。但通常它不能生成全部應該被確定的有效測試用例。

注意：因果圖方法沒有充分考慮邊界條件。建議，最好是單獨考慮邊界值分析。這不意味著我們要為此增加相應多的測試用例，而是在由因果圖生成測試用例時，可以將邊界條件分析一并考慮進去。最好的結果是既滿足了兩方面的目標，又不需要增加新的測試用例。

四、錯誤推測

錯誤猜測是一項依賴于直覺的非正規的過程，其基本思想是人們利用直覺和經驗猜測可能犯得錯誤或錯誤易發情況的清單，然后編寫測試用例來暴露這些錯誤。

例如，程序輸入中出現0這個值，就是一種錯誤易發情況。因此可以編寫測試用例檢查特定的輸入值中有0，或特定的輸出值被強制為0的情況。同樣，在出現輸入或輸出數目不定的地方，如，對某個列表進行搜索，結果為“空列表”或“只包含一個”條目的列表，也是錯誤容易發生的情況。

第三篇：測試用例設計步驟

測試用例設計步驟

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

1、測試需求分析

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

2、業務流程分析

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

從業務流程上，應得到以下信息：

A、主流程是什么

B、條件備選流程是什么

C、數據流向是什么

D、關鍵的判斷條件是什么

3、測試用例設計

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

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

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

適合的技術：由業務需求和設計說明導出的功能測試、等價類劃分

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

適合的技術：邊界值劃分

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

可能發生的，類似這樣的情況需要書寫相關的異常測試。

適合的技術：由業務需求和設計說明導出的特殊業務流程、錯誤猜測法、邊界值

分析、內部邊界值測試。

性能測試：檢查系統是否滿足在需求中所規定達到的性能，性能主要包括了解程序的內外部

性能因素。內部性能因素包括測試環境的配置，系統資源使用狀況；外部因素包

括響應時間，吞吐量等。

適合的技術：業務需求和設計說明導出的測試

壓力測試：壓力測試又稱強度測試，主要是檢查系統運行環境在極限情況下軟件運行的能力，比如說給一個相當大的負荷或網絡流量給應用軟件兼容測試：測試軟件產品在不

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

4、測試用例評審

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

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、項目經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，并記錄修改日志。

5、測試用例更新完善

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

第四篇：小議軟件測試用例的設計論文

白盒測試技術中測試用例的設計方法研究

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

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

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

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

1根據程序內部的邏輯結構設計測試用例的技術—邏輯覆蓋

（1）語句覆蓋，選擇足夠多的測試數據以使被測程序中每條語句都至少執行一次。語句覆蓋不考慮對程序的邏輯覆蓋，它主要關心表達式的結果，卻對每個條件取不同值的情況不做測試。因此，語句覆蓋是比較弱的邏輯覆蓋標準。在圖論中和語句覆蓋對應的是點覆蓋。

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

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

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

（5）條件組合覆蓋，要求選擇足夠多的測試數據，使得每個判定表達式中條件的各種可能組合都至少出現一次。條件組合覆蓋是邏輯覆蓋標準中最強的。

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

2測試程序的控制結構，主要包括條件測試，循環測試和基本路徑測試。

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

黑盒測試技術中的測試用例設計方法研究

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

1等價類劃分

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

2邊界值分析

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

3錯誤推測法

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

小結

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

第五篇：軟件測試中報表測試用例設計方法總結

軟件測試中報表測試用例設計方法總結

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

數據統計方面

1、報表統計數據的正確性；

2、報表統計數據的完整性；

3、報表統計數據的合法性；比如，統計金額字段需求要求有“$”等；

報表格式

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

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

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

4、各統計字段的顯示是否滿足需求；比如：數據過長時要求折行還是縮小；

5、頁眉和頁角的表示；

報表的預覽和印刷

1、預覽中的顯示完整性；

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

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

4、預覽后印刷；

5、不預覽，直接印刷

6、需求規定各類打印機的測試；

數據準確性測試，帶有報表測試的系統分為兩類，一類是業務系統中，帶有統計分析功能模塊，該模塊中包含分析報表，這個系統的主體是業務系統，報表是為辦理業務的而提供幫助的。

比如說，應年檢統計報表，某月應交罰款車輛統計報表，這樣的報表數據準確與否，可通過增加、刪減、修改相關業務或相關業務的參數，查看統計報表數據變化，檢查數據準確性。

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

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

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

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

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

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

●原始表使用錯誤：因為表比較多，又加上沒有統一的數據關系對應表，很容易表使用錯誤，當然這應該是單元測試檢查出來的錯誤。

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

●數據權限：不同用戶對數據有著不同的查看權限。這關系到數據的安全性。

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

●由于字典表，數據錯誤，而造成的數據錯誤，如，根據性別統計，購買量，表中的男女顛倒，或者沒有考慮性別缺失項，用了ifelse,這樣就是把表中缺失該項內容的算成了else條件里。或者邏輯中應該考慮用戶狀態，數據狀態類似的字段，容易被忽略，測試應該考慮到。

●最后一項，當數據量相當大的時候，統計應該考慮，切割速度，也就是數據的完整性，由于數據切割的滯后，帶來的數據不完整，而造成統計結果不完整。如統計昨天的銷售情況，而昨天的數據并沒有完全從業務系統數據到數據池，再者月底數據，由于最后一天的數據切割不完整而造成的正月統計數量不準確。

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

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

輸入界面要求是：

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

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

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

對于選項，應不出現可選擇的用戶權限以外的選項。

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

輸出界面要求：

①因為是報表所以應該有打印、打印預覽、報表導出等功能。不能因為報表導出丟失數據，不能因為打印缺少了報表表格框

②報表排列方式可調，用戶可按任意列升序或降序排列，或者，按某一關鍵列的一定規則排序

③報表標題明確，不能含糊誤導用戶

④報表內可關聯查詢的項，應能特殊顯示，如鼠標有箭頭變為手掌，子報表格式與父報表格式統一，數據統一。

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

1.數據的正確

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

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

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

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

其他

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

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

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

報表的頁首與頁尾：是否采用了一致的規則.分頁：當輸出的內容多時,分頁是否正確.翻頁功能是否正確

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

3.權限的控制

對于有權限控制的系統，報表當然也應該和用戶所具有的權限相一致。需要從兩方面校驗權限的控制。

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

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

報表內容：報表中的內容不能顯示用戶本沒有權限查看的數據。

4.報表的輸出

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

●打印設置

●打印預覽

●實際打印效果

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