TestDirector缺陷报告及其流程.ppt

软件缺陷报告及其流程PPT,-集合TD缺陷管理工具孙管理,软件缺陷的定义,笼统来说软件中所有不满足用户确定的需求称为缺陷（Bug），包括：软件没有达到产品说明书表明的功能软件出现了产品说明书中不一致的表现软件功能超出产品说明书的范围软件没有达到用户期望的目标（虽然产品说明书中没有要求）测试员或用户认为软件的易用性差,判断缺陷的依据,通过参考文档来确认缺陷需求规格说明书、概要设计、详细设计、用户手册通过了解软件行业准则、行业背景来发现错误通过沟通方式来确认和识别缺陷,再现与优化缺陷优化缺陷并不是优化缺陷本身，而是优化缺陷的再现步骤,必要性减少开发人员重现缺陷的时间使开发人员更准确的定位缺陷有效的报告缺陷充分发挥测试人员的才能和智慧方法不要想当然的接受任何假设查找时间依赖和竞争条件的问题与压力和负荷相关的边界条件软件缺陷、内存泄漏和数据溢出缺陷的发生有一定的前提条件考虑资源依赖性和内存、网络、硬件共享的相互作用关注软硬件失效问题从阅读缺陷报告入手,不是所有的缺陷都会修改的,市场的压力使得产品最终发行有时间限制测试员错误理解或不正确操作引出的缺陷（FQA）错误的修改影响的模块较多，带来的风险较大（遗留）修改性价比太低（FQA、遗留）缺陷报告中提出的问题很难重现FQAFrequentlyAskedQuestions的缩写经常问到的问题，或是常见问题解答,开发人员拒绝修改的bug,程序员无法重现或者现象难以捕捉没有明确的报告以说明重现bug的步骤程序员无法读懂的缺陷报告用户很少使用或者不符合用户使用习惯的操作出错由不受信任的测试人员提出,如何记录缺陷缺陷报告,缺陷的标题：操作+bug现象描述缺陷的基本信息：测试的软硬件环境；测试的软件版本；缺陷的类型；缺陷的处理优先级；缺陷的严重程度复现缺陷的操作步骤缺陷的现象描述注释文字和截取的缺陷图像（可选）,提交缺陷报告准则（5C原则）,Correct（准确）每个组成部分的描述准确，不会引起误解Clear（清晰）每个组成部分的描述清晰，易于理解Cencise（简洁）只包含必不可少的信息，不包含任何多余的内容Complete（完整）包含复现该缺陷的完整步骤和其他本质信息Consistent（一致）按照一致的格式书写全部的缺陷报告,编写缺陷报告应避免的问题,是用“I（我）”、“You（你）”等人称代词使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等使用诸如“似乎”、“看上去可能”等含义模糊的语句，而需要报告确定的缺陷结果包含认为比较幽默的内容,缺陷的分类,按照问题的引出不同界面类、功能类、说明书、联机帮助按照系统的各个模块通常需要根据软件产品的情况进行具体问题具体分析按照严重程度致命性错误、严重功能/性能错误、建议性问题按照修复缺陷的优先级紧急的、必须的、应该的、可选的、不需要的,缺陷报告的处理流程,大多数情况下，缺陷报告的处理只会经过提交分配解决关闭这样一个简单的流程，但是在有些情况下，这个过程会变得比较复杂,TD缺陷管理系统,TestDirector为应用程序发布之前的测试提供了一个管理架构，能够完成从需求管理到缺陷跟踪的整个过程，如图所示。,缺陷管理系统,是测试流程在工具上的固化通过权限控制来实现流程监控记录了缺陷识别到关闭过程中的所有数记录了版本变更的信息是开发与测试之间沟通的信息平台实时的数据和信息的更新度量和统计分析，为改进产品提供依据,TD缺陷管理系统,TD缺陷管理系统缺陷跟踪,定位和优化缺陷是测试过程中最基本的一个步骤，TD的缺陷管理贯穿于测试的整个过程，从最初的问题发现到缺陷修改，直到检验修改结果。在测试过程的任何阶段，测试人员、项目经理、开发人员和最终的用户都可以随时将缺陷记录到系统中。相关技术负责人查看新增加的缺陷，并确定哪些是需要修正的。相关技术人员修改缺陷。针对修改后的缺陷，测试人员进行回归测试，如仍不符合要求，重新提交给技术人员修改，直到缺陷被关闭。分析缺陷统计图表，分析应用程序的开发质量。,TD缺陷管理系统缺陷跟踪,一般来说，当测试人员向TD项目的缺陷管理模块中提交一个缺陷以后，需要跟踪如下几个阶段：New、Open、Fixed和Closed，一个缺陷在这4个阶段中可以根据需要随时被拒绝或者重新打开，也就是被置于Rejected和Reopened状态，如图所示显示了最基本的缺陷跟踪过程。,TD缺陷管理系统缺陷跟踪,当测试人员或其他人员向项目中提交一个缺陷后，缺陷默认被置为New项目经理或质量管理人员浏览新添加的状态为New的缺陷，决定是否需要修改，如果不需要修改，则将状态置为Rejected；如果需要修改，则确定该缺陷的优先级后将状态置为Open，并指定开发组中的相应人员进行修改开发人员修改缺陷并将状态置为Fixed测试人员重新测试应用程序，来验证缺陷是否被修复如果缺陷仍然存在，则由项目经理或质量管理人员将状态置为Reopened；如果缺陷已经修复了，则置为Closed，关闭缺陷,测试结果分析和评价,缺陷密度：基本的缺陷测量是以每千行代码的缺陷数（Defect/KLOC）来测量的称为缺陷密度，其测量单位为Defect/KLOC，可按照以下步骤来计算一个程度的缺陷密度：累计开发过程中每个阶段发现的缺陷总数（D）统计程序中新开发的和修改的代码行数（N）计算每千行的缺陷数Dd=1000*D/N例如：一个29.6万行的源程序总共有145个缺陷，则缺陷密度是：Dd=1000*145/296000=0.49defect/KLOC在计算缺陷密度时，最重要的是要使用正确的规模测量,软件测试经验分享（软件测试原则）,所有的测试都应追溯到需求。因最严重的错误是导致程序无法满足需求的错误软件开发人员和管理人员首先应该尽早的和不断地进行各种软件质量保证活动（如需求和设计阶段同行评审和代码走查）软件开发人员应避免检查自己的程序，利用同行评审的方式对代码进行审查（自己检查容易按照原有的程序设计思路进行，往往查不出问题）在设计测试用例时，必须明确预期的输出结果，否则对实际的输出结果很难有检验的标准，测试失去意义。测试用例应由输入数据和与之相对应的期望输出结果这两部分组成，在输入数据中，应当包括合理的输入条件和不合理的输入条件,软件测试经验分享（软件测试原则）,在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果统计表明大约有60%的错误是在设计阶段之前注入的，并且修正一个软件的错误所需的费用将随着软件生存期的进展而上升。错误发现得越晚，修复它的费用就越高，而且呈指数增长的趋势测试后程序中残存的错误数目与程序中已发现的错误数目（即检错率）很可能成正比（编码规范、需求理解、技术能力、内部耦合性是引起这些现象的原因）程序中大部分错误往往是在一小部分模块中发现的，遵循普遍适用的“二八定理”（即80%的错误往往集中在20%的模块所造成的），例如IBM公司的OS/370操作系统中，47%的错误仅与该系统中4%的程序模块有关,软件测试经验分享（软件测试原则）,要严格执行测试计划，排除测试的随意性，这样才能消除各种无序操作所造成的副作用；测试设计决定了测试的有效性和效率，测试工具只能提高测试效率应当对每一个测试结果做全面的检查，这样才有可能找到真正出错的原因，为今后的调试工作