测试报告缺陷分析

前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇测试报告缺陷分析范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。

测试报告缺陷分析范文第1篇

测试不是挑毛病

然而，对测试领域先行者Glenford Myers先生“测试的目的是证伪”这一概念理解也不能过于片面。在很多软件工程学、软件测试方面的书籍中都提到一个概念:“测试的目的是寻找错误，并且是尽最大可能找出最多的错误”。这很容易让人们认为测试人员就是“挑毛病”的，而由此带来诸多问题。

我们可以假想在一个软件开发公司内，软件测试人员专注于“挑毛病”，开发人员和公司管理层每天会得到这样“简洁”的测试报告:“在今天的测试过程中，系统出现10次宕机现象”。

从“挑毛病”的角度看，测试人员已经很好的完成了自己的工作，但其工作成果对开发人员和公司管理层几乎没有任何帮助。开发人员面对这样的测试报告是无法对软件进行任何修改的;而公司管理层也会疑惑软件质量到底如何，系统能否如期。

长此以往，必然会造成开发人员和测试人员之间无法调和的矛盾;而公司管理层也会认为，测试团队只是“带来坏消息的人”，对公司产品没有提供任何帮助，不如取消为好。

这样的例子看似比较极端，业内普遍认为类似的问题仅出现在一个初创测试团队的公司内，但实际的情况远没有这样乐观，这类现象甚至还蔓延到近年来蓬勃兴起的部分第三方测试机构之中。

一个软件开发公司的管理者，拿到一份刚由某第三方测试机构完成的测试报告，报告结论是该公司开发的软件无法完成预定的需求，在500个用户并发交易的情况下会发生大量交易失败。应该说这样的报告确实挑出了软件的“毛病”，但报告中并未提及造成交易失败的原因，是硬件资源不足、支撑软件参数设置错误还是应用开发问题。这样的报告会使得委托测试单位置疑自己投资进行第三方测试的是否有实际帮助。

造成这些问题的原因归根结底就是对“测试的目的是证伪”这一概念的片面理解。那么，一次成功的测试是如何对问题进行阐述的呢？质量工程学中软件失效的机理给出了很好的答案。

软件错误是人为错误

质量工程学中对于软件失效是这样分析的:由于软件内部逻辑复杂，运行环境动态变化，且不同的软件差异可能很大，因而软件失效机理可能有不同的表现形式。

譬如有的失效过程比较简单，易于追踪分析，而有的失效过程可能非常复杂，难于甚至不可能加以详尽描述和分析，尤其是运行于高度复杂实时环境中的大型软件。

但总的说来，软件失效机理可描述为:软件错误?软件缺陷?软件故障?软件失效。如图1所示，是软件错误发生的过程。

软件错误软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见软件错误是一种人为过程，相对于软件本身，是一种外部行为。

软件缺陷软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一逗点、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

软件故障软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无适当措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

软件失效软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。

因此，软件错误是一种人为错误。

逆流而上解决问题

我们了解了软件失效的机理后，就可以逆流而上，沿着软件失效嗳砑故障嗳砑缺陷嗳砑错误的方向对问题进行阐述和分析?首先，测试人员会说明软件出现了问题，在此对软件失效现象进行了描述;

其次，测试人员会详细阐明是在哪个测试用例的作用下（包括输入数值、处理过程和预期输出结果），软件产生了何种异常输出，问题的类型、严重程度、修改的紧急程度如何，这样就明晰了软件故障的情况;

第三，测试人员会根据测试经验和实际情况，帮助开发人员进行故障定位，找到软件缺陷所在;

第四，测试人员在对问题情况进行统计的基础上，会指出共性问题并分析其产生的原因，发现软件错误。

在这样对问题进行充分分析的基础上，对问题提出修改意见，这样一份问题报告会是一份对开发人员和管理层有意义的报告。

我们可以按照这样的分析方法，对前面企业内部和第三方的两个测试失败的情况进行修正。

软件失效现象:发生宕机/不能承担500个用户的并发交易;软件故障情况:在使用非法数据输入的情况下发生宕机/在进行用户交纳月通话费的情况下交易失败;软件缺陷:软件中缺少合法性校验/服务器CPU占用率达到98%;软件错误:详细设计环节缺少合法性校验内容，且文档评审工作不到位/概要设计环节未进行关键技术验证与仿真;修改建议:增加合法性校验，加强文档评审工作/重新选择服务器（重点是CPU），加强对关键技术的验证与仿真工作。

对于所有问题，都应该对软件的失效现象和故障情况做清晰的表述。除了严重程度会影响外，人员差异也对问题分析的程度有着较大影响。不同的测试人员需要承担不同的职责。

软件测试需三方协调

通过上面的分析可以看到，软件测试的目的决不仅仅是“寻找错误”，今天的软件测试需要在三个方面和开发协调工作，其相互作用如图2所示。

测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。这一工作靠对软件失效现象记录、软件故障表示、软件缺陷的分析完成。

通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进;同时通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。这一工作靠对软件错误的分析完成。

测试报告缺陷分析范文第2篇

1、需求分析：首先需要要学习并了解软件的业务，分析需求点；

2、测试计划：编写整个测试计划，在这个过程中需要参考需求规格说明书，这个阶段一般情况下是测试主管编写。包括了测试人员，测试时间，测试工具，测试方法等；

3、测试用例设计：是测试工作中的最核心的模块，在执行任何测试之前，首先必须完成测试用例的编写。测试用例是指导执行测试，帮助证明软件功能或发现软件缺陷的一种说明。用例设计好之后，会进行评审；

4、用例执行：搭建环境，准备好测试数据，进行预测，预测通过后，按照测试用例进入正式测试；

测试报告缺陷分析范文第3篇

（1）结合实际确定合理的战术技术指标、实现技术和工艺。结合实际确定合理的立项装备战术技术指标，在初步方案设计中尽量采用成熟的技术和工艺，慎重采用新材料、新技术和新工艺，不可盲目追求“高精尖”或“大而全”，已够用好用作为方案设计的基本原则，兼顾系统改建、性能扩展和升级的需要。做好可靠性的预测和安全性、可靠性设计工作，通过设计更改想法，排除或减少设计方案中的危险因素。在经过重大更改后应对方案重新进行风险分析与评估。如果通过设计更改仍不能消除方案中的严重危险因素或降低其危险性，则应放弃当前的方案重新进行方案设计。

（2）建立科学严谨的项目立项程序。新装备项目（包括所有装备立项项目）立项应有一套科学严谨的程序，不能凭感性认识或经验办事。应成立由有关各方面专家组成的论证小组，对装备研制的可行性、战术技术指标的合理性、设计方案的符合性等从技术、进度、质量、风险各方面进行综合论证和评价，选择最佳方案。既要防止草率盲目地启动研制工作，也要防止过分小心谨慎而耽误了研制工作的及时展开，同时要杜绝个别人假借组织的名义进行个人决策。

（3）认真审查和选择研制单位（或协作单位）。新装备研制单位应该有高度的国防观念和军品意识、良好的运营环境、优秀的人才队伍、完善有效的质量保证体系、优良的经营信誉。是否有过类似产品的研制经理、其结果如何也是可供参考的重要因素。

（4）签订科学、规范、完整的研制合同。新装备研制合同应科学、规范、完整，明确各种技术、质量、进度等要求，力戒含糊不清、模棱两可的叙述。研制合同既是研制过程中技术、经济、质量管理的法律文件，也是进行新装备管理的主要依据。签订合同时必须具有强烈的风险意识，学会从风险分析与风险管理的角度研究合同的每一个条款，对可能遇到的风险因素有全面深刻的了解。在合同中对各自的权利和义务做出明确规定，充分体现利益共享风险分担的原则。为了实现上述目标，确保新装备研制的质量，科研单位应该制定详细的质量管理过程文件，经过评审后颁布执行，为质量管理体系有效运转打好基础。这一阶段的质量管理过程文件主要包括立项装备需求调研提纲、立项装备需求调研报告、立项装备建设方案、立项装备建设方案评审报告、单位或上级年度科研项目计划、研制任务书、质量保证计划、风险评估报告、项目经费预算、研制任务书评审报告、评审所提问题及处理情况等。这些质量管理过程文件可以根据研制的新装备的具体情况制定和取舍。

2总体方案设计阶段质量管理过程文件

总体设计方案是整个装备设计的龙头，其设计质量将直接关系到未来装备的性能。总体方案设计既要充分利用已有的成熟技术，缩短研制周期，又应有所创新，利用最新的科研成果提高装备的技战性能。由于总体设计方案的质量是确保装备最终质量和装备整体质量的源中之源、重中之重，放松不得，马虎不得，因此，科研单位应制定详细的这一阶段的质量管理过程文件。这一阶段的质量管理过程文件包括装备技术调研提纲、装备技术调研报告、装备设计开发计划、装备总体技术方案、可靠性设计大纲、维修性设计大纲、保障性设计大纲、测试性设计大纲、安全性设计大纲、环境适应性设计大纲、环境分析报告、标准化大纲、总体技术方案评审报告、评审所提问题及处理情况等。经过评审后颁布执行，以确保总体方案设计的质量，从而最终确保研制的装备整体质量。

3详细设计及软硬件开发阶段质量管理过程文件

（1）严格控制新技术风险因素。为了确保新研制装备的先进性，采用一些新技术、新器件、新材料是必需的，但是为了确保新研制装备的综合效能（性能优、寿命长、故障少、易维修、易保障、最佳费用比）和质量，在方案审查中，要严格控制新技术、新器件、新材料的采用比例，要对技术风险、制度风险、费用风险、后续保障风险和潜在的质量问题进行认真严格的把关；

（2）加强对改进型研制装备的方案审查。要特别注重对成熟技术的借用，注重装备使用质量物理模型的建立和选用，以及对改进技术的研究，要把评审后的改进意见落实到设计方案中；

（3）要注重装备系统的接口技术和方案的审查，使装备各分系统达到最佳组合。这一阶段的质量管理过程文件包括：系统硬件设计方案、系统硬件设计方案评审报告、设备清单、外包合同采购计划、设备器材验收报告、系统硬件平台测试评审报告、软件需求规格说明书、需求分析评审报告、软件概要设计说明、概要设计评审报告、软件详细设计说明、软件详细设计评审报告、软件源代码报告、软件单元测试报告、软件单元测试问题报告、软件单元测试评审报告、软件部件测试报告、软件部件测试问题报告、软件部件测试评审报告、软件配置项测试报告、软件配置项测试问题报告、软件配置项测试评审报告、软件系统测试大纲、软件系统测试细则、软件分系统测试报告、软件分系统测试问题报告、软件分系统测试评审报告、设计和开发问题及处理结果汇总表、评审所提问题及处理情况等。

4系统研制及集成阶段质量管理过程文件

装备研制是把设计方案变成蓝图，并把蓝图变成实物的过程，也是新型装备从孕育到诞生的过程。研制的装备是否能够达到预期的战术技术指标、产品质量是否满足要求都取决于这个阶段，该阶段的风险控制工作对装备研制的成败起着决定性的作用，是装备全寿命周期内风险防范与控制的重中之重。装备研制阶段的主要工作是根据研制合同或技术协议的要求，对购方的需求进行分析，确定其功能基线和详细设计方案，进行装备的详细设计、样件加工，以及进行鉴定试验和定型工作。由于多种原因及条件的限制，许多在方案论证及产品预研阶段未能彻底突破的关键技术及未能量化的技术要求都被带到研制阶段，使研制阶段的技术风险增大。研制阶段的工作任务繁重，面临的风险因素众多，是风险因素集中、高发的阶段，技术风险、资金风险、进度风险、组织人才风险、政策风险与道德风险都会给研制工作带来严重影响。在进行装备设计时应注重安全性、可靠性、工艺性、测试性、维修性、保障性设计。设计失误是最大的失误，一点微小的疏忽都可能给生产、使用和保障带来意想不到的困难甚至灾难。在该阶段控制好风险对于降低批生产和维护保障阶段的风险有重要意义。要重视设计的工艺性，在研制过程中，应注重考察设计的工艺性（包括工装设备、工艺流程、工艺规程等），特别是新设备、新工艺及特种工艺等，发现和消除工艺设计及工艺文件的缺陷，以满足未来装备批生产的需求。注重产品的鉴定（定性）试验、可靠性试验及使用环节。通过试验及使用及时发现和处理产品的故障及设计缺陷，及时采取纠正、预防措施，并将其落实到设计更改中去。加强技术状态的控制与管理。在研制阶段，产品的技术状态复杂多变，管理上的疏忽会引起产品技术状态的混乱。要按国军标的要求做好技术状态的控制与管理。这一阶段的质量管理过程文件包括用户检测大纲、系统测试报告、系统测试问题报告、用户检测评审报告、设计和开发问题及处理结果汇总表、评审所提问题及处理情况等。

5验收与交付阶段质量管理过程文件

现在许多试制装备在科研、生产、验收、交付和使用过程中是高度交叉的，科研与生产无论是技术状态还是时间周期上已经没有明显的界线划分，研制阶段的风险因素会影响生产、验收和交付，生产阶段的风险因素会影响到装备的使用和保障。要控制好验收与交付阶段的风险，保质保量完成装备交付任务，需要加强生产组织管理、加强技术状态控制、加强质量管理，应根据装备产品技术规范的要求做好例行试验和定期检验工作，认真分析和解决试验中出现的各种问题，抓好问题的归零处理和措施落实工作，完善履历、技术说明书、操作规程、备品备件等相关资料。这一阶段的质量管理过程文件包括验收大纲、用户验收结果报告、用户验收评审报告、试运行记录、试运行报告、设计定型报告、用户验收交接清单、顾客满意度分析、数据分析等。

6结束语

测试报告缺陷分析范文第4篇

摘 要：软件维护在现实的软件开发过程中占有十分重要的地位，本文介绍了我院的软件维护实践教学的教学方案以及具体实施情况。

关键词：软件工程；软件开发；实验；实践教学；软件维护

中图分类号：G642

文献标识码：B

1 软件维护在软件工程实践教学中的意义

软件工程是一门理论与实践并重的基础课程，教学内容紧密围绕软件开发过程中的各种工程化方法、技术和思想[1]。在现实的软件开发过程中，软件维护占有很重要的地位，许多报告都指出软件维护成本已经占到总体成本的40%～70%以上。软件维护关注于“变化”，包括纠错性(corrective)、适应性(adaptive)、完善性(perfective)、预防性(preventative)等维护类型[2]。当前的软件工程教学中一般都已经包括了软件维护相关理论和方法相关的内容，例如软件维护及可维护性的概念、软件维护的类型和过程、变更管理以及软件再工程等。但软件工程实践教学仍然以瀑布式的正向开发过程为主，主要体现需求分析、设计、实现和测试等基本开发活动，缺少软件维护的实践训练。

由于软件维护在软件开发中的重要性，许多国内外学者都呼吁在软件工程教学中引入软件维护实践(如文献[3])。在软件工程实践教学中引入软件维护内容主要基于以下这些考虑。

首先，软件维护在软件开发中占有十分重要的地位，典型的软件工程开发中花在软件维护上的时间往往比软件开发还要多[3]。而且，大部分毕业生进入软件开发机构后都是从维护性的开发任务开始的。

其次，软件维护实践还能使学生更直观地体会和理解软件工程方法和原则的重要性。软件工程教学中系统地讲授了许多重要的软件工程方法和原则，包括软件文档规范、设计原则(如层次化、高内聚低耦合等)以及编码习惯(如标识符命名、注释和排版等)等，其中大部分都与软件的可维护性相关。通过对文档不全、设计混乱和编码习惯不好的软件系统进行维护，可以对这些方法和原则获得直观、深入的认识和理解。例如，对标识符命名不规范、缺少注释、排版混乱的代码进行阅读和理解，可以深刻认识到好的编码习惯对于维护工作的重要性。

此外，软件维护实践能使学生更好地认识软件开发的现实困难。缺陷报告、需求变更、软硬件平台的变化等导致软件演化的因素在现实的软件开发中总是存在的。通过在实践教学中设置阶段性的需求变更，可以让学生对于现实的软件开发有更加真实的体验，从而提高对迭代、增量式开发等实用的软件开发方法和技术的认知。

2 软件维护实践教学方案

软件维护主要包括纠错性、适应性、完善性和预防性维护四种类型[2]：纠错性维护是针对所发现的错误或缺陷而对软件进行的修改；适应性维护是为了适应外部环境(如硬件、操作系统、外部规则等)的变化而对软件进行的修改；完善性维护是由于功能扩展而进行的软件修改；预防性维护是面向未来的维护需要，为了提高软件的适应性和可维护性等而进行的系统优化和改进。软件维护实践教学应以循序渐进的方式覆盖这四个方面的软件维护任务，同时穿插并突出相关软件工程方法和原则的体验和熏陶。

根据这一总体目标，相应的软件维护实践教学将在给定的作为维护对象的遗留系统基础上，分三个阶段进行，如图1所示。遗留系统分析评估阶段的主要目的是在理解遗留系统需求的基础上对系统的外部和内部质量进行初步的了解和评价。系统改进维护阶段的目标是以当前系统需求为基础，对遗留系统的缺陷和错误进行修改，对系统内部的设计、实现以及文档质量进行改进。系统需求演化维护阶段通过若干次迭代的需求和系统环境变更，进行系统的完善性和适应性维护。针对新需求和系统环境设置的修改将通过系统测试确认，测试结果反馈给系统改进维护阶段，从而进行相应的纠错性维护活动。此外，系统修改过程中发现的内部质量问题(例如可扩展性上的不足等)同样也会反馈给系统改进维护阶段，从而进行相应的预防性维护活动。这种反馈关系以及需求和系统环境变更的迭代进行使得后两个阶段将反复迭代进行。

(1) 遗留系统分析评估阶段

与传统的基于分析、设计和实现的软件工程实践教学不同，软件维护实践教学以已经开发完成的遗留软件系统作为起点。每个小组分配到的遗留系统都是由其他人开发的，犹如在软件开发中接手其他小组的维护工作。因此，首先要求他们在理解项目当前需求的基础上，对所分配的系统进行分析和评估，从而为后续的维护活动打下基础。这阶段的主要实践任务包括：

图1 软件维护实践教学过程

1) 理解遗留系统需求。与正向软件开发一样，软件维护实践也要从了解系统需求开始。需求是评价当前系统质量，进而规划并实施各种纠错性、适应性、完善性和预防性维护活动的基础。

2) 系统测试及外部质量评价。外部质量因素是那些用户能轻易观察到的软件特性，例如功能正确性、性能、可靠性、可用性等[2]。通过系统测试，可以针对用户需求得到遗留系统的外部质量总体评价，以及待纠正的错误和缺陷列表，从而为纠错性维护打下基础。

3) 系统理解及内部质量评价。内部质量是指与系统内部设计和实现相关的质量特性，例如可理解性、可维护性、可扩展性等，它们对于软件工程师而言是十分重要的[2]。通过阅读遗留系统文档(可能残缺不全或质量不高)以及系统代码，同时借助于相关辅助理解工具的支持，获得对系统设计(如体系结构和模块结构等)和代码的初步理解，在此基础上对系统的设计和实现质量进行评价，从而为预防性维护打下基础。

这一阶段首先强化了对于软件测试的实践。在以往的教学实践中，我们发现学生在正向开发阶段往往不太重视测试(对于自己开发的系统进行测试往往会觉得没有必要或比较敷衍了事)，且常与调试混淆。而在软件维护实践中，测试对象是他人开发的系统(实践中常常发现学生对于测试、评价其他人开发的系统比较有兴趣)，而且测试结果直接决定了对遗留系统的外部质量评价和纠错性改进方案，因此学生往往会认真对待。系统理解能力也非常重要。在教学实践中，可以鼓励学生充分运用相关辅助理解工具进行系统理解，例如Eclipse相关插件所提供的代码UML视图、类语法树、调用关系图、度量信息等辅助理解功能。

除此之外，系统理解及内部质量评价还强化了对于软件工程设计和实现原则的认识。通过阅读遗留系统文档和代码，学生们可以深切体会到好的系统设计、编码风格以及文档规范对于软件开发的重要性。实践中，他们经常会抱怨遗留系统文档不全或不一致、设计混乱、编码风格不好，而这些其实也正是他们自己在正向开发阶段很容易出现的问题。

(2) 系统改进维护阶段

系统改进维护阶段将在遗留系统分析和评估基础上，进行纠错性和预防性维护。针对用户需求以及一般的软件设计和实现质量准则，从外部质量和内部质量两个方面对遗留系统进行改进。这阶段的主要实践任务包括：

1) 纠错性维护实施。针对系统测试过程中发现的问题，进行纠错性维护，包括消除系统意外出错、纠正与功能需求不一致的地方、改进系统性能、可靠性等非功能质量方面的不足。

2) 回归测试及总结。纠错性维护结束后，通过回归测试验证纠错性维护的效果，并进行总结。

3) 预防性维护方案制定及实施。针对系统内部质量评价中发现的问题以及纠错性维护中遇到的困难(例如难以扩展的系统结构等)，制定并实施对系统的预防性维护方案，包括对系统设计和编码质量的改进，以及对开发文档的补充和完善等。

4) 系统评审及总结。预防性维护结束后，对系统的设计、代码及文档进行评审，总结改进情况以及所获得的体会和经验。

这一阶段首先涵盖了纠错性维护和预防性维护实践。其次，预防性维护实践通过系统设计、开发文档、编码风格等方面的改进，强化了相关软件工程方法和原则的训练。

(3) 系统需求演化维护阶段

前两个阶段的软件维护实践都还停留在原有系统基础上，系统需求演化阶段将通过用户需求和系统环境的变化，引导学生进行完善性和适应性维护实践。由于现实中的软件开发一般都包含多次迭代和增量，因此这阶段的维护实践也将迭代进行多次。这阶段的主要实践任务包括：

1) 需求和系统环境变更分析。在原有系统需求基础上，提出若干新的扩展功能要求和系统环境变更(例如改变原有的数据库管理系统)，要求学生通过与助教的沟通和交流明确需求和系统环境变更要求。

2) 系统修改方案制定及实施。根据变更要求和对系统设计、实现的理解确定系统修改方案并加以实施。

3) 系统测试。针对需求或系统环境变更进行系统测试，对系统修改进行确认，所发现的错误和缺陷将反馈给纠错性维护活动。

4) 系统内部质量反馈。针对需求或系统环境变更的修改活动可以对系统的内部设计和实现质量进行检验，暴露设计、实现及文档等方面的问题，这些问题将反馈给预防性维护活动。

系统需求演化维护阶段除了涵盖完善性和适应性维护实践外，还具有以下几个方面的作用：使学生体验到真实软件开发中多次迭代的增量式开发过程；通过需求变更直观体会到可维护性、可扩展性等内部设计和实现质量的重要性；验证改进维护阶段对于改进系统内部质量的效果，加深对于良好的软件设计、编码和文档习惯的认识。

3 教学方案实施

软件工程课程实验可以按照由浅入深的顺序分为认知性导入实验、方法性实验和综合实践三个部分，其中前两部分穿插在一个学期的软件工程课程中进行，而综合实践则可以在后续的软件实践类课程中安排[1]。在教学实践中，软件维护实践应该作为综合实践安排，此时学生已经有了软件工程课程教学和一些正向开发实践(主要包括需求分析、设计和实现)基础。软件维护实践以3～5人的小组为单位，每个人可以分别担任需求分析、设计、实现和测试等不同实践任务。

在实践项目选择上，我们从此前的软件工程课程实践、数据库课程实践(数据库应用系统)等实践项目中选取一些具有典型性的系统实现(包括文档和代码等)作为软件维护实践候选对象。这些项目一般已经基本实现了原有的用户需求，但在外部质量和内部设计和实现上还存在许多不足。选取这类项目的好处是由类似背景的学生完成，能够反映许多典型的软件实践问题，同时相关项目学生已经有所接触，也较为熟悉。

在软件实践教学中，我们选取书店管理系统等多个在以往软件工程和数据库等相关课程的课程实践项目作为软件维护实践的对象。这些项目都是以数据库为核心的信息管理系统，这类系统较为典型且本身的需求较容易发生变化。

(1) 遗留系统分析评估阶段

此阶段学生将首先借助于原始需求说明以及与客户(由助教扮演)的交互明确系统需求。在此基础上通过测试和文档、代码分析进行外部质量和内部质量评价。遗留系统外部质量上存在的主要问题包括某些功能与需求不符、运行不稳定、用户使用不方便等。而内部质量方面的普遍问题包括类结构设计混乱、文档缺乏或不规范、编码质量差(命名不规范、缺少注释)等。

本阶段安排约4周时间，其中第1周用于了解遗留系统原始需求，第2周用于系统测试，后2周用于系统理解和分析。本阶段要求提交系统测试报告、系统总体评价报告(包括外部质量和内部质量)。

(2) 系统改进维护阶段

此阶段的系统改进针对系统测试报告中所发现的错误和缺陷进行纠错性维护，针对系统总体评价报告中指出的设计、编码和文档上的不足进行改进。初次的系统改进后，本阶段的维护活动还可能在系统需求演化维护阶段的反馈作用下反复多次进行(见图1)。

本阶段在每次迭代中安排约2周时间，要求提交回归测试报告、纠错性维护总结以及预防性维护总结。

(3) 系统需求演化维护阶段

此阶段的维护活动由需求或系统环境变更发起。以书店管理系统为例，遗留系统实现的基本功能包括图书查询、选购、订单生成、付款(现金方式)及简单的库存管理等。需求变更可以包括增加信用卡支付功能(通过虚拟的银行支付接口)、增加邮购和网上订购功能、增加会员制折扣功能等。系统环境变更可以包括改变所用数据库管理系统(如由Access改为MySQL)、改变国内地区标准编码(用于标识供应商及顾客的地区)等。相应的维护活动除了满足这些新需求及系统环境外，还可以引导学生进一步改进系统的设计和实现等。例如，为了更好的容纳信用卡支付这一新的付款方式，可以从现金支付和信用卡支付中抽取出公共的支付方式类，从而改进系统的设计结构。

本阶段在每次迭代中安排约2周时间，要求提交系统修改方案、测试报告和系统内部质量改进反馈报告。

这样，在一学期的软件实践课程中，系统改进维护阶段和系统需求演化维护阶段一起可以安排3次左右的迭代，每次完成1～2项需求或系统环境变更。

我们在复旦大学计算机科学与技术学院的软件工程本科教学实践中利用软件实践课程开展软件维护实践教学。软件实践课程安排在软件工程课程(第六学期)之后的第七学期，此时学生已经系统的学习过软件工程、数据库、操作系统等课程，初步具备了开展综合性软件开发实践的基础。

4 总结

软件开发实践是软件工程教学的重要组成部分。传统的软件开发实践教学主要以瀑布式的正向开发实践为主，忽略了软件维护实践的训练。软件维护实践的意义不仅在于软件维护在现实软件开发中的重要地位，而且可以使学生更加直观、深刻地体会和理解相关的软件工程方法和原则。通过遗留系统分析评估以及多次迭代的系统改进维护和需求演化维护，不仅培养了系统理解、修改等软件维护实践能力，还强化了软件设计准则、编码和文档习惯以及软件测试能力的培养。

参考文献

[1] 彭鑫，赵文耘，钱乐秋．软件工程实验教学研究与实践[J]．计算机教育，2007，(20).

测试报告缺陷分析范文第5篇

关键词：软件开发过程；项目管理

随着信息技术的快速发展，应用软件的功能越来越庞大，为了便于管理，把项目管理的方法引入到软件开发过程当中，对所有的软件活动进行有效的管理。本文按照传统的瀑布模型从项目管理九大知识领域的角度，进行软件管理项目的工作实践管理。

第一阶段：立项

（1）建立团队：明确项目经理，选择项目组成员，识别项目干系人。

（2）编写项目任务书：明确项目的背景和目标，能够描述出基本的项目范围，识别并且确定整个项目的需求，能够指出项目中干系人的期望值，确认需要交付的产品或服务，功能和性能指标。

（3）制定工作计划：重点描述任务的分配计划，执行的时间计划。

（4）制定成本计划：制定活动清单，采购计划，人力成本计划。

（5）制定评审流程：由项目的管理层和相关干系人制定流程。

（6）制定沟通管理：制定沟通管理。

（7）签订合同：立项、初验、中验、维保过程中确认交付的产品或者服务。

第二阶段：需求的调研

（1）人员分配：分配调研人员工作任务。

（2）编写需求规格说明书：进一步明确软件的范围，原型的制定（UI操作界面+UE界面设计），明确才用的开发环境和开发工具。

（3）运营指标的检测：监控工作任务的完成情况，监控预算是否变化，监控需求的变更。

（4）时间管理：任务分解wbs，定义具体的活动，排列顺序，估算工作时间。

第三阶段：设计和开发

（1）人员管理：分配开发人员工作任务。

（2）编写概要设计说明书，编写详细设计说明书，编写代码。

（3）运营指标的监控：监控工作任务的完成情况，监控预算是否变化，监控需求的变更。

第四阶段：测试

（1）人员管理：分配测试人员工作任务。

（2）部署：部署生产环境。

（3）编写功能测试测试计划，编写功能测试用例并执行测试，编写功能测试报告。

（4）编写性能测试测试计划，录制脚本并分析，编写性能测试报告。

（5）测试管理：缺陷管理。

（6）运营指标的监控：功能和性能是否和需求一致，工作任务否是及时完成。

第五阶段：实施

（1）人员管理：分配实施人员任务。

制定实施方案：在生产环境部署软件的使用环境，要保证执行计划所需的资源

（2）运营指标的监控：是否及时完成实施人员的培训及管理工作。

（3）用户验证确认。

第六阶段：运行和维护

（1）对项目代码进行打包，交付。

（2）合同终结：得到项目干系人的认可。

（3）跟踪问题，并解决问题。

（4）撰写项目总结报告。

在对项目的综合管理中，要制定计划，要严格的执行计划，遇到变化，要有效的进行协调和控制；在项目范围管理中，对范围进行定义和确认，有效的变更进行控制；对项目时间的管理就是对活动进行定义，根据活动的性质，进行排序，以及时间的估算，人员进度的安排和进度的控制；在项目成本管理中，要有资源计划，成本估算，成本预算和成本控制；在项目质量管理就是质量计划，质量评估和质量控制；在项目人力资源管理中强调，项目组成员的组建，干系人的识别；在项目沟通管理中，强调沟通计划，激励措施，执行情况报告以及信息管理；项目风险管理，强调风险分析和识别，以及风险监控；最后是采购管理，制定采购计划，确认项目范围内的都已经完成，合同管理及合同收尾。

软件开发类项目通常是通过团队合作的方式来完成的，引入了项目管理的知识，在整个项目中对工作任务的分解、估算工作时间，人员的分配、风险的监控、成本的控制、质量的把握等方面起到了很好的作用。让项目的每个阶段，都能够在管理者的监控之下，以达到在成本、时间、质量三者的一个平衡，最终完成整个项目的开发，最终打包交付到用户手中，合同终结。

参考文献：

[1] 王勇、张斌译.项目管理知识体系指南.电子工业出版社.（美）项目管理协会