對於軟體測試報告, 我們會希望透過它, 了解測試想要實現的目標, 以及測試期間所發生的事情的總結, 或者是測試的進展情況, 並找出某些測試未按預期工作的原因. 以下是幾個比較常見的測試報告總類:

1. 每日狀態報告

• 說明
會有這種報告, 通常是因為想要了解一線人員在做什麼, 這些報告會直接送給經理.有必須時, 會 cc 給相關的人員.

一般來說, 比較少見會使用這種報告, 因為每天撰寫很花時間. 大多會使用這種報告, 是因為遠端團隊或者是外包團隊. 但是個人覺得效果不是很好, 可以採用敏捷開發中 Daily Scrum 的作法.

• 內容
你今天做了什麼?
你計畫明天要做什麼?
你遇到什麼問題? 如何解決?
什麼事情還未處理完畢？
你需要任何幫助嗎?

2. 測試執行狀態報告

• 說明
測試對很多來說, 感覺是一個大黑箱, 不知道他們在進行什麼, 倒底這些測試個案有沒有用, 真的有在跑嗎?

為了減緩外界對測試的不了解, 以及讓外界比較清楚知道測試團隊的進度, 所以每隔一段時間, 會產生這份報告, 分享測試團隊做了哪些事情, 大致進度如何.

一般來說, 交付的頻率, 可以每週或是雙週一次.

文件的對象
• 經理
• 開發團隊
• 團隊維護或支援的團隊

• 內容
通常包含以下資訊
某週計畫要執行的測試個案數
某週已經執行的測試個案數
總共已經執行的測試個案數
找到的 bug 數目, 以及對應的狀態
未解的重要 bug 數目
Showstoppers 數目
測試個案細部資料的連結
Bug 系統的連結

3. 測試結案報告

• 說明
在測試後期, 或是測試結束後所交付的文件. 主要在描述所進行測試活動, 測試結果的細節, 測試的效果, 以及測試是否通過等等.

有些公司會很認真看待這份文件, 原因是合約關係, 或者是最後測試是否通過的說明. 尤其當有些公司會請 A 公司開發, B 公司來確認 A 公司的開發成果, 這時候這份報告就很重要.

文件的對象
• 高階長官
• 客戶

• 內容
文件的目的
受測軟體的簡介
測試範圍
哪些要測, 哪些不要測
度量指標
所執行的測試活動
測試環境和工具
所學習到的教訓 (Lesson learnt)
建議
通過標準
結論
簽核

軟體測試指標是針對測試進度, 品質, 生產力和整體健康狀況的量化指標. 目的是提高軟體測試過程的效率和有效性, 同時透過這些數據, 來做出更好的決策, 以及提高生產力. 以下是常見的指摽:

1. 基本指標
   • 測試個案總數
   • 通過的測試個案數量
   • 失敗的測試個案數量
   • 發現的 bug 數量
   • 接受的 bug 數量
   • 被拒絕的 bug 數量
   • 規劃進行測試的時間長度
   • 實際進行測試的時間長度

2. 測試涵蓋度
   • 程式碼涵蓋度 = 測試有經過的地方/程式碼全部的地方 x 100%
   • 需求涵蓋度 = 有測試的需求個數 / 所有需求的個數 x 100%
   • 測試個案執行率 = 執行過的測試個案個數 / 所有的測試個案個數 x 100%
   • 測試個案通過率 = 通過的測試個案個數 / 所有的測試個案個數 x 100%
   • 測試個案失敗率 = 失敗的測試個案個數 / 所有的測試個案個數 x 100%
   • 測試自動化的比例 = 已自動化的測試個案個數 / 所有的測試個案個數 x 100%

3. 測試效果
   • 測試個案有效性 = 在測試中找到的 bug 個數 / 所有的測試個案個數
   • 平均測試個案執行時間 = 所有測試個案執行的時間 / 所有的測試個案個數
   • 平均每個需求找到的 bug 個數 = 在測試需求中找到的 bug 個數 / 所有需求的個數
   • 平均每個需求開立的測試個案個數 = 所有的測試個案個數個數 / 所有需求的個數
   • 平均每行能找到的 bug 數 = 在測試需求中找到的 bug 個數 / 所有程式碼行數
   • 平均每行開立的測試個案個數 = 所有的測試個案個數個數 / 所有程式碼行數
   • 平均每個人找到的 bug 個數 = 在測試需求中找到的 bug 個數 / 所有測試人員個數
   • 平均每個人開立的測試個案個數 = 所有的測試個案個數個數 / 所有測試人員個數