学文网软件测试年度工作计划第1篇
作为软件的重要环节，软件测试越来越受到人们的重视。随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。然而，为了尽可能多地找出中的错误，生产出高的软件产品，加强对测试工作的组织和管理就显得尤为重要。
从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可作相对较强。但是，由于测试的依据是规格说明书、文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。软件的生命周期可用***1的表示。
为了确保软件的质量，对***1的过程应进行严格的管理。虽然测试是在实现且证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。
软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对***的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。
一个好的测试计划可以起到如下作用
1. 避免测试的“事件驱动”
2. 使测试工作和整个开发工作融合起来
3. 资源和变更事先作为一个可控制的风险项目经理圈子
测试计划的模板在各个公司中都大同小异，在个人实践中发现，测试计划制定中存在的问题具有相似，下面重点就这些相似的问题谈谈如何制定软件项目测试计划。
问题一：测试阶段划分
就通常软件项目而言，基本上采用“瀑布型开发方式，这种开发方式下，各个项目主要活动比较清晰。整个项目生命周期为需设计编测试实施维护。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常*遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。
相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。
问题二：系统测试阶段日程安排
划分阶段清楚了，随之而来的问题是测试执行需要多长的时间？标准的工程方法或CMM方式是对工作量进行估算，然后得出具体的估算值。但是这种方法过于复杂，可以另辟专题讨论。一个可作的简单方法是：根据测试执行上一阶段的活动时间进行换算，换算方法是与上一阶段活动时间1：1.1～1.5左右。举个例子，对测试经理来说，因为开发计划可能包含了单元测试和集成测试，系统测试的时间大概是编*阶段（包含单元测试和集成测试）1到1.5倍。这种方法的优点是简单，依赖于项目计划的日程安排，缺点是水分太多，难于量化。那么，可以采用的另一个简单方法是经验评估。评估方法如下：项目管理者联盟文章
1. 计算需求文档的页数，得出系统测试用例的页数
需求页数：系统测试用例页数≈ 1：1
2. 由系统测试用例页数计算编写系统测试用例时间转自项目管理者联盟
编写系统测试用例时间≈系统测试用例页数×1小时
3. 计算执行系统测试用例时间
编写系统用例用时：执行系统测试用时≈ 1：
4. 计算回归测试包含的时间项目经理博客
系统测试用时：回归测试用时≈ 2：1
注：以上比值是个人工程经验值，需要更正比值的测试经理可以在具体实践中收集数据
基于以上方法优点是需求为已知的，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况下；缺点是处于研发状态的项目，需求不清晰的时候比较难计算。现套用一个例子加于说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人；假如一个月为22个工作日，则共计约11人/月，即投入4个人需要3个月左右时间工作量完成。当然，这是系统测试需要的全部时间。根据测试阶段划分原则，设计用例时间可以和开发同步进行，只需在测试阶段中安排的时间为1500小时即4人2个月工作量。
项目管理培训
（测试经理在编写测试计划时候，测试进度中的计划开始/结束时间往往用如20050101-20051201的具体时间划分方式，这样引起的问题是当项目计划进行变更的时候，测试计划时间不得不随时调整，这种变更可能是频繁而琐碎的，可以替代的办法是取消这种方式，采用30工作日/2人或者2人月这种工作量记录方式，这样一来，只需在项目计划中跟踪阶段的具体开始时间即可，不必反复修改测试计划。）
项目管理培训
值得注意的是：国内大多数公司的测试时间都是不足的，不可能按照这样的理想比例进行运作，因为测试执行的时间实际上不可能占据整个项目周期的1/2，甚至要短于其中任何一个项目阶段时间。即使是微软的测试结束原则也并不是完成所有必需的测试，而是测试在按计划结束的那一天结束！在测试时间不足的情况下，可参考下面项目计划变更时的做法，因为计划变更也涉及到测试时间不足的情况。
参考文献：
[1]徐新海；林宇斐；易伟；；CPU-GPGPU异构体系结构相关技术综述[J]；计算机工程与科学；2009年S1期
软件测试年度工作计划第2篇
在比赛中出现任何技术故障，不仅会给运动员带来无尽的懊恼和愤怒，还会影响赛事的精彩程度。因此，信息系统是关系到比赛质量的一个关键因素，对于奥运会这样的世界顶级赛事来说，信息系统的重要性更加不可估量，这就为奥运会筹备人员带来了无法估量的压力，白晓颖作为北京奥运会组织委员会的一员，从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万字的总体规划报告，结合北京奥运会的技术战略，从人员组织、测试过程、进度计划、质量保证、策略选择及风险分析、实验室建设、测试工具选择、标准与规范、经费预算等九个方面，全面讨论了北京奥运会集成测试的总体规划方案，为奥运会信息系统的筹备工作，奠定了坚定的基础。
报告提交以后，得到了相关专家的认可，认为调研报告详细、准确、全面地反映了奥运会信息系统在测试目标、内容、组织和管理方式等方面的要求，并评价课题组制定的集成测试总体方案系统、全面、切合实际、可操作性强。课题组的工作成果被直接应用于奥组委技术战略，为北京奥运会信息系统的成功运行提供了有利保障，成为伦敦总结会中北京奥运会技术传承的一个重要经验，得到国际奥委会会的高度评价。
经过不断学习和历练，白晓颖在迅速成长，如今她已经成为清华大学计算机软件研究所副所长。作为项目负责人，她先后承担了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万字的总体规划报告，结合北京奥运会的技术战略，从人员组织、测试过程、进度计划、质量保证、策略选择及风险分析、实验室建设、测试工具选择、标准与规范、经费预算等九个方面，全面讨论了北京奥运会集成测试的总体规划方案，为奥运会信息系统的筹备工作，奠定了坚定的基础。
报告提交以后，得到了相关专家的认可，认为调研报告详细、准确、全面地反映了奥运会信息系统在测试目标、内容、组织和管理方式等方面的要求，并评价课题组制定的集成测试总体方案系统、全面、切合实际、可操作性强。课题组的工作成果被直接应用于奥组委技术战略，为北京奥运会信息系统的成功运行提供了有利保障，成为伦敦总结会中北京奥运会技术传承的一个重要经验，得到国际奥委会会的高度评价。
软件测试年度工作计划第3篇
关键词：CMM；软件开发；软件测试
中***分类号：TP311文献标识码：A文章编号：1009-3044(2007)17-31397-02
Based on CMM Software Development and Testing
YANG Guang
(Northeastern University College of Software,Shenyang 110004,China)
Abstract:Demand for software development, including design, programming and testing, and software quality assurance testing software is the key steps have been more and more people's attention. Currently, the CMM (Capability Maturity Model, Capability Maturity Model) has become the world's most popular, most practical kind of software production process standards, received international recognition software industry has become in today's enterprise-scale software as an indispensable. In software development and testing process, the characteristics of the enterprise itself, using the CMM software development management processes, to improve software development quality and efficiency.
Key words:CMM;software development;software testing
1 引言
软件开发包括需求、设计、编程和测试，而软件测试是软件质量保证的关键步骤，已经得到人们越来越多的重视。目前，CMM （Capability Maturity Model，能力成熟度模型）已经成为国际上最流行、最实用的一种软件生产过程标准，得到了国际软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。2000年，***的《鼓励软件产业和集成电路产业发展的若干***策》中第17条中表示，将对软件出口型企业CMM认证费用予以适当支持。如今，国内企业也越来越重视基于CMM的软件开发和测试。
2 CMM简介
20 世纪 80 年代中期，国际软件产业界对软件过程的研究十分重视，因为在采用软件工程方法克服软件危机的过程中，人们已认识到，软件过程是否完善是软件风险大小的决定因素。1986 年 11 月，美国卡内基梅隆大学的软件工程研究所（ Software Engineering Institute ， SEI ）应美国联邦***府的要求，针对美国***对软件承包商的能力评价问题，研究 “ 过程成熟度框架 ”。1987 年 9 月， SEI 开发了一套软件能力成熟度框架和软件成熟度问卷，用来评估软件供应商的能力。1991 年， SEI 自己总结了成熟度框架和初版成熟度问卷的实践经验，并以此为基础推出了 “软件能力成熟度模型（ Capability Maturity Model For Software ， CMM ） 1.0 版 ”。1993 年， SEI 在广泛听取美国***府和各界软件专家的意见后，推出了目前世界上比较流行的通用的 CMM1.1 版。
CMM是一个用来描述软件组织的模型，用于评价软件承包能力并帮助其改善软件质量的方法。CMM是评估软件能力与成熟度的一套标准，它侧重于软件开发过程的管理和工程能力的提高与评估。CMM表现了软件组织能力成熟度的特称，确切的说，CMM是在软件流程上的能力成熟度。 CMM将软件组织抽象为能力成熟度模型。能力成熟度是软件组织解决“按时，按计划，高质量”这一问题的关键因素，而CMM的目的，就是要帮助软件组织在进度和预算范围之内生产出高质量的软件产品。
CMM标准共分五个等级（5级为最高级别），是一个动态的过程，企业可根据不同级别的要求，循序渐进，不断改进。从第一级到第五级分别为：初始级、可重复级、定义级、管理级和优化级，从低到高，软件开发生产的计划精度越来越高，每单位工程的生产周期越来越短，每单位工程的成本也越来越低。
3 基于CMM的软件开发与测试
CMM是一种管理方法，是一个软件过程改进框架，这个框架与软件生命周期无关，也与采用的技术无关。CMM目前代表着软件发展的一种思路，一种提高软件过程能力的途径。尽管它存在着某些不足。例如，成熟级别、关键过程域、公共属性和关键实践还需要在软件行业进一步深入地讨论和修订，但它确实为软件行业的发展提供了一个良好的框架，而且是浓度软件过程能力提高的有用工具。增强我国软件企业的竞争力，提高国产软件的水平是国人的共同愿望，但目前我国软件水平，尤其是软件开发能力和软件生产能力还很差。那么，如何提高我国软件的开发和生产能力，从而提高软件整体水平？软件企业实施基于CMM的软件开发与测试也许不失为一条有效的途径。
按照CMM要求将开发分为九个阶段：项目规划、小组启动、需求分析、概要设计、详细设计、编码调试、系统集成与测试、验收、项目关闭。其中软件的测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审。
下面从各个阶段主要项目活动、阶段交付文档和评审点出发，详细描述项目开发的各个阶段。
(1)项目规划
项目规划要对所要解决的问题进行总体定义，包括了解用户的要求及现实环境。计划阶段要从技术、经济和社会等3个方面研究并论证本软件项目的可行性，编写可行性研究报告，探讨解决问题的方案，并对可供使用的资源（如计算机硬件、系统软件、人力等）成本，可取得的效益和开发进度做出估计，以制订完成开发任务的实施计划。另外，项目的相关人员提出创新性的想法，并对自己的想法进行可行性分析，研究新想法的问题范围，探索这个问题是否值得去解决，是否有大概的解决办法，并对需要的资源进行估计。
本阶段的交付文档是立项说明书，立项说明书必须提交工程委员会进行评审。如果评审不通过，项目就此结束。
(2)小组启动
在项目立项评审后，根据先前的资源估计成立项目开发小组，确立开发小组中各个角色的成员，然后对项目开发需要的软件和硬件资源进行分配，并搭建好项目开发环境。结合项目最后的期限要求以及分析CMM 历史度量库，确立项目开发的一级计划，确定以下各个开发阶段的评审点。本阶段的交付文档主要有项目计划书和小组启动说明书。项目计划书必须经过工程委员会的评审，如果评审通不过，必须参考CMM的历史度量库来修改项目计划直至通过评审。
(3)需求分析
需求分析是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把需求用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。分析阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程***和数据字典等方法。
基于CMM的需求分析阶段更注重项目的管理流程。首先项目组要确立在该阶段的二级计划，然后开始需求分析，明确需要开发系统必须具备的功能。并要主动与用户交流，获取需求并分析需求。制定相应的系统测试计划，在这以后的每个阶段项目组长都必须提交阶段工作报告。
CMM的需求分析阶段主要交付的文档有更新后的项目计划书、需求跟踪矩阵、需求分析说明书、系统测试计划书、项目词汇表和阶段工作报告。需求分析说明书必须提交给工程委员会评审，只有在评审通过后，才能进入下一个开发阶段。
(4)概要设计
一般软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块。概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构***表示。
基于CMM的概要设计阶段不但要为系统描述系统流程***、构建系统的可能方案、确立的系统总体方案和进行模块划分及设计。而且还有进行一些系统的集成测试计划和设计评审等工作。该阶段主要的交付文档为更新的项目计划书、更新的需求跟踪矩阵、编程规范、概要设计说明书(包含总体方案)、集成测试计划书、意见反馈单、阶段工作报告。各个模块的概要设计说明书和总体方案必须经过评审。
(5)详细设计
详细设计阶段是对概要设计的结果的细化，概要设计已经达到函数级的分解，详细设计是对分解的函数进行实现的描述。一般详细设计的首先要设计模块的程序流程、算法和数据结构，其次，要设计数据库，常用方法还是结构化程序设计方法。
基于CMM的详细设计阶段必须依次补充完善需求跟踪矩阵，并确立单元测试计划和进行评审。该阶段的交付文档为更新的项目计划书、更新的需求跟踪矩阵、详细设计说明书、单元测试计划书、意见反馈单和阶段工作报告。各个模块的详细设计必须经过评审。
(6)编码调试
软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的"源程序清单"。充分了解软件开发语言、工具的特性和编程风格，有助于开发工具的选择以及保证软件产品的开发质量。当前软件开发中除在专用场合，已经很少使用二十世纪80年代的高级语言了，取而代之的是面向对象的开发语言。而且面向对象的开发语言和开发环境大都合为一体，因此大大提高了开发的速度。
基于CMM的编码调试阶段的任务包括：①项目组制定出在本阶段的二级计划；②学习确认编程规范，再开始编码，同时必须进行同行检查和走读检视；③进行单元测试。一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。该阶段的交付文档为更新的项目计划书、更新的需求跟踪矩阵、代码、单元测试报告、意见反馈单和问题跟踪单。所有代码必须经过工程委员会的评审，以确认是否符合编程规范要求。
(7)系统集成和测试
软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例（测试数据和预期的输出结果组成了测试用例）。如何才能设计出一套出色的测试用例，关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法和黑盒法。
一般测试分为：单元测试、集成测试和系统测试。单元测试阶段通常是属于开发项目组编码调试的范畴。单元测试阶段后要将系统集成成一个可运行版本。此后，就进入系统集成和测试阶段，系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能******工作并完成所赋予的任务。该阶段主要的交付文档为集成测试报告和系统测试报告、问题跟踪单和阶段工作报告。在测试阶段完成后，必须经过内部验收的评审才可以提交进入正式的验收阶段。
(8)验收
在验收阶段，项目组主要是配合客户进行验收。首先准备好用户手册以及相关文档，并提交系统验收检查单，协助客户进行验收测试。本阶段的交付文档为验收报告，客户签署的验收报告也就是对本阶段的评审。
(9)项目关闭
本开发过程最后强调的是项目关闭阶段，这个阶段是对项目开发的总结。针对CMM 中关键过程域的实施执行情况，各个角色必须提交相应的角色总结报告。在项目组长汇总后，总结项目开发中的不足和经验，提交过程改进意见和CMM度量库。这个过程有助于项目开发组织改进自己的软件开发过程。
4 总结
CMM 是国际公认的 “ 事实 ” 标准，是中国软件业走向国际市场的通行证。CMM的目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件。因此在软件的开发和测试的过程中，针对企业自身的特点，采用CMM软件开发管理流程，能够提高软件开发的质量和效率。
参考文献：
[1]何新责.软件能力成熟度模型[M].北京:清华大学出版社,2000.
[2]刘莉,傅英亮,陶强.基于CMM的软件开发和维护过程的研究[J].信息技术与信息化,2006,(05).
软件测试年度工作计划第4篇
关键词：软件测试；测试成熟度模型（TMM）；模型框架；成熟度等级结构
中***分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）17-0226-03
Abstract： Modeling software testing can greatly improve the quality and efficiency of software testing， and CMMI and other popular models， there is no detailed description of the process for software testing， software testing is no level of maturity of the evaluation and measurement， There is a lack of software testing process improvement goals and guidance. Based on this situation， this article Test Maturity Model（TMM） has been proposed by Dr. Burnstein formal description given maturity level structure TMM model elaborated five test level of maturity goals and sub-goals，， TMM and implementation methods are described， as well as the author summarizes and Reflection on the TMM model.
Key words： software testing； Test Maturity Model（TMM）； modeling framework； maturity level structure
1 背景
随着信息时代的快速发展，软件产业也逐步进入高速增长态势，软件过程的研究已经发展为软件测试行业的基础工作之一。要加强软件组织的开发能力、提高软件产品的质量，就必须不断地对软件过程的能力进行改进。因此，软件能力成熟度模型即CMM在1987年美国Carnegie Mellon 大学软件工程研究所应运而生CMM逐渐成为了评估软件开发过程的管理以及工程能力的标准。目前，已经形成了以个体软件过程、团队软件过程以及过程成熟度集成模型CMMI等为主导的软件开发过程改进体系[1]。但是，传统CMM的着眼点在于软件组织的开发过程和软件过程能力，并没有关于软件测试成熟度的概念，也没有研究改进软件测试过程的方法，因此，随着软件测试在软件生命周期中的地位越来越突出，软件测试成熟度得到了业内人士的高度重视，并且在传统的软件过程成熟度基础上继续进行模型改进，其中，比较具有代表性的是由Ilene Burnstein博士等人提出的软件测试成熟度模型（TMM），该模型是对CMMI模型的补充，是对CMMI模型的存在问题的修正，同时也对改进软件测试过程及提高软件测试能力做出了思想和方法上的指导。
2 TMM模型框架简介
TMM模型为了改进软件测试与评价过程，对CMM模型进行了较大程度的改进与补充。TMM模型在CMM模型的原有基础将软件测试过程划分为初始级、定义级、集成级、管理与度量级和优化级5个等级[2]`。处于初始级的软件测试，是一个混乱的过程，测试过程在编码之后，与调试未加区分；阶段定义级的测试过程，很大程度上凸显出测试过程与调试的区分，但是其被定义为编码之后进行的的***阶段，显然不符合软件工程的要求；前两个阶段的存在的问题在集成级得到改善，集成级将软件测试融入到整个软件生命周期中，从需求分析开始，测试人员将伴随这个开发过程制定相应的测试计划、测试目标等；从管理和度量级开始，整个测试过程就已经由定性描述进入可度量化的过程。在此过程中，除进行测试之外，还有对软件生命周期各个环节的管理与审查；优化级是以前四级为基础，优化并预防缺陷、质量控制、监控测试成本与效率，为整个测试过程指引方向。
而每个等级（除等级1）都有自己的成熟度目标、子目标以及活动、任务和职责。TMM的模型框架如***1所示。
由***1可以得出，若要达到某成熟度等级，所必须实现的成熟度目标，即软件测试的改进目标。而成熟度子目标的定义更为具体，定义了该等级的范围、界限和需要完成的事项。通过活动和任务来实现子目标，任务和活动涉及实施和组织调整问题。活动和任务则定义了为了软件组织达到某一等级，进行软件测试改进的行动计划。三组人员各司其职，完成相关任务与活动，达到成熟度子目标[3]。
3 TMM的等级结构
TMM将测试的成熟度分为5个等级，每一级别都是一个测试过程，都有自己的过程域，软件组织要想达到更高的级别，就必须先满足前一个级别的过程域。同时也必须完成所有的被定义的目标。这些目标的定义，需要通过活动、任务和责任进行标记，在进行过程中，需要根据相关人员的特殊需求来不断调整[1]。如***2所示：
在TMM等级描述中，详细阐述了测试过程的特点以及为达到规定级别所需要完成的目标和子目标。
1）第一等级为初始级。软件测试的终极目标是为了查找程序中的错误，在这一阶段，由于相应的编码任务还没有完成，缺乏一定的测试资源，因此软件测试没有相对清晰的目标，测试任务也可有可无。
2）第二等级为定义级。在这一阶段，软件测试的目标是为了验证软件是否符合相应的需求，因此会启动一些相应的软件测试计划过程，并对采用的软件测试方法制度化，在定义级，由于在进行软件测试之前要把所有的编码工作完成，导致的结果就是在需求分析阶段与设计阶段产生的一些软件缺陷会一直遗留到编码阶段才能被发现。
3）第三等级是集成级。在这一阶段，会有相应的、相对***的测试部门出现，测试工作不需要在完成编码后才能进行，而是在满足用户需求的目标上进行测试工作。并集成到软件生命周期的各个阶段中。在第三等级，需组建一个软件测试组织用于负责测试规划、测试缺陷跟踪等测试技术工作。同时在测试过程中需要有相应的测试工具对测试工作进行辅助。同时，软件测试小组成员要和质量保证专家一起，与客户进行沟通，从软件需求分析阶段制定软件测试计划，并根据需求分析表格制定相应的软件测试目标。该阶段的缺点为没有行之有效的评审制度以及没有一套质量控制与度量的标准等。
4）第四等级为管理与度量级。在这一阶段，软件测试是可以进行度量与质量控制的过程，应保证进行可靠性、可用性与可维护性等方面的测试。软件测试活动既包括程序语言，还把评审与审查作为软件测试活动的补充，用于发现及消除软件产品缺陷。为了测试过程的完备性，建立了缺陷管理系统并将缺陷的等级进行划分。同时测试人员采用数据库记录和管理相应的测试数据以及测试用例。但在管理与度量级，由于没有相应的缺陷预防系统，不能自动的进行收集与分析软件测试中生成的相应数据。
5）第五等级为优化级。在这一阶段，改进了第四等级的缺陷，已经具有相应的缺陷预防能力和软件质量控制能力，能够保证之前发现的缺陷不会在后期继续产生。在这一级，自动化测试工具是整个测试过程的重要组成部分。可以进行自动的收集与分析测试中产生的数据。并建立了测试流程与测试的规章制度。由于优化级的测试活动是可重复性、已定义、已管理和已测量，所以软件组织可以对测试过程进行不断的优化改进和调整。
根据上面描述的TMM的5个等级，给出相应的成熟度等级目标和子目标，如表1所示。
② 为软件测试活动定义相应的目标、任务、活动和工具等＼&
启动测试计划过程＼&① 制定软件测试计划模版并进行任务分配
② 获取用户需求
③ 准备软件测试活动所需的工具＼&将基本的测试技术和方法制度化＼&① 在软件组织中实施基本的测试技术与方法，例如黑盒测试、白盒测试策略等。
② 制定相应的管理制度，明确规定基本的测试技术和方法何时、怎样实施，以及基本的测试工具等。＼&集成级＼&
建立软件测试组织＼&① 选择和培训相关人员成立测试小组
② 为每个测试小组成员进行职责分配
③ 与客户进行讨论，获取用户需求＼&
制定技术培训计划＼&① 为测试人员制定技术培训计划
② 明确具体的培训内容，例如：测试方法、测试标准、测试技术与工具、审查与评审过程等＼&将软件测试集成到软件生命周期中＼&① 将软件测试计划阶段划分为和生命周期各阶段相关联的各个子阶段
② 将测试策划集成到生命周期的各阶段
③ 打通渠道，提高用户参与度＼&控制与监督测试过程＼&① 监督和控制过程可视化，为测试过程提供依据
② 随时与测试策划对比，及时调整测试进展
③ 定义和配置测试相关项＼&
管理和测量级＼&
建立组织范围内的评审程序＼&① 拟定正式的评审程序
② 将评审定义为测试活动，在生命周期中实施通行评审
③ 识别、记录、清除软件产品和测试工作的缺陷＼&
拟制测试度量程序＼&① 拟定一套关于测试过程质量与能力的度量程序
② 准确识别测试数据，对测试数据进行详细处理分析
③ 根据测试结果，不断修正测试计划＼&
软件质量评价＼&① 根据测试过程充分性，定义可度量的质量属性和目标
② 测试过程完成后，需要保证软件产品可靠、可用、稳定、安全＼&
优化级＼&
应用过程数据预防缺陷＼&① 成立预防缺陷相关小组
② 记录缺陷、分析缺陷，找出缺陷根源
③ 缺陷预防组的相关成员与其他组的成员相互配合制定缺陷预防计划，防止已被识别的缺陷再次产生＼&
实施质量控制度量＼&① 根据所定义质量属性，进行测试
② 通过统计抽样、等级度量促进测试过程
③ 融入开发团队，减少缺陷，提高软件质量
④ 运用模型工具，加强测试充分性＼&
优化测试过程＼&① 根据测试进展，量化测试过程，对测试过程不断优化调整
② 建立组织结构标准，支撑成熟度的不断提高＼&]
4 TMM实施
为了指导软件工程人员进行正确的软件过程评估，采用TMM等级提供支持。在软件组织中实施TMM时，可遵循以下步骤：
1）准备活动
这个步骤中要建立评估小组，选择与培训小组成员，确定组长，选择测评项目，并制定评估计划，准备参加评估的组织部门。根据客户需求制定评估问题表。
2）实施评估
评估过程中，评估小组成员通过和被评估人员进行沟通，获取相关的评估信息，通过查询相关文档与调查表进行信息补充。为保证信息的准确性与客观性，可将信息记入问题表。评估人员根据记录信息，划分软件组织的TMM等级。
3）分析评估结果
评估人员根据评估输出的TMM等级及相应的记录分析当前软件组织存在的缺陷，并指出该软件组织需要提高的领域以及要达到的下一个目标的优先级。量化的改进目标，制定出相应的行动计划。
4）活动计划
为了使软件组织能够达到TMM的高等级，评估小组应根据高优先级的改进目标开发活动计划，通过该计划描述相应的活动和资源，并改进现有的实践内容和进度。
5 结束语
软件产品的开发过程是一项长期的工程，需要不断研究和实践。本文针对传统软件成熟度模型的不足，将TMM模型进行了详细的阐述。TMM模型补充了CMMI模型的不足，能够充分的覆盖软件测试的一系列问题，并且软件组织可以根据TMM的要求，评估当前软件测试能力的状态，并对测试目标和测试过程进行不断修正，极大提高软件测试人员的工作效率。利用TMM模型不断优化测试过程和目标，将会给软件开发和测试组织带来质量和经济上的双丰收。
参考文献：
[1] 朱少民. 软件测试方法和技术[M]. 北京： 清华大学出版社， 2010： 71-74.
[2] 王峰， 谷天阳， 佟金荣. 软件测评能力成熟度模型研究[J]. 计算机工程与科学， 2011（9）： 174-178.
软件测试年度工作计划第5篇
关键词：软件开发；软件测试；测试手段；重要意义
中***分类号：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.
软件测试年度工作计划第6篇
关键词: 软件 可靠性工程
随着科学技术的不断进步，计算机技术被越来越多地应用到武器系统中。计算机软件的复杂程度随着功能的增强，因而系统的可靠性也越来越与软件直接相关。例如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、结束语
软件测试年度工作计划第7篇
关键词:软件可靠性工程
随着科学技术的不断进步，计算机技术被越来越多地应用到武器系统中。计算机软件的复杂程度随着功能的增强，因而系统的可靠性也越来越与软件直接相关。例如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、结束语
转载请注明出处学文网 » 软件测试年度工作计划