你的组织为自动化测试做好准备了吗?(2)

发表于:2011-09-15来源:未知作者:领测软件测试网采编点击数: 标签:自动化测试
2.2.5. 级别 5:使用动作词的测试自动化 这是自动化测试的最高级别。主要的思想是将测试用例从测试工具中分离出来。这个级别要求有一个具有高技能测

  2.2.5. 级别 5:使用动作词的测试自动化

  这是自动化测试的最高级别。主要的思想是将测试用例从测试工具中分离出来。这个级别要求有一个具有高技能测试人员测小的团队,这些测试人员能够将测试工具的非常深层次的知识与他们具备的较深的编程能力结合起来。这个团队负责在测试工具中生成并维护测试的功能性,能够使测试工具从外部的来源,比如 excel 表或者数据库中执行测试用例。这种测试概念最初是由 CMG 开发的。与 CMG 方案相比,其他的可能的开放源码的方案有被 Carl Nagle 和SAS Institute 开发的 DDE。使用 DDE 的概念,关注点是当在Excel表中创建测试用例的时候,放置使用包括被使用的特定动作词语的一些类型的模板。执行的过程是从 Excel 表中读取测试用例,并将测试用例转换成为测试工具能够理解的形式,然后使用不同的测试功能来执行测试。

  这个概念变得越来越流,因为测试与用例一起使用是非常有用的。

  好处 测试用例的设计被从测试工具中分离了出来 - 关注在设计良好的测试用例上。允许快速的测试用例的执行和基于用例的更好的估计。

  缺点 需要一个具有工具技能和开发技能的测试团队,以提供并维护测试工程(框架)。

  用法 专业的测试自动化将技能的使用最优化的结合起来

  如果工具不具备使用内建的对象映射的可能性,那么这个方案对于消除与 GUI 相关的大部分维护成本是优秀的。在一些组织中已经创建了这种方案,并且他们其中的一些已经实现了高度的自动化(60%),并且他们都得到了巨大的回报。如果测试框架是适当的,我们能够使用 excel 来生成实际的测试用例。

  这个级别对于那些按照正规基础使用用例的组织或者项目来说是非常优秀的。有多少测试用的估计是被需要的,并且当用例适当时需要做的工作也是非常简单的。你可以集中时间来生成第一个包含被需要的"对象映射"的测试用例(主流程)。依靠被测试应用的复杂程度,通常这会花费大约半天到一天的时间。后续的被需要的每一个测试用例大概会花费 15 到 20 分钟的时间,因为通常多数的测试用例可以复制已有的测试用例,并对其进行必要的修改,通常这种修改是有限的。动作词语框架能够通过使用用例使紧密的并行测试用例的开发变得可能。

  2.3. 我们不需要培训!

  我们所有的人都在某一些方面具有一定的经验,我们没有时间能够花费在使用新工具的培训上。当一个对自动化工具还不是很熟悉的组织或者项目团队开始实施自动化测试时,培训和指导是至关重要的。如果我们允许组织或者项目团队在没有关于应该如何做的任何知识的情况下实施自动化的测试,那将肯定会以失败告终。用于实施自动化测试方案的预算会被超出,测试会被延误并且更坏的情况是自动化测试将被放弃。组织和项目团队需要尽量避免一些认识上的缺陷,尤其是自动化测试的维护成本和当测试人员尝试和确认工具如何工作时产生的挫败感。你需要确保你的测试过程是适当的 - 如果测试过程是不合理的,引入自动化测试只会给软件组织或者项目团队带来更大的混乱。因此,我建议希望实施自动化测试方案的组织或者项目团队应该在实施之前建立"训练营",并将重点放在培训测试团队能够很好的利用一个原型的项目上。

  为第一个原型项目制定一个实施计划,下面包括原型项目的最小化的描述:

  当先状态

  我们希望实现什么 - 建立成功的因素

  期待的回报(第一次自动化测试工作被期望验证什么)

  找到一个"简单的"测试的痛处并尽力的通过自动化测试解决它,这可以被作为在同一时间上使测试运行在多个平台上的样例

  说明被需要的资源和时间

  ......

  一开始你就要大声的说出成功的信心 - 让人们了解你所展示的进展。这将吸引更多的关注和资源。

  2.4. 我们必须 100% 的自动化

  从管理的角度来说,100% 的自动化目标只是一个从理论上可能达到的,但是实际上达到 100% 的自动化的代价是十分昂贵的。

  一个 40-60% 的利用自动化的程度已经是非常好的了。达到这个级别以上将增加测试相关的维护成本。由于对每一个构建版本的需求变化的复杂度,你将花费更多的时间在变更测试用例上以使他们能够正确的运行。在这种情况下,通过告知管理层 100% 的自动化目标是相当昂贵的来确立一个合理的期望值才是明智之举。对于决定自动化一个测试用例的一般规则是这个测试用例必须被运行 4 次以上。这个数字是基于用户对测试工具有良好的技能并且有一个良好的测试框架的。如果情况不是这样的化,整个数字能够是 10-20次或者更高。一个例子,在一个项目中测试人员花费和两周的时间将手工测试的 23天的任务转换成了自动化测试的用例。在完成使,项目能够在 4 个小时在多个平台上运行相同数量的测试用例。

  2.5. 测试框架

  测试框架对于产生成功的测试自动化的适当基础是重要的。很多考虑必须被解决以使测试自动化更加有效地被使用。重点必须在:

  维护成本

  维护成本是成功的使用自动化测试的最重要的问题之一。维护成本直接联系到前面已经提到过的自动化测试的成熟度。组织或者项目必须至少要在成熟度的 3 级使用高度的测试库才能使维护和更新测试功能变得容易。

  测试数据

  什么样类型的数据将被使用?要为每一个测试用例生成测试数据还是使用在被测试应用中已有的数据。在很多的情况下一个测试数据被创建了,删除他们是不可能的。

  可测试性

  自动化测试方案能够有效的测试吗?例如,被适当命名的对象(不仅仅是索引 Id)。一个简单的例子是所有的对话框都有相同的 #id 和相同的标题,所不同的仅仅是显示的文字信息。当测试应该覆盖多种语言的方案时,对话框的测试就是一个挑战。

  测试人员的技能

  被包括在自动化测试的创建中的人员应该具有什么样的技能呢?如果他们具有良好的开发背景,那么成熟度 3 级是足够了。如果他们有很少的或者根本没有开发的经验,我们被迫使找到或者培训一个自动化测试专家的小组,并直接到达成熟度 5 级,在成熟度 5 级测试的创建与实际的测试执行被分离开。

原文转自:http://www.ltesting.net