Integration Test Plan - College of Computing & Informaticsdpn52/Therawii/itp.pdfIntegration Test Plan TheraWii implementation to arti cially construct data structures on both sides

Integration Test Plan

TheraWii

Tim ChagnonJoe Kokinda

Andrew MeinertDon Naegely

April 8, 2009Revision 5

Integration Test Plan Revisions

Date Description Revision Editor2/8/2009 Created the document 0 Tim Chagnon2/9/2009 Added DS-DM Test Cases 1 Joe Kokinda2/10/2009 Added GI Test Cases 2 Don Naegely2/10/2009 Added TI-DS Test Cases 3 Joe Kokinda2/10/2009 Added TI-DS Test Cases 4 Andrew Meinert2/10/2009 Added Wiiuse Test Cases 5 Tim Chagnon

i

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Definitions and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3.1 Physical Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.2 Nintendo Wii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Test Approach and Constraints 12.1 Test Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Test Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Test Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Test Assumptions and Exclusions 33.1 Test Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.2 Test Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4 Entry and Exit Criteria 34.1 Entry Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44.2 Exit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

5 Testing Participants 45.1 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45.2 Training Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45.3 Problem Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45.4 Progress Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

6 Test Cases 56.1 Therapist Interface - Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

6.1.1 New Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56.1.2 Delete Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56.1.3 Edit Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66.1.4 Import Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66.1.5 Export Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76.1.6 New Task - Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76.1.7 New Task - 2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86.1.8 New Task - Repeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86.1.9 Delete Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96.1.10 Move Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96.1.11 New Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.1.12 Edit Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.1.13 Delete Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116.1.14 Import Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116.1.15 Export Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.1.16 Delete Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.1.17 View Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.1.18 Export Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.2 Therapist Interface - Input Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.2.1 Input Device Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.3 Therapist Interface - Game Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ii

Integration Test Plan TheraWii

6.3.1 Start Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.3.2 End Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6.4 Game Interface - Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156.4.1 Read Model Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156.4.2 Write Game Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.5 Game Interface - Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.5.1 Create data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.6 Game Interface - Input Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.6.1 Read input device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.6.2 Disconnected Input Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.7 Data Model - Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.7.1 Test Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.7.2 Test Writing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.8 Input Devices - Wiiuse C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.8.1 Wii Remote State Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.8.2 Wii Balance Board State Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.8.3 Wii Nunchuck State Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.8.4 Wii IR State Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

April 8, 2009 iii


1 Introduction

1.1 Background

This document provides the process for completing the integration test of the TheraWii software system.The process was influenced by the Software Design Document (see §1.2) which governed the design andimplementation of the system.

1.2 References

• TheraWii SDD—The following URL provides a link to the most recent version: https://baloo.cs.drexel.edu/trac/therawii/export/HEAD/doc/design/design.pdf

1.3 Definitions and Acronyms

1.3.1 Physical Therapy

Posture The orientation of any body segment relative to the gravitational vector. It is an angular measurefrom the vertical.

Balance The dynamics of body posture that prevents falling. It is related to the inertial forces acting onthe body and the inertial characteristics of body segments.

Center of Mass (COM) A specific point at which the system’s mass behaves as if it were concentrated.

Center of Pressure (COP) The point location of the vertical ground reaction force vector. It representsa weighted average of all the pressures over the surface of the area that is in contact with the ground.It is also called the Center of Balance (COB).

1.3.2 Nintendo Wii

Wii Remote Device that communicates through Bluetooth wireless protocol to the Nintendo Wii Gam-ing System. Data communicated includes button press and releases, accelerometer readings, and aninfrared (IR) LED pointing system.

Wii Balance Board Device that communicates the COP through Bluetooth wireless protocol to the Nin-tendo Wii Gaming System.

1.3.3 Software

Therapy A series of tasks that is completed in one session.

Session A given time in which a user completes a Therapy.

Task A subunit of a Therapy that has an objective with success and fail criteria.

Test Case A single, atomic test made up of preconditions that must be satisfied, actions that will becompleted by the tester, and postconditions that specify the expected behavior.

2 Test Approach and Constraints

This section shall describe the objectives, structure, and constraints for the acceptance test plan of theTherawii software.

April 8, 2009 1

https://baloo.cs.drexel.edu/trac/therawii/export/HEAD/doc/design/design.pdf

https://baloo.cs.drexel.edu/trac/therawii/export/HEAD/doc/design/design.pdf


2.1 Test Objectives

The main objective of the Acceptance Test Plan is to verify that the individual design components of theTherawii software work together as they were designed to.

2.2 Test Structure

The Integration Test Plan shall contain test cases that verify interoperability of design architecture compo-nents specified in section 2.3 ”System Architecture” of the TheraWii Design Document. Figure 1 depictsthis high-level system architecture.

Figure 1: TheraWii Architecture

The test cases shall provide automatically testable scenarios that focus on a single type of interactionbetween two design components. Table 1 lists the interactions between architecture components and whichsection they are covered in.

Table 1: Component Interaction ReferenceComponent Interacting Component Test CaseTherapist Interface Data Model §6.1Therapist Interface Input Devices §6.2Therapist Interface Game Interface §6.3Game Interface Data Storage §6.4Game Interface Data Model §6.5Game Interace Input Devices §6.6Data Model Data Storage §6.7Input Devices Wiiuse C §6.8

Each scenario shall consist of a precondition, an action, a postcondition for the scenario. The precondi-tion shall describe the state of the software before the tested action occurs. This may require the test case

April 8, 2009 2


implementation to artificially construct data structures on both sides of the interface. The action defineshow the integration test will be triggered by running a method from one of the two components. The post-condition is the desired state of the software after the tested action. This is what should be tested in thetest case implementation to determine success or failure.

To automate integration testing, each test case must

• be self contained with appropriate setup and tear-down mechanisms,

• be runnable from a script or test suite,

• not require any user interaction while running,

• and provide a single pass or fail result.

2.3 Test Constraints

The Acceptance Test Plan will be limited to testing the integration of components of the software as de-fined in the TheraWii Design Document. It will not test the requirements or implementation of individualcomponents of the TheraWii source code.

3 Test Assumptions and Exclusions

This section provides greater details about which components of TheraWii will be covered by the IntegrationTest Plan process, and which functions of TheraWii will not be covered.

3.1 Test Assumptions

It is assumed that all issues covered by the Integration Test Plan were also previously addressed by unittests within individual components, system tests of TheraWii. The Integration Test plan will cover

• interoperability of components listed in the Software Design Document,

• interaction with system components that DO NOT require user interaction.

3.2 Test Exclusions

It is assumed that all issues not covered by the Integration Test Plan were previously addressed by unittests, and system tests. The Integration Test Plan will not cover

• external components requiring user interaction,

• structural integrity of the source code.

4 Entry and Exit Criteria

This section lists the criteria which must be satisfied in order for the Acceptance Test Plan to begin, as wellas the criteria which must be satisfied in order for the Acceptance Test Plan to stop.

April 8, 2009 3


4.1 Entry Criteria

The Acceptance Test can begin after the following conditions have been met.

• All other unit tests, system tests and integration tests are complete.

• A proper environment that meets Software r4.6.1 and Hardware r4.6.2 constraints outlined in the SRSis available.

• A copy of the latest version of the SRS has been received.

• The latest version of TheraWii has been compiled and installed.

• Consent from the Team Leader.

• Consent from the Client Representative.

4.2 Exit Criteria

The Acceptance Test Plan should be halted after either of the following:

• All Priority 1 requirements were tested without deviation from expected behvior (Success).

• At least one Priority 1 requirement deviated from the documented specification (Failure).

5 Testing Participants

This section describes the roles and responsibilities of the parties involved in the Acceptance Test Plan, aswell as the procedure for reporting the test results.

5.1 Roles and Responsibilities

• Test team leader: Tim Chagnon

• Client representative: Carole Tucker

• Testers: Joe Kokinda, Andrew Meinert, Don Naegely

5.2 Training Requirements

All parties involved in the Acceptance Test Plan should be comfortable with standard Windows applicationinterfaces. All parties should be familiar with the user interface of TheraWii, as well as with the systemdocumentation and the Software Requirements Specification.

5.3 Problem Reporting

Any problem discovered by either the Client Representative or a Tester must be documented and reportedto the Test Team Leader. The problem report will be submitted to the Team Leader and addressed duringa periodic or special meeting depending on the severity of the problem.

5.4 Progress Reporting

The Acceptance Test Plan Report will be compiled after the testing process has been completed by the TestTeam Leader and submitted to the Team Leader.

April 8, 2009 4

https://baloo.cs.drexel.edu/trac/therawii/export/HEAD/doc/req_doc/srs.pdf

https://baloo.cs.drexel.edu/trac/therawii/export/HEAD/doc/req_doc/srs.pdf


6 Test Cases

6.1 Therapist Interface - Data Model

6.1.1 New Therapy

ID TC 1Name New TherapyDescription Simulate New Therapy DialoguePrecondition(s)

• Construct New Therapy dialog data structures.

• Manipulate New Therapy dialog data to simulate user input of Name.

Action(s)

1. Run event handler method to simulate user clicking on ”Ok” button.

Postcondition(s)

• Therapy object was constructed.

• Therapy object has requested name.

• Therapy object contains no tasks.

6.1.2 Delete Therapy

ID TC 2Name Delete TherapyDescription Simulate Deletion of a TherapyPrecondition(s)

• Data Model list of therapies contains at least one therapy.

Action(s)

1. Simulate user selection of first Therapy.

2. Simulate user clicking delete therapy.

Postcondition(s)

• Therapy object was deleted.

• Therapy object was removed from list.

April 8, 2009 5


6.1.3 Edit Therapy

ID TC 3Name Edit TherapyDescription Simulate Edit to a TherapyPrecondition(s)

• Data Model list of therapies contains at least one therapy.

Action(s)

1. Simulate user selection of first Therapy.

2. Simulate user clicking edit therapy.

3. Simulate a change to therapy properties.

Postcondition(s)

• Therapy object was updated with new data.

6.1.4 Import Therapy

ID TC 4Name Import TherapyDescription Simulate Importing a TherapyPrecondition(s)

• Valid Therapy stored on disk.

Action(s)

1. Run event handler method to simulate user clicking on File–¿Import Ther-apy and selecting stored therapy.

Postcondition(s)

• Therapy object has been added to Therapies list.

April 8, 2009 6


6.1.5 Export Therapy

ID TC 5Name Export TherapyDescription Simulate Exporting a TherapyPrecondition(s)

• Valid therapy stored in therapies list.

Action(s)

1. Run event handler method to simulate user clicking on File–¿Export Ther-apy and selecting a valid therapy.

2. Simulate user providing a location to export therapy.

Postcondition(s)

• Therapy has been exported to specified location.

6.1.6 New Task - Dialog

ID TC 6Name New Task - DialogDescription Create a New Dialog Task within a TherapyPrecondition(s)

• Construct valid Therapy.

Action(s)

1. Run event handler method to simulate user clicking on New Task buttonon the Workflow Editor Tab.

2. Run event handler method to simulate user selecting a new dialog task.

3. Modify Dialog data to simulate user input.

Postcondition(s)

• Task object created with specified data.

• Task objected added to workflow.

April 8, 2009 7


6.1.7 New Task - 2D

ID TC 7Name New Task - 2DDescription Create a New Static Task within a TherapyPrecondition(s)

• Construct valid Therapy.

Action(s)


2. Run event handler method to simulate user selecting a new 2D task.


Postcondition(s)



6.1.8 New Task - Repeat

ID TC 8Name New Task - RepeatDescription Create a New Repeat Task within a TherapyPrecondition(s)

• Construct valid Therapy with tasks to repeat.

Action(s)


2. Run event handler method to simulate user selecting a new repeat task.


Postcondition(s)



April 8, 2009 8


6.1.9 Delete Task

ID TC 9Name Delete TaskDescription Delete a Task within a TherapyPrecondition(s)

• Construct valid Therapy with tasks.

Action(s)

1. Run event handler method to simulate user selecting a task from Tasksin Workflow List.

2. Run event handler method to simulate user clicking on Delete Task buttonon the Workflow Editor Tab.

Postcondition(s)

• Task object deleted.

• Task removed from Tasks in Workflow List.

6.1.10 Move Task

ID TC 10Name Move TaskDescription Move Task position within a given TherapyPrecondition(s)

• Construct valid Therapy with multiple tasks.

• Set Focus on first task within Therapy.

Action(s)

1. Run event handler method to simulate user clicking on ”Down” buttonon the Workflow Editor Tab.

Postcondition(s)

• Selected Task has moved one position Down.

• The Task below the selected Task has moved one position up.

• No other Tasks have changed position.

April 8, 2009 9


6.1.11 New Profile

ID TC 11Name New ProfileDescription Simulate New Profile DialoguePrecondition(s)

• Construct new Profile dialog data structures.

• Manipulate new Profile dialog data to simulate user input of name.

Action(s)

1. Run event handler method to simulate user clicking on ”OK” button inAdd Dialogue.

Postcondition(s)

• Profile object was constructed.

• Profile object has requested name.

• Profile object has no sessions associated with it.

6.1.12 Edit Profile

ID TC 12Name Edit ProfileDescription Simulate Edit Profile DialoguePrecondition(s)

• Construct valid Profile object.

• Construct edit Profile dialog data structures.

Action(s)

1. Run event handler method to simulate user clicking on ”OK” button inEdit Dialogue.

Postcondition(s)

• Profile object has name of new Profile dialog data structure.

• Existing Session details remain unchanged.

April 8, 2009 10


6.1.13 Delete Profile

ID TC 13Name Delete ProfileDescription Simulate Delete Profile DialoguePrecondition(s)

• Construct valid Profile object.

Action(s)

1. Run event handler method to simulate user clicking on ”Yes” button inDelete Dialogue.

Postcondition(s)

• Profile object has been removed from data structure.

• Existing Session details have been removed from data structure associatedwith the given Profile.

6.1.14 Import Profile

ID TC 14Name Import ProfileDescription Simulate Importing a ProfilePrecondition(s)

• Valid profile stored on disk.

Action(s)

1. Run event handler method to simulate user clicking on File–¿Import Pro-file and selecting stored profile.

Postcondition(s)

• Profile object has been added to profiles list.

April 8, 2009 11


6.1.15 Export Profile

ID TC 15Name Export ProfileDescription Simulate Exporting a ProfilePrecondition(s)

• Valid profile stored in profiles list.

Action(s)

1. Run event handler method to simulate user clicking on File–¿Export Pro-file and selecting a valid profile.

2. Simulate user providing a location to export profile.

Postcondition(s)

• Profile has been exported to specified location.

6.1.16 Delete Session

ID TC 16Name Delete SessionDescription Simulate Deletion of Session DataPrecondition(s)

• Profile list of sessions contains at least one session.

Action(s)

1. Simulate user selection of first session.

2. Simulate user clicking delete session.

Postcondition(s)

• Session object was deleted.

• Session object was removed from list.

April 8, 2009 12


6.1.17 View Session

ID TC 17Name View SessionDescription Simulate Viewing Session DataPrecondition(s)


Action(s)

1. Simulate user selection of first session.

2. Simulate user clicking view session.

Postcondition(s)

• Session detail window opens with session data displayed.

6.1.18 Export Session

ID TC 18Name Export SessionDescription Simulate Exporting Session DataPrecondition(s)


Action(s)

1. Run event handler method to simulate user selecting a session from Ses-sions in Profile list.

2. Simulate user clicking export session.

3. Simulate user providing a location and format to export session data.

Postcondition(s)

• Session data has been exported to specified location in desired format.

April 8, 2009 13


6.2 Therapist Interface - Input Devices

6.2.1 Input Device Scan

ID TC 19Name Input Device ScanDescription Scan for input devices and return list of discovered devicesPrecondition(s)

• Power on input devices.

Action(s)

1. Execute scan for devices.

2. Press sync button on each input device.

Postcondition(s)

• Therapist Interface is returned a list of discovered devices

6.3 Therapist Interface - Game Interface

6.3.1 Start Game

ID TC 20Name Start GameDescription The user starts a gamePrecondition(s)

• The user has selected a workflow.

• The workflow has at least one task associated with it.

• At least one profile exists in the system.

Action(s)

1. Simulate clicking of “Play” button.

2. Simulate selection of a profile.

3. Similuate clicking “OK” button on “Choose Profile...” window.

Postcondition(s)

• Game constructed which includes the profile, workflow, and tasks as cho-sen during setup.

• Game window created and is full screen.

April 8, 2009 14


6.3.2 End Game

ID TC 21Name End GameDescription The user completes or quits a gamePrecondition(s)

• The user is currently in full screen game mode.

Action(s) Either of:

1. Simulate end game conditions which resembles user completing the game.

2. Simulate exit button click and confirm exit button click to quit the game.

Postcondition(s)

• Game object should handle exit conditions and save required data.

• Game window should be destroyed.

• User should be returned to Therapist Interface which is in the same stateas when they entered the game.

6.4 Game Interface - Data Storage

6.4.1 Read Model Data

ID TC 22Name Read Model DataDescription Reads data from disk given valid model(s)Precondition(s)

• The game is created with a profile, workflow, and associated tasks.

• The workflow has task data on the disk in valid XML format.

Action(s)

1. The task XML file(s) are gathered from the model.

2. Each task is parsed from the file and added to the Game object.

3. The Game object is executed when all tasks have been created.

Postcondition(s)

• The tasks in the Game object accurately reflect the tasks in the Workflowsdata file.

April 8, 2009 15


6.4.2 Write Game Data

ID TC 23Name Write Game DataDescription Writes the results of a game as the user playsPrecondition(s)

• A game has been started from the Therapist Interface.

• At least one input device is connected and used in the game.

• A valid Game object has been created.

Action(s)

1. Data is obtained from the input device(s).

2. The game writes this data to a results file.

Postcondition(s)

• The data in the file includes fields of interest gathered in the game.

• The data in the file appears at the same sample rate it was read in thegame.

6.5 Game Interface - Data Model

6.5.1 Create data model

ID TC 24Name Create data modelDescription Creates a Game data model based on input from file and Therapist InterfacePrecondition(s)

• A new game is started via the “Play” button on the therapist interface.

• The game receives the workflow to execute and profile to execute under.

Action(s)

1. The game accesses the list of tasks for the workflow.

2. The game reads task parameters for each task.

3. A new game task is created by interpreting the task parameters. This isadded to the list of GameTasks.

4. The game adds the profile and workflow to the game model.

Postcondition(s)

• The game model contains profile and workflow matching those it wasstarted with.

• The GameTasks accurately reflect the parameters contained in each taskin the workflow.

April 8, 2009 16


6.6 Game Interface - Input Devices

6.6.1 Read input device

ID TC 25Name Read input deviceDescription The game reads data from an input devicePrecondition(s)

• A new game has been started and the model has been created.

• At least one device has been added and is currently connected.

Action(s)

1. The game polls the sample device with frequency f(Hz).

2. The device state is returned in the poll.

3. The state data is gathered by the game and fields of interest are recorded.

4. Game waits until game is completed or next poll time arrives.

Postcondition(s)

• The game obtains the device state for all devices used in current task.

• The game reads and interprets all values correctly.

• The game only rights the fields of interesting, ignoring other data.

• The game samples the control with at least frequency f(Hz).

April 8, 2009 17


6.6.2 Disconnected Input Device

ID TC 26Name Disconnected Input DeviceDescription One or more input devices is disconnected during a game.Precondition(s)

• A new game has been started and the model has been created.

• At least one device has been added and is currently connected.

Action(s)

1. The game polls the sample device with frequency f(Hz).

2. The device state is returned in the poll.

3. The state data is read and the isConnected field is false.

Postcondition(s)

• The game pauses and saves all game state data.

• The game presents the user with a dialog to reconnect the device.

• If device is reconnected, the game proceeds from last state otherwise thegame exits.

6.7 Data Model - Data Storage

6.7.1 Test Reading

ID TC 27Name Test ReadingDescription Interaction from Data Storage to Data ModelPrecondition(s)

• Place a valid XML file on disk.

• Place a valid CSV file on disk.

Action(s)

1. Call DSxml read function to read the given XML file.

2. Call DScsv read function to read the given CSV file.

Postcondition(s)

• Therapy and Profile entities have been created.

• Therapy and Profile entities match entities from XML file.

• Profiles have sessions associated with them as defined in the CSV file.

April 8, 2009 18


6.7.2 Test Writing

ID TC 28Name Test WritingDescription Interaction from Data Model to Data StoragePrecondition(s)

• Create valid Profile.

• Create valid Therapy.

• Create valid Session.

Action(s)

1. Call DSxml write function to write the Profile and Therapy informationto the given XML file.

2. Call DScsv write function to write the Session information to the givenCSV file.

Postcondition(s)

• Therapy and Profile entities have been written to CSV and XML files.

• CSV and XML files match entities from the Data Model.

6.8 Input Devices - Wiiuse C

6.8.1 Wii Remote State Updates

ID TC 29Name Wii Remote State UpdatesDescription Check for propagation of input device states to C#Precondition(s)

• Modify C wiimote structs to add simulated input data

• Set event status as updated

Action(s)

1. Call Remote.getState() function

Postcondition(s)

• Check that simulated data is represented in RemoteState

April 8, 2009 19


6.8.2 Wii Balance Board State Updates

ID TC 30Name Wii Balance Board State UpdatesDescription Check for propagation of input device states to C#Precondition(s)



Action(s)

1. Call BalanceBoard.getState() function

Postcondition(s)

• Check that simulated data is represented in BalanceBoardState

6.8.3 Wii Nunchuck State Updates

ID TC 31Name Wii Nunchuck State UpdatesDescription Check for propagation of input device states to C#Precondition(s)



Action(s)

1. Call Nunchuck.getState() function

Postcondition(s)

• Check that simulated data is represented in NunchuckState

April 8, 2009 20


6.8.4 Wii IR State Updates

ID TC 32Name Wii IR State UpdatesDescription Check for propagation of input device states to C#Precondition(s)



Action(s)

1. Call IR.getState() function

Postcondition(s)

• Check that simulated data is represented in IRState

April 8, 2009 21

Documents

Integration Test Plan - College of Computing & Informaticsdpn52/Therawii/itp.pdfIntegration Test Plan TheraWii implementation to arti cially construct data structures on both sides