测试用例的方法_文件修改规则的测试用例

以下文章涉及测试用例的写法和注意要点

2.1定义

TestCase，为了特定的目标而设计的一组测试输入、执行条件和预期结果的文档。

2.2测试用例的核心

用例编号（ID）：标注每一条用例的唯一性

用例标题：表示测试的目的，一句话简要描述

测试项目：当前测试的功能所属范围，也可以说是模块

用例级别：标注的是测试用例的重要程度

预置条件：验证该功能的前提条件

输入数据：执行当前测试用例所需要的数据

执行步骤：执行该共功能的先后步骤

预期结果：希望的结果

测试用例的八大要素（框框即为重点）

根据情况会添加一下：测试人员、测试版本号、备注：用来存放bug截图，录屏等、测试结果

3.0设计测试用例

3.1测试两个两位整数的和

10-99 -10---99

3.1等价类划分法

3.1.1定义以及分类

等价类：在所有的测试数据中，具有某种共同特征的数据子集。分为有效等价类和无效等价类。

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

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

两者都是针对上面的条件（两个两位整数）而言。

3.1.2适用场景

一般用于经典输入框场景（input标签）

3.1.3案例

验证qq的合法性

6-10位自然数

有效等价类：6-10位自然数

无效等价类：长度小于6位，大于十位的qq号

小练习试一试：验证电话号码：区号-电话号码

验证邮箱是否有效 邮箱的名字是4-16位字符，支持字母数字下划线，但是不能全是数字或者全是下划线。

验证邮箱密码 6-18位字符。

3.2边界值分析法

3.2.1定义

选取正好等于或者刚好大于或者正好小于边界的值的作为测试数据（可以看作等价类划分法的补充）。

3.2.2边界范围的确定

6-16位的大小写字母

上点：刚好在边界 上的点，6和16； 离点：刚好大于，刚好小于，离边界最近的点，比如5，7，15，17；

内点：范围内的点，只要在区间范围内就可以，是不确定的，比如9，10，11等等；（虽然7和15在范围内，但是不称为内点，称为离点）

3.2.3边界优化（重点）

（）代表开区间

[]代表闭区间

边界值法，内点1个，上点2个，离点4个-----七个点优化成5个点。

上点：必选

内点：必选

离点：根据范围是否取值进行取舍

内点和上点必测！！！！ 口诀：闭外开内

（10，99）必选的点：10，11，50，98，99

[ 10，99)必选的点：9，10，50，98，99

[10，99]必选的点：9，10，50，99，100

实际工作中：如果不确定是五个点还是七个点，就全部选上。

3.2.4边界值法设计测试用例的步骤

1. 需求分析

2. 划分等价类：有效等价类和无效等价类

3. 使用边界值法，确定范围值

4. 提取数据进行编写测试用例

注意在需求有范围的时候使用边界值法对划分等价类进行补充

3.2.5适用场景

1. 最明确的需求，存在一个具体的范围，比如8-18位字符

2. 一般大小、尺寸、至少、最多、重量等

3.3判定表

3.3.1判定表定义

输入的条件和输出的结果之间存在相互制约的关系，使用判定表。

判定表的定义：是一种以表格形式表达多条件逻辑判断的工具，看重的是条件之间的相互组合。

逻辑判断：

与：表示多个条件同时成立。至少有两个条件。

或：多个条件只要成立一个就可以了。

非：与给予的条件相反（抬杠）

3.3.2判定表的组成部分

案例：用户停机或者关机的时候，被叫功能关闭。

条件桩：列出问题中的所有条件，列出的条件次序无影响。

动作桩：列出问题中可能采取的措施，操作的排列顺序无影响

条件项：条件桩的对应取值

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

3.3.3布尔值概念

布尔值只有两个取值，要么为真要么为假。1和0，true和false（python不区分大小写）

3.3.4判定表的形式：数字法和英文字母法

订单检查：

如果金额大于500，没有过期，发出批准单和提货单

如果金额大于500，过期，不允许发出批准和提货单

如果金额小于等于500，无论是否过期都会发出批准单和提货单

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

3.3.5适用场景

多条件组合

3.3.6案例

如果想对文件进行修改，输入的第一列字符必须是A/B，第二列字符必须是一个数字。

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

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

3.4因果图（非重点）

3.4.1基本符号

恒等关系：条件成立结果就成立，符号为-

非关系：条件成立，结果必不成立，结果是成立的。符号为：~

或关系：只要有一个条件成立，结果就成立，所有的条件都不成立，结果才不成立。符号为：v

与关系：多个条件必须同时成立，符合为：^

3.4.2设计测试用例的步骤

1. 需求分析

2. 画出因果图

3. 将因果图转化为判定表

4. 生成测试用例

3.4.3因果图和判定表的区别

先使用因果图绘制图像，再根据图完成判定表

在条件较少的情况下，推荐使用判定表

条件过多的情况下，使用因果图

3.4.4案例

3.5正交法

定义：用最小的测试用例获取最大的测试覆盖率

使用工具allpairs

4.0测试用例注意要点：

• 空值不包括空格，一般不允许出现钱输入的字符中前后有空格的情况，但是需要测试一下中间有空格的情况。

• 空格不属于特殊字符

• 小数点属于特殊字符，一般不会进行测试小数点，直接测试特殊符号就行了。

3.6场景法（流程图）

3.6.1定义

模拟用户在操作软件时的场景，主要用来测试多个功能之间的组合应用情况

3.6.2适用场景

集成测试，系统测试。验收测试。

3.6.3流程图常用的符号

开始结束：椭圆

路径：箭头

操作：矩形

判断：菱形

输入输出：平行四边形

3.6.4案例

缺陷管理

银行取款：

3.7错误推测法

概念：利用经验或者智慧发现程序中可能出现问题的地方

适用场景：重要功能

测试过相同类型的产品

任务紧的时候

新产品，市场上没有过相同的产品。

4.0缺陷

4.1定义

缺陷：软件在使用的过程中出现的任何问题，都叫软件缺陷。

4.2软件缺陷判定的标准

• 没有达到需求规格说明书指定的功能

• 实现需求规格说明书指定功能之外的额外功能

• 出现了需求规格说明书指明的不应该出现的问题

• 从用户角度发现的各种问题与错误。

• 没有达到 需求规格说明书虽然没有明确指出，但是应该实现的目标，比如后台cpu的占用，兼容性等等问题。

4.3软件缺陷出现的原因

需求阶段：需求描述不容易理解，不清晰，错误

设计阶段：设计文档出现问题或者缺陷

编码阶段：代码错误，开发人员

运行系统：软硬件系统本身导致的软件缺陷