Interface automated testing, one-click quick verification of all fields of the interface return value

Table of contents

Foreword:

1. Get to know DeepDiff

main component:

2. Use of DeepDiff

2.1 Case 1: Comparing two JSONs

2.2 Case 2: Comparing interface responses

2.3 Case 3: regular search matching

3. The last tip: DeepDiff blacklist

Four. Summary


Foreword:

In interface automation testing, it is an important task to quickly verify all fields of interface return values. Through one-click quick verification, it can effectively verify whether the returned data of the interface meets expectations, and detect potential problems in time.

Today, let's first talk about how to use the existing third-party library to solve:  quickly verify all the fields returned by the API interface . Since most of today's interfaces are based on Restful API, in my subsequent introduction, we assume that the interface response body format takes JSON as an example.

To meet the above implementation requirements, there are many third-party library solutions. For example, the common ones are: deepdiff, difflib, json-diff, json_tools etc. Each of these three-party libraries has its own focus. This article focuses on how to use the DeepDiff library to solve The problem with the field returned by the quick check interface .

1. Get to know DeepDiff

DeepdiffModules are often used to verify that two objects are identical, and to find differences between them. It provides three classes, DeepDiff, DeepSearch and DeepHash, official website address: DeepDiff OLD 4.0.7 documentation! — DeepDiff 4.0.7 documentation  , the latest version is:V5.5.0

main component:

  • DeepDiff: Compare two objects. Objects can be iterable objects such as fields and strings. For the deep differences of objects, recursively find all changes.

  • DeepSearch: Search objects for other objects

  • DeepHash: Hashing based on the content of the object

The original intention of DeepDiff is to find the difference between different data, which can be compared JSON, XMLtext-type, or compared. 图片After using it for a while, we can actually use it directly as a test assertion, which is also provided from another perspective. A new way of checking .

2. Use of DeepDiff

After reading the above introduction, I believe you are still confused and don't know how to start. Next, let's use a few cases to further experience the Deepdifffunctions and functions of the software.

Before using, install:

pip install deepdiff

2.1 Case 1: Comparing two JSONs

Use Deepdiff to compare JSON differences:

import pytest
import requests
import pprint
from deepdiff import DeepDiff

class TestDemo(object):

    def test_case_01(self):
        a = {"Object": {
            "code": "0",
            "message": "success"
        },
            "code": "0",
            "message": "success"
        }

        b = {"Object": {
            "code": "0",
            "message": "failure"
        },
            "message": "success",
            "timestamp": "1614301293"
        }

        pprint.pprint(DeepDiff(a, b))

In the above case, the function is to compare the difference between a and b, and the output result of the result difference is:

.{'dictionary_item_added': [root['timestamp']],
 'dictionary_item_removed': [root['code']],
 'values_changed': {"root['Object']['message']": {'new_value': 'failure',
                                                  'old_value': 'success'}}}

In the above output results, all the differences are actually obtained according to the returned json. It mainly compares the values ​​between objects, the changes between types, and the deleted or added keys to output the results.

It mainly includes the following four situations:

  • 1. type_changes: key of type change
  • 2. values_changed: the key whose value has changed
  • 3. dictionary_item_added: dictionary key added
  • 4. dictionary_item_removed: field key deleted

2.2 Case 2: Comparing interface responses

With the basis of Case 1, further, we changed the hard-coded variable value of the local definition into the method of calling the interface (more in line with the actual interface test), by initiating a request, obtaining a response, and using it in conjunction with Deepdiff to assert.

The core ideaDeepdiff : first define the expected response structure (meaning, you have to know in advance what your expected result is), and then automatically compare the two based on the actual returned structure .

import pytest
import requests
import pprint
from deepdiff import DeepDiff


class TestDemo(object):

    def setup_class(self):
        self.response = requests.get('http://www.httpbin.org/json').json()

    def test_case_02(self):
        expected_reps = {'slideshow': {'author': 'Yours Truly', 'date': 'date of publication',
                                       'slides': [{'title': 'Wake up to WonderWidgets!', 'type': 'all'}, {
                                           'items': ['Why <em>WonderWidgets</em> are great',
                                                     'Who <em>buys</em> WonderWidgets'], 'title': 'Overview',
                                           'type': 'all'}], 'title': 'Sample Slide Show'}}
        pprint.pprint(DeepDiff(expected_reps, self.response))

Since the actually returned structure is exactly the same as the expected structure data to be verified, the output result of the above code is: {},即两者没有差异. (also means that the actual and expected results are consistent)

On this basis, if we modify the above expected_repsexpected structure authorby and execute it again, the output result is:Yours TrulyYours

{'values_changed': {"root['slideshow']['author']": {'new_value': 'Yours Truly',
                                                    'old_value': 'Yours'}}}

From the above output results, we can clearly get three messages:

  • The value in the structure returned by the interface has changed, which is values_changedidentified by the
  • Clearly indicate which field's value has changed, eg root['slideshow']['author'].
  • Change the specific content, such as the actual return value Yours Truly, and the expected value Yours.

After reading this, I believe that at this time, you already have some feelings about the use of Deepdiff in interface testing. But then you will definitely ask questions. The values ​​returned by some interfaces are not fixed, such as verification. For example, for a timestamp field, every time the interface is called, the value of the returned field is different. For this type of data, only the data rules are known, but the value of the data itself cannot be determined at the beginning. How to use it in combination with Deepdiff? ? Don't worry, and then look down.

2.3 Case 3: regular search matching

To solve the above problems, you can use DeepSearchthe regular search matching function in . If your interface returns a deeply nested structure object, and then you want to check whether the specified element (both key and value) exists, Then Deep Search will be a good choice.

Before use, it needs to be imported first from deepdiff import grep. The sample source code is as follows:

def test_case_03(self):
    datas = {"mikezhou": "狂师", "age":18, "city": "china", "info": {"author": {"tag": "mikezhou"}}}
    reuslt = datas | grep("mike*",use_regexp=True)
    print(reuslt)

For example, if you want to check whether there is a field or value starting with mike in the returned structure, if the specified element exists, it will return its path; if it does not exist, it will return an empty dictionary. The output of the above is as follows:

.{'matched_paths': ["root['mikezhou']"], 'matched_values': ["root['info']['author']['tag']"]}

The above example is simple, but if you are smart enough, I believe you should be able to get the core idea from it: For some dynamic values ​​that cannot be predicted in advance, you can use regular expressions to match and verify. How to verify depends on your How regular expressions describe.

3. The last tip: DeepDiff blacklist

When actually doing interface test assertions, sometimes the order of the objects is different, but the two values ​​are still the same in the actual situation, or when checking the full field, you want to skip some special field verification (similar to the blacklist, will not Fields that need to be verified, clearly pointed out), in order to solve this kind of problem, Deepdiff also provides a reliable parameter, only need to be added when comparing:

  • ignore order(ignore sorting)
  • ignore string case(ignore case)
  • exclude_pathsThe field blacklist excludes parameters, and the prototype is as follows:
result = DeepDiff(result, expected, view='tree',ignore_order=True,ignore_string_case=True)

Example:

def test_case_05(self):
    expected_reps = {"datas": {
        "code": "200",
        "message": "success"
    },
        "code": "201",
        "message": "success"
    }

    actual_reps = {"datas": {
        "code": "201",
        "message": "failure"
    },
        "message": "Success",
        "timestamp": "1614301293"
    }

    pprint.pprint(DeepDiff(expected_reps, actual_reps, ignore_order=True,ignore_string_case=True,exclude_paths={"root['timestamp']"}))

The above sample code ignores the collation and case issues, and specifies the exclusion timestampfield validation. The specific output results are as follows:

{'dictionary_item_removed': [root['code']],
 'values_changed': {"root['datas']['code']": {'new_value': '201',
                                              'old_value': '200'},
                    "root['datas']['message']": {'new_value': 'failure',
                                                 'old_value': 'success'},
                    "root['message']": {'new_value': 'Success',
                                        'old_value': 'success'}}}

Four. Summary

Through the above case introduction, I believe you DeepDiffhave a basic understanding of the use of . In interface automation testing, to summarize, the benefits of using DeepDiff are:

  1. When testing the interface, you can directly use the expected structure (or interface contract) to automatically compare the actual returned structure (fields, values) to determine whether they are the same, and you can save a lot of code.
  2. The same can be done when comparing database data. After using SQL to find out the result, it can be directly converted into JSON and compared with the expected JSON.

  As someone who has been here, I also hope that everyone will avoid some detours

Here I will share with you some necessities of the way forward in automated testing, hoping to help you.

(WEB automated testing, app automated testing, interface automated testing, continuous integration, automated test development, big factory interview questions, resume templates, etc.)

I believe it can make you better progress!

Click on the small card below

Guess you like

Origin blog.csdn.net/Free355/article/details/131701448