added dev proc
|
m Dating maintenance tags: {{Cn}}
|
||
(43 intermediate revisions by 29 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Type of software testing}} |
|||
{{ |
{{More citations needed|date=August 2010}} |
||
{{Software development process}} |
{{Software development process}} |
||
'''Integration testing''', also called '''integration and testing''', abbreviated '''I&T''', is a form of [[software testing]] in which multiple parts of a [[software system]] are tested as a group. |
|||
⚫ |
|
||
Integration testing describes tests that are run at the integration-level to contrast testing at the [[unit testing|unit]] or [[system testing|system]] level. |
|||
==Purpose== |
|||
The purpose of integration testing is to verify functional, performance, and reliability [[requirement]]s placed on major design items. These "design items", i.e., assemblages (or groups of units), are exercised through their interfaces using [[black-box testing]], success and error cases being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas and [[inter-process communication]] is tested and individual [[subsystem]]s are exercised through their input interface. [[Test case]]s are constructed to test whether all the components within assemblages interact correctly, for example across procedure calls or process activations, and this is done after testing individual modules, i.e., unit testing. The overall idea is a "building block" approach, in which verified assemblages are added to a verified base which is then used to support the integration testing of further assemblages. |
|||
Often, integration testing is conducted to evaluate the [[regulatory compliance|compliance]] of a component with [[functional requirement]]s.<ref>{{Cite book|title=ISO/IEC/IEEE International Standard - Systems and software engineering|publisher=ISO/IEC/IEEE 24765:2010(E)|year=2010|pages=vol., no., pp.1–418, 15 Dec. 2010}}</ref> |
|||
Software integration testing is performed according to the software development life cycle (SDLC) after module and functional tests. The cross-dependencies for software integration testing are: schedule for integration testing, strategy and selection of the tools used for integration, define the cyclomatical complexity of the software and software architecture, reusability of modules and life-cycle and versioning management. |
|||
⚫ | In a structured development process, integration testing takes as its input [[module (programming)|modules]] that have been unit tested, groups them in larger aggregates, applies tests defined in an integration [[test plan]], and delivers as output test results as a step leading to system testing.<ref>[https://books.google.com/books?id=utFCImZOTEIC&dq=integration+test&pg=PA73 Martyn A Ould & Charles Unwin (ed), ''Testing in Software Development'', BCS (1986), p71]. Accessed 31 Oct 2014</ref> |
||
⚫ |
Some different types of integration testing are big-bang, [[top-down and bottom-up design|top-down, and bottom-up]] |
||
== Approach == |
|||
⚫ |
In |
||
⚫ | Some different types of integration testing are big-bang, mixed (sandwich), risky-hardest, [[top-down and bottom-up design|top-down, and bottom-up]]. Other Integration Patterns<ref>Binder, Robert V.: ''Testing Object-Oriented Systems: Models, Patterns, and Tools''. Addison Wesley 1999. {{ISBN|0-201-80938-9}}</ref> are: collaboration integration, backbone integration, layer integration, client-server integration, distributed services integration and high-frequency integration. |
||
⚫ | In big-bang testing, most of the developed modules are coupled together to form a complete software system or major part of the system and then used for integration testing. This method is very effective for saving time in the integration testing process {{cn|date=May 2024}}. However, if the test cases and their results are not recorded properly, the entire integration process will be more complicated and may prevent the testing team from achieving the goal of integration testing. |
||
A type of big-bang integration testing is called "usage model testing" which can be used in both software and hardware integration testing. The basis behind this type of integration testing is to run user-like workloads in integrated user-like environments. In doing the testing in this manner, the environment is proofed, while the individual components are proofed indirectly through their use. Usage Model testing takes an optimistic approach to testing, because it expects to have few problems with the individual components. The strategy relies heavily on the component developers to do the isolated unit testing for their product. The goal of the strategy is to avoid redoing the testing done by the developers, and instead flesh-out problems caused by the interaction of the components in the environment. For integration testing, Usage Model testing can be more efficient and provides better test coverage than traditional focused functional integration testing. To be more efficient and accurate, care must be used in defining the user-like workloads for creating realistic scenarios in exercising the environment. This gives confidence that the integrated environment will work as expected for the target customers. |
|||
|
In bottom-up testing, the lowest level components are tested first, and are then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested. All the bottom or low-level modules, procedures or functions are integrated and then tested. After the integration testing of lower level integrated modules, the next level of modules will be formed and can be used for integration testing. This approach is helpful only when all or most of the modules of the same development level are ready. This method also helps to determine the levels of software developed and makes it easier to report testing progress in the form of a percentage. |
||
In top-down testing, the top integrated modules are tested first and the branch of the module is tested step by step until the end of the related module. |
|||
All the bottom or low-level modules, procedures or functions are integrated and then tested. After the integration testing of lower level integrated modules, the next level of modules will be formed and can be used for integration testing. This approach is helpful only when all or most of the modules of the same development level are ready. This method also helps to determine the levels of software developed and makes it easier to report testing progress in the form of a percentage. |
|||
|
Sandwich testing combines top-down testing with bottom up testing. One limitationtothis sort of testing is that any conditions not stated in specified integration tests, outside of the confirmation of the execution of design items, will generally not be tested. |
||
<gallery> |
|||
Sandwich testing is an approach to combine top down testing with bottom up testing. |
|||
Top Down Approach.png|Top-down approach |
|||
Bottom Up Approach.png|Bottom-up approach |
|||
Sandwich Approach.png|Sandwich approach |
|||
Bing Bang Approach.png|Big bang approach |
|||
</gallery> |
|||
⚫ | |||
One limitation to this sort of testing is that any conditions not stated in specified integration tests, outside of the confirmation of the execution of design items, will generally not be tested. |
|||
⚫ | |||
⚫ | |||
⚫ | |||
==References== |
==References== |
||
{{reflist}} |
{{reflist}} |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
{{DEFAULTSORT:Integration Testing}} |
{{DEFAULTSORT:Integration Testing}} |
This article needs additional citations for verification. Please help improve this articlebyadding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "Integration testing" – news · newspapers · books · scholar · JSTOR (August 2010) (Learn how and when to remove this message) |
Part of a series on |
Software development |
---|
Core activities |
Paradigms and models |
Methodologies and frameworks |
Supporting disciplines |
Practices |
|
Standards and bodies of knowledge |
Glossaries |
Outlines |
|
Integration testing, also called integration and testing, abbreviated I&T, is a form of software testing in which multiple parts of a software system are tested as a group.
Integration testing describes tests that are run at the integration-level to contrast testing at the unitorsystem level.
Often, integration testing is conducted to evaluate the compliance of a component with functional requirements.[1]
In a structured development process, integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan, and delivers as output test results as a step leading to system testing.[2]
Some different types of integration testing are big-bang, mixed (sandwich), risky-hardest, top-down, and bottom-up. Other Integration Patterns[3] are: collaboration integration, backbone integration, layer integration, client-server integration, distributed services integration and high-frequency integration.
In big-bang testing, most of the developed modules are coupled together to form a complete software system or major part of the system and then used for integration testing. This method is very effective for saving time in the integration testing process [citation needed]. However, if the test cases and their results are not recorded properly, the entire integration process will be more complicated and may prevent the testing team from achieving the goal of integration testing.
In bottom-up testing, the lowest level components are tested first, and are then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested. All the bottom or low-level modules, procedures or functions are integrated and then tested. After the integration testing of lower level integrated modules, the next level of modules will be formed and can be used for integration testing. This approach is helpful only when all or most of the modules of the same development level are ready. This method also helps to determine the levels of software developed and makes it easier to report testing progress in the form of a percentage.
In top-down testing, the top integrated modules are tested first and the branch of the module is tested step by step until the end of the related module.
Sandwich testing combines top-down testing with bottom up testing. One limitation to this sort of testing is that any conditions not stated in specified integration tests, outside of the confirmation of the execution of design items, will generally not be tested.