测试仪驱动保护论文
测试仪驱动保护论文（精选7篇）
测试仪驱动保护论文 第1篇
绝缘栅双极性晶体管 (IGBT) 集功率、场效应晶体管 (MOSFET) 和双极型功率晶体管的优点于一体, 具有电压控制、输入阻抗大、驱动功率小、控制电路简单、开关损耗小、通/断速度快且通态压降低、易高压大电流等特点[1,2,3]。在IGBT的应用中, 驱动和保护一直都是研究的关键技术, 特别是过流保护方面。IGBT器件本身以及它在电路中运行条件的特点, 决定了其过流保护和其他开关器件相比有很大的差别。IGBT的过流保护电路直接关系到整个系统的工作性能和运行安全。
本研究集中分析IGBT驱动保护电路的设计与测试。
1 IGBT驱动电路
1.1 IGBT的开关特性
IGBT的等效电路和器件的内部结构, 如图1所示。由图1可知, IGBT的开关控制是通过和MOSFET类似的栅极结构来完成的, 因此IGBT和MOSFET的开关过程大致相似。IGBT硬开关时VGE、ICE和VCE的波形示意图, 如图2所示。开通时, 当VGE达到开通门限后, 到t2时间, ICE达到最大值, VCE下降过程中, 由于和MOSFET一样的密勒电容CGC的作用, 栅极电压基本恒定, 延缓了IGBT的开通过程, 当VCE下降结束, ICE达到稳态值, CGC作用消失, VGE以较快的上升率达到最大值。为了降低此效应, 应该使栅极驱动源的内阻足够小, 增加流经CGC的电流, 加快开通速度[4,5,6]。
关断时, 同样由于密勒电容的效应, 当VCE上升的过程中, VGE有一段近似恒定的时间, 影响关断的过程。另外, 由于IGBT是双极性器件, 在关断过程中有一个少子复合过程, 造成关断时的拖尾电流, 这是IGBT和MOSFET开关最大的不同点, 这也是影响IGBT工作频率的最主要原因。
1.2 IGBT驱动电路的要求
1.2.1 开通正栅压
IGBT静态特性曲线示意图, 如图3所示。IGBT正栅压VGE越大, 导通电阻越低, 损耗越小。但是, 如果VGE过大, 一旦IGBT过流, 会造成内部寄生晶闸管的静态擎柱效应, 引起IGBT失效。相反, 如果VGE过小, 可能会使IGBT的工作点落入线性放大区, 最终导致器件的过热损坏, 比较理想的IGBT驱动电压范围是12 V<VGE<18 V。
1.2.2 关断栅压选择
IGBT的关断过程可能会承受很大的dv/dt, 伴随关断浪涌电流, 干扰栅极的关断电压, 可能造成器件的误开通。为提高驱动电路的抗干扰能力, 在关断时栅极应加上适当的负偏压, 一般取为-10 V<VGE<-5 V。
1.2.3 栅极串联电阻Rg的选择
从IGBT的开关特性的分析可以看出, Rg直接影响IGBT的工作情况。为提高开关频率, Rg取值应该尽量小。但如果Rg取值过小, 会导致栅、射极之间的充放电时间常数小, 开通瞬间电流较大, 从而损坏IGBT;若Rg取值过大, 虽然在抑制dv/dt方面很有效果, 但增加了IGBT的开关时间和开关损耗, 严重影响IGBT的性能和工作状态。Rg的取值大概是十几欧到几百欧之间, 具体取值根据应用的实际情况选取最佳值。
2 驱动电路的保护
2.1 过流保护
2.1.1 过电流损坏原因
IGBT内部有寄生晶闸管, 在规定漏极电流范围内, 其产生的正偏压不足以使晶体管导通, 当漏极电流大到一定程度, 正偏压足以使晶体管导通, 进而使寄生晶闸管开通, 栅极失去控制, 发生擎柱效应。此时关断无效, 集电极电流很大, 致使IGBT损坏[7,8]。当电流还未达到擎柱效应所需电流大小时, 如果IGBT运行指标超过SOA所限定的电流安全边界, 即工作在过流状态下, 其长时间过流运行会造成很高的功耗, 损坏器件。当最严重的过流情况, 即短路发生时, 电流很快达到额定电流的4～5倍, 此时必须尽快关断器件, 否则器件将很快损坏。
2.1.2 过电流的处理
根据IGBT的静态特性, 当发生过流时, VCE会随电流急剧变大, 则可以通过检测VCE的大小来判断是否过流。当检测到过流发生时, 首先采取降栅压措施, 从图3的静态特性曲线可知, 栅压降低以后, 电流显著减小。这样一方面可以保护器件, 另一方面如果确定是短路需要关闭器件时, 不用在相当大电流的基础上执行关断, 反而引入di/dt。当降栅压运行一段时间后 (一般是10 μs) , 如果电流恢复正常, 可以再加上正常的栅压, 这样可以有效避免假过流造成的误保护。但如果电流仍然处于过流的状态, 则判断是短路故障, 应该马上对IGBT进行关断。此时, 绝对不能快速关断, 因为短路时电流非常大, 直接关断会在线路寄生电感上产生很大的电压, 进而损坏器件, 而应该保证电流变化率不会过大, 让栅极电压缓慢降低关断器件[9,10]。
2.2 栅极过压的保护
2.2.1 栅极过压原因
IGBT大多是工作于感性负载状态, 当其处于关断状态, 而反并二极管正在反向恢复过程时, 就会有很大的dv/dt加于C、E两端。由于密勒电容的存在, 该dv/dt将在电容上产生瞬间电流, 流向栅极驱动电路。该电流与Rg作用, 如果Rg值偏大, 使Vge超过IGBT开通门限电压值, 器件就会被误触发导通。
2.2.2 栅极过压处理
在栅射间并接入一个栅射电阻可以解决栅极过压的问题。另外, 为了防止栅极驱动电路出现高压尖峰, 本研究在栅射间并接2只反向串联的稳压二极管, 其稳压值与正、负栅压相同。这样可以保证栅射电压的稳定, 并且能有效地将密勒电容产生的电流通过栅射电阻释放, 达到栅极过压保护的目的。
3 电路设计
3.1 电路说明
驱动电路原理图, 如图4所示。整个驱动端电路采用6N137光耦隔离, 单电源供电, 通过一个5 V的稳压管D5完成0 V和-5 V之间的转换, 并用一个电源实现了正负电源的功能。图4中, D6、D7、R2构成栅极过压保护电路, D3、D4是快恢二极管, D1、D2是稳压值不同的齐纳稳压管。
3.1.1 正常工作时
驱动信号通过光耦送入驱动电路, 通过RS触发器的置位引脚启动电路。开通时, 两个过流保护的延时电路电容C1、C2开始充电, 此时推挽电路也将Vg提高到正栅压, IGBT导通, VCE很快下降为导通压降, 当C1、C2电压高于VCE时, D3、D4导通, C1、C2电压被钳位, 不再上升, 也就不会将D1、D2击穿, 电路正常工作。关断时, C3已经被充电, 与C3串联的二极管截止, 推挽电路输出低电平, 由于D5的原因, 栅压变为-5 V, 将IGBT关断。
正常工作时最重要的是C1、C2及其充电电阻的选择, 时间常数不能太小, 否则会在IGBT开通前将D1、D2击穿进入过流保护状态, 也不能过大, 否则在过流时会因为动作时间过长而损坏器件。
3.1.2 过流降栅压运行
一但IGBT过流, VCE急剧上升, 超过了C1、C2的钳位电压, D3、D4反向阻断, C1、C2开始充电, 当C1的电压高于D1的击穿电压 (D1击穿电压低于D2) 时, D1反向击穿, T1导通, 与T1串联的稳压管投入电路工作, 将此时的栅压降低, 实现降压运行。
3.1.3 短路缓慢关断
控制C2电压上升和D2击穿电压之间的关系, 调整D1、D2相继击穿的时间差约为10 μs, 如果10 μs内电流恢复正常, 那VCE会再降低, D3又导通, C1、C2电压钳位到低电平, 恢复正常工作。而如果是短路发生, C2的电压会持续上升, 直至击穿D2, 导通T2, C3马上通过R1和T2放电, 栅压开始缓慢降低, 降低的速率由C3和R1的时间常数决定, 当C3的电压降低到低电平时, 改变RS触发器状态, 将6N137封锁, 输出低电平, 完全关断IGBT, 从而实现短路时栅极电压的缓慢降低, 并缓慢关断IGBT。
该过程中最关键的是两个保护电路的延时电路参数的选取。具体IGBT的保护时间设置有很多选择, 可以改变电阻电容的组合, 也可以改变稳压管的击穿电压。
3.2 短路保护实验
试验电路, 如图5所示。先将电容充电, 然后启动驱动电路, 可以观察短路保护时的波形, 如图6所示。
由图6可见, 向驱动电路发出启动信号后, RS触发器输出反向, 栅极电压上升到开通电压, 而VCE由于电容通过IGBT放电, 电压猛降, 此时, IGBT中流过的电流相当大, 处于过流的状态, 经过大概10 μs的时间, 保护电路开始作用, IGBT进入降压运行阶段, 从图中看出, 此时从IGBT流过的电流已经明显减小, 从电阻流入的电流已经将电容的电压又补充回去, 但此时的电流仍然很大, 故再经过大约10 μs的时间, 电路进入关断阶段, 栅极电压开始以一定的斜率下降, 趋势很平缓, 当栅极电压降到逻辑低的电压值时, 触发器状态变化, 驱动电路封锁, 此时如果要重新开启电路, 需要再给出启动信号。
从短路测试中可以看出, 在过流的时候该电路能够有效地完成降压运行和缓慢关断的任务, 为IGBT的正常工作提供保障。
4 结束语
该驱动电路具有隔离驱动、过流保护、过栅压保护等特点。如果希望电路能正常工作, 重要元件的参数需要认真选择, 特别是Rg值的选取, 在电路上可对Rg部分进行改进, 利用二极管分别在开通和关断时得到不同Rg值。另外, 该驱动电路只能对过流和栅极过压起保护作用, 对VCE的过压保护需要在主电路中加入缓冲保护电路, 才能保证器件的可靠工作。
摘要：在分析了绝缘栅双极性晶体管 (IGBT) 动态开关特性和过流状态下的电气特性的基础上, 对常规的IGBT推挽驱动电路进行了改进, 得到了具有良好过流保护特性的IGBT驱动电路。实践应用证明该电路结构简单, 使用可靠, 易于操作, 配合数字信号处理器 (DSP) 等控制芯片能达到很好的驱动效果。
关键词：绝缘栅双极性晶体管,开关特性,数字信号处理器,过流保护,场效应晶体管
参考文献
[1]林渭勋.现代电力电子电路[M].杭州:浙江大学出版社, 2002.
[2]华伟, 周文定.现代电力电子器件及其应用[M].北京:北方交通大学出版社, 2002.
[3]BISWAS S K, BASAKB, RAJASHEKARAKS.AModularGate Drive Circuit For Insulated Gate Bipolar Transistors[C]//Conference Record of IEEE IAS 1991.Dearborn:[s.n.], 1991:1490-1496.
[4]SHIMIZU Y, NAKANO Y, KONO Y, et al.A High per-formance intelligent IGBTwith overcurrent protection[C]//Proceedings of ISPSD 1994:[s.n.], 1994:37-41.
[5]王永, 沈颂华.一种简单的IGBT驱动和过流保护电路[J].电测与仪表, 2004, 41 (4) :25-27.
[6]倪红军, 李明, 赵绍刚.三电平逆变器IGBT驱动和保护电路的实现[J].电子设计应用, 2004 (4) :75-77.
[7]盛祖权, 张立.IGBT模块驱动及保护技术[J].电焊机, 2000, 6 (4) :4-8.
[8]李明.IGBT特性曲线解读[J].电焊机, 2000, 30 (11) :21-25.
[9]王正仕, 徐德鸿.一种IGBT的实用驱动电路[J].电气传动, 1999, 29 (6) :54-55.
浅析测试驱动开发 第2篇
1.1 定义
测试驱动开发(Test Driven Development,TDD)是由极限编程之父Kent Beck提出的一种面向对象的开发方法[1]。区别于传统的软件开发模式,测试先行将更重视测试在整个软件开发过程中的作用并促进项目的进行。它要求先完成测试代码,然后编写功能代码,并且功能代码要以通过测试代码为标准,然后对功能代码重构,重构之后再运行测试并要通过测试[2]。它的一个开发周期比较短,整个项目是多个周期的迭代。这种开发方式有效的提高了软件质量和开发效率[3]。目前,TDD已经被很多公司和开发团队接受并用于实践。
1.2 优点
由于测试先行,因此写代码前就应该有明确的需求,并体现在测试用例中。在交付前,测试用例可以用来描述功能需求并替代部分文档。并且以测试用例描述的需求不容易出现模糊不清的概念,因为测试结果只会是True或False。这解决了开发人员在开发时误解或由于沟通问题不完全理解需求文档而造成开发到一定程度后才发现代码与需求有偏差。但这还没有解决对客户的误解或与客户沟通不畅导致需求分析错误的问题。
功能代码编写完成后必须通过所有测试,这就保证了这部分代码是满足其功能要求的。通过确保每小部分代码的质量,可以较快的叠加成更复杂的功能且保证最后交付的软件与设计的要求是一致的。在对功能代码进行优化时,因为也要通过测试用例,所以能保证这部分代码的改动不会对调用它的其他模块有影响。
1.3 适用环境
尽管从理论上讲TDD可以在各种软件开发项目中使用,但是在某些项目上可能感觉不到比较明显的效率提升或质量提高。
TDD是面向对象的开发方式,如果项目不使用面向对象的设计和开发,则不适合使用TDD。
GUI等难以进行单元测试或进行测试比较麻烦的部分也不适宜使用TDD的开发方式。因为TDD是以测试驱动的,虽然测试是软件交付内容的一部分,但是如果测试部分的难度大于软件功能的开发,且消耗更多的时间,那么就无法再提高整个项目的开发效率。
TDD还对设计有很高的要求。设计的结果直接影响到测试用例,如果测试用例没有被很好的设计,会严重影响软件的开发。
2 应用
2.1 开发流程
2.1.1 设计
在各种开发方式中,设计都是非常重要的一个环节,它在很大程度上影响了软件开发的难度、质量。在传统的软件设计方法中,需求分析的结果通常以文档、UML图、伪代码等方式表示出来。在TDD中,一般可以使用测试用例来表示各个模块的功能说明。测试用例可以明确地表示每个功能模块要完成的功能和期望得到的结果,且不容易产生误解。
设计单元测试用例时,一个比较难以把握的问题是测试用例的粒度。如果粒度太粗,可能会导致模块内实现的功能过多、难以测试等问题,并没有达到TDD的效果。TDD一般提倡小步前进。但也不能太细。粒度太细可能导致测试用例数量过多、维护测试用例过于麻烦。
2.1.2 创建测试用例
设计完测试用例以后,要实现测试用例。测试用例将保证功能代码完成了设计的功能。在没有写功能代码前,测试用例应该是无法通过的,因为需要完成的功能没有完成。
测试用例还在一定程度上起到了文档的作用。在TDD的开发方式中,测试用例可以说明某个功能模块要完成的功能和它具有的接口。测试用例对于功能代码的测试相当于黑盒测试,不用了解模块内部的实现,只管它是否满足需求。对于模块内部要完成的功能,一般不写测试用例。如要进行模块内部的测试可以通过开发工具的调试功能来完成。测试用例主要测试模块的功能。
2.1.3 编写功能代码
TDD的通常做法是测试代码未编写完成前是不写功能代码的,并且测试代码写完后是无法通过测试的。此时需要编写功能代码通过测试代码。值得注意的是,功能代码并不是越复杂越完善越好。最好的做法是所写的功能代码刚好通过所有测试用例。
编写完代码后要运行所有测试用例并保证全部通过。如果没有全部通过,就要对代码进行修改,直到通过所有测试。不应该在测试没有全部通过的情况下去编写其它代码。
2.1.4 重构
常有人质疑TDD开发方式所开发的软件质量。由于TDD在编写功能代码时只注重于快速完成代码并通过所有测试,并没有对代码的质量进行检验,所以这里面的代码质量无法得到保证。这样的质疑并不是没有道理。但是TDD的开发方式中也有比较重要的一个环节,重构。
在面向对象的开发方式中,几乎都会比较重视重构。它能提高代码的质量,利于以后对代码的修改和维护。采用TDD的开发方式也应该有重构。重构不应该修改与外部的接口而应该重点优化内部实现的代码。TDD有测试来验证重构后的代码不会影响外部接口。
在进行代码修改以后,要重新运行所有测试,并保证全部通过。重构不是一次就能完成的,可能会多次进行,并在以后对项目进行修改的时候进行。这一步常被很多开发者忽略,因为重构不增加新的功能,在运行时可能不会有明显的感觉。但对于提高代码质量非常有帮助。无论是否使用TDD都应该重视重构。
2.1.5 交付和部署
当程序代码编写完成,并通过各种测试以后,软件已经完成了客户需要的功能。由于TDD在开发过程中用测试用例代替了部分需求说明文档和规格文档,省去了前期需求变化的过程中修改文档的麻烦。在交付时可能需要补齐文档。
今后如果需要对软件进行修改,也只需要重复上述步骤。但也要保证所写的代码尽量简单,测试覆盖率要高,功能代码需要通过全部测试。
2.2 应对需求变化
敏捷软件开发是要能够快速应对需求变化的。TDD作为极限编程中倡导的软件开发方法也应该能够快速应对需求变化。
除了敏捷软件开发中要求的开发人员互相信任、经常面对面讨论等要求可以快速响应需求变化外。当使用TDD时,如果需求发生变化,则要设计和修改测试代码以反应需求的变化。当测试代码改变后,可以根据运行测试后的结果快速的发现哪些模块需要更改。只要修改代码使测试通过就可以了,而不用担心是不是又有其它地方出现了bug。TDD一个很大的好处也就是开发人员有明确的目标,代码可以马上进行测试并保证完成想要达到的功能,并通过测试覆盖率了解到是否有多余的代码。
2.3 工具
2.3.1 JUnit
JUnit是一个开源的测试框架,主要是用来对Java程序进行自动化单元测试的[4]。它能很好地集成在Eclipse中对代码进行测试。它的主要功能有对测试结果断言、共享测试数据、运行测试。
JUnit是x Unit中的一个,其它类似的还有NUnit用于测试.NET代码,Cpp Unit测试C++代码。
2.3.2 Easy Mock
Easy Mock是一个开源的生成Mock对象的工具,可以隔离测试对象与其它辅助的对象。它可以模拟出一个对象并记录它期望进行的行为和结果。在回放状态调用它以进行测试。还可以对Mock的对象进行验证。
3 结束语
本文介绍了测试驱动开发的一些特点和实现过程,并介绍了相关工具。通过与持续集成等其它敏捷软件开发工具和技术结合,可以较好地应对需求变化、及时发现问题并保证软件质量。
摘要：测试驱动开发是一种用于敏捷软件开发的开发过程,可以快速应对需求变化。它要求先设计和编写测试代码,然后编写功能代码通过所有测试,再重构以提高代码质量。文章将先介绍测试驱动开发的优点、使用环境,然后介绍开发过程,最后介绍相关工具。
关键词：测试,TDD,敏捷开发
参考文献
[1]陈立群.测试驱动开发在J2EE项目中的全程实践[J].计算机工程与科学,2008,30(4):86-88.
[2]侯典荟.基于.NET环境测试驱动开发研究与应用[D].大连理工大学,2006.
[3]Janzen D S,Saiedian H.On the influence of test-driven development on software design[C].Turtle Bay,HI,United states:Institute of Electrical and Electronics Engineers Inc,2006.
软件故障模型驱动软件测试 第3篇
1 软件故障与软件测试
蔡开元先生对软件失效机理进行了如下描述:软件错误是一种人为错误, 一个软件错误必定会产生一个或多个软件缺陷;当一个软件缺陷被激活时, 便产生一个软件故障。同一个软件缺陷在不同条件下被激活, 可能产生不同的软件故障;软件故障如果没有及时的容错处理, 便不可避免的导致软件失效, 同一个软件故障在不同条件下可能产生不同的软件失效。这样的复杂关系如图1所示。
图1可以很好地说明软件故障产生与测试的复杂性, 软件功能层面的失效往往是由各种特定的条件和环境决定的, 存在必然的复杂性和多样性。而测试虽然能从软件的不同层次开展测试, 但如果不能从问题的根源处着手, 要测试出全部问题是不可能的, 这也导致了测试再充分也不能保证测试后的软件没有问题。同样地, 我们也能看出, 如果从问题产生的根源出发开展软件的测试, 是可以将后续环境中无穷发散的问题解决的。这无疑是改善测试不确定性和盲目性的一个有效办法。
2 用软件故障模型驱动软件测试
软件故障模型 (SFMEA) 从发生的软件错误入手探究和分析导致软件故障模型, 是寻找软件问题产生的根源的一种有效方法, 是软件测试的基础。这里以成熟的动态内存故障模型为例阐述利用故障模型来驱动软件测试的方法。
2.1 动态内存故障分析
(1) 动态内存是一个自由存储区域, 编程人员根据需要, 利用编程语言提供的动态内存管理命令, 进行动态内存的分配、访问、回收等操作。各类操作后的结果与该内存区域当前所处状态紧密相关, 由此产生了动态内存使用过程中的各类问题, 在分析导致其错误的原因的基础上, 可以建立动态内存故障模型。如图2所示。
Start表示开始状态;Memory Allocate表示对内存进行动态内存分配, 若没有足够的动态内存, 则内存指针为N ULL;Ch ec k Memory检查动态内存分配的结果, 以保证后续动态内存操作的正确性;Access Memory表示对动态内存中的内容进行写、读、修改等操作;Free Memory表示动态内存操作结束, 进行动态内存的释放;End表示结束状态;
(2) 动态内存的四个核心操作缺一不可, 且在不同状态下操作也有约束, 由此导致了诸多与动态内存使用相关的问题, 如图3所示。
图3中的连线表示了引起动态管理错误出现的几种操作, 箭尾表示当前的动态内存管理状态, 箭头表示在当前状态下的操作请求, 将引起动态内存错误产生的操作请求进行分类, 可分为如下几类:1) Memory allocate操作请求引起的错误, 在图中, 6, 5, 7表示了与动态内存分配操作请求有关的错误。2) Check memory操作请求引起的错误, 图中连线10表示了动态内存检测操作有关的错误。导致错误发生的原因是在动态内存释放之后, 又对动态内存进行检测 (试图重新使用已回收的动态内存) 。3) Accessmemory操作请求有关的错误。在图中, 3、9表示了由内存访问引起的错误。导致该错误出现的原因有两个, 3表示在动态内存访问之前未进行指针P的检测, 本文将这种错误定义为空指针引用, 操作9表示在动态内存释放之后, 重新进行动态内存的访问, 从而造成动态内存的未分配使用错误。4) Freememory操作请求引起的错误, 1, 11表示了由动态内存回收操作引起的错误, 1表示没有进行动态内存的分配而进行动态内存的释放, 11表示在对指针变量P进行了动态内存的释放之后, 重新进行释放工作, 这两种情况是等价的, 即在没有可以用的动态内存的情况下, 尝试使用动态内存空间, 产生了动态内存未分配使用错误。5) 与end有关的错误。在图中, 2, 6, 8表示在程序结束阶段出现的错误, 导致错误产生的原因是在进行了动态内存的分配、检测或访问之后, 没有进行动态内存的释放, 因此, 造成了内存泄露的问题。
以上就是动态内存故障模型分析的核心部分, 这样的故障模型能从问题产生的根源出发阐述软件缺陷发生的机制, 为软件测试提供了一个寻求有效测试方法的窗口。
2.2 故障模型驱动软件测试
(1) 在有了软件故障模型之后, 在软件测试时即可针对这类故障的根源开展测试, 做到有的放矢, 达到通过测试将该类软件问题从程序中剔除的目的。动态内存故障模型从动态内存故障产生机理开展分析, 切入软件代码编写的最初级过程, 我们这里以C语言为例阐述利用动态内存故障模型驱动软件测试的过程。C语言中与动态内存管理相关的操作有几类, 可以分别与动态内存管理的四个阶段对应:1) 动态内存分配类操作:如malloc;calloc;realloc等动态内存分配类函数。2) 动态内存检测类操作:内存指针检测if (p!=NULL) , 动态内存初始化memset等操作。3) 动态内存读写访问类操作:各种动态内存空间赋值、引用、函数间的调用等, 都可能形成动态内存的读写操作。4) 动态内存释放类操作:如free等内存释放函数。
(2) 与故障模型进行对应之后 (见图4) , 即可开展软件测试工作, 最简单的方式就是采用人工走查代码的方式进行, 这类方法对程序结构简单、规模不大的程序还是很有效的, 可通过同行评审等方式开展, 能很快排除与动态内存故障模型相关的软件错误, 进而达到根除该类软件错误的目标。
(3) 软件系统高速发展的今天, 小规模、结构简单的程序越来越少, 动态内存管理越来越复杂, 通过简单的人工代码走查方式明显跟不上时代的发展, 随之各类软件测试工具供应商推出了多种软件测试工具来解决这种大规模复杂情况下的软件代码故障检测问题。比如klockwork、C++Test等等, 成为了帮助软件开发、测试人员发现并解决软件问题的有力工具, 其核心也是依据不同软件故障模型对程序代码进行检测, 提供明确的软件故障指示。针对动态内存管理故障模型, 检测软件一般通过数据流分析、制定检测规则、软件故障检测三个过程来检测问题。1) 数据流分析:程序中的数据流分析可以描述出程序的结构流程, 变量间的定值与引用关系, 为故障检测提供有力支撑, 主要方法有到达-定值数据流分析法和活跃变量数据流分析法。2) 制定检测规则:在数据流分析的基础上, 通过抽象命名, 把规则涉及实体进行命名, 再依据软件故障模型制定工具检测遵循的规则, 并将规则转化为方便工具自动处理的“语言”。3) 软件故障检测:在数据流分析和检测规则的基础上, 完成对软件特定故障的检测, 并提供个性化的展示、统计和分析能力。
综上所述, 在软件故障模型成熟之后, 据此开展更有效的软件测试活动是可行的, 也为软件自动化测试工具设计提供了依据。使用软件故障模型驱动软件测试可以按如图5所示流程开展。
首先在故障模型研究的基础上, 对需测试的对象按照故障模型进行实例化, 完成由模型向具体问题的转化;然后对模型实例进行分析, 研究发掘更优更有效的测试方法, 并用测试方法对对象进行测试确认, 不断循环分析和方法优化的过程, 直至找最适合的方法;用寻找到的方法对一类问题进行普适性确认, 因为故障模型本身就是从众多实例中抽象提炼出来的模型, 因此普适性验证重点关注方法的效率和重用度;对于重用度高, 通过工具可以大幅提高效率的方法还可设计自动化测试工具对方法进行固化。
3 结语
现代信息技术的不断发展, 软件应用已经无处不在, 通过软件故障模型来指导软件测试是提高软件可靠性的一个有效办法, 其核心是不断地总结提炼科学有效的软件故障模型, 在应用场景和方式也日趋复杂的今天形成准确的软件故障模型是件不容易的事情, 特别是从覆盖度上要能让软件故障模型覆盖所有的软件故障更是困难, 即便如此, 发掘和提炼软件故障模型仍然是值得的, 可以让测试更有针对性, 更自信, 更有效。提炼软件故障模型需要大量的工程实践作为基础, 通过假设故障存在、反向推理、实践验证的方式进行。当前软件故障模型偏重于由软件代码层次, 对软件应用环境、模式、行业特点等方面指导系统级测试的软件故障模型还很欠缺。完善软件故障模型并应用到测试行为当中还是一个很长期的过程。
参考文献
测试仪驱动保护论文 第4篇
关键词：测试驱动开发,TDD CxxTest,原理分析
1 测试驱动开发简介
测试驱动开发 (TDD) 是一种基于循环开发的软件开发过程。遵循TDD的编程人员, 在正式进行开发之前, 通常先要确定在本阶段需要实现的改进或者新功能, 然后通过编写一系列的测试代码来检验这些改进和功能。一般情况下, 这些测试代码都会运行失败。接下去的任务便是编写能够使得这些测试通过的代码, 并且在完全通过测试后, 重构代码, 以达到生产标准。这个过程将会一直循环下去, 直到所有的改进或者功能完成。下图展示了这一过程。
2 CxxTest简介
CxxTest是专门为C++语言所开发的TDD框架。它具有不需要RTTI, 可以承载外部库, 处理异常等优点。作为一种轻量级框架, CxxTest将所有的代码都仅包含在一个头文件 (tdd.h) 中。也就是说, CxxTest框架仅需要一个现代C++编译器就可以运行测试程序, 甚至在必要时, 可以通过它捕获异常和使用GUI展示。
CxxTest作为一种轻量级的测试驱动开发框架, 其优点在于使用简单。我们通常使用已有的控制台测试启动程序来调用我们自己编写的测试用DLL。之后, 该测试程序就会对此DLL的各个注册方法进行测试, 并且最终输出结果。
3 CxxTest原理分析
3.1 测试过程
整个测试的过程大致可以分成两个部分, 第一部分是测试类的选取, 而第二部分则是具体的对我们所定义的方法的测试。图1表示的是在测试类级别上的选择, 而图2则是图1中带有“*”标记步骤的具体拓展, 表现了CxxTest测试驱动开发框架如何逐个调用测试类中的各个测试方法。为了让示意图尽可能简介, 这里没有显示出异常处理。笔者将会另辟一节叙述。
3.2 类和方法的注册
测试类和方法的包装注册是整个测试开始前的准备工作。这一步的注册将会告诉CxxTest框架, 有哪些类、其中的哪些方法需要进行测试。
整个注册过程的第一阶段是在编译阶段通过CxxTest框架自定义的宏将所有的类对象定义为全局变量。然后当系统载入我们编写的带有测试类和方法的DLL时, 首先会对全局变量进行初始化, 将所有这些经过特殊处理的测试类对象加入到队列中, 以供后续使用。
测试类的包装注册是通过TESTCLASS (CSomeClass) 宏实现的。该宏最关键的代码如下所示:
该宏首先定义了函数CSomeClass_TddNamespaceResolv er::GetNameSpace () (未在上面的代码中展示该函数细节) , 用于获取CSomeClass的带有命名空间的全称, 随后, 通过将TDD::ClassRegistrar
这里起到关键作用的是TDD::ClassRegistrar
最后, 必须指出的是, 我们真正添加进全局队列的并不是CSomeClass类对象, 而是经过包装的TDD::ClassRegistrar
第二阶段则是对测试类方法的注册。这项功能是通过TESTMETHOD (MethodName) 宏实现的。其核心代码如下 (略去次要部分) 。
这里着重解释真正做测试类注册工作的__m_MethodName_variable, 该变量在类对象的初始化过程中、类的构造函数被触发前先被初始化。
仔细观察该变量, 他属于TDD::MethodRegistrar
可见, 其构造函数仅仅是将测试方法加入队列, 而当调用MethodRegistrar::RunTest () 时, 便会真正开始进行测试。
3.3 对方法进行测试
在初始化之后, 程序便进入了入口点函数TDD::UnitTestBase::RunTests () 。该函数其实异常简单, 只是从队列中找到测试类, 然后再对每一测试类找到需要测试的方法, 调用多态方法MethodRegistrar::RunClassTests () 进行测试, 然后寻找下一个测试类, 循环如此过程。
MethodRegistrar::RunClassTests () 的主要经过正如“测试过程”一节中的图2所示, 具体对应的函数也可以通过描述简单匹配, 这里就不再赘述了。至于如何由此函数调用方法测试的执行者MethodRegistrar::RunTest () , 再由此函数调用TESTMETHOD () 宏所定义的包装函数, 最后再回到我们自己的函数的过程, 笔者将会在下一节展示。
3.4 异常处理
CxxTest的设计初衷就是为程序员提供测试框架, 以检查可能的错误。为了一方面检查错误, 另一方面在检查到错误之后让程序继续执行以运行更多测试来检查其他可能的错误, CxxTest的设计者对经典的C++异常机制进行了包装。
CxxTest使用了“模板方法”设计模式, 将所有的异常机制都封装在TryCatch类中, 该类的模板方法便是TryCatch::Execute () , 在基类中, 设计者将其设计为纯虚函数, 以后每当需要进行测试时, 都会重新定义一个类 (比如说用于做方法测试的TryCatchTest类) , 该类继承自TryCatch类, 并且重新实现Execute () 函数。最终在测试时, 框架则会调用
TryCatch::TryCatchAndReport () 函数, 该函数的代码如下所示 (略去次要代码) 。
那么CxxTest又是如何重定义Execute () 函数呢?其实, 做法很简单, 他只是简单地将Execute () 函数定义为对MethodRegistrar::RunTest () 的调用, 该函数内部又调用了在方法注册时使用的那个测试方法的包装函数, 然后由该包装函数直接调用我们所定义的测试函数 (就是在TESTMETHOD () 宏后面的代码) 。
再深一步, 根据前面的分析, 框架设计者认为, 应该在Execute () 函数中可能会抛出异常, 而该函数实际上最终调用的是我们自己所定义的代码, 那我们自己的代码一定需要定义异常嘛?其实不然, 我们完全可以利用CxxTest框架所提供的验证宏。这里我们仅针对最为常用的TDD_VERIFY (expression) 宏进行展开分析, 其他类似。该宏的关键如下所示:
其实他就是先判断expression的真假, 然后直接调用TDD::Verifier::Verify () 函数, 此函数的功能非常简单, 就是判断__tdd_b是否为假, 如果为假, 则抛出异常。关键代码如下:
4 结论
CxxTest作为一款轻量级的TDD框架, 在设计的时候充分利用了C++的各种特性, 使得其运作机制看似复杂却条例清晰。本文理出了整个CxxTest框架的运行主线, 并且对其中较为重要的部分做出了详细的解释。
参考文献
[1]Robert C.Martin著.敏捷软件开发:原则, 模式与实践[M].邓辉, 等译.清华大学出版社, 2003, 9.
[2]Test-driven development.http://en.wikipedia.org/wiki/Test-driven_development.14January2010.
控制棒驱动线圈组件电气测试 第5篇
CRDM线圈是形成AP1000核电站正常运行的重要部件, 为确保在IHP在安装后达到使用和验收要求, 需对CRDM线圈以及电缆进行电气测试。
在IHP组件中, CRDM包括线圈组件、电气导管和快速插头等组成线圈部分由内部的提升用线圈 (lift coil) 、插入用线圈 (movable coil) 、静止用线圈 (stationary coil) , 以及外部不锈钢外壳和电缆导管等组成。见图1和附件1。
CRDM线圈电气测试为验证性试验, 用来检查组件在运输过程中和安装前存储时是否有损坏, 影响驱动机构的正常使用。电气试验主要分为极性检查、直流电阻测量、绝缘耐压试验。
1 极性检查
目的:确保棒控驱动机构各线圈的安装方向和CRDM导线引线的正确性。
测试器具:直流电源、双极开关、毫安表两个、导磁棒、导线若干。
测试原理:极性测试采用在提升用线圈上施加一个开关电源, 通过静止用线圈和插入用线圈的磁场产生变化, 从而在静止用线圈和插入用线圈回路产生电流, 串联在回路中的指示毫安表偏转。
测试方法:
将导磁链放入CRDM线圈组件内部, 根据上图进行接线。
对电源的电压和电流输出进行设定, 避免通过线圈的电流过大或电压过高, 将输出电源设置最大输出电压和输出电流。选用电流表量程时, 静止用线圈使用的电流表选择较小量程, 插入用线圈使用的电流表选择较大量程。
极性判定:确保测试接线正确情况下, 在开关接通瞬间, 电流表都正向偏转, 则CRDM线圈的极性正确;反之, 则极性错误。
注意事项:由于线圈安装由上往下分别是提升用线圈、插入用线圈和静止用线圈, 由于距离提升用线圈的距离不同, 在试验时, 通过插入用线圈的感应电流要比通过静止用线圈的感应电流大。在选用电流表的量程时需注意, 量程选用太大测试指针偏转不明显, 效果不理想;量程选用太小, 容易损坏电流表。
使用回路感应电流方法进行极性检查时, 要确保测试回路是连通且接线端子接线正确;如果选用感应电压法, 要确保测试回路处于断路。
可能存在的问题和解决方法:测试显示电流表指针偏转不一致或负向偏转, 检查接线是否正确, 如果接线正确, 则判断为极性检查不合格。如果导线引线错误, 可以通过重新端接线圈的引线;如果线圈安装错误, 可以通过调整线圈。
2 直流电阻检查
目的:验证线圈的连续性和检查线圈绕组是否有短路现象。
测试器具:万用表, 导线若干。
测试方法:使用二线电阻测量法进行测量;
线圈的电阻随温度变化而变化, 其中电阻与温度的关系如下:
TREF指的是所选择的标准温度 (即25°C) ;
TAMB指的是线圈所在的环境温度;
RREF指的是25°C下的校正电阻;
RAMB指的是计算出的电阻;
使用上述公式时, TREF和TAMB的温度必须为
用在上面公式中的25°C下的线圈电阻值如下:
所测得的电阻值应位于计算出的最小RAMB和最大的RAMB范围内。
注意事项:在测试时, 保证试验用快速插头和CRDM组件连接牢固, 测试导线和被检测电缆接触充分且牢固, 并且保证测试器具和被测部件静止;测试的环境保证不凝露, 相对稳定环境温度中对CRDM组件进行测试。
可能存在的问题和解决方法:万用表指示数值不稳定, 应检查测试导线与被测部件连接处是否牢固和是否有剧烈的抖动;万用表指示数值超差, 应先排除环境温度变化过快的因素, 被测CRDM线圈组件温度远低于或远高于温度计放置的环境温度, 都会产生此变化。
3 绝缘电阻的检查
目的:验证线圈的绝缘是否满足生产需求和排除漏电现象;
测试器具:绝缘兆欧表, 导线若干;
测试方法:使用绝缘兆欧表进行绝缘试验;
附件1:
每个磁性线圈组件要进行6次试验, 分别验证线圈之间、线圈与线圈组件的金属外壳。测试时间为60秒, 或直至兆欧表稳定。
注意事项:在进行绝缘试验时, 为保证测试数据准确和人员安全, 线圈组件的外壳应有可靠接地, 可以使用黄绿绝缘单芯导线与大地地连接。测试完成后, 使用接地线分别碰触测试部件, 对施加电压的线圈进行充分放电。由于绝缘值要求高, 绝缘兆欧表的选择时, 应选用能够显示较大数值的仪表。
测试仪驱动保护论文 第6篇
1 测试驱动开发
测试驱动开发的理念强调把测试作为开发过程的一个重要部分, 在软件开发的每一个阶段, 都有一部分的设计和代码是专门给测试使用的。甚至在代码开始编写之前, 测试用例就已经设计好了。将测试方案作为编码的准绳, 从测试的角度验证设计, 推导设计, 指导编码。实时验证系统的准确性。下面具体结合状态图, 介绍一个企业通信系统的测试驱动开发过程。
2 状态图模型和状态图中的变迁约束规则
2.1 状态图定义
状态图形式化地表示为一个五元组K〈S, ∑, T, S0, F〉, 其具体含义可参见文献[3]。
2.2 基于前后事件约束规则CSPE:
基于前后事件约束规则:CSPE约束 (Constrains on Succeeding and Preceding Events) , 用于限制在某一事件后发生其它事件的可能性, 它规定了前后事件之间的依赖关系, 但是忽略了程序运行时的具体状态。它的定义与规则参见文献。
2.3 基于状态图的前后事件约束规则S-CSPE:
基于状态图的前后事件约束规则S-CSPE (statechart-CSPE) , 是对CSPE的一种有效的扩展, 它将事件约束限制在状态的控制之下, 并且引入了超态的概念。使得对前后事件约束的依赖关系描述的更加准确, 并且增加了测试用例的可执行性。
t1∈T (S1) , t2∈T (S2) , 其中α、β、γ为任一变迁序列, β、γ满足:如果t’∈β、γ, 则t’/∈T (S1) ∪T (S2) 。
规则定义D (C) :n’[t1;t2]C (C≠FALSE) 该规则含义:如果α.t1是有效前缀序列, 则必存在使C为真的β, 使得α.t1.β.t2为有效前缀序列;且对于任意t (t∈T (S2) ) , 任一使C为真的γ都使得α.t1.γ.t为无效前缀序列。
规则定义E (C) :a’[t1;t2]C (C≠FALSE) 该规则含义:如果α.t1是有效前缀序列, 则必存在使C为真的β, 使得α.t1.β.t2为有效前缀序列;且对于某一t (t∈T (S2) ) , 必存在使C为真的γ, 使得α.t1.γ.t为有效前缀序列。
规则定义F (C) :_’[t1;t2]C (C≠FALSE) 该规则含义:如果α.t1是有效前缀序列, 则对任一在使C为真的β都使得α.t1.β.t2为无效前缀序列。
3 关于测试路径覆盖标准的定义
3.1 测试路径的定义
D (t) :变量V的集合, V出现在变迁t的赋值语句的左侧或者输入语句部分。
C_USE (t) :变量V的集合, V出现在变迁t的赋值语句的右侧或者输出语句部分。
P_USE (t) :变量V的集合, V出现在变迁t的谓语表达式中。
清晰定义路径 (D_Clear PATH) :路径 (ti, t1, , tm, tj) (m≥0) , 如果V/∈D (nl) (l=1, , m) , 那么满足该条件的路径为的清晰定义路径 (从ti到tj) 。
完全路径 (COMPLETEPATH) :一条满足约束集R的路径, 其初始节点是组合初态, 终节点是可接受组合终态。
3.2 基于状态图的前后事件约束规则 (S-CSPE) 的路径覆盖标准:
P是状态图S的完全路径集合, R是S的基于状态图的前后事件约束集:
all-D_CLEAR PATHs标准:对每一个变迁t的每一个V, V∈D (t) , P包含每一条关于V的D_CLEAR PATH。
4 测试用例实际生成研究
4.1 实例:
企业通信软件中一组通信模块的状态图 (图1) 表述
4.2 关于D_CLEAR PATH (清晰定义路径) 的生成
t11到t12的部分D_CLEAR PATH, 表1。
4.3 关于Complete Path (完全路径) 的生成
覆盖D_CLEAR PATH:t11 t3 t4 t12的部分完全路径集, 表2。
5 使用S-CSPE约束的优势
基于状态图的前后事件约束规则S-CSPE约束的D-use路径覆盖策略要求完全路径集必须覆盖所有的D_CLEAR PATH, 这保证了该D_CLEAR PATH将覆盖所有变迁, 这比基于前后事件约束规则CSPE有更强的路径覆盖能力, 而且该覆盖标准更方便实现TDD, 使测试用例自动生成。
6 结论
本文讨论的基于TDD结合状态图的测试方法兼顾了测试路径的覆盖力和测试用例爆炸的问题, 在保证一定覆盖能力的情况下, 避免了过多无效测试用例的产生, 从而提高了测试用例生成的效率。在公司一个Scrum小组实践应用, 产品发布周期缩短了10%, 而且客户bug反馈降低了50%。
摘要：介绍测试驱动开发 (TDD) 并结合状态图进行测试路径生成, 在避免了测试路径过多的情况下保证了测试路径的覆盖率。
关键词：TDD,状态图,路径覆盖策略
参考文献
[1]测试驱动开发 (美) Kent Beck著[M].北京:中国电力出版社, 2003.
[2]Robert V.Binder.面向对象系统的测试[M].北京:电子工业出版社, 2001.
[3]乔木, 曾一, 林宏.状态图的并发状态约束及测试用例生成研究[J].计算机工程与应用, 2004.
测试仪驱动保护论文 第7篇
软件测试是软件质量保证的重要手段。随着研发理念和技术的不断发展, 软件测试分层、测试自动化以及持续集成对测试效率的提升和软件质量的保证具有越来越重要的意义。自动化框架也先后经历了第一代的“录制-回放”、第二代的脚本技术、第三代的基于数据驱动到第四代的关键字驱动技术。
对于Java类的软件测试, 测试框架Junit对单元测试提供了较好的支持, 并且集成开发工具Eclipse提供了插件支持。Junit的出现, 大大提升了Java开发者编写单元测试用例的效率。但Junit测试框架对于系统测试、集成测试则存在一定的局限性。此外, Junit中的用例不能有任何参数。为绕过此限制, 测试人员常用的方法是测试类在构造方法中对参数赋值, 然后再传递给测试方法。另一种方法是在每个测试方法中单独构造参数, 对于参数组合的情形, 则会使测试用例数量以参数组合量级增长, 而且测试逻辑和测试数据混合, 不利于编写和维护。
作为下一代测试技术的Test NG, 兼容了Junit并支持系统测试和集成测试, 并且提供了两种方式支持传递参数给测试方法。传参的思想分别是采用XML文件配置参数 (testing.xml) 和Java注解的方式构造对象。前者仅支持基本数据类型的参数, 后者则需要采用编码方式获取需要的参数, 用例和数据不能实现较好的分离。
针对于Test NG对于复杂参数管理的局限性, 我们提出了一种基于XML的参数化方式, 通过解析XML文件提供的参数获取Data Provider参数, 使得Test NG可以间接使用XML格式的测试数据进行测试。为降低根据复杂对象编辑XML文件的复杂性, 我们根据对象自动生成默认的XML参数文件, 提供了模板支持。另外, 对于期望值和结果值的比较, 又基于XMLUnit进行了扩展, 实现了两个XML的灵活比较。
2 基于XML的Test NG的自动化测试设计
首先分析了Test NG当前构造参数存在的不足, 给出基于XML的参数结构, 为降低测试人员编写XML的工作量, 提升测试效率, 自动生成XML文件模板, 最后给出XML文件的解析算法和XML文件的结果比较方法, 并辅以实例进行说明。
2.1 Test NG用例传递参数的思想
基于Test NG的测试类中至少包含一个参数构造方法和一个测试方法, 此外, 为做必要的准备或清理工作, 测试类可借助Annotation注解添加辅助方法, 常用的注解有Before Class、Before Method、After Class、After Method、Before Test和After Test。其详细的说明, 见Test NG的参考文档[4]。
Test NG用例的执行对于参数的构造和传递有两种方法。第一种方式是, 在testng.xml文件中定义简单的参数, 然后在源代码文件中引用这些参数。如图1左, 用例login方法具有参数username, password和expected, 方法参数的来源由Parameters映射到testng.xml文件中。第二种方式是, 在源代码文件中定义参数, 然后测试用例通过data Provider属性来建立映射关系, 如图1右。从以上两种获取参数的方式可以看出, 前者易于修改, 不需要重新编译测试代码, 不足之处是testng.xml中的值只能代表基本类型, 不能是复杂类型;后者由于是Java代码, 因此支持的参数类型多样, 对象构造也比较灵活, 不足之处是要实现某些逻辑, 以返回正确的对象。
2.2 基于XML文件的参数传递
在Java类测试尤其是场景测试时, 对象的构造在用例设计时通常是复杂的, 特别是当对象中又包含层次较深的子对象时, 对象的构造将占测试用例编写的较大比例的工作量。其次, 测试类中测试用例和测试数据杂糅 (当然这里可以通过将对象构造的公共方法提取到父类中改善) , 当测试用例发生变化时, 需要修改测试代码重新编译。再者, 对于测试数据的修改, 需要测试人员具有一定的开发基础。而目前业界测试人员的分工决定了只有部分测试人员可熟练的进行Java用例的修改, 更多的测试人员则是采用GUI界面化的自动化工具进行自动化用例的编写和测试。
由此看来, 用例参数构造方式简化成了降低测试用例编写复杂度的核心。这里采用XML文件表示用例的所有参数, 包含用例执行时接口的入参外, 还有用例的期望值。XML参数文件的构造包含复杂对象和简单对象, 为区分XML类型的字符串, 引入type字段来表示类型是XML还是简单对象。XML文件编写的遵循规定的约定, 然后解析模块按照约定进行解析, 构造对象数组传递给用例, 用例执行模块则根据对象参数的维度确定用例个数, 依次执行用例, 并返回结果。
XML参数文件以data为根节点定义了指定测试类的某一测试方法的用例参数定义。其子元素case定义了用例的个数和个用例对应的参数, 各参数有name、type、catalog参数属性, 当catalog=”object”时, param添加子元素中指定了参数的具体字段。完整的XML结构见图3所示, catalog参数取值说明见表1所示。
2.3 XML参数文件的编写和生成
用例参数的编写, 对于简单数据类型, 可以直接根据xsd文件生成样例XML文件, 并在此基础上编辑完善。而对于复杂对象类型, 类型有哪些属性和对象直接相关, 通常对于类型又包括子类型的情况, 根据xsd的样例XML文件对最终的参数文件的参考意义非常有限, 并且容易出错。
为了提升测试人员编写XML文件的效率和准确性, 我们提供了默认的XML模板, 生成完整的属性并添加默认值。用户根据需要进行修改。有必要说明的是, XML模板生成和XML文件的解析需遵循如下约定:
(1) 参数name、type属性名称、类型以及顺序与用例的参数相对应。
(2) catalog取值为object时, 此时除根节点之外的复杂对象, 添加一个class属性指明了该对象的类型;当为简单数据类型时 (不含xml格式的string) 取值simple;当为xml格式的string时, catalog取值为xml。
(3) 如果是list, 各元素使用<Element></Element>包裹;如果是Map, 外层使用<Map></Map>包裹, 各元素使用<Entry></Entry>包裹。
参数文件的生成算法描述如下:
(1) 创建xml文件, 根据用例的data Provider的name属性值映射出文件名。
(2) 用例个数默认为1, 根据用例参数个数, 逐个添加元素。
(3) 参数name、type属性值与用例的参数值相对应。catalog取值参见表1所示。
(4) 关于各标签的值的生成, 简单数据类型, 按照Java生成默认值。特别的string类型直接生成“999”。复杂数据类型根据对象的类型, 遍历该类型的各属性以及子对象的属性, 对于具有父类的对象, 也会将父类继承下来的属性添加到自身。各属性依然按照简单类型来处理。特别的, string类型的XML则一般和具体的对象类型相关。我们只根据约定提供了一个根据对象转换xml的接口, 生成以后由用户自行添加。
2.4 XML参数文件的解析
文件的解析是文件生成的逆过程, 文件解析是用例读取XML参数文件的关键。没有XML文件解析为对象数组, 测试用例就获取不到数据, 因而无法触发用例执行。结合前面的约定, 我们给出参数文件的解析算法要点:
(1) 根据test用例中data Provider属性的值映射到具体的XML参数文件, 然后扫描文件中测试类下的所有用例, 循环判断各用例的校验参数个数和类型是否正确。正确则继续, 否则直接抛出异常。
(2) 依次根据参数类型进行解析对于简单数据类型, 直接读取标签值、文本值进行赋值即可;对于复杂类型, 则需要做从XML到对象的转换。 (XML到对象的转换是前面对象转XML的逆过程, 这里依然要遵循前面的约定) 。
(3) 参数转换完成以后, 赋值给对应的对象数组。然后返回对象数组。需要说明的是, 数组的维度第一个维度是由用例个数决定, 第二个维度是由参数个数决定。用例执行器根据用例的个数依次执行, 并返回直接结果。
2.5 用例结果的xml比对
对于用例结果的校验, Test NG提供了Assert接口进行支持, 其中复杂对象, 可以使用object的等于比较。在一般的测试场景中, 并非严格要求两个对象完全相同, 比如某些字段只要求实际值非空, 或者在某一范围即为实例给出说明。正确, 或者期望的xml的字段只要在实际的xml的字段中能够找到即可, 而实际xml比期望xml字段多的情形可以忽略。为此, 我们扩展了Xml Unit, 实现两个XML的比较, 对于期望值通过用例的参数传入。实际值则通过获取对象后进行转换, 然后对实际值和期望值的XML进行比较。
3 测试场景实例
在Java B/S架构软件综合实训——多用户空间项目中, 对于后台接口采用了Test NG基于XML参数的方案进行了单元测试和系统测试。以典型的用户注册接口为例说明我们的测试方案。下图中每个框图中右上角编号为 (1) 的示例是用户注册的接口定义和实现, 编号为 (2) 的示例是用户注册测试用例的相关代码。编号为 (3) 的示例是testng.xml文件的配置 (其中仅添加了用户相关的测试类) 。
4 结束语
本文介绍了test NG基于XML参数文件的测试方法, 通过对测试用例相关的参数格式的自动生成, 通过少量编辑即可完成测试数据的构造, 对于测试结果的验证, 采用了XMLUnit方式进行比较, 提高了测试数据的可读性和测试用例的易维护性, 最后经过项目
参考文献
[1]Cedrice Beust, Hani Suleiman, Next Generation Java Testing:Test NG and Advanced Concepts.[M].2007 (10) .
[2]胡骥.基于XML封装关键字的GUI自动化测试系统[J].计算机系统应用, 2015, 24 (2) :116-120.
[3]单锦辉软件测试研究进展[J].北京大学学报 (自然科学版) , 2005, 1 (41) :134-144
测试仪驱动保护论文
声明：除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
