CT320

CT320: Network and System Administration

Fall 2017

Testing

See this page as a slide show

CT320: Testing

Philosophy of testing

  1. Get over it
  2. Trust, but verify
  3. Test the typical cases
  4. Test invalid input
  5. Test the limits
  6. Automation

Get over it

Trust, but verify

Sure, whoever programmed this is really smart (especially if they’re you). It’s probably correct.

Test the typical cases

Test invalid input

  • Arguments
    • too many/too few
    • bad (e.g., -z)
    • duplicate (--high --high)
    • conflicting (--high --low)
  • Files
    • don’t exist (/foo/bogus)
    • bad permissions (/etc/shadow)
    • contain bad data (/bin/sync)
  • Numbers
    • integer
    • real
    • ±0.0
    • NaN
    • ±∞
    • too small
    • too big
    • too negative
    • fish
    • 3fish

Test the limits

Case study

Consider a command, zot, which takes a number of files as arguments, and an option which determines which files should be output. Think of it as a conditional cat.

    zot [-f first-last] file ...

Where first and last are optional inclusive ordinal file indices.

How do we test this command?

Test cases (valid cases)

    zot alpha
    zot alpha beta gamma delta
    zot -f2-3 alpha beta gamma delta
    zot -f 2-3 alpha beta gamma delta
    zot -f 2-2 alpha beta gamma delta
    zot -f 2-  alpha beta
    zot -f  -2 alpha beta gamma

Test cases (invalid cases)

    zot
    zot -fx alpha
    zot -f3 alpha
    zot -f1 -f2 alpha beta
    zot -f0-1 alpha
    zot -f1-2 alpha
    zot -f2-1 alpha beta gamma
    zot -q alpha
    zot badfile

Automation

    #! /bin/bash
    (
        zot -fx alpha
        zot -f3 alpha
        zot -f1 -f2 alpha beta
        …
    ) >&out
    diff out known-good-output

Modified: 2017-09-12T10:33

User: Guest

Check: HTML CSS
Edit History Source
Apply to CSU | Contact CSU | Disclaimer | Equal Opportunity
Colorado State University, Fort Collins, CO 80523 USA
© 2015 Colorado State University
CS Building