编写测试用例

测试用例元素

• 测试目标(Why):
  • 明确测试目的：功能/性能/可用性/容错性/兼容性/安全性等
  • 示例：测试登录功能时需说明是验证功能正确性还是安全性
• 测试对象(What):
  • 具体被测项：对象/函数/类/菜单/按钮/表格/接口/整个系统等
  • 示例：登录功能中的用户名输入框、密码输入框、登录按钮
• 测试环境(Where):
  • 系统配置要求：操作系统/浏览器/通信协议等
  • 硬件环境：服务器/客户机数量、网络设备需求
• 测试前提(When):
  • 执行条件限制：如测试登录前需先注册有效账号
  • 示例：测试支付功能前需确保账户余额充足
• 输入数据(Which):
  • 具体测试数据：数字/字符/文件等（需精确到具体值）
  • 与测试点的区别：不能仅写"输入正确账号"，需明确如"账号：test123"
• 操作步骤(How):
  • 详细执行顺序：如"1.打开登录页 2.输入账号密码 3.点击登录按钮"
  • 必须体现完整的操作流程

测试用例的模板

1.手机测试模板

• 基本结构：采用表格形式，包含ID、功能描述、操作步骤、预期结果和备注等列
• 用例编号：如MMS_001，公司或项目团队可自定义编号规则
• 功能描述：用一句话说明测试场景，如"彩信不满时选择新建"
• 操作步骤：分步骤描述测试操作，如"1、进入’新建’；2、选择’彩信’"
• 预期结果：描述正确操作后应出现的结果，如"进入彩信新建界面正常"
• 功能拆分：用例上方标注测试范围，如"基本菜单功能测试"表示测试对象

2.银行测试模板

• 案例编号：命名规范更复杂，如ms_D9_对公操作分公司账户付款i00001
• 需求参考：需注明依据的需求文档，确保用例有据可依
• 测试目的：用一句话陈述验证目标，如"验证操作分公司账户付款制单功能"
• 前提条件：明确测试前的准备要求，如账户类型、权限设置等
• 测试步骤：详细描述每一步操作和输入的具体数据
• 期待结果：分条列出每个步骤应产生的正确结果
• 组合测试：通过注释说明不同参数组合产生的案例数量，如32种汇路组合

3.电梯项目测试案例

• 检查点：相当于测试目的，如"检查入轿11人，系统报警灯是否亮起"
• 初始条件：测试前的系统状态，如"加载默认，电梯加电后"
• 测试步骤：具体操作指令，如"点击’入轿’11次"
• 预期结果：应出现的正确响应，如"系统报警灯亮起，提示’电梯中人员超载’"
• 用例追溯：关联需求文档中的具体章节，如"3.4.10"
• 优先级：标识用例执行顺序，数字越小优先级越高

测试用例的写作总结

• 核心要素：所有模板都包含用例编号、测试目的/描述、操作步骤和预期结果等基本要素
• 格式差异：不同行业/公司对相同要素可能有不同命名，如"测试案例"vs"测试用例"
• 灵活应用：需根据实际项目要求调整模板，但核心内容必须完整
• 数据具体化：操作步骤中必须使用具体数据，不能模糊描述
• 一行一用例：每个测试案例应独立成行，避免多个案例混在一起
• 需求关联：优秀用例应能追溯到具体需求条款
• 组合覆盖：通过参数组合可系统性地覆盖各种测试场景

测试用例写作

1.用例编号

• 命名规则：
  • 软件名简称_功能简称_数字（如：MA0901-例-022）
  • 数字位数规则：10个以内用1位，10-99用01，100-999用001
  • 必须保证唯一性，不可重复
• 组成要素：
  • 软件名/模块简称（如电梯系统用MA）
  • 功能简称（如开关门控制用"例"）
  • 序列号（按功能分组编号）

2.初始条件

也称为前置条件，是一个静态的状态。

数据与步骤的书写格式

• 合并写法：可将数据直接写入步骤，如"输入账号：123456；输入密码：123456"
• 分离写法：当数据要求高时，可采用"操作步骤"与"数据"分列的形式
• 参数格式：参数前必须加中文冒号，如"用户名：admin"，禁止使用空格或"为"连接

每一步都是动作，不是步骤。

3.预期结果

4.用例状态

5.优先级

冒烟测试

缺陷等级

1.A类-致命缺陷

核心特征：导致系统完全不可用的故障

典型表现：

系统级崩溃：死机、蓝屏、程序中断

关键功能失效：数据库死锁、通信错误

安全风险：数据丢失或损坏

面试准备：需准备实际项目中的案例（如"引起服务器宕机的缺陷"）

2.B类-严重缺陷

影响范围：主要功能异常但不导致系统崩溃

具体案例：

数据完整性缺失：数据库约束未设置

业务流程错误：关键业务规则实现错误

功能模块失效：次要功能完全不可用

与A类区别：系统仍可运行但存在重大功能缺陷

3.C类-一般缺陷

界面问题：列名定义不一致、打印格式错误

交互缺陷：删除操作无确认提示

设计瑕疵：输入验证放在后台处理（应在前端控制减少服务器压力）

数据问题：数据库存在大量空字段

4.D类-较小缺陷

用户体验问题：

界面不规范：对齐/大小不一致

提示缺失：长时间操作无进度反馈

术语混乱：中英文混合提示

交互设计缺陷：可输入区域无视觉区分标志（如缺少必填项红星标记）

5.E类-意见或建议

性质说明：不影响功能的优化建议

典型场景：

视觉设计：颜色搭配不协调

交互细节：动画效果生硬

文案改进：提示语不够友好

处理原则：通常作为低优先级优化项处理

缺陷按处理的优先级分类

级别表示方法：通常用P1-P5表示（简写为P），部分软件采用"高/中/低"分级，不同公司可能有自定义标准

核心区别：优先级反映修复的紧急程度（何时改），与严重程度（破坏力）是两个独立维度，但通常严重缺陷会优先处理

级别说明：

P1：必须立即停止当前工作修复，如导致系统崩溃的致命错误

P2：进入常规修复队列，开发人员按顺序处理

P3：可延期修复，但最终需要解决（如界面文字错位等非阻塞性问题）

P4：明确规划在下一版本修复，当前版本不予处理

P5：可能永不修复，包括影响架构稳定性、修复成本过高的缺陷

根据缺陷状态对缺陷分类

• 状态本质：反映缺陷在生命周期中的处理进度，不同公司可能有不同命名（如"新建"替代"已提交"）
• 核心状态：
  • Submitted：测试人员初步提交的缺陷，未经开发确认
  • Open：开发确认有效并纳入处理计划，相当于"待修复"状态
  • Rejected：包含三种情况：①非真实缺陷 ②重复报告 ③无需修复的"缺陷"
  • Resolved：开发完成代码修改，但尚未经过测试验证
  • Verified：测试人员确认缺陷已正确修复（验证失败则重新打开）
  • Closed：完成全流程的缺陷，通常不再显示在常规查询结果中
• 状态流转：典型路径为 提交→打开→解决→验证→关闭，拒绝和重新打开构成循环路径

缺陷的简单流程

• 生命周期概念：缺陷处理流程也称为缺陷生命周期，指缺陷从产生到消除的完整过程，是面试高频考点
• 核心环节：
  • 提交缺陷报告 → 分配缺陷报告 → 处理缺陷报告 → 返测 → 关闭缺陷报告
• 状态关联：处理流程与缺陷状态变化紧密相关，但回答时应避免"蹦词"，需用完整语句描述过程
• 返测分支：
  • 通过：进入关闭流程
  • 未通过：直接返回开发人员重新修改

缺陷报告的标准处理流程

• 提交阶段：
  • 责任主体：测试人员提交报告，可能需经负责人/QA审核（视公司流程而定）
  • 分配方式：可能由负责人分配或测试直接对接开发（敏捷开发常见结对编程情况）
• 处理阶段：
  • 修改权限：开发人员在开发工具中修改缺陷，需有系统赋权防止随意更改状态
  • 特殊情形：原开发人员不在时可能分配给其他成员，需在系统中标注责任人
• 返测阶段：
  • 操作规范：测试人员需严格依据修改记录进行验证
  • 未通过处理：状态重置为"打开"，直接返回原开发人员（无需重新分配）
  • 通过处理：需负责人审慎确认后关闭，防止误关未修复缺陷
• 关闭后管理：
  • 复审机制：已关闭缺陷可能被质量管理人员在阶段性复审中重新打开
  • 紧急处理：重新打开的缺陷需立即处理，形成完整生命周期闭环
• 流程要点：
  • 必须明确各环节责任人（测试/开发/负责人）
  • 公司实际流程可能存在简化（如跳过审核直接分配）
  • 关闭操作具有最终性，需特别谨慎

• 流程本质：缺陷报告处理流程与缺陷处理流程是同一概念的不同表述
• 分类标准：包含正常缺陷、重复缺陷、无效缺陷、推迟缺陷、验证不通过、描述不清楚六种处理场景

1.正常缺陷

触发条件：测试人员提交新缺陷（Open状态），开发人员确认有效且无重复

关键判断：

重复性检查：需查询历史缺陷记录确认非重复（Duplicated）

可重现性：必须能够稳定复现（Cannot reproduce/N）

信息完整性：缺陷描述需包含完整复现步骤（Need more info/N）

处理路径：确认修正（Fixed）→测试验证→关闭缺陷

典型特征：完整经历"提交-确认-修复-验证-关闭"全流程

2.重复缺陷

• 判定标准：与现有缺陷库中的记录存在完全相同的表现
• 处理步骤：
  • 开发人员标记为Duplicated
  • 测试人员进行二次确认
  • 直接关闭缺陷报告
• 特殊说明：重复缺陷属于无效缺陷的子类别，但处理流程更明确

3.无效缺陷

• 核心特征：被判定为非真实缺陷（Not a Bug）
• 验证机制：
  • 开发人员初步判定
  • 测试人员最终确认
• 处理结果：标记为无效后关闭，但需保留记录备查

4.推迟修改

• 决策节点：确认为真实缺陷但暂不修复
• 后续处理：
  • Known issue：已知问题暂不修复
  • On hold：等待项目经理决策
  • By design：设计预期行为
  • Defer：延后至下个版本修复
• 管理要求：需明确推迟原因和后续处理计划

5.验证不通过

• 本质定义：开发修复后测试验证失败（即反测未通过）
• 处理方式：
  • 重新打开缺陷（Reopen）
  • 返回开发环节重新处理
  • 形成新的处理循环
• 质量警示：通常表明修复方案不彻底或测试用例不完善

6.描述不清楚

• 判定标准：信息不完整导致无法复现或定位（Need more info）
• 处理要求：
  • 测试人员补充必要信息（如操作系统版本、特定操作步骤等）
  • 重新提交完整缺陷报告
  • 进入标准处理流程
• 常见缺失：环境信息、操作步骤、预期与实际结果的明确对比

7.标准缺陷的处理流程细分

• 共性环节：
  • 测试人员发起（Open/Reopen）
  • 开发人员初步判断
  • 双方确认机制
  • 最终状态闭环
• 特殊情形：
  • 复审重开：已关闭缺陷可能被阶段性复审重新打开
  • 经理介入：争议缺陷需提交开发经理决策
  • 版本跟踪：推迟缺陷需在下个版本重新评估
• 状态标识：包含Fixed、Fix-pending、Deferred等多种状态标签

执行用例总结

1.执行用例过程中需要注意的问题

记录完整性：测试用例执行时必须详细记录实际结果和测试结果，发现缺陷需标注编号，在备注中说明用例重复或表述不清的情况

用例修改规范：执行过程中不允许直接修改用例，但可添加备注说明问题，如"加上第二次以后连接"等补充说明

IP配置测试要点：

服务器IP变更后需验证连接窗口弹出功能（用例07）

IP首段为1或223时需验证连接正常（用例08、09）

IP后三段含255时需验证各组合情况（用例10）

文件权限测试：

首次连接前创建db.info文件并设为只读（用例05）

连接成功后修改db.info为只读再次验证（用例06）

预期结果均为连接窗口关闭后正常弹出登录窗口

2.执行用例后需要注意的问题

执行效率优化：

发现用例冗余或表述问题时应做好记录而非直接修改

通过备注提高后续执行效率，避免重复工作

典型冗余案例：文件只读权限测试存在重复用例（用例05、06）

缺陷管理规范：

发现缺陷立即提交，避免后期遗忘

示例缺陷：防火墙开启时出现"Run-time error 53: File not found"错误（用例01）

完整记录缺陷现象和重现步骤

经验总结要点：

执行约8个典型用例后即可掌握核心测试场景

需反思用例设计质量，如"加上第二次连接"等补充说明反映初始用例不完善

测试过程中应持续优化执行方法，减少简单重复工作耗时

执行记录样本

1. 缺陷报告处理流程

缺陷发现与记录：发现疑似缺陷时应详细记录，包括缺陷表现、复现步骤等关键信息

缺陷分类标准：

按等级分类：致命、严重、一般、轻微

按优先级分类：立即解决、高优先级、正常排队、低优先级

按处理状态分类：新建、已分配、已修复、已验证、已关闭

2.高质量缺陷报告撰写

写作准则：

标题要求：简明扼要描述缺陷本质

复现步骤：提供清晰、完整的操作序列

预期/实际结果：明确对比正常与异常表现

附件要求：必须包含相关截图和日志

避免问题：

重复提交相同缺陷

描述模糊不清

缺少必要复现信息

3.测试用例执行记录

记录要点：

前置条件：明确测试环境配置要求

测试步骤：详细记录操作顺序

结果比对：严格对照预期与实际结果

缺陷编号：为每个失败用例分配唯一标识

注意事项：

对于通过用例仍需记录完整执行过程

冗余用例需明确标注

合并相似用例可提高效率

4.缺陷管理实践

工具选择：

Bugzilla：需配置Perl环境和邮件服务

ZenTao：集成项目管理功能

SVN：用于版本控制和文件恢复

处理流程：

测试人员提交→负责人分配→开发修复→测试返测→最终关闭

每个状态变更需记录详细说明

5。测试经验总结

执行记录价值：

为后续版本测试提供参考

积累测试经验，避免重复错误

发现潜在改进点（如新增用例需求）

记录技巧：

备注栏记录测试中发现的问题

简要注明改进建议

保留随机测试发现的问题

6.异常场景测试

典型异常场景：

网络中断（拔网线）

服务器重启

IP地址格式错误

防火墙配置变更

错误处理要求：

应给出明确错误提示

提示信息需包含具体原因

需验证各种边界条件