1. My understanding and standards for "good" test cases
Personally, I think that test cases are somewhat similar to the characteristics of the Java language-object-oriented operations are also required, and application scenarios must be considered to ensure that the use cases are targeted, efficient, comprehensive, and reasonable. For example, for a project, if there is a user end and an operating end, from the user's point of view, many formats and lengths require basic verification, but it is not too deadly. For example, for some non-saved operations, there is no need to verify the length value. For example, there is no need to check the length of the input box of the query condition. You will understand with the query statement of the database. If the search is not found, there is no value; from the perspective of the operator, in addition to the corresponding format requirements, the rules need Except for mandatory length judgment, not everything is required. For example, for password input, if there is a set of rules that belong to him, length judgment is required. However, for the newly added type of save operation, because the rules for this operation are set by the product , The background belongs to internal personnel, so there is no need to check the length so strictly. There is no behavior of smashing your own pot, and the operation that is not user-oriented is internally controllable. Besides, the data on the user side has been done very well. With good control and verification, there will be basically no such problems in the background, so writing use cases can greatly improve efficiency.
For the design of test cases, we have many methods and strategies, the purpose is to make the test cases more abundant and to cover as many program paths and scenarios as possible. Common test case design methods include equivalence class division method, boundary value analysis method, error inference method, etc. The conventional thinking is to hope that the test cases are as comprehensive and complete as possible. However, it is basically impossible to design a complete and comprehensive test case for complex test scenarios, not to mention ensuring that this is even more difficult in emergency projects. Realistic, in addition, huge test cases will reduce the test efficiency on the contrary, often the effect is not satisfactory. Personally, I think that when designing test cases at the beginning, I hope to be "comprehensive". The dazzling use cases are amazing at first glance, but when they are actually tested, they will know how inefficient they are and how complex the redundancy is, so much. It is also to tell everyone that it is not difficult to design a comprehensive and complete test case, but how to subtract the use case. In other words, how to use as few test cases as possible to cover more program paths and functional scenarios, this can be regarded as a "good" test case.
The permutation and combination of the various parameter operations of the test case is not reminiscent of mathematics, and then the mathematics is bound to be related to algorithmic problems, so many things do not need to be immersed in hard work. You can learn from the experience of former mathematicians. Algorithm ideas will not be included in the writing of test cases to be applied flexibly, and it is still a strategy algorithm that has been verified by a large amount of data and verified by myself, and there are ready-made tools based on algorithm development. I think it is necessary to master the use of tools. Basically it is no-brainer, as long as you understand the meaning of the algorithm and the rules for screening use cases, and then hand over the data you need to the tool to implement it, which can greatly improve efficiency. Don't brag, believe me to look down.
2. Design strategy
In addition to the orthogonal method, the commonly used use case design strategies also include the pairwise algorithm, as well as the following strategies:
Assuming query factors: A, B, C, D, E
1. Separate query: A; B; C; D; E
-To ensure the correctness of individual queries, this is also the most basic.
2. Two combined queries: AB; AC; AD; AE; BC; BD; BE; CD; CE; DE.
-Ensure the correctness of the two combined queries, which ensures that the two will not affect each other.
3. Three combined queries: ABC; CDE
-Ensure the correctness of the three combinations; because we have ensured the correctness of single and two combined queries, there is no need to test all levels of the three combinations.
4. Five combination queries: ABCDE
-Ensure the correctness of the maximum combination.
If the input conditions reach more, you can consider the following methods
1. Single condition traversal
2. Default condition query
3. Select key condition combination query according to needs or business rules
4. Full condition combination query
5. Modify the query conditions to query according to the SQL spelled in the query
Three, pairwise algorithm
1. Background introduction
Pairwise was first proposed by LL Thurstone (29 May 1887 – 30 September 1955) in 1927. He is a psychostatistician in the United States. Pairwise is also the product obtained after optimizing the traditional orthogonal analysis method based on mathematical statistics.
Pairwise is based on the following two assumptions:
(1) Every dimension is orthogonal, that is, every dimension has no intersection with each other.
(2) According to mathematical statistical analysis, 73% of defects (single factor is 35%, double factor is 38%) are caused by single factor or 2 factor interaction. 19% of defects are caused by the interaction of 3 factors.
Therefore, pairwise is generated based on the most cost-effective set of use cases that cover all 2-factor interactions.
2. Detailed explanation of pairwise algorithm:
Suppose there are 3 dimensions, and each dimension has several factors. as follows:
Browser: M, O, P
Operating platform: W (windows), L (linux), i (ios)
Language: C (chinese), E (english)
Solve:
Using the pairwise algorithm, how many test cases are there? What is the specific case?
We follow the format of mathematics.
solution:
If the pairwise algorithm is not used, we need 3*3*2=18 test cases. The following is a specific case:
1，M W C
2 ， MW E
3，M L C
4，M L E
5，M I C
6，M I E
7，O W C
8 ， OWE
9，O L C
10 ， OLE
11，O I C
12 ， OIE
13，P W C
14，P W E
15，P L C
16，P L E
17，P I C
18，P I E
There are 18 in total, which is very cumbersome. But this is 100% test coverage, and the defect rate is also 100%.
Now we use pairwise and see how it turns out?
First of all, let’s start with the 18th at the bottom, which is PIE, and the pairwise combination is PI, PE, IE. See if these 3 combinations have appeared in the same positions above, PI on the 17th, PE on the 16th, and IE on the 12th. So the case of 18 can be discarded.
The rest is as follows:
1，MWC
4 ， MLE
6 ， MIE
7， OWE
9 ， OLC
11， OIC
14 ， PWE
15， PLC
17，PIC
There are 9 test cases in total, saving 50% of the test cases.
Now we start from above and do it again. No. 1 is MWC, and the pairwise combination is MW MC WC. Both have appeared, remove it.
What is left in the end is:
2，MWE
4, MLE
5, MIC
8, OWE
10, OLE
11, OIC
13 PWC
15 PLC
18 PIE
This leaves 9 test cases, but the specific case content is different. After LL Thurstone proof, pairwise algorithm eventually the rest of the test case is certainly the same number, but can have different combinations of case.
3. The efficiency of the pairwise algorithm
The Pairwise algorithm is compared with the orthogonal analysis method. When there are 3 dimensions and each dimension has 4 factors:
(1) The number of cases in the orthogonal analysis method: 4*4*4=64
(2) Number of cases of Pairwise algorithm: 20
The number of Pairwise cases is one third of the orthogonal design method. When there are more dimensions, the effect is more obvious. When there are 10 dimensions, 4*4*4*4*3*3*3*2*2*2=55296 test cases, and 24 pairswise. It is 0.04% of the original test case scale.
To put it more importantly, if you want to test a function with 10 parameters and each parameter has 26 values, all combinations will result in 141167095653376 test cases. The pairWise design test cases only needs 1094 test cases to cover the entire test path as much as possible.
3. Pairwise design method thinking:
(1) Obtain the dimensions and factors and perform a full array.
(2) Get the two-two factor combination (with position) of the specific case.
(3) Determine whether the combination of two or two factors in this case has appeared above, and if one appears, delete it. None of them have appeared before, so keep this case.
(4) Use the pairwise algorithm to filter again in a different order.
(5) Get 2 sets of data and find the same case.
(6) Add case in the order of dimensions.
4. Installation and use of PICT test case design tool
1. Installation
PICT is a free testing tool from Microsoft that can generate paired combinations. Pairwise knows that when there are too many input conditions and the coverage examples are too large, in order to effectively and reasonably reduce the number of combinations of input conditions, pairwise can simplify the problem and greatly reduce the number of combinations. If it is for a brand new system, it can be given for these The combination of creating data suddenly thought of creating a data artifact.
Download link for windows version: http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa-8dbd-8c6f76cc014b/pict33.msi
Mac version download link: https://github.com/microsoft/pict
PICT can effectively design test cases according to the principle of pairwise testing. When using PICT, you need to enter all the parameters related to the test case to achieve a comprehensive coverage. By the way, this is also used in the interface test of jmeter, you can check my article: https://blog.csdn.net/LYX_WIN/article/details/108059736
2. Use
(1) After downloading the source code of the mac version, unzip it and enter the source path to execute the make command
(2) A txt file for generating test cases needs to be prepared in the early stage, and this txt file must be placed in the same folder of the installation directory, otherwise it will not work
Let's first come to the background of the actual case:
Record: No violation in 5 years, no violation in 3 years, less than 3 violations in 3 years, 3 or more violations in the past 3 years, 3 or more violations in the past 1 year
Type: domestic car, high-end domestic car, imported Car, high-end imported car
Method: taxi, commercial car, private car
Place: urban center, urban area, suburban area, rural area
Item: full insurance, free combination, basic insurance
Years: less than 1 year, less than 3 years, less than 5 Years, less than 10 years, more than 10 years
Insurance: first time insurance, second time insurance, continuous coverage
if[Years]="less than 1 year" then [Record] in {"no violation in 3 years", "violation within 3 years Less than 3 times","3 or more violations in the past 1 year"};
if[Years]="Less than 3 years" then [Record] in {"No violations in 3 years","Less than 3 violations in 3 years" ,"3 or more violations in the past 3 years","3 or more violations in the past 1 year"};
Note: All symbols, colons, and commas in the txt document are English characters, and Chinese characters cannot be recognized; the format needs to be in ANSI format, tried UTF8 without BOM format, the result is garbled (how to change the encoding format of the font, you can use vi or To edit vim commands, you can also use Notepad++ or sublime Text, which I personally find it more convenient.
The rules are written, and you don’t need to worry about it later, you just throw it into the txt file, and you don’t need to think about it later, so you can leave it to PICT to solve it.
(3) Everything is ready, switch to the installation directory and execute the following commands:
leiyuxingdeMacBook-Pro-2:pict leiyuxing$ ./pict Demo.txtResult: (Is it 6? All the test cases you want)
(4) You are all here, and an operation is attached to write the test case you wrote to the .xls file
leiyuxingdeMacBook-Pro-2:pict leiyuxing$ ./pict Demo.txt >Demo.xlsxAt this time, you will find that there may be a garbled problem, and the results are as follows:
This is an encoding problem of vim. Excel supports the simplified Chinese encoding GB2312 that is used by default on Windows.
solve:
1) First check the encoding format of the current file for encoding conversion:
vim to open the file, and then use the command
:set fileencoding
2) Modify the encoding format
命令格式：iconv -f UTF8 -t GB18030 源文件.csv >新文件.csv
实际执行例：iconv -f UTF8 -t GB18030 Demo.xls >Demo1.xls3) Open the file to see the effect
Perfect solution, over!
In order to facilitate the operation of lazy people, write a script: create a new file name vim exit.sh
#!/bin/bash
./pict $1.txt >1$1.xls
iconv -f UTF8 -t GB18030 1$1.xls >$1.xlsAssign a permission to the script: chmod 777 exit.sh
Execute script: ./exit.sh file name
Reference link:
1）https://www.cnblogs.com/ylq1990/p/7920622.html