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

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

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

數據統計方面

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格式。

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

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

一、等價類劃分

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.軟件測試計劃

1.1 軟件測試計劃的簡介

1測試計劃概念：測試計劃在測試中處于中心位置，它闡述了測試準備工作和執行測試的必要條件，同時也形成了測試過程質量保證的基礎。

2測試計劃的作用：組織和管理測試；使測試工作和整個開發工作整合起來；資源和變更事先最為一個可控制的風險。

1.2 如何編寫軟件測試計劃

1認識測試項目不僅僅只有單一測試計劃

2避免不分析直接進行測試階段日程安排

3避免測試任務的安排超前于開發任務

4避免有些系統測試類型無法按期進入測試

5不正確的變更測試計劃

6測試計劃里明確更新周期和暫停測試原則

7測試計劃不是一成不變的1.3 測試計劃包括：簡介，目的，范圍，測試策略，進度，缺陷的嚴重程度的定義，風

險分析。

2.軟件測試方案

2.1 軟件測試方案的概念

軟件測試方案描述測試的特征，測試的方法，測試環境的規劃，測試工具的設計和選擇，測試用例的設計方法，測試代碼的設計方案。即包括以下幾點：

? 明確測試策略（黑盒，白盒，灰盒等）

? 細化測試特征

? 測試用例的規劃

? 測試環境的規劃

? 自動化測試框架的設計

? 測試工具的設計和選擇

2.2 軟件測試計劃于軟件測試方案的區別

? 測試計劃是組織管理層面的文檔。測試方案是技術層面的文檔。

? 測試方案需要在測試計劃的指導下進行，測試計劃提出“做什么”，測試方案明確“怎么做”

? 回報的對象不同，測試計劃向領導匯報，測試方案是組員共享該文檔

3.軟件測試的風險

? 軟件需求風險

? 人員的風險

? 測試環境的風險

? 測試工程師對產品的業務不熟悉

補充：

回歸測試：把以前檢查過的已經修復好的缺陷，拿來另測看有無帶來新的缺陷 反側：把開發人員已經處理的缺陷拿來測，看是否修復

第四篇：報表測試方法總結

報表測試方法總結

1.提高對業務的熟悉程度

和功能測試以及其他測試一樣，報表測試也需要熟悉業務，包括業務流程、業務規則以及數據存儲，不同點是報表測試要理解每個指標的算法、數據來源以及要明白具體的業務動作和指標之間的關系，例如：要統計保費收入，首先要考慮正常保單，其次要考慮批增、批減以及注銷、全單退以及其他特殊批改，這些業務類型都可以對此指標的統計結果產生影響。所以如果不能分析業務動作和指標之間的關系，那就無法驗證報表中數據的準確性。

2.數據準備

數據對報表測試來說是非常重要的問題，因為報表的基本功能就是通過各種查詢統計分析的方法為用戶提供準確的數據，幫助用戶進行決策以及分析，所以在報表測試前要保證準備足夠多準確、有效的數據。在實際測試的時候一定要覆蓋到報表所要求的每個維度,要保證所有的指標都要有對應的數據，不能出現指標為零的情況，當然也不需要過多，只要覆蓋了所有的類型就可以了。一下總結了兩種數據準備的方法：

1> 對測試后期比如凍結測試時產生的數據進行備份，用于報表測試，前提一定要保證數據的原始性，不允許對任何人對數據進行修改；

2> 自己手工對數據進行準備并且精心設計，要分析影響所測指標的各種因素，以及每個因素可能出現的不同變化，這樣才有可能覆蓋各種查詢統計方法，并且要考慮需要考慮的是對各種正常的、異常的業務流程和業務規則的組合的遍歷或覆蓋,從而來驗證報表是否取到的該取的數據、沒有取不該取的數據，并且最后計算出了正確的結果。最后要將自己準備的數據用excel保存，并對數據的特點進行記錄，以提高測試時的效率，并可以減少回歸測試工作量；

3.數據正確性驗證

對于客戶來說，使用報表就是期望通過報表系統這個平臺能夠快速簡單的查到自己所需要的數據，所以測試報表最主要的內容就是要驗證數據的正確性，總結方法如下：1 > 要弄清楚數據的來源，來源于哪張表、哪個字段；> 時間條件：統計區間具體應該以業務中的什么時間在卡，并且考慮需求中是否包括統計區間的邊界值；

3> 要弄清楚所測表以及所測指標的特定條件，比如要統計2009-01-01——2009-01-31 這個月份所有代理業務，那特定條件就是將保單的業務來源要限制在代理業務中； 4> Sql準備，這個過程是將上面三個過程進行總結，也是后續和開發人員進行分析數據的基礎，所以提高自己編寫sql的能力。另外當測試時間不充裕的情況下，對一

5>

6>

7>

8> 些簡單的報表，如清單之類的報表就可以不用自己遍寫sql語句，直接選出各種業務類型的單子進行單獨分析； 數據核對以及分析，用sql查詢出的數據要和開發人員的進行核對，由于有些數據量很大，所以最好借助對比工具（推薦：BCompare此軟件），對于核對不上的數據要單獨進行分析，分析的過程往往是發現問題主要環節，在這個過程中，如果自己實在分析不出來，則可以讓開發人員協助； 數據的顯示格式：小數位、千分符，百分號等是否與報表設置的一致，單位、匯率等是否進行轉化，將有些代碼是否轉換成文字，比如被保險人性別，是否將系統中的0、1轉化成男或女； 明細與合計的一致性:各部分明細值的和是否和總和一致等； 要覆蓋所有的查詢統計方式，在時間充分的條件下，要根據條件（篩選項、維度）

通過等價類劃分和排列組合設置各種條件組合，每種都要測試到，千萬不能按照自己的習慣為準；

4.報表格式的顯示

在數據驗證之后，要關注的就是輸出報表的顯示格式是否符合客戶需求。報表的格式主要有兩大類：

一、保險行業標準中規定的報表使用固定格式，如：保監會上報的一些報表，二：按照企業或者用戶的需求定制的報表，所以對這兩大類報表則需要從以下幾個方面去測試：

1> 報表的整體顯示格式是否符合客戶提供的表樣

2> 報表的標題或者表名是否正確

3> 報表頁面的時間段是否是用戶選擇的時間段

4> 當輸出的內容過多時，分頁方式是否正確，翻頁時，是否有與上頁相同的樣式（如

表頭），第2頁的輸出是否正確

5> 需要特別提醒的數據（一些異常數據）是否突出顯示，有些指標計算方法特別復雜

或者有幾個指標容易混淆時是否在頁面有加注釋

5.報表之間的可比性

在縱向的測試完成后，我們要將所測試的報表進行橫向聯系，因為有些報表雖然名稱不一樣，但是有些指標是一樣的，這樣我們就需要將這兩張報表哪起來進行比較，看在相同的時間段內是否統計出的結果都是一樣的。另外不同報表的不同指標之間也是有聯系的，如：業務中的應收保費清單和財務中的應收保費科目余額，當兩者統計口徑一致的時候，清單中的應收保費的合計則等于財務應收科目的余額，還有保費收入、實收保費、應收保費在同一統計區間總保費收入 = 實收保費 + 應收保費（未實收到的），所以在測試過程中，一定要理清它們之間的層次、順序，這就需要加強對業務的理解和知識的積累！

6.其他

1> 報表的輸出以及打印

報表在系統中生成后,并沒有結束.報表一般都需要打印出來供客戶使用用,例如開會或者提交審批之類.所以報表的打印功能也是非常重要的.在打印之前,用戶一般都需要導出報表做進一步的分析或用于和其他報表的比較.所以也要驗證報表的導出功能.一般可以導出的主要格式是Excel,pdf格式,然后要驗證導出的內容是否正確,與生成的報表相一致.2> 報表的性能

盡量要求開發人員采用最優的查詢語句，避免客戶在使用過程中等待時間過長 3> 報表的權限

對于有權限控制的系統,報表當然也應該和用戶所具有的權限相一致.需要從兩方面校驗權限的控制.報表的條件定義:在條件選擇區域,有些下拉框中應該不能顯示用戶權限范圍外的數據.備注：目前這部分內容測試比較少，之前客戶沒有提出權限這方面的需求，但是最近在使用過程中，客戶提出過，要求分公司人員只能查出自己分公司的清單，允許總公司查出所有的符合要求的清單，估計在后續還會提出類似這樣的要求，所以這部分后續要需要加強測試。

第五篇：軟件測試方法總結

軟件測試方法總結

（一）發布時間: 2008-12-12 17:07作者: lxm_lxm來源: 51Testing論壇

軟件測試方法的總結，是lxm_lxm根據個人所做過的項目整理的，提供給新來的的朋友們。軟件測試方法總結

一、界面

● 界面測試

（1）測試界面設計是否合理、簡潔、美觀，操作是否方便

（2）功能鍵、數據項信息是否齊全

（3）確認系統中同一功能抌名稱是否統一

（4）設計樣式、風格（查詢條件樣式；輸入風格（點選/手輸入）；）是否與系統其它模塊統一

（5）確認頁面內所有字段名稱顯示風格是否統一（居中、左對齊、右對齊，一般采用居中顯示風格）

1、新增頁面及功能測試

● 字段

在開始測試時應該保證數據的正確性，然后再從系統中找出各種Bug

（1）各字段輸入正確的信息值保存，確認系統是否可以正確完成新增操作。

（2）進入添加界面不輸入任何信息值，單擊“保存”功能按鈕，系統應該給出某個不允許為空字段的提示信息（屬于邊界測試）

（3）建議不允許為空的字段前面加上?*?作為標記（統一性，方便性問題）

（4）編碼/編號字段不允許輸入中文及特殊字符，否則系統應該給出相應的提示信息

（5）測試編碼/編號字段不允許重復，否則系統應該給出相應的提示信息

（6）確認字段是否已做長度限制，如果輸入值超出長度范圍，那么在保存時系統應該給出提示信息

（7）非法測試，如：校驗數值型字段輸入非數值，保存時系統是否給出相應的提示信息（根據實際需要確定數值型字段是否能夠接受負數）

（8）邊界測試，如：確認數值型字段的邊界值（如：有效值為?0-100?整數，那么輸入-1或101保存時系統應該給出相應的提示信息；輸入值為0、100系統應該能正確保存信息值；輸入0到100內的整數值系統應該正確保存信息值）

（9）精確值測試，測試小數位數是否在定義的長度內

（10）字段精確值是否正確（四舍五入否）。

（11）根據實際情況測試名稱字段是否具有唯一性，（一般情況下名稱是不允許重復的，具體問題具體分析），否則系統應該給出相應的提示信息

（12）確認各字段名稱書寫是否正確（注意：要求編輯界面、住息列表中、錯誤提示信息、查詢條件中的字段名稱完全相同）

（13）確認特殊格式的字段是否已做標準格式的限制（如：電子郵件、郵編等）

（14）測試上級信息字段（如：上級XXX名稱、上級XXX編號）的信息值是否根據所選擇的上級XXX名稱系統自動生成（注意：編號生成值一定是維護界面的編號，而不應該是相應表的那個主鍵編碼）

（15）測試如果某字段信息值是從另一個模塊中選擇輸入的，那么需要確認其它相關聯字段的信息值是否也相應的正確的自動帶入，并且這些字段應該都是只讀的（16）創建人/編輯人、發布人、創建時間、創建人字段應該設為只讀的，而且此類字段值應該默認當前操作人的姓名

（17）如果某個字段可以點選輸入多個信息值，那么測試該字段是否接受，并保存了點選輸入的多個信息值

（18）對于多選字段，測試是否具有記憶上次選擇值并已驗重

（19）測試字符型字段是否可以接受空格（統一性問題，建議不要接受空格）

（20）引用其它模塊的字段信息值的字段長度是否與被引用模塊相應字段長度一致

軟件測試方法總結

（二）發布時間: 2008-12-12 17:13作者: lxm_lxm來源: 51Testing論壇

關鍵字：軟件測試方法

6、常用功能鍵的功能測試

（1）保存---所有編輯頁面如果未輸入任何信息值而單擊“保存”，系統應該給出“XXX字段不允許為空”的提示信息

（2）保存---如果某字段輸入值有錯誤或超出長度范圍，那么單擊“保存”按鈕時，系統應該給出相應的提示信息

（3）保存---輸入相關信息單擊“保存”后，建議系統給出“保存成功”提示信息

（4）保存---測試新增/修改信息保存后，信息列表是否自動刷新

（5）下一步---單擊此按鈕，如果有非空字段為空，系統應該給出相應提示信息；如果有字段輸入非法值，單擊此按鈕系統應該給出相應提示信息；正常情況下單擊此功能按鈕，系統進入到下一個編輯/操作界面

（6）上一步---單擊此功能按鈕，系統應該正確返回到上一個編輯/操作界面

（7）瀏覽---測試該功能鍵功能是否已經正確實現，單擊此按鈕系統應該彈出文件選擇頁面，并且可以選擇輸入相關附件

（8）上傳附件---測試上傳功能已經正確實現，確認上傳的附件在界面相應位置是否顯示

（9）下載---測試下載功能已經正確實現（可以將上傳到服務器的附件下載的本地相應位置）

（10）重新上傳---保存操作后上傳功能按鈕名稱應該自動變為“重新上傳”，并且可以重新上傳附件

（11）發布---測試該功能鍵功能已經正確實現，單擊些功能按鈕系統完成發布操作，相應的信息狀態變為“已發布”，發布人、發布時間系統自動生成或已經正確保存（注意：已經發布的信息是不允許再進行修改操作的）（根據系統需求及設計測試，有些系統只有信息修改頁面才有此功能）

（12）取消發布---測試該功能鍵功能是否已經正確實現，單擊此功能按鈕系統完成取消發布功能，相應信息狀態變為“未發布”（根據系統需求及設計測試，有些系統只有信息修改頁面才有此功能）

（13）關閉---單擊此功能按鈕系統將關閉當前頁面，建議當單擊此功能按鈕時系統彈出“確認離開此頁面提示信息”

（14）查詢---單擊查詢功能按鈕，系統按鈕輸入查詢條件進行模糊查詢；查詢條件輸入非法值進行查詢操作，系統應該查詢0記錄

（15）刪除----未勾選待刪除記錄單擊此按鈕系統彈出相應提示信息；正常情況下系統刪除所選記錄

（16）選擇---勾選待選記錄，單擊此按鈕系統完成選擇操作；單擊選擇超鏈接功能按鈕系統完成選擇操作

（17）取消選擇---單擊此功能按鈕，系統完成取消選擇操作（清除所有選擇信息）

軟件測試方法總結

（三）發布時間: 2008-12-12 17:14作者: lxm_lxm來源: 51Testing論壇

關鍵字：軟件測試方法

11、對用戶名、密碼的有效性測試

（1）密碼信息有效性測試：特殊字符、正常字符、空字符（不輸入）、空格

（2）登陸名是否區分大小寫

（3）登陸名是否允許重名

（4）用戶名字和密碼都為最大長度（邊界值分析，取上點）

（5）用戶名字和密碼都為最小長度（邊界值分析，取上點）

（6）用戶名字和密碼都是非最大和最小長度的數據（邊界值分析，取內點）

（7）用戶名長度大于要求1位（邊界值分析，取離點）

（8）用戶名長度小于要求1位（邊界值分析，取離點）

（9）密碼長度大于要求1位（邊界值分析，取離點）

（10）密碼長度小于要求1位（邊界值分析，取離點）

（11）是否記住上次登陸名

（12）密碼信息有效性測試：字母數字混排、數字、符號數字、字母符號、數字符號、空字符（不輸入）、空格、ASCII字符、字符串在有空格、串在有半角空格

（13）口令鎖定：即輸入口令次數的限制

（14）密碼顯示是否以星號或者別的符號顯示

（15）看是否支持tap和enter鍵等

（16）密碼是否可以復制粘貼

密碼修改測試方法

（1）不輸入舊密碼，直接改密碼

（2）輸入錯誤舊密碼

（3）不輸入確認新密碼

（4）不輸入新密碼

（5）新密碼和確認新密碼不一致

（6）新密碼中有空格

（7）新密碼長度有效性測試方法同上

（8）新密碼為非允許字符（如有的密碼要求必須是英文和數字組成，那么要試漢字和符號等）

（9）測試密碼是否區分大小寫，新密碼中英文小寫，確認密碼中英文大寫

（10）新密碼與舊密碼一樣能否修改成功

軟件測試方法總結

（四）發布時間: 2008-12-12 17:17作者: lxm_lxm來源: 51Testing論壇

關鍵字：軟件測試方法

四、權限測試

1、業務權限

按需求測試用戶業務權限分配是否正確，業務權限主要控制功能模塊、功能菜單的展示，沒有相應業務權限的不展示其功能模塊能功能菜單。

2、操作權限

（1）權限組：按組用戶來分配操作權限。（組內所有人員都具有所分配的操作權限）

（2）測試已分配操作權限的功能按鈕是可見的（3）測試已分配操作權限的功能按鈕是否可用；是否可以正確完成相應功能操作

（4）通常不分配調看操作權限是無法進行修改操作

五、算法

1、測試前需要充分了解算法的整個計算過程及結果值的精度

2、算法測試之前需要準備充足，而且是準確無誤的測試實例

3、根據輸入值確認系統計算輸出結果是否與預期結果完全一致

4、如果計算公式中含有引用其它模塊的數據，需要先確認數據提取是否對應的正確

5、先用等價劃分法、邊界值測試方法測試輸入數據是否在需求范圍內

6、嚴格按照測試用例執行測試，確認計算結果是否正確無誤，注意結果的精度。