测试方案和测试报告

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

测试方案和测试报告范文第1篇

关键词 智能变电站；二次设备；自动测试

中图分类号 TM77 文献标识码 A 文章编号 1673-9671-（2012）111-0183-01

1 自动测试系统的原理与方案

智能变电站智能电气设备通信采用IEC61850标准。按照该标准，站内网络分为三层：过程层、间隔层和站控层。过程层采用SV报文传输交流采样数据，采用GOOSE报文传输遥信和控制信息；在站控层则采用MMS协议传输信息。IEC61850支持智能电子设备的互联和互操作。因此，以IEC61850标准为基础，可以实现实现向二次设备输入故障信息并观测其相应的动作情况。根据IEC61850标准，IED需要对装置进行建模，将功能模块和各类数据信息写入ICD模型文件。ICD文件包含了装置的功能描述和通信接口描述，详细描述了装置的输入输出数据特征。自动检测系统借助ICD文件可以读取装置内部参数。通过读取保护定值，自动设定测试用列模拟不同故障情况，产生相应的SV和GOOSE报文发送至二次设备，结合保护动作接点和动作报文自动评估测试结果，测试完毕后，自动形成用户格式的测试报告。

自动测试系统以PC机作为硬件平台，通过交换机与数字式继电保护测试仪和保护装置进行通信。通过网络通信，自动测试系统读取保护装置定值参数，自动生成测试方案，驱动数字式保护测试仪输出故障电压电流，然后监视保护装置动作情况并给予相应的评价，并生成测试报告，实现保护装置的自动测试。

上位机采用PC机，实现测试系统的建立、测试方案编制和加载、测试任务下装、测试过程监视、测试结果评价和生成报告等。测试系统通过与被测装置的通信读取ICD文件，获得被测装置的信息模型，从而完成自动读取保护装置的定值、自动投退保护压板、自动读取动作报文。根据被测装置的信息编制自动测试方案或加载已经编制完成的测试方案，并设定需要监视的信号和评价标准。

数字式测试仪是自动测试任务的执行单元。数字式测试仪通过与上位机的通信，接收测试任务，根据任务完成故障模拟，通过SV报文和GOOSE报文将信息输出至被测装置。同时测试仪通过接收被测装置发出的GOOSE报文信息判断被测装置的动作情况。

2 系统软件架构

自动测试系统软件采用Visual C++6.0进行开发。程序采用模块化设计，各个测试功能模块被设计为独立组件可以单独加载和卸载。组件功能明确，相互独立，便于维护和使用。测试过程中根据需要动态加载和卸载所需的组件，方便实现任意类型的保护装置测试。同时，允许用户根据规程编制测试模板，用户可以根据需要灵活编写，实现了测试过程的自动化和标准化。

测试系统主要由测试计划制定模块、测试计划监控模块、试验报告处理模块以及通讯规约解析模块组成。应用自动测试软件平台，按照检验规程或作业指导书、保护说明书、设计图纸，按照检验项目和程序编写每个项目的测试模板；基于测试模板，组织测试流程，定义测试方法，计算测试参数，自动实现测试过程。测试模块包括软件功能组件的调用命令、测试数据与定值数据进行链接的公式及数学表达式、程序运行控制参数、试验结果数据的链接参数等，还包括测试过程中的操作提示、安全注意事项等内容。一个测试模块可以完成一种保护功能的测试，全部测试模块组成一套完整的测试模板，就可以完成整套保护装置的测试任务。

系统在应用结构上划分为三个层次，分别为硬件接口层、测试接口层、测试层。

2.1 硬件接口层

负责与继电保护测试仪硬件进行通讯，控制继电保护测试仪进行电压、电流模拟量的输出和开关量翻转反馈的信息；从测试仪开入量翻转获取保护装置的动作时间。硬件接口层开放电压、电流发生数据接口和硬件通讯接口。

2.2 测试接口层

在硬件接口层进行一次封装，派生出保护的测试功能算法，例如距离定值校验、过流保护试验等。此层根据保护测试功能的需要，计算出测试仪需要输出的电压、电流值，通过硬件接口层接口与测试仪进行通讯。

2.3 测试层

测试层是测试系统在测试标准化、自动测试方面开发的测试平台软件，它通过数据库来管理设备、装置测试方案、测试报告等。测试层包括自动测试平台和模板开发平台等。

自动测试平台应用数据库和模块化结构技术，采用测试模板方式定制测试程序。整个测试过程将全部自动完成，实现测试过程的自动化。

模板开发平台是针对具体型号保护装置开发专用继电保护测试程序的平台。依照继电保护检验规程，并结合保护装置的说明书、设备图纸，生成保护装置的测试模板（测试方案）和报告模板（标准试验报告格式）。

3 自动测试系统的特点和应用

自动测试系统具有以下特点：

1）测试平台软件的模板文件中，测试参数与保护定值相关联。通过读取保护定值，使用数学公式和逻辑运算式将保护定值转化为测试参数。试验时打开模板文件，通过MMS接口与保护装置建立通讯链接读取当前运行定值后，即可开始试验，不需要人工对试验参数进行计算和设置，大大简化了测试过程。

2）系统通过设置评估判据，可以对测试结果自动进行评估。评估的判据包含：跳闸、重合、后加速是否动作，动作误差是否满足要求，动作时间是否在允许范围内以及动作逻辑是否正确。设置了评估判据后，测试结束后，程序将自动给出“合格”或“不合格”的结论。

自动测试系统可应用于智能变电站间隔层二次设备的检测。不同类型、不同型号的装置对应的测试项目、测试方法、测试参数各不相同，通过模板开发平台为不同的装置开发测试模板，可以方便地实现各种类型和型号的二次装置的自动测试。

4 结束语

智能变电站二次设备的调试和校验直接影响着二次设备运行的可靠性和智能变电站的运行维护水平。智能变电站二次设备自动测试系统能够自动完成二次设备的大部分测试项目，极大提高了设备的测试效率；通过测试模板标准化定制，确保测试过程规范、全面，提升了设备测试质量。实现智能变电站二次设备自动测试能有效提高二次设备的检修水平，对智能变电站二次设备的运行维护具有积极的意义。

参考文献

测试方案和测试报告范文第2篇

善舞者技艺出众

能手持彩练当空舞者,绝非等闲之辈,自身技艺出众当然不言而喻,正如在TD、TD-LTE领域,中兴通讯凭借强大的研发能力及产品化能力,在 3G元年取得令世人瞩目的成绩、新年伊始就取得了开门红一样。

记者:2009年,中兴通讯在TD\TD-LTE领域成绩斐然,请谈谈具体在哪些方面取得了突出的成绩和做出了突出的贡献。

中兴:

2009年是中国3G元年,中兴通讯在TD\TD-LTE领域取得了可喜的成绩。依托多年的全力投入和深厚积累,中兴通讯在TD技术创新方面继续引领业界。在HSPA MX4倍速、Iur-g+方案外场测试、SDR软基站应用等领域都取得了突破进展。在中移三期招标中再次拔得头筹,取得了商务第一、技术第一、后评估第一、厂家综合实力第一,综合排名第一“五项第一”的骄人成绩。

2009年也是TD-LTE产业化迅猛发展的一年。中兴通讯作为国家科技重大专项课题“TD-LTE基站设备开发”的承担单位,2009年初中兴通讯基于公司成熟的SDR基站平台推出了TD-LTE端到端的商用解决方案。2009年4月和8月,在中移和Vodafone联合组织的两个阶段的PoC测试中取得了很好的成绩,系统功能、性能、稳定性都处于业界领先位置。

2009年9月中兴通讯通过了中国移动世博会TD-LTE邀约测试,承建世博新闻中心TD-LTE室内覆盖。2009年11月演示了TD-LTE 130Mbps峰值速率,接近TD-LTE 2×2MIMO条件下的理论极限;2009年10月在TD-LTE工作组的MTNet实验室测试中,中兴通讯首批通过基本功能集测试。2010年1月在怀柔外场完成了TD-LTE多小区多UE的测试,该项测试报告提交到NGMN LSTI,受到了业界的好评。

目前TD-LTE产业链的瓶颈在终端芯片,2009年中兴通讯在支持和推动TD-LTE终端芯片发展方面也做了大量的工作。2009年4月在PoC测试中,中兴通讯在业界使用了第三方测试终端Aeroflex TM500 ,下行峰值速率达到当时TM500能力上限 61.228 Mbps。2009年8月中兴通讯与ASTRI 终端完成第一阶段IODT测试,是首家向LSTI 提交TD-LTE IODT测试报告的厂家。2009年中兴通讯自研的TD-LTE终端芯片也有了长足的进展。

2009年是TD-LTE产业化起步的一年,中兴通讯与工信部、中国移动、以及终端芯片合作伙伴紧密配合,在历次测试中都有出色的表现。设备功能、无线性能不断成熟完善,为2010年大规模试验网验证打下了坚实的基础。在新的一年里,中兴通讯将对TD-LTE进行持续投入,为推动TD-LTE成为真正的主流国际标准做出更大的贡献。

记者:今年伊始,中兴通讯在TD-LTE技术研发和商用试验上就传来好消息,在业界率先通过工信部TD-LTE外场第一阶段测试,并首家提交LSTI报告。这对中兴通讯、TD-LTE业界有着什么样的特殊意义?h

中兴:

2009年TD-LTE产业化进展非常迅速,这得益于中国移动对TD-LTE产业的推动,也得益于包括工信部中国移动在内的TD-LTE工作组的推动。TD-LTE工作组对各阶段产业化目标、测试规范、测试环境的安排都有整体规划,为产业化发展指明了方向和发展路线。中兴通讯是TD-LTE产业的积极推动者之一,对TD-LTE全力投入和不断创新,2009年在端到端整体解决方案的开发和产业链合作方面都做了大量的工作,取得了长足的进展。2009年完成了基本功能集的室内测试,并且率先在怀柔外场完成了小规模外场的无线组网性能测试。

TD-LTE怀柔外场测试是由TD-LTE工作组组织,工信部电信研究院、中国移动、Vodafone等单位联合进行测试。测试外场规模是15个小区连续覆盖,单小区测试UE数目10个。测试内容包括吞吐量、时延、覆盖、移动性、多用户调度、用户体验等,测试结果达到预期效果。测试报告作为LSTIFCT(Friendly custom Trial)阶段测试报告同时提交到NGMN LSTI工作组,受到业界的好评,增强了TD-LTE的国际影响力。

TD-LTE外场测试是TD-LTE产业化发展的关键环节,是TD-LTE测试从室内走向外场,从单站功能、性能测试走向外场小规模组网测试的重要里程碑。虽然怀柔外场的规模还不算大,但却是一个重要的验证平台。基于这个平台无线系统的组网性能将会加速完善,TD-LTE的端到端解决方案向着成熟商用迈出了重要的一步。

善舞者厚积薄发

手持彩练当空舞,绝非一日一夕之功。正如中兴通讯在TD-LTE领域取得领跑者的地位,也是多年潜心积累而厚积薄发的结果。

(4)记者:中兴通讯自2001年投入TD系统的研究和开发以来,经过近十年持续和大规模的投入,到今天在TD-LTE方面俨然已处于行业领跑者的地位。十年磨一剑,中兴的TD、TD-LTE走过了一条怎样的发展之路?

中兴:

测试方案和测试报告范文第3篇

关键词：计算机；软件测试

中图分类号：TP311 文献标识码：A 文章编号：1007-9599　（2012）　18-0000-02

1 计算机软件测试的概念

所谓软件测试，主要是以发现程序错误为目的而执行程序的过程，是结合软件开发过程中每一个阶段的规格及软件内部的结构进行认真设计的测试用例。因此，我们可以说，软件测试就是在精心搭建的环境下对程序进行执行，以更好的发现软件中的错误，对其可靠性给出鉴定。

2 软件测试的流程

2.1 设计测试方案。设计测试方案是在软件测试初始阶段进行的，在这个工作中，首先要调研所需要应对的系统框架和业务模型，对测试需求进行收集。其次，根据测试需求制订一个合理的测试计划。具体来说，我们的测试团队要对被测试项目有着提前的了解，而且开发部门也要配合测试部门的工作，提供各种系统规格书、系统总体介绍、网络拓扑结构图、用户使用手册、系统配置说明、应用部署与配置以及关键服务器及等文档。经过与业务部门协商之后，就可以确定下来这次测试的目标，然后对这一目标进行细化，制定出各个阶段的目标，并制定相应的指标要求。

2.2 开发测试场景。这主要是指开发测试脚本，是针对被测系统业务进行模拟、录制、编程、参数化、脚本定制以及调试测的工作，通过测试场景的开发，可以使测试脚本实现对现实场景的真是模拟，而且我们还可以通过改变参数来控制并发数以及思考时间等属性。

2.3 执行测试。这主要是按照预先制订的测试方案，在完成测试环境以及测试场景之后进行的工作。

2.4 测试报告及分析。这一工作主要是在执行完测试之后进行的，主要的任务是对测试过程中所暴露的问题进行收集及分析。而测试报告则主要是对测试过程中监控报告以及报表的汇总，然后对其进行一定整理之后所得到的结论性文档。

2.5 回归测试。开发部门在分析了测试报告之后，会对软件的缺陷进行了修复或者优化，使其具有更高的性能，而对于这种修复之后软件的测试就是回归测试。

3 计算机软件测试的基本方法

3.1 按照阶段进行划分。如果按照阶段对计算机软件测试方法进行划分的话，则可以分为单元测试、集成测试、系统测试、验收测试、回归测试、Alpha测试以及Beta测试。

（1）单元测试。这主要是指对软件的基本组成单位进行测试，比如一个模块。单元测试是动态测试中最基本，也是最重要的部分，它主要的目的是对软件基本单元的正确性进行验证。在单元测试中，由于需要我们了解程序的设计及编码的细节，所以这一工作主要是由程序员进行。另外，单元测试还需要开发测试驱动模块以及桩模块进行辅助。在单元测试中，主要的方法包括控制流测试、排错测试、数据流测试以及分域测试等。

（2）集成测试。集成测试主要进行于软件系统集成过程中，它的作用是对单位之间接口的正确性进行检查。一般来说，根据计划，我们将在模块集成为较大系统的过程中运行该系统，查看各个组成部分是否合拍。在这个过程中，使用的策略有自底向上以及自顶向下这两种。

（3）系统测试。这主要是针对已经集成好的系统进行测试，进而对系统的性能及正确性进行检查。由于这一测试的整体难度比较大，我们要制定合理的计划，并严格按照计划执行测试工作。在系统测试工作中，主要的方法有随机测试、性能测试以及功能测试。

（4）验收测试。这种测试的目的是主要是对软件的购买者展示软件的性能，确保其符合购买者的需求。在这个过程中，测试数据主要来自于系统测试中使用的数据。这是软件在应用之前最后的测试。

（5）回归测试。上文中已经对其概念进行了简要的分析，这里将进一步对其进行分析。回归测试的主要目的是检测所进行的修改是否合理。在这个问题上，修改有着以下内涵：首先是修改达到了预期的目的，其次是修改不能够对软件其他功能的正确性产生影响。

（6）Alpha测试。这是在软件开发即将完成的时候所进行的测试，在测试之后，一般仍然会有一些设计上的变更，在这一测试工作中，测试人员主要是最终用户而不是程序员或者测试员。

（7）Beta测试。这是指在开发及测试在根本完成之后进行的测试，这种测试的工作一般由其他人员或者最终用户来完成，不可以由测试员完成。

3.2 按照按测试方法进行划分。按照测试方法进行划分则可以分为白盒测试以及黑盒测试这两种。

（1）白盒测试。这也被我们称之为逻辑驱动测试或者结构测试，是基于覆盖所有代码、路径、分支以及条件的测试。在白盒测试中，我们是清楚程序内部工作过程的，主要的目的是检测其内部动作是否符合规格说明书的要求，至于软件的功能是否符合要求则不属于这一测试的范畴。常见的白盒测试方法有逻辑驱动以及基路测试等。

在使用白盒测试方法的时候，测试者必须对程序的内部结构进行检查，并通过对其逻辑的检查得到测试数据。在这种测试方法中，存在着以下不足：首先，对于程序是否符合设计规范，或者说程序本身就是错误程序的情况，我们是没有办法检查的。其次，对于程序中因路径遗漏而导致的错误，我们无法检查。最后，某些和数据相关的错误我们没有办法检查。在这一具体的工作中，常使用的工具有Junit　Framework，Jtest等。

（2）黑盒测试。顾名思义，黑盒测试和白盒测试是相反的。在黑盒测试中，我们的测试目的不是为了检查内部设计及代码是否正确，而是检查程序能否符合功能性方面的需求，因此，这种测试也被我们称之为数据驱动测试或者功能测试。

在测试的过程中，我们将完全不考虑其内部特性，只是将程序作为一个黑盒子看待，然后在其接口进行测试，具体的工作就是检查程序在接收到输入数据之后能否产生正确的数据输出信息。在黑盒测试方法中，常见的方法等价类划分、因—果图、边值分析以及错误推测等。

由于黑盒测试方法属于穷举输入测试，我们只有将所有的输入都当成测试情况使用之后才能够检查出程序中所有的错误，而实际的测试情况有无穷多个，因此，我们除了要有合法的输入之外，还要有不合法却可能的输入。一般常用的工具有WinRunner，Rational　Robot，QuickTestPro等。

4 结语

由上文我们可以看出，软件测试中的环节比较多，而且方法也有很大的差别。因此，做好计算机软件测试工作并不是一件很轻松的事情，需要我们对各种软件测试方法了如指掌。所以，我们还要不断的学习，并加强探索，以一个严谨科学的态度去面对软件测试工作，只有这样才能真正的使软件发挥其应有的作用，进而提升企业的竞争力。

参考文献：

[1]何强.通信软件自动化测试系统的研究与实现[D].中南大学，2009.

测试方案和测试报告范文第4篇

CI接口包括两个部分：传送流接口和命令接口。两个接口都采用层次化结构，以使得整体接口设计、实现更加容易。层次化结构中，高层实现相同，但是低层实现可以不同，数字电视机卡分离(DTV-CI方案)标准中物理层按照PC卡的实现标准制定。

传送流接口实现双向传送MPEG-2包。模块处理主机选定的业务，返回解扰过的传送包，其它未选定的包不变，如果模块不具备解扰主机选定业务的能力，则将传送流直接返回。

命令接口负责模块和主机之间的通信。功能包括：支持同一个主机处理多模块的能力、支持主机和模块之间会话、支持对象扩展。

数字电视机卡分离符合性测试概述

数字电视机卡分离标准主要描述了CI接口的传送流接口和命令接口的协议，通过两个接口的双向交互，接收机完成通用部分功能，如解调、解复用和解调功能；卡完成包括身份识别、电视收费等用户管理系统、能够实现CA解密解扰技术等独立功能。

数字电视机卡分离标准符合性测试主要是针对CI接口的传送流和命令流接口协议进行测试，可以分为四个部分：机的测试、卡的测试和监控测试和TS流测试。

测试机模式：

测试平台在测试中扮演着DTV-CI卡的角色，来完成同接收机的交互功能。即测试平台同接收机进行连接，接收机同测试平台交互发送数据，测试平台向接收机发送特定测试序列，对命令流接口协议进行分步测试，根据待测接收机对测试序列的反馈来判定命令流接口协议同机卡分离标准的符合性程度，生成对应于测试集条目的测试报告。

测试卡模式：

测试平台在测试中扮演着主机的角色，来完成同DTV-CI卡的交互功能。即测试平台同DTV-CI卡进行连接，卡同测试平台交互发送数据，测试平台向卡发送特定测试序列，对命令流接口协议进行分步测试，根据待测卡对测试序列的反馈来判定命令流接口协议同机卡分离标准的符合性程度，生成对应于测试集条目的测试报告。

监控测试：

此时测试平台扮演着监控的角色，来完成监控主机和DTV-CI卡的交换数据功能。即将该测试平台同时与接收机和DTV-CI卡相连，来完成接收机、测试平台、DTV-CI卡三者交互数据功能，每次的数据交互都要通过测试平台来加以显示，由此来完成对接收机和DTV-CI卡满足机卡分离技术性规范的符合性测试。如果任意产品同标准协议不符合，可以在监控模式下完成对该段的协议分析和判断功能。

TS流测试：

前面三项测试者D是对CI接口的命令流接口进行测试,TS流测试是对数字电视通用接口的传送流进行测试，同时还完成对DTV-CI卡的解扰功能的测试。

该项测试需要搭建一个播发端，播放码流为一段明文流和一段带有固定CW字加扰流。将测试设备同待测接收机和待测DTV-CI卡相连，最后再将接收机同播发端想连接。开始测试时，由播放设备发送特定码流，在测试平台上不仅可以通过对照参考码流和对照参考数据文件来主观判定TS流的传输质量，还可以通过对TS流的输出统计来给出客观的TS流传输质量。

数字电视机卡分离符合性测试的意义

数字电视机卡分离标准符合性测试平台的最终目的是建成一个通用的、符合我国数字电视机卡分离标准技术体制的平台，用于完成对数字电视系统中采用DTV-CI方案的接收机和卡的测试功能，一方面可以形成数字电视机卡分离标准符合性检测能力：即可以保证通过该平台测试的机器，肯定可以与任意一种通过测试的卡相连相通；通过该测试平台测试的卡，肯定可以与任意一种通过测试的机器相连相通。另一方面还可以作为数字电视机卡分离的基准：测试完毕后，不能通过测试的机与卡可以从测试中了解到自身与标准的要求在那些方面存在差距，在那些技术指标中不能满足标准的要求，需要在那些方面做一些改进工作。

测试平台搭建的功能需求

数字电视机卡分离标准符合性测试平台的搭建，至少满足以下功能需求：

1、通过数据库控制用户登录及分配操作和使用权限功能。

2、测试模式选择：即测试平台至少提供对接收机测试、对DTV-CI卡的测试、同时对接收机和DTV-CI卡监控的交互和对TS流测试等多个模式供用户选择功能。

3、为了能够提供测试模式所描述的功能，测试平台应提供以下接口：至少提供一个与主机的DTV-CI接口、至少提供一个同卡的DTV-CI接口、同主控软件的网络接口(或者提供使用USB等其它方式接口)。

4、完成对机测试模式下初始化过程、建立传输连接过程、删除传输连接过程、查询命令、请求发送数据、打开资源管理器会话、关闭资源管理器会话、轮廓查询、轮廓变更、轮廓应答、应用信息查询、CA信息查询、时间日期测试测试序列的编写工作。

5、完成对卡测试模式下的命令口测试初始化、建立并删除传输连接测试、打开并关闭与资源管理器的会话测试、轮廓查询测试、轮廓变更测试、轮廓应答测试、应用信息查询测试、CA信息查询测试、时间日期测试等测试序列的编写工作。

6、控制流命令口协议分析模块：即必须具备对接收到的命令口数据进行分析，显示，存储等处理功能。

7、测试平台对控制流和传输流的数据进行打包，解包和存储功能。

8、测试从证管理模块完成测试／认证客户信息管理功能，该模块要求为数据库管理系统，可以记录参与测试／认证的客户信息、测试结论等内容，推荐使用SQLSERVER2000。

9、测试报表的自动生成，即每次测试完成后，测试系统能够自动生成一份测试报表，客观的记录整个测试过程。

10、主机和模块在测试过程出现的错误记录和错误分析。

11、测试序列任意组合的生成、编辑功能，对自定义的测试序列的生成、编辑功能。

12、出错屏蔽功能：测试平台必须具备出错屏蔽功能，即对一些小的错误，用户具有对错误屏蔽的选择能力，由此可以保证测试过程的继续进行。

13、通过数据库完成对控制命令的存取、默认参数的保存等功能。

14、对测试序列的对象的参数的编辑功能。

15、测试过程中，测试平台和待测设备命令交互的显示功能。

16、测试平台必须具备可扩展性，能适应标准升级需要。相当于未来数字电视机卡分离(DTV-CI方案)标准：将要升级支持回传通道、PC连接、付费电视、电子支付、电子商务、数字媒体等扩展功能

应用，故测试平台从底层设计开始就要为将来扩展功能的应用作一些预留。

注解：

1、计划测试主要计划测试进度，人员分配，风险计划及避险计划，资金安排，沟通方式等等……，可以参照《计算机软件测试文件编制规范》(GB／T9386-1988)。

2、硬件的开发包括系统设计软硬件方案，PCB原理图，元器件清单，CPU的选型，FPGA选型，FPGA部分实现的功能定义，软件结构的确定，操作系统的选取。提交详细的测试平台开发系统方案。对于硬件平台的开发，即开发一个小型的嵌入式设备，该设备具有同接收机和C1卡和PC机交换数据的功能。对于这一块的开发，因为要保证同各种品牌的接收机和CI卡的交互通讯能力，该项开发涉及到硬件和操作系统的选取以及驱动程序的开发。FPGA功能定义文挡，FPGA实现代码，软件设计文档和软件验证文挡，测试平台APl，软件实现源代码。

3、控制平台的开发就是在硬件平台基础上进行的软件开发：包括测试控制流的命令、响应、分析机制，数据流的视频显示功能，设备的管理，测试模式，CA的识别、响应，测试和认证的报表自动生成，文件处理等。同时，开发后还有对软件的测试(包括功能性测试，稳定性测试)、升级、后期维护等工作。

4、调试环境是指安装系统软件，并且进行环境设置，编译等工作。

5、执行测试：是指按照运行测试程序包，执行测试活动。

6、书写测试报告是指按照测试情况书写测试总结报告，报告产品质量。可以参见《GB／T9386-1988计算机软件测试文件编制规范》。

数字电视机卡分离标准符合性测试平台的搭建，至少需要解决以下两个问题：

1、具备DTV-CI卡的功能，并能够同接收机完成对CI协议的交互，完成对接收机的测试。

测试方案和测试报告范文第5篇

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

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

中图分类号：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).