你好，我是测试开发工程师——臻叔（一）

您好，我是测试开发工程师——甄叔。

欢迎与我交流测试领域相关问题（测试介绍、技术、python交流均可）

很多人不知道写测试用例有什么用，但就像一个工具人，每次测试之前，根据需求文档，复制测试用例，仿佛穿越到现场。

在开发和测试之后，一点一点地遵循测试用例。也许测试用例会在一天内完成。开发代码写的真好测试教案怎么写，测试用例执行后没有发现bug。那么名气就是：测试结束，达到在线标准。.

测试之后，测试用例就毫无价值了。它们像垃圾一样存放在任何地方，最后都没有踪迹。

在他们眼里，做测试和在东莞的工厂打工没什么两样。

不管怎样，写了很长时间的测试用例之后，你可以成为一个人人都喜欢的熟练工。我想，到了35岁，我会下岗，回到家乡享受繁荣富足。

最后上线之后，bug很多，但是写测试用例是浪费时间，没用。

目录清楚了为什么要写测试用例？传统的测试用例编写规范？甄大叔原创的测试用例写法？如果我没有时间编写测试用例怎么办？是否需要完整的测试用例？测试用例应该如何保存？一、为什么要写测试用例？

换句话说，写测试用例有什么用？

敲黑板！测试用例主要有以下六个功能：

方便明确测试思路，避免漏测。有利于测试工作量的评估。提前准备测试数据很方便。相当于工作日志。方便控制测试工作的进度，方便上线前的回归测试。方便组织测试工作，提高测试效率，降低测试交接成本

所以，写测试用例很有必要！

那些没有写过测试用例，或者说写测试用例没用的，没有掌握测试用例的使用姿势。

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

一般在编写测试用例时，人们习惯使用“Excel（表格）”或“Xmind（思维脑图）”。

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

比如我们要测试一个“常规搜索关键字输入”功能，我们用Excel来表达，类似下图：

如果我们使用 Xmind 来编写测试用例，它可能会显示为：

可以看到用Excel和Xmind来设计测试用例，粒度和使用场景都不一样。

“在一些功能比较简单的场景一、，步骤简单，输入和期望比较明确，可以用Excel的风格写测试用例。”

“在一些功能比较复杂，依赖测试人员主观能动性的场景下，可以使用Xmind风格来编写测试用例。”

三、甄叔原创测试用例编写模板

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

如果用Excel设计测试用例，写起来会比Xmind多，编辑、维护、可读性等都比较差。

项目紧急，用Excel写测试用例显然不合理。

“所以用Xmind写测试用例在互联网测试圈也很流行。”

“但是，在一些回归验证场景中，可以使用Excel来编写测试用例。我们习惯于使用回归用例作为在线CheckList，一一验证测试教案怎么写，防止遗漏。”

实事求是

那么，在我们日常的测试中，“用Xmind写测试用例要注意什么”呢？

“不需要复制产品需求文档！” 这样做的缺点是做了很多重复的工作，而且思维很容易被产品思维框住，有些不合理的地方可能很难找。“测试用例必须是可执行的！” “你写的测试用例越多越好。” 写太多，可读性很差，无形中会给自己增加心理压力，按照28原则，80%的bug出现在20%的主进程中。可以做异常测试吗？当然要做！但不要以异常测试为重点。重点应该放在用户的角度，并优先考虑核心主流程。“测试用例应该反映测试目标。” 请注意，这不仅仅是一种期望，而是一个测试目标。需要了解测试这个用例的目的，以及是否实现了产品的功能和意图。测试用例设计最好遵循金字塔原则，“尽量详尽，完全独立，避免过多的重复用例”。“测试用例必须分级”和优先级。在根据测试用例进行一一测试时，还可以通过“在测试用例上做一些注释”来标记测试情况。测试用例不仅仅是用例。对于一些结构化的“测试数据也可以反映在测试用例中”，方便后续的回归验证。“测试用例需要说明用例的基本信息”，也可以记录一些文档的链接（比如需求文档，技术文件）等。“使用尽可能少的用例来覆盖大部分测试场景。”

因此，新式测试用例不应称为测试用例，而应更恰当地称为“测试日志”。

下面，我将展示我如何“如何构思和设计测试用例”，并逐步向您展示。是时候展示真正的技术了！

第一步是展示测试用例的基本信息。

基本信息包括：“涉众、测试范围、用例描述、相关文档”等信息。

有了这些信息，您就可以将测试用例作为切入点，提高查找相关文档的效率。

第二步是开始编写测试用例。

这一块可以因人而异，遵循几个原则：“不要复制需求文档，设计的用例是可执行的，用例是分级的，尽可能详尽，完全独立，避免太多重复用例。”

在设计用例时，最好从测试目标开始，然后向下扩展。

例如：

第三步是用例审查。

用例审查是召开会议，召集开发、产品和设计，审查书面测试用例。这个环节需要在开发和测试之前进行。

主要的意思：

第四步是执行用例。

在执行用例时，进行标记，以便于排查和处理Bug，然后有针对性地进行后续验证，而不是从头开始重复用例，以提高回归验证的效率。

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

“测试完成并达到在线标准后，我们​​需要准备一个CheckList，以便在上线当天使用。”

CheckList强调循序渐进，适合用Excel表达。

上网无小事，需谨慎！

那么，你知道如何编写测试用例吗？

下面是聊天时间。甄叔想和大家聊三个很现实的问题：四、 没时间写测试用例怎么办？

在一家互联网公司，项目进度很紧，每三天就会推出一个新功能。这是常态。

在这种情况下，一些旧的测试驱动程序放弃编写测试用例，直接开始测试。其实这是一个非常不好的习惯。

写测试用例不是面对面的项目，没必要追求极致，像满分作文一样写。

“其实，编写测试用例的主要功能就是帮助测试人员提高工作效率。”

一方面，通过编写测试用例，可以更加熟悉需求，理清思路；

另一方面，测试用例可以更好地指导你进行测试工作，尤其是在你做完测试标记之后，有必要进行Bug的后续检查。

不要写测试用例，也不应该以时间紧张为借口。

“我们应该根据需求的重要性和难度来判断是否要编写测试用例。”

如果是紧急且重要的需求，则必须编写测试用例；如果只是一句话的要求和一些文案更改，那么您不需要编写测试用例。

他们都是成年人，所以他们应该有判断力。

五、是否需要完整的测试用例？

进新公司前，导师总是让新员工写一个完整的测试用例，或者扔一个完整的测试用例给新员工看，说是为了帮助新员工更好的熟悉系统.

但是工作了很长时间后，我发现这对新员工的培训没有任何影响。相反，它让新员工感到无聊。

写一个完整的测试用例是没有意义的，就像你让学生背字典一样，它是没有意义的。

“那如何让新员工更好地融入工作，快速上手呢？”

最好的办法是心心相印，你“把你所有的文档分门别类，画更多的系统架构图、流程图、新员工培训手册等，交给新员工。” 我认为这比丢失完整的测试用例要好。对于新手测试人员来说更有用。

六、如何保存测试用例？

当然，它不仅仅是扔掉，仍然在垃圾桶里。

如果公司有条件，可以有用例平台，将项目-需求-测试用例关联起来，以后遇到的任何bug都可以跟进，方便总结和回溯。

如果公司没有这么好的条件，可以用gitlab做维护和版本控制。

字节跳动推出了飞书。里面的飞书文件也很香。自带文档管理功能，有飞书脑图，可以代替Xmind编写测试用例。它也是保存测试用例的一个很好的解决方案。

❤既然你们都看到了，请帮我一个忙：

1、 点赞，让更多的朋友看到​​；

2、关注我，免费解答新手测试问题。