全球研究计算机科学杂志》上
菜单石头:2229 - 371 x
石头:2229 - 371 x
| 1(Sanjeev Dhawan称,2Nirmal Kumar和3湿婆赛 Kurukshetra大学计算机工程系,UIET Kurukshetra。 |
| 通讯作者:Nirmal库马尔电子邮件:nirmal.sirohi@gmail.com |
| 相关文章Pubmed,谷歌学者 |
访问更多的相关文章全球研究计算机科学杂志》上
本文概述基于模型的测试的主题。基于模型的测试过程描述,可以在每个阶段的步骤。不同类型的工具必须支持列出的过程说明和示例工具以及他们支持的标准。标准位置的基于模型的测试是检查,并讨论了测试所需的新技能。在研究基于模型的测试在过去的5 - 10年中已经验证了这种方法的可能性。它已经表明,它可以节省成本,并开发了多种测试生成策略和模型覆盖标准。一些商业工具已经开始出现,来自美国(T-Vec、活性系统,I-logix),以及来自欧洲(Telelogic Conformiq Leirios技术),以及各种各样的学术和研究工具(BFS05)。本文讨论有限功能测试,因为基于模型的测试是在其他方面不太成熟。最后,确定项目的适当性的基于模型的测试。本文以下因素进行分析:模型基础测试,步骤,水平,影响MBT的方法和工具。
介绍 |
| 我们都使用模型进行测试,否则我们不会有一个提示测试是否通过或失败——这些模型允许我们知道软件应该执行一个给定的条件。然而,大多数人的模型是非常私人的,永不见天日,只在短暂的时间内现有的测试人员的头上。与基于模型或模型驱动测试,完成系统的模型的行为明确和使用为基础的整个自动化测试(参见图1)。 |
 |
| 基于模型的测试过程 |
| 基于模型的测试是指流程和技术的自动文摘的测试用例,从正式的模型,从抽象测试现有测试的一代,导致现有的手动或自动执行测试用例。因此,基于模型的测试的重点是测试生成的建模原则,测试生成策略和技巧,以及概念的具体化到现有的测试,可执行的测试。[1] |
基于模型的测试步骤 |
| 1。设计一个测试模型。模型通常称为测试模型代表预期的被测系统(SUT)的行为。使用等标准建模语言UML形式化系统的控制点和观察点,预期的系统的动态行为,与测试相关的业务实体,有些数据为初始测试配置。模型元素如转换或决策与需求,以确保双向需求之间的可跟踪性和模型,以及后来生成的测试用例。模型必须能够精确和完整的自动化测试从这些模型的推导。 |
| 2。选择一些测试生成标准。通常有无限可能的测试,可以从模型生成,所以测试分析师选择一些测试生成标准选择优先级最高的测试,或确保良好的覆盖系统的行为。测试生成的一个常见的标准是基于结构模型覆盖,使用众所周知的测试设计策略如等价划分、因果测试、双向测试,过程循环覆盖,或边界值分析(见[1]对这些策略的更多细节)。另一个有用的测试生成标准确保生成的测试用例涵盖所有的需求,也许有更多的测试生成的需求更高的风险水平。通过这种方式,可以用来实现一个基于模型的测试要求和基于风险的测试方法。例如,对于非关键应用程序,测试分析师可以选择生成一个测试的名义行为模型中,每个主要的错误情况下;但对于更多的关键需求之一,她/他可以应用更多的要求报道标准等所有无路由循环路径,以确保相关的业务流程,测试模型的一部分更彻底的测试。 |
| 3所示。生成测试。这是一个完全自动化的过程,生成所需的数量(抽象)测试用例的测试模型。每个生成的抽象测试用例通常是一系列高层SUT的行动,与输入参数和预期输出值2每个操作。这些生成的测试序列类似于高级的测试序列,将在action-word设计手动测试[2]。他们很容易被人类理解和完成足以直接由manual tester SUT上执行的。测试模型允许计算预期的结果和输入参数。数据表可以使用链接一些抽象的价值模型,通过一些具体的测试值。构建可执行使用自动化测试工具,进一步具体化阶段自动翻译所有测试用例抽象为一个具体的可执行的脚本,使用一个用户定义的从抽象数据值映射到具体SUT的价值观,从抽象操作和映射到SUT GUI操作或API调用。例如,如果测试执行是通过SUT的GUI,然后行动文字与图形对象映射,使用惠普快速测试等测试机器人专业,IBM Rational Functional Tester或者开源机器人硒。 If the test execution of the SUT is API-based, then the action words need to be implemented on this API. This can be a direct mapping or a more complex automation layer. The expected results part of each abstract test case is translated into oracle code that will check the SUT outputs and decide on a test pass/fail verdict. The tests generated from the test model may be structured into multiple test suites, and published into standard test management tools such as Quality Center, IBM Rational Quality Manager or the open-source tool TestLink. Maintenance of the test repository is done by updating the test model, then automatically regenerating and republishing the test suites into the test management tools; |
| 4所示。执行测试。生成的具体测试通常是手动执行或在一个标准的自动化测试执行环境,例如IBM Rational Functional Tester或者惠普QuickTest专业版有点。无论哪种方式,其结果是,在SUT上执行测试,我们发现一些测试通过,测试失败。失败测试表明SUT和预期结果之间的差异设计在测试模型,然后需要调查,以决定是否SUT的失败是由缺陷引起的,或一个错误的模型和/或要求。经验表明,基于模型的测试是善于SUT错误,但也是非常有效的公开需求错误(甚至远之前执行一个测试(由于造型阶段)。[4] |
水平,基于模型的测试工具和标准 |
水平的测试 |
| 在开发和维护生命周期,测试用例可以应用于非常小的单位,单位的集合,或整个系统。基于模型的测试可以支持各级测试活动。在最低层次上,基于模型的测试可以应用一个软件模块。通过建模模块的输入参数,一个小但是丰富的测试可以快速发展。这种方法可以用来协助develo1pers在单元测试期间的活动。基于模型的测试是用来检查的一个中级应用简单的行为;这就是我们所说的一个单一的应用程序。单步执行加法操作的例子,表中插入一行,发送消息,或者填写和提交内容的屏幕。仅仅需要一个单个步骤生成测试输入数据模型,并允许计算的预期输出不创建预测更复杂的比被测系统。一个巨大的挑战,提供相对更好的好处是使用基于模型的测试水平的复杂系统行为(有时称为流测试)。 Step-oriented tests can be used to generate comprehensive test suites. This type of testing mostly represents customer usage of software. At our work, we have selected sequences of steps based on operational profiles [6] and used for the combinatorial test generation approach to choose values tested in each step. An alternate approach to flow testing uses models of a system’s behavior instead of its inputs to generate tests. [5] |
工具和标准 |
| 中使用的工具用于创建模型基于模型的测试通常是非常相似的开发人员使用的,在某些情况下,可能是相同的。然后混合符号使用开源开发工具可以修改起来比较容易,即使在未来商业开发工具厂商预计将为测试人员提供必要的附加功能。测试用例生成的工具是特定模型符号使用和测试覆盖率达到标准。目前不使用这些工具在传统软件测试或开发特定于基于模型的测试。因为他们的信仰在输入模型,他们通常是封闭的工具用于模型生成。测试执行执行以同样的方式为基于模型的测试与传统的测试,所以一般可以使用同样的工具。基于模型的测试工具的列表,他们支持的建模符号如下图所示。目前没有标准,特别是支持基于模型的测试;但是有不同的标准,可以使用软件工程的其他领域。例如,最可能的候选人的测试模型的新UML 2.0标准(对象管理组织)OMG [9]。 Even though in its basic form this standard is most likely not precise enough for test modelling, it should be possible to improve this standard’s usefulness with a test modelling profile. The output from the test generation tool is a test suite (or a sequence of test cases). The two most obvious candidates for the standard defining test cases are TTCN-3 [13] and a XML-based standard, such as that is used in the AGEDIS project [7]. If in the future model-based testing tools converse using standard data formats, then users will be able to select between combinations of tools for each of the three main stages rather than being tied to a single tool and supplier, with all the inherent economic and technological limitations that this brings. |
| 算法用于测试的创建及其等价的报道同样的覆盖度量标准相关。有一些测试覆盖措施在BS 7925 - 2[8]中定义,即使这些最初定义支持组件测试,的一些措施,如状态转换报道,可能适合用于基于模型的测试。它们似乎缺乏深入的知识在这一领域的基于模型的测试方法。一些基本覆盖措施通常理解,但更复杂的大型国有措施必要合理的覆盖模型似乎是专有的,或在任何情况下不容易理解的测试社区。基于模型的测试变得更广泛地接受,测试覆盖率的方法实现应该广泛理解和接受。从而使基于模型的测试,更有可能与传统测试相比,要实现这一目标的最好方法是为这些措施是一致的。在不久的将来也会有一个一致的基于模型的测试方法,要求提供一个熟悉的理解方法。 |
 |
基于模型的测试的好处 |
| 许多研究已经表明,基于模型的测试是有效的,主要是用来测试小应用程序时,嵌入式系统、用户界面和state-rich系统实际上复杂的数据。蔷薇花坛和罗宾逊接口,Agrawal(2000)研究了测试图形用户和维特克(1993)嵌入式控制软件和Avritzer拉森(1993)电话系统。通常基于模型的测试是想法的主要吸引力的属性的自动生成测试用例,但这不是全部。定义模型的软件可以帮助炼油不确定性和严重的需求[10]。在编码开始之前通过消除模型缺陷和自动化测试用例创建结果是相当大的节约成本和高质量的代码。其他好处,更相关的测试包括如以下,[10]中提出了: |
| 综合测试;如果模型是整个软件的抽象,它可能会自动生成测试用例覆盖每一个可能的过渡利用图模型的算法。 |
| 缺陷发现;基于模型的自动化测试发现缺陷比手工方法更成功。本文建立了用手工方法的案例研究发现33系统中的缺陷,和基于模型的方法的计算56。本节所示是基于模型的测试是巨大的好处,如果造型和所有相关的任务都是有力的,但它也有一些困难和缺陷。 |
基于模型的测试的困难和分心 |
| 几乎每一个基于模型的测试研究同意一件事:部署的基于模型的测试到一个组织需要相当的努力和投资。在[12],以下三个原因提供了理想的努力和投资: |
| 从测试人员过多的技能是必要的。他们需要著名的模型,这意味着知识的不同形式的状态机,形式语言和自动机理论。积累专业知识,工具和脚本是至关重要的,当自动化测试将被使用。 |
| 大量的初始工作的工时是必需的。模型的类型必须精心挑选,不同部分的软件必须分开,这样的造型更简单,因为较小的领域和实际的模型已经建立。 |
| 模型本身也有一些缺点。主要的是爆炸所需的状态。甚至一个简单的应用程序可以保存这么多状态模型的维护变得复杂和繁琐的任务。 |
| 可以从列表中显示,基于模型的软件测试方法不是完美的解决方案。积极的一面是,在列表中所有的点可以用彻底克服规划部署的基于模型的测试为一个组织。 |
合适的应用 |
| 任何人去使用基于模型的测试之前,他们必须确保方法是适合他们的环境。建立测试模型显然是一个大型的前期成本,但这必须得到更低的维护成本当系统准备。当然,据估计,如果系统维护成本较低,那么测试建模成本不应收回的潜在节省维护成本的基于模型的测试直到很久以后在维护阶段。低维护成本可能预测,例如,如果系统计划只有一个简短的操作主要生活或预计会有一些变化所需的系统用户(和它的环境)。显然,应用程序必须适合造型支持符号。如上所述,切换应用程序被发现主要是合适的,因为它们是适合造型状态模型和有很好的工具支持[11]。应用程序也应该被视为足以支持基于模型的测试的成本。如果高质量的客户不重要那么基于模型的测试将不太可能符合成本效益。 |
| 执行传统的同步测试应用程序的复杂性也可以充当司机对使用基于模型的测试,其中的许多测试用例和系统测试用例的生成提供了良好的测试覆盖率的复杂模型。 |
结论 |
| 基于模型的测试是一个新的和不断发展的技术,使我们能够从显式描述自动生成软件测试的应用程序的行为。因为测试生成的应用程序的一个模型,它只需要更新模型生成新的测试应用程序时的变化。这使得基于模型的测试更容易维护、审查和更新比传统的自动化测试。测试人员愿意也有能力创建基于模型的测试程序可以创建灵活的、有用的测试成本的一个通用的测试语言工具。好的软件测试人员无法避免模型。MBT已成为一个有用和高效的测试方法实现足够的测试覆盖的系统。模型-based testing has already been used effectively on a number of projects and the number of applications for which model-based testing will be appropriate will carry on to grow. A number of factors will make this growth. Second, more commercial quality tool support will become offered. Model-based testing will not, however, be suitable for all situations. There will still be projects where no explicit model of necessities is available and testing needs to be finished before the end of next week. There will also be situations where the available testers are not professional software engineers, but simply those re-assigned from other parts of the organization that are currently free. |
引用 |
|