继续学习测试小知识:一些正交法、场景法的使用13.0正交

13.0 正交法

13.1 定义

用最小的测试用例获得最大的测试覆盖率

13.2 基本定义

image.png
因素:条件桩,输入的参数条件,电量,绿码

水平:输入参数的取值充足,无就是电量的水平

13.3 使用步骤

1.需求分析

2.确定因素和水平

3.确定正交表

4.根据正交表,进行测试用例的书写,一条数据就是一条测试用例

14.场景法

画流程图

14.1 定义

场景法,就是流程图法,使用流程图来描述用户的使用场景,然后通过流程图路径来设计测试用例

14.2 案例 点外卖

14.3 使用的测试阶段

集成测试

系统测试

验收测试

14.4 使用步骤

1.需求分析

2.绘制流程图

3.根据流程图的每一条路径进行设计测试用例

15.错误推测法

15.1 定义

根据经验和智慧进行分析,推测出程序中可能出现的错误

15.2 使用场景

同类型产品

任务紧

16.测试用例方法总结

1.具有输入功能,但是功能之间没有组合关系 等价类

2.输入具有边界,比如长度 边界值

3.多输入,多输出,输入和输出之间具有组合关系,判定表,因果图

4.用最小的测试用例覆盖率最高,正交表

5.多个功能之间的组合测试 场景法

6.错误推测法做进一步的补充

17.软件缺陷

17.1 定义

软件在使用的过程中存在的任何问题(错误,异常等),都叫做软件缺陷,简称bug

订单完成 ----->付钱  10支   90块钱
total = 90 
total = 9    --->
付款成功
发货
id    -------->查询单价
num = 10
复制代码

17.2 软件缺陷的判定标准

17.2.1 软件未实现需求说明书中明确要求的功能

17.2.2 软件出现了需求说明书中指明的不应该出现的错误

17.2.3 软件实现了超出需求说明书中的功能

17.2.4 软件未实现需求文档中未指明但是又应该实现的功能

17.2.5 用户体验不好,界面不漂亮,易用等

17.3 软件缺陷出现的原因

17.3.1 编码

代码出错

17.3.2 运行系统

软硬件系统本身故障导致的软件缺陷

17.3.3 设计问题

设计文档出现错误或者缺陷

17.3.4 需求阶段

需求描述有歧义

17.3.5 软件本身很复杂

17.4 软件缺陷的核心内容(重点)

标题 描述软件缺陷的基本信息,列如(用户名5位,只展示3位)
前置条件 描述缺陷出现依赖的相关基础条件
复现步骤 测试用例里的执行步骤
实际结果 执行测试用例的执行步骤,系统给出的错误
预期结果 参照需求说明书,在测试用例中设计的预期结果
附件 bug截图或者出错的日志信息,方便定位bug

17.5 缺陷的基本要素(重点)

17.5.1 ID

唯一

17.5.2 模块:

根据产品进行具体的划分,支付模块,订单模块等

17.5.3 缺陷状态

类型 说明
new 新建
open 打开
fix 已经修复
postpone 延期
reject 拒绝
close 关闭
reopen 重新打开

17.5.4 缺陷的严重程度

从技术上衡量bug的破坏力

说明 等级 类型
致命 5 critical
非常高 4 major
3 medium
2 minor
1 tiny

17.5.5 缺陷的优先级

处理缺陷的优先程度

类型 等级
紧急 5
非常高 4
3
2
1

17.5.6 缺陷类别

功能错误

UI界面错误

兼容性错误

易用性

改进意见

17.6 提交缺陷的注意事项

1.唯一性,一个缺陷只需要提交一次

2.保证可复现性,

3.规范性

描述需要准确,有细节真实

17.7 缺陷跟踪流程

17.7.1 场景

测试new ------>开发open------>开发fix ---->测试close

测试new -------->开发open-------> 开发fix --------->测试reopen

测试new ------->开发open ------->开发postpone

测试new ------->开发Open-------->开发reject