软件测试：软件缺陷管理

最新推荐文章于 2024-07-10 17:50:05 发布

csdnw1022

最新推荐文章于 2024-07-10 17:50:05 发布

阅读量448

点赞数

文章标签：测试数据库 jira

软件测试：软件缺陷管理

软件缺陷 - 概念

• 软件缺陷 - 基本概念主要分为：缺陷、故障、失效 • 缺陷（ Defect ）：以静态形式存在于软件内部，相当于 BUG ； • 故障（ Fault ）：软件运行中出现的状态，不处理可能会失效，以动态形式存在； • 失效（ Failure ）：软件运行时产生的外部异常行为结果，与用户需求不一致。

缺陷不一定导致故障，故障也不一定会失效；缺陷导致故障，有可能导致失效，也有可能不会导致失效

软件缺陷 - 定义

软件缺陷的定义

• 软件未达到产品说明书中已标明的功能 • 软件未达到产品说明书中虽未指出但应达到的目标 • 软件出现产品说明书中指明不会出现的错误 • 软件功能超出了产品说明书中指明的范围 • 软件测试人员认为软件中难以理解、不易使用、运行速度缓慢，或者最终用户认为不好缺陷的几种类型： • 设计不合理 ; • 功能、特性没有实现或部分实现 ; • 运行出错，包括运行中断、系统崩溃、界面混乱等 ; • 与需求不一致，在执行 TestCase 时则为实际结果和预期结果不一致 ; • 用户不能接受的其他问题，如存取时间过长、界面不美观 ; • 软件实现了需求未提到的功能。

软件缺陷 - 产生的原因

• 人员沟通不到位，交流上有误解或根本不交流 • 文档不完善 • 需求不断的变化 • 参与人员过度自信 • 程序设计有误 • 软件复杂性 • 工期短、任务重、时间压力大 • 软件开发工具与软硬件

识别软件缺陷

• 通过测试用例中的预期结果进行识别 • 通过需求规格说明书进行识别

• 通过用户手册及其他文档进行识别 • 通过同行业相类似成熟的商业软件识别

• 通过与开发人员的沟通进行识别 • 通过与有经验测试人员沟通进行识别

• 通过参照同行业隐式需求进行识别

软件缺陷 - 组织架构

• 缺陷的标题（一句话简单描述问题） • 缺陷的基本信息 • 测试的软件和硬件环境 • 测试的软件版本 • 缺陷的类型 • 缺陷的严重程度 • 缺陷的处理优先级 • 缺陷的操作步骤（测试步骤、预期结果、实测结果） • 备注 / 注释文字和截图

软件缺陷 - 相关属性

• 缺陷相关属性：提交人、提交日期、 BUG 状态、严重程度、缺陷优先级、缺陷版本、修复日期。

1 . 缺陷发现人：最直接的是测试人员，测试人员发现的 BUG 数是进行个人绩效考核的依据。 2. 缺陷发现时间：发现 BUG 并提交的时间。 3. 缺陷优先级：立即解决 P1 、高优先级 P2 、正常排队 P3 、低优先级 P4 。立即解决是指缺陷导致系统几乎不能使用或测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需优先考虑；正常排队是指缺陷正常排队等待修复；而低优先级是指缺陷可最后修改。 4. 缺陷版本：执行测试并发现 BUG 的版本号。 5. 缺陷修复日期：开发人员修复 BUG 的日期。

• 缺陷状态

1 . 新建 New 缺陷的初始状态

2 . 打开 Open 测试人员提交 BUG

3 . 指派 Assigned 指派给相关开发人员进行修复

4 . 已修复 Fixed 开发人员已修复

5 . 已关闭 Closed 测试通过，关闭

6 . 重新打开 Reopen 回归测试未通过，或关闭后又复现了

7 . 延期 Postpone 推迟修改

8 . 拒绝 Rejected 开发人员拒绝修改

9 . 重复 Duplicate 重复提交

10 . 已取消 / 终止 Abandon 被拒绝和重复提交的 BUG ，在确认不是问题后，置为此状态

• 缺陷严重程度：致命、严重、一般、较小、改进建议；或 A 、 B 、 C 、 D 、 E

1 . 致命：软件死机、退出或崩溃、数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。 2. 严重：主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。 3. 一般：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。 4. 较小的：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范，辅助说明描述不清楚。 5. 改进建议：由测试人员对软件的改进意见、建议或质疑。

软件缺陷 - 填写要求

1. 缺陷标识：必填，缺陷的标识编号。 2. 指派人：必填，新提交的问题分配给相应的开发人员。 3. 提交人：必填，问题提交者，默认为自己。 4. 测试版本：必填，问题最开始发现的软件版本号，对应开发的版本号。 5. 测试日期：必填，问题最开始提交的时间，默认为当天。 6. 严重程度：必填，问题本身的严重级别，越高表示越严重 7. 缺陷发生概率：必填，出现概率为必现、概率性出现（出现几次）、不可复现。 8. 优先级：必填，缺陷要求解决的优先级，越高表示开发尽快修复问题。 9. 缺陷状态：必填，缺陷的状态，新提交时默认为 “ 新建 ”。 10. 缺陷起源：在需求、架构、设计、编码、测试、用户哪阶段发现的。 11. 缺陷来源：来源于需求规格说明书、设计文档、集成接口、代码。 12. 缺陷模块：必填，哪个功能模块的 BUG 。 13. 问题描述：必填，详细描述问题，描述中必须包括预期结果和实际结果，尽量附图，如有建议，写出修改建议。 14. 问题处理意见：项目人员对缺陷给出处理的建议，均可读写。

软件缺陷 - 描述原则

缺陷描述原则：分类准确、叙述简洁、步骤清楚、易再现、复杂问题有据可查（截图或其它形式的附件）。具体为：

• 问题描述格式：问题描述时，建议分几步描述：模块或功能点 => 测试步骤 => 期望结果 => 实 • 际结果 => 其它信息，可依实际情况调整； • 叙述简洁：单一准确，一个缺陷一个报告；每步骤的描述尽量简洁明了。 • 短小简练：只解释事实、演示和描述软件缺陷必要的细节，不写无关信息； • 再现：可以再现（个别严重问题复现不了也可入库，但需标明）； • 特定条件：缺陷是否在特定条件下才会出现； • 补充完善：复杂的问题应附上截图、 LOG 等信息作为补充说明；

• 不使用抽象词句：比如 “ 有错误 ”“ 是不是 ”“ 请确认 ” 等等； • 不做评价：请勿在 BUG 描述中，评价 BUG 缺陷加入个人主观思想。

软件缺陷 - 生命周期

简单周期：发现、打开、修复、关闭

• 测试员找到并登记软件缺陷，软件缺陷移交到程序员

• 程序员修复软件缺陷，软件缺陷移交到测试员 • 测试员确定软件缺陷被修复，测试员关闭软件缺陷。

复杂周期：

• 发现缺陷（测试员发现并登记缺陷，软件缺陷转到程序员） • 软件缺陷移交到项目管理员 • （以不修复形式解决）项目管理员认为软件缺陷不重要，软件缺陷移交到测试员 • 重新激活缺陷（测试员不同意，找出通用失败案例，软件缺陷移交到项目管理员） • 项目管理员同意缺陷需要修复，缺陷转给程序员 • 以修复形式解决（测试员确认软件缺陷得以修复，测试员关闭软件缺陷） • 缺陷关闭

测试 / 开发角色职责

• 测试执行人员：缺陷发现者。对版本进行测试发现 BUG ，并对已修复的 BUG 进行验证。 • 测试组长：缺陷管理者。负责对缺陷的审核，跟踪和汇报，针对有争议的 BUG 进行各方协调。 • 开发负责人：缺陷解决者。接收 BUG ，并指派给具体开发人员进行修复，给出解决途径或修复建议。 • 开发人员：缺陷修复者。执行开发负责人指派的 BUG 修复并自测是否修复通过。

软件缺陷管理流程

BUG 跟踪流程： 1. 测试人员拿到最新软件版本，执行测试； 2. 发现 BUG 并记录到 BUG 管理平台；提交 BUG 报告或测试报告，邮件抄送开发人员； 3. 开发人员得到最新 BUG 并修复 BUG （如复杂问题，进行专家评审如何处理） 4. 修复 BUG 后把新代码 Check in 到源代码服务器； 5.Buider 人员会进行版本编译并提交到发布版本服务器； 6. 测试人员开始执行新的一轮测试任务。