基于用户登录测试用例设计产生一点对用例设计的理解

为个人博客项目的用户登录设计测试用例的过程中，让我发觉用例是越写越多，更多的用例覆盖率会越高，但是也慢慢发现这可能是一个没有穷尽的测试，同时测试的周期或长。衡量下来什么才算是好的测试用例？
特此贴上用例设计的链接

什么才算好的测试用例

通常，第一反应可能会是“发现了软件缺陷的测试用例就是好的用例”，那“如果说测试用例发现了缺陷就是好用例，那么在该缺陷被修复后，同样的用例难道就不是好用例了吗？”。

可能我们还会说“发现软件缺陷可能性大的测试用例就是好用例”，这话还是蛮有道理的，“又该用什么方法来量化测试用例发现缺陷的可能性？”。

事实上又有多少 BUG 真的是测试用例跑出来的呢？

我想关于一个好的测试用例那一定是一个完备的集合，能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。

好比“池塘捕鱼”的例子：

如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕渔网。“好的”测试用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能把鱼给捞上来。

而如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，渔网的好坏与池塘中是否有鱼是完全无关的。

好的测试用例常具有哪些特征

• 整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
• 等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
• 等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。

常用设计测试用例的方法

1. 等价类划分法

等价类中任意一个输入数据对于揭露程序中潜在错误都具有同等效果。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。

具体的例子：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是 0~100 之间的整数，考试成绩及格的分数线是 60。

为了测试这个输入项，显然不可能用 0-100 的每一个数去测试。通过需求描述可以知道，输入 0-59之间的任意整数，以及输入 60-100 之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的。

那么这就可以在 0-59 和 60-100 之间各随机抽取一个整数来进行验证。这样的设计就构成了“有效等价类”。另外等价类划分方法的另一个关键点是要找出所有“无效等价类”。显然，如果输入的成绩是负数，或者是大于 100 的数等都构成了“无效等价类”。

在考虑了无效等价类后，最终设计的测试用例为：

有效等价类 1：0~59 之间的任意整数；
有效等价类 2：59~100 之间的任意整数；
无效等价类 1：小于 0 的负数；
无效等价类 2：大于 100 的整数；
无效等价类 3：0~100 之间的任何浮点数；
无效等价类 4：其他任意非数字字符。

2. 边界值分析法

边界值分析是对等价类划分的补充，从一些实践也发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。

我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101。

3. 错误推测法

是基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握、个人的能力。

错误推测法和“探索式测试方法”的基本思想和理念是不谋而合的，在敏捷开发模式下的投入产出比很高。但是，这个方法的缺点也显而易见，那就是难以系统化，比较依赖个人能力。

比如，Web 界面的 GUI 功能测试，需要考虑浏览器在有缓存和没有缓存下的表现；Web Service 的 API 测试，需要考虑被测 API 所依赖的第三方 API 出错下的处理逻辑；对于代码级的单元测试，需要考虑被测函数的输入参数为空情况下的内部处理逻辑等等。由此可见，这些测试用例的设计都是基于曾经遇到的问题而进行的错误推测，很大程度上取决于个人能力。

在具体实践中，为了降低对个人能力的依赖，最好去建立常见缺陷知识库，在测试设计的过程中，会使用缺陷知识库作为检查点列表（checklist），去帮助优化补充测试用例的设计。可以以该缺陷知识库作为数据驱动测试的输入来自动生成部分的测试数据。也可以建立一个简单的 wiki 页面，可以在完成测试用例的最初设计后对应做一次自检。

如何设计出好的测试用例

在真实的工程实践中，不同的软件项目在研发生命周期的各个阶段都会有不同的测试类型。 比如，传统软件的开发阶段通常会有单元测试，软件模块集成阶段会有代码级集成测试，打包部署后会有面向终端用户的 GUI 测试；再比如，电商网站的测试会分为服务器端基于 API 的测试、中间件测试、前端 GUI 测试等。

对于每一种不同的测试类型，设计出“好的”测试用例的关注点和方法论可能会有很大的差异， 有些可能采用黑盒方法，有些可能采用白盒方法，有些还会采用灰盒方法（比如，微服务架构中的测试），所以很难有一套放之四海而皆准的套路。

以常见面向终端用户的 GUI 测试为例，如何才能设计一个“好的”测试用例

面向终端用户的 GUI 测试，最核心的测试点就是验证软件对需求的满足程度，要对被测软件的需求有深入的理解。最好在需求分析和设计阶段就开始介入，这是掌握软件的原始业务需求的最好时机。

理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确、从终端用户使用场景考虑的端到端（End-2-End）的测试用例集。这个阶段的测试用例设计，主要目的是验证各个业务需求是否被满足，主要采用基于黑盒的测试设计方法。

首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。

图中的业务需求到软件功能需求、软件功能需求到测试需求，以及测试需求到测试用例的映射关系，在非互联网软件企业的实践中，通常会使用需求追踪管理工具（比如 ALM、DOORS、JIRA、TestLink 等）来管理，并以此来衡量测试用例对业务需求、软件功能需求的覆盖率。

而具体到测试用例本身的设计，有两个关键点需要注意

• 从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。 比如，如果没有识别出用户登录功能的安全性测试需求，那么后续设计的测试用例就完全不会涉及安全性，最终造成重要测试漏洞。

• 对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。 这里需要注意的是，要综合运用这三种方法，并针对每个测试需求点的具体情况，进行灵活选择。

以 “用户登录” 的功能性测试需求为例，首先应该对“用户名”和“密码”这两个输入项分别进行等价类划分，列出对应的有效等价类和无效等价类，对于无效等价类的识别可以采用错误猜测法（比如，用户名包含特殊字符等），然后基于两者可能的组合，设计出第一批测试用例。

等价类划分完后，需要补充“用户名”和“密码”这两个输入项的边界值的测试用例，比如用户名为空（NULL）、用户名长度刚刚大于允许长度等。

用例设计的一些其他经验

• 理解被测试软件的架构，才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。切忌不能把整个被测系统看作一个大黑盒，需要对内部的架构有清楚的认识，比如数据库连接方式、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等等。

• 理解被测软件的设计与实现细节，理解软件内部的处理逻辑。
  单单根据测试需求点设计的用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到的部分就很可能出现缺陷遗漏。在具体实践中，可以通过代码覆盖率指标找出可能的测试遗漏点。不要以开发代码的实现为依据设计测试用例。因为开发代码实现的错误会导致测试用例也出错，所以应该根据原始需求设计测试用例。

• 需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。 如果直接把需求一段段的copy下来就成用例是不行的。写用例重要的是对需求的分解和补充。能够加上自己的经验以及对产品的理解，覆盖各种显性和隐性。功能和非功能的需求。
  即使是黑盒测试，在测试过程中，与需求确认业务规则，与开发了解代码逻辑，业务规则是准则，代码逻辑是参考，切忌与开发人员确认业务规则

可以分以下几个阶段写

1. 一般基础阶段，软件实现了什么功能，测试用例一般是围绕功能或者需求来
2. 边界值，异常值阶段。测试用例围绕在什么条件，不会怎么样？边界值之类，异常之类的测试用例。还有一些场景组合测试用例
3. 压力测试阶段，如果以上两类测试用例都通过了，那么考虑压力测试用例。比如说长期运行，高频运行等等。这三类测试用例都通过了，一般软件的质量还是有一定的保证