1. Introduction

This document provides a detailed plan for the scope, approach, resources, and schedule of system testing activities for the system Test phase of the Web Tour App Test project. It defines the business functions and the business processes to be tested, the testing activities to be performed, and the risks and mitigation plan associated with the System Test phase.

1.1 Background

The main content is testing on Login Module, Register Module, Book Tickets Module, Cancelling Tickets Module, and Exit Module.

1.2

? ? ? ? ?

Objectives

Login Module No Bug Register Module No Bug

Book Tickets Module No Bug

Cancelling Tickets Module No Bug Exit Module No Bug

1.3

Scope

1.4

Out of Scope

1.5

? ? ?

Abbreviations, Acronyms and Definitions

QC = Quality Control:

QTP = Quick Test Professional LR = Load Runner

1.6

Test Environment

1.7

Environment Diagram

?

? Test environment name: Manual Function Test Test Locations: Chongqing

1.8 Hardware/Software Requirements

The hardware requirements for this test phase are as follows:

The software requirements for this test phase are as follows:

2. Test Data Requirements

3. Resources, Roles and Responsibilities

1.9 Organization

1.10 Roles and Responsibilities

1.11 Skill Requirement and Training plan

?

?

?

? QC Training QTP Training LR Training System Testing Training

4. Test Case & Test Log

? Please Click !

5. Defect Logging and Tracking

? No Defect

6. Test Exit Criteria

7. Risks Management

第二篇：使用Rational Suite TestStudio的测试自动化项目计划的例子

附录C：使用Rational Suite TestStudio的测试自动化项目计划的例子

C．1简介

       这份文档是用于向大家传授自动化软件测试框架以及其支持的测试工具的实施策略。其目的是帮助普通读者理解对这种框架进行部署的策略。

       大家应该接受这样一种观点，即自动化测试是需要专门资源的全职的活动。只有接受了这个观点工作付出的努力才可能成功。

C．2参考文献

C．2．1内部资源

       质量保证与测试（QA&T）组的自动化测试方法应该用以下的文档进行描述。这些文档和他们的内容会随着自动化方法的成熟而改变或者被替换。

       *软件测试自动化计划（Software Testing Automation Plan）

       *自动化测试方法学（Automated Testing Methodology）

*自动化测试策略（Automated Strategy）

*自动化测试指南（Automated Test Guidelines）

C．2．2外部资源

1．Nagle,Carl.“TestAutomationFrameworks”

可在members.aol.com/sascanagl/FRAMESDataDrivenTest AutomationFrameworks.htm查到

       2．Zambelich,Keith. “Today Data-Driven Automated Testing”白皮书，可在www.auto-saqa.com/articles.html查到，这是自动化测试专家（ATS）的网站。

C．3自动化实施

       Rational Suite TestStudio包括很多产品，能够支持测试过程的不同阶段，这些产品可以用于以下过程。

C．3．1测试管理

       Rational TestManager能被用于测试的各个阶段对测试活动进行管理。

C．3．2测试设计阶段

       Rational TestManager和Rational RequisitePro能用于此阶段定义测试需求，测试场景，测试用例，测试脚本和测试套件。此外微软的word和excel可分别用于为每个应用程序功能开发此时计划和测试数据。

RequisitePro是定义测试需求的工具。功能需求，高级设计和细节设计的文档会被导入RequisitePro中。测试需求会从这些文档所包括的系统需求和设计规格说明要求中提取出来。

TestManager使用RequisitePro提取出的测试需求作为其测试输入的首要类别。TestManager中会创建一个测试计划文件夹，这个文件夹会作为每一个被测应用程序特征的所有测试相关对象的高级目录。外部测试计划和测试用例文档会与内部测试计划文件夹以及创建出来的测试产物相关联起来。

测试计划文件夹会为具体应用程序构建和测试配置爆出将测试需求与测试脚本和测试套件相联系的信息，测试数据池也会与这个级别的特殊测试相关联。

外部测试计划是通过微软的Word使用RequisitePro中的测试需求而形成的，它用于指导定义测试活动。一个修改过的Rational Unified Process测试计划模板会被使用。尽管有些是与测试计划并行开始的，但测试用例一般都是在测试计划草拟完以后有Excel准备的。测试计划和测试用例都是动态的文档，当系统需求变化时它们也需要进行更新。

C．3．3测试实现阶段

       Rational TestManager和Robot都可用于此阶段。冒烟测试脚本以及环境设置脚本都由Robot生成。数据驱动引擎（DDE）也由Robot实现以及定制在这个级别，测试待定GUI和特征测试由Robot脚本实现，这个测试脚本会传给DDE，而DDE会驱动实际的测试。TestManager用于将测试脚本与测试需求连接起来以便跟踪和检测测试覆盖。

C．3．4测试执行阶段

       Rational Robot是最初的测试执行平台，但是测试要从测试管理器的控制台接口执行。测试结果会被捕获并显示在TestManager的测试日志窗口，测试结果也将被打印出来并且存档。

C．4自动化环境

       测试自动化的基础架构如图所示：

C．4．1

       测试自动化工程师需要有一个安装了TestStudio的测试开发以及执行工作站。这个工作站不是普通的NT台式机，因为自动化测试控制着台式机，工程师的工作站运行的测试会影响到其他工作活动。测试自动化的一个好处是测试的执行可以不用干预，测试人员可以干其他的事情。

       测试脚本开发工作站应该是一台安装NT/Windows2000系统的机器，最少要有60GB的硬盘和396KB的内存，还要安装微软的Office

C．4．2测试数据存储服务器

       Rational Suite TestStudio中所有项目都是作为测试项目数据存储实现的，每一个项目数据的存储包括项目存储文件和需求存储文件。此外，ClearQuest存储文件也可以与每一个TestStudio项目相关联。通过这种方式，测试，需求和缺陷都被整合到了一起并可以被跟踪。

       这需要一个单独的项目数据存储服务器。它应被用于永久存放所有的相关联项目以及数据库，此服务器应该有每天备份的计划。

C．4．3测试执行工作站

       测试的运行需要一个或更多的执行工作站。每个测试执行工作站既能单独运行一个测试套件，也能作为执行分布式测试的几个工作站中的一个。

C．4．4测试应用程序服务器

       这些应该是专用的服务器，他们模拟出应用程序所安装的所有目标产品服务器环境。他们应该只被用于自动化测试；他们不应该被用于继承测试或手工系统测试，那些测试应该在它们自己的服务器上运行。除了特定的测试，自动化测试服务器上的任何动作都应该拒绝那些测试。

       测试环境需求       以下信息被应用于配置测试程序服务器以及测试执行工作站（客户机）。

服务器

       硬件

       所有目标平台的信息

【网络】：网络配置

【服务器类型】：服务器配置参数

【数量】：系统中服务器的个数

【需要安装日期】：不适用

软件

所有目标平台的信息

【操作系统】：windows2000, windows NT4.0等

【服务器应用程序】：所有运行在系统服务器级别的软件

客户机

硬件

所有目标客户机平台的信息

【网络】：网络配置

【工作站类型】：工作站型号和制造商

【工作站配置】：工作站软件配置描述包括操作系统

【数量】：需要工作站的个数

【需要安装日期】：实施日期

软件

所有目标平台的信息

【操作系统】：Windows2000, Windows NT等

【工作站应用程序】：运行在系统工作站级别的商业软件或自己开发的程序

C．5组织结构

       项目的开展应该在测试自动化领导的指引下进行。理想的策划组应该由2为高级测试自动化工程师，3位测试自动化工程师，可能还需要1位初级测试自动化工程师组成。

C．6外部接口

       测试自动化项目在其常规活动过程中会与其他组之间有一些交互接口。包括：

       *QA&T组

       *研发组 

*管理

*核心开发

*支持以及维护

*配置管理组

C．7角色和责任

C．7．1角色

自动化工具组领导：   

此人负责每组项目的每日协调工作（50%的工作量）此外还要参与每天的工作活动（50％的工作量）。它应该掌握所有高级工程师水平要求的技术

高级测试自动化工程师：

此人具有所有需要的技术的高级专业只是，它可以是主题专家或方法工具专家，他应该掌握所有工程师水平要求的技术。

测试自动化工程师：

       这个级别的人员在其专业领域内具有中等专业知识，并且有良好的全面的产品知识。他应掌握的包括所使用的软件和硬件的知识。

初级测试自动化工程师/实习生：

       这个级别的人员应该有信息系统基础的入门知识和/或对质量保证和/或质量控制和测试有基本了解

C．7．2责任

       那些为功能测试而计划和实现数据驱动测试框架的人，其首要责任包括如下内容：

       *用于基本框架的测试脚本设计和构建的模块化自动化测试实用库

*数据库初始化功能

*进行测试验证的数据库访问功能

*各种程序功能（例如选择菜单选项，对话框标签页浏览，窗口存在验证等等）

*各种普通功能（例如打开文件，关闭文件，启动程序等等）

参与以下自动化测试脚本的设计与实现

*GUI测试

*属性测试

*功能测试

*基于服务器的后端测试

*可靠性测试

*性能测试

*用于测试后端能力的基于非GUI的测试脚本

C．8项目估计

       微软的Project软件可用于所有与项目相关的估计