如何设计一个“好的”测试用例？
如何设计一个“好的”测试用例？
前言
本篇文章为极客时间茹炳晟老师《软件测试52讲》专栏课程的学习笔记与操作实践的相关内容。原文课程链接：
ccccccc/fvnyhtpgia3 >本篇文章介绍了三种最常用的测试用例设计方法：等价类划分方法、边界值分析方法和错误推测方法。
文章以面向终端用户的GUI测试为例，详细介绍了测试用例设计的方法和经验。重点强调了从软件功能需求出发，全面地、无遗漏地识别出测试需求的重要性，以及深入理解被测软件的架构设计和内部处理逻辑的必要性。
此外，还分享了三个独家“秘籍”，包括深入理解软件架构和内部逻辑、引入需求覆盖率和代码覆盖率来衡量测试执行的完备性等。
一、什么才算是“好的”测试用例？
关于什么是“好的”测试用例这个问题，其实没有标准答案：
你可能会说“发现了软件缺陷的测试用例就是好的用例”，我可能会反问你“如果说测试用例发现了缺陷就是好用例，那么在该缺陷被修复后，同样的用例难道就不是好用例了吗？”。你可能还会说“发现软件缺陷可能性大的测试用例就是好用例”，这话看起来还是蛮有道理的，但是我同样会反问你“你打算用什么方法来量化测试用例发现缺陷的可能性？”。你可能还会说“发现至今未被发现的软件缺陷的测试用例就是好用例”，那么我想问你的是：如何评估是否还存在未被发现的缺陷？如果软件中根本就没有错误了呢？
所以，我们不能套用邓小平爷爷的那句话“白猫黑猫，能抓住老鼠的就是好猫”，这两者是不同的概念。
“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕渔网。“好的”测试用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能把鱼给捞上来。
如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。
二、好的测试用例必须具备哪些特征？
整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。
三、3种最常用的测试用例设计方法
从理论层面来讲，设计用例的方法有很多，如果你去翻阅测试图书或网络教程，会发现一堆让人眼花缭乱的测试方法，比如等价类划分法、边界值分析法、错误推测方法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、扩展有限状态机方法等等，但是从软件企业实际的工程实践来讲，真正具有实用价值并且常用的只有前三种方法。
对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。
1.等价类划分方法
我们只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
等价类划分方法的另一个关键点是要找出所有“无效等价类”。
例子：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是 0~100 之间的整数，考试成绩及格的分数线是 60。
有效等价类 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），去帮助优化补充测试用例的设计。
四、如何才能设计出“好的”测试用例？
在真实的工程实践中，不同的软件项目在研发生命周期的各个阶段都会有不同的测试类型。
传统软件的开发阶段通常会有单元测试，软件模块集成阶段会有代码级集成测试，打包部署后会有面向终端用户的 GUI 测试；再比如，电商网站的测试会分为服务器端基于 API 的测试、中间件测试、前端 GUI 测试等。
对于每一种不同的测试类型，设计出“好的”测试用例的关注点和方法论可能会有很大的差异。在这篇文章中，仅以最常见、最容易理解的面向终端用户的 GUI 测试为例，聊聊如何才能设计一个“好的”测试用例。
1.尽早介入，充分、深入理解业务需求
面向终端用户的 GUI 测试，最核心的测试点就是验证软件对需求的满足程度，这就要求测试工程师对被测软件的需求有深入的理解。深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确、从终端用户使用场景考虑的端到端（End-2-End）的测试用例集。
正如上一篇提到的，如果面试官让我们测试一个杯子，我们不可能上来就设计测试点，而是要先从多方面搞清楚需求：
① 从功能方面看：
是不是盛水的？能不能加热？带不带保温功能？自带吸管吗？带不带刻度？是不是量杯？.......
② 从非功能方面看：
耐热性怎么样：例如零下的液体、100度以上的液体耐摔性怎么样跟各种液体的兼容性：例如果汁、浓酸性的液体安全性（是否有毒/是否可以砸伤人）......
2.识别各个需求对应的测试点
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
以上一篇提到的“用户登录”功能的测试用例设计为例：
图中的业务需求到软件功能需求、软件功能需求到测试需求，以及测试需求到测试用例的映射关系，在非互联网软件企业的实践中，通常会使用需求追踪管理工具（比如 ALM、DOORS、JIRA、TestLink 等）来管理，并以此来衡量测试用例对业务需求、软件功能需求的覆盖率。
3.针对测试点设计测试用例
测试用例设计时的注意点：
从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。
以“用户登录”的功能性测试需求为例，你首先应该对“用户名”和“密码”这两个输入项分别进行等价类划分，列出对应的有效等价类和无效等价类，对于无效等价类的识别可以采用错误猜测法（比如，用户名包含特殊字符等），然后基于两者可能的组合，设计出第一批测试用例。
等价类划分完后，你需要补充“用户名”和“密码”这两个输入项的边界值的测试用例，比如用户名为空（NULL）、用户名长度刚刚大于允许长度等。
五、用例设计其他经验
除了上面介绍的方法外，还有三个独家“秘籍”：
只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。作为测试工程师，切忌不能把整个被测系统看作一个大黑盒，你必须对内部的架构有清楚的认识，比如数据库连接方式、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等等。必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。单单根据测试需求点设计的用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到的部分就很可能出现缺陷遗漏。在具体实践中，你可以通过代码覆盖率指标找出可能的测试遗漏点。
同时，切忌不要以开发代码的实现为依据设计测试用例。因为开发代码实现的错误会导致测试用例也出错，所以你应该根据原始需求设计测试用例。需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。
六、总结
最后，来简单总结一下今天的主要内容：
首先，你需要明白，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而能否发现软件缺陷并不是衡量测试用例好坏的标准。
其次，设计测试用例的方法有很多种，但综合运用等价类划分、边界值分析和错误推测方法，可以满足绝大多数软件测试用例设计的需求。
再次，“好的”测试用例在设计时，需要从软件功能需求出发，全面地、无遗漏地识别出测试需求至关重要。
最后，如果想设计一个“好的”测试用例，你必须要深入理解被测软件的架构设计，深入软件内部的处理逻辑，需求覆盖率和代码覆盖率这两个指标可以帮你衡量测试执行的完备性。
七、精彩点评
1.需求合理性测试
上一篇的点评里提到的“需求合理性测试”就是这位大佬的留言。
2.如何快速编写用例、用例如何维护
这个点评非常精彩，对于怎样写出好的用例、写用例的注意事项、用例维护都给出了非常不错的建议，极具参考意义。
3.用户体验测试
在写用例的过程中，不仅要关注业务逻辑实现，还要从用户角度出发，关注交互细节、使用习惯等等。
4.用例的形式
每个公司通常都有不同的用例展现形式，以我本人来说，经历过Testlink用例管理系统、Excel、Word、思维导图。这些没有好坏之分，只是在不同阶段、不同背景下，适用性不同。
5.从漏测率衡量是否是“好的”测试用例
测试事前评审测试用例，测试后最好也能再评审一次测试用例，总结出哪些bug是因为用例没有覆盖到导致的，做好项目复盘（理论都懂，但真正实施的很少）。
八、补充与发散
1.为什么要写测试用例？
这个不必多说，做测试的人都懂，主要有以下作用：
帮助测试人员理解、剖析业务及测试需求，梳理测试思路反向帮助产品人员补充业务场景，推动产品完善作为测试工作的依据，指导测试工作开展，避免漏测，同时规范测试执行作为回溯问题的记录，有据可查提高测试效率，保障测试质量帮助提炼出核心测试点，转化为自动化测试用例
2.在什么情况下该用什么样的用例组织形式？
不同形式的测试用例在不同阶段、不同背景下，适用性不同。那么，到底在什么阶段、背景下，该使用什么样的测试用例呢？以下的我的个人观点：
思维导图：如果公司没有严格规定必须使用哪种格式的测试用例，思维导图无疑是最好用、最快捷的形式；Excel：优缺点都非常明显，新项目的系统测试用例写起来会非常耗时，明显与当前动辄一周一个版本的“敏捷”模式格格不入，通常适用于冒烟测试用例、验收测试用例这种复用性比较大的类型；Word：这种形式比较少见，除非公司或客户有明确要求；在线用例管理系统：适用于有基线版本的项目，不需要经常维护用例，另外可以与bug管理系统相结合使用。
建议：系统测试用例（思维导图）+冒烟、验收测试用例（Excel）相结合的方式。
3.用例要描述到什么程度？
我的理解是不仅要自己能看懂，也要让项目组的其他人（产品、开发或测试，因为他们会参与评审）、或其他项目组来帮忙支援的小伙伴，在短暂了解业务流程及需求后，也能照着用例快速上手操作。
但这并不意味着需要让所有人都能看懂，测试毕竟是一门科学，属于专业的领域，用例中会涉及到很多专有名词，上下文之间可能存在某些关联，你让一个从来接触过被测系统的小白，直接拿着测试用例就上手测试，这显然是不现实的。
所以在编写测试用例过程中，要保证前提条件、操作步骤、期望结果等描述得清晰易懂，简洁高效，相互呼应。能让项目组的其他成员或其他项目组过来支援的同学看懂就可以了。
4.用例评审是否真的有必要？
在我过往经历的项目中，发现很多bug并不是由于开发能力不足、时间紧任务重、写代码时疏忽导致的，而是对产品需求理解不足或是有偏颇，导致产、研、测三方认知不对齐导致。
在评审过程中，测试会将产品需求反讲一遍，并将一些需求不合理、需求模糊、细节遗漏的地方拿出来展开讨论，甚至是一些需要特别注意的场景提前告知开发，打好预防针。
有效的沟通能够事半功倍，避免很多不必要的问题产生。所以用例评审就显得尤为重要！
5.用例评审如何开展？
用例评审大多会经历以下过程：
先自查：写完了以后自己对照着需求文档，检查是否有遗漏的地方；再互查：和项目组的其他测试同学交换，相互检查；评审会议：在正式评审之前，先将测试用例发送给项目组的成员，让产品和各个开发先单独评审，最后汇总结果，评审会议时集中展开讨论，能够大大提高评审效率；不确定的点，一定要讨论清楚，得出结论，最后由专人汇总评审结果，测试人员再相应补充、修改测试用例。
6.其他用例设计方法
上述提到的“等价类划分法”+“边界值法”+“错误推测法”确实能够满足绝大多数的用例设计，但它们并不一定就适用于所有类型的业务。举个例子，如果是业务流程非常长、分支非常多的下单、审批类的流程性业务场景，显然就不适合使用上述几类方法，此时比较推荐场景法；如果是前提条件、操作动作比较多，且和各个状态强关联的操作类业务场景，则推荐判定表+正交实验相结合的方法。
很多博客文章讲解测试用例都喜欢用经典的“登录注册”来举例，令人遗憾的是，方法虽然是相通的，但放大到整个系统来看，业务场景要远复杂得多，可参考意义并不大。这里推荐京东物流测试工程师写的一个测试用例设计“六脉神剑”系列：
