Running Head: Troy M. Connor Lab 3
1
CS411W Lab III
Lab 2 – Prototype Plan Procedure Outline
For
READ
Prepared by: Troy M. Connor
07/26/2016
Running Head: Troy M. Connor Lab 3
2
TABLE OF CONTENTS
1.
OBJECTIVE
3
2.
REFERENCES
4
3.
Test Plan
4
3.1 Testing Approach
4
3.2 Identification of Tests
5
3.3 Test Schedule
10
3.4 Fault Recording and Data Recording
12
3.5 Resource Requirements
13
3.6 Test Environment
13
4
13
Test Procedures
4.1 Test Case Names and Identifiers
13
5.
13
Traceability to Requirements
TABLE 1 SUMMARY OF TESTS............................................................................................. 5
TABLE 2 PROTOTYPE DEMONSTRATION SCHEDULE ................................................ 10
TABLE 3 FAULT REPORTING AND DATA RECORDING TABLE ................................ 12
Running Head: Troy M. Connor Lab 3
3
1. Objectives
The objective for the prototype is to demonstrate the test plan for the Repository for
Electronic Aggregation of Documents (READ) system.
The test plan will ensure the
requirements and goals (Lab II) are met. The prototype will act as the functional system
delivered to the end user.
READ will serve the Old Dominion University Computer Science Department as a tool
to house a listing of publications and grant information. The current faculty members, who have
penned publications and have received grants, will have that listed with the READ system. This
list will allow anyone who is connected to the Internet and is interested in Old Dominion’s
Computer Science department, find information of their interest.
READ will allow authors to maintain their own profile. With their profile the authors can
edit publications and edit grant information.
They can maintain their own profile with
information they want to be seen. Information like degree, position and email address will be
displayed in the author’s profile. This information will be displayed on the author’s profile page
and will show users the information. With this being done, it will allow the READ system to
efficiently display publication and grant information to all who are interested.
(This section intentionally left blank.)
Running Head: Troy M. Connor Lab 3
2.
4
References
“Delta Cost Project Data.” The Delta project on Postsecondary Education Cost, Productivity,
and Accounatablilty. The Delta project n.d. Web 9 Feb 2013
Connor, Troy. (2013). Lab II – Prototype Product Specification for READ. Norfolk, VA:
Author
Connor, Troy. (2013). Lab I– Prototype Product Specification for READ. Norfolk, VA:
Author
3.
Test Plan
The test plan will show the overall approach that will be implemented. This will include
all the testing to check for system issues including but not limited to: User Interface, bibtex
parser, web scraper, and database infrastructure. These tests will cover all the functional
requirements and meet the goals of the prototype.
3.1 Testing Approach
The test implemented will cover the requirements and the goals of this prototype. These tests will
check the different algorithms used to make the READ system work properly. The integration testing
will test whether the user interface works with the database. It will also test whether the scraper works
with well with the bibtex parser. These components being a critical portion of the READ system are very
important to have working. The unit testing will provide limits that the software can handle. The
testing will test the functionality provided by READ from a user’s standpoint. This will ensure
that the prototype delivered will be functional to all users.
Running Head: Troy M. Connor Lab 3
5
3.2 Identification of Tests
The group has created a list with test that must pass. These tests will provide a functional
prototype when all tests have passed. Section 5.1 will show the test cases in detail. Table 1 is a
summary of the tests.
Table 1 Summary of Tests
Category ID
Description
Test Case
1.1.1
1.2.1
1.3.1
1
User Interface
1.4.1
1.5.1
1.5.2
Description
Objective
Used to
browse
through all
publications in
the system
Used to
browse
through all
grants in the
system
First page
seen by any
visitors to the
system
This page will
let a user have
access to the
system
Lists
information
on the specific
user which is
logged in
Lists
information
on the specific
user which is
logged in
To allow for
publications to be
searched on the
webpage.
To allow grants to be
searched on the
webpage.
Allow for simple
navigation of the
READ system.
Allow a user to
authenticate their
identity on the
system.
Allow users to have
access to the
publications and
grants which they
have ownership of.
Allow users to have
access to their
personal information.
Running Head: Troy M. Connor Lab 3
6
1.5.3
Lists
information
on the specific
user which is
logged in
1.6.1
Interface for
adding new
publications
1.6.1
Interface for
adding new
publications
1.7.1
1.8.1
1.9.1
1.9.2
1.9.3
1.10.1
Interface for
adding new
grants
A page used to
keep
information of
a specific user
updated
Used to edit
already
existing
publications in
the database
Used to edit
already
existing
publications in
the database
Used to edit
already
existing
publications in
the database
Correct
information
which may be
incorrect on
grants
Allow users to
manually add
publications and
grants to the
database.
Allow users to
manually add
publications to the
database.
Allow users to
manually add
publications to the
database using a
Bibtext document.
Allow users to
manually add grants
to the database.
Allow users to submit
changes to their
profile information.
Allow users to make
changes to
publications owned
by them.
Allow users to make
changes to
publications owned
by them using a
Bibtext document.
Allow users to
remove publications
owned by them.
Allow users to update
grant information in
the database.
Running Head: Troy M. Connor Lab 3
1.11.1
2
3
System User
Requirements
Database
7
Page designed
for overall site
preferences
Allow for READ to be
maintained and
organized by
approved users.
2.1
2.2
2.3
2.4
3.1
Database
Access
3.2
Add Author
3.3
Add Paper
3.4
Owns table
test
3.5
Add Grants
3.6
Add Tags to
Grants
3.7
Add Tags to
Publications
3.8
Add CO_PI
3.9
Add
AuthString
Verify that the basic
database account can
log into the database
server
Verify that the basic
database account can
add authors to the
Auths table.
Verify that the basic
database account can
add publications to
the Paper table.
Verify that the basic
database account can
link publications to
authors.
Verify that the basic
database account can
add grants to the
Grants table.
Verify that the basic
database account can
link tags to Grants
Verify that the basic
database account can
link tags to
Publications
Verify that the basic
database account can
link grants to authors
who are COPIs on
grants
Verify that the
Authstrings table can
be filled out by the
basic database
account
Running Head: Troy M. Connor Lab 3
3.10
4.1
4.2
4.3
4.4
4
MAR Scraper
4.5
4.6
4.7
4.8
4.9
4.10
8
Verify that the basic
Limitations on database account
the basic
cannot add, remove,
account
or alter tables in the
database.
Parser is
triggered upon
successful
Parser Trigger scraping of
Microsoft
Academic
Research.
Parser checks
for valid
Valid Input
BibTexformatted file.
Parser checks
Content Check valid file for
content.
Complete
Parser
Processing of processes all
Input File
entries.
Check for
Check for
required entry
required
attributes –
publication
‘title’ and
attributes
‘author’.
Check for
publication
Check for
type and
publication
attributes
type.
specific to that
type.
Format
Data format
database
updates.
Trigger
Updater
database
trigger
updater
module.
Complete
Full processing
processing of
of input data.
input data.
One author per
One author
paper.
Running Head: Troy M. Connor Lab 3
9
4.11
Duplicate Data
4.12
Database
update
(This section intentionally left blank.)
Check for
duplicate data.
Update
database with
non-duplicate
data.
Running Head: Troy M. Connor Lab 3
10
3.3 Test Schedule
The READ development team will present this prototype to our mentor Dr. Weigle. This
prototype will prove functionality and show that the requirements have been met. The
demonstration will provide evidence that all functional parts of the READ system work. This
includes the web scraper, the bibtex parser, the database queries, and the user interface. With the
demonstration fulfilling the goals and requirements to our mentor, it will become a functional
system. Table 2 provides the schedule in how the READ system will implement the tests. This
will also show the requirements that have been met with each demonstration.
Table 2 Prototype Demonstration Schedule
Timestamp
0:00
Demo. Section
Requirements Met
3.1.1.1.1-3
Introduction to READ 3.1.1.2
– Faculty Member
3.1.1.3.1-3
Search
3.1.2.1.1
3.1.3
3.1.4
0:05
Administrative
Functionality – Add a
Faculty User
0:10
Parser Demonstration
-- For New User
3.1.1.4.1
3.1.1.5.1-3
3.1.1.7.1
3.1.2.3.1
3.1.3
3.1.4
3.1.4
3.1.5.2.1,5-17
3.1.5.3.2,4,9,10
Required Preparation
- Run the scraper
successfully for at
least 5 current faculty
members, including
M. Weigle.
- Ensure that the
updates are included
on the front page of
READ.
- Create a fake Gmail
account for fake
faculty user.
- Prepare a BibTex
file containg at least 5
publication entries for
Running Head: Troy M. Connor Lab 3
11
the fake new faculty
member.
0:15
Faculty User – Edit
and Approve New
Update
0:20
MAR Scraper
Demonstration using
Real-World Data
3.1.1.8.1-3
3.1.2.2.1
3.1.3.5.1
3.1.3.6.1
3.1.3
3.1.4
3.1.5.4.1-8
3.1.1.3.1-3
3.1.1.4.1,2
3.1.1.5.1-3
3.1.1.8.1-3
3.1.3
3.1.4
3.1.5.1.,4
3.1.5.2.1-17
3.1.5.3.1-10
3.1.5.4.1-8
(This section intentionally left blank.)
(none)
- Remove all
publication data for
one pub owned by M.
Weigle.
- Prepare M. Weigle’s
profile page with
picture, etc ‘nicelooking’ data.
Running Head: Troy M. Connor Lab 3
12
3.4 Fault Reporting and Data Recording
Data will be recorded for all the tests that are performed for the READ system. The test for the
bibtex parser will be recorded in a log file that is saved to the linux machine. This log file will show the
status of documents added to the database, how many were added, and if any of the documents are
already in the database. This function will provide the READ system with information that can be useful
in implementing future improvements. In addition to the log file that the bibtex parser produces, the
READ development team will be using printed test cards. The test cards will be used to determine how
we can improve on the design of the READ system. These written test cards will serve as evidence that
each test will meet the requirements and goals of the prototype. Table 3 displays the recording process
for fault reporting.
Table 3 Fault Reporting and Data Recording Table
Component
Recording Process

Hardware
User Interface
Back-end User
Interface
Database
Data Scraper









Report failures through a visual inspection of the computer
tower
Document through hardcopy forms
Report failures through a visual inspection of the READ
website and navigation screens
Document through hardcopy forms
Report failures through a visual inspection of output printed
on the monitor
Document through hardcopy forms
Report failures through a visual inspection of the returned
SQL statements
Document through hardcopy forms
Report failures through a visual inspection of the data returned
from the scraper
Document through hardcopy forms
(This section intentionally left blank.)
Running Head: Troy M. Connor Lab 3
13
3.5 Resource Requirements
The resource that you will need to use the READ system is a laptop or desktop computer.
This computer must be hooked to an Internet source. This is so that anyone can go to the website
that the READ system is on. The resource can utilize any web browser capable of reaching the
domain https://411black.cs.odu.edu. The resource for the bibtex parser is a file with the
extension .bib. This file has to be formatted like files that are saved on
http://academic.research.microsoft.com/. This file format being unique is what generates the
bibtex parser to add publications to the database automatically. The scraper resource required is
system software installed on the linux machine. The system software installed for the scraper to
functionally work is PHP 5 and Python 2.3.
3.6 Test Environment
The testing environment involved is the READ development group’s linux machine and a
working computer connected to the Internet.
4 Test Procedures
Test cards have been printed to ensure prototype functionality.
4.1 Test Case Name and Identifier
Test cases have been printed already.
5. Traceability to Requirements
Running Head: Troy M. Connor Lab 3
Traceability matrix has been printed already.
14