報表測試注意事項

進銷存系統中的報表測試

 報表功能的基本要求，就是通過查詢/統計/分析，提供用戶所需的準確的數據。如果無法實現這個基本功能，則報表完全失去意義。

對于用戶來說，報表可以直接影響到他們的決策，例如可能因為報表對銷售和庫存情況反映的不準確，導致錯誤的大量進貨；或者因為報表對應收應付金額計算的不準確，而導致企業對資金占用情況做出錯誤的估計，

從而導致錯誤的決策，最終造成用戶在經營上的損失。諸如此類，相信只要大家留心，還可以找出很多這樣的例子。

進銷存系統中的報表多如牛毛，而且各種不同行業的進銷存系統中的業務有區別，報表也有些區別，因此不太可能對各種報表逐個講解，而主要是把一些報表測試的經驗總結成了十幾條可以在各種行業的報表測試中應用的“最佳實踐”，來跟大家一起分享。希望下面的這十幾條像一招招簡單實用的“擒拿手”，可以供正在進行報表測試或者準備開始作報表測試的朋友隨手拈來，見招拆招，輕松應對這項工作。

（1）       提高對業務的熟悉程度

    其實對任何一個軟件進行測試，都必須要熟悉它的業務，包括業務流程和業務規則。但是報表同一般的業務功能還是有些區別的。例如對于單據的增、刪、改，通過對界面的瀏覽和探索性的操作，大概都可以弄明白它的業務流程和業務規則，因為這些內容比較直觀，而且在不同的行業中也差不了太多。但是在報表中，是很難直觀的看到我們所需要了解的內容的。例如報表中的某個數據項，它的算法或者說數據來源，恐怕是比較難看出來的——即使是很類似的一個數據項，在不同行業的實際業務中，它的算法和數據來源也可以能完全不同的。

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

（2）       覆蓋所有可能的查詢統計方式，而不是以自己的使用習慣為準

    對于報表的使用者來說——一般是企業的中層或高層領導，他們對于報表的要求可能會是多方面的，例如在進銷存系統中，可能需要按不同商品進行分類統計，也可能是按供應商分類統計，這些都是由用戶在實際工作中的需要來決定的，所以假如一個報表提供了多種查詢統計的方法，那么在測試時，只要時間充分，就應該覆蓋這些所有可能被用到的查詢統計方法，而不是以自己的使用習慣為測試的依據。

（3）       使用或構造受控的數據環境

    數據對于報表測試來說是一個非常非常重要的問題。因為上面說到，報表的基本功能就是通過各種查詢統計分析的方法，為用戶提供準確的數據，幫助用戶做出決策。那么那些用來進行測試的數據從哪里來呢？

    首先，應該保證準備足夠多的有效的數據。前面一條也提到了，在實際測試報表時，應當盡可能的覆蓋到報表所提供的各種查詢統計方法，因此至少應該保證每一種查詢統計方法都應該有對應的數據，得到的結果都不會是0，否則等于沒有覆蓋到這個被測的查詢統計算法。當然數據也不是越多越好，能保證全部覆蓋，并且剛好夠用就可以了，因為數據的準備和生成也是很花時間的。

    其次，要保證數據的可控。數據并不是隨意生成的，如果使用通過自動化工具或者通過業務測試時隨意的輸入的數據來進行報表測試，一般來說是不太可能的。因為如果無法控制數據來源，那么即使知道報表中每個數據項的算法，也無法最終驗證報表的查詢統計結果是否正確。例如，系統的會有不同類型的單據，每種單據又會有不同的狀態，某個報表的統計中，可能會涉及到多種類型和狀態的單據，那么在準備數據時，就要充分考慮到這一點，準備各種不同的單據來滿足測試的要求。又比如，如果整個系統中只有一個供應商，一個商品，那么測試按供應商分類統計或者按商品分類統計的報表時，意義也就不大了。

    所以如果希望高有效、更高質量的完成報表的測試，那么就要重視并增加對于數據準備工作的關注：用于驗證報表功能的數據，一定是專門為報表準備的，并且是經過精心設計，要分析影響數據項算法的各種因素，以及每個因素可能出現的不同變化，這樣才有可能覆蓋各種查詢統計方法；同時，才能保證無論使用哪個數據項的算法進行計算，其結果都是可以預知的——因為數據來源已經被我們控制了。

    特別是對于算法比較復雜，又提供了多種查詢統計方式的報表，如果想完整的測試，就需要準備大量的數據。而如果想高效、高質量的完成這項功能，就一定要理解數據準備工作的重要性。

    經過精心設計的數據還有一個好處，就是當在進行業務功能的測試時，不再需要使用一些隨意的數據，而是可以通過業務測試的過程，把報表測試所需要的數據輸入到系統中。并根據報表對單據類型和狀態的需要，進行相應的操作。

    如果留心，你也會發現報表測試同其他業務功能測試的有個區別。業務功能（例如單據的新增、審核等）的測試用例設計，通常需要考慮的是對各種正常的、異常的業務流程和業務規則的組合的遍歷或覆蓋；而對于報表功能，雖然沒有太復雜的業務流程和規則，但是算法更加復雜，同時報表功能本身就是一種對數據的加工處理，因此會更偏重于對于各種數據來源和算法的遍歷或覆蓋，也就是要準備各種正常的、異常的數據，來驗證報表是否取到的該取的數據、沒有取不該取的數據，并且最后計算出了正確的結果。

（4）       特征性數據的準備

    這又是一個同數據準備有關的問題，也是一個解決實際問題的經驗。如果由多人同時對一個系統進行測試，雖然大家各自使用的數據都是經過精心設計的，但是在實際進行報表測試時，還是很難保證其他人的數據不會對自己的測試結果產生影響，最明顯的一個問題就是原來自己對結果是可以預知的——因為數據是經過精心設計的，是可控的，但是現在摻雜了別人的數據，就需要花時間去區分這種“假”的錯誤和真的錯誤。

有一個經驗是可以借鑒的，就是在初期，團隊內對數據的準備達成一直，使數據中的某一項具有特征性，例如分別使用不同的供應商，或者使用不同的商品。最后測試報表時，通過限定選取的數據來源，來保證相互之間盡可能的沒有影響。

（5）       做好數據環境的備份和維護

雖然數據是經過精心準備的，但是難免在操作過程中因為誤操作導致環境的變化，例如不小心把一張單據變成了另外一種狀態，或者某個類型的單據多做了一張。對于這種情況，一個簡單的方法就是去維護你的數據文檔——一般我們都可以用EXCEL表來保存我們事先準備的數據，可以一個文件保存一個類型的單據，例如采購單、入庫單、出庫單等等，文件中的每張表用來保存不同狀態的單據，例如已經審核過的入庫單，沒有審核過的入庫單，全部入庫的入庫單和部分入庫的入庫單，等等。假如你一不小心，把一張本來準備入一半的入庫單全入了，那也不要驚慌，去重新調整一下你的數據文檔，在相應的類型相應的狀態的單據列表中新增一張就行了。

而如果想減少回歸測試的工作量，那么應該考慮在一些關鍵的“點”上備份測試數據。例如所有的基礎單據已經輸入完成，但是還都沒有開始審核或者出入庫，那么可以備份一下，下次再測的時候可以直接在數據庫中恢復這部分原始數據。

（6）       在業務功能測試通過之后才開始

這一點相信應該不難理解，如果業務功能本身存在缺陷，導致的數據不準，那么最后進行報表測試也就沒有什么意義了。所以，應該在保證各項同報表有關的業務的功能測試通過之后，才開始考慮對報表進行測試。

（7）       尋求開發人員的協助

    在報表測試中很常見的一個問題，是需求文檔中可能沒有定義報表的各個數據項的算法，這時候你需要找開發人員幫忙，向他們了解準確的算法和相應的公式。

（8）       多個報表相互對照

這是一項“高級”的報表測試技能，需要對整個系統中的各種業務的熟悉程度達到一種爐火純青的地步。除了可以準確的說出各個業務的處理過程對每張報表的影響之外，還能夠進行橫向的聯系，知道不同報表之間存在的關系。例如，一個簡單的例子，庫存報表中，你可以看到商品的出入庫情況，而在銷售報表中，你可以看到商品的銷售金額和銷售成本金額，在應收應付報表中，你又可以看到不同供應商或客商之間的應收應付金額。那么這幾張報表之間，是否存在一些關聯呢？是否會存在一些可以相互驗證的地方呢？

（9）       著重對那些算法復雜、與業務功能關聯較多的報表的測試

    如果只是簡單的把某個日期范圍內的所有入庫情況統計出來，可能不會出錯；但是如果還要考慮按照供應商或商品匯總，同時要選取特定的類型或狀態的單據，再進行一些響應的計算，恐怕就很難保證開發人員永遠不會出錯了。這就像業務功能的測試一樣，越是復雜的業務，越有可能出錯。

（10）   留意四舍五入對報表數據的影響

從這一條開始，后面的內容可以說也是一些在實際測試時要注意的事項。

這也是一個常見的問題。在一般的進銷存系統中，都會存在這種情況，無論小數點后保留幾位，總是難以避免明細和匯總之間的差別。原因可能是因為采購和銷售的包裝不一致，因為拆零引起的，例如10/30*30≠10；或者由于毛利率、稅率等因素導致的不一致。我們曾經試過在保留4位小數的情況下還是無法避免這種情況。

（11）   留意進/存/銷時使用不同單位對報表數據的影響

例如采購時是5箱，每箱有100盒，而銷售單位是盒，入庫之后，可能會要求按照銷售單位來統計，這時要注意開發人員是否會選擇了錯誤的單位，把500盒弄成5盒。

（12）   留意業務單據中存在多個日期字段時對報表數據的影響

    一般來說，一張單據上都會有多個日期字段，比如采購單就有采購日期、單據日期、審核日期，而入庫單也會有單據日期、入庫日期，諸如此類。那么在測試時，一定要留意，開發人員是否按照要求選擇了正確的日期，包括日期選取的一致性——是否存在這邊取采購日期，那邊取審核日期的情況。

（13）   留意是否存在遺漏的單據類型

    例如像出入庫的報表，入庫方向的，除了最主要的采購入庫外，可能還會包括退貨入庫、盤盈入庫、報溢入庫；出庫方向的，除了最常見的銷售出庫，還會包括盤虧出庫、報損出庫。那么在具體測試時，一定要準備充分這些相應類型的單據，并且要留意開發人員是否遺漏了相應的單據類型。

（14）   留意不同狀態的單據對報表數據的影響

例如采購單，當采購單發出后，供應商會開始送貨，可能第一批之送來了一半的商品，那么這時采購單的收貨狀態是“未完成” ；當供應商把商品送齊了以后，采購數量＝收貨數量，則采購單的收貨狀態變為“已完成”。那這時留意，開發人員在采購報表中，是包含所需要的狀態的單據，還是只包含了一部分？

（15）   留意那些被當做默認規則的因素

有些規則——例如單據類型或者單據狀態——是作為默認規則寫死在SQL語句或者數據庫的存儲過程里面，這些規則不會體現在界面，也不會由用戶選擇決定。但是這些規則恰恰是最容易被忽略的部分。所以，一定要同開發人員反復確認，保證自己已經了解了同報表各數據項計算有關的各個因素。

（16）   保證測試人員可以通過UI 找到自己所需的所有原始數據

在進行系統測試時，無論是報表，還是一般的業務功能測試，都不要去直接通過SQL語句查詢數據庫中的內容，而是通過UI來輸入，再通過UI體現處理的結果進行驗證——因為這是系統測試，不是集成測試，將來用戶是決不會去直接查數據庫的。因此，如果需要對報表的結果進行驗證，應該通過其他的功能模塊，去查詢業務單據，或者其他報表，根據UI體現的結果，來進行確認。

（17）   檢查大數據量對報表的影響

    報表測試也會涉及到性能測試，主要是在大數據量查詢統計的測試。大數據量一是說原始數據多，二是被操作、計算的數據多，三是某個數據項被是經過多次計算得出的。特別是對于一些算法比較復雜的報表，10萬條數據和100萬條數據時的響應時間將表現出巨大的差別。

（18）   不要遺漏權限控制和訪問安全性的測試

這里說的權限控制不是誰可以訪問某個模塊，誰不可以訪問某個模塊，而且數據的計算也沒有直接的關系，而是側重于報表設計的測試。我們都知道不同的報表是設計給不同的人看的，例如出入庫報表是給倉庫管理人員看的，里面不會包含商品的價格，而只會包含數量；而財務報表中，只會包含采購、銷售的金額，而不會包含數量，這樣才能保證可以相互對照，不會出現營私舞弊的行為。那么在測試時，應當考慮報表是否泄漏了不該泄漏的信息。當然，這里對業務的熟悉程度就是更高的要求了。

又如，不同的業務員只能看到同自己有關的業務，但是領導可以看到所有業務員的業務——例如不同的業務員分管不同的客戶或者地域，他們之間的銷售情況是互相保密的。

還有一種情況，系統的用戶可能會為他的供應商提供一個專門的程序或者Web頁面，供其對其供應的商品的銷售、庫存情況進行查看。那么對于這種情況，一方面是要保證某個供應商只能看到他所供應的商品的銷售、庫存情況，如果某個商品由多個供應商同時提供，那么其中一個供應商應該只能看到他提供的那部分，而看不到其他供應商提供的同一商品的情況。當然，這種功能一般都是通過外網（internet）來訪問的，所以也還要考慮相應的訪問安全性測試，以免泄漏重要的商業信息。

原文轉自：http://www.anti-gravitydesign.com