眾所周知，在職場，總有各式各樣的報告要看，要寫，而最常規的莫過於週報（或者日報）了。這類報告通常是關於個人的工作情況或者專案的進展情況等。那麼作為一名測試人員，該如何寫週報呢（若有日報需要，以此類推）。

　　通常在寫一份報告之前考慮這麼兩個方面會讓你的報告更具閱讀性，那就是：報告要表達的主題是什麼，報告的觀眾/聽眾是誰。對於同一個（或者相似的）主題，觀眾/聽眾不一樣，報告所需要陳述的具體內容通常也是不一樣的。

　　下面我想從測試員和測試組長（負責人）的角度分別羅列一下測試周報的模式和內容。

　　一、測試員（tester）

　　測試員的週報一般來說是彙報給自己的組長，就我自己的工作經歷來說，一般軟體公司測試組長兼具專案以及行政兩個方面，也就是說一方面主導分配到這個測試小組的測試任務，另一方面也要關注組員的工作績效以及團隊發展等。所以彙報給測試組長的週報就要比較詳細的從專案和團隊合作方面同時闡述自己一週的工作情況。大概可以包括這個幾點：

　　1、內容概要羅列以及花費時間列表

　　闡述本週自己主要的工作情況，譬如參與了哪幾個專案的哪些相關測試，出席了幾個公司會議，參加了幾個公司內（或外）的相關培訓課，閱讀了什麼工作相關的資料/書籍等，同時（推薦以表格的形式）列出每一項工作（或相關）內容所花費的時間（work hour）

　　2、執行的測試用例數目

　　按照專案分別列出，本週執行了多少測試用例，其中pass多少，fail多少，有多少用例被block了不能執行（需要另外列出具體的被block原因，如某個bug或者某項測試資源沒有到位），還有多少已分配的測試用例沒有完成。這些資訊推薦以表格形式給出，參見下面的草圖：

　　如果執行了ad-hoc或者exploration測試，可以考慮以表格形式列出測試內容。

　　3、提交的bug具體數目

　　體現測試人員績效一個重要的方面是提交的bug數量和質量。所有在這裡列出本週裡在每個測試專案中你提交的有效bug數，無效bug數（重複的bug，不能復現的bug），驗證的bug數（有效修復-fixed，無效修復-reject），這些資訊同樣推薦以表格形式給出，參見下面的草圖：

　　4、其它

　　任何工作相關的其餘內容。譬如你希望多一個測試平臺，你需要某本專業書籍等等等等。

　　二、測試組長

　　測試組長的週報通常來說覆蓋兩個方面，一是專案相關情況，這個內容的目標讀者是所有和專案相關的人員（專案經理，產品經理，開發人員，測試人員，釋出人員等），另一個方面是關於團隊管理方面（有時候會把這一項單獨放在一份報告裡發給測試經理，畢竟專案相關人員只關注專案的測試進展情況，基本不關心測試團隊成員的具體工作內容）

　　1、嚴重問題

　　任何阻止測試順利進行的issue都要在這裡醒目列出，同時要註明希望問題得到解決的最後期限，如果知道報告接受者中的誰可以幫助推動解決這個問題，要明確指到該人姓名。

　2、各個專案測試用例完成情況

　　可以用類似於下面的柱狀圖來表示

　　（如有必要，可以給出具體的連結指向測試用例管理庫中本輪測試的詳細內容和結果）

　　3、各個專案的bug以固定時間為單位（通常週報中就按周來統計）的增減情況

　　（統計的bug數量可以是所有優先順序/嚴重程度的bug總和，也可以只取第一第二優先順序/嚴重程度的bug進行統計，因為很多時候，這類bug的數量直接影響產品釋出與否，而這個，正是專案相關人員最關心的）

　　例見下圖

　　（如有必要，給出具體連結指向bug管理庫中該專案所有bug的詳細內容）

　　4、各個專案的bug按照一定類別的百分比統計

　　（這個圖可以讓看報告的人一目瞭然當前專案中的主要問題存在哪裡，是功能上的，還是介面上的，還是通訊上的，還是其它等等等等）

　　例見下圖（具體分類根據不同產品不同專案而不同）

　　5、（如有必要）測試小組成員的大概工作情況

　　可以包括：有多少測試人員參與，每個人在各個專案中花費的時間，有時候也可以列出每個測試員執行了多少測試用例，提交了多少bug，驗證了多少bug等資訊

　　可以參見如下表格：

　　6、任何專案相關的其它雜事