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

　　自动化测试一直是敏捷开发和敏捷测试的重要基石，也是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 numbersand

　　When add these two numbers

　　Then should getof 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

　　多领域语言型的框架可以通过多句或者多个关键字的领域语言来描述一个特定的场景，使得测试用例更容易阅读和理解，并且比较容易做成一套活文档系统。由于测试用例和测试实现是分离的，还可以对测试用例进行独立管理。

　　但是缺点也是比较明显的，开发、管理和维护成本较高，并且如果没有业务分析或者产品人员等非技术人员参与协作开发，那么它的投入产出比就很低，大家往往会认为它是事倍功半。

　　以上内容为大家介绍了自动化测试框架分类与思考，本文由多测师亲自撰写，希望对大家有所帮助。了解更多自动化测试相关知识：https://www.aichudan.com/xwzx/