开发测试自动化脚本以及自动化框架(2)

发表于:2016-10-17来源:UML作者:Sasha Reminnyi点击数: 标签:
测试人员 将获得一份关键字的参考引用,因此他们可以在表格中直接编写脚本。这些表格随后将导入某些关键字解释器中,并通过调用某个库中的特定实

测试人员将获得一份关键字的参考引用,因此他们可以在表格中直接编写脚本。这些表格随后将导入某些关键字解释器中,并通过调用某个库中的特定实现而开始执行测试。

测试自动化方案

我倾向于将特定于某个项目的测试脚本与所有相关的底层框架统称为测试自动化方案,它包含了与整个项目、测试环境管理、测试方案架构以及最佳实践相关的所有特定或一般性的框架,同时也包含了测试脚本。因此在进行评估时,我倾向于讨论整个测试自动化方案。

如何确定边界?

实现测试自动化通常来说意味着巨大的投入,因此重要的是尽早理解并使投入的回报清晰化,否则项目很可能会被取消

没错,在某些场景下,你可能需要开发一种特定的测试用具,而这非常耗时。但不能因此就决定选择一种独立于测试脚本之外的实现。你需要时刻牢记以最佳实践实现自动化测试脚本(以便于日后的维护),这才是最重要的。这种做法实际上只会节省你在项目上投入的时间。

举一个真实的案例:我曾经参与评估了一个“首次尝试”的自动化项目,它最终被取消了。其原因是所有的精力都投入到开发某个环境管理实验之中,以支持运行自动化的各种操作系统。经验丰富的开发者为此投入了数月的开发时间,但管理人员在开发过程中看不到任何投资收益。最后还是延续了手动的测试周期。

那么,如果在一开始选择仅支持一到两个最高优先级的环境,首先部署手动测试,随后对某个测试进行自动化,这种做法会不会更好一些呢?

其实,只要你能够减少测试的成本(或者至少能够预期成本的减少),同时交付可维护的自动化脚本,这正是控制成本的管理人员所乐于见到的。在实际实现背后的测试用具或许规模庞大,并且对于运行这些测试用例来说更为重要,但我们应具体情况具体分析。一般来说,在运行第一批脚本的时候,你不大会用到所有的测试用具。因此,我认为更重要的地方在于提供一个一致的测试自动化方案的架构,它能够允许你今后对测试用具进行扩展,而不是一上来就要完成所有的测试用具。

你可以在这里找到一种可扩展的测试自动化架构的描述,这是一种分层的测试方案。它的做法是将代码分解为多个独立的层,并创建相应的Page Object对象。这种做法不需要你投入大量的时间,却能够为最终的方案带来很大的可维护性。而且,最终的方案能够在一种还是多种操作系统、web浏览器上工作,这一点真的并不重要,我们可以随后为其添加多平台的支持。

另一个值得一提的重要领域就是关键字驱动的框架,这种途径意味着你首先需要开发出一个框架(一个关键字的集合),随后才能够通过将这些关键字链接在一起的方式开发测试脚本。

我个人认为这种做法是一种糟糕的实践。首先,在电子表格中进行开发非常容易出错,任何一个拼写错误都会造成错误,并且难以通过调试发现。此外,如果你在编写业务逻辑,而生成的测试却不会调用这些逻辑,那就好像在开发应用程序的业务逻辑时不提供任何单元测试、或是不提供用户界面一样。另外,你永远都无法预先估计你需要开发多少条关键字,才能够让一定特定的测试得到足够的关键字,从而满足测试脚本的需求。

一种推荐方法

我将描述一种我个人对测试自动化方案进行计划的方法,按照我的经验来看,这种方式已经证实了它的正确性,不过它也只是“正确的做法”之一。

1.客户对于引入测试自动化这种做法的期待是什么?对于当前项目的时间表与技术能力来说,测试自动化是否真的可行?我的看法是,在某些时候,在这一阶段对此问题的回答是“测试自动化完全不适合于实现你的目标”。出现这种情况的一种可能是:自动化的开发工作与所获的益处相比,所投入的精力过于巨大。

2.了解将测试系统的技术,并且选择最适合的自动化工具以模拟用户的行为也非常重要。

3.那么,我们应当选择怎样的方式呢?我在这里要区分两种主要的方式,即“快速而粗糙”的方式,以及“基于解决方案”的方式。“基于解决方案”的方式在上文已经描述过了,“快速而粗糙”则意味着可以说这种方式“只能够在我的机器上运行”。只需一些最基本的投入,你就能够立即得到一些结果。对于性能测试来说,这种方式不失为一种良好的选择,因为获取系统的性能参数有时(但也并非总是如此)就是一种一次性的活动。

原文转自:http://www.uml.org.cn/Test/201610172.asp