众所周知，在职场，总有各式各样的报告要看，要写，而最常规的莫过于周报（或者日报）了。这类报告通常是关于个人的工作情况或者项目的进展情况等。那么作为一名测试人员，该如何写周报呢（若有日报需要，以此类推）。
通常在写一份报告之前考虑这么两个方面会让你的报告更具阅读性，那就是：报告要表达的主题是什么，报告的观众/听众是谁。对于同一个（或者相似的）主题，观众/听众不一样，报告所需要陈述的具体内容通常也是不一样的。
下面我想从测试员和测试组长（负责人）的角度分别罗列一下测试周报的模式和内容。
一、测试员（tester）
测试员的周报一般来说是汇报给自己的组长，就我自己的工作经历来说，一般软件公司测试组长兼具项目以及行政两个方面，也就是说一方面主导分配到这个测试小组的测试任务，另一方面也要关注组员的工作绩效以及团队发展等。所以汇报给测试组长的周报就要比较详细的从项目和团队合作方面同时阐述自己一周的工作情况。大概可以包括这个几点：
1、内容概要罗列以及花费时间列表
阐述本周自己主要的工作情况，譬如参与了哪几个项目的哪些相关测试，出席了几个公司会议，参加了几个公司内（或外）的相关培训课，阅读了什么工作相关的资料/书籍等，同时（推荐以表格的形式）列出每一项工作（或相关）内容所花费的时间（work hour）
2、执行的测试用例数目
按照项目分别列出，本周执行了多少测试用例，其中pass多少，fail多少，有多少用例被block了不能执行（需要另外列出具体的被block原因，如某个bug或者某项测试资源没有到位），还有多少已分配的测试用例没有完成。这些信息推荐以表格形式给出，参见下面的草图：
| Pass | Fail | Blocked | Remaining | |
| Project A | 25 | 3 | 2 | 16 |
| ...... |
如果执行了ad-hoc或者exploration测试，可以考虑以表格形式列出测试内容。
3、提交的bug具体数目
体现测试人员绩效一个重要的方面是提交的bug数量和质量。所有在这里列出本周里在每个测试项目中你提交的有效bug数，无效bug数（重复的bug，不能复现的bug），验证的bug数（有效修复-fixed，无效修复-reject），这些信息同样推荐以表格形式给出，参见下面的草图：
| Submitted-Valid | Submitted-Duplicated | Submitted-Unreproduciable | Verify-Fixed | Verify-Reject | |
| Project A | 5 | 2 | 0 | 8 | 3 |
| ...... |
4、其它
任何工作相关的其余内容。譬如你希望多一个测试平台，你需要某本专业书籍等等等等。
二、测试组长
测试组长的周报通常来说覆盖两个方面，一是项目相关情况，这个内容的目标读者是所有和项目相关的人员（项目经理，产品经理，开发人员，测试人员，发布人员等），另一个方面是关于团队管理方面（有时候会把这一项单独放在一份报告里发给测试经理，毕竟项目相关人员只关注项目的测试进展情况，基本不关心测试团队成员的具体工作内容）
1、严重问题
任何阻止测试顺利进行的issue都要在这里醒目列出，同时要注明希望问题得到解决的最后期限，如果知道报告接受者中的谁可以帮助推动解决这个问题，要明确指到该人姓名。
