当前位置：首页 > news >正文

软件测试用例篇

news 2025/7/3 22:54:46

设计测试用例是测试面试的必考题,务必好好学

1. 测试用例

测试用例的概念

测试⽤例（Test Case）是为了实施测试而向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

设计测试⽤例的第一个原则：

测试⽤例中⼀个必需部分是对预期输出或结果进⾏定义

举个例子:

软件中涉及到的特性很多,我们无法单凭想象来完成一次完整的测试,因此我们需要编写测试用例,通过编写测试用例我们可以想到要测试哪些内容,通过一次又一次的更新修改把测试用例写到完成,功能覆盖率更高.

编写测试用例的要素

我们先来看一下一个测试用例的编写方式.编写测试用例的要素: 标题,测试环境,测试数据,测试步骤,期望结果

很早之前使用excel来编写,而现在一般使用思维导图或者脑图来写.笔试的时候需要按照excel表格的形式来答题(会涉及测试用例的要素),而面试的时候回答测试用例,需要按照思维导图的方式来回答(不会涉及测试用例的要素)

编写测试用例的形式

excex形式

思维导图形式

2. 设计测试用例的万能思路

错误案例:

现在有⼀款产品，要求我们对“⻔锁”设计测试⽤例，假如你是测试⼈员，你会怎么设计呢？

这个测试用例不够具体,太笼统了.工作中,测试用例的设计不是越多越好,而是能够达到更大的功能覆盖则是更好的.(学习中,设计测试用例越多越好,这是考察我们的思维发散能力)

正确的设计测试用例的思想:

常规思维+逆向思维(用尽各种办法证明是有bug的)+发散性思维

设计测试用例的第二个原则:

1.测试⽤例的编写不仅应当根据有效和预料到的输⼊情况，⽽且也应该根据⽆效和未预料到的输⼊情况。

2.检查程序是否“未做其应该做的”仅是成功的⼀半，测试的另⼀半是检查程序是否“做了其不应该做的”(使用特殊字符,比如sql注入,看是否能登录成功)。（是上⼀条原则的必然结果）

3.计划测试⼯作时不应默许假定不会发现错误。

打开思维之后, 设计测试用例是想到一条说一条,我们需要思维的引导才可以把数量提上去.

比如说出家里的电器:

而我们的万能公式就是起到这个作用,此时我们介绍万能公式

万能公式:

功能测试+界⾯测试+性能测试+兼容性测试+易用性性测试+安全测试

每个测试具体的意思

1> 功能测试: 从产品功能角度出发,验证功能是否正确(参考需求文档,比如登录,我们的账号密码是采用数字,下划线,字母....长度多少,是否为必填项)

2> 界面测试: 肉眼可以看到的部分都为界面.界面设计到的内容: 元素(大小,颜色,形状,材质(可以触摸到的))(比如门锁,如果是电子锁,它有没有数字,数字大小颜色是否合适..)

3> 性能测试: 通常为一些极端的情况(比如门锁,我们测试在极寒或者极热的情况下它的表现如何)

功能测试和性能测试的区别:

比如名牌车和一般品牌的车,它们都能实现开车这个功能,但是百米加速所耗费的时间名牌短一些(这个就是性能)

4> 兼容性测试: 不同的版本(软件,系统),浏览器的兼容性(同一个浏览器上不同版本打开我写的系统)不同浏览器(不同浏览器上打开我的系统),(比如谷歌浏览器是否能在苹果,联想,win10,win11...上打开),还有数据的兼容性(场景 : 可以进行手机号注册,可以进行微信注册,邮箱注册...邮箱注册之后,个人手机号是否可以登录)

数据的兼容性例子

5> 易用性测试: 具备简单易上手的属性(比如: 购物软件,我们很容易就知道怎么下单,怎么购买.或者这个软件有引导教程)

6> 安全性测试: 是否具备危险材质(门锁,用的材质是否伤身,sql注入,我们的账号密码,密码是不会显示出来的这个是脱敏展示,也是为了安全,再比如接口响应数据也要考虑到用户数据的安全性,登登录场景也需要将密码进行加密展示)

sql注入演示:

越权: 比如写博客我们修改一下我们url里面的参数就能看到别人写的博客

应用:

水杯测试

除了万能公式之外，还有⼀个⽐较常⽤的测试类型：弱⽹测试、安装卸载测试

弱网测试

分别用wife,2G,3G,5G网来看页面加载速度如何(在不同网络情况下,页面的加载如何)

弱⽹测试的⽬的就是尽可能保证用户体验，关注的关键点包括：

        • ⻚⾯响应时间是否可以接受，关注包括热启动、冷启动时间、⻚⾯切换、前后台切换、⾸字时间，⾸屏时间等。

        • ⻚⾯呈现是否完成⼀致(不管网速如何,大部分的页面要展示出来)。

        • 超时⽂案是否符合定义，异常信息是否显⽰正常。

        • 是否有超时重连。

        • 安全⻆度：是否会发⽣dns劫持、登陆ip更换频繁、单点登陆异常等。

        • ⼤流量事件⻛险：是否会在弱⽹下进⾏更新apk包、下载⽂件等⼤流量动作。

演示:

该图来自于CSDN @软件测试情报局

如何进行弱网测试

弱⽹需要借助⼯具来构造弱⽹，这⾥推荐使⽤fiddler

1）fiddler配置代理

2）fiddler进⾏抓包（桌⾯/移动端）

3）fiddler如何构造弱⽹条件

设置的数字越大,网速越慢安装卸载测试

针对需要进⾏部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载(xmind,王者荣耀,微信...这些软件都会涉及到安装和卸载)

安装: 安装包是否可以安装,卸载后是否可以继续安装,重复安装,软件更新后是否安装成功...

卸载: 安装完成后卸载,安装一半后卸载,卸载后安装继续卸载,卸载停止后是否还可以继续卸载...

3. 设计测试用例的方法

基于需求的测试方法

测试和开发工作展开的依据: 软件需求(需求文档/产品规格说明书)

以该注册邮箱账号需求为例，我们来设计测试⽤例

1> 明确需求中的功能点(账号注册,账号登录)

2> 结合万能公式来设计测试用例

具体的设计方法

刚刚我们设计注册邮箱账号的测试用例只是初步设计的,而部分用例还需要细化,比如下面这个图,我们测试姓名,我们规定的字符数是需要全部测吗(6-15位每一个都测一下),当然不是,此时我们就需要借助具体的设计方法.

等价类

依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，如果这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

等价类主要分为俩种: 有效等价类和无效等价类.比如我们设计上面的姓名,我们设计有效等价类(我们设计>=6,<=15),无效等价类(<6,>15).

具体解释:

• 有效等价类：对于程序的规格说明书是合理的、有意义的输⼊数据构成的集合，利⽤有效等价类验证程序是否实现了规格说明中所规定的功能和性能

• ⽆效等价类：根据需求说明书，不满⾜需求的集合

根据等价类来设计测试用例的方法

1> 确定有效等价类和⽆效等价类(有效等价类: 我们设计>=6,<=15,无效等价类:我们设计<6,>15)

2>编写测试⽤例，设计具体测试数据

此时我们就可以扩展出来:

等价类只考虑输⼊域的分类，没有考虑输⼊域的组合，需要其他的设计⽅法和补充。

边界值

边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。

边界值包含: 边界值(给定范围的左数据和右数据)+次边界值(根据边界值的有效无效来选)

次边界值的选法

1> 如果边界值为有效等价类中的数据,则次边界值为无效等价类中的边界

2> 如果边界值为无效等价类中的数据,则次边界值为有效等价类中的边界

比如:

1) 有效范围是[6,15]

边界值: 6,15(有效)

次边界值:5,16(无效)

2) 有效范围是(6,15)

边界值: 6,15(无效)

次边界值:7,14(有效)

我们使用上述方法进一步完善:

场景法

现在的软件⼏乎都是⽤事件触发来控制流程的，事件触发时的情景便形成了场景，而同⼀事件不同的触发顺序和处理结果就形成事件流(步骤一触发步骤二,步骤二触发步骤三...).同一事件,不同的触发顺序和处理结果就形成了多个事件流.

场景法师一种通过运⽤场景来对系统的功能点或业务流程的描述，从⽽提⾼测试效果的⼀种⽅法。。我们通常以正常的⽤例场景分析开始，然后再着⼿其他的场景分析。场景法⼀般包含基本流和备⽤流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流(基本事件流)和备⽤流(备用事件流)来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

比如逛街买衣服,选择不同,事件流就不同

该⽅法可以⽐较⽣动地描绘出事件触发时的情景，有利于测试设计者设计测试⽤例，是测试⽤例更容易理解和执⾏。

比如刚刚的注册,我们也可以这么分析:

确认完基本流和备用流后,我们编写测试用例

1> 基本流: 点击注册入口,同意协议,输入正确的信息,点击注册,成功激活

2> 备用流: 点击注册入口,不同意协议,重新点击注册入口同意协议,输入正确的信息,点击注册,成功激活.

3> 备用流: 点击注册入口同意协议,,重新点击注册入口同意协议,输入错误的信息后重新输入正确的信息,点击注册,成功激活.

....

场景法在工作中的需求评审和设计测试用例中常用.

正交表法

引入

当前还剩下⼀个场景的⽤例未补充完成，“只填写部分选项”
这⾥到底要设计多少测试⽤例呢？通常来说，为了保证系统的测试覆盖率，我们⾸先能够想到的就是排列组合。

假如当前有两个选项A和B，可以设计出都填写、都不填写、填写A、填写B四个测试⽤例（2²）。假如当前有三个选项A、B、C，通过设计可以得到8个测试⽤例（2³）

......

当前可选的选项是5个，分别是，姓名、电⼦邮箱、密码、确认密码、验证码。按照排列组合设计出来的⽤例是32个.....

正交法的⽬的是为了减少⽤例数⽬。⽤尽量少的⽤例覆盖输⼊的两两组合

概念:

正交试验设计(Orthogonal experimentaldesign)是研究多因素多⽔平的⼀种设计⽅法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的⽔平组合。正交试验设计是⼀种基于正交表的、⾼效率、快速、经济的试验。

正交表

L4(2^3)是最简单的正交表,L标识值的是正交表,4表示行数,2表示水平数,3表示因素数

因素:存在的条件

水平:因素的取值

这个表是L12(2^11)

正交表的特性

• 每⼀列中，不同的数字出现的次数相等(一列中每个数字出现的次数是相同的)

• 任意两列中数字的排列⽅式⻬全⽽且均衡(每一列每个数字出现的次数是相同的)

设计正交表的步骤

借助工具来实现正交表:allpairs

1> 根据因素找到因素和水平

2> 把因素和水平写到excel表格中

3> 在allparis.exe同级文件夹下创建一个txt文件,把excel表格中的内容复制进去,然后进行保存.

4> 使用allparis.exe对txt文件生成正交表文件

打开cmd,进入到: allpairs.exe test01.txt > res-test01

生成的正交表如下: ~表示可以是任意选项:填写/不填写

5> 根据生成号的正交表来编写测试用例(继续把重要的用例补全)

1. 姓名填写,电子邮箱填写,密码填写,确认密码填写,验证码填写

2. 姓名填写,电子邮箱不填写,密码不填写,确认密码不填写,验证码不填写

3. 姓名不填写,电子邮箱填写,密码不填写,确认密码不填写,验证码不填写

4. 姓名不填写,电子邮箱不填写,密码填写,确认密码不填写,验证码填写

5. 姓名填写/不填写,电子邮箱填写,密码填写,确认密码不填写,验证码不填写

6. 姓名填写/不填写,电子邮箱不填写,密码不填写,确认密码填写,验证码填写

7. 姓名不填写,电子邮箱不填写,密码不填写,确认密码不填写,验证码不填写(这一条是补充的)

若不使用excel,而是直接手动在txt文件中编写因素和水平,使用命令生成正交表会存在格式校验错误的情况,allparis工具对格式的要求非常严格

allpairs生成的正交表和实际的正交表会有出入但是不影响

判定表法

通过具体的⽅法能够将测试⽤例设计的更加完整和规范。

需求中会存在各种各样的场景，现在我们把需求改成如下的要求：

用户输⼊的账号中包含admin字符，或者通过内部链接进⼊注册⻚⾯，提交注册按钮成为管理员⾝份；反之⽆管理员⾝份.(账号内部包含admin字符||内部链接进入注册页面 + 提交注册按钮就是管理员.反之不包含admin字符||非内部链接进入注册页面||未点击注册按钮就没有管理员身份)

通过这个需求可以看出，不同的组合操作可能对应不同的结果。采⽤正交法⽆法解决这样的问题。⽽正交法能够解决需要考虑输⼊之间的组合关系对应不同结果的场景。

判定表:

判定表是⼀种表达逻辑判断的⼯具，形如下图,我们可以知道不同的组合对应的结果是不一样的(它很容易编写出测试用例)

根据判定表法设计测试⽤例的步骤：

        1> 确认需求中输⼊条件和输出条件

        2> 找出输⼊条件和输出条件之间的关系

        3> 画判定表

        4> 根据判定表编写测试⽤例

例子:

账号内部包含admin字符||内部链接进入注册页面 + 提交注册按钮就是管理员.

反之不包含admin字符||非内部链接进入注册页面||未点击注册按钮就没有管理员身份

在这里面

1> 确认需求中输⼊条件和输出条件

输入: 账号包含admin字符,内部链接进入注册页面,提交注册按钮

输出: 管理员/无管理员

2> 找出输⼊条件和输出条件之间的关系(通过对输入条件的组合找出不同组合对应的结果)

3> 画判定表

4> 根据判定表编写测试⽤例

1. 账户包含admin字符,提交注册按钮,成为管理员账号

2. 内部链接进入注册,提交注册按钮,成为管理员账号

3. 账户包含admin字符,不提交注册按钮,不成为管理员账号

4. 账户包含admin字符,从内部链接进入注册,提交注册按钮,成为管理员账号

5. 账户不包含admin字符,不从内部链接进入注册,不提交注册按钮,不成为管理员账号

6. 账号包含admin字符,不提交注册按钮,不成为管理员账号

7. 内部链接进入注册,不提交注册按钮,不成为管理员账号

8. 只提交注册按钮,不成为管理员账号

错误猜测法

这个方法往往是根据个人的直觉和经验,推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。 错误推测法和⽬前流⾏的“探索式测试⽅法(边测边找)”的基本思想⼀致，这类⽅法在敏捷开发模式下的投⼊产出⽐高，被⼴泛应⽤于测试。

当我们⼀提到某个⾮常熟悉的⼈的名字，脑海会⽴刻浮现对他的评价.比如张三(法外狂徒)

再比如,我们提到了密码,我们就会想到:是否加密,是否具备安全性.获取用户输入(是否存在SQL注入的情况).软件存在多个版本(多个版本都要测试).活动每个月都存在但是每个月的奖励不一样(在保留当月活动的情况下,更新下一个月的活动,也就是要兼容前面月份的活动)

这个⽅法的缺点是难以系统化，并且过度依赖个⼈能力.

一般我们测一个系统我们会这么测