Integration Testing
Integration testing is a software testing technique that focuses on verifying the interactions between different components or modules of a system. It aims to uncover defects in the interfaces and interactions between integrated components. This type of testing is performed after unit testing and before system testing to ensure that the integrated components work together as expected.
8 Key excerpts on "Integration Testing"
- David Stokes(Author)
- 2003(Publication Date)
- CRC Press(Publisher)
...The purpose of Software Integration Testing is, therefore, to ensure that the various software components all function correctly together. At a higher level, Software Integration Testing is also used to test the interfaces between different systems. In order to evaluate the functioning of the interface it is necessary that the individual systems (or at least those functions in the system responsible for handling the interface) have been fully tested. When defining Software Integration Tests the purpose is not to challenge test the individual modules or systems, but to ensure that the modules or systems function correctly together in a robust, reliable and predictable manner. Where appropriate, stress testing (or challenge testing) may be part of this. The objectives of the Software Integration Tests should be clearly traceable to the appropriate sections of the Software Design Specification(s)...
eBook - ePub- John A. Burgess(Author)
- 2020(Publication Date)
- CRC Press(Publisher)
...(Module testing is often referred to as unit testing.) Then, the task of integrating related modules into subsystems must be performed next. And finally the subsystems must be integrated into a working system, including operation with the actual hardware (e.g., computer, microprocessor, etc.) and other applicable software. This approach builds on the orderly partitioning of the task, but it requires planning and forethought to conduct testing in this manner. The process of program verification is often performed in two distinct phases. These are Integration Testing and acceptance testing. Integration Testing is conducted as part of the software development process and is normally done by the analyst/programmer. Although it is a disciplined and rigorous process, it is relatively informal. On the other hand, acceptance testing typically involves participation by the end-use customer and is done in a formal and controlled manner. For in-house programs, it is very desirable to involve the eventual user throughout the design and verification stages. This process can generally be more informal than if an outside customer is the ultimate user. Each of the elements of program verification is described in subsequent sections. 7.4.1 Integration Testing The guiding principle in Integration Testing is to proceed with deliberate caution. It should be performed in a top-down fashion to the maximum extent possible. Some lower-level integration of interfacting modules may be necessary, but routinely skipping over levels or pursuing a bottom-up test path is just asking for trouble and delays. Top-down testing, applied one level at a time, verifies the top-level portion works before the detailed execution of all the modules is attempted. This is done by programming the modules as "stubs" (or black boxes)...
- John Bartlett(Author)
- 2017(Publication Date)
- Routledge(Publisher)
...Ongoing sampling is useful when the quality of manufactured components is unproven or where there are grounds to suspect that quality of manufacture has deteriorated over time. Project teams may be able to use standard test scripts to work through or even reuse scripts from previous projects. Some scripts will have to be constructed afresh. Much testing these days is automated and may be controlled through software programs. Quality aspects to look for when considering components, either developed in-house or by a third party, are: Is there good, well-formatted and intelligible documentation accompanying a component? (In the case of software code, is the code well commented?) Is there an audit trail of version control (i.e., can one component be identified against a previous version)? Does a component include the name of an individual responsible for its development (in order to have traceability of who constructed what)? Are standard test scripts applicable, or do they have to be uniquely devised? Integration Testing Integration Testing is the bringing together of components to test as a deliverable or system as a whole. In some ways it emulates component testing, but the idea is to ensure that individually tested components can operate together as a whole. An obvious example of this is a completed motor car. The many components brought together need to function as expected in the total concept of a car. These include mechanical, electro-mechanical, hydraulic, electronic and liquid components, all of which need to be tested as an integrated whole. Car manufacturers have particular test routines for this, of course, but the end result still has to meet the expectations of the end-user. As I have said before, many perfectly integrated systems have failed the ultimate test – the discerning customer. Their road test will be to very different criteria than that undertaken by the manufacturing plant. The story is the same for many items in commercial and domestic use...
eBook - ePubMaximizing Benefits from IT Project Management
From Requirements to Value Delivery
- José López Soriano(Author)
- 2016(Publication Date)
- CRC Press(Publisher)
...The responsibility for carrying out such tests is the programmer or programmer analyst who is developing each component, and the purpose is to ensure that the component is working properly. Unit test results should provide reasonable assurance that the component is working according to specification. However, this test does not offer any conclusions about how this component will interact with the other components of the global system. Integration tests. These tests will be performed by personnel with advanced experience relative to those involved in unit testing. Their responsibility will include testing the subsystem or module to which those unit components belong. They will review validated unit test results, and then perform the designated Integration Testing to ensure that the different components can handle the required maximum load and level of stress and that they are properly integrated and interact correctly to result in a functional and operational subsystem that meets the test indicated in the relevant design specifications. This process is repeated successively at progressively higher levels of integration, ending in a complete system test. The test plan should also include provisions regarding the actions to be taken when a unit or system test fails. The plan should specify the variety of incidents that could cause modules and components to be returned to technical teams for correction and rectification. It should identify the process for doing this, and for arranging the repeated iterations of tests needed until we have an information system that is clean of errors. It is very important that the various test conditions are defined from the perspective of customer acceptance. To that end, test conditions should correspond to the criteria for product acceptance, and as such should be discussed and approved by users who have defined the behavior of the system they are seeking to obtain...
- Susan M. Houston(Author)
- 2021(Publication Date)
- Productivity Press(Publisher)
...This concept also applies to COTS systems, in which the software is configured to meet the organization's processes. If, for example, there is an option of what happens when the user double clicks on a patient name in the patient list, does the expected result occur? Unit testing is also applicable for any ongoing changes made to the system during operations and maintenance. This is also called “component testing” and is the only type of testing with which the developers should be involved. Once development is complete, the code is moved to a dedicated test environment where all changes are controlled to minimize the impact to the ongoing testing processes. For smaller systems, testing may occur in a combined development/test environment. In this environment, functional testing is conducted to determine that the integrated components function as designed. Functional testing is completed by the testing staff and is based on the functional requirements. Defined test scripts are used to perform functional testing; each script is written to verify a specific requirement or a group of requirements. A sample test script is in Table 11.1. Besides testing how the integrated components function, based on the requirements, functional testing ensures that the code follows the organizations business processes. This includes a series of tests using normal and erroneous data that should mimic what real users would enter. Table 11.1 Portion of Sample Test Script # Task Data Expected Outcome P/F Comment 1 Enter URL <URL to be opened> Website appears with logo in top right corner, login/password fields and privacy verbiage at the bottom P 2 Enter login/password and select “Enter” Login=testrn; PW=testrn The home screen of the application appears and displays… F Received the error “error verbiage documented here” 3 Testing the integration or connection between multiple modules, multiple systems, or portions of a single system is called system Integration Testing...
eBook - ePubNanosatellites
Space and Ground Technologies, Operations and Economics
- Rogerio Atem de Carvalho, Jaime Estela, Martin Langer, Rogerio Atem de Carvalho, Jaime Estela, Martin Langer(Authors)
- 2020(Publication Date)
- Wiley(Publisher)
...Integration relates to functionally combining lower-level assemblies (hardware or software) so they operate together to constitute a higher-level functional entity. The integration of nanosatellites can be defined straightforwardly as the process of combining several subsystems into one system due to their small proportions. Each of these subsystems individually contributes to the whole system functionality, but only the combination of all subsystems provides the complete system functionality. 11.1.2 Testing Testing is the process that demonstrates the expected behavior of a system under specific conditions. Tests are designed to reproduce the estimated operational environment and scenarios with the best accuracy whenever it is possible. It may be defined as the measurement of product characteristics, performance, or functions under representative environments [ 2 ]. The tests are part of a set of alternatives available to verification of requirements, and are considered an expensive, but effective method. There are different types of tests that can be performed at different levels of integration, development stages, and models. The test has generally auxiliary equipment that simulates environments, conditions, or restrictions to which the system will be exposed, in order to indicate performance, functionality, absence of failures, or resistance to harsh environment for a certain period [ 3 ]. System level testing can be divided into two types, environmental and functional tests. Environmental tests simulate various conditions (simultaneously or separately) on which an item is subjected during its operational life. They include natural and induced environments [ 2 ], for example, the vibration and thermal-vacuum tests, which are designed to replicate the launch and on-orbit environments, respectively...
eBook - ePubSoftware Engineering for Embedded Systems
Methods, Practical Techniques, and Applications
- Robert Oshana, Mark Kraeling(Authors)
- 2019(Publication Date)
- Newnes(Publisher)
...There are therefore limitations to what it can achieve and to the circumstances under which it can be used, especially when timing errors are a concern. However, within appropriate bounds it has been highly successful and in particular has made a major contribution to the sound safety record of software in commercial aircraft. Some test tools can perform structural coverage analysis in isolation or in combination with unit, module, and/or Integration Testing. 6.1.5 Unit, Module, and Integration Testing Unit, module, and Integration Testing (referred to collectively as unit testing hereafter) all describe an approach in which snippets of software code are compiled, linked, and built in order that test data (or “vectors”) can be specified and checked against expectations. Traditionally, unit testing involves the development of a “harness” to provide an environment where the subset of code under test can be exposed to the desired parameters for the tester to ensure that it behaves as specified. More often than not in modern development environments the application of such techniques is achieved through the use of automated or semi-automated tools. However, a manual approach can still have a place in smaller projects or when only practiced on a critical subset of an application. Some of the leading automated unit test tools can be extended to include the automatic definition of test vectors by the unit test tool itself. Unit testing and structural coverage analysis focus on the behavior of an executing application and so are aspects of dynamic analysis. Unit, integration, and system test use code compiled and executed in a similar environment to that being used by the application under development. Unit testing traditionally employs a bottom-up testing strategy in which units are tested and then integrated with other test units. In the course of such testing, individual test paths can be examined by means of structural coverage analysis...
eBook - ePubSystems Engineering for Aerospace
A Practical Approach
- Richard Sheng(Author)
- 2019(Publication Date)
- Academic Press(Publisher)
...SE monitors this process as described. 5.1.3 Outputs 1. Informally verified hardware and software. 2. Corrections as needed to requirements, design, and interface documents. 3. Ongoing evaluations of Technical Performance Measurements (TPMs). 5.1.4 Milestone Reviews Generally, there are no formal milestone reviews during this period. However, for safety critical systems the integration and verification activities may be performed by a team independent of the initial developers. 5.2 Subsystem Test and Integration During the Subsystem Test and Integration phase, maturing elements of the hardware and software are brought together and exercised, with corrections processed as needed. These tests are conducted in accordance with their respective test plans and may be conducted iteratively and/or in parallel as appropriate. 5.2.1 Inputs 1. Output from the prior phases, as well as engineering work products that have completed verification at the prior level during this phase. 2. Verification plans that identify verifications to be bought off at this level. 3. Labs and simulations that provide models of sending and receiving equipment as needed for testing at this level. 4. Inspection and demonstration procedures, data, and evaluation/acceptance criteria. 5.2.2 Process Integration and verification as previously described continue up to and beyond complete hardware and software end items. Subsystem Test and Integration is a risk reduction effort, to commence evaluation of those requirements that span multiple end items. For example, Compatibility & Integration (C&I) testing may be conducted in labs so that interfacing CSCIs can clearly communicate over their interfaces (e.g., message formats, timing, and protocols work across the testing group). Hardware items may be physically integrated (e.g., boards and chassis are assembled) to similarly assure physical compatibility and that power, signals, etc., are being communicated across the physical interfaces...
