文章目录
- 结论：只有动态测试才用测试用例
- 测试用例最简写法
-
- 一、标准8要素（必写）
- 二、万能模板（复制直接用）
- 三、3条写作口诀
- 四、快速写用例思路
-
- [1. 正常流程（正向用例）](#1. 正常流程（正向用例）)
- [2. 异常流程（反向/错误场景）](#2. 异常流程（反向/错误场景）)
- [3. 边界值（极限数值/长度）](#3. 边界值（极限数值/长度）)
- 测试一般是按照测试用例来执行
-
- [1. 什么时候严格按用例走](#1. 什么时候严格按用例走)
- [2. 什么时候不用死板按用例](#2. 什么时候不用死板按用例)
- [3. 行业真实执行规则](#3. 行业真实执行规则)
- [4. 最简单总结](#4. 最简单总结)
- 测试用例**标准执行顺序**
-
- [1. 先做：冒烟测试（最先跑）](#1. 先做：冒烟测试（最先跑）)
- [2. 再按**模块顺序**执行](#2. 再按模块顺序执行)
- [3. 同模块内固定顺序（最重要）](#3. 同模块内固定顺序（最重要）)
- [4. 优先级排序（职场必守）](#4. 优先级排序（职场必守）)
- [5. 发现BUG后执行规则](#5. 发现BUG后执行规则)
- [6. 最后收尾](#6. 最后收尾)
- 测试中发现bug
-
- [1. 发现BUG操作（最简单）](#1. 发现BUG操作（最简单）)
- [2. 举个实例](#2. 举个实例)
- [3. 重点区分](#3. 重点区分)
- [4. 一句话总结](#4. 一句话总结)
结论：只有动态测试才用测试用例
- 两大测试分清
静态测试（不动代码、不点页面）
- 干什么：看文档、看代码、看界面原型、评审需求
- 不用测试用例
- 方式：肉眼看、读文档、走读代码、评审
- 例子：查错别字、逻辑文案错误、代码格式错
动态测试（运行起来、手动点/跑程序）
- 干什么：打开软件、点击操作、输入数据跑功能
- 必须用测试用例
- 就是你平时一条条执行用例那种
- 包含：功能测试、接口测试、性能测试、自动化测试
测试用例最简写法
一、标准8要素（必写）
- 用例ID：TC001、TC002
- 用例名称：简洁说清测什么
- 模块：所属功能模块
- 前置条件：进入页面、登录、数据准备
- 操作步骤：一步步点什么、输什么
- 预期结果：正确应该显示/发生什么
- 实际结果：测试后填写
- 测试结果：通过/不通过
二、万能模板（复制直接用）
| 用例ID | 用例名称 | 模块 | 前置条件 | 操作步骤 | 预期结果 | 实际结果 | 测试结果 |
|---|---|---|---|---|---|---|---|
| TC001 | 登录-正确账号密码 | 登录页 | 打开登录页面 | 1.输入正确账号 2.输入正确密码 3.点击登录 | 登录成功，进入首页 | ||
| TC002 | 登录-密码错误 | 登录页 | 打开登录页面 | 1.输入正确账号 2.输错误密码 3.点击登录 | 提示密码错误，无法登录 |
三、3条写作口诀
- 步骤越细越好，别人照着能复现
- 预期结果写死，不写"正常、没问题"
- 覆盖：正常流程+异常流程+边界值
四、快速写用例思路
- 先走正常流程（最常用操作）
- 再写异常（空输入、错输入、重复、超时）
- 最后写边界（最大数、最小数、极限长度）
举例：以 账号密码登录为例
1. 正常流程（正向用例）
操作：输入正确用户名+正确密码，点击登录
预期：成功登录，跳转首页
2. 异常流程（反向/错误场景）
- 账号为空，填正确密码登录
- 密码为空，填正确账号登录
- 账号密码全都空
- 账号正确、密码错误
- 账号不存在，任意密码
- 输入特殊符号、乱码登录
- 已登录状态重复点登录
3. 边界值（极限数值/长度）
假设账号限制6-12位
- 输入最小6位合法账号+正确密码
- 输入最大12位合法账号+正确密码
- 输入**5位（小于最小）**账号
- 输入**13位（大于最大）**账号
- 密码刚好达到最长位数
- 密码刚好最短位数
再举一个：输入金额（限制1~10000元）
- 正常：输入500元提交
- 异常：输负数、输0、输汉字、输字母、空着不填
- 边界
- 最小值：1元
- 最大值：10000元
- 超下限：0.99元
- 超上限：10001元
测试一般是按照测试用例来执行
正式测试必须按测试用例执行，日常随手测可以不按
1. 什么时候严格按用例走
- 版本正式上线测试
- 提测、回归测试、冒烟测试
- 项目要写测试报告、留记录
- 多人协作测试
流程：对照用例一步步操作 → 填实际结果 → 标记通过/失败
2. 什么时候不用死板按用例
- 开发自测、简单改bug随手点
- 探索性测试（自由乱点找隐藏bug）
- 临时快速验证功能
- 小功能、改文字改样式
3. 行业真实执行规则
- 主干流程必走用例，保证核心功能不漏测
- 边缘场景自由发散测（在用例之外多点点）
- 发现bug：先记bug，继续走完当前用例，不要跳用例
- 用例写错/过时：先执行，事后修改更新用例
4. 最简单总结
正规干活=照着用例执行；摸鱼自测=随便点
企业90%正式测试，全是严格按测试用例一条条跑完
测试用例标准执行顺序
1. 先做：冒烟测试（最先跑）
只跑核心主干流程
目的：确认版本能不能测，崩没崩
- 登录、进入主页、核心功能走一遍
- 跑不通直接打回开发，不用测别的
2. 再按模块顺序执行
从左到右、从首页→子页面→详情页
例：首页 → 登录 → 注册 → 列表 → 新增 → 编辑 → 删除
3. 同模块内固定顺序（最重要）
- 正向正常用例（先测正确流程）
- 边界值用例（极限数字、长度）
- 异常错误用例（空、错、乱输）
- 重复/并发/特殊场景（最后测）
4. 优先级排序（职场必守）
- P0 最高优先级：核心流程、必用功能（优先跑完）
- P1 常用功能：日常高频操作
- P2 次要功能：少用功能
- P3 边角场景：极少用到，最后测
5. 发现BUG后执行规则
- 发现bug先记录，截图+写清楚步骤
- 继续跑完当前这条用例
- 同类型bug统一记录，不反复卡着
- 全部跑完统一提bug，不跑一条提一条
6. 最后收尾
- 全部用例执行完毕
- 统计通过率
- 回归测试：开发改完bug，优先重测失败用例
测试中发现bug
1. 发现BUG操作（最简单）
- 照着用例操作，中途出问题=出现bug
- 先截图保存
- 在这条用例的 实际结果 里写清楚报错现象
- 测试结果直接填：不通过
- 继续把这条用例剩下步骤走完，不要直接停
2. 举个实例
用例：输入正确账号密码登录
- 预期结果：登录成功
- 实际操作：点登录直接闪退
- 实际结果填写：点击登录按钮页面闪退，无法进入首页
- 测试结果：不通过
- 截图留存
3. 重点区分
- 测试用例里 ：只写现象+填通过/不通过
- BUG管理平台（禅道/Jira）：再单独提完整bug单（步骤+截图+环境+版本）
4. 一句话总结
发现bug → 用例里填实际错误结果+标不通过 → 走完本条用例 → 全部测完统一提bug