自动化测试框架的4种有效分类与使用选择

自动化测试一直是敏捷开发和敏捷测试的重要基石，也是DevOps和CI/CD必不可少的组成部分。由于不同项目的测试需求不同，以及各种不同的限制，导致需要的自动化测试框架和工具也不同。比如很多金融和能源类的企业就倾向于选择收费的企业级自动化测试框架或者工具，而新型互联网企业则倾向于开源免费的自动化测试框架或者工具，或者基于它们进行二次定制开发，或者重新开发适合自己的自动化测试框架、工具或者平台。
自动化测试架构分层图
其中测试库和被测系统紧密相关，所以可以选择的范围不是很大，也很难进行统一分类。而测试框架与被测系统关系并不紧密，而是和技术栈，开发流程与组织管理等关系紧密相关，并且种类繁多，可选择范围很多，所以选择也相对比较困难。
因此对测试框架进行统一分类可以更好的帮助团队选择适合自己的测试框架，从而更好进行自动化测试开发。
本文根据自动化测试用例的呈现方式和管理方式将其分为四种类型：函数型，单领域语言型，多领域语言型以及富文档型。
四个类型：
函数型
函数型自动化测试框架是第一代自动化测试框架，也是最轻量的测试框架。它只是通过函数的方式来定义测试用例，并且通过管理这些函数的调用来管理测试用例，从而快速的实现自动化测试，比如xUnit等。
函数型自动化测试框架由来已久，开发快速，运行稳定。虽然它相对简单与轻量，但是也存在缺点：很难通过函数名来描述测试用例的内容和细节，并且不方便对测试用例进行单独管理，因为测试用例的描述函数名和测试实现通常都在一起。
单领域语言型
由于函数型的自动化测试框架很难通过函数名去描述一个测试用例的内容。为了更清晰和容易的描述测试用例，就出现了单DSL型的自动化测试框架，比如RSpec，Jasmine，Mocha等。
单领域语言型可以通过自然语言或者关键字形式的领域语言来描述测试用例，从而以一种更加易读和理解的方式来描述测试用例。但是每个测试用例只用一句DSL语言，并不能很好的描述测试用例和被测场景，不易形成一套好的活文档。由于它的测试用例与测试实现通常也是在一起的，所以也不方便对测试用例进行单独管理。
如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣可以175317069，群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。
多领域语言型
由于单DSL型框架中对于每个测试用例只能使用一句DSL来描述，并不能很好的体现测试用例场景，比如测试的前提，行为和结果等。为了能在测试用例层更为清晰的描述测试用例的行为和测试数据等型信息，出现了多领域语言型的自动化测试框架，比如Cucumber，JBehave，SpecFlow，RF等。
多领域语言型的框架可以通过多句或者多个关键字的领域语言来描述一个特定的场景，使得测试用例更容易阅读和理解，并且比较容易做成一套活文档系统。由于测试用例和测试实现是分离的，还可以对测试用例进行独立管理。
但是缺点也是比较明显的，开发、管理和维护成本较高，并且如果没有业务分析或者产品人员等非技术人员参与协作开发，那么它的投入产出比就很低，大家往往会认为它是事倍功半。
富文档型
对于一些场景十分复杂，需要通过富文档的方式来描述软件测试场景，甚至需要一些业务流程图或者系统用户界面等，比如Concordion，Fitnesse，Guage等。
富文档型的框架比多领域语言型拥有更为丰富的文档，更容易阅读和理解，从而能做成说明书式的活文档，使得所有角色的人都能审阅。并且其测试用例和测试实现也是分离的。但是当前业界存在的富文档型测试框架的易用性和协作性都还不是很好，导致其开发，管理和维护成本相比前三种是最高的。并且当没有其它各个角色来协同开发，管理和维护时，其投入产出比也是最低的，所以它在行业中的使用率也是很低的。这类测试框架在易用性和协作性方面还有很大的发展空间，并且也是自动化测试框架和活文档系统的一个重要的发展方向。
总结与选择
自动化测试的代码实现层一般是与编程语言强相关的，而主流的编程语言比较少，所以选择比较容易：一般建议选择团队大部分成员都熟悉的编程语言(这样可以促使整个团队来对自动化测试进行开发和维护)或者是有特定测试库的编程语言（比如需要使用Scapy时就只能选择基于Python的自动化测试框架）。当确认自动化测试开发语言后，真正的问题是如何在如此众多的自动化测试框架里面选择合适自己的自动化测试框架。选择方法可以根据以上四种类型来进行选择，从而缩小选择范围。
当确认了测试框架类型之后，比如只有一个可选项（Java->函数型->JUnit），那么就直接使用了，但是如果存在多选项（JavaScript-> 单领域语言型->Jasmine vs Mocha），就还需要对其进行深入比较，从而最终选择自己适合的自动化测试框架。