報告系統的測試計劃

Question

我有一個由多個集成軟件包組成的軟件套件。它們都運行在一個單一的集中式SQL數據庫上。

我們正處於編寫測試計劃的階段，併爲軟件的每個獨立模塊分配了單個測試計劃。唯一剩下的就是報告模塊的測試計劃。這個特定的模塊什麼都不做，只是運行SQL數據庫中的數據報告（將由其他模塊寫入）。

任何測試迭代之前都有開發人員，迴歸和集成測試，這些測試應該消除數據庫數據未正確維護的任何問題。

我的困境是如何處理報告模塊的黑盒測試計劃。我看到它的方式有三種選擇：

• 追加報告測試用例的測試計劃，影響他們（下行模塊：該模塊共同作用產生的報告;報告不能由模塊劃分像這樣）
• 編寫一份測試計劃，用於指定先決條件，基本上是要在其他模塊中執行的任務的指令列表，然後是測試用例以測試報告是否正確生成以響應這些任務（下行：非常複雜且冗長）
• 編寫一個測試計劃，用於在專用受控SQL數據庫上設置數據集的報告（缺點：缺乏靈活性能力）

在我看來，第二個選項是最好的。這是時間最長的一次，但僅此而已，幾乎不是打折的理由。

有沒有人有任何測試純粹是爲了報告模塊的經驗，誰可以提供一個洞察最好/行業標準的方法來做到這一點？

在此先感謝！

Answer 1

自問一個有用的問題是「這個測試的目的是什麼？」。查看Agile Testing Quadrants瞭解不同測試類型角色的一些細節。

（圖片來源：麗莎·克里斯平）

選項1着眼於整合點自己，這可能是對球隊有價值的，因爲它可以簡化問題的診斷（因爲只有1個模塊將被使用一次），但未能測試系統，因爲它實際上會被使用。從這個意義上講，可能屬於第二象限。

選項2更側重於測試系統，因爲它將用於現實世界場景，調用多個模塊。您從選項1中無法輕鬆診斷問題，但您實際上已開始以對最終用戶有價值的方式對其進行測試，並將其置於第3象限中。

選項3基本上是靈活性較低的選項版本2.你也失去了很多與單個模塊的交互，使得選項2非常有價值（因爲它作爲一個整體來執行系統）。一個足夠'真實世界'的數據庫可以使這個Q3選項，但你仍然失去了靈活性。

通過這個鏡頭比較選項2和3，我們可以看到他們服務於不同的目的。當然，他們都執行許多相同的代碼路徑，但選項1主要支持團隊，讓他們知道何時更改特定模塊已打破報告，而選項2用於批評產品，詢問是否實際工作一個真實世界的場景。現在的問題是哪些結果對你更有價值，這取決於你和你的團隊。

希望有所幫助。