测试规范及使用说明V12Word格式文档下载.docx

测试规范及使用说明V12Word格式文档下载.docx

《测试规范及使用说明V12Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《测试规范及使用说明V12Word格式文档下载.docx（11页珍藏版）》请在冰豆网上搜索。

A

2010-7-22

创建文档

V1.1

M

2010-8-9

补充和修改该文档各个章节内容

2010-8-10

修改该文档各个章节内容

1简介

1.1编写目的

在测试工作过程中存在一些不好定义修改优先级的BUG、需求不明确造成的BUG、无法确认是否可以关闭的BUG，这些BUG的修改直接或间接影响到项目开发进度。

另外，禅道使用过程不够规范，开发员和测试员对于一个BUG的理解不同，导致BUG不能修改、误修改或延长了BUG存在周期。

对于Web网站的功能测试不全面的问题，有必要明确Web网站测试方法和注意事项。

综上所述，此次编写该文档的目的在于明确测试流程、测试规范。

对于不同性质的系统说明需要测试的方法、内容和注意事项。

禅道在项目中的合理高效运用的方案。

1.2项目背景

在测试过程中经常出现一些延长开发和测试工作的问题。

1.3文档对象

●技术中心所有成员

●各事业部技术部门

●项目管理部所有成员

●研发中心所有成员

1.4参考文档

●《测试标准流程V1.5》

●《测试组成员岗位职责说明V1.0》

●《文档编写规范说明V2.0》

2测试方法

2.1功能测试

●针对于WEB网站，测试方法需考虑：

兼容性、易用性、风格布局统一、符合行业规范、功能性、安全性（权限管理、业务流程、网络安全）

●针对于应用软件，测试方法需考虑：

易用性、风格布局统一、符合行业规范、功能性、安全性（权限管理、业务流程）

2.2性能测试

并发测试、压力测试和负载测试，根据项目需求说明书中的性能要求使用不同的测试方法。

3测试条件及规范

该测试流程适用于正常测试流程、需求变更测试流程和回归测试流程。

其中说明了测试启动条件、测试暂停条件、测试重启条件、版本号的变更及规范、功能测试和回归测试流程及规范、各阶段产出物（文档）。

3.1测试条件

3.1.1常规测试

3.1.1.1启动条件

●项目经理向测试组提供了需求说明书

●测试组参与了项目需求评审且需求评审通过

●项目经理向测试组提供了评审通过后修改好了的需求说明书及项目测试计划

●项目经理提供了程序包和数据库给测试组

●测试软硬件环境已搭建完成

3.1.1.2拒绝测试原因

●项目经理未提供需求说明书及项目进度计划书

●测试组未参与需求评审会议

●测试组不同意项目进度计划书中关于测试时间的周期

●项目经理未提供程序包和数据库给测试组

●测试软件件环境未搭建成功

3.1.2需求变更测试

3.1.2.1启动条件

●项目经理向测试组提供了《需求变更文档》及《项目测试申请单》且有项目经理和项目管理部相应项目QA签字

●测试软硬件环境已搭建成功

3.1.2.2拒绝测试原因

●项目经理未向测试组提供《需求变更文档》及《项目测试申请单》

●《项目测试申请单》内容不详细且无项目经理和项目管理部相应项目QA签字

●测试软硬件环境未搭建成功

3.1.3回归测试

3.1.3.1启动条件

●BUG已修改完成

●项目经理向项目测试组长提供了内容详细的《项目回归测试申请单》

3.1.3.2拒绝测试原因

●项目经理未向项目测试组长提供内容详细的《项目回归测试申请单》

3.1.4临时测试任务

3.1.4.1启动条件

●项目经理提供了需求说明书和项目进度说明书

●有充足的测试时间和人员

●软硬件测试环境已搭建成功

3.1.4.2拒绝测试原因

●项目经理未提供需求说明书和项目进度计划书

●测试组长不同意临时项目进度测试时间的安排

●软硬件测试环境未搭建成功

3.1.4.3延期测试原因

●无充足的测试时间和人员

3.2测试规范

3.2.1测试流程规范

常规测试、需求变更测试和回归测试必须按照《测试标准流程V1.5》和本文档中的要求执行测试。

3.2.2测试文档规范

●各个测试文档内容必须严格按照CMMI全套文档V2.0模版进行编写

●测试文档格式（标题级别、标题和文字大小和样式、页面风格等）必须按照《文档编写规范说明V2.0》规定进行编写

4禅道使用及规范

在测试过程中，发现一些问题。

这些问题主要集中在BUG状态的确认、项目版本的控制和BUG生存周期不明确。

为了更好的发挥禅道项目任务跟踪管理系统功能，特别制定了禅道使用流程和规范。

4.1使用流程

4.1.1使用流程描述

1、产品人员于产品视图创建产品，并维护产品模块，添加管理需求项；

2、项目经理创建项目，添加团队成员，维护项目视图模块，并关联产品及对应项目待实现的需求项确认，分解指派项目任务

3、开发人员接收并完成项目开发任务，创建版本并提交测试申请，处理BUG；

4、测试人员维护测试视图模块，进行测试用例设计，接收与管理测试任务，提交并验证处理BUG，报表统计与文档管理等

5、BUG解决前，一般要经过项目经理先确认BUG解决优先级与对应指派的开发人员，也可由对应指派的开发人员直接解决，绽上所述有3种情况：

5-1、BUG提交后的初始状态为“激活/未确认”；

5-2、项目经理确认是个BUG，并重新定义BUG解决优先级，分派给对应开发人员修改，此时BUG状态为“激活/已确认”；

5-3、由对应指派的开发人员直接解决的BUG状态为“已解决/已确认”；

6、bug的解决方案

先来解释一下bug的解决方案，在禅道中，共有七种解决方案，分别如下：

�bydesign=>

设计如此，无需改动。

�duplicate=>

重复Bug，以前已经有同样的bug。

�external=>

外部原因，非本系统原因。

�fixed=>

已解决。

�notrepro=>

无法重现，无非重现bug。

�postponed=>

延期处理，确实是bug，但现在不解，放在以后。

�willnotfix=>

不予解决。

7、测试人员对状态为“已修复”的BUG进行复测，有以下2种情况：

7-1、复测通过后将BUG状态改为“已关闭”，并且写明在哪个版本上复测通过

7-2、复测不通过将BUG状态改为“激活”并说明复测不通过的原因及在哪个版本上复测不通过。

4.1.2使用流程图

4.2使用规范

4.2.1BUG状态

在上面的流程图中可以看出，BUG状态有激活/未确认、激活/已确认、已解决/已确认、已关闭/已确认。

4.2.2功能测试

这里的功能测试指的是区分于回归测试的一种测试过程称呼。

4.2.3回归测试

对于回归测试过程中发现的新BUG需要新建BUG报告，而不能在“问题注释”区域写新BUG内容。

4.3BUG使用权限

●项目经理：

分派、打回

●项目测试组长：

打回、新建版本号、报告、暂缓

●测试员：

报告、打回、解决

●修改员：

修改、打回

4.4报告BUG规范

●BUG摘要中必须写明版本号，对BUG的简要描述

●在报告BUG明细页面，根据第5.1章节中的BUG类别选择BUG分类

●选择BUG出现频率，不频繁出现的BUG一定要上传BUG错误截图

4.5BUG描述规范

BUG描述主体内容必须包含以下内容：

●版本号

●BUG所在的模板路径

●操作步骤（执行这些操作步骤后会产生BUG）

●现象：

BUG的具体体现

●期望：

正确的功能实现方式

5BUG说明

5.1分类说明

5.1.1按功能分类

●一致性：

即统一性，一般有功能按钮样式是否统一、提示窗口样式是否统一、相同功能实现的方式是否统一等

●功能：

功能是否正常使用

●接口：

程序功能需要依靠外部设备或功能才能实现

●文档：

文档编写是否规范，是否符合CMMIV2.0和《文档编写规范说明V2.0》规定的要求和规范

●易用性：

一般是功能操作性是否方便灵活

●用户界面：

界面风格、样式是否一致

5.1.2按严重级别分类

●致命：

功能完全不符合用户需求、功能完全未实现

●严重：

功能部分不符合用户需求、影响其它功能或模块的正常使用

●一般：

符合用户需求，功能已实现，但是在功能上通过更好的方法以提高功能的实用性

●提示：

轻微、提示性问题，不影响系统功能；

用户使用不便或者容易出现误操作

●优化：

友好性、易用性方面的改善建议，使软件可用性更强；

对某模块功能提出的质疑、改进

5.1.3按BUG修改优先级分类

●特急：

致命问题且紧急

●加急：

严重问题且比较紧急

●高：

比较严重

●中：

一般

●低：

微小

5.2BUG的界定

该章节的内容随时更新。

5.2.1功能性BUG的界定

●不符合用户需求的功能或业务

●功能未实现

●功能实现的不正常

●功能实现的不完全

●浏览器不兼容，在部分浏览器中功能实现不了

●在浏览器上可以通过非法操作访问系统：

如浏览器自带的前进、后退功能

5.2.2非功能性BUG界定

●页面风格不统一（页面、提示框中的字体大小样式不统一）

●操作不方便

●提示框中内容不统一

●功能已按客户需求实现，但是有更好的方式实现该功能

●站在易用性的角度发现功能有更好的实现方式，虽然客户对此没有需求

6测试环境控制

每次开始测试之前，项目经理须提供最新的程序包。

如果数据库有变化只能提交SQL语句。

交由项目测试组长在测试服务器上面执行。

项目测试组长不接受开发员提供的程序包和数据库，除非该开发员是由项目经理指定的。

7功能测试报告BUG统计方法及格式

7.1BUG统计方法

根据目前各个项目的功能测试报告中BUG统计不合理的情况，特意制定了一个新的能体现功能测试和回归测试发现的BUG数和（或）复测BUG数、已解决BUG数的方法。

每个阶段的BUG数统计按照项目版本区分，并且BUG数按照功能测试和回归测试分类。

●功能测试范围包括在初测阶段发现的新BUG数和回归测试中发现的新BUG数

●回归测试范围包括已解决BUG数、未解决BUG数、已关闭BUG数和已确认数

7.2BUG统计计算方法

按照版本号顺序举例说明：

●V1.0：

BUG总数=功能测试发现的BUG数

●V1.1：

1、功能测试发现的BUG数；

2、回归测试：

已解决BUG数+未解决BUG数+已关闭BUG数+已确认BUG数=V1.0功能测试BUG数。

●V1.2：

V1.2功能测试BUG数+V1.2回归测试的未解决BUG数。

这里的未解决也包括已确认的BUG。

以此类推，最终的BUG数可以按照功能测试和回归测试分开统计。

7.3BUG统计格式

版本号

功能测试

回归测试

已解决BUG数

未解决BUG数

已关闭BUG数

已确认BUG数

15

3

10

2

1

5

合计

20

8

通过上面的表格可以直观的统计出功能测试发现的BUG数及回归的BUG数。