1
Running Head: Lab 3- READ Prototype test Plan/ Procedure
Lab 3-READ Prototype Test Plan/ Procedure
Andrew Sprague
CS411
Professor Brunelle
April 15, 2013
Version #1
2
Lab 3: READ Test Plan/Procedure
Table of Contents
1. OBJECTIVES ............................................................................Error! Bookmark not defined.
2. REFERENCES ........................................................................................................................... 7
3. TEST PLAN................................................................................................................................ 8
3.1 Testing Approach .................................................................................................................. 8
3.2 Identification of Tests ........................................................................................................... 8
3.3 Test Schedule ...................................................................................................................... 13
3.4 Fault Reporting and Data Recording .................................................................................. 16
3.5 Resource Requirements ...................................................................................................... 16
3.6 Test Environment ................................................................................................................ 17
4. TEST RESPONSIBILITIES ......................................................Error! Bookmark not defined.
5. TEST PROCEDURES ...............................................................Error! Bookmark not defined.
5.1 Test Case Name and Identifier .............................................Error! Bookmark not defined.
6. TRACEABILITY TO REQUIREMENTS ................................Error! Bookmark not defined.
List of Figures
Figure 1: Prototype MFCD ........................................................................................................... 5
List of Tables
Table 1: Test Case Outline .............................................................................................................. 8
Table 2: Test Schedule .................................................................................................................. 14
3
Lab 3: READ Test Plan/Procedure
1. Objectives
According to the Digest of Education Statistics there are 4,706 research
institutions in the United States (Digest of Education Statistics). The primary way these
institutions attract both clients and new talent is to disseminate information on what they and
their employees have accomplished. This dissemination is usually done by employees publishing
papers. Universities, one of the largest groups of research institutions, make twenty percent of
their annual income from federal contracts and grants (freeby50.com). These universities do not
have a good online tool for sharing the work that they have done with prospective students or
faculty. Currently the systems that many institutions use to share publications are slow and
tedious.
This issue causes much of the work that universities and faculty accomplish to go without
the proper recognition. Students, who wish to go to a university that has professors who
specialize in a particular research area, can have trouble discerning between universities. The
work universities have done is not as well known, and, as a result, the faculty loses out on their
work being recognized.
The Repository for the Electronic Aggregation of Documents or READ System is an
online program that consists of a database and web scraper designed to automate the process of
gathering and sharing faculty publications. READ will allow faculty to organize all of their
publications and make any corrections that are required before sharing them to the public. Then
the public may access and browse the publications using READ.
The case study of READ will be the Computer Science Department of Old Dominion
University (ODU). This is because the current system that ODU utilizes is particularly deficient.
The Computer Science Department at ODU’s method for storing papers no longer is being
4
Lab 3: READ Test Plan/Procedure
utilized. It is not currently updated and has never had any method of searching the content and,
the method for updating the system was unable to encourage faculty to participate.
The prototype will consist of three main components that are the same as those of the
finished product as shown in Figure 1. The prototype will include a basic user interface. It will
also contain an implementation of the database. The Schaefer Scraper will be included to datamine websites.
The prototype will be implemented in the Computer Science Department’s servers. The
database will be implemented using MySQL. The web based interface will be implemented in
the prototype using Joomla!. Using this content management system will make logging in
authors easier to implement the interface because, one of the team members working on READ
already has a log in method for Computer Science faculty implemented in another project using
Joomla!. All of the queries to the database will be made through PHP scripts to interface between
MySQL and the web based interface. An interface between the Schaefer Scrapper and author
information in the database will be written in python.
5
Lab 3: READ Test Plan/Procedure
Figure 1 Prototype MFCD
The prototype will allow viewers to search and filter the database through the web-site. It
will also allow for minimal user-profile control. An RSS feed and email system will also be
implemented, so that people can stay informed of what is contained within the database. Access
Control will be a priority to prevent unauthorized users from updating author papers. The
Schaefer Scraper will automate much of the process of updating the publication lists. In the
prototype, the Schaefer Scraper will search online for publication on one fourth of the authors
every week.
6
Lab 3: READ Test Plan/Procedure
The objective of the Tests of the system is to ensure that the READ prototype is
completely functional. The components of read will be tested individually to ensure that they
work. If the testing shows any faults, the prototype will be fixed and re-tested.
7
Lab 3: READ Test Plan/Procedure
2.References
Digest of Education Statistics. 2011. National Center For Educational Statistics Web. 19 Nov
2012.
http://nces.ed.gov/programs/digest/d11/tables/dt11_001.asp?referrer=report.
"Where Do Universities Get their Money From?." Free By 50. N.p., 13 2011. Web. 19
Nov 2012.
<http://www.freeby50.com/2011/11/where-do-universities-get-their-money.html>.
Lab 1 -- READ Prototype Description. V3.(2012April). Black Team CS411:Andrew Sprague
Lab 2 -- READ Prototype Specification. V1.(2012April). Black Team CS411:Andrew Sprague
8
Lab 3: READ Test Plan/Procedure
3. Test Plan
This section of the Report will outline the test Plan for the READ Prototype. It will
describe the various procedures and methods for testing. The test scheduling will be explained in
this section.
3.1 Testing Approach
READ will be tested by performing unit test on each individual piece and then on the
whole. This method should ensure that each individual component is working before they are
combined. The parser, scraper, database, and GUI will all be tested individually.
3.2 Identification of tests
The tests for the READ prototype are listed in table 1. They have been broken down into
the sub categories: user interface, back-end user interface, database, and data scraper. More
detailed versions of these tests are in section 4.
Sub-Module
Module
Requirement
Module
Sub-Module
Requirement
ID
Objective
ID
ID
Browse through all
Publication
1.1
1.1
publications on the
Query Page
system
User
1
Interface
Grant Query
Browse through all
1.2
1.2
Page
Main Page
grants on the system
1.3
1.3
Home page of READ.
9
Lab 3: READ Test Plan/Procedure
Displays most recent
documents and llows
for navigation to other
parts of the UI
Sub-Module
Requirement ID
Objective
Sub-Module
Requirement ID
Allow registered users
to log into READ for
Login Page
1.4
1.4
authentication
purposes
List information on
Profile Page
1.5
1.5
the specific user
which is logged in
Allow the user to
Publication Add
submit publictions
1.6
1.6
Page
manually into the
system
Allow the user to
submit grants
Grant Add Page
1.7
1.7
manually into the
system
Profile Edit
Allow the user to
1.8
Page
1.8
submit changes to
10
Lab 3: READ Test Plan/Procedure
their profile page
Sub-Module
Requirement ID
Objective
Sub-Module
Requirement ID
Allow the user to alter
Publication Edit
1.9
1.9
their own publication
Page
information in READ
Allow the user to alter
Grant Edit Page
1.10.
1.1
their own grant
information in READ
Houses all abilities
Administration
which are restricted
1.11
1.11
Page
solely to system
administrators
Default publication
3.1.1
display
Publications
2.1
Page
Filtered publication
3.1.2
display
Back-end
Default grants
2
User
3.2.1
Grants Page
displaly
2.2
Interface
3.2.2
Filtered grants display
Verify username
Login
2.3
3.3.1
validity and
authenticity
11
Lab 3: READ Test Plan/Procedure
Verify publication
3.4.1
Editing
editing
2.4
3.4.2
Verifiy grants editing
Sub-Module
Requirement ID
Objective
Sub-Module
Requirement ID
Verify that profile
Profile Page
2.5
3.5.1
page is displaying
properly
Profile Editing
2.6
3.6.1
Verify profile editing
Verify that the basic
Database
database account can
3.1
3.4.9
Access
log into the database
server
Verify that the basic
database account can
Add Author
3.2
3.4.3
add authors to the
3
Database
Auths table
Verify that the basic
database account can
Add Paper
4.3
3.4.4
add publications to
the Paper table.
Verify that the basic
Owns table test
4.4
3.4.7
database account can
12
Lab 3: READ Test Plan/Procedure
link publications to
authors
Sub-Module
Requirement ID
Objective
Sub-Module
Requirement ID
Verify that the basic
database account can
Add Grants
4.5
3.4.5
add grants to the
Grants table.
Verify that the basic
database account can
Add CO_PI
4.8
3.4.8
link grants to authors
who are COPIs on
grants
Verify that the
Authstrings table can
Add AuthString
4.9
3.4.9
be filled out by the
basic database
account
Microsoft
Academic
5.1
Data
Scraper
4
Scraper
Bibtext Parser
5.2.1
Trigger Parser
5.2.2
Empty Results
5.2
13
Lab 3: READ Test Plan/Procedure
5.2.3
Process All Items
5.2.4
Empty Attributes
Parse Specific
5.2.5
Attributes
5.2.6
Correct Format
Sub-Module
Requirement ID
Objective
Sub-Module
Requirement ID
5.3.1
Update
5.3.2
No Overwrite
5.3.3
Required Data
Database
5.3
Updater
One Author At A
5.3.4
Time
Email
5.4
Notification
Table 1 Identification of Tests
3.3 Test Schedule
Forty five minutes are allotted for demonstrating the testing of the READ prototype.
Table 2 lists the current testing plan. The test plan will include an introduction of the product and
demonstrations of its functionality.
14
Lab 3: READ Test Plan/Procedure
Prototype Demonstration Schedule
Timestamp
Demo. Section
Requirements Met
Required
Preparation
0:00
Introduction to
READ – Faculty
Member Search
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
- 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.
0:05
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
- Create a fake
Gmail account for
fake faculty user.
15
Lab 3: READ Test Plan/Procedure
Timestamp
Demo. Section
Requirements Met
Required
Preparation
0:10
Parser
Demonstration -For New User
3.1.4
3.1.5.2.1,5-17
3.1.5.3.2,4,9,10
- Prepare a BibTex
file containg at least
5 publication entries
for the fake new
faculty member.
0:15
Faculty User – Edit
and Approve New
Update
3.1.1.8.1-3
(none)
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
0:20
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
- Remove all
publication data for
one pub owned by
M. Weigle.
3.1.3
- Prepare M.
16
Lab 3: READ Test Plan/Procedure
3.1.4
Weigle’s profile
3.1.5.1.,4
page with picture,
3.1.5.2.1-17
etc ‘nice-looking’
3.1.5.3.1-10
data.
3.1.5.4.1-8
Table 2 Test Schedule
3.4 Fault Reporting and Data Recording
Issues will be manually identified during testing. Database entries will be manually
displayed in the MySQL prompt to be checked for accuracy. Functionality of the GUI will also
be tested by manually running the system and looking for faults. If the output for any test is
incorrect the fault will be recorded and a fix will be attempted. After the issue has been resolved
the failed test will be repeated.
3.5 Resource Requirements
Testing the read prototype will require minimal resources. A standard web-browser, such
as Google Chrome or FireFox, can be used to efficiently test the Graphical User Interface. A ssh
program, such as PuTTy, can be used to test the database elements. The Scraper and parser can
be tested by running it in ssh and then checking the database for the entries.
17
Lab 3: READ Test Plan/Procedure
3.6 Testing Environment
The testing demonstration of READ will take place on April seventeenth. The
demonstration will be held in Dragas Hall at Old Dominion University. After the demonstration
the black team will answer any questions that asked.