关键词：软件开发；软件测试；测试手段；重要意义
中图分类号：TP311.52
软件开发是一项集信息量大、程序代码多和时间长的工程，一个软件的好坏、质量的优劣不仅取决于软件的开发目标及其可行性的评估、功能需求的分析、软件的设计以及程序代码的编写，还取决于软件测试。软件测试是软件开发中的最后一个阶段，软件测试是使用人工或者自动手段来运行或测试某个系统的过程，通过测试发现软件开发设计过程中存在的问题，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。因此，软件测试在软件开发中的重大作用由此可见一斑。本文将从软件开发中的软件测试的内容、软件测试的方式方法、软件开发在软件开发中的作用及对软件测试的展望等几个方面对软件开发这一话题进行一番论述，从软件功能测试的作用谈起，浅析软件测试在软件开发中的重要意义。
1 软件开发阶段概况
当下软件开发一般分为五个阶段，从软件开发中的计划、分析、设计、编码到测试。（当然从广义上来说：软件维护也可以算是软件开发中的一个阶段）主要阶段具体可为：
1.1 问题的定义及规划
作为软件开发的第一步，对问题的定义及规划是软件开发的首要工作。软件计划中软件工作人员需要完成对所需解决的问题从市场需求、用户要求现实环境对所要解决的问题进行总体上的定义，在完成定义的同时，在这个阶段中还要就技术和经济层次上对所定义的问题进行合理的规划，做成资源、经济成本分析，就软件设计项目的有效实施提出具有可行性、操作性强的最优化方案，最大限度的规避在项目开发实施过程中不必要的问题。
1.2 需求分析
在完成问题的定义及规划之后，就要对软件需要实现的各个功能进行详细需求分析。需求分析阶段软件需求分析就是对开发什么样的软件的一个系统的分析与设想。它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言表达出来的过程。是一个很重要的阶段，需求分析的好坏，直接决定了软件功能基础，只有在需求分析阶段打下了良好的基础，才能为后面的软件开发过程省去不少的工作，才能设计出好的软件。
1.3 软件设计
软件设计是根据软件需求分析的结果来进行的，有什么样的需求，对应之进行怎样的功能设计，这个阶段是对整个软件系统进行设计，主要包括概要设计和详细设计两个阶段：主要用软件结构图表示方法和结构化程序设计方法分别对概要设计和详细设计进行说明，完成软件模块结构、程序流程等主要目标，为程序编码提供依据。
1.4 程序编码
此阶段是将软件设计的结果转化为计算机可运行的程序代码。在程序编码中必定要制定统一、符合标准的编写规范。以保证程序的可读性、易维护性。提高程序的运行效率。程序编码的正确与否直接决定了软件测试工作量的大小。所以软件编码在保证程序可读性还要做到越简约越好，为后续的工作打下坚实的基础。
1.5 软件测试
在软件设计完成之后要进行严密的测试，一发现软件在整个软件设计过程中存在的问题并加以纠正。整个测试阶段分为单元测试、组装测试、系统测试三个阶段进行。测试方法主要有白盒测试和黑盒测试。
2 软件测试的内容
软件测试是使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
测试是为了发现程序中的错误而执行程序的过程，是一个寻找软件中尚未发现的错误的测试，一个成功的软件测试可能是一个新的测试方式方法，不但可以发现、改正软件中的错误，还能进一步的提升软件质量。软件功能测试一般包括了从以前段准备的测试用例进行测试为测试策略，通过对页面友好，安全性，可靠性，性能等内容进行测试的分支的测试、以解决合并时出现的冲突的测试和回归测试为主的合并到主干后的测试、以回归主要功能，关注特殊数据的预测试及可以监控了用户的某些行为的Beta测试这几个阶段一一进行。
3 软件测试的方式及特征
软件测试是一个系列过程活动，贯穿于软件项目的整个生命过程，很多软件项目的开发还停留在“作坊式”阶段，项目的成功往往靠个别程序员决定。软件测试看似只是一个寻找在软件开发中出现问题，解决问题的过程，其实软件测试是一个十分困难，耗时非常多，工作量巨大的任务，需要测试员工不但需要有良好的技术知识和测试经验，还需要拥有细心、恒心和耐心。在软件测试中主要用到的测试方式为白盒测试和黑盒测试。
3.1 白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
3.2 黑盒测试
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。通过边界值分析、错误推测法、因果图法、和正交试验设计法进行测试。。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。
4 软件测试的作用
软件测试在软件开发中的重要性不言而喻，软件测试是质量保证的重要手段之一。软件测试的作用，具体地说明的话，可以概括为下列四个方面：
对产品质量完成全面的评估，为软件产品（如验收测试）、软件系统部署（如性能规划测试）、软件产品鉴定（第三方独立测试）委托方和被委托方纠纷仲裁（第三方独立测试）和其它决策提供信息。
通过持续的测试（包括需求评审、设计评审、代码评审等）可以对产品质量提供持续的、快速的反馈，从而在整个开发过程中不断地、及时地改进产品的质量，并减少各种返工，降低软件开发的成本。
通过测试发现所要交付产品的缺陷，特别是尽可能地发现各种严重的缺陷，降低或消除产品质量风险，提高客户的满意度，扩大市场份额，提高客户的忠诚度。
通过对缺陷进行分析，找出缺陷发生的根本原因（软件过程中的问题，包括错误的行为方式）或总结出软件产品的缺陷模式，避免将来犯同样的错误或产生类似的产品问题，达到缺陷预防的目的。
从具体的市场需求和客户的使用情况来看，软件测试在软件开发中占据着不可或缺的位置，因为软件测试决定了软件的质量。从1982年，最大的一次非核子爆炸――软件BUG导致横跨西伯利亚的输气管爆炸事件到1996年6月4日的Ariane 5火箭的飞行计算机中的软件BUG问题使得其升空40秒后爆炸事件；从近年来的奥运门票预定系统瘫痪到诺顿病毒误杀事件；从2000年11月，巴拿马国家癌症中心的放射线医疗仪的软件出现BUG到NOKIA新款手机的推迟等一系列的由软件质量引起的问题甚至可以说是灾难，都无不警示着我们，都无不告诉着我们软件质量是一个软件的命脉，而决定这一命脉的则是软件测试。当然，在市场的需求和客户的具体使用情况分析来看，有缺陷的软件产品带给用户的问题会给该软件带来危机，让该款软件很快的淘汰出市场，甚至会很大程度上的危害到企业的利益。由此来看，要想很好的规避质量问题，把好软件测试至关重要。
总之，软件测试更适宜被视为试图发现程序中错误（假设其存在）的破坏性的过程。一个成功的测试，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。
5 对软件测试的展望
软件测试为软件质量控制中的重要一环，利用测试工具按照测试方案和流程对产品进行功能测试和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对侧四方案可能出现的问题惊醒分析和评估。执行测试用例后，需要跟踪故障，以确保开发的差频频满足需要。从软件业发达的美国、印度的发展不难得出：软件测试不仅成为软件开发的一个有机组成部分，而且在软件开发的系统工程中占据着相当大的比重。当然，在近些年，随着国内软件工程的不断发展，软件测试的人才培养、引进也显得尤为火热。软件测试人才的空缺也很好的说明了软件测试的重要性。所以，可以预见的是：在未来的软件工程的发展过程中，在软件开发中的软件测试会变得更为重要，不仅是因为软件测试能够完善软件功能，更为重要的是软件测试能够把好软件的质量关，从而保证软件在使用过程中的安全性。面向未来，软件测试的作用不可替代，软件测试的重要性日益剧增。
6 结语
通过从软件开发阶段概况、软件测试的内容软件、测试的方式及特征、软件测试的作用及对软件测试的展望这五个方面对对软件测试在软件开发中的重要意义有了更为深刻的理解：软件测试不仅仅是局限于在发现软件中存在的问题，解决发现的问题，还是保证软件质量的至关重要的一步，只有把握好软件测试的关，才能让软件质量拥有更好的使用寿命和使用价值，才能更好地得到市场的认可，满足客户的需求。所以可以说，软件测试是软件成功与否的一个门槛，迈过这个门槛，才能拥有美好的未来。
参考文献：
[1]I Jacobson，G Booch，J Rumbaugh，周伯生，冯学民.统一软件开发过程[M].北京：机械工业出版社，2002.
[2]基于W模型的面向对象软件测试教学研究[J].承德石油高等专科学校学报，2012，1（14）.
[3]李海峰，马琳.软件测试 PC Jorgensen[M].北京：人民邮电出版社，2011.
[4]浅谈软件测试用工具的设计与实现[J].科技创新与应用，2012，3.
[5]单锦辉，姜瑛，孙萍.软件测试研究进展[J].北京大学学报（自然科学版），2005.
[6]浅谈软件测试的研究热点[J].民营科技，2012，2.
[7]余久久.软件功能测试用例的设计过程及实践[J].电脑知识与技术，2008.
[8]颜炯，王戟，陈火旺.基于模型的软件测试综述[J].计算机科学，2004.
关键词: 软件 可靠性工程
随着科学技术的不断进步，计算机技术被越来越多地应用到武器系统中。计算机软件的复杂程度随着功能的增强，因而系统的可靠性也越来越与软件直接相关。例如afti/f-16飞机首航因软件问题推迟一年，事先设计的先进程序无法使用；海湾战争中f/a–18飞机飞行控制系统计算机500次故障中，软件故障次数超过硬件。软件可靠性成为我们关注的一个问题，本文仅就软件可靠性工程在软件开发过程中的应用谈谈自己的认识。
1、软件可靠性工程的基本概念及发展
1.1什么是软件可靠性工程
软件可靠性工程简单地说就是对基于软件产品的可靠性进行预测、建模、估计、度量及管理，软件可靠性工程贯穿于软件开发的整个过程。
1.2软件可靠性工程的发展历程
软件可靠性问题获得重视是二十世纪60年代末期，那时软件危机被广泛讨论，软件不可靠是造成软件危机的重要原因之一。1972年正式提出jelinski—moranda模型，标志着软件可靠性系统研究的开始。在70年代．软件可靠性的理论研究获得很大发展，一方面提出了数十种软件可靠性模型，另一方面是软件容错的研究。在80年代，软件可靠性从研究阶段逐渐迈向工程化。进入90年代后,软件可靠性逐渐成为软件开发考虑的主要因素之一，软件可靠性工程在软件工程领域逐渐取得相对独立的地位，成为一个生机勃勃的分支。
1.3软件可靠性工程研究的基本问题
软件可靠性工程的主要目标是保证和提高软件可靠性。为达到这一目标，首先要弄清软件为什么会出现故障或失效。只有这样，才有可能在软件开发过程中减少导致软件故障或失效的隐患，且一旦出现软件故障或失效，有可能采取有效措施加以清除。但是软件是开发出来的，满足可靠性要求的软件也是开发出来的，因此，软件可靠性工程的核心问题是如何开发可靠的软件。而有了软件，又该如何检验其是否满足可靠性要求?这是软件可靠性工程的又一个问题。
2、软件可靠性工程在软件开发中的应用
2.1项目开发计划及需求分析阶段
在项目开发计划阶段需根据产品具体要求作出软件项目开发计划，明确项目的目的、条件、运行环境、软件产品要求、人员分工和职责及进度，并估计产品的可靠性。需求分析阶段要根据项目开发计划阶段确定软件开发的主要任务、次要任务和其它任务，并设计软件程序的基本流程、软件结构、模块的定义和输入输出数据、接口和数据结构等同时应对项目开发计划阶段作出的可靠性预计进一步细化形成可靠性需求，建立具体的可靠性指标。这个阶段的可靠性工作一般应如下安排：
⑴确定功能概图
所谓功能概图就是产品的各种功能及其在不同环境条件下使用的概率。为确立功能概图必须定义产品的功能，功能定义不但包括要完成的任务，还包括影响处理的环境因素。
⑵对失效进行定义和分类
这里应从用户的角度来定义产品失效，将软件和硬件失效及操作程序上的失效区分开，并将其按严重程度进行分类。
⑶确定用户的可靠性要求
在这个阶段应由系统设计师、软件设计师、可靠性师、测试人员及用户方代表可靠性评估小组共同根据用户提出的系统可靠性来确定软件的可靠性。
⑷进行平衡关系研究
通常应考虑可靠性和功能之间的关系以及可靠性、开发费用和开发周期之间的关系。一般来说，增加功能会导致可靠性降低，可靠性提高的程度一般与测试加强程度相对应，这意味着时间和费用的增加。
⑸建立可靠性指标
在这个阶段应对每种失效分别建立可靠性指标。通常，首先建立系统可靠性指标，然后在硬件和软件间分配。影响建立可靠性指标的因素主要有：合同或有关标准中明确规定的可靠性指标，相似产品的可靠性指标，产品的质量保证，使用已有模块的可靠性，技术能力和局限（如容错技术的使用）等。
2.2软件设计和功能实现阶段
软件设计是对上一阶段定义的每一个功能模块逐步细化，确立系统体系结构，形成若干可编程的模块。说明硬件和软件模块之间的接口及它们与外部环境的接口，详细描述各模块的输入、处理过程及输出。功能实现是根据设计方案进行软件编程。该阶段主要应做：
⑴在模块间分配可靠性指标
定义系统体系结构时，应将系统分解成模块同时保证总体可靠性指标。进行系统分解是应考虑以下因素：系统的物理特性、以前收集的数据的特性及收集数据需要的工作量等。确定每个模块的可靠性要求时，首先进行可靠性分配，然后根据试分配值计算系统的可靠性。这样及时调整，使各模块开发周期、难度和风险大致相当，系统的开发费用也才能降至最低。
⑵按可靠性指标进行设计
目前，可靠性设计有以下几种方法：设计恢复策略、使用冗余软件单元、鉴别高风险区域。设计恢复策略是指软件只须重新启动即可消除失效的设计，设计恢复应能保存修复可能破坏的数据，应具备确定失效发生时间和阻止继续运行的机制，以减少程序数据的破坏。使用冗余软件单元时是采用与原软件单元不同的冗余软件单元来提高可靠性。鉴别高风险区域采用fmea（失效类型与后果分析）和fta（错误树分析）的方法来进行可靠性分析。
⑶根据功能概图集中资源配置
根据功能概图把人力、物力等资源用到用户认为最重要的地方。
⑷控制错误的引入和传播
错误是引起软件失效的根本原因，所以控制每个开发步骤中引入的错误数目及未被察觉的而传入下一步的错误数目，对于控制产品的可靠性是非常重要的。错误控制受多种因素影响，其中主要有：
a.构造模块化系统;
b.进行软件重用;
c.进行单元和集成测试，阻止错误向下一开发步骤传播;
d.进行检查和复核;
e.控制改动。
⑸度量现成软件的可靠性
如果在产品中使用现成的未在本产品中开发或测试过的软件，必须对其进行可靠性证明，证明其可靠性指标在可以接受的范围内方可采用。
2.3系统测试和现场试运行阶段
系统测试和现场运行以确认产品的软件要求是否得到满足，用户是否可以实际应用。系统测试阶段是开发过程阶段的最后阶段，如果措施得当，可以在产品首次使用前进一步提高可靠性。现场试运行阶段在用户环境中验证产品的各种说明及系统测试所得的可靠性指标。这个阶段的工作有以下工作：
⑴确定操作概图
操作概图是指实现系统功能的操作及其概率的集合，一个操作可以是特定环境下执行的一条命令，或同时附有限定范围内的参数或输入变量集。确定操作概图是测试计划的一个重要部分，一般在系统测试阶段之前由测试计划人员，在系统设计师和软件设计人员的协助下完成。
⑵进行可靠性增强测试
在系统测试阶段需进行可靠性增强测试。在可靠性增强测试中，系统测试员根据操作概图描述各种操作的现场发生概率，按比例的执行测试用例，通过模仿用户的应用方式可靠性增强测试，易于发现令用户最不满意的失效，能够反映出用户使用时的可靠性感受。
⑶根据测试进展并证明可靠性指标是否达到要求
在可靠性增强测试中，要收集失效数据，利用已有或自行设计并经验证的可靠性工具跟踪测试进展及规划必须的额外测试，根据进展情况在系统测试进行中可以对资源和进度安排随时做必要的调整。
⑷现场可靠性评估
系统测试阶段完成后，转入现场试运行阶段。在试运行中，从现场收集失效数据，利用此数据和软件工具评估现场可靠性，然后与系统测试结束后测得的可靠性相比较，同时对可靠性差异的产生原因进行分析。
2.4维护阶段
维护阶段是在产品用户使用过程中改正软件暴露出来的与失效有关的错误。在这个阶段监视产品现场运行的可靠性，并和预定指标及用户的满意程度进行对照比较，以便提高后继版本的可靠性，改进软件开发过程中的质量。此阶段主要做的工作是：
⑴用可靠性模型规划产品交付使用之后的人员需求，如：用户恢复失效操作的人员，承制方处理用户报告的失效的人员，承制方处理与用户报告的失效有关的错误的软件开发人员。
⑵监视现场可靠性是否达到预期指标，根据其间的差距采取相应的措施。同时还应跟踪用户是否满意，根据不满意的情况，进行必要的现场支持服务及产品改动。
⑶当加入新的功能时，通过监视可靠性，消除由此带来的失效强度增加。
⑷分析软件交付使用后的失效产生原因，指导工程的改进，降低引入类似错误的可能性。
3、软件可靠性工程成功应用的实例
美国at&t公司的国际definityr程控交换机部在系统软件开发过程中应用了软件可靠性工程，相对于以前发行的主要软件版本，产品的质量提高是惊人的：
⑴用户反映的问题下降了10倍；
⑵项目维护费用下降了10倍；
⑶系统测试件的间隔缩短了2倍；
⑷引入新产品的间隔缩短了30%。
而且，在投入运行的前两年，从未发生严重影响业务的机器中断，客户满意程度大为提高。具体分析原因，有以下两点：
⑴把可靠性作为确定是否发行的标准，可避免用户在使用中反映过多问题和进行相应的维护工作。
⑵采用“操作概图驱动”的测试方法，提高了测试效率；20%的操作覆盖了95%的应用，20%的错误导致了95%的实效；先测试20%的使用最频繁的操作可以加速可靠性的提高。
4、结束语
关键词:软件可靠性工程
随着科学技术的不断进步，计算机技术被越来越多地应用到武器系统中。计算机软件的复杂程度随着功能的增强，因而系统的可靠性也越来越与软件直接相关。例如AFTI/F-16飞机首航因软件问题推迟一年，事先设计的先进程序无法使用；海湾战争中F/A–18飞机飞行控制系统计算机500次故障中，软件故障次数超过硬件。软件可靠性成为我们关注的一个问题，本文仅就软件可靠性工程在软件开发过程中的应用谈谈自己的认识。
1、软件可靠性工程的基本概念及发展
1.1什么是软件可靠性工程
软件可靠性工程简单地说就是对基于软件产品的可靠性进行预测、建模、估计、度量及管理，软件可靠性工程贯穿于软件开发的整个过程。
1.2软件可靠性工程的发展历程
软件可靠性问题获得重视是二十世纪60年代末期，那时软件危机被广泛讨论，软件不可靠是造成软件危机的重要原因之一。1972年正式提出Jelinski—Moranda模型，标志着软件可靠性系统研究的开始。在70年代．软件可靠性的理论研究获得很大发展，一方面提出了数十种软件可靠性模型，另一方面是软件容错的研究。在80年代，软件可靠性从研究阶段逐渐迈向工程化。进入90年代后,软件可靠性逐渐成为软件开发考虑的主要因素之一，软件可靠性工程在软件工程领域逐渐取得相对独立的地位，成为一个生机勃勃的分支。
1.3软件可靠性工程研究的基本问题
软件可靠性工程的主要目标是保证和提高软件可靠性。为达到这一目标，首先要弄清软件为什么会出现故障或失效。只有这样，才有可能在软件开发过程中减少导致软件故障或失效的隐患，且一旦出现软件故障或失效，有可能采取有效措施加以清除。但是软件是开发出来的，满足可靠性要求的软件也是开发出来的，因此，软件可靠性工程的核心问题是如何开发可靠的软件。而有了软件，又该如何检验其是否满足可靠性要求?这是软件可靠性工程的又一个问题。
2、软件可靠性工程在软件开发中的应用
2.1项目开发计划及需求分析阶段
在项目开发计划阶段需根据产品具体要求作出软件项目开发计划，明确项目的目的、条件、运行环境、软件产品要求、人员分工和职责及进度，并估计产品的可靠性。需求分析阶段要根据项目开发计划阶段确定软件开发的主要任务、次要任务和其它任务，并设计软件程序的基本流程、软件结构、模块的定义和输入输出数据、接口和数据结构等同时应对项目开发计划阶段作出的可靠性预计进一步细化形成可靠性需求，建立具体的可靠性指标。这个阶段的可靠性工作一般应如下安排：
⑴确定功能概图
所谓功能概图就是产品的各种功能及其在不同环境条件下使用的概率。为确立功能概图必须定义产品的功能，功能定义不但包括要完成的任务，还包括影响处理的环境因素。
⑵对失效进行定义和分类
这里应从用户的角度来定义产品失效，将软件和硬件失效及操作程序上的失效区分开，并将其按严重程度进行分类。
⑶确定用户的可靠性要求
在这个阶段应由系统设计师、软件设计师、可靠性师、测试人员及用户方代表可靠性评估小组共同根据用户提出的系统可靠性来确定软件的可靠性。
⑷进行平衡关系研究
通常应考虑可靠性和功能之间的关系以及可靠性、开发费用和开发周期之间的关系。一般来说，增加功能会导致可靠性降低，可靠性提高的程度一般与测试加强程度相对应，这意味着时间和费用的增加。
⑸建立可靠性指标
在这个阶段应对每种失效分别建立可靠性指标。通常，首先建立系统可靠性指标，然后在硬件和软件间分配。影响建立可靠性指标的因素主要有：合同或有关标准中明确规定的可靠性指标，相似产品的可靠性指标，产品的质量保证，使用已有模块的可靠性，技术能力和局限（如容错技术的使用）等。
2.2软件设计和功能实现阶段
软件设计是对上一阶段定义的每一个功能模块逐步细化，确立系统体系结构，形成若干可编程的模块。说明硬件和软件模块之间的接口及它们与外部环境的接口，详细描述各模块的输入、处理过程及输出。功能实现是根据设计方案进行软件编程。该阶段主要应做：
⑴在模块间分配可靠性指标
定义系统体系结构时，应将系统分解成模块同时保证总体可靠性指标。进行系统分解是应考虑以下因素：系统的物理特性、以前收集的数据的特性及收集数据需要的工作量等。确定每个模块的可靠性要求时，首先进行可靠性分配，然后根据试分配值计算系统的可靠性。这样及时调整，使各模块开发周期、难度和风险大致相当，系统的开发费用也才能降至最低。
⑵按可靠性指标进行设计
目前，可靠性设计有以下几种方法：设计恢复策略、使用冗余软件单元、鉴别高风险区域。设计恢复策略是指软件只须重新启动即可消除失效的设计，设计恢复应能保存修复可能破坏的数据，应具备确定失效发生时间和阻止继续运行的机制，以减少程序数据的破坏。使用冗余软件单元时是采用与原软件单元不同的冗余软件单元来提高可靠性。鉴别高风险区域采用FMEA（失效类型与后果分析）和FTA（错误树分析）的方法来进行可靠性分析。
⑶根据功能概图集中资源配置
根据功能概图把人力、物力等资源用到用户认为最重要的地方。
⑷控制错误的引入和传播
错误是引起软件失效的根本原因，所以控制每个开发步骤中引入的错误数目及未被察觉的而传入下一步的错误数目，对于控制产品的可靠性是非常重要的。错误控制受多种因素影响，其中主要有：
a.构造模块化系统;
b.进行软件重用;
c.进行单元和集成测试，阻止错误向下一开发步骤传播;
d.进行检查和复核;
e.控制改动。
⑸度量现成软件的可靠性
如果在产品中使用现成的未在本产品中开发或测试过的软件，必须对其进行可靠性证明，证明其可靠性指标在可以接受的范围内方可采用。2.3系统测试和现场试运行阶段
系统测试和现场运行以确认产品的软件要求是否得到满足，用户是否可以实际应用。系统测试阶段是开发过程阶段的最后阶段，如果措施得当，可以在产品首次使用前进一步提高可靠性。现场试运行阶段在用户环境中验证产品的各种说明及系统测试所得的可靠性指标。这个阶段的工作有以下工作：
⑴确定操作概图
操作概图是指实现系统功能的操作及其概率的集合，一个操作可以是特定环境下执行的一条命令，或同时附有限定范围内的参数或输入变量集。确定操作概图是测试计划的一个重要部分，一般在系统测试阶段之前由测试计划人员，在系统设计师和软件设计人员的协助下完成。
⑵进行可靠性增强测试
在系统测试阶段需进行可靠性增强测试。在可靠性增强测试中，系统测试员根据操作概图描述各种操作的现场发生概率，按比例的执行测试用例，通过模仿用户的应用方式可靠性增强测试，易于发现令用户最不满意的失效，能够反映出用户使用时的可靠性感受。
⑶根据测试进展并证明可靠性指标是否达到要求
在可靠性增强测试中，要收集失效数据，利用已有或自行设计并经验证的可靠性工具跟踪测试进展及规划必须的额外测试，根据进展情况在系统测试进行中可以对资源和进度安排随时做必要的调整。
⑷现场可靠性评估
系统测试阶段完成后，转入现场试运行阶段。在试运行中，从现场收集失效数据，利用此数据和软件工具评估现场可靠性，然后与系统测试结束后测得的可靠性相比较，同时对可靠性差异的产生原因进行分析。
2.4维护阶段
维护阶段是在产品用户使用过程中改正软件暴露出来的与失效有关的错误。在这个阶段监视产品现场运行的可靠性，并和预定指标及用户的满意程度进行对照比较，以便提高后继版本的可靠性，改进软件开发过程中的质量。此阶段主要做的工作是：
⑴用可靠性模型规划产品交付使用之后的人员需求，如：用户恢复失效操作的人员，承制方处理用户报告的失效的人员，承制方处理与用户报告的失效有关的错误的软件开发人员。
⑵监视现场可靠性是否达到预期指标，根据其间的差距采取相应的措施。同时还应跟踪用户是否满意，根据不满意的情况，进行必要的现场支持服务及产品改动。
⑶当加入新的功能时，通过监视可靠性，消除由此带来的失效强度增加。
⑷分析软件交付使用后的失效产生原因，指导工程的改进，降低引入类似错误的可能性。
3、软件可靠性工程成功应用的实例
美国AT&T公司的国际DEFINITYR程控交换机部在系统软件开发过程中应用了软件可靠性工程，相对于以前发行的主要软件版本，产品的质量提高是惊人的：
⑴用户反映的问题下降了10倍；
⑵项目维护费用下降了10倍；
⑶系统测试件的间隔缩短了2倍；
⑷引入新产品的间隔缩短了30%。
而且，在投入运行的前两年，从未发生严重影响业务的机器中断，客户满意程度大为提高。具体分析原因，有以下两点：
⑴把可靠性作为确定是否发行的标准，可避免用户在使用中反映过多问题和进行相应的维护工作。
⑵采用“操作概图驱动”的测试方法，提高了测试效率；20%的操作覆盖了95%的应用，20%的错误导致了95%的实效；先测试20%的使用最频繁的操作可以加速可靠性的提高。
4、结束语
关键词：软件工程；教学改革
软件工程是一门综合性程度高、知识面广、实践性强的系统学科。开设软件工程学科的目标，是为了培养具有工程能力、综合素质、扎实专业技术基础、良好团队协作能力及职业道德的复合型人才。
一、教学现状
学生因缺乏项目实施经历，在软件工程课堂内并没有体会，到了工作岗位，经历几年实践，才会对软件工程学有领悟。软件工程入门要求较高，学生在前期必须掌握程序语言、数据库技术、开发工具、系统平台等，如何针对不同专业方向的学生开展教学工作是一个巨大考验。本文改革涉及教学内容与学生工程能力评定、教学实践等方面。
二、教学改革探讨
1.教学内容与学生能力评价体系：根据美国计算机学会制定的软件工程学科要求，掌握软件工程理论的最小子集包括软件过程与生命周期模型、需求分析、软件设计与进化、测试与评估、项目管理、软件工具和环境。现有的教材，极少在一本教材上对上述内容进行全面覆盖。按照上述教学内容，对学生在实践项目中的表现做出如下能力等级认定。1.1软件过程与生命周期模型1。软件过程定义包括项目类型定义、项目规模定义、项目风险识别、项目文档的规范模板。根据需求类型、项目风险、项目类型、用户类型、团队类型进行项目生命周期选择。分为如下5个等级：1.1.1理解软件过程流程图，理解风险识别与分析活动，理解常见软件生命周期模型；1.1.2根据教师提供的项目生命周期模型选择表，从瀑布型、迭代型、增量型模型中做出选择；1.1.3选用适合的标准过程文档模板，包括过程管理类、项目研发类、项目管理类，并采用svn等工具对文档进行版本控制；1.1.4理解风险管理活动，确定风险来源，识别风险，确定风险优先级别，建立风险行动计划，跟踪风险；1.1.5分解工作任务，制定完整的项目计划书，采用project、Git等工具进行跟踪管理。1.2需求分析与需求管理2。包括开展需求调研活动，理解用户需求，产生《用户需求说明书》。进行需求分析与定义，形成基于UML建模的产品需求规格说明书。对《产品需求规格说明书》进行评审与确认。需求管理内容包括对《用户需求说明书》、《产品需求规格说明书》进行评审。需求管理员建立与维护《需求跟踪矩阵》，确保需求一致性。需求管理员建立和维护需求跟踪矩阵，管理需求变更。根据上述知识范畴，分为如下5个等级：。1.2.1理解用户需求，理解需求规格说明书内容；1.2.2通过访谈、调查、网络收集、同类类比、征询建议等方式进行需求调查，形成《用户需求说明书》；1.2.3采用UML用例图、活动图、顺序图等方式进行建模，形成符合模板的《产品需求规格说明书》；1.2.4能识别需求描述不一致、有二义性的地方，根据需求检查单确认；1.2.5能根据需求跟踪矩阵，按照已建议、已接受、已分析、已实现、已验证需求项的状态来跟踪管理，在系统设计、编程、测试等阶段对工作产品进行跟踪，更新和维护《需求跟踪矩阵》。1.3软件设计与软件进化4。可通过强调设计规范、增设设计模式内容，以极小易懂的程序为出发点，通过持续改进，让学生理解版本改动的原因，会评价一个设计的好与坏。分为如下5个等级：1.3.1理解软件设计活动，理解概要设计、详细设计、数据库设计方案；1.3.2理解面向对象方法设计原则，能用UML类图表达设计；1.3.3根据需求文档，能产生实体-联系图，将实体间关系转化为表间约束，尽量优化表结构；1.3.4能够基于复用、可维护的考虑，进行一定程度的软件重构；1.3.5撰写数据库设计、概要设计说明书，执行设计规范、编程规范。1.4测试与评估。制定测试计划，编写测试用例，规定输入与预期输出结果、测试步骤。执行测试用例，进行测试分析，形成测试报告。分如下5个等级：1.4.1理解需求，编写系统测试用例，合理运用等价类分析、边界值分析等设计方法；1.4.2理解设计，编写集成测试用例和单元测试用例，能搭建测试环境，手动执行，并记录测试结果。理解缺陷管理，发现缺陷，填写测试报告并执行回归测试；1.4.3能使用自动化测试工具，编写测试脚本，运行脚本执行测试，将发现的问题进行报告。使用Bugfree等工具管理和维护缺陷，确保项目提交时，缺陷的状态均为关闭；1.4.4能使用大型测试管理工具进行测试计划、测试管理、跟踪需求、设计等变更对测试的影响；1.4.5采用工具进行性能测试、安全性测试、压力测试等方面，能够进行测试场景设计、脚本编写、执行和报告。1.5软件工具和环境。工具包括建模工具、开发工具、测试工具、配置管理工具、项目管理工具等6。分为如下3个等级。1.5.1在工程类活动中采用建模工具、开发工具、测试工具；1.5.2在管理活动中采用配置管理工具、项目管理工具进行项目策划、风险监控、项目监控活动；1.5.3能够根据团队人数和项目情况，选择适合项目特点的工具。1.6项目管理。强调人员、产品、过程、质量的关系，包括项目策划、项目跟踪与监控、项目风险与管理、软件质量保证、项目配置管理等。分为如下2个等级：1.6.1理解项目过程管理，定期召开例会，编写个人周报，会议纪要，进行问题追踪，坚持执行规范；1.62理解项目立项策划、项目监控、风险及结项管理，并从团队实践项目中进行组织级总结。上述六个关键内容上，不要求学生在每个活动上能力认定都达到几，可通过每个关键活动上分别评定，最后计算加权平均值的方法，折算学生的最终成绩。2.教学措施。避免一言堂式教学方式，创造引导和探讨式、学生自启发式教学模式。可采取以下措施：2.1教学采用小班制教学，学生分为三五人制团队，自我管理和团队合作完成实践项目。2.2引导学生自拟实践题目，协助定义软件过程，协助制定软件进度计划，并提供软件标准文档模板和工程标准规范。2.3引导学生在每周召开例会，完成对项目跟踪追溯。例会的内容可加入软件技术的规范、风险意识的培养和训练、软件文档写作等内容。2.4教学案例可选用一般信息管理案例讲述，项目知识不宜超出学生认知范围。2.5专家来访，引入课堂。营造良好的学习氛围，企业工程师与学生分享和交流工程应用、企业管理方面的最佳实践和教训，培养学生工程意识。2.6结合学生不同专业方向，对实践案例做出选择。软件测试方向重在理解需求、掌握软件测试工具、软件测试管理工具、自动化测试、性能测试工具和测试报告写作。嵌入式方向重在嵌入式平台使用、设计模式、UI设计、UML与软件设计、手机客户端和服务器设计实现、嵌入式数据库应用方面。游戏设计方向重在游戏策划、工程标准和规范、游戏引擎工具、项目管理工具、版本控制工具、游戏测试等方面。2.7启发学生学习新技术，包括大数据、交互设计、CMMI能力成熟度模型及标准。
三、结语
本次课程改革集中在教学内容、教学措施、能力认定等方面。软件工程课程改革是一个长期和持续过程。在实施中取得的成效值得我们不断思考和总结。
参考文献：
[1]方智.面向对象编程思维的建立和培养[J].实验科学与技术,2013年06期.
[2]张海藩.软件工程导论(第6版)[M].北京：清华大学出版社,2013.
【关键词】NESTOR；软件工程化；过程管理
0引言
核电设计分析以及运行支持软件是开展核电工程设计以及维护核电厂运行的重要技术手段之一，对核电工程设计科研工作的质量、研发效率以及核电厂的运行安全起到了至关重要的作用。由于核电设计分析以及运行支持软件具有很强的核安全相关性，多年以来，国外核发达国家对核电软件设计研发以及运行管理都是高度重视的，相关软件研发的各个流程环节、软件适用性、可靠性、过程质量管理以及后续的应用均受到核安全监管机构的高度关注。与此同时，在国内，核电相关的安全也受到了核安全监管机构的高度关注。针对核安全相关软件，国家核安全监管机构也制定了相关的软件评价实施办法。根据相关实施办法，核安全相关软件的认证过程不仅重视软件的重要物理现象识别、物理模型建立、验证计算模型的合理性以及不确定性和敏感性等评价，对软件的研发过程、研发体系以及质量保证体系的建立也同样重视。在中核集团龙腾自主创新科研项目的支持下，由中国核动力研究设计院牵头，中国核电工程有限公司、中核武汉核电运行技术股份有限公司参与共同完成了成体系的核电设计与分析软件包NESTOR（NuclearPowerPlantEngineeringSoftwareTechnologyResearchProject)）。NESTOR软件包包含了核电设计与分析所需要的相关专业软件，涉及核反应堆物理设计、屏蔽与源项设计、热工水力与安全分析、燃料元件相关设计、系统与设备设计、仪控设计、软件共性技术等相关领域。NESTOR软件项目自2011年立项以来便高度重视软件研发体系建设，并针对“软件开发过程质量保证体系与开发规范”成立单独的课题进行研究。该项目致力于将核电工程设计与软件工程化相结合，贯穿研发全生命周期，覆盖需求管理、模型研究、软件设计、VV流程等各个环节，建立健全核电软件工程化研发体系，并在NESTOR项目中的各个软件开展软件工程化实施流程。长期以来，建立适应核电工程特色的软件工程化研发体系，并将体系融入工程设计、科研及管理工作中，一直是NESTOR项目的重要研究方向之一。
1核电软件工程化体系建立
核电设计分析软件以及运行支持软件具有高可靠性、高安全性、高经济性的特殊要求。在国家核安全导则、GJB5000A、CMMI等软件工程化的总体指导要求下，遵循软件工程化思想，建立一套具有核电工程特点的完善的核电软件工程化研发管理体系，对确保研发团队开发出高质量、满足核电核动力工程需求的软件产品起到重要的保障作用。中国核动力研究设计院经过多年的研究及实践应用，制定了覆盖软件工程化研发中的重要过程域的指导性文件《软件工程化体系文件》。
2NESTOR软件工程化实施过程
软件工程化研发的实施主要覆盖软件开发过程和软件管理过程。针对NESTOR软件，主要分为工程化主机平台类软件以及嵌入式软件。软件的开发过程依据软件的类型以及规模等属性，选择适用的软件生存周期模型，并定义软件开发的阶段及阶段中的活动。软件管理过程主要包括需求管理、项目策划、项目监督与控制、过程和产品质量保证、配置管理、测量与分析等过程，软件项目的管理过程中的活动可根据软件的自身特点进行裁剪。
2.1核电软件的管理过程实施
2.1.1项目初始管理策划
在接受核电软件研制任务后，应落实项目组主要成员，并组织各阶段工作安排。项目负责人根据《软件研制能力等级要求》，组织对项目软件的重要性等级和规模等级进行确定。最终形成《项目软件工程化策划书》，作为开展核电软件工程化研发的输入。
2.1.2研发过程规范制定
NESTOR项目结合自身的特点，建立了一系列的研发过程规范，规范由项目部批准后应用于本项目所承担的所有核电软件研发中。
2.1.3项目监督与控制
核电软件项目的监督与控制是将软件项目的实际执行情况与相关计划要求进行对比分析，如超出偏差范围，则采取必要的纠正措施。如软件需求发生重大变化，则修订计划以满足相关要求，从而确保项目研发工作有序、正常的实施。
2.1.4核电软件项目过程和产品质量保证
开展质量管理的策划工作，主要目的是识别NESTOR项目及其最终交付成果的质量要求及规范标准。通过有计划地、定期地对NESTOR相关软件全生存周期的开发与管理活动进行符合性检查，对各阶段工作产品与活动进行审核来判断研发工作是否按照软件工程化体系的要求实施，从中发现不符合项并实施相应的纠正措施。
2.1.5项目配置管理
配置管理是结合配置管理工具对开发的软件进行版本管理与变更控制，对软件开发过程的各阶段工作产品进行有效保护，维护阶段工作产品和软件产品的完整性和可追溯性的管理过程。NESTOR项目相关软件的配置管理贯穿于软件研发活动的全生命周期以及各个流程环节。NESTOR项目采用专门的软件配置管理工具，对程序源代码、版本、各阶段文档、工况数据及流程进行有效的配置，实现了研发过程的自动化配置和动态管理，增加了软件研发人员对设计流程的能见度。NESTOR项目在配置管理实施中建立了软件开发库、受控库以及产品库，并限定配置项在不同库之间的流转的权限及流程的控制。通过实施配置管理有效地保证了软件的正确性、完整性及可追溯性。
2.1.6测量与分析
测量与分析是NESTOR软件项目各软件设置有专门的测量分析工程师，该人员负责依据既定的测量目标、测量项、数据采集和存储规程、分析规程等相关要求采集和分析测量数据，在合适的控制点/项目结题时采集并汇总相关数据，形成测量分析信息。项目执行的过程中，相关的测量分析信息及时专递到项目组团队成员内以及利益相关方。通过测量与分析活动，有效的监督了项目绩效，并为后续活动做出有根据的管理和技术决策，以便在出现问题时及时采取相应的纠正措施，实现项目监督控制的可视性、及时性
2.1.7项目评审
在软件开发与管理过程中，针对重要节点或者里程碑组织软件项目组内部及外部人员对NESTOR软件产品、研发活动及工作进展情况的符合性、合理性和正确性进行验证。通过评审活动，可以高效率、尽早发现并消除问题，从而保证软件产品的最终质量。
2.1.8记录控制
为满足软件工程化体系要求，NESTOR项目实施工程化研发过程中所产生的记录、以及能够证明体系文件有效运行的记录、作为可追溯性依据的记录均进行了有效的控制。通过核电管理平台，对项目实施中产生的所有过程记录文档进行分发、流转等控制，过程记录包括技术传递单、技术联系单、备忘录、会议纪要、设计评审报告、项目周报、QA核查单、质量保证报告、配置管理报告等。同时，通过档案管理系统，对项目所产生的所有设计文件进行有效的归档及控制。
2.1.9软件的鉴定与应用
研发完成的软件，在未经过专业鉴定前仅可用于学习、科研，不能直接应用于工程设计。软件的鉴定是专业设计人员对入库归档的软件产品进行专业分类及筛选后，由软件鉴定专家委员会对筛选后的软件进行鉴定。鉴定软件的功能、性能、工程适用范围、可靠性等各方面能够满足相关工程使用需求。NESTOR所研发的软件只有通过鉴定才能够归入工程可用软件库。当工程项目产生软件应用需求时，即可从工程软件库中选择合适的软件。
2.2核电软件的开发过程实施
2.2.1核电软件研制策划
NESTOR软件研制策划工作是估计NESTOR软件包中每个软件的规模、开发工作量，并根据估计结果，结合进度要求来制定合理的开发计划，提出必要保障条件的管理过程。本项工作主要由项目软件负责人组织，对所负责软件的根据各项软件的开发和管理工作进行全面的策划，并安排相关角色依据既定的分工制定所需研制软件的各项计划，最终以书面的形式形成《软件开发计划》、《软件配置管理计划》、《软件质量保证计划》、《软件测量分析计划》、《软件验证和确认计划》、《文件清单》以及估计记录等相关文档，文档经过评审后生效执行。相关文档是软件开发过程中各项活动的重要依据文件，并将随着软件研发过程而细化或调整.
2.2.2核电软件需求分析
NESTOR项目结合核电工程软件特点，在需求阶段开展了详细的需求理解、需求确认、需求跟踪等需求分析活动，需求包括功能需求以及非功能的需求。需求分析是软件生存周期中最重要的一步。只有通过需求分析，才能准确地将软件的功能以及非功能的需求从概念描述转换为具体的可测量的规格说明形式。NESTOR项目的各个软件在需求分析阶段都依据软件的相关需求完成对应软件的需求分析活动，并以书面的形式形成《需求说明书》/《需求分析报告》，同时建立并维护需求跟踪矩阵。NESTOR项目在开发的过程中持续跟踪维护需求矩阵，确保了需求与项目策划的一致性，并在必要时进行变更。
2.2.3核电软件设计与实现
软件的设计是在需求的基础上，对软件开展计算部分的设计以及界面设计工作，计算部分包括系统结构设计、数据设计、接口设计、算法以及过程设计，界面部分的设计工作包括界面原型设计以及界面设计，软件设计即是把需求转换成表达的过程。在设计活动完成后，软件的设计工程师需要依据体系文件以及相关规范编制相关的《软件设计说明书》，设计说明书可依据软件规模或者复杂程度拆分成《概要设计说明书》以及分模块的《设计说明书》。在软件的实现阶段，按照对应的编码规范，依据设计结果实现软件编制、编译和调试，编制《软件编码报告》以及《用户手册》。《软件编码报告》主要对软件的数值计算及界面模块的目录结构、模块结构、全局数据、各模块的功能和数据，以及软件的编译运行方式、集成方式进行描述《用户手册》主要对软件的功能、性能、运行环境、安装以及操作说明进行描述，给最终软件使用对象对软件的使用有直观的了解。
2.2.4核电软件测试及验证
软件测试是由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满足规定的需求。测试活动由软件测试工程师负责，在测试的策划阶段形成《软件测试计划》并开展测试设计，包括测试用例说明等相关文档。NESTOR项目的测试计划以及测试说明文档均经过评审，以确保测试工作的有效性。测试工作严格按照计划及测试说明执行，对测试过程发现的缺陷应进行报告、确认、修正和验证，并形成缺陷记录单，通过多轮测试及回归，确保缺陷全部关闭或得到妥善处置。测试完成后编制《软件测试报告》。通过测试的软件，由独立于开发团队的验证工程师，通过确认用例对软件进行验证，确认用例包括基准题、实测数据（试验数据或电厂运行数据）等，通过验证确保软件的功能、性能以及计算精度满足预期。采用第三方验证的方式对所开发软件的正确性进行确认
2.2.5核电软件
VV验证和确认遵循GJB5000A要求以及软件工程化体系执行，从VV的过程、过程中包含的VV活动，再到具体的VV任务，多层次全方位地定义验证和确认流程。N开展VV活动是确保NESTOR软件的质量和可靠性的重要措施，通过VV活动确认各项需求以及设计要求正确实施，识别期望的结果和实际结果之间有无差别，有效地提高软件计算的精度并保证软件的正确性，确保NESTOR软件质量。除了项目团队内的VV团队，NESTOR项目还创新的采用软件研发合作模式，邀请了高校测试组、专业测试公司以及第三方验证团队，针对开发的核电软件根据相关行业内规范开展了第三方独立的测试和验证。通过有效利用外部资源，对软件的功能、性能进行全面的测试验证分析，有效地摒除了内部团队在相关工作中的“程式”思维、思路局限性而带来的漏洞，更多的发现软件运行中的问题，进一步提高所开发核电软件VV的全面性和客观性。
2.2.6核电软件结项
软件研制完成后，项目软件负责人组织对软件的测试验证情况进行分析，根据项目目标要求，组织总结分析工作。就软件的研发工作进行总结，组织编制《软件开发总结报告》，另外，还有软件开发过程中的相关配置管理情况、质量管理情况进行总结，编制《配置管理总结报告》以及《质量保证总结报告》。相关总结文档完成后，组织项目结项评审，软件具备结项条件后，提交验收申请并组织验收，形成验收报告。
3结语
NESTOR软件包通过结合广泛的工程经验，依托科学理论和软件工程化技术的进步，形成了重要的自主创新能力，成功应用于华龙一号工程设计与校核，并正在进一步应用于其他核电工程开发中。部分运行支持软件也已在国内多个核电厂推广应用，发挥了良好的经济效益。通过工程化管理体系的建立以及对软件工程化的过程管理实施，NESTOR软件包的研发工作以及运行管理实现了流程精细化管控以及监督可视化、可控化。确保了NESTOR软件在满足工程需求同时，提升了研发效率、缩短了研发周期，提高了软件的质量，大大减轻了运行管理成本，提升了软件研发精细化管理水平。
【参考文献】
［1］张晓龙.现代软件工程[M].清华大学出版社,2011.
［2］林锐,彭国明.CMMI和集成化软件研发管理[M].北京:电子工业出版社,2008.
［3］姜霄雪,严建平,蒋剑伟.基于CMMI的过程和产品质量保证过程研究与应用[J].广东通信技术,2017,37(04):77-79.
关键词：UML 软件测试 卓越工程师
一、软件测试教学现状
由于软件测试技术发展起步比较晚，测试人员数量少，测试重视度不高，测试费用投入较少，从而导致我国的软件测试行业上在理论和实践上都比较滞后。随着软件行业蓬勃的发展，近年来，软件测试技术也得到了迅速发展，全国高校都陆续成立了软件学院并开设了软件工程相关专业。2010年6月，教育部启动了“卓越工程师教育培养计划”以促进工程教育改革与创新。在这样的契机下，我校结合软件工程专业教学的需要积极申报了卓越工程师培养计划，并得到了江苏省教育厅的立项，随之软件测试这门课程也得到校级优秀课程建设的支持。不过该课程面临如下问题：
第一，软件测试相关课程的老师缺少大规模软件开发的经验，而且对软件公司关于软件测试的需求目标并不是很明确。第二，软件测试的教学对象是大三第一学期的学生，他们对软件设计和软件开发还缺少系统的编程训练，同时也缺少系统的项目开发经验，而且学生对测试的重要性理解不够使得学生普遍喜欢学习开发和编程技术，而轻视软件测试技术。第三，由于高校教学每门课程基本上都是由不同的授课老师来完成导致软件开发和软件测试的课程衔接上存在问题，软件开发和测试的授课内容基本脱节，并导致软件测试课程所需的教学测试用例缺少，需要再花时间来编写，占用了软件测试的教学时间。第四，目前软件设计技术已经由面向过程转向了面向对象设计，目前以统一建模语言（UML）为基础的软件设计技术已经普及，但以UML为基础的软件测试技术（UML Testing Profiling，UTP）远未出现在当今高校的软件测试教学中，也是就是说软件测试的教学内容严重滞后。
因此，本文通过如何提高软件开发和测试的项目经验，如何提高学生对软件测试的重要性，如何将软件设计和软件测试相结合来提高软件测试这一门课程的教学质量。
二、软件测试教学方案改革
1.结合卓越工程师培养方案提升软件测试课程教学质量。卓越工程师培养方案以产品研发、运行、维护直到废弃的全生命周期为载体，建立一体化的教学体系，为学生提供实践、理论课程有机关联的教学情景，整个过程与软件开发的周期不谋而合，该方案“以人为本”，有助于高校实现“大工程”的培养目标，从而实现培养具有职业道德，工程伦理等方面的学生。同时该方案“边做边学、边学边研、边研边创”，有助于高校改革软件工程专业课程体系，把自然科学知识，工程科学基础，专业知识技能工程能力有机融合到一起，全面实施工程素质教育。
2.将软件开发与软件测试课程相结合的一体化教学课程。美国麻省理工学院（MIT）和瑞典的查尔摩斯工业大学等得出了CDIO工程教育模式：构思（Conceive）、设计（Design）、实施（Implement）和运行（Operate）。该模式的主旨是以产品研发、运行、维护直到废弃的生命周期为载体，以一体化教学为目标。为此，借鉴CDIO的教学模式，我们改进了软件工程的教学模式，强调设计规范和详细的实践教学方案，对实施过程阶段考核，并对实践教学的考核评估机制进行改革，构建了多元化、复合型的实践教学考核评估机制。在软件开发教学中从需求分析和详细设计就使用UML对软件开发进行建模，并预留了对后期软件测试的用例设计。
3.以项目为主导增加学生软件开发经验。不论是CDIO工程教育模式还是卓越工程师的教学培养方案，都是以工程化的教学为主，因此，为了提高学生的工程化实践能力和软件开发能力，学校积极与国内外的大型软件公司合作，比如达内，微软和印度的NIIT公司，对学生了进行专项的训练。通过实践项目的训练使得学生掌握了面向对象软件开发的基本流程，熟悉了使用用例图表达需求分析，熟悉了使用类图表达整个软件系统的静态模型，掌握了使用序列图和交互图来表达用例的动态行为，掌握了使用活动图和状态图来表达软件的状态变化，同时也学会了如何设计软件测试用例，如何编写软件测试计划，如何搭建软件平台和编写相应软件测试驱动和桩模块。
4.软件开发和软件测试以UML及UTP指导的工程化教学思想。由于软件测试产品中存在着压力负载性能，时间性能、安全测试性能等约束，使得UML无法直接支持这些约束的测试建模，UTP就是对UML在软件测试建模进行扩展得到的。它不仅可以支持软件测试的用例设计、结果可视化、结果规格说明，还可以软件测试过程和构造以及软件测试结果进行文档化，而且支持从单元测试，集成测试，系统测试和用户测试等各个级别的测试建模。因此，在UML软件建模和需求分析课程中强调了与UTP结合，并从软件的需求分析，概要设计和详细设计中不仅体现了UML软件建模的手段，而且提前考虑了软件测试的需求，对测试方法和管理办法及测试用例进行了详细的分析，并对软件测试的管理方法，测试用例，测试环境进行了详细的建模分析。
5.加强软件测试课程体系的建设和师资的培养。在软件开发和软件测试使用UML和UTP进行一体化的授课。第一，提高对软件测试课程的教学重视度，提高学生对软件测试的重视度，让教师在软件开发中做软件测试教学，让学生在软件开发中学软件测试。第二，及时引进办国内处软件测试的教学教材。选择质量高、知识内容新颖的软件测试的教材，并尽可能的使用配套对学实验指导系统培训实验指导书的教材。从大二开始有规划地对学生进行软件开发和测试培养，并以软件测试项目为主线，在大二第四学期和大三第四学期开设的软件开发课程中，比如JAVA，等课程中都安排软件测试的教学内容，并以软件开发项目为中心使学生掌握软件测试工作中需要的技能，比如黑盒测试中的等价类划分法，边界值分析法等，白盒测试中的控制流测试方法，基本路径测试技术等方法。熟练使用相关的测试工具，比如黑盒测试技术的WinRunner等，白盒测试技术的CPP unit和Junit等工具。第三，提高教师队伍的软件测试素质，有计划的安排教师到软件公司参与实践，增强软件测试的案例分析能力。
三、结论
软件测试技术在软件行业越来越显得很重要，软件测试人员在整个软件开发中的地位也越来越作用明显，然而国内整个高校对软件测试的教学课程体系明显有待提高。本文通过结合我校的实际情况，对软件测试的教学人员、教学方法和教育理念进行了梳理，并提出了五条合理化的提高软件测试教学的可行性建议，对于国内开展卓越工程师的学校提供了参考。
参考文献
[1]蓝新生，封二强，郑军.基于UML Testing Profile的软件测试过程浅析[J].环境与可靠性，2015（8）：49-51
关键词：测试风险 风险识别 应对计划措施 风险控制。
一、前言
吉林省电子信息产品监督检验研究院/中国赛宝（吉林）实验室（）始建于1973年，隶属于吉林省工业和信息化厅，是非盈利性事业单位，业务领域涉及电子元器件及液晶、家电、视听、安防、计算机、通讯、医用电器设备、电池等电子应用产品及计算软件产品、网络系统、信息安全的质量监督、检验、鉴定和仲裁，其中，软件产品测试业务是我院重要的一项核心业务。我院软件产品测试业务于2004年通过了中国合格评定国家认可委员会（CNAS）的评审，是省内唯一授权的第三方软件评测机构，同时，也是我省双软认定工作中唯一指定进行软件产品登记测试的单位，现开展软件测试服务已经10余年，主要开展的项目有：软件产品的登记测试、鉴定测试、确认测试、性能测试、验收测试、定制性测试、白盒测试等。经过多年的持续发展，目前拥有一批高素质、高水平的专业测试人才队伍和先进的测试设备，优质、高效地完成了各种类型的软件产品测试项目，得到了广大客户的高度认可和好评。
二、背景和立意
软件测试风险管理在软件测试项目中的地位是不容忽视的，本文主要通过对软件测试项目在测试风险管理方面的相关内容的讨论，使读者从中会体会到软件测试风险管理对测试项目的重要性和给项目带来的帮助。
三、以“锅炉优化燃烧专家诊断系统”软件的测试风险管理为例，论述软件测试的风险管理。
1、系统描述：
“锅炉优化燃烧专家诊断系统”软件（以下简称本软件）应用于锅炉设备燃烧情况的监测领域，通过温度场范围、烟气场范围、计算诊断结果范围等初始参数设置，模拟量量程、一次风差量程等串口设置，及开始设置、保存数据等模块，实现了锅炉内部温度场及烟气场的情况推算及结果显示等功能。对本软件测试的要求是在20个工作日内完成本项测试任务，在最后回归测试时的结果需达到预期要求。
2、测试类型：功能测试
功能测试是黑盒测试，是对软件产品的各项功能进行验证的测试，注重于测试软件的功能性需求。
3、编制测试风险管理计划
在测试的初期，我们会编制测试风险管理计划，主要描述如何在对本软件的测试中处理和执行风险管理活动在责任、资源、时间等方面的安排。我们全面考虑了风险对测试的影响，制定了充分的测试风险管理计划。其中，我们详细编制了单个测试风险管理计划和综合测试风险管理计划，为后续实施的测试风险管理做好了准备，并形成了依据。
4、测试风险识别及测试风险分析
本软件测试之前，我们以会议讨论的形式，根据以往的经验，列出检查项目列表，并进行分解，通过假定分析，最后研究、识别、确定了影响测试计划实施的因素。
我们还对预测的测试风险进行了分析，确定测试风险对测试的影响程度及发生几率，并对风险进行量化、选择、排序，确定哪些风险是可以接受的，哪些风险是必须要应对的，哪些风险是可以忽略的。进行测试风险管理应该把主要精力集中在那些概率高、影响力大的风险上。
经过测试风险识别及风险分析，确定测试过程中我们主要关注的可能存在的对测试影响程度大的主要风险，如下：
（1）由于本软件是针对锅炉设备燃烧情况的监测领域的软件，需要测试人员对锅炉设备燃烧情况的监测领域相关知识有所了解，故测试人员对锅炉设备燃烧情况的监测领域了解不足或不了解，导致测试人员对被测系统的业务流程不熟悉，对需求的理解上把握不准、理解不透彻、理解错误等，对测试形成风险。
（2）测试人员出具软件测试问题报告单后，与企业开发人员交流时，开发人员对发现的问题理解程度不佳，导致对测试问题的修改不满足要求，或由于企业原因，企业再次报送相关修改结果速度过慢。
（3）测试人员实施测试时的测试方法有错误或缺失，导致对功能点没有采用正确的测试方法，或某些测试方法被忽视，如边界测试等，导致测试不充分。
（4）测试环境出现故障，给测试带来的影响。
5、测试风险应对计划措施
对已识别的主要风险制定的对应应对计划措施，如下：
（1）请企业相关人员培训测试人员学习锅炉设备燃烧情况的监测领域的相关知识，测试人员也要通过网络和书籍多查找锅炉设备燃烧情况的监测领域相关资料，做好测试前了解行业知识的准备。
（2）加强对测试人员的沟通能力和服务意思的培训，保证测试人员能详细、认真、准确的讲解测试问题报告单中体现的bug，使得企业软件开发人员能明白测试人员的讲解，并确认软件中存在的bug，及时快速的修复bug，且在与企业人员沟通中，强调测试进度及修改速度的重要性，督促企业人员尽快再次报送相关修改结果，保证测试按测试计划完成。
（3）加强对测试人员测试方法相关知识的培训，要求测试人员主动翻阅历史测试经验的积累记录，充实经验方面的不足，并向有经验的人员请教。
（4）严格按照软件文档的要求搭建测试环境，尽量避免测试环境出现故障，安排1名维护人员（兼职），当测试环境出现故障时，尽快安排维护人员整修、排除故障，尽量减小对测试进度的影响。
6、测试风险控制及实际测试情况
在进行测试的过程中，我们会对已识别出的测试风险的状态进行跟踪，监控测试风险的发生，做好对测试风险的监督控制，及时应对已发生的测试风险，并深入分析，继续识别新出现的测试风险，复审测试风险应对计划措施的执行情况和效果，根据实际情况修改测试风险应对计划措施，对新识别的测试风险，制定新的测试风险应对计划措施。
在实际测试时，我们对已出现的测试风险按照测试风险应对计划措施做好了相应的应对措施，效果十分明显，有效的避免了测试风险对测试的影响或把测试风险的影响降到了最低，但还是由于企业原因，企业再次报送相关修改结果过慢，影响了测试进度，我们对晚报送的修改结果进行了加班测试、并添加测试人员的应对措施，虽然根据测试计划规定，实施测试的时间延期了1天，但我们缩短了出具测试报告的时间，使得测试任务按时圆满的完成了，测试结果得到了客户的认可，而且，我们在测试的过程中给企业提出了许多规范、改善、优化企业软件开发或维护方面的建议，企业人员对我们的建议予以接受，同时，企业对我们的服务态度及服务质量给予了高度的评价和赞扬，肯定了我们各方面的服务。
四、总结
通过对“锅炉优化燃烧专家诊断系统”软件的测试风险管理案例的讨论，论述了怎样进行软件测试的风险管理，总结了本人对软件测试风险管理的认识和积累的经验，希望能通过本文使读者有所收获。
对软件测试管理方面的研究，我们还要继续努力，不断加强测试管理方面的知识积累及探索，提高测试管理方面的能力和水平，使自己成为优秀的软件评测员及测试管理员。
参考文献：
[1]《软件测试方法和技术》作者：朱少民；出版日期：2005年7月；出版社：清华大学出版社
执行标准：
[1]《GB/T 17544-1998 信息技术 软件包 质量要求和测试》
[2]《GB/T 16260.1-2006 软件工程 产品质量 第1部分：质量模型》
[3]《GB/T 16260.2-2006 软件工程 产品质量 第2部分：外部度量》
【关键词】质量管理
1前言
2015年6月，作者参与了“XXXX”软件项目（以下简称为S软件）主管一职，任务来源于航天系统外部客户，XXXX应用于航天XX卫星载荷分系统导航任务处理机计算机模块S，主要目的设计支持应用程序的上载和重构功能。由于本软件应用于航天卫星系统，对软件质量、可靠性和安全性要求较高，本软件的开发过程中结合国军标GJB5000A能力成熟度模型三级的框架要求（相当于CMMI三级要求），以及软件工程学的质量保证策略进行项目的质量保证工作。S软件类型为新研类项目，使用C语言编码。软件的生存周期包括：软件需求分析、软件设计、软件实现、单元测试、集成测试、配置项测试、软件验收交付7个阶段，由于S软件应用于航天系统，可靠性安全性要求较高，需要对每个阶段的工作进行认真的评审和审查，所以整个阶段采用瀑布模型进行软件的研发。2016年1月，S软件已随卫星发射，目前卫星在轨运行，本软件运行正常。
2软件开发平台下的质量保障
下面作者以此软件开发平台项目为背景，论述了如何在公司质量管理体系大环境下，进行项目的质量规划、质量保证和质量控制等项目质量管理工作。
2.1项目初始阶段，对组织级项目管理过程进
行剪裁，制定项目的已定义过程作者所在的公司是一家科研研究所，我所已经建立ISO9000质量管理体系,也通过了国军标GJB5000A能力成熟度模型三级认证。我所具有较为完备的项目管理体系文件，其中包含了质量管理体系。我所制订了相关的质量方针和目标，落实了质量责任。按照我所项目管理流程，项目管理团队在项目启动后需要对组织的质量管理过程以及相关的项目管理过程进行剪裁，剪裁过程依据我所制定的过程剪裁指南执行。为保证用户需求不被遗漏、蔓延，为项目制定了需求双向跟踪矩阵，并根据体系文件《需求管理过程剪裁指南》，将需求双向跟踪矩阵包含在《需求规格说明》中；根据《工程过程域剪裁指南》将《概要设计说明》和《详细设计说明》合并为《设计说明》；过程和产品质量保证过程的工作产品输出为：质量保证计划、不符合项记录、产品评价记录单、过程评价记录单、软件质量保证报告。剪裁完毕后，形成本项目的已定义过程，之后我作为项目经理组织了同行评审，邀请项目组成员、相关专家、以及所EPG组成员参与，经过评审通过后，作为本项目执行过程中的指导。并将已定义过程写入开发计划的一个章节，作为制定质量管理计划的输入之一。
2.2项目计划实施阶段，制定质量计划、实施质量保证和质量控制
在完成项目管理的剪裁和开发计划后，作者领导和组织质量保证人员开始制定项目的质量管理计划。在质量管理计划中，明确了组织和资源，人员的分工；明确了质量目标；明确了质量保证活动和进度安排、以及使用的工具；明确了质量控制过程、进度安排、以及使用的工具；明确了工作产品和过程不符合项的解决和处理途径，软件BUG的管理。作者和项目组成员进行了充分的沟通，明确了质量对项目的重要性以及大家如何做才能保证项目的质量，使大家对于如何实现项目的质量目标充满了信心。使大家就以下内容达成了一致：（1）项目的质量是靠规范的项目管理流程和质量保证人员对项目的监管，而不是单靠测试保证的；（2）要十分重视项目的质量成本，越在项目早期发现的错误，纠正的成本越低。（3）项目质量目标的达成需要全体项目成员的参与，而不是个别人的事，质量保证人员在对过程和产品评价过程中指出的问题，项目组所有成员都应予以配合，及时纠正。根据规划，在项目实施期间，质量保证人员对软件工作产品和工作过程进行评价。过程评价依据组织级过程检查单，对工程过程和管理过程进行评价，包含需求分析需求分析过程、软件设计过程、软件实现过程、软件测试过程、需求管理过程、配置管理过程、项目管理过程、同行评审过程、测量分析过程的评价。除配置管理过程由事件促发评价外，其他过程评价每周一次，生成不符合项记录和质量趋势评价报告，对发现的质量问题用Excel进行统计分析。工作产品完成后两天内由质量保证人员完成审核，然后开展同行评审。对质量保证过程中发现的不符合项，形成不符合项纪录，及时通报给相关责任人，遇到质量保证人员和责任人意见不一致则逐级上报，先汇报给作为项目经理的作者，对仍不能解决的问题，再汇报给部门领导。考虑到本软件应用于航天系统，对质量要求较高。对本软件的源代码由测试组人员开展了单元测试、集成测试、配置项测试，测试组人员设计了相关的测试用例，单元测试语句和分支覆盖率均达到100%；在集成测试中，制定了模块设计和集成测试用例的双向跟踪举证；在配置项测试中，根据《需求规格说明》，制定了需求和配置项测试用例的双向跟踪举证。除开展单元测试、集成测试、配置项测试外，增加了代码走查，由每个模块的二岗设计师按照《航天软件C语言安全子集》要求对代码进行代码走查，形成走查报告，及时发现问题，修改代码直至符合要求；对关键模块代码进行代码开展同行评审；并请专业测评机构对软件开展第三方测评。对所有工作产品进行同行评审，对需求规格说明和配置项测试报告开展了用户参与外部评审，形成评审报告，对评审过程中发现的问题，有质量保证人员跟踪验证，直至问题关闭。对测试过程中发现的BUG，使用TestDirector进行BUG的跟踪、管理，直至问题关闭。对软件源代码和相关技术文档使用SVN<<上接59页系统进行配置管理，工作产品经过评审并对评审问题经质量保证人员验证关闭后进入配置管理系统，对交付用户的工作产品，待验收通过后需入产品库，再交付用户，保证了软件版本的有序性和正确性。
2.3项目收尾阶段，总结经验教训，丰富组织过程资产
在项目交付时，由用户和相关部门领导、资深工程师组成的评审委员会，对项目的成果进行了验收。认为项目的主要交付物已达到用户要求，可以交付用户使用，参与XX卫星载荷分系统的分系统联试。但也提出技术文档和源代码版本的配套说明欠缺，在《版本说明》文档中加以描述，经过评审后，入配置管理受控库。之后，源代码和需交付用户的文档入我所产品库后交付用户。作为软件开发主管，组织了项目组成员开展了项目的总结会议，分析了项目执行过程中的经验和教训，形成项目总结报告，并归入我所资产库，作为历史数据供后续项目参考。对质量保证过程检查单进行了修正，经过评审通过后，也归入组织资产库中，丰富组织过程资产。
3结语
购物车(0)
