測試日報和測試報告有什麼區別？如何瞭解專案進度？

軟體測試記錄，是一項比較考驗邏輯思維和想象力的工作。它既不像軟體開發那樣有實實在在的程式碼作為工作成果的展示，也沒有BA那樣，將軟體需求拆分為story，就能夠決定專案的走向。測試工程師的測試成果則沒有那麼明顯，沒有很容易可度量的成果展示，那麼為了保證軟體質量，同時也要知會給專案相關方，那麼測試日報和測試報告就是非常重要的途徑了。

測試日報和測試報告，在一定程度上是可以避免冗長的會議彙報，以及反覆和專案相關方的溝通，體現了資料一次性報備，同時在原有郵件上全部回覆式的更新，可以清晰地體現出測試工作的推進和版本的迭代情況。有助於未能深入瞭解專案的相關方，從基礎資料入手來了解整個專案的執行。同時也避免了專案後期，對於一些使用者發現bug的回溯被歸因為測試漏測的情況。

一、測試日報

這是一個理論上可以使用Jira或禪道等專案管理軟體，生成每日專案情況來進行替代的東東，但礙於各種原因，專案組內的干係人不一定能夠及時獲得這樣的資訊，那麼對於同步專案進度，特別是測試進度，測試日報就顯得非常重要了。

一個合格的測試日報，需要起到以下幾種作用：告知測試進度；明確風險因素；現存bug列表中的內容；以及相關資訊。

1）相關資訊：包括專案的日期、開發測試人員名單、軟體版本等等。

專案日期用於表明該專案所屬的時間週期和時限，用於確定專案進度的階段是否在專案週期範圍內。

人員名單這個用於告知專案相關方，尤其是專案組之外的干係人，開發和測試分別是誰，這樣需要了解具體情況的時候，可以直接找到具體對應的人。

而軟體版本，則是用來確定當前的測試物件的版本，是否是目標版本，以及明確當前測試的測試物件。

2）測試進度：就是告知測試程式，一般以百分比表示。這個度量可以是測試工程師針對自己工作總量的比較，也可以是測試用例執行數量和總數量的比較，也可以是日程的進度百分比。作用是直觀地體現測試進度，對於很注重專案進展的干係人，會有直觀反饋。但其實在敏捷流程下，這個指標的意義並不明顯。

可以到我的個人號：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。同時我邀請你進入我們的軟體測試學習交流平臺，大家可以一起探討交流軟體測試，共同學習軟體測試技術、面試等軟體測試方方面面，瞭解測試行業的最新趨勢，助你快速進階Python自動化測試/測試開發，穩住當前職位同時走向高薪之路。

3）現存Bug列表：一般包括Bug在Jira上的編號及連結，嚴重程度。這個列表是測試日報的核心，用於顯示在當前測試周期內未關閉的bug都有哪些。需要注意的是，該列表在週期末未能歸零，則當前Sprint是無法進入下一週期的。

這樣就可以直觀地看出來當前bug中，各個等級的bug佔比，用於進行資料統計。

測試日報沒有固定的格式，需要注意的幾點：

1）測試活動進行的時候，當天才會有測試日報。

2）測試日報傳送範圍僅包括專案組和專案干係人。

3）如果專案採用的是敏捷流程，那麼日報中的資料要能夠和Jira的資訊相互印證。

4）測試日報不用來體現開發問題，也不用來作為評價開發水平的依據。

以下是測試日報可以參考的模板：

二、測試報告

測試報告是針對一個專案結束，或者一個release節點完成了，針對該專案或者該節點階段，進行的軟體質量總結性的評價。

測試報告的形式也比較多，比較簡單的是測試用例表格的執行結果記錄，可一直接作為測試報告的內容；稍微複雜一點的，可以進行一些圖表的列舉，用以呈現在該週期內，質量資料的變化，這裡就是對之前日報中bug嚴重程度佔比的引用。各種變化的折線圖、餅狀圖等等，都可以在報告中展示質量指標的變動。

和測試日報一樣，在測試報告中，需要標明專案參與人員，測試環境的各項條件，軟體版本區間，以及測試物件的拓撲結構。

形式最複雜的，涵蓋內容最多的，可以稱之為質量分析報告。在這裡需要說明的是，質量分析報告仍然是聚焦於分析軟體質量本身，而並不用於質量追責或者責任回溯。

質量分析報告中，需要對發現的bug進行歸類和分析，用以分析出引發失效的原因，從整體上反映出來問題較為集中的模組，或者失效集中發生的原因，例如需求不夠明晰、模組分離度不夠，聚合度低耦合度高等。

以下是測試報告可以參考的模板：

測試日報和測試報告，乃至最後的質量分析報告，是測試工程師在專案中，可被直接認定的、可量化的工作輸出，需要認真對待，特別是Jira和禪道等專案管理/缺陷生命週期管理軟體的報表功能還沒有得到充分利用的時候。這些是能夠最直觀呈現軟體質量波動的有力武器，也是軟體測試工程師的基本功體現。