目录
10.4? 7位------->5位（从7个值中选取5个值）（从边界值范围中选取边界值）
七、软件的质量模型?
| 功能性 | 检查业务功能是否满足需求 |
| 可靠性 | 容错能力（恢复时间、恢复能力） |
| 易用性 | 看得懂，会使用 |
| 效率性 | 性能【响应时间、消耗的资源（cpu，内存）】 |
| 维护性 | 为后续功能的开发和维护提供便利 |
| 移植性 | 软件需要在不同的软件环境下和硬件环境下都能正常工作 |
| 信息安全性 | 信息在传输过程中或者存储过程中的安全程度 |
八、软件的测试用例
8.1 软件的测试用例的概念
一个为了特定目的（检验开发的代码实现是否满足用户的需求）而设计的文档，文档的形式可以是excel，xmind等
Test Case
8.2 模板
?
| ID | 唯一值 |
| 模块 | 测试用例所属的模块 |
| 优先级 | 作用：体现了测试用例的执行先后顺序 |
| 分类：高? 中? 低 | |
| p0：一般是保证软件中最重要、最主要的功能，保证最基本的流程能够正常运行而设计 | |
| p1：次要功能、小功能 | |
| p2：UI，边界，错误设置 | |
| p3：错误信息，较为复杂的场景，不常用的场景 | |
| 用例标题 | 唯一性，见名知意 |
| 预置条件 | 前提条件 |
| 测试步骤 | 要求：尽可能详细 |
| 测试数据 | 根据要求填写 |
| 预期结果 | 根据数据和步骤，预期的结果 |
| 测试结果 | pass |
| fail | |
| block? ? 由于存在bug不能继续执行填写 | |
| Na? ? ? ? ? 由于环境或者资源缺失导致不能执行 | |
| 测试版本号 | 当前测试任务所用的软件版本号 |
| 测试人员 | 略 |
| 备注 | fail 的用例问题和对应的bugID 要填写 |
| block / Na 需要在备注中填写原因 |
8.3?测试用例的作用
- 便于理清测试思路，确保需要覆盖测试的功能点无缺失
- 便于估计测试工作量
- 便于提前准备测试数据
- 便于把控测试的工作进度
- 便于回归测试
- 便于测试工作的组织，提高测试效率，降低测试的交接成本
8.4验证电脑
| ID | 目的 | 前提条件 | 操作步骤 | 预期结果 | |||
| 1 | 验证电脑开机 | 有电，无损 | 按开机键 | 开机 | |||
| 2 | 验证运行效率 | 开机有电 | 打开大型软件 | 流畅 |
九、等价类划分法（*）（设计测试用例的方法）
9.1 等价类划分法
9.1.2?数学表示形式
?9.1.2等价类划分法定义
?在所有的测试数据中，找到具有某种共同特征的数据子集
9.1.3?等价类划分法
- 有效等价类：满足条件的数据子集
- 无效等价类：不满足需求的数据子集
9.2?设计测试用例的步骤?
9.2.1 需求分析
9.2.2 划分等价类
| 有效 | |
| 无效 | 规则? 长度? 类型? 是否空值? 是否重复数据(即需求本身 长度本身 数据类型 空值 重复数据) |
9.2.3 设计测试用例
9.3案例?
案例1 qq账号：6-10位自然数?
???? ? ?
? 案例2 注册邮箱? ? ? ?
十、边界值分析法（*）（等价类划分法的补充）
10.1 边界范围的确定
选取正好等于，或者刚好大于，或者正好小于边界值的数据作为测试数据
10.2 上点、离点、内点
| 上点 | 边界上的点? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 必选 |
| 内点 | 区间范围内的点? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 必选，尽量选择中间范围的???????? |
| 离点 | 距离上点距离最近的点，刚好大于，正好小于? ? ? | 根据开闭情况选择 |
此时例如在9.4案例1中还需列出以下几种情况
10.3 边界值设计用例的步骤
1.明确需求
2.确定有效类和无效类
3.确定边界值范围
4.提取数据编写测试用例
10.4? 7位------->5位
（从7位数中选取5位数，7位－2位）（用于离点有问题时进行讨论）
10.5 设计测试用例的步骤
1.需求分析
2.划分等价类
3.确定边界
上点
内点
离点
7------>5）
4.设计测试用例
10.6使用场景
存在边界，有一定范围
比如：9-10、至少10位、大于等于、小于等于、等
十一、判定表（*）（多个条件的组合）
例如进地铁（有电 有网 有钱 健康码 口罩）
11.1 判定表的定义
一种以表格的形式，表达的多条件逻辑判断工具
存在多个输入条件，多个输出结果，输入和输出之间存在组合关系
输入条件和输出条件之间存在依赖关系
11.2 组成部分
11.2.1 基本概念
| 条件桩 | 列表当前问题中，所有的条件，次序没有影响，例如电量状态，绿码状态（标题） |
| 动作桩 | 列出当前问题中所有的可能性操作，没有次序影响，例如进地铁，不进地铁（最终的结果）（标题） |
| 条件项 | 列出条件对应的取值，所有可能性的真假值，就是有效等价类和无效等价类（标题对应的状态） |
| 动作项 | 列出条件项的各种取值情况下，对应采取的动作结果，基于各个条件的组合，得到确定的结果（标题对应的状态） |
11.2.2 条件项表达形式
条件项的概念：列出条件对应的取值，所有可能性的真假值，就是有效等价类和无效等价类
11.2.2.1 字符表达
有效等价类/真 Y
无效等价类/假 N
12.2.2.2数字表达形式
有效等价类/真 1
无效等价类/假 0
?
11.3 设计测试用例的步骤
1.明确条件桩（找到所有的输入条件）
2.明确动作桩（找到所有的输出结果）
3.对所有的条件桩进行全组合
4.明确每一个组合对应的动作桩
5.设计测试用例，每一条数据对应了一个测试用例
11.4 使用场景
多条件组合
十二、因果图
12.1 展示图
?
12.2基本符号
| V | 或 | 只要一个条件成立就可以 |
| ^ | 与 | 多个条件同时成立 |
| ~ | 非 | 条件成立，则结果不成立；条件不成立，则结果成立 |
| - | 恒成立 | 条件成立，结果成立 |
12.3 步骤
实例分析
产品说明书：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”、或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退还5角硬币。
（1）确定需求中的原因与结果
（2）确定原因与结果的逻辑关系
C1 与 C2 需要一个中间结果Cm1, C3、C4、C5 需要一个中间结果Cm2.
（3）确定因果图中的约束
C1 与 C2 是或的关系, C3、C4、C5 是或的关系。
（4）画出因果图并转化为决策表
决策表
将原因C1、C2、C3、C4、C5按二进制由小到大分别取值，并分析中间结果的成立与否，进而得出下面的简化版（即中间结果Cm1、Cm2成立的情况）
简化版
（5）根据决策表设计测试用例
1.需求分析
2.画出因果图
3.将因果图转换成判定表
4.生成对应的测试用例
十三、正交法
allpairs
13.1 定义
用最小的测试用例获得最大的测试覆盖率
13.2 正交表基本定义
因素：条件桩，输入的参数条件，比如电量、绿码
水平：条件项，每一个输入参数的取值，比如电量的水平是充足、无
13.3 使用步骤
1.需求分析分析
2.确定因素和水平
3.确定正交表
4.根据正交表，进行测试用例的书写，一条数据就是一条测试用例
十四、场景法
画流程图
14.1 定义
场景法，就是流程图法，使用流程图来描述用户的使用场景，然后通过流程图路径来设计测试用例
14.2 案例 点外卖
经过老师画流程图，发现整个过程是由商品模块，订单模块，支付模块进行组合在一起的
14.3 使用的测试阶段
集成测试
系统测试
验收测试
14.4使用步骤
1.需求分析
2.绘制流程图
3.根据流程图的每一条路径进行设计测试用例
十五、错误推测法
15.1 定义
根据经验和智慧进行分析，推测出程序中可能出现的错误
15.2 使用场景
同类型产品
任务紧
十六、 测试用例方法总结
1.具有输入功能，但是功能之间没有组合关系 等价类
2，输入具有边界，比如长度 边界值
3.具有多输入多输出，输入和输出之间具有组合管子 版定表，因果图
4.用最小的测试用例覆盖率最高 正交表
5.多个功能之间的组合测试 场景法
6.错误推测法作进一步的补充
十七、缺陷
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 软件缺陷的核心内容（重点）
| 标题 | 大概的描述软件缺陷的基本信息（eg：用户名5位，只展示3位） |
| 前置条件（预置条件） | 描述缺陷出现依赖的相关基础条件（eg：邮箱注册时密码用5位注册成功） |
| 复现步骤 | 测试用例中的执行步骤 |
| 实际结果 | 执行测试用例的执行步骤，系统给出的结果 |
| 预期结果 | 参照需求说明书，在测试用例中设计的预期结果 |
| 附件 | 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提交缺陷的注意事项
-
唯一性，一个缺陷只需要提交一次
-
保证可复现性
-
规范性
-
描述需要准确，有细节真实
17.7 关于缺陷的跟踪流程
17.7.1 场景
测试new------>开发open------>开发fix------>测试cloce
测试new------>开发open------>开发fix------>测试reopen
测试new------>开发open------>开发postpone
测试new------>开发open------>开发reject ?