测试驱动开发

测试驱动开发（精选8篇）

测试驱动开发 篇1

1 测试驱动开发

生产高质量产品的软件开发过程对于软件的质量和软件开发人员来说是非常重要的，一方面要开发高质量的软件产品，另一方面还要兼顾软件开发的成本、人员的效率及合理的开发进度，在软件开发方法中，极限编程提供了一个新的思想。

极限编程(eXtreme Programming,XP)是Kent Beck倡导的一种新型软件开发方法，它是一个周密而严谨的软件开发流程。它基于简单、交流、反馈、勇气的原则，在充分考虑到人的因素的前提下进行，达到客户的最大满意度。测试驱动开发是XP编程思想的一种主要实践，可以有效地让程序开发人员开发出更高品质的、经过完整测试的程序。

测试驱动开发(Test-Driven Development,TDD)是极限编程的最佳实践之一,是开发方法中的基石,也是对传统编程开发方法最不一样的地方之一。它的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能时，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。之后循环进行添加其他功能，直到完成全部功能的开发。测试驱动开发主要包括两方面：测试先行和代码重构。测试主要针对单元(最小的可测试软件元素)实施测试。它所测试的内容包括内部结构(如逻辑和数据流)以及单元的功能和可以观测的行为。测试先行一改传统开发模式中的单元测试在编写代码之后进行，而将单元测试的编写移到编写正式代码之前。重构是在不改变代码外在行为的条件下改进其内部的行为的一种软件系统改变的过程，使代码松耦合并且内聚度高。这种方法在实际中能够起到非常好的效果，使得测试工作成为设计的一部分,很好地把开发和测试融合为一个整体。

2 优点

测试驱动开发的想路就是要通过测试来推动整个开发的进行。而测试驱动开发方法并不只是单纯的测试工作，它会直接或间接地将开发人员的信心和开发进度关联起来，对于软件开发团体来说，开发、测试是可以互相促进的，由于软件产品说明书可以说是经常改动，因此可能需要团体经常在一起进行讨论，通过沟通来统一一些观点，而测试和开发工作的并行为沟通提供了桥梁，所以测试不仅仅是测试设计员设计的测试用例和测试员执行测试的过程，更是与软件开发团体互相沟通、互相研究、互相促进的过程。根据测试驱动开发的实践，测试驱动开发的思想至少可归纳为以下几个优点：(1)项目进度可预测，而传统的方式很难知道编码何时结束。(2)大部分时间代码处在高质量状态，100%的时间里成果是可见的。(3)从软件开发的初始阶段，测试驱动就强迫开发人员以测试的角度与用户的观点对软件进行审视，因而更能够对软件有全面的认识和把握。为系统改进提供了很好的保障。(4)由于可以保证编写测试和编写代码的是相同的程序员,降低了理解代码所花费的成本。(5)对于一个敏捷的开发小组，每个人都在做设计，对改善设计有很大助益。(6)减轻了测试的工作量。无论是否进行设计工作，测试工作都是不可避免的，先进行单元测试，可以减少后续的测试工作量。(7)让程序员能够更大程度地控制代码的正确度，相当于提供了两道的代码审核手段，在软件成品的质量上提供了一定的保障。(8)显著增加开发者的信心并赢得他人的信任。(9)为功能代码提供了很好的“文档”。(10)在一定程度上可以代替程序调试的工作。

3 过程

测试驱动开发的基本过程如下：(1)明确当前要完成的功能。可以记录成一个TODO列表。(2)快速完成针对此功能的测试用例编写。(3)测试代码编译不通过，新增的测试用例很可能编译不通过。(4)编写对应的功能代码。(5)测试通过。(6)对代码进行重构，并保证测试通过。(7)循环完成所有功能的开发。

测试驱动开发也是单元测试，单元测试是通过测试定义所要开发的功能的接口，然后实现功能的开发过程。开发人员开发过程中要做不同的工作，比如：根据测试用例编写测试代码、开发相应功能代码、对代码进行重构等。做不同的事，承担不同的角色。开发人员完成对应的工作时应该保持注意力集中在当前工作上，而不要过多的考虑其他方面的细节。避免考虑无关细节过多，无谓地增加复杂度。同时，在做测试计划时，应该考虑到软件产品需要测试的功能点很多。在任何阶段如果想添加功能需求问题时，应先把相关功能点加到测试列表中，然后继续手头工作。循环不断地完成对应的测试用例、功能代码、重构。一是避免疏漏，也避免干扰当前进行的工作。在单元测试中，对照软件产品说明书或详细设计，检查某个功能，某个类，首先编写测试代码，考虑其如何使用、如何测试。再对其进行设计、编码。

4 实现

NUnit是一个单元测试框架，专门针对于.NET来写的，它和JUnit(Java),DUnit(Delphi)，CPPUnit(C++)一样都是x U-nit的一员。NUnit是x Unit家族种的第4个主打产品，完全由C#语言来编写，并且编写时充分利用了许多.NET的特性，比如反射，客户属性等等。最重要的一点是它适合于所有.NET语言。下面用Nunit来实现一个简单的测试驱动的实践。在一般的信息管理系统中都需要有管理员对后台进行管理，这就需要有管理员登录的功能，据此有如下过程：

(1)明确当前要完成的功能，设计管理员登录功能。

(2)设计管理员登录测试用例，编写单元测试如下：

(3)编译，发现不能编译，因为还没有生成UserOper类。

(4)编写功能代码，生成最简单的UserOper类，以及对数据库连接的DBClass类，旨在通过编译测试代码。

(5)运行测试,这时测试通过

(6)再对代码进行重构，每次实现功能代码后，测试通过后都要进行重构。

(7)按此步骤循环完成所有功能的开发。

5 结语

随着WindowsXP开发方法的风行，测试驱动开发单元测试的思想也在遍地开花。越来越多的开发人员和公司开始学习和接受这种思想，并且在日常的开发工作中进行一些尝试，取得了很好的效果，但也存在一些不足，测试驱动开发是单元性测试，不是全局性测试。因此在对模型的验证方面起不到关键作用;如果用测试驱动开发驱动图形用户界面的编写，容易造成资源浪费;测试驱动开发的应用领域问题。对于设计很重要必须提前做好的软件，对于软件质量要求极高的军事或科研产品如神州六号，对于人命关天的软件如医疗设备软件等等不适合用测试驱动开发。

测试驱动开发是一个很有影响的研究方向，它能够提高代码的质量，帮助设计出可重用和可测试性的代码。积极有效地使用测试驱动开发是软件开发的好的方向。

摘要：极限编程是一种新型软件开发方法,而测试驱动开发是极限编程思想的一种主要实践。本文通过极限编程、测试驱动的理论阐述和用NUnit进行单元测试的实践来阐明测试驱动开发的实施过程。

关键词：极限编程,测试驱动开发,单元测试,NUnit

参考文献

[1]Kent Beck.测试驱动开发[M](影印版).北京:中国电力出版社,2003.

[2]陈果,陈蔚薇,林宝军.测试驱动开发在.NET环境中的应用[J].计算机工程与设计,2005,26(2):527530.

[3]唐东铭译.Beck K.解析极限编程-拥抱变化[M].北京:人民邮电出版社,2002.

[4]陈伟柱,陶文译.Andrew Hunt,David Thomas.单元测试之道C#版——使用NUnit电子工业出版社,2005.

测试驱动开发 篇2

某公司经理想开发C2C系统，找到IT部门的头头说，帮我做一个吧，头头回答说系统已经做好了啊。经理疑惑了，可是现在这个系统什么都还没有，怎么叫做好了呢？头头说，对，现在什么都还没有，好大一个Bug啊！于是，他在Bug管理系统上记录了该系统第一个Bug，“BUG1，C2C系统“。然后他问经理，这个系统应该包含哪些功能呢？经理说，它要有用户管理，权限管理，物品管理等。头头接着给BUG1添加了几个子Bug，“BUG2，需要用户管理”“BUG3，需要权限管理”等。接着越来越多的Bug被添加到Bug系统中，如果想Close任何一个Bug，那么它的所有子Bug必须都被Close，也就是它的依赖。每一个Bug被分配一个Owner（当然也可以自由选择），该Owner的任务就是Fix Bug，

Bug驱动开发是一个轻量的软件开发方法学，它利用Bug管理系统来记录要实现的功能，从大到小，逐渐具体化，而不仅限于记录系统缺陷。

它的优势是什么呢？

轻量。它仅仅使用Bug管理系统就可以管理所有的需求和系统缺陷，还可以利用dashboard来查看系统当前完成的进度。

每个Bug分配到人，人的任务就是Fix Bug，有约束性。

利用Bug系统的功能，很容易对各个需求进行排列优先级，状态跟踪。

QA从一开始就融入团队工作，对Bug进行管理。

优势应该不只这么多，只是我没有参与过Bug驱动开发，没有太多体会。不知道它和Feature驱动开发有什么本质的区别，就我看来这里的Bug是一种变相的需求表达方式而已。

TDD是具体开发过程中的实践，从测试开始到实现某功能。而BDD或者FDD，更加high level，从整个系统开发流程来驱动。

测试驱动的嵌入式开发与实践 篇3

关键词：测试驱动开发,嵌入式开发,单元测试,敏捷开发

在传统的软件开发中,代码正确性的检验依赖于后期的测试环节。而极限编程主张采用测试驱动开发(TDD)的方法,即通过测试定义所要开发的功能的接口,然后实现功能的开发过程。TDD通过不断测试推动代码的开发,既简化了代码,又保证了软件质量。随着科技的发展,软件开发出现了新的特点,软件的需求经常发生变化,从而导致敏捷软件开发的出现,使相对重量级软件过程变为经量级软件过程。敏捷软件开发是一种面向迅速变化的需求,快速开发软件的能力。 极限编程是敏捷软件开发方法中最著名的一个,它由一系列简单却互相依赖的实践组开发作为极限编程的核心实践。

1 测试驱动开发的现实意义

1.1 测试驱动开发

测试驱动开发(Test-Driven Development,TDD),是一种不同于传统软件开发的新方法。它要求在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。这有助于编写简洁可用的高质量代码,并加速开发过程。

测试自动化是TDD的关键。在TDD的进程中,首先会产生新的自动化测试,紧跟着是满足这些测试的产品代码。一套单元测试伴随着产品代码同时不断增长,它也是像产品代码一样具有价值的资产。每次微小的改动时,这套测试都会运行一次。这样不仅保证了新代码是可工作的,同时也保证了已存在的代码与新的改动兼容。尽管要写很多有价值的自动化测试,但TDD并不是一种测试技术。它是解决编程问题的一种方法。它能帮助软件开发人员做出更好的设计决策[1]。

1.2 测试驱动开发的机制

与传统的编程方式相比,能更容易看出TDD的运行原理,及优点。在这里把传统的方式称为后期调试式编程(Debug-Later Programming,DLP)。在后期调试式编程中,代码先设计并写出,即代码“写完”之后才进行测试。通常这个对于“写完”的定义忽略了约1/2的工作量,即对代码“写完”所进行的测试。在设计和编码的过程中经常会出现错误,这时会发现后期调试式编程存在反馈滞后性,错误通常要在较长时间才能反馈给开发者。在慢速反馈的情况下,出错代码可能还堆积了改动,因此问题的根源难以确定。

图1所示,当发现一个错误的时间(Td)增加时,找到这个错误根本原因的时间(Tfind)也会增加,而且增加较多。修正有些错误的时间(Tfix)通常和Td无关。但如果这是由建立在错误假设之上的代码造成的组合错误,Tfix也可能大幅增长。

当发现错误的时间(Td)趋于零时,定位问题的时间(Tfind)也将趋于零。刚引入到代码中的问题明显。若不明显,开发者也可以通过回退来恢复到以前工作的状态。时间只会模糊程序员的记忆并让更多的代码建立在早期错误之上,而TDD则会让Tfind+Tfix最小化。相比之下,TDD则会立即给出反馈。对失误的立刻通知将帮助避免错误。

TDD的核心是由小步骤来不断重复的循环组成,称为TDD微循环,TDD循环步骤基于Kent Beck的著作[2],描述如下:1)增加一个小的测试。2)运行所有的测试并期待新测试失败,也可能连编译都通不过。3)为了让测试通过来做一些小改动。4)运行所有的测试并期待新的测试通过。5)重构,以移除重复并改进代码的表达方式。

在这个过程中,不仅了解到了解决方案,同时也对所解决的问题有了进一步了解。测试变成了对需求细节的详实描述。当工作不断地增加后,测试同产品代码一起绑定了对问题的定义和解决方案。这些只是以稳定的形式被捕捉到。

2 嵌入式系统测试驱动开发的策略

2.1 双目标开发策略

对多数嵌入式项目来讲,并行进行硬件和软件开发是个现实。如果只能在目标硬件上运行,有可能会有多个浪费时间的因素[3]。

但并不是所有的开发团队都会遇到浪费时间的问题,传统意义上,这也是嵌入式开发者会转而使用评估板来缓解目标硬件的一个原因。评估板是在开发时使用的一种电路板,它有同目标系统相同的处理器配置,理想情况下还有同样的输入输出接口。评估板能保护不会延迟项目,但是这还不够,评估板仍然有构建时间长的问题。

双目标开发则是解决上述瓶颈问题的一个策略。双目标是指代码被设计成至少应能在两个平台上运行:代码最终是要在一个嵌入式目标硬件上运行,但它首先在开发系统中写出和测试的,而双目标解决了以下几个问题:它可以在硬件就绪之前就测试代码,并使它在整个软件开发周期里避免硬件带来的瓶颈,还可避免随硬件和软件同时调试带来的互相指责。双目标还会影响设计、对软件与硬件之间边界的关注会产生更模块化的设计。

在开发系统中,测试代码会在把代码应用于目标硬件之前来帮助开发人员建立信心,但在双目标方案当中存在其固有的风险。所以这些可能导致在一个环境里运行没有错误的代码却在另一个环境里却测试失败。在嵌入式中的TDD循环可以较好地应对这些问题。

2.2 嵌入式的TDD循环

嵌入式的TDD循环是对TDD微循环的扩展,它可以克服目标硬件所带来的瓶颈。当构建和测试的循环只有几秒钟的情况下TDD效果最好,更长的构建和测试时间会导致采用更大的步伐。对这种快速反馈的需求迫使TDD的微循环脱离目标硬件,而运行在本地的开发系统中。TDD微循环是嵌入式TDD循环的第一个平台,如图3所示。

平台2～4被设计用于缓解用开发平台来运行单元测试所带来的风险。平台5确保完整集成后的系统能够提供可工作的特性。

平台1:TDD 微循环。在这个平台运行得最频繁,通常几分钟一次。大部分代码会在这个平台中写出,并且只在开发系统本地编译。测试是在开发系统里完成的,这样它能给出快速反馈,而不会被硬件的可靠性或可用性的约束拖累。在这个平台中,需要写于平台无关的代码。要寻找把软件和硬件断开的机会,硬件和软件的边界要很清楚,并记录在测试用例中。

平台2:编译器兼容性检查。要定期的为目标系统作编译,采用为产品而使用的交叉编译器。这个平台是对编译器不兼容的一个早期警告。它会警告移植问题,如头文件不可用,语言支持不兼容,以及语言特性缺失等,不必在每次代码改变时都运行平台2。在每次采用了新的语言特性时做一下目标系统的交叉编译。

平台3:在评估板上运行单元测试。有一个风险是,编译后的代码在本地开发系统和目标处理器上运行起来是不同的。为缓和这种风险,可以在评估板上运行单元测试。使用评估板可以看到代码在开发系统和目标处理器上行为的差异。拥有在评估板上运行的能力,即使在目标硬件就绪之后可能仍然比较方便。如果有一些可疑的目标硬件行为,可以快速地通过在评估板上运行单元测试,以把目标硬件的问题包含进来或排出。

平台4:在目标硬件上运行单元测试。平台4的目的和平台3相同,只是平台4会使用真实的内存。而且可以运行只能在目标硬件上运行的测试。这些测试可以识别出或者学习到目标硬件的行为。这个平台一个新增的功能是目标硬件上有限的内存。在这种情况下,可以把测试组织成不同的测试套件,使每个套件都能装进内存中。

平台5:在目标硬件上运行验收测试。最后,需要在目标硬件上运行自动化的和手工的验收测试来保证产品特性。这里要确保任何不能完全被自动化测试的、依赖于硬件的代码都会被手工测试。

3 结束语

针对传统嵌入式开发所遇到的瓶颈,论述了测试驱动开发的机制与现实意义,以及嵌入式系统测试驱动开发的策略。TDD不是一个简单的方法论,而是强调质量文化。从更高层的视野来看,TDD 事实上是把测试对软件整体质量的保证引入到软件单元的开发中,使得整个开发过程中的质量得到更进一步监护,就像敏捷开发中的每件事情一样,测试也需要敏捷。

参考文献

[1]JAMES W G.测试驱动的嵌入式C语言开发[M].尹哲,译.北京:机械工业出版社,2012.

[2]KENT B.Test driven development:by example[M].MAUSA:Addison-Wesly Reading,2002.

数据驱动的需求测试 篇4

随着科学技术的进步,信息科学与技术有了长足发展,带动了冶金、机械、交通和物流等行业的快速发展。随着企业规模的扩大,生产设备和工艺越来越复杂,基于数据驱动模式建立起物理和化学的模型,并在生产过程中对设备加以控制,以提升管理效率。在实际运营中,预测和评估比较复杂,企业生产过程中需要大量的设备,储存大量的处理数据,在此过程中要及时对设备运行信息加以管理,形成数据驱动理论来构建数据知识体系,构建和实现精确的机理模型,在此条件下实现生产工艺和设备的优化,对数据驱动理论要加以预测和评估控制,形成控制理论。数据驱动的控制理论和方法发展,是新时期控制理论发展和应用的必然要求,因此对数据驱动进行需求测试有重要的理论意义和现实意义。

2 数据驱动控制模型的发展

将基于数据驱动控制模型的理论应用到控制对象中,以实现精确的模拟仿真,建立起数学模型,并采用科学的办法确保数据驱动控制模型所建模型是科学准确的,基于此可实现控制器的合理操作,以保证所建模型的准确性,基于数据驱动控制模型的顺序构建会让控制器设计处于高阶系统模型状态,求解过程会变得非常复杂。因此要建立起模型系统控制方法以实现基于模型的控制理论,当前数据驱动控制方法的理论研究和实际应用主要有:

(1)基于离线数据的PID控制。PID控制已被广泛地用于工业数据驱动控制过程中,根据当前离线的数据来实现PID控制,在当前的系统控制中采用PID控制方法,以实现控制参数的调节,使用PID控制方法有利于控制方法的构建,采用离线数据进行PID控制是工业控制系统中常用的方法之一,要使用给定的输出数据,来对数据驱动控制加以构建,形成参数控制器,数据驱动的方法是简单有效的,也是易于使用的,所以工业生产中要对数据驱动加以控制,以实现数据驱动理论的构建。

(2)基于子空间方法的控制。在子空间辨识方法中基于子空间方法的控制的基础理论研究中要使用大量的输入和输出数据来对线性子空间加以预测,再次使用控制器体系进行预测指标的设计。子空间辨识方法的优点是其不需要识别系统的模型,要采用无模型控制系统,并且可与基于数模型方法组合来设计各种控制器。子空间辨识方法的缺点是数据通过该方法设计驱动器来进行有针对性的线性系统构建,子空间辨识系统有一定的局限性。

(3)去伪控制。1995年,Safnove提出了数据驱动的控制方法。根据控制对象的输入和输出的测量数据,从该组候选控制器中做出选择,是满足特定性能要求的控制器。数据驱动控制能够找到满足性能指标的控制器,然后选择可切换到闭环系统的环境。

(4)虚拟参考反馈整定。在2000年,Guardabassi和Savaresi提出虚拟参考反馈调整的非迭代数据驱动控制方法,使用一组受控对象的输入和输出测量数据方法,构建起最佳的参数结构控制器,使效率得到了进一步提高。

(5)无模型自适应控制。无模型自适应控制是国内外学者提出的一种自适应控制(MFAC)数据驱动的控制模型,这种方法的基本思想是在控制系统当前工作点与等效线性动态模型的基础上,采用适宜的方法,以取代一般离散时间的非线性系统,从而实现自适应模型的自由控制。

3 数据驱动的需求测试特点

在尽可能早的时候就开始进行的软件测试,在实践中可总结出数据驱动的需求测试的特点。

(1)在系统上线投入运营前要做好数据驱动的需求分析工作,要根据系统需要,做好系统的测试开发工作,对系统加以测量构建起系统模型,数据驱动的需求测试对于整个系统的测试过程都有着非常重要的意义。

(2)要在理解数据驱动需求的基础上,对需求测试计划加以管理,以对系统产生积极的影响。数据驱动的需求构建需要对数据驱动测试中产生的偏差加以修改,以重新测试、实施,从而避免浪费大量的人力、时间和金钱的浪费。

(3)数据驱动的需求会因应用环境的差异而发生改变,这在许多项目中是十分常见的,要根据数据驱动的需求变化情况做好测试工作,对数据驱动的需求分析从开始阶段就要做好规划和设计工作,以便相应的加以补充,并进行快速的调整。

(4)数据驱动的测试需要专业的人员加以设计,经验丰富的工程师和测试工程师要做好相互的配合工作,以提高数据驱动的需求测试水平,满足数据驱动需求测试工作的要求。

(5)数据驱动的需求测试工作中,要及时发现数据驱动系统中的问题所在,及时地对数据加以效准,以做好数据驱动需求测试的修正工作,提高质量数据驱动的测试质量,降低数据驱动系统的开发成本。

4 结语

基于模型驱动的测试架构 篇5

软件测试在软件开发中占有非常重要的位置。然而为缩短产品的开发周期,各商家又不得不从测试环节中节省时间。所以如何在确保软件质量的前提下缩短测试周期便成了各测试领域专家研究的重点。

随着UML 2.0 Testing Profile的发布,模型驱动测试作为一种全新的测试思想已由前期的理论探索论证转入了发展与实践阶段。模型驱动测试就是通过对SUT的功能与系统结构进行分析,然后结合测试策略构建起全面、清晰的测试模型,最后通过测试模型自动生成测试用例驱动测试人员完成SUT的测试。模型驱动测试的优点主要有两方面:

(1)测试模型为用户提供了更加清晰、准确和系统地测试设计;

(2)减少了测试用例的维护工作,实现了测试资源的重利用,有效缩短了测试周期。

1 基于模型驱动的测试架构

1.1 测试架构

MDT-TA(Model Drive Testing Testing Architecture)的系统结构如图一所示,该系统将所有模块分成三层。

(1)模型处理层---核心层

该层是整个测试架构中的核心层。在本层中提供可视化的建模工具来支持系统设计建模和测试设计建模。当系统模型设计完成后,“模型转换器”就可以根据模型转换算法自动将系统模型转换成测试模型。

(2)测试用例抽象层

为了增加本测试架构的扩展性,在本测试架构中提炼出了测试用例抽象层。该层根据已建立的测试模型和测试策略,自动生成测试逻辑和测试数据池,而不直接生成具体的测试用例脚本。具体的实现与执行将由测试人员根据系统的要求在第三层的用例实现与执行层进行适配。

(3)测试用例实现与执行层

有了测试逻辑和测试数据后,系统就可以根据SUT的特性选用一种最合适的测试语言生成具体的测试脚本实施测试。本层的功能就是用测试数据实例化测试逻辑从而形成测试用例,然后生成测试脚本。

1.2 模型自动转换技术

在文献[2]中描述“软件的测试内容与方法由被测系统决定”,文献[3]中则称“测试模型与系统设计模型之间有一种天然的联系”,由此可见测试设计模型与系统设计模型之间存在着一种强关联。本文的模型转换技术就是通过解析系统设计模型与测试设计模型之间的关联关系来实现从UML模型到U2TP模型的自动转换。图二展示了设计模型与测试活动的对应关系。

在UML建模语言中,用例是用来描述业务功能的,它的执行有明确的前因和后果事件,一般由几个有序的步骤来完成。由用例组合而成的用例图明确地划定了系统所能提供的服务(即系统功能),而系统序列图(用例描述中步骤的体现)则清晰地描述出了每一个功能的详细操作步骤和激励。本文的模型转换技术就是通过分析用例图和系统序列图来构建系统测试模型,其构建过程如图三所示。

生成测试系统模型的过程如下:

(1)根据用例图分析出所有的参与者;

(2)根据用例描述图分析出参与者的活动和系统活动;

(3)根据参与者活动和系统活动的基本流程和备选流程生成系统测试模型。

下面通过ATM系统的实现用例来演示模型转换技术,图四和表一分别为ATM机系统的用例图和用例描述表。

模型转换器通过扫描分析系统设计模型的MOF文件,得到当前系统的参与者和系统活动。然后将系统活动集转换成测试模型中的状态图,同时将参与者的活动转换成激励,每一状态迁移时输出的信息作为测试结果仲裁的输入。基于用例图自动生成的ATM系统测试模型如图五所示。在生成的测试模型中存在两个激励和三个观察点,通过对激励点的不同组合就可以完成对ATM系统查询功能的系统测试。

1.3 测试逻辑自动生成技术

为了实现与平台无关和提高系统的可扩展性,本文提出了“测试逻辑”的概念,其定义如下:

(1)有特定的测试目的且在当前测试中是唯一的;

(2)不含测试数据;

(3)是一系列有序的测试步骤集合。

测试模型生成测试逻辑的过程可以根据测试策略选用不同的算法来实现。本文结合深度优先算法和广度优先算法,从测试模型状态图的初始状态开始遍历,将遍历过程中产生的每一条完整的状态转换路径都记录下来,这样每一条完整的路径就是一个测试逻辑。算法描述如下:

第一步:检查出当前状态图的所有回路并在相应的节点做上标记;

第二步:采用深度优先算法打上一级步骤编号;

第三步:采用广度优先算法打上二级步骤编号;

第四步:根据编号生成测试逻辑。

1.4 测试数据自动生成技术

测试数据的好坏直接决定了测试用例的质量。测试数据如果过多,则会加重对测试资源的消耗(包括人力资源);如果过少,又有可能导致覆盖不全面,容易造成漏测。本文的测试数据自动生成技术是针对系统测试用例而提出的,所以它只关注激励数据而不关注程序实现本身。算法描述如下:

第一步:获取测试模型中的所有激励(即标识为“IN”的变量)与约束,约束即密码不能为空且为6位数字,不能以0开头。

第二步:根据激励的合法性约束划分出有效等价类和无效等价类的边界,如表二所示。

第三步(可选):如果激励的约束中确定了值的范围、个数或者先后顺序,则标识该激励的边界值,如表三所示。

第四步:根据Pair Wise算法,生成有效等价类解集和无效等价类解集。在生成的测试数据中,根据测试策略中的权值表(该表从XML模板文件中读取,表中的权值因测试的目的不同而判定每一级的条件不同。例如在性能测试策略中,靠近阀值或极限值的数据优先级别为最高;而在基本功能测试中,为上点、离点或内点的数据的优先级要高于阀值)设定每一个测试数据的优先级,如表四所示。

2 结论与展望

目前基于MDT-TA指导开发的全流程测试管理与执行工具Test Studio已进入用户体验阶段。从用户反馈的结果看,一方面证实了本架构在实现测试前移、缩短开发周期和降低维护成本的优势;另一方面也暴露出了本架构的不足之处:

(1)只能证实,不能证伪。如果系统设计模型错误,则测试模型无法自动检测出系统设计模型的错误。

(2)当前的UML语义还不足以完全地支撑测试模型中需要的信息。

(3)生成的U2TP测试模型可以非常方便地生成TTCN测试用例,但JAVA、C++语言的支持不够。U2TP模型中的部份概念无法直接转换成对应的JAVA或C++代码。

因此,下一步需要研究的重点主要是下面几个方向:

(1)研究测试设计模型的自动测试技术;

(2)扩展UML和U2TP语义,使其满足测试建模的需要;

(3)研究将状态图、类图生成测试模型的算法,使当前的测试模型不仅仅覆盖系统测试,而且还可以覆盖集成测试和单元测试;

(4)扩展测试逻辑和测试数据自动生成算法。

参考文献

测试驱动开发 篇6

随着软件产业的飞速发展,软件系统的规模越来越大,功能、技术经济等方面的危机频频出现,软件质量的问题已经成为开发者和用户关注的焦点。而软件测试正是目前保证软件质量的控制手段,验证软件能否完成用户预期需求的唯一有效方法。因此,软件测试在软件开发中的地位得到了前所未有的提高。

长期以来,我国软件行业重开发轻测试,测试人员的很多工作由开发者代劳,导致很多人员不愿意从事专门的测试工作,因此行业内的软件测试人才严重短缺;另外,在高校的教学设计中,软件测试仅仅作为软件工程的一个章节来讲解,而没有设置专门的软件测试课程,因此学生无法胜任软件测试工作。基于以上背景,为了满足软件测试人才的大量需求,在高校中,培养应用型技术行的人才迫在眉睫。

2 项目驱动教学模式

项目驱动是指把项目作为专业课程的总教学目标,根据教授的知识点,将项目划分为若干个典型案例, 以案例引导学生对知识点的掌握,实行“理论与实践的一体化”,在这个过程中,学生会不断获得成就感,并激发学习热情,培养自主学习能力。基于项目的统领,将原来琐碎的知识点,通过不同的案例,整理的系统、条理,是提高教学效果, 训练职业技能的有效教学方法。

在软件测试课程中,所挑选的项目为学生们比较熟悉的学生管理系统,根据理论+实践课程的教学方式,将该系统分为多个小项目,每个项目中都蕴含着重要知识点的讲授,在理论课的教授中,先通过简单案例,熟悉知识点,之后将其应用的小项目中,最后将各个项目综合起来,按照软件测试的过程,带领学生进行实际项目的测试工作,使学生在实际工作中,尽快上手。

3 课程改革实践

根据应用型软件测试人才培养的目标,在基于项目驱动的教学中,软件测试课程的定位主要分为:课堂教学和项目驱动。

3.1 课堂教学

课题教学由基础理论知识和实验操作两部分组成。根据不同的阶段,所提供的案例,使学生能够掌握软件测试的基础知识。

在理论部分,重点和难点为黑盒测试和白盒测试测试用例的设计方法。依黑盒测试用例方法为例,将学生管理系统所分的两个小项目:系统登录功能和学生评价功能,当学生掌握黑盒测试用例方法设计时,对两个项目进行用例设计和功能测试。在教学过程中,一方面为了使学习内容更接近学生的接受能力,另一方面扩大接触不同类型软件,扩大学生知识面,根据学习内容,由简到难分别提供了加法器、求三角形的面积、ATM机等例子,分别对应等价类划分、边界值、因果图、场景法等。掌握黑盒测试用例的编写。其中三角形的面积贯穿与等价类划分、边界值和因果图三个知识点,为了提高学生的学习兴趣和动手能力,将求三角形面积作为学生动手的项目任务进行练习。首先,老师提出软件需求;其次,将学生进行分组,一部分学生进行软件功能说明文档的编写,部分学生根据功能说明进行软件的开发。第三:根据软件的功能说明,对开发的软件的功能进行设计测试用例,并且进行测试的执行。

通过求三角形面积项目,能够将所学到的基础知识点,应用的实践项目中,为下一步进行系统所分割的登录功能和查询学生功能打下坚实的基础。

在实践部分,主要是软件测试工具的学习。软件测试所使用的工具很多,根据学校的实际情况和学生对象,所教授的工具有:实践:例如单元测试:Junite;错误的管理:Bugziller;自动化工具:QTP;所测试的对象为自带飞机订票系统和所开发软件学生管理系统。

在学习Junit中,仍然测试学生所开发软件求三角形面积为任务驱动,要求学生掌握两个方面的内容,一、复习理论中白盒测试用例设计的方法,对程序进行用例设计;二学习Junit单元测试工具,包括掌握JUnit的安装,熟悉简单测试和运行的过程。当在测试工程中发现软件的缺陷时,利用Bugziller工具进行缺陷的管理,包括缺陷描述、缺陷报告的提交、分配缺陷、审核缺陷报告、处理缺陷和验证关闭缺陷等。

相对于手工测试而言,把需要重复执行的测试步骤描写成测试脚本,让机器去重复执行即自动化测试可以极大的提高工作效率。在教学设计中介绍了自动化测试的基本概念,通过QTP自带的飞机订票系统,介绍了QTP功能的基本使用,特别是检查点、数据驱动、参数化、对脚本的编辑等,提取学生管理系统的小项目,作为每个知识点学习的案例。

3.2 项目驱动

在本校的教学设计中,软件工程为软件测试的先驱课程,将学生所设计的软件作为一个整体的项目进行测试,一方面丰富了教学内容,另一方面,进一步的提高了学生的积极性。

以学生管理系统为例:在对整个项目的测试中,包含了测试计划的编写,测试环境的搭建,测试用例的编写,自动化工具的使用,从错误的描述及Bug管理工具的使用。当学生对软件测试的技术有一定程度的掌握时,选取的项目尽可能的与企业的实际工作环境接近。

在整个项目实践中,测试工程师从软件最初简单的需求模型到产品发布各个阶段的主要工作都进行了详细的讲述和实践操作,包括项目初期各个阶段的主要工作,软件测试计划的制定、软件测试案例的编写、软件项目各个部门相互协作、执行测试案例并报告缺陷、产品功能完善与修复缺陷阶段、测试工程师在产品发布前后的工作,如下表所示:

4 总结

测试驱动开发 篇7

本文在简要分析了VxWorks I/O系统及设备驱动基础之上,将A/D与D/A两者整合为一个完整的字符设备挂接到VxWorks的I/O系统中,成功实现了该设备的硬件驱动并附上对应的核心驱动代码,最后在驱动程序测试过程中简要说明了应用层软件的设计方法,为工程应用提供了完善的解决办法。

1 VxWorks l/O系统与设备驱动

了解和掌握VxWorks的I/O系统及设备的驱动结构,是成功设计AD/DA设备驱动的前提和基础。具体来说:VxWorks是一个层次化分明的操作系统,每层各负其责,层与层之间又紧密相连。通常所说的驱动程序属于底层的范畴,而用户的应用程序则属于上层,位于这两层之间的是中间层,无需用户开发,由VxWorks进行维护和管理。这样,操作系统把各层有机地连接在一起,使代码紧凑而高效。VxWorks的I/O系统正是这样的中间层,以本文所要研究的AD/DA驱动系统设计为例,图1详细介绍了三者的关系。

图1中的最底层就是所要编写的设备驱动程序,包括对具体硬件的初始化和各种操作,以及与上层I/O系统的接口;中间层为I/O系统层,VxWorks的I/O系统不但向上提供了7个基本的I/O接口,以供应用程序调用,而且还向下提供与各种设备驱动程序的接口;最顶层为应用层,用户根据实际应用需要编写应用程序,并通过应用程序向下调用I/O系统。与UNIX类似,VxWorks所有的I/O设备都被当作文件来存取。关于VxWorks I/O系统驱动机制的更多内容请参考文献[2][3]。

针对系统需要,选择7个基本I/O接口函数中的open()、read()、write()以及ioctl()进行驱动系统设计,各层函数与相应实现的功能对应关系如表1所示。

此外,D/A输出通道在应用程序中选择,下面给出AD/DA驱动系统的具体设计过程。

2 AD/DA驱动系统设计

2.1 驱动系统开发环境

与其他嵌入式系统开发类似,VxWorks也采用主机-目标机模式[4],如图2所示。

硬件平台中主机使用CPU为迅驰的PC机,运行VxWorks开发环境Tomado2.2;目标机依照系统应用要求选用基于PC104总线的嵌入式CPU卡MSMP586SEV,该CPU是VxWorks所支持的Intel x86系列CPU。VxWorks自带的板级支持包(BSP)支持该CPU,使得在驱动开发过程中无须过多考虑CPU部分的代码设置。外扩AD/DA采用的同样是PC104总线的数据转换卡ADT-650。开发调试过程中,主机通过网络方式下载VxWorks映像至目标机中,目标机设定为CF卡启动。

2.2 PC104-AD/DA卡硬件结构[5]

PC104-AD/DA卡主要由A/D转换控制器(AD1674)和D/A转换控制器(ADC7724)两个核心器件组成,可提供的硬件资源为12位分辨率的8通道A/D转换和同分辨率的4通道D/A转换;CPU卡通过I/O映射方式对其进行访问,可通过硬件开关选通该卡的I/O映射基地址,为了避免与其他器件地址冲突,在此选择其基地址为:BA=0x240(可根据实际情况选择),其余各寄存器采用偏移地址访问的方式。为便于后续说明,简要将卡上其他寄存器地址及功能列于表2。

在传统非嵌入式实时操作系统(比如DOS)下应用该卡,实际上是在应用程序中对板卡进行初始化和设置相应功能寄存器以完成硬件功能。但由前面对VxWorks的I/O系统和设备驱动结构分析可知,该部分工作在VxWorks操作系统下由底层硬件驱动完成,应用程序中通过调用相应I/O接口函数来实现硬件功能,由此实现分层结构以达到隔离硬件的目的。因此,AD/DA驱动的开发就是依照I/O系统传递过来的应用层各调用接口函数完成对相应寄存器的不同设置。

2.3 AD/DA驱动程序实现

AD/DA驱动的实现方式主要是完成以下6个函数的编写:

设备驱动程序安装函数adcDrv();

设备创建函数adcDevCreate();

设备打开函数adcOpen();

设备读函数(A/D转换)adcRead();

设备写函数(D/A转换)adcWrite();

I/O控制函数adIoctl()。

其中前三个函数的设计与具体硬件关联较少,与VxWorks下其他字符型设备驱动开发基本类似,不做过多介绍,仅需按照标准代码形式编写即可,具体详细代码可见参考文献[6]。下面详细介绍A/D转换驱动、D/A转换驱动以及设备控制驱动等部分的程序设计,给出核心代码。

2.3.1 A/D转换驱动

A/D转换驱动实际是完成adcRead()函数的编写,在该函数编写之前,首先应明确A/D转换驱动实现过程:当应用程序调用read()函数时,VxWorks的I/O系统将调用底层驱动adcRead()函数,该函数随即依照程序设定对表2所列卡上各相关寄存器进行设置来实现A/D转换的硬件功能,从而实现底层驱动。

A/D转换驱动具体实现的核心代码如下(伪指令为代码说明,以下同):

首先选择一个输入通道(通过ioctl选择)并触发A/D转换,随后查询A/D转换状态信息直到A/D转换过程结束,最终将转换结果保存在pBuf[]数组中传送到应用层,应用程序使用得到的数字量信息,至此,A/D驱动完毕。其中sysOutByte()和sysInByte()为VxWorks下对寄存器操作的标准函数。

2.3.2 D/A转换驱动

与上述驱动实现过程类似,D/A转换驱动是完成对adcWrite()函数的编写,转换过程是A/D转换的逆过程,由于其不涉及查询判断,代码相对简化。D/A转换驱动具体实现的核心代码如下:

首先将应用程序中设定的待转换数字量的低4位和高8位分别存放在pBuf[1]、pBuf[2]中,随后依照先高后低的顺序写入D/A转换缓冲区内,当低位数据写入完成后,硬件将自动开始更新D/A输出的模拟量,至此,D/A驱动完毕。需要说明的是:D/A通道选择是在应用程序中的编码过程中实现的。

2.3.3 设备控制驱动

设备控制驱动用于完成A/D通道选择,实现过程是对BA+3寄存器进行设置,当该寄存器高低位不同时,通道进行自动扫描,每当AD转换完成时切换到下一个通道。以控制A/D对通道0至通道3循环扫描为例,具体代码如下:

通过定义控制参数CH30,实现通道扫描的范围为0、1、2、3、0、1、2、3……,利用该方法的好处是可以省去置通道的软件操作时间,这个功能在高速多通道切换时起很关键作用,同样可定义其他通道的控制参数,如CH20、CH00等等。

3 应用及测试

为了验证上面所设计的驱动系统的有效性,文章对其进行了详细的实验验证。针对本系统而言,D/A能将电机转速控制数字量转换为相应的模拟电压量输出至电机,并且在控制电机运转的同时,还能利用A/D将压电陀螺敏感到的电机转速所输出的模拟电压量转换为数字量后并采集,以此证明驱动系统设计是成功的。下面详细给出实际工程中用于测试驱动程序设计成功的应用程序。

3.1 应用程序设计

首先调用adcDrv()和adcDevCreat()初始化驱动并创建AD/DA设备;并通过fd=open(“adc”,O_RDWR,0)操作打开设备。这样,系统为AD/DA卡分配了一个文件描述符fd,通过读写该描述符操作即可完成相应AD/DA变换。

随后发起两个任务[7][8]:写任务和读任务,分别完成上述D/A与A/D的功能。两个任务的核心代码如下:

3.2 测试结果

在WinShell下通过调用iosDevShow()函数可以看到,名为/adc的AD/DA卡设备已经被VxWorks操作系统正确识别,如图3所示。

测试分为两个步骤来验证A/D及D/A驱动的正确性:

步骤1:数字量→模拟量→电机转速(D/A)

步骤2:电机转速→模拟量→数字量(A/D)

步骤1控制电机加减速过程当中,给定的控制电机运转的数字量如图4中datal所示(其中:datal是通过16进制数转换为10进制数实现的)。每隔0.5s对系统进行一次D/A转换,得到电机实际转速rate如图5所示。

对比datal和rate,两条曲线规律一致,说明D/A驱动功能正常。

随后将图5中的电机转速作为输入量,输入到步骤2中进行实验,以相同时间间隔对系统进行A/D采样,转换后的数字量如图4中data2所示,对比data2和rate,两条曲线规律一致,说明A/D驱动功能正常。

datal与data2两条曲线基本重合,二者之间的误差曲线error (datal-data2)如图6。

由图6可得:误差最大值为3.2LSB,最小为2.1LSB。由此可见,AD/DA功能实现的同时精度完全符合要求(4LSB≥error≥2LSB)。实验结果表明:驱动系统设计成功有效。

本文介绍了VxWorks下AD/DA驱动的开发过程,给出了驱动中的核心代码。同时在对驱动程序进行测试的过程中说明了部分应用程序的设计。测试结果表明,所开发的驱动系统满足实际需要(12位AD/DA转换分辨率),可在实际工程中应用。限于篇幅本文未能给出全部代码,但文中驱动程序的设计是完全依照VxWorks的标准I/O机制实现的,具有普遍的指导意义,可为VxWorks下其他字符型设备驱动开发提供参考。

摘要：在分析了VxWorks实时操作系统设备驱动机制后，通过采用VxWorks I/O系统挂接应用层与底层的方式实现了VxWorks下对AD/DA设备的驱动。在重点介绍驱动中核心代码的同时，简要说明了应用层软件的设计方法，并给出了详细的测试手段。

关键词：VxWorks,实时操作系统,设备驱动,AD/DA

参考文献

[1]孔详营，柏桂枝．嵌入式实时操作系统VxWoks及其开发环境Tornado[M]．北京：中国电力出版社，2002．

[2]解月江，张梅．VxWoks下设备驱动技术研究[J]．航天控制，2004，22(6)：54-57

[3]解月江，秦龙勇．VxWorks下PC/104-CAN驱动程序设计[J]．单片机与嵌入式系统应用，2003，29(4)：25-27．

[4]Tornado 2.2 User's Guide[S].Wind River System Inc. 2002.

[5]盛博科技．SysExpanModuleTM/ADT650技术手册[S]．

[6]周启平，张杨．VxWorks下设备驱动程序及BSP开发指南[M]．北京：中国电力出版社，2004．

[7]陈智育，温彦军，陈琪．VxWorks程序开发实践[M]．北京：人民邮电出版社

测试驱动开发 篇8

近年来, 具备可垂直起降、悬停及低空低速飞行能力的四旋翼无人飞行器已经成为一种主流的无人飞行器应用与研究平台, 在侦察、搜索救援、交通监控、灾情监测、航拍、地理测绘、遥测遥感等领域有着非常广泛的应用前景。

由螺旋桨、无刷直流电机、电子调速器及电池构成的驱动系统是四旋翼无人飞行器的关键部件, 它不仅产生升力, 更通过对各旋翼升力的快速调节提供飞行器六自由度运动所需的操纵力和力矩。由于具备开环不稳定、高动态的特性, 四旋翼无人飞行器的姿态需要通过对各旋翼升力的快速调节实现自稳定, 这要求旋翼升力具备快速的动态响应能力。旋翼升力通常由飞行控制计算机向电子调速器发送转速或PWM命令实现。前者要求电子调速器实现旋翼转速的闭环控制[1], 如此可降低电池电压波动对旋翼转速的负面影响;然而转速控制难免存在余差。此外, 出于轻量化考虑, 现有的电子调速器通常使用精度较差的内部RC振荡器, 这使得控制转速与真实转速之间存在误差, 需要额外的校正[2]。后者直接改变PWM占空比调整旋翼升力, 电子调速器仅进行换向而不构成转速闭环[3];在这种开环方式下, 旋翼升力具有快速的动态响应, 然而其动态特性不可避免会受电池电压变化的影响。

在电机方面, 当前的四旋翼飞行器通常采用有刷直流电机[4,5]或无感无刷直流电机[6,7]。有刷直流电机控制简单, 但扭矩较小, 需要减速齿轮配合驱动螺旋桨。无感无刷直流电机扭矩大、效率高, 可直接驱动螺旋桨, 可靠性更高。

本研究给出一个基于无感无刷直流电机的四旋翼无人飞行器驱动系统设计与实现方案并建立了旋翼升力的动态模型, 在此基础上对驱动系统进行详细的性能测试, 并给出实际的自主飞行实验结果。

1 驱动系统设计

1.1 驱动系统总体架构

四旋翼无人飞行器驱动系统总体架构如图1所示。四旋翼无人飞行器的驱动系统由螺旋桨、无感无刷直流电机、电子调速器及电池构成。对角线上的旋翼1、旋翼3逆时针旋转, 旋翼2、旋翼4顺时针旋转。飞行器的俯仰力矩由旋翼1与旋翼3的升力差产生;滚转力矩由旋翼2与旋翼4的升力差产生;4个旋翼的升力之和与反扭力差分别产生升力与偏航力矩;各通道操纵量与各电机PWM值的关系为:

式中:uq, up, uT, ur—俯仰、滚转、升力、偏航通道的操纵量;u1, u2, u3, u4—4个电机的PWM输入。

除了快速的动态特性, 效率也是驱动系统设计的重要指标。根据动量理论, 飞行器悬停所需的理想功率为[8]:

式中:T—升力, ρ—空气密度, A—桨盘面积。

由式 (5) 可知, 在给定悬停重量的前提下, 桨盘面积越大, 消耗的功率越小。因此为了提升旋翼效率, 旋翼越大越好。然而大的旋翼需要大扭矩输出的电机匹配, 相应地, 电机与机体的尺寸也要做大, 因此研究者需要根据悬停重量、机体尺寸进行综合折衷。

1.2 电子调速器设计

为了实现无感无刷直流电机的电子换向, 本研究设计了由六臂全桥驱动电路、反向感生电动势过零检测电路、电流检测电路及ATmega88单片机构成的电子调速器如图2所示。

六臂全桥驱动电路的3个PMOS上臂由单片机的15.625 k Hz PWM输出驱动, 3个NMOS下臂由单片机I/O驱动。

电机转子位置通过检测第三相反向感生电动势 (BEMF, 以下简称反电动势) 过零点判断;过零事件由单片机内置的模拟比较器检测, 由于各相过零事件是按顺序产生的, 根据当前相位控制模拟通道多路选择器切换各相电压输入可以实现比较器的复用, 如此可有效简化电路设计。在静止或低速运行时, 由于反电动势很小, 过零事件检测存在较大误差, 这将导致电机无法正确换向而启动失败。为解决该问题, 本研究在电机启动阶段采用开环换向策略, 等电机产生足够反电动势后再基于反电动势过零点进行换向。

电机工作电流检测电路将电机工作电流转换成电压, 该电压由单片机ADC采集, 用于过流、电机堵转的检测, 以保护电机与MOS管。

ATmega88单片机实现换向、过流检测、与飞控计算机通讯等功能;通讯接口采用I2C总线, 以方便连接多个电子调速器, 并满足4个电子调速器500 Hz PWM更新频率所需的通讯带宽要求。

2 驱动系统模型辨识与性能测试

2.1 测试平台

本研究在如图3所示的测试平台上进行驱动系统的模型辨识与性能测试。测试过程中, 旋翼气流朝上, 产生的下压力由计重设备测量, 电子调速器同时以500 Hz频率输出转速测量值到本地保存。由于设备限制升力难以实时测量, 本研究在获得典型工作点转速与升力数据的基础上, 利用升力与转速平方的正比关系实时估计各转速下的升力。本研究测试的4种动力组合如图3所示。

2.2 模型辨识

PWM-升力阶跃响应曲线如图4所示。从图4给出的PWM-升力阶跃响应曲线可以看出, 旋翼升力的动态特性可以很好地用二阶线性模型描述:

式中:T—单个旋翼的升力;u—电机的PWM输入;k—模型增益;Tp1, Tp2—时间常数。

由实验辨识得到的11.4 V供电电压下4种动力组合的模型参数如表1所示, 辨识实验以方波信号为激励源, 模型参数由Matlab系统辨识工具箱估计得到。从表1可以看出, 同一动力组合正反桨对应的模型增益和带宽存在平均4.4%和4.3%的差异, 这主要是由于正、反桨空气动力学特性难以做到完全一致导致的;电机和桨的转动惯量对模型带宽影响很大, 驱动系统应选用转动惯量尽量小的电机和桨以提高驱动系统带宽, 使得其动态满足四旋翼无人飞行器实时控制的要求。

四旋翼飞行器的4个电机由于总工作电流非常大 (10 A以上) , 只能由未经稳压的锂聚合物电池组直接供电。在飞行过程中, 随着电池电压因放电而逐渐降低, 旋翼升力动态模型的增益和带宽将逐渐下降。针对3S锂聚合物电池组, 本研究选择12.4 V、11.4 V、10.4 V这3个典型的工作电压对各动力组合的模型参数进行了辨识, 结果如图5所示。在电池电压下降16.1%的情况下, 各动力组合模型增益和带宽平均降低22.1%和11.7%。因此, 在飞行控制器设计中需考虑这些参数摄动以保证系统鲁棒性。

2.3 效率测试

除了动态响应带宽, 能量效率也是评价驱动系统性能的重要指标, 它直接影响飞行器的续航时间与里程。11.4 V电压下各动力组合的效率测试结果如图6所示。在相同的升力下, 尺寸越大的桨诱导速度越低, 所消耗的功率越小, 因此效率越高;由于旋翼消耗功率与转速三次方成正比, 效率随升力增大而降低。

3 自主飞行实验及结果分析

3.1 四旋翼飞行器

为了验证驱动系统在实际飞行中的有效性, 本研究在如图7所示的四旋翼无人飞行器上进行了自主飞行测试。飞行器电机和桨分别采用朗宇X2212 550 k V电机和EPP1245正反桨, 电机对角距离0.5 m, 起飞重量1.024 kg。飞行器采用基于多源传感器信息融合的GPS/MEMS SINS/地磁组合导航算法[9]提高飞行状态信息估计的精度与动态性能。为保证飞控系统在驱动系统模型参数摄动下的鲁棒性, 姿态和速度控制算法均基于针对系统不确定性的定量反馈理论进行综合设计[10]。

3.2 自主飞行测试结果

四旋翼无人飞行器自主飞行轨迹如图8所示。在自主飞行实验中, 四旋翼飞行器首先从起降点自主起飞并爬升到航点1, 然后依次穿越航点2、航点3、航点4并返回航点1, 最后自主降落到起降点。由于四旋翼飞行器本质上具备的开环不稳定及高动态特性, 飞控系统对驱动系统的动态性能有很高要求。自主飞行实验结果如图9所示, 由图9可以看出, 驱动系统能很好地满足自主飞行需要, 即使374.5 s飞行器前飞时由于阵风干扰前飞速度出现1.4 m/s控制误差的情况下, 驱动系统也能快速响应, 并在2 s内通过姿态调整恢复前飞。整个飞行过程中, 轨迹跟踪均方根误差为0.58 m, 远小于GPS误差 (2.5 m RMS) 。

4 结束语

本研究给出了一个完整的四旋翼无人飞行器驱动系统设计与实现方案, 在此基础上通过系统辨识实验建立了旋翼升力的动态模型并对系统进行了综合的性能测试。

实验结果表明, 本研究设计的驱动系统动态带宽大于10 rad/s, 且在每个旋翼300克升力输出时效率高达9 g/W, 航线跟踪均方根误差为0.58 m, 完全满足四旋翼无人飞行器自主飞行控制的需要, 大量的飞行实验也验证了其稳定性。

参考文献

[1]王璐, 李光春, 王兆龙, 等.欠驱动四旋翼无人飞行器的滑模控制[J].哈尔滨工程大学学报, 2012, 33 (10) :1248-1253.

[2]NICOL C, MACNAB C J B, RAMIREZ-SERRANO A.Ro-bust adaptive control of a quadrotor helicopter[J].Mechatronics, 2011, 21 (6) :927-938.

[3]HOFFMANN G M, HUANG H, WASLANDER S L, et al.Precision flight control for a multi-vehicle quadrotor heli-copter testbed[J].Control Engineering Practice, 2011, 19 (9) :1023-1036.

[4]唐懋.基于Arduino兼容的Stm32单片机的四旋翼飞行器设计[D].厦门:厦门大学自动化系, 2014.

[5]刘乾, 孙志锋.基于ARM的四旋翼无人飞行器控制系统[J].机电工程, 2011, 28 (10) :1237-1240.

[6]孔天恒.基于Radar-scanner/INS的微小型旋翼无人机室内组合导航与控制的研究[D].杭州:浙江大学信息学院, 2014.

[7]许云清.四旋翼飞行器飞行控制研究[D].厦门:厦门大学自动化系, 2014.

[8]LEISHMAN J G.Principles of Helicopter Aerodynamics[M].New York:Cambridge University Press, 2000.

[9]XU Yu, REN Qin-yuan, SUN Wen-da, et al.Design andImplementation of Low Cost Integrated Navigation Systemfor Mini Autonomous Helicopter[C]//World Congress on In-telligent Control and Automation.Jinan:IEEE, 2010:6842-6847.