The objective of system integration is to build a “working” version of the system by (i)putting the modules together in an incremental manner and (ii) ensuring that the additional modules work as expected without disturbing the functionalities of the modules put together.
Integration testing provides a systematic technique for assembling a software system while conducting tests to uncover errors associated with interfacing.
The application is tested in order to verify that it meets the standards set by the client as well as reassuring the development team that assumptions which were made during unit testing are correct.
Integration testing need not wait until all the modules of a system are coded and unit tested. Instead, it can begin as soon as the relevant modules are available.
Integration testing or incremental testing is necessary to verify whether the software modules work in unity.
Following are the types of interface errors:
Some programming languages, such as C, generally separate the interface specification from the implementation code.
In a C program, programmers can write a statement #include header.h where header.h contains an interface specification.
Since the interface specification lies somewhere away from the actual code, programmers overlook the interface specification while writing code.
Therefore, inappropriate use of #include statements cause construction errors.
These are errors caused by implicit assumptions in one part of a system that another part of the system would perform a function.
However, in reality, the “other part” does not provide the expected functionality – intentionally or unintentionally by the programmer who coded the other part.
3. Location of Functionality:
4. Changes in Functionality:
- Changing one module without correctly adjusting for that change in other related modules affects the functionality of the program.
5. Added Functionality:
- A completely new functional module, or capability, was added as a system modification. Any added functionality after the module is checked in to the version control system without a CR is considered to be an error.
6.Misuse of Interface :
- One module makes an error in using the interface of a called module. Interface misuse can take the form of wrong parameter type, wrong parameter order, or wrong number of parameters passed.
7.Inadequate Error Processing:
- A called module may return an error code to the calling module. However, the calling module may fail to handle the error properly.
8. Violation of Data Constraints:
- A specified relationship among data items was not supported by the implementation. This can happen due to incomplete detailed design specifications.
9.Timing/Performance Problems :
- These errors were caused by inadequate synchronization among communicating processes.
- A race condition is an example of these kinds of error.
10. Coordination of Changes:
- These errors are caused by a failure to communicate changes to one software module to those responsible for other interrelated modules.
11.Hardware/Software Interfaces :
- These errors arise from inadequate software handling of hardware devices. For example, a program can send data at a high rate until the input buffer of the connected device is full.
12. Initialization/Value Errors:
- A failure to initialize, or assign, the appropriate value to a variable data structure leads to this kind of error.
- For example, if the programmer forgets to reinitialize the pointer before using a function once again, the pointer may eventually point to code.
13.Inadequate Interface Support :
- The actual functionality supplied was inadequate to support the specified capabilities of the interface.
- For example, a module passes a temperature value in Celsius to a module which interprets the value in Fahrenheit.
14.Misunderstanding of Interface:
- A calling module may misunderstand the interface specification of a called module.
- The called module may assume that some parameters passed to it satisfy a certain condition, whereas the caller does not ensure that the condition holds.