测试工程师都是怎么写测试用例的?

很多人不知道写测试用例有什么用,而仅仅是像工具人一样,在每次提测之前,把测试用例照着需求文档抄一遍,仿佛像是走个过场。

开发提测之后,就照着测试用例点点点,可能一天就走完用例了,开发代码写得真好,测试用例执行完毕都没有测出bug,然后美其名曰:测试完了,达到上线标准。

测完之后,测试用例毫无价值,像随手仍垃圾一样,随地保存,终于无迹可寻。

在他们眼里,从事测试工作,和去东莞进厂打工没什么区别。

反正测试用例写久了,都能成为人人爱戴的熟练工,想着到了35岁,光荣下岗,回老家享受荣华富贵。

最后上线之后,bug一大堆,反而还怪写测试用例浪费时间,且没有用。

目录

  1. 明确为什么要写测试用例?
  2. 传统的测试用例编写规范?
  3. 臻叔独创的测试用例编写大法?
  4. 没时间写测试用例怎么办?
  5. 全量的测试用例是否有必要?
  6. 测试用例应当如何保存?

一、为什么要写测试用例?

或者说,写测试用例到底有什么用?

敲黑板!测试用例主要有以下六大作用:

  1. 方便理清测试思路,避免漏测
  2. 有助于测试工作量的评估
  3. 便于提前准备测试数据
  4. 相当于工作日志,把控测试工作进度
  5. 方便进行上线前的回归测试
  6. 便于测试工作的组织,提高测试效率,降低测试交接成本

所以,写测试用例是很有必要的!

那些没有写测试用例、或者说写测试用例没有用的,都是没有掌握测试用例的使用姿势。

二、传统的测试用例编写规范

一般写测试用例,大家习惯于用 「Excel(表格)」 或者 「Xmind(思维脑图)」

一般用 Excel 要表达的元素有:用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、预期结果。

比如说,我们要测试一个“常规搜索关键词输入”的功能,我们用 Excel 来表达,类似下图所示:

 

假如我们用 Xmind 来编写测试用例,大概呈现成:

 

 

可以看到用 Excel 和 Xmind 去设计测试用例,粒度以及使用场景都不太相同。

「在一些功能比较单一、步骤简单、输入和预期比较明确的场景,可以采用 Excel 的风格去编写测试用例。」

「在一些功能比较繁杂、依赖测试人员的主观能动性的场景,可以采用 Xmind 的风格去编写测试用例。」

三、测试用例编写模版

现在在互联网公司,产品迭代很快,功能也比较复杂。

如果用 Excel 去设计测试用例的话,会花费比 Xmind 更多的时间去编写,而且编辑维护、可读性等等,都比较差。

项目这么紧急,用 Excel 去写测试用例,显然是不合理的。

「所以用 Xmind 的方式去编写测试用例,在互联网测试圈子里面也是深得人心。」

「但是,在一些回归验证的场景,是可以用 Excel 去写测试用例的,我们习惯把回归用例当作上线 CheckList,逐条去验证,防止遗漏。」

小细节

  • 日常测试工作,用 Xmind 去编写测试用例。
  • 上线环节,用 Excel 去编写回归用例,确保万无一失。

那么,我们日常测试,「用 Xmind 编写测试用例时,需要注意些什么呢」

  1. 「照抄产品需求文档没有必要的!」 这么做的坏处是:做了很多重复工作,而且思维容易被产品思维框住,有些不合理的地方或许难以发现。
  2. 「测试用例一定是可执行的!」
  3. 「测试用例并不是写得越多越好」。写得太多,可读性很差,也会无形之间给自己增加心理压力,而且根据二八原则,80%的bug都出现在20%的主流程上面。那异常测试做不做?当然要做!但是千万不要把异常测试作为重点,重点应该是站在用户的角度,优先保证核心主流程。
  4. 「测试用例要体现测试目标」,注意,这里不仅仅是预期,而是测试目标,要明白测试这条用例,到底目的是啥,产品功能和意图是否已经实现。
  5. 测试用例设计最好遵循金字塔原理,「尽量穷尽,完全独立,避免太多重复的用例」
  6. 「测试用例千万要做好分等级」,优先重点。
  7. 根据测试用例逐条进行测试时,还可以在「测试用例上做一些标注」,标记测试情况。
  8. 测试用例不仅仅是用例,对于一些构造的「测试数据也可以在测试用例上体现出来」,方便后续回归验证。
  9. 「测试用例需要注明用例基本信息」,还可以记录一些文档的链接(比如需求文档、技术文档)等等。
  10. 「用尽可能少的用例,覆盖绝大部分的测试场景」

所以,新式的测试用例,感觉不该叫测试用例,应该叫 「“测试日志”」 更加合适。

下面,我将把我是「如何构思和设计测试用例」,一步一步给大家呈现出来,是时候展示真正的技术了!

第一步,把测试用例的基本信息表示出来。

基本信息包含:「干系人、测试范围、用例说明、关联文档」等等信息。

有了这些信息,就可以把测试用例当成一个入口,提升查找相关文档的效率。

 

 

第二步,开始写测试用例。

这一块可以因人而异去设计,遵循几个原则:「不要照抄需求文档、设计的用例都是可执行的、用例做到分级、尽量穷尽,完全独立,避免太多重复的用例」

设计用例的时候,最好可以从测试目标出发,再进行向下延展。

举个例子:

 

第三步,用例评审。

用例评审就是拉个会,喊上开发、产品和设计,针对编写好的测试用例进行评审。这个环节需要在开发提测之前进行。

主要目的:

  • 沟通测试用例有没有遗漏的地方,评估当测试用例执行完,没有bug的情况下,是否可达到上线标准。
  • 和开发约定好,在开发自测阶段,开发需要保证冒烟测试用例能够通过。冒烟用例通过基本上可以作为提测标准。
  • 和开发、产品对接好上线前的验收标准。

第四步,执行用例。

一边执行用例,一边做好标记,方便查处bug之后,后续有针对性的去验证,而不是又从头把用例再走一遍,提升回归验证的效率。

另外,对于测试过程中,用到的一些测试数据,也可以直接在用例上标注出来,提高后续回归测试的效率。

「当测试完毕,达到上线标准之后,我们需要准备一份 CheckList,在上线当天使用」

CheckList 比较强调步骤性,所以适合用 Excel 去表达。

 

 

 

 

上线无小事,一定得谨慎!

所以,知道怎么写测试用例了么?

下面是闲聊时间,我想和大家一起聊聊三个很现实的问题:
  • 「没时间写测试用例怎么办?」
  • 「全量的测试用例是否有必要?」
  • 「测试用例应当如何保存?」

四、没时间写测试用例怎么办?

身处互联网公司,项目时间紧,三天两头就要上线一个新功能,这是常态。

有的测试老司机在这种情况下,就放弃写测试用例,直接上手就测,其实这是很不好的习惯。

写测试用例不是面子工程,没有必要追求极致,写得像满分作文一样。

「其实写测试用例最主要的作用,就是帮助测试人员提升工作效率」

一方面,通过写测试用例可以对需求更加熟悉,脑子理顺;

另一方面,测试用例可以更好的指导你进行测试工作,尤其是你做好测试标记之后,对于后续验bug很有必要。

不写测试用例,不应该拿时间紧作为借口。

「我们应该根据需求的重要程度、难易程度来评定要不要写测试用例。」

如果是一些紧急且重要的需求,那肯定要写测试用例;如果只是一句话的需求、几个文案的改动,那这种不写测试用例也罢。

都是成年人了,应该要有判断力。

五、全量测试用例是否有必要?

以前入职一家新公司,导师总会要求新员工去写一份全量的测试用例,或者说丢一份很全的用例给新员工去阅读,说是帮助新员工更好的熟悉系统。

但是工作久了,我发现这对于新员工的培养,并不能起到什么效果,反而让新员工产生厌烦的心理。

写一份全量的测试用例是没有意义的,就像你让一个小学生去背字典一样,毫无意义。

「那怎样让新员工更好的融入到工作当中,快速上手呢?」

最好的办法就是将心比心,你「把自己所有的文档分门别类,多画点系统架构图、流程图,新员工培养手册等等,把这些给到新员工」,我觉得是比丢一个全量测试用例给一个测试新手更有用。

六、测试用例应当如何保存?

当然不是随手一丢,仍垃圾桶。

如果公司有条件的话,可以有个用例平台,把 项目-需求-测试用例 进行关联,后续遇到bug,都可以有迹可循,方便总结和回溯。

如果公司没有那么好的条件,可以用gitlab进行维护,进行版本控制。

字节跳动推出了飞书,里面的飞书文档也是特别香的,自带文档管理功能,而且还有飞书脑图可以替代 Xmind 进行测试用例编写,也是一种不错的保存测试用例的方案。

最后感谢每一个认真阅读我文章的人,作为一位过来人也是希望大家少走一些弯路,在这里我给大家分享一些自动化测试的学习资源,如果你用得到的话可以直接拿走,希望能给你前进的路上带来帮助。(包括Python编程、WEB自动化测试、app自动化测试、接口自动化测试、测试框架、持续集成、自动化测试开发、性能测试、安全测试、大厂面试真题、简历模板等等、当然还有一些测试基础、工具、app测试、接口测试、linux、mysql数据库等基础知识),相信能使你更好的进步!这些学习资料我都放在我的测试学习交流裙:1033482984 里面了,同时还有几千个行业大佬相互进行技术交流、经验分享,如果你也感兴趣,那么期待你的加入。

原文转载于:公众号:软件测试小dao

热门相关:斗神战帝   法医王妃不好当!   无限杀路   夫人,你马甲又掉了!   重生当学神,又又又考第一了!