A summary of the idea of integration test

For integration testing, beginners tend to be more vague, in the end how to measure? Do you connect two modules together and then test the larger module with the technology of unit testing?

As we all know, integration testing is concerned with interfaces between modules. Then you can use "interface" as a pointcut. Look at the interface between modules, we can be summed up in the following types, described below.

1, communication protocol: two modules in the communication between the standard or custom (network) protocol;

The protocol includes the data part and the control part, some implementations separate the data from the control, such as FTP, and most implementations pass the data and control through a link, often separated by different message packets.

2, Call Relations: module A call module B, in fact, by module A to Module B issued a control instruction, where the data transmission is not very obvious, often reflected as parameters and return values, they can be considered a control copy.

3, files, databases, queues, third party middleware, etc.: the main performance is the transmission of data, the control embodied in the not obvious.

4, shared resources: such as sharing a "storage area", which involves a key resource is "lock", such two modules are often distributed to different processes or threads in the performance of the competition for resources, as well as the sharing of data.

5, synchronization: The operation of a module requires another module of the trigger, the two sides often exist "signal" and other notification mechanisms, can also be understood as a special control mode.

OK, now that the pointcut is available, we can classify the system under test (the above classification) and find out the data interface and the control interface.

The next approach is no different from the general test idea.

First, decompose the data interface with the control interface-what data do you need to pass? What control directives exist?

Then, find the variables in the data and instruction, such as the value of the field in the data (Protocol packet), the parameter change of the instruction, etc.

Next, the variables are divided into equivalent classes, to find each representative of the class, is our test data-our goal is: each type of data flow and control flow through the interface once, so as to achieve the complete interface testing;

Finally, consider how to generate these test data. Often need to correspond to the integration of the "big module" input and output.

Talk a lot, the above content more attention to the implementation. Here we want to consider another side--business.

The interface between modules is often used to reflect business linkages. As we all know, the association itself has many attributes. If there is a role for the association point (each module), the Association has multiplicity (multiplicity)-that is, module a may correspond to multiple instances of module B at run time.

We have found another entry point for the test, can the integration of the module accurately reflect the business relationship? Does each module have all the attributes and interfaces of its role, and how is the relationship between the modules broken? Is the multiplicity of associations valid?

Of course, integration testing does not care too much about business or demand, which is a matter of system testing. But when you think about it, you can often get an unexpected harvest.

Too much attention to features that tend to overlook the other. Sometimes we have to consider the performance of interfaces, especially for system-critical interfaces. The earlier the performance test of the interface is, the better. If you wait until the system is tested, it is possible to encapsulate too many code outside the interface, affecting the precise positioning of performance problems.