测试用例设计指南
一、测试用例设计原则
测试用例设计的基本原则包括：有效性、清晰性、可复用性、可维护性、完整性、兼容性、易操作性、可管理性、可评估性
1.    
1.    有效性:测试用例步骤必须描述清晰，不能出现模棱两可的以及重复的话语，测试用例应该按照一定的顺序进行编写，这样执行的时候效率比较高。 
1.    需求：登录密码必须同时包含大小写字母 
1.    错误举例：输入错误密码，登录失败（太过模糊，无法界定密码错误；此外还有针对计算结果的校验，用例中只描述“验证数据正确”的话，太过模糊无法执行）
2.    正确用例：密码仅包含小写字母，登录失败；密码仅包含大写字母，登录失败；密码不包含字母，登录失败；
2.    用例编写顺序：按照业务流程、模块、页面布局进行，方便用例的执行
2.    清晰性:用例的操作步骤要描述清晰，包含清晰的输入数据以及预期输出，验证点必须明确清晰，并能突出重点，对于流程性的用例建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。 测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。
3.    可复用性:可重复使用，并尽量将具有相似功能的测试用例抽象并归类。 
1.    组件类的用例可抽取为公共用例，如输入框（非空、长度、空格、特殊字符...），分页（首尾页、上下页、指定跳转页、总页数、当前页数、指定每页显示条数...）
2.    功能业务上类似，也可归类
4.    可维护性:测试用例因为业务需求发生变更的时候，需要及时更新维护测试用例，做到测试用例的实时性与有效性，测试用例需要细化和不断的完善，是个循序渐进的过程。
5.    完整性:用例是否完成并覆盖所有需求点，做到对需求的完全理解。
6.    兼容性:测试用例要包含新老版本的兼容、新老数据兼容、浏览器兼容等测试点。
7.    可管理性:能够检测测试人员的测试进度、工作量等。 
1.    MS平台中新增用例，创建测试计划，可初步评估维护用例的数量以及版本测试执行进度
8.    可评估性:测试用例的通过率和缺陷的数目是评估软件质量的好坏的标准。
二、测试用例的生命周期
软件测试用例的设计阶段包含：需求分析、测试用例设计、测试用例实现、测试用例执行、测试用例管理
2.1 需求分析
测试用例过程的第一步是确定测什么，标识出测试点，并且对测试点进行优先级的划分。
2.2 测试用例设计
测试用例设计确定了如何来测试已经分析出的测试点。
测试设计的主要点是确定测试预期结果。为了确定测试预期结果，测试人员不仅需要关注测试输出，同时也需要注意测试数据和测试环境的前后置条件。假如测试用例没有测试的预期结果，则测试用例对于测试结果的对错判断是毫无意义的。
测试预期结果可以是各种各样的，包括需要创建或者输出的结果，也可以是需要更新或者变更的结果，也可以是删除的结果。每个测试用例都应该清楚的描述测试的预期结果。这样，就需要测试人员具有被测系统相关的丰富的知识和经验，才可能对软件系统的测试输出作出正确的评估。假如测试输出结果评估认为是正确的，那么就可以作为测试用例的期望输出结果。
 
1.    需求：成本科目树，存在下级节点时不允许删除，无子级节点可删除 
1.    存在子科目时进行删除，删除失败提示“当前科目存在子科目无法删除”
2.    不存在子节点时进行删除，成功删除，列表不再回显数据库删除标识修改
2.3 测试用例实现
测试用例实现的过程包括准备测试脚本、测试输入、测试数据以及预期结果等。测试脚本指的是按照标准的语法组织数据或者指令。测试执行之前，首先必须满足测试前置条件，比如一个测试用例需要用到配置好的一些数据，那么这个数据就必须提前创建等。
  
1.    如平台的组织、用户数据；物联网平台的设备、测点数据；外业的工单模板；报警中心的报警规则接入...
2.4 测试用例执行
通过运行测试用例来对被测系统进行测试。对于手动测试来说，主要参照测试用例的步骤来进行测试执行，比较预期结果和实际结果、并记录测试过程中发现的问题。
对于自动化测试过程，执行时需要借助测试工具，运行测试用例脚本等，记录测试结果。
执行测试时如实际结果和预期结果是一样的，则认为是通过的，如果不一样，那用例执行失败，或存在问题，对于用例执行失败，需要进一步的检查，确定是软件问题还是用例的预期结果有问题，或者是数据问题，环境问题引起的，需要从不同的方面进行问题分析。
2.5 测试用例管理
1）测试用例组织
每一个项目，其测试用例的数目都非常多。如何来组织、跟踪和维护测试用例是一件非常重要的事情。如何来组织测试用例，是测试成功与否的一个重要因素，也是提高测试效率的一个重要步骤。可以用不同的方法来进行组织或者分类：
   
    按照软件功能模块组织：软件系统一般是根据软件的功能模块来进行工作任务分配的。因此，根据软件功能模块进行测试用例设计和执行等是很常用的一种方法。根据模块来组织测试用例，可以保证测试用例能够覆盖每个系统模块，达到较好的模块测试覆盖率。
    按照测试用例优先级组织：测试用例是有优先级的。对于任何软件，实现穷尽测试是不现实的。在有限的资源和时间内，首先应该执行优先级高的测试用例。
按照功能模块进行划分是最常用的，我们也可以结合起来使用，比如在按照功能模块划分的基础上，再进行不同优先级的划分。
2）测试用例跟踪
测试用例的跟踪主要是针对测试执行过程中测试用例的状态来进行的，通过测试状态的跟踪和管理，从而实现测试过程和测试有效性的管理和评估。
 
    测试用例执行的跟踪：在测试执行的过程中，对测试用例的状态进行跟踪，可以有效的将测试过程量化。比如，执行一轮测试过程中，测试的测试用例数目是多少，测试用例中通过、未通过、未测试的比例各是多少。这些数据可以提供一些信息来判断软件项目执行的质量和执行进度，并对测试进度、状态提供明确的数据，有利于测试进度和测试重点的控制。
3）测试用例维护
测试用例并不是一成不变的，当一个阶段测试过程结束后，会发现一些测试用例编写的不合理，或者需求发生了变化，这都需要对当前的一些测试用例进行修改和更新，从而使测试用例具有可复用性。
三、测试用例编写要素
•    用例编号：用例的唯一标识
•    测试模块：测试用例所属模块
•    用例标题：测试用例的简要说明
•    前提条件：用例执行的前提
•    测试步骤：执行用例步骤
•    预期结果：应该得到的结果
•    优先级：用例重要程度
四、编写覆盖全面的测试用例要素
4.1 分别设计不同类别的测试用例
测试用例需要先区分类别，然后再进行设计。如冒烟测试用例，主要用来支持开发自测试，以及开发提测后，测试人员用来验证提测质量。冒烟测试用例主要覆盖需求核心业务流程，如果测试用例通过不过，会影响测试工作的正常开展。全功能测试用例，覆盖整个需求的测试用例，用来在测试过程中执行用例，来验证开发的代码是否符合产品的需求，发现可能存在的问题。不同类别的测试用例有不同的用途，需要分别来对待的。
4.2 从用户角度出发，编写测试用例
虽然我们了解到很多设计测试用例的方法，可是在实际工作中不能完全按着这些方法来实施的。需要切换用户视角，去编写用例；比如功能交互的易用性，不同网络环境、硬件环境，特定场景这些都是测试用例设计的出发点。
4.3 异常用例编写
除了主流程用例外，也需要关注异常场景、异常操作相关用例，结合边界值、等价类等方法将异常测试用例添加进来。同时，性能边界，安全边界也是我们需要考虑的地方，只有补充了这些边界，才不会造成遗漏的地方。
4.4 根据业务流程编写用例
根据业务流程编写用例：需求描述功能验收、影响范围功能回归；很多时候我们的新需求只是一个业务流程的一部分，在通过相应的方法编写测试用例，验证了本次需求的核心功能，边界条件后，还需要考虑相关的具体业务流程。编写业务流程场景相关的测试用例，来验证本次需求对业务流程上下游的影响，能否正确传递数据。本次需求可能影响到的地方，测试用例也必须覆盖得到。
4.5 根据代码实现方案编写测试用例
根据代码实现的方案编写测试用例，比如增加：消息队列逻辑、数据存储/缓存逻辑、代码/接口相关的测试用例；
4.6 根据业务经验编写测试用例
测试人员必须对你所测试的业务有充分的了解，这也是一个测试人员必备的能力。然后在遇到新的需求的时候，可以从参加需求评审的时候快速评估出本次需求可能影响的范围，从而对相关要影响的地方添加用例覆盖，进行回归测试。如一个需求是对某接口响应时间的调优，我们就需要对调用这个接口的所有业务进行相关用例覆盖，测试的时候进行回归测试。有这样的技术敏感度，业务熟悉度，才能做到不会遗漏影响到的功能。
五、功能测试用例设计方法
4.1 等价类划分法
等价类划分法的定义
  
    输入具有代表性的数据子集
等价类划分法分类
   
    有效等价类：满足需求的
    无效等价类：不满足需求的
适用范围
  
    具有单个输入的功能
步骤
    
    明确需求
    确定有效和无效等价类
    编写测试用例
举例
 
4.2 边界值分析法
边界值的定义
    
    对于输入等价类和输出等价类而言稍高于其边界或者稍低于其边界的一些特定情况
边界值范围
   
    正好等于
    刚刚好大于
    刚刚好小于
边界值分析法中的三个点
  
    上点：边界上的点
    离点：距离边界最近的点
    内点：范围内的点
举例：1-100 ，上点：1 100 离点：0 99 2 101 内点：50
适用范围
  
    有输入参数，且输入类型或范围长度有边界时（适用于题目需求中有长度或者范围的情况）
    和等价类一起使用，适用于单个功能的输入的情况
步骤
   
1.    明确需求
2.    确定有效和无效等价类
3.    明确题目条件中的边界值
4.    编写测试用例
举例
 
4.3 判定表法
适用条件
   
    判定表表示的是有多个输入和多个输出，而且输入与输入之间相互的组合关系，输入和输出之间有相互的制约和依赖关系
组成部分
  
    条件桩：题目条件中的所有的测试输入
    动作桩：题目条件中的所有输出
    条件项：测试输入的取值
    动作项：测试输出的取值
步骤
 
1.    明确条件桩
2.    明确动作桩
3.    对条件桩进行全组合
4.    明确每个组合对应的动作桩
5.    设计测试用例
举例
 
4.4 因果图法
因果图法定义
 
    理论中是通向判定表的一个中间过程
适用范围

    因果图是一种利用图解法来分析输入的各种组合情况，从而设计测试用例的方法，它适用于检查程序输入条件的各种组合情况
因果图法的核心  
    所谓的原因就是输入，所谓的结果就是输出。
    因果图的因 —输入条件
    因果图的果 -输入结果
因果图基本符号
 
关系  
    恒等：若 c1是 1，则 e1 也是 1；否则 e1是 0
    非：若 c1是 1，则 e1是 0；否则 e1是 1
    或：若 c1 或 c2 或 c3 是 1，则 e1 是 1；否则 e1是 0
    与：若 c1 和 c2 都是 1，则 e1是 1；否则 e1 是 0
                       
                    
约束：是指输入状态还存在这某种依赖关系，这种关系称作为约束。
E约束（异）：表示a，b两原因不会同时成立，最多一个能成立。
I约束（或）:a、b、c三个原因中至少有一个必须成立。
O约束（唯一）:a、b当中必须有一个，且仅有一个成立
R约束（要求）:当a出现时，b必须也出现，不可能a出现b不出现
M约束（屏蔽）:表示当a是1时，b必须是0。而当a为0时，b的值不定
步骤  
    标识输入和输出
    画出因果图
    将因果图转换为判定表
    生成测试用例
举例
需求：某软件规格说明书包含这样的要求：第一列字符必须是 A 或 B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息 L；如果第二列字符不是数字，则给出信息 M。
 
转化为判定表，最终转化为测试用例。
 
4.5 正交分析法
定义  
    正交法又叫正交试验法，又叫正交排列法，使用最小的测试过程集合获得最大的测试覆盖率，（测试用例的条数写的少一点，而测出的 bug 多一点），正交试验设计法，是从大量的试验点中挑选出适量的，有代表性的点，应用依据伽罗瓦理论导出的 “正交表”，合理安排试验的一种科学的试验设计方法。
    通过正交表挑选部分有代表性的水平组合试验替代全面试验。这些有代表性的组合试验具备了“均匀分散，整齐可比”的特点
正交表的概念：一种特制的表，一般的正交表标记为 Ln（mk），n=k*(m-1)+1 
    n 表示行数，也就是需要测试组合的次数
    k 表示的列数，表示控件的个数（因素的个数，或是因子的个数）
    m 是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）
如：L9( 34 )：有 4 个控件，每个控件有 3 个取值，9 为需要测试的组合个数、有 9 条测试用例，叫 4 因素 3 水平；正交表生成工具：Allpairs
步骤  
1.    根据需求形成因子状态表—-因子：控件名称 状态：每个控件对应的取值
2.    确定所采用的正交表
3.    将正交表中的数字用文字代替
4.    一行就是一条测试用例
举例
4.6 场景法 - 流程图法
定义
    模拟用户操作时的场景，主要用于测试多个功能之间的组合使用情况
为什么要用户场景法
    用户角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
    测试人员角度：平时测试的都是单个功能点进行测试，为了保证测试的全面性，考虑多个功能之间组合测试的场景
场景法的适用范围

    多个功能之间的组合测试
    往往在冒烟测试时经常使用
场景法中两个重要的概念
    基本流：按照正确的业务流程操作的一种路径
    备选流：出现错误的操作流程
步骤
1.    确定项目角色
2.    明确角色的常用功能
3.    根据需求构建测试场景
4.    一个场景就是一条 case