Integration testing: Difference between revisions

Revision as of 22:23, 22 August 2017

Latest revision as of 02:52, 2 June 2025

(47 intermediate revisions by 33 users not shown)

Line 1:

{{Short description|Type of software testing}}

{{RefimproveMore citations needed|date=August 2010}}

{{Software development process}}

'''Integration testing''' is a form of [[software testing]] in which multiple software components, modules, or services are tested together to verify they work as expected when combined. The focus is on testing the interactions and data exchange between integrated parts, rather than testing components in isolation.

'''Integration testing''' (sometimes called '''integration and testing''', abbreviated '''I&T''') is the phase in [[software testing]] in which individual software modules are combined and tested as a group. It occurs after [[unit testing]] and before [[verification and validation (software)|validation testing]]. 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]] to those aggregates, and delivers as its output the integrated system ready for [[system testing]].<ref>[https://books.google.com/books?id=utFCImZOTEIC&pg=PA73&dq=integration+test&hl=en&sa=X&ei=4EpTVOvJMayu7Aak5YCIDA&ved=0CDwQ6AEwAg#v=onepage&q=integration%20test&f=false Martyn A Ould & Charles Unwin (ed), ''Testing in Software Development'', BCS (1986), p71]. Accessed 31 Oct 2014</ref>

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==

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>

Some different types of integration testing are:

'''IntegrationIn testing'''a (sometimesstructured calleddevelopment '''integration and testing'''process, abbreviated '''I&T''') is the phase in [[software testing]] in which individual software modules are combined and tested as a group. It occurs after [[unit testing]] and before [[verification and validation (software)|validation testing]]. Integrationintegration 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]] to those aggregates, and delivers as its output thetest integratedresults systemas readya forstep leading to [[system testing]].<ref>[https://books.google.com/books?id=utFCImZOTEIC&pg=PA73&dq=integration+test&hlpg=en&sa=X&ei=4EpTVOvJMayu7Aak5YCIDA&ved=0CDwQ6AEwAg#v=onepage&q=integration%20test&f=falsePA73 Martyn A Ould & Charles Unwin (ed), ''Testing in Software Development'', BCS (1986), p71]. Accessed 31 Oct 2014</ref>

* '''big-bang''' - 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. 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.

* '''[[top-down and bottom-up design|bottom-up]]''' - Bottom-up testing is an approach to integrated testing where the lowest level components are tested first, 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. At first, 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.

* '''[[top-down and bottom-up design|top-down]]''' - Top-down testing is an approach to integrated testing where the top integrated modules are tested and the branch of the module is tested step by step until the end of the related module.

* '''mixed''' (sandwich) - Sandwich testing is an approach to combine 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.

* '''risky-hardest''' - Risky hardest integrated testing is the approach where the test is performed starting with the hardest and the riskiest software module first<ref>{{cite web|title=Big Bang Integration Testing|url=http://www.professionalqa.com/big-bang-integration-testing|website=ProfessionalQA.com|accessdate=22 August 2017}}</ref>.

== Approach ==

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:

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, Mostmost 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.

* collaboration integration

* backbone integration

* layer integration

* client-server integration

* distributed services integration

* high-frequency integration.

* '''[[top-down andIn bottom-up design|bottom-up]]''' - Bottom-up testing is an approach to integrated testing where, 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. At first, allAll 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.

==References==

{{reflist}}

*In '''[[top-down and bottom-up design|top-down]]''' - Top-down testing is an approach to integrated testing where, 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.

==See also==

{{Portal|Software Testing}}

* '''mixed''' (sandwich) - Sandwich testing is an approach to combinecombines 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.

<gallery>

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>

=== Test Data Management ===

Integration tests that alter any [[persistent storage|persistent store]] or database should always be designed carefully with consideration of the initial and final state of the files or database, even if any test fails. This is often achieved using some combination of the following techniques:

* The <code>TearDown</code> method, which is integral to many test frameworks.

* <code>try...catch...finally</code> [[exception handling]] structures where available.

* [[Database transactions]] where a transaction [[atomicity (database systems)|atomically]] includes perhaps a write, a read and a matching delete operation.

* Taking a "snapshot" of the database before running any tests and rolling back to the snapshot after each test run. This may be automated using a framework such as [[Apache Ant|Ant]] or [[NAnt]] or a [[continuous integration]] system such as [[CruiseControl]].

* Initialising the database to a clean state ''before'' tests, rather than cleaning up ''after'' them. This may be relevant where cleaning up may make it difficult to diagnose test failures by deleting the final state of the database before detailed diagnosis can be performed.

==See also==

* [[Design predicates]]

* [[Functional testing]]

* [[Continuous integration]]

==References==

{{reflist}}

{{Portal|Software Testingtesting}}

{{DEFAULTSORT:Integration Testing}}