测试用例的内容
主要内容
-
用例编号(如何命名)
-
所属模块
-
用例标题(验证谁在什么情况下，去做什么，最后结 果是什么)
-
优先级
-
前置条件
-
操作步骤
-
测试数据
-
预期结果
-
实际结果
辅助内容
-
通过否
-
bugID
-
编写人员
-
编写时间
-
测试人员
-
测试时间
-
备注
测试种类分类
-
-
界面类 图片 文字 颜色 布局 显示 内容
-
功能类 业务逻辑
-
性能类 不能够满足性能指标
-
安全类
-
兼容类
缺陷的验证程度
-
严重
-
一般
-
次要
-
轻微
缺陷的优先等级
-
立刻解决
-
-
正常排队
-
低优先级
缺陷发生阶段分类
-
需求阶段缺陷
-
架构阶段缺陷
-
设计阶段缺陷
-
编码阶段缺陷
-
测试阶段缺陷
缺陷报告
什么是缺陷报告
描述软件缺陷现象和重现步骤的集合
缺陷报告的核心要素 (背下来)
-
缺陷编号
-
缺陷状态
-
缺陷标题
-
重现步骤(复现步骤)
-
严重程度
-
优先级
-
缺陷类型
-
测试环境
缺陷管理
提交缺陷的注意事项
-
可复现: 缺陷可以复现
-
唯一性: 一条缺陷只报告一个问题
-
规范性: 缺陷报告编写要规范, 符合公司或者项目要求
-
准确: 描述的信息是正确的
-
具体: 有细节且是真实特定的, 避免使用模糊不清的词语, 如功能中断, 功能不正确, 功能不起作用等等.
-
简洁易懂: 描述简单容易理解, 不要产生歧义
-
次序清晰: 描述缺陷过程有条件, 有先后顺序
-
缺陷的跟踪流程
-
-
缺陷的生命周期
测试人员提交新的Bug入库，错误状态为New。如果确认是错误，设置状态为Open。如果不是错误，设置为Declined状态。如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决，置Bug的状态为Closed，如没有解决,置bug状态为Reopen。
-
测试描述
-
测试目的
-
测试依据
-
测试范围
-
测试环境
-
测试实际进度
-
-
执行结果
-
测试结果分析
-
测试需求覆盖分析
-
测试用例执行分析
-
缺陷分布分析
-
遗留缺陷
-
测试缺陷列表
-
-
测试结论
-
测试有效性分析
-
测试结论
-