软件测试笔记-怎么设计“好”用例

作为一个刚刚毕业还没正式入职的老做题家，应试教育最典型的产物之一。在不知道多少个雷雨交加的夜晚，我的母亲，金刚怒目，一手抓着我鲜红的成绩单，一手抓着已经被我屁股打的有点开裂的拖鞋，对着被压在身下的我慈祥的问道：“你多跟好学生玩能考成这个样子吗？你考这点分我该不该打你？”话音刚落，娇嫩的屁股又传来了一阵疼痛。哭喊之余，一个疑问在我虽然幼小但已经满是沧桑的心灵里种下了一颗种子：什么是好学生？

什么是好的测试用例？

我们设计测试用例，就像老师教育学生一样。老师想要教出来一个好学生，我们也希望设计出来好的设计用例。好学生的标准不仅仅是成绩，而是德智体美劳全面发展 ~~即使不少地方的老师家长依然不是很开明~~。

如果我们以能否发现缺陷来看待测试用例，就走软件测试中“唯成绩论”的牛角尖。好的用例应该像一个德智体美劳全面发展的学生一样，是一个完备的集合，能够覆盖所有等价类和各种边界值。

渔网的好坏，与池塘里有没有鱼无关。

好的测试用例的特点：

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

要设计出好的测试用例，需要使用哪些方法？

任何一本书上都有很多设计方法，但是“二八定律”在测试方面，依然能发挥作用：对于大多数的软件测试而言，设计好的测试用例，等价类划分、边界值分析和错误推测三个方法就够。

1.等价类划分法

可以帮我们找到等价的一类数据，我们可以用最少的代表性数据取得足够高的用例覆盖率。等价类划分要注意到“无效等价类”。

以考试成绩举例：

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

我们只需要6个测试用例，就可以覆盖全部的类型。

2.边界值分析法

这个方法是对等价类划分的补充，我们可以选取正好等于、刚刚大于或小于边界的值做测试数据。

依然以考试成绩举例（三个边界值加粗表示）：-1，0，1，59，60，61，99，100，101。

3.错误推测（important）

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

这是一个比较偏向经验的内容，比如从事网络安全的开发者，可能会习惯性地在输入框中输入攻击脚本；Web 界面的 GUI 功能测试，需要考虑浏览器在有缓存和没有缓存下的表现；Web Service 的 API 测试，需要考虑被测 API 所依赖的第三方 API 出错下的处理逻辑；对于代码级的单元测试，需要考虑被测函数的输入参数为空情况下的内部处理逻辑等等。设计者基于曾经遇到的问题进行错误推测，很依赖个人的开发经验。

但是能让我这个毫无企业开发经验的菜鸡安心的是，企业的事件中，为了防止我这种经验不足的菜鸡拖后腿，在测试设计的过程中，会用缺陷知识库作为checklist，帮助优化用例的设计。

如何设计“好”用例

我们知道了什么是好的用例，也知道了用什么样的方法设计好的用例。但是软件开发的过程中，项目迭代的周期类型、项目体量、不同的测试主题与阶段之间有很大的不同。而对于不同的测试类型，“好”用例的关注点和方法论可能也会有所改变。我们需要发挥主观能动性。

以最常见的GUI测试举例

软件是否满足需求是最核心的测试点。此时，测试工程师需要在需求分析和设计阶段就开始介入，这样才能理解和掌握原始业务需求。

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

==在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。==即：业务需求→功能需求→测试需求→测试用例。搬张图举个例子：

设计测试用例本身的两个关键点：

从需求出发，识别出所有的测试需求。关系到用例的测试覆盖率，如有疏忽，可能会造成重要的测试漏洞。
综合运用上面提到的三个方法：等价类划分、边界值分析和错误推测。全面的设计用例，并根据情况灵活选择。

其他经验：

理解软件架构，有利于发现系统边界以及系统集成上的潜在缺陷。数据库链接方式、中间件的配置、网络传输等。不能单纯把系统看作一个黑盒.测试人员更应该广泛学习各种技术的底层逻辑。
理解软件设计与实现细节。必要的时候，我们的用例也要覆盖到内部的处理流程、分支等。

当然，也不要被代码牵着走，否则会导致用例出错。以原始需求为本设计用例，辅以代码内部容易出错的逻辑细节。
引入需求覆盖率和代码覆盖率来衡量测试执行的完备性。还没学到。