下载文档原格式
基于模型的软件测试方法与工具软件测试是确保软件质量的重要环节。
在软件开发过程中，为了提高测试效率和准确性，基于模型的测试方法和工具被广泛应用。
本文将介绍基于模型的软件测试方法和工具的定义、原理和应用。
1. 定义基于模型的软件测试方法和工具是一种使用模型来描述系统行为和属性，通过实例化和执行模型自动生成测试用例并进行测试的技术。
它采用形式化模型来对系统进行建模和验证，从而提高测试覆盖率、发现更多的缺陷，并减少测试工作量。
2. 原理基于模型的软件测试方法和工具基于以下原理：2.1 模型驱动基于模型的测试方法和工具使用形式化模型来描述系统行为和属性，并通过自动化工具实现模型解释和执行。
开发人员可以根据模型的需求规约和约束，自动生成测试用例，使得测试过程更加直观和规范。
2.2 测试用例生成基于模型的测试方法和工具可以通过模型自动生成测试用例。
测试工程师只需要做好模型的规约和约束，然后通过模型的解释和执行工具，自动生成测试用例。
这样可以节省测试用例设计的时间和精力，并提高测试覆盖率。
2.3 测试执行和验证基于模型的测试方法和工具可以自动执行测试用例，并对测试结果进行验证。
通过模型的自动化工具，可以监控系统的行为和属性，发现异常和错误，并生成测试报告。
这样可以提高测试的效率和准确性。
3. 应用基于模型的软件测试方法和工具在软件开发过程中有广泛的应用。
3.1 自动化测试基于模型的测试方法和工具可以实现自动化测试。
通过对系统进行建模和验证，自动生成测试用例并进行自动化测试，从而提高测试的速度和质量。
开发人员只需关注模型的规约和约束，无需手动编写大量的测试用例。
3.2 软件验证基于模型的测试方法和工具可以进行软件验证。
通过对系统进行形式化建模和验证，可以确保系统满足规定的需求和约束。
开发人员可以基于模型进行形式化证明，发现系统中的潜在问题和缺陷，提高软件的可靠性和稳定性。
3.3 缺陷发现基于模型的测试方法和工具可以发现更多的缺陷。
引言概述：TESSY自动化测试工具是一款功能强大的软件测试工具，它可以帮助软件开发团队自动化执行测试任务，提高测试效率和软件质量。
本文将深入探讨TESSY自动化测试工具的特点和应用场景，并分析其在软件测试过程中的作用，引导读者更好地了解和应用TESSY自动化测试工具。
正文内容：1. 基于模型的测试方法：- TESSY自动化测试工具采用基于模型的测试方法，可以根据软件系统的需求规约和设计模型自动生成测试用例。
这样，测试人员无需手动编写测试用例，大大提高了测试效率，并减少了测试过程中的错误。
- TESSY还支持多种模型，包括状态机模型、数据流模型和决策表模型等。
根据软件项目的特点和需要，测试人员可以选择合适的模型进行测试，以达到最佳的测试效果。
2. 自动化测试执行：- TESSY具有自动化测试执行的能力，可以自动执行测试用例，收集测试结果，并生成测试报告。
这样，测试人员可以将更多的精力放在测试分析和策略制定上，大大提高测试效率。
- TESSY还支持多种测试技术，包括白盒测试、黑盒测试和灰盒测试等。
测试人员可以根据需求选择合适的测试技术，并在自动化测试执行过程中应用这些技术，以发现更多的软件缺陷。
3. 高度可定制的测试环境：- TESSY提供了高度可定制的测试环境，可以根据软件项目的特点和需求，灵活配置测试环境。
测试人员可以选择不同的编程语言和操作系统，以及不同的测试工具和库，以适应不同的测试需求。
- TESSY还支持与其他测试工具和开发工具的集成，包括版本控制工具、缺陷管理工具和构建工具等。
测试人员可以与开发团队紧密合作，共同推动软件测试工作的进展。
4. 高度可扩展的测试框架：- TESSY基于开放式标准和设计原则，提供了高度可扩展的测试框架。
测试人员可以根据自己的需求，使用Tessy提供的API和扩展接口，将其他测试工具和技术集成到TESSY中，以实现更复杂和全面的测试任务。
- TESSY还支持分布式测试和并行测试，可以在多个计算机上同时执行测试任务，并进行结果的汇总和分析。
基于模型的测试综述报告摘要：本综述报告主要对基于模型的测试进行综述，介绍了基于模型的测试的定义、用途和特点，总结了现有的基于模型的测试方法，并对其进行评价和比较。
一、引言基于模型的测试是软件工程领域中一种重要的测试方法，它通过使用系统的形式模型来指导测试用例的设计和生成。
基于模型的测试能够提高测试效率、降低测试成本，并且能够提高测试覆盖率和准确性。
本综述报告将对基于模型的测试进行详细的介绍和评价。
二、基于模型的测试方法1.模型设计2.测试用例设计根据系统的形式模型，可以生成相应的测试用例。
常见的测试用例设计方法有路径覆盖、边界值分析、等价类划分等。
测试用例的生成可以通过手工设计、遍历系统的状态空间和符号执行等方法实现。
3.测试执行测试执行阶段根据设计的测试用例进行实际的测试。
测试可以在软件开发周期的不同阶段进行，如单元测试、集成测试、系统测试等。
测试执行可以通过手工执行、自动化测试工具和平台进行。
4.测试评估测试执行后需要对测试的结果进行评估。
评估指标包括测试覆盖率、错误检出率、性能指标等。
通过评估结果可以调整测试策略和改进测试技术。
三、基于模型的测试方法评价1.优点-提高测试效率，通过生成测试用例减少了手工设计的工作量。
-提高测试准确性，通过模型的形式化描述能够避免测试用例的遗漏和错误。
-提高测试覆盖率，通过遍历模型的状态空间能够达到更全面的测试覆盖。
-减少测试成本，通过自动化测试和测试工具的支持，能够节约测试资源和时间。
2.挑战-模型设计的复杂性，需要对系统进行深入的理解和抽象。
-测试用例的生成和执行的复杂性，需要设计适应于模型的测试用例生成算法和执行策略。
-测试评估的准确性，需要选择合适的评估指标和方法来评估测试的有效性和覆盖率。
四、结论基于模型的测试是一种有效的测试方法，能够提高测试效率、准确性和覆盖率，并降低测试成本。
尽管该方法面临一些挑战，但是通过合适的模型设计、测试用例生成和执行策略以及评估方法，可以克服这些挑战，并改进测试质量。
基于模型的软件测试用例生成方法研究在软件开发过程中，软件测试是确保软件质量的关键步骤。
测试用例生成是软件测试中一个重要的环节，它可以帮助测试人员自动化生成大量有效的测试用例，提高测试的效率和覆盖率。
然而，传统的测试用例生成方法存在一些问题，如生成的测试用例数量庞大、生成的用例不够高效等。
为了解决这些问题，基于模型的软件测试用例生成方法被提出和研究。
基于模型的软件测试用例生成方法是利用软件模型作为基础，通过对模型进行分析和推理来生成测试用例。
这种方法可以克服传统测试用例生成方法中的一些问题，并且具有以下优势：一是生成测试用例的覆盖率高。
基于模型的方法通过对软件模型进行分析和推理，可以生成更全面、多样化的测试用例。
通过模型的自动化推理能力，可以发现隐藏的错误和潜在的问题，从而提高测试用例的覆盖率。
二是生成的测试用例数量可控。
传统的测试用例生成方法往往无限制地生成测试用例，导致测试人员难以选择和管理。
而基于模型的方法可以根据测试目标和需求，通过对模型的控制和调整，生成适量的测试用例，避免了测试用例数量过多的问题。
三是生成的测试用例质量高。
基于模型的方法充分利用了软件模型的信息，可以生成更加高效和有效的测试用例。
通过对模型的分析和推理，可以发现测试用例中存在的问题和潜在的错误，提高测试用例的质量。
基于模型的软件测试用例生成方法主要包括以下步骤：建立软件模型。
软件模型是进行测试用例生成的基础，可以使用各种建模技术和工具，如UML、状态机等。
通过建立软件模型，可以准确地描述软件的功能和行为，为后续的测试用例生成提供基础。
对软件模型进行分析和推理。
通过对软件模型的分析和推理，可以发现潜在的错误和问题，并根据测试目标和需求生成测试用例。
分析和推理过程可以使用各种自动化技术和算法，如模型检测、符号执行等。
接下来，根据测试目标和需求生成测试用例。
根据测试目标和需求，通过对模型的控制和调整，生成适量的测试用例。
在生成测试用例的过程中，需要考虑测试的覆盖率和效率，确保生成的测试用例能够有效地覆盖软件的各个功能和部分。
基于模型的自动化测试工具的实现基于模型的自动化测试工具（Model-based Testing Tool）是一种用于测试软件系统的工具，通过对软件系统建立模型，自动生成测试用例并执行测试，以提高测试效率和测试覆盖率。
本文将介绍基于模型的自动化测试工具的实现过程，包括模型建立、测试用例生成和执行三个主要步骤。
首先，构建软件系统模型是基于模型的自动化测试的关键步骤。
模型是对软件系统的抽象描述，通过对系统关键状态和行为建模，可以帮助理解系统功能和结构，并据此生成测试用例。
模型建立可以使用不同的建模语言和工具，如UML（统一建模语言）、BPMN（业务流程建模和标记语言）等。
根据系统的特点和需求，选择合适的建模语言和工具进行模型构建。
其次，基于模型的自动化测试的核心是测试用例生成。
模型可以为自动生成测试用例提供基础，通过对模型进行逆向分析、系统覆盖分析和路径选择等技术，生成全面且有效的测试用例。
测试用例生成可以使用各种技术和算法，如符号执行、模型检测、遗传算法等。
其中，符号执行是一种常用的测试用例生成技术，它通过对程序路径的符号化计算，自动创建各种输入数据并执行程序，以发现潜在的错误和漏洞。
最后，基于模型的自动化测试还需要执行生成的测试用例，并收集和分析测试结果。
测试用例执行可以使用自动化测试工具完成，通过模拟用户的操作和输入，执行测试用例并记录系统的响应和输出。
在测试用例执行过程中，可以使用断言（assertion）来验证系统的实际行为是否符合预期。
测试结果的收集和分析可以使用各种技术和工具，如测试报告生成工具、测试结果可视化工具等。
这些工具可以帮助开发人员和测试人员更好地理解系统的测试覆盖和测试效果，及时发现和修复问题。
综上所述，基于模型的自动化测试工具的实现主要包括模型建立、测试用例生成和执行三个步骤。
模型建立通过对系统建立抽象描述，帮助理解系统结构和功能；测试用例生成通过对模型进行逆向分析和路径选择，自动生成全面且有效的测试用例；测试用例执行通过模拟用户操作和输入，验证系统的实际行为是否符合预期；同时，测试结果的收集和分析可以帮助开发人员和测试人员更好地理解系统的测试覆盖和测试效果。
CAST的工作原理与设计计算一、工作原理CAST是一种用于计算机辅助软件测试的自动化工具。
它的工作原理基于模型检测技术，通过对软件系统的模型进行分析和验证，来发现潜在的错误和缺陷。
1. 模型构建：在使用CAST之前，需要先对被测试的软件系统进行建模。
这个模型可以是抽象的，也可以是具体的。
模型通常由状态、变量和操作组成，用于描述系统的行为和状态转换。
2. 属性规约：在模型构建完成后，需要为系统定义一组属性规约，用于描述系统应该满足的性质和约束。
这些性质可以是安全性、正确性、可靠性等方面的要求。
3. 模型检测：一旦模型和属性规约定义完成，CAST就会对其进行模型检测。
模型检测是一种自动化的技术，通过遍历系统的状态空间，来验证属性规约是否被满足。
如果存在不满足的情况，CAST会生成相应的错误报告。
4. 错误修复：当CAST检测到错误时，它还可以提供一些修复建议。
这些建议可以是对系统模型的修改，或者是对属性规约的调整。
修复建议的目标是使系统满足所有的属性规约。
二、设计计算在CAST中，设计计算是指通过对系统模型进行计算和分析，来指导软件系统的设计和开发过程。
设计计算可以帮助开发人员在系统设计的早期阶段发现和解决潜在的设计问题，提高系统的质量和可靠性。
1. 系统建模：设计计算的第一步是对系统进行建模。
建模可以使用各种建模语言和工具，如UML、Petri网等。
建模的目的是将系统的功能和行为抽象出来，以便进行后续的计算和分析。
2. 属性规约：在系统建模完成后，需要为系统定义一组属性规约。
属性规约用于描述系统应该满足的性质和约束。
这些性质可以是功能性的，如系统是否满足某个需求；也可以是非功能性的，如系统的性能、可靠性等方面的要求。
3. 设计计算：一旦系统模型和属性规约定义完成，设计计算就可以开始了。
设计计算通常包括以下几个步骤：(1) 模型分析：通过对系统模型进行分析，可以得到系统的一些重要特性，如状态空间的大小、系统的可达性等。
基于MBT的⾃动化测试⼯具——GraphWalker介绍和实际使⽤GraphWalker是⼀个开源的基于模型的⾃动化测试⼯具，它可以⽤来通过图形测试模型来⾃动⽣成测试⽤例。
本⽂主要描述了使⽤yed画出FSM, EFSM模型图（常见的流程图），然后使⽤GraphWalker命令⽣成⼿⼯⾃动化⽤例，最终通过python将⼿⼯⽤例读取后⾃动执⾏并⽣成执⾏报告。
⼀： GraphWalker概述GraphWalker就是⼀个基于测试模型的⽤例⽣成⼯具。
它主要应⽤于FSM, EFSM模型。
可以⽤来它可以直接读取FSM, EFSM图形模型、json模型、⽣成测试⽤例。
那什么是MBT呢？ MBT中⽂名称为基于模型的测试, 基于模型的测试属于软件测试领域的⼀种测试⽅法。
MBT步骤如下：⾸先由被测系统（SUT， system under test ）的⼀些（通常是功能）⽅⾯描述，构建出被测系统的模型。
再根据模型或模型中的⼀部分部分⽣成测试⽤例。
进⽽进⾏软件测试。
常见的MBT中模型通常有下列⼏种：前置后置条件模型: Pre and post condition models (State based, OCL)基于转换的模型: Transition based models (FSM, EFSM)随机模型：Stochastic models (Markov chains).数据流模型: Data-flowmodels(Lustre)⼆：⼯具下载：1、画图⼯具YED2、 GraphWalker的jar包下载：三：学习笔记整理（关键知识点）1、顶点：如上图所⽰，所有的顶点⽐如Start,V_ClientNotRuning.⼀个顶点称为节点，通常表⽰为⼀个框表⽰我们想要检查的预期状态。
在任何实现代码/测试中，可以通过断⾔或者数据校验改结果。
常见有以下⼏种顶点：Start顶点：start顶点不是必需的。
如果使⽤，则必须有1个（且只有1个）顶点名称为：start.从start顶点出发只能有1个边。
AutoTCG使用手册1.概述自动化测试通过机器执行事先准备好的测试脚本进行，提升了软件测试效率。
然而，测试脚本存在着编写专业性强、调试工作量大、维护成本高、难以复用等困难，成为自动化测试技术的难以广泛使用的主要技术瓶颈。
AutoTCG使用了模型驱动的测试脚本生成方法。
首先，使用遵循BPMN2.0规范的方法对被测系统业务流程进行可视化建模，获得模型化的测试需求；然后，采用路径深度覆盖算法生成测试路径，根据路径上的约束条件生成测试输入参数；最后，通过自定义的测试动作原语将测试路径和输入参数转化为可在自动化测试平台上自动执行的测试脚本。
AutoTCG采用先进的数学算法，可实现全面科学的测试覆盖；适用于嵌入式软件测试、web应用测试、移动app测试、桌面软件测试等多种自动化测试场景。
2.文件夹显示和操作打开AutoTCG网址，进入“我的文件夹”，可以查看我的模型文件夹内容。
“我的文件夹”中有四个主文件夹：我的文件、最近修改、我的收藏、回收站。
如图1所示。
图1文件夹界面2.1 我的文件以列表形式显示显示我创建的文件，包含子文件夹和模型文件。
列表内容包括了文件名、创建时间、最后修改时间、包含模型数（对子文件夹有效）、生成用例数、操作。
如图2所示。
图 2 我的文件子文件夹的操作有：重命名、移动/复制、移到回收站。
模型文件的操作有：重命名、移动/复制、移到回收站、收藏、发布到公共模型库。
点击子文件夹名称可以进入子文件夹。
显示方式同“我的文件”。
点击模型文件名称，可以进入模型文件编辑界面。
子文件夹界面上方显示路径。
点击路径上的任意名称可以进入该文件夹。
2.2 最近修改以列表形式显示最近修改的模型文件，按照修改时间进行排序，最近修改的模型排在最前面。
列表内容包括了文件名、创建时间、最后修改时间、生成用例数、操作。
如图3所示。
图 3 最近修改模型文件的操作有：重命名、移动/复制、移到回收站、收藏、发布到公共模型库。
基于AI增强及模型驱动的UI功能自动化测试随着人工智能技术的不断发展，越来越多的软件开发公司开始将AI技术应用于功能自动化测试中。
AI增强及模型驱动的UI功能自动化测试是一种新兴的测试方法，它利用机器学习和模型预测等技术，可以有效地提高测试效率和准确性。
本文将探讨AI增强及模型驱动的UI功能自动化测试的原理、优势和实践。
首先，AI增强及模型驱动的UI功能自动化测试是如何工作的呢？在这种测试方法中，首先需要构建一个机器学习模型，该模型可以学习软件系统的行为和功能，并根据学习结果预测系统在不同场景下的行为。
然后，测试工程师可以利用这个模型来生成测试用例和测试数据，以执行自动化测试。
通过不断地迭代学习和测试过程，模型可以得到不断优化和提升，从而提高测试的准确性和效率。
相比传统的UI功能自动化测试方法，AI增强及模型驱动的测试有很多优势。
首先，由于模型可以学习系统的行为和功能，可以更容易地捕捉到潜在的bug和问题，提高测试的覆盖率和准确性。
其次，由于模型可以自动识别测试用例和数据，节省了测试工程师大量的时间和精力，提高了测试的效率。
此外，AI增强的测试可以应对软件系统的复杂性和变化性，更容易地适应不同的测试场景和需求，从而保证系统的稳定性和可靠性。
在实践中，AI增强及模型驱动的UI功能自动化测试已经被越来越多的软件开发公司采用。
例如，一些知名的互联网公司和科技公司已经开始将AI技术应用于自动化测试中，取得了显著的效果和成果。
他们通过构建自己的学习模型和测试平台，对软件系统进行全面的功能和性能测试，提高了系统的质量和用户体验。
总的来说，AI增强及模型驱动的UI功能自动化测试是一种创新的测试方法，可以有效地提高测试的效率和准确性，是未来软件测试的发展趋势。
随着人工智能技术的不断发展，我们相信这种测试方法将会得到更广泛的应用和推广。
希望更多的软件开发公司可以积极探索和应用这种新兴的测试方法，为用户提供更加稳定和可靠的软件产品。
基于模型的自动化测试工具的实现摘要基于模型的测试是本文首先介绍了Atmel-View框架以及菜单系统UI在其中所将扮演的角色、与各个功能模块间的关系。
其次讲解了Atmel-View内存映射窗口结合OSD应用的UI设计思想，涉及了多图层表现的想法，硬件OSD与伪OSD的比较使用。
然后详细阐述了基于Atmel-View 的菜单系统方案和框架结构，针对最重要的MenuMode菜单构建函数分析其数据抽象、界面绘制和事件响应处理过程。
其后介绍Nucleus Plus，给出进程通信、进程同步在菜单系统中支持蓝牙模块的应用方法。
本方案的实现提供了一套层次化、结构化、可扩展的电子相框菜单系统，并有效支持了蓝牙模块的应用。
关键词：OSD，内存映射窗口，菜单系统，UIFULFILL UI OF DIGITAL PHOTO FRAMEBASED ON ATMEL-VIEWABSTRACTAtmel Corporation's Atmel-View is the application for board A T76C120, it has already provided low level realization for digital photo frame, and it could be an extendable 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 with OSD's 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 System's framework were illustrated. The process of data abstraction, interface drawing and event handling were analyzed for the 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 digital photo frame. And it effectively supports Bluetooth module.Key words:OSD, SDRAM-Mapping Window, Menu System, UI目录第一章绪论 (1)1.1.软件测试简介 (1)1.2.软件测试工具发展现状 (2)1.3.项目背景和论文结构 (4)1.3.1.项目背景 (4)1.3.2.论文结构 (4)第二章基于模型的测试 (5)2.1.MBT一般操作流程 (5)2.2.MBT模型表现形式 (6)2.3.MBT测试用例生成 (7)2.4.MBT预期输出生成 (10)第三章系统架构 (12)3.1.功能概述及流程 (12)3.2.系统架构 (12)第四章系统各功能实现 (14)第五章实例分析：ATM系统 (21)第六章结论及展望 (26)参考文献 (27)第一章绪论1.1.软件测试简介随着电子信息化的飞速发展，计算机软件已经遍布于人类社会的各个角落，远至月球探测卫星的发射系统，近至个人携带的MP3音乐播放器。
但是软件带来巨大便利的同时，软件中的任何微小缺陷也可能带来难以估量的损失。
据美国国家标准技术研究院（NIST）2002年公布的一份研究报告显示，软件故障平均每年对美国经济造成的损失约为595亿美元，占其国民生产总值的0.6% [1]。
因此，如何保证软件的质量显得尤为关键。
软件测试能够有效地帮助软件开发人员找出系统中存在的错误，从而在很大程度上保证软件的质量。
现代软件工程理论将软件测试作为软件开发过程的重要组成部分，软件开发过程中有一半以上的资源都花费在软件测试上。
早期的软件测试等同于程序调试，1957年Charles Baker才正式将两者区别开来，他认为调试侧重于保证程序运行，而测试侧重于保证程序解决问题[2]。
1979年Myers提出“测试是带有发现错误意图去执行程序的过程”[3]，越是发现了错误才说明测试过程的成功。
1983年美国国家标准局（NBS）发表了评估软件生命周期各阶段的测试方法[4]，同年美国电气和电子工程师协会（IEEE）发布了八大软件测试相关文档的标准[5]，人们开始利用这些评估标准来衡量测试软件的质量。
1988年David Gelperin等在书中写道，“测试是为了证明软件符合需求规约，发现缺陷和防止错误”[6]。
时间测试阶段-1956 面向调试时期1957-1978 面向论证时期1979-1982 面向破坏时期1983-1987 面向评估时期1988- 面向防止时期表1-1 测试的发展阶段[6]测试不可能遍历所有可能出现的情况，必须在适当的时候终止测试。
如果一味地追求缺陷数量，很可能得不偿失。
常用的判断标准有：代码覆盖率、测试用例通过率、缺陷数量收敛率等等。
图1-1 缺陷数量收敛图1.2.软件测试工具发展现状纯手工地进行软件测试往往是费时费力的，而且测试人员容易因为疏忽产生失误，测试准确性无法得到足够的保证。
于是人们需要开发一些自动化工具来管理或者执行测试过程，虽然编写软件测试工具需要引入额外的工作量，但是软件测试工具能大大提高软件测试的效率和质量，并且市面上也已经存在着许多现成的测试工具。
名称产商简介WinRunner Mercury Interactive 支持自动录制、检测和回放用户操作LoadRunner Mercury Interactive 模拟大量并发负载来预测系统性能TestDirector Mercury Interactive 基于Web的测试管理系统Robot IBM 具有测试和管理的双重功能xUnit \ 最流行的开源单元测试框架SilkTest Borland 软件功能测试工具WAS Microsoft 强大的网站压力测试工具JTest Parasoft 针对Java语言的自动化白盒测试工具JMeter Apache 100%用Java实现的功能和性能测试工具WebLoad RadView Web性能测试和分析工具表1-2 常用软件测试工具一般来说，自动化测试可以分为：基于代码的测试和基于图形化用户界面的测试。
基于代码的测试是指通过程序提供的公共接口，直接验证各个类、库和模块在不同的输入情况下返回结果的正确性与否，如xUnit系列框架。
而基于图形化用户界面的测试则是通过模拟用户动作行为（比如键盘输入、鼠标点击），产生某些事件来观察和判断程序响应是否满足预期，如WinRunner。
绝大部分软件测试工具并不能自动完成整个测试过程，测试人员依然需要事先编写好测试脚本或测试用例，即一组测试输入、执行条件和预期结果。
测试用例能够被快速和反复地执行，方便地使得发现的软件错误重现。
当测试本身就需要多次重复时（比如回归测试、压力测试），其优点将更加显著。
基于模型的测试（MBT, Model-Based Testing）是一种轻量级自动生成测试用例的方法，测试人员的关注点在于构建一个能够描述被测系统各方面数据和行为的形式化机器可读模型。
为了抽象出理想的模型可能需要花费一定的时间，但是模型构建的工作可以在软件开发生命周期的早期就开始，只要求被测系统的需求定义完成即可。
而且往往在将非形式化的需求转化为形式化的模型过程中，需求中的遗漏和不足部分将被发现。
模型所带来的回报也是巨大的，因为一旦模型被确立且其能够准确反映被测系统的真实需求，软件测试工具就能够分析模型自动得到测试用例。
软件测试的主要目的就是发现错误。
事实证明，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很可能并不容易建模。
