數據報表類（BI）項目測試應該如何去啃？

　　測試工作是一項十分枯燥的工作，與之相對的測試人員必須有足夠的耐心、絕對的細心等素質才能完美的完成這項工作。

　　從最初的瀑布模式，到如今風靡的敏捷，Devops等；從最初的最后一道關卡到滲透至各個流程，再到一名人員身兼數職（Devops），測試人員的人員素質要求越來越高，各類新興產業的層出不窮，人工智能、大數據、區塊鏈等的興起，只能說沒兩把刷子能吃這口飯的時間是不會長的，因此，驚濤駭浪下，仍需默默前行！

　　BI，（Business Intelligence）這個名詞應該都不會陌生，BI商業智能，它是一套完整的解決方案，用來將企業中現有的數據進行有效的整合，快速准確地提供報表並提出決策依據，幫助企業做出明智的業務經營決策。（百度百科）說白了就是一系列數據資源的整合（具體模式不談），那么面對該類的項目應該如何去測試？測試時需要注意的問題。

　　

 

　　首先分析該類項目的特點：數據！報表！絕對是該類項目的主題。圍繞這兩個主題應該如何去拓展思維，思路呢？整合了一些博客資源，輸出該篇隨筆。

覆蓋功能時需要注意業務的覆蓋：對於報表業務的熟悉，主要是兩個方面：數據項的算法和數據來源，也就是說要明白一個數據項同具體的業務有什么關系，單據的增、刪、改或者狀態的變化，對報表中各個數據項的計算會產生什么不同的影響。如果不知道到這些，那么就無法驗證報表中的數據是否准確，也無法通過報表去檢查業務系統的正確與否。羅列一下需要注意的地方：　

　　

 

1． 源數據的來源

源數據，即保存在報表數據庫中的數據。源數據的來源，大致可分兩大類：

A． 由業務系統生成

報表數據庫中的數據是由前台業務系統插入的。報表系統和業務系統是關聯着的，甚至它們根本就在使用同一個數據庫。如此一來，前台的操作即直接反應在報表的統計值上。在這種情況下，我們測試用例的設計，重點放在影響報表統計值的前台業務場景的設計上。

例如，某點播系統中的點播率報表，其報表統計值有效點播次數的源數據，就是點播業務所關聯的點播數據庫表。在測試用例設計中，我們重點考察不同場景的點播對報表統計值的影響。而場景的設計除了考慮前台業務規則外，更重要的是考慮報表的統計規則。如例子中，有效點播次數的統計規則是，視頻購買后1分鍾內的重復點播不計入有效點播次數中。這樣一來，場景的設計就不能只是點播一次和點播多次這么簡單。

B． 來源於第三方數據庫

有些報表系統與業務系統是分隔的，各自獨立的。這樣的設計，更多地出現在大型系統中。如此設計，既可以確保業務系統和報表系統各自的性能，又可以提高報表系統的擴展能力，即使用一個報表系統對不同業務系統的數據進行整合和分析。當然這個設計也有不足之處，即報表的實時性。

在這種情況下，測試用例設計的重點應該放在報表數據庫源數據的設計上，重點考察第三方數據到報表數據庫傳遞的正確性，源數據的完整性，以及不同業務源數據的相互影響。

 

2． 報表的算法

算法，是指源數據演變成統計值的過程。報表的算法應詳細清晰地記錄在Functional Specification中。根據算法的復雜程度，我將報表划分為三大類：

A． 羅列式

羅列式報表是將源數據根據規則進行羅列，不涉及任何計算，如話費清單、銷售清單等。對於此類報表，測試的重點在於：

 

• 羅列項的完整性，即FS中所規定的源數據的屬性項是否列舉完整；
• 列舉數據的正確性和完整性；
• 數據屬性變動對報表的影響，如，修改客戶地址后，報表是否能正確地顯示客戶的最新地址；

B． 統計式。

統計式報表是指，統計值是由單個源數據簡單的加或平均得來的報表。此類報表，我們可以采用增量的方法來測試。

例如，前面所舉的有效點播次數統計值。應用增量測試方法，就是在執行不同的場景后，檢查報表的統計值是否在原來的基礎上有對應的增減。

使用增量的方法來測試報表，既可以避免復雜的數據設計，又可以提高測試效率。但是增量測試方法的使用范圍比較狹窄，對所測試的統計值要求不能太復雜。

C． 算法式

算法式報表是指，統計值是由一個或多個源數據根據一定的公式得來的報表。此類報表中的統計值，涉及到多表數據，多業務流程，是報表測試的難點。

在設計此類報表的測試用例時，建議理清以下兩點：

•  統計值所關聯的源數據；
•  源數據關聯的業務規則；特別注意，源數據受多個業務規則共同影響的情況。

數據測試

1． 有效數據

有效數據，顧名思義，是指既符合前台業務規則，又符合統計規則的數據。它們會被統計進報表中，對報表的統計值會產生正面的影響。

2． 無效數據

無效數據，屬於統計規則以外的數據。此類數據，符合前台業務規則，但不符合報表統計規則，即對報表的統計值不會產生任何影響。

3． 異常數據

異常數據，主要目的是用於檢驗報表系統對數據的容錯能力。此類數據不符合前台業務規則，對報表的統計值會產生負面影響。最常見的場景是，統計值的分母為零。

這類數據的設計，更多地應用於報表系統與業務系統分離的情況中。當報表系統與業務系統互相統一時，異常數據會受到前台業務規則的限制，即異常數據連出現的可能也沒有；在報表系統和業務系統分離的情況下，異常數據就很有可能由於數據傳輸的不同步，造成短時間的出現，此時報表系統對於錯誤的處理機制就顯得非常重要了。

注意點：

        1． 保證場景間測試數據的獨立性

這是為了保證數據可控而要注意的。如果同一條或者同一組測試數據被使用到多個報表統計值的檢查中時，一旦出現測試結果與預期結果不一致，就會提高查錯的難度。況且保證數據的獨立，可以更好地闡述defect，保留defect現場，等待開發人員來解決。

2． 數據的多樣性

多樣性是指為場景而准備的多組測試數據。因為憑借不同數據才能更接近真實，更容易發現問題。此前我就碰到過類似的情況：在測試一份報表中，我發現同一個統計值，一月份的是正確的，三月份的卻是錯誤的。正常情況下，使用同樣的程序計算只有兩種結果，要不兩者都對，要不兩者都錯。怎么會出現一對一錯呢？后來開發人員經過檢查，發現還是計算程序中存在的問題。而出現一對一錯是因為一月份與三月份的數據使用了不同組的測試數據，而正好一月份的數據，在錯誤的計算程序中也能計算出正確的值。由此說明，報表的測試是需要多組測試數據支持的，否則defect就會從我們眼皮底下溜走了。

3． 不要忘了空報表

所謂的空報表，就是指在報表查詢條件下，沒有相符的源數據，從而造成報表中的統計值為空。這樣的測試，是為了確保報表的正確性，檢查報表統計是否有張冠李戴的現象。

4． 注意數值的設計

這里所說的數值，是指統計值。例如，統計值是百分比時，我們需要覆蓋最大值(100.00%)、最小值(0.00%)、中間值(如38.01%)、小數位檢查(99.99%)。除了這些，我們還需要考慮負數、百分比超過100%、小數位的四舍五入等情況。

5． 不同報表間的對照

同一組數據在不同報表中的表現應該是一致的。例如，在銷售總額報表中，營業點A的一月份總計是1萬元；然而在營業點A的銷售清單卻只能查看到9000元的銷售數據。那么，這意味着肯定是其中一份報表出現問題了。

6． 注意歷史數據的設計

在基於OLAP技術設計的報表系統中，歷史維度也屬於測試的一個重點。歷史維度的測試，涉及到歷史數據的設計。例如，銷售員A在2011年1月份，服務於營業點A，那么他的銷售業績就應該計算到營業點A中；然而到了2月份銷售員A調到了營業點B，那么他2月份以后的銷售業績就應該計算到營業點B中。報表是否能正確地將銷售員A在不同時間的銷售業績計算到對應的營業點中，就需要我們設計一批針對銷售員A的銷售源數據來檢查。

7． 測試數據的備份

與一般的系統測試相同，報表的測試也需要經歷多個版本。此外，報表測試數據的量很大，起碼是業務測試數據的3倍以上。因此，數據的備份就非常必要了。我使用過數據庫備份文件、SQL語句、CSV或excel格式3種方式來備份數據。通過比較，我推薦大家采用CSV或者excel格式來保存數據。因為在不同版本的測試中，我們很難避免數據庫結構或者數據表字段的變化。如果采用數據庫備份文件，一旦數據庫發生了一點變化，就導致這個備份無法使用；SQL語句可以避免這樣的問題，但保存在SQL語句中的測試數據不直觀，且不方便修改。因此，CSV或excel格式使用起來更簡單，而且很多數據庫都提供批量導入CSV或者excel文件的功能。

 

 

3：權限

報表系統的權限控制包含功能點和數據兩方面的權限控制。

             功能點權限控制，是指登錄用戶對某一功能點有無訪問權限的控制；

             數據權限控制，是指登錄用戶對數據的訪問范圍的控制。

4：UI設計

 

1． 善用顏色

我在寫平時的email或者交付測試報告的時候，經常被老板提醒顏色的使用。在同一個頁面中，最好不要出現多於3種顏色。因為本來顏色的使用是為了突出重點，然而如果過多地使用顏色，就等於到處都是重點，最后的結果就是沒有重點。因此善於使用顏色也是UI設計的關鍵。

¨         使用顏色區分報表的類別

這樣做是為了方便用戶區分報表。例如，把紅色加粗字體應用於銷售類報表名，把藍色加粗字體應用於出勤類報表。那么用戶以后看見紅色標題的頁面就知道是銷售類；藍色標題的頁面就知道是出勤類了。

¨         應用顏色區分閾值數據

如，對於銷售類報表，Manager們關心的是沒有達到銷售指標的區域。如果報表中對沒有達到指標的數據均以紅色字體呈現，那么Manager一打開頁面一眼就可以從眾多的數據中看到他最關心的部分，大大提高了閱讀報表效率。

2．  統一格式

一般報表分為兩大部分，表頭(Head)和表體(Body)。表頭，一般放置報表名稱以及查詢條件；表體，由表格形式的報表組成，可以為一個也可以為多個(子報表)。在統一格式方面，我們需要注意的地方有：

¨         字體

不同的地方應使用不同的標准，如，表頭中的報表名稱，表體中的統計值的字體和大小應該不一樣；然而不同的報表的報表名稱應使用一種字體和大小。

¨         表格

定義最小單元格，而報表中只能使用最小單元格的整數倍作為表格的大小。例如，UI標准定義最小單元格為(長X寬)=1cm X 0.5cm；如果遇到某單元格中需要填寫的值長度為1.3cm時，此時對應單元格應該為2 cm X 0.5cm。這個有利於導出格式的一致性。

¨         單位

不同的統計值使用的單位是不一樣的。不管單位是什么，我們都應該放置於一個統一的地方。例如，可以統一標注在報表的某個地方，寫着(Unit：￥)；或者是直接填入統計值中，如￥ 3.00。

¨         術語

使用行業術語，增加報表的專業性。

3．  導出和打印格式

一般報表的使用者，會更多地應用導出功能導出成別的格式，或者是直接打印出來查看。此時，我們就需要檢查報表導出后格式有沒有變形。打印時，報表會不會因為分頁打印而造成報表內容缺失，或者不易被查看。

 

轉載來源 https://www.cnblogs.com/richered/p/8490776.html