01

测试用例设计原则

测试用例设计的基本原则包括：有效性、清晰性、可复用性、可维护性、完整性、兼容性、易操作性、可管理性、可评估性。

● 有效性：测试用例步骤必须描述清晰，不能出现模棱两可的以及重复的话语，测试用例应该按照一定的顺序进行编写，这样执行的时候效率比较高。

● 清晰性：用例的操作步骤要描述清晰，包含清晰的输入数据以及预期输出，验证点必须明确清晰，并能突出重点，对于流程性的用例建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。 测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。

● 可复用性：可重复使用，并尽量将具有相似功能的测试用例抽象并归类。

● 可维护性：测试用例因为业务需求发生变更的时候，需要及时更新维护测试用例，做到测试用例的实时性与有效性，测试用例需要细化和不断的完善，是个循序渐进的过程。

● 完整性：用例是否完成并覆盖所有需求点，做到对需求的完全理解。

● 兼容性：测试用例要包含新老版本的兼容、新老数据兼容、浏览器兼容等测试点。

● 可管理性：能够检测测试人员的测试进度、工作量等。

● 可评估性：测试用例的通过率和缺陷的数目是评估软件质量的好坏的标准。

02

测试用例的生命周期

软件测试用例的设计阶段包含：需求分析、测试用例设计、测试用例实现、测试用例执行、测试用例管理。

2.1 需求分析

测试用例过程的第一步是确定测什么，标识出测试点，并且对测试点进行优先级的划分。

2.2 测试用例设计

测试用例设计确定了如何来测试已经分析出的测试点。

测试设计的主要点是确定测试预期结果。为了确定测试预期结果，测试人员不仅需要关注测试输出，同时也需要注意测试数据和测试环境的前后置条件。假如测试用例没有测试的预期结果，则测试用例对于测试结果的对错判断是毫无意义的。

测试预期结果可以是各种各样的，包括需要创建或者输出的结果，也可以是需要更新或者变更的结果，也可以是删除的结果。每个测试用例都应该清楚的描述测试的预期结果。这样，就需要测试人员具有被测系统相关的丰富的知识和经验，才可能对软件系统的测试输出作出正确的评估。假如测试输出结果评估认为是正确的，那么就可以作为测试用例的期望输出结果。

2.3 测试用例实现

测试用例实现的过程包括准备测试脚本、测试输入、测试数据以及预期结果等。测试脚本指的是按照标准的语法组织数据或者指令。测试执行之前，首先必须满足测试前置条件，比如一个测试用例需要用到配置好的一些数据，那么这个数据就必须提前创建等。

2.4 测试用例执行

通过运行测试用例来对被测系统进行测试。对于手动测试来说，主要参照测试用例的步骤来进行测试执行，比较预期结果和实际结果、并记录测试过程中发现的问题。

对于自动化测试过程，执行时需要借助测试工具，运行测试用例脚本等，记录测试结果。

执行测试时如实际结果和预期结果是一样的，则认为是通过的，如果不一样，那用例执行失败，或存在问题，对于用例执行失败，需要进一步的检查，确定是软件问题还是用例的预期结果有问题，或者是数据问题，环境问题引起的，需要从不同的方面进行问题分析。

2.5 测试用例管理

1）测试用例组织

每一个项目，其测试用例的数目都非常多。如何来组织、跟踪和维护测试用例是一件非常重要的事情。如何来组织测试用例，是测试成功与否的一个重要因素，也是提高测试效率的一个重要步骤。

测试用例的组织，可以用不同的方法来进行组织或者分类：

按照功能模块进行划分是最常用的，我们也可以结合起来使用，比如在按照功能模块划分的基础上，再进行不同优先级的划分。

2）测试用例跟踪

测试用例的跟踪主要是针对测试执行过程中测试用例的状态来进行的，通过测试状态的跟踪和管理，从而实现测试过程和测试有效性的管理和评估。

3）测试用例维护

测试用例并不是一成不变的，当一个阶段测试过程结束后，会发现一些测试用例编写的不合理，或者需求发生了变化，这都需要对当前的一些测试用例进行修改和更新，从而使测试用例具有可复用性。

测试用例编写要素

4.1 等价类划分法

等价类划分法的定义：

等价类划分法分类：

适用范围：

步骤：

举例：

需求：下单若是函速达，需要允许快递员修改，且限定包裹数必须为 1，重量要<0.5kg。

4.2 边界值分析法

边界值的定义：

边界值范围：

边界值分析法中的三个点：

举例：1-100 ，上点：1 100 离点：0 99 2 101 内点：50

适用范围：

步骤：

1.明确需求

2.确定有效和无效等价类

3.明确题目条件中的边界值

4.编写测试用例

举例：

4.3 判定表法

适用条件：

组成部分：

步骤：

1.明确条件桩

2.明确动作桩

3.对条件桩进行全组合

4.明确每个组合对应的动作桩

5.设计测试用例

举例：

4.4 因果图法

因果图法定义：

适用范围：

因果图法的核心：

因果图基本符号：

关系：

步骤：

举例：

需求：某软件规格说明书包含这样的要求：第一列字符必须是 A 或 B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息 L；如果第二列字符不是数字，则给出信息 M。

4.5 正交分析法

定义：

正交表的概念：一种特制的表，一般的正交表标记为 Ln（mk）

如：L9( 34 )

有4个控件

每个控件有3个取值

9为需要测试的组合个数、有9条测试用例

叫4因素3水平

步骤：

1.根据需求形成因子状态表—-因子：控件名称 状态：每个控件对应的取值

2.确定所采用的正交表

3.将正交表中的数字用文字代替

4.一行就是一条测试用例

举例：

注意：

如果各个因子的状态数是不统一的，几乎不可能出现均匀的情况时，选择正交表为 等于或略大于因子数，状态数，且试验次数最少

4.6 场景法 - 流程图法

定义：

为什么要用户场景法

场景法的适用范围：

场景法中两个重要的概念

步骤：

1.确定项目角色

2.明确角色的常用功能

3.根据需求构建测试场景

4.一个场景就是一条case

安全性测试设计

安全测试是在软件产品开发基本完成时，验证产品是否符合安全需求定义和产品质量标准的过程。安全测试是检查系统对非法侵入渗透的防范能力。

包含的测试点如下：