如何写出可靠的测试用例

前言

测试用例是测试的基础，无论是接口测试、功能测试、自动化测试，都依赖测试用例是否可靠。那么如果证明测试用例是可靠的呢？要考虑到到以下三点：覆盖度、有效性、执行效率。

image

1.覆盖度

书写用力之前要明确的一点事：测试点是不可穷举的。例如：一个输入框，如果没有限制输入数据类型，哪像罗列出所有的测试点，可能要包含数字、字符、字母、各个国家的文字；在字数限制内各种各样数据类型的组合；不同的浏览器、操作系统、输入法，等等。由此可见，我们是不可能为一个测试点编写大量的测试用例的，总有一些场景是想不到的，甚至是没有使用场景的。所以我们在追求高覆盖度的同时首先要明确我们覆盖的范围，在合理的范围内追求100%的测试覆盖度才是有意义的。

那么如何评估我们的测试覆盖度呢？根据个人过往经验，可以大致分为三个方向统计：1.功能点覆盖度，2.代码覆盖度，3.缺陷逃逸率。

• 功能点覆盖度
  对于黑盒测试来说我们拿到需求之后最先开始的就是对需求内功能点的拆解，这个过程应该会根据产品文档中描述的业务流程梳理出各个分支流程的测试点。但整个过程主要依赖与个人经验与对业务的了解程度，而且没有很好的评估工具，及时安排了用例评审的流程也并不能保证测试用例的覆盖度能够达到100%,不过也正因为没有任何工具也可以保证测试用例的100%覆盖，才体现出了测试工程师的价值，我们做的就是利用自己的经验和对业务的熟悉产出高质量、高覆盖度的用例。以下仅凭个人经验罗列一些测试点拆解方向：

  
  
  测试点剖析.png

• 代码覆盖度
  代码覆盖度的分为：语句覆盖，判定覆盖，条件覆盖，路径覆盖。不同的语言都有自己的代码测试覆盖度度量工具，例如 Java有 Jacoco，JS有 JsCover，Python有 Coverage.py，但这些度量工具一般只适用于白盒测试，尤其是单元测试，测试同学可能很难主动去推动。而且这些度量工具的实现原理大多也只是对打码进行插桩，检测是不是每行代码都被执行到了。如果有代码没有被执行到，那可能是本身逻辑有问题或者有冗余、无用的代码，研发需要进行修改。但这依然需要依赖人工输入足够全面的case才行，但让这个人可以是测试也可以是研发。

  
  
  代码覆盖度度量流程.png
• 缺陷逃逸率
  缺陷逃逸率不是上线前的度量手段，而是上线后统计未被测出的缺陷与测试过程中提出的缺陷之比。虽然缺陷逃逸率并不能提升我们的交付质量，但也并非无用，它能从回顾的角度统计出测试过程中被忽略的测试点，通过分析这些被漏测的点可以增加我们的经验，保证下次不再遗漏类似的场景，是个亡羊补牢的动作。

2.有效性

测试的有效性是指在高覆盖度的前提下，精简我们的测试用例数量，去除掉一些无用的case。例如一个输入框，要求只能输入数字，那我们需要把所有数字都试一遍嘛？当然不需要，我们只需要挑选一些比较有代表性的case就可以了，例如0，1，-1，最大长度等。要做到提高有效性必须要先做到测试左移，了解项目整体的业务流程和项目代码的实现方案，借此找到关键性的验证点，尽量做到每一条case都在验证关键、易错功能。如果这么说比较模糊的话，可以简单的将测试用例与过程缺陷关联起来，如果我们执行了一条测试用例但没有发现缺陷，那么我们就认为这条用例是“无效”的，可以把它和其他case合成一条甚至删除掉。
永远记住一点：测试用例的数量并不能说明一个测试工程师的水平，测试用例也不应该是描述需求文档中对应功能的执行过程。一个优秀的测试工程师应该去想办法构造“异常”的场景，拥有足够的深度和广度才能发现程序中的问题，甚至是业务本身的设计缺陷，用测试来带动整个项目的交付节奏。

3.执行效率

提升执行效率其实和测试用例本身关系没有太大的直接关系，当我们把覆盖度和有效性都做到很好的时候，我们才应该考虑执行效率的问题，也就是我们常说的工程效能提升，最常见的方案就是自动化，无论是UI自动化还是接口自动化其实都是在提升我们的执行效率，解放双手，这里就不多赘述了，大家想了解可以自行百度。另一方面可以加强开发自测环节的质量，结合代码覆盖度度量工具统计核心流程代码可用性。
说到这里就不得不说一句，好多人说自动化做的好了是不是测试就失业了？其实不是的，从上面两点我们也能知道，测试真正的价值是输出全面且有效的测试用例，这个过程是不可能完全被自动化替代的，这时候可能有人会说，我们有AI测试、精准化测试等等，但这些所谓的智能也是建立在庞大的测试数据基础之上的。换句话说被替代的是那些写无用case的测试工程师，这也是为什么我们要学习怎么样写出的质量更高的测试用例的原因。