Day03
目录
一、用例执行
执行结果与用例的期望结果（含义）不一致，为缺陷
二、缺陷
工作流程：
设计用例→执行用例（执行测试）→缺陷（提交、验证、关闭）
（一）定义
软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。
（二）判定标准
- 软件未实现需求（规格）说明书中明确要求的功能——少功能
- 软件出现了需求（规格）说明书中指明不应该出现的错误——功能错误
- 软件实现的功能超出需求（规格）说明书指明的范围—多功能
- 软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求——隐形功能错误
- 软件难以理解，不易使用，运行缓慢，用户体验不好——不易使用
（三）产生原因
- 需求阶段：需求描述不易理解，有歧义、错误等。
- 设计阶段：设计文档存在错误或者缺陷。
- 编码阶段：代码出现错误。
- 运行阶段：软硬件系统本身故障导致软件缺陷。
（四）软件缺陷的生命周期
（五）软件缺陷的核心内容
- 缺陷的标题：描述缺陷的核心问题
- 缺陷的预置条件：缺陷产生的前提
- 缺陷的复现步骤：复现缺陷的过程
- 缺陷的预期结果：希望得到的结果
- 缺陷的实际结果：实际得到的结果
- 缺陷的必要附件：图片、日志等信息（证据）
（六）缺陷提交要素
- 缺陷报告编号：
- 缺陷的唯一标识
- 严重程度：
- 严重（S1）：主功能；
- 一般（S2）：次要功能；
- 微小（S3）：易用性，界面；
- 建议（S4）：建议性为题
- 缺陷优先级：
- Priority 0：24小时之内解决；
- Priority 1：发布前必须修复；
- Priority 2：可以在下一个版本中修复；
- Bug类型：
- 代码错误、兼容性问题、设计缺陷、性能问题
- 缺陷状态：
- New：新建；
- Open：打开；
- Closed：关闭；
- Postponed：延期
（七）缺陷类型
- 功能错误
- 界面（UI）错误
- 兼容性
- 数据（数据库）
- 易用性
- 改进建议
- 架构
二、测试编写
（一）缺陷跟踪流程
（二）提交缺陷注意事项
可重现：缺陷可以复现
唯一性：一个缺陷上报一个问题
规范性：符合公司或者项目要求
面试题：发现缺陷后怎么办？——确定是Bug且可复现
提交时，要检查缺陷是否已存在
三、缺陷管理工具
1、项目管理工具——管理缺陷（禅道、JIRA、TFS）
2、Excel管理缺陷
（一）禅道的介绍
特点：
- 国产、免费、开源、简单、轻量级
- 三管融合（产品管理、项目管理、质量管理）
（二）禅道的特点
-
三权分立：
产品部门——构思者
研发部门——执行者
测试部门——保证者 -
四角协同：
产品经理
项目经理
研发团队
测试团队
（三）禅道使用工具
