测试活动中的那些文档们

很久没有更新文章了，今天给大家讲一下测试活动中的那些文档们。

不知从何时起测试过程中，写得最多的文档就是测试用例，有时连测试报告都免了，毕竟测试任务真的很紧，时间都拿熟悉执行测试了，哪里有时间写测试文档啊，再说我们也不爱写这些文档啊，哈哈。。。

首先，列一下测试过程中我们会接触到哪些非测试人员编写的文档：

1、需求文档

需求文档包含很广，有产品经理写的PRD，有word版、有excel版、还有原型图的，具体输出什么类型的文档看产品经理的心情（习惯），也有UI画出来的高保真原型图。

2、接口文档

3、数据库开发文档

接口文档和数据库开发文档有没有要看公司的制度，大多公司都没有，所以重要接口需要测试人员自己去梳理，或导出数据库字典，对照代码查看，理清业务操作中数据库的数据存取。

4、项目排期计划

5、等等

然后，在测试过程中哪些文档是由测试人员输出的：

1、项目测试计划

测试计划可能跟阶段有关，也有可能是根据项目迭代期次来写，也有可能根据测试活动类型来写

测试计划文档中重点就是测试范围、测试进度，一般只需要对这二块做详细描写，若是有风险出列当前风险和解决办法。

2、测试方案

大多根据测试活动类型来写，写起来太费时间了，写得不多

3、测试用例

测试用例的重要性就不用讲了，现在只要测试流程基本正常的公司都会有测试用例。

随着互联网迭代速度，测试用例的形式也由以前的excel或用例工具变成了xmind，使用word写测试用例的公司应该很少了吧，王豆豆还是在早期入行的时候是通过word来写过测试用例。

现在企业用excel来编写测试用例的也存在，使用xmind的公司大多都是敏捷开发，测试版本迭代快，需要输出用例快。

xmind写测试用例的好处：

（1）快

xmind写测试用例最重要的是突出测试点，针对一个功能或字段只需要列出测试点即可

（2）有利于思维发散

xmind毕竟叫思维导图嘛，所以在用xmind写测试用例的时候，针对一个字段的校验可以从组成、长度、特定校验入手写，若写完之后有遗漏，通过查看也能快速发现，这是区别于excel这类文字多的工具。

xmind写测试用例的坏处：

（1）对测试人员要求高

对于测试人员写测试用例有一个要求，就是测试用例能让一个新人也看懂，且能执行

用xmind写测试用例，最难的就是自己写的用例能让别人完成看懂，并且执行，因为xmind一般很少写操作步骤，且常规的检查点有时也会省略，所以要求测试人员对业务、对功能检查点比较熟悉才能做到。

（2）复用性不足

对一个系统来说，每一轮测试都需要测试人员对系统主要功能和主要流程进行回归测试，若是这部分功能特别多，相比而言excel更适合对于这部分功能进行管理 。

xmind编写测试用例更适合于功能迭代快的项目。

（3）执行结果不清晰

xmind在备注执行结果时不如excel明了、清晰，便于统计。

虽然如些，但目前王豆豆写测试用例还是更倾向于用xmind写测试用例，毕竟天下武功，唯快不破。

4、测试进度

一般来说测试过程中很少会发测试进度，因为每天都会有早会或晚会随时跟踪项目。

但实际测试过程中，最怕遇到测试阻塞之类的问题，一旦碰到这类的情况，最好的解决方案就是发测试进度出来，将测试阻塞的问题、跟踪情况、何时能解决都需要发出来。

所以一般公司都规定只要测试时间达到三天以上的都需要在每天测试完成之后发送测试进度。

测试进度中一般写：当天测试内容及完成进度、明日计划、遇到的问题、缺陷修改情况等。以邮件的形式发送给项目相关人员。

5、测试报告

测试报告经常写，除非是很小的项目才不能写，只要测试时间达到了三天以上的都需要输出测试报告。

根据每个公司的要求，对测试报告的侧重点也不同，有些测试报告只需要统计缺陷数量和测试结论就行，更简单的就只要测试结论。

最近也几份相对比较全面的测试报告，从人员、测试进度、测试范围到缺陷分析、遗漏风险、最后到测试结论，每一个环节都需要涉及到，特别是缺陷分析那一块，需要从不同维度去分析bug，更像是从不同维度去判断系统的质量、开发质量、bug修改情况、bug收敛情况，其实这才是一份完整的测试报告，因为写这样的测试报告需要很多时间，所以很多企业对于测试报告内容没有太多要求。

测试报告对测试花费也能很好体现。

整体上来说测试活动中就是这些文档，但测试人员编写的不仅限于上面的文档，有时我们也会输出一些技术文档、业务文档之类的，用于团队能力建设。有时需求文档不完善，我们可能还能自己动手给自己整理一份需求文档、业务流程图，方便于测试人员能更快更深入地了解需求。

最近项目刚成立，对测试流程要求不明确，所以需要明确测试流程和规范，明确测试流程和规范免不了要确定各个阶段的输入输出文档。

欢迎各位小伙伴一起讨论和交流项目中的那些文档。