作者:梁lxc_131 | 来源:互联网 | 2023-07-11 10:53
如何编写测试文档
相信很多小伙伴都有过产品测试的经历,在测试环节之后,就是要编写合理的测试文档。那么一篇合格的测试文档是什么样的呢?
通常情况下,测试报告上会包含测试进度,测试环境,测试情况大致描述、作为测试者对于当前版本的看法(是否可以上线),测试内容(测试场景),测试概况,新提交的bug汇总等内容。
本文中将以我们的一个项目,TimeIsMoney,一款校园做任务挣钱的云平台为例。
测试文档包含的要素
一、项目背景
本测试报告的具体编写目的,指出预期的读者范围。
简单介绍项目的情况,令读者有一个较为明确的产品概念。
例如:
Time Is Money将是一款专门面向大学生的C2C的在线应用,是一个为广大高校生群体提供快速兼职的平台。Time Is Money面向所有高校生,用户可以发布任务获取便利,也可以完成任务获得赏金,平台将会保证每一个任务的真实性与可靠性。
二、测试人员
说明这次测试的人员有哪些,每个人的职责是什么。
明确责任,明确测试投入人力。
三、测试时间
这个部分其实是在写测试报告时通常会遗漏的点,因为我们总是认为大家应该是知道时间的,就觉得不重要,但其实这是很基本的要呈现出来的测试要素。明确测试时间,也能让看报告的人知道测试精力投入情况,以此再做其他的评估。
测试的时间要精准,如果是整个展品的测试,就要写明测试的时间点;如果是针对某个功能的测试,就要注明测试的模块,并写明测试的具体时间,以便于以后将其他模块的测试进行整合。
四、测试平台/测试版本
注明当前测试的平台,以便于之后的分析工作。
注明当前测试的版本,如果之后产品进行迭代,可以清楚地区分,并且方便进行比较与整理。
五、版本风险
当前有哪些已知风险,可能有什么未知风险?基于要事先说的原则,在靠前的位置就需要把当前遇到的可能影响项目质量或者进度的问题列出来,如果是比较紧急的,可以标红或者加粗来引起收件人的注意。
例如:
1、设计风险
(1)没有统一的界面设计规范。
解决方案:与项目负责人确认测试标准。
2、开发风险
(1)所有模块开发没有统一设计,开发人员有自己的设计方式。
解决方案:与项目负责人确认标准方式,与标准方式不一致的地方全部以BUG形式提交。
3、测试风险
(1)版本控制。
解决方案:严格控制版本,BUG以版本为单位进行提交。在测试过程中及BUG确认阶段禁止任何代码更新。
(2)测试时间不足。
解决方案:动员测试人员完成测试任务。
六、测试内容
测试内容也就是测试场景,是测试文档中最为重要的部分。在这个环节中,我们需要说明在此次测试中测试了什么内容,是怎么测试的,采用的测试场景有哪些,是否符合测试预期,测试的结果是怎么样的。
我们可以用文字的形式表达出来,具体列举测试中的每一项内容;也可以选择更为直观的方式,比如表格、绘图等。
例如:

七、测试结果
测试结果是对于本次测试的一个总结和评价。一般包括:
1、测试中存在的问题
2、版本各个模块存在的bug情况
3、是否有严重的问题,分别是什么问题?
4、作为测试者对于当前版本的看法(例如从测试的角度上来说这个版本是否可以上线)
5、项目评价
如果项目测试效果较好,没有明显的bug,则可以针对需求和设计方面进行评价和总结。
例如:

当然也可以采用图表的形式:

以上就是编写测试文档所需要注意的内容了,最后要说明的一点是,一定要注意格式的问题。清晰的层次,一目了然的架构会为你的文档增色不少。