关键词：飞行控制软件；单元测试；动态测试
中图分类号：TP301
文献标识码：A 文章编号：1672-7800（2015）005-0029-03
作者简介：刘思思（1985-），女，陕西商洛人，硕士，上海机电工程研究所工程师，研究方向为飞行控制软件开发、系统集成与验证；刘迪（1985-），男，黑龙江哈尔滨人，硕士，上海机电工程研究所工程师，研究方向为制导控制系统设计与仿真。
0 引言
在飞行控制软件（简称飞控软件）开发过程中，单元测试环节必不可少。其中，静态度量指标可以用专门的工具很方便得出其具体数值，而动态测试虽然也有专门的工具，但编写测试用例需要花费大量时间和精力。当前，航天多型号开发任务重，迫切需要应用自动化的测试工具软件来提高动态测试的工作效率。
本文结合飞控软件的特点，论述通过自动生成测试用例的工具软件Cantata6.2进行单元动态测试的方法。
1 飞行控制软件特点
飞控软件的主要功能是完成相关设备之间的实时信息交互与控制解算，从而实现飞行过程中姿态和位置的控制。飞控软件主要分为应用层软件、接口协议层软件和底层驱动软件3个部分，软件架构如图1所示。
应用层软件由实现姿态和位置控制的各功能模块组成；接口协议层软件主要为飞行控制设备与其它设备之间通信的协议模块；底层驱动软件主要由飞行控制设备的接口驱动模块以及硬件输入输出模块组成。
飞控软件嵌入在飞控设备中，具有实时性高、时序和逻辑复杂、可靠性高的特点。首先，要确保底层驱动软件和接口协议软件的正确性，使得各类信号得以正确传输；其次，要确保软件与控制算法模型的一致性，输入输出及解算正确；最后，要确保软件时序和逻辑的正确性。只有这样才能保证飞行控制系统正常工作。
2 飞行控制软件单元测试的意义
对飞控软件的最小组成单位――函数进行测试的目的在于检验其能否正确地实现其功能，满足性能指标和接口要求。通过语句（SC）、条件（DC）、修正条件判断（MC/DC）等覆盖率指标评价程序结构，及早发现软件代码中的编码和逻辑错误。
对控软件来说，被测函数已经完成了编码和调试，能够通过编译和链接进行单元测试。此外，不考虑每个模块与其它模块之间的关系，为每个模块设计驱动模块和桩模块，每个模块进行独立的单元测试，各模块的单元测试可以并行进行，能够提高测试效率，也较容易实现100%的覆盖率指标要求[1]。
3 Cantata6.2测试工具
3.1 Cantata6.2简介
Cantata6.2采用先进的代码分析器和AutoTest技术，智能分析被测代码，扫描代码的所有可能路径，根据选定的覆盖率标准，自动生成满足100%覆盖率的测试用例。对全局变量、返回值自动赋期望值，并包含对全局变量、返回值、调用函数参数传递等进行检查。对形参为复杂类型，如结构体指针的情况，能自动生成相应的测试对象，即构造一个结构体数组，将结构体数组的地址赋给形参。自动生成桩函数，在测试工程中替代真实的外部函数。使用Cantata6.2进行单元测试的原理如图2所示。
用户可以使用Cantata6.2工具AutoTest选择相应的覆盖率规则集，通常航天A级软件要满足修正条件判断（MC/DC）覆盖率100%，B级软件要满足分支判断（DC）覆盖率指标100%，C级软件要满足语句（SC）覆盖率指标100%。飞控软件通常均为A级软件，选择DO-178B/ED-12B Level A Coverage规则，自动生成满足SC、DC、MC/DC3个覆盖率指标要求的测试脚本文件。
3.2 含有桩函数的测试实例
本文以飞控软件的指令形成函数模块为例，检验Cantata6.2的动态测试功能。该函数模块的主要功能是形成稳定控制系统姿态控制等的指令信号。代码框架如下：
void Instruction （C_INSTRCUTION *C_）
{
……； //定义局部变量
if（C_->fInTT < t1）
{
……； //控制解算
}
else
{
……； //控制解算
Function1（C_）；
……；
if（C_-> fInTT < t2） //注①
{
……；
}
else
{
……；
}
……；
}
}
利用Cantata6.2进行动态测试。自动生成10个测试用例并执行完后，语句覆盖率和分支判断覆盖率都没有达到100%，源代码中注①处标注的条件判断的假分支没有得到执行。于是，手动添加一个测试用例，使得在给定的输入条件下结构体变量C_-> fInTT的值落在[t2，∞）的区间内，接着重新执行该测试用例，结果还是执行不到该假分支。仔细分析代码后发现，该分支中的条件判断表达式中的结构体变量C_-> fInTT的值已被桩函数Function1（C_）修改。
处理方法如下：第一步，在Cantata6.2的调用接口控制界面中，为该桩函数添加一个新的桩函数实例，并手动修改结构体变量C_-> fInTT的值，该数值应大于或等于t2；第二步，在Cantata6.2测试用例界面，将调用序列更改为新的桩函数实例。至此，执行全部11个测试用例之后，满足语句和分支判断覆盖率全达到100%的指标要求。
3.3 编译器对测试结果的影响
飞行控制软件的编译器目前主要使用CCS2.2或CCS3.3，在用Cantata6.2进行单元测试时，CCS被设置为Simulator模式，Cantata6.2会自动调用CCS，执行编译好的测试中间文件，进而生成测试结果文件。测试过程中，笔者发现对于如下代码段，Cantata6.2自动生成的测试用例对X自动赋值为0.9999，调用CCS2.2执行用例后，代码运行的实际路径与期望路径不一致，测试结果不能达到100%的分支覆盖率指标要求。
#define ZEROP 0.00001
void Function2 （void）
{
if（X
{
……；
}
else
{
……；
}
……；
}
笔者分别在CCS2.2和CCS3.3编译器环境下，验证了该代码段的运行情况，最终得出结论如下：①在CCS2.2编译器下，程序执行真分支，与期望不一致，结果不正确；②在CCS3.3编译器下，程序执行假分支，与期望一致，结果正确。上述结果表明，不同的编译器版本影响程序实际执行路径的正确性。
4 基控软件的Cantata6.2使用策略
4.1 Cantata6.2使用策略
飞控软件中包含很多复杂的结构体数据类型，Cantata6.2能够对结构体类型自动赋值，不用手动一一赋值；而且飞控软件涉及大量数学计算，Catata6.2的测试脚本是开放的纯C代码，可在其脚本管理器界面或测试脚本中直接修改某个测试用例的变量值，提高测试效率。Cantata6.2测试工具是通用的，而飞控软件具有其特殊性，就二者的融合使用，笔者总结出如下经验：
（1）飞控软件中一般都包含do while（1）的死循环结构，测试时需要将这类死循环放开，测试用例才能执行完毕。
（2）飞控软件中包含有很多类似“x=x”的赋值操作，本义是在某些特定条件下，x的值不变，测试时要将这类语句注释起来，否则Cantata6.2会报错。
（3）当被测函数包含子函数时，Cantata6.2会自动作打桩处理，但桩函数有可能会修改某些全局变量的值，进而导致某个分支始终无法覆盖。这时，可以在该桩函数的调用接口添加一个桩函数实例，并手动修改该变量的值，再将调用序列更改为新的桩函数实例，如3.2小节所述实例。
（4）飞控软件作为嵌入式软件，最终是固化在飞控设备中，构成飞控系统运行。因此，软件一般都包含对硬件端口地址的操作，如果是从端口输出数据，测试时需要将这些代码注释起来，如果是读取某个地址的值，则可以自己定义一个变量代替该数值，否则将导致不能自动生成测试用例。
（5）飞控软件中的控制算法一般都包含有积分计算，开发人员一般习惯定义静态的局部变量，遇到这种情况时，应该将这些变量移到函数外部定义，否则会导致不能自动生成测试用例。
4.2 测试驱动开发
Cantata6.2测试工具能够自动生成测试用例，即使不满足语句、分支判断、修正条件判断覆盖率100%要求，测试人员也能很快根据覆盖率结果图示手动添加新的测试用例，使得该用例执行后覆盖到上一次未覆盖到的分支。但是，就笔者的使用经验而言，Cantata6.2对被测代码的要求比较高，被测代码要符合标准C要求，其头文件不能相互嵌套重复引用，否则一个.c文件和其相关的.h文件加载进去就会出现错误提示和警告，而且必须将这些错误提示解决完并通过编译后，才能进行下一步生成测试用例的工作。此外，由控软件具有逻辑复杂、运算量大的特点，要借助Cantata6.2的自动生成测试用例的功能快速完成飞控软件测试，这也对飞控软件的代码质量和框架结构提出了比较高的要求。在飞控软件框架结构和代码质量比较高的情况下，可以加载整个.c文件，一次性生成整个.c的全部测试用例，而不用单个函数去建测试工程，从而加快测试速度。笔者总结使用经验如下：
（1）飞控软件的自动驾驶仪模块根据控制系统的模型编写，模型中包含滚动、偏航、俯仰三通道控制解算算法，该模块代码最好拆成3个函数模块，单个模块代码行数要在200行以内，便于测试，代码结构也更加清晰。
（2）由控软件的特殊功能需求，同一个函数中包含多个条件表达式“与”或者“或”，再进行逻辑（即if else）判断的用法非常多，譬如if（条件表达式1&&条件表达式2||条件表达式3），开发人员在编写代码时，最好将这些条件表达式的计算在if判断之前完成，以有利于测试用例能够正常覆盖到期望的分支。
（3）依据航天软件工程化标准要求，飞控软件的安全关键性等级一般为A级，单元测试必须满足语句（SC）、分支判断（DC）、修正条件判断（MC/DC）覆盖率均达到100%。MC/DC要求每个判定中的每个条件都曾至少一次独立影响判定结果。由控系统的特殊算法需求，模型中涉及分段函数计算比较多，选择MC/DC覆盖率标准后，某些代码会覆盖不到。代码结构如下，斜体加粗部分为未覆盖到的代码：
if（（x1>x2）&&（x1< （x2+const1）））
{
……；
}
else if（ （x1>（x2+ const2））&&（x1< （x2+const3））） //注2：0
{
……；
}
else
{
……；
}
分析上述代码，笔者认为由于选择了修正条件判断覆盖率标准MC/DC，Cantata6.2认为第一个判断条件“x1>x2”的假分支不应再包含“x1>（x2+const2）”的判断条件。类似情况，建议控制系统设计师修改模型文件，或者软件开发人员优化程序结构。
（4）通过3.3小节中的实例，建议开发人员应该选择升级版本的编译器作为开发工具。此外，笔者尝试了将ZEROP定义为局部变量0.00001，结果程序无论在CCS2.2还是CCS3.3编译器下，均执行不到期望的正确分支，这对编码质量提出了较高要求。
5 结语
利用Cantata6.2自动生成测试用例的功能能够快速完成单元动态测试，促进开发人员提高编码质量，提高飞控软件的可移植性和可维护性，满足当前航天多型号软件开发和单元测试的工作需求。同时，工具内置的很多规则集能够帮助测试人员快速定位软件编码错误和框架问题，进而帮助开发人员更好的优化程序结构，进一步提高航天软件研制水平。
参考文献：
[1] 张猛，毛亮.航天嵌入式软件的单元测试方法探讨[J].航天器工程，2006（7）：32-35.
[2] 陶幸辉，宋志刚.嵌入式飞控软件测试方法研究及实践[J].软件导刊，2011（8）：14-16.
[3] 马飒飒，赵守伟，肖小峰.基于覆盖与故障注入的飞控软件测试技术研究[J].计算机测量与控制，2005，13（3）：291-293.
【关键词】车顶单元；制冷量；设计
上世纪90年代后，随着铁路空调客车的飞速的发展，车顶单元式空调器的产量逐年增加。据不完全统计，目前国内拥有空调器约20000多台。值得注意的是投入运用的空调器早已到了大修期，其中绝大部分为车顶单元式空调器。为保证检修后的空调器的性能，客车车顶单元式空调器的检修试验就显得十分重要。
一、客车车顶单元式空调器的性能试验装置
1、空调器的型号
目前，我国铁路客车用空调器的主要型式是车顶单元式。该型空调器自1980年从日本引进，仿制改进，至今已经运用20多年，通过不断地改进完善，现在已经形成标准化，系列化。空调器的结构型式主要有三种：平底侧出风口型，代号为“—”；圆底下出风型，代号为“Y”；平底侧出风口型，代号为“P”。平底侧出风型空调器安装于客车车顶端部，新造客车安装的绝大部分都是这种型式。
2、空调器的构造
车顶单元式空调器是将机械制冷部分的压缩机、冷凝器、干燥过滤器、毛细管(或膨胀阀)、蒸发器、气液分离器、冷凝风机、蒸发风机和空气预热器等集中装在一个箱体内，组成一个单元，可方便地安装在车顶部。与空调器配套的电气控制柜安装在车内配电室，空调器与电气控制柜通过电气连接器(插头、插座)连接，由发电车集中供电(亦可由本车悬挂式发电机供电)。空调器出风口与车内主风道之间通过软风道连接，空调器处理后的空气经车内主风道由送风口送入客室内，达到调节车内空气温度的目的。由此可见，客车车顶单元式空调器性能试验装置的重要性。
3、设计原则
1）试验装置结构力求紧凑，占地面积尽量小，以求适应于各类生产车间的工艺布局；
2）外形应该美观，设备整体性强；
3）工艺布置应该灵活，工艺设计应该简单；
4）操作方便，参数的测试及数据处理要求准确
4、设计方案的确定
目前现场使用的车顶单元式空调器性能装置有闭路式和开路式两种原理方法：
1）闭路式测试原理方法
该方式需要一间室外侧试验室一间室内试验室，被试空调器安装于室外侧试验室内，该室内的空气温度需要调节到名义工况下空调器冷凝器进风温度，经空调器制冷后的空气由送风道引入置于室内侧试验室的空气流量测试装置进行空气流量测量，接着进入空气调节装置，调节后的空气再由回风道被空调器吸入，即完成了一次循环。空气 参数调节及空气流量测量均在风道内进行，该方式的特点是测试环路必须密闭，热湿损耗较小。
2）开路式测试原理方法
该方式与闭路式的区别在于，空气经过流量测量装置后直接排入室内侧试验室内，在房间内进行空气调节。其优点是室内侧试验室的空气参数易于稳定，但热湿损耗较大。
对于这两种方式，均需要设置独立的试验房屋，房屋面积随实际情况而定。被试空调器的安装可采用固定式安装架或试验小车。如果采用固定式安装架，则一般采用箱式结构，室外需设置空调器吊装设备。若采用试验小车则一般采用房间式结构（即由几间相互隔热的房间构成）可在有起重机的检修间将空调器吊装到小车上，试验小车推入室外侧试验室，接上管道即可进行试验。
相比于房间式结构，箱式结构相对构造简单，占地面积较小，它的工艺布置也相对灵活，工艺设置简单，不需要大量的土建工程。所以，本设计“以箱体式空调器试验装置”作为总体设计方案。针对箱体式试验装置的特点，其室内可以安装加热加湿装置，弥补室内的热湿损耗，所以我们选用开路式测试原理。综上所述，我们本次设计方案最后确定为：“箱体结构式的开路式测试”车顶单元式空调器性能装置
二、制冷量的测量方法设计
1、设计原则
1）测量精度高，范围宽，系统环节少；
2）测量装置结构力求紧凑，体积小，以适应在箱体内布局；
3）装置安装操作维护应该方便，参数的读取和数据的处理应该力求简单方便。
2、测量方案确定
目前，由于某些设计单位设计的试验装置仅仅采用一种方法测试制冷量，不能有效地控制室外侧空调器的冷凝器的进风温度，造成试验工况的不稳定，影响了测试精度。
《客车空调三机检修及运用管理规程》中规定，空调器制冷量达不到原参数的90％时，应该分解制冷系统。这就要求所建的试验装置工况要稳定，测试数据应该准确。TB/T2432-93《铁道客车车顶单元式空调器试验方法》中规定，空调器制冷量试验方法采用室内侧空气焓差法为主测试方法，室外侧空气焓差法为辅测试方法。对于检修性能试验装置也可以只采用室外侧空气焓差法。但是为了保证试验装置测试制冷量的的精度及使所测试空调器性能的稳定性，我们采用室内侧空气焓差法为主测试方法，室外侧空气焓差法为辅测试方法测试制冷。两种方法测试的结果相对偏差不大于6％，若超出6％，则要进行管路损耗修正。它的特点是稳定性好，不受外界因素变化的影响。
3、测量原理方法
所谓室内侧空气焓差法,即在规定工况下通过测得流经空调器室内侧空气焓差及量流量,经过计算获得有效制冷量的方法。
所谓室外侧空气温差法,即在规定工况下通过测得流经空调器室外侧空气温差及重量流量，经过计算获得有效制冷量的方法。
三、制热量的测量方法设计
1、设计原则
1）测量精度高，范围宽，系统环节少；
2）测量装置结构力求紧凑，体积小，以适应在箱体内布局；
3）装置安装操作维护应该方便，参数的读取和数据的处理应该力求简单方便。
2、测量方案确定
我国车顶单元式空调器运行在制热状态时候一般在冬季，采用的制热方式一般是直接加热。当空调吸入的新鲜空气和室内的回风在空调器加热室内被混合加热后，将其直接送入客室内即可，它相对于制冷状态而言比较简单，所以我们测试其制热量时候可只用一种方法——室内空气焓差法测试即能满足要求，为了保证热损失在控制要求的范围以内，要用输入电加热器的瓦数所制得的热量来验算（验算公式为qd=3.41·x，x为输入电加热器的瓦数，x可以在试验装置控制柜上读出来），若误差大于6％则要进行管路损失修正。若需要修正，修正方法为将两种结果的差值加给室内空气焓差法计算的制热量。
结 语
目前车顶单元式空调器在铁道客车上的运用已经越来越多，但是空调器性能试验装置的价格都非常高。因此，空调器的检修和性能测试的是急需解决的问题，它直接关系铁道客车运营情况的好坏。车顶单元式空调器性能试验装置能得到广泛的应用，有助于提高客车空调器的性能，从而提高铁道客车乘坐的舒适度，也就在一定程度上提高了铁道客车和其它交通工具的竞争力。
参考文献
[1]王其伟.单元式空调器性能试验装置的工况控制[J].铁道车辆,2008(12)
关键词：NetBeans；Junit；单元测试
中图分类号：TP311文献标识码：A文章编号：1009-3044(2008)16-21255-03
NetBeans Platform Software Development Unit Testing Technology Research
TANG Jun
(Hunan Urban Construction College, Xiangtan 411101,China)
Abstract: Software development and software testing like the two brothers, they are inseparable, collaboration, there is only one objective, that is, successful development of high-quality software. Development and testing of the relationship between such closely, it is difficult to complete the demarcation of the two strict set. Unit testing as part of the test, the general commitment by the staff to coding, the module level who has been coded, who tests. So the test is not just testing things, as a coding staff also need to understand the basic test methods, through unit testing procedures to high-quality modules.
Key words: NetBeans; Junit; unit testing
1 引言
任何一个程序员都知道单元测试的重要性，没有经过严格测试的模块是“靠不住”的，组装过程会出现越来越多的Bug，甚至到了客户那里都不能正常工作，这简直就是一场灾难。虽然每个程序员都深刻的知道这点，但是很多时候在进度的压力下，程序员不得不放弃部分甚至是全部的单元测试。特别是在我国现在的国情下，献礼项目太多，建设方的领导为了在某个“有意义”的日子里使项目上线，往往迫使软件开发方违背客观事实，在不可能的工期内完工。程序员作为项目的最底层人员，自然没有力量来进行反抗，当他们加班加点都无法在规定时间完成，于是放弃测试就成为了他们的唯一选择。
很快这就成为一个恶性循环：压力越大，编写的测试越少。编写的测试越少，的效率越低，并且代码越不稳定。而效率越低并且越不精确，开发人员就感觉越有压力。
程序员的精力就在这样的恶性循环中被耗费掉。想要打破它需要一种外界的影响。所谓的这种外界的影响，其实就是一个简单的测试框架，它可以让我们通过做很少的测试，来达到完整的测试，减少我们编写测试代码的时间。
2 NetBeans 5.0对单元测试的支持
NetBeans IDE 5.0 引入了对基于 NetBeans 平台的 IDE 模块和富客户端程序开发的全面支持，直观的全新 GUI Builder Matisse，经过重新设计的对 CVS 的新支持,对 Sun Application Server 8.2、Weblogic9 和 JBoss 4 的支持，以及很多的编辑器增强功能。同时集成了Java开发工具中应用最广泛的单元测试工具Junit，使得在NetBeans下进行单元测试变得简单容易，提高了程序员进行单元测试的积极性。
可以使用NetBeans IDE创建以下类型的测试：
（1）空测试：没有测试方法的测试框架，尚未指定要测试的任何类。
（2）现有类的测试：包含实际测试方法的类，这些方法镜像了要测试的源的结构。
（3）测试套件：汇集在一起的几组测试类，允许对整个应用程序或项目进行测试。
可以使用以下方法生成并找到测试：在“项目”窗口中选择任何类或包节点，然后从“工具”> "JUnit" 菜单中进行选择。NetBeans 将单元测试表示为子树，这些子树反映了项目的 Java 包结构。每个测试类都由它所测试的类的名称后Test 单词组成（如 MyClassTest.java）。
每个项目都有一个缺省的测试包，所有的测试文件都在测试包内被组织。程序文件与测试文件被分割成两个独立的部分，在项目下分为一个SRC文件夹和一个TEST文件夹，互相不产生影响，测试完成后，只需要将SRC文件夹单独移开，并不需要TEST文件夹的支持。包结构如图1：
3 被测试模块的编写
新建一个Java类库的项目，项目名称为：MoneyChange，新建包moneychange，在包中添加类Money.class。
package moneychange;
public class Money {
private int fAmount;
private String fCurrency;
public Money(int amount,String currency) {
fAmount=amount;
fCurrency=currency;
}
………
}
该类有两个私有属性fAmount和fCurrency，构造函数在对类进行初始化的时候，对两个私有属性进行了赋值。Add方法对两个Money对象的现金（fAmount）进行相加，equals方法对两个Money对象的现金及货币单位进行比较是否相等。
4 创建单元测试
在项目窗口中的类Money.class上鼠标右键单击，在弹出的菜单中选择“工具”，并在子菜单中选择“创建Junit测试”。
这并不是创建单元测试的唯一方法，也可以通过“工具”下拉菜单中的“创建Junit测试”进行。接着弹出“创建测试”对话框，对测试类的类名以及需要生成的内容进行选择后，点击“确定”即可完成测试类的生成。
5 测试代码的修改
Junit不是万能的，不要指望它什么都帮你做好，在单元测试中，Junits 负责测试框架的生成，其他的事情还是需要程序员来做，如测试用例的设计和测试管理等。Junit针对上面代码生成的测试代码如下（已经删除部分注释）：
package moneychange;
import junit.framework.*;
public class MoneyTest extends TestCase {
public MoneyTest(String testName) {
super(testName);}
protected void setUp() throws Exception {}
protected void tearDown() throws Exception {}
public void testAmount() {
System.out.println("amount");
Money instance = null;
int expResult = 0;
int result = instance.amount();
assertEquals(expResult, result);
fail("测试案例为原型。");}
public void testCurrency() {
System.out.println("currency");
Money instance = null;
String expResult = "";
String result = instance.currency();
assertEquals(expResult, result);
fail("测试案例为原型。");}
public void testAdd() {
System.out.println("add");
Money m = null;
Money instance = null;
Money expResult = null;
Money result = instance.add(m);
assertEquals(expResult, result);
fail("测试案例为原型。"); }
public void testEquals() {
System.out.println("equals");
Object anObject = null;
Money instance = null;
boolean expResult = true;
boolean result = instance.equals(anObject);
assertEquals(expResult, result);
fail("测试案例为原型。");}
}
此时，如果要执行测试，可以展开项目中的测试包，在测试类上鼠标右键单机，在弹出的菜单上选择“运行文件”，如图2所示。默认的测试类的执行结果是全部都不能通过的，结果如图3。
图2 图3
我们需要对生成的测试代码进行修改，将我们的测试用例以及期望的结果写入测试代码中，将fail(“测试案例为原型”)；语句删除。testAdd的代码修改后如下：
public void testAdd() {
System.out.println("testAdd");
Money m12CHF= new Money(12, "CHF");
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF);
Assert.assertTrue(expected.equals(result));
}
该方法创建了两个进行加法操作的对象m12CHF和m14CHF，相加的结果为result对象，然后将result与期望的对象expected对象进行相等性测试。对修改后的测试代码再次执行结果如图4。
图4
对所有的测试用例进行测试通过后，即可以开始填写单元测试报告。通过单元测试的类比没有经过测试的类的稳定性将大大提高。
6 结束语
NetBeans集成的Junit单元测试工具为单元测试提供了一个很好的框架，我们无需将精力浪费在写单元测试代码上，而将更多的关注测试用例的设计。开发人员进行测试越来越方便，这也增强了开发人员进行单元测试的信心，在赶工期的同时将单元测试做好，是保证项目最后能够成功的一个重要手段。
参考文献：
[1] 蔡高亮.软件单元测试[J].信息技术与标准化,2008(Z1).
[2] 刘升华.单元测试自动化工具的研究与实现[J].计算机工程与设计, 2007(23).
[3] 郭雯.基于VC6.0的单元测试研究与实践[J].甘肃科技，2007(02).
[4] 隋智泉.一种改进的单元测试JUnit框架[J].电脑知识与技术,2007(08).
关键词：软件测试；认知误区；嵌入式；单元测试流程
1 软件测试简述
软件测试是在软件投入商用前，对软件需求分析报告、设计规格说明书和编码的最终复查，是软件质量保证的关键方法，软件测试并不等于程序测试。它贯穿于软件定义和开发的整个过程，因此，软件需求分析、软件概要设计、软件详细设计和程序编码等各阶段所得到的文档，包括需求规格说明书、概要设计说明书、详细设计说明书，以及源代码都是软件测试的测试对象。随着软件规模的不断扩大，以及软件设计复杂程度不断的提高，软件开发中出现失误或缺陷的概率越来越大。随着市场对软件质量重要性的认知程序的提高，因此软件测试在软件项目实施过程中的重要性尤为突出。软件测试将会成为一个具有很大发展前景的行业，市场将需要更多具有丰富测试技术和先进管理经验的测试技术员和项目经理。
2 软件开发项目测试的误区
软件测试从1990年左右进入中国，目前国内大的测评中心、大型企业已经完全掌握了软件测试的测试策略和测试方法。小企业普遍存在测试人员不懂什么是单元测试，怎样进行单元测试，很少能看懂代码的细节。而开发人员很少能够提供完整的详细设计报告、需求报告。导致单元测试，以拼凑测试报告为目的。
认知误区一：软件测试是软件开发的最后一道步骤，工程师们一般认为，软件实际项目要经过下面六个阶段：需求分析，概要设计，详细设计，软件编码，软件测试，软件。因而，认为软件测试只是编码后的一个孤立的阶段，这就是不了解软件测试流程的认知偏差。软件测试是一个系列的活动过程，是一个开放的体系，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。从而，软件测试应当贯穿于软件项目的整个生命周期，并不是软件开发后最后一道步骤。认知误区二：软件商用后如果发现质量问题，就武断认为是软件测试人员的工作失误。这种认识很狭隘，很是打击软件测试人员的工作积极性。软件测试只能确认软件存在错误，不能保证软件没有错误。因为从根本上讲，软件测试不可能发现全部错误，软件后的错误可能来自软件项目中的各个过程。认知误区三：软件测试对测试人员技术要求不高，任何人都可以做。很多工程师认为软件测试就是安装并运行程序，按按键盘的重复性工作。随着软件测试技术的不断改进和完善，新测试方法、新流程、新工具都在不断被开发出来。这就需要软件测试工程师掌握和学习很多专业测试新理念和新技能。认知误区四：只有编写程序的高手才是软件专家，而软件测试没有前途。由于我国软件行业整体研发能力比较低，软件开发过程不规范。不少软件项目的开发都还停留在“累加堆叠“阶段。项目开发依靠个别程序员决定，他们一人负责总体设计和代码编写，给人的印象是程序员是真正的牛人，完成了所有的软件项目开发工作。但在微软等世界知名软件企业里，软件测试人员的待遇和数量与一般程序员没有多少差异，优秀测试人员的待遇甚至比普通程序员要高的多。
3 嵌入式软件单元测试流程
单元测试是指对软件中的最小可测试单元进行检查和验证。单元是规格说明书中的最小单元，包括函数、子程序、程序。单元测试关注独立的函数功能，是测试过程中最低级别的测试活动。需要开发一个或多个测试用例执行单元测试。把代码问题缩小范围在开发阶段锁定Bug是单元测试的主旨要求，以下将介绍一种容易操作的嵌入式单元测试实战流程。
第一阶段，制定测试记录表，记录测试过程，和测试情况。测试记录表包含：源文件名，子函数名，用例标号，用例名称，用例个数，用例通过个数，语句覆盖率，分支覆盖率，MC/DC覆盖率，测试结果，问题描述，测试人员，测试时间。针对第一阶段的测试结果，此时需要大家分析出问题的代码，各抒己见，总结问题，给出解决方法。
第二阶段，解决部分测试用例failed问题，找出阻止生成用例的共性。常见问题汇总：局部变量未初始化，调用函数未声明，局部变量直接赋值，结构体嵌套、结构体指针、声明问题、声明位置问题，函数指针，大循环、死循环，绝对地址，指针变量，C语言程序中带有goto语句。解决办法：局部变量声明后，需要赋初值再使用。调用函数未声明，该问题发生在隔离测试阶段，属于代码书写不规范问题。解决方法：自定义的函数都需要在头文件中做统一声明。局部变量直接赋初值：该问题发生在测试用例无法生成阶段，属于代码书写不规范问题。解决方法，结构体局部变量，指针变量需要先声明后赋初值。结构体嵌套、结构体指针、声明问题、声明位置问题：该问题也属于代码书写不规范问题。解决方法：根据MISRA代码书写规范，结构体需要放在头文件中统一声明。大循环、死循环：单元测试需要有程序结束的出口。解决方法：把大循环改为小循环，注释掉死循环（if（1）、for（； ；），while（1））。绝对地址：单元测试不连接真实的硬件设备。遇到寄存器等绝对地址时，需要对寄存器做变量处理。指针变量：需要声明一个同类的数组，然后把数组的首地址，赋给指针变量。函数指针：需要虚构一个函数实体，取函数地地址赋给函数指针，完成映射。C语言程序中带有goto语句：需要改变程序结构，增加判断语句，去除所有的goto语句，以便确保C语言程序的稳定性。
测试第三阶段：基本圈复杂度高于MISRA阀值要求的函数，先考虑把复杂函数改为几个小函数。改不了的由开发人员写声明以及具体原因，再按照路径分支来设计测试用例。汇总测试结果，提交测试问题报告单，并提交行业标准测试报告。
4 结束语
文章简述了软件测试的基本概念，澄清了软件测试工程实践中的几个误区，依据单元测试实践的具体案例，介绍了一种高效、容易操作的嵌入式单元测试的流程。
参考文献
[1]胡丹，杜新华.基于目标机的嵌入式软件单元测试[J].电子测量技术，2006（2）.
[2]赵正海，王宁.跟踪雷达“指示引导”功能软件测试方法研究[J].现代电子技术，2013（36）.
[3]于园园.软件测试技术与测试管理研究[J].江苏科技信息，2016（7）.
[4]王琨.嵌入式计算机软件测试关键技术探讨[J].科技创新与应用，2016（7）.
[5]张金环，田洪涛.浅析设备软件测试与质量保证[J].电子工业专用备，2016，45（1）.
作者简介：张军（1988-），男，陕西武功人，工学硕士，助理工程师，主要研究方向：雷达信号处理算法、数字中频收发机和嵌入式软件测试。
功能测试主要通过单元测试和集成测试来完成系统的功能测试。单元测试的目的是测试源码中最小单元的代码是否正确处理它该处理的任务。单元测试重点测试了代码中分支比较多的地方,以验证程序是否能根据条件执行相应的分支;并重点测试了代码对于异常情况的处理,以验证代码是否能对于发生的异常情况进行相应的处理;再就是对源码中与数据库相关的代码和涉及用户输入输出的代码进行了重点测试。集成测试是在单元测试的基础上,将已经通过单元测试的软件单元组合起来,组成可以执行的功能单元,然后进行测试。通过测试的子功能单元再通过组合,组成更大一级的功能模块进行测试。集成测试重点测试软件单元的组合能否正常工作,模块之间的组合能否集成起来工作,还要测试构成系统的所有模块组合能否正常工作。集成测试主要有三种测试方案:自底向上进行测试,自顶向下进行测试,以及自底向上和自顶向下结合的方式进行测试。自底向上的集成测试方式是最常使用的方法,这种方式从程序模块结构中最底层的单元模块开始组装和测试。自顶向下的集成测试方式正好与自底向上的方式相反,需要编写桩模块以支撑上层的测试。最理想的方案是能将这两种集成方式结合起来,这样在早期的时候,既能发现重大的问题,又能及早展开人力。但是这种方式实施起来有难度,需要软件开发者一开始要做好合理的策划和设计。由于系统在需求和设计阶段做的工作比较扎实,本系统主要采用了自底向上的集成测试方式:先把最底层的软件单元组合,组成高一级的功能单元进行测试;测试通过的功能单元再进行组合,组成更高一级的模块单元,并对模块单元进行测试;最后,模块单元再集成到系统中进行测试。测试重点集中在各单元与各单元之间的接口和信息交互。
2.用户界面测试
通过用户界面测试来验证用户与系统的交互情况。界面测试的目标是确保系统向用户提供适当的访问和浏览被测对象功能的操作。测试方法,为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确进行浏览,并处于正常状态。完成标准,证实各个窗口与基准版本保持一致,或符合接受标准;需考虑的特殊事项,并不是所有定制或第三方对象的特征都可访问。
3.性能测试
性能测试采用了主观评测和软件评测相结合的方法,先部署上系统,在环保局内部试运行,通过工作人员的使用来了解系统的反应速度是否满足客户的需求。系统的性能需求主要是对系统web访问的response时间和系统负载能力的要求。在性能测试过程中,我们利用Loadrunner模拟用户向系统发送请求,并监控系统的CPU,Memory等参数。
4.安全性测试
本系统采用先登录,后操作的方式。因此,必须测试有效和无效的用户名和密码,并注意到是否大小写敏感。本系统是有超时的限制,也就是说,用户登录后在一定时间内(20分钟)没有点击任何页面,需要重新登录才能正常使用。所以,也必须对其进行测试。
5.测试结果
关键词：单元教学；单元测试；整体性；科学性
随着新课程的深入开展，语文课从一开始的异化慢慢开始理性地回归“语文”，越来越多的教师开始注重语文能力的培养和训练。在这样的形势下，“单元教学”这一概念再次进入了大家的视野。
早在1935年，由夏丏尊、叶圣陶合编的《国文百八课》在《编辑大意》中就提出这么一个理念：“从来教学国文，往往只把选文讲
读，……本书每课为一单元，有一定的目标，内含文话、文选、文法或修辞、习问四项，各项打成一片……”在1980朱绍禹教授撰文赞扬了北京市语文特级教师霍懋征的“单元教学法”。
我们所说的“单元教学”是指根据学生认知结构发展的特点，站在知识系统性的高度，将几篇在知识结构上具有内在联系的课
文按照一定顺序编排在一起进行教学，综合培养学生听说读写能力的教学模式。单元教学中教师教读、学生自读、写作、练习、测试等环节是融合成一个整体的。单元教学具有整体性、系统性、有序性、综合性等特点，具有很大优势。单元教学的优势主要表现在：（1）重点突出，可以从识记、理解到分析、应用，从听、读到说、写，全面立体地提升学生的语文能力。（2）单元整合，有助于解决语文课时不足的问题，提高教学效率。（3）可以体现语文知识的系统性、科学性。（4）可以更多地引入课本外鲜活的语文资源。
单元教学正在新课程背景下如火如荼地开展着，而作为教学
的一个重要环节——单元测试却往往被忽略，成为单元教学最为
薄弱的一个环节。
测试是教学的一个重要环节。众所周知，教学需要评价，教学评价的两个核心环节：对教师教学工作（教学设计、组织、实施等）的评价，还有就是对学生学习效果的评价——考试与测验。全面客观的评价工作不仅能估计学生的成绩在多大程度上实现了教学目标，而且能解释成绩不良的原因，并找出主要原因。作为一种量化的教学评价，测试可以说是对教学进行一次科学的诊断。同时，只有较为科学地掌握了学生的接受情况，才能有针对性地开展补救
措施，从而更好地实现达标。
一、现在的高中阶段，单元测试出现的问题
1.单元测试一味贴近高考，与单元教学内容严重脱节
市场上很多的单元练习卷、测试卷以及学校自己命题的单元
测试卷都存在着这样一个问题——不顾自己本单元教学到底是什么内容，直接拿现成的高考题、高考模拟题进行拼接，组成一份单元测试卷。进行这样的单元测试危害颇大：一方面，即使教学中严格执行的是单元教学，而这样的试卷是绝对无法检验学生对于单
元教学目标的掌握情况的；另一方面，让学生过早接触高考题、高考模拟题是违背学生的认知规律的，不但不能提高学生的学习成
绩，往往还会造成很多后遗症，为将来的教学造成隐患。
当然，这一种做法越来越被大多数教师、学校所抛弃，很多教师重拾一个理念——回归书本。而根据本人对江苏省各名校单元测试卷的研究，发现所谓的“回归书本”，就是增加对课文中出现的高考高频字音、成语的考查，对高考规定篇目的古诗文默写的分值增大等等换汤不换药的措施。有小部分单元测试出现了一些与课内知识相关联的迹象，但是这些都是对识记层次的考查，与我们所需要的与单元教学相配套的单元测试相去甚远。
上述单元测试表现出的问题简单概括起来就是随意、不科
学——与单元教学目标严重脱节。这样的单元测试，即使之前的单元教学完成得多么好，都不能说是完整的单元教学。并且缺少量化的单元测试，仅仅凭借教师的经验来判断学生的达标情况，显然是不够科学的。而这种做法带来的最直接、最现实的问题就是——学生觉得听语文课是没用的，上课讲的考试全考不到，而语言感受能力好的同学不用上课成绩一样好。
2.有部分单元测试基于的是主题的单元教学
比如，高中语文必修一板块三“月是故乡明”的主题是乡情。所选的课文《想北平》一方面表达了作者对北平的思念与热爱，另一方面表达了在当时特定的历史条件下，老舍对家乡北平的种种忧
虑。《我心归去》主题中重要的一点就是——奋斗过的地方留下了人的汗水，就成了你的故乡。于是，有相应配套的单元测试就选择了杜甫的《月夜忆舍弟》作为诗歌鉴赏题，考查的是虚写的写作手法。文学类文本阅读选择了《草屋的声音》，因为这篇文章写了知青在“第二故乡”征服恶劣大自然的生活经历，而考查的点就更加五花八门了。这样的单元测试是从根本上违背我们所追求的“以培养学生语文能力”为目标的单元教学目标的，所以也是存在很大问题的。
3.有些单元测试虽然注意了对单元教学目标达成情况的考
查，但是比重不够
有些学校自己命题的单元测试，开始注意对单元教学目标达
成情况的检验。比如，苏教版高中必修二的教学，设计的单元教学总目标是多种手法综合的景物描写以及景物描写对于抒情的作用。与之对应的单元测试中，诗歌鉴赏选择了一首运用多种修辞手法，并且借景抒情的诗歌，文学类文本阅读中出了一道景物描写赏析的题目。但是，在传统的语文综合卷中，能做的也只有这些。一份高考规格的“标准”语文试卷是由90分的基础阅读部分和70分的写作部分组成，这90分的基础阅读部分若要全面照顾单元目标中提到的某一种具体的语文能力，那么可做文章的地方一般是语言
运用、诗歌鉴赏、文学类文本阅读这几类题目。但是考查分值一般只有语言运用3-5分（一题），诗歌鉴赏10分，文学类文本阅读6分（一题），这19-21分在整卷160分中仅仅占了百分之十多一点。显然，这种单元测试是无法客观有效地反映单元目标达成情况的。
二、为适应教学，单元测试需改革
针对上述情况，我认为，只要我们进行单元教学，我们就应该对现在的单元测试进行大刀阔斧的改革，使之与单元教学相适应，成为融入单元教学这一整体的新单元测试。
1.单元测试应该科学，不能随意
我们应该抛弃使用现成题目的错误做法，时刻要明确，单元测试是整个单元教学的一个重要组成部分，是对单元教学目标达成
情况的检查，所以命题时一定要把单元教学目标时刻放在心中，从各种角度，用各种题型全方位检查目标达成情况。也只有将测试与教学紧密结合起来，才能进一步激发学生学习语文的意愿。
2.单元测试应该有层次，不能无序
我们应该打破对语文试卷结构的旧有认识。语文试卷未必需要各种题型齐全，也未必需要和高考形式一样，从基础到文言文，然后是诗歌鉴赏，最后是阅读。我在实践中根据大纲对知识的要
求，把整张测试卷分成三个部分：基础检查部分、分析应用部分、综合实践部分。基础检查部分包括识记要求的知识点，以及课堂上强调过的知识点，甚至就是同样的语段同样的题目。分析应用部分包括单元目标中要求的语文能力的简单应用、课堂内容的迁移，在这一部分还可以加入对指定课外阅读篇目、课文自学情况的检查。综合实践部分是对本单元要求掌握的语文能力的综合运用，在这一
部分还可以兼顾之前几个单元的内容。其中，每个部分都可以兼顾语言文字运用、文言文、诗歌鉴赏、文学类文本阅读等题型。
要做到一份单元测试卷层层推进，科学有序，还需要我们在命题前设计好双向细目表，明确每一个层次所设计的分值、题量，依据双向细目表来命题，这样不仅可以更好地控制测试的效度，还便于测试后分析教学中出现的问题。
3.单元测试后要有反馈和补习工作
单元测试是对单元教学目标达成情况的检查，通过检查，一定能发现学生在知识方面的漏洞，同时也能发现教师教学中的不足，所以测试后我们应该及时把测试的结果和详细的数据分析反馈给学生和教师。在获得结果后，教师和学生都应该认真进行分析，对大面积发生的问题，教师应该对自己的教学过程进行反思，采取一定的补救措施；对于个别出现的问题，可以用单独辅导、补充训练的方式进行补习。只有将这一环节做好了，单元测试的真正目的才算达到。
总之，在教学中，我们的思维应该与时俱进。一方面，我们要紧跟新课程发展的脚步；另一方面，我们也应该用思辨的眼光审视在发展中出现的各种现象。单元测试不是应试教育，而是教学做到整体性、系统性的一个重要环节。把单元教学条件下的单元测试做
好，能够使语文教学更加科学，更推进一步。如果能将高中三年的期中、期末考试都纳入整个单元教学系统中来，语文教学定能更加科学，更为有效。
参考文献：
[1]王家伦，赵黎丽.呼唤单元教学的涅槃[J].中学语文，2009（7）：3-5.
[2]彭光宇.论语文单元目标分类教学[J].湖南教育学院学报，2000（1）：67-71.
[3]耿法禹.30年来中学语文教学科学化之路[J].广西教育学院学报，2009（1）：153-157.
本文就如何运用反馈——矫正手段提高教学目标效果谈几点看法。
一、在课前通过诊断性测试，获得学生在学习新内容前的知识反馈，为上新课做好准备。
诊断性测试一般安排在新学期或新开课前进行，测试时间一般5～10分钟，测试应侧重于考查学习新课所需要掌握的基本知识和基本技能。例如，在上动物模拟人体手术实验课前，先测试学生关于无菌技术和无菌原则方面的知识并补偿，由此提高他们的学习外科手术的前提能力，最终提高实验目标。
二、在课前或课后，通过形成性测试了解学生的达标情况，及时查漏补缺。
1、编制形成性测试题，包括课堂测试题和单元测试题，要确保适合各自的特点。
（1）课堂测试题，要适合在课堂教学中进行测试。课堂教学时间一般以二学时为单位，共80分钟。其中用以进行课堂测试及反馈矫正的时间通常只有5分钟，故编制此类试题要突出重点，考虑课堂操作的可行性，试题量不能过多。例如，在“复苏”一章编制的课堂测试题为：①快速诊断心脏骤停的方法；②心肺初期复苏的abc步骤；③心脏按压有效的标志是什么；④心肺复苏有效的指标是什么等。这些题中包括了本章的重要知识点，学生掌握后，在遇到心脏骤停病人时就会懂得如何去诊断和处理，而且试题量适中，便于在课堂上进行测试和矫正。
（2）单元测试题，即教师根据教学的情况，一般按章节划分为一个教学单元，每学完一个单元后进行一次单元测试，以评价学生的单元达标情况。单元达标测试覆盖的目标范围较大，而且每一目标都应有相应的检测题，测试时间为20～30分钟，测试内容多时间少，因此编制此类题主张多用选择题和判断题，少用填空题、名词解释和问答题，以方便学生答题，做到既能检测目标又不影响课堂授课。此处，通过定期的单元测试，又能促使学生经常系统地进行复习，有利于知识的巩固和强化。
2、编制平行性测试题，此类试题适用于对矫正生的检测。
即用以检测单元测试中的未达标者，在经过补救矫正后是否已达标。编制此类别试题应与单元形成性测试题是同质不同形的，即用不同的试题形式去检测同一目标。例如，检测“补钾原则”这一目标时，如果在单元形成测试中采用选择形式，则在平行性测试中可采用判断或填空题的形式进行检测。
三、反馈——矫正是对经测试反馈的未达标者及时补救矫正，使其达标。
1、课堂反馈矫正。
课堂测试反馈一般采用提问、回答、接力填空等形式，其中最常用的是课堂提问的形式，而课堂提问的形式主要适合于对个别学生，这与目标教学要面向全体学生的宗旨是矛盾的，为了解决这一矛盾，在提问时应使所提问的学生具有代表性和随机性。所谓代表性是指所提问的学生能代表全班学生中的某一部分，如优生、中等生或差生。要做到有计划有目的地进行提问检测，尤其对差生要多进行检测矫正。随机性主要是针对课堂教学的具体情况，在全班同学中随机地进行提问。笔者曾在上“急性阑尾炎”一节时，发现一位同学在上课时开小差，当时立即对她进行提问检测：“急性阑尾炎最有特征的症状是什么？”她回答是“腹痛”。这样通过提问，可及时地使她调整思维、融入课堂。虽然她答得不全对，但是通过提问既能起到对她及时补救矫正的效果，同时也能引起其他同学的重视（尤其是对提问的这一问题的重视），结果在单元形成测试中全班同学都能答对这一题。这样通过抓典型、抓代表，达到“牵一发而动全身”的效果，既能及时纠正课堂上出现的个别问题，又能调动全班同学的课堂积极性和主动性，因而能有效地提高教学目标达成度。
关键词：ISO 26262；汽车电子；测试
DOI：10.3969/j.issn.1005-5517.2013.4.005
ISO26262标准概述
功能安全标准（ISO26262）是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，主要定位在汽车行业定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件，旨在提高汽车电子、电气产品功能安全的国际标准。
ISO26262从2005年11月起正式开始制定，经历了大约6年左右的时间，已于2011年11月正式颁布，成为国际标准。中国也正在积极进行相应国标的制定。
ISO26262主要内容包括：
·提供了汽车生命周期（管理，研发，生产，运行，服务，拆解）和生命周期中必要的改装活动。
·提供了决定风险等级的具体风险评估方法（汽车安全综合等级，ASILs）。
·使用ASILs方法来确定获得可接受的残余风险的必要安全要求。
·提供了确保获得足够的和可接受的安全等级的有效性和确定性措施。
功能安全受研发过程（包括具体要求，设计，执行，整合，验证，有效性和配置），生产过程和服务流程以及管理流程的影响。
安全事件总是和通常的功能和质量相关的研发活动及产品伴随在一起。ISO26262强调了研发活动和产品的安全相关方面。
符合性要求
1）如果要宣称符合ISO26262，那必须是符合其每个要求，除非有如下情况之一：
·根据ISO26262-2中，对不适用的要求进行安全行为的裁剪：
·针对不符合项，提出其说明理由，并对理由根据ISO26262-2进行评估：
2）所有安全行为的输出物都在ISO26262中有明确的规定。
3）下文中出现的列举各测试方法的表中，有不同的序号表示方法：
·连续的序号，比如1.2.3：所有的方法应被用于对应的ASIL等级，如果出现所列表中之外的方法背用于测试，则需要进行说明。
·可选的序号，比如1a，1b，1c：可以选择某个或多个方法进行测试，并优先考虑更高推荐指数的方法。如果多个方法被组合选择用于测试，则需要进行说明。
4）针对ASIL的各级，表中的每个方法都有对应推荐指数：
·“++”：最高的推荐指数
·“+”：建议使用
·“0”：不建议使用或不需使用
测试概述
ISO 26262-8中的第9节描述了“Verification”的目标、要求和建议、工作输出等。Verification是用于确保实现与需求的一致性，在安全生命周期的几个阶段中都会用到。包括概念阶段、产品开发阶段、生成和运营阶段。本文主要描述在产品开发阶段中的测试环节中，需要用到的各种测试要求和建议。
测试计划
1）在测试执行前，都需要建立测试计划，其主要包括几部分：
·测试范围：用于测试的产品内容：
·测试方法：用于测试的各种方法：
·测试标准：测试通过或失败的标准：
·测试环境：如果需要用到各种测试环境，比如仿真环境等，需要进行说明：
·测试工具：用到的各种测试工具：
·出现异常后的对策：
·回归策略：在测试对象发生变更时，指定其如何进行回归测试，比如全部回归、部分回归、和其他测试案例一起回归等。
2）测试计划的制定还需考虑到以下几个方面：
·测试方法的完整性：
·测试对象的复杂度：
·测试经验：
·测试技术的成熟性和风险。
测试规格
1）测试规格需要选择和指定用于测试的方法，并包括测试案例、测试数据和测试对象。
2）每个测试案例需要包括：
·序号：唯一的ID
·测试对象的版本号
·测试对象的条件和配置：针对测试对象的不同配置，需要选择合理的测试案例进行测试
·测试环境
·输入值和顺序
·期望行为：报刊输出值、输出范围、功能表现等
3）测试案例需要根据测试方法来分类。针对每个测试方法，除了测试案例外，还需考虑以下几方面：
·测试环境：
·相关性：
·测试资源。
测试执行和测试报告
4）按照上述章节中制定的测试计划和测试规格，进行测试的执行。
5）针对测试结果，其测试报告需包括以下几个方面：
·测试对象的ID：
·测试计划和测试规格的引用：
·测试环境、测试工具、标定数据：
·测试结果和期望值的符合度：
·测试通过或失败的结论，如果失败，还需要指明失败原因和修改建议：
·针对没有执行的测试案例，说明原因。
ISO26262中的测试阶段
ISO26262中涉及到测试的阶段共包括“硬件集成和测试”、“软件集成和测试”、“产品集成和测试”这三部分。下面章节分别介绍这三部分的要求和建议。
硬件集成和测试
ISO26262中“Part 5：ProductDevelopment：HardwareLevel”针对产品开发的硬件部分提出了专门的集成和测试要求和建议。
1 硬件集成和测试需要按照安全计划和验证要求来按计划进行：
2 硬件集成和测试需要按照产品集成和测试计划来进行：
3 针对变更，需要按照标准规定中的变更管理来对测试策略进行影响分析：
4 测试的设备可以按照国际标准（比如ISO17025）或公司标准来进行标定：
5 硬件集成测试的测试案例需要按照表1的方法进行设计：
6 针对硬件安全需求，硬件集成和测试需要对其安全机制实现的完整性和正确性进行验证，其方法如表2所不。
7 硬件集成和测试需要按照表3的方法进行外部压力环境下的鲁棒性测试。
软件集成和测试
软件单元测试
软件单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。ISO26262中规定了其相对应的要求和建议：
1 软件单元测试需按照“ISO26262-8节9中”的验证要求来有计划的定义和执行。软件单元测试的对象是具体的软件实现单元，在基于模型的软件开发过程中，软件单元测试的对象是其单元模型。
2 软件单元测试需要按照表4中列的方法进行，以完成以下目标：
·检查是否符合软件单元设计的具体要求：
·检查是否符合软硬件接口要求：
·检查功能是否正确实现：
·检查是否有异常功能：
·检查软件实现的鲁棒性，比如错误处理效率等：
·检查功能所需资源的完整性。
3 软件单元测试中的测试案例需要按照下表5中的方法进行分析设计。
4 软件单元测试中，对于需求的覆盖度、代码的覆盖度都需要进行衡量，具体方法如表6所示。如果覆盖度不够，还需要增加其他测试案例。
·代码的覆盖度都可以借助一些软件工具来实现：
·如果是基于模型的开发，其软件单元测试需要利用类似的模型的结构化覆盖指标来衡量：
·如果通过代码的打桩来进行测试覆盖度的衡量，必须保证打桩的代码和正常的代码的执行功能是一致的：
·对于覆盖度衡量目标，都需要给出一个合理理由来表示其不同的级别，对于无法覆盖的代码，可以通过检查等其他方法来进行验证。
5 软件单元测试需要尽可能的在真实的目标环境上执行，如果利用其他环境，则需要评估其与真实环境的差异、源代码和目标代码的差异，分析设计测试案例，以便在接下来的测试阶段中得到执行。
·测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。
·如果能利用目标环境中的相同处理器来运行软件单元测试案例，那是最有效的，但如果不行，则可以用处理器模拟器来代替，否则软件单元测试只能在开发系统中进行测试。
·软件单元测试可以在不同的环境中执行，比如模型在环测试（MIL）、软件在环测试（SIL）、处理器在环测试（PIL）、硬件在环测试（HIL）等。
·在基于模型的开发系统中，软件单元测试可以在模型级别进行，但模型与代码的执行比较测试必须要做，以保证模型与自动生成的代码的结果一致性。
软件集成和测试
软件集成和测试主要对实现的各软件模块进行集成，并验证其嵌入式软件实现是否符合软件架构设计。该阶段的要求和建议如下：
1 软件集成计划应该描述层次化的集成单个软件单元进软件组件中，直到嵌入式软件完全集成，并且应该考虑如下：
·软件集成功能的相互关系：
·软件集成和软硬件集成的相互关系。
注意：对于基于模型的开发，可以先集成各模型，然后对集成好的模型进行自动代码生成以完成整体软件的集成。
2 软件集成测试根据ISO26262-8：2011，第9节计划，定义并且执行。软件集成测试的测试对象是软件组件。对于基于模型的开发，测试对象可以是和软件组件相关的模型。
3 软件集成测试需要按照表7的方法进行，以完成以下目标：
·检查集成的软件是否和软件架构设计一致：
·检查集成的软件是否满足软硬件接口规格：
·验证功能的正确性：
·检查其鲁棒性，比如错误检测、错误处理机制的有效性：
·检查是否有足够的资源来支持。
4 测试案例需要按照表8中的方法进行分析设计。
5 对于软件架构级别的需求测试覆盖度，可以用来衡量测试的完整性，以及用于证明没有设计之外的功能实现。如果有需要，可以增加新的测试案例，或者提供一个合理的理由说明。
6 为了评估测试案例的完整性，同时确保没有多余的功能，根据表9列出的指标需要衡量出其结构覆盖率。如果覆盖率不够高，要么需要添加额外的测试案例，或者提供一个合理的理由说明。例如，结构覆盖率的分析可以用于发现测试案例的不足、无用代码、无效代码或者多余功能等。
·结构覆盖率可以利用工具计算出来。
·如果是基于模型的开发，结构覆盖率可以通过模型级别的模型结构覆盖率来统一计算。
7 作为产品的一部分，嵌入式软件需要被验证其包含设计的所有功能。如果嵌入式软件包含了设计之外的功能（比如用于调试的代码），则这些功能需要被验证是不影响软件的安全需求的。如果这些设计之外的功能在真实产品中保证不会被激活执行，那也是符合这个要求的：否则删除这些功能，也需要按照需求变更流程来统一处理。
8 软件集成测试需要尽可能地在真实环境中运行，如果不行，则需要评估测试环境与真实环境的差异性，并针对这些差异，在后续的阶段的真实环境的测试中设计专门的案例来执行。
·测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。
·针对各种测试，需要建立合适的测试环境。比如目标处理器的测试环境、仿真处理器的测试环境、开发测试环境等。
·软件集成测试可以利用模型在环测试（MIL）、软件在环测试（SIL）、处理器在环测试（PIL）、硬件在环测试（HIL）等测试手段进行测试。
软件安全需求验证
本阶段的目标是验证嵌入式软件符合软件安全需求，其所规定的要求和建议如下：
1 软件安全需求的验证需要制定计划，定义再执行。
2 为了验证嵌入式软件实现了软件安全需求，表10列了所需的测试环境。注意：已有的测试案例，例如在软件集成测试阶段使用的可以重用。
3 对于软件安全需求实现的测试需要在目标硬件平台上完成。
4 软件安全需求验证的结果需要考虑下面这些因素来评估：
·和预期结果一致：
·软件安全需求的覆盖率：
本文作者：惠大成工作单位：陕西省榆林市清涧县实验中学
把握语文教学单元形成性评价程序操作
单元形成性评价可分为四个步骤：出示试题——检测阅卷——反馈矫正——总结评价。一是针对性测试题应与教学目标相对应，单元目标中的重点对应题型的测试题应多一点，反之，对应数量少的测试题也不容忽视。二是分层次性教学原则。按阅读，记忆、理解、运用、综合的顺序，试题应是呈现层层递进关系，体现一种由简到繁、由具体到抽象、由易到难的循须进方式，把握好试题的难易程度。三是体现综合归纳性原则。试题要有灵活性，特别是要注重培养学生解决问题的应变能力。检测阅卷测试一般不超过一小时，测试的方法一般采取闭考形式，有时也可采取半开的形式，采取何种方式由试题的难易程度确定。阅卷要及时、认真，并写出试卷分析，填写单元检测评估表。反馈矫正是语文教学单元形成性评价中的重要一个环节，根据阅卷中获得的信息，经过教师反思，形成纠正方案。只有找准问题，纠正措施才会有效。对于学生做错的题纠正时，普遍性问题应重点纠正，同时对个别性问题也不能忽视。这时的纠正实质上是有效地组织学生进行第二次学习，加深学生对所学知识巩固，给不达标的学生创造再提高的机会。总结评价这一环节，也就是反思的过程。做好总结，进行合理公正评价，是激发学生的学习热情、调动学生积极性的重要手段。应注意到三个方面：一是讲公平性，教师对学生要一视同仁，不歧视后进生，坚决避免唯分数论；二是多鼓励性，所谓鼓励性，就是只表扬不批评，对那些在单元测试中没有过关而在平常测试中达标的学生也要表扬鼓励，三是勇于承担责任，这里所说的责任是指老师在分析错题的原因时，不要一味把责任推给学生，要主动承担教学过程中的责任，从教学的某些方面找出不足，这样会使师生关系更加密切，更有利于改进教学工作。
语文教学单元阶段性测试采取的措施
为保证语文教学单元过关顺利实施，单元测试卷必须保证质量。单元测试卷由任课教师认真批阅，便于掌握试卷得失，有利于反馈矫正。这样每进行一次单元测试才能获得其真正的意义上的提高。1.搞好单元阶段评价有利于促优转差。通过单元达标测试，便于发现薄弱环节，便于及时采取补救措施。认真搞好单元阶段性评价，就会让差生通过二次达标获得成功，感受到成功的喜悦，增强战胜困难的决心和学好知识的信心，形成良性循环。对于优等生来说更应找出存在的问题，有待于进一步提高。2.做好单元阶段性评价，有利于教学质量的整体提升。单元阶段性测试不同于综合性测试，更不同于升级测试，应当把单元阶段测试看作提高学生课堂练习的一种手段，让学生在轻松愉快的气氛中使知识得到巩固、能力得到提高。3.培养学生的自学能力。语文单元阶段性测试的目的是为了让学生通过测试掌握良好的语文学习方法，提升学生的学习能力。灵活运用知识，做到有师精通，无师自通。语文教学是一个慢长而渐进的过程，只要教师引导学生把握好段性测试学习方法，及时做好单元阶段测试的测评工作，才能使语文教学更上新台阶。做到阶段段性测试与综合测试有机统一，达到使学生在语文学习中如鱼得水尽情傲游。
