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, I recommend a set of videos to you. This video can be said to be the number one automated testing tutorial on the entire network played by Bilibili. The number of people online at the same time has reached 1,000, and there are also notes available for collection. Technical communication with various experts: 798478386

[Updated] A complete collection of the most detailed practical tutorials on Python interface automation testing taught by Bilibili (the latest practical version)_bilibili_bilibili [Updated] A complete collection of the most detailed practical tutorials on Python interface automated testing taught by Bilibili (practical version) The latest version) has a total of 200 videos, including: 1. Why interface automation should be done for interface automation, 2. Overall view of request for interface automation, 3. Interface practice for interface automation, etc. For more exciting videos from UP master, please follow the UP account . icon-default.png?t=N7T8https://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

Calling easytest through python code

You can call easytest directly through python

import easytest
easytest.main()

Parameters can also be passed

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, write the above case into an Excel file in the following format:!

When writing use cases in Excel files, keep the data clean and do not have any data in other cells to avoid failure to load the use case data. easytest will organize 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 # 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

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 threads in units to execute the test cases in the order in the suite. Note that the execution order between packages is not fixed.

A single test case will also be wrapped in a test suite. A single test case in yaml format will be packaged into a test suite with a YAML file name. A single test case in Excel format will be packaged into a test suite with a table name. 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. One 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 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, url parameter carried by 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:
  json:
    username: xinlan
    password: 123456

    • headers

      JSON object, header carried by http request. For example

      request:
  headers:
    X-Lemonban-Media-Type: lemonban.v1

    • cookies

      JSON object, cookie information carried by http request. For example

      request:
  cookies:
    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:
  - [eq,$..username,xinlan]
  - [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:
  - [mobile_phone, $..mobile_phone]
  - [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 simulation 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:

  1. 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.

  2. 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 treeWeb application development Django359013 people are learning the system