1 Test Automation
The workload of software testing is very large, but the testing is very likely to use computers to carry out a considerable part of the automated work, the reason is that many operations of testing are repetitive, non-intellectual and creative work, requiring careful attention, and computers are best suited to replace human beings to complete these tasks.
Test automation has a significant impact on the quality, cost, and duration of the overall development effort. Some of the test activities that might be considered for automation are: (1) test case generation (including test inputs, standard outputs, test operation instructions, etc.). (2) Test execution control (including single machine and network multi-machine distributed operation, night and holiday operation, test case call control, test object, scope, version control, etc.). (3) Comparison of test results with standard output. (4) Analysis, recording, classification and notification of inconsistent test results. (5) Total test statistics, report generation. Test automation and software configuration management are inseparable, and the resources related to test should be considered in configuration management.
Object-oriented testing
The traditional software testing strategy starts from “small test” and gradually moves to “large test”. You start with unit testing, move to integration testing, and end with system testing.
The structure of object-oriented program is no longer the traditional function module structure. As a whole, it is impossible to build the developed modules together for testing as required by original integration test. Moreover, object-oriented software has abandoned the traditional development mode and has different requirements and results for each development stage. It is impossible to detect the results of object-oriented analysis and design with the view of functional refinement. Therefore, the traditional testing model is no longer suitable for object-oriented software.
2.1 Object-oriented test model
Object oriented development model breaks through the traditional waterfall model and divides development into OOA, OOD and OOP. In view of this development model, combined with the division of traditional testing steps, object-oriented software testing can be divided into: object-oriented analysis testing, object-oriented design testing, object-oriented programming testing, object-oriented unit testing, object-oriented integration testing and object-oriented system testing.
2.2 Testing of object-oriented analysis
Traditional process-oriented analysis is a process of function decomposition, which regards a system as a set of functions that can be decomposed. Functional decomposition analysis focuses on what kind of information processing methods and processes a system needs, and treats the needs of the system with process abstraction. Object-oriented analysis directly maps the problem space, abstracts the instances in the problem space into objects, uses the structure of objects to reflect the complex instances and relationships in the problem space, and uses attributes and operations to represent the characteristics and behaviors of instances. The result of OOA is to provide a platform for the selection and implementation of classes and the organization and implementation of class hierarchies in subsequent phases. Therefore, OOA testing should be considered from the following aspects: (1) Testing of identified objects. (2) Testing of identified structures. (3) Tests on identified topics. (4) Tests associated with defined properties and instances. (5) Tests for the defined service and message association.
2.3 Testing of object-oriented design
The traditional structured design method adopts the idea of activity-oriented. After the system is decomposed, a group of tasks are proposed. These tasks are based on the basic structure of process realization system, and the analysis of problem domain is transformed into the design of solution domain, and the analysis result is the input of the design stage. OOD summarizes classes based on OOA, and establishes a class structure or further constructs a class library to realize the abstraction of analysis results to the problem space.
Thus, OOD is not another way of thinking of OOA, but a further refinement and higher level abstraction of OOA. The boundary between OOD and OOA is often difficult to distinguish strictly. OOD determines the class and class structure not only to meet the requirements of current requirements analysis, but also to facilitate the reuse and expansion of functions through recombination or appropriate supplement, so as to continuously meet the requirements of users. Therefore, the OOD testing should be considered from the following three aspects: (1) the testing of identified classes. (2) The test of the constructed class hierarchy. (3) The test of class library support.
2.4 Object-oriented programming testing
Typical object-oriented programs have the new characteristics of inheritance, encapsulation and polymorphism, which make the traditional testing strategy must be changed.
Encapsulation is the hiding of data. The outside world can only access or modify the data through the provided operations. In this way, the possibility of data being arbitrarily modified and read and write is reduced, and the test of illegal data operations in traditional programs is reduced.
Inheritance is an important characteristic of object-oriented program, which makes code reuse and error propagation more likely.
Polymorphism makes the object-oriented program show powerful processing power, but it also complicates the behavior of the “same” function in the program. When testing, we have to consider the specific code execution and behavior of different types of parameters.
Object-oriented programs distribute the implementation of functionality among classes. Classes that correctly implement functionality collaborate through messaging to implement the functionality required by design. Therefore, in OOP stage, ignore the detailed rules of the implementation of class functions, and focus on the implementation of class functions and the corresponding object-oriented program style, mainly reflected in the following two aspects. (1) Whether the data members meet the requirements of data encapsulation. (2) whether the class realizes the required function.
2.5 Object-oriented unit testing
The object of traditional unit test is the smallest unit of software design — module, and the test is based on the detailed design specification. Unit testing should design test cases for all important control paths within a module in order to find errors within the module. Unit testing mostly uses white box testing technology, and multiple modules in the system can be tested in parallel.
For object-oriented software, the concept of a cell has changed. Instead of individual modules, each class and instance of a class (object) encapsulates properties (data) and operations that manipulate that data, and the smallest testable unit becomes the encapsulated class or object. As a result, the meaning of unit testing has changed considerably. Instead of testing individual operations in isolation, you test them as part of a class.
2.6 Object-oriented integration testing
In traditional integration testing, there are two typical integration strategies: (1) top-down integration, which starts from the main control module and gradually integrates each module together in a depth-first or breadth-first strategy according to the control hierarchy of the software. (2) Bottom-up integration, starting from the “atomic” module (that is, the module of the lowest layer of the software structure) assembly test. Object-oriented software has no hierarchical control structure, so the traditional top-down and bottom-up integration strategy is meaningless.
In addition, integrating one operation at a time into a class (the traditional incremental integration approach) is often not possible. There are also two different strategies for integration testing of OO software: the first is called thread-based testing, where a set of classes required to integrate an input or event to a system are integrated and tested separately, and regression testing is used to ensure there are no side effects. The second type, called usage-based testing, first tests classes that rarely use other classes (called independent classes) and starts building the system. After the independent class testing is complete, the next layer of classes that use independent classes (called dependent classes) is tested. This sequence of class-dependent tests continues until the entire system is constructed.
2.7 Object-oriented system testing
Through unit testing and integration testing, only the functions of software development can be ensured. However, it is not confirmed whether it meets the needs of users when it is actually run. To this end, the software that has been developed must undergo standardized system testing. System test should try to build the same test platform with the actual use of the user environment, should ensure the integrity of the system under test, for the temporary system equipment components, there should be corresponding simulation means. During system testing, check whether the software can fully reproduce the problem space by referring to the OOA analysis results and the described objects, attributes, and services.
System testing is not only to detect the overall behavior of the software, but also to reconfirm the software development and design from another side.
The overall goal of object-oriented testing is to find the most errors with the least effort, which is consistent with the goal of traditional software testing, but the strategy of OO testing is very different from traditional testing. This difference is mainly reflected in two aspects. First, the focus of testing has shifted from process components (modules) to classes. Second, the testing perspective expands to analyze and design models.
