基于测试流程上的缺陷管理系统

三、基于测试流程上的缺陷管理系统缺陷的定义软件没有达到产品说明书表明的功能软件出现了产品说明书中不一致的表现软件功能超出产品说明书的范围软件没有达到用户期望的目标(虽然产品说明书中没有要求)测试员或用户认为软件的易用性差不是所有缺陷都会修改市场的压力使得产品最终发行有时间限制测试员错误理解或者不正确操作引出的缺陷(FAQ)错误的修改影响的模块较多，带来的风险较大（遗留）修改性价比太低(FAQ，遗留）缺陷报告中提出的问题很难重现FounderR&D3.1缺陷报告管理系统是测试流程在工具上的固化通过权限控制来实现流程监控记录了缺陷识别到关闭过程中的所有数记录了版本变更的信息是开发和测试之间沟通的信息平台实时的数据和信息的更新度量和统计分析，为改进产品提供依据FounderR&DFounderR&D采用LotusNotes作为bug管理平台完全电子化的信息传递统一管理和备份具备数据统计和查询功能能够进行个性化二次开发方正测试缺陷跟踪与管理系统3.1.1系统测试缺陷处理流程新建表单待测试提交待指定处理人正在处理返回处理待开发提交待返测待归档已归档个人提交退回测试提交指定处理人重新指定处理完毕返测完毕归档重新返测退回提交版本更新说明FounderR&DBug报告准则如何重现错误-使用最少步骤重现现象描述没有歧义尽量简单-一个bug一个报告可以提出对错误的解决建议开发人员拒绝修改的bug程序员无法重现或者现象难以捕捉没有明确的报告以说明重现bug的步骤程序员无法读懂的bug报告用户很少使用或者不符合用户使用习惯的操作出错由不受信任的测试人员提出缺陷报告FounderR&D3.1.2集成测试缺陷处理流程新建表单待指定处理人正在处理待返测待归档已归档返回处理测试提交指定处理人重新指定处理完毕返测完毕归档重新返测退回FounderR&D4.1缺陷分析的关注点：1、对软件问题的功能域分布进行分析，找出系统的薄弱环节要详细采集每个功能模块或系统构件的bug数据，并按功能、错误类型、严重程度等分类比较实际发现的软件bug是否与预期的问题分布相吻合二八定理：80%的软件问题总是发生在大约20%的功能模块（系统构件）中。FounderR&D缺陷分析的关注点2、对bug的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集bug的数据要求软件各开发阶段的缺陷密度小于本单位过去的平均值而且要求需求分析、设计和代码复查阶段的缺陷排除率之和大于或等于规定值（例如75%）。（同行评审）FounderR&DFounderR&D缺陷分析的关注点3、应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。可参考PSP中缺陷类型标准（如下表），其中缺陷类型是按照问题的复杂度来排列的，类型10到40是比较简单的编码缺陷，类型50到100是比较复杂的设计缺陷。类型编号类型名称描述10文档注释，消息20句法拼写，标点，打字，指令格式30联编，打包理改管理，库，版本控制40分配说明，重名，作用域，限制50接口过程调用和引用，输入/输出，用户格式60检查出错信息，不恰当的检查70数据结构，内容80函数逻辑，指针，循环，递归，计算，函数缺陷90系统配置，记时，内存100环境设计，编译，测试，或其它支持系统问题缺陷分析的关注点4、应动态采集每个测试周期中发现的bug数，并有效地控制缺陷的修复率。5、应密切观察bug的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况FounderR&D缺陷分析的的关注点6、应该采采集bug不同方式式的修复数数据，以便便检验软件件产品是否否满足交付付规则分析修改代代码、改变变设计、封封掉功能遗遗留以及下下一版本解解决的bug数约占占缺陷总数数的比例。。在有严密和和有效的质质量保证体体系条件的的监控下，，常常会引引起有较高高比例的延延期解决的的缺陷数，，这是因为为许多细微微的或枝节节性的问题题被测试出出来，经过过评价证明明不会造成成大的质量量影响，但但可为产品品进一步升升级提供有有价值的参参考。FounderR&D4.2测测试人员的的绩效评价价评价标准：：1、bug数量：同一个项目目组内，提提交bug数量的多多少是衡量量测试人员员工作效率率的一方面面；另一个个衡量指标标是每人日日提交的bug数。。2、bug严重程度度：Bug的严严重程度是是衡量bug的质量量的一个重重要因素，，好的bug应该是是极端严重重的，对系系统造成极极大危害的的。3、bug价值：Bug的双双方面评判判，对于bug的价价值开发人人员在另外外一个角度度上进行评评判以上三个因因素的加权权平均才能能更有效的的评价测试试人员的绩绩效！FounderR&D4.3缺缺陷统计分分析工具介介绍FounderR&D测试结果分分析和评价价缺陷密度:基本的缺陷陷测量是以以每千行代代码的缺陷陷数(Defects/KLOC)来来测量的。。称为缺陷陷密度(Dd)，其其测量单位位是defects／KLOC。可按按照以下步步骤来计算算一个程序序的缺陷密密度：累计开发过过程中每个个阶段发现现的缺陷总总数(D)。统计程序中中新开发的的和修改的的代码行数数(N)。。计算每千行行的缺陷数数Dd=1000*D/N。。例如，一个个29.6万行的源源程序总共共有145个缺陷，，则缺陷密密度是：Dd＝1000*145/296000=0.49defects／KLOC。。在计算缺陷陷密度时，，最重要的的是要使用用正确的规规模测量。。FounderR&D测试结果的的分析和评评价输出《测试试综合报告告》：测试过程的的总结测试数据分分析（按照照严重程度度等方式分分类统计的的分析，包包括测试密密度等）产品主要问问题和总体体评价遗留的问题题总结最终的测试试结论FounderR&D测试结果分分析和评价价为了了解和和控制缺陷陷带来的费费用，很有有必要测量量缺陷排除除的效果测测量：一种测量方方法是计算算每小时排排除缺陷的的个数；一种是计算算缺陷排除除效益，即即测量通过过某一排除除方法所发发现的缺陷陷的百分比比。缺陷排除效效益是45%100个缺缺陷开始测试测试发现45个个缺陷missing55defectsFounderR&D测试结果分分析和评价价测试覆盖率率测量语句覆盖率率 测试试经历语句句数/总语语句数分支覆盖率率 测试试经历支路路数/总支支路数简单路径覆覆盖率测测试经历简简单路径数数/总简单单路径数功能覆盖率率界面数菜单数输入/输出出的数据元元数构件、模块块…FounderR&D4.5软件件测试经验验分享所有的测试试都应追溯溯到需求。。因最严重重的错误是是导致程序序无发满足足需求的错错误；软件开发人人员和管理理人员首先先应该尽早早地和不断断地进行各各种软件质质量保证活活动（如需需求和设计计阶段同行行评审和走走查等）;软件开发人人员应避免免检查自已已的程序，，利用同行行评审的方方式对代码码进行审查查；(自己检查容容易依照原原有的程序序设计思路路进行，往往往查不出出问题)在设计测试试用例时，，必须明确预预期的输出出结果，否否则对实际际的输出结结果很难有有检验的标标准，测试试失去意义义。测试用例应应由输入数数据和与之之对应的期期望输出结结果这两部部分组成，，在输入数数据中，应应当包括合合理的输入入条件和不不合理的输输入条件；；在进行各种种分析和修修复工作中中，要充分分注意修复复工作所产产生的影响响效果和波波及效果。。FounderR&D软件测试经经验分享统计表明大大约有60%的错误误是在设计计阶段之前前注入的，，并且修正正一个软件件错误所需需的费用将将随着软件件生存期的的进展而上上升。错误误发现得越越晚，修复复它的费用用就越高，，而且呈指指数增长的的趋势。测试后程序序中残存的的错误数目目与该程序序中已发现现的错误数数目（即检检错率）很很可能成正正比；(编码规范、、需求理解解、技术能能力、内部部耦合性是是引起这些些现象的原原因)程序中的大大部分错误误往往是在在一小部分分模块中发发现的，遵遵循普遍适适用的“二二八定理””（即80%的错误误往往是由由20%的的模块所造造成的），，例如，IBM公司司的OS/370操操作系统中中，47%的错误误仅与该系系统中的4%的程序序模块有关关；要严格执行行测试计划划，排除测测试的随意意性，这样样才能消除除各种无序序操作所造造成的副作作用；测试设计决决定了测试试的有效性性和效率，，测试工具具只能提高高测试效率率应当对每一一个测试结结果做全面面的检查，，这样才有有可能找到到真正的出出错原因，，为今后的的调试工作作奠定基础础。FounderR&D结束语产品越复杂杂，测试花花费的时间间就越长，，费用就越越大，测试试发现缺陷陷的效率也也就越低。。缺陷会掩盖盖或加重其其它缺陷。。也就是说说，当一个个程序有许许多缺陷时时，由于缺缺陷相互作作用，使得得发现和修修复缺陷的的过程更加加复杂。这这使得一些些缺陷很难难查找和修修复。一个个缺陷可能能掩盖其它它缺陷，使使得这些被被掩盖的缺缺陷难以发发现，增加加了它们