Object-Oriented Software Testing

Object-Oriented Software Testing
Abstract: The structure of object-oriented programs is no longer a traditional functional module structure. As a whole, the method required by the original integration test to gradually build the developed modules for testing together has become impossible. The traditional test model is no longer applicable to object-oriented software.
This article summarizes the effective object-oriented software testing technology. First, clarify the basic concepts of Object-Oriented Software Testing. Then, the Analysis and Design of Model Testing Technology, class testing technology, object interaction testing technology, class level structure testing technology, and object-oriented system testing technology are discussed respectively. Finally, summarize the implementation of object-oriented software testing.
Key words: Object-oriented; software testing; class testing; object interaction; Test Cases
1. Analysis and Design of Model Testing Technology
The initial step of object-oriented software development is to develop analysis and design models. UML (Unified Modeling Language) can be widely used in the development of object-oriented technology, because building models can help developers understand the problems being solved; building a model can help you manage the complexity of the system being developed. The model constructed in the analysis and design phases will ultimately provide guidance for specific implementation. If the model quality is high, it will be of great value to the project; but if the model is wrong, its harm to the project will be immeasurable.
1. Analysis and Design of Model Testing content
The focus of analyzing and designing model testing is to test the integrity and consistency of the model. The main content of this test is as follows:
1. Test the determined objects;
2. Test the determined structure;
3. Test the subject;
4. Test the association between defined attributes and instances;
5. Test the service and message association defined.
1. 2. Analysis and Design of Model Testing Methods
The Analysis and Design Model Test mainly tests the analysis and design model to find out the errors in the model. The method adopted is the guidance review (guided inspection ). Guided Review technology provides an objective and systematic approach to finding defects in work results by using clear test cases. It is an enhanced detection technique designed to test the model and can also be used to verify whether the model meets the needs of the project. The basic steps are as follows:
1. Define the test location.
2. Use a specific policy to select a test value from the test position.
3. Apply the test value to the tested product.
4. Evaluate the test results and the model test coverage rate (based on a medium standard.
　
It is a key test in the early stage of software development.
2. Test Technology
A class test is composed of activities associated with whether the implementation of the verification class is exactly the same as the description of the class. The objects of this type of test mainly refer to the original class that can independently complete certain functions. If the implementation of the class is correct, the behavior of each instance of the class should also be correct.
2.1. Test content
The purpose of the class test is to ensure that the code of a class fully meets the requirements described in the class description. test a class to ensure that it only performs the specified tasks. The amount of attention it pays depends on the risks associated with the classes that provide additional actions. if the code coverage is incomplete after various types of tests are run, this may mean that this class contains additional behaviors supported by documentation. more test cases are required for testing.
2.2. Time of class test
The start time of the class test is generally to fully describe the class, and soon after it is prepared to code it, a test plan will be developed-at least some form of determining the test case. This is especially true if the developer is still responsible for testing the class. The early test cases help developers understand the class description and get feedback on independent code checks.

2.3. class testing testers
A class test is usually tested by a developer who serves as a tester to minimize the number of people who must understand the class description.
2.4. Method of class test
Class testing methods include code check and execution test cases. In some cases, it is feasible to replace the execution-based test method with code check. However, compared with the execution-based test, code check has the following two disadvantages:
1. The code check is vulnerable to human factors.
2. Code check obviously requires more work in regression testing, often similar to the original test.
Once an executable test case of a class is determined, the test driver must be executed to run each test case and the results of each test case must be given.
2.5. Build Test Cases
The following methods are used to construct a test case for a class: Determine the test case based on the class description (expressed in OCl) and build a test case for the class based on the class state transition diagram.
According to the class description, it is determined that the description of the class represented by OCL describes every restriction condition of the class. Analyze each logical relationship under the OCL condition to obtain the test case corresponding to the structure of the condition. The Method for Determining Test Cases of the class is to construct a test case based on the pre-and post-conditions. The overall idea is to determine the test case requirements for all possible combinations. In these possible combinations, the preconditions can be met or the post conditions can be reached. Based on these requirements, create test cases, create test cases with specific input values (common values and special values), and confirm their correct output-expected output values.
Follow these steps to create a test case based on the prerequisites and prerequisites:
1. determine the impact of a series of preconditions specified by each project that matches the prerequisite Formation in table 1.
2. determine the impact of a series of preconditions specified by each project that matches the post condition in table 2.
3. Construct test case requirements based on all possible combinations that affect each project in the list. A simple method is to use each input constraint in the first list to replace each precondition in the second list.
4. All meaningless conditions generated in the exclusion table.

Table 1 Influence of preconditions on Test Series
Preconditions
True (true, post)
A (A, post)
(Not a, exception )*
Not a (not a, post)
(A, exception )*
A and B (a and B, post)
(Not a and B, exception )*
(A and not B, exception )*
(Not a and not B, exception )*
A or B (A, post)
(B, post)
(A and B, post)
(Not a and not B, post)
A xor B (not a and B, post)
(A and not B, post)
(A and B, exception )*
(Not a and not B, exception )*
A implies B (not a, post)
(B, post)
(Not a and B, post)
(A and not B, exception )*
If a then B
Else C endif (a and B, post)
(Not A and C, post)
(A and not B, exception )*
(Not a and not C, exception )*
Note: ①. A, B, and C represent components represented by OCL.
② If the protective design method in the class description is implicit, the test cases marked with * must also be elaborated. If the protective design method appears explicitly in the class description, the test case is determined.

Table 2 influence of post conditions on Test Series
Post-condition shadow
A (pre;)
A and B (pre; A and B)
A or B (pre;)
(Pre; B)
(Pre; A or B)
A xor B (pre; Not A or B)
(Pre; A or not B)
A implies B (pre; Not A or B)
If a then B
Else C endif (Pre and *; B)
(Pre and not *; c)
Note: ①. A, B, and C represent components represented by OCL.
②. For the post condition "if a then B else C endif", if the test case does not affect expression A, when this post condition is used, * = A else * is to make a true condition

The status transition diagram of a test case is constructed based on the Status transition diagram to illustrate the behavior associated with an instance of a class in the form of a legend. The status transition diagram can be used to supplement the written class description or constitute a complete class description. Each transition in the status chart describes one or more test case requirements. Therefore, representative values and boundaries can be selected at each end of the conversion to meet these requirements. If the conversion is protected, you should also select boundaries for these protection conditions. The Boundary Value of a State depends on the range of State-related attribute values. You can define each State based on the attribute values.

3.2 abstract class test
When testing a Class Based on execution, you need to construct an instance of the class. However, the root class of an inheritance system is usually abstract. Many programming languages do not allow the construction of abstract class instances in semantics. The test of this abstract class brings great difficulties. Here, we propose three methods for testing abstract classes:
1. the abstract class to be tested defines a specific subclass separately. Test the abstract class by creating an instance for a specific subclass. The disadvantage of this method is that, if multi-level inheritance is not used, the implementation of the abstract class method cannot be easily passed to the abstract subclass. However, most object-oriented programming languages do not support multi-inheritance and do not advocate the use of multi-inheritance in these aspects.
2. Use the abstract class as part of the first child of the test. This method does not require the development of additional objective classes for testing, but you need to consider providing an appropriate and correct test case and test script method for each ancestor, this increases the complexity of testing specific classes.
3. to directly implement the specific version of the abstract class for testing purposes, try to find a method to write source code for the class, so that the class can be easily compiled as an abstract or specific class. However, neither the editing Heritage scheme nor the Conditional compilation scheme has produced good results. The merging code should be complicated and difficult to read, making it easy to make mistakes.
4. object interaction Testing Technology
Object-oriented software is composed of several objects and solves some problems through the continuous collaboration of these objects. The interaction and writing modes of objects determine what the program can do and the correctness of the program execution. An instance of the trusted original class may not contain any errors, but if the service department of that instance is correctly used by other program components, the program contains errors. Therefore, the correct collaboration of objects in the program-interaction-is critical to the correctness of the program.
Based on the type of the class, you can divide the test into a pooled test and a collaborative test.
. Pooled Test
A collection class refers to such a type. These classes use objects in their instructions, but in fact, they never collaborate with any of these objects-that is, they never request services of these objects. On the contrary, they will show one or more of the following actions:
1. Stores references (or pointers) of these objects, which usually represents the one-to-many relationship between objects in the program.
2. Create instances of these objects.
3. Delete instances of these objects.
You can use the method of testing the original class to test the collection class. The test driver needs to create some instances and send them as parameters in the message to a testing set. The purpose of the test case center is to ensure that those instances are correctly added to the set and removed from the set correctly, and the Set described in the test case limits their capacity. Therefore, accurate classes of each object (these objects are used in the test of the Collection class) are not important in determining the correct operation of the Collection class, because there is no interaction between a collection instance and the objects in the set. If 40 to 50 pieces of information may be added to the actual application, at least 50 pieces of information will be added to the generated test cases. If a representative upper limit cannot be estimated, a large number of objects in the set must be used for testing.
. Collaboration Test
Any non-primitive class that is not a collection class (primitive tired is some simple, independent classes, these classes can be tested using the class test method) is a collaboration class. This type uses other objects in one or more of their operations and uses them as an indispensable part of their implementation. When a post condition of an operation in an interface references the instance status of a collaboration class object, it indicates that the gender of the object is used or modified. It can be seen that the complexity of writing test is much higher than that of Collection class or original class test. Given that the testing of the assistance class needs to be determined according to the specific situation, and the specific situation is complex and changeable, It is not discussed here.
5. Object-oriented System Testing Technology
Through unit testing and integration testing, only the functions of software development can be implemented. However, you cannot determine whether it meets your needs during actual operation. To this end, the developed software must undergo standardized system testing. For system testing, we should try to build a test platform that is the same as the user's actual use environment. We should ensure the integrity of the tested system and simulate the temporarily unavailable system equipment components. During system testing, you should check whether the software can completely "reproduce" the problem space by referring to the OOA analysis results, corresponding to the objects, attributes, and various services described. System Testing not only detects the overall behavior of the software, but also confirms the software development and design.
The overall objective of object-oriented testing-the most common errors found with minimal workload-is consistent with the objective of traditional software testing, but the policies and tactics of OO testing are very different. The testing perspective is extended to include review analysis and design model. In addition, the testing focus is shifted from the process component (module) to the class.
Object-oriented software testing is still in the development stage. This paper discusses Object-Oriented Software Testing Based on the process and characteristics of object-oriented development methods, and puts forward a series of practical software testing technologies. For example, Analysis and Design of Model Testing Technology, class testing technology, object interaction testing technology, class level structure testing technology, and object-oriented system testing technology ., Despite the ease of speaking, software testing is a very troublesome task.
Whether it is a traditional test method or an object-oriented test method, we should follow the following principles:
1. "early and continuous testing" should be taken as the motto of developers.
2. programmers should avoid checking their own programs, and testing should be done by an independent professional software testing organization.
3. when designing test cases, legal input and illegal input, as well as various boundary conditions should be taken into account. In special circumstances, extreme states and unexpected states should be created, such as abnormal network interruptions and power outages.
4. Be sure to pay attention to errors in testing. This has a lot to do with the programmer's programming level and habits.
5. Check the test error results. Generally, errors from a testing must be confirmed by B. For serious errors, a review can be held for discussion and analysis.
6. Develop a strict test plan and arrange the test time as loose as possible. Do not complete a high-level test in a very short time.
7. The relevance of regression testing must be fully noticed. It is not uncommon to modify an error and cause more errors.
8. It is self-evident that all testing process documents should be properly stored. the reproducibility of testing often depends on testing documents.
Contribution
[1] McGregor. J. D. et al; translated by Yang wenhong. object-oriented software testing [M]. Mechanical Industry Press, 2002.8.
[2] Zhang haifan. Introduction to software engineering [M]. Beijing: Tsinghua University Press, 1998.
[3] Zhang Yikun. Characteristics and methods of Object-Oriented Software Testing [J]. Journal of Xi'an University of Technology, 361 (4): 365.