写好测试用例的关键要素：
（1）编写规范
（2）测试点覆盖全面（可用思维导图写出测试点）
测试用例的八大要素
1、用例编号：项目代号 - 模块名 - 序列号 eg：百度的登录模块 Baidu-Login-001
2、测试模块：一级模块（可以加上二级模块）
3、用例标题：关键动作（测试点）+ 预期结果
eg：百度的登录模块，用例标题：输入合法的账户信息（关键动作），登录成功（预期结果）
4、重要级别（为下拉列表，也叫优先级）：决定用例的执行先后顺序，一般按照功能的重要程序分为高、中、低
• 高：保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例
• 中：重要程度介于高和低之间的测试用例
• 低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例
5、预置条件（描述状态）：操作步骤要正常执行，必须在预置条件满足情况下
eg：登录界面正常
6、操作步骤：描述详细的用例执行步骤，写明具体测试点。操作步骤要写序列号123...，一个序列号表明一个步骤为一行；测试点需细化，不可含糊；不需写数据，数据写在测试输入里。
eg：登录百度
1、输入合法的用户名
2、输入合法的密码
3、点击【登录】
7、测试输入：符合测试点的参考测试数据（无测试输入则写无，或不写）
eg：登录百度
用户名：1380013800
密码：123456
8、预期结果：符合需求的结果，一定要写具体现象
eg：登录成功，成功跳转百度首页界面
缺陷报告
缺陷报告的要素：
1、缺陷编号：项目代号 - 序列号（不用写模块名） eg：Baidu-001
2、所属用例 ID：查询哪条用例执行失败
3、所属模块
4、所属版本
5、测试者
6、提交日期
7、缺陷标题：描述、概述 格式：XXX模块时，关键动作，实际结果
eg：登录账户时，密码为空，登录成功
8、缺陷详细描述：包括下列4个点
a、预置条件
b、复现步骤（操作步骤与测试输入合并）
c、预期结果
d、实际结果
9、缺陷严重程度：
• 致命：系统奔溃、无响应、数据库数据损坏丢失
• 严重：主要功能出现问题
• 一般：一般功能出现问题
• 较小：问题较小，如界面错别字等
• 建议：问题本身不影响系统使用，但是可以提高用户体验
10、缺陷的优先级：
• 高：立即处理（一般缺陷严重程度越高，优先级越高）
• 中：正常排队解决
• 低：推迟处理
11、缺陷的重复率：一般是复现三次（养成发现缺陷立即截图的习惯，保存下来，以免无法复现）
①总是100% ②经常50%~80% ③偶尔20% ④无法复现（原因有环境导致，或者某个固定的数据导致）
12、缺陷的状态：如下图
13、解决人与解决日期
14、验证人及验证日期（和提交人可能是同一个人，也可能不是同一个人，比如离职了）
问题来了：
无法复现的缺陷如何处理？
①做好缺陷的截图，第一时间详细记录缺陷的复现步骤，输入的测试数据，使用的测试环境。若有日志，获取详细的日志信息。
②紧接着，花个半小时到一小时左右，努力复现缺陷，找到缺陷出现的规律
③若依然无法复现，做好备注，先完成其他本职工作
④利用自己下班时间，周末时间努力复现
⑤若始终未复现（2~3工作日过去了），告知测试经理和开发人员
提交的缺陷，开发人员拒绝处理，如何处理？
①测试人员应先自己对缺陷报告反复复现缺陷，分析缺陷产生的原因及影响
②拿着整理的资料与开发人员耐心沟通（提前约好时间）
③若开发人员依然拒绝处理，告知测试经理协助解决
正常缺陷的处理流程是怎样的？
①测试人员提交缺陷，状态为 new，分配给测试经理
②测试经理审核缺陷，状态为 open，分配给开发人员
③开发人员处理缺陷，修复代码后，状态为 fixed，分配给测试人员
④测试人员验证缺陷，若缺陷修复正确，状态为 closed；若缺陷未修复正确，状态为 reopen
