TVAC Electronic Call Sheet System

Team HeatWave

Summer 2007

The Paper Call Sheet

Front Back

Advantages Electronic data can be made more secure than

paper storage with backup systems and redundancy on geographically dispersed servers

Electronic call sheets can be searched instantly Data can be shared more quickly and easily with

other emergency services and municipal organizations

Enables data mining for statistics that can be used to improve procedures and detect patterns

System Architecture 3-tier architecture Built on latest Java EE

framework (EE 5, EJB 3.0, JPA)

All server functionality exposed via Web Service

Built entirely with open-source components

DB

Internet

Client

EJB Containter

Web Containter

App S

erver

mySQL

WSB | EJB

Servlet

System Capabilities (Release 1)

Create call sheet Search call sheets View call sheet details Edit call sheet Delete call sheet

Walk-thru: Call Sheet Creation

Tom’s Restaurant

Walk-thru: Call Sheet Creation

Call sheet created successfully. (id=54234)

54234

Walk-thru: Call Sheet Search

Corner of Deli New York

Search selection

Search results stored in JTable

View detail(driven by

search selection)

Walk-thru: Call Sheet Search

Critical code paths: GUI CallSheetSearchUI : Covers 80% of use cases

Procedures followed Blackbox testing

Boundary value analysis Whitebox testing

Statement coverage Branch coverage Control flow path coverage Data flow path coverage

Critical code paths: GUI (cont) Results obtained

Search by Call Sheet ID, location, town, date range Boundary value errors

View call sheet detail based on JTable selection of search results

Statement, control and data flow path errors Edit a call sheet

Control and data flow path errors Delete call sheets

No errors

Critical code paths: Controller Requests from the client module are intercepted by the

servlet and forward to the processRequest method in CallSheetServlet.java

This method draws all the subsystems together and performs the following tasks: Reads the client’s XML request Converts the request to a call sheet object Invokes the appropriate database method Returns the request result to the client

The centrality of this method and the abundance of custom code make this the most critical method of the Controller.

Critical code paths: Data Store Managed persistence and connections eliminated most

of the data store “plumbing” CallSheetFacade.java (stateless EJB) contains

most of the custom logic findBySearchCriteria() method involves building

an EJB-QL query from our custom SearchCriteria object

Custom code, EJB-QL syntax, and direct coupling with the Controller make CallSheetFacade the most critical section of code in the data store

Code inspection: GUI Line by line review of the critical section Q & A format 17 Issues documented and prioritized in issue tracker:

Code inspection: Controller CallSheetServlet

Procedures followed Formal code review

Results obtained Edit and delete functionality not implemented Missing comments Missing / incorrect Java Doc Dead code

Code inspection: DataStore Line by line review of the critical section, CallSheetFacade.java

Issues discovered Dead code Missing error handling Missing comments

Testing: Statement Adequacy Coverage Coverage testing was done to ensure that each

line of code in the critical paths was run at least once.

Due to the reduction in code size brought about by Java EE 5 and the familiarity with the code brought about by the code reviews, coverage tests were designed to reach each line and were verified with a visual debugger.

Unit, integration, and acceptance tests exercised the paths more rigorously by testing a variety of paths through the critical code

Testing: GUI (CallSheetSearchUI.java)

Code for UI construction and layout does not branch Normal testing covers the straight-line code (lines 1-131,

methods CallSheetSearchUI(), draw(), createSection1(), createSection2(), and createSection3()

Updating functions require specific actions and data to achieve full code coverage (presented in the next two slides)

In the following test cases, expected results are that the application reports problems when the action cannot be performed and otherwise completes the operation successfully.

In addition to the following actions and data, perform one test case where you resize the search screen (lines 337-343).

Testing: GUI (actions)Search Delete Update

Perform search action with no call sheets in the database

Perform delete action with no call sheets in the database

Perform update to create a new call sheet (no call sheet number specified)

Perform search with representative test data loaded but with no matching results

Perform delete with representative data loaded but specified call sheet does not exist

Perform update action where the new call sheet data is invalid (e.g. bogus date info)

Perform search with representative test data and search criteria returns matching results

Perform delete with representative data and delete is successful

Perform update to modify an existing call sheet (with call sheet number specified)

Results in 27 test cases using 3 sets of data for each of the 9 boxes. Using these27 tests, all lines of code are executed.

Testing: GUI (data)

Location Date Coverage (lines)

= null <> null 149-150

<> null = null 102

<> null <> null Normal case, covers most code

When creating a representative set of data. Be sure that you have at least three records with the following fields set as indicated. This data will ensure that the specified lines of code are covered.

Testing: GUI (data)

Test type Lines not executed

Search/Delete with no data 144-153

Update with invalid data 232-244

We ensured that all code is covered by tests as indicated in the charts above. However, to gain full confidence in the code it was necessary to cover some of the same lines of code but by following different code paths to get there. Tests described here were designed to skip lines of code to see the impact when those lines are not executed.

Testing: Controller Procedures followed

Create call sheet Search for call sheets View call sheet detail Edit a call sheet Delete call sheets

Testing: Controller (cont) Results obtained

Create call sheet<CallSheetList>

<CallSheet>

<Action>SAVE</Action>

<Status>SUCCESS</Status>

….

….

</CallSheet>

</CallSheetList>

Search for call sheets<CallSheetList>

<CallSheet>

<Action>SEARCH</Action>

<Status>SUCCESS</Status>

<CallSheet_Date>1186891200000</CallSheet_Date>

<Location>116 Broadway</Location>

<Patient_Info><Town>New York</Town></Patient_Info>

</CallSheet>

</CallSheetList>

View call sheet detail <CallSheetList>

<CallSheet>

…

</CallSheet>

<CallSheet>

…

</CallSheet>

…

</CallSheetList>

Edit a call sheet<CallSheetList>

<CallSheet><Action>SAVE</Action><Status>SUCCESS</Status><CallSheet_Number>2</CallSheet_Number>…………</CallSheet>

</CallSheetList>

Delete call sheets<CallSheetList>

<CallSheet><Action>DELETE</Action><Status>SUCCESS</Status><CallSheet_Number>1</

CallSheet_Number></CallSheet>

</CallSheetList>

Testing: Data Store (CallSheetFacade.java)

Class under test is very limited in code size due to implementation of EJB.

Due to limited code size, coverage testing was accomplished by using debugger and manually tracking the covered lines.

Developed small test classes to invoke methods in CallSheetFacade.java. Was able to accomplish both black box and white box testing with these acceptance and unit tests.