测试用例设计心得
👆 这是第 413 篇不掺水的原创，想要了解更多，请戳下方卡片关注我们吧～
测试用例是测试工程师必不可少的测试手段，体现了测试人员在测试策略和业务理解上的思考。一份详尽全面的测试用例将会给项目带来更扎实的保障。下面将从测试用例的定义、作用、编写原则三方面进行阐述如何进行测试用例设计。
一、测试用例的定义
（一）测试用例Test Case
测试用例是为特定目的而设计的，由测试输入、执行条件和预期的结果组成的，为了测试某个程序路径 或 核实是否满足某个特定需求的一段表述。
（二）测试用例的目标
测试的一个目标在于如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质。
测试用例是软件测试的核心，是为了高效率的发现软件缺陷而精心设计的少量测试数据。好的测试用例应该能发现尚未发现的软件缺陷。
实际测试中，由于无法达到穷举测试，所以要从大量输入数据中精选有代表性或特殊性的数据来作为测试数据。通过有限的测试用例，最大限度的提高发现问题的数量，以取得最好的测试效果。
（三）测试用例的组成
用例标题 重要性（优先级） 执行条件（前置条件） 对程序的输入数据的描述（必要） 对程序在上述输入数据下的正确输出结果的精确描述（必要）
（四）测试用例的执行
测试用例是执行的最小实体，执行用例的结果只有通过或不通过。
二、测试用例的作用
（一）影响软件测试的因素
影响软件测试的因素主要有软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等。有些因素是客观存在的，无法避免，如业务逻辑复杂。有些因素则是波动的、不稳定的，如人员是流动的；一个具体的人工作也受情绪等影响等。
（二）如何保障软件测试质量的稳定
规范测试用例。有了测试用例，无论是谁来测试，参照测试用例实施，都可以把人为因素的影响减少到最小，最大限度的保障测试的质量。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。
因此测试用例的设计和编制是软件测试活动中最重要的工作。测试用例是测试动作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。
（三）测试用例的作用
1、理清测试思路
有的系统本来就是一个大而复杂的项目，因此需要把项目功能细分，根据每一个功能通过编写用例的方式来整理测试系统的思路，避免遗漏掉要测试的功能点。而测试用例是执行的最小实体，是测试执行的有效依据，设计测试用例，也就是在设计和制定测试过程，解决要测什么，怎么测的问题。
2、明确测试任务
编写完用例后，可以明确自己需要执行的用例总数，以便预估测试工作量。并且可以很清楚的知道实际测试执行的进度，还很容易统计和跟踪我们的剩余工作量和回归工作量。
3、规范测试行为
每个人对于功能和开发原理的理解都是不同的，同一条案例，每个人的理解程度和扩展都是不一样的。对于没有测试经验的新人来讲，更是需要详细明确的用例来规范，以减少遗漏。同时也可以作为追溯测试、缺陷分析的有效依据。
三、测试用例编写原则
一份完美的测试用例至少要满足以下三个原则：准确性、简洁性、完整性。
（一）准确性
1、输入输出一一对应
测试用例一个步骤对应一个且只有一个预期结果
执行操作后，必然会有一个确定的结果，否则程序的执行结果就有不确定性，用户不知道会得到什么结果，这是不被允许的。
【例】：
步骤和结果不是必须分开，可一句话概括
对于某些简单的场景，步骤和结果不是必须的，简单的可一句话概括内容。
【例】：
2、测试目标明确
测试用例不是简单的场景堆叠，而是对一个功能点的拆分，是细化的执行的最小实体，是对一条规则的细则的验证。一条测试用例应该是在一个特定场景下，验证一个具体的功能点，场景描述可以体现在用例标题或前置条件中。也就是，一个功能点 ↔ 实现此功能的代码 ↔ 一个模块下的测试用例。
【例】：
before：场景罗列堆叠，层级很深，但其实前面描述的这么多都是前置条件，而非测试功能的描述。我把多个场景揉搓在一起，自己看着也蒙，还生怕少考虑了哪种场景。
after：主要功能点的概括描述作为用例标题，用例测试的功能一目了然。一个功能点应该对应一段实现此功能的代码，也应该对应一个模块下的、不同前置条件的多个用例。
3、可再现
对于同一个测试用例来说，系统的执行结果应该是每次相同的，避免用模糊的语言描述。稳定的系统可以验证测试用例的可再现性，测试用例多次执行结果的统一也可以验证系统的稳定。
（二）简洁性
1、语言描述要准确、精简
用例描述的语言要尽量准确和精简，没有冗余。
例：
before： after：
要可读性良好，测试过程明确，测试结果唯一。
（三）完整性
1、覆盖全面
测试用例编写的依据不仅是有效和预期的输入情况，还有无效和未预料到的输入情况。要尽可能的覆盖核心的业务逻辑、用户场景、需求点和业务分支。
2、测试用例需要不断完善
原因主要来自三方面：
在测试过程中发现设计测试用例时有遗漏，需要完善
在产品上线使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成
软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新
3、参考开发的实现方式
测试用例是为了测试代码是否满足业务要求。用户场景的划分，与同代码的处理相对应，测试用例不仅覆盖业务场景，也要关注代码的实现方式，从更深层次覆盖全面。
【例】：
看到这个需求，大家会怎么写用例？
before：把prd的流程按着头走到尾，每条分支走下来。写下去发现，层级太深，执行用例时要一个一个看条件是否对应，耗时效率低。
or：为了避免层级太多，所以前置条件放在一起五六个，写到头昏眼花。读都费劲，别说执行了。
after：在了解开发的实现后，发现开发是把这部分判断分成了三个责任链，判断单选、多选、数字三种属性类型，所以测试用例也应该按照这三种属性类型划分模块，可读性更高，条理更清晰。
四、总结
本文着重于讨论实际工作中应该如何优化我们的测试用例，提出编写测试用例的思考逻辑，当然也需要结合测试用例常用设计方法如等价类划分、边界值法等等。结合实践，希望能够对你的工作有所帮助。
参考文献
https://www.sohu.com/a/231616924_505788
看完两件事
如果你觉得这篇内容对你挺有启发，我想邀请你帮我两件小事
1.点个「在看」，让更多人也能看到这篇内容（点了「在看」，bug -1 😊）
招贤纳士
政采云技术团队（Zero），Base 杭州，一个富有激情和技术匠心精神的成长型团队。规模 500 人左右，在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。
如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com