测试用例的定义

测试用例是在软件项目测试中，为了某个特殊目标而编写的，具有测试输入，执行步骤，预期输出的，可以指导测试实施的测试文档。主要用于项目的需求验证。

编写测试用例的好处

设计和编写测试用例文档有下面几大好处：

• 更加理解测试需求，避免遗漏测试点；
• 跟踪和记录测试进展，更好掌控进度；
• 保留项目验收步骤，避免重复设计；
• 记录和确认已经执行过的测试点；

测试用例设计的来源

• 产品需求。需要准确理解产品的需求，对产品需求进行划分，转化成测试需求
• 产品设计文档。对开发的设计文档进行阅读，尤其代码处理逻辑进行测试需求转换，做到分支尽量完全覆盖。
• 系统部署文档。对系统的部署环境进行场景覆盖，尽量覆盖到实际部署所使用的环境。

测试用例的几要素

• 测试编号，每个用例都应该有独一无二的编号进行标识，比如可以使用：项目+模块+验证阶段+序号进行标识；
• 测试标题，每个测试用例都应该有明确的测试标题，表达该条测试用例的测试目的；
• 测试输入，每个用例的输入都需要准确定义，不能使用模糊的概念，最好明确到具体数字；
• 测试步骤，每个测试用例都应该有可实施的描述清晰的测试步骤，每个测试人员都可以按照所写的测试步骤完成用例执行；
• 预期结果，每个用例的每个测试步骤，都应该对应有该步骤执行完成只有的预期结果如何，如果执行时和预期结果不一致，则视为用例执行失败；
• 重要级别，每个测试用例都应该有对应的级别，一般按照四个级别来，定义标准可以按照如下标准：

  • level 0（高），重要性为高的测试用例，最基本的测试用例，版本转测试时，可以作为冒烟测试标准，如果该级别用例不通过，则表示严重阻碍测试活动，对应的bug级别为阻塞，同时冒烟测试不通过，可以考虑让开发重新提交版本进行测试。
  • lever 1(中)，重要性为中等的测试用例，表示验证系统的核心的主要的功能的测试用例，如果对应的测试用例执行不通过，则表示系统的核心功能无法正常工作，对应的Bug级别对应的致命或者严重。
  • lever 2（一般），重要性为一般的测试用例，表示验证的是系统的次要的，一般性的功能，如果对应的测试用例执行不通过，则表示系统的功能基本正常，但是存在一些使用上面的问题，对应的Bug级别对应为一般。
  • lever3 （提示），重要性为提示的测试用例，表示验证的是系统的界面提示性的内容，如果对应的测试用例执行不通过，则表示对应的界面不友好，或者提示信息不正确，对应的Bug级别为提示。
    不同重要性测试用例在项目中所占比例参考
    |level 0 (重要)|level 1 (中) |level2 (一般)|level 3(提示)|
    |------------------|----------------|------------------|-----------------|
    | -----10%------|-----20%---- | -----50%------|-----10％------|

• 测试结果，每个执行之后的测试用例都需要准确标识测试结果，通过／失败／阻塞；
• 备注，在测试执行的过程中，如果发现了和预期结果不一致，但是需求里面没有明确定义的现象，可以记录在备注中。

＃测试用例设计的原则

• 产品需求≠测试用例，不能直接拿产品的需求直接做为测试用例的标题，其有以下基层含义：

＋ 测试用例设计之前详细理解产品需求，对每个需求做详细的用例设计，覆盖每个需求的输入和输出测试；

• 不直接复制产品需求为测试用例的标题，从可测试的角度进行标题定义；
• 对产品需求中没有明确的需求，但是符合业界标准的功能需求也需要进行测试用例设计；
• 对需求中未明确的异常情况，也需要设计异常测试用例；
• 对需求中未明确的兼容性和性能方面的要求，也需要设计兼容性和性能测试用例，预期结果可以通过集体评审的方式给出；

＋ 唯一性，每个测试用例的测试目的是唯一的，不能一条测试用例测试系统的好几个功能点。

• 易读性，测试用例易读性好，易于人们的理解和维护，并且复用性高。
• 有效性，每个测试用例应该是对功能的有效验证，具备较高的发现问题的概率。
• 合理性，测试用例集按照特性划分的很合理，特性和特性之间区别比较明显。
• 完整性，整个测试用例的集合应该能够把系统的功能／兼容，性能等方面都完整验证到。
• 可维护性，在测试过程中，或者在测试的任意阶段，发现测试没有覆盖的地方，可以及时添加测试用例，陈旧的用例可以及时更新。

测试用例的设计方法

测试过程可以分为白盒测试和黑盒测试，白盒测试是清楚系统的内部运行机制和代码运行逻辑的情况下进行，主要对系统结构模块代码的接口和模块内部处理逻辑进行测试。黑盒测试意味着测试人员不需要考虑代码内部结构实现的逻辑，只依据程序的需求说明书进行测试用例设计，检查是否满足需求说明书上的内容。

白盒测试用例设计方法

白盒用例设计的方法有代码检查法，静态结构分析法，逻辑覆盖法。其中逻辑覆盖法可以从以下几个角度进行覆盖：语句覆盖，判定覆盖，条件覆盖，判定／条件覆盖，条件组合覆盖，路径覆盖。

黑盒测试用例设计方法

具体的黑盒用例设计方法有等价类划分法，边界值分析法，场景分析法，因果图法，功能图法，错误推测法。

等价类划分

利用物以类聚的思想进行测试用例设计的方法。可以针对系统的输入／输出／执行场景等角度，在可以明确划分界限的地方进行等价类划分，总体上可以分为有效等价类和无效等价类。设计用例时，可以根据下面的总结的几个常识进行用例设计：

• 在输入条件规定了取值范围和规定个数的情况下，可以设计一个有效等价类和两个无效等价类。
• 在输入条件规定了取值的集合或者规定了必须如何时，可以设计一个有效等价类和一个无效等价类。
• 在输入条件是一个布尔变量的时候，可以设计一个有效等价类和一个无效等价类。
• 在输入条件规定了是某一组值时（假定ｎ个），并且程序会对每个输入值进行单独处理时，可以设计ｎ个有效等价类和１个无效等价类。
• 在规定了输入条件必须满足某种规则时，可以设计一个有效等价类和多个无效等价类（从不同的角度违反规则）。
• 在确定的分类下，某个子类中仍然可以按照某种规则进行等价类划分时，则可以继续按照上面的方法进行子类的等价类细分。

边界值分析法

边界值分析法一般会跟等价类划分法结合起来使用，但是它不是从等价类中任意选择一个子类作为输入，而是将边界值作为重点测试目标。选择刚好等于，刚好小于，刚好大于的几个情况作为测试输入。

• 如果输入条件规定了值的范围，可以选择正好等于，正好大于，正好小于边界值的数据作为合理的输入，如输入值的范围是[1，100]，可取0，1，100，101等值作为测试数据。
• 如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如，一个输入文件可包括1--255个记录，则分别设计有1个记录、255个记录，以及0个记录的输入文件的测试用例。

场景分析法

场景法是路径覆盖法的一种延伸，根据系统的处理流程中不同处理场景进行场景覆盖的用例设计方法。举例如下：

image.png

按照上图中每个经过用例的路径，可以确定以下不同的用例场景：

场景 1 基本流

场景 2 基本流 备选流 1

场景 3 基本流 备选流 1 备选流 2

场景 4 基本流 备选流 3

场景 5 基本流 备选流 3 备选流 1

场景 6 基本流 备选流 3 备选流 1 备选流 2

场景 7 基本流 备选流 4

场景 8 基本流 备选流 3 备选流 4

注：为方便起见，场景 5、6 和 8 只考虑了备选流 3循环执行一次的情况。

因果图法

因果图法是利对系统的输入进行各种组合的手段得到的测试用例设计方法，等价类划分和边界值分析都是考虑输入条件，但是没有考虑输入条件的各种组合的情况，以及各种输入之间相互制约的情况，由此就导致各种输入单独正确或者出错的情况都验证到了，但是输入之间相互组合的情况没有验证到。如果输入之间的各种组合全部进行用例设计，那么造成的测试用例数量是巨大的，由此就需要借助因果图进行用例精简设计，其因果图就是白盒测试中使用的因果图。

错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法,基本方法是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。

测试方法选择的综合策略

在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效提高测试水平，以下是各种测试方法选择的综合策略，可在实际应用过程中参考。

• 首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的最有效方法。

• 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。

• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

• 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。

里面内容部分参考：《测试用例设计》　https://www.jianshu.com/p/9dd69fbe2df5