软件测试技术第5章ppt课件.pptx

《软件测试技术第5章ppt课件.pptx》由会员分享，可在线阅读，更多相关《软件测试技术第5章ppt课件.pptx（108页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件测试技术及实践詹慧静 陈燕 段相勇第第5 5章章 缺陷报告和测试评估缺陷报告和测试评估在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确 了解软件缺陷的基本知识。了解软件缺陷的生命周期。熟练掌握报告软件缺陷。了解重现软件缺陷含义及常用的分析技术。了解软件缺陷跟踪管理。了解软件缺陷的评估。了解测试评审。本章学习目标对于软件缺陷，需要学习以下内容：软件软件缺陷的定义与描述缺陷的定义与描述。软件软件缺陷的种类。缺陷的种类。软件软件缺陷的属性。缺陷的属性。5.1软件缺陷在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的

2、梯度，由浅入深，所提出的问题也很明确5.1.1软件缺陷的定义与描述1.软件缺陷的定义软件缺陷是指软件开发过程的各个阶段中存在的不完美甚至存在错误的地方，这些不完美和错误造成了软件缺陷，如编码过程中出现的语法、拼写错误或者存在不正确的程序语句等。简单地说，软件缺陷就是指在软件(包括数据、程序、文档)之中存在的那些不希望或不能接受的、会导致软件产生质量问题的偏差。在行业定义中，软件缺陷通常又被称为defect或bug，是指软件或程序中存在的某种破坏正常运行能力的问题和错误，其存在会导致软件产品在某种程度上不能满足用户的需要。从软件内部看，缺陷是软件在开发或维护过程中存在的问题或错误。从软件外部看，

3、缺陷是系统所需要实现的某种功能的失效或违背。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.1软件缺陷的定义与描述软件缺陷是影响软件质量的关键因素之一，发现并排除软件缺陷是软件生存周期中的一项重要工作。每一个开发软件的组织都必须妥善处理软件中存在的缺陷，它不仅关系到软件的质量，更关系到软件运用在工业生产中是否会导致安全隐患。按照一般的定义，只要符合下面规则中的一个，就可叫做软件缺陷：（1)软件未达到软件需求说明书中规定的功能。（2)软件超出软件规格说明书中指明的范围。（3)程序中存在语法错误。（4)程序没有达到用户的期望。（5

4、)程序中存在拼写错误。（6)软件运行出现错误。（7)运行缓慢，用户体验差，最终用户认为软件使用效果不好。（8)软件语言描述过于技术化，非专业人员无法理解。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.1软件缺陷的定义与描述2.软件缺陷的描述软件缺陷的描述是报告软件缺陷的基本部分，那么，当发现软件缺陷后，应当如何描述软件缺陷呢？一个好的软件缺陷描述，需要使用简单、准确和专业的语言来呈现缺陷的本质。在描述软件缺陷时，不能信息含糊不清，从而误导开发人员。准确描述软件缺陷是非常重要的，这是因为:（1)清晰准确的软件缺陷描述可以提高与

5、开发人员的沟通效率。（2)提高软件缺陷修复的速度，使每一个小组能够有效地工作。（3)提高开发人员对测试人员的信任度，并得到开发人员对软件缺陷的有效响应。（4)加强开发人员、测试人员和管理人员的协同工作。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.1软件缺陷的定义与描述2.软件缺陷的描述适用于有效描述软件缺陷的规则主要有以下几个：（1)单一和准确。每个缺陷报告只针对一个软件缺陷。若在一个报告中报告多个软件缺陷，可能会导致其中部分缺陷被忽略，而不能得到修正。（2)可以再现缺陷。提供重现缺陷的精确操作步骤，使开发人员容易看懂，只

6、有再现了缺陷，才能正确地修复缺陷。（3)描述要完整。提供完整的软件缺陷的步骤和信息，例如图片信息、报错截图、日志文件等。（4)短小简练。通过使用关键词，既可以使软件缺陷的标题短小简练，又能准确解释产生缺陷的现象。（5)描述特定条件。许多软件功能要在某种特定条件下才会产生缺陷，所以软件缺陷描述不能忽视对这些特定条件(如特定的操作系统、浏览器或某些设置等)的描述，从而帮助开发人员发现产生软件缺陷的线索。（6)补充完善。从发现缺陷那一刻起，测试人员的责任就是保证该缺陷及时得到正确的报告，并且受到应有的重视，继续监视其修复的全过程。（7)描述但不做评价。在软件缺陷描述中不要带有个人观点对开发人员进行评

7、价。软件缺陷报告是针对问题本身，只需将缺陷事实或现象客观地描述出来，而不能进行评价或议论。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.2软件缺陷的种类1.从开发者角度划分从开发者角度将软件缺陷分为需求缺陷、设计缺陷、文档缺陷、代码缺陷、测试缺陷、过程缺陷、计算错误和边界错误。（1)需求缺陷包括需求有误、需求逻辑错误、需求不完备、需求文档描述问题、需求更改。（2)设计缺陷包括设计不合理、设计文档描述出现问题、设计变更带来的问题。（3)文档缺陷指在文档的静态检查过程中发现的缺陷，例如通过测试需求分析及文档审查发现的文档缺陷。（

8、4)代码缺陷指对代码进行同行评审、审计或代码检查过程中发现的缺陷。（5)测试缺陷指在测试执行活动中发现的被测对象(一般是指可运行的代码或软件系统)的缺陷，测试缺陷不包括静态测试中发现的问题。（6)过程缺陷指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于开发过程的缺陷和问题。过程缺陷的发现者一般是质量经理、测试经理及管理人员等。（7)计算错误指代码中出现的计算错误，例如使用了错误的运算公式、累加器未进行初始化等。（8)边界错误指的是输入边界和输出边界或输入等价类边界的错误，这是最容易发生的一类错误。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度

9、，由浅入深，所提出的问题也很明确5.1.2软件缺陷的种类1.从开发者角度划分从开发者角度例如，程序本身无法处理超越边界所导致的错误，由于开发人员在声明变量或使用边界范围时不小心引起的错误等。下面是一个典型的缓冲区溢出可能导致攻击的错误：#include;#include;voidwhy_here(void)/这个函数没有任何地方调用过printf(whyuhere!nn);printf(youaretrappedheren);system(pause);_exit(0);intmain(intargc,char*argv)intbuff1;buff3=0 x004113c0;/buff3=0

10、x0041111d;buff3=why_here;system(pause);return0;在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.2软件缺陷的种类1.从开发者角度划分从开发者角度执行结果如下：从图中可以看出，虽然在代码中并没有调用why_here函数，但why_here函数还是被执行了，这是因为main函数里面赋值时发生溢出，数组实际地址变成0 x0041111d，就会跳转到why_here执行。只需要查看调试过程的汇编结果和程序执行过程中的监视窗口，不难发现其buff溢出，如果这段代码的是恶意代码，那么将会对系统

11、造成严重的损害。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.2软件缺陷的种类2.从使用者角度从使用者角度划分划分从使用者角度，可以将软件缺陷分为功能未满足用户需求、使用不方便、交互性不好、使用性能不佳、未做好错误处理、控制流程错误、对硬件兼容性差及文档错误。1）功能不能满足用户需求：功能不能满足用户需求包括功能不正常、所提供的功能不完善或其它方面的功能问题在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.2软件缺陷的种类2.从使用者角度从使用者角度划分划分（

12、1）功能不正常：简单地说，就是软件应该提供的功能，在使用上并不符合产品设计规格说明书中规定的要求，或是运行结果达不到预期设计，或是根本无法使用，这类错误常常会发生在测试过程的初期和中期。例如，在用户接口上所提供的选项及动作，使用者操作后没有反应。（2）所提供的功能不完善：与功能不正常不同，软件功能不完善指的是软件提供的功能能运行，甚至软件的功能运行结果也符合设计规格的要求，但对于使用者来说却认为该功能是不完整的，是没有完全满足他们需求的。系统测试人员在测试结果的判断上，必须从使用者的角度进行思考，即从用户体验出发，来判断提供的功能是不是真正满足使用者的需求。（3）其它功能方面的问题：包括是不是

13、有重复的功能、多余的功能等。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.2软件缺陷的种类2.从使用者角度从使用者角度划分划分2）软件在使用上不方便：如果一个软件，使用者不知如何使用或难以使用，就一定是在软件产品的设计上存在问题。一个好用的软件，会尽量做到让使用者容易上手，导航清晰，易于操作，使用方便。3）与操作者交互不良：一个好的软件必须与操作者之间可以实现正常交互。在操作者使用软件的过程中，软件必须很好地响应操作者。例如在浏览网页时，如果操作者在某一网页填写信息，但是输入的信息不足或有误。当点击“确定”按钮后，网页此时提

14、示操作者输入信息有误，却并未指出错误的哪里，操作者只好回到上一页重新填写，或直接放弃离开。产生这个问题的原因是在软件与操作者互动方面未做完整的设计。4）使用性能不能满足用户的需求：被测软件功能正常，但性能不能满足用户需求，如事务处理速率、并发量、数据量、压缩率、响应时间等不能满足用户的使用要求。此类缺陷通常是由于开发人员采用了错误的解决方案，或使用了不恰当的算法导致的。如大数据量并发压力测试对于分布式软件系统而言是必须进行的，因为分布式软件系统对并发量、稳定性的要求远比其它软件要高。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.

15、1.2软件缺陷的种类2.从使用者角度从使用者角度划分划分5）未做好错误处理：软件除了避免出错之外，还要做好错误处理。许多软件之所以会产生错误，就是因为程序本身对于错误和异常处理的缺失。例如被测软件读取即插即用移动设备时，移动设备插上时程序正常读取，但刚好所读取的盘已被移出时。当程序读取这个盘时未做好处理，程序发现问题报错，此时操作系统为保护系统自身只能中断程序执行。由此可见一个好的软件系统必须能对各种错误及异常情况进行处理。6）控制流程错误：软件控制流程的好坏考验开发人员对软件设计是否严谨，软件各状态间转变是否合理，要依据流程控制。例如导出数据表格功能，当从某个表单导出数据时，选择好要导出的数

16、据点击导出后，软件就将数据导出了，可是用户不知道导出的文件在何处，用户希望自己定义导出的目录。而软件未向用户提供可以更改导出目录的选择，这就是软件流程控制不完整的错误问题。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.2软件缺陷的种类2.从使用者角度从使用者角度划分划分7）对不同硬件兼容性差：软件安装在某些硬件环境下不能正常工作。例如，在开发程序时使用的是Intel的处理器，程序打包生成后放在AMD处理器下运行会报错。8）软件文档错误：影响发布和维护的文档包括注释、用户手册、设计文档等。软件文档错误除了软件所附带的使用手册、

17、说明文档及其它相关的软件文档内容错误之外，还包括软件使用接口上的错误文字和错误用语、产品需求设计、设计说明书等的错误。错误的软件文档除了降低产品质量外，还会误导用户。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.3软件缺陷的属性为了便于跟踪软件缺陷，避免遗漏严重的软件缺陷，需要定义软件缺陷的属性，为开发人员和测试人员提供修复缺陷的参考。软件缺陷的主要属性有缺陷标识、缺陷类型、缺陷严重程度、缺陷产生的可能性、缺陷的优先级、缺陷状态、缺陷起源、缺陷来源和缺陷根源等。1.缺陷标识缺陷标识缺陷标识是对某个缺陷进行标识的唯一标识符，通

18、常用数字序号缺陷标识是对某个缺陷进行标识的唯一标识符，通常用数字序号表示，方便对缺陷进行索引等管理操作表示，方便对缺陷进行索引等管理操作。2.缺陷类型缺陷类型所谓缺陷类型是指根据缺陷的自然属性进行划分得到的不同缺陷种类。常见的软件缺陷类型如下表所示：在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.3软件缺陷的属性缺陷缺陷类型型描述描述功能缺陷功能缺陷能够影响各种系统功能、逻辑的缺陷接口缺陷接口缺陷与其他模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷验证缺陷缺陷提示的错误信息或不合适的数据验证等缺陷软件包缺陷件包缺

19、陷因为软件配置库、软件变更管理或软件版本控制而引发的错误文档缺陷文档缺陷文档（包括注释、用户手册、设计文档等）的缺陷影响了软件的发布和维护算法缺陷算法缺陷算法错误用用户界面缺陷界面缺陷包括对用户界面、人机交互特性（如屏幕格式、结果输出格式、用户输入灵活性等）产生影响的缺陷性能缺陷性能缺陷软件的性能（如执行时间、事务处理速率等）不满足系统可测量的属性值准准则缺陷缺陷不符合各种标准（如编码标准、设计符号等）的要求在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.3软件缺陷的属性3.缺陷缺陷严重严重程度程度缺陷严重程度是指因为软件缺陷

20、而引发的故障对软件产品的影响程度，其判断应该依据软件最终用户的观点。通常可将缺陷严重程度分为致命（Fatal）、严重（Critical）、一般（Major）、较小（Minor）几个级别，如下表所示。程度级别描述致命系统的某个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全严重系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响一般系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题较小给操作者带来不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字

21、、文字排列不整齐等一些小问题在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.3软件缺陷的属性4.缺陷缺陷产生产生可能性可能性缺陷产生可能性是指某个缺陷发生的概率，通常将其划分为总是、通常、有时、很少几种可能性，如下表所示。可能性描述总是即产生这个软件缺陷的概率是100%通常按照测试用例，通常情况下会产生这个软件缺陷，其产生的概率大概是80%90%有时按照测试用例，有时候产生这个软件缺陷，其产生的概率大概是30%50%很少按照测试用例，很少产生这个软件缺陷，其产生的概率大概是1%5%在整堂课的教学中，刘教师总是让学生带着问题来学

22、习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.3软件缺陷的属性5.缺陷缺陷的优先级的优先级缺陷的优先级是指某个缺陷必须被修复的紧急程度，通常可划分为立即解决、高优先级、正常排队、低优先级几个级别，高优先级的缺陷应该优先修复。缺陷的优先级如下表所示。级别描述立即解决某个缺陷导致系统几乎不能使用或者测试不能继续时，需立即修复高优先级某个缺陷严重到影响测试，需要优先考虑正常排队某个缺陷在产品发布之前必须被修复，需正常排队等待修复低优先级某个缺陷可以在开发人员有时间的时候才去修复在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题

23、也很明确5.1.3软件缺陷的属性6.缺陷缺陷状态状态缺陷的状态是指描述缺陷通过一个跟踪修复过程的进展情况，在这一过程中，缺陷可被描述为激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息等状态，如下表所示。状态描述新建首次发现的缺陷，提交到缺陷库中时设置为此状态已分配开发人员确认提交的某个缺陷需要修复，负责人就将这个缺陷分配给某位开发人员准备进行处理打开开发人员开始处理缺陷已解决无法修复缺陷因技术原因或其他产品原因无法进行修复重复问题对某个功能点的同一个缺陷重复提交无法重现根据缺陷的描述无法重现缺陷稍后处理修复需要更多的信息或因时间、严重程度等关系当前暂不修复不

24、必修复由于理解错误而提交的缺陷已修复缺陷已经被修复被拒绝经分析后拒绝的缺陷重新打开被拒绝或已修复的缺陷进行验证后确定仍然为缺陷，需要设置为该状态已关闭缺陷处理完毕后，关闭该缺陷在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.3软件缺陷的属性7.软件软件缺陷的起源缺陷的起源缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶段，可分为：1）需求阶段发现的软件缺陷。2）在概要设计和详细设计阶段发现的软件缺陷。3）在编码阶段发现的软件缺陷。4）在测试阶段发现的软件测试缺陷。5）在用户使用阶段发现的软件缺陷。各个阶段发现的软件缺陷所占比

25、例通常为：1）需求阶段发现的软件缺陷占54%。2）设计阶段发现的软件缺陷占25%。3）编码阶段发现的软件缺陷占15%。4）其它占6%。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.3软件缺陷的属性8.软件软件缺陷的来源缺陷的来源缺陷来源是指引发某个软件缺陷的位置，通常软件缺陷来源于需求说明书、设计文档、系统集成接口、数据流（库）、程序代码等，如表5-6所示。表5-6缺陷来源来源描述需求说明书由于需求说明书中的错误或表述不清楚而引起的问题设计文档由于设计文档描述不准确或与需求说明书不一致而引起的问题系统集成接口由于模块参数不匹

26、配或团队之间缺乏沟通而引起的问题数据流（库）由于数据字典、数据库中的错误而引起的缺陷程序代码由于编码中的问题所引起的缺陷在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.1.3软件缺陷的属性9.缺陷缺陷根源根源缺陷的根源是指产生缺陷的根本因素，包括测试策略、过程、工具和方法、团队（人员）、硬件、软件和工作环境等，如表5-7所示。表5-7缺陷根源根源描述测试策略如错误的测试范围，对测试目标产生误解和超越能力的测试目标等过程、工具和方法如无效的需求收集过程、过时的风险管理过程、不适用的项目管理方法、没有估算规程及无效的变更控制过程等。团

27、队（人员）如项目团队职责不明晰、项目团队缺乏经验、项目团队士气低下及缺乏培训等。缺乏组织和通讯如测试缺乏用户参与、测试职责不明确和管理失败等。硬件如处理器缺陷导致算术精度丢失、内存溢出等。软件如软件设置不当或缺乏、操作系统错误导致无法释放资源、工具软件的错误、编译器的错误等。工作环境如组织机构调整、预算改变和工作环境恶劣等。对于软件缺陷的生命周期，需要学习如下内容：软件缺陷生命周期的定义软件缺陷生命周期的几个阶段软件缺陷生命周期管理工具5.2软件缺陷的生命周期1.软件软件缺陷生命周期的缺陷生命周期的定义定义在软件开发过程中，缺陷拥有自身的生命周期，缺陷在其生命周期中会处于不同的状态，确定的生命

28、周期保证了过程的标准化。软件缺陷的生命周期是指从软件缺陷被发现、报告、缺陷被修复、验证直至确保不会再出现之后关闭的整个过程。5.2软件缺陷的生命周期2.软件软件缺陷生命周期的四个阶段缺陷生命周期的四个阶段根据IEEEStd10441993中的描述，软件缺陷生命周期主要由四个阶段组成：识别阶段（Recognition）、调查阶段（Investigation）、改正阶段（Action）和总结阶段（Disposition）。无论是缺陷生命周期的哪个阶段，都包括了记录（Recording）、分类（Classifying）和确定影响（IdentifyingImpact）三个活动。缺陷生命周期的四个阶段依

29、次进行，但是缺陷可能会在这几个阶段中进行多次迭代，如图5-2所示。5.2软件缺陷的生命周期2.软件软件缺陷生命周期的四个阶段缺陷生命周期的四个阶段图5-2缺陷生命周期的四个阶段5.2软件缺陷的生命周期2.软件软件缺陷生命周期的四个阶段缺陷生命周期的四个阶段缺陷生命周期的各个阶段及其中的各项活动描述如下：图5-2缺陷生命周期的四个阶段5.2软件缺陷的生命周期2.软件软件缺陷生命周期的四个阶段缺陷生命周期的四个阶段缺陷生命周期的各个阶段及其中的各项活动描述如下：1）识别阶段缺陷的识别是整个缺陷生命周期的第一个阶段，它可能发生在软件开发生命周期的任何一个阶段。缺陷的识别可以由参与项目的任何相关人员来

30、完成，如系统人员、开发人员、测试人员、支持人员、用户等，都可能进行缺陷的识别。在缺陷识别阶段的主要活动有：（1）记录：在缺陷识别阶段，需要记录缺陷的相关信息，包括发现缺陷时的支持数据信息和环境配置信息，如被测系统的硬件信息、软件信息、数据库信息和平台信息等。（2）分类：在缺陷识别阶段，需要对缺陷相关的一些重要属性进行分类，主要包括发现缺陷时执行的项目活动、引起缺陷的原因、缺陷是否可以重现、缺陷发现时的系统状态、缺陷发生时的征兆等。（3）确定影响：根据缺陷发现者的经验和预期，判断缺陷可能会造成的影响，如缺陷的严重程度、优先级以及缺陷对成本、进度、风险、可靠性、质量的影响等。5.2软件缺陷的生命周

31、期2.软件软件缺陷生命周期的四个阶段缺陷生命周期的四个阶段缺陷生命周期的各个阶段及其中的各项活动描述如下：2）调查阶段经过缺陷识别后，需要对每个可能的缺陷进行调查，以发现可能存在的其他问题并寻找相关的解决方案。在缺陷调查阶段的主要活动包括：在缺陷识别阶段的主要活动有：（1）记录：在缺陷调查阶段，需要记录相关的数据和信息，并对缺陷识别阶段记录的信息进行更新。缺陷调查阶段记录的信息包括缺陷调查者的信息、缺陷调查的计划开始时间、计划结束时间、实际开始时间、实际结束时间、调查工作量等。（2）分类：在缺陷调查阶段，需要对缺陷进行分类的属性包括缺陷引起的实际原因、缺陷的来源、缺陷的具体类型等。此外，对缺陷

32、识别阶段中的分类信息，要进行检查和更新。（3）确定影响：根据缺陷调查阶段的分析结果，对缺陷识别阶段的影响进行分析和更新。5.2软件缺陷的生命周期2.软件软件缺陷生命周期的四个阶段缺陷生命周期的四个阶段缺陷生命周期的各个阶段及其中的各项活动描述如下：3）改正阶段根据缺陷调查阶段中得到的结果和信息，就可以采取相应的改正措施解决缺陷问题：（1）进行缺陷修复。需要进行相关的回归测试和再测试，避免由于缺陷的修复而影响原有的功能。（2）针对开发过程和测试过程的改进建议，以避免在将来的项目中重复出现相似的缺陷。在缺陷改正阶段的主要活动包括：（1）记录：在缺陷改正阶段，需要记录改正缺陷的相关支持数据信息，包括

33、需要修改的条目、需要修改的模块、修改的描述、修改的负责人、计划修改开始的时间、计划修改完成的时间等。（2）分类：当合适的修改计划或者活动确定以后，需要对下面的信息进行分类：缺陷修复的优先级（例如：是马上修改、延期修改还是不修改）、缺陷的解决方法、缺陷修复的改正措施等。（3）确定影响：对在缺陷识别阶段、缺陷调查阶段中得到的影响分析进行合适的检查，并在需要的时候进行更新。5.2软件缺陷的生命周期2.软件软件缺陷生命周期的四个阶段缺陷生命周期的四个阶段缺陷生命周期的各个阶段及其中的各项活动描述如下：4）总结阶段总结阶段是缺陷生命周期中的最后一个阶段，这一阶段的主要活动包括：（1）记录：在缺陷总结阶段

34、，需要对一些支持数据信息进行记录，例如：缺陷关闭时间、文档更新完成时间等。（2）分类：针对缺陷进行确认测试和相关的回归测试以后，就可以将缺陷的状态进行分类，例如：关闭状态、延迟状态或者合并到其他项目中去等。（3）确定影响：对在缺陷识别阶段、缺陷调查阶段和缺陷改正阶段中得到的影响分析进行合适的检查，并在需要的时候进行更新。5.2软件缺陷的生命周期2.缺陷在生命周期中的缺陷在生命周期中的状态状态缺陷在其生命周期的不同阶段会处于不同的状态，最理想的一种状态是软件缺陷被打开、解决和关闭。但这种状态在实际工作中是很难做到的，因此，软件缺陷在其生命周期中的状态要复杂得多，如图5-3所示：5.2软件缺陷的生

35、命周期2.缺陷在生命周期中的缺陷在生命周期中的状态状态图5-3缺陷在生命周期中的状态5.2软件缺陷的生命周期2.缺陷在生命周期中的缺陷在生命周期中的状态状态1）新缺陷：当发现一个缺陷并提交到缺陷库中时，缺陷则为新缺陷状态。缺陷的提交通常可以有以下几种情况：(1)由测试人员来提交软件中新发现的缺陷。(2)由开发人员自己在组件测试或代码走读过程中提交。(3)由软件的最终用户或使用现场反馈得到的缺陷报告。(4)从需求和设计阶段的文档评审过程中发现的缺陷。(5)在编码阶段的代码评审和代码静态分析过程中发现的缺陷。(6)在测试阶段的动态测试过程中发现的缺陷。在使用阶段的用户反馈过程中发现缺陷。2）接受：

36、对已经提交的缺陷报告进行评审，评审的内容主要有确认缺陷报告中描述的问题是否确实是一个缺陷、提交的缺陷报告是否符合要求等，评审通过后，将缺陷状态设置为“接受”。3）分配：将缺陷状态为“接受”的缺陷分配给相关人员进行问题定位和修复，并将缺陷状态设置为“分配”。4）打开：当开发人员开始对缺陷进行处理时，将缺陷状态设置为“打开”。5.2软件缺陷的生命周期2.缺陷在生命周期中的缺陷在生命周期中的状态状态5）交付：当找到解决缺陷的方法，并已经通过使用该方法对缺陷进行了处理，则将将缺陷状态设置为“交付”，然后交付给版本经理。6）解决：版本经理将处理后的缺陷（“交付”状态）转交给相关的开发小组进行验证，如果验

37、证通过，则缺陷状态设置为“解决”。7）已修改：版本经理将已经解决的缺陷转交给相关的测试小组进行确认测试，如果测试通过，则缺陷状态设置为“已修改”。8）关闭：对修改后的缺陷，缺陷评审委员将对整个缺陷修复过程进行评审，如果评审通过，则将缺陷状态设置为“关闭”。5.2软件缺陷的生命周期2.缺陷在生命周期中的缺陷在生命周期中的状态状态需要注意的是，在缺陷的生命周期中除了以上缺陷的状态外，实际工作中，软件缺陷还存在一些其他的状态：1）研究：当缺陷分配给开发人员时，开发人员并不是都能立刻找到相关的解决方案，因此，开发人员需要对缺陷和引起缺陷的原因进行调查研究，此时可以将缺陷状态设置为“研究”。2）询问和回

38、答：在进行缺陷修复时，如果相关人员认为缺陷描述信息不够明确，或希望能够得到更多与缺陷相关的配置和环境条件等，可以将缺陷状态改为询问和回答。3）拒绝：缺陷评审委员会对缺陷进行评审时，如果认为提交的问题不是缺陷，或者开发人员经过研究分析，认为问题不是缺陷，并将具体的理由写入缺陷描述，那么缺陷评审委员会则将缺陷状态设置为“拒绝”。4）重复：缺陷评审委员会进行评审时，如果发现新缺陷和某个已经提交的缺陷描述的是针对同一个功能点的同一个问题，那么将缺陷状态设置为“重复”。5）延期：缺陷不能在当前版本解决。6）无计划：虽然确认了缺陷，但在用户需求中没有要求或计划。5.2软件缺陷的生命周期对于报告软件缺陷，需

39、要学习如下内容：报告软件缺陷的原则软件缺陷的报告模板软件缺陷报告的特点越早地提交缺陷信息，程序员就越能尽早地改正缺陷。相对于制定测试计划和实际测试工作，报告软件缺陷是软件测试过程中最省时、省力的工作。但事实上，如果能把缺陷描述得越清楚，开发人员就越能更好地修复缺陷。软件缺陷的报告对开发人员的工作有直接的影响，包括付出的时间，消耗的精力等。因此，当有问题出现时，应该尽可能详细填写缺陷报告单，如果只是粗略记录，当需要填写报告时，就很容易忽略某些问题的复杂程度和严重程度，从而导致修复困难。本节将对如何报告软件缺陷才能更有效地促进与开发人员沟通交流进行详细的介绍。5.3报告软件缺陷在整堂课的教学中，刘

40、教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.3.1报告软件缺陷的原则在软件测试过程中，对于发现的大多数软件缺陷，都要求测试人员能够简洁清晰地把发现的问题报告给审查缺陷小组，并提供所需要的全部缺陷信息，开发维护小组才能决定怎么去处理。但是一些缺陷报告经常包含过少或过多信息，而且组织混乱，难以理解。软件开发模式的不同和修复小组也是不固定的，导致缺陷被退回，从而延误及时修正，最坏的情况是由于没有清楚地说明缺陷的影响，开发人员忽略了这些缺陷，使这些缺陷随软件版本一起发布出去。因此，软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务，要理

41、解缺陷报告读者的期望，遵照缺陷报告的写作准则，书写内容完备的软件缺陷报告。在大多数情况下，决定权在项目管理人员中手中，还有一些情况是在程序员手里，也可能通过会议讨论决定。一般情况，由软件测试专业人员或专业团队来审查发现的软件缺陷，判定是否修复。但无论什么情况，软件测试提供的描述软件缺陷的文档都十分重要，若软件测试人员对软件缺陷描述不清楚，报告不及时有效，也没有建立强大的测试用例来证明缺陷必须修复，那么将有可能导致软件缺陷被误认为不是软件缺陷，不值得修复或者被认为修复风险太大等，从而产生偏离事实的决定。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出

42、的问题也很明确5.3.1报告软件缺陷的原则报告软件缺陷的目的是保证修复人员可以重现报告的错误，进而分析错误产生的原因，查看产生的日志，定位错误，然后修正。因此报告软件缺陷的基本要求是及时、准确、简洁、完整、规范：（1)尽快报告。软件缺陷发现得越早，留给修复的时间就越多。例如，在软件发布前几个月从软件界面上的中文描述中找出错别字，该缺陷被修复的可能性就非常高。（2)有效描述。软件缺陷的基本描述是软件缺陷报告的基础部分。一个好的描述需要使用简单、准确、专业的语言清晰地呈现缺陷。如信息含糊不清，可能会误导开发人员。软件缺陷的描述也是测试人员就一个软件问题与开发工程师交流的最好机会。一个好的描述，需要

43、使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员，因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。（3)完备友好。写出的报告应该完备、易于理解且没有敌意，如果报告迷惑或惹恼了程序员，它就不会使程序员愿意改正问题、修复缺陷。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.3.2软件缺陷报告模板ANS/IEEE829-1988标准定义了一个软件缺陷报告的文档，用于报告在测试过程期间发生的任何异常事件，模板标准如下：IEEE829-1988软件测试文档编制标准软件缺陷报告模

44、板目录1软件缺陷报告标识符2软件缺陷总结3软件缺陷描述3.1输入3.2期望得到的结果3.3实际结果3.4异常情况3.5日期和时间3.6规程步骤3.7测试环境3.8再现尝试3.9测试人员3.10见证人4影响在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.3.2软件缺陷报告模板关于ANS/IEEE829-1988标准的各项解释如下：1.软件缺陷报告标识符软件缺陷报告标识符就是指定软件缺陷报告的唯一ID，用于定位和引用。2.软件缺陷总结简明扼要地陈述事实，总结软件缺陷。给出所测试软件的版本引用信息、相关的测试用例和测试说明等信息。对于任

45、何已确定的软件缺陷，都要给出相关的测试用例，如果某一个软件缺陷是意外发现的，也应该编写一个能发现这个意外软件缺陷的测试用例。3.软件缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，一个好的描述需要使用简单的、准确的、专业的语言来抓住缺陷的本质。软件缺陷报告的编写人员应该在报告中提供足够多的信息，使一般修复人员能够理解和再现事件的发生过程。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.3.2软件缺陷报告模板下面是软件缺陷描述中的各个内容。(1)输入。记录描述实际测试时采用的输入(例如文件、按键等)数据。(2)期望得到的结果。用来记

46、录期望得到的结果，正在运行的测试用例的设计结果。(3)实际结果。记录测试程序的实际运行结果。(4)异常情况。记录实际结果与预期结果的差异。也记录一些其他重要数据，例如有关系统数据量过小或者过大、一个月的最后一天、闰年等。(5)日期和时间。记录软件缺陷发生的日期和时间。(6)规程步骤。记录软件缺陷发生的步骤。如果使用的是很长的、复杂的测试规程，这一项就特别重要。(7)测试环境。记录本次测试所采用的环境，例如系统测试环境、验收测试环境、客户的测试环境以及测试场所等。(8)再现尝试。记录为了再现这次测试做了多少次尝试确定它是一个缺陷。(9)测试人员。记录进行这次测试的人员情况。(10)见证人。记录了

47、解此次测试的其他人员情况或相关人员。在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.3.2软件缺陷报告模板4.影响软件缺陷报告的“影响”是指软件缺陷对用户造成的潜在影响。在报告软件缺陷时，测试人员要对软件缺陷分类，以简明扼要的方式指出其影响。经常使用的方法是给软件缺陷划分严重性和优先级。当然，具体方法各个公司不尽相同，但是通用原则是一样的。测试实际经验表明，虽然可能永远无法彻底克服在确定严重性和优先级过程中所存在的不精确性，但是通过在定义等级过程中对较小、较大和严重等主要特征进行描述，完全可以把这种不精确性减小到一定程度。关于重现

48、缺陷，需要学习以下内容：重现缺陷的基本概念及重现缺陷分析。重现缺陷的基本概念及重现缺陷分析。可可重现缺陷分析技术。重现缺陷分析技术。缺陷缺陷如何重现。如何重现。5.4重现缺陷关于重现缺陷，需要学习以下内容：重现缺陷的基本概念及重现缺陷分析。重现缺陷的基本概念及重现缺陷分析。可可重现缺陷分析技术。重现缺陷分析技术。缺陷缺陷如何重现。如何重现。5.4重现缺陷重现缺陷，也可称为再现缺陷，是指当无意或按照测试用例发现一个缺陷的时候，需要把这个缺陷的中间步骤记录下来，然后可以依据这个步骤将这个缺陷再演示出来，并且缺陷记录步骤能够描述如何让程序进入到这个缺陷状态。需要注意的是，重现缺陷通常要采取繁杂的步骤

49、才能实现，或者根本无法重现，开发人员可以根据相对简单的错误信息就能找出问题所在。此外，一个软件缺陷重现的问题有时光凭个人是难以实现的，需要团队的共同努力。第一次发现缺陷后，将重现的步骤中，可以展示缺陷的必要步骤写明，尽量不要有多余的操作，需精简步骤，这就叫优化。在优化的过程中，记录下前后两次的步骤减少了哪些，会不会仍然展现刚才的缺陷，并加以测试。像这样尽可能的减少步骤重现缺陷，就叫优化缺陷。5.4重现缺陷在整堂课的教学中，刘教师总是让学生带着问题来学习，而问题的设置具有一定的梯度，由浅入深，所提出的问题也很明确5.4.1重现缺陷分析 软件缺陷的分离和重现非常考验测试人员的专业技能，同时也是充分

50、发挥软件测试人员“侦探”才能的地方，测试人员想要有效地报告软件缺陷，就要对软件缺陷加以明显、通用和再现的形式进行描述。在测试过程中，应设法找出缩小问题范围的具体步骤，某些擅长分离和重现软件缺陷的测试人员可以迅速找出该具体步骤和条件，进而找到软件缺陷，而某些测试人员又需要通过寻找和报告各种软件缺陷类型的锻炼来获得这种能力。总之，测试人员需要抓住每一个可以分离和重现软件缺陷的机会，以此来锻炼和培养这种技巧。通常，“可重现”隐含了下列含义：（1)能够描述如何让程序进入某个已知的状态，任何熟悉程序的人都能够依照该描述使程序进入该状态。（2)从进入的状态出发，能够确定相应的一组步骤来暴露出问题。在整堂课