Recently, some students have been asking some questions about concepts and design automation.
For example, do you need to verify that the database is correct?
This is still related to your company, your team, and your testing methods or strategies.
Why do you say that?
Because the company I worked for before was very powerful because it was a listed company.
Therefore, the test does not have database permissions at all. Not to mention that you want to see the data, the permission you want to connect to the database may need to be applied for by the leadership.
The automated testing framework designed at that time was relatively simple and only automatically verified whether the json format was correct.
So, you see, if the team doesn't allow it, you can't do database validation.
So if there are conditions, or the test can have permissions to the test environment: I strongly recommend verifying the database!
Here’s my point of view:
1. Generally, front-end and back-end data interaction is performed through json data, and the json data is obtained from the database. This involves the verification of json data.
Then format verification is format verification, and whether the field value is correct is correct verification of field value.
Then the most appropriate way to verify field values is to query the database.
2. In special circumstances, I called an interface for deleting data. Is a piece of data really deleted? I can call an interface for querying data! If the data just deleted cannot be found, it means that the deletion interface operation just now is OK. Another way is to query whether my data exists in the database, and if not, delete it.
What's the key? The key is that after some deletion operations, associated data will be deleted (if you don't understand the business or the table structure, you need to ask the development team). So has the associated data been deleted? So is it necessary to verify the database?
3. For testing, after requesting an interface, you need to know what the interface does behind the scenes (in fact, it is nothing more than adding, deleting, modifying, and querying operations on the database) and understanding the logic. For multi-interface testing, there is more complex logic behind it. More details are needed. Table structure, association method, field parameter changes, meaning, etc. Not only should the development be clear, but the testing should also be thoroughly understood.
I think maybe only by achieving the above points can it be regarded as "interface testing based on business functions, not rogue".
So to do the above things you need to:
1. The interface process needs to be thoroughly understood, the interface functions, the meaning of each field need to be clear, and the changes in parameters need to be known. In response to changes in data, for example, our company has developed Yapi interface definition documents defined by classmates (the interface documents of each company may have different platforms, but they are generally the same). I need to test my classmates’ patience and take a closer look~~
2. You need to understand database fields, database relationships, relationships between tables, etc. You need to know, for example, what the fields represent and how to modify them? Which fields in the logical corresponding interface? Sometimes you may need to go to redis to get cached data, which may be a little complicated.
What do you think, after reading this, do you think we need to verify the database when doing interface automation testing?
Everyone is welcome to leave a message for discussion.
Thank you to everyone who reads my article carefully. There is always a courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can also help you! Anyone in need Partners can click on the small card below to receive it