很多人不知道写测试用例有什么用,而仅仅是像工具人一样,在每次提测之前,把测试用例照着需求文档抄一遍,仿佛像是走个过场。
开发提测之后,就照着测试用例点点点,可能一天就走完用例了,开发代码写得真好,测试用例执行完毕都没有测出bug,然后美其名曰:测试完了,达到上线标准。
测完之后,测试用例毫无价值,像随手仍垃圾一样,随地保存,终于无迹可寻。
在他们眼里,从事测试工作,和去东莞进厂打工没什么区别。
反正测试用例写久了,都能成为人人爱戴的熟练工,想着到了35岁,光荣下岗,回老家享受荣华富贵。
最后上线之后,bug一大堆,反而还怪写测试用例浪费时间,且没有用。
目录
- 明确为什么要写测试用例?
- 传统的测试用例编写规范?
- 臻叔独创的测试用例编写大法?
- 没时间写测试用例怎么办?
- 全量的测试用例是否有必要?
- 测试用例应当如何保存?
一、为什么要写测试用例?
或者说,写测试用例到底有什么用?
敲黑板!测试用例主要有以下六大作用:
- 方便理清测试思路,避免漏测
- 有助于测试工作量的评估
- 便于提前准备测试数据
- 相当于工作日志,把控测试工作进度
- 方便进行上线前的回归测试
- 便于测试工作的组织,提高测试效率,降低测试交接成本
所以,写测试用例是很有必要的!
那些没有写测试用例、或者说写测试用例没有用的,都是没有掌握测试用例的使用姿势。
二、传统的测试用例编写规范
一般写测试用例,大家习惯于用 「Excel(表格)」 或者 「Xmind(思维脑图)」。
一般用 Excel 要表达的元素有:用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、预期结果。
比如说,我们要测试一个“常规搜索关键词输入”的功能,我们用 Excel 来表达,类似下图所示:
假如我们用 Xmind 来编写测试用例,大概呈现成:
可以看到用 Excel 和 Xmind 去设计测试用例,粒度以及使用场景都不太相同。
「在一些功能比较单一、步骤简单、输入和预期比较明确的场景,可以采用 Excel 的风格去编写测试用例。」
「在一些功能比较繁杂、依赖测试人员的主观能动性的场景,可以采用 Xmind 的风格去编写测试用例。」
三、测试用例编写模版
现在在互联网公司,产品迭代很快,功能也比较复杂。
如果用 Excel 去设计测试用例的话,会花费比 Xmind 更多的时间去编写,而且编辑维护、可读性等等,都比较差。
项目这么紧急,用 Excel 去写测试用例,显然是不合理的。
「所以用 Xmind 的方式去编写测试用例,在互联网测试圈子里面也是深得人心。」
「但是,在一些回归验证的场景,是可以用 Excel 去写测试用例的,我们习惯把回归用例当作上线 CheckList,逐条去验证,防止遗漏。」
小细节
- 日常测试工作,用 Xmind 去编写测试用例。
- 上线环节,用 Excel 去编写回归用例,确保万无一失。
那么,我们日常测试,「用 Xmind 编写测试用例时,需要注意些什么呢」?
- 「照抄产品需求文档没有必要的!」 这么做的坏处是:做了很多重复工作,而且思维容易被产品思维框住,有些不合理的地方或许难以发现。
- 「测试用例一定是可执行的!」
- 「测试用例并不是写得越多越好」。写得太多,可读性很差,也会无形之间给自己增加心理压力,而且根据二八原则,80%的bug都出现在20%的主流程上面。那异常测试做不做?当然要做!但是千万不要把异常测试作为重点,重点应该是站在用户的角度,优先保证核心主流程。
- 「测试用例要体现测试目标」,注意,这里不仅仅是预期,而是测试目标,要明白测试这条用例,到底目的是啥,产品功能和意图是否已经实现。
- 测试用例设计最好遵循金字塔原理,「尽量穷尽,完全独立,避免太多重复的用例」。
- 「测试用例千万要做好分等级」,优先重点。
- 根据测试用例逐条进行测试时,还可以在「测试用例上做一些标注」,标记测试情况。
- 测试用例不仅仅是用例,对于一些构造的「测试数据也可以在测试用例上体现出来」,方便后续回归验证。
- 「测试用例需要注明用例基本信息」,还可以记录一些文档的链接(比如需求文档、技术文档)等等。
- 「用尽可能少的用例,覆盖绝大部分的测试场景」。
所以,新式的测试用例,感觉不该叫测试用例,应该叫 「“测试日志”」 更加合适。
下面,我将把我是「如何构思和设计测试用例」,一步一步给大家呈现出来,是时候展示真正的技术了!
第一步,把测试用例的基本信息表示出来。
基本信息包含:「干系人、测试范围、用例说明、关联文档」等等信息。
有了这些信息,就可以把测试用例当成一个入口,提升查找相关文档的效率。
第二步,开始写测试用例。
这一块可以因人而异去设计,遵循几个原则:「不要照抄需求文档、设计的用例都是可执行的、用例做到分级、尽量穷尽,完全独立,避免太多重复的用例」。
设计用例的时候,最好可以从测试目标出发,再进行向下延展。
举个例子:
第三步,用例评审。
用例评审就是拉个会,喊上开发、产品和设计,针对编写好的测试用例进行评审。这个环节需要在开发提测之前进行。
主要目的:
- 沟通测试用例有没有遗漏的地方,评估当测试用例执行完,没有bug的情况下,是否可达到上线标准。
- 和开发约定好,在开发自测阶段,开发需要保证冒烟测试用例能够通过。冒烟用例通过基本上可以作为提测标准。
- 和开发、产品对接好上线前的验收标准。
第四步,执行用例。
一边执行用例,一边做好标记,方便查处bug之后,后续有针对性的去验证,而不是又从头把用例再走一遍,提升回归验证的效率。
另外,对于测试过程中,用到的一些测试数据,也可以直接在用例上标注出来,提高后续回归测试的效率。
「当测试完毕,达到上线标准之后,我们需要准备一份 CheckList,在上线当天使用」。
CheckList 比较强调步骤性,所以适合用 Excel 去表达。
上线无小事,一定得谨慎!
所以,知道怎么写测试用例了么?
下面是闲聊时间,我想和大家一起聊聊三个很现实的问题:
- 「没时间写测试用例怎么办?」
- 「全量的测试用例是否有必要?」
- 「测试用例应当如何保存?」
四、没时间写测试用例怎么办?
身处互联网公司,项目时间紧,三天两头就要上线一个新功能,这是常态。
有的测试老司机在这种情况下,就放弃写测试用例,直接上手就测,其实这是很不好的习惯。
写测试用例不是面子工程,没有必要追求极致,写得像满分作文一样。
「其实写测试用例最主要的作用,就是帮助测试人员提升工作效率」,
一方面,通过写测试用例可以对需求更加熟悉,脑子理顺;
另一方面,测试用例可以更好的指导你进行测试工作,尤其是你做好测试标记之后,对于后续验bug很有必要。
不写测试用例,不应该拿时间紧作为借口。
「我们应该根据需求的重要程度、难易程度来评定要不要写测试用例。」
如果是一些紧急且重要的需求,那肯定要写测试用例;如果只是一句话的需求、几个文案的改动,那这种不写测试用例也罢。
都是成年人了,应该要有判断力。
五、全量测试用例是否有必要?
以前入职一家新公司,导师总会要求新员工去写一份全量的测试用例,或者说丢一份很全的用例给新员工去阅读,说是帮助新员工更好的熟悉系统。
但是工作久了,我发现这对于新员工的培养,并不能起到什么效果,反而让新员工产生厌烦的心理。
写一份全量的测试用例是没有意义的,就像你让一个小学生去背字典一样,毫无意义。
「那怎样让新员工更好的融入到工作当中,快速上手呢?」
最好的办法就是将心比心,你「把自己所有的文档分门别类,多画点系统架构图、流程图,新员工培养手册等等,把这些给到新员工」,我觉得是比丢一个全量测试用例给一个测试新手更有用。
六、测试用例应当如何保存?
当然不是随手一丢,仍垃圾桶。
如果公司有条件的话,可以有个用例平台,把 项目-需求-测试用例 进行关联,后续遇到bug,都可以有迹可循,方便总结和回溯。
如果公司没有那么好的条件,可以用gitlab进行维护,进行版本控制。
字节跳动推出了飞书,里面的飞书文档也是特别香的,自带文档管理功能,而且还有飞书脑图可以替代 Xmind 进行测试用例编写,也是一种不错的保存测试用例的方案。
最后,绵薄之力.
感谢每一个认真阅读我文章的人,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
资料获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,关注公众号:一个心态巨好的朋友 即可自行领取。文章来源:https://www.toymoban.com/news/detail-450945.html
文章来源地址https://www.toymoban.com/news/detail-450945.html
到了这里,关于测试工程师都是怎么写测试用例的?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!