针对穷举场景设计测试点

        针对限定边界规则设计测试点

        对多条件依赖关系进行设计测试点

        对于项目业务进行设计用例

---

1、等价类划分法：针对穷举场景设计测试点

        1）说明：在所有测试数据中，具有某种共同特征的数据集进行划分

        2）分类：有效等价类：满足需求的数据集，所有有效数据的集合，取一个即可。

                         无效等价类：不满足需求的数据集，所有无效数据集合，取一个即可。

        3）步骤：明确需求；

                        确定有效和无效等价类；

                        提取数据编写测试用例

        4）案例：

                4-1需求：验证QQ号的合法性；要求：6-10位自然数

        4-2需求：验证某城市电话号码正确性

                        要求：区号：空或者是三位数字

                                  前缀码：非“0”且非“1”开头的三位数字

                                  后缀码：四位数字

用例执行：预期结果与实际结果不一致，为缺陷

        5）应用场景

                针对：有大量数据测试输入，但是没法穷举测试的地方。输入框、下拉列表、单选复选框

                典型代表：页面级的输入框类测试。

2、边界值分析法：针对限定边界规则设计测试点

        1）边界范围节点：选取正好等于、刚好大于、正好小于边界的值作为测试数据

                上点：边界上的点（正好等于）

                离点：距离上点最近的点（刚好大于、刚好小于）

                内点：范围内的点（区间范围内的数据）

        2）应用设计步骤

        3）案例

                3-1 案例1：标题

                        需求：通过边界值法验证标题长度的合法性

                        要求：标题长度大于0，小于等于30个字符

                3-2 案例2：

                        需求：通过边界值法验证QQ号码的合法性

                        要求：6-10位自然数

3-3 案例优化

        结论：7个优化为5个点

                上点：必选（不考虑区间开闭）

                内点：必选（建议选择中间范围）

                离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）(10,20]

        优化：6<=qq<=10-->[6,10]-->开内闭外-->5、11进行测试-->7、9删除

        4）应用场景

                常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语

                典型代表：有边界范围的输入框类测试

           注：边界值可以覆盖等价类的长度，但是无法覆盖类型，所以设计用例时，两者结合使用。

3、解决多条件依赖问题：判定表法

        1）判定表法的引入

               验证“若用户欠费或者关机，则不允许主被叫”功能的测试

        2）判定表定义及组成部分

                定义：是一种以表格形式表达多条件逻辑判断的工具

                组成：

                        条件桩：列出所有条件，列出条件的次序无关紧要。

                        动作桩：可能执行的操作，操作的排列顺序没有约束。

                        条件项：条件对应的取值，所有可能情况下的真假值。

                        动作项：条件项的、各种取值情况下应该采取的动作结果。

                规则：判定表中贯穿条件项和动作项的一列就是一跳规则。

                          假设有n个条件，每个条件的取值有两个（0,1），全组合有2的n次方种规则。

        3）判定表法设计用例步骤

                ① 明确请求

                ② 画出判定表

                        列出条件桩和动作桩

                        填写条件项和动作项

                        根据条件项的组合确定动作项

                        简化、合并相似规则（有相同的规则）

                ③ 根据规则编写测试用例

        4）案例

                4-1 订购单检查

                        需求：①如果金额大于500元，又未过期，则发出批准单和提货单；

                                  ②如果金额大于500元，但过期了，则不发出批准单和提货单；

                                  ③如果金额小于等于500元，则不论是否过期都发出批准单和提货单；

                                  ④在过期的情况下不论金额大小还需要发出通知单。

                4-2 文件修改规则

                        需求：①输入的第一列字符必须是A或B；

                                  ②第二列字符必须是一个数字；

                                  ③如果第一列字符不正确，则给出信息L；

                                  ④如果第二列字符不正确，则给出信息M；

                                  ⑤如果两列字符输入正确，则修改文件成功。

        5）应用场景

                有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系；

                判定表一般适用于条件组合数量较少的情况（4个条件以下）

          提示：如果碰到项目中多条件组合大于4个相互依赖，可以使用（正交表和因果图来实现）

4、对于项目业务进行设计用例：场景法

        1）流程图：使用标准图形和箭头来表示程序或业务的走向

                作用：主要解决业务用例问题；当需求文档信息不全时，能够根据需求，梳理出流程

        2）介绍：基于流程图的方法，利用流程图描述用户的使用场景，通过覆盖流程路径来设计测试用例。

                注：测试用例，首先设计业务用例，其次设计单功能。

                意义：用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用

                        测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。

        3）案例

                3-1 ATM机取款流程—流程图

 注：6条业务线；成功的线一般用来做冒烟测试。

扩展—错误推荐法

        1）定义：通过经验推测系统可能出现的问题

        2）思想：根据经验列举出可能出现的清单，根据清单分析问题可能原因，推测发现缺陷。

        3）场景：时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试；

                        时间宽裕通过该方法列出之前出现问题较多的模块，再次测试。