基于模型的自动化测试工具的实现.docx
《基于模型的自动化测试工具的实现.docx》由会员分享，可在线阅读，更多相关《基于模型的自动化测试工具的实现.docx（30页珍藏版）》请在冰豆网上搜索。
基于模型的自动化测试工具的实现
基于模型的自动化测试工具的实现
摘要
基于模型的测试是
本文首先介绍了Atmel-View框架以及菜单系统UI在其中所将扮演的角色、与各个功能模块间的关系。
其次讲解了Atmel-View内存映射窗口结合OSD应用的UI设计思想，涉及了多图层表现的想法，硬件OSD与伪OSD的比较使用。
然后详细阐述了基于Atmel-View的菜单系统方案和框架结构，针对最重要的MenuMode菜单构建函数分析其数据抽象、界面绘制和事件响应处理过程。
其后介绍NucleusPlus，给出进程通信、进程同步在菜单系统中支持蓝牙模块的应用方法。
本方案的实现提供了一套层次化、结构化、可扩展的电子相框菜单系统，并有效支持了蓝牙模块的应用。
关键词：
OSD，内存映射窗口，菜单系统，UI
FULFILLUIOFDIGITALPHOTOFRAME
BASEDONATMEL-VIEW
ABSTRACT
AtmelCorporation'sAtmel-ViewistheapplicationforboardAT76C120,ithasalreadyprovidedlowlevelrealizationfordigitalphotoframe,anditcouldbeanextendableandmaturesolution.BasedoncurrentfunctionsofAtmel-View,wewilldesignandfulfilltheMenuSystem.
FirstlytheframeworkofAtmel-View,whichroleMenuSystemUIactsandhowitrelateswithotherfunctionmoduleswereintroducedinthispaper.ThentheconceptofSDRAM-MappingWindowwithOSD'susagewasproposed.ItreferredtotheideaofmultipleimagelayerinterfaceandthecomparisontheusageofhardwareOSDandPseudoOSD.ThenthedetailsofMenuSystem'sframeworkwereillustrated.Theprocessofdataabstraction,interfacedrawingandeventhandlingwereanalyzedforthemostimportantMenubuildingfunctionMenuMode.AfterthatNucleusPluswasintroducedandthemethodtouseprocesscommunication,processsynchronizationforsupportingBluetoothmoduleinMenuSystemwasgiven.TheUIsolutionprovidesalayered,structuralandextendableMenuSystemfordigitalphotoframe.AnditeffectivelysupportsBluetoothmodule.
Keywords:
OSD,SDRAM-MappingWindow,MenuSystem,UI
第一章绪论
1.1.软件测试简介
随着电子信息化的飞速发展，计算机软件已经遍布于人类社会的各个角落，远至月球探测卫星的发射系统，近至个人携带的MP3音乐播放器。
但是软件带来巨大便利的同时，软件中的任何微小缺陷也可能带来难以估量的损失。
据美国国家标准技术研究院（NIST）2002年公布的一份研究报告显示，软件故障平均每年对美国经济造成的损失约为595亿美元，占其国民生产总值的0.6%[1]。
因此，如何保证软件的质量显得尤为关键。
软件测试能够有效地帮助软件开发人员找出系统中存在的错误，从而在很大程度上保证软件的质量。
现代软件工程理论将软件测试作为软件开发过程的重要组成部分，软件开发过程中有一半以上的资源都花费在软件测试上。
早期的软件测试等同于程序调试，1957年CharlesBaker才正式将两者区别开来，他认为调试侧重于保证程序运行，而测试侧重于保证程序解决问题[2]。
1979年Myers提出“测试是带有发现错误意图去执行程序的过程”[3]，越是发现了错误才说明测试过程的成功。
1983年美国国家标准局（NBS）发表了评估软件生命周期各阶段的测试方法[4]，同年美国电气和电子工程师协会（IEEE）发布了八大软件测试相关文档的标准[5]，人们开始利用这些评估标准来衡量测试软件的质量。
1988年DavidGelperin等在书中写道，“测试是为了证明软件符合需求规约，发现缺陷和防止错误”[6]。
时间
测试阶段
-1956
面向调试时期
1957-1978
面向论证时期
1979-1982
面向破坏时期
1983-1987
面向评估时期
1988-now
面向防止时期
表1-1测试的发展阶段[6]
测试不可能遍历所有可能出现的情况，必须在适当的时候终止测试。
如果一味地追求缺陷数量，很可能得不偿失。
常用的判断标准有：
代码覆盖率、测试用例通过率、缺陷数量收敛率等等。
图1-1缺陷数量收敛图
1.2.软件测试工具发展现状
纯手工地进行软件测试往往是费时费力的，而且测试人员容易因为疏忽产生失误，测试准确性无法得到足够的保证。
于是人们需要开发一些自动化工具来管理或者执行测试过程，虽然编写软件测试工具需要引入额外的工作量，但是软件测试工具能大大提高软件测试的效率和质量，并且市面上也已经存在着许多现成的测试工具。
名称
产商
简介
WinRunner
MercuryInteractive
支持自动录制、检测和回放用户操作
LoadRunner
MercuryInteractive
模拟大量并发负载来预测系统性能
TestDirector
MercuryInteractive
基于Web的测试管理系统
Robot
IBM
具有测试和管理的双重功能
xUnit
\
最流行的开源单元测试框架
SilkTest
Borland
软件功能测试工具
WAS
Microsoft
强大的网站压力测试工具
JTest
Parasoft
针对Java语言的自动化白盒测试工具
JMeter
Apache
100%用Java实现的功能和性能测试工具
WebLoad
RadView
Web性能测试和分析工具
表1-2常用软件测试工具
一般来说，自动化测试可以分为：
基于代码的测试和基于图形化用户界面的测试。
基于代码的测试是指通过程序提供的公共接口，直接验证各个类、库和模块在不同的输入情况下返回结果的正确性与否，如xUnit系列框架。
而基于图形化用户界面的测试则是通过模拟用户动作行为（比如键盘输入、鼠标点击），产生某些事件来观察和判断程序响应是否满足预期，如WinRunner。
绝大部分软件测试工具并不能自动完成整个测试过程，测试人员依然需要事先编写好测试脚本或测试用例，即一组测试输入、执行条件和预期结果。
测试用例能够被快速和反复地执行，方便地使得发现的软件错误重现。
当测试本身就需要多次重复时（比如回归测试、压力测试），其优点将更加显著。
基于模型的测试（MBT,Model-BasedTesting）是一种轻量级自动生成测试用例的方法，测试人员的关注点在于构建一个能够描述被测系统各方面数据和行为的形式化机器可读模型。
为了抽象出理想的模型可能需要花费一定的时间，但是模型构建的工作可以在软件开发生命周期的早期就开始，只要求被测系统的需求定义完成即可。
而且往往在将非形式化的需求转化为形式化的模型过程中，需求中的遗漏和不足部分将被发现。
模型所带来的回报也是巨大的，因为一旦模型被确立且其能够准确反映被测系统的真实需求，软件测试工具就能够分析模型自动得到测试用例。
软件测试的主要目的就是发现错误。
事实证明，MBT确实具有很强的错误发现能力。
IBM公司和BMW公司的研究表明，MBT发现的错误和手工设计的测试集发现的错误数量差不多。
而微软公司的某一应用中，MBT发现了多10倍的错误[14]。
其它的一些研究结果中（如图1-2），和人工测试相比MBT都是发现更多或者相同数量的错误。
当然MBT也不是万能的，它发现错误的能力很大程度上依赖于建模和选择测试用例选择要求人员的水平。
图1-2各种测试方法整个测试过程的花费时间图[14]
MBT能否降低测试的花费和时间，取决于建立和维护模型加上生成测试用例花费的时间是否比其它方法设计和维护测试集所需要的时间少，通常情况下答案是肯定的。
而且MBT可以提高测试效率，因为人工测试受限于测试人员的思维活跃程度，MBT使用的测试用例生成算法和启发式用例选择机制能够快速生成大量测试用例，达到对模型更高的覆盖率却仅需要多花费少量运行测试用例生成程序的时间。
如果SUT支持大规模地测试，MBT必然将发现更多的错误。
有时侯测试用例没有通过，并不是因为程序编写的错误，而是因为系统需求定义存在错误。
其它形式的软件测试一般无法发现此类错误，但是MBT可以。
我们知道，软件开发中的错误越早发现需要付出的修复代价越小，MBT把一些错误扼杀在需求阶段，贡献无疑是巨大的。
此外，MBT具有良好的应付软件需求变更的能力。
传统的测试方法很可能需要重新设计编写所有测试用例，MBT只需要调整模型后再自动生成测试用例。
凡事有利必有弊，好的模型可以让测试过程一帆风顺，模型也给测试过程带来了许多问题。
实施MBT的测试人员需要具有比普通测试人员更强的系统抽象能力，因为SUT很可能并不容易建模。
当MBT的测试用例没有通过时，测试人员无法断定是SUT存在错误还是建模存在错误，增加了错误分析的代价。
传统的人工测试的测试用例都是依据系统需求定义的，MBT的测试用例生成算法难免产生一些无效冗余的测试用例，测试用例通过率不再是衡量软件测试效率的有效标准。
认识到这些MBT的不足之处，我们才能更加正确地利用MBT。
目前代表性的支持MBT的测试工具有：
IBM公司的GOTCHA-TCBeans软件测试套件，面向Java、C/C++语言编写的应用程序接口（API,ApplicationProgramInterfaces）和软件协议[7]；微软公司的SpecExplorer工具，具有创建软件行为模型、可视化分析模型、验证模型有效性和根据模型生成测试用例等功能[8]；“净室”公司的CleanTest，主要用于净室软件工程中使用的统计测试过程[9]。
此外，军方也积极尝试MBT技术，比如美国海军水面战中心开发的SMERFS[10]和CASRE[11]。
1.3.项目背景和论文结构
1.3.1.项目背景
本课题来源于作者实习所在的微软公司，旨在遵照基于模型的软件测试理论开始实现一款自动化测试工具，该工具能够支持有限状态机模型的输入，然后自动生成抽象测试用例。
用户填充实现完整的测试用例后，此工具能执行测试用例并给出测试报告。
该测试工具将被主要用于微软公司SCCM系统的基于角色权限控制（RBAC，Role-BasedAccessControl）功能的测试。
特别地，在测试用例生成过程中算法需要结合参数配对组合测试技术，尽可能缩减测试用例数目却又不影响测试质量。
因为与传统的单纯正交排列组合测试相比，配对组合测试技术具有较大的优越性。
1.3.2.论文结构
本文第二章主要介绍MBT测试技术，依照MBT测试的一般流程来说明工具使用的模型表现形式、测试用例生成算法和预期输出的生成。
第三章介绍系统的总体架构和简要阐述系统各模块的功能。
第四章使用类图和算法伪代码详细讨论系统的设计和实现。
第五章通过一个虚构的自动取款机（ATM，AutomaticTellerMachines）系统来演示如何使用我们完成的工具进行MBT测试。
最后作简要的总结及展望。
第二章基于模型的测试
2.
2.1.MBT一般操作流程
基于模型的测试依赖于三项关键技术：
模型的表现形式、测试用例的生成算法和产生其它辅助性内容（包括预期结果）的工具[12]。
模型是MBT技术的核心，不同领域的不同软件系统适用的模型表现形式都不尽相同，测试人员应该结合被测系统的工作特点和自身对模型的熟悉程度来慎重选择。
如果没有使用正确的模型表现形式，会拖累影响整个测试流程。
针对各个不同的模型表现形式，如今已有许多测试用例算法与之对应，我们可以在实际应用过程中灵活地借鉴参考来设计自己的算法。
至于产生其它辅助性内容的工具，它在不同项目之间不具有可移植性，只有根据不同项目来专门设计实现。
图2-1MBT一般操作流程[13]
上图展示了MBT的一般操作流程。
首先在系统需求或者规约文档的基础上建立某种形式的模型（步骤1），模型说明了系统所有的潜在行为意图。
接下来需要定义测试用例的选择要求（步骤2），形成测试用例规约（步骤3），编写算法将其应用于模型之上来生成测试用例（步骤4）。
然后在被测系统（SUT，SystemUnderTest）环境中真正执行所有测试用例（步骤5-1），可以利用测试脚本来自动化执行测试，最终得到测试结果（步骤5-2）。
2.2.MBT模型表现形式
理想的模型需要容易被测试人员理解，能够把大的复杂的问题描述成小的简单的系统，最好还是以一种测试用例生成工具方便识别的形式。
想要同时满足以上所有的特性是很困难的，但是可以把几种不同的模型整合成一个，扬长避短地得到理想模型。
在MBT中使用过的模型可能有几十甚至上百种，我们不可能也没有必要去逐一了解，MarkUtting和BrunoLegeard把它们大致分为以下几种[14]：
类型
示例
基于Pre/Post
B、OCL、JML、Spec#、Z
基于转换
FSM、状态图、UML状态机
统计式
马尔可夫链
基于历史
消息队列图、UML顺序图
函数式
HOL系统
操作式
Petri网
数据流式
Lustre、块状图
表2-1MBT模型分类
基于转换的模型是我们最为熟悉的模型类型，它们集中于描述系统在不同状态之间的转换过程。
通常是以节点和弧线的形式出现，节点代表系统的状态，弧线代表系统的动作或操作。
有限状态机（FSM，FiniteStateMachine）模型可以被认为是该类模型的鼻祖，是极其重要的一种模型表现形式。
图2-2是一个描述了门的四种不同状态及其转换关系的FSM。
Harel在FSM的基础上添加了层次、并发和交流概念，扩展成了状态图模型[15]，从而在面对复杂系统时也能够轻松建立模型。
之后又有人删去了Harel的状态图模型中的部分特性，同时增加了一些新的特性，形成了统一建模语言（UML，UnifiedModelingLanguage）状态机模型。
UML状态机模型用于定义类之间状态相关的行为，包括方法调用和数据域的修改。
图2-2FSM示例
我们工具主要面向的是RBAC功能的测试，频繁关心具有不同权限的不同角色所能执行的操作。
把系统抽象为变量集合和修改这些变量操作的基于Pre/Post的模型需要测试人员预先学习一段时间才能完全掌握，所以基本不予考虑。
我们也并不需要描述系统行为随着时间变化的变化情况，RBAC测试中不涉及分布式并发操作，侧重关心系统控制流而不是数据流，可见基本的FSM模型就已经满足相关要求。
而且FMS模型也最为简便，测试工具识别起来没有任何问题，降低了编写测试工具的难度，测试人员构建模型时可以从SUT设计文档中的UML状态图稍加变化直接转化而来。
如果以后需要额外考虑系统事件和测试输入的概率分布，只需要为每个状态之间的迁移动作增加概率相关属性，非常轻松地支持统计式模型。
2.3.MBT测试用例生成
软件测试过程中的执行和监督过程已经可以使用现代化的自动测试工具代替完成，至于如何生成测试用例，依然是一件棘手的事情。
MBT中使用的测试用例生成方法主要依赖于所使用的模型表现形式，针对不同的模型表现形式，研究者分别想出了一些解决方案。
如果系统的模型是由一系列逻辑表达式所组成的，那么可以使用定理证明的方法。
定理证明方法原先是被用于自动证明数学公式，MBT生成测试用例时根据逻辑表达式的有效说明把模型划分为不同等价类，每个等价类描述了SUT的某一行为。
这些等价类就可以用于生成测试用例，最简单的划分方法是析取范式的方法。
当需要为程序的特定执行路径寻找输入时，沿着路径使用符号执行的方法，结合途中遇到的一些分支断言，我们可以求出预期输入所需要满足的约束。
于是可以用各种约束来建立MBT的模型，收集不同执行路径中数据约束再利用约束编程中的方法求解得到测试用例。
其中约束编程是一种通过约束来描述变量间关系的编程方法，求解约束的方法有布尔式求解方法和数值分析方法。
MBT自然还会让人想到模型检测，即检测模型是否满足特定的属性。
无论检测结果是满足属性还是违背属性，都可以形成测试用例。
但是一般来说反例的作用更大，因为测试用例中的各种断言正是通过反例来生成的，从而有效地识别出系统是否正常工作。
模型检测会遇到的问题是，生成的用例中存在过多冗余用例,导致软件测试执行的代价增加。
为此，Hamon等人详细讨论提出了高效模型检测的方法[16]。
类似于描述程序所有可执行路径的控制流和描述程序所有变量定义和内存使用的数据流，事件流模型描述的是GUI上所有可执行的事件序列。
通常情况下，GUI又可以分为不同的层次结构，比如整个GUI系统是由各种对话框所组成的，那么系统的事件流图就是由对话框各自的事件流图组成的。
把复杂系统拆分为相对独立的组件单独分析，也是所有MBT测试用例生成方法通用的窍门。
马尔可夫链也是MBT中生成测试用例的重要方法之一，它由两大部件组成：
代表系统所有使用场景的FSM和评价FSM来说明系统统计性使用信息的操作说明。
马尔可夫链模型为MBT提供了测试的侧重点，即着重测试那些用户经常使用的功能。
因为对于系统中那些极少概率出现的错误，是几乎不可能被发现的。
我们选用的是FSM模型，所以可以利用图论中的一些遍历方法，比如广度优先遍历算法或者深度优先遍历算法，每找到的一条可执行路径对应于一个测试用例。
当FSM包含的状态比较多时，遍历组成FSM有向图产生的测试用例数量可能太多，不仅难以测试包含冗余测试用例。
可以通过指定初始遍历节点和限定路径长度的方法来减少生成测试用例的数量，但是更好的是下面介绍的组合测试。
软件开发者和用户经常还会遇到这样的问题，把同样的软件应用从一台机器换到另外一台机器上使用时，原先从未出过故障的软件突然变得无法正常使用。
问题有许多可能的影响因素，比如跟软件安装所在机器的操作系统类型有关，或者是系统物理内存的大小，甚至网卡型号等等。
除了硬件环境的不同，软件接受的输入参数也很可能不同，比如同一款Web应用发布后，不同国家的用户将会输入不同编码的内容。
软件能否经得住各种条件下的考验，是软件测试需要解决的问题。
当然，最简单和理想的情况下是把所有可能出现的硬件配置和参数取值都测试一遍。
但是现实并不允许测试人员这么做，因为造成的测试用例数量是指数性爆炸增长的，N个分别有M种取值的影响因素将需要MN个测试用例来完成测试。
后来人们发现通过巧妙地选取测试用例，只要求某些参数的组合情况被包含，能够在保证测试效率的同时大大缩减测试用例数量。
该理论是基于以下事实的，软件中的错误大部分都是由单个参数所导致的，一般最多是由两个参数相互作用而触发，三个或三个以上的情况几乎没有。
如果测试用例集包含了任意t个参数的所有取值组合，那么称该测试用例集组合强度为t，或者说它是t-way的。
图2-3不同组合强度下的错误发现率
图2-3是NIST报告中总结的几个应用使用不同组合强度的测试用例集测试后的错误发现率曲线[17]。
我们可以看出，随着组合强度的增加，错误发现率显著增长。
以NASA应用为例，67%的错误由单个参数触发，93%由两个参数相互作用后触发，98%由三个参数一起造成。
其它应用的错误发现率曲线也都比较相像，组合强度等于4到6时错误发现率都达到了将近100%。
特别的，生成2-way的测试用例集的方法被称为pair-wise（或all-pairs）测试方法。
目前pair-wise是使用最普遍的组合测试技术，因为软件中的绝大部分错误都只由一个或两个参数造成，pair-wise生成的测试用例能够覆盖足够的错误空间。
使用pair-wise技术后，总测试用例数目从原来的MN下降到了约M*N。
至于生成高组合强度的测试用例，测试用例集发现错误的能力没有实质上的提高，却会导致生成算法的更加复杂化和产生多得多的测试用例。
最坏的情况下，当组合强度和参数的数目相等时，组合测试退化为枚举测试。
组合测试的最早提出，也就是为了简化软件在各种配置环境下的测试。
因为牵涉到硬件环境的搭建，配置参数测试中每增加一种测试情况比单纯地多写一个测试用例所花的代价大得多。
人们迫切需要解决这一问题，使得配置参数测试成为了组合测试中最为发达的形式，尤其在那些要求适应不同硬件平台和环境的软件的测试过程中。
考虑一款受5个配置因素影响的应用：
操作系统（WindowsXP、AppleOSX、RedHatEnterpriseLinux），浏览器（IE、FireFox），网络协议（IPv4、IPv6），处理器平台（Intel、AMD）和数据库（MySQL、Sybase、Oracle），一共3·2·2·2·3=72种硬件平台。
pair-wise测试只需要设计如下10个测试，就覆盖了每一种影响因素和另外一种影响因素的所有组合。
编号
操作系统
浏览器
网络协议
处理器平台
数据库
1
XP
IE
IPv4
Intel
MySQL
2
XP
FireFox
IPv6
AMD
Sybase
3
XP
IE
IPv6
Intel
Oracle
4
OSX
FireFox
IPv4
AMD
MySQL
5
OSX
IE
IPv4
Intel
Sybase
6
OSX
FireFox
IPv4
Intel
Oracle
7
RHEL
IE
IPv6
AMD
MySQL
8
RHEL
FireFox
IPv4
Intel
Sybase
9
RHEL
FireFox
IPv4
AMD
Oracle
10
OSX
FireFox
IPv6
AMD
Oracle
表2-2pair-wise测试的配置
即使被测软件没有配置选项，软件仍要处理一些输入。
例如，Word2010应用程序至少允许用户对拖黑文字进行10种不同操作：
设为上标、设为下标、加粗、加下划线、设为斜体、加删除线、加灰色背景、加阴影效果、加倒影效果、加荧光效果。
相关的字体处理函数需要根据用户的输入来相应修改文字效果，该函数需要在所有的可能情况下都正常工作，而一共有210=1024种可能。
前面的经验告诉我们，3-way的测试用例就能够达到90%以上的错误发现率，具有较高的收益-代价比。
图2-43-way覆盖数组
图2-4列出了对于具有10个变量、每个变量各有两种取值的3-way覆盖数组。
覆盖
升级会员 