作者：京东物流 王莹莹

一、测试用例为什么存在

1.1 定义

测试用例 (Test Case) 是指对特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。测试用例内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档类的输出。简而言之，测试用例是为某个目标而设计的一组测试输入、执行条件以及预期结果，用于核实是否满足某个软件需求。

1.2 作用

①指导测试（开发）的执行

测试用例作为各个测试阶段工作基准指导测试人员按照按用例项目和测试步骤实施测试。另外，测试工作左移时，测试同学提前输出的测试用例也可以指导开发人员的开发工作。

②测试物料的准备

• 数据：按照测试用例配套准备一组或若干组测试所需的原始数据。

• 测试脚本：自动化测试脚本的设计依据。

③测试工作进度把控

•测试工作量评估

•提高测试工作组织效率

④测试结果的度量基准

测试完成后需要撰写测试报告，判断测试是否完成、衡量测试质量量化的结果更加准确、有效。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。

⑤分析缺陷

通过测试用例和缺陷数据库对比，分析缺陷原因与类型。

二、测试用例设计基本原则

①正确性：测试用例必须是正确的，需通过测试用例评审。

②代表性：测试用例不可能是 “穷举” 的，期望在有限的测试时间内进行有效的测试，用例必须具有代表性的。

③可判定性：用例的测试结果必须可量化，这样测试完成之后才能将测试结果与预期结果进行比较，判定是否存在 BUG。

④可重现性：测试用例执行可复现性保证问题定位的准确性。

⑤可操作性：详细、准确和清晰的步骤是测试用例执行的必要条件，也是测试用例可重现的基础。

三、关于测试用例设计的三言两语

3.1 地基：常用测试用例设计方法（黑盒测试）

等价类划分与边界值分析

•等价类划分

将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出若干个有代表性的值作为测试用例。

•边界值分析

边界值分析法就是对输入或输出的边界值进行测试的一种方法，通常是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

场景法

场景法是通过场景描述用例执行的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。场景法适合测试业务流程清晰的系统或功能，从系统整个业务流程的全部角度对系统进行测试。

举例：京东商城购买商品，APP->选择商品->点击购买->确认购买信息->支付，这里的每个环节不同的结果结合起来都是一条不一样的用例。

错误推测法

错误猜测主要是一项依赖经验和直觉的非正规的工程方法，基本思想是列举程序可能出现的错误或者容易产生错误的测试点，然后根据测试点来编写测试用例。

举例：京东商城 APP 搜索输入框特殊字符的检查。

因果图与判定表

用图解的方法表示各种组合关系，写出判定表，从而设计相应的测试用例。类似于数学知识中的布尔逻辑运算，将各种输入条件的组合起来。每种组合条件就是 “因”，它有一个输出的结果，这就是 “果”。

举例：

正交实验法

正交试验设计是使用已经造好的正交表格进行数据分析，从中挑选出部分具有代表性的点进行试验，这些代表性的点具备了 “均匀分散，整齐可比” 的特点，是一种相对高效、快速的用例设计方法。

举例：

3.2 盖房子：实际工作中的测试用例设计

实际工作中，很多时候我们无法遵循理论上的测试用例设计方法那样，编写大而全的用例去执行所有大大小小需求的测试。更多情况下，用例设计时应该遵守精益测试策略，不能一味的追求测试覆盖率，有效的测试更有价值。利用测试四象限等信息指导的精益测试，追求以业务价值为目标，以尽量少的成本交付高质量的软件，做到有效覆盖，减少浪费。不管是手工测试还是自动化测试，都要先搞清楚业务价值和质量目标，测试用例设计和执行过程都需要做出相对应的考量（如测试用例的优先级）。

框架搭建

用例设计之前，我们应该熟悉需求的业务背景与技术架构，从而勾勒出测试用例整体框架。然后，使用【横向扩展】+【纵向分层】的组合模式下来针对每个需求完成用例拆解覆盖。

•横向业务扩展：指从业务角度平铺来看，总共有哪些业务场景，提供了哪些能力，即产品最上层的功能全景。

•纵向架构分层：是指从技术架构层面来分析，当前产品可以宏观上分为几层，以便于在用例验证是从不同层次上进行验证和用例覆盖。

举例：

添砖加瓦

测试框架搭建完成之后，就需要完善测试范围梳理，确认功能点的细节信息。例如，一般情况下需要进行回归测试、异常测试，再有可能需要进行并发测试、安全测试和性能测试等。从测试类型出发，结合常规用例设计方法进行用例设计与编写。

举例：

站在房子外面：像用户一样去测试

怎样像用户一样测试，能否做到还原真实用户的使用场景，还原用户在使用产品时的真实心理。说起来有点玄，但其实思路很简单。第一步想象自己就是用户，如果是我会有多少奇奇怪怪的操作或需求；第二步是弥补测试人员和用户之间的断层，用户和测试信息对齐，指导用户更好的使用软件，指导测试更有同理心。

小妙招

•用户画像：我们大概率能知道用户群体是谁，他的典型画像是什么样的，这也是我们进行换位思考的基础。

•不信任上下游：我们不能保证上下游给我的信息或者功能一定是完美的，结合自身系统定位和业务确认不同场景下我们应该做出什么样的反馈。

3.3 拓展：房子的维护，测试用例管理

测试用例是我们测试人员宝贵的财富，在测试工作中测试用例是其最为重要的基础。所以，一个良好的测试用例除了可以帮助测试人员阅读，理解，修改之外，也要方便我们去管理它，从而提高测试工作的质量和效率。不同的业务条线或者团队可以根据自己需要制定一些规则，让大家在进行测试用例设计遵守。