Threadingtest leads white-box testing into the industry

All tests are black and white. White-box testing generally requires high technical requirements and higher project experience and meticulous logic thinking abilities than general developers. It takes a long time to test and is mostly used for unit testing, the tool is expensive, so generally Chinese enterprises will ignore the white box test, which is why the white box test has not been officially launched in China since its birth. For a Healthy testing team, one or more people must be familiar with white box testing. Let's analyze it first. In general, there are several completely different policies to implement coverage testing.

1 black box test (function test)

Black box testing is a function-oriented Testing. Testing cases are based on the needs of software, and testing objects are running software. Generally, after a test case written by an experienced Test Engineer according to the requirement specification is executed, the coverage rate is generally about 70%, and it takes n working days. To reach the final goal of coverage rate of 100%, new test cases need to be added. Friends who have experience in coverage testing know that the remaining 30% may take n * 3 working days or even more. At the same time, in order to achieve higher coverage, a large number of repeated test cases are usually generated, greatly increased testing costs. For the coverage and cost of black box testing:

 

2 white box testing

In contrast to the black box test, the white box test case is based on the software code. The test engineer needs to analyze the logic structure and basic path of the Code to obtain the test case. Because this method is directly code-oriented, the written test cases are very targeted. Each execution of a test case can improve the coverage rate and reach the ultimate goal. It sounds good. In fact, there is another big problem, that is, the test engineer needs to analyze the logic structure, call relationship, and data stream of all the code. This alone takes a huge amount of time. In addition, traditional unit-level white box tests focus only on program coverage, not on Program unit combinations and integrated system-level functions. For white box test coverage and cost usage:

In combination with the above two methods, threadingtest puts forward a brand new idea: theadingtest. It adopts a combination of white box and black box, and uses the black box testing method, to obtain the white-box test data. Combined advantages:

3 threading Test

Since the black box and white box have their own advantages and disadvantages, it is better to combine them. Threading testing is actually an innovative system-level white box testing tool. It is a brand new academic school in the software testing field. It tests all the basic functions through the traditional black box test, and the coverage rate reaches 70%. At the same time, this process is monitored by the threading test tool and the testing result data of this stage is obtained. Step 2, the white box results obtained through the threading test quickly locate the remaining 30% of the code and add test cases accordingly to reach the ultimate goal. After many customers' practical experience, this method is the most effective for coverage testing, and the test time is the shortest.

Speaking of this, many testers are certainly interested In threading tests. Next we will use stories to illustrate the requirements of traditional white box tests for testers, and the Countermeasures for threading testing in this regard:

A story about code coverage

Early in the morning, a young programmer asked the master: "I am going to write some unit test cases. How much code coverage should be achieved ?"

The master replied, "do not consider code coverage. Just write some good test cases ."

Young programmers are very happy to bow and leave.

Not long afterwards, the second programmer asked the master the same question.

The master pointed to a pot of boiling water and said, "How many meters should I put in this pot ?"

The programmer seemed to be stuck and replied, "How can I get the answer? It depends on how many people they want to eat, whether they are hungry, what food they have, how many meters you have, and so on ."

"Completely correct," said the master.

The second programmer is very happy to bow and leave.

Finally, the third programmer asked the master about code coverage.

"80%, not less !" The master hammers at the table and answers in a harsh tone.

The third programmer is very happy to bow and leave.

A story about code coverage-Explanation

After replying to this question, a young intern came to the master's side:

"Master, today I accidentally heard you give three different answers to the same code coverage issue. Why ?"

The master stood up from the Chair and said, "Bring me some tea. Let's talk about it ."

When the cup filled with hot green tea, the master began to say:

"The first programmer is a newbie. He just started learning the test. Currently, he has no test cases for a large number of programs. He has a long way to go; now it is useless to require code coverage to only hit him. It is best to let him learn to write some test cases and test them. He can consider code coverage later ."

"The second programmer, both programming and testing, is very experienced. I asked her how many meters she should put in the pot, so that she could understand that there are many factors that determine the number of test cases, she knows these factors better than me-after all, it's her own code. There is no simple and direct answer to this question. With her cleverness, she can fully understand this truth and complete the task correctly ."

"I understand," said the young intern. "But if there is no simple and direct answer, why do you tell the third programmer '100, no shares ?"

The master smiled and sprayed green tea.

"The third programmer only wants a simple answer-even if there is no simple answer... And even if there is an answer, she will not do it according to the answer ."

Young interns and white-haired masters finish tea in meditation.

From the above story, we can find that:

It takes a long time for the first novice tester to conduct coverage tests.

The second experienced tester should be familiar with programming and testing as well as the whole of the tested program during coverage testing.

Third, it indicates that when testers perform coverage tests, the coverage rate indicators have clear requirements.

However, in practice, white-box testers in China suffer from problems such as scarcity, long training cycle, high costs, and testing Progress requirements.

In the case of white boxes, a brand new solution is proposed for threading testing.

As mentioned above, the cabling test passes the original black box testing method to obtain the white box results, which greatly reduces the testing difficulty and the testing personnel's capability requirements, in order to make the white-box test results easier to understand, the threading test has successively proposed visual code coverage, which is displayed in simple graphics, this allows a large number of black box testers who do not understand the code and internal program structure to perform master-level code coverage tests.

For example, we can see the following:

 

In the figure, sc0 coverage is explained as follows:

[Segment]

The sequence of computer program statements between two consecutive pivot points is called segments.

[Visible segment]

The maximum possible sequence of non-conditional statements within a control layer is called a visible segment. The length of the visible segment between two nodes may be zero (no executable statement is available ).

Sc0

The basic test coverage measurement is also called block test coverage. If all visible segments (blocks) of the program are executed at least once, sc0 coverage of the Program reaches 100%.

Sc0 = number of executed blocks/number of blocks contained in this program (that is, number of visible segments)

 

In the figure, we can clearly see how sc0 is covered by the function, and how the code is calculated and displayed. In this way, this allows the majority of testers who have no access to the Code to find out what is not covered by the code in the coverage rate through the black box test and supplement the test cases, this improves the production of test cases and the quality of test.

In threadingtest, other coverage rates are also described, such as true (percentage of true conditions), both (percentage of true and false conditions), and branch (branch coverage) and MC/DC.

Please pay attention to the coverage rate analysis on the official technical website www.threadingtest.com, with detailed explanations and calculations.

Test Coverage Rate

Test Coverage is part of the test end standard

Test Coverage of modules with low test coverage and important modules. These data can help us quickly locate the modules that require more tests and help us understand the testing status of important modules to measure the quality of our test cases and even the testing quality.

In the spiral development mode, if we do not control the test coverage rate in the previous iteration, when a version

After a version is accumulated, it is difficult to determine which modules are not given sufficient tests during the development process.

Develop effective testing plans for the next stage through coverage

Reports for test coverage

Through the coverage rate display, we can carry out the overall direction plan for the next test.

Check unused features

Check the minimum coverage of the first 10

Enhanced Test Cases

Penetration test coverage and verification phase

The verification phase can be divided into Unit verification (UT) phase, integration verification (IT) phase, and system verification (ST) phase.

In the Unit verification stage, the module function and module quality are concerned. The exit condition is the code coverage rate. The common exit condition in the industry is that the row coverage rate reaches 100%, the branch coverage rate reaches 100%, and the condition coverage rate reaches 95%. A reasonable explanation is required for the absence of coverage rate.

In the integration verification phase, the system functions of interest, and interfaces between modules, the exit condition is function coverage. The exit condition commonly used in the industry is: The function coverage rate reaches 90%, and a reasonable explanation should be given for the non-coverage rate.

? High Function coverage and low code coverage:

The verification plan is inadequate and feature coverage needs to be added.

? High code coverage and low functional coverage:

The design does not implement the specified function.

Threading to cope with test coverage to achieve best practices

Traditional white box testing

Path coverage> condition coverage> Decision coverage> statement coverage

Testing coverage of 100% is an ideal situation and is hard to achieve

The test coverage rate of 100% does not indicate that we have performed a complete test.

The overall coverage rate of the software and the project cost, including manpower and time, must be taken into account.

Because of the above factors, traditional white-box tests do not recommend that the company specifically meet the coverage test indicators for testing.

The traditional white-box test results are managed in a unified manner through the threading test to achieve the accumulation of various stages and shorten the time for repeated tests, thus ensuring a high coverage rate of 100% of the test coverage.

From the original test, the unit test phase, integration test phase, and system test phase test data in the normal test are separated, but in the actual process, the unit test is sufficient, it is associated with later integration tests and system tests. In this section, the penetration tests use the accumulative coverage rate technology, the test results of all stages of the test are followed and accumulated, so that the entire test iteration plays the role of quantitative association, and testing of each stage can be analyzed and improved at any time.

Compared with the traditional unit-level white box testing, the distribution testing method is also proposed for threading testing. for medium and large software or websites, a single tester cannot complete the entire Testing task, to better cooperate with each other, threadingtest adopts a distributed test design. During the test process, testers can test different modules of a program or website at the same time in different locations, the test results are aggregated to the central server without mutual interference, so that the test data results of each person are managed in a unified manner every day, and the overall Test Progress is effectively quantified.

 

Reform in the testing field in the case of threading Testing

Threadingtest, a commercial testing tool, productize the threading concept. It allows black box testers to perform white-box testing at the code level through tools, the whole testing process is quantitatively managed, and the white box results are displayed through the black box test, completed the most effective 70% black box + 30% white box test method.

Threading testing breaks through the traditional white box testing method, which is too difficult to operate, and overtests the coverage rate. Through the combination of black boxes and white boxes, testers at various stages can, all tests can be conducted correctly according to your own needs, thus avoiding blindness, repetition, omission and other problems.

 

 

Threadingtest leads white-box testing into the industry