1 / 68

Software Engineering: The Development Process, Vol 1, Chapter 7 Presented By: Andrew Diemer

A Review of Software Testing - P David Coward Reprinted: Information and Software Technology; Vol. 30, No. 3 April 1988. Software Engineering: The Development Process, Vol 1, Chapter 7 Presented By: Andrew Diemer Software Engineering II – EEL 6883. Aim of paper.

zahir-wilcox
Télécharger la présentation

Software Engineering: The Development Process, Vol 1, Chapter 7 Presented By: Andrew Diemer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Review of Software Testing- P David CowardReprinted: Information and Software Technology; Vol. 30, No. 3 April 1988 Software Engineering: The Development Process, Vol 1, Chapter 7 Presented By: Andrew Diemer Software Engineering II – EEL 6883

  2. Aim of paper No guarantee that software meets functional requirements Introduces software testing techniques

  3. Needs Software is to be correct What does this mean It often means the program matches the specifications. Problem with specification Specification could be wrong

  4. Needs If this happens then the correctness is measured by the software meeting the user requirements

  5. Needs Testing Why test Tests may have not been adequate enough Asses the performance of the tasks

  6. Terminology Verification –vs- Validation Verification Ensures correctness from phase to phase of the software life cycle process Formal proofs of correctness

  7. Terminology Validation Checks software against requirements Executes software with test data Author uses testing and checking instead of verification and validation

  8. Categories of Testing Two categories of testing: Functional Non-functional

  9. Functional Testing Functional Addresses to see if the program obtains the correct output It is normally used when testing a modified or new program

  10. Functional Testing Regression Testing Tests following modification Tests to see if the unchanging functions have indeed changed

  11. Non-functional Requirements Style Documentation standards Response times Legal obligations

  12. Situation testing Two situations testing can fall under: Testing which finds faults in the software Testing which does NOT find faults in the software

  13. Situation testing Finding faults Destructive process more probing Not finding faults miss inherent faults too gentle

  14. Questions How much testing is needed? Confidence in testing? Ignore faults? Which ones are important? Are there more faults? What is the purpose of this testing?

  15. Testing Strategies Functional -vs- Structural Static -vs- Dynamic analysis

  16. Strategy starting points Specification It makes known the required functions Asses to see if they are provided Functional testing

  17. Strategy starting points Software Tests the structure of the system Structural testing Functions are included into the system but are NOT required Example: accessing a database that has not been asked by the user

  18. Functional testing Identify the functions which the software is expected to perform Creating test data that will check to see if these functions are performed by the software Does NOT matter how the program performs these functions

  19. Functional testing Rules may be applied to uncover the functions Functional testing methods of formal documentation that includes descriptions of faults that correlate to each part of the design and the design features themselves

  20. Functional testing Isolation of these particular properties of each function should take place Fault class associations Black box approach Testers have an understanding of what the output should be

  21. Functional testing Oracle An expert on what the outcome of a program will be for a particular test When might the oracle approach not work? Simulation testing Only provides a “range of values”

  22. Structural testing Testing is based on the detailed design rather than the functions required by the program

  23. Structural testing Two approaches for this testing First and most common is to execute the program with test cases Second is symbolic execution Functions of the program are compared to the required functions for congruency

  24. Structural testing May require single path or percentage testing Research has been conducted to find out what the minimum amount of testing would be to ensure a degree of reliability

  25. Structural testing Measure of reliability All statements should be executed at least once All branches should be executed at least once All linear code sequence and jumps in the program should be executed at least once

  26. Structural testing Measure of reliability (cont.) Best approach would be the exhaustive approach in which every path is tested

  27. Structural testing Problems with the exhaustive approach Extensive number of paths Multiple combinations constitutes multiple conditions Infeasible paths Contradictions of predicates at conditional statements

  28. Structural testing Path issues There is a path for a loop not executing, executing once, and executing multiple of times Control loops determine the number of paths

  29. Structural testing Path issues Known as the “level-i” path or island code Island code A series of lines of code, following a program termination, which is not the destination of a transfer control from somewhere else in the program

  30. Structural testing Path issues When does island code occur? When failing to delete redundant code after maintenance

  31. Static analysis Does NOT involve execution of software with data but involves the use of constraints on the input and output data sets mathematically on software components Examples of static analysis would be program proving and symbolic execution

  32. Static analysis Symbolic execution Use symbolic values for variables instead of numeric or string values

  33. Dynamic analysis Relies on program statements which make calls to analysis routines They record the frequency of execution of elements of the program

  34. Dynamic analysis Act as a liaison between functional and structural testing Test cases monitored dynamically, then structurally tested to see what idle code is left by previous tests Shows functions the program should perform

  35. Classification of Techniques There are three classifications: Static – Structural Symbolic execution Partition analysis Program proving Anomaly analysis

  36. Classification of Techniques Dynamic - Functional Domain testing Random testing Adaptive perturbation Cause-effect graphing

  37. Classification of Techniques Dynamic - Structural Domain and computational testing Automatic test data generation Mutation analysis

  38. Classification of Techniques Dynamic - Structural Domain and computational testing Automatic test data generation Mutation analysis

  39. Symbolic execution Non traditional approach traditional is the execution requires that a selection of paths through a program is exercised by a set of test classes Produces a set of expressions, one per output variable

  40. Symbolic execution Usually a program executes using input data values with the output resulting in a set of actual values Use of flow-graphs Each branch contains decision points (directed graph) Branch predictions are produced

  41. Symbolic execution Use of top down approach During the top down traversal, the input variable is given a symbol in place of an actual value A problem is in the iterations As mentioned before, no executing loop, executing once, and then executing multiple times.

  42. Partition analysis Uses symbolic execution to find sub domains of the input domain Path conditions are used to find them Input domains that cannot be allocated to a sub domain infer a fault

  43. Partition analysis Specifications need to be written at a higher lever

  44. Program proving At the beginning and end of the procedure, place a mathematical method assertions Similar to symbolic execution Neither of them execute actual data and both examine source code

  45. Program proving Tries to come up with a proof that encompasses all possible iterations Program proving steps: Construct a program Examine the program and insert mathematical assertions at the beginning and end of procedures

  46. Program proving Program proving steps (cont): Determine whether the code between each pair of start and end assertions will achieve the end assertion given the start assertion If the code reaches the end assertion then the block has been proven

  47. Program proving DeMillo says that proofs can only be stated as acceptable and not correct His acceptance is determined by a gathering of people who cannot find fault with the proof

  48. Program proving The larger the audience, the more confidence in the software Total correctness means loops will terminate

  49. Anomaly analysis Two levels of anomalies: made by the compiler (language syntax) problems that are not necessarily wrong by the programming language

  50. Anomaly analysis Some anomalies are: Unexecutable code Array boundaries Initializing variables wrong Unused labels and variables Traversing in and out of loops

More Related