全国咨询热线：136-9172-9932
本章节主要讲解“软件测试的相关术语以及缺陷管理”这两部分内容，缺陷管理的相关术语有Bug、缺陷(Defect)、错误(Error)、故障(Fault)和失效(Failure)。
(1)Bug：程序缺陷、计算机系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷，都可以统称为“Bug”，有时也泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。
(2)缺陷(Defect)：指静态存在于软件工作产品(文档、代码)中的错误，也指软件运行时，由于这些错误被激发引起的和软件产品预期属性的偏离现象。
(3)错误(Error)：指编写错误的代码，一种是语法错误(Syntax Error)，另一种是逻辑错误(Logical Error)。
(4)故障(Fault)：软件运行中出现的状态，可引起意外情况，若不加以处理可导致失效，是一个动态行为。
(5)失效(Failure)：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。
在测试过程中我们无法保证系统零缺陷发布，任何一个系统不管是简单还是复杂，一个简单的程序也存在Bug，一个花费大量人力资源开发的系统发布后也存在Bug。
但是这些Bug 在客户端不一定会被激活，也不一定会形成故障，有的功能客户几乎不使用，这样Bug 被很好地隐藏起来，很难被客户发现。有时一些Bug 也可能被激活，但如果其带来的负面影响很少，也不会表现为故障。
故障一定会导致系统失效吗?答案是否定的，开发工程师在开发系统时会考虑软件在使用期间可能出现的故障，并针对这些可能出现的故障采取了一系列的预防措施。比如数据库可能出现数据丢失的问题，为了避免这种失效出现，在开发过程中采用备份的方式来容错，这样当一个数据库出现异常时，另外一个数据库还可以正常工作。
缺陷不一定会导致故障，故障不一定会导致失效，但故障如果没有得到正确的处理则会导致失效。
缺陷管理，缺陷管理的目的是保证缺陷被有效地跟踪和处理，保证缺陷的信息一致性，不致于丢失，能正确地获取缺陷的信息，用于缺陷分析和产品质量度量。缺陷管理的内容包括缺陷的严重等级、缺陷的管理流程、缺陷的生命周期和缺陷的状态转变。
1、缺陷的严重等级
缺陷的严重等级是指软件缺陷对软件质量的破坏程度，即软件缺陷的存在将对软件的功能和性能产生怎样的影响。
7.1.3 节中介绍了缺陷的严重等级一般分为四类：致命、严重、一般和建议。对于不同的缺陷管理工具，其缺陷的等级划分可能有所不同，但也都大同小异。
如何定义缺陷的严重等级?一般认为导致系统出现死机现象或崩溃的缺陷为致命缺陷，这种定义是否正确呢?假如修改系统设置项导致系统偶尔出现死机现象，那么还能定义为致命问题吗?答案是否定的。
因此仅仅通过缺陷引起的结果来判断缺陷的严重等级是不客观的，也是不科学的。衡量缺陷的严重等级应该从两个维度来分析：一是该功能被客户使用的概率;二是缺陷带来的影响。
(1)该功能被使用的概率。
功能被使用的概率是指该功能在客户端可能被使用的程度，关于功能被使用的概率需要与业务专家确定，一般情况下核心业务和一般业务被使用的概率很大，如果这些业务存在缺陷则会直接影响客户对产品质量的认可程度，如手机通话功能。而对于一些类似于系统设置的功能，显然被使用的概率很小，有的客户可能只会使用一次，类似这种功能即使存在一些偶发的缺陷，也不会直接影响客户对产品质量的认可度，如手机设置时间格式的功能。
(2)缺陷影响。
缺陷影响是指由于该缺陷对系统带来的影响。如一些致命的影响，某功能导致系统出现死机等。在工作中划分缺陷严重等级时需要将这两个维度结合起来考虑，不能仅考虑某个方面。西门子公司有着明确的规定，在三级菜单以下的功能，即使由于功能的缺陷导致系统出现崩溃的现象，最多也只能定义为一般问题。而测试工程师最容易犯的错是通过缺陷带来的影响来决定缺陷的严重等级。
在工作中缺陷严重等级的定义还容易受到开发工程师解决缺陷的难易程度影响，开发工程师认为修改缺陷越困难，这类缺陷严重等级越高;反之修改缺陷越简单，这类缺陷严重等级越低。
如界面显示问题，在本地化开发过程中，系统主界面一些字样显示出现乱码的情况，这类问题的严重等级应该设置为严重，但如果将缺陷的严重等级设置为严重，开发工程师就无法理解，他们认为这类问题很容易解决，应该将其严重等级设置为建议或提示才对。西门子公司有着明确的规定，对于主界面或三级菜单以内的字符，如果出现显示不全或乱码现象，都应该将其设置为严重问题。
本章节关于“软件测试的相关术语以及缺陷管理”的内容就学习到这里，下一章节学习“缺陷的管理流程以及缺陷的生命周期”这两部分内容，大家觉得文章有用的话，记得每天来这里和小编一起学习涨薪技能哦。
