前言：中文期刊网精心挑选了单元测试方法范文供你参考和学习，希望我们的参考范文能激发你的文章创作灵感，欢迎阅读。
单元测试方法范文1
摘 要:随着汽车电子市场的快速发展，汽车控制器的电子控制单元(ECU)已越来越多，对ECU的功能测试也变得日趋复杂。为解决车载ECU功能测试，研究了基于控制器局域网络(CAN)的ECU自动测试方法。以NI公司的软硬件为开发平台、CAN总线为通信平台搭建测试系统与被测ECU形成闭环结构。通过CAN总线传输测试信息，可实现对同型号ECU的批量测试。此系统采用了新的测试方法来降低测试误差，并支持ECU的流水线测试，大大降低了测试的复杂度，减少了工作量。同时，在完善仿真信号产生模块和测试模块用例库后，也能适用于其他类型ECU的功能测试。
关键词:
控制器局域网络；电子控制单元；批量测试；汽车电子；车载网络
中图分类号: TP206.1 文献标志码:A
Abstract: With the rapid development of automotive electronic market, more and more Electronic Control Units (ECU) for vehicle controller appear and the functional test also becomes more complex. In order to solve the problem of ECU functional test, the ECUs automatic test method based on Controller Area Network (CAN) was studied. The system included the software and hardware platform of National Instrument (NI) and communication platform of CAN bus, by which the system and ECU formed a closed-loop structure. To transmit the test message through CAN bus, the system could achieve batch test of ECUs with the same type. By using the new test method, the system can reduce the test errors, and support assembly line test of ECU, which greatly reduces the complexity of ECU functional test and test work. At the same time, the system can also apply to other types of ECU functional test by improving the generation module of simulated signal and use case library.
Key words: Controller Area Network (CAN); Electric Control Unit (ECU); batch test; vehicle electronic; vehicle network
0 引言
随着汽车电子的不断发展，汽车已进入电子控制时代，其标志为电子控制单元(Electric Control Unit, ECU)的广泛应用。现如今，车辆上电控单元数量不断增加，功能越发复杂，多个处理器之间相互连接、协调工作并共享信息构成了汽车车载互联通信网络。其中控制器局域网络(Controller Area Network, CAN)是汽车中应用较多的现场总线。其良好的实时性、可靠性和经济性能很好地满足汽车ECU之间数据通信的需要，已成为最有发展前景的现场总线之一［1-2］。因此，带CAN总线功能的ECU测试也将变得更加复杂。ECU功能测试属应用层功能测试范畴，是为了检测ECU是否符合给定的协议规范，能否进行正常的控制工作。这种测试在系统级开发中占据了很大的比重，成为应用层测试中最为关键的部分［3］。
在传统的ECU功能测试中，一种方式是利用测试面板产生ECU各种信号后连接到ECU各输入引脚，触发它的各驱动模块进行控制工作，有专门的线路负责数据交换，但这样的测试系统随着传感器数量的增多，连线非常困难，且需要高速的数据采集和信号调理设备，使整体成本增加［4-5］；另一种则改进了信号的产生方式，即通过虚拟仪器模拟ECU的控制信号来代替传统的触发信号，采用人工对控制效果进行直接的观察和记录。这些测试方法都加大了测试过程中的测试误差、复杂度和测试工作量，且无法进行自动测试和结果的自动生成，也不能同时对多个ECU进行测试，给ECU厂商进行批量生产时带来很大的不便。
由此，引发了对新的测试方法的思考和探索。基于CAN总线的ECU功能测试方法以CAN总线的传输作为关键技术，采用闭环测试方法对同型号的ECU进行自动和批量测试。
1 基于CAN总线的ECU功能测试介绍
车载控制系统主要任务就是要解决车身电器设备的功能性问题，所以，首先应关注ECU是否能实现功能上的控制，即测试其是否满足控制协议的要求。ECU在控制功能上包括了通信服务功能、传送数据功能、诊断信息及标定信息功能、设备监控和网络管理功能等，具体的要求规范则由各ECU生产厂商自行制定。
目前应用层协议制定分为以测试为重心的模式和以设计为重心的模式。不论哪种模式，控制器开发过程中，都需要通过测试来验证功能的正确性，确定ECU工作正常并不干扰总线正常通信［6］。
由图1的控制器开发“V”模式图可见，控制器开发过程包括多个环节，其中的应用层功能测试是其重要组成部分，它包括ECU功能测试、网络管理功能测试、故障诊断测试等，是进行实车测试前的重要环节。在引入CAN总线后，将大大降低ECU功能测试的复杂度和测试工作量，是CAN总线测试的重要组成部分［7］。
在基于CAN总线的ECU测试系统中，通信网络是进行数据传输，实现各模块协调工作的桥梁［8］。利用LabVIEW［5,7,11］虚拟仪器产生仿真信号代替数据采集卡采集的真实信号，并在此基础上引入CAN总线作为测试的关键技术，充分发挥CAN总线在传输上的高可靠性和实时性等优点。通过总线对仿真信号的测试报文进行有效传输，如表1所示。
表1中：Message表示报文名称；ID表示报文仲裁场；DLC表示报文长度；Data表示报文数据。
将报文与同型号ECU进行连接，形成闭环测试结构，模拟实车中ECU的各种传感器信号来驱动其进行控制工作（于3.2节详细描述），将仿真报文数据和CAN总线上反馈回来的ECU控制报文数据进行解析，提取出Data的值，并自动进行多次对比和测试后，在人机界面上对测试结果和各种信号量进行直观显示，并利用测试结果自动生成测试报告，优化和改进了传统的测试方法。
2 设计方案
此方法采用仿真信号序列代替采集卡采集的真实信号，利用CAN总线的特点对数据进行传输，并将整个测试构建成闭环结构，大大降低测试的复杂性。
2.1 方法总体框架
由CAN2.0协议可知，CAN报文的基本要素是报文ID、周期和信号与消息的映射关系。因此对ECU的协议功能测试，主要任务就是测试ID、消息周期、确定信号与消息的映射关系是否满足要求，并测试在循环执行多次之后，ECU是否具备在控制功能上的稳定性［8］。
选用以LabVIEW为软件平台实现ECU的功能测试。测试系统整体框架包括三部分：上位机仿真和测试、CAN网络和底层待测ECU模块。如图2所示。
工业计算机仿真给定ECU的各种信号量，驱动ECU进行控制工作。由于各ECU之间是相互独立的，“测试与结果显示模块”采集不同ECU广播的控制信息，并通过ID对它们进行识别。对采集到的控制信息进行分析、对比原始输入来判定各个ECU在功能控制中是否满足协议要求。
具体测试方法如下：
首先，通过上位机LabVIEW模拟仿真信号（如：转向灯信号、温度信号等）,通过NI 6259板卡，与待测ECU各引脚进行对接；
然后，发送仿真信号，驱动ECU进行控制工作，并发送出相应的CAN控制信息；
再次，通过NI 8473s板卡与上位机LabVIEW进行对接，接收采集到的CAN报文，并通过LabVIEW实现报文的解析、处理和ECU控制效果的同步显示；
最后，把原始仿真数据和处理后的数据进行对比，验证ECU在功能控制上是否满足预期效果，并对以上测试步骤循环多次，得出测试结论，生成测试文档。
在此，根据测试大纲要求，选用一个由实验室和整车厂联合开发的ECU作为应用实例，仿真信号由模拟信号和开关量信号组成，主要分为：转向灯信号、报警信号、状态信号、门信号、温度信号和压力信号控制信号。具体的控制量与变化范围因测试ECU功能要求进行定制化处理。测试ECU仿真控制信号如表2所示。
2.2 软件设计流程
上位机软件整体分为7部分：虚拟仪器配置、模拟信号仿真、同步信号显示、测试结果显示、系统数据判断、数据处理、测试报告生成。模块示意图如图3所示。
1）虚拟仪器配置。对测试时使用的板卡进行初始化配置，设定参数和使用通道。
2）模拟信号仿真。产生ECU仿真信号（如转向灯信号，水温信号等）。
3）同步信号显示。将采集到的CAN报文，进行处理之后，在人机界面上进行控件显示，方便测试者进行直接观察和分析。
4）测试结果显示。在人机界面上进行测试结果的显示，以表格和BOOL数组的形式显示出每个信号在多次测试之后的通过情况。
5）系统数据判断。将处理后的CAN报文数据与预先保存的仿真信号数据进行对比，得出测试结果。
6）数据处理。处理NI 8473s板卡采集到的CAN报文，提取数据信息。
7）测试报告生成。在人机界面上显示测试结果后，将测试结果以网页（.html）格式的文档进行保存，便于后期的分析和处理。
软件设计流程如图4所示。
3 系统分析
由图2测试方法总体框架图可知，此系统主要包含三部分：上位机仿真和测试、CAN网络和底层待测ECU模块。其中上位机仿真和测试模块又分为仿真信号产生模块和测试与结果显示模块两部分。
3.1 仿真信号产生模块
使用NI 6259板卡和上位机LabVIEW构建仿真信号产生模块。此板卡可支持48路数字信号输出和4路模拟信号输出。在调用接口函数模块后，可产生需要的仿真信号，在板卡对应引脚输出对应电压信号。
由表2的ECU控制信号表可知，此待测ECU具有两种不同类型的信号：模拟信号和开关量信号。所以需要在LabVIEW中使用DAQmx各模块仿真出ECU需要的模拟信号和开关量信号。
1）产生模拟仿真信号［10］。需要把模拟信号转化为ECU能识别的电压信号，一般范围在5V以内。
如：仿真发动机冷却水温度信号，水温与电压之间的关系如图5所示。
通过最小二乘法线性拟合得出公式：
y=－4×10－10x5+7×10－8x4－3×10－6x3+0.0002x2－0.0642x+4.2044
其中：y为输出电压值；x为冷却水温度值。
如：进气歧管压力信号，压力与电压之间的关系式：
V=V参（0.0023P-0.015）
其中：P为上位机模拟的压力值；V参为参考电压5V。关系如图6如示。
由图5~6可知模拟信号与电压值之间的转换特性，由上位机进行转换后通过板卡进行输出，传递对应电压值到待测ECU,驱动其进行控制工作。
2）产生开关量仿真信号。
在LabVIEW中定义各种开关量信号，通过板卡产生高/低电平。一般情况下，ECU检测到高边信号（ECU有效电平分两种：H、L，即高电平有效或低电平有效）后进行控制工作（一般情况下，ECU的高电平判断电压在2.5V~5V），控制信号的开启或关闭，并同步使用CAN模块广播CAN报文。
如：DriverDoorStatus（左前门状态）,根据ECU手册可知，其为BOOL量，所以在前面板中放置一个BOOL型控件。在对信号进行操作处理后调用NI6259板卡的接口函数并配置通道信息，与此板卡进行通信，产生所需仿真信号（此功能是否正常可通过示波器进行验证）。
3.2 待测ECU模块
车载ECU控制功能工作原理：ECU外接12V工作电压，在人为进行操作或发生状态变化（如开启转向灯、水温变化）时电路接通，然后产生电压值传递到ECU的模拟输入引脚，如图7所示。
此系统使用板卡产生的各种电压信号代替左侧虚线部分图中未见虚线，请补充或说明。，ECU检测到信号后进行控制工作。
3.3 测试与结果显示模块
上位机LabVIEW调用NI 8473s板卡接口函数采集CAN报文［12］。根据ECU控制协议，对CAN报文进行解析、分析、处理，提取出周期、ID、DATA等控制信息。然后对比原始数据（3.1节部分），进行多次测试后，如果每次测试都全部通过，则判断为Pass，否则为False，并在前面板中进行显示。
其中：原始数据包括报文周期、ID和控制信号数据等；报文周期和ID由ECU控制协议决定；控制信号数据由仿真控制信号模块在产生仿真信号时提供。
4 测试实现
测试ECU在控制功能上是否满足给定的协议和规范，并测试在循环测试多次之后，ECU控制功能是否具有较好的稳定性。测试系统人机界面如图8所示。
“仿真信号控制部分”产生表1的ECU控制信号。“ECU控制显示部分”是对接收到的CAN报文进行解析、处理之后用控件进行形象的显示，并与“仿真信号控制部分”进行对比。结果显示，在循环测试100次之后，信号量“左前门状态”和“进气歧管压力信号”控制出错，在BOOL数组和测试表格中都有明确显示。“ECU控制显示部分”显示出“左前门状态”灯不亮以及进气歧管压力信号数据不一致，这些也同样说明了信号控制的错误。在生成的测试报告(.html格式)中也有明确显示，如图9所示。
从测试过程中得知，各个ECU的触发电平有可能不一样，大致在5V~12V。NI 6259板卡的工作电压需小于10V，所以在需要触发电平高于10V的ECU上进行测试时，则需要在板卡的输出端加入一个增压电路。
同时，为了保证测试的正确性，在使用示波器确认仿真部分的输出电压无误后，采用车载网络测试专用工具CANoe对ECU控制报文进行监测，观察结果如图10如示。
由图8和图10可知，使用CANoe监测的总线报文与测试系统监测到的报文一致，验证了本文所设计测试方法的可行性和准确性。在对比分析图8和图10中的监测数据，验证了数据一致性和通信协议的可行性。
根据不同ECU的控制协议，制定不同的仿真信号产生模块和测试模块，并在使用过程中，不断完善ECU的测试用例库，在完善后进行不同ECU功能测试时，进行规格选择后，即可实现对不同ECU的功能测试。
5 结语
本文介绍了ECU功能测试的现状，优化和改进了传统测试方法。此方法以仿真信号代替采集的真实信号来驱动ECU进行控制工作，并引入闭环结构和CAN总线，使测试过程更加简单和智能化。所测结果准确可靠，能运用于ECU生产线，提高ECU批量测试的工作效率，为整车厂进行ECU测试带来了方便。在完善仿真信号模块和测试模块用例库后可扩展到对不同型号ECU的功能测试。同时，此方法的思想，还可以应用于车载网络的测试、故障诊断等方面，具有较好的理论价值和实际意义。
参考文献:
[1]
夏巍，严辉，丁刚.CAN网络的实时性与可靠性的研究［J］.安徽建筑工业学院学报：自然科学版,2007,15(1):65-68.
[2]
KONG FENG, ZHANG LIYAN, ZENG JIE, et al. Automatic measurement and control system for vehicle ECU based on CAN bus ［C］// Proceedings of the IEEE International Conference on Automation and Logistics. Washington, DC: IEEE Computer Society, 2007: 964-968.
[3]
王立萍.CAN网络在汽车控制方法的应用［J］.工业仪表与自动化装置,2009(5):77-79.
[4]
WU WEI-BIN, HONG T S, LUO CAI-RU, et al. Hardware-in-loop of alternative fuel engine ECU ［C］// Proceedings of the Second International Conference on Computer Modeling and Simulation. Washington, DC: IEEE Computer Society, 2010: 291-294.
[5]
陈彦丰，朱君.基于PXI的汽车测试方案［J］.汽车制造与装备,2005(3):44-46.
[6]
程跃,康劲松,徐国卿.一种车用CAN总线网络测试系统的研究［J］.电子应用,2008,27(1):83-86.
[7]
梁锐.NI软硬件平台在汽车ECU开发和测试中的应用［J］.世界电子元器件,2007(12):61-63.
[8]
WEI WEN-XIONG, GUO JIANG-WEI, LIU SHENG-LONG, et al. Design of CAN communication network in automobile ECU testing system ［C］// Proceedings of the Second Pacific-Asia Conference on Circuits, Communications and System. Washington, DC: IEEE Computer Society, 2010: 1-3.
[9]
CAN Specification 2.0,Part A ［EB/OL］. ［2011-02-15］. can-cia.de/fileadmin/cia/specifications/CAN20A.pdf.
[10]
曹更彦.汽车燃气发动机电控系统实时仿真技术研究［D］.重庆:重庆邮电大学,2009.
[11]
阮奇桢.我和LabVIEW［M］.北京:北京航空航天大学出版社,2009.
[12]
Society of Automotive Engineers. SAE J1939 ［EB/OL］. ［2011-03-03］. 省略/PDFs/manual/drehgeber/M36X8/M3658_J1939.pdf.
[13]
胡思德.汽车车载网络（VAN/CAN/LIN）技术详解［M］.北京：机械工业出版社，2006.
收稿日期:2011-06-16;修回日期:2011-08-21。
基金项目:
国家“核高基”重大专项（2009ZX01038-002-002-2）；重庆高校优秀成果转化项目(KJZH08210)。
单元测试方法范文2
关键词：软件测试；单元测试；模拟对象
中图分类号：TP311文献标识码：A文章编号：1009-3044(2008)05-00ppp-0c
1 引言
随着极限编程在实际软件开发项目中的推广，越来越多的项目开始采用测试驱动开发作为主要的软件开发方法。单元测试不仅优化了软件系统设计，还大大简化了功能测试的工作量[1]。但是另一方面．更多的项目在开始不久就发现在很多情况下针对一个类编写单元测试比较困难．随着项目的进行，越来越多的代码无法进行单元测试．到最后整个项目无法继续采用测试驱动的方式进行开发。因此，要将测试驱动开发真正在整个项目里贯彻执行，必须有一种方法能够相对容易的解决这些问题。本文将首先讨论了单元测试和无法或很难进行单元测试的情况，然后引入Mock Object的概念，基于Mock Object实现单元测试。接下来讨论在软件开发过程中引入Mock Object对测试和设计的影响。最后简述了Mock Object的局限性。
2 单元测试
2.1 什么是单元测试
单元测试是对程序中的单个子程序或过程进行测试的过程，也就是说，一开始并不是对整个程序进行测试，而是将注意力集中在对构成程序的较小模块的测试上面[2]。单元测试从两个角度进行测试：一是测试数据都是针对程序的功能来设计的黑盒测试；二是针对程序的逻辑结构来设计测试用例的白盒测试。
2.2 单元测试面对的难题
造成针对一个类难以进行单元测试的主要原因是因为这个类依赖于一些其它的难以测试的资源。主要有这三类最主要的资源：数据库，第三方组件和网络硬件资源。下面我们将对这三大类难以测试的资源进行分类讨论。
2.2.1 数据库
现在大部分的软件项目都会采用数据库作为数据存储。常见的开发团队会在每个开发人员的机器上安装一个本地的数据库，每个人针对自己的数据库进行开发调试。这样做的问题是：必须有一种方式同步数据库的设计。如果有一个人修改了数据库schema或者某个存储过程，这个修改必须同步到所有开发者的本地数据库以及测试服务器上。采用敏捷软件开发的很多项目组往往会浪费大量的时间在数据库设计同步上。更严重的是每周都会遇到由于数据库设计不同步，修改冲突导致的问题导致整个项目的中心源码库在Auto Build时失败。每个开发人员都有自己的测试数据，除了上面提到的需要把这些测试数据同步到所有开发机器和测试服务器上外，还面临更重大的问题。因为测试用例需要修改数据库，因此还必须准备一种机制能够在每一个测试用例执行结束后重新将所有的测试数据调入数据库。采用最简单直接的方法就是在每个测试用例执行前都将数据库清空，然后再将测试数据调入，这样会大大减慢单元测试的时间。单元测试时间越长，开发者就越不愿意执行这些测试用例，单元测试所发挥的作用越小，这也是很多测试驱动项目最终无法进行到底的一个重要原因。另一个非常严重的问题是为了清理测试环境，在针对商业逻辑的测试用例中加入了大量的数据访问层的代码。采用这样的方式强迫开发者在开发商业逻辑层的同时开发数据访问层，并且严重降低了可读性。
2.2.2 第三方组件或应用服务器
数据库是最常见的第三方服务器。除此以外在越来越多的项目中使用第三方的组件和应用服务器。例如：客户环境中的ERP系统,全球定位系统(GPS)的Web Service接口，绘图引擎等。对于这些第三方提供的内容，造成难以编写单元测试的最根本的原因有：一是系统不透明：对于大部分商业组件或者服务来说，一个很重要的内容是良好的封装。但这个特性带来的问题是在外界无法对其内部状态进行控制和访问。往往经过好几个操作后才能在外部观察到相应的变化。二是环境配置困难。由于项目组成员计算机配置不同，加入项目的时间不同，在项目中负责的内容不同导致无法为所有开发人员配置一个完全一致的环境。例如一个绘图引擎的开发版的license是按照一个局域网内部同时使用的人员个数收费的，就不可能只为了能够进行完整的单元测试就为只编写商业逻辑层的开发人员也安装一套。
2.2.3 网络资源和硬件资源
在稍大一些的项目中都或多或少的用到一些网络资源。例如将文件部署到远程的webDAV服务器上同时很多项目还会用到一些硬件资源。常见的有打印机、指纹识别验证或者条形码阅读器等。这些资源有两大特点导致很难针对与他们相关的类编写测试用例。
一是资源访问冲突。很多网络资源对于并发访问的响应协调是通过锁机制进行的，在实际项目中常见的是一个开发人员在调试本地代码时导致远端资源被锁定导致其它开发者无法访问这些资源。
二是环境可控因素。对于网络资源和硬件资源相关代码的测试与针对商业逻辑层代码的测试最大的不同是环境的不确定性。访问网络资源有可能遇到的异常情况非常多，例如网络忙造成访问超时，也有可能建立链接后数据传输失败，还有可能数据传输完成后校验失败。针对访问这些资源的代码进行的测试必须能够覆盖到所有可能出现的每一种情况。如果没有一个可控，并且是全自动的环境辅助单元测试的话，这项任务基本上不可能完成。
3 模拟对象
3.1 什么是模拟对象
Mock这个单词翻译成中文大概的意思是假的，模拟的。如图1所示：通过一个常见的对商业逻辑的测试描述了一个Mock Object。在图中我们可以看出：测试代码需要测试商业逻辑，而商业逻辑代码需要通过IMyDataAccess接口访问底层数据库，这就是数据库依赖问题。为了解决这个问题我们引入一个Mock Object，并将这个Mock Object而非真正的Data Access传递给商业逻辑代码进行测试。这里的Mock Object不需要实现任何逻辑只需要根据商业逻辑的需要返回适当的内容就可以了。
图1 使用Mock Object对商业逻辑进行测试
3.2 模拟对象实现单元测试应用实例
现在我们写好了类AccountService，具体如下：
public class AccountService {
private AccountManager accountManager;
public void setAccountManager(AccountManager manager) {
this.accountManager = manager;
}
public void transfer(String senderId, String beneficiaryId, long amount) {
Account sender = this.accountManager.findAccountForUser(senderId);
Account beneficiary =
this.accountManager.findAccountForUser(beneficiaryId);
sender.debit(amount);
beneficiary.credit(amount);
this.accountManager.updateAccount(sender);
this.accountManager.updateAccount(beneficiary);
}}
现在我们想测试transfer方法，它内部调用的AccountManager的两个方法。但是对于AccountManager来说，它只是个接口，如下：
public interface AccountManager {
Account findAccountForUser(String userId);
void updateAccount(Account account);
}
所以现在我们必须写个MockAccountManager对象。而且里面的方法体都是非常简单的，就是假定它就返回某某值。
我们这里还有Account类。
public class Account {
private String accountId;
private long balance;
public Account(String accountId, long initialBalance) {
this.accountId = accountId;
this.balance = initialBalance;
}public void debit(long amount) {
this.balance -= amount;
}
public void credit(long amount) {
this.balance += amount;
}
public long getBalance() {
return this.balance;
}
public String getAccountId() {
return accountId;
}}
public class AccountService1Tests extends TestCase {
public void testTransfer(){
AccountService as = new AccountService();
MockAccountManager mockAccountManager=new MockAccountManager();
Account accountA = new Account("A",3000);
Account accountB = new Account("B",2000);
mockAccountManager.addAccount(accountA);
mockAccountManager.addAccount(accountB);
as.setAccountManager(mockAccountManager);
as.transfer("A","B",1005);
assertEquals(accountA.getBalance(),1995);
assertEquals(accountB.getBalance(),3005);
}}
这里我们在假定AccountManager方法都工作正常的情况下，完成了对transfer方法的测试。
从以上代码可以看出，采用Mock Object进行的单元测试基本上可以分为下面几步：
(1)基于一个接口定义Mock并实现这个接口的所有函数。
(2)创建Mock Object的一个对象
(3)设置对象内部属性
(4)告诉对象测试代码希望看到的反应
(5)进行测试
(6)检查Mock Object的确按照希望的顺序进行工作。
3.3 模拟对象的优点
3.3.1 模拟对象作为测试手段的优点
Mock Object最直接的优点在于提供单元测试的质量和覆盖率：
(1)只要在测试中对期待发生的问题指定好执行的顺序引入Mock Object对象后的单元测试就是在一个完全可控的环境里进行的。也就是说我们再也不会无法定位一个“时隐时现”的bug。相反我们可以非常迅速的将问题定位在一个类的内部，而不是一个函数调用序列。
(2)于测试人员来说，最常见的问题是测试人员提交的bug无法在开发人员那里复现。有了Mock Object这个工具测试人员可以利用Mock Object明确的指定输入和输出编写一个测试用例让开发人员修复。
(3)超过8O％ 的异常处理代码没有被充分测试过。主要原因是在没有Mock Object之前很多情况是无法由人工进行控制的，例如写文件失败网络连接超时，数据库数据传输失败或者从网络接收到的数据已经损坏。通过控制Mock Object我们很容易就可以模拟上面的这些情况。
3.3.2 模拟对象作为设计手段的优点
虽然Mock Object最直接的优点在于给予测试代码更多的可控性和可操作性，它最大的优点在于对软件设计的影响[3]。
(1)测试驱动开发与Mock Object一起使用，可以写出低耦合高内聚，非常优雅干净的代码。
(2)强迫设计者放弃对第三方库的强依赖关系，取而代之的是比较弱的依赖关系。
(3)设计人员可以将更大的注意力放在商业逻辑的实现和测试．由于Mock Object的存在，我们不需要实现数据访问层就可以对商业逻辑进行测试。而商业逻辑才是任何系统中对于客户最重要的内容，它的正确与否决定了整个系统是否能完成任务，它的稳定性决定了整个系统架构的稳定性。
(4)在项目初期，甚至是中期，将设计人员解放出来，不用对系统底层的基础设施做出判断。例如，在商业逻辑并不明确，需求还不稳定的时候，我们是更多根据感觉来做出很多重要的判断的，而这些判断往往导致比较关键的决定。例如，在项目之初，谁能够明确的回答到底需要什么样的数据库？Oracle？SQL Server?还是XML文件？到底需要什么样的队列服务器 MSMQ还是IBM―MQ？由于Mock Object的引入，我们可以将这些决策推迟到商业逻辑层更加明确之后进行，从而可以获得更加准确有针对性的答案。
3.4 模拟对象的局限性
Mock Object在实际项目中的应用存在一些限制，一些是由于Mock Object本身性质决定的，有一些则是由于其它类库设计存在的缺陷导致的。
(1)一个典型的不是Mock Object的问题，而是类库设计的问题。是Mock Object无法模拟比较深的对象树。有一些第三方的类库，尤其是一些消息处理函数的参数，提供的不是接口而是一些对象。往往这些对象内部有很多子对象，也就是我们常说的一棵大的对象树。我们需要花费太多的精力去构造这些对象来进行模拟，时间消耗巨大。
(2)一般性而言，单元测试的粒度越细，功能测试的粒度就可以越粗[4]。但是引入Mock Object的单元测试仍然无法取代功能测试。一个很好的例子就是误差积累的测试，哪怕每个单元的误差都在可接收范围内，我们仍然需要一个功能测试确保整体误差也是可以接受的。
4 结束语
模拟对象解决了传统单元测试的两个问题：一是如何将需要测试的代码与相关环境隔离；二是如何创建一个快速、可控的环境辅助测试开发。随着模拟对象技术的成熟，基于模拟对象的单元测试会越来越广泛地被采用。
参考文献：
[1]Kent Beck.测试驱动开发[M].北京:中国电力出版社,2003.
[2]Myers.王峰，陈杰译.软件测试的艺术（第二版）[M]. 北京:机械工业出版社,2006.50-52.
[3]David Astels.崔凯,译.测试驱动开发实用指南[M].北京:中国电力出版社,2004.120-130.
[4]Paul C Jorgensen.韩柯,杜旭涛,译.软件测试（第二版）[M].北京:机械工业出版社,2003.
单元测试方法范文3
本文就如何运用反馈——矫正手段提高教学目标效果谈几点看法。
一、在课前通过诊断性测试，获得学生在学习新内容前的知识反馈，为上新课做好准备。
诊断性测试一般安排在新学期或新开课前进行，测试时间一般5～10分钟，测试应侧重于考查学习新课所需要掌握的基本知识和基本技能。例如，在上动物模拟人体手术实验课前，先测试学生关于无菌技术和无菌原则方面的知识并补偿，由此提高他们的学习外科手术的前提能力，最终提高实验目标。
二、在课前或课后，通过形成性测试了解学生的达标情况，及时查漏补缺。
1、编制形成性测试题，包括课堂测试题和单元测试题，要确保适合各自的特点。
（1）课堂测试题，要适合在课堂教学中进行测试。课堂教学时间一般以二学时为单位，共80分钟。其中用以进行课堂测试及反馈矫正的时间通常只有5分钟，故编制此类试题要突出重点，考虑课堂操作的可行性，试题量不能过多。例如，在“复苏”一章编制的课堂测试题为：①快速诊断心脏骤停的方法；②心肺初期复苏的ABC步骤；③心脏按压有效的标志是什么；④心肺复苏有效的指标是什么等。这些题中包括了本章的重要知识点，学生掌握后，在遇到心脏骤停病人时就会懂得如何去诊断和处理，而且试题量适中，便于在课堂上进行测试和矫正。
（2）单元测试题，即教师根据教学的情况，一般按章节划分为一个教学单元，每学完一个单元后进行一次单元测试，以评价学生的单元达标情况。单元达标测试覆盖的目标范围较大，而且每一目标都应有相应的检测题，测试时间为20～30分钟，测试内容多时间少，因此编制此类题主张多用选择题和判断题，少用填空题、名词解释和问答题，以方便学生答题，做到既能检测目标又不影响课堂授课。此处，通过定期的单元测试，又能促使学生经常系统地进行复习，有利于知识的巩固和强化。
2、编制平行性测试题，此类试题适用于对矫正生的检测。
即用以检测单元测试中的未达标者，在经过补救矫正后是否已达标。编制此类别试题应与单元形成性测试题是同质不同形的，即用不同的试题形式去检测同一目标。例如，检测“补钾原则”这一目标时，如果在单元形成测试中采用选择形式，则在平行性测试中可采用判断或填空题的形式进行检测。
三、反馈——矫正是对经测试反馈的未达标者及时补救矫正，使其达标。
1、课堂反馈矫正。
课堂测试反馈一般采用提问、回答、接力填空等形式，其中最常用的是课堂提问的形式，而课堂提问的形式主要适合于对个别学生，这与目标教学要面向全体学生的宗旨是矛盾的，为了解决这一矛盾，在提问时应使所提问的学生具有代表性和随机性。所谓代表性是指所提问的学生能代表全班学生中的某一部分，如优生、中等生或差生。要做到有计划有目的地进行提问检测，尤其对差生要多进行检测矫正。随机性主要是针对课堂教学的具体情况，在全班同学中随机地进行提问。笔者曾在上“急性阑尾炎”一节时，发现一位同学在上课时开小差，当时立即对她进行提问检测：“急性阑尾炎最有特征的症状是什么？”她回答是“腹痛”。这样通过提问，可及时地使她调整思维、融入课堂。虽然她答得不全对，但是通过提问既能起到对她及时补救矫正的效果，同时也能引起其他同学的重视（尤其是对提问的这一问题的重视），结果在单元形成测试中全班同学都能答对这一题。这样通过抓典型、抓代表，达到“牵一发而动全身”的效果，既能及时纠正课堂上出现的个别问题，又能调动全班同学的课堂积极性和主动性，因而能有效地提高教学目标达成度。
单元测试方法范文4
关键词:软件测试;案例教学;教学内容
中图分类号:TP311 文献标识码:A文章编号:1009-3044(2010)09-2275-02
Teaching Methods of Software Testing Technology
GAO Zhi-sheng
(School of Mathematic and Computer, Xihua University, Chengdu 610039, China)
Abstract: Software testing is a course that teaches the software testing methods and means. Case teaching methods that runs through the whole software testing process with a single case is proposed. The corresponding teaching contents and experiment requirements are also introduced. Through the teaching methods, the studying interesting, the initiative and the capability of finishing the practical software testing projects are really improved.
Key words: software testing; case teaching; teaching contents
软件开发过程中的质量问题是关系到软件和软件组织生存的重大问题,得到了越来越多的重视。目前在高校的软件工程专业普遍开设有软件测试相关课程。但是在具体教学实践中,教师普遍感觉到有许多不如意的地方[1],具体表现在教学内容与具体应用脱节,学生对软件测试认识有误区,学生学习积极性不强、认为软件测试是文字性课程,软件测试过程如何展开,如何选择测试工具,如何在教学中贯彻软件测试管理思想等。
近年来关于怎样进行软件测试教学,引起了相关专家的重视和讨论[1-4]。本文在总结前人的经验基础上,结合作者近几年在软件测试技术课程教学中的实践提出了以一个具体项目案例贯穿整个教学过程,理论与实践紧密结合的教学方法。
1 教学的目的和教学方法
软件测试技术课程是本校软件工程专业的一门专业必修课程,通过软件知识体系的学习,使学生了解软件测试的发展现状,认识软件测试的重要性,掌握软件测试的方法和技术,熟悉软件测试过程管理,从而具有独立承担软件测试项目的实施能力,具有测试计划、管理、实现和软件质量保障的能力[3]。
针对以上教学目的,我们在软件测试技术教学过程中引入一个具体测试项目案例贯穿整个教学过程的教学方法。第一课时,我们组织学生自由进行分组,每组5个人左右,每组确定一个名称。要求每个小组在课程的前几周完成同一个模拟题目“大学图书馆管理系统”的软件开发。系统完成后,然后各个小组交叉进行测试对方开发的软件系统。随着课程的进度,主要要求学生完成软件系统的单元测试,集成测试,功能测试和系统测试。单一的案例贯穿整个软件项目测试过程的案例教学方法的优点是:
1)软件测试的前期课程有“Java EE编程技术”,同时我们选择图书馆管理系统作为开发对象,学生从技术上和业务需求上都具备快速完成该系统的能力。
2)相同的开发对象,互相测试对方开发的系统,有利于形成竞争,有利于调动学生的学习积极性。同时也有利于教师对学生完成的结果进行点评和组织课堂讨论。
3)整个软件测试课程,学生能够完成对一个具体项目的全部测试过程,有利于促进学生系统地掌握软件测试的技术方法,组织和过程。
2 教学过程
我们的教学过程主要包括以下5个阶段,最初的几周主要讲解软件测试原理,同时这个阶段学生主要完成指定项目,然后是4个主要的软件测试技术:单元测试,集成测试,功能测试和性能测试。软件测试课程也会讲解其他如回归,压力等其它测试技术,下面是我们课程重点讲授的内容和要求。
2.1 软件测试原理
本阶段主要讲授软件测试技术的基本概念,使学生掌握基本的软件测试原理。包括软件测试的重要性,软件评测师的职业规划,软件质量的概念等基本概念,重点讲授的内容是白盒测试及用例的设计和黑盒测试及用例的设计两个章节。白盒测试主要包括逻辑覆盖和基本路径覆盖两种用例设计方法,逻辑覆盖又分为语句、判定、条件、判定/条件、组合、路径覆盖等。黑盒测试的重点内容是等价类划分,边界值分析,因果图,决策表和场景法。
本阶段对学生的实践要求是开发“大学图书馆管理系统”,由上课老师为学生统一提供系统的需求规格说明书,该系统的主要功能如图1所示。要求学生结合对本校图书借阅系统的使用和需求规格说明书,采用Java EE技术进行开发,系统采用典型的4层结构进行设计,如图2所示,即运行在客户端计算机上的客户层组件、运行在Java EE服务器上的Web层组件、业务层组件和运行在EIS服务器上的企业信息系统(EIS)层软件[4]。系统开发采用JSF+EJB3.0的架构,Glassfish为应用服务器,MySql提供数据库服务。
2.2 单元测试
单元测试是对软件最小组成单元的测试,是软件开发过程中进行的最基本的测试。单元测试主要按照程序内部的结构测试程序,检验程序中的每条通路是否都能按预定要求正确工作。单元测试主要考虑各个模块接口的输入和输出,模块内部的数据结构,模块的边界条件,模块的基本路径和模块的出错处理。单元测试阶段还讲授代码规范性检查,代码覆盖率的检查,代码复杂度的计算和内存泄漏的检查等。
完成单元测试的基本原理的学习后,要求学生交叉完成图书馆管理系统的单元测试,主要抽取系统中的核心函数进行测试。完成测试后要求每个小组提供单元测试计划,单元测试用例和单元测试报告3个报告文档。得到所有报告后,组织一次课堂讨论,展示优秀小组的成果,分析原因总结经验。单元测试工具要求采用JUnit,代码规范和代码质量分析采用Logitscope, Pruify用于分析代码的内存问题。
2.3 集成测试
软件各个单元通过单元测试之后,需要检查各个单元之间的相互接口是否正确,就是集成测试。软件集成测试主要考虑的问题是模块间的数据传递是否正确,一个模块的功能是否会对另一个模块的功能产生错误的影响,全局数据结构是否有问题,块组合起来的功能是否能满足要求,集成后累积误差是否被放大等[5]。关于软件集成测试的原则、策略和用例设计等相关原理可参考其它相关文献。
教授完集成测试相关原理后,我们要求每个小组负责人组织完成系统的集成测试。集成测试以一个EJB、Servlet或者JSF为基本单元,工具选择Cactus和HttpUnit。完成集成测试后要求每个小组提交集成测试计划、集成测试设计文档和集成测试分析报告。收齐所有小组成果,组织学生进行讨论。
2.4 功能测试
功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。主要考虑系统的各个功能,一般从软件产品的界面、架构出发,按照需求编写测试用例,测试产品时是否达到用户使用的需求。本阶段主要让学生采用WinRunner完成系统的功能测试,进行功能测试之前首先完成测试计划和测试用例的设计。然后完成WinRunner的6个步骤:识别程序的GUI,建立测试脚本,完善测试脚本,在新版应用程序执行测试脚本,分析测试结果和回报缺陷。
2.5 性能测试
典型的性能测试主要是从系统的响应时间、吞吐量、系统资源利用率、并发用户数、HTTP事务处理数/秒、会话数/秒和连接建立时间等方面衡量系统的性能。性能测试主要有压力测试,容量测试和强度测试等。针对图书馆管理系统的特点,我们要求学生理解性能测试的重要性和困难性,掌握性能测试的基本概念和技术。在此技术上,我们要求学生使用LoadRunner完成系统的压力测试。主要步骤是测试需求分析,制定测试策略和方案(重点是设计测试场景),使用VuGen创建脚本,在Controller中创建场景,运行场景,分析结果。完成后提交测试策略和方案报告,脚本和图书馆管理系统压力测试报告。
3 结论
一个合格的软件评测师要求具有编程能力、开发能力、沟通能力、管理能力、逆向思维能力等多种能力。怎样在大学软件测试技术教学中培养既有理论又能实践的软件测试从业人员是本文研究的动机。我们提出的基于同一案例贯穿整个软件测试技术教学过程的教学方法,通过学生互测对方开发的软件系统,相互对比,相互促进同时组织课堂讨论,有效营造了主动学习的气氛,增强了学生的学习积极性,培养了学生主动思考问题的能力。该方法是一个值得借鉴的软件测试技术教学方法。
参考文献:
[1] 李绘卓,唐峻,范勇.基于案例的软件测试实验教学[J].电脑知识与技术,2009,27(5):7820-7821.
[2] 屠红蕾.软件测试教学的点滴体会[J].计算机教育,2008(10):124-125.
[3] 李亚.“软件测试”教学探索与实践[J].计算机教育,2008(6):14-15.
单元测试方法范文5
随着信息化军事技术的不断发展，装备仿真训练软件也获得了迅速的发展，其规模越来越庞大、实现的功能越来越多、结构越来越复杂，装备仿真训练软件的性能和可靠性也成为至关重要问题的。因此，软件测试成为装备仿真训练软件开发过程中一个必要的环节。依据一个科学的测试模型，使用先进的软件测试技术对装备仿真训练软件进行充分的测试，可以及时发现软件程序中的错误，有效降低软件错误出现的概率，验证软件功能的可行性，提高软件的可靠性和安全性。
1 软件测试模型
软件测试是装备仿真训练软件开发过程中一个不可缺少的重要步骤，而且随着装备仿真训练软件规模的增大、复杂度的增加，软件测试也变得越来越重要。装备仿真训练软件软件测试过程与开发过程一样，都能决定软件的质量，而且测试过程的质量将直接影响测试结果的准确性和有效性。
在软件开发几十年的实践过程中，人们总结了很多的开发模型，这些模型对于软件开发过程具有很好的指导作用，由于测试与开发是紧密结合在一起的，所以软件测试也需要有测试模型去指导实践。软件测试模型是将测试过程活动进行抽象的概念模型，用于定义测试活动的流程和方法，是确保软件工程质量的重要手段。测试专家通过实践总结出了很多很好的测试模型。这些模型将测试活动进行了抽象，明确了测试与开发之间的关系，更好的分析软件测试在整个软件研发中的参与度和工作过程，进而不断完善软件质量保证流程，提高软件产品的质量，并成为了测试管理的重要参考依据。目前，主要的测试模型主要有以下4种：
1.1 V模型
V模型是将传统测试模型瀑布模型改进后的一种测试模型，如图1所示，从左到右，分别描述了软件的基本开发过程和对应的测试行为，清楚地体现出每个测试阶段和开发过程各阶段的对应关系。但是在V模型当中，测试过程放在了编码的下一个阶段，这就容易使人误解为测试是软件开发的最后一个阶段，而需求分析的检验工作也是在验收测试才能进行。
1.2 W模型
W模型由两个V模型组成，分别代表测试与开发过程，非常明确的标注了生产周期中开发与测试之间的对应关系，如图2所示。但是在W模型中测试和开发也保持着一种线性的前后关系，上一阶段工作完全结束，才能正式开始下一阶段的工作，这样就无法支持迭代、自发性以及变更性调整等情况。
1.3 H模型
H模型形成了一个完整独立的测试过程，并且将测试准备活动和测试执行活动清晰的区别出来，如图3所示。图中仅仅演示了在整个生命周期中某个层次上的一次测试“微循环”，图中的“其他流程”可以是任意开发流程。H模型的特点是软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。当某个测试点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
2 装备仿真软件测试的特点及关键问题
2.1 装备仿真软件测试的特点
装备仿真训练软件是一个由系统、分系统/子系统、模块组成的复杂系统，并随着系统和操作功能的增多，复杂程度也在增加，系统的好坏归根结底是由各个分系统和各个模块的好坏决定的，对各个分系统和各个模块的测试是一个非常重要的环节。装备仿真训练软件测试具有以下6个特点：
2.1.1 装备仿真训练软件测试主要分为三个阶段
从软件生命周期全过程来看，软件测试可分为单元测试、功能测试、集成测试、性能测试、系统测试、配置测试、回归测试等阶段。根据装备仿真训练软件的结构、规模、类型和安全性关键等级等方面的特点，确定装备仿真训练软件测试主要分为单元测试、集成测试和系统测试三个阶段。
2.1.2 单元测试是装备仿真训练软件的测试重点
装备仿真训练软件测试是一项针对性很强的工作，即使对同一类型的功能，可能由于不同型号任务的要求，功能实现也会有所差异，因此要求重点进行单元测试。单元测试是根据详细设计和源程序，了解每个最小模块的输入、输出条件和逻辑结构是否正确合理。单元测试通常应对模块内所有控制路径设计测试用例，以便发现错误。
2.1.3 装备仿真训练软件程序内部结构复杂，路径组合数目庞大
程序的三种基本结构分别是：顺序结构、分支结构和循环结构，装备仿真训练软件最小组成模块的内部程序都可看作是这三种结构按不同方式组合的产物，这其中包含大量多重选择和循环嵌套的程序，而且模块与模块之间存在着大量的交互，所以程序内部包含的不同路径数目可能是天文数字，尤其对大规模复杂的装备仿真训练软件，穷举所有的路径是不可能的，需要根据实际情况去选择适合的覆盖测试方法。
2.1.4 装备仿真训练软件黑盒测试用例数量庞大
装备仿真训练软件中包含了不同专业的多个分系统，每个分系统又由多个子系统和模块组成，其中包含的参数数量庞大，参数与参数之间的进行组合之后的数量将更加庞大，而软件运行出现的故障时，更多的情况是由于多个参数的相互作用的原因，所以，要想充分考虑到参数与参数之间的关系，需要的测试用例数量是无穷尽的。
2.1.5 装备仿真训练软件测试一般需要特定的测试环境支持
装备仿真训练软件测试可以采用静态测试方法和动态测试方法。其中，静态测试以人工检查为主，不需要特定的测试环境;而动态测试则需要建立驱动软件模块执行的测试环境，支持软件模块的参数输入和输出结果的可视化。
2.1.6 装备仿真训练软件测试一般采用白盒测试与黑盒测试相结合的方法
一般采用白盒测试方法来测试装备仿真训练软件程序内部的逻辑结构;装备仿真软件的功能测试部分则需要采用黑盒测试方法。
2.2 装备仿真软件测试的关键问题
软件测试的目标是发现软件中可能存在的设计缺陷和错误。测试时验证得越全面，软件中可能存在的缺陷就会越少，而每一个项目、每一个软件的测试都会有不同的特点和测试关键问题，测试工作要根据软件的特点和关键问题，设计适合该软件的测试。装备仿真训练软件测试的关键问题主要有以下4点：
2.2.1 测试工作必须由非开发人员来完成
由于许多开发单位对软件测试的认识水平不够，自己设计、自己编程、自己测试、自己维护的现象还比较普遍，这样的结果就是导致测试结果不理想，没有达到测试的要求。所以，为了保证测试质量，装备仿真训练软件的测试工作必须由非开发人员来进行，保证的效果。
2.2.2 在白盒测试中，采用基本路径测试方法解决路径覆盖率问题
在装备仿真训练软件结构中，路径组合是一个庞大的数字，所以要在测试中覆盖所有路径是不可能的，需要把覆盖的路径压缩到一定范围内。如：程序的循环部分可以只循环一次。因此，在路径覆盖测试上，我们选择基本路径测试法。
2.2.3 在黑盒测试中，采用组合覆盖测试方法解决测试用例无穷尽问题
由于装备仿真训练软件中参数与参数的组合数量庞大，无法设计无穷尽的测试用例满足覆盖率问题，为此，采用组合覆盖测试方法，不仅可以充分考虑到软件中参数与参数之间的相互作用，更重要的是能以最少的测试用例实现最大程度的覆盖，具有较好的测试效果。
2.2.4 要有必要的测试文档
没有文档的项目是一个不成功的项目，同样，没有文档的测试也不会是一个成功的测试。测试工作的计划、设计、实现和问题报告都要以文档的形式记录下来留存，方便同项目组人员进行阅读和修改，更重要的是对于后续同类项目是资源的积累过程和设计的改进依据。
3 装备仿真软件测试模型
测试过程模型定义了测试的流程和方法，为测试工作提供了指导。但是传统的测试模型各有长短，不可能适合所有的测试软件，软件测试模型因测试软件的不同而不同，所以，本文通过对传统的测试过程模型进行的分析和探讨，同时研究分析了装备仿真训练软件的实际情况，进而得到了适合装备仿真软件的测试模型，然后从该模型出发，完善软件测试工作流程。装备仿真训练软件测试模型是一个包含了软件文档审查、代码静态分析和审查、单元测试、子系统集成测试、系统测试和验收测试的综合测试模型，如图4所示。
3.1 测试准备
测试准备阶段是在测试实施之前，构造执行测试所需的要素，这些要素通常包括软件开发文档、软件开发程序、实际执行测试所需的软件、准备测试环境和测试工具;同时还要为测试过程准备适当的测试用例。
3.2 单元测试
装备仿真训练软件单元测试部分包含静态测试和动态测试两个部分。其中静态测试的对象是装备仿真训练软件单元模块的文档和程序代码，主要通过文档审查、代码审查、代码静态分析等方法来确保软件需求和设计文档的正确性、代码的规范性、设计或实现的正确性。而软件结构和功能方面的缺陷则需要采用动态测试的方法来完成。
装备仿真训练软件单元模块动态测试采用黑盒测试和白盒测试相结合的方法，从模块级检查软件的功能、性能、接口和其他约束条件是否满足需求。白盒测试技术主要测试每个单元内部逻辑结构的覆盖率，黑盒测试技术测试模块单元功能满足需求情况。
3.3 集成测试
集成测试主要检验装备仿真训练软件中经过单元测试的模块和子系统各部分工作是否实现了相应技术指标、达到了相应的要求。在装备仿真训练软件集成测试部分，既可以弥补单元测试中没有测试到的Bug，又可以测试单元测试中没有办法测试的功能，如装备仿真训练软件中前后台集成之后的关联功能。所以集成测试就是测试各个部件之间的配合情况，为系统测试提供基本保证。
装备仿真训练软件的集成测试必须在所有模块、子系统能够正常运转的情况下才能进行，一般采用的方法是数据驱动方法中的自底向上集成测试。具体的步骤是先测试组成子系统的模块群，由于最底层的单元模块都已经经过了单元测试，所以各个模块可以向上集成为各个子系统;然后在此基础上就可以测试各个子系统能否正常工作，以及进行各个子系统之间的测试工作。
3.4 系统测试
装备仿真训练软件的系统测试是在集成测试的基础上进行的，不仅是单纯的测试软件部分，而是将硬件、网络和外设等其他要素结合进来进行综合性测试。系统测试主要依据系统总体技术方案和需求说明书进行测试，目的是发现系统与用户需求不符或矛盾的地方。
系统测试的测试类型一般包括功能测试、性能测试、负载测试、强度测试、容量测试、安全性测试、用户界面测试、有效性测试、配置测试、故障恢复测试、安装测试和回归测试。而在装备仿真训练软件的系统测试中，功能测试、性能测试、负载测试、安全性测试、有效性测试、配置测试、故障恢复测试是必须进行的，其他项目可以依据具体项目情况选择性的进行。
3.5 验收测试
在完成装备仿真训练软件的系统测试之后，进行验收测试。只有通过了验收测试，才标志着项目的结束，软件产品的完成。一般来说，验收测试以用户为主，主要验证软件的功能、性能以及其他特性是否与用户要求相一致。
4 结束语
软件测试的目的是通过测试来发现缺陷，找出缺陷的分布特征和出现的规律，以便在新的开发项目中改进设计结构，避免缺陷的出现，同时也能够通过设计有针对性的检测方法，改善软件测试的有效性。随着装备仿真训练软件质量要求的提高，软件测试在软件开发中的地位越来越重要。装备仿真训练软件测试模型是从传统的软件测试模型中提取出来的，适合装备仿真训练软件的测试模型，不仅可以提高测试在软件生命周期中的作用，还可以完善软件部分的工作流程。
作者：钟尚斌 来源：电子技术与软件工程 2016年7期
单元测试方法范文6
0 引言
现代电子装备的研制中，始终贯穿了两个过程：即硬件研制和软件的开发。这两个过程其实是交织在一起，有些软件的设计活动与硬件的设计还是迭代进行的。但又基于软件设计与硬件设计各自不同的特性和规律，大多研制过程的程序文件是把软件和硬件研制按照独立的两个过程来描述或界定的。这样就带来一个问题，很多设计人员以及管理人员有时就不清楚在研制的各阶段中应该开展哪些软件的设计工作，或者某个软件开发过程，对应于装备研制过程的哪个阶段，以至于在研制计划的安排上，软件与硬件的设计进程不能很好地同步，造成时间上的延误。目前，还未见相关资料对此加以论述，所以，理清电子装备在研制各阶段的软件开发工作还是十分必要的。
1 论证阶段
论证阶段的工作是进行战术技术指标、总体技术方案的论证及研制经费、保障条件、研制周期的预测，主要进行技术、经济可行性研究。嵌入式软件是由于计算机技术的发展应运而生，软件是硬件功能的更为便捷高效的实现，所以，在论证阶段，只需要论证人员了解基于嵌入式CPU、DSP等处理芯片和软件的发展水平，并无实际具体的软件开发工作。
2 方案阶段
方案阶段的主要工作是进行系统方案设计、关键技术攻关和新部件、分系统的试制与试验，根据装备的特点和需要进行模型样机或原理性样机研制与试验。在此阶段，要按照软件工程化的要求，开展系统需求分析和设计，主要工作是按照GJB 2786A的相关要求分析系统对软件的需求，确定软件的实现和运行环境，对研制的软件项目进行定义，形成软件研制任务书。其具体工作是：
①通过获取软件所从属的系统(或产品)的有关资料，分析系统的要求及实现环境;分析硬件和软件的关系，进行可行性研究。②确定硬件环境和软件环境。分析硬件和软件的关系，定义硬件和软件之间的接口;③确定系统的功能和性能要求，明确标识关键性要求;④将系统的功能和性能要求分配到软件和硬件;⑤评估和确定软件项目的安全关键性等级;⑥确定对关键计算机资源和资源余量的要求。例如：处理器、时间、存储器、I/O通道等资源的约束。
若要进行原理样机的研制，则还需针对原理样机的需求，开展软件需求分析、软件设计和编码。
3 工程研制阶段
工程研制阶段的主要工作是根据批准的《研制任务书》进行武器装备的设计、试制、试验工作。在这个阶段软件的开发工作依次是：
3.1 软件需求分析 软件需求分析阶段的主要目的为每个计算机软件配置项(CSCI)分配一组完整的功能、性能要求和一组完整的接口要求，并编制《软件需求规格说明》和《接口需求规格说明》。主要工作内容有：
①根据《软件研制任务书》定义的系统要求，建立软件逻辑模型，自顶向下地把系统对软件的需求逐层分解;②分配软件的功能需求、性能需求、接口需求、操作需求、资源需求、确认测试需求、文档需求、可靠性需求、安全保密需求、质量需求等，确保所有软件需求分配到CSCI;③进行软件安全关键性分析，提出安全性关键CSCI清单;④进行故障模式分析，确定可靠性冗余设计需求;⑤对资源的需求进行分析;⑥编制《软件需求规格说明》和《接口需求规格说明》。
在软件需求分析中，软件的功能需求、性能需求、接口需求、操作需求等都对软件的运行环境和资源提出了需求，所以，软件需求分析须在《软件研制任务书》下达后即可进行，以便给硬件的设计提供依据。
3.2 软件设计 《软件需求规格说明》通过评审后，即可进入软件设计。其主要的工作有：
①将需求分析阶段建立的逻辑模型转化为能实现软件需求的实现模型;②进行CSCI体系结构设计。设计软件的总体层次结构，采用自顶向下的方法，把《软件需求规格说明》和《接口需求规格说明》的要求逐项分解到计算机软件配置项的计算机软件部件(CSC);③设计各CSC接口相关的数据结构(或数据库)、数据流和控制流;④进行安全性设计，使关键、重要部件符合软件安全性要求;⑤如果软件研制合同/研制任务书中对交付软件的编程语言有明确规定，则软件项目组应遵循其要求。否则应按照软件继承性、通用化和标准化的要求选取编程语言;⑥软件项目组应确定所遵循的软件编码标准;⑦针对资源的要求进行设计，包括运算能力、时间、存储、I/O通道、数据库等资源;⑧进行CSCI详细设计。将构成软件系统的各个软件部件(CSC)逐步细化，形成若干软件单元(CSU);⑨采用程序流程图或其它表示方法对各个软件单元进行过程描述，包括算法和数据结构;⑩设计各软件单元间的接口信息。
3.3 编码和单元测试 软件设计(含接口和数据库设计)说明通过了评审，即可进入编码和单元测试阶段。其主要的工作有：
①根据软件设计说明对各软件单元进行编码，确保软件代码正确实现了设计的逻辑并满足相关的约束和要求;②软件源代码的编写应遵循软件编码标准的要求;③对编码完成的软件单元进行编译，采用合适的调试技术查找和纠正其中的错误;④采用静态分析工具对软件所有单元的源代码进行静态分析，找出其中的缺陷、错误、违背编码标准之处，并加以分析和纠正;⑤按照GJB/Z 141《军用软件测试指南》的要求，对所有软件单元进行动态测试;⑥使用单元测试工具，编制测试用例、开发单元测试辅助程序;⑦按照软件文档编制与管理指南的格式要求编制《软件单元测试计划》、《软件单元测试说明》文档;⑧执行单元测试用例和辅助程序，填写单元测试记录单;⑨确认和纠正单元测试中发现的问题，并进行单元回归测试。
3.4 软件集成和部件测试阶段 软件单元测试达到测试要求，通过评审后，即可进入软件集成和部件测试阶段。其主要的工作有：
①采用增量式的集成方法，将软件单元逐步集成为软件部件、构件直至软件配置项;②按照GJB/Z 141《军用软件测试指南》的要求，对所有软件部件进行测试;③编制《软件部件测试计划》;④按测试计划建立部件集成测试环境，编写测试用例和测试辅助程序;⑤编制《软件部件测试说明》;⑥确认和纠正软件部件测试中发现的问题，对文档和代码进行必要的修改，并通过回归测试;⑦软件部件测试需求覆盖率和调用对覆盖率均应达到100%，未达到测试覆盖率指标的，应给出合理的说明。
3.5 软件配置项(CSCI)测试 软件部件测试报告通过了评审后即可进入软件配置项(CSCI)测试。软件配置项(CSCI)测试工作可以由研制单位软件测试专门机构完成，也可以由用户指定的第三方软件测评机构完成。其主要内容有：
①根据软件需求规格说明和软件设计说明文档，识别软件测试需求;②编写《软件配置项测试计划》和《软件配置项测试说明》;③建立软件配置项的测试环境;④按照软件研制任务书中规定的测试类别，对识别出来的每个测试项分别编制测试用例和测试辅助程序。
3.6 软件系统测试 软件配置项测试报告通过了评审后即可进入软件系统测试。由用户指定的第三方软件测评机构完成。其主要内容有：
①根据《软件研制任务书》、《软件需求规格说明》和《软件设计说明》文档，识别软件测试需求;②建立系统测试环境;③编写《系统测试计划》和《系统测试说明》;④按照《软件研制任务书》中规定的测试类别，对识别出来的每个测试项分别编制测试用例和测试辅助程序;⑤根据测试结果对设计文档和代码进行修改，并实施所有必需的回归测试。
软件单元测试和软件集成和部件测试，可在搭建的仿真环境中进行，但对性能方面的测试，最好在真实的目标环境中进行，这就要求，硬件的组件(模块)设计、组合或分系统设计在时间安排上与之相匹配。
软件配置项(CSCI)测试和软件系统测试，属合格性测试，按照软件工程的要求，严格地讲，应该在正样机鉴定之前进行。软件配置项测试可在承制单位内部的软件测试专门机构进行测试，如使用方有要求，需在由用户指定的第三方软件测评机构进行。软件系统测试，一般在由用户指定的第三方软件测评机构进行。
在实际工作中，由于时间、经费等方面原因，经过使用方和承制方协商达成共识，也可在正样机鉴定时不进行合格性测试，而在设计定型阶段由定委指定软件测评机构进行软件测评即可。
4 设计定型阶段
设计定型阶段软件工作主要是进行软件测评。软件测评，是通过软件测试，来评价软件是否满足研制要求。软件测评由定委指定的软件测评机构完成。软件测评和基地试验、部队试验同步进行。
5 结束语
电子装备的研制程序，是以传统的硬件研制过程为主线进行的，而现代电子装备，嵌入了软件的研制过程，这是一个有别于硬件研制模式、又分属于两个团队的研制过程，深入了解硬件研制和软件研制过程各阶段关联性，对于科学合理安排研制计划，有效管理研制进程，提高研制效率，都具有重要的作用。
