软件测试年度工作计划例1

白晓颖，清华大学副教授、计算机系软件研究所副所长，主要研究领域为软件工程，研究方向包括软件测试、分布式系统、服务计算等。童年时父亲从国外为她带回的一个小小的游戏机，为她打开了通向计算机的一扇门。长大以后，她真正走入了这扇门中的那个计算机的世界，并且不断攀登前行，走到了如今的辽阔天地。1995年毕业于西北大学计算机系之后，她考入了北京航空航天大学计算机系攻读硕士。三年后硕士毕业，远赴美国继续攻读博士学位，先后就读于美国明尼苏达大学和亚利桑那州立大学。2001年底，她学成回国，进入清华大学任教。

2001年7月，我国申办2008年奥运会成功，举国欢腾。2001年12月，北京奥运会组织委员会正式成立，虽然当时距2008年奥运会还有6年多的时间，但是大量的准备工作都要开始着手进行。从2002年1月份开始，奥组委开始着手成立各个领域的相关部门。技术部是最早筹建的部门之一，负责奥运会信息系统、通信系统及场馆技术系统的相关工作，年轻的白晓颖参与了清华大学计算机系与奥组委技术部的科技攻关合作，成为技术部的一员，白晓颖笑称自己是北京奥运会最早的“技术志愿者”之一。

信息系统已经成为现代奥运会成功的基础和保障。奥运会信息系统结构复杂、涉及面广，项目实施规模大、周期长、风险高、难度大，也是奥运科技系统中技术含量高、应用范围广的主要部分之一。奥运会信息系统体系结构分析是充分了解系统特点，有效控制系统质量、进度、预算的前提和保证。奥运会信息系统包括运动会管理系统、计时记分系统、现场成绩处理系统及成绩系统四个主要部分。各子系统及相关模块分别由位于不同国家的不同机构承担，包括国际奥委会指定的顶级合作伙伴、顶级合作伙伴的分包商、以及主办城市组委会所签署的赞助商、提供商、开发商等，是典型的大型国际化外包项目，项目组织管理复杂。时限严格、大型遗产系统的继承及再工程，以及包括技术、管理、操作各层面在内的系统体系结构复杂，是该项目所面临的主要挑战。奥运会的所有赛事都是“一次性艺术”，甚至是“一瞬间艺术”，任何人为失误或技术漏洞，都会成为白玉瑕疵，无可补救。一次性的艺术异常精彩，但有时也会带点残酷。白晓颖和她的同事开始了马拉松式的奥运会信息系统筹备工作。

面对奥运会信息系统质量控制的挑战，白晓颖和周立柱老师在2003～2005年承担了国家科技部科技攻关项目《奥运会信息系统集成测试总体方案及集成测试管理平台的预研》。本项目的主要目的是：为2008年北京奥运会信息系统集成测试的实施做好前期的预研、规划和准备工作，降低风险；加强对测试的管理，为2008年北京奥运会信息系统地集成测试系统、有计划、有组织、高效地进行奠定坚实的基础，并最终达到提高奥运会信息系统可靠性的目的；加强测试队伍的建设，为2008年北京奥运会信息系统集成测试的实施培养骨干力量。带动软件测试行业的发展，促进北京乃至全国的测试技术的发展，逐步探讨软件集成测试规范，为我国自己高水平的软件集成测试标准的建立探讨依据。

本项目的研究主要分为三部分：历届奥运会信息系统的开发和测试的调研，北京奥运会信息系统集成测试的总体方案的研究，以及测试管理平台的预研。根据课题任务书的计划，课题组完成了要求的研究工作：收集、整理、总结和分析了悉尼、盐湖城和雅典三届奥运会信息系统的相关技术资料，形成了两份调研报告《技术体系架构》和《集成测试分析》；立足于北京2008年奥运会的实际情况，参照往届奥运会的最佳实践，在软件测试及软件工程理论的指导下，形成了北京奥运会信息系统集成测试的总体规划报告；研究开发了基于Web的、可应用于分布式开发环境的测试管理系统。

在收集和分析相关资料的基础上，白晓颖还亲自前往2004年奥运会举办城市雅典进行实战考察，收集了大量第一手资料，对项目研究起到了重要作用。理论研究加上实地“取经”，课题组交出了最后的答卷，完成了技术体系架构分析集成测试分析两份调研报告，从应用系统的功能、运行环境、接口、数据流等角度系统全面地分析了信息系统的软件体系架构；从项目管理、测试环境、以及测试用例等几个方面，总结分析了往届奥运会中系统集成测试的实施方式、经验和教训。并在此基础上完成了19万字的总体规划报告，结合北京奥运会的技术战略，从人员组织、测试过程、进度计划、质量保证、策略选择及风险分析、实验室建设、测试工具选择、标准与规范、经费预算等九个方面，全面讨论了北京奥运会集成测试的总体规划方案，为奥运会信息系统的筹备工作，奠定了坚定的基础。

报告提交以后，得到了相关专家的认可，认为调研报告详细、准确、全面地反映了奥运会信息系统在测试目标、内容、组织和管理方式等方面的要求，并评价课题组制定的集成测试总体方案系统、全面、切合实际、可操作性强。课题组的工作成果被直接应用于奥组委技术战略，为北京奥运会信息系统的成功运行提供了有利保障，成为伦敦总结会中北京奥运会技术传承的一个重要经验，得到国际奥委会会的高度评价。

经过不断学习和历练，白晓颖在迅速成长，如今她已经成为清华大学计算机软件研究所副所长。作为项目负责人，她先后承担了10余项包括科技攻关项目、国际合作项目、863计划及973计划项目在内的科研项目，在国内外期刊和软件工程重要会议上70余篇，获得了一系列研究成果。在服务化软件研究方面，是国际上最早开展服务软件测试技术研究的学者之一。从面向过程、到面向对象、到面向服务，软件形态与其开发方法发生了重大的变革，服务化已经成为互联网软件的主要形态。服务化软件具有代码不可见、服务动态组合、在线演化的特点，使得传统的以人工为主或是以程序分析为基础的测试技术难以适用。针对这种新型的软件范型的质量问题，课题组从协同测试、自动化测试、在线测试三个方面，研究有效的测试方法和测试技术。另一个重要的研究方向是以机载软件为背景，研究嵌入式软件中模型驱动测试自动化技术。机载嵌入式软件的规模和复杂度成指数级增长，机载软件质量控制实际上已成为世界航空业的一个挑战性问题。课题组针对机载国产操作系统标准符合性测试的需要，实现了基于模型的测试自动化工具。

2001年8月，世界军人锦标赛在圣彼得堡举行，俄罗斯选手斯卢德诺夫以27秒25的成绩打破了50米蛙泳的世界记录。但遗憾的是，由于赛场内的电子计时器出现故障，没有记录到斯卢德诺夫的成绩。短暂休息后，斯卢德诺夫又以27秒25的成绩再次打破世界记录。谁料，他的这次成绩仍旧不能作数，原因是裁判忘了重新启动电子计时器……“就因为这样，我所有的努力，以及数月来的训练和准备工作全都白费了，真是让人恼怒！”这位游泳健将绝望透顶地说。

在比赛中出现任何技术故障，不仅会给运动员带来无尽的懊恼和愤怒，还会影响赛事的精彩程度。因此，信息系统是关系到比赛质量的一个关键因素，对于奥运会这样的世界顶级赛事来说，信息系统的重要性更加不可估量，这就为奥运会筹备人员带来了无法估量的压力，白晓颖作为北京奥运会组织委员会的一员，从2002年进入奥组会到2008年8月24日奥运会闭幕，切切实实地感受了6年多的时间。直到奥运会圆满结束，她才放下了一直悬着的心，真正松了一口气。

白晓颖，清华大学副教授、计算机系软件研究所副所长，主要研究领域为软件工程，研究方向包括软件测试、分布式系统、服务计算等。童年时父亲从国外为她带回的一个小小的游戏机，为她打开了通向计算机的一扇门。长大以后，她真正走入了这扇门中的那个计算机的世界，并且不断攀登前行，走到了如今的辽阔天地。1995年毕业于西北大学计算机系之后，她考入了北京航空航天大学计算机系攻读硕士。三年后硕士毕业，远赴美国继续攻读博士学位，先后就读于美国明尼苏达大学和亚利桑那州立大学。2001年底，她学成回国，进入清华大学任教。

2001年7月，我国申办2008年奥运会成功，举国欢腾。2001年12月，北京奥运会组织委员会正式成立，虽然当时距2008年奥运会还有6年多的时间，但是大量的准备工作都要开始着手进行。从2002年1月份开始，奥组委开始着手成立各个领域的相关部门。技术部是最早筹建的部门之一，负责奥运会信息系统、通信系统及场馆技术系统的相关工作，年轻的白晓颖参与了清华大学计算机系与奥组委技术部的科技攻关合作，成为技术部的一员，白晓颖笑称自己是北京奥运会最早的“技术志愿者”之一。

信息系统已经成为现代奥运会成功的基础和保障。奥运会信息系统结构复杂、涉及面广，项目实施规模大、周期长、风险高、难度大，也是奥运科技系统中技术含量高、应用范围广的主要部分之一。奥运会信息系统体系结构分析是充分了解系统特点，有效控制系统质量、进度、预算的前提和保证。奥运会信息系统包括运动会管理系统、计时记分系统、现场成绩处理系统及成绩系统四个主要部分。各子系统及相关模块分别由位于不同国家的不同机构承担，包括国际奥委会指定的顶级合作伙伴、顶级合作伙伴的分包商、以及主办城市组委会所签署的赞助商、提供商、开发商等，是典型的大型国际化外包项目，项目组织管理复杂。时限严格、大型遗产系统的继承及再工程，以及包括技术、管理、操作各层面在内的系统体系结构复杂，是该项目所面临的主要挑战。奥运会的所有赛事都是“一次性艺术”，甚至是“一瞬间艺术”，任何人为失误或技术漏洞，都会成为白玉瑕疵，无可补救。一次性的艺术异常精彩，但有时也会带点残酷。白晓颖和她的同事开始了马拉松式的奥运会信息系统筹备工作。

面对奥运会信息系统质量控制的挑战，白晓颖和周立柱老师在2003～2005年承担了国家科技部科技攻关项目《奥运会信息系统集成测试总体方案及集成测试管理平台的预研》。本项目的主要目的是：为2008年北京奥运会信息系统集成测试的实施做好前期的预研、规划和准备工作，降低风险；加强对测试的管理，为2008年北京奥运会信息系统地集成测试系统、有计划、有组织、高效地进行奠定坚实的基础，并最终达到提高奥运会信息系统可靠性的目的；加强测试队伍的建设，为2008年北京奥运会信息系统集成测试的实施培养骨干力量。带动软件测试行业的发展，促进北京乃至全国的测试技术的发展，逐步探讨软件集成测试规范，为我国自己高水平的软件集成测试标准的建立探讨依据。

本项目的研究主要分为三部分：历届奥运会信息系统的开发和测试的调研，北京奥运会信息系统集成测试的总体方案的研究，以及测试管理平台的预研。根据课题任务书的计划，课题组完成了要求的研究工作：收集、整理、总结和分析了悉尼、盐湖城和雅典三届奥运会信息系统的相关技术资料，形成了两份调研报告《技术体系架构》和《集成测试分析》；立足于北京2008年奥运会的实际情况，参照往届奥运会的最佳实践，在软件测试及软件工程理论的指导下，形成了北京奥运会信息系统集成测试的总体规划报告；研究开发了基于Web的、可应用于分布式开发环境的测试管理系统。

在收集和分析相关资料的基础上，白晓颖还亲自前往2004年奥运会举办城市雅典进行实战考察，收集了大量第一手资料，对项目研究起到了重要作用。理论研究加上实地“取经”，课题组交出了最后的答卷，完成了技术体系架构分析集成测试分析两份调研报告，从应用系统的功能、运行环境、接口、数据流等角度系统全面地分析了信息系统的软件体系架构；从项目管理、测试环境、以及测试用例等几个方面，总结分析了往届奥运会中系统集成测试的实施方式、经验和教训。并在此基础上完成了19万字的总体规划报告，结合北京奥运会的技术战略，从人员组织、测试过程、进度计划、质量保证、策略选择及风险分析、实验室建设、测试工具选择、标准与规范、经费预算等九个方面，全面讨论了北京奥运会集成测试的总体规划方案，为奥运会信息系统的筹备工作，奠定了坚定的基础。

软件测试年度工作计划例2

随着科学技术的不断进步，计算机技术被越来越多地应用到武器系统中。计算机软件的复杂程度随着功能的增强，因而系统的可靠性也越来越与软件直接相关。例如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%的使用最频繁的操作可以加速可靠性的提高。

软件测试年度工作计划例3

中图分类号：G642.0 文献标志码：A 文章编号：1674-9324（2015）06-0160-02

一、引言

为培养创新能力强、适应社会经济发展需要的软件测试人才，适应卓越软件工程师培养要求，软件测试课程亟须改变传统的教学理念，更新教学内容，改进教学方法。笔者结合自己10余年软件测试课程的教学科研和工程实践经验，分别从教学内容组织、实验教学改革和工程实践能力培养等方面论述《软件测试与质量保证》课程改革的措施和体会。

二、国内高校在软件测试教育方面存在的问题

通过多年软件测试教学实践和调研，发现国内高校在软件测试教学中普遍存在如下问题：

（一）教材选择取舍两难

企业要求软件测试工程师掌握软件测试及软件质量保证知识及技能。但是，在售中文图书中（以2014年6月7日当当网在售中文图书作为基础数据），与软件测试相关的书籍居多达300多种，软件质量保证方面图书有10种，同时包含软件测试与软件质量保证知识的中文图书仅有6种。分析仅有的6种软件测试与质量保证教材，发现这几种教材都偏重软件测试理论和方法的讲解，很少涉及软件测试工具、软件测试项目实践等，难以适应软件测试人才培养的要求。

（二）实验教学存在知识点遗漏

统计分析与软件测试、质量保证相关的中文图书发现：作为发现软件缺陷最高效的静态测试技术现有的中文图书很少系统讲述。除了软件测试工程师认证考试培训教材之外，其他图书均未阐述软件测试人才必需的专业外语知识。在内容组织上，上述教材普遍均未按照软件测试项目实践的过程进行系统化的组织，兄弟院校在软件测试与质量保证教学过程中也存在上述知识点遗漏情况。

（三）思维锻炼不足

自主学习能力培养有助于学生自主学习掌握软件测试新的方法、技术和工具，使学生尽快适应新的软件测试环境；逆商是积极应对挫折、摆脱困境和超越困难的能力，逆商培养有利于学生积累软件测试项目实践的经验教训，从而促进其软件测试工程师职业素养的形成。但是，国内高校在软件测试与质量保证教学时，很少关注学生自主学习能力和逆商的培养。

三、教学改革内容

在卓越工程师计划驱动下，以软件企业对软件测试人才的需求和国家软件测试工程师认证要求为导向，我们整合已有的校企合作课程资源，按照软件测试三要素组织课堂教学内容，强化实验教学环节，采用项目驱动的案例教学法开展教学活动，取得了较好的教学效果。

（一）课堂教学改革

1.教材选择。我们选择同济大学朱少民教授编写的《全程软件测试》作为课程教材，该书按照软件测试项目实践的实际过程组织软件测试的基本概念、原理、方法、技术以及最佳实践等知识，为学生系统化学习软件测试技术、开展软件测试实践提供具有高度可操作性的指南；选择NIIT培训教程《Software Testing and Quality Assurance：Student Guide》，作为专业英语教程，学生阅读该教程可以了解印度在软件测试职业教育方面的成功经验，为学生专业英语水平的提高提供便利。

2.教学内容的组织。教学内容组织方面，围绕软件质量，把课堂教学内容划分成软件质量管理、软件质量保证、软件测试基础和软件测试技术等课程模块。（1）软件质量管理模块，介绍软件问题的分类、软件缺陷管理、软件质量基础和软件质量管理等知识；（2）软件质量保证模块，讲解常用的软件质量保证措施（包括软件质量保证团队的组织、软件质量管理措施、软件质量标准、项目早期阶段的质量保证措施、软件开发维护阶段的质量保证措施等），让学生认识到软件质量的提高需要综合运用软件质量保证的各项措施；（3）软件测试基础模块，介绍软件测试的定义与目的、软件测试原则、软件测试过程模型、软件测试停止标准、软件测试类型的划分、软件测试自动化以及软件测试人才的职业素质等。（4）软件测试技术模块，突出软件测试用例的作用，按照软件测试项目实施过程组织，包括软件测试计划、测试设计（包括测试过程设计、测试用例设计、驱动模块及桩模块的设计）、测试实施（包括测试脚本编写、编码实现驱动模块和桩模块）、测试执行、测试评估、软件缺陷管理等知识点。软件测试执行方面，根据软件测试执行的层次划分为单元测试、集成测试、确认测试和系统测试。

（二）实验教学改革

如何在有限的实验课时内，最大限度地加深学生对软件测试技术的理解，增强其软件测试实践能力，是实验教学的主要任务。根据软件测试项目实施过程编排教学内容，突出软件测试与质量保证的基本方法、原理和业界常用工具的使用，以反映中小企业软件测试项目实践的经验。

1.基于Microsoft Project的软件项目计划。软件项目计划及进度管理，既是软件质量保证中重要的管理部件，也是开展软件测试活动的前提。为此，安排软件项目计划实验，要求学生使用Microsoft Project建立软件项目计划。实验内容包括使用“资源工作表”定义软件测试项目所需的各类资源、使用甘特图制定软件测试计划、运用跟踪甘特图跟踪项目进展，等等。

2.软件测试与软件调试。软件测试的目的是发现软件系统中潜在缺陷，而缺陷解决则通过软件调试手段实现。本次实验以员工工资核算软件Employee作为测试对象，要求学生在Eclipse开发环境中用Java语言描述软件测试过程，发现Employee中人为注入的软件缺陷，然后应用Java调试器的断点调试功能，结合回归测试手段修订所发现的缺陷。

3.BugFree软件缺陷管理。软件缺陷管理贯穿软件测试项目的始终，记录软件缺陷从发现、修复、回归测试直至关闭软件缺陷的全过程。“BugFree软件缺陷管理”介绍开源缺陷管理软件BugFree的软件缺陷管理思想，要求学生掌握BugFree安装与配置、软件缺陷管理等技能。

4.软件静态测试。软件静态测试是软件测试技术中发现软件缺陷效率最高的技术。我们安排“软件静态测试实验”，讲解软件制品阅读、静态分析的技巧，还介绍如何运用CheckStyle、FindBugs等静态测试工具分析程序源代码、目标程序中潜在缺陷。

5.JUnit单元测试。“JUnit单元测试”实验要求学生编写Triangle类描述三角形问题，使用等价类划分方法、边界值分析方法为三角形问题设计测试用例，把测试用例编码成为基于JUnit框架的测试脚本，执行测试脚本以发现潜在缺陷。推荐学有余力的学生自学JMock，综合应用JUnit和JMock进行对Java应用系统进行集成测试。

6.QuickTest Professional功能测试。安排“QuickTest Professional（简称QTP）功能测试”实验，要求学生为机票预订系统设计测试用例，录用人工测试的过程形成机票预订系统的测试脚本框架，把测试用例中软件预期执行结果和测试实际执行结果的比较编码成为QTP检查点，产生测试脚本。然后，在回放测试脚本，产生功能测试执行报告。

7.LoadRunner性能测试。该实验讲述如何运用HP Mercury LoadRunner对Web系统进行性能测试，让学生在实验过程中理解虚拟用户技术，掌握基于LoadRunner的性能测试技术的过程及技巧。

（三）工程实践能力培养

课程开篇即向学生介绍软件测试人员的就业前景、能力要求。利用我校网络课程平台BlackBoard把讲稿、实验讲义、实验视频、参考文献等课程素材到BlackBoard，要求学生在学有余力的前提下利用课外时间完成课程扩展任务，锻炼学生的自主学习能力。通过临时调整实验地点，要求学生在新的测试环境中快速完成测试环境构建，引导学生渐进地解决测试实践过程中遇到的各类问题，锻炼学生的逆商能力。

四、结束语

《软件测试与质量保证》通过十余年的建设已形成了较完善的课程体系，十多轮的授课实践积累了丰富的教学经验。本课程作为软件工程专业卓越工程师课程已进行了2轮教学，最近一轮的课程教学评价学生评分为98.19，教学效果较好。

当前，我校正转型应用技术大学，这将对本课程的教学内容、教学方法、教学手段等提出更多、更高的要求。鉴于此，本课题的教学团队正积极更新课程体系，以适合长三角地区中小型软件企业对软件测试人才的能力要求。

参考文献：

[1]陈翔，鞠小林.卓越计划驱动下的软件测试技术课程教学改革[J].计算教育，2013，（13）.

软件测试年度工作计划例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系统测试和现场试运行阶段

系统测试和现场运行以确认产品的软件要求是否得到满足，用户是否可以实际应用。系统测试阶段是开发过程阶段的最后阶段，如果措施得当，可以在产品首次使用前进一步提高可靠性。现场试运行阶段在用户环境中验证产品的各种说明及系统测试所得的可靠性指标。这个阶段的工作有以下工作：

⑴确定操作概图

软件测试年度工作计划例5

一、软件测试教学现状

由于软件测试技术发展起步比较晚，测试人员数量少，测试重视度不高，测试费用投入较少，从而导致我国的软件测试行业上在理论和实践上都比较滞后。随着软件行业蓬勃的发展，近年来，软件测试技术也得到了迅速发展，全国高校都陆续成立了软件学院并开设了软件工程相关专业。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等工具。第三，提高教师队伍的软件测试素质，有计划的安排教师到软件公司参与实践，增强软件测试的案例分析能力。

三、结论

软件测试技术在软件行业越来越显得很重要，软件测试人员在整个软件开发中的地位也越来越作用明显，然而国内整个高校对软件测试的教学课程体系明显有待提高。本文通过结合我校的实际情况，对软件测试的教学人员、教学方法和教育理念进行了梳理，并提出了五条合理化的提高软件测试教学的可行性建议，对于国内开展卓越工程师的学校提供了参考。

参考文献

软件测试年度工作计划例6

0引言

在软件技术快速发展和应用范围不断扩大的同时，软件复杂性也不断提升。在当前的很多软件开发企业中，软件质量管理问题开始成了关注的焦点。

1软件质量管理中存在的主要问题分析

1.1需求模糊问题

结合软件工程来说的话，软件产品的生产主要包括多个过程：第一是系统需求研究过程；第二是系统设计过程；第三是系统实现过程。但对于软件系统需求来说，往往描述不够完善，相应的软件需求调研以及研究也不够深入，没有加强对软件质量需求的管理，这样不仅会使得研发以及测试设计工作落实不到位，还会明显提升沟通成本，导致产品实现与用户需求不一致［1］。

1.2立项管理不到位问题

大量实践结果表明，通过加强立项管理，可以有效避免质量管理项目风险的产生，赋予软件项目开发深刻的意义。（1）软件项目开展。不加强深入的立项调查，以及加强项目可行性分析，落实好立项评审，则可能会导致产品需求获取不到位，软件开发产品规划出现很多问题，无法保证软件研发工作的有效开展，致使项目研发功能明显减弱，不但会导致资源浪费，还会阻碍新产品的正常［2］。（2）软件项目。如果没有加强立项管理，可能会导致成员行为涣散问题的出现。工作人员只顾自己，不顾团队利益，无法全面了解项目产品的实际开发要求与背景，也不能从根本上明确项目开发的最终目标，无法满足用户的实际软件开发需求，最终使得软件开发计划无法按期实施以及软件开发费用超支等问题出现。

1.3软件质量保证体系尚待完善

针对我国很多软件开发企业来说，往往都处于“软件质量管理”实施的最初阶段，甚至是试行阶段，很多科研制作部门对应的标准化软件质量管理体系还都不完善，甚至有一些科研部门对应的软件质量管理制度和体系还没有形成［3］。另外，一些企业虽然设立了软件质量管理的专有部门，但相应的体系文件却还不完善，需要经过大量的实践来完善。在软件开发项目研制部门质量管理普通较低的情况下，软件开发工作者的综合素质低下，也会影响软件产品的最终质量。

2软件质量管理的优化对策分析

2.1加强需求工程有效管理

在实际的软件开发当中，如果相应需求模糊，会出现需求随意变更的现象，导致时间被白白浪费。对于该问题来说，必须针对相关需求活动，加强统一化的需求管理。要在落实好软件需求开发工作的基础上加强需求管理，这样不但能够限制需求变更的实际次数，还能促进工程师对质量管理需求的深入理解。总之，软件需求开发与软件需求管理的重要性同等重要，必须实现两者的有效结合，才能保证最终产品的质量。

2.2加强软件测试流程有效管理

在软件测试的各个环节，都可能会出现一些问题，必须不断优化软件测试流程，加强对软件测试流程的有效管理。具体来说：（1）软件测试相关部门人员，必须加强需求知识学习，开展深入的需求探讨。（2）对有疑虑的需求者，研发设计工作者要做出及时而准确的解答。对于研发设计工作者也不能有效解答的问题，要让他们联系用户来有效解答。在明确需求的基础上，根据软件系统的作用以及性能，专门的测试工程师要科学合理地设计软件测试测用例，具体要结合两大方面的内容来设计：第一，针对测试工程师来说，必须结合实际需求，科学合理地编写测试用例；第二，针对测试工程师来说，要在结合实际用户反馈情况的基础上，做好分析汇总工作［4］。要大力引入和合理应用QC功能测试设备以及工具，加强对软件以及实际操作系统兼容性能的合理性测试，才能充分发挥软件测试工具使用的功能与作用，落实好软件兼容性测试工作。此外，要加强自由软件测试，适当补充软件测试用例，了解软件测试用例没有涉及的问题以及问题产生的原因；要采取定期研究和分析的方法，明确缺陷库里面存在的问题，并深入研究问题成因，进而利用测试用例来解决问题［5］。

2.3加强项目进度质量有效管理

要保证软件开发项目的顺利完成，首先必须保证软件项目质量足够好。在软件项目开始实施之前，必须保证项目开发计划足够科学、合理。如果软件开发项目计划设计人员相关工作经验足够丰富、设计能力足够强，往往可以有效保证软件开发计划的合理性与完善性，有效预见软件开发计划当中的问题，消除相关阻碍和影响因素。在软件开发项目计划设计的开始，相关人应及时组织软件质量管理人员，开展软件项目计划讨论会与评审会，并请相关技术专家、真实用户等，针对软件项目计划的科学性和合理性进行探讨，分享个人意见和看法，由专门的记录人员总结相关意见，最终形成系统化的质量记录，再以书面或者文档的形式传送给相关工作人员进行意见修改整合，确保软件项目计划的完善性。

2.4提升工作人员的综合素质

在软件开发和质量管理过程中，技术人员和管理人员是核心主体。因此，要想有效保证软件质量管理有效性，必须保证管理工作人员和技术人员的综合素质足够高。让员工全面地了解企业，正确理解自身的工作性质和要求，并不断增强自身的责任感。即使工作人员已经对工作内容很熟悉，也可能没有深入理解企业经营战略以及相应的发展规划。企业外部环境条件变化幅度比较大，企业工作人员必须及时掌握内部战略和规划变化情况，及时调整自己的工作计划和方法。对于软件质量管理人员来说，不但要主动参与到企业发展规划设计工作中，还必须及时将相关信息传达给各个部门。通常来说，企业应当定期或者不定期地开展例会，介绍企业近期情况和之后的发展规划。在掌握全体例会内容的基础上，各个部门负责人员应当再次开展部门会议，根据部门工作开展情况，做好后期工作规划调整工作，使得每位员工都掌握企业发展动态，进行自身科学合理的工作调整与规划。软件质量管理者还必须基于企业内部软件质量问题，增强创新意识，提出可以有效解决软件质量问题的措施。

3结语

综上所述，软件开发成本管理不到位、软件质量管理不到位等问题仍然存在，导致这些问题产生的主要原因是管理者管理不到位，如：软件质量管理制度不完善、随意性较强。要有效解决这些问题，必须以完善的软件质量管理体系为依据，加强软件开发的全过程监控［6］。

参考文献

［1］翁婕，丁铁，乔扬，等.软件质量管理的优化对策［J］.电子制作，2015（6）：98-99.

［2］周波，钟小咪.铁路运输行业的供应商软件质量管理［J］.科学与财富，2016（5）：750.

［3］张沐辰.基于软件全面质量管理的团队建设［J］.科教导刊，2014（16）：45，55.

［4］方俊钗.数字超声检测仪软件的质量管理和软件测试［J］.科技风，2014（13）：238.

软件测试年度工作计划例7

虽然F-35整个项目已历时9年系统开发和4年小批量生产，但飞机和发动机设计至今尚未最终确定。设计稳定性是产品成熟的一个关键指标，虽然对F-35这样的一些技术先进的武器系统，在某些层次上或某些循环阶段中，设计更改是必不可少的，但过多的更改必定影响设计的成熟度。F-35项目3种型别飞机的关键设计评审在2006年和20075就已完成，但仍在不断进行大量更改。项目在2007年产生了2万余份发动机图纸，增加量为图纸总数的50％。2009和2010年的月更改率继续高于预期，预计到2016年1月还有约1000余项要更改。

进入采办阶段后，新增的设计更改导致在研制飞行和地面试验阶段出现诸多问题和返工，更大的影响可能波及之后的生产过程、供应基础以及对已生产的和已服役飞机的翻修，导致2018年前新增大量测试项目以及系统开发相关工作量。设计更改使承包商不能按原计划快速减少工程师数量，这也是项目费用比预期增加很多的原因之一。

目前在飞行测试阶段暴露出的问题，确定需要进行更改的包括：①“短距起飞和垂直降落”(STOVL)型飞机的升力系统开发和集成。设计人员正努力将升力风扇和驱动轴技术成熟化。②STOVL型试验飞机的疲劳断裂。在耐久性地面试验中，STOVL型试验飞机的主要舱壁出现了疲劳断裂。断裂是在耐久性试验进行1500小时后出现的，这个时间还不到STOVL机体框架满足设计要求所需进行疲劳试验时间的1／10。③翼尖涡流。翼尖涡流是机翼在产生升力时，在其后面形成的环状紊流。这些涡的核心由于水的聚集有时是可见的。如果这些可见涡核心出现在白天，则可能影响飞机的隐身性能。④飞机的外型线。由于供应商缺乏一些飞机外型线生产能力，导致外型线不能满足设计要求，可能会影响飞机的隐身性能。

这一系列问题都有可能引起新的设计更改，导致工作量激增。尽管已开始一些重新设计工作，但这些问题可能要到2015年6月才能解决。飞机和发动机制造成熟度不够

飞机和发动机生产过程尚不成熟。由于管理问题致使试验飞机在生产过程中劳动力的持续增加，2010年实际人工小时数已经比2007年预计的人工小时数超出150万小时，增力NT75％。一般来说，批量生产飞机随飞机数量增加，人工小时费用会随之降低。然而，F-35的初始生产飞机数据显示，未来批量生产飞机的费用将会高于预期值，首批3架低速率生产飞机不仅费用增加，交付时间也比预计延长了9个月。飞机和发动机制造商目前在生产方面还存在很多问题，完成所有工作和交付任务所需的生产能力很勉强。目前全球供应链不能有效支持最终每月20架的生产速率。

提高可靠性对于控制未来使用费用和确保飞机在需要时处于可用状态是至关重要的，但飞机至今也没有满足预期的可靠性增长计划。关键可靠性矩阵分析表示了飞机失效间的平均飞行小时数，即完成的飞行小时除以失效次数。按设计，“常规起降”(CTOL)型故障间的飞行小时数应为2.9，但实际测试表明只有1.8，是预期值的60％；STOVL型的设计值至少应为1.9，而实际测试表明只有0.4，仅实现当前节点预期值的20％；“舰载”(CV)型没有给出具体数据，而且据了解是在没有充足可靠性数据的情况下，提前进入飞行试验阶段的，不利机全寿命周期费用管理。

飞行试验―再滞后

各型F-35的研制飞行试验也严重滞后于计划。截至2010年底累计的飞行架次，只有2007年所作计划的1／5；完成约5万个试验点，只完成计划的10％，但大部分试验点都是属于基本机体的操作特性，相对容易完成，而其他剩余的试验点，大多是更复杂或要求条件更为苛刻的试验点。例如，任务系统、舰船适配性以及武器集成等，完成相对要困难得多。

目前用行试验的13架试验飞机中，已有10架运送至测试地点，剩余3架处于最后检查阶段。原计划这些飞机的飞行强度能达到12架次／月，但2010年的平均月飞行强度只有2～8架次，试验节奏缓慢。

2010年12月，飞机4％的性能已通过飞行试验或实验室模拟结果得到验证。验证全任务系统性能和武器投放的整机集成试验2015年后才能进行，比计划推后3年。在2010年研制飞行试验中，项目验证取得了一些进展，但仍滞后于计划，而且STOVL型出现的问题已严重拖延了整个进度。32个关键地面测试实验室和模拟模型中只有3个按计划建成，某些情况下还需采用飞行试验替代，以确保结果的可信度，这将进一步拖延整体进度。

软件开发严重滞后

提供F-35基本性能的软件目前尚不成熟，用于测试的版本落后于进度。其软件开发工作提供了80％的F-35重要性能，比如传感器融合、武器和火控、维修诊断和推进系统等。F-35机载软件代码行数是F／A一18E／F“超级大黄蜂”的8倍，是F-22A“猛禽”的4倍。随着集成和测试工作的深入，软件代码还会有所增加。目前，3／4的软件已完成编写和集成，但测试落后于进度，军方对开发和集成软件所需的时间和工作量评估不足，这是造成“拖、降、涨”的主要原因。计划人员和主要承包商也承认，软件开发进度已进行了几次调整，从初始设计评审以来，项目的软件代码行数已增长了40％，在关键设计评审之后增长了13％。每次调整都延长了完成工作所需时间，已严重影响了飞行测试、训练及实验室的试验鉴定。而且随着工作的进展，在项目验证全部作战性能之前，还有大量的软件开发工作。

所有开发的软件，不仅要完成与飞机的全系统、功能集成，而且要在使用环境中得到充分验证，而F-35项目用于测试的软件将验证全系统性能，比原计划延迟了3年。

地面测试进展缓慢

与之前的武器系统相比，F-35项目更加依赖建模与仿真，对飞机设计和分系统性能进行测试和验证。然而，目前32个实验室和模型中，只有3个按时间节点达到了标准。作战试验与鉴定局报告指出，50％的模型要在飞行试验的最后一年进行试验鉴定，风险很高。延期的试验鉴定将增加风险，既不能按时完成大量软件的开发，也不能及时发现后面出现的问题。

目前承包商实验室的数量和综合度

不足以满足要求，特别当之前模块需要返工时，就会与正在进行的模块在实验上发生冲突。由于新旧模块在开发进度上存在一定的时间交叠，也在一定程度上造成集成和测试进度拖延，不能满足飞行测试和训练的进度安排。产品交付一延再延，费用高涨

因为主要合同承包商没有充分采用项目“收益值管理”(EVM)，即用与进度计划、成本预算和实际成本相联系的3个独立的变量，对项目进行有效的进度跟踪和经费控制，整个项目被经费和进度问题拖后了至少3年，到2010年，合同中32个要求的基线目标只满足了19个

国防部从2007年开始采购生产型飞机，目前已在首批4份低速率初始批生产合同下订购了58架，合同要求2010年交付14架，但至今1架都没有交付。首批2架生产型(都是CTOL型)的交付时间已经延至2011年4月，而国防部还期望201 1财年能再采购32架。面对如此大的订货量，但又无法及时交付，从而不能更有效地利用合作国的资金，导致批量生产之前产生较高的债务。GAO建议，国防部应以同样理由削减STOVL的产量。如果美国和其他合作国减少采购飞机的数量，将进一步增加单架飞机的成本。

此外，为F-35三种机型研制的F135发动机和原始生产部件虽已经交付，但交付时间延后，导致首批3台发动机的成本也随之上涨。尤其STOVL型发动机的试验鉴定延至2010年12月，致使该型机的服役时间大大拖延。

调整措施建议

GAO报告建议，美国防部必须将F-35项目限定在预算中进行，加强项目管理，寻求更加有效的管理方法，控制项目未来经费的增长，建立更好的国防采办投资组合，确保更加顺畅地推进F-35项目。

加强供应商管理和项目管理

改善全球供应链管理，完成全球物流计划和供应链风险管理计划，提高生产能力；继续执行全面项目进度风险评估，以便清楚直观地看到关键活动、费用和进度的相关关系，揭示风险。

强化项目质量管理，设立更有效的工作岗位，提高质量，增加部件有效性，减少等待时间，在这些改善措施完全生效前，通过减少生产数量，为全面成熟的制造和供应提供足够的改进时间。在开始批生产之前，验证系统可靠性是否按计划进行、能否实现目标值，有利机全寿命周期费用管理和提高可靠性。对STOVL型开展独立评估，允许各

机型根据各自进展向前推进

STOVL型将作为此次调整的重要内容，美国防部除考虑是否削减STOVL生产量外，还专门设定一个为期2年的“考察期”，并制定标准，单独对STOVL型进行评审，从而使其重返正常发展轨道，确保STOVL型的费用和进度里程碑能满足项目要求。同时，美国防部要求项目人员制定关于3种型号各自的新的试验计划，将STOVL型的飞行和验证试验点与其他两型分开，使后者能以各自进度推进。

制定更现实的试验计划

新的调整除为研制试验增加更多资源、延长试飞期限、缩小初始作战试验之前的差距外，还决定将新增一架CV型试验飞机，并允许使用3架生产批飞机进行开发试验，试验飞行架次总数也由原计划的5856架次增至7727架次，增加了1／3以上，还要预留更多用机维护和计划升级所需的时间，并制定一个更标准的单架试验飞机出勤率的增长目标。

但调整带来的项目成本的增加，对于美国和其他参与国来说将是一个很大的挑战，目前F-35A飞机单价已由项目开始时的8100万美元增至1.56亿，增长了近一倍，而且新的预测显示，该机寿命周期内的使用和维护费用也将大大超过其所替代飞机的相关费用。

软件测试年度工作计划例8

0 引言

“卓越工程师教育培养计划”（简称卓越计划）是教育部为贯彻落实《国家中长期教育改革和发展规划纲要（20113—2020年）》和《国家中长期人才发展规划纲要（2010—2020年）》而设立的重大改革项目。该项目旨在培养一批创新能力强、适应经济社会发展需要的高质量工程技术人才。在计算机科学与技术学院软件工程专业卓越T程师的培养计划中，软件测试技术是该专业的一门核心课程。通过该课程的学习，学生需要理解软件测试的基本概念，熟练掌握各种软件测试技术，了解不同测试阶段的测试目标、测试方法和相关测试文档，掌握经典测试工具的使用。为了适应卓越计划的新要求并融合软件测试在工业界的最新发展，培养出符合企业实际需求的软件测试卓越工程师，课程亟须改变传统教学理念，即更新已有教学内容，补充新的知识和技术，同时改进教学方法。笔者结合近些年的教学经历、工程实践和科学研究，分别从课堂教学内容、实验教学内容、创新实验项目建设等方面，论述卓越计划驱动下软件测试技术课程教学改革的措施和体会。

1 软件测试技术课程开设背景

当今软件行业面临复杂性、开放性、演化性等诸多挑战，而软件测试是保障软件质量的一种重要手段。统计数据表明，软件测试所需开销占软件开发总开销的40%，对于一些关键性软件，其占据比例甚至会提升到80%。近些年来，软件测试日益得到工业界、教育界和学术界的广泛关注。在工业界，软件企业对软件测试工作日益重视，因此设置了软件测试部门并招聘大量软件测试工程师，由于软件测试工作本身的高复杂性，使得目前测试人员的地位和待遇逐步提高；在教育界，国内外大学和社会培训机构陆续开设了软件测试技术相关课程，与软件测试相关的专业书籍也日渐增多，计算机技术与软件专业技术资格（水平）考试还增添了软件评测师中级资格；在学术界，软件测试是目前软件工程研究领域中的一个研究热点，每年均有大量的高质量研究，其中一些研究成果已经成功融入到企业的软件测试实践中。

基于上述背景，学院从2007年开始为全日制本科三年级学生开设了软件测试技术这门课程。该课程属于必修课，共48学时，其中理论3时，上机时。课程的先修课程包括离散数学、数据结构、高级编程语言、软件工程、编译原理等。截止到目前，学院先后有4名教师担任过该门课程的教学工作，约900名学生选修了这门课。通过与相关任课教师和听课学生的深入交流，我们发现该课程在卓越计划的新要求下仍存在如下问题：

（1）与软件工程专业的传统课程，如数据结构、操作系统和数据库技术相比，软件测试技术的教学内容并不成熟。该课程作为一门独立课程在国内院校中普遍开设较晚，早期一般作为软件工程课程的一部分进行讲解。通过分析市面上已经出版的一些经典教材，我们发现这些教材关注的知识点较为分散，授课老师普遍反映通过这些教材难以把握授课的重点和难点。同时，与企业目前的需求相比，这些知识点较为陈旧，甚至有的已经不能满足企业的实际需求。

（2）课程涉及的知识点多而繁杂且概念抽象，测试标准和规范类的教学内容偏多。由于听课学生欠缺软件测试经验，他们普遍认为课程内容抽象枯燥，学习兴趣不高，大部分学生存在听课时似懂非懂、考试时死记硬背、考完后全部忘记的现象。

（3）教师偏重理论知识讲解，缺乏实际案例。软件测试技术是一门实践性较强的课程，但目前的课程开设缺乏合理的实验项目设计，因此，老师可以由浅入深、循序渐进地培养并提高学生的软件测试技能，让学生通过实训验证在课堂学到的理论知识。

2 教学改革思路

按照卓越计划的指导思想、基本思路和基本要求，卓越计划驱动下软件测试技术课程的教学改革需要按企业测试部门的通用标准和行业标准来培养软件测试人才，同时，培养学生在完成软件测试任务时的工程能力和创新能力。基于课程的重要地位和特点，我们在教学改革时提出如下教学理念：

（1）教学内容要立足现代。立足现代是指对传统教学内容进行更新，即在原有的基本教学内容基础上，通过分析该领域在企业实践和学术研究上的最新进展，将一些操作性和实用性强的测试技术引入到教学中去。

（2）注重学生测试技能的培养。教学不仅要让学生知其然，而且还要让他们知其所以然，即不仅要掌握软件测试的基本概念和方法，而且在软件测试过程中，能够借助已有工具或自己开发工具来解决测试过程中出现的疑难问题，真正做到将所学知识灵活应用到实际软件测试工作中。

3 课堂教学内容改革

我们以上述教学理念为指导，分别从课堂教学内容、实验教学内容和创新实验项目建设上对课程教学进行改革，主要改革措施包括：

（1）教材选择上，力求教材更加贴近企业实际需求，同时在理论上具有一定的深度。在中国互动出版网、京东网、当当网和亚马逊网上输入关键词“软件测试”或“软件质量保障”，通过筛选，我们最终在一百多本教材中确定了两本英文教材和一本中文教材。两本英文教材分别是美国乔治·梅森大学Ammann教授等编写的《Introduction to Software Testing》和普渡大学Mathur教授编写的《Foundations of SoftwareTesting》。中文教材是同济大学朱少民教授编写的《软件测试方法和技术（第二版）》。前两本教材对软件测试的基本理论给出清晰的讲解，后一本教材则更加贴近企业的实际测试实践。

（2）以“基本概念一测试方法一测试流程一测试工具”为主线组织教学内容。针对卓越计划，我们对已有的教学内容进行重新设定，没定后的教学内容见表1。其中，基本概念模块是教学的核心，构成后续模块学习的基础，而软件测试技术（包括白盒测试技术和黑盒测试技术）模块、测试流程模块和测试工具模块则三者相互依赖。具体来讲，不同测试技术有不同的测试工具支撑，测试流程中的不同阶段借助不同的测试技术。例如，测试阶段以白盒测试技术为主，而集成测试和系统测试阶段则以黑盒测试技术为主。通过这条主线，可以将软件测试中的知识点有机融合并相互贯通。

（3）结合科研和企业实践，我们将软件测试技术的最新进展融入到教学内容中。在传统教学内容基础上，我们引入了很多具有较强使用价值的软件测试技术，具体包括：黑盒测试技术模块教学在正交实验法基础上引入组合测试（combinatorial testing）方法；在白盒测试技术模块教学中，不仅讲解了传统控制流覆盖准则（包括语句覆盖准则、判定覆盖准则、条件覆盖准则等），还深入介绍了数据流覆盖准则（包括all-defs覆盖准则、a11-uses覆盖准则和all-du-paths覆盖准则等）；在高级技术教学中，讲解了一种用于评估测试用例集测试充分性的变异测试（mutation testing）技术，并介绍了相关开源工具；在回归测试中，介绍了一系列测试用例维护技术，包括测试用例选择、测试用例集缩减和测试用例优先排序等。通过引入这些契合企业需求且可操作性强的新兴技术，学生提高了学习兴趣，丰富了自己的知识，锻炼了动手能力，有效满足了教学内容要立足现代的教学理念。

（4）提高学生的自学能力。在企业实践和学术研究的推动下，新的测试技术和理念不断被推出，所以提高学生的自学能力构成培养软件测试卓越工程师的一个重要目标。我们在日常授课时应注重学生自学能力的培养，对一些新的测试方法，要着重讲解方法的动机和核心思想；对方法的实现细节，则通过读书报告或创新实验项目方式，鼓励学生充分利用课余时间，自己查找相关文献予以完成。例如在讲解组合测试方法时，我们仅讲解了两种经典算法AETG和IPO的核心思想，对于具体的实现细节，我们鼓励学生用自己熟悉的编程语言去实现这两种算法。通过这种教学方式，可以培养良好的自学意识和高效的自学方法，最终有助于将学生培养为合格的软件测试卓越工程师。

4 实验教学内容改革

卓越计划对课程的实验教学环节提出了新的要求。如何在有限的实验时间内，最大限度地加深学生对软件测试基本理论的理解，为后续的专业学习和工作打好基础，是实验教学的首要任务。

在实验项目设计上有两种方案，一种方案是使用商用测试工具，另一种是使用基于开源软件的测试工具。对这两种方案进行可行性分析后，我们认为，如果采用商用测试工具，则存在投入高、适用面窄等问题；而采用开源软件，一方面投入较低，另一方面因开源软件可以获取源代码，将提高实验设计的灵活性。

在完成上述可行性分析后，我们基于Java编程语言，充分利用了一些经典开源软件，设计出如下三个难度适宜的实验项目。

1）单元测试工具JUnit的使用。

项目要求：掌握Eclipse、JUnit和Ant工具的使用。

项目内容：首先编码实现三角形类型判断程序，该程序的输入是三条边的大小，输出是三角形的类型（需要考虑等边三角形、等腰三角形、其他种类三角形、不能构成三角形等情况）；然后基于JUnit编写测试用例，在设计测试用例时需要采用等价类划分、边界值分析等测试技术；最后编写Ant脚本驱动测试用例并生成测试报告。

2）代码覆盖工具EclEmma的使用。

项目要求：掌握Eclipse、JUnit、Ant和EclEmma工具的使用。

项目内容：首先在Eclipse开发工具内安装EclEmma工具并完成配置工作，然后在项目1的基础上，通过使用EclEmma工具分析出测试用例集的条件覆盖情况。若出现测试用例尚未覆盖的条件，则通过修改被测程序或添加测试用例来确保所有条件均被充分覆盖到。

3）单元测试工具EasyMock的使用。

项目要求：掌握Eclipse、JUnit、EclEmma和EasyMock工具的使用。

项目内容：首先完成一个简单自动取款机（ATM）系统的设计和开发，该系统包括存款、取款、账户余额查询等功能；随后借助EasyMock工具来模拟ATM系统常用功能从而完成ATM系统的测试；最后借助EclEmma工具对测试用例的代码覆盖率进行分析。

上述二个实验项目在实际设定时，可以根据被测程序特征和学生自身技能特点，采用其他开源软件予以替代。例如，若测试cH编程语言实现的程序，可以考虑采用CPPUnit工具或gTest工具等。代码覆盖工具可以考虑gcov工具或Clover工具等。Mock工具可以考虑JMock等。

通过这三个实验项目的依次完成，逐渐增强了学生对软件测试知识的感性认识，使抽象枯燥的教学内容变得形象具体，从而培养了课程学习的兴趣，也使学生进一步加深了对Java编程语言的理解。

5 创新实验项目建设

在课程教学过程中，我们也加强了对优秀学生的培养。对于基础知识较为扎实、实践动手能力较强、创新思维和批判性思维较为活跃的学生，在完成课堂教学和实验教学阶段后，我们对他们增加了创新实践阶段。创新实践中的实验项目可以来自企业的实践需求，也可以来自教师平时的科研工作。例如，我们曾经组织2010级的若干拔尖学生组成一个小组，在有经验教师的指导下，通过研读相关论文，开发出一个错误定位（fault localization）工具。该工具以Tarantula方法为基础，通过搜集通过测试用例和未通过测试用例的语句覆盖信息，借助启发式公式将包含缺陷可能性高的语句用红色进行特别标记，实践表明该工具可以有效辅助程序员的软件调试工作。目前我们以该工具为基础，组织学生考虑更多的错误定位方法。

软件测试年度工作计划例9

通常来说，测试用例（Test Case）是指对一项特定的软件产品进行测试任务的描述，体现软件测试的测试方案、方法、技术和策略。测试用例必须给出测试目标、测试对象、测试环境、前提条件、输入数据、测试步骤和预期结果，并最终形成文档。

不同类别的软件，其测试用例是不同的。通常的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试便构成了一个个测试用例。

随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展，并逐步与世界接轨。软件测试从最初的由软件编程人员兼职测试，到软件公司组建独立专职测试部门；测试工作也从简单测试逐渐演变为包含多项内容的正规测试；测试方式则由单纯手工测试发展为手工、自动兼而有之，并有向第三方专业测试公司发展的趋势。目前软件测试内容主要包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等等。

影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。在测试时不可能进行穷举测试，所以应以最小的财力和物力投入，在最短时间内以最低成本尽快发现软件缺陷。因此要提高测试效率、节约测试时间，就必须设计好测试用例。测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。所以，有了好的测试用例，无论是谁来测试，只要参照测试用例实施，都能保障测试的质量。这样就可以把人为因素的对软件质量的影响减少到最小。因此测试用例的设计和编制是软件测试活动中最重要的。

下面就来详细地谈一谈测试用例在软件测试中的作用。

一、测试用例用于指导软件测试的实施

即使是很小的项目，也可能会有几个或是更多的测试用例，测试用例可能在数月甚至几年的测试过程中不断地被被创建和使用，正确的测试计划会很好地组织这些测试用例并提供给测试人员或者其他项目人员来参考并能有效的使用。

测试用例主要适用于集成测试、系统测试和回归测试。在进行软件测试的过程中，测试用例作为测试的标准，测试人员一定要按照测试用例项目和测试步骤逐一实施测试，并对测试情况进行记录，这些记录可以输入到测试用例管理软件中，以便自动生成测试结果文档。

根据测试用例的测试等级，集成测试应测试哪些用例，系统测试应测试哪些用例，回归测试又该测试哪些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

二、测试用例可以用于规划测试数据的准备

在实施具体的软件测试时，测试数据是与测试用例分离的。按照测试用例准备一组或若干组与之配套的测试原始数据以及标准测试结果。例如，为保证测试报表之类数据集的正确性，按照测试用例来规划准备测试数据是非常有必要的。当然，除准备正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

三、测试用例实际上就是要编写测试脚本的“设计规格说明书”

为提高测试效率，自动测试是目前软件测试大力发展的方向。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

四、测试用例是评估测试结果的度量基准

软件测试实施完成后，需要对测试结果进行评估，并且编制出测试报告。判断软件测试是否完成、衡量测试质量是否达到要求，都需要一些量化的结果，比如说测试覆盖率是多少，测试合格率是多少，重要测试的合格率又是多少，等等。以前统计的基准是软件模块或功能点，但是这种统计显得过于粗糙。采用测试用例作度量基准会更加准确、有效。从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保障。经常说代码的质量不高或者代码的质量很好，量化的标准应该是测试用例的通过率和软件缺陷和软件错误的数量。

五、测试用例是分析软件缺陷的标准

通过收集软件缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

另外，测试用例也可以作为检验测试人员的进度、工作量以及跟踪、管理测试人员的工作效率的因素，尤其是比较适用于对于新的测试人员的检验，从而更加合理做出测试安排和计划。

总之，测试用例将会使得测试的成本降低，并具有可重复使用功能，也是作为检验测试效果的重要因素，设计良好的测试用例将事倍功半。但是测试用例并不是每个人都可以编写的，它需要编写者对产品的设计、功能规格说明书、用户场景以及程序，模块的结构都有比较透彻的了解。测试人员一开始只能执行别人写好的测试案例，随着项目的进展以及测试人员的成熟，测试人员很快能自己编写测试用例，并可以提供给别人使用。

参考文献：

软件测试年度工作计划例10

中图分类号：V448.2 文献标识码：A 文章编号：1674-098X（2014）04（c）-0164-02

航天器项目管理是一个涉及单位多、综合性强、技术复杂、研制周期长的复杂系统工程，管理难度非常大。计划管理是航天器项目管理的重要组成部分，在航天器的研制过程中，软件产品同硬件产品一样是必不可少的配置项，因此航天器的软件计划管理是航天项目管理中一个重要的组成部分，是确保航天项目中软件产品按计划交付所必须的管理过程，在型号的研制过程中发挥着关键的作用。因此，分析研究航天器型号的软件计划管理及控制措施，对于按时完成型号任务具有重要的现实意义。

1 航天器研制的通用流程

项目管理是指为完成某一个特定的目标，应用一定的规范或者规章制度对项目资源进行全面的规划、组织、协调、控制并使之系统化的过程，即在规定的时间、预算和质量目标范围内完成项目的各种工作。航天项目管理是项目管理系统中一个分支，综合性强、技术难度大、涉及的单位多、可靠性要求高，而且研制周期相对较长，因此航天项目管理是一个相对复杂的系统工程。

航天器设计分为系统设计、硬件设计和软件设计，通常按照航天器的通用研制技术流程是先由航天器总体单位进行航天器的系统设计评审工作，完成后给各个分系统单位下达分系统的研制技术要求，然后各分系统单位分别开展分系统的方案设计和技术设计工作，下达分系统内部的软、硬件产品任务书，从而启动软、硬件产品的研制工作。

2 航天器软件计划管理的方法

现阶段，航天器研制单位已经结束了以前“手工作坊式”的生产过程，已经引入了相关的计划、质量管理工具进行软件的管控。软件计划的合理性和准确性直接关系到航天器研制的成败。软件的计划应力求完备，不但要考虑到一些可控因素，同时还要考虑到如果发生意外应如何应变。按照航天器的通用研制技术流程，在分系统完成详细设计后，启动软件产品的研制工作，航天器软件产品的通用研制流程如图1所示。

通常软件计划管理使用OPENPLAN工具进行管理，在OPENPLAN中软件计划严格按照技术流程编制，每个阶段安排合理的工期，软件的最终交付时间满足分系统的计划节点要求。

在整个流程中，主要关注A10：建立和软件功能基线；A3：原型软件验证与确认；A21：软件入受控库；A24：建立并软件产品基线；A31：软件入产品库这5个控制点，这也是难度比较大的控制点。

首先，建立和软件功能基线是软件研制的前提条件，有了明确的输入，对软件来说就是有了软件用户需求、软件任务书、相关通讯协议以及接口文件，软件研制单位才能知道软件该如何干，这些输入条件需要分系统研制单位和卫星总体单位进行充分的协调后才能确定，但是在型号研制之初，往往型号设计方案需要反复协调，输入条件迟迟无法确定，更有甚者，因为技术方案复杂，航天器总体单位无法提出明确的输入条件，直接影响软件研制工作的启动，可能使分系统的研制计划受到影响。

因此抓输入是航天器软件计划管理首先应关注的问题。抓输入首先是抓航天器总体单位的输入，分系统研制单位的软件计划管理者跃层来督促总体单位的输入文件的到位，对计划管理者来说明显感觉有些吃力，但是这又是计划管理者所必须关注的控制点。通常在这个阶段运用的管理手段就是协调、及时与上层机关的计划管理者沟通，督促并安排双方进行协调，如果此项工作迟迟无法完成，或者已经超出了所能承受的最后完成时间，计划管理者必须做出决策，就是基于现有的初步协调结果。分系统自行编制输入文件，同时反馈给航天器总体单位，作为软件研制的临时依据，当然，这个决策必须要争得相关领导同意后方可执行。抓输入的第二层意思是抓分系统的软件用户需求、相关通讯协议、任务书等输入文件，这项工作是分系统的内部工作，是必须完成了分系统级别的设计评审后开展，在这个阶段，就需要软件研制单位参与输入文件的讨论，很多时候软件研制单位积极参与到输入文件的协调中，可以提前了解系统的设计方案，将软件的实现方式也可以提前与方案设计师进行沟通，有利于方案设计的合理性。

其次，原型软件验证与确认是新研软件研制的第一个阶段。其实按照通用的软件研制流程，应该是不应该有这个原型版软件的，但是航天器的特点是设计复杂、研制周期短，在3～4个月的时间内研制出一个全功能的软件，而且完成了所有的测试工作，实现起来难度很大。因此在现阶段几乎所有新研航天器软件都在第一阶段提一个基本型，研制流程是首先由总体确定一个基本型软件的要求，再在这个基础上研制一个基础版本，由这个版本负责与其他硬件产品的调试，并根据调试的结果，改进软件原型，确定最终的软件需求。抓原型版软件的研制是计划管理者所需要关注的第二个问题，在这个阶段主要运用的管理手段就是做好计划，勤沟通，勤协调。新研型号在原型版研制阶段通常比较艰难，方案是新的、软件是新的、设备是新的、产品是新的，方案需要软件验证，软件需要在产品上验证，产品又需要设备验证，当所有都是新的时候往往出现各种各样的问题，解决起来难度比较大，需要各个部门配合，这时候就需要计划管理者多与设计师进行沟通，多跑现场，做好各种条件保障工作。

再次，软件入受控库是软件研制的第二阶段。在这个阶段需要完成软件需求规格说明的编写，完成软件详细设计，代码编写以及单元测试和组装测试工作，这个阶段工作项目比较多，主要是软件研制单位内部的工作，和其他单位的接口相对较少，因此计划管理者主要关注点是抓内部资源的冲突，而且要在入库前安排软件走查工作。

最后，软件入产品库是计划管理者最终关注点，入产品库标志着软件产品完成了编码、测试以及第三方评测等全部工作，具备软件落焊固化的条件，在这个阶段计划管理者需要关注的是要抓产品升级。因为在这个阶段软件产品要参加系统测试和整星测试，在测试过程中会发现各种问题，有可能是方案设计的问题，也有可能是软件设计的问题，因此可能会发生多次的软件升级，因此本阶段要针对每一次升级制定计划，编制软件升级计划，如图2所示并做好跟踪，联合软件产保经理做好软件的版本控制工作。

综上所述，计划管理者编制好软件研制计划，按时跟踪，主要关注上述5个控制点，即可较好地管理好软件产品。

3 航天器软件计划管理的难点及措施

经过调研，在平时的软件计划管理工作中遇到的最大困难有以下3条：

（1）输入条件不能按时到位，影响计划节点；

（2）软件版本太多，版本升级计划不到位，导致各方资源冲突；

（3）软件研制过程中人力资源、设备资源冲突，需要综合调配解决输入条件不能按时到位的困难解决办法在前面已经叙述，这里不再赘述。

研制过程中版本升级计划做不到位的情况经常可以遇到，通常计划管理者只做了第一个版本入库的计划，至于后续版本管理者关于软件会发生多少问题，后续会出现多少版本，无法提前做策划等状况，则了解总体的测试计划，配合分系统的测试计划，制定软件版本的研制和升级计划非常必要。因为在科研生产资源冲突极其严重的时候，只有制订计划，各研制单位才能依据计划调配资源，使各种资源尽可能满足各型号的计划要求。否则很容易出现某个版本研制未完成，还不具备入库条件，而这时候整星催促要上星测试，那么只能把这个版本匆忙入库，更改功能基线，原本为此版本安排的各种资源需要重新调配，浪费了资源，等打算重新启动的时候资源已经调配给别人了，影响最终的产品交付。因此软件计划还是非常重要的。

关于任务中的资源冲突的问题，近年来中国航天器型号任务逐年递增，几乎所有型号项目都受到资源的约束如何利用现有资源，在保证质量的同时，大幅提高产能满足市场需求是航天器研制单位所面临的巨大挑战，软件研制工作也不例外。资源冲突主要包括人力资源冲突、设备冲突、场地冲突，而每项资源冲突又分为型号之间冲突和型号内部两种冲突。资源被同时分配到几个不同的型号时，或者当不同型号同时需要使用某种有限资源时冲突就不可避免的发生了。在多型号并举的管理模式中，解决资源冲突的一个重要手段就是通过合理确定各个型号在不同阶段的优先级，从而达到有效利用资源实现各个型号目标的目的。为了实现高效率、低成本、高质量的计划管理，建立综合策划制定，航天器研制单位已经形成了“型号-产品-部门”三级调度体系，“型号”一级主要下达任务需求，“产品”一级安排产品综合计划，“部门”一级调配内部资源，三级调度体系的运行必须以科研生产综合策划为前提，科研生产综合策划是对全年的各型号的需求进行综合分析的工作，明确各项任务的宏观计划和先后次序，作为各型号全年工作策划的输入，因此软件产品研制的各项资源是在综合策划的基础上进行调配，每年年初各部门根据型号计划安排各项资源，使资源尽量满足各型号需求，如果各型号都能够按照预期的计划完成各项工作，出现资源冲突的几率不大。往往是因为各种原因没有按照计划完成工作，或者临时计划较多，打破年初对各类资源的统筹平衡，从而导致资源冲突。解决资源冲突的办法就是做好计划，严格执行计划，对推迟或者延误的项目及时通知相关单位，必要时刻求助的各级领导的协调。

4 结语

该文从航天器软件研制技术流程出发，陈述了软件计划管理的几个控制点以及控制措施，给航天器软件的研制提供了一系列科学的、可操作性的辅助管理方法，为有效提高航天型号软件的可靠性及质量提供了理论依据。