Misunderstanding in software test understanding
Abstract Because people's emphasis on software quality is increasing, the status of testing in software development is increasingly important. Yes, the test is currently used to verify that the software can complete the uniquely effective way to complete the desired function. Under the guidance of this trend, now many software-related companies attach great importance to the test of the software they develop, and even spend huge money to buy commercial test tools, but the effect is not necessarily ideal. The reason is mainly there is many misunderstandings for software testing. This article tried to analyze some misunderstandings about testing, and also discussed the more far-reaching impact on the quality of software product quality.
Introduction Test has always received attention during software development, even in traditional software engineering, there is also a clear and independent test phase. As the software crisis has emerged and the status of the test has been improved unprecedented in a further understanding of the essence of software. The test is not limited to a stage in software development. It has begun to run through the entire software development process, and people have begun to realize that the earlier the test start, the more frequent test execution, the entire software development cost The more you will fall. Extreme Programming is pushed to the limit of the test, and all software development activities must start from first to write test code.
However, relative to the prevalence of testing this word, the work on testing education is far less enough, and many of the articles about testing are for a test tool, and test tool manufacturers often The purpose of business is exaggerated for test tools. In this way, many software practitioners are easy to fall into some misunderstandings, resulting in testing without the effective role in their software development projects. The following sections will be analyzed for some of the more representative misunderstandings, and elaborate on some of the design thoughts contained behind the test, it is desirable to play the role of tile jade.
One of the misunderstandings: Using test tools, it is a valid test. This misunderstanding can be said to be a common problem. Almost every field will bring this problem, such as: if a software development team is in software The Rational Rose tool is used in the development of the Rational Rose tool to perform the Drawing of the UML map, they may claim that they use object-oriented methods, regardless of their design and code actually how procedure.
The same is true in the test field, a software development team tends to think that as long as you use some software test tool, then you should get the benefits of testing, this idea is of course wrong. Because, if you want to test a software or module, first, the software or module should be tapered. Testability is an intrinsic property that reflects the quality of the software. It will not be tested because you have tested behavior because you have used a test tool. If the software being tested does not have testability, how expensive test tools can be used to test the income that can bring is minimal.
Ingenious, talented and good software quality has naturally associated, a testic software inevitably a strong internal gather, weak coupling, clear interface, intent, instead of software Often have a logical coupling and chaotic logic. More contents about testedness are not discussed herein, please refer to the relevant literature (herein, the more deeper information]
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 experience, constantly reflect. To get good results, you must work hard, this is the unchanging truth. The practice of testing in EXTreme Programming is a good starting point, and details can be found in References [3]. For the selection of test tools, it is possible if you meet the needs and automatically run the test. Do not pursue complex features and unnecessary flexibility. For most items, some very famous source open test tools are sufficient, such as the unit test tool JUnit and C unit test tool CPPUnit in Java. Regarding the acceptance test, there is no better test tool that meets all aspects of the test tool, but use the scripting language, step-by-step self-developing a good thing is not a difficult thing, one sentence: only improves itself The inner quality of the team, the external tool can play a role.
Misunderstanding: There are too many things that cannot be tested in the field of software development, there are indeed something that seems to be tested more than others, but far from being tested. And in most cases, it is still not taken into consideration of tonic problems due to the design of the software itself. This unpatientableness is not caused by the overall coupling inside the software tested, but the exterior of some difficulties of the external difficult test is too tight, thereby exhibiting the software itself is difficult to test. These difficulties of these difficulties are more common: graphical interfaces, hardware, databases, etc. The following is a graphical interface as an example.
If a software module must be able to trigger its application logic through a graphical interface, you must use the graphical interface when you test this software module. But the graphical interface is difficult to test. It seems that it seems to be difficult. Let us take a look at it, in fact, we really want to test the application logic of the software module itself, not the trigger logic of the graphical interface. If we can make a good package that is tested in design, we define a good service to provide interfaces, then we can test through the interface provided by the software module itself. This allows you to bypass the graphical interface that is difficult to test. The cause of the above software module is difficult to test is due to the design of the application logic of the software module itself and the two-independent logical coupling of the graphical interface. Separate these two logic, not only make it easier and more efficient to the software module, but also make the software module have good reusability and portability.
So what should we do for a graphical interface that is not tested? The principle is very simple, if something is not good, let it do not have wrong things, and put the logic that may be wrong, put it in a module that can be tested. For graphical interfaces, just maintain a very thin graphical interface logic, its job is to forward the user's request to the software module that truly handles the request (generally known as Application Facade). The forwarding logic is simple enough that it will definitely not be wrong, so we do not 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 problems from the perspective of easy usability, easy testivity, so you will focus on the high-level abstraction and responsibilities of the software module. This will define clear, clearly reflecting the module interface, in addition, in order to make the test can be performed, you will take the initiative to remove the coupling of bad tests. Such a result is not only tonel, but also produces 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 balancing between the benefits brought about by the payment and testing. If the benefits (less debugging, maintenance, release cost) brought about by pay, then the cost of pay is very worthwhile. Misunderstanding 3: Test code can be free to write everyone must know that the test code cannot be written free, and it is not a random attitude when writing test code, but the test code you have written and the test code is running. It has exhibited a random and disorderless. Because you may not figure out the true intentions of the test.
I have seen such a case related to the acceptance test, and the acceptance tester uses expensive commercial test tools to test software with graphical interfaces. The test method is to drive the mouse to random click on the graphical interface (of course, each click, you can receive the area where the event can be received, and then wait for the crash of the test software. Of course, this test method can be used as an 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, the test script that he written will definitely, but because each test case is clearly portrayed a user's demand. Then check whether the system implements the functionality of the user. This test is a clear purpose and is the most effective test. And isolate interface logic and application logic, using clear performance of user demand test cases, 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 test for each particular implementation detail in the class. 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 meaning. This frequency of frequent changes is huge. Category is an abstraction that reflects higher levels of cohesiveness, it should have clear responsibilities and definition of good service interfaces, its responsibilities and external interfaces are more stable relative to internal implementation details. And we have to verify that this class has its responsibilities. Therefore, when testing the class, we should verify whether the class has achieved its responsibilities instead of other interfaces. 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. If you implement the functionality of the class first, then test the class, you will not be confirmed to verify some of the implementation details of the class that has been completed. If you can write a test code for this class before writing the actual class, the situation will have a big difference, as this will force you to consider the problem from the perspective of the user. The result is that the focus will be placed on the ease of use of classes, placed on the class, placed on the interface of the class, rather than 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: Unit test and acceptance tests have no differences and 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 principles of distinguishing unit testing and acceptance testing.
We also take advantage of factories that are often used to use software as an example, first give you a sense of understanding. The unit test can be detected by a quality inspection personnel of a building. The focus of his concern is the internal structure of the building, foundation, frame, and walls are vertical. His test is to ensure that the parts of the building are normal, safe, in other words, to ensure that the construction meets the quality standards above the building. Acceptance tests can be detected by users of the building. First of all, he believes that this building is to meet the requirements of the prescribed project, which is a quality inspection personnel with buildings to ensure. The focus of use is the feeling of living in this building. He cares about whether the look is beautiful, whether the size of each room is suitable, whether the location of the window is suitable, can meet 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. The quality inspection personnel of the building is the unit test, and he is from the perspective of the builder. It is this differential difference that determines the difference between unit testing and acceptance testing. They are testing for different aspects of the system, both of which are complementary. Regardless of how much our system is used, no matter how flexible our system, first we must be available, otherwise 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 from the perspective of the system, even if the system never crashes, it cannot prove that is an available system. Because the test is not from the perspective of users, the tester should write the acceptance test with the user. Unit test guarantees that we make things right, and acceptance tests ensure that we do correct things.
Regarding the clear division between unit testing and acceptance testing, there is no universal standard, which only has to increase this experience through its own constant practice. The more practices you have conducted, the more clear the boundary between unit tests and acceptance tests. Some guidelines are given below, and it may be help when you write test code. If a unit tests should cross the boundaries of the class, it may be an acceptance test If a unit test is very complicated, then it may be an acceptance test. And change, then it may be an acceptance test If a unit test is difficult to write than it is to test, then it may be an acceptance test.
Conclusion The test is used to ensure the efficiency of the software development process, as well as high quality and availability of software products developed. Software development itself is a very difficult thing, which also determines that effective testing is by no means simple depending on some test tools. While using tools, we have to strengthen training and education about testing, so that everyone has a correct understanding. Only in this way can we be more effective and efficient to use tools to make the test really play a role. I hope this article can help everyone in the test of testing.
