在一个较大型的项目中，通常运作的方式是按照子项目或者功能模块来进行分工每个功能模块有具体对应的设计、产品、运营、开发和测试人员。结合实际的项目情况如果功能较大可能上面一个角色有多个人一起参与，反之也可能一个人同时负责多个功能模块。不管是哪种情况，实际项目在测试进行中，以上不同的角色，以及对应的各个团队 leader，甚至公司或部门管理层，都希望及时看到工作的进展，以及遇到的问题和风险。
而另一个方面，互联网产品的测试周期都比较短，一个模块的整个测试周期只有几天是非常常见的，使得我们不可能有大量的时间用在整理测试进度的报告本身。结合这两种情况，我们需要考虑一个比较清晰简洁的方式来反映出测试工作的进度，暴露出其中的问题让大家尽快关注到，同时让编写这样的进度报告的代价变得比较小，因为太多的文字工作是无法承受的。下面我们来看一下在实际的项目中我们用到的一些方式。
测试进度报告：在测试阶段中间发出，告知测试工作的进度，发现的问题、风险，以及接下来的计划。
这个报告发送的频次依据具体的项目情况而定，对于比较重要的且时间比较短的项目建议每天发出，让相关人员可以非常及时地了解进展和风险。对于一些周期比较长的或者重要性的不高的项目，可以考虑隔天或者每周发送，基于大家的讨论来约定。
测试完成报告：标志测试工作的结束，会给出对应的测试结果和结论，包含是否达到可发布的标准以及还有哪些遗留问题。这个报告一般在整个测试工作完成之后发出，针对某一个具体的模块或者整个的测试项目。
测试进度报告
测试进度报告，主要内容非常简洁，主要侧重于一下几个方面：
风险和问题：基于要事先说的原则，在邮件的一开始就把当前遇到的可能影响项目质量或者进度的问题列出来。如果是比较紧急的，可以标红或者加粗来引起收件人的注意。
测试工作进度：这个可以给出一个大概的百分比，可以用测试用例的执行情况，也可以基于测试人员自己的工作估计。
当前 bug 统计：一个简单的 bug统计，让大家可以看到 bug 的总数和待处理的 bug数量。
未关闭bug列表：让大家可以比较直观地看到待解决bug的情况，从标题上就有个基本的了解，以及对应的状态、严重程度和相关的处理人。
我们在测试的过程中，有的项目会包含多个子项目，在上报测试进度的时候，要考虑各子项目的测试进度。
还有的项目进行了专项测试，针对某个模块的测试，除了基本的黑盒功能测试之前，可能还需要进行其他针对性的测试，我们称之为专项测试，具体的专项测试内容和做法将在本书的后续章节展开讨论，这里为了便于说明，只简单列举部分测试类型，比如:兼容性测试、流量测试、电量测试、弱网络测试、代码覆盖率测试。
测试完成报告
当某个具体的功能模块测试完成后，对应模块的测试负责人会发出对应模块的测试报告，发给相关的项目经理/设计/产品/开发/运维同事，以及对应的团队leader，标志着该功能通过了测试，可以进人发布(或者灰度)阶段。
实际中报告的具体信息可以根据团队项目管理的要求来做调整。在有专职项目经理来跟进功能和版本进度的情况下，通常项目经理会基于这样的测试完成报告来认定该模块的测试完成，常常也意味着该模块研发工作的完成，所以在发出该报告前也需要将遗留问题都评审过，大家认定当前模块质量达到了发布标准。
以上是单个模块的测试完成报告，对于整个 App，通常 Android 和iOS 等平台分开来看，因为对外发布的单位是一个完整的App，所以也需要一个完整的测试完成报告来给出测试的结论。格式和上面类似，只是测试范围和遗留问题的罗列可能会多一些。
