代码人生

软件项目测试计划示例

代码人生 http://www.she9.com 2018-05-01 11:21 出处:网络 编辑:@霜伤
 NOAHTestPlan Ver1.0     TableofContents   RevisionHistory..3 1        Introduction...4


 

NOAH Test Plan

 

Ver 1.0

 


 


 

Table of Contents

 

Revision History.. 3

1         Introduction... 4

1.1  Purpose   4

1.2  Project Overview... 4

1.3  Audience   4

2         Test Scope.. 4

2.1  What is covered.. 4

2.2  What is NOT covered.. 4

3         Test Strategy.. 5

3.1   Test Approach and Strategy.. 5

3.2   Control Procedures. 8

3.3  Defect Tracking Tools.. 9

3.4  Use of QA Automation.. 9

4         Test Schedule and Resource Requirements.. 9

4.1  Test Schedule and Resource Allocation.. 9

4.2  Roles and Responsibility (*). 10

5         Test Environment.. 11

5.1  System environment.. 11

5.2  Test environment.. 11

5.3  Test environment establishment request.. 11

5.4  Test environment gap analyze.. 11

6         Test Entry and Exit Criteria.. 11

6.1  Test Cases Design.. 12

6.2  Smoke Test(Build Verification Test). 12

6.3  System Test   12

6.4  Regression Test.. 12

6.5  Performance Test.. 13

7         Dependencies, Assumption and Risks.. 13

7.1  Dependencies & Assumption.. 13

7.2  Risks   13

8         Test Standard... 14

8.1  Bug Severity and Priority.. 14

8.2  Bug Handling Procedure.. 14

8.3  Test Case Standard.. 15

8.4  Defect Template.. 16

9         Reference Documents.. 16

 


Date

Version

Description

Author

10/15/2007

1.0

Create

Sophia Tang






















     This document discusses in detail the Test Plan for the Noah project, based on the set of software requirement specifications (SRS) and project management plan. It will server as a guideline for this project’s test work and help to ensure to test the project successfully. It describes things like test scope, test approach and strategy, test schedule and resource, test environment, test entry and exit criteria, test standard and some dependencies and assumptions.

Noah is a windows form application based on .Net framework, which will cover the features of FDMaster, QwikSign and Receipt Manager. Noah provides an integrated solution for the document management.  Also, Noah has the ability to work with the core system in Credit Union.

     This document is intended for Project team including PM, TTL, developers and QA, TD, PA and PMO for review.

     This document might also be provided to customers with approval from TD or PM.

         Function test would cover areas listed as below:        

l  Noah shell including the user interface and Noah framework;

l  Document template management including setting up a template, importing a template, exporting a template, cloning a template;

l  Document signing;

l  Document archiving.

l  Integration test: test the system’s integration with the third party’s product such as VeryPDF.

Non-function test will contain test kinds listed as below:

l  Performance test: Noah should be able to support thousands of workstations in a system; and there’s no limitation for the length of a document and the document count in a batch

l  Compliance test: central service has the ability to support the old version front end

l  Localization test is not covered here because there is no such requirement for the project;

l  Concurrent test is not covered here because there is no such requirement for the project;

l  Stress test is not covered here because there is no such requirement for the project.

Strategy

 

Test Phase

General Test Type

Test Type Details

Descriptions

Notes

System

Test

Function Test

Smoke Test
Focus on the system’s main functions:
Noah shell;
Template management;
Document recognition;
Document signing;
Document Archiving;
 

Verify the stability of new builds before   accepting them to start system test

 

Function Test

GUI Test
Error Test
Negative Test
Logical Test
All functions
 

 

Manual test focused on the system’s function required by   Noah software requirement.

Installation Test

Focus on:

Installation; Uninstaller;

Initialization

Test functionality, not compatibility. These   tests should be performed once the system’s installer has been finished and installer bugs have been closed, and once again during the final   testing.

Integration   test

Test   the system’s integration with the third party’s product such as VeryPDF


Document Test


Review documents:

Printed manual;

Online help system;

Downloadable user guide

Test the document’s   contents and its language. And the document should be updated in time.


Non-Function

Performance Test

Noah should be   able to support thousands of workstations in a system;

There’s no   limitation for the length of a document and the document count in a batch.

The requirement   need to be detailed.

Compatibility Test

Noah shall provide a mechanism to work   with the Core System together;

Noah has   the ability to run against the Citrix system;

Noah central   service has the ability to support the old version front end


Regression Test

Function Test

Smoke Test

Focus on the system’s main functions:
Noah shell;
Template management;
Document recognition;
Document signing;
Document Archiving;
 

Verify the stability of new builds before   accepting them to start regression   test

 

Function Test


All Functions

Verify that the reported problems were fixed   properly and no additional problems were introduced during the fix. Manually   execute all function test cases

 

3.2.1 Review

Kind of Review

Time

Attendee

Test plan review

TBD

PM, TTL, QAL, QA,   Client

Test case review

TBD

PM, TTL, QAL, QA,   Client

 

3.2.2 Test Report

QAL is required to report the QA team’s daily work to PM and BluePoint Solution’s QA manager.

QAL is responsible to report test execution status report in time to PM, TTL and project related persons to state test progressing according to test plan and test related issues.

In Test Status Report, all test phases and all cases identified to conduct in each test phase will list based on test case matrix.

One test phase finish or one test type finish, a separated Test Status Report can send out to summary this test phase or test type execution status.

QAL is responsible to deliver quality status report in time to PM, TTL and project related persons to state project quality status. Quality status report is better to send out with test status report together.

QAL should upload quality stats report onto PPM website weekly

In Quality status report, bug origin analysis will analyze those bugs resolved during the report period.

In this project, we will still use CFS, demanded by the BluePoint company, as our defect tracking system. This system is accessible to members of BluePoint US team and Beijing team.  And this is a user-number limited system. Putting all together, there are only 5 team members that can login in this system simultaneously. So after finishing your work in this system, you’d better logout as soon as possible.

Since this is a defect tracking system co-worked with the BluePoint US team, all the BluePoint teams- both US team and Beijing team- can do things related to the bug lifecycle such as reporting a defect, assigning a defect, fixing a defect , verifying a defect, etc according to the rules and procedures of defect tracking.  The detailed defect tracking rules and procedures can be referred to Objectiva company’s  QA_gdln_Bug Tracking.

Automation testing for function test will not be used in this project.

Schedule and Resource Requirements

      According to the PMP and SRS, this project’s schedule, milestone and human power is planed as below:

Mile Stone Name

Activities

Planned

Resources

(Person*Day)

Start Date (mm/dd/yy)

Target Date

(mm/dd/yy)

Definition

Create Test Plan

10/15/07

10/19/07


Test   Plan Review/Approve

TBD

TBD

TBD

M1

Test case   Analysis for feature 1

TBD

TBD

TBD

Test Case   implementation for feature1

TBD

TBD

TBD

Feature1 Test cases review

TBD

TBD

TBD

Establish Test Environment

TBD

TBD

TBD

Smoke Test

TBD

TBD

TBD

Feature 1 Test   Case Execution

TBD

TBD

TBD

M2

Test case   Analysis for feature 2

TBD

TBD

TBD


Test Case   implementation for feature2

TBD

TBD

TBD


Feature2 Test cases review

TBD

TBD

TBD


Establish Test Environment

TBD

TBD

TBD


Smoke Test

TBD

TBD

TBD


Feature 2 Test   Case Execution

TBD

TBD

TBD


Compatibility   Test

TBD

TBD

TBD

M3

Smoke Test

TBD

TBD

TBD


Installation   Test

TBD

TBD

TBD


Performance   Test

TBD

TBD

TBD


Partial Regression   Test

TBD

TBD

TBD


Documentation   Test

TBD

TBD

TBD


….

TBD

TBD

TBD

M4

Regression   Test

TBD

TBD

TBD


Platform Test

TBD

TBD

TBD


Release   verification

TBD

TBD

TBD

 

<Define each roles and responsibility based on test guideline>

<List of QA team members and their responsibilities, one sample is below>

Resources

Staff

Responsibilities

1 PM


Serve as a primary contact   between the client and the QA team

1 QA Leader


Ensures the overall success of the test cycles;.

He/she will communicate the testing status, test requirements   to the project team and clients;

Create Test plan;

Assign test assignments and monitor testing progress;

Manage risks in testing

1 QA


Make out overall test strategy;

Identify function and performance requirements

Create test scenarios

Guide test cases design and testing cases execution

1 QA


Implement and update test cases based on test scenarios;

Program and debug test scripts.

1 QA


Sep up test environment;

Conduct system testing;

Execute test cases or test scripts;

Record test results and report bug if necessary

1 QA


Analyze test results and get quality conclusion

Find out major functional defects or performance   bottleneck, provide optimize suggestions.

 

environment

       Refer to Noah Software Requirement Specification.doc.

Hardware

Software

Server(Windows 2000/2003), Client(Windows XP),   Sigpad

ODOC Server/Client, SQL   Server 2000 and SP4, .net framework 2.0

 

  Test environment establishment should follow the following steps:

1.    Add the ODOC data source

2.    Install ODOC client

3.    Run 2100server.reg and XP2ODOC.reg to write to Registry

4.    Install Noah

5.4     Test environment gap analyze

The test environment is fully matched the system’s required environment described in the , so there is no gap between there two and risks may be caused by test environment difference could be ignored.

are the entry and exit criteria for Noah’s some typical test activities.

Entry Criteria

l  Noah software requirement specification is available

l  Noah software requirement has been analyzed

l  Line Item Design Document has been approved

Exit Criteria

l  Test cases has been successfully reviewed and approved

Build Verification Test)

Entry Criteria

l  Test cases for smoke test have been completed and reviewed

l  Test environment is ready

l  Testable build has been successfully installed in the test environment.

Exit Criteria

l  Successfully executed the smoke testbuild verification testtest cases without blocking.

Entry Criteria

l  Integration test has been finished

l  Test cases have been completed and reviewed

l  Test environment is ready

l  Testable build has been successfully installed in the test environment

l  Smoke Test (Build Verification Test) exit.

Exit Criteria

l  Planned test cases have been 100% attempted

l  90% test cases completed. Remaining test cases deferred into next build

l  There are no severity 1 and 2 bugs outstanding, unless otherwise approved by PM.

l  Severity 3/4 bugs have been worked on by developers and fixes will be integrated into the next build prior to the regression test, or      severity 3/4 bugs will be deferred to other approved by PM.

Test

Entry Criteria

l  System testing have exited

l  Regression test cases have been identified

l  All blocking bug fixes have been integrated into the build, if any

l  Test environment is ready

l  Testable build has been successfully installed in the test environment

l  Smoke test(build verification test) has exited

Exit Criteria

l  Planned test cases have been 100% attempted

l  There is no severity 1 and 2 bugs outstanding, unless otherwise approved by PM and TTL.

Test

Entry Criteria

l  Test environment is ready

l  Basic function implementation is done

l  Performance test case is ready and resource is available

Exit Criteria

l  Planned test cases have been 100% attempted

l  Performance profile are satisfied upplemental, Non-Functional Requirements listed in approved SRS

l  There is no serious bug outstanding, unless otherwise approved PM.

 

A series of dependencies and assumption must be taken into consideration in order to assure the success of test.  For Noah project, we should take things as below into consideration:

l  Smooth communication between BluePoint US team and Beijing team to figure out     misunderstand as earlier as possible

l  Build availability

l  Tester availability (in a timely fashion)

l  Test requirements (reasonably defined) availability

l  Test group training

l  Technical support

l  Defects fixed in a timely manner

l  Adequate testing time

l  Computers and other hardware such as sigpads and scanners

l  Software and associated documentation

l  Defined development methodology

l  Defined build delivery procedure

 

      Refer to PPM

There is a separate definition of bug severity and priority showed as below in the CFS system.

Severity  

Functionality

Sev.   1

Customer Down

System Failure

Sev.   2

Data   Loss

Sev.   3

Loss of Functionality

Sev. 4

Minor Problem

Sev.   5

Cosmetic

 

      There are five levels of bug priority:1, 2,3,4,5. Bug’s priority should be determined by many factors such as bug severity, time availability, costumer request, etc.

Bug handling procedure is similar to Objectiva’s bug handling procedure(Refer to Bug_Tracking Guideline). The following picture describes the workflow:

软件项目测试计划示例

 

In Noah project, we use the test case template that had been used during the test of other BluePoint’s products.

Test Case should be designed according to software requirement specification(SRS), Test Plan, Function Specification, Software Design and Test Strategy Rule document. It should keep to the rules listed below:

l  All feature and sub features described in SRS should be covered in test cases with different methods like boundary’, ‘Equivalence Partitioning’, ‘negative’, ‘error guessing’, etc.

l  All non-function requirements in SRS should be covered in test cases

l  The prerequisite if exists should be described in test cases

l  The preparation of test data if needed should be mentioned in test cases

l  The test case clear and easy to be followed to execute test

 

In Noah project, we use the template defined by Customer First System provided by client.

Project Management Plan.doc

Noah Software Requirement Specification.doc

 


请关注公众号:程序你好
0

精彩评论

暂无评论...
验证码 换一张
取 消