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

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

开发提测之后，就照着测试用例点点点，可能一天就走完用例了，开发代码写得真好，测试用例执行完毕都没有测出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