Massachusetts Institute of Technology Touchstone Performance Test Plan

Abstract

This test plan is intended to prescribe the scope, approach, types of performance testing, resources and high-level schedule of the testing activities to be performed in the Touchstone project. This plan will identify the use cases, data, and related systems to be included in the testing process.

1.0 Document identifiers

1.1 Document Author

The document author is:

Author

Title

Telephone

Email Address

Will Smithee

Senior Practice Manager

336-232-5208

will_smithee@questcon.com

1.2 Document Revisions

Issue

Date

Author

Reason for Change

0.1

01/27/2008

Will Smithee

Initial draft

 

 

 

 

1.3 References

The following documents were used as sources of information for this test plan:

  • Questcon Technologies, The Questcon Test Management Methodology; 01/07/2005; (Test Management Methodology Release 4.0.doc).
  • Questcon Technologies, MIT SOW Testing Touchstone.

2.0 INTRODUCTION

2.1 Purpose

The objective of this test plan is to outline the performance testing effort to be undertaken for the Touchstone project.

2.1.1 Project Description

MIT Touchstone is a new suite of technologies for authenticating a variety of web applications, being introduced by IS&T. MIT Touchstone provides a single sign-on solution for applications that have been coded and configured to use the system. Within the context of Touchstone enabled applications, users will be able to seamlessly transition between systems without being prompted for additional authentication information.
The intended audience of this document includes all IT personnel involved in the development, testing, and support of Touchstone.

2.1.2 Project Technologies

MIT Touchstone utilizes/integrates with the following technologies:

  • Stanford's WebAuth
  • Internet 2's Shibboleth
  • SAML (the Security Assertion Markup Language)
  • A new account management system for some users outside of the traditional MIT community
  • HTTP/S (extensive redirects)
  • SSL
  • MIT X.509 certificates
  • Kerberos (via the HTTP/SPNEGO protocol)
  • TLS
  • OpenID
  • Web Services
  • MySQL (including replication)
  • Apache
  • Tomcat
  • IDP High Availability Package
  • LDAP
  • KDC
  • DNS load balancing

2.2 Scope

2.2.1 Items To Be Tested

Each of the following business processes (user flows) will be tested under load:

  • CAMS Account Creation
  • CAMS Account Authentication
  • CAMS Account Association (OpenID)
  • Authenticated Kerberos user access
  • Kerberos user id and password authentication
  • Authenticated OpenID user access

2.2.2 Items Not To Be Tested

The following modules and types of tests are considered to be outside the scope of this test effort and will not be tested by Questcon:

  • MIT X.509 certificate access
  • Kerberos (HTTP/SPNEGO) access
  • CAMS Account Association (Kerberos (HTTP/SPNEGO))

2.3 Risks & Contingencies

The following risks have been identified, which may impact the testing effort.

Risk

Contingency

Production-like test environment not available

Utilize development or production environment. Results may not be indicative of production and therefore cannot be used as a benchmark. Production performance issues may not be identified during testing.

Production-like setup and settings not available.

Use the closest setup and settings we can. Results may not be indicative of production and therefore cannot be used as a benchmark. Production performance issues may not be identified during testing.

Fully operational test tools not available.  (i.e. tools capable of generating the desired load and capturing the desires metrics)

Wait until the test tools are available or find and use another test tool(s). This will extend the time required to perform testing.

Test time increases due to changes in scope requiring additional test analysis and/or test case creation

If test time cannot be increased, reduce/cut performance testing scenarios and execute highest priority scenarios initially followed by lower priority tests until test time runs out

Involvement of subject matter experts (SMEs) for all stages of the testing effort not sufficient.

Extend testing time.

Inadequate Non-functional Requirements

Missing pass/fail criteria based on stated non-functional requirements will invalidate performance benchmarking. Missing load modeling will invalidate all test scenarios. The contingency is to perform only a brute stress test to try and flush out major bottlenecks and functionality under load issues. Additionally an endurance test can be run to attempt to identify memory leaks, although these tests will be less indicative of real world usage scenarios.

Insufficient access to systems in order to monitor the tests (including any necessary server side scripts which may need to be developed in order to capture desired metrics).

Root cause analysis will be difficult if possible. Testing time will most likely need to be extended and scenarios may be abbreviated due to time constraints.

Substantial issue(s) which requires significant modifications to the application or re-configuration of the system are encountered.

Some testing may need to be re-executed, possibly including re-scripting etc. This would extend testing time.

Excessive number of bottlenecks encountered and/or issue correction time.

Extend testing time.

Test time increases due to changes in scope requiring additional test analysis and/or test script/scenario creation .

If test time cannot be increased, reevaluate priorities and risks and execute tests according to new priorities.

Conflicting information provided.

Project manager will work to resolve any conflicting information, goals, and/or instructions received.

3.0 Approach

3.1 Testing Strategy

The overall strategy for performance testing the Touchstone project is goal based. There are four main goals we hope to achieve:

  1. Performance - Benchmark the system to ensure it meets all documented non-functional requirements related to performance.
  2. Stress - Push the system to its breaking point and beyond to identify how and under what level of load the system fails as well as the ramifications of such a failure.
  3. Endurance - Place the system under a heavy, yet manageable, load for a protracted period of time to identify any performance degradation and/or memory leaks.
  4. Fail-over - Place the system under a heavy, yet manageable, load, wait for it to stabilize and then disconnect the servers from their network connections to identify how the system handles the sudden loss of a server. This will help satiate any up-time SLAs or non-functional requirements.

Scripts will be designed to model various user interactions with the system. While most of the user interactions will be scripted, some may be omitted according to the 80/20 rule and/or any time constraints which may exist.

3.2 Tools

The tools we will employ are yet to be determined. A proof of concept (PoC) is under way on a performance testing tool. If it is acceptable to MIT then this tool will be identified here. Otherwise further PoCs may need to be conducted until a satisfactory tool is identified and accepted by MIT.

The following tools will be used as part of the overall Touchstone testing effort:

Tool

Purpose

Used By

Atlassian Jira

Web-based defect tracking system accessed by http://mv.ezproxy.com.ezproxy.canberra.edu.au/jira

Touchstone Project Team (MIT & Questcon)

StressTester

Performance testing / load generation tool

(MIT & Questcon)

3.3 Environmental Needs

We will need the following:

  • Stable production like system to test against.
  • Stable hardware and software to use to generate load.
  • Adequate rights and privileges to capture server side metrics (monitoring) as well as any server side scripts necessary to accomplish any needed monitoring.

4.0 Scripts

The following scripts will be used during the performance testing effort.

** Design steps for the following scripts have not been provided by MIT yet.

Script

Objective

Priority

CAMS Account Creation

End user creates a Touchstone account.

High

CAMS Association - OpenID

End user associates their Touchstone account with an OpenID account.

Medium

CAMS Association - Kerberos

End user associates their Touchstone account with a Kerberos account.

High

Site Access - Kerberos w/ticket

End user access a site using an MIT machine that has a Kerberos ticket.

High

Site Access - Web Auth

End User access a site using Web Auth.

High

Site Access - CAMS Account

End user access a site using their CAMS accont only.

High

Site Access - OpenID

End user access a site using their OpenID.

Medium

Password Reset

End User resets their password.

Low

Admin - Password Reset

Administrator resets an end user's password.

Low

Admin - De-Activate Account

Administrator de-activates an end user's account

Low

Admin - Delete Account

Administrator deletes an end user's account.

Low

Admin - Activate Account

Administrator activates a de-activated account.

Low

5.0 Scenarios

5.1 Performance Testing Scenarios

A performance test is designed to benchmark the system under test under a realistic load scenario that mimics what we anticipate real world usage will be at its peak.

References to non-functional requirements marked as TBD will be updated once the non-functional requirements are provided by MIT.

5.1.1 IdPi Only

The objective of this scenario is to benchmark just the internal IDP.

5.1.1.1 Load Model

Desired Transaction Rate: TBD

Script

% of Load

Site Access - Kerberos w/ticket

TBD

Site Access - Web Auth

TBD

We will be able to specify the transaction rate, and load modeling once the non-functional requirements have been provided by MIT.

5.1.2 IdPe Only

The objective of this scenario is to benchmark just the external IDP.

5.1.2.1 Load Model

Desired Transaction Rate: TBD

Script

% of Load

CAMS Account Creation

TBD

CAMS Association - OpenID

TBD

CAMS Association - Kerberos

TBD

Site Access - CAMS Account

TBD

Site Access - OpenID

TBD

We will be able to specify the transaction rate, and load modeling once the non-functional requirements have been provided by MIT.

5.1.3 Integrated IDP External & Internal

The objective of this scenario is to benchmark both IdPs concurrently.

5.1.3.1 Load Model

Desired Transaction Rate: TBD

Script

% of Load

CAMS Account Creation

TBD

CAMS Association - OpenID

TBD

CAMS Association - Kerberos

TBD

Site Access - CAMS Account

TBD

Site Access - OpenID

TBD

Site Access - Kerberos w/ticket

TBD

Site Access - Web Auth

TBD

We will be able to specify the transaction rate, and load modeling once the non-functional requirements have been provided by MIT.

5.2 Stress Testing Scenarios

5.2.1 IdPi Only

The objective of this scenario is to stress only the internal IDP. We plan to push it gradually up to its breaking point and then beyond to determine how and at what load it fails.

5.2.3.1 Load Model

Desired Transaction Rate: OPEN

Script

% of Load

Site Access - Kerberos w/ticket

TBD

Site Access - Web Auth

TBD

We will be able to specify the transaction rate, and load modeling once the non-functional requirements have been provided by MIT.

5.2.2 IdPe Only

The objective of this scenario is to stress only the external IDP. We plan to push it gradually up to its breaking point and then beyond to determine how and at what load it fails.

5.2.3.1 Load Model

Desired Transaction Rate: OPEN

Script

% of Load

CAMS Account Creation

TBD

CAMS Association - OpenID

TBD

CAMS Association - Kerberos

TBD

Site Access - CAMS Account

TBD

Site Access - OpenID

TBD

We will be able to specify the transaction rate, and load modeling once the non-functional requirements have been provided by MIT.

5.2.3 Integrated IDP External & Internal

The objective of this scenario is to stress both IdPs concurrently. We plan to push it gradually up to its breaking point and then beyond to determine how and at what load it fails.

5.2.3.1 Load Model

Desired Transaction Rate: OPEN

Script

% of Load

CAMS Account Creation

TBD

CAMS Association - OpenID

TBD

CAMS Association - Kerberos

TBD

Site Access - CAMS Account

TBD

Site Access - OpenID

TBD

Site Access - Kerberos w/ticket

TBD

Site Access - Web Auth

TBD

We will be able to specify the transaction rate, and load modeling once the non-functional requirements have been provided by MIT.

5.3 Endurance Testing Scenarios

5.3.1 Integrated IDP External & Internal

The objective of this scenario is to run both IdPs concurrently for a protracted period of time (multiple days) to determine stability and check for memory leaks. We plan to load the system with 80% of the capacity as determined by the integrated stress test scenario and hold it. During this time special attention will be paid to memory and general system stability. There should also not be any appreciable deterioration in end-user response times.

5.3.1.1 Load Model

Desired Transaction Rate: 80% of capacity

Script

% of Load

CAMS Account Creation

TBD

CAMS Association - OpenID

TBD

CAMS Association - Kerberos

TBD

Site Access - CAMS Account

TBD

Site Access - OpenID

TBD

Site Access - Kerberos w/ticket

TBD

Site Access - Web Auth

TBD

We will be able to specify the transaction rate, and load modeling once the non-functional requirements have been provided by MIT.

5.4 Fail-over Testing Scenarios

5.4.1 Integrated IDP External & Internal

The objective of this scenario is to check how both IdPs handle a sudden interruption in connectivity by pulling the network plug from one of the servers at a time.

5.4.1.1 Load Model

Desired Transaction Rate: TBD

Script

% of Load

CAMS Account Creation

TBD

CAMS Association - OpenID

TBD

CAMS Association - Kerberos

TBD

Site Access - CAMS Account

TBD

Site Access - OpenID

TBD

Site Access - Kerberos w/ticket

TBD

Site Access - Web Auth

TBD

We will be able to specify the transaction rate, and load modeling once the non-functional requirements have been provided by MIT.

6.0 Monitoring

The following metrics will be collected from each Touchstone server during the performance tests to assist in diagnostics

  • CPU %
  • System Load
  • System Memory
  • JVM Memory (For each JVM)
  • JVM Processor % (Hopefully we can get this through JMX) (For each JVM)
  • JVM Garbage Collections (For each JVM)
  • Apache httpd processes (memory, CPU, and open files for each process)
  • Number of open files.
  • Network Connections
  • LDAP Connections (This would be applicable to Core IdP testing only)
  • DB Connections (This would be applicable to CAMS testing only)

7.0 Non-functional Requirements

MIT has not yet provided the non-functional Requirements. The link below will be updated if a web page is created to house them, otherwise they will be specified here.

Touchstone Non-functional Requirements

8.0 Architectures

Architectural diagrams will be referenced here as MIT provides them.

8.1 Physical

Touchstone Production Physical Architecture

8.2 IdPi Logical

Touchstone Production IdPi Logical Architecture

8.2 IdPe Logical

Touchstone Production IdPe Logical Architecture

9.0 Schedule of Deliverables and Resources

9.1 Deliverables

This section identifies the deliverables, delivery date and resource responsible for each deliverable.

Key Deliverables

Description

Expected Delivery Date

Resource

Performance Test Plan

This document.

After all non-functional requirements and other needed data is delivered

Questcon

Performance Test Scripts

Automated scripts used to deliver load.

30 business days after test plan finalization and environmental needs are met.
(2.5 days/script * 12 scripts)

Questcon

Performance Test Scenarios

Automated execution designs used to conduct performance tests.

~5 business days after scripts are developed.
(~.65 days/scenario * 8 scenarios)

Questcon

Execute Performance Tests

Running of scenarios.

10 business days
(~1 day for 7 scenarios and 3 days for the  endurance scenario)

Questcon

Status Reports

Accomplishments, issues and plans.

Weekly

Questcon

Defect Reports

Entered in Jira as they are discovered.

Ongoing during test execution

Questcon

Performance Test Summary Report

Details the results of the testing effort.

3 business days after the last performance test is completed.

Questcon

9.2 Test Schedule

The planned test schedule of the Touchstone project has an anticipated start date of //2008 and completion date of //2008. The estimated completion date is based on several assumptions, some of which have been identified in 2.3 Risks & Contingencies.

Milestone

Target Timeframe

Summation of Activities

Develop performance test plan

01/15/2008 - 02/05/2008
15 Business Days

  • Analyze existing design documents, notes, and other available materials
  • Develop test plan document

Review performance test plan

02/05/2008 - 02/11/2008
3 Business Days

  • Review, clarify, correct, and update the test plan
  • Client approval of test plan

Build Performance test scripts

//2008 - //2008
30 Business Days

  • Author test scripts in automated tool

Build Performance test scenarios

//2008 - //2008
5 Business Days

  • Setup web server and database server
  • Load application under test
  • Setup logins and authorizations

Setup test data

//2008 - //2008
1 Business Day

  • Review & analyze test cases to target data to load in test environment
  • Load initial test data set

Execute performance tests

//2008 - //2008
10 Business Days

  • Execute documented performance test scenarios
  • Communicate with the development team when issues are found
  • Maintain a test run log
  • Track test metrics

Create test summary

//2008 - //2008
3 Business Days

  • Create and deliver a test summary report to include:
    • Summation of planned/actual test activities
    • Deviation from planned activities
    • Summary of defects (open defects)
    • Summary of test metrics

TOTAL:

73 Business Days

 
  • No labels