文章目录
测试理论
什么是软件：控制计算机硬件的工具，基本组成如下：
什么是软件测试：使用技术手段保障软件质量
- 需求产生 – 需求文档 – 设计效果图 – 产品开发 – 产品测试 – 部署上线
- 主流技能包含：
- 功能测试 ： 测试是否能输出文档中对应的结果
- 自动化测试 ：写代码自动测试 + 写测试报告
接口测试：通过代码或工具验证单人访问- 性能测试 ： 通过代码或工具验证多人访问
软件测试分类：单元测试、集成测试、系统测试、验收测试；黑盒测试、灰盒测试、白盒测试
- 按阶段划分：单元测试、集成测试、系统测试、验收测试
- 单元测试：针对程序源代码、一般开发自己测试
- 集成测试：针对模块之间访问地址进行测试，又称
接口测试，- 系统测试：针对整个系统的功能、非功能进行测试
- 验收测试：使用不同人群发掘项目缺陷 – 主要分为内测，公测
- 按代码可见度划分：黑盒测试 (功能测试)、灰盒测试 (
接口测试)、白盒测试 (单元测试)
测试模型之质量模型：衡量一个优秀软件的维度
功能性、性能（服务器每秒处理请求数，服务器硬件配置是否满足）、兼容性(不同浏览器、不同操作系统、不同手机等)、易用性(简洁、友好、流程、美观)、可靠性(无响应问题、卡顿问题、死机问题)、安全(信息传输、信息存储)、可维护性、可移植性（网站数据迁移）- 根据质量模型中的点启发 – 测试点的设计
软件测试流程：需求评审、测试计划与方案、测试用例设计、用例执行、缺陷管理、测试报告
- 需求评审：确保各部门需求理解一致
- 计划编写：测什么、谁来测、怎么测
- 用列设计：验证项目是否需求的操作文档
- 用例执行：项目模块开发完成开始执行用例文档实施测试
- 缺陷管理：对缺陷进行管理的过程
- 测试报告：实施测试结果文档
用例： 用户使用的案例
测试用例：为测试项目设计的执行文档
测试用例八大要素：用例编号、用例标题、项目/模块、优先级、前置条件、测试步骤、测试数据、预期结果
- 用例编号：项目_模块_编号
- 用例标题：预期结果 (测试点)
- 项目/模块：所属的项目或模块
- 优先级：重要程度或者影响力 P0~P4 (P0 最高，用户使用频率最高的)
- 前置条件：执行此条用例，有哪些前置操作
- 测试步骤：描述操作步骤
- 测试数据：操作的重点数据，没有的话为空
- 预期结果：期望达到的结果
测试用例设计方法示例
一、 穷举场景（等价类划分法）
- 典型：页面的输入框测试
【需求】 用户名输入框：长度 6~12 个字符，只能包含字母和数字，首字符必须是字母
【划分】根据特征：长度、字符类型、首字符规则 → 等价类划分
| 特征 | 有效等价类 | 无效等价类 |
|---|---|---|
| 长度 | 6~12 个字符 | 小于 6 / 大于 12 |
| 类型 | 仅字母或数字 | 含特殊字符 |
| 首字符 | 首字符为字母 | 首字符为数字 / 特殊字符 |
【用例】（有效取1，每个无效取1）
| 用例编号 | 用例标题 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
|---|---|---|---|---|---|---|
| 登录_输入框_001 | 用户名符合规则 (6个有效字符) | P0 | 系统正常运行 | 1.输入用户名， 2.提交 | abc123 | 提交成功 |
| 登录_输入框_002 | 用户名长度不足 (4个有效字符) | P1 | 系统正常运行 | 1.输入用户名， 2.提交 | ab12 | 提示长度不足 |
| 登录_输入框_003 | 用户名长度超限 (13个有效字符) | P1 | 系统正常运行 | 1.输入用户名， 2.提交 | abc1234567890 | 提示长度超限 |
| 登录_输入框_004 | 用户名含特殊字符 (6个含无效字符) | P1 | 系统正常运行 | 1.输入用户名， 2.提交 | abc@@1 | 提示非法字符 |
| 登录_输入框_ 005 | 用户名首字符非字母 (6个含首字母数字) | P1 | 系统正常运行 | 1.输入用户名， 2.提交 | 1abc12 | 提示首字符错误 |
二、 边界限制（边界值分析法）
- 典型：输入框值判定
【需求】 年龄输入框要求输入整数，范围 18~60（含边界）
【划分】 根据特征：字符类型 → 等价类划分
【用例】 根据关键边界：18、60： 分别取等于边界（上点 * 2）、离边界最近的值 （离点 * 4）、边界内的值（内点 * 1）
| 用例编号 | 用例标题 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
|---|---|---|---|---|---|---|
| 登录_输入框_000 | 不合法（年龄非整数） | P1 | 系统正常运行 | 1.输入年龄，2.提交 | H | 提示年龄非整数 |
- 上面这条用例结合了等价类划分，因为边界值分析法无法测试类型缺陷；所以和等价类划分法结合使用
| 用例编号 | 用例标题 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
|---|---|---|---|---|---|---|
| 登录_输入框_001 | 不合法（年龄小于最值一位 – 离点） | P0 | 系统正常运行 | 1.输入年龄，2.提交 | 17 | 提示超出范围 |
| 登录_输入框_002 | 合法（年龄等于最小值 – 上点） | P0 | 系统正常运行 | 1.输入年龄，2.提交 | 18 | 提交成功 |
登录_输入框_003 | 合法（年龄大于最小值一位 – 离点） | P0 | 系统正常运行 | 1.输入年龄，2.提交 | 19 | 提交成功 |
| 登录_输入框_004 | 合法（ 年龄在区间内 – 内点） | P0 | 系统正常运行 | 1.输入年龄，2.提交 | 39 | 提交成功 |
登录_输入框_005 | 合法（年龄小于最大值一位 – 离点 ） | P0 | 系统正常运行 | 1.输入年龄，2.提交 | 59 | 提交成功 |
| 登录_输入框_006 | 合法（年龄等于最大值 – 上点） | P0 | 系统正常运行 | 1.输入年龄，2.提交 | 60 | 提交成功 |
| 登录_输入框_007 | 不合法（年龄超过最大值一位 – 离点） | P0 | 系统正常运行 | 1.输入年龄，2.提交 | 61 | 提示超出范围 |
- 进一步，根据 【开内闭外原则】，上述
标红的用例可以省略不测；因为其所属类型已被上点包含，所以可以被优化 【7项 →5项】
三、 多条件依赖场景（判定表法）
- 典型：输入框值判定
【需求】 优惠券发放规则： 根据是否会员（是/否） & 购物金额 ≥ 100 元（是/否） & 是否节日（是/否）
- 会员 & 满100 & 节日 → 50元券
- 会员 & 满100 & 非节日 → 30元券
- 会员 & 不满100 → 10元券
- 非会员 & 节日 → 5元券
- 其他 → 不送券
【划分】 组合全部条件 → 判定表覆盖所有分支
【用例】 对于判定表中的每一项，设计一个测试用例
| 用例编号 | 用例标题 | 优先级 | 前置条件 | 测试步骤 | 测试数据（会员/金额/节日） | 预期结果 |
|---|---|---|---|---|---|---|
| 购物软件_优惠券_001 | 50元券 (会员 + 满100 + 节日) | P0 | 系统正常运行 | 模拟下单 | 是 / 是 / 是 | 50元券 |
| 购物软件_优惠券_002 | 30元券 (会员 + 满100 + 非节日) | P0 | 系统正常运行 | 模拟下单 | 是 / 是 / 否 | 30元券 |
| 购物软件_优惠券_003 | 10元券 (会员 + 不满100 + 节日) | P0 | 系统正常运行 | 模拟下单 | 是 / 否 / 是 | 10元券 |
| 购物软件_优惠券_004 | 10元券 (会员 + 不满100 + 非节日) | P0 | 系统正常运行 | 模拟下单 | 是 / 否 / 否 | 10元券 |
| 购物软件_优惠券_005 | 5元券 (非会员 + 满100 + 节日) | P0 | 系统正常运行 | 模拟下单 | 否 / 是 / 是 | 5元券 |
| 购物软件_优惠券_006 | 不送券 (非会员 + 满100 + 非节日) | P0 | 系统正常运行 | 模拟下单 | 否 / 是 / 否 | 不送券 |
| 购物软件_优惠券_007 | 5元券 (非会员 + 不满100 + 节日) | P0 | 系统正常运行 | 模拟下单 | 否 / 否 / 是 | 5元券 |
| 购物软件_优惠券_008 | 不送券 (非会员 + 不满100 + 非节日) | P0 | 系统正常运行 | 模拟下单 | 否 / 否 / 否 | 不送券 |
四、 业务场景（场景流程图法） （最重要，
首测）
- 典型：输入框值判定
【需求】 电商下单完整流程：
【划分】 基于流程图，识别正常及异常分支
【用例】 基于流程图分支，设计用例
| 用例编号 | 用例标题 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
|---|---|---|---|---|---|---|
| 1 | 正常（正常下单完成交易） | 高 | 有库存可购买 | 下单 → 支付成功 → 发货 → 收货确认 | 库存足,支付成功 | 完成交易 |
| 2 | 异常 下单库存不足 | 高 | 无库存 | 下单 | 库存不足 | 提示库存不足 |
| 3 | 支付失败终止交易 | 高 | 有库存可购买 | 下单 → 支付失败 | 库存足,支付失败 | 提示支付失败 |
缺陷 – 执行失败的用例
什么是缺陷：软件中存在的各种问题都是缺陷 (BUG)
缺陷衡量标准：多功能、少功能、功能错误、隐性功能错误、易用性
缺陷产生原因：产品需求、产品设计、编码、运行
- 产品需求：需求描述不易理解、有歧义、错误等
- 产品设计：设计文档中存在的缺陷
- 编码：代码出现错误
- 运行：软硬件系统本身导致的缺陷
缺陷分类：功能错误、UI 界面错误、兼容性、易用性、建议、数据错误、架构错误
缺陷管理流程：提交、验证、关闭
缺陷描述要素：缺陷编号、缺陷标题 (推荐格式：数据+实际结果，预期结果)、描述（前置条件、复现步骤、预期结果、实际结果）
缺陷提交要素：优先级、严重程度、指派人、状态
- 一般是提交时候下拉框选 (
不需要记忆选项，理解就行)；确定可复现并且未记录(保证唯一性)之后再进行提交- 优先级：
- Priority 0: 24h 内解决
- Priority 1: 发布前必须修复
- Priority 2: 可以再下一个版本中修复
- 严重程度：
- 严重（S1）: 主功能
- 一般（S2）: 次要功能
- 微小（S3）: 易用性、界面
- 建议（S4）: 建议性问题
- 指派人
- 状态：
- New：新建
- Open：打开
- Closed：关闭
- Postponed：延期
完结撒花~~~
扫一扫
4101
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
