今天聊得是自动化测试与测试用例的编写,首先来聊一聊框架(Framework)。
框架是工程学上一个非常重要的概念。在计算机和软件工程领域,我们可以轻松列举出一些耳熟能详的框架。例如,Windows软件开发框架.NET,Web开发框架React JS、 Angular JS、Python Django、Ruby on Rails, 机器学习框架TensorFlow、Caffe,等。
那么,什么是一般意义上的框架呢?首先,框架是一个“架子”。这个架子能够完成领域内基础的、重要的功能。基于这个已有的架子,我们可以将重心放在面向业务的开发上。其次,框架也是一个“框框”。“框框”为我们设置了有形和无形的约束。所谓有形的约束,就是我们的开发工作需要符合框架的定义、与框架兼容。所谓无形的约束,就是我们的开发工作需要承受框架的缺点和不足(毕竟,没有十全十美的框架)。
回到测试自动化领域,什么是测试自动化框架呢?顾名思义,就是用于测试自动化的框架。具体来说,它提供了自动化测试用例编写、自动化测试用例执行、自动化测试报告生成等基础功能。我们只需要基于这个框架,完成和业务高度相关的测试用例设计和实现即可。另外,框架会为我们处理好复杂度与扩展性的问题,我们无需为此操心。
相比手动测试,自动化测试更加注重框架。毕竟,自动化测试本质上也是一种软件开发活动,也需要适当的软件框架。在多个项目中,使用一致的自动化测试框架,可以让复用自动化测试成为可能。
在某一领域,经常存在着多种类型的框架。测试自动化也不例外。那么,有哪些种类的测试自动化框架呢?它们各自有什么特点?
线性框架:又指录制和回放(play and record)框架。在这种框架中,测试人员通常不需要编写测试脚本,只需要录制某一次测试的过程(自动生成测试脚本),然后在后续的测试中回放这次录制的结果(执行测试脚本)即可。线性框架最大的好处是无须手动编写测试代码,因此门槛较低、易于上手。然而线性框架的不足之处也很明显:录制的脚本是固定的(hardcode)。这意味着,当应用发生微小变化时,上一次录制的脚本可能就无法使用了,需要重新录制(rework),从而产生大量的后期维护成本。
数据驱动框架:在数据驱动框架中,测试数据和测试脚本是分离的。在许多测试场景中,需要使用不同的测试数据多次测试同一功能或特性。如果测试数据是hardcode进测试脚本的,那么每更换一次测试数据都需要修改测试脚本。这是很大的工作量。此时,可以使用数据驱动框架。具体来说,测试脚本是固定的,而测试数据可以从外部的数据文件,以Excel、CSV、SQL等形式作为参数传入测试脚本。这样,我们只需要维护一份脚本和一份数据文件即可。总体来说,这种框架最大的好处就是易于维护。但是识别与格式化数据、编写通用测试脚本等需要花费技术和时间。
关键词驱动框架:在关键词驱动框架中,测试数据和测试脚本也是分离的。不同的是,这个框架更进一步地将测试脚本中的通用功能剥离出来,形成关键词(keyword)。测试脚本本质上就是对一系列通用的或者自定义的关键词的调用。这样做的好处是关键词可以在多个测试中复用,并且测试脚本更加易于维护。不过,实现这样一个框架并非易事。
除了上述三种类型,测试自动化框架还有:模块化框架、库结构框架、混合框架等类型。
需要指出的是,业界已经有了实现上述各种测试自动化框架的工具。通常来说,我们并不需要重新发明一个新的框架,而是基于已有的框架完成自动化测试工作。那么,面对一个新的自动化测试框架,如何着手工作呢?笔者认为,我们应该聚焦在以下四个问题上。
如何生成测试用例?不同的框架,生成测试用例的方法不一样。对于线性框架来说,无须编写脚本,只需要点击预设的按钮就能够生成测试用例;对于多数框架来说,生成测试用例需要编程。当然,不同框架使用的编程语言、编程风格有差异。对于Selenium框架来说,使用的是通用编程语言Java;对于Robot Framework来说,使用的是其专用的Robot Framework编程语言。一般来说,使用框架编程的过程很多时候就是调用库接口的过程。因此作为前提,在编写用例之前,我们需要熟悉框架提供的库的种类和功能,以及这些库所提供的API的使用方法。
如何执行测试用例?当测试用例完成之后,我们需要运行测试用例。自动化测试是通过GUI图形界面来触发,还是通过CLI命令触发,这因框架而异。当然,仅仅知道如何触发测试是不够的。我们通常有更多的需求。例如,如何选择性地执行满足特定条件的测试用例子集?如何设置全局的执行参数(超时时间、日志路径、报告形式、...)?如何动态地给测试用例集传入参数?一般来说,一个完整的框架需要提供足够多的控制选项,从而让我们根据需求定制执行测试的方式。以Robot Framework为例,其执行用例的命令具有30多个不同的选项。这提供了足够的自由度和一些非常棒的功能。例如其dryrun选项,可以让我们在不实际执行用例的情况下,快速检查出测试用例中参数不匹配、语法不正确、关键词找不到、库导入失败等错误,非常实用。
如果对软件测试、接口测试、自动化测试、面试经验交流。感兴趣可以加软件测试交流:1085991341,还会有同行一起技术交流。
如何检查测试结果?测试执行结束之后,我们需要关注测试结果。不同的框架会以不同形式提供测试结果。例如,测试结果既能以控制台日志的形式体现、也能够以图表和报告的形式体现。根据测试结果,我们可以很容易地了解测试的执行情况,包括测试的成功/失败情况、测试的整体/局部用时等。当测试失败时,我们尤其需要关注测试失败的具体情况。通常,我们关心失败是由于我们使用框架的方法不当造成的,还是由于被测软件的质量问题。这一点,只能通过检查和分析测试结果得到。
如何扩展测试框架?一般来说,框架只是提供了最基本的功能。很多时候,框架并不能直接满足自动化测试的需求。这时我们可以寻求第三方的、与框架本身兼容的库或者插件。如果第三方工具不能满足我们的需求,我们就需要开发自己的库和工具。例如,对于HTTP、SSH等公有协议,我们很容易在网络上找到某个框架的第三方库;而对于只用于公司产品的私有协议,我们通常无法找到第三方库,只能自己开发。自己开发时,需要注意的是要遵从框架的规范,使得开发出的库能够与框架无缝兼容。
我们已经强调过,选择了一个框架,在享受其好处时,也不得不承受其不足。如果我们的关键需求受制于框架,并且框架也不容易扩展,那么我们就可能需要开发自己的框架。这是一件投入较大的事情。
以上内容希望对你有帮助,有被帮助到的朋友欢迎点赞,评论。
网友评论