软件缺陷分析

软件缺陷分析（精选12篇）

软件缺陷分析 篇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

软件问题报告包括头信息、简述、操作步骤和注释。

头信息包括：测试软件名称、版本号、缺陷或错误类型、可重复性、测试平台、平台语言、缺陷或错误 范围。要求填写完整、准确。

简述是对缺陷或错误特征的简单描述，可以使用短语或短句，要求简练、准确。

操作步骤是描述该缺陷或错误出现的操作顺序，要求完整、简洁、准确。对命令、系统变量、选项要用大写字母，对控件名称等加双引号。

注释一般是对缺陷或错误的附加描述，一般包括缺陷或错误现象的图像，包括其他建议或注释文字。

书写专业软件问题报告的技巧

书写软件问题报告的目的是为了正确地重复缺陷或错误，从而在后续工作中可以准确验证并加以处理。因此，基本要求是准确、简洁、完整、规范。为了正确书写专业的软件问题报告，应该注意以下要点：

每个软件问题报告只书写一个缺陷或错误

这样可以每次只处理一个确定的错误，定位明确，提高效率，也便于修复错误后方便的进行验证。

对错误的描述要做到简洁、准确、完整，揭示错误实质

描述要准确反映缺陷或错误的本质内容，简短明了。为了便于在答数据库中寻找，包含错误发生时的用户界面是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

明确指明错误类型和严重程度

根据错误的现象，总结判断错误的类型和严重程度，例如，是功能错误？还是界面布局错误？该错误是属于特别严重的错误还是一般错误？是否影响软件的后续开发和发布？

每一个步骤尽量只记录一个操作

简洁、条理井然，容易重复操作步骤，以便确认、修复、验证该错误.复现的操作步骤要完整，准确，简短

保证快速准确的重复错误，完整即没有缺漏，准确即步骤正确，简短即没有多余的步骤。附加必要的错误特征图像

为了直观的观察缺陷或错误现象，通常需要附加错误出现的界面，作为附件附着在记录的附件部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。

附加必要的测试用例

如果打开某个特殊的测试用例而产生的错误，则必须附加该测试用例，从而可以迅速再现缺陷或错误。为了使错误修正者进一步明确缺陷或错误的表现，可以附加修改建议或注解。

尽量使用短语和短句，避免复杂句型句式

混凝土缺陷原因分析 篇3

１．露筋

露筋是指钢筋混凝土结构内部的主筋、架立筋、分布筋、箍筋等没有被混凝土包裹而外露的缺陷。在混凝土梁和柱的结构上，任何一根主筋的单处露筋长度不大于10cm，累计不大于20cm的，可以进行修复，但梁端主筋锚固区不允许有露筋。露筋缺陷超过上述范围时，应做结构检测和结构鉴定。

原因分析:

下述原因分析，不仅仅是某一个原因的单独作用，往往是两种或多种原因共同作用的结果。

（1）钢筋骨架放偏，没有钢筋垫块或垫块数量放置不够，位置不正确，致使钢筋紧贴模板而外露。

（2）粗骨料粒径大于钢筋间距，或者杂物在钢筋骨架中被搁住，又混凝土漏振，形成严重蜂窝和孔洞。

（3）混凝土泵管、振动棒等机械的反复冲击、工人踩踏或振动器碰触钢筋，引起钢筋变形位移而外露。

2.峰窝（含麻面）

混凝土拆模之后，表面局部漏浆、粗糙、存在许多小凹坑的现象，称之为麻面；若麻面现象严重，混凝土局部酥松、砂浆少、大小石子分层堆积，石子之间出现状如蜜峰窝的窟窿，称之为蜂窝缺陷。

从工程实践中总结出麻面蜂窝与混凝土强度的下降级别如下：

A级，混凝土表面有轻微麻面，浇注层间存在少量间断空隙，此时相当于强度比率为80%；

B级，混凝土表面有粗骨料，凸凹不平，粗骨料之间存在空隙，但内部没有大的空隙，此时相当于强度比率为60%～80%；C级，混凝土内部有很多空隙，粗骨料多外露，粗骨料周围及粗骨之间灰浆黏结很少，有少量钢筋直接与大气接触，此时相当于强度比率在30%以下。

原因分析:

（1）模板安装不密实，局部漏浆严重。或模板表现不光滑、漏刷隔离剂、未浇水湿润而引起模板吸水、黏结砂浆等。

（2）混凝土拌合物配合比设计不当。

（3）新拌混凝土和易性差，严重离析，砂浆石子分离，或新拌混凝土流动度太小，粗骨料太大，配筋间距过密，加之又漏振、振捣不实、振捣时间不够等。

（4）混凝土下料不当（未分层下料、分层振捣）或下料过高，未设串筒。

（5）输送到施工层面的砼料偏干时，工人直接向砼料随意大量冲水，将砂石洗得干干净净，水泥浆大量流走。

3.孔洞

混凝土梁或柱上的孔洞面積，单处不大于40cm2，累计不大于80cm2，可以进行修补。混凝土基础、墙、板的面积较大，但任何一处孔洞面积不得大于100cm2，累计不大于200cm2时同样可以采取修补的方法将混凝土修补整齐。超过上述范围的孔洞，应做结构检测和结构鉴定。

原因分析:

（1）在钢筋较密的部位或预留孔洞和预埋件处，混凝土下料被搁住，未振捣就继续浇注上层混凝土。

（2）混凝土离析，砂浆分离，石子成堆，严重跑浆，又未进行振捣，或者竖向结构干硬性混凝土一次下料过多、过厚，下料过高，振捣器振动不到，形成松散孔洞。

（3）薄壁结构及钢筋密集部位的混凝土内掉入工具、模板、木方等杂物，混凝土被搁住。

4.夹渣

混凝土内部夹有杂物且深度超过保护层厚度，称之为夹渣。杂物的来源有两种情况，一是原材料中的杂物，另一个是施工现场遗留下来的杂物。

原因分析:

（1）砂、石等原材料中局部含有较多的泥团泥块、砖头、塑料、木块、树根、棉纱、小动物尸体等杂物，并未及时清除。

（2）模板安装完毕后，现场遗留大量的垃圾杂物如锯末、木屑、小木方木块等，工人用水冲洗时不仔细，大量的垃圾杂物聚积在梁底、柱头、柱跟、梯板脚及变截面等部位，最后未及时清理。

（3）现场工人掉落工具、火机、烟盒、水杯和矿泉水瓶等杂物及丢弃的小模板等卡在钢筋中未作处理。

5.疏松

前述的蜂窝麻面、孔洞、夹渣等质量缺陷都同时不同程度地存在疏松现象，而单独存在的疏松现象，砼外观颜色、光泽度、粘结性能甚至凝结时间等均与正常混凝土差异明显，混凝土结构内部不密实，强度很低，危害性极大。

原因分析：

（1）混凝土漏振。

（2）水泥强度很低而又计量不准，或商品混凝土站因设备故障造成矿物掺合料掺量达到65%以上，此时混凝土砂浆粘结性能极差，强度很低。

（3）严寒天气，新浇混凝土未做保温措施，造成混凝土早期冻害，出现松散，强度极低。

（4）实际工作中，可能出现泵送混凝土浇筑时，不预拌润泵砂浆，现场工人图省事，直接向泵机料斗内铲两斗车砂子和一包水泥，加水后未充分搅拌就开启泵机。或在浇注面上未将润泵砂浆分散铲开而堆积在一处，拆模后构件表面起皮掉落，内部疏松。

预防措施：

（1）严格操作规程，加强振捣，避免漏振。

（2）使用优质水泥，严格砂石等原材料进场验收，经常检查计量设备，严格控制水灰比，商品混凝土站防止将矿物掺合料注入水泥储罐内。

（3）防止严寒天气混凝土早期冻害，加强保温保湿养护。

（4）严格润泵砂浆配合比，润泵砂浆应用模板接住，然后铲向各个柱头或柱根。

6.裂缝

混凝土出现表面裂缝或贯通性裂缝，影响结构性能和使用功能。实际中所有混凝土结构不同程度地存在各种裂缝，混凝土原生的微细裂纹有时是允许存在的，对结构和使用影响不大。但是必须防治产生宽度大于0.5mm的表面裂缝和大于0.3mm贯通性裂缝（一般环境下的工业与民用建筑）。以下说明工程结构中常见的各种类型的裂缝的处理方式。

原因分析：

（1）早期塑性收缩裂缝：混凝土在终凝前后由于早期养护不当，水分大量蒸发而产生的表面裂缝，裂缝上宽下窄，纵横交错，一般短而弯曲。

（2）干缩裂缝：混凝土由于阳光高温暴晒又缺少水养护，发生干燥而在1～7天内出现的裂缝，板面板底干缩裂缝长而稍直，十字形交叉或机根裂缝放射状交叉。梁侧干缩裂缝间距1～1.5m平行出现，裂缝中部宽而深，两头细而浅，此时一般梁底部并无裂缝出现。

（3）温度裂缝：一般是大体积混凝土快速降温而在侧面出现的长而直、宽而深的裂缝。

（4）自收缩裂缝：水泥发生化学反应后，体积有一定量的减小，处理不好（如未留置适当的施工缝、后浇带等）会产生如龟背样的细小弯曲的裂缝。

（5）应力裂缝：由于设计上应力过于集中或钢筋（温度筋、分布筋）分布不合理而使混凝土产生裂缝。裂缝深而宽，可出现贯通性。

（6）载荷裂缝：混凝土未产生足够强度即拆除底模，或新浇注楼面承受过大的集中载荷，如钢管、模板、钢筋的集中堆放，使混凝土受到冲击、震动、扰动等破坏而产生的裂缝。裂缝深而宽，从受破坏部位向外延伸。

（7）沉缩裂缝：地基（模板）下沉或垂直距离较大的部位与水平结构之间因为混凝土沉降而产生的裂缝。

（8）冷缝裂缝：大面积混凝土分区分片浇注（未设施工缝）时，接茬部位老混凝土已凝结硬化，出现冷缝，极易产生裂缝。

软件缺陷预测技术分析 篇4

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.

SWOT分析的缺陷 篇5

从战略管理教学的角度看，许多战略管理教科书仍然使用SWOT分析作为全书的布局，人们对SWOT分析耳熟能详，凡案例分析大多必用之。在企业管理咨询领域，有众多战略咨询报告以以此为分析工具。那么SWOT分析是不是一个完善的分析工具?它存在哪些问题和缺陷?

SWOT分析最早由Learned等人于1965年提出，在战略管理领域中被广泛运用。对企业内部分析而言，从最初简单的检核表(check list)，到特异能耐(distinctive competence)、价值链及核心能力等概念的提出可以都看作是对优势的发展，对企业的外部分析，除了PEST分析，Porter的竞争战略理论对企业外部环境的分析，以产业为对象进一步细化，这些无疑都对战略管理理论和实践的发展产生了重要影响。

SWOT的隐含假定

战略决策需要信息，SWOT分析对战略决策需要的信息做了两个区分：内外区分，即关于企业自身的信息和关于企业所处环境的信息；利害区分，即对企业有利的企业内部优势(S)、外部机会(O)和对企业有害的内部劣势(W)和外部威胁(T).毫无疑问，这种分类大大明晰和简化了企业制定战略时需要掌握的信息，然而这也是招致了SWOT缺陷的隐含假定——内外区分的假定。

在SWOT分析中通常认为，机会和威胁只存在于外部环境中，优势与劣势只存在于内部境中，然而事实上优势和劣势可能出现在企业外部，机会和威胁也可能出现在企业内部。

Penrose指出，企业的发展机会往往存在于企业内部，企业内部剩余的生产性资源是企业得以成长的重要机会。更为重要的是很多时候企业内外难以分割，Chamberlain认为企业的能力嵌套在相互依赖的网络中，这个网络中的相互依赖既存在于企业内部，也体现在企业与环境之间。

Barney认为环境分析通常不能得到超额收益，如果因此而得到超额收益，也是运气，因为环境分析的方法和信息是公开的，任何企业都可以得到，只有分析企业执行产品市场战略的独特资产，例如专有技术，才可能获得超额收益。

Barney的分析仍然是内外分割，即使是分析环境，也要受企业内部因素的影响，组织资产的价值只有在＿定的环境中才能彰显其价值，内外整合的分析才可以展现更完整的战略图景。如果在SWOT分析中泛泛和割裂地列举企业内部优势和劣势以及外部环境的机会和威胁，继而建立某种内外关势和劣势所采用的标准，往往依据业务的营运需要和组织特征的历史表现。

威胁和机会可以针对同一事件，因为企业如果把握或处理的好，就有机会独占鳌头，反之则有可能﹁蹶不振，这种情况可以成为危机。例如中国加入世贸，对很多中国企业就是如此。

因此，SWOT的优势与劣势区分割裂了企业内部情况的连续统一，而机会与威胁的区分不能反映同一事件的利害联，并籍此形成企业的战略，显然是危险的，而且在实践中已经证明是难以操作的。企业的外部变化导致企业优势的改变，这也从另一个方面表明企业内外联系的紧密性。换句话说，内外环境的分割只是分析的便利，而不是企业的实际。

利害区分的假定

对优势和劣势的判断其实是一个复杂的测量问题。从测量的角度看，对企业内外条件的测量往往会表现为一个连续体，优势和劣势的相对性和程度性要求使用SWOT分析采用合适的测量标准，这比泾渭分明的优劣区分对企业实际有着更加客观的把握。然而，对优势和劣势、机会和威胁都缺乏明晰的测量标准。例如，优势是与企业自身历史、预先计划、竞争对手比较有优势，还是与顾客需求的情况比较有优势?

Stevenson的研究表明，对优势和劣势的评价标准有历史的、竞争的和计划的三个标准，企业更多地是采用历史和竞争标准来测量自己的优势，而对劣势常常采用计划标准。虽然企业采用的评价步骤类似，但是并没有统一的标准，评价优两面性。

静态分析的假定

SWOT分析通常是在某一时点对企业内外进行扫描，然后进行优势、劣势、威胁和机会的分析，从而形成四种内外匹配的战略，即 SO战略：依靠内部优势，利用外部机会；ST战略：利用内部优势，回避外部威胁；WO战略：利用外部机会，克服内部弱点；WT战略：减少内部弱点，回避外部威胁。尽管有些学者对每项匹配的具体解释会有所不同，但是在当下对企业的优势、劣势、机会和威胁的静态分析，很难确保还没有实际发生的内外匹配一定会实现，例如，企业的优势是否强到足以把握机会、对抗威胁，企业的劣势是否弱到错失良机、不堪威胁。

例如，SO战略包括的两种战略规划过程，即以产业威胁和机会为分析起点的外部导向战略规划过程(五力分析→产业定位→价值活动→驱动因子)和以内部资源和能力为起点的内部导向战略规划过程(识别资源和能力→评价资源和能力→利用资源和能力→填补资源差距)，在企业外部环境稳定时期，对企业的战略制定有一定的指导作用，但是在企业外部环境动荡时期：产业结构模糊，企业的资源和能力不再有效，SWOT的静态分析和内外匹配很难有实际的意义。

换句话说，SWOT分析对制定涉及产业演化和能力演化的跨期发展战略帮助不多。SWOT分析隐含着对人理性能力的自信，机械的内外匹配战略忽略了内外匹配往往是一个试错和学习的过程。

综上所述，SWOT分析所隐含的假定可以说既具有简化和分类信息的优势，也具有其不能综合把握信息的劣势，对运用SWOT者可以说存在潜在的威胁，然而，近些年的战略管理研究提供了丰富我们对SWOT分析认识的机会。

SWOT的构成要素

近二十多年的战略管理探索可以看作是对SWOT分析的深化，对企业内部的研究，以资源基础观点为主要代表；对企业外部的研究，最具代表性的是波特的竞争战略理论。这里以资源基础观点为主，结合竞争战略理论，对 SWOT分析的区分要素进行分析。作为有一定特征的优势单纯地讨论优势没有任何意义，优势隐含着比较的含义，通常是和竞争对手比才能彰显出优势，这也是特异能力提出的基础，即特异能力是企业做得比竞争对手特别好能力，在价值链的不同环节上，企业各自从事自己擅长的活动。然而问题是为什么有些企业不可以做得和另一些企业一样好?

战略理论的回答是因为另一些企业拥有核心能力，核心能力不仅使企业做得好，而且是竞争对手难以模仿和复制的，相当数量的文献对企业拥有的资源和能力的特征进行了探讨，例如 Peteraf指出的能带给企业竞争优势的资源必须是异质的、对资源积累前后的相关竞争是有限制的，资源是难以转移的。有的学者则认为带给企业竞争优势的资源和能力是有价值的、稀有的、难以模仿和替代的。

资源基础观点是由外部导向的竞争战略理论向内部导向的古典战略理论的回归，从生产资料市场的层面给出了竞争优势更令人信服的解释，波特的产品市场超额收益的竞争优势定义，从资源基础观点看只是结果，而非原因。毫无疑问，资源基础观点丰富了我们对优势的理解。

基于优势的机会SWOT分析中的机会主要是围绕产品和市场中，可以使业务增长的一些情况，例如开发新市场、引入新产品和进行多角化。Porter按照行业对机会做了进一步的分析，例如在零散行业中有联合的机会，在新兴行业中有掌握先动优势的机会；在行业中还可以移动性壁垒为基础，进一步分析战略群组的机会。

然而，资源基础观点的企业异质性表明，不同的企业可能面临不同的机会，即拥有不同资源和能力的企业更是可以选择不同的机会；既然有一定特征的资源和能力给企业带来竞争优势，那么可以获得企业所需的资源和能力也是一种重要的机会，尽管带给企业竞争优势的资源和那里常常是积累所得。这一点在战略联盟的文献中也有研究，即战略联盟是企业获取资源和能力的重要机会，例如青岛啤酒和美国A—B公司结盟，提升了青岛啤酒在控制啤酒口味一致性上的能力。

曾经是优势和危及优势的威胁 企业的核心能力不能满足环境的要求时，企业的核心能力往往表现为核心刚性。Barton认为核心刚性是不合时宜的知识集，表现为公司中过去运转良好的价值观、技能、经营系统和技术系统，或许只能在整体上适用现在的某些项目或某些项目的—些部分。例如在发达国家钢铁行业中，大型钢铁厂及其技术风光一时，然而，随着外部需求的降低及新技术的出现，大型的一体化钢铁生产者常常陷入经营上的困境。

Porter的竞争战略理论揭示了对企业利润产生威胁的五种力量，然而由对企业优势的讨论可以得知，产品市场的优势是因为要素市场的不完全所致，所以对企业造成更大危害的是在要素层次上对企业的资源和能力造成破坏。

战略学者研究了技术变迁等外部因素对企业资源能力的影响，其中能力摧毁型(competence—destroying)、颠覆性(disruptive)和整体(architectural)技术变革对企业的资源和能力的威胁很大。能力摧毁型技术变革是指一种技术对另一种技术的替代；颠覆性技术变革是指技术领先的企业可能被技术一般的低成本企业挫败；整体性技术变革涉及局部技术进步和系统的优化。因此，这里可以看出，对企业优势的静态分析难于指导企业的跨期发展，今日的优势往往因为技术变革的威胁成为企业明日的劣势。

以上论述是资源基础观点之下的SWOT分析，对优势、劣势、威胁和机会都不再停留在产品市场层次，而是在探究企业产品背后的东西，即企业的资源和能力，从而我们可以更清晰的看出优势、劣势、威胁和机会的相互联系，而不是彼此分割的进行分析。

认知对SWOT分析的影响

SWOT分析往往作为战略规划的第一步被广泛的使用，然而利用SWOT分析常常产生难以操作的战略选择，因此招致了广泛的批评，这与组织制定战略规划过程中的认知有关。Stevenson研究发现：一个人对其组织优势和劣势的认知，受到其个人而非组织特征的强烈影响，例如在组织中的地位，包括职位的高低、责任的类型、职业背景及工龄等，这些都在很大程度上影响了管理人员对企业当前客观现实状况的评价。职位的高低也影响经理对所需评价组织特征的选择，例如高层经理通常侧重于组织方面，而低层经理更看重财务方面；管理层很少能对公司的优势和劣势精确地达成一致意见，许多的组织特征既是优势也是劣势。识别企业的优势和劣势也受到一些其它因素的影响，例如，情景分析、自我保护和维持现状的需要，以及

定义与计算优势和劣势的能力。

Mintzberg对以SWOT分析为核心的设计学派提出质疑和批评，他认为企业很难事前知道已经建立的能力将会是优势或劣势，优势往往被证明更窄，而劣势更宽。管理层的感觉常常表现出自我服务(self-serving)的归因模式，Wagner和Gooding的研究结果表明，在处理有关组织绩效的因果两面性信息时，经理们往往将正面的结果归因于组织的优势，而将负面的结果归因于环境的威胁；而在评价其它的组织时，情况则反

之。

Glynn对组织核心能力的非人格化(1mpersonal)做出批评，通过研究发现，组织内群体对组织认同1的定义，会影响对核心能力的感知。例如 Selznick以一个优秀的造艇厂为例做出说明：该公司对高品质工艺技术非常内行，公司管理层决定扩展低成本快艇业务并大量投产，但是很难改变工人的态度，使他们远离对质量和工艺技术的历史信奉，管理层被迫重新安排快艇生产，并招募一些独立的劳动力，由于组织历史和文化不适应其新任务，这项新的业务失败了。因此，这里员工的认知会限制企业的特异能力(优势)的适

用范围，相应地也影响企业战略实施的成功。

如果说战略规划者的认知偏差会影响战略规划的制定，那么实施者的认知会影响战略规划的实施。因此，战略规划过程应该考虑如何组织战略规划活动，有效的处理规划过程中的不同认识，并且要考虑战略实施

者的认知可能产生的影响。

结 语

优势和劣势总是相对于要做的事而言的，不涉及具体需要解决的问题，优势和劣势往往难以定义，机会与威胁也总是相对于优势与劣势而言的，而企业如果厘清了战略目标，优势与劣势和威胁与机会似乎又趋于明朗化。Lenz(1980)提出战略能力(strategic capability)的概念，描述了战略能力的三个维度，即创造价值的知识和技术基础、一般管理技术、生成及获得资源的能力。用可能妨碍实现战略目标的壁垒作为评价战略能力的标准，从而使战略能力的分析框架很大程度上规避了SWOT的内外和利害区分假定，如果阻挠战略执行的壁垒在未来具有重大意义，那么企业因此而形成的战略就具有动态含义。当然，企业制定战略

规划还要考虑战略规划者和实施者的认知。

SWOT盘踞我们的大脑已久，去之如抽丝。如果沿用SWOT分析框架，那么依据其提出问题，仍可引发我们一定的战略思考。然而，如何更好的超脱SWOT的三项假定，代之一种内外整合、综合分析、动态学习的简

活套安装方式缺陷分析及改进 篇6

关键词：活套 缺陷 分析 改进

0 引言

活套是连轧生产中不可或缺的设备之一，它的作用主要是调整堆拉关系，消除大头大尾现象，对钢材的顺利轧制和质量产生重要作用。

活套按照安装方式分为立活套和平活套，按照动力方式分为电动活套、气动活套和液压活套。

龙钢西轧厂精轧部分有四台活套，均为立式气动活套。

本文通过对活套气缸和起套辊的安装方式进行分析，指出了气缸和起套辊更换困难的原因，提出了改进方法，取得了很好效果。

1 立式气动活套结构原理

龙钢西轧厂立式气动活套由气缸、气缸底座、起套辊和其它气动元件组成（图1）。气缸型号为JB100*200MT4，气缸安装在底座上，通过电磁阀的换向，气缸带动起套辊做上下运动，起套辊在导向槽内滑动。

气缸的底座安装在跑槽支腿上，跑槽支腿由槽钢制作，在槽钢的侧面焊接底板，底板上加工四个螺纹孔。气缸底座为左右对称的两部分，安装在气缸耳轴上后，用螺栓把底座固定在底板上。

起套辊是自由辊，被安装在气缸上部U形支座内，用压板压紧辊轴，并用止动夹板防止辊轴转动和轴向移动。

2 活套设计缺陷分析

2.1 活套气缸更换困难及原因分析

在活套的使用过程中，发现气缸损坏后，更换比较费时费力，用时30分钟以上，甚至达到45分钟。

结构比较简单的活套，更换气缸的过程竟然会耗时30分钟以上，促使西轧厂对其中原因进行分析。除了维修人员素质因素外，主要原因是气缸底座螺栓拆卸比较困难。由于活套工作环境恶劣，不仅轧机喷淋水会溅落到气缸底座上，而且氧化铁皮、高温环境等都会使螺栓及螺纹孔很快生锈，造成螺栓拆卸困难。同时，由于气缸底座安装空间狭小，工具回转不开，使维修人员难以较快完成工作。

2.2 起套辊更换困难及原因分析

起套辊的更换相对简单一些，只需去掉连接在气缸和起套辊支座之间的销轴即可，但是也需要至少两人协作，用时10多分钟。主要原因是去掉销轴后，整个起套辊会掉落下来，同时，去掉销轴的时候要对销轴进行敲击，会对气缸造成一定的影响，因此敲击时不能用力过大。

同时更换下来的起套辊维修时较为麻烦。需要拆掉生锈的螺栓，然后维修轴承和辊子。

3 活套设计改进

3.1 活套气缸安装方式改进

通过分析活套气缸更换困难原因，西轧厂提出了改进措施（图2）。由于气缸在工作时，只承受轴向载荷，不承受径向载荷，所以对支座上的耳轴孔进行改进，把原设计中的圆孔改为U形槽，并在底座上加工通孔，插入圆柱销对气缸耳轴进行定位。更换气缸时，只需去掉两个圆柱销即可取出气缸。同时，把滑道下端封闭起来，去掉气缸时，起套辊不会掉落下来。对气缸气管接头进行改进，把原内接头改为快换接头，使更换气缸时更为便捷。

图1 图2

3.2 起套辊安装方式改进

原设计中更换起套辊时需要连同支座一起更换，而支座在使用的过程中不易损坏，因此绝大多数情况下不需要更换维修，所以西轧厂对起套辊进行分体设计，去掉原支座上的两块压板，把支座两边加高，中间加工出U形槽。

由于活套在下落的过程中，轧件会下压起套辊，因此起套辊不会从U形槽内脱出。起套辊损坏后，只需从U型槽内取出起套辊，安装新的起套辊即可。

更换下的起套辊维修工作量也大为减轻。

4 结语

经过改进后，更换活套气缸时间由原来的至少两人操作30分钟以上，减少为一人3分钟就能完成，节约生产时间27分钟。更换起套辊时间由原来的两人配合协作10分钟，减少为一人操作0.5分钟，节约时间9.5分钟。

虽然活套改进产生经济效益不是很大，但是开阔了西轧厂人员的工作思路，使技术人员工作素质得到了进一步提高，奠定了西轧厂作为龙钢公司技术输出单位的核心地位。

参考文献：

[1]徐灏.机械设计手册[M].第3、4卷.机械工业出版社，1993.

[2]李曼云主编.小型型钢连轧生产工艺与设备[M].冶金工业出版社，1999.

[3]潘慧琴.轧钢车间机械设备[M].冶金工业出版社，1994.

[4]文庆明，程志彦.轧钢机械设备[M].人民邮电出版社，2006.

[5]袁建路，陈敏.轧钢机械设备维护[M].冶金工业出版社，2006.

作者简介：

软件缺陷分析 篇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

软件质量可以通过一系列度量因素来描述。对软件质量, 我们大致可以总结出5个关键度量维度, 即客户满意度、产品价值、关键属性、缺陷率和开发过程质量。高质量的软件, 应具备外部属性和内部属性, 其中外部属性包括产品的正确性和精确性、可用性、运行效率、可靠性、健壮性和适应性;内部属性包括可维护性、易扩展性、平台灵活性、可复用性、易测试性、代码可读性和整体理解性。软件质量重点强调软件需求、具体标准和隐含需求。

目前, 人们对软件质量保证体系的研究已比较成熟。世界上关于软件质量保证体系存在CMM/PSP/TSP、ISO 9000系列和ISO/IEC 15504 (SPICE) 三个流派, 其中, 以美国国防部支持的CMM/PSP/TSP流派研究得最为深入, 使用得最为广泛。

在软件缺陷分析和预测研究方面, 人们进行了大量的研究, 开发出一些软件缺陷预测模型。这些模型大致分为两类:一类是在软件开发的测试阶段, 根据历史数据预测软件缺陷;另一类是在软件开发之前, 通过对以往项目的缺陷数据进行分析, 预测在软件开发中会出现的缺陷数, 这些模型大多可以用于软件开发过程中的质量控制。

软件缺陷风险识别框架

软件生命周期是软件项目开发的重要阶段划分, 风险管理的实践通常都是与其结合进行的。本文按软件项目生命周期进行分阶段风险因素识别, 通过文献总结和软件项目从业人员的经验总结获取有价值的风险因素。

为了更好地了解基于软件项目风险分类的风险因素识别方法, 下面来看看软件开发项目风险结构图 (如图1所示) 。该分类从三个方面分析:软件项目生命周期过程、项目内部环境和项目外部环境。事实上, 在软件项目进展的过程中, 项目的内外部环境中的风险因素始终威胁着项目, 这些内外部因素随着软件项目的进展在不断演化, 不断影响着项目的产出结果。软件项目的管理技术将项目团队置于项目环境之中, 正是项目的环境、项目的管理技术和项目团队影响着整个项目的进展。项目的环境就是项目特性, 它包含了项目的本身需求因素、项目的内外部因素等;项目管理包含了项目的管理思想和管理技术;项目团队包括了项目的技术人员和项目的管理人员。

项目特性、项目管理和项目团队三者之间, 其实是互相影响的关系。当然, 项目管理是其他两者的重要纽带, 是三者关系的重要推力。紧密结合的三者又在项目的进展中不断改变各自的影响力, 互相均衡自己的影响力来推动项目的进展。

在一个软件项目当中, 项目管理人员和项目技术人员是可以在建设阶段中熟知一部分风险的, 只是从项目组织上无法通过沟通合作对风险形成一致的认识以实现共同抵御风险;在项目建设过程中, 持续的风险评估对于风险管理有着重要意义, 这就要求风险评估应当跟随项目进展, 应当经历项目建设的每一个阶段, 并对项目建设过程中变化的环境因素进行持续的风险评估;为了更有效地进行持续的风险评估, 就需要一个结构化的风险评估方法, 而且应将风险评估工作放置在一个开放的环境之中;最后, 在项目团队中要形成一种认识, 为了取得项目建设的成功并非需要控制所有的风险。

软件缺陷风险评估模型

项目管理者依靠有效的项目管理方法, 组织项目团队在相应的项目环境下去解决一定的项目需求, 而项目环境和项目需求是这个项目最典型的特性。在整个项目阶段进展过程中, 项目团队、项目管理和项目特性始终影响各阶段的递进, 就好像一条纽带把它们紧紧联系起来。

软件缺陷的评估, 可以放在需求阶段、设计编码阶段和测试阶段进行, 软件开发在不同阶段都会有项目团队的参与, 项目团队的工作能力和效率将直接影响着各个阶段的项目产出。

风险模型构造。软件缺陷的风险识别, 是按照软件生命周期的阶段分类进行的, 若将各阶段的风险因素置于同一个网络模型中, 那么, 这个模型无论它的复杂度还是数据存储空间都会制约着风险模型的评估效率。因此, 将风险模型按照软件生命周期各阶段进行分类, 每类之间按照阶段递进方式进行参数传递, 这种分阶段评估模型可以提高风险评估的效率。

需求阶段产生的需求错误和需求变更, 经过需求检测和新需求匹配性审核进入下一个阶段;设计编码阶段接受检测后的需求错误、需求分析文档和新需求匹配性审核, 输出编码错误和设计文档进入测试阶段;测试阶段接受设计编码阶段的输出和用户方试用的效果共同影响项目的缺陷率。项目团队工作能力的评估是贯穿三个阶段进行的, 它的输出进度压力、管理者工作能力和技术人员工作能力, 这些都作为三个阶段的评估输入。从图2可以看到, 各阶段风险模型的输入和输出、模型之间的联系因素等。分阶段模型一旦建立, 就可以在软件开发过程中的关键时刻设立预测点, 从而对整个开发过程进行有效的管理。

团队工作能力评估。团队工作能力评估主要根据管理者和技术人员之间的沟通以及项目管理的计划和分工水平来进行, 具体来说就是项目客户代表的工作能力、项目经理的资质、项目成员的技术水准、员工之间的沟通机制、项目管理人员的计划分工能力和项目团队的人才管理能力。

图3描述团队工作能力的风险模型。图中给出了设计阶段的设计质量目标的影响图, 包括设计质量受到阶段进度、开发人员工作能力、采用的技术、管理者工作能力, 并且软件开发其他阶段质量目标都有类似的影响结构图, 并进一步细化项目管理人员工作能力的评估、项目技术人员工作能力的评估和整个项目进度的评估。

软件缺陷评估工具

评估工具的应用, 能够让项目经理了解到项目目前的管理水平和风险威胁, 并根据提前的评估通过有效的管理控制措施来提高项目的成功率, 在项目和项目管理者之间架立桥梁。评估工具的核心就是图4中的四个风险模型, 四个风险模型分别描述了项目不同阶段风险因素之间的影响关系。

评估工具总体结构。项目经理可以通过评估工具的风险简要表, 向评估系统提供项目的目前基本信息, 经过项目团队工作能力的评估之后, 可以分别进入不同阶段的风险评估。当然, 不同的阶段评估将需要管理者提供不同的当前项目基本信息。

评估工具目前可以提供三类评估:一类是全程预测, 即软件开发需求分析前期, 对开发质量的整体评估, 按照图4中首先进行团队工作能力的评估, 接着进行需求阶段的评估, 然后是设计编码阶段评估, 最后是测试阶段评估, 整个评估路线就是 (1) (4) (5) ;第二类是需求后阶段评估, 即需求分析阶段之后的设计编码和测试阶段评估, 在这一类评估之前, 必须要了解项目在需求阶段的产出, 包括需求阶段引入的缺陷和需求变更的评估, 按照图4中首先进行团队工作能力的评估, 接着进入设计编码阶段的评估, 最后进行测试阶段评估, 整个评估路线就是 (2) (5) ;第三类是测试阶段评估, 在这类评估之前, 必须要了解项目在需求阶段和设计编码阶段的产出, 包括需求分析质量、设计文档质量和编码阶段引入的缺陷的评估, 按照图4中首先进行团队工作能力的评估, 接着直接进入测试阶段评估, 整个评估路线就是图中的 (3) 号路线。

数据流图。评估流程说明了评估工具应用的场合, 而评估工具的数据流图可以进一步解释评估工具的输入和输出, 为具体应用提供更明确的数据操作。

在评估工具的数据流图中, 项目经理首先需要选择软件开发的评估阶段, 接着进入评估工具的输入状态, 完成相应的风险因素的评估, 进入评估工具的整个评估路线, 最后得到软件缺陷的风险状态和其他风险的状态值, 这些状态信息可以作为项目经理进行风险管理的可靠依据。

软件缺陷数目是软件可靠性的重要度量指标, 而软件可靠性是衡量软件质量的最重要因素。如何为进行项目管理提高重要的风险信息, 对软件缺陷进行合理、正确的评估, 已经成为项目管理的首要任务。这样, 软件项目的风险管理成为软件项目管理的重要工作, 能否很好地解决这些问题将直接影响到软件项目风险管理的有效性, 同时也影响到软件开发的质量和软件项目的完成。

参考文献

[1]朱鸿, 金凌紫.软件质量保障与测试.北京:科学出版社, 1997.

[2]李文静.软件缺陷与软件测试.计算机与网络, 2001, (21) :31-32.

[3]黄国青, 田英.改善软件开发质量的全面质量管理办法.西北工业大学学报 (社会科学版) , 2001, 21 (3) :20-22.

[4]叶俊勇, 汪同庆, 杨波, 彭健.软件开发的质量保证体系.计算机与现代化, 2002, (6) :1-4.

[5]郑翠芳, 吴志杰, 夏涛, 张伟燕.基于BBNs的软件残留缺陷预测模型.微计算机信息, 2006, (3) :269-271.

软件缺陷度量与软件过程管理 篇9

软件产品的生产过程是软件质量的形成过程, 所以只有在过程中实现良好的管理和质量控制, 才能得到一个质量合格的软件产品。软件缺陷就是其中的软件质量的负面影响因素。虽然所有的软件系统都不是尽善尽美的, 但是严重的质量问题会危及用户的使用, 从而危及企业的软件生产。

软件的开发阶段的缺陷管理和预防是非常重要的, 因为一旦制定了有问题的软件的设计方案, 会直接导致软件的质量隐患, 所以, 我们在研发阶段要尽可能的防止这种情况的发生, 将隐患扼杀在初始阶段。一般的做法是, 在软件研发的过程中要形成一个严谨的缺陷分析报告, 将关于软件的性能的各个方面的具体数据和资料综合整理出来, 对于存在安全隐患和易出现问题的环节做好一定的预防措施和预防方案。

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.

软件缺陷管理 篇10

关键词：软件测试,缺陷管理

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.

汽车点焊质量保证与缺陷分析 篇11

关键词：汽车车身焊接；点焊；质量保证；缺陷分析；汽车产品

中图分类号：TG409 文献标识码：A 文章编号：1009-2374（2014）33-0072-02

1 点焊质量保证

1.1 点焊工艺设计的优化

汽车工业中，焊接是汽车零部件与车身制造中的一个关键环节，起着承上启下的特殊作用，同时，由于汽车产品的车型众多、结构复杂，汽车车身零部件生产逐渐步入专业化和标准化，汽车制造在成本、效率和质量等方面的综合要求，都决定了汽车焊接加工是一个多学科、跨领域和技术集成性比较强的生产过程。

点焊采用的设备以及点焊质量在相当程度上由点焊的工艺设计决定。应该避免设计多层板，充分考虑点焊的边距和间距。合理安排焊接顺序，这样就可以减少在焊接的过程中出现焊接分流以及焊接变形现象的出现。在进行设计焊接回路时，我们应该尽量减小采用二次回路阻抗。制定出合理的、简便的、经济高效的点焊质检工艺，在进行施焊的过程中应该制定合理可靠的质检工具和方法。施焊前应该制定合适的质检频次和测试仪表及工具。汽车车身整体结构完整性和刚度主要是由焊接质量决定的，因此做好焊接质量工作以及做好点焊检测工作对于汽车车身质量具有重要的意义。

1.2 电极

影响点焊质量的重要零件是点焊电极。电极主要由端部、主体、尾部、冷却水孔等组成。下面介绍电极的主要作用，包括电极可以向工件传递压力、传导电流、迅速导散焊接区的热量。现在点焊时主要采用的电极主要有两种，分别为球面形和锥台形，其中电极端部端面直径d决定了焊件与焊接电极的接触面积的大小。当电流相同时，电极端部端面直径d又是控制电极压强分布范围以及焊接电流密度大小的重要因素。我们在进行电极的选择时，应该充分地考虑到电极在整个点焊过程中起到的作用，在电极进行向工件传递压力时能够很好地控制压力的大小，在电极进行向工件传导电流时能够均匀输送，这样才能够保证点焊的质量。

1.3 点焊的强度保证

要想使点焊有足够的强度，首先应该根据焊件的厚度、材质以及其他的相关技术要求制定合理的焊接工艺和检查标准，在焊接的过程中应该加大管理力度，对焊件的材质进行检查并结合焊件的使用技术要点制定合理的施焊工艺。另外，点焊的质量控制主要取决于采取有效措施来控制不利于焊接工作的各种因素，主要因素有网路电压的波动和性能的变化以及电极端面直径，随着点焊次数的不断增加，电极端面直径在压力和电阻热双重作用下引起电流密度降低。铁磁性物质进入焊钳导致二次回路阻抗的变化。针对这些因素采取的措施有：选用目前先进的微电脑阻焊控制器，可有效克服网路电压的波动及二次回路阻抗变化的影响。在进行焊接时采用的是计算机群控管理和集中控制对焊机的通电焊接进行管控。采用这样的管理措施可以有效地防止出现同时作业的点焊机数量过多，从而减小电源电压下降的概率，使得每个点焊机的电压都控制在允许的范围内。

同时，应该安排专业的质量管理人员对在线所有焊机的工作状况进行检查，这样就可以有效地保证焊接质量，为在施焊时保证汽车车身焊接质量和实现焊接质量达标提供了很好的基础。

其次，我们在进行编制汽车车身焊接工艺时，可考虑到利用微电脑阻焊控制器来控制电极以及施焊时电流的影响，利用微电脑阻焊控制器可以在很大程度上减少电极端面直径变大而引起的电流密度下降，还有由于电极端部损坏对点焊质量的影响。在施焊的工程中不可避免地会出现一把焊钳需焊接板件组合不同的部位。对于这个问题，我们应该采用不同的焊接规范进行焊接，不同部位的焊接要求是不一样的，还有在焊接的过程中容易出现焊工混淆或者遗忘，这些问题已经被焊接技术智能化系统解决了。采用机械人点焊和自动化焊钳就可以解决不同部位焊接标准一样的问题，在焊接夹具上设置程序转换板，进行对焊接规范进行强制转换，能够取得一定的效果，保证点焊的质量。

1.4 点焊外观质量的保证

点焊的外观质量主要是指平滑均匀过渡、局部挤压造成的表面鼓起或者无明显的凸肩以及毛刺，点焊表面没有熔化和粘附的杂物出现，没有裂纹出现，在焊接的过程中点焊的位置准确，没有发生点焊造成的工件变形。为了保证点焊的施焊质量，我们采取了以下措施保证焊接质量：在焊件的外表面使用可以浮动电极垫板，这样就可以在一定出程度上减少毛刺等焊接缺陷出现，为了保证点焊位置的准确性和避免造成工件变形，我们在进行施焊时采用点焊导向块就很好地解决了工件变形以及点焊位置不准确的问题。采用有浮动机构的焊钳以避免工件受非焊接压力的作用而变形。

2 点焊主要缺陷产生的原因及预防措施

2.1 飞溅

飞溅是点焊比较常见的缺陷，飞溅首先依据时间可分为后期飞溅和前期飞溅，其次依据产生的部位可分为外飞溅和内飞溅。点焊时产生后期飞溅的原因是：在进行焊接时由于熔核长大过快，已经超出电极压力能够承受的范围，导致冲破塑性环，在径向造成内飞溅，在轴向冲破板表面造成外飞溅。飞溅不仅仅影响外观，而且对于焊件的疲劳性能和耐腐蚀性都会有一定程度上的影响。前期飞溅产生的原因是：由于前期的清理工作不到位，导致焊件的表面清洁度不好或者焊件表面上承受的压强分布不均匀，这样就会引起熔化的现象出现，这就是压强分布不不均和不洁净的表面导致局部电流密度过高造成的。防止前期飞溅的措施有：首先，加强焊件清理质量管理工作，在施焊前进行焊件表面清洁度的检查；其次，采用渐升电流或者增加预热电流来减慢加热速度，这样就可以避免早期熔化而引起飞溅。

2.2 收缩性缺陷

收缩性缺陷主要包括缩孔和收缩性裂纹。造成缩孔和收缩性裂纹的原因有：在进行点焊时，由于温度的落差比较大，焊接时集中加热，冷与热的交换速度很快，液态金属被包围在金属塑性环中，同时受焊接区金属变形的影响，导致在焊缝的接头处出现收缩性裂纹和缩孔等缺陷。我们可以采取以下措施防止出现缩孔和收缩性裂纹：防止出现缩孔和收缩性裂纹主要靠提高电极压力，特别是熔核形成、焊接区快速冷却时的锻压力来

实现。

3 结语

目前，点焊采用的设备以及成本和点焊质量在相当程度上由点焊的工艺设计决定。在我们进行点焊时为了减少飞溅﹑收缩性缺陷等焊接缺陷的出现，应该加强焊件清理质量，采用渐升电流或者增加预热电流来减慢加热速度，保证焊接的质量。在进行焊接施工时应合理安排焊接顺序，这样就可以减少焊接变形和焊接分流现象的出现。制定合理的质检频次和测试仪表及工具。为了防止出现缩孔的现象，我们在进行焊接施工时应该注意电极压力以及焊接区快速冷却时的锻压力的处理。

参考文献

[1] 吕毅，周华.汽车焊接拼台上的气路系统设计及管路布置浅谈[J].装备制造技术，2008，（3）.

[2] 任桂华.焊接新技术在汽车制造业中的应用及发展趋势[J].现代机械，2005，（3）.

[3] 河南省汽车工程学会第四届科研学术研讨会论文集

[A].

软件开发的缺陷预防手段 篇12

每个产品都会有缺陷,在软件开发过程中应争取尽早发现缺陷,开发的时候提高软件质量要远比开发完成后再进行测试更为有效。一般对软件开发主要控制缺陷手段是进行测试和检查,在一定程度上可以确保不让不合格产品交付到用户手里,然而能够保证最初制造的产品就是一个合格产品吗?能将质量测试融入产品中去吗?实现起来比较困难,而且只能在开发的结束才能进行测试。其实这不仅是改进软件流程所独有的现象,也是目前软件开发共同面临的问题。要想得到高质量软件,重要的是将质量设计到软件中。这比如何设置质量保证部门、向谁报告、独立测试、需要进行什么样的评审等事情重要得多。要想在软件开发的每个阶段都注重质量需要有一个流程进行管理,大多数软件流程改进模型(像CMM和ISO 9000)都认为有效和正确的流程必然会导致生产出高质量软件。我们有理由相信有效的流程肯定能制作出一开始就能正常工作的高质量软件。下面先介绍缺陷管理的基本原理,然后讨论软件在产品开发周期中的验证和确认,特别是所采用的评审、检查和测试技术。

2 缺陷管理

软件中一般会有问题和缺陷,其实这都是一些由开发人员造成的软件错误,这些缺陷实际上在开发过程从提出要求到进行维护的任一阶段都可能造成。假如适当条件永远不发生而没有触发执行有问题代码的话,缺陷就将隐藏下去,否则它们会暴露出来而造成失效。失效的严重程度不尽相同,最坏情况下失效可使系统崩溃或者系统功能不正常,而轻微时失效仅仅使用户感到不方便或不满意而已(如响应时间太慢或者接口使用困难等)。

当然还是应该尽量避免缺陷,关于缺陷管理有两个指导性原则。首先,在最初阶段就要避免造成缺陷,可以通过在产品开发周期每个步骤都使用正确技术做到这一点。第二个原则就是在流程中尽可能早地检测出缺陷,一旦检测到就要从源头处把它消除掉。这就是说如果缺陷是在低层设计中造成的,就应在此时把它消除,最好在编码开始前。

时间拖得越久,消除和修复缺陷的费用就越高。研究指出,缺陷在产品开发周期晚期发现其消除的费用将会急剧上升。为避免缺陷,需要针对软件开发每一阶段的特殊技术进行培训。

通过评审检查的验证和确认活动,是缺陷形成后尽早检测出来并从源头处把它消灭掉,这样做不仅去除缺陷的费用更少,而且使我们相信质量已被制造在产品中,而不是直到装运前才将高质量产品筛选出来。通过评审就是在每一阶段对软件进行评估,以保证它符合前一阶段所提出的要求;同时,通过在开发工作完成时对软件及其技术指标规范进行测试,以保证软件符合总体要求。

3 评审和检查

有人说技术工作需要进行评审就如同铅笔需要橡皮擦一样,因为人总是要犯错误的。在开发过程的各个阶段进行评审,如果软件开发时没有定出精确要求,则根本不可能通过评审或其它方法验证设计是否准确,因为此时设计不是根据要求做出而是孤立的,任何对缺陷的判定最终都是个人观点。因此评审和检查首先假设软件开发过程已有严格的要求。评审每个开发阶段的中间产品有两个基本作用。首先,我们能在早期检查出缺陷并在修改费用较低时将其消除掉;其次,这一点可能更重要,我们能够在公司内部改变流程,在软件开发最初阶段就提出大量的严格要求。如果管理层在评审上投机取巧,则到时候可以清楚地看到没有好的要求(或者好的设计)评审就不会带来什么价值。

评审可作为质量过滤的一种形式用于软件开发各阶段,其目的是尽早发现错误以使产品更加完善。评审结果是:指出产品中需要改进之处;确认好的部分;使产品在编码方式、文件样式、设计方法等方面更加一致,以便技术工作能更好地进行管理;改进软件开发过程。

进行评审,确保四方面的特性。完整性,下一阶段产品与其前期设计的产品是完备的整体,没有待定项、遗漏功能。一致性,符合产品的要求。可行性,产品能完成。易测性,产品做指定测试的能力,该测试必须是具体的、明确的和可以量化的。

评审会议的组织,人员应限于3～7人,会议中,明确分工,经过培训。为使会议有效,事前做准备,时间一般不超过两个小时;评审的是产品而不是它的设计者,要客观地讨论产品而不涉及与之相关的人要限制争论和辩解。搞清问题所在但不要试图去解决任何事情会议的焦点是发现而不是解决,正式评审中小组的目的不是进行共同设计。会议应沿着发现问题的思路进行。指定记录员。

评审检查是很经济的,通过检查能在修复费用相对较低的早期阶段发现缺陷。此外当要求作必要的修改时,对多层次设计文件、产品代码及产品文件进行改动会出现脉动效应,而检查能防止这类效应,评审的另一个关键是它设计为检测缺陷而不是检测失效。最后,因为每一个中间产品必须要能追溯至前一级中间产品,所以评审必然会改善整个流程,而要求的准备和设计工作都做得很差的小组几乎就拿不出合适的东西进行评审。

4 软件测试

虽然正式评审和检查占用了我们大量的精力,测试仍然是缺陷控制和检查中很有用且很重要的一个部分。测试时我们在受控状态下运行软件以检测缺陷,如同我们在提要求、设计和编码等各阶段进行评审和检查一样,我们在软件制作的任何适当的地方进行测试。下面将简单介绍单元测试、集成测试、系统测试和回归测试。

4.1 单元测试

单元测试的任务是在一个受控环境中执行一个特定模块。它一般包括某种形式的构架,通常为短线程和驱动器。一般用来验证模块的功能属性,但也可以测试其它项目,如性能、可用性等等,可使用“黑盒”或“白盒”方法进行。

4.2 集成测试

当各模块己经过单独的单元测试后,我们就将它们组合到一起,看与其它模块集成在一起时的整体功能。模块可按多种途径集成,包括从上向下和从下向上。实际上任何方法都可以使用,只要测试人员能了解特定模块组合所表示的行为,组合从最前面两个模块开始,到加入最后一个模块结束,形成一个完整的系统。理想状况下,集成测试应每加入一个模块进行一次。集成测试一般也看作验证的一种形式,因为组合模块的行为是一个功能规范的产品。

4.3 系统测试

系统测试是指对整个系统或产品进行测试,看它是否符合总体系统要求。系统测试人员相当于用户代言人,因为测试指导文件应该或者是用户提出的需求,或者是直接基于这一要求的技术规范。系统测试能发现任何质量问题,包括功能、性能、可靠性和可用性,还有特定项目的其他方面要求。

4.4 回归测试

回归测试就是漏洞修复完成后再对软件进行测试,以确保软件没有产生“回归”或因修复而变得更糟,这种测试一般要重新运行最初发现问题的原始测试程序。

测试是一个专业,要用专门的一套技术来进行关键的工作。好的测试是从一开始就参加软件开发,可为产品开发阶段带来一种质量的观念。尽量使产品暴露出问题才是公司和用户的最大利益所在,应当注意的是测试的技能与开发并不相同。常常和测试联系在一起的用户和开发人员,但用这两类人作测试都存在一些问题。开发人员的工作是构建,他制造产品;而测试人员的任务则是找出缺陷,每个工作都要求特定的个性,在两者之间随意变动不是小事。更重要的是,让开发人员去测试自已的代码,当处理代码的薄弱部位时,会不自觉地退缩,不是很好地了解问题而是绕开软件中有问题的部分,他们没有足够的勇气对自己动手术。由用户来进行测试,虽然在可用性方面能提供大量反馈。用户在测试时通常重复,不够系统,另外缺乏想象力。对新软件缺乏信心,速度也比较慢。

5 结束语

许多公司对独立测试或功能验证相当满意。但这些公司的测试一般是在流程结束时才会进行,以确定产品达到必要的质量水平。本文重点是评审和检查,尽管这两种技术提供了一个更可靠的机制,可以随着开发阶段的进行将质量制造在产品中,但它们在软件公司中使用得并不普遍。用很少人对产品进行直观检查在很多方面会相当费力,但其潜在的好处是巨大的。每个产品都有缺陷,这是无法改变的,但产品中的缺陷迟早都是会发现的。最坏的情况是在应用现场发现,最好则是尽可能早地在软件开发过程中发现缺陷。一个很充分的理由就是应该制造缺陷更少的产品,并且这些剩下的缺陷其严重程度应能被用户所接受。

摘要：软件开发由于是人为的设计和开发过程,发生缺陷很难避免,传统软件工程做法是通过软件测试,控制软件存在的缺陷。在本文中我们讨论通过实施有效的评审和检查以及软件测试活动,控制软件交付后,存在较少缺陷。

关键词：缺陷,评审,检查,软件测试

参考文献

[1](印)PANKAJ JALOTE,译者:胡春哲张洁等,CMM实践应用-Infosys公司的软件项目执行过程[M].北京:电子工业出版社,2002.