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

　　开发提测之后，就照着测试用例点点点，可能一天就走完用例了，开发代码写得真好，测试用例执行完毕都没有测出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 进行测试用例编写，也是一种不错的保存测试用例的方案。

作者：程序员臻叔   

来源：http://www.51testing.com/html/97/n-4477397.html