1 / 23

Program design and analysis

Program design and analysis. Program validation and testing. Goals. Make sure software works as intended. We will concentrate on functional testing---performance testing is harder. What tests are required to adequately test the program? What is “adequate”?. Basic testing procedure.

edithhorton
Télécharger la présentation

Program design and analysis

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. Program design and analysis • Program validation and testing. Overheads for Computers as Components

  2. Goals • Make sure software works as intended. • We will concentrate on functional testing---performance testing is harder. • What tests are required to adequately test the program? • What is “adequate”? Overheads for Computers as Components

  3. Basic testing procedure • Provide the program with inputs. • Execute the program. • Compare the outputs to expected results. Overheads for Computers as Components

  4. Types of software testing • Black-box: tests are generated without knowledge of program internals. • Clear-box (white-box): tests are generated from the program structure. Overheads for Computers as Components

  5. Clear-box testing • Generate tests based on the structure of the program. • Is a given block of code executed when we think it should be executed? • Does a variable receive the value we think it should get? Overheads for Computers as Components

  6. Controllability and observability • Controllability: must be able to cause a particular internal condition to occur. • Observability: must be able to see the effects of a state from the outside. Overheads for Computers as Components

  7. Example: FIR filter • Code: for (firout = 0.0, j =0; j < N; j++) firout += buff[j] * c[j]; if (firout > 100.0) firout = 100.0; if (firout < -100.0) firout = -100.0; • Controllability: to test range checks for firout, must first load circular buffer. • Observability: how do we observe values of buff, firout? Overheads for Computers as Components

  8. Path-based testing • Clear-box testing generally tests selected program paths: • control program to exercise a path; • observe program to determine if path was properly executed. • May look at whether location on path was reached (control), whether variable on path was set (data). Overheads for Computers as Components

  9. Points of view • Several ways to look at control coverage: • statement coverage; • basis sets; • cyclomatic complexity; • branch testing; • domain testing. Overheads for Computers as Components

  10. Example: choosing paths • Two possible criteria for selecting a set of paths: • Execute every statement at least once. • Execute every direction of a branch at least once. • Equivalent for structured programs, but not for programs with gotos. Overheads for Computers as Components

  11. +/+ Covers all branches Covers all statements Path example Overheads for Computers as Components

  12. Basis paths • How many distinct paths are in a program? • An undirected graph has a basis set of edges: • a linear combination of basis edges (xor together sets of edges) gives any possible subset of edges in the graph. • CDFG is directed, but basis set is an approximation. Overheads for Computers as Components

  13. Basis set example a b c d e a 0 0 1 0 0 b 0 0 1 0 1 c 1 1 0 1 0 d 0 0 1 0 1 e 0 1 0 1 0 a b c incidence matrix a 0 0 1 0 0 b 0 0 1 0 1 c 1 1 0 1 0 d 0 0 1 0 1 e 0 1 0 1 0 d e Overheads for Computers as Components basis set

  14. Cyclomatic complexity • Provides an upper bound on the control complexity of a program: • e = # edges in control graph; • n = # nodes in control graph; • p = # graph components. • Cyclomatic complexity: • M = e - n + 2p. • Structured program: # binary decisions + 1. Overheads for Computers as Components

  15. Branch testing strategy • Exercise the elements of a conditional, not just one true and one false case. • Devise a test for every simple condition in a Boolean expression. Overheads for Computers as Components

  16. Example: branch testing • Meant to write: if (a || (b >= c)) { printf(“OK\n”); } • Actually wrote: if (a && (b >= c)) { printf(“OK\n”); } • Branch testing strategy: • One test is a=F, (b >= c) = T: a=0, b=3, c=2. • Produces different answers. Overheads for Computers as Components

  17. Another branch testing example • Meant to write: if ((x == good_pointer) && (x->field1 == 3))... • Actually wrote: if ((x = good_pointer) && (x->field1 == 3))... • Branch testing strategy: • If we use only field1 value to exercise branch, we may miss pointer problem. Overheads for Computers as Components

  18. Domain testing • Concentrates on linear inequalities. • Example: j <= i + 1. • Test two cases on boundary, one outside boundary. correct incorrect Overheads for Computers as Components

  19. def p-use Data flow testing • Def-use analysis: match variable definitions (assignments) and uses. • Example: x = 5; … if (x > 0) ... • Does assignment get to the use? Overheads for Computers as Components

  20. Loop testing • Common, specialized structure---specialized tests can help. • Useful test cases: • skip loop entirely; • one iteration; • two iterations; • mid-range of iterations; • n-1, n, n+1 iterations. Overheads for Computers as Components

  21. Black-box testing • Black-box tests are made from the specifications, not the code. • Black-box testing complements clear-box. • May test unusual cases better. Overheads for Computers as Components

  22. Types of black-box tests • Specified inputs/outputs: • select inputs from spec, determine requried outputs. • Random: • generate random tests, determine appropriate output. • Regression: • tests used in previous versions of system. Overheads for Computers as Components

  23. Evaluating tests • How good are your tests? • Keep track of bugs found, compare to historical trends. • Error injection: add bugs to copy of code, run tests on modified code. Overheads for Computers as Components

More Related