说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！

一、软件缺陷的判定

1.什么是缺陷

软件存在着不符合质量需求或违背软件用户、客户、企业意愿的问题，这就是软件缺陷（Defect），又叫“Bug（臭虫）”。

2.软件缺陷的判定准则

• 软件未达到产品说明书标明的功能；
  √ 产品说明书简称为说明（spec）或产品说明（product spec），是软件开发小组的一个协定。它对开发的产品进行定义，给出产品的细节、如何做、做什么、不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。

• 软件出现了产品说明书指明不会出现的错误；
  √ 如金融软件 7*24 工作不能宕机

• 软件功能超出产品说明书指明范围；

• 软件未达到产品说明书虽未指出但应达到的目标；
  √ 如软件在断电时的意外处理

• 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
  √ 主要体现在易用性方面。

3.软件缺陷的表现形式

• 用户要求的功能、特性没有实现或部分实现。

• 运行出错，包括运行中断、系统崩溃、界面混乱等。

• 数据结果不正确、精度不够、不完整或格式不统一。

• 文字显示内容不正确或拼写错误。

• 系统性能低下、系统资源浪费。

4.分离和再现软件缺陷

• 发现缺陷后，应该做好分离和再现，排查发现的“缺陷”是不是软件本身的问题，然后才能提交。

• 再现 3 次
  √ 重现
  √ 复现

5.避免提交缺陷的缺陷和重复缺陷

• 缺陷的缺陷
  √ 是测试人员提交的不是缺陷的缺陷；
  √ 是一种无效缺陷；
  √ 此类缺陷常使测试人员遭受指责。
  √ 怎么办
  ✰ 正确理解需求；
  ✰ 做好复现。

• 重复缺陷
  √ 同一个缺陷 A 测试工程师提交后，B 测试工程师又提交或者自己提交的缺陷与之前提交的缺陷相同或类似；
  √ 是一种无效缺陷；
  √ 怎么办
  ✰ 尽量避免两个人同时测试同一模块；
  ✰ 自己提交的缺陷与自己的重复，提交前查找一下，增强开发知识。

6.处理无法再现的缺陷

• 首先，对这样的缺陷进行详细的记录，使用不同办法去尝试复现。

• 其次，要合理地安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度，并尽快提交给开发人员。

• 最后，在测试过程中对未再现缺陷予以关注。

7.处理有争议的缺陷

• 跟有关人员进行沟通、讨论；

• 搁置。

二、提交缺陷报告

1.什么是缺陷报告

缺陷报告是对缺陷进行记录、分类和跟踪的文档。

2.缺陷报告的读者对象

• 软件开发人员
  √ 报告缺陷是为了缺陷得到修复。
  √ 希望获得缺陷的本质特征和复现步骤。

• 质量管理人员、市场人员、技术支持人员
  √ 希望获得缺陷的严重程度和分布情况，以及对市场和用户的影响程度。

3.缺陷报告的写作准则（5C）

• Correct（准确）
  √ 每个组成部分的描述准确，不会引起误解；

• Clear（清晰）
  √ 每个组成部分的描述清晰，易于理解；

• Concise（简洁）
  √ 只包含必不可少的信息，不包括任何多余的内容；

• Complete（完整）
  √ 包含复现该缺陷的完整步骤和其他本质信息；

• Consistent（一致）
  √ 按照一致的格式书写全部缺陷报告。

4.缺陷报告的组织结构

• 缺陷的标题/缺陷摘要/缺陷概述/缺陷基本信息

• 预处理

• 复现步骤

• 期望结果

• 实际结果

• 缺陷的严重程度

• 缺陷的优先级

• 测试的软件和硬件环境

• 测试的软件版本

• 缺陷的类型

• 注释文字和缺陷截图

5.缺陷报告的写作要求

5.1 缺陷标题

• 尽量按缺陷发生的原因与结果的方式书写；
  √ 执行完 A 后，发生 B；
  √ 在什么地方，做了什么事情，出了什么结果；
  ✰ 使用“在…以后”，“在…时候”或“在…期间”等连结词有助于描述缺陷的原因和结果。

• 避免使用模糊不清的词语；

• 为了方便搜索和查询，尽量使用关键字；

• 为了便于他人理解，避免使术语、俚语或过分具体的测试细节。

5.2 复现步骤

• 提供测试的预备步骤和信息；

• 步骤完整，准确，简短，没有缺漏任何操作步骤，没有任何多余的步骤；

• 将常见步骤合并为较少步骤；

• 简单地一步一步地引导复现该缺陷；

• 每一个步骤尽量只记录一个操作；

• 每一个步骤前使用数字对步骤编号；

• 尽量使用短语和短句，避免复杂句型和句式；

• 只记录各个操作步骤是什么，不要包括每个步骤的执行结果。

5.3 预期结果

• 软件应该具有的结果，或者说正确结果应该是什么样子。

5.4 实际结果

• 实际结果的描述要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。

• 如果一个动作产生彼此不同的多个缺陷结果，或者一个动作将产生一个结果，而这个结果又产生另一个结果。为了易于阅读，这些结果应该使用数字列表分隔开来。如实际结果：
  √ 1.显示“命令代码行…错误”；
  √ 2.显示“并且终止…服务”。

5.5 注释/截图

• 可以包含以下各方面的内容：
  √ 截取缺陷特征图像文件；
  √ 测试过程所使用的测试文件；
  √ 测试附加的打印机驱动程序；
  √ 再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息；
  √ 再次指明该缺陷是否在前一版本已经存在；
  √ 多个平台之间是否具有不同表现；
  √ 注释包含缺陷的隔离信息，指出缺陷的具体影响范围。

• 如，缺陷的注释可能包含下面的内容：
  √ 能在 Win2000 和 WinXP 文本框中显示文本内容，但不支持 Win98
  √ 屏幕刷新后，现象会消失。
  √ 使用二进制文件，不存在该错误。
  √ 参见附加的使用说明书和测试文件。

6.怎么提交高质量的缺陷报告

• 尽早提交缺陷报告。

• 清楚地说明此问题对用户价值的危害。

• 提供尽可能多的技术信息（如包含复现该缺陷需要的环境变量或测试所用的数据文件），方便程序员调试。

• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确。

• 易于搜索软件测试报告的缺陷。

• 一个缺陷报告中只报告了一种缺陷。

• 缺陷报告中不要提问题。

• 避免常见的错误
  √ 我（I）、你（You）、他/她（He/She）
  √ 情绪化的语言和强调符号！！！
  √ 似乎（Seems）、看上去可能（Appears to be）
  √ 认为比较幽默的内容
  √ 不确定的测试问题（Issues）/不确定是否是缺陷

三、缺陷的分类

1.缺陷的分类标准

2.根据缺陷类型对缺陷分类

• 功能缺陷

• 界面缺陷

• 文档缺陷

• 代码缺陷

• 算法错误

• 性能缺陷

3.根据缺陷的等级对缺陷分类

• A 类—致命缺陷，包括以下各种错误：
  √ 由于程序所引起的死机，非法退出；
  √ 死循环；
  √ 数据库发生死锁；
  √ 因错误操作导致的程序中断；
  √ 功能错误；
  √ 与数据库连接错误；
  √ 数据通讯错误

• B 类—严重缺陷，包括以下各种错误：
  √ 程序错误；
  √ 程序接口错误；
  √ 数据库的表、业务规则、缺省值未加完整性等约束条件

• C 类一般缺陷，包括以下各种错误：
  √ 操作界面错误（包括数据窗口内列名定义、含义是否一致）；
  √ 打印内容、格式错误；
  √ 简单的输入限制未放在前台进行控制；
  √ 删除操作未给出提示；
  √ 数据库表中有过多的空字段

• D 类—较小缺陷，包括以下各种错误：
  √ 界面不规范；
  √ 辅助说明描述不清楚；
  √ 输入输出不规范；
  √ 长操作未给用户提示；
  √ 提示窗口文字未采用行业术语；
  √ 可输入区域和只读区域没有明显的区分标志

• E 类—意见或建议

4.根据缺陷处理的优先级对缺陷分类

5.根据缺陷状态对缺陷分类

四、缺陷报告的处理

1.缺陷报告的简单处理流程/缺陷的生命周期

• 软件测试人员提交缺陷报告；

• 测试负责人审核后将缺陷报告分配给相关的开发人员修改；

• 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测；

• 返测通过的缺陷报告由负责人关闭，返测未通过的缺陷报告直接返回开发人员重新修改，缺陷报告直到缺陷被修复以后才关闭；

• 关闭或已解决的缺陷报告可能会被阶段性的复审重新打开，这些报告一旦被再次打开应该立即处理。

2.缺陷报告的标准处理流程

• 正常缺陷

• 重复缺陷

• 无效缺陷

• 推迟修改

• 验证不通过

• 描述不清楚
  

3.缺陷跟踪管理系统/缺陷管理工具

3.1 缺陷管理工具的功能

• 缺陷提交

• 缺陷跟踪

• 缺陷分析
  √ 有效的缺陷分析不仅可以评价软件质量，同时可以帮助项目组很好地掌握和评估软件的研发过程，进而改进研发过程，未对缺陷进行分析就无法对研发流程进行改进。
  √ 缺陷分析还能为软件新版本的开发提供宝贵的经验，进而在项目开展之前，指定准确、有效的项目控制计划，为开发高质量的软件产品提供保障。

3.2 常见缺陷管理工具

• Bugzilla（是一款很老的用于提交缺陷的开源软件，基于cgi动态网站）

• Bugfree（比Bugzilla用量多一点也是开源软件，不仅可以管理缺陷还可以管理用例，基于php动态网站）

• Mantis（可以管理用例和缺陷的php网站）

• Jira（部分公司在用，是收费的，基于php动态网站）

• ZenTao（禅道，可以管理需求丶用例丶缺陷的，安装简单）
  √ 在博主的软件测试之测试计划与工具（三）文章中已经详细介绍了禅道的安装与使用了

• Quality Center/Application Lifecycle Management
  √ 目前市场占用率最高的项目管理工具。
  √ 全球最大的测试工具提供商 Mercury Interactive 公司生产的企业级项目管理工具。
  √ 在博主的软件测试之测试计划与工具（一）文章中已经详细介绍了QC的安装和使用了
  √ 在博主的功能测试与项目实战之编写测试用例（重中之重）文章中已经详细介绍了ALM的安装和使用了

五、Bugfree的安装

1.挂载iso安装文件

• 在windows server 2008中挂载bugfree的iso安装程序
  

2.安装xampp

• 将挂载出的文件中执行以下安装程序
  
• 出现如下提示，直接确定
  
  
• 选择所需安装的服务即可
  
• 最后点击finish完成安装，并运行xampp即可
  
• 在浏览器中输入http://localhost，显示如下图表示已安装成功
  
• 点击中文进入xampp主页
  

3.xampp配置

• 点击左侧栏菜单中的安全，显示目前的XAMPP配置是不安全的，需要处理
  
• 点击上图中绿色框中的链接，为mysql数据库管理员root设置密码
  
• 设置Xampp目录保护，输入用户名和密码（自行设置，需要记住），以后再登录Xampp时，需要输入上述用户名和密码
  
• 用PHPmyadimin配置mysql，关闭上述网页，回到xampp主页，点击图中“phpMyAdmin”链接，输入mysql的用户及密码，点击确定
  
  
• 关闭网页，重新打开http://localhost/，输入前面设置的用户名密码即可
  
• 点击安全菜单，查看是否全部安全，发现如下一项还是不安全
  
• 解决方法：打开C:\xampp\php\php.ini文件，查找safe_mode字段，设置为ON
  
• 重启apache和mysql服务，重新刷新安全页面，全部显示安全
  

4.安装BugFree

• 将Bugfree网站源代码复制到XAMPP系统的htdocs目录下
  
• 在浏览器地址栏输入http://localhost/bugfree/install可以看到，bugfree的环境存在问题，如下图
  
• 以上错误，很好处理，看一眼就明白了什么意思，C:\xampp\htdocs\BugFile 下没有BugFile这个目录，所以我们创建一个即可
  
• 刷新页面后，问题解决
  
• 下拉页面点击继续
  
• bugfree进行配置，输入mysql数据库的用户名和密码，然后进行安装
  
• 安装完成后，输入初始用户名admin密码123456，点击登录
  
• 登录成后，如下所示，BugFree安装已经完成