软件缺陷管理方案分析（共8篇）
软件缺陷管理方案分析 篇1
1. 引言
软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误, 或者隐藏的功能缺陷。软件缺陷管理是在软件生命周期中获取、管理、沟通任何变更请求的过程, 可以确保问题或缺陷被跟踪管理而不丢失。目前缺陷管理类的软件工具比较多, 主要功能比较一致, 但在一些细节, 如缺陷管理的流程, 与其它软件工程管理软件的集成, 甚至涉及到软件测试流程和软件质量管理的理念上, 都存在差异[1]。本文结合作者的软件开发和测试工作经历, 给出一套软件缺陷管理方案。
2. 软件缺陷的产生
软件测试从需求分析阶段就与软件开发同步进行, 软件缺陷在软件测试的各个阶段都会产生。图1是软件缺陷的产生示意图。
测试人员和开发人员首先根据测试需求创建各个测试用例, 测试需求与测试用例是一对多的关系;各个测试用例在运行后会产生相应的测试结果, 在一次测试过程中, 一个测试用例只会有一个测试结果, 但从整个软件测试流程中, 一个测试用例会产生多个测试结果, 比如在针对不同版本进行的回归测试, 从测试用例到测试结果一般测试人员和开发人员都会参与;最后, 如果测试结果完全满足对应的测试需求的要求, 即测试成功, 可以认为该测试用例测试通过, 若不满足, 即测试失败, 根据测试结果创建相应的缺陷, 测试结果与软件缺陷是一对多的关系[2]。
3. 软件缺陷管理方案
3.1 管理内容
从管理功能的角度, 软件缺陷管理会记录缺陷时间、严重度、异常的程序表现以及如何重现软件缺陷的细节;另外还有报告程序缺陷的人员身份和可能修正此缺陷的程序员信息。为了追踪与软件缺陷相关的测试用例和测试结果, 应该对测试用例和测试结果进行分类管理, 同时关联好测试用例、测试结果和软件缺陷三者的关系[3,4]。
从管理权限的角度, 软件缺陷管理过程中, 除了需要分配相关的人员对测试用例、测试结果和软件缺陷进行维护外, 还需要不断跟踪软件缺陷及与之相关的测试用例、测试结果在其生命周期中被分配的状态指数。在跟踪过程中应当允许管理员设定基于状态的权限, 可以结合软件缺陷的管理流程, 通过权限管理来维护在测试用例、测试结果和软件缺陷生命周期中的状态, 包括缺陷的确认、缺陷任务的分配等等。同时对各类状态进行定义和维护[3,4]。
下面首先分析软件缺陷的具体内容及生命周期中的状态关系, 然后定义相关的权限和角色, 并赋予角色对应的权限。
3.2 软件缺陷管理
一条测试用例的多次执行会产生多个测试结果, 当测试结果与预期结果不一致时, 可以通过该测试结果产生一个或多个软件缺陷, 当发现软件缺陷后, 需要设法找到引起这个缺陷的原因, 对软件缺陷进行分类, 分析对产品质量的影响, 然后确定软件缺陷的严重性和处理这个缺陷的优先级。一个完整的软件缺陷包括如下表所示的字段信息:
软件缺陷在其生命周期中的状态关系图如图2所示:
如图所示, 软件缺陷共有四个状态, 缺陷创建时为Active状态, 表明该缺陷激活, 需经过管理员的确认, 管理员确认通过后, 此时将该缺陷设置为Reviewed状态, 表明缺陷得到确认, 再将该缺陷分配给软件修复者 (通常为开发人员) 进行处理;软件修复者得到任务后对缺陷进行修复, 修复完成后, 将该缺陷设置为Resolved, 表明该缺陷已得到解决;当修复者处理好缺陷后, 创建者需要判断该缺陷是否得到了处理, 如果并未得到处理, 则将缺陷重新设置为Active状态, 表明该缺陷没有能正常解决, 然后交给管理员再进行确认;若创建者判断修复者已经完成了对缺陷的处理, 则由管理员进行确认, 确认通过后缺陷状态仍然为Resolved;当管理员认为该缺陷已经解决, 同时在后续开发过程中也无须跟踪该缺陷, 则可以将缺陷状态设置为Closed, 表明该缺陷为关闭状态, 后续测试和开发无须考虑该缺陷;对新创建和重新激活的缺陷, 管理员在进行确认过程中, 如果认为创建的缺陷无须修复, 直接可以设置为关闭状态, 或者对于创建者重新激活的缺陷, 管理员若认定该缺陷已经解决, 管理员可以将缺陷再次设置为Resolved状态;同样对于已经为Closed状态的缺陷, 在后续测试过程中重现, 可以重新激活, 设置为Active状态[3,5]。
设置为Resolved状态的软件缺陷, 并不表明该软件缺陷得到了修复, 仅仅表示该软件缺陷得到了处理, 有的情况下有些软件缺陷是不需要修复的, 比如无法复现的问题, 或者暂时不能解决的软件缺陷, 也有的情况下软件缺陷发现得比较晚, 当前的处理结果是在下一个版本进行修复;这里将Resolved状态的缺陷分为两大类:无效缺陷和有效缺陷, 该两大类将已解决的缺陷再分成如下的解决分类[5], 如表2所示:
3.3 软件缺陷权限管理
由前面分析可以看到, 在软件缺陷管理过程中, 所涉及到的角色较多, 因此必须要设置相应的角色和对应的权限。首先将权限分为软件产品管理、用户管理、测试用例管理、测试结果管理和软件缺陷管理五个方面, 将角色分为系统管理员、项目管理员、测试管理员、测试审核员、测试人员和开发人员六个方面, 各角色的具体权限分配如表3和表4所示:
4. 结语
本文给出了一套软件缺陷管理方案, 该方案从生命周期和管理内容两个方面详细分析了软件缺陷的管理方法, 并给出了软件缺陷权利管理中权限和角色分配方法。该方案更多的是结合本人在软件开发和测试工作中的经验总结而成, 在软件缺陷的状态关系中, 强调了审核和确认的机制, 管理方案略显繁琐, 在软件开发和测试的实际运行中比该方案相对简单;另外方案在团队工作和项目管理方面, 尤其是质量控制和质量保证方面, 考虑得不够全面, 在今后的工作过程应重点融入这部分内容。
摘要：基于作者软件开发和软件测试的工作经历, 给出了一套软件缺陷管理方案, 该方案对软件缺陷的管理内容和生命周期进行重点分析, 定义了软件缺陷在其生命周期中的各个状态, 以及状态之间的转换过程, 然后在软件缺陷权利管理中给出了权限和角色分配方法, 最后对方案提出了一些不足和改进。
关键词：软件缺陷管理,测试用例,测试结果,生命周期,权限管理
参考文献
[1]百度百科.缺陷跟踪管理系统[EB/OL].http://baike.baidu.com/view/107502.htm, 2013.
[2]张创基.软件缺陷管理系统的分析与设计[J].教育教学论坛, 2012.8.
[3]林璐.对软件测试中的缺陷管理的研究和实践[D].上海:复旦大学, 2011.
[4]闫振兴, 郑骏.软件缺陷度量与软件过程管理方法研究[J].计算机与数字工程, 2010.8.
[5]王昕.基于工作流的软件缺陷管理系统的设计与实现[D].上海:上海交通大学, 2011.
房屋租赁管理缺陷及应对措施分析 篇2
【关键词】房屋租凭管理；缺失问题；应对措施
目前在我国社会经济发展的过程中，房地产市场发展得十分的迅速，其管理模式逐渐向着规范化、制度化的方向发展，从而使得房地产市场的稳定性得到进一步的提升。但是，人们在对其进行实际管理的过程中，还存在着许多房地产租赁管理缺失的问题，这就让我国房地产市场在运作时具有一定的局限性，使得租赁当事人的合法权益无法得到有效的保障。因此在当前我国房地产租赁市场发展当中，就要根据其实际情况和相关的规范要求，采用相关的应对措施，来对房屋租赁管理的制度进行完善。下面我们就简单的介绍一下，房屋在租赁管理中存在的缺少问题和相关的应对措施。
一、房屋租赁管理中存在的缺失问题
随着社会经济发展的过程中，房地产市场作为其中重要的组成部分，它在其中有着十分重要的意义。然而，我们在房屋租赁管理的过程中，由于其管理机制存在着一定的局限性，因此导致当前人们在房屋租赁管理的过程中，存在着管理缺失的问题，这就对房屋租赁市场的发展有着严重的影响。其中我们在房屋租赁管理中粗壮呢着缺失问题主要表现在以下几个方面：
1、管理主体方面的问题
目前人们在房屋租赁管理的过程中，所设计到的政府管理部门有很多，其中主要包括了房地产管理部门、工商以及税务部门等，它们都是通过协同管理的方法，来对房屋租赁管理机制进行相应的改进和完善，以确保我国房地产市场的正常运作。但是，在实际管理的过程中，这些管理主体都没有对自身的管理职能进行明确的规定，这就使得各个部门在对房屋租赁市场管理的过程中，其管理体制出现混乱的现象，这就对当前我国房地产市场的发展有着许多的不利的影响。而且部分管理人员其自身的管理能力和综合素质不高，这就导致人们在房屋租赁管理的过程中，对房屋租凭管理的效果有着一定的影响。此外，部分地区的房屋租赁管理机构不够健全，这就使得房屋租赁管理部分无法起到良好的管理效果。
2、管理依据方面的问题
近年来，我国为了促进房屋租赁市场的发展，颁布并实施了相关的法律规范，来为房屋租赁市场的运作以供相关法律依据，这也为房屋租赁的管理工作打下了扎实的基础。不过，从当前这些法律依据的实际应用情况来看，我们在房屋租赁管理的过程中，没有建立一个完整的法律一些，而且部分法律规范的执行力度不强，没有实际的操作性，这就导致人们在对房屋租赁管理的过程中，其管理依据无法起到良好的应用效果，对房屋租赁的规范化管理工作有着十分严重的影响。
3管理手段方面
房屋租赁管理中也存在着手段过于简单和单一化的问题，主要体现在各个管理主体间只是单打独斗，难以形成合力；房地产行政管理部门对于租赁活动中存在的不法行为，只能履行检查的功能，缺乏有力处罚依据和更加强硬、有效的处理手段，行政处罚执行难度大；对于未能履行租赁责任的，如集体土地上的房屋租赁当事人未能及时办理或根本不办理登记备案手续的，也难以有行之有效的手段，导致管理过程中问题重重，已有的规定无法得到切实有效的落实。
二、提高房屋租赁管理水平的政策分析
从以上分析中不难看出，房屋租赁管理主体、客体、依据及方法等方面存在的问题，严重制约着我国房屋租赁市场的持续健康发展。作为房地产市场体系的重要组成部分，房屋租赁市场的良性运作既是当前满足居民住房消费的重要途径之一，也是推进整个房地产行业的多渠道、多形式发展的重要措施之一，更是当前进行房地产调控的关键。
1理顺房屋租赁管理体制，形成以房地产管理部门为主导，其他部门相互积极配合的管理新体制，真正凸显出齐抓共管的良好局面，提高房屋租赁管理合力和质量
具体来讲，一是，房地产管理部门要切实发挥起对房地产市场和房屋租赁市场的熟悉优势，用足用活国家的房屋租赁管理的相关政策，形成牵头组织力量，在租赁管理工作中主动积极，取得主导地位。二是，根据房屋租赁市场的特殊性，要积极寻求工商、公安、税务、民政、社保等相关部门的配合和支持。同时各相关职能部门也要提高重视，正确认识到房屋租赁市场的重要性和加强房屋租赁管理的迫切性，严格履行相应的职责，积极配合。各地可根据当地的具体情况，在相关条件成熟的前提下，建立以房地产行政管理部门为主的房屋租赁管理办公室，实现公安、工商、税务、治安管理部门等的集中统一综合办公，推行一条龙服务，既提高行政管理效率，又能真正地体现出以人为本、为民服务、方便群众的执政理念。三是，切身加强房屋租赁管理队伍的建设，在保证人员配备与所承担职能、任务相适应的情况下，要提高培训力度，抓好管理人员的业务技能和职能道德教育，建立高素质的行业人才队伍，切实改进服务形象，提高服务的水平和质量。
2进一步完善房屋租赁市场的法律法规建设工作
立法先行，通过法律的相关规定巩固租赁管理部门的有效法律地位是实现房屋租赁市场良性循环发展的关键。当前有关房屋租赁市场的政策、法规的完善工作需从以下几个方面进行：一是，从法律层面上正式明确规定房地产管理部门及其他涉及部门，包括工商、公安、税务等在房屋租赁管理中的具体职责，部门与部门之间的工作衔接，避免相互推诿和消极应对情况的出现，实现各部门间的相互积极配合。二是，尽快出台《商品房屋租赁管理办法》的实施细则与相应的配套法规，如针对不同类型的房屋租赁市场形成相应的实施规则、租赁环节税收的征缴等；同时尽快对房屋租赁各政策间存在的矛盾和冲突给予消除，制定统一管理规范。各地要切实从当地实际情况出发，抓紧抓好出台具体的实施规范，提高规范的可操作性，提高法律效力，使房屋租赁市场的管理有法可依、有据可依。三是，严格规范租赁当事人包括出租人、承租人、中介服务机构等各方面的权利和义务，使其自觉遵守租赁管理相关法律法规的规定。
三、结束语
總而言之，在当前我国房屋租凭市场发展的过程中，由于其管理体系不健全，使其人们在房屋租凭管理的过程中存在着许多的管理缺失的问题，这不仅侵害了房屋租凭当事人的合法权益，还对当前我国房地产市场的发展有着一定的影响，因此我们这就对我国房屋租凭管理中存在的缺少问题进行分析，采用相应的应对措施来对其进行处理，从而使得房屋租凭管理体系得到进一步的完善，以确保我国房地产市场的稳定发展。
参考文献
[1]李燕.房屋租赁管理缺陷及应对方案分析[J].中国市场. 2010（19）
软件缺陷管理方案分析 篇3
在软件产品生产过程中出现软件缺陷是必然的, 如何采取合适的对策尽早发现和消除已经产生的缺陷, 提高软件产品的开发质量和成功率, 以及研究如何减少软件缺陷所产生的代价和成本是很有现实意义的。软件缺陷管理作为软件开发管理的重要组成部分, 已经被越来越多的软件开发人员所重视。
1 软件缺陷管理概述
缺陷管理/软件缺陷管理 (Defect Management) 是在软件生命周期中获取、管理、沟通任何变更请求的过程 (从变更的建议到变更的解决) 。可以确保你的问题如需求或者缺陷被跟踪管理而不丢失。软件缺陷管理通过适当的缺陷管理工具就可以成功对缺陷进行记录、跟踪和管理。
2 软件缺陷管理的目标
软件测试过程简单说就是围绕缺陷进行的, 对缺陷的跟踪管理一般而言需要达到以下的目标:
(1) 确保每个被发现的缺陷都能够被解决;
(2) 这里解决的意思不一定是被修正, 也可能是其他处理方式 (例如, 在下一个版本中修正或是不修正) , 总之, 对每个被发现的BUG的处理方式必须能够在开发组织中达到一致;
(3) 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段;决定测试过程是否结束有很多种方式, 通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式;
(4) 收集缺陷数据并在其上进行数据分析, 作为组织的过程财富。
3 软件缺陷管理的流程
不同的软件组织缺陷管理的流程会不尽相同, 根据对国内外著名软件公司缺陷管理流程的研究, 有如下两种常见的管理流程:
第一种缺陷管理流程包含七种缺陷状态:New、Open、Fixed、Reopen、Deferred、Cancel和Closed态, 其管理过程描述如下:
1) 测试小组向项目经理提交新发现的缺陷, 此时将缺陷状态设为“New” (新建) 。2) 项目经理根据Bug的详细情况, 确定处理方案, 进行以下操作:将事务状态设为“Open” (公开) , 并指派具体修复缺陷的人员;将事务状态设为“Cancel” (取消) , 并分配给测试小组;将事务状态设为“Deferred” (延后) , 并分配给测试小组。3) 被指派修复缺陷的人员接到“Open” (公开) 的事务后, 根据处理方案处理事务, 处理完毕后, 将状态设为“Fixed” (已解决) , 并提交给测试小组进行验证。一般情况下, 每个项目都有相对固定的测试人员, 如果不清楚应该提交给谁测试时, 可提交给测试组长, 由测试组长转给其他测试人员验证。4) 测试小组在验证时, 应按处理方案进行测试, 严格控制测试的质量。在测试时, 进行以下操作:如果验证通过, 将事务状态设为“Closed” (已关闭) , 结束事务;如果验证没有通过, 将事务状态设为“Reopen” (重打开) ;并提交给该缺陷的原负责修复人员重新处理。5) 缺陷修复人员接到“Reopen” (重打开) 的事务后, 需及时查明原因, 重新处理该事务。6) 测试小组接到项目经理提交的“Cancel” (取消) 的事务时, 应根据该事务的严重性及对相关系统的影响, 判断该事务是否可以取消, 进行以下操作:如果确定可以取消时, 将状态设为“Closed” (已关闭) , 结束事务;如果确定不可以取消时, 将状态设为“Reopen” (重打开) , 提交给项目经理进行重新缺陷的解决。7) 测试小组接到项目经理提交的“Deferred” (延后) 的事务时, 须在必要时设置缺陷的状态为“Open” (公开) , 并再次提交给项目经理进行处理。8) 如果“Closed” (已关闭) 的Bug再次出现时, 则作为一个新发现的缺陷提交。缺陷管理流程如图1所示:
第二种缺陷管理流程精简了缺陷管理的状态, 仅由Open、Fixed和Closed三种状态组成。
(1) 测试小组向项目经理提交新发现的缺陷, 此时缺陷的状态设为“Open” (公开) , 责任人指定为项目经理。
(2) 项目经理根据Bug的详细情况, 确定处理方案, 进行以下操作:确认测试小组提交的缺陷, 指派具体修复人员进行修复。驳回测试小组提交的缺陷, 将事务状态设为“Fixed” (已解决) , 并注明驳回的理由, 同时分配给测试小组;对延期修复的缺陷, 保持其状态为“Open” (公开) , 并注明延期的理由, 同时分配给测试小组。
(3) 被指派修复缺陷的人员接到“Open” (公开) 的事务后, 根据处理方案处理事务, 处理完毕后, 将状态设为“Fixed” (已解决) , 并提交给测试小组进行验证。
(4) 测试小组在验证时, 应按处理方案进行测试, 严格控制测试的质量。在验证时, 进行以下操作:如果测试通过, 将事务状态设为“Closed” (已关闭) , 结束事务。如果测试没有通过, 将事务状态重新设为“Open” (公开) , 并提交给该缺陷的原负责修复人员重新处理。
(5) 测试小组对于项目经理返回的带有驳回信息的“Fixed” (已解决) 的事务时, 应根据该事务的严重性及对相关系统的影响, 判断该事务是否可以取消, 进行以下操作:如果确定可以取消时, 将状态设为“Closed” (已关闭) , 结束事务。如果确定不可以取消时, 将状态重新设为“Open” (公开) , 并提交给项目经理进行重新缺陷的解决。
(6) 测试小组接到项目经理返回的带有延期信息的“Open” (公开) 的事务时, 须在必要时重新提交给项目经理进行缺陷的处理。
(7) 如果“Closed” (已关闭) 的Bug再次出现时, 则作为一个新发现的缺陷提交。其缺陷管理流程如图2所示:
4 基于缺陷度量属性的分类方法
缺陷分类的目的是通过实施软件缺陷管理, 采集完整的缺陷数据信息。通过缺陷数据分析软件缺陷产生的原因, 改进软件过程, 预防软件缺陷, 提高软件质量, 改善组织的软件能力成熟度。传统的软件缺陷分类方法主要目标是消除软件缺陷, 评价软件的性能和可靠性, 不能满足改进软件过程的需要。本文中将缺陷度量属性设计为描述属性、统计属性和控制属性三类。
4.1 基于缺陷描述属性的分类
缺陷描述属性是指:缺陷信息描述, 缺陷处理时间, 缺陷引入/流出原因分析, 缺陷处理结果描述, 缺陷调查分析相关的辅助文件路径等由处理分析缺陷的相关责任人进行记录的属性, 其属性值没有固定的取值范围。缺陷文字属性按照表1进行分类。
4.2 基于缺陷统计属性的分类
缺陷统计属性是指:缺陷生命周期状态, 缺陷流出的开发阶段, 缺陷流出的部门, 缺陷流出的功能模块, 缺陷表现类型, 缺陷的严重等级等基于缺陷数量统计其分布的属性。并且缺陷统计属性参考正交缺陷分类方法划分, 属性间没有相关性。缺陷统计属性按照表2进行分类。
4.3 基于缺陷控制属性的分类
缺陷控制属性是指:处理缺陷的角色, 缺陷的分配, 处理缺陷的时间, 缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。缺陷控制属性按表3进行分类。
5 软件缺陷管理典型工具介绍
缺陷管理作为软件质量管理的重要组成部分, 正在成为软件开发管理过程中的又一亮点。目前在国内软件组织中, 大家比较熟知的缺陷管理工具主要有Mercury Interactive公司的Test Director、IBM Rational公司的Clear Quest、上海微创公司的BMS系统以及开源软件Bugzilla。
5.1 TestDirector
Test Director是业界第一个基于Web的测试管理系统, 它可以为企业组织进行全球范围内测试的协调。通过在一个整体的应用系统中提供并且集成了测试需求管理、测试计划、测试日程控制, 以及测试执行和错误跟踪等功能, 极大地加速了测试过程。
5.2 ClearQuest
Clear Quest提供基于活动的变更和缺陷跟踪。以灵活的工作流管理所有类型的变更要求, 包括缺陷、改进、问题和文档变更。能够方便地定制缺陷和变更请求的字段、流程、用户界面、查询、图表和报告。开箱即用特性提供了预定义的配置和自动电子邮件通知和提交。与Rational Clear Case一起提供完整的SCM解决方案。拥有“设计一次, 到处部署”的能力, 从而可以自动改变任何客户端界面 (Windows、Linux、UNIX和Web) 。
5.3 BMS3.6.4 Bugzilla
Bugzilla是开源项目中有关软件缺陷管理的最为知名的软件之一, 其特点是基于Web方式, 安装简单、运行方便快捷、管理安全。提供全面详尽的报告输入项, 产生标准化的Bug报告。提供大量的分析选项和强大的查询匹配能力, 能根据各种条件组合进行Bug统计。系统灵活, 具有强大的配置能力。能够根据设定的不同责任人, 自动发送最新的动态信息, 有效的帮助测试人员和开发人员进行沟通。
6 测试管理数据分析
6.1 基于需求的测试覆盖
(1) 计划的测试覆盖程度:Coverage＿Plan= (TP/Rf T)
其中Coverage_Plan表示计划测试需求的覆盖率;TP表示测试计划确定的测试用例的数量, Rf T表示测试需求的总数。
(2) 已实施的测试覆盖度:Coverage＿Done= (TD/TP)
其中Coverage_Done表示已实施测试的覆盖率;TD表示到目前为止已完成的测试用例的数量, TP表示测试计划确定的测试用例的数量。
(3) 基于成功的测试覆盖程度成功的测试:Coverage＿Suc-cess= (TS/TP)
其中Coverage_Success表示已成功测试的覆盖率;TS表示到目前为止已成功完成测试的测试用例数量, TP表示测试计划确定的测试用例的数量是指测试过程中没有发现软件缺陷, 表示测试通过, 或者即使测试员发现了软件缺陷, 但是程序员进行了修改并重新测试通过。
6.2 从测试成本角度分析
不同缺陷需要的测试工时是不尽相同的。设计与代码审查过程是有效的发现与排除缺陷过程。设审查组的第i次审查为准备设计与代码检查, 所用的工时数为Ti1, 实际审查所用的工时数为Ti2, Si代表第i次审查中查出的主要 (非轻微) 缺陷数。I为迄今为止的总审查次数。则某阶段审查出每个缺陷的工时数M为:
对新开发程序而言, M一般有一个稳定范围, 例如3-5。如果M显著低于这个规范, 说明缺陷密度可能太高———因为准备工作不充分或实际测试过程不充分, 产品开发可能存在问题, 应对开发过程仔细审查;如果显著高于这个范围, 说明审查过程可能有缺点。M的不断度量使质量可靠性部门及时对开发及审查过程的质量进行一定的监控。
6.3 开发人员熟练程度度量分析
首先计算开发人员的缺陷率DBR (neveloperBugRatio)
DBR=该阶段缺陷总数/某人该阶段开发代码行数L, 这里用某一时期某一开发人员缺陷总个数与该阶段代码行数的比值来表示该开发人员的缺陷率。这只是一个粗略的计算, 不能充分反映开发人员的熟练程度, 为了充分反映开发人员的熟练程度, 我们对不同开发人员的缺陷级别 (Bug level) 进行评估:
定义1:缺陷类型权值向量W, 其中各元素WX代表缺陷类型X对应的权值:
在向量W中, 作为最后一个缺陷类型E, 虽然它不是产生于程序员本身, 而是由于系统在前期设计的不足或者存在错误导致, 但这些缺陷如果在程序开发的后期才被发现, 那么修改的成本将会很高, 因此将它的权值设为最高。
定义2:缺陷数量向量N, 代表某一编码人员被检查出的所有类型缺陷数量, 按照缺陷类型依次排列, 其中每个元素的值NX对应发现该类型X缺陷的个数, 值为0表示未发现该类型的缺陷。N= (na1, na2…, na9, na10…, nb1, nc1…, nc5, nd1…nd6, ne1, ne2)
定义3:缺陷数量加权值, 代表某一编码人员被检查出的所有类型缺陷数量的加权值。
PersonA_BL=[N, w], 向量N与W的内积表示该测试人员测试出的不同类型缺陷数 (N中元素值) 与对应权值 (W中元素值) 的乘积之和, 这是从质量的角度去衡量该人员的编码质量, 可以作为该开发人员熟练程度的标志。
6.4 测试人员的熟练程度度量分析
我们以测试人员的测试效率TE作为测试人员的熟练程度的标志。例如, 某一测试人员被检查出的缺陷数量向量是:N= (5, 3, 二, 3, 6, …, 3, 6, …, 4, 2, …, 3, 1, 0)
PersonBJE=[N, w]/T=246.5/2=73.4, 向量N与W的内积表示该测试人员测试出的不同缺陷类型数 (N中元素值) 与对应权值 (W中元素值) 的乘积之和, 再除以本次测试的周期, 作为测试人员的熟练程度。这里抛开单纯从缺陷个数的角度去衡量测试人员熟练程度的不足, 而从测试效率的角度来进行分析。影响测试人员熟练程度的因素有两个:a.测试出不同类型缺陷中权值大的缺陷数所占比重;b.本次测试所经历周期的长短, 最终的结果与a呈正比, 与b呈反比。显然如果测试出的缺陷中权值大的部分占的比重大, 同时经历的周期比原来的短, 则最终PersonB_E的值会增大, 反之将会减小。从而可以准确的反映该测试人员的熟练程度 (值越大, 该测试人员的熟练程度越高) 。
6.5 缺陷密度度量分析
软件缺陷密度是指单位代码量所引入的软件缺陷个数。代码量通常以千行为单位, 软件缺陷密度的计算公式如下:
其中, Defect_Density是缺陷密度, D是软件缺陷总数, T是指被测试软件的代码行或功能点数量。
6.6 缺陷分布分析
(1) 可以通过饼图的方式对软件缺陷的严重性进行总结, 让我们一目了然的知道软件缺陷当前的严重程度, 修复的优先级。
(2) 我们可以统计软件缺陷主要发生在哪些功能区, 从而为软件缺陷的改进指明方向。
6.7对软件缺陷的趋势进行统计
(1) 对每天发现的软件缺陷数量进行统计, 形成软件缺陷趋势图, 从而评估当前软件是否可以发布。
(2) 对软件缺陷的累计趋势进行统计, 我们不仅需要对每天打开的软件缺陷进行统计, 还需要对累计的软件缺陷进行统计。
(3) 统计软件缺陷修复情况, 将软件缺陷三种状态:打开, 解决和关闭进行比较, 从而指导当前软件测试和开发的工作。
7 结束语
目前对于缺陷管理的研究, 是一个很具有发展前途的研究课题。本文首先通过对已有缺陷属性分类方法, 缺陷分析, 缺陷管理流程的分析与总结, 设计研究一种易于实施的缺陷管理方案, 提出了基于软件度量的缺陷管理方法, 使缺陷管理从传统的模式中解脱出来, 通过对整个缺陷管理过程的度量来量化项目开发阶段的管理。从而达到了更好的监控项目进展的作用, 以及对项目相关问题的分析。
摘要：介绍了软件缺陷的分类与特性, 进一步研究基于缺陷特性的缺陷管理流程, 以及分析几种常用管理工具, 并且详细阐述了量化分析软件缺陷管理数据的方法。
关键词：软件缺陷分类,软件缺陷管理流程,软件缺陷量化分析,数据分析,缺陷管理工具
参考文献
[1]陈文海.软件测试管理工具的研究与实现[D].北京:中国科学院软件研究所, 2003.
[2]Rex Black.测试流程管理[M].北京:北京大学出版社.2001.
[3]啄木鸟部落.测试工具的选择和使用[J].程序员, 2003, (9) .
[4]李轩.基于struts的缺陷度量和管理系统的研究与实现[D].西北大学硕士论文, 2007.
[5]赖涵.软件缺陷管理的研究与辅助工具实现[D].吉林大学硕士论文, 2004.
房屋租赁管理缺陷及应对方案分析 篇4
房屋租赁管理是房地产市场管理和调控社会治安综合管理的一项基础性工作。加强房屋租赁管理是准确把握房地产市场信息, 科学调控房地产市场的内在需要, 是强化房地产行政管理职能的必要手段, 是有效实施小区和大厦物业管理的题中之意。加强房屋租赁管理对于促进房地产中介服务业发展, 规范市场秩序, 防范租赁纠纷, 创建和谐社会, 都具有十分重要的意义。因此, 在加强房屋租赁管理中, 要以“三个代表”重要思想为指导, 以服务社会和经济发展为目标, 以促进房地产市场规范健康发展为立足点, 依法认真做好房屋租赁管理工作。
2 目前房屋租赁管理缺陷分析
住房租赁市场有了较好的发展, 但是仍与房地产转让市场发展的步伐不相协调, 更是与市场经济发展的需要不相适应。
2.1 诚信缺陷
随着房屋租赁市场的壮大, 许多不法分子乘虚而入, 一些房屋中介机构既无营业执照, 也没有房屋管理部门颁发的房屋中介资质证明, 就进行无证经营, 打出虚假房屋租赁广告, 以提供虚假租赁信息和电话, 和顾客签合同, 骗取顾客押金和定金, 骗取中介费, 这种欺骗消费者的现象普遍存在。这类案件比比皆是, 例如, 2003年年底“坚石公司”卷款3000万元潜逃, “金百佳”分部携款人去楼空, 再到2004年“中天恒基”骗钱事件, 短短几个月时间里, 几家“房屋中介”屡次进行诈骗, 使公众对房屋中介机构的信任程度降到了冰点。这证明了解决行业诚信缺陷问题是目前房屋租赁管理中最迫切需要解决的问题。
2.2 管理体系无序
当前房屋租赁管理体系还没有走上一条规模化、专业化、规范化的住房租赁道路, 因此, 杂乱无序的管理必定会制约当前住房租赁市场的发展, 也成为了房屋中介机构工作中的主要障碍。同时, 我们也可以看到, 房地产开发企业经营管理方式单一, 从而导致了房地产租赁市场管理系统的单一, 制约了租赁管理系统的整体发展。
2.3 房屋租赁管理的立法滞后
当前, 我国房屋租赁市场的发展日新月异, 但是, 面对租赁管理中出现的新情况和新问题, 却缺乏相关的法律、法规与之很好地配合, 相关法律法规的建立仍存在一定的滞后性。立法工作的滞后, 是房屋租赁管理工作中最为突出的难点, 有关房产部门和房地产企业对促进房地产健康发展的意识和理念都相对滞后, 比如说对集体土地上的房屋租赁、出租人的多元化、支付租金方式、租赁形式的多样化的认识还不够全面, 因此, 房屋管理立法的滞后性是目前阻碍当前房屋租赁市场发展的重要因素。
2.4 房产租赁合同不规范
在目前的房屋租赁管理中, 出现最多的问题就是合同纠纷问题, 例如租金价格不合理的纠纷, 因为有部分中介机构只采取口头定价的方式, 出租单位没有参照房屋评估市场法进行合理的定价, 因此造成了房屋租金价格过低或过高。加上没有签订正式合同, 导致租金价格的纠纷。另外有些机构签订的合同也没有按照《合同法》有关条款签订, 造成了租赁管理的混乱。
3 进行科学有效的房屋租赁管理的应对措施
3.1 增强法律意识, 避免房屋租赁纠纷
《城市房地产管理法》规定, 房屋租赁是指房屋所有权人作为出租人将其房屋出租给承租人用, 由承租人向出租人支付租金的行为。“住宅用房的租赁, 应当遵照国家和房屋所在地城市人民政府规定的租赁政策。”公有房屋租赁, 出租人必须持有《房屋所有权证》和政府规定的其他证明文件。私有房屋出租人必须持有《房屋所有权证》, 承租人必须持有身份证明。要实现科学有效的房屋租赁管理, 必须增强法律意识, 用法律来保护出租者、租房者及中介机构的合法利益, 才能有效的避免房屋租赁纠纷问题的出现。在进行房屋租赁交易行为时, 要清楚房屋租赁的前提条件:公民、法人或其他组织对享有所有权的房屋和国家授权管理和经营的房屋可以依法出租。但是有以下情形之一的房屋, 一律不得出租:
A.未依法取得房屋所有权证的;
B.司法机关和行政机关依法裁定、决定查封或者以其他形式限制房地权利的;
C.共有房屋未取得共有人同意的;
D.权属有争议的;
E.属于违法建筑的;
F.不符合安全标准的;
G.已抵押, 未经抵押权人同意的;
H.不符合公安、环保、卫生等主管部门有关规定的;
I.有关法律、法规规定禁止出租的其他情形。
3.2 加强信息化租赁管理体系的建立
科学技术的应用, 是房屋租赁管理体系走向不断完善的重要途径。目前我国已经出现了一些较为完善的房屋租赁管理系统, 例如:精锐房屋租赁管理系统 (V2.6 | IT168) 、华人房产租赁管理软件 (HLO_V8) 、天远房屋租赁管理系统等。
系统中包含房屋租赁合同管理、租金管理、押金管理、统计报表、系统管理、房屋管理、业主信息、客户管理、租金提醒、合同提示等功能, 实现了出租、收款、统计、提醒等功能的完美结合, 大大地提高了房屋租赁管理工作的效率, 有效地降低了工作量、工作时间。信息化的租赁管理系统如下图所示。
信息化租赁管理体系的建立, 可以实现自动化与信息化的完美结合。首先, 在保证租赁信息全天候自动显示, 对物业的收费进行智能自动的计算, 得出准确的收费内容和数量, 保证各项管理工作有序自动进行的同时, 把人文关怀融入其中, 淡化自动化的机械性, 让房屋租赁管理的系统由管理者走向租赁者, 毕竟租赁管理管理的是人与人之间经济的问题, 如果管理者只从自身管理方便的角度出发, 而不考虑租赁者的实际利益, 那这样的租赁管理系统是不完全的、不科学不合理的, 毕竟在和谐社会观下, 人与人之间的经济关系也需要和谐化, 因而需要进一步增强管理系统的自动化的人情味, 对合同到期、租金到期、欠费的客户进行人性化的提示, 尽量使用礼貌用语, 把人性化的服务运用在日常的管理当中。其次, 在软件的运用上, 应该尽量的采用图形导航的模式, 实现管理和使用的简便化, 在方便管理者进行日常管理时, 也让操作简单化, 让一些没有计算机基础的用户能够掌握使用, 毕竟随着城市化的进一步加快, 大量的农民工成了租赁市场的一支生力军, 是租赁市场重要的参与主体, 但是他们的教育水平普遍低下, 计算机基础知识薄弱, 因此简单化的操作是十分必要的。最后, 对租赁管理者而言, 要对租赁市场进行及时有效的管理, 就必须依赖灵活的信息化管理系统, 可以根据自己的需要和市场的具体需求设置相应的收费项目, 设置不同的收费标准和项目, 保证信息化系统符合本地租赁市场的需求。
摘要：随着社会城市化进程的快速发展, 流动人口的增多, 房价高涨等情况的存在, 使得城市人们对房屋的租赁的需求越来越大。但是目前房屋租赁管理中仍存在很多的缺陷和漏洞, 基于房屋租赁管理的重要性, 本文主要探讨如何加强管理, 促进房屋租赁市场健康的发展壮大, 提高人们的生活质量和住房质量。
软件缺陷度量与软件过程管理 篇5
软件产品的生产过程是软件质量的形成过程, 所以只有在过程中实现良好的管理和质量控制, 才能得到一个质量合格的软件产品。软件缺陷就是其中的软件质量的负面影响因素。虽然所有的软件系统都不是尽善尽美的, 但是严重的质量问题会危及用户的使用, 从而危及企业的软件生产。
软件的开发阶段的缺陷管理和预防是非常重要的, 因为一旦制定了有问题的软件的设计方案, 会直接导致软件的质量隐患, 所以, 我们在研发阶段要尽可能的防止这种情况的发生, 将隐患扼杀在初始阶段。一般的做法是, 在软件研发的过程中要形成一个严谨的缺陷分析报告, 将关于软件的性能的各个方面的具体数据和资料综合整理出来, 对于存在安全隐患和易出现问题的环节做好一定的预防措施和预防方案。
2 问题描述
缺陷度量的技术的一个重要的指标和重要的作用就是对于软件系统中存在的问题的显示, 也就是对具体问题的描述。一般情况下, 软件的缺陷会分为大致的几种常见类型, 我们也可以根据这些类型, 做出不同的缺陷显示方法。正交分类方法ODC (Orthogonal Defects Classification) 作为一种常见的问题显示方法, 能够准确的显示问题, 一直被业内广泛的使用, 但是它也存在着技术上的缺陷, 就是解读方式比较复杂。另一种常见的方式是Thayer, 有点是比上一种方式的结果更精确, 但是解读起来也更加复杂。这两种方式的共同点在于都忽略了对于软件的过程的监控和分析, 这是一个非常严重的技术问题, 因为软件的研发过程才是质量问题的形成的重要阶段, 要控制质量问题, 就必须控制软件的研发过程, 所以, 我们想要找出新的监管和缺陷度量方法, 就要从控制过程的角度来分析。现在市场上的已经开发了几种缺陷管理系统工具, 例如Mercury公司的Quality Center, IBM公司的Rational系列管理工具, 微软公司的VSTS等。上述的几种技术都没有解决缺陷的分类问题, 导致了在软件过程的管理中的缺陷分类的薄弱。也直接导致了现有的缺陷管理工具在实用性和综合性方面的不完善, 上述的两种管理工具只是提供一些缺陷属性数量的简单统计结果, 要想得到一些更精确和更综合全面的分析结果, 用户不得不借助其他的统计方式。基于该目前市面上的工具的这样一种缺陷, 和软件过程管理的实际需要的不协调, 笔者制定了一种新的管理模型, 如图1。该模型可根据需要设计缺陷属性度量分类标准。在软件开发过程中通过缺陷管理系统采集缺陷数据, 运用缺陷分析方法实施缺陷分析, 把握缺陷发展趋势, 对软件项目开发过程进行综合评价。实施缺陷预防方案, 提高软件产品的开发质量。通过缺陷分析结果的反馈, 改进缺陷度量分类标准和分析目标, 提高缺陷分析结果的准确性。本文重点研究了缺陷分类方法和缺陷数据的分析方法, 并结合某项目中的缺陷数据实例进行了分析。
3 缺陷分类方法研究
3.1 缺陷分类的目的和原则
将软件的缺陷问题分类, 可以更好的管理和击破软件的缺陷问题。并且有益于分析缺陷产生的原因, 可以早到有计划的预防。缺陷分类方法应满足以下要求:准确地对发现的缺陷类型进行分类;缺陷分类类型之间应无重叠, 并尽可能多的覆盖开发过程中出现的分类;分类要与软件生命周期有机结合, 从软件过程的角度对软件缺陷进行分类。
3.2 缺陷度量属性分类
实施度量分析的最终目的是为了服务软件的研发和试验的各个阶段的顺利进行, 一旦发现问题可以及时纠正, 以免影响软件的研发和生产。在引言中曾提到, 软件缺陷的范围很广, 它贯穿于整个软件研发和生产试验的各个阶段, 是一种伴随着软件的整个过程的始终的应用, 所以它的重要程度也可想而知。一个缺陷需要记录许多相关的度量属性, 如何划分这些度量属性也是缺陷分类研究领域的一个热点。传统的分类方法主要目标是消除软件缺陷, 而不是对缺陷出现的原因进行一个正确的评估和解决方案的分析, 这样的分类方法是不利于软件的完善和发展的。所以, 一个全方位多角度的缺陷度量方式就应运而生。下面本文中将从缺陷度量属性设计的三个方面, 即描述属性、统计属性和控制属性来进行具体阐述。a.缺陷描述属性。缺陷描述属性是指:缺陷信息描述, 对于缺陷的各个方面和各个角度的描述, 既包括缺陷的时间, 产生原因也包括具体的解决方案的策划。b.缺陷统计属性。缺陷统计属性是指:缺陷生命周期状态, 缺陷流出的开发阶段, 缺陷流出的部门, 缺陷流出的功能模块, 缺陷表现类型, 缺陷的严重等级等基于缺陷数量统计其分布的属性。并且缺陷统计属性参考正交缺陷分类方法划分, 属性间没有相关性。c.缺陷控制属性缺陷控制属性是指:处理缺陷的角色, 缺陷的分配, 处理缺陷的时间, 缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。
4 缺陷度量过程管理
4.1 处理缺陷的角色
在软件开发过程中处理缺陷的四个负责人和所负责的任务的具体情况:报告人:将发现的缺陷登录到缺陷管理系统, 描述缺陷的表现形式和再现方法, 对缺陷进行简单分类, 由项目经理、组长对缺陷进行再分配, 缺陷修正完成后, 对其进行回归测试审核。负责人:负责缺陷的调查和修正工作, 分析缺陷引入的原因。组长:分配缺陷到负责人, 并对负责人已修正缺陷进行复查, 确保不会因为修正而引入新的缺陷产生, 分析缺陷流出原因。项目经理:分配缺陷到项目组, 定期总结缺陷分析报告, 把握缺陷发展趋势, 采取应对措施保证项目的进度及开发质量, 根据缺陷分析结果改进缺陷度量属性分类。
4.2 缺陷生命周期
缺陷生命周期是指缺陷从被报出之后, 到开始修正, 再测试直到该缺陷被完全消除的时间段。缺陷生命周期是影响软件研发的一个重要的指标和因素, 定期对缺陷各种状态信息的变化趋势进行总结, 是项目经理计划开发周期, 调整开发进度的重要依据。
4.3 缺陷分配管理流程
整个的缺陷的周期主要是指从发现到完全消灭的时间, 在这个时间内, 缺陷的分配管理流程主要包括:a.报告人登陆缺陷;b.管理人员分配缺陷给相关责任人;c.责任人调查并修正缺陷, 分析缺陷引入的原因;d.管理人员对修正结果进行复查, 分析缺陷流出的原因;e.报告人验证缺陷是否被正确。
结束语
软件的研发是一项非常复杂和严谨的工程, 所以在这个阶段要对软件的质量作出各个方面的监测和试验, 这样才能最大程度上减少软件的质量问题的发生概率, 而软件缺陷度量作为软件质量监测的一个重要方式, 应该引起我们有关的工程人员的足够重视, 不断在缺陷度量的技术上提升, 这样才更好的服务于我们的软件研发工作。
参考文献
[1]何荣勤.CRM原理.设计.实践[M].北京:电子工业出版社, 2006.
软件缺陷预测技术分析 篇6
1 软件缺陷预测技术
软件缺陷预测技术发展于上个世纪七十年代 , 软件预测技术从出现至今 , 一直都是软件工程领域中最重要的内容。这主要是因为 , 它对软件的质量、开发成本、开发周期都有着影响。软件缺陷预测技术的作用对软件中存在的缺陷进行预测 , 在预测过程中需要依据软件的开发方法、复杂度等 , 通过已经发现软件中存在的缺陷对软件中潜在的缺陷进行预测。软件研究人员可以通过软件缺陷预测技术对软件产品的质量进行分析 , 并对软件最终是否可以提供给客户使用做出准确判断。
软件缺陷预测技术主要分为静态和动态两种。因为, 软件缺陷预测技术在理论和实施方法上具有多样性 , 因此两种技术存在很多分歧 , 因此在实际工作中针对不同的软件采取不同的方式。
静态缺陷预测技术利用软件复杂度、软件规模这些可以对软件缺陷的进行度量的元素对软件中潜在 , 但还没有出现的缺陷进行分析。软件研究人员通过静态预测技术对软件产品可能的模式和软件产品质量的进行合理分析 , 并对软件是否可以给用户使用做出准确判断。
动态缺陷预测技术的研究要在缺陷发生的时间基础上。在对该技术上的研究上 , 研究人员必须要根据自己的工作经验 , 对软件应用的整个寿命周期进行研究。采用该技术对利用时间分布统计软件的缺陷情况 , 寻找软件的缺陷情况。使用该技术不仅可以减低在软件上的修复成本 , 并可以减低对软件缺陷的修复时间。
2 软件复杂性度量与缺陷预测之间的关系
软件的质量主要通过软件的可维护性、可理解性进行反映。软件外部属性主要包括软件的可靠性、可理解性、可维护性等。在软件测试过程可以对软件的规模、控制流、数据流等属性进行量化。在软件测试过程中对软件的外部属性进行度量 , 可以获取软件研究人员需要的数据 , 对软件开发进行指导。然而在软件测试过程中对外部属性只有定性定义 , 并没有利用数字对其进行明确定义 , 因此在实际工作中对其进行度量显得十分困难。复杂性度量的目的在于利用软件外部属性度量从而获取外部属性值 , 是在软件测试中进行缺陷测试的主要模型工具。软件复杂性度量、软件质量、软件缺陷预测三者之间关系如图1所示。
从图1可以看出软件模块在发生错误时可以对软件的可靠性进行直接反应 , 但却无法直接获取。将软件复杂性度量的度量值当作为整个软件缺陷预测的输入值 , 获取的整个系统中出现错误的预测值 , 然后利用预测值对整个软件的质量进行反映。
3 软件缺陷预测原理
进行软件缺陷测试的主要目的在于提高软件研究人员对整个系统有一个宏观认识。区分系统中不同模块在发生错误时的倾向 , 从而可以合理分配软件修改和测试过程中使用的资源 , 降低在软件开发过程中的人力和财力上的消耗 , 提高软件开发效率。软件缺陷测试原理如图2所示。
3.1 软件复杂度性度量
在进行软件缺陷测试时 , 应当对软件早期测试数据和早期版本的相关数据进行收集 , 并从中对成功的经验进行提取。软件复杂性度量主要包括两部分 :度量属性和历史数据。在软件缺陷测试过程将软件复杂性度量作为样本数据“属性”, 在软件测试过程中 , 可以将样本中得到数据作为样本中的“数值”。这样在实际工作中就可以将复杂性度量数据进行集中 , 组成样本。在软件测试过程中的“值”的数据类型为布尔型 :有出错倾向和无出错倾向。在对软件缺陷预测技术中应用的“属性”来自软件开发中的属性集。
3.2 建立缺陷预测模型
数据集利用“同属一值”的方式对复杂性度量中的样本和复杂性度量是否存在出错倾向之间的非线性管理 , 简单的说 , 缺陷预测模型本身属于一种模式识别形式。而在实际工作中建立缺陷预测模型就是利用合理的机器算法进行模型结构的搭建 , 并对复杂性度量属性之间相互产生的依赖程度进行确定 , 也就是参数学习和模型学的一个过程。
3.3 利用模型预测结果
在软件缺陷预测模型部分 , 预测部门和训练集从本质上就各不相同的。在实际工作中 , 可以对建设好的预测模型进行利用 , 然后通过模型参数和模型结构对预测结构和复杂性度量的关系进行判断 , 这样在实际软件测试过程中就可以通过软件模块复杂性度量在数据集上的数据 , 然后利用训练好的模型 , 确定该模块是否存在缺陷 , 从而实现软件缺陷预测。
3.4 数据预处理
在对数据进行预处理时要对两个方面的问题加以考虑。1) 对原始数据的采集避免不了会存在噪声数据 , 噪声数据的使用势必会使模型的预测能力下降。2) 不同数据的复杂性度量与量纲之间存在很大差异 , 如果在运用过程中不进行合理的处理 , 会导致在性能和时间上发生一些不可估量的问题。在预处理上首先需要处理噪声数据 , 在对操作数据的处理方式可以采用忽略样本法。数据预处理第二部就是对数据进行归一化 , 消除不同量纲产生的影响。
4 结论
缺陷预测试技术的应用的最终目的对软件中还存有的缺陷进行预测 , 在应用过程中 , 依据软件自身特有的属性。例如 :复杂度、规模、开放过程等等 , 利用已发现的软件存在的缺陷 , 为发现的缺陷或遗留的缺陷进行测试。在软件测试过程中对缺席预测技术进行合理应用, 可以帮助工作人员对软件的质量做出客观判断 , 从而确定软件是否能够正常使用 , 软件在使用过程中可能会出现的失效模式进行判断。
参考文献
[1]杨根兴, 蔡立志, 陈昊鹏.软件质量保证、测试与评价[M].北京:清华大学出版社, 2012:34-36.
[2]黄科.计算机软件质量和软件质量保证[J].电脑知识与技术, 2010, 6 (6) :727-728.
[3]颜炯, 王戟, 陈火旺.基于UML的软件Markov链使用模型构造研究[J].软件学报, 2012, 6 (8) :12-13.
软件缺陷管理方案分析 篇7
众所周知,软件故障对软件可靠性具有重要影响。软件错误是一种人为错误,一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时,便产生一个软件故障。软件故障如果没有得到有效、及时的处理,便不可避免地导致软件失效。因此,分析不同软件故障对软件可靠性的影响,是软件可靠性研究的重要内容之一。
由于软件错误和缺陷是软件失效的源头,人们对此进行了大量的研究工作,提出了多种软件缺陷分类法。由于观察问题的角度不同,其分类也各有不同,下面是几种有代表性的软件缺陷分类[1,2]:
(1) Putnam等人从软件生存周期的角度提出的分类方法,将软件缺陷分为六类:需求缺陷、设计缺陷、文档缺陷、算法缺陷、界面缺陷和性能缺陷。
(2) Thayer软件错误分类方法[3]按错误性质分类,它利用测试人员在软件测试过程填写的问题报告和用户使用软件过程反馈的问题报告作为错误分类的信息,包括16大类,164个子类。这16个大类分别是计算错误、逻辑错误、I/O错误、数据加工错误、操作系统和支持软件错误、配置错误、接口错误、用户需求改变(指用户在使用软件后提出软件无法满足的新要求产生的错误)、预置数据库错误、全局变量错误、重复的错误、文档错误、需求实现错误(指软件偏离了需求说明产生的错误)、不明性质错误、人员操作错误、问题(指软件问题报告中提出的需要答复的问题)。该分类方法特别适用于指导开发人员的缺陷消除和软件改进工作。通过对错误进行分类统计,可以了解错误分布状况,对错误集中的位置重点加以改进。该方法分类详细,适用面广,当然分类也较为复杂。该分类方法没有考虑造成缺陷的过程原因,不适用于软件过程改进活动。
(3) 电气和电子工程师学会制定的软件异常分类标准(IEEE Standard Classification for Anomalies 1044-1993)对软件异常进行了全面的分类,该标准描述了软件生命周期各个阶段发现的软件异常的处理过程。分类过程由识别、调查、行动计划和实施处理四个步骤组成,每一步骤包括三项活动:记录、分类和确定影响。异常的描述数据称为支持数据项,分类编码由两个字母和三个数字组成,如果需要进一步的分类可以添加小数。其中调查步骤将异常类型分为逻辑问题、计算问题、接口/时序问题、数据处理问题、数据问题、文档问题、文档质量问题和强化问题,共八个大类,每一个大类又分为数量不等的小类。分类细致深入,准确说明了异常的类型。
(4) 正交缺陷分类ODC[4](Orthogonal Defects Classification)是IBM公司提出的缺陷分类方法。缺陷类型被分为七大类:赋值、检查、算法、时序、接口、功能、关联。该分类方法提供一个从缺陷中提取关键信息的测量范例,用于评价软件开发过程,提出正确的过程改进方案。该分类方法分类细致,适用于缺陷的定位、排除、原因分析和预防活动。缺陷特征提供的丰富信息为缺陷的消除、预防和软件过程的改进创造了条件。它的缺点在于分类复杂,难以把握分类标准,缺陷分析人员的主观意见会影响属性的确定。
(5) 马里兰大学/NASA软件工程实验室缺陷分类法。它从缺陷的最初来源,缺陷修复时间,缺陷发现方法,缺陷发现的模块这四个因素入手开展缺陷分析。该分类法仅从缺陷产生的原因分析,没有从缺陷发生的角度分析,仅是ODC方法实现的一部分。
(6) 优利系统公司错误分类方案。1984年优利系统公司实行的错误分类方案通过填写软件变更报告,搜集软件变更原因、问题适合的发现和隔离方式、软件开发人员最初编写的代码是否正在被修补、隔离和修改花费的时间、修改的模块等客观问题,以及问题原因判断、理由两个主观问题的答案。这些问题的回答帮助将缺陷从“错误主要分类”、“错误类型”、“限定”、“用途”四个方面分类。该分类从软件开发过程中多个角度实现了有价值的分析,但分类不够清晰。
(7) IBM的缺陷预防方案。1990年IBM研究中心的R.G.Mays等人提出的缺陷预防方案是采用因果分析方法对缺陷进行分析,包括三个步骤:1)将缺陷归类于疏忽、教育、交流不当、文字错误等问题;2)分析缺陷起因及引入的时间,并讨论如何防止类似缺陷再次出现;3)查找剩余残留缺陷,并消除所有存在的缺陷并改进开发过程。该方法和根源分析法类似,人为执行因果分析时容易受到过多主观因素的影响,分析结果不客观。
以上是当前有代表性的几种软件缺陷分类方式,但这些分类法都是宏观地考虑整个软件开发过程,并没有从代码的角度对软件缺陷进行分类。
1 面向程序代码的缺陷分类
使用程序变异方法注入故障,首先必须从程序代码的角度对软件缺陷进行分类。在分析、研究了已有的各种分类方法的基础上,针对C++语言,我们提出了面向程序代码的软件缺陷分类法。该方法将软件缺陷分为以下五类:
(1) 赋值缺陷 主要指由变量未赋值和赋值不正确引起的故障。这类软件故障主要包括:变量未初始化就使用错误;数组变量的越界错误;数组元素使用错误;指针变量使用错误;指针越界;数据类型不匹配的错误;算术表达式优先级错误;非法算术运算错误(除数0,负数开方);整数和浮点数的上溢下溢错误;非法类型转换错误;引用赋值与内容赋值使用错误等。这类故障常发生于函数的开头部分。
(2) 分支缺陷 主要发生在分支的判断体及分支结构部分。这类软件缺陷主要包括:等于运算符使用错误;边界值被忽略;逻辑运算符与位运算符的误用;逻辑运算符使用错误;if-else匹配错误;缺少默认情况;逻辑表达式优先级错误;引用比较与内容比较使用错误等。
(3) 循环缺陷 主要发生在循环条件及循环结构部分。这类软件缺陷主要包括:边界值错误;等于运算符使用错误;循环变量使用错误;多循环嵌套时,因大括号位置错误引起的循环体不完整;break语句与continue语句使用错误;永不循环错误等。
(4) 接口缺陷 主要指用户、构件、函数之间的信息交换错误。这里所说的接口表现为函数调用、参数传递、函数返回值及共享的全局变量。这类软件缺陷主要包括:函数调用参数传递错误;多出口函数中某个return语句的丢失错误;return语句返回值错误;函数调用错误;函数调用丢失;响应延迟;响应丢失类故障;发送/接受错误消息;多用户冲突引起的系统异常;同步异常等。其中,响应延迟、响应丢失类故障、发送/接受错误消息、多用户冲突引起的系统异常和同步异常主要发生在分布式软件中。
(5) 类缺陷 主要指与面向对象特征相关的错误。这类软件缺陷主要包括:访问控制错误;状态可见性异常;状态定义不一致;状态定义异常;异常处理错误;构造函数行为异常;构造函数不完整;类型使用不一致;重载函数实现错误;重载函数使用错误等。
2 程序变异及其分类
程序变异作为一种软件实现的故障注入方法,最早在20世纪70年代末期由DeMillo等人提出。它能够系统地模拟软件中存在的各种缺陷,并构造较为完备的测试用例集。虽然该技术具有较强的排错能力,但它对资源的消耗也是不容忽视的。
程序变异是指根据软件缺陷定义一系列的变异算子,并将变异算子作用于程序代码,从而改变程序句法以达到故障注入的目的。程序变异理论基于两个基本假设:一是程序员的能力假设,即假设程序不存在功能型错误,只存在一些代码编写的失误;二是组合效应假设,即复杂错误是简单错误的组合。
程序变异常用于软件测试阶段,它的基本原理是使用变异算子每次对被测试程序做一处微小的合乎语法的改动,从而产生大量的新程序,我们称之为变异体,然后根据已有的测试数据运行变异体,比较变异体和原程序的运行结果,如果两者不同,就称测试数据将该变异体杀死[5]。这样做的目的是不断提高测试数据集的测试充分度。变异测试是一种行之有效的测试方法,具有排错能力强、灵活性好、自动化程度高等优点。但它也存在一些缺点,如需要大量的计算机资源来产生、存储、运行变异体,并且需要大量的人工操作。
在程序变异中,变异算子的设计一直是人们研究的重点。针对不同类型的软件缺陷,研究人员设计出不同类型的变异算子。按照模拟软件缺陷的类型不同,可将程序变异分为以下四种:
(1) 传统变异 在早期程序变异的研究中,变异算子的设计主要集中在对操作数和运算符的变异上。有代表性的研究成果是Mothra测试工具集[6]。它针对Fortran语言定义了22种变异算子,这些变异算子源自程序员的错误。
(2) 接口变异 它模拟集成错误,在模块的接口处作用变异算子产生变异体。变异算子的设计主要针对函数调用、参数传递、函数返回值、共享的全局变量。文献[7]针对C语言设计了分别作用于被调用函数内部和调用函数内部的两组接口变异算子。文献[8]的实验结果表明接口变异不仅产生较少的变异体,消耗较少的资源,而且揭错率也维持在较高的水平。
(3) 类变异 是传统变异测试的一个延伸,它针对面向对象软件的特殊性质,模拟类、对象、继承、封装、信息隐蔽、多态、动态绑定等方面的软件缺陷。
文献[9]针对Java语言定义类变异算子,通过类变异算子植入与Java面向对象特征相关的错误。这些变异算子包括:更改访问控制符;删除隐藏变量;插入隐藏变量;删除覆盖方法;改变覆盖方法调用位置;重名命覆盖方法;删除super关键词;删除父类构造函数的显式调用;将子类型对象的声明替换为父类型;子类对象替换参数中的父类对象;兼容类型对象的赋值替换;改变重载方法的内容;删除重载方法;删除异常处理;修改异常处理;引用赋值和内容赋值之间的替换;引用比较和内容比较之间的替换。
(4) 合约变异 它是针对功能规约的变异测试,发现由于规约被错误理解或实现所导致的程序中的错误。与传统变异测试相比,合约的规模小于程序,其产生的变异体数目较小。此外,还可以通过定义有效的变异算子来减少合约变异体的数量,从而降低变异测试的计算代价[10]。
3 变异算子的设计
我们用变异算子模拟软件中将会出现的各类软件缺陷,通过程序变异的方法将软件故障注入到代码中。程序变异的同时,在变异体中插入故障检测代码,实现对故障的自动检测。按照第1节的软件缺陷分类,为每一类软件缺陷设计了一些变异算子来进行模拟。在设计变异算子时,我们遵循变异算子的两个设计原则:第一,程序的改动必须是微小的;第二,改动必须是符合语法规则的,也就是编译时不报错,程序能够正常执行。表1是为这五类软件缺陷所设计的变异算子。
3.1 赋值缺陷
为了模拟赋值故障,设计了五种变异算子。当被赋值的变量与原变量的值不一致时,认为故障发生。
(1) 删除变量初始化(DVI)
通过删除局部变量的第一次赋值,模拟变量未初始化就使用错误。
(2) 随机数替换整形值(RIR)
通过用随机数赋值给当前整形变量,模拟整形变量的赋值错误。在变量的使用过程中,整形变量的使用是最为频繁的,因此我们单独设计变异算子来模拟整形变量的赋值错误。
(3) 数组长度代替数组下标(LRS)
通过用数组长度的值代替当前数组元素的下标,模拟数组越界错误。
(4) 数组元素替换(AAR)
通过随机选择数组中的元素替换当前元素,模拟数组元素使用错误。与RIR算子相同,使用C语言的库函数rand()产生一个随机数,再通过求余运算,即可得到数组长度范围内的随机数。
(5) 将float型转换为int型(FCI)
通过float型变量强制转换为int型,模拟非法类型转换错误。
3.2 分支缺陷
为了模拟分支故障,设计了三种变异算子。当变异体的执行路径与原程序的执行路径不一致时,认为故障发生。
(1) 分支结构中赋值运算符替换等于关系运算符(ACB)
在分支结构的判断条件处,经常会发生“==”与“=”的误用,这类错误主要由于程序员的疏忽所致。
(2) 分支结构中逻辑运算符替换(LRB)
通过在分支结构的判断条件中,用“&&”替换“‖”,或者用“‖”替换“&&”,模拟分支结构中逻辑运算符使用错误。
(3) 删除括号(DPB)
通过删除嵌套的if语句中的括号,模拟if-else的匹配错误。
3.3 循环缺陷
为了模拟循环故障,设计了以下三种变异算子。当变异体的循环判断条件的真假值与原程序的不一致时,认为故障发生。
(1) 循环结构中赋值运算符替换等于关系运算符(ACL)通过将循环条件中“==”替换为“=”的方法,模拟循环结构中的等于运算符使用错误。
(2) 循环结构中逻辑运算符替换(LRL) 通过在循环条件中,用“&&”替换“‖”,或者用“‖”替换“&&”,模拟循环结构中逻辑运算符使用错误。
(3) 改变循环变量(CVL) 通过用相同类型的变量替换循环变量,模拟循环变量使用错误。这种变异也常会伴随引入变量未初始化就使用错误。
3.4 接口缺陷
为了模拟接口故障,设计了以下四种变异算子:
(1) 改变调用参数顺序(POC) 通过改变函数调用中兼容类型参数的顺序,模拟函数参数传递错误。这种类型的错误通常由于程序员的疏忽所致。
(2) 兼容型变量替换参数(VPR) 通过用兼容型的变量替换被调用函数参数,同样可模拟函数参数传递错误。另外,此变异若发生在Socket中的Send函数时,可模拟发送错误消息。
(3) 删除调用语句(FCD) 通过删除一个不在赋值语句中的函数调用,模拟函数调用丢失。
(4) 删除return语句(RSD) 在有多个出口的函数中,通过删除其中一个出口的return语句,模拟return语句丢失。
3.5 类缺陷
为了模拟类故障,设计了以下五种变异算子:
(1) 改变访问控制符(AMC) 通过改变成员变量的访问控制符模拟访问控制错误。该类故障依赖于软件特性,一般不易发生。此变异一般作用于类的头文件。
(2) 删除隐藏变量(IHD) 通过删除派生类中与基类同名同类型的变量,模拟因隐藏变量引起的状态定义不一致错误。此变异一般作用于类的头文件。
(3) 声明基类成员变量(MDB) 通过用基类声明一个派生类的对象,模拟类型使用不一致错误。
(4) 删除派生类覆盖函数(OMD) 通过删除派生类中的覆盖函数,模拟因覆盖引起的状态定义异常。
(5) 改变被覆盖函数的调用位置(OCC) 有些情况下派生类的覆盖函数需要调用基类的函数,通过改变被调用的基类函数的位置,模拟状态可见性异常。
4 软件缺陷对软件可靠性影响的分析
4.1 实验内容及步骤
选取经过充分测试后的软件作为实验对象,其缺陷数为0,软件可靠性为1。用程序变异的方法将上述变异算子分别作用于该实验对象,估计软件的可靠性,分析比较这些故障对可靠性的影响。实验的具体步骤如下:
(1) 从实验对象中选取待注入故障的构件。因为在C++语言中程序代码以CPP格式的文件存放,所以我们选择待注入故障的构件所在的CPP文件。
(2) 从上一节选择变异算子,将其作用于步骤(1)中所选的CPP文件,生成多个变异体。变异体的命名采用“原文件名+变异算子+流水号”。例如“CImageView_DVI_5.cpp”表示DVI变异算子作用于CImageView.cpp文件后所产生的第五个变异体。
(3) 选择一个步骤(2)中产生的变异体替换原文件,达到故障注入的目的。此时的实验对象中已包含了产生该变异体的变异算子所模拟的故障。
(4) 使用改进后的Cheung模型估计上一步得到的含有故障的软件的可靠性,具体步骤如下:
① 根据分布式软件在实际使用中各功能与数据的出现频率,建立操作剖面。频率必须从大样本中获取,以确保统计数据的有效性。
② 为分布式软件划分构件,确定构件间的连接件。将每台主机上的通信模块定义为一个连接件,该主机的其余模块定义为一个构件。根据各构件之间的调用关系,建立分布式软件体系结构及转移概率矩阵。
③ 根据耦合性最小的原则,并为每个构件划分子构件。根据子构件之间的调用关系,建立该构件的转移概率矩阵。
④ 从操作剖面中选择一个操作序列,通过执行分布式软件,收集失效数据。
⑤ 取一个构件,根据步骤④得到的失效数据,计算其中每个子构件的可靠性。
⑥ 根据步骤③中所得到的该构件的转移概率矩阵与步骤⑤中得到的子构件的可靠性,计算当前构件的可靠性。
⑦ 从步骤⑤开始重复执行,直到所有构件的可靠性都已计算完成。
⑧ 根据步骤④得到的失效数据,计算每个连接件的可靠性。
⑨ 根据步骤②、⑥、⑧所得到的分布式软件转移概率矩阵、构件可靠性、连接件可靠性,修正分布式软件的转移概率矩阵,计算当前操作序列下的软件可靠性。
⑩ 从步骤④开始重复执行,直到所有操作序列下的软件可靠性均计算完成。根据步骤①、⑨得到的操作剖面与各操作序列下的软件可靠性,计算最终的分布式软件可靠性。
(5) 重复执行步骤(3)、(4),记录所有的软件可靠性的值,分析比较实验结果,得出结论。
按照设计好的实验步骤,漫游系统实验选取文献[11]中提到的立方体全景图虚拟场景漫游系统(简称漫游系统)作为实验对象。该系统是在VC++ 6.0集成环境下,基于文档视图结构开发的可以在单机上运行的软件,属于集中式软件。它包含2017行代码,提供了水平、垂直方向的360度旋转漫游及场景的缩放功能。
4.2 实验数据分析及结论
选择第3节中的变异算子作用于漫游系统的CImageView.cpp文件,估计软件可靠性,我们用图形来表示注入各故障后漫游系统的可靠性,其中横轴表示各变异体,纵轴表示含有该变异体的软件可靠性。图1-图5分别表示五种类型故障对漫游系统可靠性的影响程度。
根据上述数据可以得到注入各类故障后系统可靠性的分布区间和平均值,如表2所示。
从表2中我们可以看到,含有赋值故障的软件可靠性的平均值最小,并且其分布较为集中,故认为赋值故障对该软件可靠性影响最大;含有类故障的软件可靠性的平均值最大,并且其分布区间也相对集中,所以我们可以得出类故障对软件可靠性的影响最小;除类故障外,含有接口故障的软件可靠性的平均值较大,其次是含有循环故障的软件和含有分支故障的软件。
总体来看,可以得出这五类故障对漫游系统可靠性的影响由大到小依次为赋值故障、分支故障、接口故障、类故障。由于含有循环故障的软件可靠性分布区间较宽,且较散乱,因此其平均值并不能说明该类故障对软件可靠性的影响程度,但我们可以得出该类故障会因变异体的个体差异而对软件可靠性造成不同的影响。
赋值故障一般发生在程序中函数的开头部分,后续的语句会直接或间接的使用到这些变量,故障的扩散性较强,因此该类故障对软件可靠性的影响较大。分支故障仅会发生在分支型结构的某个分支上,当程序在分支结构中的执行路径发生变化时故障才会发生,因此该类型故障发生的概率要比其他类型故障发生的概率要小,对软件的影响也较小。由于分支结构与循环结构在程序中占有很大的比例,而接口故障经常会发生在分支结构与循环结构中,因此故障发生的次数较少,所以该类故障对软件可靠性的影响较小。另外,在含有循环故障的软件中,由于循环次数的不确定性,导致故障发生次数的不确定,因此故障的个体差异使其对软件可靠性的影响不同。
类故障对不同的软件影响程度不同。第一,类故障与面向对象特性使用的多少有关,如覆盖、继承、重载等。当这些技术在软件中的应用较多时,出错的概率也较大,对软件可靠性的影响也较大。第二,类故障与软件的规模有关。类故障发生的条件较严格,在软件的一次运行中失效次数较少。当软件规模较大时,构件的执行次数较多,因此构件的可靠性较高,软件的可靠性也较高。
通过进一步的实验发现,软件可靠性值的分布与软件规模有关。表3给出了二个实验软件的测试数据。可以看到,软件规模较大时,可靠性的值的分布也较广,下限低,上限高;软件规模较小时,可靠性的值分布较窄,下限高,上限低。表中C/S系统的软件规模指的是客户端的代码行数。当软件规模较大时,构件的执行次数会增多,构件的失效次数也会增多。当执行次数增长速度大于失效次数增长速度时,构件可靠性提高,同时软件可靠性也提高;反之,构件可靠性和软件可靠性均降低。因此当软件规模较大时,可靠性波动也较大,各类故障对软件影响的差异性也较大。
5 结束语
软件缺陷是引起各类软件失效的根本原因,是影响软件可靠性的重要因素。研究人员从不同的角度出发,对软件缺陷进行了分类。然而这些分类方法均没有从程序代码的角度对软件缺陷进行分类。本文提出了一种面向程序代码的缺陷分类方法。根据这一分类法,设计了模拟各类软件故障的变异算子;采用程序变异方法,通过实验获得了各类软件故障对软件可靠性影响的相关数据,得出了各类软件故障对软件可靠性的影响程度,对软件的开发和使用都具有实际意义。
参考文献
[1]聂林波,刘孟仁.软件缺陷分类的研究[J].计算机应用研究,2004(6):8486.
[2]戚馨文.ODC和OPC方法在软件质量管理中的应用[D].浙江大学,2006.
[3]黄锡滋.软件可靠性、安全性与质量保证[M].北京:电子工业出版社,2002.
[4]Ram Chillarege,et al.Orthogonal Defect Classification:A Concept forIn-process Measurements[J].IEEE Transactions on Software Engineer-ing,1992,18(11):94395.
[5]单锦辉,李炳斌,孙萍.变异测试——一种面向缺陷的软件测试方法[J].半导体技术,2007,32(增刊):8085.
[6]King K N.A Fortran Language System for Mutation-Based SoftwareTesting[C]//ACMSIGPLAN Symposium on Interpreters and Interpre-tive Techniques,St.Paul MN,1987,7.
[7]Delamaro ME,Maldonado J C,Mathur A P.Interface mutation:an ap-proach for integration testing[J].IEEE Transactions on Software Engi-neering,2001,27(3):228247.
[8]Delamaro M E,Maldonado J C,Mathur A P.Integration Testing UsingInterface Mutation[C]//Proc.VII Int'l Symp.Software Reliability En-gineering(ISSRE'96).1996,11:112121.
[9]Ma Y S,Kwon Y R,Offutt A J.Inter-class mutation operators for Java[C]//Proceedings of the 13thInternational Symposium on SoftwareReliability Engineering(ISSRE 2002).Annapolis,MA,USA,2002:352363.
[10]姜瑛,辛国茂,单锦辉,等.一种Web服务的测试数据自动生成方法[J].计算机学报,2005,28(4):568577.
软件缺陷管理系统的设计与实现 篇8
1 软件缺陷管理模型
软件测试活动贯穿整个软件开发过程，包括需求测试、概要设计测试、详细设计测试、单元测试、集成测试、系统测试和验收测试等，软件测试管理是一种活动，可以对软件测试各阶段的测试计划、测试用例、测试流程进行管理、跟踪、记录其结果，并将结果反馈给系统的开发者和管理者，同时将测试人员发现的缺陷记录下来，进行跟踪、控制和监督，同时生成缺陷报告并对其进行管理[2]。
本文结合前人的工作，结合软件开发和测试的过程，提出了软件缺陷管理工作模型，如图1所示。首先，系统分析员将需求分析提交到需求库，并指定给测试经理和项目经理;测试经理接收到需求分析后，将需求分析审核测试划分为若干任务指派给各测试人员，测试人员接收到任务后进行需求规格测试，对找到的需求缺陷创建缺陷实例，进入BUG库，并指派给测试经理;测试经理对所找到的需求缺陷进行审核鉴别，审核缺陷的是否为真实缺陷，审核缺陷的登记，确定对该缺陷的下一步处理方案等。如果确定该缺陷要立即进行处理，测试经理则将该缺陷指派给对应的需求分析人员。对于设计和编码做同样的处理。
2 系统分析与设计
2.1 系统的功能描述
根据软件缺陷管理的特点和需求，系统应该具备下列基本功能：
1)测试人员可以通过系统获得测试任务，通过系统创建测试用例、管理测试用例，通过系统创建缺陷，管理跟踪缺陷。
2)测试经理可以通过该系统创建测试任务，指派测试任务，审核软件缺陷，指派软件缺陷。
3)决策人员可以通过系统分析当前软件缺陷的状态，分析软件的质量。
系统功能模块图如图2所示。
2.2 软件缺陷的属性及生命周期
软件缺陷的管理是本系统的重要内容，一个完整的缺陷数据信息主要由缺陷的基本属性、状态和等级等组成。我们主要考虑的软件缺陷信息有：1)所属模块，软件缺陷属于整个项目中具体的模块编号。2)缺陷类型，该缺陷属于什么样的BUG，需求错误，设计错误或则编码错误等。3)严重程度，描述缺陷的破坏程度，分为严重、主要、次要和轻微四个等级。4)优先级，描述缺陷解决的紧急程度，分为紧急、很高、高、中和低等5个级别。5)缺陷的状态，描述缺陷在生命周期中所处的阶段。6)拥有者，发现缺陷的人。7)指派给，指定该缺陷由谁负责下一步处理。8)解决者，解决该软件缺陷的人。9)缺陷标题，缺陷的简要描述。10)重现步骤，再现该缺陷的操作步骤，供相关人员找到该缺陷的原因。11)用例，该缺陷所对应的测试用例。12)附件，与缺陷相关的文件。
软件缺陷的生命周期分为创建，未审核，分配，打开，拒绝中，拒绝，修正，异议，关闭等几个状态，各状态间的转换如图3所示。
2.3 系统的结构
系统结构采用J2EE的三层架构设计，三层分别是客户层，应用服务层和数据服务层，其中应用服务层按照MVC设计思想进一步分层设计，包括：表示层，控制，业务层和数据访问层。该设计最大的优点是模型、视图和控制分离，各组件之间有较低的耦合度，提高了系统的开发效率，增加了系统的可维护性。系统结构如图4所示。
1)表示层的设计主要采用JSP,CSS,JavaScript等将模型数据，业务关系展示给用户。
2)控制层处理用户与软件之间的交互操作，实现针对不同的用户请求进行不同的页面流重定向。
3)模型层实现对数据库表的封装，数据库中每一张表都对应一个JavaBean和一个与该JavaBean相关的java类以实现相关的业务逻辑。
3 系统实现
本文，MVC模式采用Structs框架实现。Structs框架是一个很好的MVC的应框架。Structs框架的优点：视图与业务逻辑分离，使开发者只关注业务逻辑的实现。有丰富Struts标记库(TagLib)，大大提高开发效率。开放源码，可以查看代码并能检查代码[3]。在Structs框架中，模型由Action和ActionForm对象构成，所有的Action处理器对象都是从Structs的Action类派生的子类，Action处理器对象封装了具体的处理逻辑，调用业务处理模块，并且把响应提交到合适的视图组件以产生响应。
例如在收到测试人员新缺陷记录的请求后，将测试人员在页面上输入的缺陷信息数据填入模型类中，然后控制器进行业务处理，将一条新的缺陷数据添加到系统中。实现的部分关键代码如下：
4 总结
本文在前人工作的基础上，提出了软件缺陷管理模型，该模型实现了软件测试过程的自动管理，定义了缺陷的生命周期和相应的状态变换，达到减少测试人员的工作量，提高测试效率的目的。系统采用J2EE三层架构，并且运用了Struts模板技术，实现了MVC经典的模式，使系统结构松散，具体有较高的可靠性和可维护性。
摘要：软件缺陷管理是软件项目管理的重要组成部分,是保证软件质量的重要手段,该文研究了软件缺陷管理模型,在此基础上设计软件缺陷管理系统,采用J2EE三层架构和MVC设计模式实现该系统,系统提供BUG跟踪、软件功能模块、测试用例、部门及角色管理功能,并提供大量统计报表功能。
关键词：软件缺陷,软件质量,MVC
参考文献
[1]鞠秀娟,赵明.基于CMM的缺陷管理系统的设计及应用[J].四川大学学报:工程科学版,2007,39(S1).
[2]陈文海,秦晓.软件测试管理工具的研究与实现[D].中国科学院研究生院,2003.