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

《软件测试技术第5章ppt课件.pptx》由会员分享，可在线阅读，更多相关《软件测试技术第5章ppt课件.pptx（108页珍藏版）》请在三一办公上搜索。

1、软件测试技术及实践,詹慧静 陈燕 段相勇,第5章 缺陷报告和测试评估,了解软件缺陷的基本知识。 了解软件缺陷的生命周期。 熟练掌握报告软件缺陷。 了解重现软件缺陷含义及常用的分析技术。 了解软件缺陷跟踪管理。 了解软件缺陷的评估。 了解测试评审。,本章学习目标,对于软件缺陷，需要学习以下内容：,软件缺陷的定义与描述。软件缺陷的种类。软件缺陷的属性。,5.1软件缺陷,5.1.1软件缺陷的定义与描述,1.软件缺陷的定义软件缺陷是指软件开发过程的各个阶段中存在的不完美甚至存在错误的地方，这些不完美和错误造成了软件缺陷，如编码过程中出现的语法、拼写错误或者存在不正确的程序语句等。简单地说，软件缺陷就是

2、指在软件(包括数据、程序、文档)之中存在的那些不希望或不能接受的、会导致软件产生质量问题的偏差。在行业定义中，软件缺陷通常又被称为defect或bug，是指软件或程序中存在的某种破坏正常运行能力的问题和错误，其存在会导致软件产品在某种程度上不能满足用户的需要。从软件内部看，缺陷是软件在开发或维护过程中存在的问题或错误。从软件外部看，缺陷是系统所需要实现的某种功能的失效或违背。,5.1.1软件缺陷的定义与描述,软件缺陷是影响软件质量的关键因素之一，发现并排除软件缺陷是软件生存周期中的一项重要工作。每一个开发软件的组织都必须妥善处理软件中存在的缺陷，它不仅关系到软件的质量，更关系到软件运用在工业生

3、产中是否会导致安全隐患。按照一般的定义，只要符合下面规则中的一个，就可叫做软件缺陷： （1) 软件未达到软件需求说明书中规定的功能。（2) 软件超出软件规格说明书中指明的范围。（3) 程序中存在语法错误。（4) 程序没有达到用户的期望。（5) 程序中存在拼写错误。（6) 软件运行出现错误。 （7) 运行缓慢，用户体验差，最终用户认为软件使用效果不好。（8) 软件语言描述过于技术化，非专业人员无法理解。,5.1.1软件缺陷的定义与描述,2.软件缺陷的描述软件缺陷的描述是报告软件缺陷的基本部分，那么，当发现软件缺陷后，应当如何描述软件缺陷呢？一个好的软件缺陷描述，需要使用简单、准确和专业的语言来呈

4、现缺陷的本质。在描述软件缺陷时，不能信息含糊不清，从而误导开发人员。准确描述软件缺陷是非常重要的，这是因为:（1) 清晰准确的软件缺陷描述可以提高与开发人员的沟通效率。 （2) 提高软件缺陷修复的速度，使每一个小组能够有效地工作。 （3) 提高开发人员对测试人员的信任度，并得到开发人员对软件缺陷的有效响应。 （4) 加强开发人员、测试人员和管理人员的协同工作。,5.1.1软件缺陷的定义与描述,2.软件缺陷的描述适用于有效描述软件缺陷的规则主要有以下几个： （1) 单一和准确。每个缺陷报告只针对一个软件缺陷。若在一个报告中报告多个软件缺陷，可能会导致其中部分缺陷被忽略，而不能得到修正。 （2)

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

6、复的全过程。（7) 描述但不做评价。在软件缺陷描述中不要带有个人观点对开发人员进行评价。软件缺陷报告是针对问题本身，只需将缺陷事实或现象客观地描述出来，而不能进行评价或议论。,5.1.2软件缺陷的种类,1.从开发者角度划分从开发者角度将软件缺陷分为需求缺陷、设计缺陷、文档缺陷、代码缺陷、测试缺陷、过程缺陷、计算错误和边界错误。（1) 需求缺陷包括需求有误、需求逻辑错误、需求不完备、需求文档描述问题、需求更改。（2) 设计缺陷包括设计不合理、设计文档描述出现问题、设计变更带来的问题。（3) 文档缺陷指在文档的静态检查过程中发现的缺陷，例如通过测试需求分析及文档审查发现的文档缺陷。（4) 代码缺陷

7、指对代码进行同行评审、审计或代码检查过程中发现的缺陷。（5) 测试缺陷指在测试执行活动中发现的被测对象(一般是指可运行的代码或软件系统)的缺陷，测试缺陷不包括静态测试中发现的问题。（6) 过程缺陷指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于开发过程的缺陷和问题。过程缺陷的发现者一般是质量经理、测试经理及管理人员等。（7) 计算错误指代码中出现的计算错误，例如使用了错误的运算公式、累加器未进行初始化等。（8) 边界错误指的是输入边界和输出边界或输入等价类边界的错误，这是最容易发生的一类错误。,5.1.2软件缺陷的种类,1.从开发者角度划分从开发者角度例如，程序本身无法处

8、理超越边界所导致的错误，由于开发人员在声明变量或使用边界范围时不小心引起的错误等。下面是一个典型的缓冲区溢出可能导致攻击的错误： #include;#include;void why_here(void)/这个函数没有任何地方调用过printf(why u here !nn);printf(you are trapped heren);system(pause);_exit(0);int main(intargc,char * argv)int buff1;buff3=0 x004113c0; /buff3=0 x0041111d; buff3=why_here;system(pause);r

9、eturn 0;,5.1.2软件缺陷的种类,1.从开发者角度划分从开发者角度执行结果如下： 从图中可以看出，虽然在代码中并没有调用why_here函数，但why_here函数还是被执行了，这是因为main函数里面赋值时发生溢出，数组实际地址变成0 x0041111d，就会跳转到why_here执行。只需要查看调试过程的汇编结果和程序执行过程中的监视窗口，不难发现其buff溢出，如果这段代码的是恶意代码，那么将会对系统造成严重的损害。,5.1.2软件缺陷的种类,2.从使用者角度划分从使用者角度，可以将软件缺陷分为功能未满足用户需求、使用不方便、交互性不好、使用性能不佳、未做好错误处理、控制流程错

10、误、对硬件兼容性差及文档错误。1）功能不能满足用户需求：功能不能满足用户需求包括功能不正常、所提供的功能不完善或其它方面的功能问题,5.1.2软件缺陷的种类,2.从使用者角度划分（1）功能不正常：简单地说，就是软件应该提供的功能，在使用上并不符合产品设计规格说明书中规定的要求，或是运行结果达不到预期设计，或是根本无法使用，这类错误常常会发生在测试过程的初期和中期。例如，在用户接口上所提供的选项及动作，使用者操作后没有反应。（2）所提供的功能不完善：与功能不正常不同，软件功能不完善指的是软件提供的功能能运行，甚至软件的功能运行结果也符合设计规格的要求，但对于使用者来说却认为该功能是不完整的，是没

11、有完全满足他们需求的。系统测试人员在测试结果的判断上，必须从使用者的角度进行思考，即从用户体验出发，来判断提供的功能是不是真正满足使用者的需求。（3）其它功能方面的问题：包括是不是有重复的功能、多余的功能等。,5.1.2软件缺陷的种类,2.从使用者角度划分2）软件在使用上不方便：如果一个软件，使用者不知如何使用或难以使用，就一定是在软件产品的设计上存在问题。一个好用的软件，会尽量做到让使用者容易上手，导航清晰，易于操作，使用方便。3）与操作者交互不良：一个好的软件必须与操作者之间可以实现正常交互。在操作者使用软件的过程中，软件必须很好地响应操作者。例如在浏览网页时，如果操作者在某一网页填写信息

12、，但是输入的信息不足或有误。当点击“确定”按钮后，网页此时提示操作者输入信息有误，却并未指出错误的哪里，操作者只好回到上一页重新填写，或直接放弃离开。产生这个问题的原因是在软件与操作者互动方面未做完整的设计。4）使用性能不能满足用户的需求：被测软件功能正常，但性能不能满足用户需求，如事务处理速率、并发量、数据量、压缩率、响应时间等不能满足用户的使用要求。此类缺陷通常是由于开发人员采用了错误的解决方案，或使用了不恰当的算法导致的。如大数据量并发压力测试对于分布式软件系统而言是必须进行的，因为分布式软件系统对并发量、稳定性的要求远比其它软件要高。,5.1.2软件缺陷的种类,2.从使用者角度划分5）

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

14、何处，用户希望自己定义导出的目录。而软件未向用户提供可以更改导出目录的选择，这就是软件流程控制不完整的错误问题。,5.1.2软件缺陷的种类,2.从使用者角度划分7）对不同硬件兼容性差：软件安装在某些硬件环境下不能正常工作。例如，在开发程序时使用的是Intel的处理器，程序打包生成后放在AMD处理器下运行会报错。8）软件文档错误：影响发布和维护的文档包括注释、用户手册、设计文档等。软件文档错误除了软件所附带的使用手册、说明文档及其它相关的软件文档内容错误之外，还包括软件使用接口上的错误文字和错误用语、产品需求设计、设计说明书等的错误。错误的软件文档除了降低产品质量外，还会误导用户。,5.1.3软

15、件缺陷的属性,为了便于跟踪软件缺陷，避免遗漏严重的软件缺陷，需要定义软件缺陷的属性，为开发人员和测试人员提供修复缺陷的参考。软件缺陷的主要属性有缺陷标识、缺陷类型、缺陷严重程度、缺陷产生的可能性、缺陷的优先级、缺陷状态、缺陷起源、缺陷来源和缺陷根源等。1. 缺陷标识缺陷标识是对某个缺陷进行标识的唯一标识符，通常用数字序号表示，方便对缺陷进行索引等管理操作。2. 缺陷类型所谓缺陷类型是指根据缺陷的自然属性进行划分得到的不同缺陷种类。常见的软件缺陷类型如下表所示：,5.1.3软件缺陷的属性,5.1.3软件缺陷的属性,3. 缺陷严重程度缺陷严重程度是指因为软件缺陷而引发的故障对软件产品的影响程度，其

16、判断应该依据软件最终用户的观点。通常可将缺陷严重程度分为致命（Fatal）、严重（Critical）、一般（Major）、较小（Minor）几个级别，如下表所示。,5.1.3软件缺陷的属性,4. 缺陷产生可能性缺陷产生可能性是指某个缺陷发生的概率，通常将其划分为总是、通常、有时、很少几种可能性，如下表所示。,5.1.3软件缺陷的属性,5. 缺陷的优先级缺陷的优先级是指某个缺陷必须被修复的紧急程度，通常可划分为立即解决、高优先级、正常排队、低优先级几个级别，高优先级的缺陷应该优先修复。缺陷的优先级如下表所示。,5.1.3软件缺陷的属性,6. 缺陷状态缺陷的状态是指描述缺陷通过一个跟踪修复过程的进

17、展情况，在这一过程中，缺陷可被描述为激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息等状态，如下表所示。,5.1.3软件缺陷的属性,7. 软件缺陷的起源缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶段，可分为：1）需求阶段发现的软件缺陷。2）在概要设计和详细设计阶段发现的软件缺陷。3）在编码阶段发现的软件缺陷。4）在测试阶段发现的软件测试缺陷。5）在用户使用阶段发现的软件缺陷。各个阶段发现的软件缺陷所占比例通常为：1）需求阶段发现的软件缺陷占54%。2）设计阶段发现的软件缺陷占25%。3）编码阶段发现的软件缺陷占15%。4）其它占6%。,5.1.3软件缺

18、陷的属性,8. 软件缺陷的来源缺陷来源是指引发某个软件缺陷的位置，通常软件缺陷来源于需求说明书、设计文档、系统集成接口、数据流（库）、程序代码等，如表5-6所示。表5-6 缺陷来源,5.1.3软件缺陷的属性,9.缺陷根源缺陷的根源是指产生缺陷的根本因素，包括测试策略、过程、工具和方法、团队（人员）、硬件、软件和工作环境等，如表5-7所示。表5-7 缺陷根源,对于软件缺陷的生命周期，需要学习如下内容：,软件缺陷生命周期的定义软件缺陷生命周期的几个阶段软件缺陷生命周期管理工具,5.2软件缺陷的生命周期,1. 软件缺陷生命周期的定义,在软件开发过程中，缺陷拥有自身的生命周期，缺陷在其生命周期中会处于

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

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

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

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

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

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

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

26、的状态,1）新缺陷：当发现一个缺陷并提交到缺陷库中时，缺陷则为新缺陷状态。缺陷的提交通常可以有以下几种情况：由测试人员来提交软件中新发现的缺陷。由开发人员自己在组件测试或代码走读过程中提交。由软件的最终用户或使用现场反馈得到的缺陷报告。从需求和设计阶段的文档评审过程中发现的缺陷。在编码阶段的代码评审和代码静态分析过程中发现的缺陷。在测试阶段的动态测试过程中发现的缺陷。在使用阶段的用户反馈过程中发现缺陷。2）接受：对已经提交的缺陷报告进行评审，评审的内容主要有确认缺陷报告中描述的问题是否确实是一个缺陷、提交的缺陷报告是否符合要求等，评审通过后，将缺陷状态设置为“接受”。3）分配：将缺陷状态为“接

27、受”的缺陷分配给相关人员进行问题定位和修复，并将缺陷状态设置为“分配”。4）打开：当开发人员开始对缺陷进行处理时，将缺陷状态设置为“打开”。,5.2软件缺陷的生命周期,2.缺陷在生命周期中的状态,5）交付：当找到解决缺陷的方法，并已经通过使用该方法对缺陷进行了处理，则将将缺陷状态设置为“交付”，然后交付给版本经理。6）解决：版本经理将处理后的缺陷（“交付”状态）转交给相关的开发小组进行验证，如果验证通过，则缺陷状态设置为“解决”。7）已修改：版本经理将已经解决的缺陷转交给相关的测试小组进行确认测试，如果测试通过，则缺陷状态设置为“已修改”。8）关闭：对修改后的缺陷，缺陷评审委员将对整个缺陷修复

28、过程进行评审，如果评审通过，则将缺陷状态设置为“关闭”。,5.2软件缺陷的生命周期,2.缺陷在生命周期中的状态,需要注意的是，在缺陷的生命周期中除了以上缺陷的状态外，实际工作中，软件缺陷还存在一些其他的状态： 1）研究：当缺陷分配给开发人员时，开发人员并不是都能立刻找到相关的解决方案，因此，开发人员需要对缺陷和引起缺陷的原因进行调查研究，此时可以将缺陷状态设置为“研究”。2）询问和回答：在进行缺陷修复时，如果相关人员认为缺陷描述信息不够明确，或希望能够得到更多与缺陷相关的配置和环境条件等，可以将缺陷状态改为询问和回答。3）拒绝：缺陷评审委员会对缺陷进行评审时，如果认为提交的问题不是缺陷，或者开

29、发人员经过研究分析，认为问题不是缺陷，并将具体的理由写入缺陷描述，那么缺陷评审委员会则将缺陷状态设置为“拒绝”。4）重复：缺陷评审委员会进行评审时，如果发现新缺陷和某个已经提交的缺陷描述的是针对同一个功能点的同一个问题，那么将缺陷状态设置为“重复”。5）延期：缺陷不能在当前版本解决。6）无计划：虽然确认了缺陷，但在用户需求中没有要求或计划。,5.2软件缺陷的生命周期,对于报告软件缺陷，需要学习如下内容：,报告软件缺陷的原则软件缺陷的报告模板软件缺陷报告的特点越早地提交缺陷信息，程序员就越能尽早地改正缺陷。相对于制定测试计划和实际测试工作，报告软件缺陷是软件测试过程中最省时、省力的工作。但事实上

30、，如果能把缺陷描述得越清楚，开发人员就越能更好地修复缺陷。软件缺陷的报告对开发人员的工作有直接的影响，包括付出的时间，消耗的精力等。因此，当有问题出现时，应该尽可能详细填写缺陷报告单，如果只是粗略记录，当需要填写报告时，就很容易忽略某些问题的复杂程度和严重程度，从而导致修复困难。本节将对如何报告软件缺陷才能更有效地促进与开发人员沟通交流进行详细的介绍。,5.3 报告软件缺陷,5.3.1报告软件缺陷的原则,在软件测试过程中，对于发现的大多数软件缺陷，都要求测试人员能够简洁清晰地把发现的问题报告给审查缺陷小组，并提供所需要的全部缺陷信息，开发维护小组才能决定怎么去处理。但是一些缺陷报告经常包含过少

31、或过多信息，而且组织混乱，难以理解。软件开发模式的不同和修复小组也是不固定的，导致缺陷被退回，从而延误及时修正，最坏的情况是由于没有清楚地说明缺陷的影响，开发人员忽略了这些缺陷，使这些缺陷随软件版本一起发布出去。因此，软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务，要理解缺陷报告读者的期望，遵照缺陷报告的写作准则，书写内容完备的软件缺陷报告。在大多数情况下，决定权在项目管理人员中手中，还有一些情况是在程序员手里，也可能通过会议讨论决定。一般情况，由软件测试专业人员或专业团队来审查发现的软件缺陷，判定是否修复。但无论什么情况，软件测试提供的描述软件缺陷的文档都十分重要，若软

32、件测试人员对软件缺陷描述不清楚，报告不及时有效，也没有建立强大的测试用例来证明缺陷必须修复，那么将有可能导致软件缺陷被误认为不是软件缺陷，不值得修复或者被认为修复风险太大等，从而产生偏离事实的决定。,5.3.1报告软件缺陷的原则,报告软件缺陷的目的是保证修复人员可以重现报告的错误，进而分析错误产生的原因，查看产生的日志，定位错误，然后修正。因此报告软件缺陷的基本要求是及时、准确、简洁、完整、规范：（1) 尽快报告。软件缺陷发现得越早，留给修复的时间就越多。例如，在软件发布前几个月从软件界面上的中文描述中找出错别字，该缺陷被修复的可能性就非常高。（2) 有效描述。软件缺陷的基本描述是软件缺陷报告

33、的基础部分。一个好的描述需要使用简单、准确、专业的语言清晰地呈现缺陷。如信息含糊不清，可能会误导开发人员。软件缺陷的描述也是测试人员就一个软件问题与开发工程师交流的最好机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员，因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。（3) 完备友好。写出的报告应该完备、易于理解且没有敌意，如果报告迷惑或惹恼了程序员，它就不会使程序员愿意改正问题、修复缺陷。,5.3.2软件缺陷报告模板,ANS/IEEE829-1988 标准定义了一个软件缺陷报告的文档，用于报告在测试过程期间

34、发生的任何异常事件，模板标准如下：,IEEE829-1988 软件测试文档编制标准软件缺陷报告模板目录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. 软件缺陷总结简明扼要地陈述事实，总结软件缺陷。给出所测试软件的版本引用信息、相关的测试用例和测

35、试说明等信息。对于任何已确定的软件缺陷，都要给出相关的测试用例，如果某一个软件缺陷是意外发现的，也应该编写一个能发现这个意外软件缺陷的测试用例。软件缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，一个好的描述需要使用简单的、准确的、专业的语言来抓住缺陷的本质。软件缺陷报告的编写人员应该在报告中提供足够多的信息，使一般修复人员能够理解和再现事件的发生过程。,5.3.2软件缺陷报告模板,下面是软件缺陷描述中的各个内容。(1) 输入。记录描述实际测试时采用的输入(例如文件、按键等)数据。(2) 期望得到的结果。用来记录期望得到的结果，正在运行的测试用例的设计结果。(3) 实际结果。记录测试程序的实际

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

37、. 影响软件缺陷报告的“影响”是指软件缺陷对用户造成的潜在影响。在报告软件缺陷时，测试人员要对软件缺陷分类，以简明扼要的方式指出其影响。经常使用的方法是给软件缺陷划分严重性和优先级。当然，具体方法各个公司不尽相同，但是通用原则是一样的。测试实际经验表明，虽然可能永远无法彻底克服在确定严重性和优先级过程中所存在的不精确性，但是通过在定义等级过程中对较小、较大和严重等主要特征进行描述，完全可以把这种不精确性减小到一定程度。,关于重现缺陷，需要学习以下内容：,重现缺陷的基本概念及重现缺陷分析。可重现缺陷分析技术。缺陷如何重现。,5.4 重现缺陷,关于重现缺陷，需要学习以下内容：,重现缺陷的基本概念及

38、重现缺陷分析。可重现缺陷分析技术。缺陷如何重现。,5.4 重现缺陷,重现缺陷，也可称为再现缺陷，是指当无意或按照测试用例发现一个缺陷的时候，需要把这个缺陷的中间步骤记录下来，然后可以依据这个步骤将这个缺陷再演示出来，并且缺陷记录步骤能够描述如何让程序进入到这个缺陷状态。需要注意的是，重现缺陷通常要采取繁杂的步骤才能实现，或者根本无法重现，开发人员可以根据相对简单的错误信息就能找出问题所在。此外，一个软件缺陷重现的问题有时光凭个人是难以实现的，需要团队的共同努力。第一次发现缺陷后，将重现的步骤中，可以展示缺陷的必要步骤写明，尽量不要有多余的操作，需精简步骤，这就叫优化。在优化的过程中，记录下前后

39、两次的步骤减少了哪些，会不会仍然展现刚才的缺陷，并加以测试。像这样尽可能的减少步骤重现缺陷，就叫优化缺陷。,5.4 重现缺陷,5.4.1 重现缺陷分析,软件缺陷的分离和重现非常考验测试人员的专业技能，同时也是充分发挥软件测试人员“侦探”才能的地方，测试人员想要有效地报告软件缺陷，就要对软件缺陷加以明显、通用和再现的形式进行描述。在测试过程中，应设法找出缩小问题范围的具体步骤，某些擅长分离和重现软件缺陷的测试人员可以迅速找出该具体步骤和条件，进而找到软件缺陷，而某些测试人员又需要通过寻找和报告各种软件缺陷类型的锻炼来获得这种能力。总之，测试人员需要抓住每一个可以分离和重现软件缺陷的机会，以此来锻

40、炼和培养这种技巧。通常，“可重现”隐含了下列含义： （1) 能够描述如何让程序进入某个已知的状态，任何熟悉程序的人都能够依照该描述使程序进入该状态。（2) 从进入的状态出发，能够确定相应的一组步骤来暴露出问题。,5.4.1 重现缺陷分析,为使报告更有效，对问题应该进一步分析。如果问题复杂是因为需要采取很多步骤才能重现，或是因为结果很难描述时，应该简化报告，或者将其拆分为几份报告，多花点时间进行分析，而对重现缺陷进一步分析的目的有以下几个： （1) 找出问题最严重的后果。找出某个缺陷可能导致的最严重后果，可以激发人们改正它的兴趣，因为一个看来很轻微的问题通常更有可能被暂缓处理。例如，假设有一个缺

41、陷，它是程序运行时在程序界面角落显示的一个无用字符，这个问题很轻微，是可以报告的。它可能会得到修复，但如果与时间有冲突，那么即使未修改也不会阻止程序的交付。有些时候，屏幕上显示出无用信息只是一个孤立的问题(因此对它置之不理的决定可能是明智的，尤其是程序快要交付的时候)。但更可能是某个更为严重的隐藏问题的先兆。如果继续运行这个程序，可能会发现一旦显示无用信息之后，程序几乎会马上崩溃。这就是要找出的严重后果，为防止这种严重后果，此时就需要修复显示的无用信息。,5.4.1 重现缺陷分析,（2) 找出发生程序失效的原因。如果程序发生了失效，原因可能是程序陷入了未预期的状态或是陷入了错误恢复例程中。（3

42、) 找出最简单、最直接和最常见的缺陷触发条件。例如，有些缺陷会在每个闰年的午夜显现，其他时间从不出现。又如，有些缺陷仅在输入某一特殊序列时才出现。如果能找到重现某个缺陷的比较简单的方法，进行调试的程序员也就能够更快地完成任务。重现缺陷所需采取的步骤越少，程序员所需要检查的代码位置也越少，也就更能集中精力去寻找缺陷产生的内部原因。（4) 找出产生相同问题的其他路径。有时候触发某个缺陷需要做很多工作，不管将问题分析得有多深入，仍然需要采取很多步骤才能重现它。即使每个步骤都好像是程序的例行操作，一个散漫的观察人员仍然会认为问题太复杂了，不会有太多客户会注意到它。,5.4.1 重现缺陷分析,（5) 找

43、出相关的问题。可以根据以往经验，仿照以前发现缺陷的方法，查找程序中其他可能存在缺陷的位置，很可能在新的代码中找出类似的问题，然后跟踪这个缺陷，看是否还存在其他缺陷。,5.4.2 可重现缺陷的分析技术,目前常用的可重现缺陷分析技术有寻找关键步骤、提高程序运行可见性、找出关键步骤，改变做法等。1寻找最关键的步骤当发现一个缺陷时，看到的只是缺陷的表象而不是其根源，例如，程序的异常是由代码中的错误而导致，由于看不到代码，因此也看不到错误的本身，这时可根据以下任何线索查找相关缺陷：1）错误信息2）处理延时3）屏幕闪烁4）光标跳跃5）文本错误6）工作指示灯异常,5.4.2 可重现缺陷的分析技术,2最大程度

44、提高程序运行的可见性程序运行的每一个步骤其实在计算机里面都是可见的，这时就可以考虑使用源代码调试工具。不但可以对代码的执行路径进行跟踪还可以报告当前活动的进程、程序占用的内存和其他资源的数量等内部信息。也可以将屏幕显示的所有内容和磁盘文件的所有变量都打印出来，然后进行分析。3找出关键步骤，改变做法如果程序依次执行事件A、B、C、D，程序执行到C的时候违背了需求，那么就知道可能问题出在B上，这时变换步骤，看看程序发生了什么变化能产生什么结果。,5.4.2 可重现缺陷的分析技术,4查找后续错误即使还没有找到最关键的步骤，一旦发生了某个缺陷，也应该再坚持运行程序一段时间，看看是否会有其他的错误出现。

45、最初出现的缺陷有可能诱发一系列后续问题，一旦最初的问题得到修复，后面的问题就可能不会出现了。从另一方面来看，这种因果关系也并不是确定的，当缺陷被查找出来后，后面出现的错误不一定非得是前面的错误的结果。必须从某个已知并清楚的状态出发，沿一条不会触发原有问题的路径对这些错误分别进行测试。5渐进地省略或改变步骤如果遇到的问题很复杂，步骤很多，如果跳过了其中的一些步骤或是稍微进行了改动，会出现什么情况？缺陷还存在吗？消失了还是变成了别的什么？,5.4.2 可重现缺陷的分析技术,6在程序以前的版本中查找错误如果错误仅在以前出现，没有出现在最近测试的版本中，那么它就是由代码变更所导致的。如有可能，应重新载

46、入旧版本程序，查找这个错误，以重现这个错误，在项目结束阶段这样做是有重要意义的。7查找配置依赖 假设程序在32位的计算机上运行时出现了一个缺陷，那么同样的问题会在64位计算机上重现么？当配置发生变化，新增加了一块网卡、新增加了一块硬盘、显示器由VGA连接转变为HDMI连接等会发生什么情况？,5.4.3 让缺陷可重现,缺陷是可重现的，当且仅当做到所描述的事情，并得到同样的结果，发现缺陷后，测试人员需说明如何使计算机进入某个已知的状态，执行哪些步骤可以触发缺陷，以及缺陷出现后如何识别它。许多缺陷会扰乱意想不到的内存区域，或者改变设备的状态。为确保观察到的不会是以前某些缺陷的附带现象，在执行触发缺陷

47、所必要的步骤前，通常需要重新启动计算机，并重新载入程序，这些都是重现缺陷工作的必要操作。任何缺陷都是可重现的，当然也存在着不能立即重现的情况，通常，在以下情况中软件缺陷不能重现：,5.4.3 让缺陷可重现,（1) 测试环境不一致。众所周知，环境是保证或影响软件测试的重要因素，如不同的系统平台、不同的服务器类型或不同的浏览器等，都有可能导致同一个缺陷不能重现。例如将某个基于B/S架构的系统软件在IE6或IE7上运行，软件运行正常，没有发现缺陷，如果在IE8上运行该软件，则会出现JS(JavaScript)脚本错误导致页面浏览异常的软件缺陷。（2) 测试配置不一致。任何程序的运行都是基于一定配置条

48、件的，如被测系统参数设置、基础数据完整性、业务流程完整性等。当测试配置条件不一致时，可能会导致缺陷无法重现。如在对某数据库产品进行测试时，如果数据库在安装界面中选择了非默认路径进行安装，结果导致该数据库物理备份的恢复功能出错，而测试时，在核对缺陷时按照默认路径进行安装，则该缺陷不能重现。（3) 内存泄漏。开发人员如未养成回收内存的习惯，则可能导致所使用的系统在长期运行后会速度变慢。短期内这类问题可能不会出现，但当系统长期运行时，可能会导致缺陷无法重现，并由此引发一系列的问题。（4) 数据接口不匹配。通常来说，这种无法重现缺陷的情况只有在查看源代码后才能被发现。如系统会自动转换某些类型的数据，而

49、有些数据被截断或被强制转换成另外一种数据类型时，可能会出现一些潜在的错误，从而导致缺陷无法重现。,5.4.3 让缺陷可重现,基于以上测试过程中出现的软件缺陷不能重现或难以重现的原因，本书提出了如下一些解决策略来帮助重现软件缺陷： （1) 记录所有的事情。将所有有关第一次操作的所有事情都记录下来，可使用录像记录所有的操作步骤，或者使用捕捉程序记录所有的击键操作和鼠标移动来辨别出触发缺陷的操作。（2) 注意测试的时间与运行条件。有些缺陷的重现也许与输入的速度、测试用例的硬件的运行速度、事件发生的次序等因素相关。测试人员在测试时，需要使用完全一致的硬件条件和相同的次序来进行测试。如一个跟踪每日时间的

50、程序可能会在元旦或闰年的2月底进行特殊的处理。（3) 注意测试的软件临界条件、内存容量和数据错误。若可用内存总容量足够，但散布为不连续的小内存块，则运行软件时会显示内存不足。这种情况下，如果能够显示出5个最大的内存块的大小，看到在测试开始时有多少可用内存，那么就能够在相应的程度上减少可用内存以真正重现某个缺陷。同时必须对程序进行相同的数据输入以防止数据错误。,5.4.3 让缺陷可重现,（4) 考虑资源的依赖性。在一个多重处理系统中，CPU资源及内存同时由两个或者两个以上的进程占用。如果一个进程使用打印机，那么其他的进程就必须等待该进程结束。若一个进程的使用占用了80%的可用内存，则仅剩20%的