自动化测试框架分类与思考

发表于:2017-12-14 08:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:刘冉    来源:思特沃克

  自动化测试一直是敏捷开发和敏捷测试的重要基石,也是DevOps和CI/CD必不可少的组成部分。由于不同项目的测试需求不同,以及各种不同的限制,导致需要的自动化测试框架和工具也不同。比如很多金融和能源类的企业就倾向于选择收费的企业级自动化测试框架或者工具,而新型互联网企业则倾向于开源免费的自动化测试框架或者工具,或者基于它们进行二次定制开发,或者重新开发适合自己的自动化测试框架、工具或者平台。
  我之前写过一篇文章——《自动化测试框架Cucumber和RobotFramework的实战对比》仅仅针对两种自动化测试框架进行了讨论,却引发了大量的讨论,由此可见业界对于自动化测试框架存在很多不同的理解和争议。在我看来,没有任何一个自动化测试框架是银弹,并且适合所有类型的测试,所以“如何选择一款适合自己的测试框架”变成为了一个首要问题。我将自动化测试进行了简单的分层,见下图。
  
自动化测试架构分层图
  其中测试库和被测系统紧密相关,所以可以选择的范围不是很大,也很难进行统一分类。而测试框架与被测系统关系并不紧密,而是和技术栈,开发流程与组织管理等关系紧密相关,并且种类繁多,可选择范围很多,所以选择也相对比较困难。
  因此对测试框架进行统一分类可以更好的帮助团队选择适合自己的测试框架,从而更好进行自动化测试开发。
  本文根据自动化测试用例的呈现方式和管理方式将其分为四种类型:函数行,单领域语言型,多领域语言型以及富文档型。
  四个类型:
  函数型
  函数型自动化测试框架是第一代自动化测试框架,也是最轻量的测试框架。它只是通过函数的方式来定义测试用例,并且通过管理这些函数的调用来管理测试用例,从而快速的实现自动化测试,比如xUnit等。
  例子JUnit
public class DemoTest {
@Test
public void testAddWithTwoNumbers() {
//测试实现代码
}
}
  函数型自动化测试框架由来已久,开发快速,运行稳定。虽然它相对简单与轻量,但是也存在缺点:很难通过函数名来描述测试用例的内容和细节,并且不方便对测试用例进行单独管理,因为测试用例的描述函数名和测试实现通常都在一起。
  单领域语言型
  由于函数型的自动化测试框架很难通过函数名去描述一个测试用例的内容。为了更清晰和容易的描述测试用例,就出现了单DSL型的自动化测试框架,比如RSpec,Jasmine,Mocha,RF等。
  例子Jasmine:
describe("The add function of the calculator can add two numbers", function() {
it("should get the sum after add two numbers", function() {
//测试实现代码
});
});
  单领域语言型可以通过自然语言或者关键字形式的领域语言来描述测试用例,从而以一种更加易读和理解的方式来描述测试用例。但是每个测试用例只用一句DSL语言,并不能很好的描述测试用例和被测场景,不易形成一套好的活文档。由于它的测试用例与测试实现通常也是在一起的,所以也不方便对测试用例进行单独管理。
  多领域语言型
  由于单DSL型框架中对于每个测试用例只能使用一句DSL来描述,并不能很好的体现测试用例场景,比如测试的前提,行为和结果等。为了能在测试用例层更为清晰的描述测试用例的行为和测试数据等型信息,出现了多领域语言型的自动化测试框架,比如Cucumber,JBehave,SpecFlow,RF等。
  例子Cucumber:
  测试用例代码
Feature: The add function of the calculator can add two numbers
Scenario: add two numbers
Given there are two numbers <Number 1> and <Number 2>
When add these two numbers
Then should get <Sum> of two numbers
Examples:
| Number 1 | Number 2 | Sum |
| 1        | 2        | 3   |
| -1       | 2        | 1   |
  测试实现代码
Given(/^there are two numbers$/) do
//测试实现代码
end
When(/^add two numbers together$/) do
//测试实现代码
end
Then(/^should get sum of two numbers$/) do
//测试实现代码
end
  多领域语言型的框架可以通过多句或者多个关键字的领域语言来描述一个特定的场景,使得测试用例更容易阅读和理解,并且比较容易做成一套活文档系统。由于测试用例和测试实现是分离的,还可以对测试用例进行独立管理。
  但是缺点也是比较明显的,开发、管理和维护成本较高,并且如果没有业务分析或者产品人员等非技术人员参与协作开发,那么它的投入产出比就很低,大家往往会认为它是事倍功半。
21/212>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • launcelot
    2017-12-14 17:14:24

    http://bbs.51testing.com/thread-1150457-1-1.html

  • launcelot
    2017-12-14 17:14:01

    http://upload-images.jianshu.io/upload_images/5146600-0c808d1e89d72486.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/669

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号