報表的測試 主要分爲如下幾個方面:界面,安全性,準確性,展現速度(性能)html
數據統計方面程序員
一、報表統計數據的正確性；算法
二、報表統計數據的完整性；數據庫
三、報表統計數據的合法性；好比，統計金額字段需求要求有「$」等；編程
報表格式安全
一、表頭字段表示的正確性；性能
二、表頭字段表示的完整性；單元測試
三、表頭字段表示的字體，字號，美觀程度；測試
四、各統計字段的顯示是否知足需求；好比：數據過長時要求折行仍是縮小；字體
五、頁眉和頁角的表示；
報表的預覽和印刷
一、預覽中的顯示完整性；
二、多頁狀況下，第2頁的表頭顯示；
三、可否實現需求要求的特定印刷狀況；（好比，印刷使用指定的模板）
四、預覽後印刷；
五、不預覽，直接印刷
六、需求規定各種打印機的測試；
數據準確性測試，帶有報表測試 的系統分爲兩類，一類是業務系統中，帶有統計分析功能模塊，該模塊中包含分析報表，這個系統的主體是業務系統，報表是爲**業務的而提供幫助的。
好比說，應年檢統計報表，某月應交罰款車輛統計報表，這樣的報表數據準確與否，可經過增長、刪減、修改相關業務或相關業務的參數，查看統計報表數據變化，檢查數據準確性。
另外一類是系統只有統計功能，就是我說的數據倉庫展示這類，它與業務系統分離，而且通過多層處理，好比數據倉庫的數據，通過抽取，清洗，展示前會通過數據 挖掘，數據再處理，有些字段在原始數據表中根本就沒有。這樣的數據準確性測試比較複雜，固然檢查出數據錯誤，修改定位也是很不容易的。
從整個項目節約成本看，逐層測試效果是最好的。徹底修改率也是最高的。
首先創建測試數據模型，模擬全部應用表，創建簡單易跟蹤的數據用例，底層的數據表測試，方法很原始，嘿嘿，經過SQL 語句和手工計算，對數據進行比對。對系統中的報表數據準確性測試方法較爲靈活，
① 系統中報表重疊的進行比對
② 對子報表彙總與父報表比對，就是對月報表彙總與年報表比對，日報表彙總與月報表比對，這只是一個方面，能夠從維度關係考慮，地域，行政級別、時間，我的等方面下手，進行彙總比對
③ 這個方法若是延伸點呢，能夠將報表間的業務邏輯關係做爲比對依據。呵呵，這要看測試人員的需求瞭解深度我的能力了。插幾句不想幹的話，作測試工做 總 讓我保持快樂狀態，前兩天個人一個同事說，公司裏一直沒有人喜歡作測試工做，這個工做太枯燥。嘿嘿，我當時就說我作了這麼多年的測試工做歷來沒有感受到枯 燥。重複性工做不表明枯燥，編程其實不也是重複嘛，人天天誰不重複昨天的事啊，吃飯，吃這個動做重複一輩子，有誰以爲麻煩枯燥啦？
④ 使用SQL和手工計算進行比對。以上是差錯方式，接下來說一下查什麼錯？哪些地方容易出錯
● 原始表使用錯誤：由於表比較多，又加上沒有統一的數據關係對應表，很容易表使用錯誤，固然這應該是單元測試 檢查出來的錯誤。
● 數據處理邏輯錯誤：這一點容易由於測試人員和開發人員對需求理解有誤差形成爭執，因此在需求評審時，對數據處理規則用表達式或僞代碼表示清楚。還有就是程序員失誤，邏輯編寫有誤差，邊界值、特殊狀況處理不當。
● 數據權限：不一樣用戶對數據有着不一樣的查看權限。這關係到數據的安全性。
● 數據偏差：數據的保留位數，數據是不是處理計算是不是最後一次計算使用了位數保留和四捨五入。
● 因爲字典表，數據錯誤，而形成的數據錯誤，如，根據性別統計，購買量，表中的男女顛倒，或者沒有考慮性別缺失項，用了if else,這樣就是把表中缺失該項內容的算成了else條件裏。或者邏輯中應該考慮用戶狀態，數據狀態相似的字段，容易被忽略，測試應該考慮到。
● 最後一項，當數據量至關大的時候，統計應該考慮，切割速度，也就是數據的完整性，因爲數據切割的滯後，帶來的數據不完整，而形成統計結果不完整。如統計昨 天的銷售狀況，而昨天的數據並無徹底從業務系統數據到數據池，再者月底數據，因爲最後一天的數據切割不完整而形成的正月統計數量不許確。
報表的界面和輸入輸出測試
界面分爲輸入界面和輸出界面；統一的界面要求：美觀、統1、易操做。
輸入界面要求是：
① 輸入項字段長度不容許超過字段長度；
② 輸入不符合字段要求的，不容許查詢。如money類型，在輸入漢字，字母、特殊字符等不容許查詢，並有友好的操做提示。
③ 用戶 權限範圍外的輸入，不容許查詢。如用戶輸入不是其權限範圍內的客戶號，不容許查詢，並有友好的操做提示。
對於選項，應不出現可選擇的用戶權限之外的選項。
對於漢字模糊查詢，考慮不常見字，如「�」即漢字因譯碼問題，形成的漢字存儲出現亂碼問題。
輸出界面要求：
① 由於是報表因此應該有打印、打印預覽、報表導出等功能。不能由於報表導出丟失數據，不能由於打印缺乏了報表表格框
② 報表排列方式可調，用戶可按任意列升序或降序排列，或者，按某一關鍵列的必定規則排序
③ 報表標題明確，不能含糊誤導用戶
④ 報表內可關聯查詢的項，應能特殊顯示，如鼠標有箭頭變爲手掌，子報表格式與父報表格式統一，數據統一。
報表測試根據項目的定義有大有小,有時只是做爲軟件的一個部分進行測試,有時整個項目都是測試各類報表.但不論如何,報表的做用始終都是將系統中已經存在的數據根據用戶的設置計算加工/整理彙總/最終以清晰的格式展現給用戶,以便用戶進一步作數據分析或統計.
軟件中的報表實現通常分爲定義報表的所需數據(通常能夠經過選擇或手工輸入條件來縮小數據範圍)和定義報表格式兩個部分.報表格式除了如國家各行業標準中規定的報表使用固定格式外,大可能是根據企業或用戶的須要定製報表.
因此,作報表測試時要注意如下方面:
1.數據的正確
用戶使用報表就是指望經過一個簡單方便的平臺能快速的查找到他所須要的數據.因此在測試報表時首先就要檢查報表中的數據是否是用戶須要的數據,若是沒有加工的數據,是否保持了原貌; 加工過的數據查看加工的結構是否和手工加工的結果一致.簡言之,須要測試如下內容.
數據的來源：來源於哪張表,哪一個字段,數據庫中的數值與界面數據的對應.如數據庫中性別的數據多是0或1,但界面顯示爲男或女,這個對應關係是否正確.
數據的範圍：是否只顯示了報表設置的對應範圍；特別要注意邊界數據,要清楚報表的需求,是否須要過濾掉被選擇的數據.如時間選擇爲2006-9-27~2007-9-27,那麼是否應該包含9-27這天.
數據的對應關係：數據庫中的字段是否與報表中的信息對應
數據的格式：小數位,千位符,四捨五入等是否與報表設置一致；單位或稅率轉換是否正確；組合顯示的數據是否合理
數據的排序：排序方式是否與報表設置一致(若是沒有設置,是否有一個清晰的默認排序方式,如按字母或數字排序)
流水號：如報表有使用流水號,流水號的生成和格式是否正確.取消操做是否會生成流水號.
明細與合計的一致性：各部分明細或小節是否與最後總和一致
其餘
測試這一部份內容須要對業務邏輯至關熟悉,對數據庫的設計也要很是瞭解.必要時能夠經過本身寫查詢語句查看數據.
有些報表的條件有多有少,但測試方法都是同樣.根據條件經過等價類劃分和排列組合設置各類條件組合.千萬不要盲目的測試,不然會致使該測的沒 測,多餘的測試作了一堆..通常來講有類別劃分的(通常界面表現爲下拉框),每一個類別都要測試到,如性別中的男,女都要測試.輸入的能夠用等價類來劃分要 測試的數據.
2. 格式的正確
數據驗證正確後,就須要看看報表的輸出格式是否符合要求.能夠從如下幾方面來檢查.
報表的總體風格：報表是否符合規定的或用戶設置的格式
報表標題：報表的標題是不是正確的報表名稱；如報表中有嵌入的數據(會跟隨用戶的選擇而變化的).須要檢查數據是否正確,如XX企業9月份財務 報表,這個9月就是用戶選擇的; 或者XX公司2006-9-27~2007-9-27的網站訪問量,這個時間段也是用戶選擇的.
公司的一些標誌：如logo,名稱,地址之類的是否正確
報表的頁首與頁尾：是否採用了一致的規則.
分頁：當輸出的內容多時,分頁是否正確.翻頁功能是否正確
友好性：數據或圖表是否清晰,一目瞭然,數據的展現符合用戶的習慣；須要特別提醒的數據(如合計,異常數據)是否突出顯示；複雜算法處,用戶不明白或容易混淆處是否有註釋；一些默認的格式是否讓人感受舒服,如對齊,邊界,間隔等
3. 權限的控制
對於有權限控制的系統，報表固然也應該和用戶所具備的權限相一致。須要從兩方面校驗權限的控制。
報表的條件定義:在條件選擇區域，有些下拉框中應該不能顯示用戶權限範圍外的數據。如普通文員在使用報表時，報表名稱下拉框中是不能夠顯示管理者才能查看的報表的。有些以輸入的文本框有級別的劃分時，都應該要測試輸入超越權限的數據的相應。
注意這裏必定要測試每一個條目。
報表內容：報表中的內容不能顯示用戶本沒有權限查看的數據。
4.報表的輸出
報表在電腦上生成後，並非報表的結束。報表通常都須要打印出來他用，如開會或者提交審批之類。因此報表的打印功能也是很是重要的。測試主要分紅三部分：
● 打印設置
● 打印預覽
● 實際打印效果
除了打印以外，用戶有可能須要導出報表作進一步的分析或用於和其餘報表的比較。因此也應該提供導出報表的功能。通常能夠導出爲CSV,Excel,pdf,html,xml格式。