软件测试 - 测试用例常见面试题

1.测试用例的要素

测试用例是为了实施测试而向被测试的系统提供的一组集合, 这组集合包含 : 测试环境, 操作步骤, 测试数据, 预期结果等要素.

例如 : 在 B 站输入框输入一个空格, 检查结果

测试用例

标题 : 输入框输入空格
测试环境 : Windows 系统, 谷歌浏览器-版本 111.0.5563.65（正式版本） （64 位）
操作步骤 :
1) 打开浏览器, 输入网址 : https://www.bilibili.com/
2) 在输入框中输入关键词, 回车展示结果
测试数据 : 空格
预期结果 : 不展示任何内容

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

2.1 设计测试用例的万能公式

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

功能测试 : 对产品的功能设计测试用例.
性能测试 : 极端情况: 高并发量, 响应时间等等. (功能测试没用问题不代表性能测试好)
界面测试 : 每个元素的大小, 颜色, 材质, 形状, 页面跳转等都需要进行测试.
兼容性测试 : 软甲的不同版本是否兼容, 不同的浏览器, 不同的系统版本, 数据兼容性等等.
易用性测试 : 产品是否具备简单易上手的属性.
安全测试 : 用户的隐私数据是否加密 (注册场景, 接口返回值, SQL 注入等等).

使用万能公式针对水杯设计一个测试用例

使用万能公式针对登录页面设计一个测试用例

兼容性测试里需要注意 : 不同的浏览器, 不同的版本可能会有非常非常的多, 难道所有的浏览器和版本我们都需要测试吗 ? 我们的选型标准是什么 ?

1. 测试大部分用户使用的浏览器
2. 在工作中是有数据后台可以检测到和管理大部分用户使用的浏览器, 版本或者手机型号, 参考数据管理平台给出的数据选型.

3. 基于需求进行测试用例的设计

基于需求设计测试用例是设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正
确、完整、无二义性，并且逻辑自洽。在需求正确的基础上再细化测试需求，从测试需求提炼出一个个测试点，然后根据每一个测试点进行测试用例的设计；

在分析测试需求时，一般分为功能测试需求和非功能测试需求

功能需求测试分析

功能测试需求主要是各个功能界面的验证, 功能的一致性, 交互性的测试, 功能的错误操作, 异常操作的测试, 用户操作的易用性, 用户体验, 往往结合功能测试同时验证等等.

非功能需求测试分析

非功能需求主要涉及性能, 安全性, 可靠性, 兼容性, 易维护性和可移植性等. 从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，比如安全性越高，就越有可能给易用性，性能带来更大的挑战.

4. 测试用例的具体设计方法

4.1 等价类

依据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题.

等价类的划分

1.有效等价类 - 需求文档的要求是有意义的集合.
2. 无效等价类 - 需求文档的要求是没有意义的集合.

例如针对一个 6~18 位的密码使用等价类方法设计测试用例, 具体步骤 :

1.确认有效等价类和无效等价类.

有效等价类 : 6~18位
无效等价类: 小于 6 位, 大于 18 位

2. 编写测试用例

1. 输入长度为 6~18 位的密码, 例如 : 10 位
2. 输入长度小于 6 位的密码, 例如 : 1 位
3. 输入长度大于 18 位的密码, 例如 : 20 位

4.2 边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等
价类划分法的补充，这种情况下，其测试用例来自等价类的边界.

边界值指的是有效边界 + 无效边界

4.3 判定表

使用场景 : 输入条件的组合对应不同的结果

判定表设计测试用例的步骤 :

1. 确认输入条件和输出条件
2. 找出输入条件和输出条件之间的关系
3. 画判定表
4. 根据判定表编写测试用例

测试案例 : 当某订单使用了红包或者订单金额大于 300 元, 则该订单是优惠订单, 否则是不优惠的订单

1.确认输入条件和输出条件

输入条件 : 红包(A) , 订单金额大于300元(B) , 订单已提交(C)
输出条件 : 有优惠(1) , 无优惠(2)

2. 找出输入条件和输出条件之间的关系

先确定输入条件之间可能的组合关系, 然后根据组合关系, 给出对应的输出结果.

AC BC ABC A B C AB 非ABC

1 1 1 2 2 2 2 2

3.画判定表

4. 根据判定表编写测试用例

1) 有红包并提交订单, 则该订单为有优惠的订单.

2) 金额大于 300 元并提交订单, 则该订单为有优惠的订单.

3) 有红包, 金额大于 300 元并提交订单, 则该订单为有优惠的订单.

4) 有红包, 订单金额小于 300 元, 不提交订单则该订单为无优惠订单.

5) 无红包, 订单金额大于 300 元, 不提交订单则该订单为无优惠订单.

6) 无红包, 订单金额小于 300 元, 提交订单, 则该订单为无优惠订单.

7) 有红包, 订单金额大于 300 元, 不提交订单则该订单为无优惠订单.

8) 无红包, 订单金额小于 300 元, 不提交订单则该订单为无优惠订单.

4.4 场景法设计法

可以比较生动地描绘出事件触发时的情景, 有利于测试设计者设计测试用例, 是测试用例更容易理解和执行. (思路引导作用)

例如拿 ATM 取款为例 :

编写测试用例 :

基本事件流的用例 : 先插卡, 输入正确的密码, 选择取卡功能, 输入金额 .......
备选事件流的用例 : 插卡插不进去, 输入错误的密码, 卡被 ATM 卡出, 退出来.....

4.5 正交排列法

正交排列法是从大量的试验中挑选出适量的, 有代表性的点, 依据 "正交表" 从而合理的设计出测试用例.

正交法的目的是为了减少用例数目, 用尽量少的用例覆盖输入的两两组合. (因为用例多的时候, 使用判定表法, 两两组合的情况是穷举不完的)

下图正交表的表示形式, L9(4^3)

9 代表 9 组实验
4 代表的是因素数
3 代表的是每个因素数对应的水平数 (输入条件的可能选项)

正交表的特性

1. 每一列中, 不同的数字出现的次数相等.
2. 任意两列中数字的排列方式齐全且均衡 (每个组合出现的次数相同, 例如第一列和第三列的第 2 行, 是 1,2 组合, 那么这两列组合的其他行就不会再出现 1,2 组合了)

案例 : 针对注册页面使用正交排列法设计测试用例.

设计测试用例的步骤 :

1. 找出因素数和水平数

因素 : 姓名, 电子邮箱, 密码, 确认密码, 验证码
水平 : 填写, 不填写

2. 使用 allpairs 工具生成正交表

a. 在excel 中写好对应的因素数, 和水平数
b. 在 pairs 工具的安装路径下找到 allpairs.exe, 然后在改路径下新建一个 txt 文件, 把excel 中写好的 因素数和水平数复制张贴到 txt 文件中.
c. 打开 cmd, 进入到刚刚新建的 txt 路径的商机路径中, 也就是 pairs. 执行命令
allpairs.exe 322.txt>322jg.txt (322.txt是我自己新建的txt文件, 322jg.txt 是待生成的正交表文 件, 不用自己创建)

allpairs 生成的正交表

生成的正交表虽然有些不符合正交表的特性 2, 但是问题不大.

3. 根据正交表编写测试用例

1. 全部填写姓名, 电子邮箱, 密码, 确认密码, 验证码.
2. 填写姓名, 不填写电子邮箱, 密码,确认密码, 验证码.
3. 填写电子, 确认密码, 不填写邮箱, 密码, 验证码.
4. 填写密码,验证码, 不填写姓名, 电子邮箱, 确认密码.
5. 填写姓名, 电子邮箱, 密码, 不填写确认密码, 验证码.
6. 填写确认密码, 验证码, 不填写姓名, 电子邮箱, 密码.

4. 补充可能存在遗漏的但是非常重要的测试用例

7.全部都不填写姓名, 电子邮箱, 密码, 确认密码, 验证码.

只有第一个用例是正常的用例.

4.6 错误猜测法

错误猜测法主要依赖测试人员的工作经验和积累.这个方法的缺点是难以系统化，并且过度依赖个人能力.

案例 : 以注册为例

1、校验中特殊字符空格的处理?
2、密码校验中的大小写？
3、姓名中的特殊字符？
4、密码发送是否明文

5. 白盒测试, 黑盒测试, 灰盒测试

黑盒测试 : 纯功能测试, 不关心程序具体是怎么实现的. (系统测试)
白盒测试 : 关注程序的内部实现 (单元测试)
灰盒测试 : 介于白盒测试和黑盒测试之间 (集成测试)

5.1 常见面试题

为什么不能让灰盒测试取代黑盒测试和白盒测试 ?

灰盒测试没有白盒测试那么详尽, 灰盒测试没有黑盒测试覆盖产品的广度大, 所以灰盒测试不能取代黑白盒测试.

哪种测试方法用的多 ?

黑盒测试和白盒测试, 测试人员都会使用到, 在工作中需要结合实际情况来定, 通过场情况下对于测试人员来说, 黑盒测试相对要多一些.