自动化测试框架cucumber_自动化测试框架Cucumber和RobotFramework的实战对比

关键字的概念很有趣，它们本质上就是一堆自由函数，或者是类的成员函数13，所以使用它们来编写用例事实上就是在编写代码，本质上和Cucumber的Step Definition是一样的。但由于RIDE以表格的形式呈现，并且有良好可视化的文档，在这种环境下写测试会给人一种“我不需要编写代码”或“我没在写代码”的感觉。在我们经历过的几个项目中，测试人员对这种形式都比较接受。当然从另一个角度看，用例的编写者失去了对测试代码的直接掌控权，这对于很多开发人员来说还是有些别扭，所以如果你不喜欢RIDE这种形式，可以尝试使用Pycharm来开发RobotFramework用例。

在这个项目中有不止一套测试运行环境，比如开发集成环境、CI环境、系统测试环境等。该项目包含了多个Web Portal，每套环境中Web Portal的IP地址都是不同的。如何保证一套测试代码能够在不同的环境中无差别的运行呢？简单的答案是配置文件或者环境变量，在RobotFramework中，解决方案是变量文件。比如我希望测试代码能够在开发集成环境和CI环境中运行，则可以按照下面的方式操作。

首先定义两个变量文件：

ci-env.py:

portal_ip = “192.168.1.1"

……

dev-share-env.py:

portal_ip = “192.168.1.4"

……

在用例文件中可以按照下面的方式引用上述变量文件中的变量：

……

open browser ${portal_ip}

……

然后在运行测试时加入如下的命令行参数即可针对CI环境运行测试：

pybot -V ci-env.py tests/

开发人员在自己编写调试测试或者定位问题时，在命令行中使用dev-share-env.py的配置即可针对另一套环境进行测试。

在这个项目中遇到的另一个问题是中文问题。客户非常在意用例是否能很好地处理中文，一方面是因为可读性，另一方面是要适配一些使用中文编写的Java代码。RobotFramework和Cucumber这些工具都有考虑国际化的问题，比如Cucumber Java版就支持使用类似于“给定”、“当”等中文关键字及中文的Step Definition，而RobotFramework对中文的支持也很好。但是如果从可用性的角度考虑，RobotFramework会比Cucumber好一些。原因是Cucumber本身并没有专用的IDE，只能求助于其它IDE插件，这些插件可以完成高亮、自动补全和Step Definition跳转等功能，但一旦使用了中文，有些功能就不好用了。而在RIDE中就不存在这个问题。所以如果你的团队因为某种原因对于中文用例的需求很旺盛，可以考虑RobotFramework。

如果重新选择，我还是会选择RobotFramework，主要从两个方面进行考虑：一方面是因为其“不用写代码”的方式更容易被测试人员接受，另一方面是对中文的支持更好。

通过上面四个案例，展示了在不同的项目中实际使用Cucumber和RobotFramework时的一些经验和选择它们的理由。但对于Cucumber和RobotFramework更多的知识点，下面有一个更为详细的对比表。