For integration testing, beginners tend to be vague, in the end how measured? Is the two modules together, and then use unit testing techniques and test the larger module?
We all know, integration testing is concerned that the interface between modules. Then you can "interface" as the entry point. Looking at the interface between modules, we can classified into the following types, the following 11 brief.
1, communication protocols: The communication between the two modules is standard or custom (network) protocol;
Agreement that contains the data portion, but also contains the control part; some of the data and control to achieve separation, such as FTP; and most of the data and control to achieve a link to pass through, often by different news packages to be separated.
2, call the relationship: module A calls module B, is actually from the module A to module B sends a control command, where data transfer is not reflected in clear, often reflected in parameters and return values, they can be considered as a copy control .
3, documents, databases, queues, third-party middleware such as: the performance is mainly data transfer, which control the expression of the obvious.
4, shared resources: such as sharing a "storage area", which involves the critical resources are the "lock" a; these two modules are distributed in the run-time to a different process or thread, showing competition for resources, and data sharing.
5, synchronization: a module requires another module to run the trigger, the two sides there are "signals" and other notification mechanism can also be understood as a special control mode.
OK, now have a starting point, we can classify the tested system (the classification above), find the data interface and control interface.
The following practices are no different from the test ideas.
First, data interfaces and control interfaces decomposition - What data needs to be passed? What are control orders?
Then, find the data and instructions in the variable location; such as data (protocol packet) in the field of values of the parameters of change orders;
Next, the variables divided into equivalence classes, to find representatives of each class, is our test data - and our goal is: to each type of data flow and control flow are the first through the interface in order to achieve the complete interface testing ;
Finally, is to consider how to generate these test data. After the corresponding integration often required to "big blocks" of input and output.
Talk a lot more attention to the contents of the above realization. Here we have to consider the other side - business.
The links between modules (interface) is usually to reflect the business association. We all know that correlation itself is a lot of property. Such as correlation points (each module) are there is a role associated with the multiplicity (multiplicity) - that is, at run-time module A module B may correspond to multiple instances.
We found the test of another entry point, the integration module can accurately reflect the business association? Does each module have all the properties of their role and interface, the relationships between the modules how to break? Associated multiplicity effective?
Of course, integration testing will not be too concerned about the business or demand, it is a matter of system testing. But this time think about it, often can be a bonus.
Much attention functions, often neglected other. Sometimes we have to consider the interface performance, especially on key system interfaces. Interface performance test earlier. If you wait until the system testing done, it could interface to the code outside the package too much affect the performance issues accurately.