软件测试之功能测试

【功能测试】

功能测试，依据产品设计规格说明书完成对产品功能进行操作，以验证系统是否满足用户的功能性需求

一 等价类划分法

1.等价类划分法的引入

案例：如何测试两个两位数整数之间的和（即-99到99之间数据求和）没有问题？

2.等价类划分法

等价类的概念：在所有测试数据中，具有某种共同特征的数据子集。

等价类划分为：

有效等价类：满足需求的数据子集

无效等价类：不满足需求的数据子集

3.等价类划分法设计用例步骤

• 明确需求
• 确定有效和无效等价类
• 提取数据编写测试用例

4.适用场景

针对需要数据量大，有测试数据输入的地方

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

二 边界值分析法

1.边界值分析法的引入

案例：测试两个两位数整数之间的和（即-99到99之间数据求和）？

//判断输入的数据是否小于-99或者大于99，如果小于-99或大于99给出错误提示 

If Val(Text1.Text) >= 99 or Val(Text1.Text) <=- 99 Then 

MsgBox ("输入的参数值必须大于-99同时小于99") 

Else if 

Val(Text2.Text) >= 99 or Val(Text2.Text) <= -99 Then 

MsgBox ("输入的参数值必须大于-99同时小于99") Then 

Else

Text3.Text = Val(Text1.Text) + (Text2.Text) 

End if 

End if

输入的数据包含99或者-99时，边界条件设置出错：代码中将“>”写成了“>=”，将“<”写成了“<=”

2.边界范围的确定

选取正好等于、刚好大于、搞好小于边界的值作为测试数据

• 上点：边界上的点（正好等于）
• 离点：距离上点最近的点（刚好大于、刚好下于）
• 内点：范围内的点（区间范围内的数据）

3.边界范围取值优化

结论：7个优化为5个点

• 上点：必选（不考虑区间开闭）
• 内点：必选（建议选择中间范围）
• 离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

4.边界值法设计用例步骤

• 明确需求
• 确定有效和无效等价类
• 确定边界范围值
• 提取数据编写测试用例

案例1：通过边界值法验证标题长度的合法性（要求：标题长度大于0，小于等于30个字符）

案例2：通过边界值法验证QQ号码的合法性（要求：6~10位自然数）

5.适用场景

在等价类的基础上针对有边界范围的测试数据输入的地方

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

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

三 判定表法

1.判定表法的引入

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

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

 

• 条件桩：列出问题中的所有条件。列出条件的次序无关紧要。
• 动作桩：列出问题中可能采取的操作。操作的排列顺序没有约束。
• 条件项：列出条件对应的取值。所有可能情况下的真假值。
• 动作项：列出条件项的各种取值情况下应该采取的动作结果。
• 规则：判定表中贯穿条件项和动作项的一列就是一条规则

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

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

• 明确需求
• 画出判定表
• 列出条件桩和动作桩
• 填写条件项，对条件进行全组合
• 根据条件项的组合确定动作项
• 简化、合并相似规则（有相同的动作）

3.根据规则编写测试用例

案例1：订购单检查

订购单的检查：
如果金额大于500元，又未过期，则发出批准单和提货单；
如果金额大于500元，但过期了，则不发批准单与提货单；
如果金额小于等于500元，则不论是否过期都发出批准单和提货单；
在过期的情况下不论金额大小还需要发出通知单

4.适用场景
有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系

四 场景法

1.场景法介绍

场景法，也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。

2.场景法的意义

• 用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
• 测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

3.场景法的适用场景

对于多个功能之间的组合逻辑测试，可以使用场景法

案例：ATM机取款流程

ATM机的取款流程图 

 

五 错误推测法

1.错误推测法的定义

通过经验和直觉推测系统可能出现问题的地方，一般由经验丰富的测试人员使用。

2.错误推测法的设计思想

• 凭人们对过去所作测试结果的分析，列举出可能出现问题的清单，根据清单测试来发现缺陷

3.错误推测法的适用场景

• 所有正常测试结束后，通过错误推断法再测试之前问题较多的模块
• 时间紧，任务量大，根据之前项目类似经验找出易出错的模块重点测试