This link: https: //blog.csdn.net/zjuxsl/article/details/79364811
Software testing is an integral part of a software engineering process them. In software engineering, test those who act as "virtual users" software product testing. Only through rigorous testing of software products in order to publish to users.
As long as the software place, there is software testing.
Software testing is an all-encompassing topic. One such "all-inclusive" is a concrete manifestation of the classification of software testing: a variety of viewing angles, a variety of measures, creating a variety of classifications. Classification of software testing is a "Hundred Flowers."
For example, according to the test methods, the test software may be divided into manual and automated tests, the test can be divided into static and dynamic testing can be divided into white-box testing, black box testing and gray box testing.
For example, according to the test objectives, test software can be divided into functional and non-functional testing. Functional test can be classified according to the type of business do secondary; non-functional testing can be divided into performance testing, security testing, usability testing, stability testing.
For example, the software at various stages of production, there unit test, integration test, system test, smoke testing, alpha testing, beta testing.
For example, according to the test execution frequency, software testing can be divided into non-regression testing and regression testing.
For example, the degree of freedom according to the test, the test software can be divided into pre-defined tests and exploratory testing.
.....
Faced with such numerous and diverse classification test, is there a main method allows us to restore justice, clear your mind of it?
The author believes that the classification based on hierarchical testing, you can answer this question.
So, what is a test grade?
We can understand test rating from the perspective of two kinds of the same thing.
The first angle is also a classic time-based method. Specifically, according to the different stages of testing, software testing is divided into:
Unit Test: a test object is generally a function (Function) or a class (Class). Unit testing is highly correlated with the software code, usually done by the developers themselves.
Component Test: a test object is usually a module (Module), the purpose of functional verification module meets the design goals. Component tests are usually carried out simultaneously and software development.
Integration testing: test object may be a separate external interface software entity (Entity) of (essentially a test of the software entity assumes a function); can also be a multiple adjacent the interface between each other (on the nature of software testing entity the whole is more functional software entities appear adjacent). Integration testing focuses on software functions, the software development is generally carried out after partial or complete.
System Test: Testing object is a real system contains all the software entities. From the perspective of the user using the system test design test procedures designed to test the system meets user needs. Usually performed after all software systems are developed.
The second angle is the method of space, and it is based on the use of Google. In Google, more emphasis on test classification test range, rather than testing stage. Specifically, the software testing into Google:
Small Tests (small scale test): generally corresponding test unit testing and assembly.
Medium Tests (Test medium range): generally corresponding integration testing. In Google, Medium Tests emphasized that the test object is a direct interface between the mutually adjacent or interoperable software (Interoperation) Relationship module / software entity.
Large Tests (large scale test): generally corresponds to the test system.
Regardless of time-based or space-based, hierarchical theory test software testing are classified as low-level tests (Low Level Testing, LLT), medium-level test (Medium Level Testing, MLT) and high-level test (High Level Testing, HLT).
It is called a "staged", but also because the spatial angle, is the divided type having a certain progressive layers sequentially growing relationship to each other both from the perspective of time. This is both unity and opposition relations. For example, unit testing, component test, integration test, system test unified in both the time dimension, and each different situation arranged in order in time.
Test grading is a very simple theory. However, the simple things are often a powerful force.
Test grading theory not only helps us a comprehensive understanding of software testing, and we are better able to guide the implementation of software testing.
On the one hand, no matter what type of testing can usually attributable to a particular level of one or more tests. The different levels of testing have significantly different characteristics, we can better understand the type of test based on the level of a certain type of test belongs.
For example, low-level test can be manual or automated, high-level test may likewise be manual or automatic; however, in general, low-cost low-level test automation, the high-level and the high cost of test automation. As another example, usability testing, stability testing, smoke testing usually apply only to high-level, that system-level testing. We rarely do stability testing of low-level test object (a function or a class) or smoke tests.
On the other hand, in the actual project, usually require more than one level of software testing, we need to work on the test grading, classification of testers. At the same time, for different levels of testing, test resources should be invested with a difference, the purpose is to test the advantages of all levels are adequately demonstrated, in a complementary, synergistic manner to complete the good work of software testing.
For example, in the project, we often need to avoid a new code changes break existing functional regression testing. If we try to test the high-level regression (either manually or automatically), it will consume enormous resources. We might as well test the limited resources more into the low-level regression testing. Try the low-level test automation to achieve a low-level regression tests. Although low-level regression testing existing functionality can not completely avoid being destroyed, but can usually be found most of the problems. It would be a pragmatic and higher cost strategy.
Of course, the example cited here is only piece of a jigsaw. In future articles, we will see a test rating of this most basic test theory in helping us develop test strategies, test schedule tasks and do more powerful aspects of the test work.
----------------
Disclaimer: This article is the original article CSDN bloggers' Xiaoge shelwin ", and follow CC 4.0 BY-SA copyright agreement, reproduced, please attach the original source and link this statement.
Original link: https: //blog.csdn.net/zjuxsl/article/details/79364811