第7章--软件测试度量与评价.ppt

麦考尔 * * Boehm（勃姆）质量模型包含15个属性，比McCall模型更全面，更复杂，它比McCall模型出现的要晚。 1、Boehm质量模型见P6图1-2 2、Boehm质量模型的特点： Boehm质量模型为分层结构。 Boehm质量模型包含了McCall模型中没有的硬件特性。 Boehm质量模型从软件的整体效用，并考虑了系统交付后不同类型的用户的需求，因此，Boehm模型反映了对软件质量的全过程理解，即软件做了用户要它做的；有效地使用系统资源；易于用户学习和使用；易于测试和维护。 * * 这个模型更精细，更复杂。 标题一：黑体 加粗 字号36 内容：黑体 字号25 * 7.5 软件缺陷管理及缺陷预防 软件缺陷和软件缺陷种类 软件缺陷的属性 软件缺陷跟踪 软件缺陷严重级别 软件缺陷提交方法 软件缺陷和软件缺陷种类 软件缺陷的定义和描述： 软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。 按照一般的定义，只要符合下面5个规则中的一个，就叫做软件缺陷： 软件未达到软件规格说明书中规定的功能； 软件超出软件规格说明书中指明的范围； 软件未达到软件规格说明书中指出的应达到的目标； 软件运行出现错误； 软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。 单一准确 可以再现 完整统一 短小简练 特定条件 补充完善 不作评价 软件缺陷的有效描述规则 （1）缺陷标识 （2）缺陷描述与缺陷注释 （3）缺陷类型 （4）缺陷严重程度级别 （5）缺陷产生可能性 （6）缺陷的优先级 （7）缺陷状态 （8）软件缺陷的起源 （9）软件缺陷的来源 （10）缺陷根源 软件缺陷的属性 软件缺陷的生命周期 软件缺陷从被测试人员发现一直到被修复，也经历了一个特有的生命周期的阶段。下面是一个最简单的软件缺陷生命周期的例子，系统地表示软件缺陷从被发现起经历的各个阶段： （1）测试人员找到并登记软件缺陷，软件缺陷被移交到程序修复人员。 （2）程序修复人员修复软件中的软件缺陷，然后移交到测试人员。 （3）测试人员确认软件缺陷被修复，关闭软件缺陷。 实例：缺陷流转流程（缺陷生命周期） New (新缺陷)：测试中新发现的软件缺陷（bug）； Open (打开)：由开发人员确认是缺陷； Fixed (修正)：开发人员已完成修正，等待测试人员验证； Rejected (拒绝)：由于测试人员对某功能项理解不足产生的不是缺陷的问题，经开发人员提出，并由测试人员确认的不是缺陷的问题； Deferred (延期): 不在回归测试版本修复的错误，下一版或以后再修复的缺陷； Closed (关闭)：复测后，确认的已被修复的缺陷； Reopen(重开)：开发人员已修改，但测试人员回归测试后发现依然存在的缺陷； Pending（未决的）：开发方确认是缺陷，但需要进一步和客户确认后再决定是否修改的缺陷。 实例：缺陷状态 缺陷流转流程说明 步骤 描述 1 测试人员提交新的Bug入库，缺陷状态为New。 2 开发人员验证缺陷，如果确认是缺陷并将分配给开发人员解决，设置其状态为Open，同时将其分配给相应的开发人员修改；若有些缺陷是需要进一步与客户确认后，再决定是否修改的，置状态为Pending。 3 开发人员认为不是缺陷、不能重现或对缺陷报告有疑问的，定期与测试人员沟通，测试人员负责重现BUG，如果是缺陷，则由开发人员置状态为open，如果测试人员确认不是缺陷，则由测试人员则置状态为Rejected，如果还不能明确问题，由开发和测试双方人员讨论，最后决定BUG的状态。 4 开发人员查询状态为Open的Bug，在开发环境进行修改，并在对应的BUG下记录修复说明，如果完成修复则置状态为Fixed。 每一轮测试（除第一轮外）发布新版本后，开发组需要将已修改的需要测试人员复测的缺陷，均置为Fixed状态。 5 对于不能解决和延期解决的Bug，要留下文字说明，由开发组置为Deferred。 6 测试人员在新一轮回归测试时，查询状态为Fixed的Bug，然后验证Bug是否已修复，如修复,则置Bug的状态为Closed，如没有修复则置状态为Reopen。 7 每一轮结束之前，应把所有状态为New的BUG进行评审确认，使QC库不再有状态为New的BUG，本轮方可结束。 8 对于缺陷级别有不同意见，应由客户方和测试方协商后，决定升级还是降级。 缺陷严重程度定义 一般分为3级到5级，如下样例，bug严重等级为4个级别： 严重等级 缺陷判定准则 致命缺陷 导致系统crash 、上线后可能导致无法进行正常业务、用户数据受到破坏、系统数据完全混乱无法再继续进行测试、任何一个主要功能完全缺