很多人不知道写测试用例有什么用，而仅仅是像工具人一样，在每次提测之前，把测试用例照着需求文档抄一遍，仿佛像是走个过场。
开发提测之后，就照着测试用例点点点，可能一天就走完用例了，开发代码写得真好，测试用例执行完毕都没有测出bug，然后美其名曰：测试完了，达到上线标准。
测完之后，测试用例毫无价值，像随手仍垃圾一样，随地保存，终于无迹可寻。
在他们眼里，从事测试工作，和去东莞进厂打工没什么区别。
反正测试用例写久了，都能成为人人爱戴的熟练工，想着到了35岁，光荣下岗，回老家享受荣华富贵。
最后上线之后，bug一大堆，反而还怪写测试用例浪费时间，且没有用。
或者说，写测试用例到底有什么用？
敲黑板！测试用例主要有以下六大作用：
所以，写测试用例是很有必要的！
那些没有写测试用例、或者说写测试用例没有用的，都是没有掌握测试用例的使用姿势。
一般写测试用例，大家习惯于用 「Excel（表格）」 或者 「Xmind（思维脑图）」。
一般用 Excel 要表达的元素有：用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、预期结果。
比如说，我们要测试一个“常规搜索关键词输入”的功能，我们用 Excel 来表达，类似下图所示：
假如我们用 Xmind 来编写测试用例，大概呈现成：
可以看到用 Excel 和 Xmind 去设计测试用例，粒度以及使用场景都不太相同。
「在一些功能比较单一、步骤简单、输入和预期比较明确的场景，可以采用 Excel 的风格去编写测试用例。」
「在一些功能比较繁杂、依赖测试人员的主观能动性的场景，可以采用 Xmind 的风格去编写测试用例。」
现在在互联网公司，产品迭代很快，功能也比较复杂。
如果用 Excel 去设计测试用例的话，会花费比 Xmind 更多的时间去编写，而且编辑维护、可读性等等，都比较差。
项目这么紧急，用 Excel 去写测试用例，显然是不合理的。
「所以用 Xmind 的方式去编写测试用例，在互联网测试圈子里面也是深得人心。」
「但是，在一些回归验证的场景，是可以用 Excel 去写测试用例的，我们习惯把回归用例当作上线 CheckList，逐条去验证，防止遗漏。」
那么，我们日常测试，「用 Xmind 编写测试用例时，需要注意些什么呢」？
所以，新式的测试用例，感觉不该叫测试用例，应该叫 「“测试日志”」 更加合适。
下面，我将把我是「如何构思和设计测试用例」，一步一步给大家呈现出来，是时候展示真正的技术了！
基本信息包含：「干系人、测试范围、用例说明、关联文档」等等信息。
有了这些信息，就可以把测试用例当成一个入口，提升查找相关文档的效率。
这一块可以因人而异去设计，遵循几个原则：「不要照抄需求文档、设计的用例都是可执行的、用例做到分级、尽量穷尽，完全独立，避免太多重复的用例」。
设计用例的时候，最好可以从测试目标出发，再进行向下延展。
举个例子：
用例评审就是拉个会，喊上开发、产品和设计，针对编写好的测试用例进行评审。这个环节需要在开发提测之前进行。
主要目的：
一边执行用例，一边做好标记，方便查处bug之后，后续有针对性的去验证，而不是又从头把用例再走一遍，提升回归验证的效率。
另外，对于测试过程中，用到的一些测试数据，也可以直接在用例上标注出来，提高后续回归测试的效率。
「当测试完毕，达到上线标准之后，我们需要准备一份 CheckList，在上线当天使用」。
CheckList 比较强调步骤性，所以适合用 Excel 去表达。
上线无小事，一定得谨慎！
所以，知道怎么写测试用例了么？
身处互联网公司，项目时间紧，三天两头就要上线一个新功能，这是常态。
有的测试老司机在这种情况下，就放弃写测试用例，直接上手就测，其实这是很不好的习惯。
写测试用例不是面子工程，没有必要追求极致，写得像满分作文一样。
「其实写测试用例最主要的作用，就是帮助测试人员提升工作效率」，
一方面，通过写测试用例可以对需求更加熟悉，脑子理顺；
另一方面，测试用例可以更好的指导你进行测试工作，尤其是你做好测试标记之后，对于后续验bug很有必要。
不写测试用例，不应该拿时间紧作为借口。
「我们应该根据需求的重要程度、难易程度来评定要不要写测试用例。」
如果是一些紧急且重要的需求，那肯定要写测试用例；如果只是一句话的需求、几个文案的改动，那这种不写测试用例也罢。
都是成年人了，应该要有判断力。
以前入职一家新公司，导师总会要求新员工去写一份全量的测试用例，或者说丢一份很全的用例给新员工去阅读，说是帮助新员工更好的熟悉系统。
但是工作久了，我发现这对于新员工的培养，并不能起到什么效果，反而让新员工产生厌烦的心理。
写一份全量的测试用例是没有意义的，就像你让一个小学生去背字典一样，毫无意义。
「那怎样让新员工更好的融入到工作当中，快速上手呢？」
最好的办法就是将心比心，你「把自己所有的文档分门别类，多画点系统架构图、流程图，新员工培养手册等等，把这些给到新员工」，我觉得是比丢一个全量测试用例给一个测试新手更有用。
当然不是随手一丢，仍垃圾桶。
如果公司有条件的话，可以有个用例平台，把 项目-需求-测试用例 进行关联，后续遇到bug，都可以有迹可循，方便总结和回溯。
如果公司没有那么好的条件，可以用gitlab进行维护，进行版本控制。
字节跳动推出了飞书，里面的飞书文档也是特别香的，自带文档管理功能，而且还有飞书脑图可以替代 Xmind 进行测试用例编写，也是一种不错的保存测试用例的方案。
❤既然都看到这里啦，请你帮个忙：
1、点赞，让更多小伙伴看到；
2、关注我，免费解答新手测试的疑惑。
