软件缺陷（精选8篇）
软件缺陷 篇1
1 概述
软件产品的生产过程是软件质量的形成过程, 所以只有在过程中实现良好的管理和质量控制, 才能得到一个质量合格的软件产品。软件缺陷就是其中的软件质量的负面影响因素。虽然所有的软件系统都不是尽善尽美的, 但是严重的质量问题会危及用户的使用, 从而危及企业的软件生产。
软件的开发阶段的缺陷管理和预防是非常重要的, 因为一旦制定了有问题的软件的设计方案, 会直接导致软件的质量隐患, 所以, 我们在研发阶段要尽可能的防止这种情况的发生, 将隐患扼杀在初始阶段。一般的做法是, 在软件研发的过程中要形成一个严谨的缺陷分析报告, 将关于软件的性能的各个方面的具体数据和资料综合整理出来, 对于存在安全隐患和易出现问题的环节做好一定的预防措施和预防方案。
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.
[2]肖阳春.计算机网络与多媒体技术[M].北京:中国铁道工业出版社, 2008 (6) :81-82.
软件缺陷 篇2
安全专家表示，IE7允许一个网站显示包含有虚假Web地址的弹出式窗口。 可以利用这一缺陷诱骗人们相信他们在访问一个可靠的网站，而实际上他们在访问一个恶意网页。微软称，问题在于IE7地址栏显示Web地址的方式， 可以通过诱骗用户点击一个特殊格式的链接来利用这一缺陷，
据了解，IE7是5年来微软首次对IE进行的重大升级，而安全是它的第一任务。
软件缺陷管理 篇3
关键词：软件测试,缺陷管理
1 引言
软件缺陷会存在于软件产品的整个生命周期中, 测试是发现缺陷的主要手段, 也是它的主要目的。测试活动和开发活动一样, 是项目质量保证不可或缺的重要部分。因此, 对于测试活动的主要产物:缺陷, 我们需要建立一个完善的缺陷管理流程, 来对缺陷进行报告、查询、分类、跟踪、处理和验证等。
软件测试的主要目的在于发现软件存在的缺陷, 为了不影响测试效果, 需要及时正确的处理测试中发现的错误, 保证软件符合需求设计的目标。在实际的软件测试过程中, 建立一套完备的软件缺陷跟踪管理系统是十分必要的, 建立这样一个系统, 我们首先需要清楚每个不同bug的严重性以及它们的优先级分类, 其次是每个bug需要经过的测试管理流程。
2 缺陷严重性与优先级分类
为了能将测试的主要精力刚好地集中到最有价值的地方, 需要通过对缺陷分布情况个进行仔细分析, 重要的软件故障与失效往往会带来重大经济损失逾灾难, 因此在报告缺陷时, 要对缺陷进行分类, 并以简明扼要的方式指出其影响以及修改的优先次序。
缺陷的严重性指的是假如缺陷没有修改, 由这个缺陷引发的问题对客户的影响程度。而缺陷的优先级指的是解决这个缺陷需要的时间。下面来介绍一些分类的建议和思想。
按缺陷的严重性, 我们可以通划分成四级:
最高级别:产品在正常的运行环境下无法给用户提供服务, 并且没有其他的工作方式来补救
高级别:极大的影响了系统提供给用户的服务, 有其他的工作方式来缓解这种影响。
中等级别:系统需要增强的或存在的一些缺陷, 但有相应的补救方法来解决这个缺陷。
低级别:细小的问题, 不需要补救方法或功能增强的请求。
缺陷的优先级, 我们可以如表1进行分类:
3 缺陷管理流程
一般的缺陷管理流程如图1所示。测试人员提交新的Bug入库, 错误状态为New。高级测试人员验证错误, 如果确认是错误, 分配给相应的开发人员, 设置状态为Open。如果不是错误, 则拒绝, 设置为Declined状态。开发人员查询状态为Open的Bug, 如果不是错误, 则置状态为Declined;如果是Bug则修复并置状态为Fixed。不能解决的Bug, 要留下文字说明及保持Bug为Open状态。对于不能解决和延期解决的Bug, 不能由开发人员自己决定, 一般要通过某种会议 (评审会) 通过才能认可。测试人员查询状态为Fixed的Bug, 然后验证Bug是否已解决, 如解决置Bug的状态为Closed, 如没有解决置状态为Reopen。
软件缺陷流程管理的要点是为了保证错误的准确性, 需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误, 书写的测试步骤是否准确, 可以重复。每次对错误的处理都要保留处理信息, 包括处理姓名, 时间, 处理方法, 处理意见, Bug状态。拒绝或延期错误不能由程序员单方面决定, 应该由项目经理, 测试经理和设计经理共同决定。错误修复后必须由报告错误的测试人员验证后, 确认已经修复, 才能关闭错误。加强测试人员与程序员的交流, 对于某些不能重复的错误, 可以请测试人员补充详细的测试步骤和方法, 以及必要的测试用例。
4. 使用测试工具建立缺陷管理系统
一个缺陷跟踪系统, 需要实现几部分的功能:
(1) 缺陷的上报, 当问题被发现后, 可以通过系统进行提交、保留, 方便跟踪。
(2) 缺陷录入系统后, 项目经理应该可以通过缺陷跟踪系统进行浏览, 定期获得最新的缺陷问题报告。
(3) 项目经理将缺陷问题报告通过缺陷跟踪系统转交给程序员, 程序员可以通过缺陷跟踪系统知道自己负责的修正的缺陷问题报告。
(4) 缺陷问题的修正处理, 当程序员修复问题后, 可以通过跟踪系统, 通知项目经理问题已修复。
(5) 对于无法根据缺陷报告重现的问题, 也可以通过跟踪系统, 向项目经理及测试人员要求更多更详细的信息, 并将缺陷问题返回至项目经理重新处理。
(6) 问题暂缓及申诉过程处理, 对于缺陷报告提到的问题, 如在当前版本无法实现或者缺陷与需求有冲突的时候, 可以将问题置为“暂缓处理”或“提出申诉”。
(7) 对于优先等级较低的缺陷问题, 可能不能被及时处理掉, 但必须可以被查询。
(8) 缺陷跟踪系统可以提供跟踪项目的状态报告。
下面以使用软件测试工具Test Director为例, 分四个步骤来说明如何建立一个缺陷管理系统。
4.1 设计缺陷管理流程
通过使用测试工具, 在SDLC中未被发现的所有和项目有关的差异及问题都将汇报到管理工具中。Test Director针对不同的差异, 清晰的定义了NEW、OPEN、CLOSED等级别。当工具中开放了一个新的缺陷问题, 我们就要陆续开始登录缺陷报告、定义缺陷安全等级、描述缺陷、指派相关人员展开最初的调查、将差异转交给相关的测试主管等工作。
召开缺陷解决会议能确保所有缺陷都能涉及并得到有效解决。这种定期会议由来自开发、项目管理、产品管理、和项目相关的业务团队代表及测试主管共同参加, 就缺陷问题展开讨论。测试主管在会议期间对测试工具进行信息更新, 会议的中心议题是对缺陷报告进行审核。有了测试工具提升的完备的报告, 我们就可以依据其严重程度和状态情况, 选择处理的优先权。
缺陷解决会议后, 缺陷将被分配给合适的小组主管, 以便着手解决。这些小组包括:开发小组、环境支持小组, 或是业务团队。通过管理工具对任务进行合理分配, 能更为高效地解决缺陷问题。
被修复缺陷如果在环境缺陷中没有代码变更, 将马上展开重复测试, 并立即关闭。需要代码变更的缺陷修复会涵盖在一个版本打包中, 从而展开重复测试, 接着将根据测试结果或者关闭缺陷, 或者将缺陷重新开放。
4.2 定义缺陷状态
每个缺陷都有一个状态显示, 会在整个测试周期中得到随时地更新。每次当缺陷状态有了更新, 评论信息就会加入到缺陷的R&D评论栏中。测试工具中的缺陷状态一般会有以下几种:New、Open、Fixed、Ready for Retest、On Hold、Closed、Reopen等。
4.3 用户操作的状态修改
通过对测试工具所允许的状态变更操作, 可以为实现便捷的学习曲线和巩固一种优化的工作流程提供帮助。状态变更包括:根据适合的变更控制流程所进行的任何系统变更。在进行修复操作之后, 未通过测试或某个测试部分根据需要展开重复测试。在流程中的任何时段, 项目经理、系统分析人员、开发人员和测试工作人员可以使用测试工具来恢复保存在存储器中的所有缺陷状态等。
4.4 将新的流程配置到测试自动化工具中
最后, 当所有流程都得到了及时改进后。我们就把一个杂乱无序的流程打造成为一个有着杰出运作表现的项目, 具有完备的信息记录;可重复的流程;可衡量的成果;和一个改进程序。正确地运用软件去创建缺陷解决流程, 实现开发环节中使用的手动流程自动化, 以创建稳固的测试计划及测试组合。
Test Director通过一个独立的、基于Web的应用来支持整个测试流程, 包括需求管理;规划、创建、安排和执行测试;缺陷管理;项目状态分析等。同时, 它还可与行业中广泛使用的第三方应用相集成, 有效保护企业现有解决方案上的投资。有了可以在无人操作情况下自动地、24X7不间断运作的测试工具, 我们就能很好地达到提升IT系统质量, 增强系统效益的目标。
5. 结束语
对于如何建立和使用缺陷跟踪系统, 应该进一步反思, 毕竟缺陷跟踪系统只与缺陷有关, 与行政无关, 但实际情况往往不是如此, 缺陷跟踪系统成为了衡量项目参与者工作量的指标, 为参与的项目人员造成压力, 例如, 对于测试人员, 衡量他们工作量的是他们对项目提交的缺陷数量, 往往为了这个目的, 测试人员可能不断的提交缺陷, 甚至乎与其他人提交的缺陷相似, 这样一来就对程序员造成了压力, 容易使工作变得复杂。因此如何建立缺陷跟踪系统还需要在实际中进行进一步完善与讨论。
参考文献
[1]郑翠芳, 吴志杰.基于软件开发过程的软件缺陷管理研究[J].微计算机信息, 2007.03.
[2]胡冠林, 汪厚祥.软件缺陷分类及其度量技术研究[J].舰船电子工程, 2005.03.
软件缺陷管理方案分析 篇4
软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误, 或者隐藏的功能缺陷。软件缺陷管理是在软件生命周期中获取、管理、沟通任何变更请求的过程, 可以确保问题或缺陷被跟踪管理而不丢失。目前缺陷管理类的软件工具比较多, 主要功能比较一致, 但在一些细节, 如缺陷管理的流程, 与其它软件工程管理软件的集成, 甚至涉及到软件测试流程和软件质量管理的理念上, 都存在差异[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
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.
软件缺陷 篇6
印度软件业发展过程中存在的缺陷
1.软件产业极度依赖出口, 在迅速开拓国际市场的同时, 国内市场发展缓慢。根据印度全国软件服务协会 (NASSCOM) 的统计, 印度现阶段软件业出口额占软件产业总额的80%以上, 软件产业出口额占据全国出口总额的约20%, 可见出口对于印度软件产业甚至印度经济的重要性。印度软件业对出口和国际市场的极度依赖是由多方面的原因造成的, 也为印度软件业的长远发展埋下了很大的隐患。一方面, 印度软件业在国际市场上大行其道, 另一方面, 在印度的国内市场上, 软件业的产值很低, 为软件业的发展贡献的利润和市场份额都很有限。印度软件产业极度依赖国际市场的缺陷使得软件企业的发展对印度经济的贡献仅仅是数量上的, 而不是结构上的。软件产业作为一门现代化的科技产业, 其在印度的发展得到了政府部门的大力扶持, 因而其对印度经济和社会发展所起到的效应不仅仅应是增加出口额和外汇收入, 还应体现在推动整个印度国内经济和社会的发展上。
2.出口市场集中, 过度依赖美国和欧洲市场, 加大了市场风险。根据印度全国软件服务协会 (NASSCOM) 的统计, 美国市场占据了印度软件业出口份额的60%以上, 欧洲市场占据了印度软件业出口份额的30%以上。出口市场结构的单一加剧了软件业出口的市场风险, 也使得印度软件业的发展面临着极大的不稳定性和不确定性。2007年, 金融危机的爆发使得美国软件发包商大受打击, 美国市场对软件外包服务的需求因此直线下降, 沉重打击了印度的软件外包业。印度软件业三巨头英佛赛斯 (Infosys) 、维普罗 (Wipro) 和萨蒂扬 (Satyam) 在2007年的收入及净利润均大幅下降, 并拖累了整个印度经济, 印度孟买证券交易所Sensex指数在金融危机爆发后的一年内累计下跌了近50%。
3.印度软件业的发展实际上是对外大量输出劳务, 而不是发展具有核心竞争力的高科技信息技术, 这也是印度软件业发展过程中存在的最大缺陷。印度软件产业的主要盈利模式为软件外包, 其中相当大一部分产品或服务属于劳动密集型的低附加值产品。这些低附加值的软件产品通常都没有自己的品牌, 并且并不拥有产品的核心知识产权, 处在软件产业价值链的最低端。据相关统计, 目前印度软件产业低附加值产品占据了印度软件产业产品的90%以上。核心知识产权的缺乏必将使得印度软件业缺乏核心竞争力, 无法获得持续、稳定、高效的长远发展。
另外, 创新不足也严重制约了印度软件产业的进步与升级。目前, 印度整个软件产业的发展缺乏一套有效的创新机制, 政府采取了诸多措施鼓励和扶持软件业的创新, 但效果都不甚明显。虽然在印度软件业的心脏地带班加罗尔有许多的软件研发机构, 但大多数都是由跨国公司设立的, 所创造出来的知识产权自然也属于跨国公司, 而不是印度软件产业自身的创新。
印度软件业的缺陷对我国软件业发展的启示
1.国内市场和国际市场并举, 在发展国内市场的同时, 大力开拓国际市场, 同时加强创新体系的建设, 在软件产业发展的问题上不能急功近利, 要脚踏实地的走出一条开放创新与自力更生相结合的拥有自主核心知识产权的高效发展道路。我国软件业发展的国情明显不同于印度, 软件业发展的国内环境比印度优越很多。印度软件业国内市场的萎靡在很大程度上是由于其国内的经济较为落后, 尤其是电子信息硬件制造业的落后, 使得其本国市场对软件产品的需求较低, 制约了国内软件市场的开拓。我国则明显不同。近年来我国经济持续高速发展, 各行各业对软件产品的需求急剧增加, 可以说软件产业在我国国内的发展前景一片大好;另外, 我国号称“世界工厂”, 国内的电子信息硬件制造业也较为发达, 为软件产业的发展打下了坚实的根基, 提供了良好的发展环境。
在当前环境下, 应充分发挥政府政策的导向性作用, 利用我国国内市场硬件产业基础雄厚的优势, 出台相应的扶持和鼓励政策, 对软件企业提供财政、税收和行政方面的优惠和便利, 鼓励软件企业进行技术创新并积极开拓国际市场, 同时积极建设软件科技园区和出口基地, 增强我国软件出口企业的国际竞争力, 力求扩大我国国内软件产业的规模, 培育出类似印度的英佛赛斯 (Infosys) 和维普罗 (Wipro) 之类的软件龙头企业, 并以软件龙头企业为核心, 积极吸纳和借鉴世界软件产业先进的技术和经验, 以提升我国软件企业的核心竞争力和我国软件业的综合素质。
软件开发的缺陷预防手段 篇7
每个产品都会有缺陷,在软件开发过程中应争取尽早发现缺陷,开发的时候提高软件质量要远比开发完成后再进行测试更为有效。一般对软件开发主要控制缺陷手段是进行测试和检查,在一定程度上可以确保不让不合格产品交付到用户手里,然而能够保证最初制造的产品就是一个合格产品吗?能将质量测试融入产品中去吗?实现起来比较困难,而且只能在开发的结束才能进行测试。其实这不仅是改进软件流程所独有的现象,也是目前软件开发共同面临的问题。要想得到高质量软件,重要的是将质量设计到软件中。这比如何设置质量保证部门、向谁报告、独立测试、需要进行什么样的评审等事情重要得多。要想在软件开发的每个阶段都注重质量需要有一个流程进行管理,大多数软件流程改进模型(像CMM和ISO 9000)都认为有效和正确的流程必然会导致生产出高质量软件。我们有理由相信有效的流程肯定能制作出一开始就能正常工作的高质量软件。下面先介绍缺陷管理的基本原理,然后讨论软件在产品开发周期中的验证和确认,特别是所采用的评审、检查和测试技术。
2 缺陷管理
软件中一般会有问题和缺陷,其实这都是一些由开发人员造成的软件错误,这些缺陷实际上在开发过程从提出要求到进行维护的任一阶段都可能造成。假如适当条件永远不发生而没有触发执行有问题代码的话,缺陷就将隐藏下去,否则它们会暴露出来而造成失效。失效的严重程度不尽相同,最坏情况下失效可使系统崩溃或者系统功能不正常,而轻微时失效仅仅使用户感到不方便或不满意而已(如响应时间太慢或者接口使用困难等)。
当然还是应该尽量避免缺陷,关于缺陷管理有两个指导性原则。首先,在最初阶段就要避免造成缺陷,可以通过在产品开发周期每个步骤都使用正确技术做到这一点。第二个原则就是在流程中尽可能早地检测出缺陷,一旦检测到就要从源头处把它消除掉。这就是说如果缺陷是在低层设计中造成的,就应在此时把它消除,最好在编码开始前。
时间拖得越久,消除和修复缺陷的费用就越高。研究指出,缺陷在产品开发周期晚期发现其消除的费用将会急剧上升。为避免缺陷,需要针对软件开发每一阶段的特殊技术进行培训。
通过评审检查的验证和确认活动,是缺陷形成后尽早检测出来并从源头处把它消灭掉,这样做不仅去除缺陷的费用更少,而且使我们相信质量已被制造在产品中,而不是直到装运前才将高质量产品筛选出来。通过评审就是在每一阶段对软件进行评估,以保证它符合前一阶段所提出的要求;同时,通过在开发工作完成时对软件及其技术指标规范进行测试,以保证软件符合总体要求。
3 评审和检查
有人说技术工作需要进行评审就如同铅笔需要橡皮擦一样,因为人总是要犯错误的。在开发过程的各个阶段进行评审,如果软件开发时没有定出精确要求,则根本不可能通过评审或其它方法验证设计是否准确,因为此时设计不是根据要求做出而是孤立的,任何对缺陷的判定最终都是个人观点。因此评审和检查首先假设软件开发过程已有严格的要求。评审每个开发阶段的中间产品有两个基本作用。首先,我们能在早期检查出缺陷并在修改费用较低时将其消除掉;其次,这一点可能更重要,我们能够在公司内部改变流程,在软件开发最初阶段就提出大量的严格要求。如果管理层在评审上投机取巧,则到时候可以清楚地看到没有好的要求(或者好的设计)评审就不会带来什么价值。
评审可作为质量过滤的一种形式用于软件开发各阶段,其目的是尽早发现错误以使产品更加完善。评审结果是:指出产品中需要改进之处;确认好的部分;使产品在编码方式、文件样式、设计方法等方面更加一致,以便技术工作能更好地进行管理;改进软件开发过程。
进行评审,确保四方面的特性。完整性,下一阶段产品与其前期设计的产品是完备的整体,没有待定项、遗漏功能。一致性,符合产品的要求。可行性,产品能完成。易测性,产品做指定测试的能力,该测试必须是具体的、明确的和可以量化的。
评审会议的组织,人员应限于3～7人,会议中,明确分工,经过培训。为使会议有效,事前做准备,时间一般不超过两个小时;评审的是产品而不是它的设计者,要客观地讨论产品而不涉及与之相关的人要限制争论和辩解。搞清问题所在但不要试图去解决任何事情会议的焦点是发现而不是解决,正式评审中小组的目的不是进行共同设计。会议应沿着发现问题的思路进行。指定记录员。
评审检查是很经济的,通过检查能在修复费用相对较低的早期阶段发现缺陷。此外当要求作必要的修改时,对多层次设计文件、产品代码及产品文件进行改动会出现脉动效应,而检查能防止这类效应,评审的另一个关键是它设计为检测缺陷而不是检测失效。最后,因为每一个中间产品必须要能追溯至前一级中间产品,所以评审必然会改善整个流程,而要求的准备和设计工作都做得很差的小组几乎就拿不出合适的东西进行评审。
4 软件测试
虽然正式评审和检查占用了我们大量的精力,测试仍然是缺陷控制和检查中很有用且很重要的一个部分。测试时我们在受控状态下运行软件以检测缺陷,如同我们在提要求、设计和编码等各阶段进行评审和检查一样,我们在软件制作的任何适当的地方进行测试。下面将简单介绍单元测试、集成测试、系统测试和回归测试。
4.1 单元测试
单元测试的任务是在一个受控环境中执行一个特定模块。它一般包括某种形式的构架,通常为短线程和驱动器。一般用来验证模块的功能属性,但也可以测试其它项目,如性能、可用性等等,可使用“黑盒”或“白盒”方法进行。
4.2 集成测试
当各模块己经过单独的单元测试后,我们就将它们组合到一起,看与其它模块集成在一起时的整体功能。模块可按多种途径集成,包括从上向下和从下向上。实际上任何方法都可以使用,只要测试人员能了解特定模块组合所表示的行为,组合从最前面两个模块开始,到加入最后一个模块结束,形成一个完整的系统。理想状况下,集成测试应每加入一个模块进行一次。集成测试一般也看作验证的一种形式,因为组合模块的行为是一个功能规范的产品。
4.3 系统测试
系统测试是指对整个系统或产品进行测试,看它是否符合总体系统要求。系统测试人员相当于用户代言人,因为测试指导文件应该或者是用户提出的需求,或者是直接基于这一要求的技术规范。系统测试能发现任何质量问题,包括功能、性能、可靠性和可用性,还有特定项目的其他方面要求。
4.4 回归测试
回归测试就是漏洞修复完成后再对软件进行测试,以确保软件没有产生“回归”或因修复而变得更糟,这种测试一般要重新运行最初发现问题的原始测试程序。
测试是一个专业,要用专门的一套技术来进行关键的工作。好的测试是从一开始就参加软件开发,可为产品开发阶段带来一种质量的观念。尽量使产品暴露出问题才是公司和用户的最大利益所在,应当注意的是测试的技能与开发并不相同。常常和测试联系在一起的用户和开发人员,但用这两类人作测试都存在一些问题。开发人员的工作是构建,他制造产品;而测试人员的任务则是找出缺陷,每个工作都要求特定的个性,在两者之间随意变动不是小事。更重要的是,让开发人员去测试自已的代码,当处理代码的薄弱部位时,会不自觉地退缩,不是很好地了解问题而是绕开软件中有问题的部分,他们没有足够的勇气对自己动手术。由用户来进行测试,虽然在可用性方面能提供大量反馈。用户在测试时通常重复,不够系统,另外缺乏想象力。对新软件缺乏信心,速度也比较慢。
5 结束语
许多公司对独立测试或功能验证相当满意。但这些公司的测试一般是在流程结束时才会进行,以确定产品达到必要的质量水平。本文重点是评审和检查,尽管这两种技术提供了一个更可靠的机制,可以随着开发阶段的进行将质量制造在产品中,但它们在软件公司中使用得并不普遍。用很少人对产品进行直观检查在很多方面会相当费力,但其潜在的好处是巨大的。每个产品都有缺陷,这是无法改变的,但产品中的缺陷迟早都是会发现的。最坏的情况是在应用现场发现,最好则是尽可能早地在软件开发过程中发现缺陷。一个很充分的理由就是应该制造缺陷更少的产品,并且这些剩下的缺陷其严重程度应能被用户所接受。
摘要：软件开发由于是人为的设计和开发过程,发生缺陷很难避免,传统软件工程做法是通过软件测试,控制软件存在的缺陷。在本文中我们讨论通过实施有效的评审和检查以及软件测试活动,控制软件交付后,存在较少缺陷。
关键词：缺陷,评审,检查,软件测试
参考文献
[1](印)PANKAJ JALOTE,译者:胡春哲张洁等,CMM实践应用-Infosys公司的软件项目执行过程[M].北京:电子工业出版社,2002.
软件缺陷管理系统的设计与实现 篇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.