Misunderstanding in software test understanding
Because people pay more and higher for software quality, they have led to increasing the status of testing in software development. Yes it is,
Test is the only effective way to verify that software can complete the desired function. Under this trend, now
Many software-related companies attach great importance to the test of the software they have developed, and even spend huge money to buy commercial test workers.
With, the effect is not necessarily ideal. The reason is mainly there is many misunderstandings for software testing. This article is trying to compare some
Popularization of misunderstanding of testing, and in terms of testing the deepest impact on the quality of software products
Opened discussion.
introduction
Testing is always received in software development, even in traditional software engineering, there is also a clear, independent test.
stage. As the software crisis has emerged, the status of the test is unprecedented in the status of the software crisis.
improve. Test is not limited to a stage in software development, it has begun to run through the entire software development process, people have
It has begun to realize that the earlier the start of the test, the more frequent test execution, the more the entire software development costs will be
many. Extreme Programming is pushed to the limit of the test, and all software development activities must write tests first.
The code begins.
However, relative to the prevalence of testing this word, the work of testing education is still not enough, many of the test
The article is for the use of some kind of test tool, and test tool manufacturers often do for the purpose of testing tools.
Use exaggerated its words. In this way, many software practitioners are easy to fall into some misunderstandings, resulting in testing without their software.
The development project played a valid role. The following sections will be analyzed for some representative misunderstandings, and for testing
Some design thinking behind it will be explained, and it is hoped that it can play the role of tiles.
One of the misunderstandings: Using test tools is effective testing
This misunderstanding can be said to be a common problem, and the CASE tool in almost every field has just caused this problem, such as:
If a software development team uses the Rational Rose tool in the development of the software to draw the UML map, they may
It will claim that they use object-oriented methods, regardless of their design and code actually what process is actually.
The same is true in the field of test, a software development team tends to think that as long as you use some software test tool, then
This idea is of course wrong with the benefits that can get the test brought. Because, if you want to be effective for a software or module
Misunderstanding in software testing www.51testing.com
Bo as Feng Software Make BWF Software
Test, first of all, the software or module should be testable. Testability is an intrinsic property that reflects the quality of the software, not because
You have used a test tool to test behavior, so that the software tested has tested. If the software is tested
It does not have talents, so how expensive test tools can be used to test the income that can bring is minimal.
Ingenious is that there are naturally related to other aspects of tested and good software quality, and a testic software is inevitable.
The software that is weak, weakly coupled, the interface is clear, the intent, and the unparalleled software often has the logic of excessive coupling and confusion.
More contents about tonality are not discussed in this article, please refer to the relevant literature (in the reference) attached to this article.
More deeper information about testedness).
To really get the huge benefits of testing, and make the test tool to play the greatest efficiency, the key is to make the software itself
Has good testability. The acquisition of this capability is a step-by-step process, it is impossible to be one. The most critical point is
To constantly practice, constantly learn some excellent experiences, constantly reflect. To get good results, you must work hard, this is the unchanging truth. The practice of test in EXTreme Programming is a good starting point, and you can see it.
Reference [3].
For the selection of test tools, it is possible if you meet the needs and automatically run the test. Don't pursue complex features
And unnecessary flexibility. For most projects, some very famous source of source code open test tools are enough, such as Java
SCIENTIARUM NATURAL SCIENCE EDUCATION INSTITUTE. Not currently
Good to meet all aspects of test tools, but use scripting languages, step-by-step self-developing a test of yourself
Test tools are not a difficult thing, in a word: only improves the quality of your own team, external tools can be played
effect.
Misunderstanding 2: There are too many things that cannot be tested
In the field of software development, there are indeed some things look more than others, but it is far from testing. and
In most cases, it is still a testic problem due to the design of the software being tested itself. This is not
Testability is not due to the overall coupling of the software inside the test, but is too tightly coupled to some difficulties of the outside.
Thereby showing the software that is tested itself is difficult to test. These difficulties are more common with some of the more common: graphical interfaces, hardware, data
Library, etc. The following is a graphical interface as an example.
If a software module must trigger its application logic through a graphical interface, then test this software module.
You must use the graphical interface. But the graphical interface is difficult to test. It seems that it seems to be difficult. Let us change a angle test
Misunderstanding in software testing www.51testing.com
Bo as Feng Software Make BWF Software
Consider, in fact, we really want to test the application logic of the software module itself, not the trigger logic of the graphical interface. If I
When designing the software module itself is well packaged, we define a good service to provide the interface, then we will finish
It can be tested through the interface provided by the software module itself. This allows you to bypass the graphical interface that is difficult to test. Software
The cause of the module is difficult to test is due to the two-independent logical coupling of the application logic and graphical interfaces of the software module itself during design.
Together. Separate these two logic, not only can be easier and more efficient to the software module, but also make it
The software module has good reusability and portability.
So what should we do for a graphical interface that is not tested? The principle is simple, if something is not good, let it
Do something that will not be wrong, and put the logic that may be wrong, put it in a module that can be tested. For graphics
In terms, just maintain a very thin graphical interface logic, its work is to forward the user's request to real handle
The requested software module (generally referred to as Application FACADE). The forwarding logic is simple enough that it will definitely not be wrong.
So we don't need to test it. For more information on this, see References [5].
If you can write a test code first when you have developed, you will force you to consider it from the perspective of easy usability and easy testing.
Question, so you will focus on the high-level abstraction and responsibility of the software module. This will define clear, clearly reflected modules
Interface, in addition, in order to make the test can be performed, you will take the initiative to remove the coupling of the bad test. This result is not
It is only available to obtain tonality and also produce a better design and system architecture.
But there are some bad test things and it is difficult to only let it perform some very simple logic, such as the BSP in the embedded system (board-level support package). Developing the language, the environment, and its own characteristics of them, which are difficult to test.
The difficult test here is actually a test cost problem. Specifically, it is to pay more time and effort. This requires you to pay
Balance between the considerations and the income brought about by the test. If the benefits of paying (less debugging, maintenance, release
Cost) is huge, then the cost of pay is very worthwhile.
Misunderstanding 3: Test code can be written freely
Everyone must know that the test code cannot be written casually, and it is not a random attitude when writing test code, but
The test code you have written and the situation of test code is running exhibits a random and disorder. Because you may not
Clear the true intent of the test.
I have seen such a case for acceptance testing ___________, acceptance tester to use expensive commercial test tools to a graphic
The software of the interface is tested. The test method is to drive the mouse random click on the graphical interface by writing test scripts (of course each
Misunderstanding in software testing www.51testing.com
Bo as Feng Software Make BWF Software
The time click, you can receive the area where the event can receive events, then wait for the crash of the test software. Of course this kind of measurement
The test method can be used as an aspect of the acceptance test, but it is not the only one aspect. There is also more important content being ignored.
The purpose of the test is to verify that the software system meets the needs. So, your test code must be clearly expressed in this.
As mentioned above, if the tester really starts from the user's needs, then the test script that he written will definitely be like that
Because it is clearly compliant to each test case, it is clearly in which the system is inspected whether the user is expected.
Features. This test is a clear purpose and is the most effective test. And isolate interface logic and application logic, using clear table
Now the user needs testing cases for testing, the above test method cannot be said to be a bit.
Some errors are often seen in unit tests for classes. Many testers tend to each of the classes
Specific implementation details are tested. Specific implementation details in the class are easily changed, and this is especially in fast iterative development.
Once a certain implementation in the class you tested changes, your original test code will make a corresponding change, otherwise it will lose
Significant. This frequency of frequent changes is huge. The class is an abstraction that reflects the higher level of cohesiveness, it should be clear
Responsibilities and definition of good service interfaces, its duties and external interfaces are more stable relative to internal implementation details, and
What we have to verify is whether this class has its responsibilities. Therefore, when testing the class, we should test the interface of the interface.
Whether the certificate category implements its duties instead of others. The test code written in this should be more stable, and it is also effective.
It is important to make it easy to fall into the reasons for the implementation of the detail test. It is mainly due to the first class, and then take test. in case
First implement the functionality of the class, then test the class, the subconscious will not be compromised by the independent to verify some of the completed classes.
Implement details. If you can first write the test code for this class before writing the actual class, the situation will have a big difference, because
This will force you to consider problems from the perspective of the user. The result is to put the focus on the ease of use of classes, put in the role
Above, placed on the interface of the class provides the service, not some kind of implementation details.
In summary, the test code should be carried out from whether the object being tested does not meet the needs of the need, not other.
Misunderstanding 4: No difference between unit testing and acceptance test
As three of the misunderstandings, many people may not recognize this. But they can't make it clear about the differences between the two. This way, it will be more confused when writing test code. This subsequence attempts to give some distinctive unit testing and acceptance testing
Some principles come.
We also take advantage of factories that are often used to use software as an example, first give you a sense of understanding. Unit tests can be classified
The quality inspector of the building is tested by the building. He is concerned with the internal structure of the building, foundation, framework, and wall.
Misunderstanding in software testing www.51testing.com
Bo as Feng Software Make BWF Software
Vertical, etc. His test is to ensure that the parts of the building are normal, safe, in other words, it is to ensure that the construction meets the building.
The above quality standard. Acceptance tests can be detected by users of the building. First of all, he thinks this building is
The premissible project quality is met, this is a quality inspection personnel with buildings to ensure. The focus of the user is to live in this building.
Feel. He cares about whether the appearance of the building is beautiful, whether the size of each room is suitable, whether the location of the window is suitable, can it be satisfied?
The needs of the family, etc. Here, the construction of the construction is the acceptance test, and he is from the perspective of the user. Quality inspection person of architecture
The execution is the unit test, he is from the constructive angle.
It is this differential difference that determines the difference between unit testing and acceptance testing. They are testing for different aspects of the system
Try, both are complementary. Regardless of how smarter methods we use in the system's construction, no matter how much our system is
Flexible, but first our products must be available, otherwise what we do is to waste time, from this point of acceptance test
It is more important than unit testing.
The case given in the above section is an example. The test method used in the case is only available from the system of robustness.
Even if the system never crashes, it cannot be proved to be an available system. Because the test is not from the perspective of users,
The tester should write an acceptance test with the user. Unit test guarantees that we have made things, and the acceptance test guarantees us to do
Right thing.
Regarding the clear division of unit testing and acceptance testing, there is no universal standard, which only has to increase this through its own constant practice.
Aspects of experience. The more practices you have conducted, the more clear you will feel the boundaries between unit tests and acceptance tests.
The location. Some guidelines are given below, and it may be help when you write test code.
· If a unit tests should cross the boundary of the class, then it may be an acceptance test.
· If a unit test is very complicated, then it may be an acceptance test
· If a unit test is often changed as user needs, then it should be an acceptance test.
· If a unit test is difficult to write than it is to test, then it may be an acceptance test.
in conclusion
The test is used to ensure the efficiency of the software development process, as well as high quality and availability of the developed software products. Software open
It is a very difficult thing to send itself, which also determines that effective testing is not simple to rely on some test tools.
of. While using tools, we have to strengthen training and education about testing, so that everyone has a correct recognition.
Misunderstanding in software testing www.51testing.com
Bo as Feng Software Make BWF Software
knowledge. Only in this way can we be more effective and efficient to use tools to make the test really play a role. hope
This article is able to help everyone in conducting tests.
references
· EXTreme Programming Explained: Embrace Change, Kent Beck, 1999
· Agile Software Developments, Principles, Patterns, AND Practices, Robert C. Martin, 2002 · Test Driven Development: by Example, Kent Beck, 2002
· Refactoring: Improving The Design of EXISTING CODE, MARTIN FOWLER, KENT BECK, 1999
· Testing Things That Seem Hard to Test, Robert S. Koss, 2001
About author
Deng Hui, software engineer, main interest in Oo, Generic Programming. You can contact the author via DHUI@263.net.
Sun Ming, Software Engineer, currently engaged in data network management in a large communication company, main interest in Java and databases. can
Contact the author through DHUI@263.net.
