ECE 453/CS 447 Course Project



ECE 453/CS 447/SE 465 Course Project Part2

Version 21.10

Departments of Electrical and Computer Engineering

and Computer Science

University of Waterloo, Waterloo ON, Canada, N2L 3G1

Introduction

This document contains the description for the second part of the ECE453/CS447/SE465 project that pertains to Unit and System Testing.

In the second part of the project that will be due on Sunday, March 26, 2006, 23:59 EST,. of the course you will:

i. Provide the full implementation of the system extensions and testing framework

ii. Compile a limited test plan for your system extensions

iii. Use JUnit or CPPUnit to test parts of your code

iv. Use also the infrastructure developed in the first part of the project to perform additional the same tests on your code

The project is structured into three wo main themes: Limited Test Plan, Unit Testing, and System Testing. In the sections below, you will find details on the structure and theme of your test cases.

Test Plans

For this part of the project you should compile a limited test plan document that pertains only to the Functional aspects of the Call Forwarding (i.e. not include robustness or performance scenarios). The structure of the Test Plan Document should be as follows:

Section 1: Introduction (1 page)

Section 2: Feature Description (a table listing with feature IDs, and a its short English description for each basic feature ID in Call Forwarding) (2 pages max.)

Section 3: System Test Suite Structure

3.1 System Test Cases (the system test cases scenarios that pertain only to the functional properties of Call Forwarding (see test case scenario template in section 3.2.1 of the project description) (2 – 3 test case scenarios per page)

3.2 Traceability Matrix (rows are Test Case IDs and Columns are Feature IDs) (1 page)

3.3 Test Effort Estimation (to be discussed in class) (2 pages)

3.1.1 Test Design Effort

3.1.2 Test Execution Effort

3.1.3 Environment Set-Up Effort

3.1.4 Training Effort

3.1.5 Total Testing Effort

Unit and System Testing

The overall structure of the work-list of the project is as follows:The following outline describes the testing tasks which will be required in this project:

• Unit Testing (test cases implemented in JUnit/CPPUnit AND your testing framework)

o Functional Unit Testing

▪ Decision Table-based testing (for three methods you select)

o Structure Unit Testing

▪ Condition Path coverage (for three methods you select); show control flow graph and paths covered in each test case

• System Testing (for the five specified scenarios)

o A description for each scenario using the template provided (see section 3.2.1 in the project description).

o The units involved for each scenario.

o A high level description of the threads involved in each scenario in terms of FSMs, ASFs or high level psudocode.

o The input and expected output of each test.

o The actual outcome for each test with respect to (i) whether the expected output has been observed, and (ii) the threads involved (i.e. all expected units have been triggered, states have been reached properly, or ASFs or test case steps have been successfully applied).

1. Testing

1. Unit Testing

1. Functional Unit Testing

1. Decision Table based testing (for three methods from the system extensions or any other part of the system code)

1. Using JUnit / CPP Unit

2. Using your own framework

2. Structural Unit Testing

1. Condition Path Coverage (for three methods – can be same as in point 1.1.1.1) – Show CFG and paths covered in each test case.

1. Using JUnit

2. Using your own framework

2. System Testing (for five scenarios you will select)

1. A description for each scenario using the template provided (see section 3.2.1)

2. The Units involved for each scenario

3. A high level description of the Threads involved in each scenario in terms of FSMs or ASFs or high level psudocode.

4. The input and expected output of each test.

5. The actual outcome for each test with respect to whether (i) of the expected output has been observed and (ii) with respect to the Thread involved (i.e. all expected Units have been triggered, states have been reached properly, or ASFs, or test case steps have been successfully applied).

For Unit Testing you will select three methods of your choice from the system extensions you have implemented in the first part of the course project. If you can not find any complex enough method to test from the newly created / modified methods, you are allowed to test any other three methods from your system code.

3.1 Unit Testing: Detailed Overview

For this part of the project, you will select three methods obtained from the codein your implementation to perform unit testing using pertaining to the system extensions (Call Forwarding, Internationalization) and you will perform Unit Testing using a Functional Unit Testing tTechnique (Decision Tables), and aone Structural Unit Testing tTechnique (Condition Coverage).

The three selected methods should pertain to the system extensions (call forwarding or internationalization). If you can not find any complex enough methods with sufficient complexity to test from the newly created / modified methods, you are allowed to select o test any other otherthree methods from your previous system code. It would be a good practice to choose the same three methods for both functional and structural unit testing; advice in given in the following subsections for choosing the methods.

3.1.1 Functional Unit Testing

For Functional Unit Testing, you will use Decision Tables to come up with the test cases for the three selected methods of your choice., The methods you select for Functional Unit Testing should have significant control logic so that the Decision Tables will not be trivial. You are required to implement five (5) distinct test cases which are defined in the decision table for each method; therefore, a total of fifteen (15) test cases must be implemented for functional unit testing identified in the document.. (and documented)

and

Yyou will exercise the inferred same test cases using both :

a) The JUnit or CPP Unit (if you implementation is in C++) toolkits, and,

b) tThe testing framework you have implemented ion the first part of the project. In addition,

The methods you will chose for Functional Unit Testing have to implement significant control logic so that the Decision Tables will not be trivial. you are expected to show the complete decision tables for each method, and the input, output and outcome of the actual test cases in the test execution document.

It will be a good practice to chose the three methods to Unit Test them so that you will use the same methods for your Structural Unit Testing as well (see section 2.2). You can limit the runs to at most 5 test cases obtained from the Decision Table, for each method. You will be also expected to show in the final report for this part of the project the Decision Table and the input, output and outcome of your actual tests.

3.1.2 Structural Unit Testing

For Structural Unit Testing, you will use the Condition Coverage criterion to infer test cases. Try to avoid selecting simple or trivial methods to test. You can check this by evaluating the Cyclomatic Complexity of the method you are testing. Avoid though selecting any method for this project testing with Cyclomatic Complexity lower than 34 and higher than 6. You are required to identify all test cases implement all of the test cases which are inferred by the criterion for each method but implement and run only 5 of these test cases. ; Ttherefore, the total number of test cases required is 15 (5 for each method).is implementation dependent. (how many test cases???)

You will exercise the inferred test cases using both a) JUnit or CPPUnit toolkits, and b) the testing framework you implemented in the first part of the project. In addition,

For this part of Unit Testing you will exercise the same test cases using both:

a) The JUnit or CPP Unit (if you implementation is in C++) toolkits and,

b) The testing framework you have implemented on the first part of the project

yYou will are expected to show, for each selected method, in the final report for this part of the project the Control Flow Graph of your method, , the Statements and Paths exercised by each test case selected, and the input, output and outcome of your the actual tests in the test execution document..

3.2 System Testing: Detailed Overview

For this part of the project you will perform system testing for the following five scenarios:

1) Try setting call forwarding in a phone that has already call forwarding activatedActivate call forward

2) Try setting call forwarding towards an inactive numberDeactivate call forward

3) When B has set call forwarding to C and A calls B, verify the correct billing Timeout

4) Administrator revokes receive privileges of the forwardee Billing forwarding correctly

5) Exercise the correct operation of double forwarding B forwards to C and C forwards to D, and A calls B.Forwarding is cancelled when change occurs to the privilege …

For each scenario, you are expected to show:

select five usage scenarios from your working system and you will perform system testing. For this par of the project you are expected to show:

a) A description for each the scenario using the template provided belowin section 3.2.1 of the project description.

b) The uUnits involved for each scenario.

c) A high level description of the tThreads involved in each scenario in terms of FSMs, or ASFs or high level psudocode.

d) The input and expected output of each test.

e) The actual outcome for each test with respect to whether (i) whetherof the expected output has been observed and (ii) wetherith respect tto the tThreads involved are traversed according to the specification (i.e. all expected uUnits have been triggered, states have been reached properly, or ASFs, or test case steps have been successfully applied). The method or formalism (FSM, ASF Graph etc.) that you will use to show or discuss points e(i) and e(ii) is up to you.

For the purpose of this project, you are required to implement one system test per scenario, although in general, the mapping between a scenario and a test case is one-to-many.

3.2.1 Scenario Template

The A scenarios should be specified as follows: using the following template:

|TEST CASE ID#: |Test Case Title: |

|Creator: | |

|Test Category: | : Basic Tests, Functionality Tests, Robustness Tests, Stress |

| |Tests, Performance Tests, Load and Stability Tests |

|Requirement ID: | |

|Test Objective: | |

|Assumptions: | |

|Initial Conditions: | |

|Post Conditions: ||

|Test Steps: | |

|Clean Up: | |

|Pass/Fail Criteria: | |

|Automation: | |

|Test Priority: | |

3.2 Test Execution Document

The structure of the Test Execution Document should be as follows:

Section 1: Introduction (1 page)

Section 2: Unit Testing (12x pages)

1. Functional Unit Testing (2 x pages max per method …)

o Decision tables for each selected method

o Definition of five test cases for each selected method (subset of the test cases inferred by decision table)

o Input, output, and actual outcome of each test case

2. Structure Unit Testing (2x pages max per method …)

o Control flow graphs for each selected method

o Indication of the statements and paths exercised by each test case

o Input, output, and actual outcome of each test case

Section 3: System Testing (15 pages)

5. (one subsection per specified scenario, 3y pages max per scenario)

o description of the scenario (as per template)

o describe the units involved

o high level desription of the threads involved in terms of FSMs, ASFs, or high level pseudocode

o input and expected output of each test

o actual outcome of each test (see point e in section 3.2)

Deliverables

For this part of the project you will need to providesubmit:

1. Test Plan for Call Forwarding Extension Document (defined in section 2 of the project description)

2. Test Execution Document (defined in section 3 of the project description)

3. An archive file containing the full system implementation with system extensions, testing framework and defined test cases

1. A Short Test Plan Document (see structure in Section 2.0)

2. A Test Execution Document (see structure in Section 3.0)

2.1. Unit Testing.

2.1.1 Functional Testing (use JUnit/CPP Unit and your own Test Framework)

You will run at most 5 test cases obtained from the Decision Table, for each

method. You will be also expected to show in the final report for this part of the

project the Decision Table and the input, output and outcome of your actual

tests

2.1.2 Structural Testing (use JUnit/CPPUnit and your own Test Framework)

You will expected to show in the final report for this part of the project the

Control Flow Graph of your method, the Statements and Paths exercised by

each test case selected, and the input output and outcome of your actual tests.

2.2. System Testing (use JUnit/CPPUnit or just manual entries according to your

system test scenarios) Five usage scenarios from your working system and you

will perform system testing.

For this par of the project you are expected to show:

• A description for each scenario using the template provided below

• The Units involved for each scenario

• A high level description of the Threads involved in each scenario in terms of FSMs or ASFs or high level psudocode.

• The input and expected output of each test.

• The outcome for each test with respect to whether (i) of the expected output has been observed and (ii) with respect to the Thread involved (i.e. all expected Units have been triggered, states have been reached properly, or ASFs, or test case steps have been successfully applied).

3. The archive file of your full system implementation

4.

You can sSubmit an archive file with the above documentsdeliverables in the to CourseBook, by 23:59 Sunday March 26, 2006.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download