RequestsLibrary general keywords
| Keywords |
Description |
| Create Session |
Creating an HTTP session |
| Get Request |
Way using get request |
| Post Request |
Post request using way |
| Put Request |
Put mode request using |
| Delete Request |
Delete mode request using |
| Head Request |
Head request |
| Delete All Sessions |
Delete all HTTP sessions |
| To Json |
Converted to json format |
▲ There are more keywords, the RF frame F5 key to view the test library to use, you need to close Create Dictionary libraries and other tests Get From Dictionary, Should Be Equal As Integers, Should Be Equal As Strings keywords
Test pyramid
From the pyramid chart shows:
1, UI testing of high input costs, slow, common black box automated test scenarios
2, Service Interface Test belongs among them, testing the maximum benefit, and most likely to have part of outputs and outcomes [prerequisite: the need for product developers must provide interface documentation]
3, Unit unit test low cost, high speed, generally have a product development team to carry out
Example interfaces with hierarchical design
Here module may be divided into three categories:
A class , divided by function modules, when named as a specific function names, such as login module, can be named Login, and function modules for a single module to verify the compliance with the intended function on each interface
The second category , by business module division, when named Business name, verify all business functions are stored in this directory is mainly used to verify the realization of specific business functions, interfaces associated with each combination of call verification, such as a video player verification when the function in which the video played for this particular business, it may involve a lot of calls between the interfaces, including interfaces pre-conditions, to transfer data between the interface, the interface data cleaning and so on.
项目的功能模块划分以具体的项目而定，在实际的接口自动化项目开展中，需要求开发人员提供项目接口对接文档。接口测试人员，依据接口对接文档描述，划分具体的功能模块及某个功能模块下包含了哪些具体接口。
三类，按安全模块划分，在命名时以Safe命名，所以安全功能验证均存放在此目录下同，主要用来验证接口安全，比如绕过验证、敏感信息是否加密等。
整体分层如下：
不同接口模块下，又可根据子功能的不同，划分成不同的接口。主要包含两部分：
1、接口业务关键字（所谓关键字驱动：对应在其它编程语言中，这里所说的关键字，其实就是封装的函数、方法），通常一个接口下，可以根据测试的业务不同，定义多个不同的关键字
2、接口功能用例，接口用例下仅需填测试数据即可(也就是常见的数据驱动测试方法)。通常不同的用例存放不同的测试数据，即业务关键字的入参，业务关键字根据接收到不同测试数据而去自动执行对应的业务流程。
通常将具体的一组动作序列封装一个业务关键字，测试用例中之所以只存放测试数据，设计核心就是在于将测试业务与测试数据分离。因为通常测试过程中，一个业务关键字的动作序列不会经常变更，需要变更的是测试数据，通常不同的测试数据，会导致业务关键字的产生的结果不同。如下图所示：通过调用数据驱动模板把每行不同的数据逐步传参到接口业务关键字执行用例。
公共方法数据分离
主要包括三部分：公共方法（Public）、项目配置文件(Config)、数据构造文件(xx_var.py)。其中：
● 公共方法，主要提供各个不同项目接口之间都会调用到的一些公共方法，如数据加密、解密，接口数据校验、接口统计等。
● 项目配置文件，主要存储接口在各个不同环境下（通常一个产品，开发完成后，都需要在测试环境验证通过后，才可发布到线上环境，这里所说的不同环境指的就是测试环境、线上环境）的访问地址，通常做法可在业务关键字编写脚本时，将接口访问地址通过变量来控制，然后此变量访问主配置文件对应的接口地址即可，通常接口环境分定义为测试环境下的接口访问地址、预发布环境接口地址、线上接口环境地址等。
● 数据构造文件，由于在不同环境下，需要用到的测试数据可能会有所不同，所以可通过构建对应环境下的变量文件来为接口在不同环境下执行时提供测试数据，变量控制文件中主要存储一些可变的变量文件，或通过函数来构造测试数据然后再将构建数据方法返回到具体变量中提供给测试用例或业务关键字使用。
数据控制文件的设计核心在于，在变量文件中定义构造数据的函数方法，然后将方法的返回值赋给一个变量，在具体的接口引用该变量。
除了通过python代码函数以外，还可通过如下关键字来封装成函数通过返回值传参供业务关键字调用，如下图所示：
- 封装加密接口
这里产品接口登录采用了token+毫秒级时间戳+md5+aes接口加密处理流程，具体解决方法如下：
先封装好生成密钥接口，如上图所示，先创建时间再转换原始时间，然后再转换为毫秒级时间戳，然后根据生成密钥规则原理进行逻辑处理，最后调用关键字Body Encrypt生成aes密钥，再返回创建的时间戳和产生的AES密钥提供其它用例模块使用。
这里的关键字Body Encrypt是需要自己二次开发测试库。然后导入自己开发的测试库就可以使用关键字，如下图所示：
- 封装获取token值
需要通过传参生成的AES密钥和时间戳传入给${Data}变量，登录成功后，会返回token值，提供其它用例模块调用。
- 数据驱动
如上图，录入数据，通过调用测试模板修改个人信息，把数据传参过去。
这里调用加密接口和获取token接口，把token变量传给头部，这样能够进行其它用例接口测试，因其它用例接口头部涉及到token字段，所以需要用到token构造头部。