Upload
madison-diane-barber
View
220
Download
0
Tags:
Embed Size (px)
Citation preview
CEN 5070 Software V&VSpring 2002
Testing 102 -- Internal Modules© 2001-2002, Dr. E.L. Jones
1/2002 Testing 102 -- Internal Modules 2
Purpose
This lecture prepares the student to practice unit testing on a project by applying the concepts covered in the Software Unit Test Concepts course.
1/2002 Testing 102 -- Internal Modules 3
Agenda
• Products & Deliverables
• Testing Classes
• What is Unit Testing?
• Testing Callable Modules
• Putting it All Together
1/2002 Testing 102 -- Internal Modules 4
What is Unit Testing?
• Executing a software element to determine whether it meets its specification
• Executing a software element to discover defects or anomalies
• Inspecting software element code to discover defects or anomalies.
1/2002 Testing 102 -- Internal Modules 5
What Is A Unit?
• Named software element with properties and behavior
• Separately invokable• Performs single function• Logically cohesive set of the above
1/2002 Testing 102 -- Internal Modules 6
Examples of Units
• User-Visible software elements• Fields on forms
• Buttons on forms
• Entire forms (reports)
• Program-Internal software elements• Subprograms (procedures, functions, mains)
• Classes
• Databases
1/2002 Testing 102 -- Internal Modules 7
Elementary Units
• Form• Field
• Navigation Button
• Operation Button
• Database• Field
• Stored Procedure
• Query
• Program Code• Main
• Method
• Function
• Script
1/2002 Testing 102 -- Internal Modules 8
Can A Unit Be Bigger?
• Yes, but beware of pitfalls• Complex units are hard to test• Repetition of tests more costly• Tendency to focus on the easy part
• A composite unit (naturally related parts)• A class = methods + data• A form = data fields + action buttons
• One test script for hierarchical testing of parts, then whole
1/2002 Testing 102 -- Internal Modules 9
Objective
The practice of unit testing adds value to the development process by surfacing areas of incompleteness, inaccuracy or ambiguity. Extensive use of aids (checklists, worksheets) minimizes the effort but encourages thorough analysis.
1/2002 Testing 102 -- Internal Modules 10
Agenda
• Products & Deliverables
• Testing Classes
• What is Unit Testing?
• Testing Callable Modules
• Putting It All Together
1/2002 Testing 102 -- Internal Modules 11
Required Elements of Testing Practice
• Specification for the software
• Process for designing test cases
• Repeatable process for designing, running and evaluating tests
• Accountable artifacts of testing activities
• Economical use of human, time and computing resources
1/2002 Testing 102 -- Internal Modules 12
Recommended Practice
Analysis
Design
Implementation
Execution
Evaluation
Decision Table
[Test Script, Driver]
#Bugs Found
Worksheet(Test Cases)
Worksheet(Results)
Specification,
Code
1/2002 Testing 102 -- Internal Modules 13
Products vs Deliverables
• A Product is an informal artifact from applying a testing process. • belongs to the developer
• a physical form, not necessarily electronic
• A Deliverable is an artifact that attests to the application of the testing process• belongs to the team
• an attesting signature required
1/2002 Testing 102 -- Internal Modules 14
Product Templates
• Templates will be provided for these test products• Black-box Schematic
• Decision table
• Unit test cases (functional, boundary)
• Unit test worksheets
1/2002 Testing 102 -- Internal Modules 15
Agenda
• Products & Deliverables
• Testing Callable Subprograms/Methods
• What is Unit Testing?
• Testing Callable Modules
• Testing Database Procedures
1/2002 Testing 102 -- Internal Modules 16
Testing Modules -- Overview
Directly testing callable modules requires isolating the module and capturing the context in which it is called. Additional effort is required for this "code level" testing, but certain aspects can be automated, providing repeatability, efficiency and documentation.
1/2002 Testing 102 -- Internal Modules 17
Testing Modules -- Drivers
A test driver executes a unit with test case data and captures the results.
Driver
Test setData External
EffectsUnitArguments
ResultsTest Set Results
1/2002 Testing 102 -- Internal Modules 18
Implementing Test Drivers
• Complexity– Arguments/Results only– Special set-up required to execute unit– External effects capture/inquiry– Oracle announcing "PASS"/"FAIL"
• Major Benefits– Automated, repeatable test script– Documented evidence of testing– Universal design pattern
1/2002 Testing 102 -- Internal Modules 19
Test Driver for Unit Pay
Driver D_payuses unit_environment E;{ declare Hrs, Rate, expected; testcase_no = 0; open tdi_file("tdi-pay.txt"); open trs_file("trs-pay.txt"); while (more data in tdi_file) { read(tdi_file, Hrs, Rate); read(tdi_file, expected);
testresult = pay(Hrs, Rate); write (trs_file, testcase_no++, Hrs, Rate, expected, testresult); }//while close tdi_file, trs_file; }//driver
1/2002 Testing 102 -- Internal Modules 20
Test Driver Files (Pay)
Test Data FileFile name: tdi-pay.txtFormat: (test cases only) rate hours expected-pay
File content:10 40 400 10 50 55010 0 0
------Note: No environment setup.
Test Results FileFile name: trs-pay.txtFormat: case# rate hours exp-pay act-pay
File content:1 10 40 400 4002 10 50 550 5003 10 0 0 0
------Note: Results file must be inspected for failures.
PassFailPass
Test Script!!
1/2002 Testing 102 -- Internal Modules 21
Testing Modules -- Drivers with Test Environment Set-Up
The driver initializes the execution environment of the unit, and examines it after testing completes.
External
EffectsUnit
Driver
Test setData
ArgumentsResults
Test Set Results
Environment
ExecutionEnvironment
Setup / Inquire
1/2002 Testing 102 -- Internal Modules 22
Test Driver Files (Pay2) (Accumulates grand total of pay amounts)
PassFailPass
Fail
Test Data FileFile name: tdi-pay.txtFormat: initial_pay_total final_pay_total {rate hours expected-pay}
File content:1000 195010 40 400 10 50 55010 0 0
------Note: Environment setup = initialize global variable.
Test Results FileFile name: trs-pay.txtFormat: case# rate hours exp-pay act-pay env_init, env_exp, env_final
File content:1 10 40 400 4002 10 50 550 5003 10 0 0 0
1000 1950 1900------Note: Results file must be inspected for failures.
Test Script!!
Initial / ExpectedGrand Total
1/2002 Testing 102 -- Internal Modules 23
Test Driver for Pay2(Accumulates grand total of pay amounts)
Driver Dglobal total_pay;{ open tdi_file ("tdi-pay2.txt"); open trs_file("trs-pay2.txt");
//Set up unit_environment E read (tdi_file, initial_tot, exp_tot); total_pay = initial_tot; testcase_no = 0; while (more data in tdi_file) { read (tdi_file, Hrs, Rate); read (tdi_file, expected);
testresult = pay2(Hrs, Rate); write (trs_file, testcase_no++, Hrs, Rate, expected, testresult); }//while
final_tot = total_pay; write(trs_file, initial_tot, exp_tot, final_tot); close tdi_file, trs_file; }//driver
1/2002 Testing 102 -- Internal Modules 24
Unit Test Driver Design -- Test Environment Set-Up/Inquiry
Driver Duses unit_environment E;{ open tdi_file (filename); open trs_file (filename);
//Set up unit_environment E read (tdi_file, E_initial, E_expect); E.set (E_initial); testcase_no = 0; while (more data in tdi_file) { read (tdi_file, testdata); read (tdi_file, expected);
testresult = unit(testdata); write (trs_file, testcase_no++, testdata, expected, testresult); }//while
E.get(E_final); write (trs_file, E_initial, E_expect, E_final); close tdi_file, trs_file; }//driver
1/2002 Testing 102 -- Internal Modules 25
Your Turn -- Test Driver Design
Unit GenPayroll(PayDate) computes pay for all employees who
submitted time records (file "time.dat") for the previous week. All
employees are hourly. Employee IDs, pay rates, and YTD earnings
are stored in the Employee database ("emp.db"). GenPayroll calls
unit Pay (Hours, Rate) to compute gross pay. Next, GenPayroll
deducts a flat 10%, then writes PayDate, EmployeeID, Hours, Rate,
GrossPay, Deductions, and NetPay to the Payroll Register (file
"payreg.dat"). Finally, GenPayroll updates YTD-Earning for the
employee. -------------------------------
Design the test driver for GenPayroll. Focus on (1) required set-
up; (2) data preparation; (3) test execution; (4) verification of
results.
1/2002 Testing 102 -- Internal Modules 26
Your Turn -- Test Driver Design
DriverPayDate
GenPayroll Pay
RateHours
GrossPay
file"time.dat"
database"emp.db"
file"payreg.dat"
Verification
Set-Up
1/2002 Testing 102 -- Internal Modules 27
Agenda
• Products & Deliverables
• Testing Classes
• What is Unit Testing?
• Testing Callable Modules -- DB Proc
• Putting It All Together
1/2002 Testing 102 -- Internal Modules 28
Testing DB Procedures -- OverviewSince the database plays a central role in a system, database procedures should be tested carefully. Automating this testing permits thorough testing and efficient verification via database queries. Trusted database code is a candidate for reuse.
1/2002 Testing 102 -- Internal Modules 29
Testing DB Procedures -- Process
• Set-Up• Initialize DB to baseline (or error) state
• Run Test Script (manual/automated)• Run Verification Script (manual/auto)
• Verify queries, updates
• A test driver can combine the test and verification scripts into a single, comprehensive test.
1/2002 Testing 102 -- Internal Modules 30
Testing Callable Units -- SummaryA test driver is a reusable design pattern. Test drivers give code-level visibility into the behavior of units, while documenting the testing process. A unit driver can be used for indirect testing of lower level modules. The unit test driver can be extended to test complex units (classes).
1/2002 Testing 102 -- Internal Modules 31
Agenda
• Products & Deliverables
• Testing Classes
• What is Unit Testing?
• Testing Callable Modules
• Putting It All Together
1/2002 Testing 102 -- Internal Modules 32
Testing Classes -- Overview
A class is a collection of elementary units (methods) sharing an execution context. As with forms, testing a class requires unit testing of its methods along with an "integration" test of the overall semantics of the class. The approach for unit testing is extended for classes.
1/2002 Testing 102 -- Internal Modules 33
Testing Classes -- Drivers(Black-Box)
ClassTest
Driver Method Args/Results
Test setData
Test Set Results
Class
Class-state
Method(s)
1/2002 Testing 102 -- Internal Modules 34
Example -- Stack Class
class Stack{ public: Stack(); void push(int n); int pop(); int top(); bool empty(); private: int Size; int Top; int Values[100];};
Notes:
(1) Class state -- variables Size, Top and the first 'Size' values in array Values.(2) Methods push and pop modify class state; top and empty inquire about the state.(3) Stack does not require any test environment of its own.(4) Class state HIDDEN from test, i.e., black box.
1/2002 Testing 102 -- Internal Modules 35
Test Driver Files (Stack class)
Test Data File (tdi-stack.txt)File content:----- 1 8 1 7 3 7 2 7 2 8 4 true------Note: No test environment setup.Methods: 1-push, 2-pop, 3-top, 4-empty
Test Results File (trs-stack.txt)File content:-----1 1 8 2 1 73 3 7 84 2 7 85 2 8 76 4 1------Note: Results file must be inspected for pass/fails.
--- Top should be 7.
--- Push .
--- Pop, should be 8.--- Stack should be empty.
FailFailFailPass
1/2002 Testing 102 -- Internal Modules 36
Class Test Driver Design
Driver dCuses class C{ c = new (C); testcase_no = 0; open tdi_file("tdi_stack.txt"); open trs_file("trs_stack.txt"); while (more data in tdi_file) { op = read(tdi_file); switch (op) {
case 1: //Push. read(tdi_file, value); c.push(value); write(trs_file, testcase_no, 1, value); break;
case 2: //Pop. read(tdi_file, expect); value = c.pop(); write(trs_file, testcase_no, 2, expect, value); break;
1/2002 Testing 102 -- Internal Modules 37
Class Test Driver Design
… default:
} //switch
}//while
close tdi_file, trs_file;
}//class-driver
case 3: //Top. read(tdi_file, expect); value = c.top(); write(trs_file, testcase_no, 3, expect, value); break;
case 4: //Empty. read(tdi_file, expect); value = c.empty(); write(trs_file, testcase_no, 4, expect, value); break;
1/2002 Testing 102 -- Internal Modules 38
Implementing Class Test Drivers
• Interactive vs Batch (files) • Extend Unit Driver
– switch to handle multiple methods– Method-specific test cases– Method interactions tested– All results stored in common results file
• Major Benefits -- comprehensive driver– Automated, repeatable, documented– Minimized set-up
1/2002 Testing 102 -- Internal Modules 39
Class Test Driver -- Summary
• Data Driven -- flexible, extensible
• Varying levels of detail– black-box (method calls, no class state)
– clear-box (class state, advanced topic)
– global effects (test environment)
• A driver is a reusable pattern for testing.
1/2002 Testing 102 -- Internal Modules 40
Clear-Box Class Testing -- Drivers Use Internal State
External
Test Env
ClassTest
Driver Method Args/Results
Test setData
Test Set Results
Setup / InquireInternalTest Env
ClassTest Env
Class-state
Method(s)
Class StateSetup/Inquire
1/2002 Testing 102 -- Internal Modules 41
Example -- Stack Class
class Stack{ public: Stack(); void push(int n); int pop(); int top(); bool empty(); void SetState(int,int,int[]); void GetState(int &,int &,int[]); private: int Size; int Top; int Values[100];};
Notes:
(1) Class state -- variables Size, Top and the first 'Size' values in array Values.(2) Methods push and pop modify class state; top and empty inquire about the state.(3) "Hooks" can be created to set and retrieve the class state.(4) Stack does not require any test environment of its own.
1/2002 Testing 102 -- Internal Modules 42
Class Test Driver Design
Driver dCuses Test_Env T;uses class C{ // Set up external environment // c = new (C); testcase_no = 0; open tdi_file (filename); open trs_file (filename)
case -4: //Set test env// read(tdi_file. t_env); T.setenv(t_env); break;case -3: //Get test env// T.getenv(t_env); write(trs_file, t_env); break;case -2: //Set class state// read(tdi_file, c_state); c.setstate(c_state); break;
1/2002 Testing 102 -- Internal Modules 43
Class Test Driver Design
// If the internal state of the class // must be set or checked, a (-2) // precedes case "m", and a (-1) // follows case "m".
// Remaining methods … // default: } //switch }//while close tdi_file, trs_file; }//driver
case -1: //Get class state. c.getstate(c_state); write(trs_file, c_state); break;
case m: // test class method #m. read(tdi_file, args); read(tdi_file, expect); result = method(args); write (trs_file, testcase_no++, args, expect, result); break;
1/2002 Testing 102 -- Internal Modules 44
Agenda
• Products & Deliverables
• Testing Classes
• What is Unit Testing?
• Testing Callable Modules
• Putting It All Together
1/2002 Testing 102 -- Internal Modules 45
Putting It Together
• Test design is the central thing
• Test scripts define the sequence of test
actions -- a repeatable process
• Test drivers automate test scripts and
produce test documentation
• Automation is reusable!
1/2002 Testing 102 -- Internal Modules 46
CONCLUSION
Unit testing lays the foundation for software testing. The techniques covered in this class extend from simple to complex units and, as we will see, to integration testing. Worksheets and templates facilitate the process while guiding the tester through a systematic design process.
1/2002 Testing 102 -- Internal Modules 47
SOLUTIONS TO EXERCISES
1/2002 Testing 102 -- Internal Modules 48
Unit Test Driver Design -- Global Pre/Post Conditions
(pattern)Driver Duses unit_environment E;{ open testdata_file(filename); open testresults_file(filename); // Set up unit_environment E\ read (testdata_file, E_initial); E.set (E_initial );
testcase_no = 0; while (more data in testdata_file) { read(testdata_file, testdata); read(testdata_file, expected);
testresult = unit(testdata); write (testresults_file, testcase_no++, testdata, expected, testresult); }//while E.get(E_final); write(testresults_file, E_initial, E_expect, E_final) close testdata_file, testresults_file; }//driver