A super easy-to-use interface automation framework, lemon-easytest internal beta version is released, hurry up and use it~

easytest

easytest is an interface automation framework.

Features:

Support http interface testing
Supports response assertions in json, html, xml formats
Support database assertions
Support use case tag filtering
Supports re-run of use case failure
Support multi-threading

Installation

pip install lemon_easytest

Quick use

There is no need to write any code, all you need to do is write the use case document according to the rules and then run the command easytest.

easytest supports use case documents in yaml format and excel format.

Create the file singe_test.yaml in any directory with the following content:

test: #Table name This is a single test case
  title: A simple test # Use case name
  url: http://httpbin.org/get # url
  method: get # Request method
  request: # Request parameter field
    headers: # Request headers
      CustomerHeader: lemonban #Header information
    params: # url parameters
      search: lemonban # url parameter key-value pair
  res_type: json # Response data type
  status_code: 200 # Status code
  assertion: # assertion expression
    -
      - eq # equal
      - $..Customerheader # Result extraction expression
      - lemonban # expected value
    -
      -eq
      - $..search
      - lemonban

If you want to learn automated testing, here I recommend a set of videos for you. This video can be said to be the first interface automation testing tutorial on the whole network played by Station B. At the same time, the number of online users reaches 1,000, and there are notes available Receipt and technical exchanges with various experts: 798478386

[Updated] The most detailed collection of practical tutorials for automated testing of Python interfaces taught by Station B (the latest version of actual combat)_哔哩哔哩_bilibili [Updated] The most detailed collection of practical tutorials for automated testing of Python interfaces taught by Station B (actual combat The latest version) has a total of 200 videos, including: 1. [Interface Automation] The current market situation of software testing and tester competency standards. , 2. [Interface Automation] Fully skilled in the Requests library and the underlying method call logic, 3. [Interface Automation] interface automation combat and the application of regular expressions and JsonPath extractors, etc. For more exciting videos, please pay attention to the UP account. https ://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337 & amp;vd_source=488d25e59e6c5b111f7a1a1a16ecbe9a Then run on the command line

easytest yourpath/single_test.yaml

INFO 2021-10-30 14:53:26,081 :==========single_test test starts============
INFO 2021-10-30 14:53:26,081: Use case [a simple test] Start testing >>>>>>>>
INFO 2021-10-30 14:53:26,591 : use case [a simple test] test ended <<<<<<<<<<
INFO 2021-10-30 14:53:26,591 :==========single_test test ended============
Total number of use cases: 1, success: 1, skip: 0, failure: 0, error: 0

Call easytest from python code

You can call easytest directly from python

import easytest
easytest.main()

You can also pass parameters

easytest.main(['test_dir', '--debug', '--logfile', 'test.log'])

Writing use cases

Test Cases

To write a single test case in easytest, you can use yaml format or Excel file.

Excel Format

It is very simple to write a single test case using an Excel file. For example, the format of writing the above case into an Excel file is as follows: !

Keep the data tidy when writing use cases in Excel files, and do not have any data in other cells, so as not to fail to load the use case data. easytest will organize the use cases according to the sheetname of the Excel file, so please delete other sheets for a single use case.

YAML format

When using a YAML file to write a single test case, the outermost key must be test, because easytest uses it to determine that the data in a YAML file is a single test case.

test: # table name This is a single test case
  title: a simple test # case name
  url: http://httpbin.org/get # url
  method: get # request method
  request: # request parameter field
    headers: # Request headers
      CustomerHeader: lemonban #Header information
    params: # url parameters
      search: lemonban # url parameter key-value pair
  res_type: json # response data type
  status_code: 200 # Status code
  assertion: # assertion expression
    -
      - eq # equal
      - $..Customerheader # Result extraction expression
      - lemonban # expected value
    -
      -eq
      - $..search
      - lemonban

Test Suite

The test suite in easytest represents a set of sequential test cases. When multi-threading is started, the test suite is given to the thread to execute the test cases in the order of the suite. Note that the execution order between packages is not fixed.

A single test case will also be covered with a test suite. A single test case in yaml format will be encapsulated into a test suite named after a YAML file, and a single test case in Excel format will be encapsulated into a test suite named after a table. name in the test suite.

Excel Format

There is no difference between writing a test suite in an Excel file and a single test case. You can just write it from top to bottom in the order of execution, for example:

Multiple test suites can be written in a single Excel file, and a table is a test suite, so please delete tables that are not test cases or project settings.

YAML format

When writing a test suite in a YAML file, the outermost key must be test_suit, because easytest uses it to determine that the data in a YAML file is a test suite. Note that unlike Excel, the YAML format does not support writing multiple test suites in one file, as multiple levels of nested indentation would be a nightmare.

test_suit:
  - title: A Simple Test
    url: http://httpbin.org/post
    method: post
    status_code: 200
    res_type: json
    request:
      json:
        username: xinlan
        password: 123456
    assertion:
      - [eq,$..username,xinlan]
      - [eq,$..password,123456]

  - title: A not-so-simple test
    url: http://httpbin.org/post
    method: post
    status_code: 200
    res_type: json
    request:
      json:
        username: xinlan
        password: 123456
    assertion:
      - [ eq,$..username,xinlan ]
      - [ eq,$..password,123456 ]

Use case collection rules

The easytest command accepts a positional parameter file_or_dir, which can be a use case file or a directory.

When a use case file is passed in, it must be a excel or yaml file that conforms to the format mentioned in the previous section. Excel files only support .xlsx suffix format, YAML files support .yaml or .yml suffix.

When a directory is passed in, easytest will recursively search for all use case files (excel, yaml) that meet the rules in this directory, and extract use cases from them. When a format error is encountered, the program will interrupt , so do not put irrelevant Excel files and YAML files in the use case directory.

Use case field description

title

String, use case title
url

String, requested URL, supports complete URL, such as https://httpbin.org/get, and also supports the key corresponding to the interface in the project configuration. For example: register
method

string, http request method
request

JSON objects, parameters carried by http requests, request headers, cookies, etc. The bottom layer calls Python’s requests library, and the parameter names are exactly the same.
- params
  
  JSON object, the url parameter carried by the http request. For example

request:
  params:
    search: python

data

JSON object, form parameters carried by http request. For example

request:
  data:
    username: xinlan
    password: 123456

JSON

JSON object, JSON parameters carried by http request. For example

request:</code><code> json:</code><code> username: xinlan</code><code> password: 123456

headers

JSON object, the header carried by the http request. For example

request:</code><code> headers:</code><code> X-Lemonban-Media-Type: lemonban.v1</code>?</pre ></li><li> <p>cookie</p> <p>JSON object, cookie information carried by http request. For example</p></li></ul></li></ul>
<pre>request:</code><code> cookies:</code><code> key: value

res_type

String, http response type, optional values are: json,xml,html
status_code

Integer, http assertion response status code.
assertion

Array object that responds to the result assertion expression. The format is: [[condition symbol, extraction expression, expected result], [condition symbol 1, extraction expression 1, expected result 1],...], for example:

assertion:</code><code> - [eq,$..username,xinlan]</code><code> - [eq,$..password,123456]

Conditional symbols support:

eq: equal
gt: greater than
gte: greater than or equal to
lt: less than
lte: less than or equal to
in: in it
contains: contains

Currently only supports eq

Extraction expression support:

- regular expression
- jsonpath expression
- xpath
db_assertion

Array object, database assertion expression. The format is: [[conditional symbol, sql statement, expected result], [conditional symbol 1, sql statement 1, expected result 1],...], for example:

db_assertion:
  - [eq,select leave_amount from member where id=#invest1_id#,0]
  - [exist,select id from invest where member_id=#invest1_id# and loan_id=#loan_id# and amount=5000,true]
  - [exist,select id from financelog where pay_member_id=#invest1_id# and amount=5000 and pay_member_money=0 and status=1,true]

Conditional symbols support:

- eq: equal
- exist: exist. When using exist, the expected result must be true
extract

Array object that responds to the result extraction expression. The format is [[variable name, extraction expression], [variable name 2, extraction expression 2],...] For example: ?

exract:</code><code> - [mobile_phone, $..mobile_phone]</code><code> - [token, $..token]

The underlying easytest will bind the extracted value to the variable name attribute of the use case class for subsequent use cases to rely on.

Extraction expression support:
- jsonpath
- regular expression
- xpath expression
marks

Strings, use case tags, and matching tag use cases can be filtered out from the running parameters.

Project Configuration

The easytest command will read the configuration file named easytest.ini from the current directory. The following is an example of a complete configuration file:

[project] # project configuration section
name = xxx project # project name
host = http://some.api.root.com # Project interface root address
[db_config] # Database configuration
host = dbhost # Database host
user = root # database user
password = 123456 # Database password
db = somedb # database name
charset = utf8 #Character encoding
port = 3306 # port
[interfaces] #Interface address
register: /member/register # Register the corresponding address of the interface
login: /member/login # Corresponding address of the login interface
withdraw: /member/withdraw
recharge: /member/recharge
add: /loan/add
audit: /loan/audit
invest: /member/invest
[run] # Runtime parameters
debug=true # Turn on debug mode
logfile=a.log # Log file
marks=success,login # Filter marks
thread_num=10 # Number of startup threads
retry=3 # Number of failed reruns
report=result.json #Report file

project
project section, supports name and host
name project name

host project interface root address, be careful not to end with /

db_config
db_config section, database configuration, currently only supports MySQL
host database host

user database user name

password data password

db database name

port port

charset string encoding

interfaces
interfaces section, interface name configuration, format: key=value, key is the interface name string, value is the interface address after removing the host, starting with /. In the use case, the url field can be filled with key, and easytest will use the project host + interface address internally. Perform splicing.

run
run field, runtime parameters.
debug debugging mode, default is false

logfile generates a log file, which can be an absolute path or a relative path

marks Marks that need to be filtered. Use commas to separate multiple marks, for example: success, login, which means that use cases marked with success and login will be filtered.

thread_num is the number of startup threads. The default is 0, which means single-thread execution.

retry The number of times to rerun the use case after failure. The default is 0, which means no reruns.

report is the file name of the generated report. The corresponding report is automatically generated based on the suffix. Currently, only JSON format is supported.

Note: Command line parameters will override project configuration.

Generate simulated test data
During the testing process, sometimes it is necessary to dynamically generate test data, such as mobile phone numbers, names, etc. easytest uses the Faker module to produce simulation data, and currently only supports the interface in Simplified Chinese language. For details, see Faker Simplified Chinese providers.
The fields in the use case that support the production of simulation test data include url, request, and db_assertion.
Use the format $generate data interface name$.
For example, the method to generate a mobile phone number in Faker is called phone_number, then use $phone_number$ in the use case to dynamically generate a mobile phone number.

test: #Table name This is a single test case
  title: A simple test # Use case name
  url: http://httpbin.org/get # url
  method: get # Request method
  request: # Request parameter field
    headers: # Request headers
      CustomerHeader: lemonban #Header information
    params: # url parameters
      search: lemonban # url parameter key-value pair
      phone: $phone_number$

The above use case indicates that the url parameter phone is a dynamically generated mobile phone number.

Handling of interface dependencies

In easytest, under the same test suite, the data returned by the previous use case can be passed to the next use case through variables.

For example, after successful login, the returned token value is passed to the next use case that requires token. The transfer steps are as follows:

Add the extract field in the login case to extract the token value returned from the response and bind it to the variable name admin_token you defined.
In the following use cases, you can use #admin_token# in the data part that needs to use token, and easytest will automatically replace it.

All you need to do is write use cases according to the rules and let easytest do the rest.

Command line parameter description

file_or_dir

String, project path, or use case file that needs to be executed
–debug

Enable log debugging mode
–logfile

String, log file path
–marks

String, tag selected at runtime

–thread_num

Integer, the number of threads to start at runtime. The default is 0, which means single-threaded execution.
–report

String, test report file path, generate a report in the corresponding format according to the file suffix.

The knowledge points of the article match the official knowledge files, and you can further learn relevant knowledge. Python entry skill treeHomepageOverview 332347 people are learning the system