Big talk test data (i)
Turn from: Skytraveler's big talk test data (i)
2015-11-17,
Directory:
1 Why testing data is important
2 Classification of test data
2.1 From the life cycle angle of the test data
2.2 Data partitioning from a business point of view
2.3 Partitioning from test data sources
3 The test data generation process
The test data plays an extremely important role throughout the testing process, but it is like an actor without a star, at least second, but is always ignored by the audience. In the testing process, we often neglect the test data during the test planning phase, at first did not give the test data design, preparation to set aside enough time, put enough effort, to the test execution phase of regret. Only testers who have had a big loss will take it seriously at the beginning of the next test. The landlord is also considered to have eaten a loss of people. So in the current test work, always carry the test data this string. Today, an online classmate asked a question about the test data, after a few answers, found that they actually have accumulated some experience. Now summarize them for your discussion. We welcome suggestions and questions, and I'll try to answer them.
1 Why testing data is important
return
1. The most obvious truth: plainly, the execution of the test case is done mainly by doing some input operations, and then observing the output. The test data is the input content, no test data, how do you execute the use case?
2. Test data is an important part of the test design, the validity of the test case relies heavily on the selection of test data or design, to remember that the nature of the test is sampling, sample selection is actually a profound science, have learned the statistics of the reunion deeply understand this truth.
3. The test data is not straightened out, good automated testing is simply empty talk. Imagine that the most common mode of test automation is the "record-playback" mode, if the data can not be confused, playback will basically fail, automated verification will not be able to effectively complete the natural.
4. Test data can inspire test design. The students who do a lot of tests will have to choose a set of test cases and then feel that they are feeling the fountain of experience.
5. If the system is on-line or has a longer life cycle, data from the log on the production system can be used to guide the test well. (Some statistics can help identify those businesses that are important, provide important information for the ability to develop the right test strategy, and can be used to supplement test scenarios and use cases for data-profiling purposes, as well; This data can also be reused in testing).
6. Other Benefits ...
2 Classification of test data
return
We can classify test data from multiple dimensions, and here's how I classify it:
2.1 From the test dataLife cycle PerspectiveDivided
You can divide your test data into: stability and data , consumable data , and mixed-type data
- Stable data: data that rarely changes during the execution of a round/multi-wheel test, such as some basic data in a common e-commerce system-City, zip code, properties of some goods, such as clothing size code.
- consumable data: after a test executes a step, the data is irreversible, or a reversal operation takes a lot of effort to change. Examples of such data are: Inventory of goods, tickets in the ticketing system, expired data to be deleted by the night-dimension program, network packets, and so on.
- mixed-type data : Some data is composite data, such as XML structure or some data of the JSON structure, one piece of data is stable data, the other part is consumable data, such an example is very common, the general such data will be treated as consumable data.
From the point of view of whether the data can be constructed, the test data can be divided into: directly construct the data and the data that needs to be acquired indirectly .
- data that can be directly constructed: Most of the data in a common system can be directly constructed, through the operating system itself, or by invoking certain interfaces (SQL also counted as interfaces) to insert data, and sometimes even the data is text, ready for them directly.
- data that needs to be acquired indirectly : the cost of manual manufacturing is too high (in theory we can make all the test data, but sometimes it is too expensive), such as some data containing information stored in binary (serialized data), some non-textual data, such as audio data, video data, The very complex data that the sensor uploads comes with some pattern. For a fun example, have you seen the "Cookie Hunter" app? Occasionally hear a song, open the Hunter, 10 seconds or so it can tell you which song. You basically can't create a valid test data yourself, unless you're Jacky Cheung or Lady Gaga.
2.2 FromBusiness PerspectiveSee Data partitioning
Can be divided into: compliance data , non-compliance data, fuzz data
- Compliance Data: words too literally, which is the data that complies with business rules, such as the identification number that can be verified.
- Non-compliance data: Clearly the data that does not conform to the business rules, when you are asked to enter the registration email, you give this input: [email protected]@163.com obviously not compliant.
- Fuzz Data: The fuzz data is mainly used for the system stability testing and security testing by using the chaotic data generated by some tools. This is a big topic, and if you are interested in it, it is recommended to read the "fuzzy test" this good book.
2.3 Fromtest DataSources to divide
Can be divided into: the production of dump data , their own generated data
The above classification is not very accurate, but the classification is to help solve the problem more efficiently. Next I'll explain how I deal with the data of the above types.
3
the test data generation process
return
Conceptual data: that is, abstract data, for example, your analyte is a cashier software, you know that after each transaction is completed, you need to generate an "invoice", see the invoice you probably know what it looks like, "Invoice" is the conceptual data, but it is not directly used.
data that has been refined: that is, the specific data item. Get the invoice, we also have to analyze the invoice in the end what data, through the demand and analysis, we know that the invoice contains: invoice date, invoice code, payer, payee, amount, security code, two-dimensional code and so on. At the same time we also know the specification of these data, for example, the date format of the invoice is: yyyy mm month DD day.
data that is really available : We know the details of the data, and we can prepare the data that can be identified and accepted by the system under these details. For example, the above mentioned invoice payer, the payee, the real operation may be entered directly in the GUI, or can call some interfaces, or can be inserted directly into the database. All you have to do is get your data to work.
From the above explanations you can get the test data from being identified to the general steps that can be used:
In fact, in practice, the preparation of test data is far from simple. A lot of times the push of each step above is a hard process. It takes Conan's cobwebs ability and craftsmen's meticulous and patient. I will try to tell some of my experiences in the following articles.
"Turn" test data (i)