0


如何编写一份完整的软件测试报告?(进阶版)

背景

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

一、什么是测试报告?

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

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

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

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

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

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

这一点很重要!!!

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

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

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

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

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

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

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

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字以上的文章,不知网的成功率略逊于全知网,且耗时更长,建议长文本分批量编辑后合并;

总结

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


本文转载自: https://blog.csdn.net/ckckjsws/article/details/123994907
版权归原作者 柯有Q 所有, 如有侵权,请联系我们删除。

“如何编写一份完整的软件测试报告?(进阶版)”的评论:

还没有评论