Outside-in integration test

from Wikipedia, the free encyclopedia

The outside-in integration test is a strategy for performing an integration test . The outer software parts (usually interacting with the system environment, "Outside") and the inner units to be called ("In") can be tested independently of one another using auxiliary routines.

Testing according to the outside-in approach

Basically, the integration test consists of a series of individual tests through which the interaction of independently developed software components is tested. This requires an integration strategy that specifies the order in which the tests take place. The aim is to check and ensure error-free interaction between all modules of the software system involved. Depending on the applied process model the integration testing, the testing isolated software modules as a separate test stage , module test 'precede.

According to the outside-in approach, the integration test requires drivers instead of missing (as yet untested) calling components and dummies ( stubs ) instead of missing 'subordinate' modules. Successfully tested components gradually replace their substitutes in subsequent tests so that the complete system can finally be subjected to final individual tests. The sequence in the integration test is determined by the call structure of the components to be tested (test objects).

Outside-in and inside-out software tests belong to the process-oriented incremental strategies for integration tests. They are variants of the sandwich strategy, which is a mixture of the bottom-up and the top-down strategy and combines the advantages of the top-down and the bottom-up strategy.

How the outside-in strategy works

With the outside-in strategy, two teams work their way up to the middle independently of each other. The first team starts at the lowest hierarchical level, which includes the service-providing modules, and continues to the service-using, which are the top modules. So you are using the bottom-up method. The second team works exactly the other way around, starting with the modules using the service and moving down to the modules providing the service. This is the top-down approach. Both teams then meet in the middle of the hierarchy and put the overall system together. This means that the outside-in method first models [tests] the environment of a system before dealing with the inside of the system. This integration test is, besides the inside-out test, the only strategy that supports the use of several test teams [working separately from one another].

Advantages and disadvantages

advantages

The advantages of the outside-in method are:

  • The exterior of a software is basically everything that is in contact with people or with other systems (the environment). By focusing on the external components, it is ensured that the system is in harmony with its environment.
  • At the beginning a product is developed which shows the rough processes of the system.
  • In order to develop a functioning system, the system is checked again and again from the beginning.
  • Dummies that are built into subordinate modules enable a precise check of the error handling by allowing the manipulation of return values.
  • If there are interface problems, the cooperation between the hardware, software and system software is checked as early as possible in order to have enough time to correct the problem.
  • In the layers that are inserted according to the bottom-up process, it is possible to use intentional incorrect entries to check error handling.
  • In addition, the outside-in test takes a shorter period of time and requires fewer staff.

disadvantage

The disadvantages of the outside-in test are:

  • Drivers and dummies are required.
  • It is harder to find a bug in the internal components when they are called from outside. This is because there are too many layers in between that determine the call.
  • With the outside-in method, only the influences of the existing context are considered, but if the context changes, it is possible that the system will become unusable. This does not guarantee reusability.
  • The tests are expensive because several parts of the system are required to run the test.

Inside-out integration test

In contrast to the outside-in method, the inside-out method first models the inside of the system before dealing with the system's environment. The inside-out method focuses on structural considerations. This harbors the risk that environmental necessities will be overlooked or discovered too late. Inside-out integration is used very rarely, as it does not combine the advantages of top-down and bottom-up, but rather its disadvantages.

Method of inside-out integration

It starts in the middle of the hierarchy and from there components are integrated both upwards and downwards until the system is fully integrated.

literature

  • Dietmar Abts, Wilhelm Mülder; Basic course in business informatics a compact & practice-oriented introduction, ISBN 978-3-658-16378-5 ; Springer Vieweg; 9th edition; Wiesbaden 2017
  • Dirk Zander, Tool-Supported Verification of Distributed Technical Control Systems on the Basis of Activity Diagrams, Ruhr University Bochum; Dissertation, Bochum 2009
  • Peter Liggesmeyer; Software Quality Testing, Analyzing & Verifying Software; ISBN 978-3-8274-2056-5 ; Spectrum academic publisher; 2nd Edition; Heidelberg 2009
  • Dirk. W. Hoffmann; Software quality; ISBN 978-3-642-35699-5 ; Springer Vieweg; 2nd Edition; 2013
  • Mario Winter, Mohsen Ekssir-Monfared, Harry Sneed, Richard Seidl, Lars Borner: The integration test - from design and architecture to component and system integration. ISBN 978-3-446-42564-4 ; Carl Hanser Verlag; 1st edition; 2012
  • Florin-Avram pint; Automatic optimization and evaluation of model-based test cases for the component and integration test, dissertation, Erlangen, 2012
  • Helmut Balzert; Textbook of software technology, basic concepts and requirements engineering; ISBN 978-3-8274-1705-3 ; Spectrum academic publisher; 3. Edition; 2009
  • Walter Masing, Tilo Pfeifer; Masing manual quality management; ISBN 978-3-446-43431-8 ; Carl Hanser Verlag GmbH & Co. KG; 6th edition; 2014
  • Jürgen Moormann, Günter Schmidt; IT in the financial sector: management and method; ISBN 978-3-540-34511-4 ; Jumper; 2007
  • Torsten Cleff; Basic knowledge testing of software; ISBN 978-3-86834-012-9 ; W3L GmbH, 1st edition; 2010

Individual evidence

  1. ↑ [1] Retrieved June 17, 2018.
  2. ↑ Dirk Zander, Tool-based verification of distributed technical control systems based on activity diagrams, Ruhr University Bochum; Dissertation, Bochum 2009, pp. 72-74.
  3. ↑ Peter Liggesmeyer; Software Quality Testing, Analyzing & Verifying Software; Spectrum academic publishing house, Heidelberg 2009; 2nd Edition; P. 372.
  4. ↑ a b c Mario Winter, Mohsen Ekssir-Monfared, Harry Sneed, Richard Seidl , Lars Borner: The Integration Test - From Design and Architecture to Component and System Integration. Carl Hanser Verlag; 2012; 1st edition; P. 163f.
  5. ↑ a b Florin-Avram Pinte; Automatic optimization and evaluation of model-based test cases for the component and integration test, dissertation, Erlangen, 2012; P. 26.
  6. ↑ a b c d e Helmut Balzert; Textbook of software technology, basic concepts and requirements engineering; Spectrum academic publisher; 2009; 3. Edition; Pp. 54-56.
  7. ↑ a b Peter Liggesmeyer; Software Quality Testing, Analyzing & Verifying Software; Spectrum academic publishing house, Heidelberg 2009; 2nd Edition; Pp. 375/376.
  8. ↑ a b Walter Masing, Tilo Pfeifer; Masing manual quality management; Munich, Vienna: Carl Hanser Verlag GmbH & Co. KG; 2014; 6th edition; P. 910f.
  9. ↑ [2]  ( Page no longer available , search in web archives )  Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice. Retrieved July 17, 2018.@1@ 2Template: Dead Link / www.atlassian.com  
  10. ^ Jürgen Moormann, Günter Schmidt; IT in the financial sector: management and method; ISBN 978-3-540-34511-4 ; Jumper; 2007; P. 144f.
  11. ↑ Torsten Cleff; Basic knowledge testing of software; ISBN 978-3-86834-012-9 ; W3L GmbH, 1st edition; 2010; P. 29.