Software Testing Techniques Dan Berger dberger@cs.ucr.edu
Upcoming SlideShare
Loading in...5
×
 

Software Testing Techniques Dan Berger dberger@cs.ucr.edu

on

  • 340 views

 

Statistics

Views

Total Views
340
Views on SlideShare
340
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Software Testing Techniques Dan Berger dberger@cs.ucr.edu Software Testing Techniques Dan Berger dberger@cs.ucr.edu Presentation Transcript

    • Software Testing Techniques Dan Berger [email_address] Peter Fröhlich [email_address] edu
    • Outline
      • What is Testing?
      • Why Test?
      • How To Test The Tests?
      • Code Coverage (Peter)
      • How To Decide What To Test?
      • Automation Tools
      • Writing Test Cases
    • What Is Testing?
      • In this context – confirming correct behavior of a piece of software.
    • Why Test?
      • We know what we intended the code to do – we need to confirm that it does what we intended.
    • How To Test Our Tests?
      • In other words: how can we be sure our tests are:
        • testing the right (relevant) “stuff”?
        • testing “most” of the code and not just repeatedly testing the same code?
    • Code Coverage
      • Take it away, Peter…
    • How To Decide What To Test? Low-Level Classes Application Subsystems Your Program
    • How To Decide (II)
      • The trick is drawing a line across that triangle.
        • Draw it too low and you have too many classes to test – and the tests aren’t meaningful.
        • Draw it too high and a test failure leads you on a wild goose chase…
      • The bad news is – deciding where to draw that line is an art, not a science.
    • Automation Tools
      • How many times have you written code and then sat in front of the keyboard running through test cases?
        • How many times have you actually thought about test cases?
      • The good news is that there is a better way.
        • And it’s never too late for a new beginning…
    • Automation To The Rescue
      • A few key tools:
        • make
          • make running tests a part of your build
        • scripting
          • if you can automate it, automate it
        • expect
          • a powerful tool
    • Make
      • Add a test rule to your makefile – it should run all the tests you’ve written and log their results.
      • If they all pass, you’re done – if not, figure out why not.
    • Scripting
      • Imagine you have a bunch of executables that test various parts of your program.
        • We’ll talk about how they might be built shortly.
      • Imagine you’ve written a shell script to run them, one at a time.
      • How do you know when one fails?
    • Scripting (II)
      • You can check the exit code of a program running from a shell script:
        • if [ $? –ne 0 ]; then … else … fi
      • if the executable exits abnormally, the then clause executes.
    • Expect
      • Written by Don Libes – an extension to Tcl
        • What, you’ve never heard of tcl?
        • That’s OK – there’s a python version as well.
          • If you’ve never heard of python, you should have attended our python seminar…
    • Expect (II)
      • It’s be installed on the lab machines
      • Basic commands:
      • spawn
        • run’s a new command under script control.
      • send
        • provides input to the command
      • expect
        • matches a pattern in the command output
    • Expect (Example)
      • #!/usr/bin/expect
      • set timeout 5
      • spawn ssh –x [lindex $argv 0] “ls /”
      • expect {
      • timout {puts “timeout”}
      • eof {exit 0}
      • “ continue connecting (yes/no)? ” {send “yes” }
      • }
      • expect {
      • eof {exit 0}
      • }
    • Python Expect
      • Pexpect – http:// pexpect .sourceforge.net
      • Good News: Provides *most* of expect’s functionality from within python.
      • Bad News: it’s not installed on the lab machines (yet?).
    • Writing Test Cases
      • Write a simple executable that instantiates a class, and “drives” that instance.
    • Test Cases (Cont.)
      • Imagine you have a linked list class…
        • If you wrote your own linked list class – and you’re working in C++ - you should have been in our STL seminar.
      • What should your test program test?
    • Parting Words
      • Be a skeptic – you, as the developer, are the only one who can crystal-box test your code.
        • Don’t test the easy cases – test the ones you’re not sure about.
        • Don’t waste time testing the same thing more than once – break input into “equivalence classes”