In fact, most types of tests require the preparation of test data.
- Manual testing: Some basic data, such as configuration data, etc., need to be prepared;
- Automated testing: The foundation needs to be prepared, existing data, and data generated during dynamic runtime need to be prepared;
- Performance testing: similar to automated testing;
Here some concepts about data are involved.
Classification of test data
We can divide test data into some categories
- Basic data. For example, some content management systems will configure basic configuration data such as the title of the site and friendly links.
- Stock data, that is, existing data. For example, when testing some e-commerce sites, some product information, category information, logistics information, etc. will be inserted in advance.
- Dynamic data can also be called session data. For example, when testing the product publishing function of an e-commerce site, we often create some new products.
We can imagine that the basic data can be easily kept consistent with the production environment. The existing data in the test environment will be less than that in the online environment, and the dynamic data in the test environment may not be as realistic as the online environment.
Here we need to discuss the magnitude and authenticity of the test data.
The magnitude of the test data
In most cases, the test data is not as large as the production environment. So the test data can be a subset of the real data.
If you have a production-like environment or a pre-release environment, you can try to keep it at the same level as online data. In this way, some problems caused by the amount of data that are difficult to test in the test environment can be tested in the pre-release environment.
Test data authenticity
The data in our test environment is often different from the data generated by real users. For example, when testing the forum system, we may often only have a few stickers in posts, and the sizes are just right, while online users may have a variety of stickers, which may lead to unexpected problems.
How to prepare basic and stock data
The more consistent the basic and stock data are with the online environment, the higher the probability of finding problems during testing. Generally speaking, the following strategies can be used
Full dose + desensitization strategy. Directly and regularly desensitize online data and import it into the test environment. Desensitization is a must here, as the severity of problems caused by data leakage is often much more serious than ordinary online bugs.
Quantification + desensitization strategy. Only upload some online data, for example, only pull 1,000 products and 1,000 user information online, and then do desensitization. The technical implementation difficulty here will be relatively high, after all, the association table must be straightened out.
crawler strategy. If it is a new project/product and there is no existing data online that can be imported, then you may have to crawl some data from a friend and import it to the test environment for testing. For example, if you are building a travel site, there will be no user travel notes at the beginning. At this time, you need to go to similar sites and crawl a little to test it.
Generate dynamic data. If there is no data online and no friends can crawl it, then human resources or automated methods are needed to generate some data. If the system is simple, you can use SQL to run it. If it is more complex, you may need to call an interface or use an automated method to generate it. When you really have no idea, you can also create some data manually.
About dynamic data
After doing automation or interface testing, everyone often generates a large amount of dynamic data. Then the problem arises.
Where does this data live? What does that mean? If we need to create a product in an automated way, where should the product information and image address be placed? In fact, this is a persistence issue.
Put it in the file. There are many file formats to choose from, such as xml/csv/json/yaml, etc. However, excel is not recommended. After all, it is a private format and does not have strong scalability. Moreover, once Excel is upgraded, your parsing code and libraries may also need to be modified. Well, it is strongly not recommended.
Put it in the database. It is also a good way to crawl some product information and save it in the database, and then read the database. You can also become familiar with the usage of SQL, which is often asked in interviews. In addition, you can use the transaction mechanism of the database to clean up the test data and
dynamically generate it in the code. For example, dynamically and randomly generate user names, genders, ages and other
data. After the data is generated, it faces a problem of cleaning. The cleaning problem is actually a data life cycle issue. The test data should have the following life cycles.
Short term data. Data that is deleted after the use case is completed. Generally, the data used for online performance testing is short-term data
and long-term data. It’s okay to leave the data generated by the use case there and it can always exist. Too much data of this kind will sometimes affect the performance of the test environment.
It is recommended to use short-term data when running automated tests, and then find a way to clear it out, because the frequency of automated runs can actually be very high. If a bunch of data is generated every time, the data The magnitude may become very large in the short term, affecting the performance of the test environment.
Some of the above opinions are personal, superficial and vulgar opinions, and there must be many immature aspects. Everyone is welcome to correct me.
Finally, I would like to thank everyone who reads my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:
This information 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!
