0 < i < 1000 10 < i < 500 bar = #i + 1 def bar i Computer Science and Engineering The Ohio State University Is foo correct? Copyright By PowCoder代写 加微信 powcoder
if “yes”, why?
if “no”, what test case reveals the bug?
Is bar correct?
if “yes”, why?
if “no”, what test case reveals the bug?
Computer Science and Engineering College of Engineering The Ohio State University
Definition of Testing
A process whereby we increase our confidence in an implementation by observing its behavior
Computer Science and Engineering The Ohio State University
What is “testing”?
Fundamental point:
Testing can detect the presence of
mistakes, never their absence! Fail a test case ==>
Pass all test cases ==>
Importance of Testing
Computer Science and Engineering The Ohio State University
Despite limitations, testing is the most practical approach for large systems
quotation:
“Warning: I’ve only proven this algorithm is correct… I haven’t tested it!”
3 levels of abstraction in functionality
Want: the idea Have: an
implementation
“Testing” requires comparing it against something, but what?
Computer Science and Engineering The Ohio State University
Specification
Implementation
Theory (II)
Ideal: test against our “idea” But the idea is usually too fuzzy
So make it concrete by writing a specification
Defines desired mapping from input to output
Input Specification
Computer Science and Engineering The Ohio State University
Expected Output
Implementation
Actual Output
Example: Sorting a List
Computer Science and Engineering The Ohio State University
Idea: Function takes a list and puts it in order
Too fuzzy!
Does it modify the list or return a new one?
Does it require the list to be non empty?
Does it sort in increasing or decreasing order?
What kind of items can be in the list?
Questions:
Example: Sorting a List
Computer Science and Engineering The Ohio State University
Example: Sorting a List
Computer Science and Engineering The Ohio State University
Initial and Final Values
Computer Science and Engineering The Ohio State University
Often the final value of a parameter depends on its initial value
SW I/II: “Updates” parameter mode Example: mutator method sort!
Consequence: Specification includes old value (eg #list) in ensures clause
Sometimes the final value is independent of its initial value
“Replaces” and “Clears” parameter modes Example: mutator methods fill, clear
Relational Specifications
Computer Science and Engineering The Ohio State University
A function maps each element in its domain to a single element in its range
A relation maps each element in its domain to at least one elt in its range
For specifications:
Function = deterministic behavior Relation = nondeterministic behavior
find_factor n returns some prime factor shuffle scrambles elements of array
Frame of Mind for Validation
Computer Science and Engineering The Ohio State University
Tests should be written to break a program
Not to show it works!
When a test reveals an error, that’s success!
Failed test case is a positive thing
Good approach: have someone else test your code
Importance of Indep’t Testing
Computer Science and Engineering The Ohio State University
See IEEE Computer, Oct ‘99 study at NASA Langley
had two groups working in parallel
The group with independent testers found:
more faults overall (critical and non-critical) found these faults earlier in the process fixed these faults with less effort
Figure 1 from Arthur article
Computer Science and Engineering The Ohio State University
Figure 2 from Arthur article
Computer Science and Engineering The Ohio State University
Writing Good Tests (Inputs)
Computer Science and Engineering The Ohio State University
Too many possible inputs to test them all
Space is defined by requires clause Choose inputs wisely
Test boundary conditions
eg 0, empty array, empty string eg positive, negative, and zero
Test different categories of input
Test different categories of behavior
eg each menu option, each error message eg nil, last name includes a space
Test “unexpected” input
Test representative “normal” input
eg random, reasonable values
How To Create Expected Output
Computer Science and Engineering The Ohio State University
Error-prone and tedious
With another program
Also error-prone
Work backwards
Inverse may be easier to calculate
Eg start with a sorted list then permute it
Often just redoing the implementation, and making the same mistakes!
Alternative: Validating Output
Computer Science and Engineering The Ohio State University
Keep a copy of the input
Run the program
Validate the actual output against input
Example: sorting
write two helper functions:
copy the input
run program and check
Helper functions may be easier to get right than the unit under test
Dangers with Testing
Computer Science and Engineering The Ohio State University
“Expected output” is wrong
Testing program is wrong
Extra code means more chances to make mistakes
E.g. permute(a,b) always returns true With these errors, there are 2 dangers:
1. Spurious test failures (passes when shouldn’t)
2. False positives (fails when it shouldn’t) Which is worse?
Another Danger with Testing
Computer Science and Engineering The Ohio State University
A third, more subtle, potential error: The specification is wrong
How can this be?
When testing drives implementation, this kind of error will not be exposed
To increase the chances of finding these problems, have someone else test your code!
Levels of Testing
Computer Science and Engineering The Ohio State University
Different kinds of testing, aimed at identifying different kinds of errors 1. Unit tests
2. Integration tests
3. System tests
Unit Tests
Individual components tested in isolation UUT: Unit Under Test
Black box: testing based only on specification (tester does not look at code)
White box: testing based on code structure (tester looks at code to make sure every branch of a switch statement is followed)
Often uses a test fixture
Configuration, values, objects which are set
up before running all the tests
Flavors of unit testing:
Computer Science and Engineering The Ohio State University
Integration Tests
Computer Science and Engineering The Ohio State University
Modules tested in combination in order to check the interfaces
Best done incrementally Driver
Initialize Load
FileIO Header
Bottom-up vs Top-down Testing
Start with most basic modules
Easy to exercise all the features
Write a “driver” for higher-level modules
Computer Science and Engineering The Ohio State University
Start at top (main)
Test interfaces early
Write “stubs” for lower level modules
Often these two occur simultaneously, in tandem
System Tests
Verify that system as a whole meets the requirements and specifications
Three flavors:
alpha: By developers, before release
beta: By “friendly customers”, before general release
acceptance: By end customer, to decide whether or not to hire you next time!
Computer Science and Engineering The Ohio State University
TDD: Test-Driven Development
Computer Science and Engineering The Ohio State University
In dynamic languages, testing is even more important
Load-time errors << compile-time errors
Extreme position: "If it isn't tested, assume it doesn't work"
TDD: Write tests first (before code) Recall "client-view first" in Software I/II
Development cycle: "red, green, refactor" Write tests, watch them fail
Write (only) enough code for tests to pass (may need to refactor)
Nature of testing
Computer Science and Engineering The Ohio State University
Importance of the right frame of mind
Write tests to break code
TDD: write tests to guide development
Levels of Testing
Unit tests Integration tests System tests
Specification, implementation, test cases Initial values matter too
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com