報表測試根據項目的定義有大有小，有時只是作爲軟件的一部分進行測試，有時整個項目都是測試各種報表。但無論如何，報表的作用始終是將系統已存在的數據根據用戶的設置計算加工/整理彙總/最終以清晰的格式展示給用戶，以便用戶進一步做數據分析和數據統計。
軟件中的報表實現一般分爲定義報表所需數據（一般可以通過選擇或手工輸入條件來縮小數據範圍）和定義報表格式2部分。報表格式除了如國家個行業標準中規定的報表使用固定格式，大多是根據企業或用戶需要定製報表。所以：
1、做報表測試要注意以下幾個方面：
1.1 數據的準確性
用戶使用報表就是期望通過一個簡單方便的平臺能快速的查找到他所需要的數據.所以在測試報表時首先就要檢查報表中的數據是不是用戶需要的數據,如果沒有加工的數據,是否保持了原貌; 加工過的數據查看加工的結構是否和手工加工的結果一致.簡言之,需要測試以下內容.
數據的來源：來源於哪張表,哪個字段,數據庫中的數值與界面數據的對應.如數據庫中性別的數據可能是0或1,但界面顯示爲男或女,這個對應關係是否正確.
數據的範圍：是否只顯示了報表設置的對應範圍；特別要注意邊界數據,要清楚報表的需求,是否需要過濾掉被選擇的數據.如時間選擇爲2006-9-27~2007-9-27,那麼是否應該包含9-27這天.
數據的對應關係：數據庫中的字段是否與報表中的信息對應
數據的格式：小數位,千位符,四捨五入等是否與報表設置一致；單位或稅率轉換是否正確；組合顯示的數據是否合理
數據的排序：排序方式是否與報表設置一致(如果沒有設置,是否有一個清晰的默認排序方式,如按字母或數字排序)
流水號：如報表有使用流水號,流水號的生成和格式是否正確.取消操作是否會生成流水號.
明細與合計的一致性：各部分明細或小節是否與最後總和一致
其他：
測試這一部分內容需要對業務邏輯相當熟悉,對數據庫的設計也要非常瞭解.必要時可以通過自己寫查詢語句查看數據.
有些報表的條件有多有少,但測試方法都是一樣.根據條件通過等價類劃分和排列組合設置各種條件組合.千萬不要盲目的測試,否則會導致該測的沒測,多餘的測試做了一堆..一般來說有類別劃分的(一般界面表現爲下拉框),每個類別都要測試到,如性別中的男,女都要測試.輸入的可以用等價類來劃分要測試的數據.
1.2 格式的正確
數據驗證正確後,就需要看看報表的輸出格式是否符合要求.可以從以下幾方面來檢查.
報表的整體風格：報表是否符合規定的或用戶設置的格式
報表標題：報表的標題是否是正確的報表名稱；如報表中有嵌入的數據(會跟隨用戶的選擇而變化的).需要檢查數據是否正確,如XX企業9月份財務報表,這個9月就是用戶選擇的; 或者XX公司2006-9-27~2007-9-27的網站訪問量,這個時間段也是用戶選擇的.
公司的一些標誌：如logo,名稱,地址之類的是否正確
報表的頁首與頁尾：是否採用了一致的規則.
分頁：當輸出的內容多時,分頁是否正確.翻頁功能是否正確
友好性：數據或圖表是否清晰,一目瞭然,數據的展示符合用戶的習慣；需要特別提醒的數據(如合計,異常數據)是否突出顯示；複雜算法處,用戶不明白或容易混淆處是否有註釋；一些默認的格式是否讓人感覺舒服,如對齊,邊界,間隔等
1.3 權限的控制
對於有權限控制的系統，報表當然也應該和用戶所具有的權限相一致。需要從兩方面校驗權限的控制。
報表的條件定義:在條件選擇區域，有些下拉框中應該不能顯示用戶權限範圍外的數據。如普通文員在使用報表時，報表名稱下拉框中是不可以顯示管理者才能查看的報表的。有些以輸入的文本框有級別的劃分時，都應該要測試輸入超越權限的數據的相應。
報表內容：報表中的內容不能顯示用戶本沒有權限查看的數據。
1.4 報表的輸出
報表在電腦上生成後，並不是報表的結束。報表一般都需要打印出來他用，如開會或者提交審批之類。所以報表的打印功能也是非常重要的。測試主要分成三部分：
● 打印設置
● 打印預覽
● 實際打印效果
除了打印之外，用戶有可能需要導出報表做進一步的分析或用於和其他報表的比較。所以也應該提供導出報表的功能。一般可以導出爲CSV,Excel,pdf,html,xml格式。
2、報表的測試主要分爲以下幾個方面：
界面，安全性，準確性，展示速度（性能）。
2.1 數據統計方面
報表統計數據的正確性；
數據準確性測試，帶有報表測試的系統分爲兩類，一類是業務系統中，帶有統計分析功能模塊，該模塊中包含分析報表，這個系統的主體是業務系統，報表是爲辦理業務的而提供幫助的。
比如說，應年檢統計報表，某月應交罰款車輛統計報表，這樣的報表數據準確與否，可通過增加、刪減、修改相關業務或相關業務的參數，查看統計報表數據變化，檢查數據準確性。
另一類是系統只有統計功能，就是我說的數據倉庫展現這類，它與業務系統分離，並且經過多層處理，比如數據倉庫的數據，經過抽取，清洗，展現前會經過數據挖掘，數據再處理，有些字段在原始數據表中根本就沒有。這樣的數據準確性測試比較複雜，當然檢查出數據錯誤，修改定位也是很不容易的。
報表統計數據的完整性；
從整個項目節約成本看，逐層測試效果是最好的。完全修改率也是最高的。
首先建立測試數據模型，模擬所有應用表，建立簡單易跟蹤的數據用例，底層的數據表測試，方法很原始，嘿嘿，通過SQL語句和手工計算，對數據進行比對。對系統中的報表數據準確性測試方法較爲靈活，
①系統中報表重疊的進行比對
②對子報表彙總與父報表比對，就是對月報表彙總與年報表比對，日報表彙總與月報表比對，這只是一個方面，可以從維度關係考慮，地域，行政級別、時間，個人等方面下手，進行彙總比對
③這個方法如果延伸點呢，可以將報表間的業務邏輯關係作爲比對依據。呵呵，這要看測試人員的需求瞭解深度個人能力了。插幾句不想幹的話，做測試工作總讓我保持快樂狀態，前兩天我的一個同事說，公司裏一直沒有人喜歡做測試工作，這個工作太枯燥。嘿嘿，我當時就說我做了這麼多年的測試工作從來沒有感覺到枯燥。重複性工作不代表枯燥，編程其實不也是重複嘛，人每天誰不重複昨天的事啊，喫飯，喫這個動作重複一生，有誰覺得麻煩枯燥啦？
④使用SQL和手工計算進行比對。以上是差錯方式，接下來講一下查什麼錯？哪些地方容易出錯
● 原始表使用錯誤：因爲表比較多，又加上沒有統一的數據關係對應表，很容易表使用錯誤，當然這應該是單元測試檢查出來的錯誤。
● 數據處理邏輯錯誤：這一點容易因爲測試人員和開發人員對需求理解有偏差造成爭執，所以在需求評審時，對數據處理規則用表達式或僞代碼表示清楚。還有就是程序員失誤，邏輯編寫有偏差，邊界值、特殊情況處理不當。
● 數據權限：不同用戶對數據有着不同的查看權限。這關係到數據的安全性。
● 數據誤差：數據的保留位數，數據是否是處理計算是否是最後一次計算使用了位數保留和四捨五入。
● 由於字典表，數據錯誤，而造成的數據錯誤，如，根據性別統計，購買量，表中的男女顛倒，或者沒有考慮性別缺失項，用了if else,這樣就是把表中缺失該項內容的算成了else條件裏。或者邏輯中應該考慮用戶狀態，數據狀態類似的字段，容易被忽略，測試應該考慮到。
● 最後一項，當數據量相當大的時候，統計應該考慮，切割速度，也就是數據的完整性，由於數據切割的滯後，帶來的數據不完整，而造成統計結果不完整。如統計昨天的銷售情況，而昨天的數據並沒有完全從業務系統數據到數據池，再者月底數據，由於最後一天的數據切割不完整而造成的正月統計數量不準確。
報表統計數據的合法性；比如，統計金額字段需求要求有“$”等；
2.2報表格式
表頭字段表示的正確性；
表頭字段表示的完整性；
表頭字段表示的字體，字號，美觀程度；
各統計字段的顯示是否滿足需求；比如：數據過長時要求折行還是縮小；
頁眉和頁角的表示；
2.3 報表的預覽和印刷
預覽中的顯示完整性；
多頁情況下，第2頁的表頭顯示；
能否實現需求要求的特定印刷情況；（比如，印刷使用指定的模板）
預覽後印刷；
不預覽，直接印刷
需求規定各類打印機的測試；
報表的界面和輸入輸出測試
界面分爲輸入界面和輸出界面；統一的界面要求：美觀、統一、易操作。
輸入界面要求是：
①輸入項字段長度不允許超過字段長度；
②輸入不符合字段要求的，不允許查詢。如money類型，在輸入漢字，字母、特殊字符等不允許查詢，並有友好的操作提示。
③用戶 權限範圍外的輸入，不允許查詢。如用戶輸入不是其權限範圍內的客戶號，不允許查詢，並有友好的操作提示。
對於選項，應不出現可選擇的用戶權限以外的選項。
對於漢字模糊查詢，考慮不常見字，如“?”即漢字因譯碼問題，造成的漢字存儲出現亂碼問題。
輸出界面要求：
①因爲是報表所以應該有打印、打印預覽、報表導出等功能。不能因爲報表導出丟失數據，不能因爲打印缺少了報表表格框
②報表排列方式可調，用戶可按任意列升序或降序排列，或者，按某一關鍵列的一定規則排序
③報表標題明確，不能含糊誤導用戶
④報表內可關聯查詢的項，應能特殊顯示，如鼠標有箭頭變爲手掌，子報表格式與父報表格式統一，數據統一。
3、測試數據的準備
在報表測試用例設計中，測試數據是關鍵。正如Jackie在《進銷存系統中的報表測試》中所言，如果希望更有效、更高質量地完成報表測試，就要重視並增加對於數據準備的關注。其實，測試數據也是爲測試場景服務的，一個或者一組的測試數據往往是爲了驗證在某個測試場景下報表是否能正確的展現統計值。歸根結底，測試場景的設計纔是關鍵的關鍵。在之前的報表分析後，測試用例的基本框架已經完成。接下來我們需要在這個框架上，細化和補充場景設計，然後通過場景，設計出對應的測試數據。
對於測試數據的設計，我將其粗略地分爲3大類：
3.1有效數據
有效數據，顧名思義，是指既符合前臺業務規則，又符合統計規則的數據。它們會被統計進報表中，對報表的統計值會產生正面的影響。
3.2無效數據
無效數據，屬於統計規則以外的數據。此類數據，符合前臺業務規則，但不符合報表統計規則，即對報表的統計值不會產生任何影響。
3.3異常數據
異常數據，主要目的是用於檢驗報表系統對數據的容錯能力。此類數據不符合前臺業務規則，對報表的統計值會產生負面影響。最常見的場景是，統計值的分母爲零。
這類數據的設計，更多地應用於報表系統與業務系統分離的情況中。當報表系統與業務系統互相統一時，異常數據會受到前臺業務規則的限制，即異常數據連出現的可能也沒有；在報表系統和業務系統分離的情況下，異常數據就很有可能由於數據傳輸的不同步，造成短時間的出現，此時報表系統對於錯誤的處理機制就顯得非常重要了。
除了針對以上3類數據的設計以外，我們在設計報表測試數據時，還需要注意以下幾點：
3.4 保證場景間測試數據的獨立性
這是爲了保證數據可控而要注意的。如果同一條或者同一組測試數據被使用到多個報表統計值的檢查中時，一旦出現測試結果與預期結果不一致，就會提高查錯的難度。況且保證數據的獨立，可以更好地闡述defect，保留defect現場，等待開發人員來解決。
3.5 數據的多樣性
多樣性是指爲場景而準備的多組測試數據。因爲憑藉不同數據才能更接近真實，更容易發現問題。此前我就碰到過類似的情況：在測試一份報表中，我發現同一個統計值，一月份的是正確的，三月份的卻是錯誤的。正常情況下，使用同樣的程序計算只有兩種結果，要不兩者都對，要不兩者都錯。怎麼會出現一對一錯呢？後來開發人員經過檢查，發現還是計算程序中存在的問題。而出現一對一錯是因爲一月份與三月份的數據使用了不同組的測試數據，而正好一月份的數據，在錯誤的計算程序中也能計算出正確的值。由此說明，報表的測試是需要多組測試數據支持的，否則defect就會從我們眼皮底下溜走了。
3.6 不要忘了空報表
所謂的空報表，就是指在報表查詢條件下，沒有相符的源數據，從而造成報表中的統計值爲空。這樣的測試，是爲了確保報表的正確性，檢查報表統計是否有張冠李戴的現象。
3.7 注意數值的設計
這裏所說的數值，是指統計值。例如，統計值是百分比時，我們需要覆蓋最大值（100.00%）、最小值（0.00%）、中間值（如38.01%）、小數位檢查（99.99%）。除了這些，我們還需要考慮負數、百分比超過100%、小數位的四捨五入等情況。
3.8 不同報表間的對照
同一組數據在不同報表中的表現應該是一致的。例如，在銷售總額報表中，營業點A的一月份總計是1萬元；然而在營業點A的銷售清單卻只能查看到9000元的銷售數據。那麼，這意味着肯定是其中一份報表出現問題了。
3.9 注意歷史數據的設計
在基於OLAP技術設計的報表系統中，歷史維度也屬於測試的一個重點。歷史維度的測試，涉及到歷史數據的設計。例如，銷售員A在2011年1月份，服務於營業點A，那麼他的銷售業績就應該計算到營業點A中；然而到了2月份銷售員A調到了營業點B，那麼他2月份以後的銷售業績就應該計算到營業點B 中。報表是否能正確地將銷售員A在不同時間的銷售業績計算到對應的營業點中，就需要我們設計一批針對銷售員A的銷售源數據來檢查。
3.10 測試數據的備份
與一般的系統測試相同，報表的測試也需要經歷多個版本。此外，報表測試數據的量很大，起碼是業務測試數據的3倍以上。因此，數據的備份就非常必要了。我使用過數據庫備份文件、SQL語句、CSV或excel格式3種方式來備份數據。通過比較，我推薦大家採用CSV或者excel格式來保存數據。因爲在不同版本的測試中，我們很難避免數據庫結構或者數據表字段的變化。如果採用數據庫備份文件，一旦數據庫發生了一點變化，就導致這個備份無法使用；SQL語句可以避免這樣的問題，但保存在SQL語句中的測試數據不直觀，且不方便修改。因此，CSV或excel格式使用起來更簡單，而且很多數據庫 都提供批量導入CSV或者excel文件的功能。
總結：驗證報表，主要是驗證SQL。所以很多時候報表數據不對，基本是開發SQL邏輯寫得有問題導致。