如何编写一份完整的软件测试报告？（进阶版）

背景

作为测试从业者，编写测试用例，测试计划，测试报告都是必经之路，最近完成了年终述职以及版本准出，感觉测试报告或者各类报告真是职场人不可或缺的一项技能，趁着热乎劲🔥，写下一些注意事项吧~

一、什么是测试报告？

要写测试报告，首先得知道到底什么是测试报告？

测试报告：是完成测试工作之后，测试人员交出的一份总结性汇报文档

这既是对于你测试工作的一个总结，也是对于你测试对象的一个评估！

二、测试报告是给谁看的？

既然测试报告主要包含这两部分，那么另一个问题就是测试报告要写给谁看？

给领导？还是产品？还是开发？还是企业里的任何人？

这一点很重要！！！

就像你写一篇悬疑推理小说，有可能会被一些学生看到，觉得你的构思很精巧；有可能会被一些大牛看到，觉得文笔还有巨大的进步空间；也有可能被一些萌新看到，第一次接触悬疑推理，完全不懂这些推论是怎么来的，所以，问题来了，你的测试报告是给谁看的？

在企业中一般是给所有与这个项目有关的人看的，包括你的主管，项目领导，产品，运营，前后端开发等等，甚至是销售人员

所以这一份报告怎么样才能让所有人都能看懂？怎么样让所有人都能一眼看到他想要的内容？

三、测试报告应该怎么写？

既然你的测试报告要给这么多不同岗位的人提供他们想要的信息，那就应该有一个逻辑，一个贯穿始终的逻辑！

我们先看看一份测试报告应该包含什么？

然后再看一下这份测试报告的内容应该以什么方式呈现？

1、测试报告的内容

1.1 工作内容

首先，这份报告要体现你的工作内容，一个大项目搞了一年半载，一个小的功能回归就点了几下鼠标，这都是你的工作，说白了，和你下地干活没有任何区别

下地：犁地，播种，灌溉……收获粮食（结果）

测试：功能，性能，压力……软件稳定和健壮（结果）

所以这份报告应该体现你的工作内容！

包括但不限于：

• 功能测试：系统全部功能的走查/验证/回归，系统设计规格书内的功能是否全部实现，是否正常操作产生了异常预期
• 性能测试：系统整体性能的验证，在平时工作时，CPU和MEM的剩余；在极限场景下，系统的剩余性能，能否稳定工作（苟延残喘）
• 压力测试：一般考察7*24h下，系统的稳定情况，微信可否连续聊天，抖音能否持续推送视频，连续登录10000次账号成功率是否高于99.9999%
• 安全测试：这里就要考虑系统的各种安全情况，例如SQL注入，网络攻击等
• UI测试：这要求测试人员以一个真实用户的角度，去考虑这一功能的呈现，该有的弹框是不是都有，图标设计的是不是对称，某一功能的路径会不会太深
• 兼容性测试：这就包括多种兼容性，软件兼容性比如新旧版本的游戏能否互通，硬件兼容性比如市面常见的手机电脑能否支持该软件的平稳运行，甚至于蓝牙耳机鼠标等各种外设
• 数据一致性测试：这种数据一致性体现在各个方面，SQL查询结果是否正确，返回值是否正常，网络数据传输前后是否完全一致
• 可靠性测试/异常测试：一般都考虑各种异常情况下的系统反馈，比如系统剩余空间不足5%检查软件能否正常运行，弱网丢包率高于50%语音通话的质量能否接受，读写过程中插拔外设是否对原始数据有损坏

以上测试工作纷杂繁多，具体按照你的测试对象来判断，如果有兴趣我也可以再开一章单独聊聊

1.2 软件结果

这里包含的也比较繁多，就像你下地秋收一样，如何评判你的劳动成功？颗粒是否饱满，每亩产量是否充足，坏果率大概是多少？

但是一定要记住，不是所有人都会懂你这些技术细节，所以需要一句简单的总结，来告诉所有人经过你的测试工作，软件质量到了一个什么样的地步？

【例如】

• 当前软件版本质量：高，各项功能均已正确实现，系统经过7*24小时无任何稳定性问题，复合准出标准，予以准出！
• 当前软件版本质量：中，各项功能基本实现，系统经过7*24小时存在稳定性问题，遗留问题主要分为3类：第一，第二，第三，问题出现后系统可自动恢复，带风险准出！
• 当前软件版本质量：低，各项功能基本实现，仍存在遗留问题，系统经过7*24小时仍存在稳定性问题，包括内存泄漏等严重问题，不予准出！

1.3 展开说说

这既然是一款软件，就会有他的卖点，核心竞争力，和基础功能，也会有同行业的竞品（绝大部分情况是有的），在1.2中你已经给出了“一句话结论”，那么大部分人就已经不会接着看你这份报告了，对于他们来说就已经够了，但你这份报告才刚刚开始~

就像我们出去吃饭一样，首先这份饭要能吃，其次才是什么好不好吃

一款软件最基础的功能要具备，稳定性也得具备，这才是它的经济基础，有了经济基础才有上层建筑，才是那些花哨的用户界面，领先行业半个世纪的技术亮点等等……

所以这一部分应该包括（以CSDN软件为例，数据全部虚构！！！）

• 软件基本功能的实现情况：目前全功能回归完成××轮次，其中的遗留问题是什么（如果没有遗留问题，一定是你的问题，而不是软件没有问题！），责任人分别是谁，计划在哪个版本迭代上线
• 基本模块的用户体验：最基础的功能体验起来怎么样，CSDN看博客是否流畅，响应时间快不快，同时能开几个窗口
• 核心卖点的客观评价：比如现在CSDN出了一个自动编辑博文的功能，对于千字文章，成功率高达97.03%，对于错别字的识别，成功率高达96.28%；对于百字文章，成功率更是高达100%等等
• 竞品对比分析：比如这种技术论坛有不知网，全知网等等，对比不知网，优势是发帖耗时更低，只需要183ms，速度领先35.76%；但劣势是弱网下发帖的成功率太低，仅27.30%，同样网络下低于不知网的49.72%
• 客户共创/内测：一般第一个版本上线之前都会提前投入市场看看真实的客户反馈，游戏叫做内测不删档，这里会得到一些真实的客户反馈，比如某厂禁止上班摸鱼封了CSDN的端口号，能上微信上不了CSDN；员工网络设备没加白，能上内网上不了外网
• 软件的基本信息：写清楚当前软件的所有信息，方便以后问题回溯，以及其他人员不会下载到错误的软件版本，规避许多麻烦！【例】当前软件MD5值为23gk2hf2v3uf2y3g23guy,当前软件版本号V1.2.3，推荐算法模型为recommend_20220407_1305_alpha，软件包升级下载链接为hhttps:test0407/download/test.apk

1.4 你的价值

虽然这叫一份测试报告，但是有些软件庞大，光功能点就动辄成百上千，大的模块都有十几个，你一个人是测不完的，那怎么办？难道就只是呈现你的测试工作就可以了吗？

当然不行！

还是以CSDN为例，我的工作就是测试Android端APP，我测试了功能（发帖，看帖，评论等），性能（系统多后台下浏览，24h连续浏览等），兼容性（市面主流安卓机）

那我就只写这么多吗？

比如A同学负责Web端的测试（Windows&Mac），B外包同学负责IOS端的测试，C团队参与了弱网情况的软件稳定性测试，这些所有的进展都要在这里汇总，因为这一份测试报告就是整个项目的出口，而不是你一个人工作的呈现！

当然，ABC团队可能都有自己的测试报告，你可以引用

• 当前弱网情况下软件稳定性：高，在丢包率30%以下时，发帖成功率可达到87.91%；丢包率50%以上时，会给用户提示“请检查网络”并禁用发帖功能；详见参考：C团队弱网下的软件稳定性测试报告.xls

测试报告的最终目标，是给这一项目相关的所有人呈现出当前软件所有模块的最终质量！！！

2、测试报告的结构

说完了测试报告应该有哪些内容，那么就该说说这些内容应该如何排列组合了

2.1 首先呈现出你的结论

很多领导基本就只看这一点了，直接给出当前软件结论，如果软件质量高，没啥问题，他们就根本不会接着往下看了，这里其实有点像议论文的总分结构，先总述，后分开详述

2.2 当前遗留问题&排期

我前面说过了，如果这里没有遗留问题，一定是你的问题，而不是系统没有任何问题！任何系统都一定会存在各种各样的bug，大到内存泄漏，小到token提示信息缺失，如果没有遗留问题，说明你的测试工作还不到位，加油再测吧~

1）当前遗留严重问题

原则上有严重问题其实是不能发版的，但是如果不影响用户使用或者有应对措施就可以

• 比如CSDN客户端会crash，但是前提是需要连续刷24h，这样的客户场景一般难以遇到；
• 比如CSDN在多后台情况下打开就闪退，那么可以弹窗提示客户手动清理后台后再次尝试打开；

所有的严重问题必须在下一个版本完成迭代！！！

2）剩余遗留问题给出排期

那么剩下的就是一些普通问题或者提示性问题，虽然不严重，但它是问题就得解决，必须得给出排期，并且精确到责任人，比如这么几类情况

• 这个问题可能对用户影响更大，下个版本必须解；@前端工程师-王德发
• 这个问题有点难解，第二个版本再排期；@后端工程师-侯丽谢
• 这个问题现在连头绪都没有，长期跟踪；@测试开发工程师-二大爷

2.3 软件版本&算法/组件版本

这里一定要写清楚所有的软件版本，方便以后问题的迭代和回溯（甩锅），比如像下面这样

• 当前软件版本号V1.2.3
• 推荐算法模型为recommend_20220407_1305_alpha
• 当前软件MD5值为23gk2hf2v3uf2y3g23guy
• 软件包升级下载链接为https:test0407/download/test.apk
• 以此类推……

2.4 全业务回归情况

这里要写出系统测试情况，做了什么测试，覆盖了多少轮，一个是体现你的工作（摸鱼）情况，另一个反馈完整的软件质量，比如：

• 功能测试：ALL：100，PASS：96，FAIL：4，BLOCK：0，通过率96%
• 性能测试：ALL：100，PASS：81，FAIL：9，BLOCK：10，通过率90%（BLOCK不能算在已执行里面，这里是81/90）
• 以此类推……

2.5 各类专项进展&竞品分析

还是上面说过的其他团队的进展，或者你这产品的卖点，做一个专项，要有评测和竞品分析

虽然这两项往往都是合在一起的，但是这里我分开举例吧，比如自动编辑博文专项：

• 对于百字文章，成功率高达100%，对于错别字的识别，成功率高达99.86%；
• 对于千字文章，成功率高达97.03%，对于错别字的识别，成功率高达96.28%；
• 对于万字文章，成功率不低于80%，对于错别字的识别，成功率不低于75%；

再比如发帖耗时的竞品分析：

• 发帖耗时这一方面，在各量级的文章下都优于友商不知网：
• 优势是发帖耗时更低，只需要183ms，速度领先35.76%；
• 劣势是弱网下发帖的成功率太低，仅27.30%，同样网络下低于不知网的49.72%；

2.6 客户声音

内测也好，共创也好，都是需要听到客户的声音，这里建议写上全部的客户问题，已解决的用横线划掉，但是要保留，不要直接删除，来保留你为客户服务的诚心（鸡贼）

• 1、【严重】客户端打开时崩溃，A化工厂反馈
• 2、【一般】弱网下没有任何提示，一直转圈，B餐饮企业反馈
• 3、【提示】编辑完成后没有提示，实际成功发帖，C皮革厂反馈
• 以此类推……

3、亿点点小技巧

其实你们也发现了，我这文章里全是字，你们也不想看，所以这里有一些小技巧，能画📈的就画图表，问题清单或者问题描述也可以用xmind的形式绘制出来，该复杂的地方就复杂，该简单的时候就简单，详略得当，我就随便举两个🌰吧，毕竟我也不是学美术（前端）的

【例1】自动编辑博文专项

• 对于百字文章，成功率高达100%，对于错别字的识别，成功率高达99.86%；
• 对于千字文章，成功率高达97.03%，对于错别字的识别，成功率高达96.28%；
• 对于万字文章，成功率不低于80%，对于错别字的识别，成功率不低于75%；

【例2】一键编辑的竞品分析

• 在一键编辑成功率这一方面，整体的成功率较高，符合预期；在低量级的文章下优于友商全知网，而且随着文章量级增加，成功率的变化比较平稳
• 优势是2000字以下的文章，不知网的成功率要明显优于全知网；
• 劣势是2000字以上的文章，不知网的成功率略逊于全知网，且耗时更长，建议长文本分批量编辑后合并；

总结

测试报告是你个人工作和软件质量的一个综合体现，不是你套用模板就能写出来的，所以我这里没有贴一个模板出来让你直接往上套。画虎画皮难画骨，光学个样子是不会明白为什么有人就那么善于写报告的，我也刚开始思索和总结，借着这次报告的机会，对项目也是一份完整的总结，进步犹如逆水行舟，与君共勉~