Running Head: Lab 3 – READ Description
1
Lab 3 – Prototype Test Plan/Procedure for READ
Jim Lawrence Calderon
CS411W
Janet Brunelle
February 18, 2013
Version 1.0
Lab 3 – READ Description
2
Table of Contents
1
OBJECTIVES .......................................................................................................................... 3
2
REFERENCES ........................................................................................................................ 4
3
Test Plan .................................................................................................................................. 5
3.1
Testing Approach ............................................................................................................. 5
3.2
Identification of Tests....................................................................................................... 5
3.3
Test Schedule ................................................................................................................... 8
3.4
Fault Reporting and Data Recording................................................................................ 9
3.5
Resource Requirements .................................................................................................. 10
3.6
Test Environment ........................................................................................................... 10
Table of Tables
Table 1: Test Categatories ............................................................................................................................ 7
Table 2: Test Schedule .................................................................................................................................. 9
Table 3: Fault Reporting and Data Recording Table .................................................................................... 9
Lab 3 – READ Description
1
3
OBJECTIVES
The Repository for Electronic Aggregation of Documents (READ) is a system created by
the CS411 Black Group in response to the ODU Computer Department’s lack of a publication
database. Like the initial problem, this solution is not isolated to only ODU, and may be
integrated into the systems of any interested parties. The planned prototype is designed to
automatically perform the task of collecting publications owned by CS faculty members, from
across multiple scholastic websites. These publications and grants then have the ability to be
organized by the viewer through the use of numerous filters as they browse through the material.
While the viewers have the ability to browse, registered users and administrators will
additionally be able to update existing publications, or manually add publications when
necessary. With these features, READ aims to ease the responsibility of each researcher to
manually keep track of their publications outside of the initial upload to a single site.
The prototype’s main purpose consists of three major functions: obtain publication
information from across multiple scholastic sites using the Schaefer Scraper, store the data
obtained from this procedure into the database and display the information for viewers to browse
through in the web interface. The Schaefer Scraper software, which will be responsible for
obtaining publications, is already coded in PHP as well, requiring only to be integrated with the
web interface once ready. MicrosoftAcademic will be the only site utilized for the prototype.
Actual data will be scraped from the website using the software. It will then be parsed for
pertinent information, and stored into a MySQL database, which will be integrated with the web
interface.
READ’s user interface will be divided into the publications page, grants page, user profile
pages, and administrative function pages. Each of them has their respective filters tailored to the
Lab 3 – READ Description
4
page. By default, both the publications and grants page will display their respective material by
latest upload. The profile page will allow for the author to edit their personal information, grants,
publications or citation information. They may be added either by entering the information into
the fields or by supplying a BibTeX bibliography file from which the information can be
extracted in a similar manner to the Schaefer Scraper. The objective for this test plan is to test the
system so that all the aforementioned features are properly implemented.
2
REFERENCES
Lab1-- READ Product Description.V3.(2013 April). Black Team CS411W: Jim Lawrence
Calderon
Lab2-- READ Prototype Product Specification.V1. (2013 April). Black Team CS411W: Jim
Lawrence Calderon
(This space was intentionally left blank.)
Lab 3 – READ Description
3
5
Test Plan
This section will detail the READ test plan. It will discuss the testing approach,
identification of tests, test schedule, resource requirements and test environment. The plan will
be implemented recursively until the system functions properly.
3.1
Testing Approach
READ will undergo two types of test: integration, and unit testing. Unit testing will be
conducted to verify the individual components of the system. Integration testing will be
conducted to verify that the components connect to each other correctly. These methods will be
used to test each of the functional components of READ to ensure proper implementation. The
test data will be obtained by accessing real publications on MicrosoftAcademic owned by a
selected sample of faculty through the use of the Schaefer Scraper.
3.2
Identification of Tests
Illustrated in Table 1 are the test cases for the READ prototype. Each sub-module is
associated with at least one test and is organized under their respective modules.
Module
ID
1
Module
Sub-Module
Sub-Module
Requirement ID
Requirement
ID
Publication Query Page
1.1
1.1
Grant Query Page
1.2
1.2
Main Page
1.3
1.3
Login Page
1.4
1.4
Profile Page
1.5
1.5
Publication Add Page
1.6
1.6
User
Interface
Objective
Browse through all
publications on the system
Browse through all grants on
the system
Home page of READ.
Displays most recent
documents and llows for
navigation to other parts of
the UI
Allow registered users to log
into READ for authentication
purposes
List information on the specific
user which is logged in
Allow the user to submit
publictions manually into the
system
Lab 3 – READ Description
Module
ID
1
2
3
Module
User
Interface
Back-end
User
Interface
Database
6
Sub-Module
Sub-Module
Requirement ID
Requirement
ID
Grant Add Page
1.7
1.7
Profile Edit Page
1.8
1.8
Publication Edit Page
1.9
1.9
Grant Edit Page
1.10.
1.1
Administration Page
1.11
1.11
Publications Page
2.1
Grants Page
2.2
Login
2.3
2.3.1
Editing
2.4
2.4.1
2.4.2
Profile Page
2.5
2.5.1
Profile Editing
2.6
2.6.1
Database Access
3.1
3.1.1
Add Author
3.2
3.2.1
Add Paper
3.3
3.3.1
Owns table test
3.4
3.4.1
Add Grants
3.5
3.5.1
Add CO_PI
3.6
3.6.1
Add AuthString
3.7
3.7.1
2.1.1
2.1.2
2.2.1
2.2.2
Objective
Allow the user to submit
grants manually into the
system
Allow the user to submit
changes to their profile page
Allow the user to alter their
own publication information in
READ
Allow the user to alter their
own grant information in
READ
Houses all abilities which are
restricted solely to system
administrators
Default publication display
Filtered publication display
Default grants displaly
Filtered grants display
Verify username validity and
authenticity
Verify publication editing
Verifiy grants editing
Verify that profile page is
displaying properly
Verify profile editing
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 grants to
authors who are COPIs on
grants
Verify that the Authstrings
table can be filled out by the
basic database account
Lab 3 – READ Description
Module
ID
4
Module
7
Sub-Module
Sub-Module
Requirement ID
Microsoft Academic
Scraper
5.1
Bibtext Parser
5.2
Database Updater
5.3
Email Notification
5.4
Data Scraper
Requirement
ID
Objective
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.3.1
5.3.2
5.3.3
5.3.4
Trigger Parser
Empty Results
Process All Items
Empty Attributes
Parse Specific Attributes
Correct Format
Update
No Overwrite
Required Data
One Author At A Time
Table 1: Test Categatories
(This space was intentionally left blank.)
Lab 3 – READ Description
3.3
8
Test Schedule
The prototype demonstration is allotted 45 minutes in order for the team to showcase the
features of READ. Table 1 details what features will be showcased at approximate time stamps.
Timestamp
0:00
Demo. Section
Introduction to READ
– Faculty Member
Search
Requirements Met
3.1.1.1.1-3
3.1.1.2
3.1.1.3.1-3
3.1.2.1.1
3.1.3
3.1.4
0:10
Administrative
Functionality – Add a
Faculty 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
0:20
Parser Demonstration
-- For New User
3.1.4
3.1.5.2.1,5-17
3.1.5.3.2,4,9,10
0:30
Faculty User – Edit
and Approve New
Update
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
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
the fake new faculty
member.
(none)
Lab 3 – READ Description
9
Timestamp
Demo Section
Requirements Met
0:35
MAR Scraper
Demonstration using
Real-World Data
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
Required Preparation
- Remove all
publication data for
one pub owned by M.
Weigle.
- Prepare M. Weigle’s
profile
Table 2: Test Schedule
3.4
Fault Reporting and Data Recording
The results of the tests will be recorded during the prototype demonstration by the READ
team members. Success and failure will all be based off of visual examination. A member will
have a copy in order to document them.
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
Table 3: Fault Reporting and Data Recording Table
Lab 3 – READ Description
3.5
10
Resource Requirements
In order to demonstrate the functionality of READ, a few resources are required. Hardware
will consist of a local computer with Internet connection in order to access the READ website
and the Virtual Machine. Software requirements consist of a MySQL database. The system will
use the ODU Computer Science faculty as people resources to obtain test data.
3.6
Test Environment
The prototype demonstration will be held at a computer laboratory in the Dragas building
within Old Dominion University campus. A computer and the projector within the lab will be
utilized to demonstrate READ’s functionality.