4/12 Testing

Samel test for you project

$ java InventoryProject
> user Alice ( user perforimgn command .. a new user is specificied) > role Operations (role of current user) > add-inv ( "add inventory" command . . . > show-user
> Alice
> show-role
> Operations
.
.
> quit
$

NOTE: Instead of having mulitple "show -" commands we culd have just one that takes an argument that indicates what to show

ex:
show -user
show -group
show -available
show -booked
.
.
.

if number of records is small, you can sum "view total"
if number of records exceeds ~1000, you may want to start keeping a running summary, but this makes updating harder, but it makes a summary easier


view booked command needs to iterate thru the store and sum booked inventory





**************************

Testing

black-box (aka functional testing)
+ based on specifications - no inspection
+ avoids the mistake of examining/inspecting the app and making the same wrong assumptions the developers made
-independent verification of functionality
+tests are representation independent


NOTE: this is how the TA is going to test your project. the other part of the grading is code inspection

Clear-Box (aka white-box)
+ test cases are generated by looking at the implementation
+ very effective n pointing out problems with inputs that are handled differently by different branches in the code

EX:

int max3(int x, int y, int z) {
if (x>y) {
if (x>y) return x; else return z;
} else {
if (y>z) return y; else return z;
}
}


Clear-box testing also helps finding additional test condition based on things like local variable, loopiterators, etc.

EX:


possible addtional test case
+ input such that the loop is never exectured
+ execeuted just once
+ executed max number of times

Test Strategy and automation use both black=box and clear box testing
(ideally, the test cases developed by someobdy whos only read the specification for the product)


bottom-up : test each module before it gets integrated into the larger context
top-down test hte application until all test pass

assume the followng module dependency diagram


A

| |
B C
| |
D | |
E F

bottum up : test D before B
test E & F before C
test B & C before A

Q: how do you test D before B?
A: youll need to dvlop drivers/wrappers that provide the inputs needed by D.


top down:write stubs to stimulate the behavrior of those parts of the system that havent been developed yet


write stubs..all tests fail..work on it till it passes
as you start writing more code, you change those stubs in to actual working code

advantage of top-down: erros can be identified early in the process before all code has been written

top down is difficult for a large project because clients are unable to detail all criteria for the application

regression testing
+ test your code after youmake code change
- validate that you havent introduced a defect while fixing some code or adding new functionality

automated acceptance testing
+ the test can record human's actions on screen
+ add custom scripting to supplement the recording

The tool can do what a human would do in front of the same screen (e.g. fill in text bozes, check radio buttions, submit forms, etc.)

NOTE: the development of test scrpting should be treated like any other software development activity.

testing is like code, it's intellectual property... will help manage employee turnover, gaurantee function and customer satisfaction, maintain sofware, ...


"start writing code and see how it evolves"