1.测试设计与架构
1.1.测试分析及设计流程
图1 测试分析及设计流程图
1.1.1.从需求演到功能特性和需求场景
从需求分析产品的功能特性，梳理性能指标、设计约束条件和使用保障要求。
从需求分析产品的需求场景，分析核心是3个维度的梳理，角色、场景、方案。（哪类角色用户，在某种场景下产生了该需求，能够满足该需求、解决该问题的方案、途径有哪些？对应的具体流程是怎样的？）
分析需求并不只是一类用户在单一场景下产生的需求，可能是各类用户在很多场景下都普遍存在的，所以需要通过脑图的形式梳理出来具体的需求场景。
1.1.2.从功能特性和需求场景到测试方案
针对功能特性和需求场景，每一个功能特性和需求场景融入测试数据、测试条件，再加上通过等价类划分、边界值等分析方法获得的测试数据，这就形成了测试方案。
测试方案的目的是实现内部的测试目标沟通以及服务于对外的评审。
1.1.3.功能点判断
先设计主要功能的测试用例，再设计次要功能的测试用例。
1.1.4.从测试方案到测试用例
编写用例不等于把测试方案进行复制粘贴，需要对方案进行总结，在编写用例的同时需要思考测试方案的欠缺。
因测试用例则是测试执行的详细的指导，需要按照测试用例编写的规范尽可能的满足测试可执行性。
1.2.测试设计需要考虑的因素
在考虑背景、需求、技术知识、团队、进度、风险因素且穷举所有的测试场景或组合难度较大的前提下，设计测试用例时，需要抓住测试的风险和重点，并遵循由点到面的规则上进行充分分析与设计，才能达到理想的覆盖率。
| 因素 | 内容 |
|---|---|
| 测试需求目标 | 包括功能性测试与性能、接口集成测试目标。 |
| 用户实际使用的场景 | 站在用户的角度去思考产品的每一个特性，确保为测试用例建立正确的判断依据。 |
| 输入文档 | 测试用例设计的主要输入文档，如需求说明书与产品设计，会影响到测试用例的设计。这些文档的描述方法、格式和详细程度需要进行细致的评审。 |
| 测试的方法 | 测试用例具体设计方法，详见4.4章节。 |
| 被测试的对象 | 不同阶段的测试用例的侧重点不同，测试设计需从不同的侧面去发现系统的弱点或薄弱环节。 |
1.3.测试设计的基本原则
测试用例不是简单地复制产品需求、功能设计规格说明书等，而是通过思考和优化设计出来的。测试是基于数据分析的数据流和基于逻辑结构分析的控制流。测试设计方法就是通过测试用例的不断设计、优化，最终达到控制流和数据流的覆盖。
1.3.1.薄弱环节、边界点判断
1.3.2尽量找出系统大的薄弱环节、边界点，对特殊的区域进行更多的测试，从而降低测试的风险，达到所设定的测试目标。
1.3.3.优先级判断
1.3.4先设计高优先级测试项的测试用例，再设计低优先级测试项的测试用例。
1.3.5正常异常分支流程判断
针对具体需求，先设计正面的测试用例，再设计异常、非法操作的测试用例，详见图2及图3。
图2 具体需求测试设计顺序图
图3 软件流程示意图
1.4.测试设计的方法
在测试过程中，单一的方法不能满足测试设计的需求，要运用多种方法，才能满足测试设计的需求。例如，将等价类划分和边界值分析结合起来使用。
1.4.1.测试设计的依据
(1)需求说明书
(2)所属行业的业务知识掌握
(3)测试工程师的理解程度（个人经验）
1.4.2.测试的设计方法
1.4.2.1.场景用例设计方法
场景法测试用例设计方法主要用于事件触发流程，当某个事件触发后就形成相应的场景流程，不同的事件触发不同顺序和不同的处理结果，就形成一系列的事件结果。也可以将这一系列的事件触发流程看成不同的路径，使用路径覆盖的方法来设计测试用例，故场景分析法也称为流程分析法。
图4 场景用例设计方法
首先将系统运行过程中所涉及到的各种流程（如图3）进行图表化，先从最基本的流程入手，将流程抽象为不同功能的顺序执行。在最基本流程的基础上再去考虑次要或者异常的流程，这样将各种流程逐渐细化，将各个看似孤立的流程关联起来，完成所有流程的图表化后就完成了所有路径的设定。
找出路径后，需要给每条路径设定优先级，这样在测试时就可以先测优先级高的，再测优先级低的，在时间紧迫的情况下甚至可以考虑忽略一些优先级低的路径。优先级根据两个原则来选取：一是路径使用的频率，使用越频繁的优先级越高;二是路径的重要程度，失败对系统影响越大的优先级越高。将根据两个原则分别得到的优先级相乘，就得到了整个路径的优先级。根据优先级的排序就可以更有针对性地进行测试。
为每条路径设定好优先级后，为每条路径选取测试数据，构造测试方案。
1.4.2.2.等价类划分法
典型的黑盒测试方法，要求测试人员对需求书中的各项功能需求进行细致分析，把程序的输入域划分成若干个部分，然后从每个部分选取少数代表性数据作为测试用例，经过这种划分后，每一类的代表性数据在测试中的作用都等价于这一类中的其他值。
(1)分类
1)有效等价类：有意义输入的数据构成的集合；
2)无效等价类：无意义输入的数据构成的集合；
(2)方法
举例说明：我们要测试“司机输入车次号为5位数字”组成的字符，先划分子集：空车次号、1-4位数字、5位数字、5位以上数字、非数字，然后从每个子集选出若干个有代表性的值：
(1)空车次号：（无效等价类、无意义）；
(2)1-4位数字：1234（无效等价类）；
(3)5位数字：00000（有效等价类）根据需求是否合理；
(4)5位以上数字：123456（无效等价类）；
(5)非数字：fy7ui（无效等价类）；
1.4.2.3.边界值分析法
等价类测试的特例，主要考虑等价类的边界条件，在等价类的边缘处选择元素，是指输入和输出的等价类中那些恰好在边界，恰好超过边界以内的数据集合组成的用例。对于选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值。
例如：轮径值设置为860，那么边界值就是859，861，如果是一个完整的测试除了需要测边界值外，还需测试正常值。
1.4.2.4.错误推测法
在测试过程中，测试工程师可以根据经验或直觉推测程序中可能出现的各种错误，从而有针对性的编写这些错误的测试用例的方法。
这种方法没有固定的形式，主要依靠的是经验和直觉。
1.4.2.5.探索式测试设计
根据测试用例进行全面的测试执行是基础，但在完成测试用例执行以后鼓励基于风险以及反馈的基础上进行探索型测试，对于涉安功能以及风险等级较高的功能优先进行探索型测试，已完成测试中问题较多的功能模块进行第二步探索型测试。
其中要注意的地方是一旦探索型测试发现问题，需要再梳理测试方案未考虑的点，进行复盘，以完善测试方案测试用例库以及提高人员的测试设计能力。
2.测试方案编写的目的和要求
2.1.测试方案编写的目的
在整个开发、测试环节中，思考、沟通是最重要的环节，把产生的、达成共识的内容记录下来，汇集在脑图中展现，就可以看到整个需求点测试的全景图，然后再不断细化成测试故事点，大脑容易接受这种思维扩散以及总结的模式。
2.1.1.加强内外部评审
测试方案评审时，可以很直观的和需求进行一一对应，能够很快的确认需求覆盖率，以及确认测试的场景以及主要观察项。
2.1.2.测试用例的输入
作为测试用例的输入，在测试方案阶段更关注的测试场景以及重点需要观察项，对测试的细节描述可以省略，这部分在测试用例设计的阶段进行补充。
2.1.3.指导测试执行的过程
测试方案作为测试执行的过程，让执行者对测试的计划更了解以及对每条测试用例执行更有目的性。
2.2.测试方案编写的要求
| 要求 | 内容 |
|---|---|
| 全面性 | 尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备。 |
| 目的性 | 罗列的测试场景中，需要重点观察的输出需要标识明确。 |
3.测试用例规范性
3.1.写测试用例之前
测试用例是对测试场景和操作的描述，所以必须了解测试目标、测试对象、测试环境要求、输入数据和操作步骤，概括为5W1H。
| 5W1H | 内容 |
|---|---|
| 测试目标（Why） | 为什么而测？功能、性能、可用性、容错性、兼容性、安全性等。 |
| 测试对象（What） | 测什么？被测试的项目，如：对象、函数、类、按钮、系统、表格等。 |
| 测试环境（Where） | 在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、通信协议等单机或网络环境 |
| 测试的前提（When） | 什么时候开始测？测试用例运行时所处的前提条件或条件限制。 |
| 输入数据（Which） | 哪些数据？在操作时，系统所接受的各种可变化的数据，如：数字、文件、字符等。 |
| 操作步骤（How） | 如何测?执行软件和程序的先后次序步骤等。如：单击按钮。 |
3.2.测试用例编号规则
测试用例的编号是唯一的，用例编号格式下：
SYS（系统）-XXXX（产品名称）-YYYY（子系统名称）-TC（测试用例）-0001
3.3.测试用例内容
| 编号组成 | 内容举例 |
|---|---|
| 用例名称 | ?要清晰的描述需要测试的目的和关键测试要素、?不允许出现重复、包含关系或数字、编号差异 |
| 需求标识号（需求编号） | ?每个需求功能点对应一个需求编号 ?每个需求编号，需对应用例编号，需求对用例可以是一对一、一对多的关系，不可以是多对一的关系 |
| 需求名称 | 用例所对应的需求名称 |
| 用例状态 | ?描述每条用例目前存在的状态、?初始用例状态为正常。用例维护时状态为删除、增加、修改等 |
| 操作步骤 | ?每个操作步骤都应该对应一个或多个预期结果?操作步骤必须以序号为编号 |
| 预置条件 | ?需要描述测试所需要处于的外部环境和测试前测试对象及辅助对象所处于的状态和配置、?需要保证在完成预置条件中所描述的状态和配置及外部环境后，确保测试执行的正确性、一致性、?预置条件应为测试场景的上一步操作、?预置条件必须以序号为编号 |
| 预期结果 | ?针对测试用例的测试目的，测试步骤中操作后对应的预期输出状态。?预置结果必须以序号为编号。?预期结果应是直接可见的内容，而不是可能存在二异性（如或许、可能）的概念描述 |
（如不应该写临时限速办理成功，而是ATS调度界面可见黄色临时限速光带办理成功，ZC打印可见临时限速速度，起始位置终点位置均正确等具备观察性的描述）
3.4.编写用例规范
| 规范 | 内容 |
|---|---|
| 系统性 | ?对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系、?对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系。 |
| 全面性 | ?尽可能覆盖各种路径、尽可能覆盖各个业务点、接口需要覆盖码位的消亡状态。?要考虑跨年、跨月的数据以及大数据量并发测试的准备 |
| 连贯性 | ?对系统业务流程要说明各个子系统之间是如何在一起（若需要接口，各子系统之间是否有正确的接口，若是依靠负面链接，则页面的链接是否正确）?对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯 |
| 正确性 | ?输入界面后的数据应与测试文档所记录的数据一致?预期结果应与测试数据发生的业务吻合。 |
| 复用性 | 注重测试案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作人员的工作量。 |
| 统一性 | 测试用例编写应该制订统一的模板，并约定模板的适用方法。 |
4.测试方案及用例评审要点
测试方案/用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需通过后才可以使用。评审委员会可以由项目负责人和测试、软件开发工程师、分析设计等有关人员组成，也可邀请客户代表参加。
4.1.评审测试用例之前
在测试用例评审之前，要定义测试用例要符合以下标准：
| 检查项 | 内容 |
|---|---|
| 覆盖率 | 覆盖所有得测试范围内容 |
| 易读性 | 前提条件、步骤和期望结果等描述清楚、准确 |
| 易维护性 | 以很少的时间维护用例 |
| 易用性 | 设计思路容易理解，测试用例的组织结构合理，执行畅通、操作连贯性好 |
4.2.用例评审检查项
从测试用例的框架、结构开始向局部和细节推进
| 检查项 |
|---|
| 分析设计思路是否符合业务逻辑，是否符合技术设计逻辑 |
| 在局部上，有轻有重，要抓住难点和关键点，从不同的角度评审。 |
| 细节上，是否遵循编写规范和模板，是否描述清楚。 |
| 从测试用例的正面、反面评审 |
| 正面的测试用例，参照需求和设计文档，根据关联的功能和操作路径，覆盖率达100% |
| 负面的异常测试用例，可以发现更多的软件缺陷 |
4.3.检查表评审
通过检查表进行评审，根据检查表中的问题回答“是”或“不是”。
5.测试用例的完善与维护
测试用例必须定期修改与更新。在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善
| 行为 | 要求 |
|---|---|
| 新增用例 | ?对于系统新增功能，在评审或测试过程中发现缺少测试用例或者系统存在本身的设计缺陷而没有对应的测试用例，需要对应设计编写测试用例的规范进行新增测试用例。?新增用例时，需要在相同功能模块的最下方插入新增测试用例，并加以说明。 |
| 删除过时用例 | ?因需求变更导致某些用例无法适用，需要进行删除。应该将测试用例整行删除，且在备注中注明删除原因并将被删除用例迁移至用例删除库中，加备注说明原因。?如果整个功能模块删除时，需要将整个模块所对应的测试用例迁移至用例删除库中，并加备注说明原因。 |
| 修改测试用例 | ?根据需求的变更，需要修改已经不符合目前测试要求的用例，并加备注说明原因。?测试用例的修改、删除、新增应体现在《测试用例目录》中的“用例状态”处。 |
| 删除冗余用例 | 如果存在两个或更多的测试用例对一组相同的输入进行测试，则需要对其进行删除，只需留下其中一个。 |
| 补充漏写用例 | 如果产品基线后在现场发现的缺陷是由于室内漏测造成的，需要对测试用例进行完善。 |