Revision as of 00:27, 26 April 2017 edit CodeCurmudgeon (talk \| contribs) Extended confirmed users 625 edits added dev proc ← Previous edit		Revision as of 06:12, 26 April 2017 edit undo Arood (talk \| contribs) 7 edits Undid revision 777226962 by Walter Görlitz (talk) Next edit →
Line 3: '''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> The International Software Testing Qualification Board (ISTQB) defines integration testing in it’s glossary as ‘Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.’ <ref>{{cite web\|title=ISQTB\|url=http://astqb.org/glossary\|website=ISQTB - Glossary\|accessdate=25 April 2017}}</ref> ==Purpose== Integration Testing can fall into two categories, ‘Integration Testing - in the small’ or ‘Integration Testing – in the large’. 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. ‘Integration Testing in the Small’ describes the testing of interfaces between the various components of a larger system. This testing phase, when applied is conducted between unit testing (of the components) and system testing (of the integrated system).<ref>{{cite web\|url=http://www.testingexcellence.com/integration-testing-in-small/\|title=testingexcellence.com\|accessdate=25 April 2017\|website=Integration Testing In The Small}}</ref> ‘Integration Testing in the Large’ describes the testing of any interface between the system under test and a remote system to which it interfaces. This testing phase, when applied will be conducted after system testing (of the integrated system). <ref>{{cite web\|url=http://www.testingexcellence.com/integration-testing-in-large/\|title=testingexcellence.com\|accessdate=25 April 2017\|website=Integration Testing In The Large}}</ref> In either case the purpose of the testing phase is to identify any existing defects within the implementation of the message sending or receiving functions. 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. Some different ~~types~~approaches ofto integration testing are big-bang, [[top-down and bottom-up design\|top-down, and bottom-up]], mixed (sandwich) and risky-hardest. 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 the big-bang approach, 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.

Integration testing: Difference between revisions

Languages