做自动化测试，离不开自动化测试框架(Framework)。框架约定了自动化测试用例的编写规则，并提供用例解析、用例执行、测试报告生成等基础功能。正是因为有测试框架的支撑，我们才能把测试工作重心放在和业务紧密相关的用例设计与实现之上。
谈到自动化测试框架，我们经常看到的一个身影就是Robot Framework。作为著名的开源测试框架，Robot Framework拥有一定的江湖地位。有人根据字面意思把它翻译成"机器人框架"，个人感觉这个翻译有点宽泛，我还是习惯直接叫它Robot Framework。
Robot Framework从诞生至今，已有十几年的历史。它的作者是芬兰人Pekka Laukkanen，其设计思想源于Pekka在2006年提交的，题为"Data-Driven and Keyword-Driven Test Automation Frameworks"的硕士论文。在同年，Robot Framework有了第一个版本。2008年，Robot Framework v2.0正式在Github上开源。它的最新版本是今年5月发布的v3.1.2。
刚参加工作时，我就开始接触Robot Framework，前后与它打了好几年交道。在这期间，我既使用Robot Framework开发了多种不同测试场景中的自动化测试用例，也基于Robot Framework开发了若干第三方测试库。可以说，对于Robot Framework，我是蛮喜欢的，对它的理解也越来越深入。
今天，我就来总结一下自己对Robot Framework的认识和体会。这部分内容是整体和宏观的。至于Robot Framework的具体内容和技术细节，例如安装方法，使用示例，标准库和第三方库介绍等，在网络上有现成的材料，我就不在这里重复了。
先来看看Robot Framework的特点。作为一款完整的自动化测试框架，它的特点我们可以列出一长串出来。然而，如果只允许用三个词语来形容它，个人觉得应该是: 通用(general)，关键词驱动(keyword-driven)和模块化(modular)。
Robot Framework并不是为某一行业或某一类型的软件测试所设计的。相反，它的技术框架是通用的，适用于各种各样的自动化测试场景。例如，在接口测试，UI测试，端到端测试中，Robot Framework都是适用的。
自动化测试框架通常分为线性框架，数据驱动框架和关键词驱动框架三大类型。Robot Framework属于关键词驱动型: 测试数据和测试脚本分离，并且测试脚本中的通用功能被剥离形成关键词。测试用例本质上是对一系列通用或自定义的关键词的调用。
从内部架构上看，Robot Framework整体是分层和模块化的，自上往下分为四层: 测试数据，测试框架，测试库和被测系统(SUT)。其中测试库这一层又进一步模块化，由许许多多的标准库/第三方库模块组成，它们是承担核心自动化工作的底层模块。
再来看看Robot Framework的优势。上面总结的三大特点，其实各自都能引申出一些优势。例如，因为通用性好，所以Robot Framework具有应用面广的优势；因为使用了关键词驱动，Robot Framework测试脚本易于封装和复用。
另外，因为模块化，Robot Framework的可扩展性好，支撑能力强。上面提到，核心的自动化工作由测试库完成，而Robot Framework支持扩展Python或Java两种语言开发的自定义测试库。我们可以充分利用Python和Java的生态优势，开发各种各样的测试库，来拓展Robot Framework的功能。
除此之外，Robot Framework还有一个显著优势，那就是开发自动化用例的门槛低。这是因为，Robot Framework提供了独特的Robot语法。它接近自然语言，约束限制条件少，并且支持制表式编写。也就是说，大家可以像编辑Excel文件或写文本文档一样，来开发自动化测试用例。
这意味着，一个几乎没有什么开发经验的测试工程师，经过简单培训，就可以运用Robot Framework完成自动化测试工作。因此，在传统测试团队向自动化转型的过程中，Robot Framework是很适用的。
然而，"凡事皆有两面性"，Robot Framework既有优势，也有局限。从本质上说，Robot Framework是一种领域专用语言(domain-specific language, DSL)。作为DSL，Robot Framework凭借十分灵活的语法，提升了开发自由度，降低了开发门槛。然而，"水能载舟，亦能覆舟"。当项目规模逐渐变大时，DSL会让项目变得越来越难以维护。
软件项目的可维护性与多种因素有关，包括代码可读性，代码简洁性和代码自身的质量控制。然而，作为一种DSL，Robot Framework缺乏像通用编程语言(general-purpose language, GPL)那样完整的代码风格检查，语法检查，静态分析，动态分析，单元测试等内部质量保障体系。
这意味着，较低的开发门槛会导致低质量脚本引入到项目中。当大量风格迥异，重复度高，结构不清晰，未经充分测试的自动化用例堆积在一起时，项目会陷入混乱。这时，自动化测试用例不仅难以胜任测试工作，而且后续的增加，修改，删除成本也更高，也更容易引入新问题。
多大规模的Robot Framework项目会遇到这种困境？以我个人经验，当测试用例数量100+或测试脚本行数10000+时，有较大概率会出现问题。例如，我曾经参与过的一个拥有20000+行脚本，300+用例的Robot Framework自动化测试项目，就严重遇到这种困境。
为了自救，我们制定了统一的代码风格规则，开发了代码风格检查，重复度检查等脚本，并使用了Robot Framework自带的dryrun技术，虽然一定程度上提升了项目的质量和可维护性，但距离目标还很远。
毕竟，这种"打游击"的方式，与"正规军"无法相提并论。缺乏原生的内部质量保障体系，是DSL们无法消除的痛点。
到这里，大家可以看到Robot Framework具有的"两面性"。一方面，它的语法灵活，上手容易，"接地气"，能够满足各种测试场景和测试团队的自动化需求。
事实上，这些年来，Robot Framework的生态优势和影响力稳步上升。在一年一度的Robot Framework大会(RoboCon)上，各种围绕Robot Framework的优秀测试工具，测试库和应用案例层出不穷。
另一方面，由于Robot Framework作为领域专用语言(DSL)的局限性，使得它在较大规模的自动化测试项目中，可维护性比较差，自身质量难以保障，因此适用性并不好。
了解这种"两面性"，对自动化测试框架的选型是很有必要的。个人觉得，当测试团队的自动化能力比较成熟时，完全可以采用基于通用编程语言的测试框架，例如近年比较火的Python pytest。通用编程语言的生态优势，良好的扩展性，以及全面的内部质量保障体系，可以帮助我们完成任意规模的自动化测试工作。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
