1、 基于模型的自动化测试工具的实现基于模型的自动化测试工具的实现摘要基于模型的测试是本文首先介绍了 Atmel-View 框架以及菜单系统 UI 在其中所将扮演的角色、与各个功能模块间的关系。其次讲解了 Atmel-View 内存映射窗口结合 OSD 应用的 UI 设计思想，涉及了多图层表现的想法，硬件 OSD 与伪 OSD 的比较使用。然后详细阐述了基于 Atmel-View 的菜单系统方案和框架结构，针对最重要的 MenuMode 菜单构建函数分析其数据抽象、界面绘制和事件响应处理过程。其后介绍 Nucleus Plus，给出进程通信、进程同步在菜单系统中支持蓝牙模块的应用方法。本方案的实现
2、提供了一套层次化、结构化、可扩展的电子相框菜单系统，并有效支持了蓝牙模块的应用。关键词：OSD，内存映射窗口，菜单系统，UI基于模型的自动化测试工具的实现FULFILL UI OF DIGITAL PHOTO FRAMEBASED ON ATMEL-VIEWABSTRACTAtmel Corporations Atmel-View is the application for board AT76C120, it has already provided low level realization for digital photo frame, and it could be an exte
3、ndable and mature solution. Based on current functions of Atmel-View, we will design and fulfill the Menu System.Firstly the framework of Atmel-View, which role Menu System UI acts and how it relates with other function modules were introduced in this paper. Then the concept of SDRAM- Mapping Window
4、 with OSDs usage was proposed. It referred to the idea of multiple image layer interface and the comparison the usage of hardware OSD and Pseudo OSD. Then the details of Menu Systems framework were illustrated. The process of data abstraction, interface drawing and event handling were analyzed for t
5、he most important Menu building function MenuMode. After that Nucleus Plus was introduced and the method to use process communication, process synchronization for supporting Bluetooth module in Menu System was given. The UI solution provides a layered, structural and extendable Menu System for digit
6、al photo frame. And it effectively supports Bluetooth module.Key words: OSD, SDRAM-Mapping Window, Menu System, UI基于模型的自动化测试工具的实现目 录第一章 绪论 .11.1. 软件测试简介 .11.2. 软件测试工具发展现状 .21.3. 项目背景和论文结构 .41.3.1. 项目背景 41.3.2. 论文结构 4第二章 基于模型的测试 .52.1. MBT 一般操作流程 .52.2. MBT 模型表现形式 .62.3. MBT 测试用例生成 .72.4. MBT 预期输出生成
7、.10第三章 系统架构 123.1. 功能概述及流程 .123.2. 系统架构 .12第四章 系统各功能实现 12第五章 实例分析：ATM 系统 12第六章 结论及展望 12参考文献 .13基于模型的自动化测试工具的实现第 1 页 共 13 页第一章 绪论1.1. 软件测试简介随着电子信息化的飞速发展，计算机软件已经遍布于人类社会的各个角落，远至月球探测卫星的发射系统，近至个人携带的 MP3 音乐播放器。但是软件带来巨大便利的同时，软件中的任何微小缺陷也可能带来难以估量的损失。据美国国家标准技术研究院（NIST）2002 年公布的一份研究报告显示，软件故障平均每年对美国经济造成的损失约为 59
8、5 亿美元，占其国民生产总值的 0.6% 1 。因此，如何保证软件的质量显得尤为关键。软件测试能够有效地帮助软件开发人员找出系统中存在的错误，从而在很大程度上保证软件的质量。现代软件工程理论将软件测试作为软件开发过程的重要组成部分，软件开发过程中有一半以上的资源都花费在软件测试上。早期的软件测试等同于程序调试，1957 年 Charles Baker 才正式将两者区别开来，他认为调试侧重于保证程序运行，而测试侧重于保证程序解决问题 2。1979 年 Myers 提出“测试是带有发现错误意图去执行程序的过程” 3，越是发现了错误才说明测试过程的成功。1983 年美国国家标准局（NBS）发表了评估
9、软件生命周期各阶段的测试方法 4，同年美国电气和电子工程师协会（IEEE）发布了八大软件测试相关文档的标准 5，人们开始利用这些评估标准来衡量测试软件的质量。1988 年 David Gelperin 等在书中写道， “测试是为了证明软件符合需求规约，发现缺陷和防止错误” 6。时间 测试阶段-1956 面向调试时期1957-1978 面向论证时期1979-1982 面向破坏时期1983-1987 面向评估时期1988- now 面向防止时期表 1-1 测试的发展阶段 6测试不可能遍历所有可能出现的情况，必须在适当的时候终止测试。如果一味地追求缺陷数量，很可能得不偿失。常用的判断标准有：代码覆盖
10、率、测试用例通过率、缺陷数量收敛率等等。基于模型的自动化测试工具的实现第 2 页 共 13 页图 1-1 缺陷数量收敛图1.2. 软件测试工具发展现状纯手工地进行软件测试往往是费时费力的，而且测试人员容易因为疏忽产生失误，测试准确性无法得到足够的保证。于是人们需要开发一些自动化工具来管理或者执行测试过程，虽然编写软件测试工具需要引入额外的工作量，但是软件测试工具能大大提高软件测试的效率和质量，并且市面上也已经存在着许多现成的测试工具。名称 产商 简介WinRunner Mercury Interactive支持自动录制、检测和回放用户操作LoadRunner Mercury Interacti
11、ve模拟大量并发负载来预测系统性能TestDirector Mercury Interactive基于 Web 的测试管理系统Robot IBM 具有测试和管理的双重功能xUnit 最流行的开源单元测试框架SilkTest Borland 软件功能测试工具WAS Microsoft 强大的网站压力测试工具JTest Parasoft 针对 Java 语言的自动化白盒测试工具JMeter Apache 100%用 Java 实现的功能和性能测试工具WebLoad RadView Web 性能测试和分析工具表 1-2 常用软件测试工具一般来说，自动化测试可以分为：基于代码的测试和基于图形化用户界面
12、的测试。基于代码的测试是指通过程序提供的公共接口，直接验证各个类、库和模块在不同的输入情况下返回结果的正确性与否，如 xUnit 系列框架。而基于图形化用户界面的测试则是通过模拟用户动作行为（比如键盘输入、鼠标点击） ，产生某些事件来观察和判断程序响应是否满足预期，如 WinRunner。绝大部分软件测试工具并不能自动完成整个测试过程，测试人员依然需要事先编写好测试脚本或测试用例，即一组测试输入、执行条件和预期结果。测试用例能够被快速和反复地执行，方便地使得发现的软件错误重现。当测试本身就需要多次重复时（比如回归测试、压力测试） ，其优点将更加显著。基于模型的测试（MBT, Model-Bas
13、ed Testing）是一种轻量级自动生成测试用例的方法，测试人员的关注点在于构建一个能够描述被测系统各方面数据和行为的形式化机器可读模型。为了抽象出理想的模型可能需要花费一定的时间，但是模型构建的工作可以在软件开发生命周期的早期就开始，只要求被测系统的需求定义完成即可。而且往往在将非形式化的需求转化为形式化的模型过程中，需求中的遗漏和不足部分将被发现。模型所带来的回报也是巨大的，因为一旦模型被确立且其能够准确反映被测系统的真实需求，软件测试工具就能够分析模型自动得到测试用例。软件测试的主要目的就是发现错误。事实证明，MBT 确实具有很强的错误发现能力。IBM 公司和 BMW 公司的研究表明，
14、MBT 发现的错误和手工设计的测试集发现的错误数量差不多。而微软公司的某一应用中，MBT 发现了多 10 倍的错误 14。其它的一些研究结果中（如图 1-2） ，和人工测试相比 MBT 都是发现更多或者相同数量的错误。当然 MBT 也不是万基于模型的自动化测试工具的实现第 3 页 共 13 页能的，它发现错误的能力很大程度上依赖于建模和选择测试用例选择要求人员的水平。图 1-2 各种测试方法整个测试过程的花费时间图 14MBT 能否降低测试的花费和时间，取决于建立和维护模型加上生成测试用例花费的时间是否比其它方法设计和维护测试集所需要的时间少，通常情况下答案是肯定的。而且MBT 可以提高测试效
15、率，因为人工测试受限于测试人员的思维活跃程度，MBT 使用的测试用例生成算法和启发式用例选择机制能够快速生成大量测试用例，达到对模型更高的覆盖率却仅需要多花费少量运行测试用例生成程序的时间。如果 SUT 支持大规模地测试，MBT 必然将发现更多的错误。有时侯测试用例没有通过，并不是因为程序编写的错误，而是因为系统需求定义存在错误。其它形式的软件测试一般无法发现此类错误，但是 MBT 可以。我们知道，软件开发中的错误越早发现需要付出的修复代价越小，MBT 把一些错误扼杀在需求阶段，贡献无疑是巨大的。此外， MBT 具有良好的应付软件需求变更的能力。传统的测试方法很可能需要重新设计编写所有测试用例
16、，MBT 只需要调整模型后再自动生成测试用例。凡事有利必有弊，好的模型可以让测试过程一帆风顺，模型也给测试过程带来了许多问题。实施 MBT 的测试人员需要具有比普通测试人员更强的系统抽象能力，因为 SUT 很可能并不容易建模。当 MBT 的测试用例没有通过时，测试人员无法断定是 SUT 存在错误还是建模存在错误，增加了错误分析的代价。传统的人工测试的测试用例都是依据系统需求定义的，MBT 的测试用例生成算法难免产生一些无效冗余的测试用例，测试用例通过率不再是衡量软件测试效率的有效标准。认识到这些 MBT 的不足之处，我们才能更加正确地利用MBT。目前代表性的支持 MBT 的测试工具有：IBM
17、公司的 GOTCHA-TCBeans 软件测试套件，面向 Java、C/C+语言编写的应用程序接口（API, Application Program Interfaces）和软件协议 7；微软公司的 Spec Explorer 工具，具有创建软件行为模型、可视化分析模型、基于模型的自动化测试工具的实现第 4 页 共 13 页验证模型有效性和根据模型生成测试用例等功能 8；“净室”公司的 CleanTest，主要用于净室软件工程中使用的统计测试过程 9。此外，军方也积极尝试 MBT 技术，比如美国海军水面战中心开发的 SMERFS10和 CASRE11。1.3. 项目背景和论文结构1.3.1.
18、项目背景本课题来源于作者实习所在的微软公司，旨在开发遵照基于模型的软件测试理论实现一款自动化测试工具，能够支持有限状态机模型的输入，然后自动生成抽象测试用例。用户填充实现完整的测试用例后，此工具能执行测试用例并给出测试报告。该测试工具将被主要用于测试微软公司 SCCM 系统的基于角色权限控制（RBAC， Role-Based Access Control）功能。特别地，在测试用例生成过程中算法需要结合参数配对组合测试技术，尽可能缩减测试用例数目却又不影响测试质量。因为与传统的单纯正交排列组合测试相比，配对组合测试技术具有较大的优越性。1.3.2. 论文结构本文第二部分主要介绍 MBT 相关技术
19、，包括其一般流程、注意事项和几种常用的模型。第三部分介绍参数组合测试，重点在于 Pair-wise 技术。第四部分详细阐述系统的设计和实现。第五部分以测试 ATM 取款机系统为例，演示完成的工具如何工作。最后作简要的总结及展望。基于模型的自动化测试工具的实现第 5 页 共 13 页第二章 基于模型的测试MBT 一般操作流程基于模型的测试依赖于三项关键技术：模型的表现形式、测试用例的生成算法和产生其它辅助性内容（包括预期结果）的工具 12。模型是 MBT 技术的核心，不同领域的不同软件系统适用的模型表现形式都不尽相同，测试人员应该结合被测系统的工作特点和自身对模型的熟悉程度来慎重选择。如果没有使
20、用正确的模型表现形式，会拖累影响整个测试流程。针对各个不同的模型表现形式，如今已有许多测试用例算法与之对应，我们可以在实际应用过程中灵活地借鉴参考来设计自己的算法。至于产生其它辅助性内容的工具，它在不同项目之间不具有可移植性，只有根据不同项目来专门设计实现。图 2-1 MBT 一般操作流程 13上图展示了 MBT 的一般操作流程。首先在系统需求或者规约文档的基础上建立某种形式的模型（步骤 1） ，模型说明了系统所有的潜在行为意图。接下来需要定义测试用例的选择要求（步骤 2） ，形成测试用例规约（步骤 3） ，编写算法将其应用于模型之上来生成测试用例（步骤 4） 。然后在被测系统（SUT， Sy
21、stem Under Test）环境中真正执行所有测试用例（步骤 5-1） ，可以利用测试脚本来自动化执行测试，最终得到测试结果（步骤 5-2） 。基于模型的自动化测试工具的实现第 6 页 共 13 页2.2. MBT 模型表现形式理想的模型需要容易被测试人员理解，能够把大的复杂的问题描述成小的简单的系统，最好还是以一种测试用例生成工具方便识别的形式。想要同时满足以上所有的特性是很困难的，但是可以把几种不同的模型整合成一个，扬长避短地得到理想模型。在 MBT 中使用过的模型可能有几十甚至上百种，我们不可能也没有必要去逐一了解，Mark Utting 和Bruno Legeard 把它们大致分为
22、以下几种 14：类型 示例基于 Pre/Post B、OCL、JML、Spec#、Z基于转换 FSM、状态图、UML 状态机统计式 马尔可夫链基于历史 消息队列图、UML 顺序图函数式 HOL 系统操作式 Petri 网数据流式 Lustre、块状图表 2-1 MBT 模型分类基于转换的模型是我们最为熟悉的模型类型，它们集中于描述系统在不同状态之间的转换过程。通常是以节点和弧线的形式出现，节点代表系统的状态，弧线代表系统的动作或操作。有限状态机（FSM， Finite State Machine）模型可以被认为是该类模型的鼻祖，是极其重要的一种模型表现形式。图 2-2 是一个描述了门的四种不同
23、状态及其转换关系的FSM。Harel 在 FSM 的基础上添加了层次、并发和交流概念，扩展成了状态图模型 15，从而在面对复杂系统时也能够轻松建立模型。之后又有人删去了 Harel 的状态图模型中的部分特性，同时增加了一些新的特性，形成了统一建模语言（UML，Unified Modeling Language）状态机模型。UML 状态机模型用于定义类之间状态相关的行为，包括方法调用和数据域的修改。图 2-2 FSM 示例基于模型的自动化测试工具的实现第 7 页 共 13 页我们工具主要面向的是 RBAC 功能的测试，频繁关心具有不同权限的不同角色所能执行的操作。把系统抽象为变量集合和修改这些变
24、量操作的基于 Pre/Post 的模型需要测试人员预先学习一段时间才能完全掌握，所以基本不予考虑。我们也并不需要描述系统行为随着时间变化的变化情况，RBAC 测试中不涉及分布式并发操作，侧重关心系统控制流而不是数据流，可见基本的 FSM 模型就已经满足相关要求。而且 FMS 模型也最为简便，测试工具识别起来没有任何问题，降低了编写测试工具的难度，测试人员构建模型时可以从 SUT 设计文档中的 UML 状态图稍加变化直接转化而来。如果以后需要额外考虑系统事件和测试输入的概率分布，只需要为每个状态之间的迁移动作增加概率相关属性，非常轻松地支持统计式模型。2.3. MBT 测试用例生成软件测试过程中
25、的执行和监督过程已经可以使用现代化的自动测试工具代替完成，至于如何生成测试用例，依然是一件棘手的事情。MBT 中使用的测试用例生成方法主要依赖于所使用的模型表现形式，针对不同的模型表现形式，研究者分别想出了一些解决方案。如果系统的模型是由一系列逻辑表达式所组成的，那么可以使用定理证明的方法。定理证明方法原先是被用于自动证明数学公式，MBT 生成测试用例时根据逻辑表达式的有效说明把模型划分为不同等价类，每个等价类描述了 SUT 的某一行为。这些等价类就可以用于生成测试用例，最简单的划分方法是析取范式的方法。当需要为程序的特定执行路径寻找输入时，沿着路径使用符号执行的方法，结合途中遇到的一些分支断
26、言，我们可以求出预期输入所需要满足的约束。于是可以用各种约束来建立 MBT 的模型，收集不同执行路径中数据约束再利用约束编程中的方法求解得到测试用例。其中约束编程是一种通过约束来描述变量间关系的编程方法，求解约束的方法有布尔式求解方法和数值分析方法。MBT 自然还会让人想到模型检测，即检测模型是否满足特定的属性。无论检测结果是满足属性还是违背属性，都可以形成测试用例。但是一般来说反例的作用更大，因为测试用例中的各种断言正是通过反例来生成的，从而有效地识别出系统是否正常工作。模型检测会遇到的问题是，生成的用例中存在过多冗余用例,导致软件测试执行的代价增加。为此，Hamon 等人详细讨论提出了高效
27、模型检测的方法 16。类似于描述程序所有可执行路径的控制流和描述程序所有变量定义和内存使用的数据流，事件流模型描述的是 GUI 上所有可执行的事件序列。通常情况下，GUI 又可以分为不同的层次结构，比如整个 GUI 系统是由各种对话框所组成的，那么系统的事件流图就是由对话框各自的事件流图组成的。把复杂系统拆分为相对独立的组件单独分析，也是所有 MBT 测试用例生成方法通用的窍门。马尔可夫链也是 MBT 中生成测试用例的重要方法之一，它由两大部件组成：代表系统所有使用场景的 FSM 和评价 FSM 来说明系统统计性使用信息的操作说明。马尔可夫链模型为 MBT 提供了测试的侧重点，即着重测试那些用
28、户经常使用的功能。因为对于系统中那些极少概率出现的错误，是几乎不可能被发现的。我们选用的是 FSM 模型，所以可以利用图论中的一些遍历方法，比如广度优先遍历算法或者深度优先遍历算法，每找到的一条可执行路径对应于一个测试用例。当 FSM 包含的状态比较多时，遍历组成 FSM 有向图产生的测试用例数量可能太多，不仅难以测试包含冗余测试用例。可以通过指定初始遍历节点和限定路径长度的方法来减少生成测试用例的数量，但是更好的是下面介绍的组合测试。软件开发者和用户经常还会遇到这样的问题，把同样的软件应用从一台机器换到另外一台机器上使用时，原先从未出过故障的软件突然变得无法正常使用。问题有许多可能的影响因素
29、，比如跟软件安装所在机器的操作系统类型有关，或者是系统物理内存的大小，基于模型的自动化测试工具的实现第 8 页 共 13 页甚至网卡型号等等。除了硬件环境的不同，软件接受的输入参数也很可能不同，比如同一款 Web 应用发布后，不同国家的用户将会输入不同编码的内容。软件能否经得住各种条件下的考验，是软件测试需要解决的问题。当然，最简单和理想的情况下是把所有可能出现的硬件配置和参数取值都测试一遍。但是现实并不允许测试人员这么做，因为造成的测试用例数量是指数性爆炸增长的，N 个分别有 M 种取值的影响因素将需要 MN个测试用例来完成测试。后来人们发现通过巧妙地选取测试用例，只要求某些参数的组合情况被
30、包含，能够在保证测试效率的同时大大缩减测试用例数量。该理论是基于以下事实的，软件中的错误大部分都是由单个参数所导致的，一般最多是由两个参数相互作用而触发，三个或三个以上的情况几乎没有。如果测试用例集包含了任意 t 个参数的所有取值组合，那么称该测试用例集组合强度为 t，或者说它是 t-way 的。图 2-3 不同组合强度下的错误发现率图 2-3 是 NIST 报告中总结的几个应用使用不同组合强度的测试用例集测试后的错误发现率曲线 17。我们可以看出，随着组合强度的增加，错误发现率显著增长。以 NASA 应用为例，67%的错误由单个参数触发，93%由两个参数相互作用后触发，98%由三个参数一起造
31、成。其它应用的错误发现率曲线也都比较相像，组合强度等于 4 到 6 时错误发现率都达到了将近 100%。特别的，生成 2-way 的测试用例集的方法被称为 pair-wise（或 all-pairs）测试方法。目前 pair-wise 是使用最普遍的组合测试技术，因为软件中的绝大部分错误都只由一个或两个参数造成，pair-wise 生成的测试用例能够覆盖足够的错误空间。使用 pair-wise 技术后，总测试用例数目从原来的 MN下降到了约 M * N。至于生成高组合强度的测试用例，测试用例集发现错误的能力没有实质上的提高，却会导致生成算法的更加复杂化和产生多得多的测试用例。最坏的情况下，当组
32、合强度和参数的数目相等时，组合测试退化为枚举测试。组合测试的最早提出，也就是为了简化软件在各种配置环境下的测试。因为牵涉到硬件环境的搭建，配置参数测试中每增加一种测试情况比单纯地多写一个测试用例所花的代基于模型的自动化测试工具的实现第 9 页 共 13 页价大得多。人们迫切需要解决这一问题，使得配置参数测试成为了组合测试中最为发达的形式，尤其在那些要求适应不同硬件平台和环境的软件的测试过程中。考虑一款受 5 个配置因素影响的应用：操作系统（Windows XP、Apple OS X、Red Hat Enterprise Linux） ，浏览器（IE、FireFox） ，网络协议（IPv4、IP
33、v6） ，处理器平台（Intel、AMD）和数据库（MySQL、Sybase、Oracle） ，一共 32223=72 种硬件平台。pair-wise 测试只需要设计如下 10 个测试，就覆盖了每一种影响因素和另外一种影响因素的所有组合。编号 操作系统 浏览器 网络协议 处理器平台 数据库1 XP IE IPv4 Intel MySQL2 XP FireFox IPv6 AMD Sybase3 XP IE IPv6 Intel Oracle4 OS X FireFox IPv4 AMD MySQL5 OS X IE IPv4 Intel Sybase6 OS X FireFox IPv4 In
34、tel Oracle7 RHEL IE IPv6 AMD MySQL8 RHEL FireFox IPv4 Intel Sybase9 RHEL FireFox IPv4 AMD Oracle10 OSX FireFox IPv6 AMD Oracle表 2-2 pair-wise 测试的配置即使被测软件没有配置选项，软件仍要处理一些输入。例如，Word 2010 应用程序至少允许用户对拖黑文字进行 10 种不同操作：设为上标、设为下标、加粗、加下划线、设为斜体、加删除线、加灰色背景、加阴影效果、加倒影效果、加荧光效果。相关的字体处理函数需要根据用户的输入来相应修改文字效果，该函数需要在所有的
35、可能情况下都正常工作，而一共有 210=1024 种可能。前面的经验告诉我们，3-way 的测试用例就能够达到 90%以上的错误发现率，具有较高的收益-代价比。图 2-4 3-way 覆盖数组图 2-4 列出了对于具有 10 个变量、每个变量各有两种取值的 3-way 覆盖数组。覆盖数基于模型的自动化测试工具的实现第 10 页 共 13 页组并不唯一，这只是其中一种情况。t-way 覆盖数组的特点是，任意 t 个参数的所有排列组合都将分别出现在覆盖数组的某一行中，比如上图中的 ABC、DEG、HIJ，三个参数共有8 种排列组合（000、001、010、011、100、101、110、111）都
36、被覆盖数组所覆盖。覆盖数组的每一行对应一个测试用例，相比之前的 1024 个测试用例，组合测试只需要 13 个测试用例。组合测试用例生成的本质是构造覆盖数组，最早的构造方法是利用正交数组，其定义和覆盖数组类似，唯一区别在于正交数组中所有 t 元组出现的次数相同，而覆盖数组不保证这一点。在某些特殊的情况下，正交数组就是最优的覆盖数组，为此，如何构造正交数组问题吸引了大量的研究者研究。Sloane 在其网站上总结记录了超过 200 个正交数组 18。利用计算机也可以自动求解出部分类型的正交数组，由已知的大覆盖数组构造小覆盖数组的方法被称为坍塌 19。坍塌的缺陷在于，最终得到的覆盖数组往往并不是最优
37、解，一般比最优解要大。另一种构造方法刚好相反，是由已知的小覆盖数组递归构造出大覆盖数组。构造最优覆盖数组的实际上是一个 NP 完全问题 20，我们知道，NP 完全问题是一系列可以互相转化的问题。于是我们可以利用和借鉴其它 NP 完全问题的研究成果来构造覆盖数组，比如第一个被证明为 NP 完全问题的可满足性问题，整数规划问题，图论问题等等。数学构造方法仅限于某些特定大小或者组合强度的覆盖数组的构造，不具有通用性。NP 完全问题则是困扰了人类多年的超级难题，目前还没有突破性解法，所以转化为其它问题也是大同小异。但我们可以利用局部搜索方法，比如启发式搜索算法，在较短的时间内就可以搜索出近似最优解。启
38、发式搜索算法是利用一个已有的数组，通过合适的变换得到一个更优的覆盖矩阵，不断地变换直到得到一个较优的矩阵。近年来流行的模拟自然界行为的智能优化算法中，目前已经应用到组合测试中的主要有模拟退火、禁忌搜索、遗传算法等等。更为有效的方法是贪心算法，贪心算法的思想是从空矩阵开始，然后逐行或者逐列地扩展矩阵，直到所有的 t 元组都被覆盖。按照扩展方式的不同，又可以分为一维扩展和二维扩展。商业工具 AETG 最先提出一维扩展的方法 21，依次增加一行，每次尽可能多地覆盖未覆盖的 t 元组。微软开发的工具 PICT 采用类似 AETG 的方法生成测试用例 22，不同之处在于，PICT 每次产生的结果是相同的
39、。Lei 等人提出的 IPO（In-parameter-order） 23方法属于二维扩展，该算法主要针对 pair-wise 测试。首先构造前两个参数的所有组合，形成一个小的矩阵，再分别为矩阵添加一列和必要多的行，覆盖完所有元组后结束。我们将模仿 PICT 工具中 pair-wise 算法的主要思想，使用一维扩展的贪心算法来生成覆盖数组。同时给系统留好接口，利于以后换用新的 pair-wise 生成算法，具体的算法设计将在第四章介绍。2.4. MBT 预期输出生成三大关键技术就只剩下辅助性内容生成工具了，辅助性工具主要还是为了解决预期输出的生成问题。前面我们构造了系统的模型，模型描述了系统的
40、状态和状态之间的动作，这些动作都是由一个个函数和方法的调用序列组成的。SUT 提供的 API 往往不能和测试用例的要求完全契合，为了让测试用例能够顺利地在 SUT 上执行，需要测试人员在 SUT 之上再包装一层，即图 2-1 中的适配器层。严格地说，我们编写的工具只负责生成基本的测试用例框架，或者称为抽象的测试用例。测试用例中相当于使用了打桩的设计模式，桩的实际实现由最终的测试人员补充完成，桩的实现包括对 SUT 提供的 API 的封装组合和测试判断逻辑的编写。我们把这些桩叫做token，token 对应于适配器层中的某个函数和方法，两者可以直接一一对应，也可以先序列化为 XML 文件再利用
41、XML 解析器之类的工具生成测试用例。这样 MBT 的整个测试工具都基于模型的自动化测试工具的实现第 11 页 共 13 页变得项目之间可移植了，如果某一测试条件和预期结果不同则在 token 中抛出异常，抛出的异常随后被测试工具捕获，最终判定该测试用例不通过。图 2-5 展示了一个测试工具自动生成的测试用例，用户需要实现 token_1 和 token_2 的具体逻辑，然后测试用例就能够被真正执行了。token_1 和 token_2 执行过程中如果发现错误会触发异常，程序打印出错误提示，同时导致测试用例的总错误个数加一。反之，一切正常并给出通过提示。图 2-5 测试用例示例另外我们也可以利
42、用 pair-wise 来完成部分情况下预期输出的生成。对于相同输出结果的某些参数取值组合，把输出结果也当作 pair-wise 算法输入参数的一项，输出结果列和其它输入参数的区别在于其取值唯一。PICT 工具还支持混合组合强度的测试用例生成，以及输入各种约束，比如指定某些参数的组合形式必须出现或者不出现，所以具有较强的预期输出生成能力。不过如果预期输出涉及复杂的判断逻辑，还是使用委托给 token 来处理的方法较好。基于模型的自动化测试工具的实现第 12 页 共 13 页第三章 系统架构功能概述及流程课题要求完成的基于模型的自动化测试工具的功能包括：支持输入 FSM 模型、支持添加 toke
43、n、支持 pair-wise 组合测试、支持生成测试用例框架、支持序列化 FSM 模型到文件和反序列化读入。其中考虑到 token 的可复用性，用户可以直接在工具上定义 token 顺序执行序列组成的函数过程，更复杂的函数过程则通过添加新的 token 实现。用户使用该工具生成测试用例的流程如下：添加 token 定义添加函数过程定义绘制 FSM设置变量取值设置路径长度生成测试用例挑选保存实现 token3.2. 系统架构第四章 系统各功能实现FSM Model/Xml 序列化FSM 界面实现PICT深度遍历图，路径SuiteMaker第五章 实例分析：ATM 系统第六章 结论及展望基于模型的
44、自动化测试工具的实现第 13 页 共 13 页参考文献1 Software Errors Cost U.S. Economy $59.5 Billion Annually, NIST Report2 Baker, C. Review of D.D. McCrackens “Digital Computer Programming”.Mathematical Tables and Other Aids to Computation 1 I, 60(Oct. 1957). 298-305.3 Myers, G.J. The Art of Software Testing. John Wiley B
45、. Hetzel (1988). “The Growth of Software Testing“. CACM 31 (6). ISSN 0001-0782.7 https:/ http:/ http:/ A tool for statistical modeling and estimation of reliability functions for software: SMERFS11 CASRE - An Easy to Use Software Reliability Measurement TOOL12 S.R.Dalal, A.Jain, N.Karunanithi, J.M.L
46、eaton, C.M.Lott, G.C.Patton, B.M. Horowitz, Model-Based Testing in Practice, Proceedings of ICSE99.13 M. Utting, A. Pretschner, B. Legeard, B., A Taxonomy of Model-Based Testing, Technical report, Department of Computer Science, University of Waikato, 2006.14 Mark Utting, Bruno Legeard. Pratical Mod
47、el-Based Testing: A Tools Approach.15 D. Harel. Statecharts: A visual approach to complex systems. Science of ComputerProgramming, 8:231274.16 Hamon, G., de Moura, L., Rushby, J.: Generating efficient test sets with a modelchecker. In: 2nd International Conference on Software Engineering and FormalM
48、ethods (SEFM), Beijing, China, IEEE Computer Society (2004) 26127017 (2010) Practical Combinatorial Testing. SP 800-142 Natl. Inst. of Standards and Technology. (Report).18 Sloane NJA. A library of orthogonal arrays. http:/ Williams AW, Probert RL. A practical strategy for testing pair-wise coverage of network interfaces. In: Lyu MR, ed. Proc. of the 7th Intl Symp. on Software Reliability Engineering (ISSRE). Los Alamitos: IEEE Press, 1996. 246254.20 Y. Lei and K. C. Tai. In-parameter-order: a test generation strategy for pairwise testing. In Proceedings of the Third IEE
