测试执行

测试执行

常见术语

关于BUG：

Bug：电脑系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷，都可以叫做“Bug”；有时也被泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。
Defect（缺陷）：既指静态存在于软件工作产品（文档、代码）中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。

容易混淆的几个概念：

• 失误（Mistake）：导致软件包含故障的人的行为；
• 缺陷（Defect）：软件的异常情况；
• 故障（Fault）：引起一个功能组件不能完成所要求的功能的一种意外情况；
• 失效（Failure）：功能组件执行其规定功能的能力丧失；

缺陷管理的基本概念

缺陷的类型：

• 遗漏（Missing）
• 错误（Error）
• 额外的实现（Extra）
• 改进（Enhancement）

缺陷的评价标准：

• 软件未实现需求规格说明书（SRS）要求的功能
• 软件未实现需求规格说明书（SRS）虽未明确提及但应该实现的目标
• 软件出现了需求规格说明书（SRS）指明不应出现的错误
• 软件实现了需求规格说明书（SRS）未提到的功能
• 软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好

缺陷跟踪的交付物

缺陷报告单（Bug Report）：也叫缺陷跟踪单。测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。

缺陷报告单写作准则（5C）

Correct（准确）
每个组成部分的描述准确，不会引起误解
Clear（清晰）
每个组成部分的描述清晰，易于理解
Concise（简洁）
只包含必不可少的信息，不包括任何多余的内容
Complete（完整）
包含复现该缺陷的完整步骤和其他本质信息
Consistent（一致）
按照一致的格式书写全部缺陷报告

缺陷报告单基本内容

缺陷报告的相关属性

• 缺陷所属模块
• 缺陷种类
• 缺陷严重程度
• 缺陷优先级
• 可再现性
• 缺陷发现人
• 缺陷状态

缺陷的严重程度

严重性：顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

• 致命：例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。
• 严重：例如，由于单功能失效导致多个相关功能均失效 。
• 一般：例如，软件的单个功能失效。
• 提示：软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等。

缺陷的严重程度

• 压缩：精简任何不必要的信息，特别是冗余的测试步骤。
• 去除歧义：使用清晰的语言，尤其是避免使用那些有多个不同或相反含义的词汇。
• 中立：公正的表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、幽默或讽刺。
• 评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在递交错误报告之前自己先阅读一遍。

缺陷管理的目的

• 保证信息的一致性
• 保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效
• 利于缺陷分析、产品度量，使项目情况可视化加强

软件缺陷管理工具

• Mercury TestDirector（简称TD）
• HP Quality Center（简称QC）
• Rational ClearQuest（简称CQ）
• Jira
• Bugzilla

BUG的生命周期

• 缺陷的生命周期就是指缺陷从开始提出到最后完全解决，并通过验证和确认的过程。在这个过程中缺陷报告的状态不断发生着变化，记录着缺陷被处理的过程。
• 缺陷的生命周期通过缺陷流程图得以展现

缺陷跟踪流程的角色

• 软件开发人员
• 软件测试人员
• 软件测试经理
• 软件项目经理
• 需求分析人员/产品人员
• 需求经理/产品经理

缺陷报告的状态

缺陷管理中的常见问题

• 提交的缺陷开发人员不认可怎么办？
• 如何处理不能重现的缺陷？
• 如何处理好与开发人员及其他相关人员的关系？
• 缺陷太多怎么办？
• 找不到缺陷怎么办？
• 缺陷得不到及时修复怎么办？
• 如何处理缺陷级别定义之争？
• 如何处理缺陷跟踪中的扯皮现象？