In a certain testing group, I saw someone ask a question: What is the difference between putting the test data in the configuration file to read and putting the file to read through function calls?
At that time, I subconsciously answered this: the larger the amount of data, the more bloated the configuration file will be. Put it in a special data file (such as excel, csv) to facilitate targeted maintenance.
At first glance, there was nothing wrong with it, but when I discussed this issue with others, I thought about it seriously. The following are some of the results of my thinking and discussion, for reference only. . .
In the automated testing process, most of them now default to a design that separates test scripts from test data. The benefits of this are: reducing maintenance costs, migration costs and improving efficiency.
Therefore, where to place test data and how to manage it cannot be generalized. Personally, I think we should consider the following aspects:
1. Business scenario
① For example, in UI automation testing, each business module of an e-commerce website needs to be tested, but the prerequisite is that the user logs in. The test account data used to perform login is often fixed, so specifically
Putting a set of usernames and passwords in a test data file or test database is too cumbersome, time-consuming and labor-intensive. Write it into a test script or write it into a configuration file, and it will be more efficient to quote it directly.
② Similarly, when testing e-commerce websites, the account system is divided into ordinary accounts, member accounts, and members are divided into many levels. Sometimes in order to test whether the information displayed by different accounts in the member center is different, you need to use different
Log in with a level account. In this scenario, you can put the test data in the test file (such as excel, csv), read it in a loop through parameterization, and perform subsequent operations.
③. In API automated testing, for example, for restful-style interfaces, their domain names are relatively fixed, but the paths of different interfaces are different. Then the domain name can also be written into the configuration file.
During the testing process, you only need to splice the instantiated domain name and path. This also saves the cost of maintaining the test data file and improves testing efficiency to a certain extent.
2. Data type
Test data is also divided into different types, roughly divided into the following types:
base-data: basic data, such as product information and SKUs on e-commerce websites, such as warehouse management of logistics companies, etc. This type of data often has a relatively large base and can be regarded as a persistence layer and stored in DB;
test-data: test data. Depending on the business scenario, the data will be different in both magnitude and frequency of changes. Based on the concept of separation of test scripts and data, it can be placed in special test files, such as excel and csv;
ephemeral-data: Temporary data, that is, data that is used once. This type of data can be stored in a temporary file format (such as dat, csv, etc.), and then read parameterized, or written directly into a script;
3. Data level
① Or in a certain scenario on an e-commerce website, you need to log in first. The login account is, for example, a specially configured test account, which is relatively fixed, so there is nothing wrong with writing the test account into the test script.
However, I personally don’t like to write the test data directly into the script. In this case, I will write the configuration file and then instantiate the call. In this case, it needs to be designed according to personal habits, and there is no fixed routine;
②. The data magnitude ranges from tens to hundreds to thousands. In this case, excel files can be written for storage management, but the limitation of excel is that it currently supports a maximum of 65,500+ rows of data storage.
And it only supports single transactions. If multi-threaded reading is required, it will become a bottleneck.
③. The csv file has a simple and universal structure, can be converted to excel, can reduce the size of the stored file, and has simple security. It can replace excel as a data storage file to a certain extent.
I currently use csv-type files for test data storage and management in most scenarios;
④. When the test data exceeds a certain level, such as in performance testing, if you want to perform a concurrent test or stability test, the required test data will be very large. At this time, it will be very inconvenient to use excel or csv.
Regardless of maintenance cost or convenience, you should choose to use DB or other efficient management methods to store and manage test data;
4. Frequency of use
The reuse frequency of test data is different, and different storage methods need to be selected, such as:
①. Once: The test data is only used once, so you only need to write it into a temporary file and invalidate or delete it after use;
②. often: for frequently used test data, appropriate storage management methods should be selected based on data magnitude, usage scenarios, and data types;
③. always: It can be understood as base-data or persistent data. This type of data has a very low update frequency or a large data size. Generally, storing it in DB is a better management solution.
To sum up, there is no fixed routine for the storage and management of test data. It needs to be comprehensively considered based on business scenarios, frequency of use, data type and data magnitude, and designing a reasonable and efficient solution is the right way!
The content is for reference only. If you have better suggestions, please comment, thank you. . .
[Latest in 2023] Python automated testing, complete 60 practical projects in 7 days, and provide you with practical information throughout the process. [Automated testing/interface testing/performance testing/software testing]
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!