移山公司-stone项目测试计划

移山公司-stone项目测试计划

总体测试计划

测试负责人
Project Test Lead
Test Project Owner
Usability Tester
Performance Test
Security Test Contact

 

 

Contact Information
Author
PM Contact
Dev Contact
Test Contact
Operations

 

 

Revision Summary
Author	Date	Version	Comments

目录

[具体目录略]

介绍

[这个文件是做什么的？] 这个文档讨论了移山公司Stone项目测试所需的时间、人力、物力（工具）。

背景

项目的远景和阶段目标。

质量目标

Stone项目测试团队的目标是在项目RTO的时候，达到下面的目标：

（1）没有任何p1或以上的问题存在。

（2）验证并批准 (sign-off) 效能测试/压力测试的目标。

（3）所有的BVT和RC发布标准的测试用例必须全部通过。所有已知的问题必须记录在TFS中。

工作的划分

职责划分

下表列出了Stone 项目不同人员的职责。

任   务	PM	DEV	TEST	UE	OPS
产品需求说明	X
设计说明		X
测试发布文档（TRD）：让测试人员知道什么是可以测试的		X
测试计划			X
帮助文档				X
可用性测试			X
常规（每日）构建		X
单元测试		X
常规构建存档			X
写发布脚本		X
写测试用例和自动化			X
项目总计划	X
管理Beta 发布	X
会诊（triage）问题	X	X	X
构建验证测试（BVT）			X
发布到正式网站			X		X
监控网站运行并报告			X		X

Deliverables (TRDs)

TRDs（Test release documents）是由开发人员在每一个功能完成后提供给测试人员的文档。TRD都应该作为附件保存在跟踪相应功能的工作项中。对于一些简单的功能，我们也可以把TRD直接写在工作项的说明中，不必拘泥于TRD的形式。

宏观功能测试责任划分

下表列出了Stone项目各个功能测试职责的划分。

功  能	负责人
商家功能 主页/注册/登录 上传文件/信息 修改商品信息 售后服务	阿毛
用户功能 主页/注册/登录 浏览商品 购物车 分类/搜索	小燕
管理功能 用户管理 商家功能 订单管理 统计	九条
网站整体效能	阿彪

测试方法(Testing Methodology)

测试总策略

每个项目和同一项目的不同版本测试的策略不尽相同。在Stone项目中，测试着重于基本场景和基本功能，可用性测试，效能测试在这一版本中处于相对次要的地位。

为了保证功能测试能快速地执行，我们在项目的初期以手工测试为主，同时开发自动化的测试。在项目后期以自动测试为主，辅以部分手工测试。这样既兼顾快速开发，快速反馈和提高测试质量的要求。

功能一级的测试计划

测试矩阵

从浏览器的版本和操作系统的我们可以得出测试矩阵，有X标注的部分是我们要测试的组合，标有*的是系统必须通过的测试环境（Windows XP + IE6/7）：

	XP		Vista		Win2k3 (Eng)
	CH	Eng	CH	Eng
IE6	X*				X
IE7	X*	x	x	X
Firefox	X			X
Opera	n/a	n/a	n/a	n/a	n/a
Safari	n/a	n/a	n/a	n/a	n/a

测试报告流程

报告流程是怎样的？

（1）功能小组必须复审并通过测试计划。

（2）测试人员必须根据测试计划开发测试用例和测试工具，以及相应的文档。

（3）功能小组必须复审测试用例。

（4）每一个测试用例用一个TFS中的"任务"来跟踪。

（5）功能小组在报告进展的时候，必须同时报告相应测试的进展。

所有的文档都要放在和Stone项目下的SharePoint网站中，在签入文档时，要保留版本信息。

测试工具和实验室

我们有没有专用的测试工具，和测试实验室？

 

测试范围

那些是必须测试的？

所有优先级是1和2的测试用例。

那些可以相机行事？

如果我们有时间和人力，物力，我们要测试优先级为3的测试用例。

那些不用测试？

所有优先级是4的测试用例。

测试日程

测试的日程安排，参加项目的计划，在此不重复列出。

Milestone

Date

风险

在Stone项目中有什么样的风险？我们如何去了解，规避，解除风险？

人员问题

大部分测试人员都是实习生或新毕业生，没有经历过商用软件的开发。

工具问题

所有人都是第一次使用 TFS 进行测试工作。

缺陷的优先级

测试人员在创建"缺陷"这一工作项的时候，要遵循以下的原则输入优先级：

SEVERITY:

（1）CRASHES: Causes a crash or hang or destroys files or causes serious data corruption/loss in some way. This includes recall class bugs and data bugs that are catastrophically systematic and/or impact large areas of the product.  In debug builds, a fatal assertion is a crash.

（2）MAJOR: A serious defect in the functionality of the product. Data or software operates contrary to the spec and/ or could cause data loss. This would include non-fatal assertions (clicking [Ignore] does not cause a crash).  Less serious systematic problems, such as individual instances of major transportation connectivity breaks.

（3）MINOR: A defect in the software but with little risk of data loss. Causes the software to operate contrary to user level documentation.

（4）TRIVIAL: Primarily a cosmetic problem or other small distraction that ought to be corrected.   This category also includes suggestions and spelling/grammar errors in dialogs.