1 软件的质量模型

功能性	检查业务功能是否满足需求
可靠性	容错能力(恢复时间，恢复能力)
易用性	看得懂，会使用
效率性	性能(响应时间，消耗的资源(CPU,内存))
维护性	为后续功能的开发和维护提供便利
移植性	软件需要在不同的软件环境下和硬件环境下都能正常工作
信息安全性	信息在传输过程中或者存储过程中的安全程度

2 软件的测试用例概念

2.1 概念

一个为了特地的目的而设计的文档，文档的形式可是是excel，xmind等，

Test Case

2.2 模板

• ID: 唯一值

• 模块： 测试用例所属的模块

• 优先级：

  • 作用：体现了测试用例的执行先后顺序
  • 分类：高 中 低
    • P0:一般是保证软件中最重要、最主要的功能，保证最基本的流程能够正常运行而设计的
    • P1：次要功能，小功能
    • P2：UI,边界，错误设置
    • P3：错误信息，较为复杂的场景，不常用的场景

• 用例标题：

  唯一性

  见名知意

• 预置条件： 前提条件

• 测试步骤：

  要求：尽可能详细

• 测试数据： 根据要求填写

• 预期结果： 根据数据和步骤，预期的结果

• 测试结果： pass fail block 由于存在bug不能继续执行填写 Na 由于环境或者资源缺失导致不能执行

• 测试版本号： 当前测试任务所用的软件版本号

• 测试人员： 略

测试用例的作用

1. 便于理清测试思路，确保需要覆盖测试的功能点无缺失
2. 便于估计测试工作量
3. 便于提前准备测试数据
4. 便于把控测试的工作进度
5. 便于回归测试
6. 便于测试工作的组织，提高测试效率，降低测试的交接成本

等价类划分法

1 步骤

• 需求分析、
• 划分等价
  • 有效等价类(满足需求的数据子集）
  • 有效数据
  • 无效等价类（不满足需求的数据子集：需求本身、长度本身、数据类型、空值、重复数值）
  • 无效数据

案例 ：验证qq号

2适用场景

• 具有典型的输入框场景
  • 邮箱注册、用户注册

边界值划分法

1 边界范围的确定

选取正好等于或者刚好大于或者正好小于边界值的确定作为测试数据，是等价类划分法的一个补充。

2上点 离点 内点

上点	边界上的点
内点	区间范围内的点
离点	距离上点距离最近的点，刚好大于，正好小于

3 边界值设计用例的步骤

• 明确要求
• 确定有效类和无效类
• 确定边界值范围
• 提取数据，编写测试用例

7位——————5位

5 适用场景

• 存在边界，有一定的范围
  • 例如只有9-20，至少有10位，大于等于、小于等于等

判定表

1 定义：

• 是一种以表格形式表达的多条件逻辑判断的工具
  • 存在多个输入条件，多个输出结果，输入和输出之间存在组合关系
  • 输入条件和输出条件之间存在以来关系

2 组成部分

条件桩	列出当前问题中，所有的输入条件，次序没有影响	例如电量状态、绿码状态
动作桩	列出当前问题中所有的可能性操作，没有次序的影响	例如进地铁不进地铁
条件项	列出条件对应的取值，所有可能性的真假值（用字符true,false,huo 数字0，1来表示）	就是有效等价类、无效等价类
动作项	列出条件项的各种取值情况下，对应采取的动作结果	基于各个条件的组合，得到确定的结果

• 案例

3条件项的表达形式

3.1条件项的概念

列出条件对应的取值，所有可能性的真假值，就是有效等价类、无效等价类

3.1.1 字符表达

• 有效等价类/真 Y
• 有效等价类/假 N

3 设计测试用例的步骤

1.明确所有的条件桩（找到所有的输入条件）

2.明确动作桩（找到所有的输出结果）

3.对所有的条件桩进行全组合

4.明确每一个组合对应的动作

5.开始设计测试用例，每一条数据对应了一个设计用例

4 适用场景

• 多条件组合

因果图

1 展示图

2 基本符号：

• 与或非关系 | | | | | - | --- | ----------------------- | | V | 或 | 只要一个条件成立就可以 | | ^ | 与 | 多个条件同时成立 | | ~ | 非 | 条件成立，则结果不成立；条件不成立，则结果成立 | | - | 恒成立 | 条件成立，结果成立 |

3 步骤

• 先要需求分析，再画出因果图，在将因果图转化成判定表，最后生成对应的测试用例

实例分析

• 产品说明书：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”、或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退还5角硬币。

1. 确定需求中的原因与结果

2. 确定原因与结果的逻辑关系C1 与 C2 需要一个中间结果Cm1, C3、C4、C5 需要一个中间结果Cm2.

3. 确定因果图中的约束C1 与 C2 是或的关系, C3、C4、C5 是或的关系。

4. 画出因果图并转化为决策表

正交法

1 定义

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

2 基本定义

• 因素：条件桩，输入的参数条件，电量、绿码
• 水平：输入参数的取值充足，无就是电量的水平

3 使用步骤

• 需求分析
• 确定水平和因素
• 确定正交表
• 根据正交表进行测试用例的书写，一条数据就是一条测试用例

4 案例 正交表

场景法

1 定义

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

2 案例点外卖

graph TD
A[打开美团] --> B[打开美团]
B --> C[选择喜欢的午饭]
C-->D[点击提交订单]
D-->E[选择配送地址]

3 使用的测试阶段

• 集成测试
• 系统测试
• 验收测试

4 使用步骤

1. 需求分析
2. 绘制流程图
3. 根绝流程图的每一条路径设计测试用例

错误推测法

1 定义

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

2 使用场景

• 同类型产品
• 任务紧

测试用例方法总结

1. 具有输入功能，但是功能之间没有组合关系，--->等价类
2. 输入具有边界，比如长度--->边界值
3. 多输入、多输出输入和输出之间具有组合关系--->判定表。因果图
4. 用最小的测试用例覆盖率最高--->正交法
5. 多个功能之间的组合测试--->场景法
6. 错误推测法做进一步的补充

软件缺陷

1 定义

• 软件在使用的过程中存在的任何问题（错误，异常等），都叫做软件缺陷。简称bug。

2 软件缺陷的判定标准

• 软件未实现需求文档中需求说明书中明确要求的功能
• 软件出现了需求说明书中指明的不应该出现的错误
• 软件实现了超出需求说明书中的功能
• 软件未实现需求文档中未指明但是又应该实现的功能
• 用户体验不佳，界面不美观，不易用等

3 软件缺陷出现的原因

• 编码
  • 代码出错
• 运行系统
  • 软硬件系统本身的故障
• 设计问题
  • 设计文档出现错误或者缺陷
• 需求阶段
  • 在需求阶段出现沟通问题，需求描述有歧义
• 软件本身很复杂

软件缺陷的核心内容

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

缺陷的基本要素

• ID ：唯一性
• 模块 ：根据产品进行具体的划分，支付模块，订单模块等。
• 缺陷状态：

new	新建
open	打开
fix	已经修复
postpone	延期
reject	拒绝
close	关闭
repone	重新打开

• 缺陷的严重程度：从技术上衡量bug的破坏力

致命	5	critical
非常高	4	major
高	3	medium
中	2	minor
低	1	tiny

• 缺陷的优先级：处理缺陷的优先程度 | | | | ----- | ----- | | 紧急 | 5 | | 非常高 | 4 | | 高 | 3 | | 中 | 2 | | 低 |1 |
• 缺陷类别
  • 功能错误
  • UI界面出现错误
  • 兼容错误
  • 易用性
  • 改进意见

提交缺陷的注意事项

• 唯一性，一个缺陷只提交一次
• 保证可复现性
• 保证规范性
  • 描述需要准确，有细节真实

关于缺陷的跟踪流程

1 场景

1.1 测试new----->开发open----->开发fix----->测试close
1.2 测试new----->开发open----->开发fix----->测试reopen
1.3 测试new----->开发open----->开发post
1.4 测试new----->开发open----->开发reject