众所周知，在职场，总有各式各样的报告要看，要写，而最常规的莫过于周报（或者日报）了。这类报告通常是关于个人的工作情况或者项目的进展情况等。那么作为一名测试人员，该如何写周报呢（若有日报需要，以此类推）。
通常在写一份报告之前考虑这么两个方面会让你的报告更具阅读性，那就是：报告要表达的主题是什么，报告的观众/听众是谁。对于同一个（或者相似的）主题，观众/听众不一样，报告所需要陈述的具体内容通常也是不一样的。
下面我想从测试员和测试组长（负责人）的角度分别罗列一下测试周报的模式和内容。
一、测试员（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都要在这里醒目列出，同时要注明希望问题得到解决的最后期限，如果知道报告接受者中的谁可以帮助推动解决这个问题，要明确指到该人姓名。
2、各个项目测试用例完成情况
可以用类似于下面的柱状图来表示
（如有必要，可以给出具体的链接指向测试用例管理库中本轮测试的详细内容和结果）
3、各个项目的bug以固定时间为单位（通常周报中就按周来统计）的增减情况
（统计的bug数量可以是所有优先级/严重程度的bug总和，也可以只取第一第二优先级/严重程度的bug进行统计，因为很多时候，这类bug的数量直接影响产品发布与否，而这个，正是项目相关人员最关心的）
例见下图
（如有必要，给出具体链接指向bug管理库中该项目所有bug的详细内容）
4、各个项目的bug按照一定类别的百分比统计
（这个图可以让看报告的人一目了然当前项目中的主要问题存在哪里，是功能上的，还是界面上的，还是通讯上的，还是其它等等等等）
例见下图（具体分类根据不同产品不同项目而不同）
5、（如有必要）测试小组成员的大概工作情况
可以包括：有多少测试人员参与，每个人在各个项目中花费的时间，有时候也可以列出每个测试员执行了多少测试用例，提交了多少bug，验证了多少bug等信息
可以参见如下表格：
6、任何项目相关的其它杂事
暂时就想到这么多了，欢迎大家指点意见。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/