-
测试用例设计
-
测试用例概念
-
简介
-
测试用例（Test Case）是为特定的目的而设计的一组测试输入、执行条件和预期的结果的文档。 实际工作中可以通过大量的测试用例来检验软件的运行效果。它是指导测试工作进行的依据。其实通俗一点说，测试用例就是指导怎么做测试的一个文档。在这个文档里面，会指明测试的功能点是什么，然后会把怎么去测试这个功能点的步骤和要输入的测试数据都写进去，当然也要包含希望的结果是什么。
-
-
测试用例价值
-
指导测试的实施
-
规划测试数据的准备
-
编写测试脚本的"设计规格说明书"
-
评估测试结果的度量基准
-
分析缺陷的标准
-
-
-
黑盒测试方法论-等价类
-
简介
-
等价类划分是一种重要的、常用的黑盒测试方法，不需要考虑程序的内部结构，只需要考虑程序的输入规格即可。它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。 这种方法需要把用户所有可能输入的数据，划分成了若干份（或者也可以叫做若干个子集），然后从每一个子集当中选取少数具有代表性的数据作为测试用例，这种测试用例称为“等价类划分法”。
-
-
等价类分类
-
有效等价类：指符合《需求文档》，输入合理的数据集合。
-
无效等价类：指不符合《需求文档》，输入不合理的数据集合。
-
-
等价类划分原则
-
规定输入的取值范围或个数时，划分一个有效和两个无效
-
规定了输入的集合或规则必须要遵循的条件，则划分一个有效和一个无效
-
输入条件是一个布尔值，则划分为一个有效和一个无效
-
输入条件规定了必须要遵循的某些规则下，则划分为一个有效和若干个无效
-
不是所有的等价类都有无效等价类
-
-
等价类设计步骤
-
先划分等价类：找出所有可能的分类
-
确定有效等价类：需求中的条件
-
确定无效等价类：与条件相反的情况，再找到特殊情况
-
从各个分类中挑选测试用例数据
-
-
-
黑盒测试方法论-边界值
-
简介
-
边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力。它是对等价类划分法的一个补充。 这个方法其实是在测试实践当中发现，大量的错误发生在输入和输出范围的边界上。所以要针对各种边界情况设计用例，这样可以查出更多的错误。
-
-
边界值确定
-
上点：边界上的点。
-
离点：离上点最近的点。
-
内点：在输入域内任意一个点。
-
-
边界点划分规则
-
如果规定了输入域的取值范围，则选取刚好在范围边界的点，以及刚好超过边界的点，作为测试的输入数据。
-
如果规定了输入值的个数，则用最大个数，最小个数，比最小个数少 1，比最大个数多 1 的数作为测试数据。
-
如果规定了输入是一个有序的集合，则选取集合的第一个元素和最后一个元素作为测试数据。
-
-
-
黑盒测试方法论-判定表
-
简介
-
判定表是一种用于表示决策逻辑的表格形式，常用于软件测试领域。判定表以清晰的方式描述了各种输入条件和相应的输出结果之间的关系，使得决策逻辑更易理解和管理。 因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例。但有时画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例。
-
-
判定表的组成
-
条件桩：问题的所有条件。
-
动作桩：问题的所有输出。
-
条件项：针对条件桩的取值。
-
动作项：条件项的各种取值情况下的输出结果。
-
-
判定表设计步骤
-
列出所有的条件桩和动作桩
-
确定规则数：条件取值个数^条件数
-
填入条件项
-
填入动作项。得到初始判定表
-
简化判定表
-
-
-
黑盒测试方法论-场景法
-
简介
-
场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程。 当拿到一个测试任务时，不能只关注某个控件的边界值、等价类是否满足要求，也要关注它的主要功能和业务流程是否正确实现，这就需要使用场景法来完成测试。
-
-
场景分类
-
基本流：按照正确的业务流程来实现的一条操作路径。
-
备选流：导致程序出现错误的操作流程。
-
-
场景法优缺点
-
优点：涉及倒业务流程的业务需求适合用场景法。
-
缺点：只验证业务流程，不验证单点功能，一般先采用先用等价类，边界值，错误推断，判定表等方法对单点功能进行验证，验证通过后再采用场景法进行业务流程的验证。
-
-
设计步骤
-
根据需求规格说明，画出功能模块流程图。
-
根据流程图，描述出程序的基本流及备选流。
-
根据基本流和备选流生成不同的场景，构造场景列表。
-
对每一个场景生成相应的测试用例。
-
对生成的所有测试用例重新复审，去掉多余的测试用例。
-
测试用例确定后，为每一个测试用例确定测试数据值。
-
-
-
测试用例基础概念
-
简介
-
测试用例（Test Case）是为特定的目的而设计的一组测试输入、执行条件和预期的结果的文档。
-
-
测试用例的组成
-
用例编号
-
模块
-
测试点（测试标题）
-
优先级
-
前提条件
-
测试步骤
-
期望结果（预期结果）
-
实际结果
-
-
测试用例的优先级
-
简介
-
测试用例根据重要性分成一定的等级。在不同的公司，可能测试用例的等级划分不尽相同，但是基本大同小异。这里列的这种是公司里面比较常用的一种测试用例等级划分的方法，共分为4级，由高至低依次为 P0-P3。
-
-
分类
-
P0：核心功能测试用例
-
P1：高优先级测试用例
-
P2：中优先级测试用例
-
P3：低优先级测试用例
-
-
-
-
测试用例设计与评审
-
设计方法的选择
-
任何情况下，都需要采用等价类划分法，将无限测试变成有限测试
-
在规定了数据范围的情况下，必须采用边界值分析法
-
如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
-
如果含有输入条件的组合情况，考虑选用因果图和判定表法
-
采用错误推断法再追加测试用例
-
-
测试用例编写步骤
-
划分功能模块：先用思维导图把大功能里的小功能点都拆分出来。
-
正向功能验证：先把这个大功能的正向的操作先走通，其实就相当于是一个简单的冒烟。
-
单个功能项验证：把每一个拆分出来的小的功能点再去单独的验证。
-
功能之间交互验证：验证一些场景的用例。
-
隐形需求：产品特性验证，特殊业务场景验证。
-
-
测试用例评审
-
测试用例的本身的描述是否清晰，是否存在二义性
-
测试用例内容是否正确，是否与需求目标相一致
-
测试用例的期望结果是否确定、唯一
-
测试用例是否覆盖了所有的需求
-
测试用例是否具有可执行性
-
是否从用户层面来设计用户使用场景和业务流程的测试用例
-
场景测试用例是否覆盖最复杂的业务流程
-
用例设计是否包含了正面、反面的用例
-
-
-
