一年多以前，我首先尝试了机器人框架。 在参与一个相当大规模的项目期间，我体验了两种使用此工具进行自动化测试的方法：在纯DSL机器人框架上编写测试，以及与Python协同工作。 如果第一条路径的入门门槛较低，那么从支持大型项目的角度来看，第二条路径更方便。 尽管这两种方法之间没有根本区别。 一种或另一种方式，全都归结为寻找库。
但是，值得讨论这些方法的功能。
谁是机器人，它与谁一起吃
可能值得从引入此功能强大的工具开始。
Robot Framework是用于关键字驱动的测试的框架。 它用于自动化验收测试和ATDD（通过验收测试的开发方法）。 该系统具有易于使用的测试数据语法，并允许您使用关键字自动执行测试。 此外，Robot Framework具有出色的内置库和第三方库，可让您快速启动自动化并将其集成到工作流程中，而无需发明自己的自行车-与我上面提到的相同的低入门门槛。
Robot Framework的基本结构是使用Python实现的，并且还可以在Jython（JVM）和IronPython（.NET）上运行。
使用示例以及有关框架和内部库的完整文档可在该项目的官方网站上找到：
http :
//robotframework.org/ 。
我的第一步。 第一种方法
一年后，我换了工作后第一次遇到机器人框架。 在此之前，我只使用Java和C＃进行自动化。
我为自己选择了应对现有测试所必须使用的工具，并就他们的偏好采访了新同事。 他们不同意使用机器人框架的最佳IDE。 用于各种文本编辑器和IDE的插件（例如PyCharm）主要允许使用Robot Framework。 我收集的建议在Atom和PyCharm之间分配为50/50。 当然，这里有RIDE，但这不是万能药。 那时（一年前），我没有找到关于它的常规文档，而在我发现的文档中，我没有发现我的任务有什么大的好处。 因此，对于初学者来说，我决定尝试使用带有插件的Atom。 克隆存储库后，我开始慢慢研究我们的测试以及Robot Framework本身中发生的情况。
实际上，我已经迷上了这个项目。 一堆Jython + Robot Framework已经在这里工作了，庞大的代码库（由DSL Robot Framework本身编写）是通过Java的1000多个测试和数千行辅助库的代码组装而成的。
据我了解，当项目开始时，即 甚至在我来该部门之前，主要是Java专家来进行研究，而被测产品本身就是Java，因此在选择一种方法时，我们将重点放在可用资源上。 通常，计算是这样的：解决了与Robot Framework和Java集成相关的一些问题之后（主要是因为Java是一种编译语言，但解释了Python和RF +捆绑包中的相同Python和测试），然后很容易吸引只了解DSL机器人框架的第三方专家，并悄悄地对关键字进行测试。 的确，同事们不得不花费大量的精力来用Java创建库，因此，在没有客户条件的情况下，他们不会推荐这样的路径。
做一些重构后，作为我的第一个任务，我首先运行了测试。 由于使用了Jython + RF捆绑包，因此maven收集了所有内容，并将机械手文件简单地复制到目标目录以供以后执行。
测试是通过脚本（.bat或.sh文件）运行的，这些脚本采用了指向单独的测试用例（单独的.robot文件）或测试计划（带有测试用例的相对路径的文件）的路径。
重构影响了大量的测试，因此第一次运行耗时约15分钟，完成后，该看一下Robot Framework提供的报告了。
标准报告（在上面的屏幕截图中）由report.html和log.html文件组成：
- 报告包含过去运行的一般摘要，您可以在其中查看所有测试（通过或失败）的表面结果；
- 在日志文件中，您可以查看更多详细信息-逐步执行每个测试。 在那里，您可以显示调试测试所需的一切。
坦率地说，乍一看机器人框架报告，眼睛开始有点抽搐：显示了大量信息，并且花了一些时间来理解测试的端到端结构并发展了读取此类日志的技能。 但是这项业务并不那么棘手。 在几个月内，我可以引用《黑客帝国》：“您的大脑自行翻译。 我什至看不到代码。 我看到一个金发，一个黑发和一个红发。” 因此，我-无需附加工具即可在文件中看到所有必要的信息。
加号的是可以控制输出：有不同级别的日志记录确定将显示哪些信息，而不显示哪些信息。 通过内置的库方法，甚至可以为每行单独调整电平。 同时，知道在测试库和辅助库中进行调用的顺序并不是多余的-更容易发现错误时刻。
使用DSL机器人框架作为主要工具，我们工作了大约六个月。 在这段时间里，我从个人偏好从Atom切换到VSCode，但这并没有改变该方法的本质。
但是，该项目正在开发中。 在最后的迭代中，用于该数据库的辅助库在纯Robot框架上总共有6,700行代码。 有了如此规模的代码库，就变得难以维护-重构未分配的所需资源。
应用第一种方法的最终决定权属于商业。 我们项目的客户还与其他团队一起完成了相关任务。 在其中一个平行的方面，他从他的角度看到了使用Robot Framework的一种更有效和更具说明性的选项，该选项开始专门为管理而实施。
第二种方法
第二种方法是结合机器人框架使用Python开发测试。 我们没有使用DSL Robot Framework语法创建所有内容，而是开始使用Python用测试产品编写帮助程序库和其他低级交互。 实际上，机器人框架只是成为赛跑者。
由于Python是一种纯粹的高级语言，而不是DSL，因此有更多的结构选项，因此更容易弄清楚。 至少，您可以使用Python IDE来帮助您找到相同的方法（它们执行相同的操作，但名称不同），甚至为您编写一段代码。 某些数据可以包装在生成器中，在函数上悬挂装饰器等。 在这种背景下，第一种方法的工具（纯Robot Framework）看起来相当苛刻-实际上，它是带有语法高亮显示的记事本。 没有IntelliJ为您编写的设置器或获取器。 所以我很高兴回到更高层次的语言。 使用这种方法更像是正常的开发。 是的，药膏里有蝇。 如果没有额外的跳舞，就不可能理解Python里面的东西，从RF调用。
慢慢地，我们的子系统的第一个测试和辅助库开始编写。 在能够使用新方法的那段时间里，我觉得使用其他工具确实有更多机会。 但是实际上，测试的编写并没有太大变化。 在这个特定的项目中，在Python代码内部，仍然调用了Robot Framework内置库方法。 这是由于客户对测试开发的特殊要求。 我们只是将可执行部分与测试用例算法分开。
哪个更好？
我个人喜欢第二种方法。 但是，选择项目的路径，值得从任务开始-谁编写测试以及如何编写。
如上所述，Python（第二种方法）提供了更多机会，但是在这种情况下，项目中需要熟悉这种语言的人。 Robot Framework本身（也是第一种方法）要求不高-您可以通过阅读DSL上的官方文档来实现。 在学习了用户指南之后，您可以创建任何测试-它们看起来将很干净。
因此，无需任何高级语言的明确编程经验，Robot Framework和我们最初使用它的方式就更适合于昨天的手动测试人员。 即使是一个不太参与编程的人也可以编写测试，只需调用必要的关键字即可。
但是，如果要按照我们的项目示例将可执行部分分开，并同时在友好的IDE中重构代码，则第二种方法适合您。
文章作者：德米特里大师
PS：我们在多个Runet网站上发表文章。 订阅我们在
VK ，
FB或
Telegram频道上的页面，以查找有关我们所有出版物和其他Maxilect新闻的信息。