关键字的概念很有趣,它们本质上就是一堆自由函数,或者是类的成员函数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更多的知识点,下面有一个更为详细的对比表。
三、测试工具选择的一般性原则
在上述的实战案例中,针对项目的具体情况我们对Cucumber和RobotFramework这两种工具进行了取舍。本节就来总结一下这些取舍的考虑因素。
首先来看一下自动化验收测试的层次:
然后对每层进行分析:
1、最下面是被测系统,需要明确它的形态,比如是Web系统、REST系统或者特定协议系统。
2、中间是测试库。比如Selenium、SSH、Scapy等,有了它们用例才能和被测系统进行交互,所以需要根据被测系统的形态来选择相应地测试库。该层的选择需要考虑几个因素:
· 测试库的易用程度。
· 测试库是否有良好的商业或者开源社区的支持。
· 团队成员是否熟悉测试库使用的编程语言。
3、最上层则是测试框架,也就是Cucumber和RobotFramework这一层。其作用包括用例管理、测试数据管理、测试运行、测试报告等。该层的选择需要考虑几个因素:
· 这一层会通过函数调用的方式和测试库打交道,因此测试框架必须支持测试库所使用的编程语言。
· 是否提供易用的测试用例开发环境,比如是否有如RIDE这样的专用工具,或者Intellij的IDE的插件。
· 引入某个测试框架之后对现有工作模式的影响程度,比如让不懂编程的测试人员写代码。
以上这些点是从RobotFramework和Cucumber的对比中总结出来的,但如果你想要选择这两者之外的其他框架,同样可以考虑上述这些原则。
四、总结
我们在银行、保险、社交、电信、物流、互联网等项目上实施过自动化功能以及验收测试。对于Cucumber和RobotFramework到底属于ATDD还是BDD,这里不做过多的讨论,因为当前在业界对于ATDD和BDD怎么区分还有一些争议,而对于我们来讲,它们只不过是两个名词而已。对于这两个工具本身来讲,只需要清楚它们各自的特点,根据项目本身的情况和需求选择就可以了,简单地说就是:知行合一。
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。