RobotFramework + HTTP接口自动化实现

一、          什么是自动化测试？

1.      定义

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，也可以说是软件测试的一种技术手段。

2.      常见工具

• • Appium： AppUI自动化测试，一个移动端自动化测试开源工具。

• • Selenium： WebUI自动化测试 ，一个用于Web应用程序测试的工具。

• • QTP ： WebUI自动化测试，提供符合所有主要应用软件环境的功能测试和回归测试的自动化。

• • Robot： 多功能自动化测试，是一款python编写的功能自动化测试框架。

• • Loadrunner： 性能测试，一种预测系统行为和性能的负载测试工具。

• • Jmeter： 接口性能测试，用于测试静态或者动态资源的性能。

• • GT： App性能测试，一个直接运行在手机上的“集成调测环境”，可对APP进行快速的性能测试。

• • Monkey： 稳定性测试， 适用于android和ios，通过adb shell，生成用户或系统的伪随机事件，

• • Appscan：  安全测试，一个适合安全专家的 Web 应用程序和 Web 服务渗透测试解决方案。

• • Jenkins： 持续集成 ，用于自动化构建，编译，部署，任务执行，测试报告，邮件通知等。

3.      常见误区

• • 自动化测试找不到bug？

自动化测试不直接找bug，而是通过自动化测试解放出测试人员的时间和精力，来间接地找到更多、更深层次的新bug，将产品质量再提高一个档次，还有就是用于快速迭代中的回归测试。

• • 自动化测试一定会马上大量减少测试人员数量？

自动化测试不会马上大量减少测试人员数量。因为开展自动化测试初期需要投入一定的人力进行自动化测试脚本开发，并逐渐将自动化测试脚本用于日常的测试中，逐步减少手工测试人员从事重复劳动的时间和人数。

• • 自动化测试能提供百分百的测试覆盖率？

并非所有内容都可以被自动化地测试到。不可能覆盖所有可能的输入，所有可能的组合和路径。自动化测试可以增加测试的广度和深度，但是仍然无法达到100%的测试覆盖率，因为没有足够的时间或资源。

二、         
什么项目适合自动化？

       通常，以查询报表为主的系统，就是以插入，查询，删除，编辑为主的xx管理系统，这种系统不适合做web自动化。why？ 因为这种系统一般定位起来也比较麻烦，主要以嵌入式表格为主，层次较深，没有特定属性，很难准确定位，要写又臭又长的xpath。最主要的是不太好断言结果，因为你的数据是查询出来的，今天查询出来“张三”在第一页，后面这个查询数据增加，“张三”跑后第五页了，再后来跑到第170页，你说怎么用固定的信息断言？ 没有断言，你怎么知道查询的结果对不对？

这种系统的核心就是数据，其后台实现就是各种增删改查询接口。功能可用就好，一般这种系统不讲究用户体验之类的，关键是数据得正确。尤其是针对金融领域相关的系统，那少算一个数、一个零、一个小数点，事可就大了。所以在我看来做web自动化的实际意义并不大，或者说这类系统做web自动化的并不是系统最重要的部分。但是，这类系统非常适合做接口自动化测试，why？因为接口测试关注的就是数据，我们可以通过改变传参，然后断言接口的返回，以及数据入库结果。最后只要数据正确了，功能就做成大半，剩下的无非是如何把这些数据展示在页面上。

三、         
Robot Framework

1.     简介

Robot Framework是用于验收测试和验收测试驱动开发（ATDD）的通用测试自动化框架。 它具有易于使用的表格测试数据语法，并使用关键字驱动的测试方法。 它的测试功能可以通过使用Python或Java实现的测试库进行扩展，用户可以使用与创建测试用例相同的语法，从现有的关键字创建新的更高级别的关键字。

2.     特点

• 使用简单

当你真的要向项目中推广一个技术或工具的时候，其实这点非常重要。对于大多测试团队的测试人员来说，开发技术还是很薄弱的。RF使用非常简单，只要告诉你是这些关键字是做什么用的，你去“填表格”就好的。

• 支持开发系统关键字

RF可不是只能写一些死板的操作过程，定义变量，数组、字典，写if判断，for循环都不在话下，甚至调用python所提供的方法。

• 可以像编程一样写测试用例

开发系统关键字，或者自己写个自定义库也很简单，用工具，但又不会受制于人工具。

• 非常丰富的库

详情参考以下内置库和扩展库说明。

3.     内置库

• • Builtin：提供一组经常需要的通用关键字（默认自动引入）。

  • Collections：提供一组用于处理Python列表和词典的关键字。

  • DateTime：用于日期和时间转换的库。

  • Dialogs：提供暂停测试执行和从用户获取输入的方法。

  • OperatingSystem：用于执行各种与操作系统相关的任务。

  • Process：用于在系统中运行进程的库。

  • Remote：可以连接到Telnet服务器并在打开的连接上执行命令。

  • String：用于生成，修改和验证字符串的库。

  • Screenshot：提供关键字以捕获桌面的屏幕截图。

  • Telnet：可以连接到Telnet服务器并在打开的连接上执行命令。

  • XML：用于生成，修改和验证XML文件的库。

4.     扩展库

• • WEB自动化测试：Selenium2Library(Python)、Selenium2Library(Java)
    等。

  • HTTP自动化测试：HTTP library (livetest)、HTTP library
    (Requests) 等。

  • 移动自动化测试：Android library、IOS library、AppiumLibrary等 。

  • 数据库测试：Database Library、MongoDB library 等。

  • 文件对比测试：Diff Library。

  • Windows-GUI测试：AutoItLibrary。

.

四、         
环境搭建

1. 开发语言

Python2.7，对RIDE版本兼容性较好。

2. 自动化框架

Robot Framework，不再多说。

3. 编辑器

RIDE，用于测试数据的轻量级直观编辑器。

4. 引用库

HttpLibrary.HTTP，用于接口测试。

DatabaseLibrary，用于数据库查询验证。

5. 必要插件

wxPython，编辑器RIDE的 GUI开发库。

6. 安装说明

个人建议：Python2.7 + wxPython2.8 + RF3.0 + RIDE1.5

详情参考附件及文档说明：

链接: https://pan.baidu.com/s/1KKVTqLzbtMciHINMqc6ELA 提取码: 59de

五、         
工程架构

 1.      
项目主目录 

CRJM，用于存放系统各模块的测试用例集，测试用例。

2.      
基础关键字 

BasicResoure.txt，用于存放公共关键字。

3.      
配置文件 

config.ini，用于存放系统地址，数据地址，用户信息等。

4.      
数据文件

cr_api_info，用于存放接口url和请求体。

5.      
自定义库

MyLibrary，存放我们自己开发的一些关键字。

六、         
用例编写

1.预制/清理数据

测试前的数据预制，以及数据清理。

比如，测试建卡成功，那么就要确保数据库不存在这条数据，需要提前清理数据；

反之，测试建卡重复，那么就要确保数据库已存在这条数据，需要提前预制数据。

2.      
设置请求体

根据测试点的不同，设置不同的请求体，达到测试的覆盖。

3.      
发送请求

根据接口的不同（如post、get），调用不同关键字。

4.      
验证响应体

获取响应体进行校验，如果响应体固定不变，可以整体校验；反之动态变化，请拆分进行校验。

5.      
验证数据库

根据数据实际入库情况，编写不同SQL语句进行校验。

6.      
数据清理

为了防止数据库太多冗余数据，测试完最好清理掉。

7.      用例设计思路

七、         
执行查看

1. 左侧是用例条目，可以添加删除，以及勾选执行。

2. 上方是常用操作，可以进行执行/停止/暂停等操作，执行完毕可以查看报告和日志。

3. 中间是结果版块，打印用例执行情况，以及报告日志文件存放路径。

4. 下方是日志版块，打印用例实时执行日志。

八、         
结果分析

1. 首先是测试报告，可以查看执行日期时间，以及执行条目，成功条目，失败条目，耗时等

2.再者是执行日志，可以查看到测试用例详细执行情况，并且可以根据失败用例集>>失败用例>>失败步骤>>错误日志，最终定位到具体问题。

九、         更多资料

https://www.cnblogs.com/leozhanggg/p/9675263.html

Reference:https://www.cnblogs.com/fnng/p/5370433.html, https://www.cnblogs.com/fnng/p/4333977.html