Software Testing Testing in the Software Lifecycle

  • View
    225

  • Download
    8

Embed Size (px)

Transcript

  • Slide 1
  • Software Testing Testing in the Software Lifecycle
  • Slide 2
  • Component Test Explanation of term Verifies whether each software component performs correctly according to its specification Checks internal aspects and behavior of a component Also called module test, unit test, or class test depending on programming language used Test objects The software components are tested individually and isolated from all other software components of the system Isolation is to prevent external influences If a problem exists, it is definitely originating from the component
  • Slide 3
  • Component Test Test environment Test objects coming directly from the developers desk Close cooperation with development Case study Testing a class method C++ function to calculate the total price In order to test the class method a test driver is necessary: a program that calls the component under test and then receives the test objects reaction The test driver Information could be recorded in test drivers: Test data and results Date and time of test A function that reads test cases from a file or database
  • Slide 4
  • Component Test Test objectives Important task is to guarantee the particular test object executes its entire functionality correctly and completely as required by the specification (functional testing) This means the behavior of input/output of test object The component is tested with a series of test cases, where each test case covers a particular input/output combination (partial functionality) What do the input/output combinations in test cases for the case study tell us? Test case 2 checks the partial functionality of discount in the case of five or more special equipment items. If test case 2 is executed the test object calculates an incorrect total price. Test case 2 produces a failure
  • Slide 5
  • Component Testing Typical defect found: Wrong calculation Missing or wrongly chosen program paths Eg special cases that were forgotten or misinterpreted Robustness testing Testing to determine the robustness of the software product The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environment conditions Function calls and test data are used that are either known to be wrong or at least are special case not mentioned in the specification The components reaction should be an appropriate exception handling If there is no such exception handling, wrong inputs can trigger domain faults such as like division by zero or access through null pointer Such faults could lead to a program crash
  • Slide 6
  • Component Testing Such test cases are also called negative tests Example for case study (negative test) // testcase 20 price = calculate_price(-1000.00,0.00,0.00,0,0); test_ok = test_ok && (ERR_CODE == INVALID_PRICE); //testcase 30 price = calculate_price(abc,0.00,0.00,0,0); test_ok = test_ok && (ERR_CODE == INVALID_ARGUMENT);
  • Slide 7
  • Component Testing Testing nonfunctional characteristics that cannot be tested at higher test level such as efficiency and maintainability Efficiency states how efficiently a component uses computer resources Use of memory measured in kilobytes Computing time measured in milliseconds Disk or network access time measured in milliseconds Time required to execute the components function and algorithms Efficiency must be verified only in efficiency-critical paths or if efficiency requirements are stated in spec. Eg: testing embedded software, realtime system
  • Slide 8
  • Component Testing Maintainability means all the characteristics of a program that have an influence on how easy or difficult it is to change the program or to continue developing it Maintainability testing requires: Code structure Modularity Quality of comments Adherence to standards Understandability Currency of the documentation Can be done by analysis of the program text and spec Static test What are your analysis on the method in the case study?
  • Slide 9
  • Component Testing Test strategy Use white box testing Tester can design test cases using their knowledge about the components program structures, its functions, and variable. Use debugger Observe program variables during test execution Can help checking for correct and incorrect behavior
  • Slide 10
  • Integration Test Explanation of terms second test level after component test Supposes that the test objects subjected to components have been tested Groups of these components are composed to form larger structural units and subsystems (integration) After assembling the components, it must be confirmed through testing that all components collaborate correctly The goal of integration testing To expose faults in the interfaces and in the interaction between integrated components Is necessary as a further test level to find collaboration and interoperability problems and isolate the causes
  • Slide 11
  • Integration Test Explanation of terms Component integration test is also called integration test in the small System integration test is also called integration test in the large Testing interfaces to external systems Test objects Assembled components External system or component off-the-shelf (COTS)
  • Slide 12
  • Integration Test Test Environment Also needs test drivers Can reuse test drivers that were used earlier for component testing Additional tools, called monitors, are required that read and log data traffic between components
  • Slide 13
  • Integration Test Test objectives To reveal interface and cooperation problems, as well as conflicts between integrated parts Example of integration not working Interface format may not compatible Some files are missing Developers have split the system into completely different components than were in original design Faults in data exchange A component transmits syntactically wrong or no data The communication works but the involved components interpret the received data in a different way (contradict or misinterpret spec) Data is transmitted correctly but is transmitted at the wrong time
  • Slide 14
  • Integration Test Is it possible to do without component testing and execute all test cases after integration is finished? It is possible but only at the risk of great disadvantages Most of failures that will occur in a test design are caused by functional faults within the individual components Because there is no suitable access to the individual component some failures cannot be provoked and many faults, cannot be found If a failure occurs in the test, it can be difficult or impossible tp locate its origin and to isolate its cause
  • Slide 15
  • Integration Test Integration strategies In what order should the components be integrated in order to execute the necessary testing as quickly and easily as possible? Components may be completed at different times Ad hoc strategy is to integrate the components in order in which they are ready As a component has passed the component test, check if it fits with another already tested component, or if it fits into partially integrated subsystem If so, both parts are integrated and tested Need to write stubs to help in integration Stub is a skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component
  • Slide 16
  • Integration Test : Basic strategies Top-down integration The test starts with the top level component that calls other components but not called itself. Stubs replace all subordinate components Successively, integration proceeds with lower level components The higher level that has already been tested serves as test drivers Advantage Test drivers are not needed or only simple ones are required, because the higher-level components that have been tested serve as main part of the test environment Disadvantage Lower level components not yet integrated must be replaced by stubs. This can be costly
  • Slide 17
  • Integration Test : Basic strategies Bottom-up integration The test starts with the elementary system components that do not call further components, except for functions of operating system. Larger subsystems are assembled from the tested components and then these integrated parts are tested Advantage No stubs are needed Disadvantage Higher-level components must be simulated by test drivers
  • Slide 18
  • Integration Test : Basic strategies Ad hoc integration The components are being integrated in the (casual) order in which they are finished Advantage Save time, because every component is integrated as early as possible into its environment Disadvantage Stubs as well as test drivers are required
  • Slide 19
  • Integration Test : Basic strategies backbone integration strategy A skeletal or backbone is built into which components are gradually integrated Advantage Components can be integrated in any order Disadvantage Labour intensive skeletal or backbone is required
  • Slide 20
  • Integration Test : Basic strategies Top-down and bottom-up integration in their pure form can only be applied to program structured in a strictly hierarchical way A more or less individual mix of the integration strategies may be chosen Any non-incremental integration, also called big bang should be avoided Disadvantages The time leading up to the big bang is lost time that could have been spent on testing All failures will occur at