软件测试作业指导书.doc

软件测试作业指导书.doc

《软件测试作业指导书.doc》由会员分享，可在线阅读，更多相关《软件测试作业指导书.doc（70页珍藏版）》请在冰豆网上搜索。

软件测试作业指导书

质量控制部

2010年01月01日

目录

1．编写目的 6

2．测试团队构成 6

2.1工作职责 6

2.2角色划分 6

3．测试流程 8

3.1测试流程概述 8

3.2计划阶段 9

3.2.1组建测试团队 9

3.2.2测试预通知 10

3.2.3召开测试启动会议 10

3.2.4编写测试计划文档 10

3.3设计阶段 11

3.3.1测试需求分析 11

3.3.2测试用例设计 13

3.4实施阶段 16

3.4.1冒烟测试 16

3.4.2测试执行 16

3.5总结阶段 18

3.5.1测试结论 18

3.5.2自测质量评估 18

3.5.3环境备份 19

3.5.4用户手册 19

3.5.5测试指南 19

3.6预发布测试阶段 20

3.6.1预发布测试流程 20

3.6.2预发布测试过程 21

3.7升级测试阶段 21

3.8流程执行要点 21

4．测试规范 22

4.1测试规范概述 22

4.2计划阶段 23

4.2.1测试计划规范 23

4.2.2评审规范 25

4.3设计阶段 27

4.3.1测试需求规范 27

4.3.2测试用例规范 28

4.3.3评审规范 32

4.4实施阶段 34

4.4.1提交测试规范 34

4.4.2测试报告填写规范 34

4.4.3缺陷录入规范 35

4.4.4测试通过标准 35

4.5总结阶段 37

4.5.1测试结论编写规范 37

4.5.2自测质量评估规范 38

4.5.3测试环境备份规范 39

4.5.4用户手册维护规范 43

4.5.5测试指南编写规范 45

4.6预发布测试阶段 46

4.7升级测试阶段 46

4.7.1升级测试用例整理规范 46

4.7.2现场反馈测试报告复核规范 47

4.8现场反馈BUG分析 48

4.8.1现场反馈BUG分析职责 48

4.8.2BUG分析周期 48

4.8.3参与人员 48

4.8.4文档存放 48

4.9地区差异维护 49

4.9.1填写规范 49

4.9.2维护规则约定 49

4.9.3维护时间要求 50

4.9.4交流制度 50

4.9.5文档存放 50

5．缺陷管理 50

5.1BUG类型 50

5.2BUG严重级 51

5.3BUG优先级 51

5.4BUG处理过程 52

6．争议处理 52

7．经验分享 53

7.1.1测试环境搭建 53

7.1.2辅助测试工具 55

7.1.3经验积累 55

7.1.4测试管理 56

7.1.5测试服务器维护 60

8．标准文档 62

8.1.1文档存放标准 62

8.1.2文档配置库目录结构说明 64

文档控制页

版本号

变更日期

变更内容简述

变更人员

备注

1.0

2010-01-01

新建

褚伟

70

序言

做好测试工作，首先需要建立并维护一个高效的测试团队。

良好的制度可以规范测试工作的开展，相反，缺乏有效管理和良好的团队氛围，则可能导致凝聚力差、效率低下。

俗话说，国有国法、家有家规，一个成功的测试团队也是这样，必须有自己的规范和制度，这样才能够让整个测试团队良性运转，同时，测试人员一起遵循相同的规范可以减少不必要的沟通成本，提高工作效率。

自我们测试团队创建以来，测试已经存在了很多的规范和文档，这些规范和文档都是我们部门历任的测试工程师在工作和学习过程中不断摸索出来的经验的沉淀，是我们的宝贵财富。

但是，目前这些规范和文档相对放置的都比较散乱，同时，也缺乏一个系统的管理，如果某位测试工程师对某部分业务不熟悉或者不涉及的话某些规范和文档就无法了解到，那么，这些规范和文档也就无法彰显其存在的价值，为了让这些规范和文档能够更好的发挥它们的作用，特此编写了这份测试工作作业指导书，希望能够为所有的测试工程师的测试工作提供一些帮助和指导。

此外，该份文档还用来作为内部改进工作的参考资料，后续工作过程中随着测试技术的改进，该文档中的部分内容将会不断更新。

本文档的阅读对象为本部门所有测试工程师和其它相关人员。

1．编写目的

本文档是测试团队的日常工作指导规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作以及测试过程中应遵循的规范。

2．测试团队构成

2.1工作职责

测试是软件开发过程中的重要组成部分，肩负着如下责任：

Ø在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。

Ø编写合理的测试计划，并与项目整体计划有机地整合在一起。

Ø编写覆盖率高的测试用例。

Ø针对测试需求进行相关测试技术的研究。

Ø认真仔细地实施测试工作，并提交测试报告供项目组参考。

Ø进行缺陷跟踪与分析。

Ø为各工程点的现场测试提供帮助。

注意：

工作职责会随着整体的要求增加或减少。

2.2角色划分

在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。

测试团队角色及职责定义如下：

角色名称

相关主要责任

测试经理

l组建测试组

l协调测试组内部的沟通

l代表测试组与其他角色组进行沟通

l编写测试计划

l参与测试相关的评审工作

l测试周报反馈

l测试人员招聘及管理

测试组长

l测试项目组内测试工作分配及问题沟通

l代表所负责的测试小组与其他角色组进行沟通

l编写所负责项目的测试计划

l编写测试用例

l负责测试相关文档评审的质量控制

l实施测试用例，执行测试

l测试进度报告反馈（也可以权利下放给组内骨干测试人员）

l测试报告及测试结论发布

l自测质量评估报告填写反馈（也可以权利下放给组内骨干测试人员）

l编写用户手册

l负责协调安排所负责项目的现场反馈BUG分析工作

l地区差异文档的更新

l单个测试任务完成后组织经验交流共享

测试工程师

l编写测试用例{可以由测试经理或测试组长兼任}

l实施测试用例，执行测试

l负责测试相关文档的评审及问题改进工作

l反馈测试进度报告

l测试过程中的缺陷跟踪及沟通

l反馈测试结论及测试报告（根据测试组长的任务安排反馈自己所负责部分的测试结论）

l升级测试工作配合（测试用例整理、现场测试策略制定及现场反馈测试报告复核）

l编写用户手册

l参与现场反馈BUG分析工作

l地区差异文档的更新

l测试任务完成后共享经验和收获

3．测试流程

3.1测试流程概述

软件测试过程分成若干个阶段，每个阶段都有自己的一些特点，有些阶段虽然不是测试的主要工作体系阶段，但却是一个成功的测试不可或缺的重要组成部分。

测试的各个阶段组成一个PDCA循环整体，通过这个循环来达到提高测试质量的目的。

测试流程和开发流程相辅相成，测试工作从产品规划完成后即开始介入。

整个测试流程包括测试计划制定、测试需求分析、测试用例设计、冒烟测试、测试执行、用户手册编写和升级测试配合七个环节，在测试计划制定、测试需求分析和测试用例的设计环节中穿插评审环节，在测试执行过程中穿插缺陷跟踪环节。

注意：

PDCA循环也叫做戴明循环，是一种质量改进模型。

P代表计划，D代表执行，C代表检查，A代表处理。

3.2计划阶段

3.2.1组建测试团队

在项目组成立的同时，测试组也将同时成立。

团队成立的工作与责任如下：

过程要点

详细说明

输入条件

项目组成立（参与《项目计划书》的评审）

工作内容

为该项目的测试组任命一名测试主管，同时确定测试组的构成人选。

退出标准

测试组成立

责任人

质量经理或者测试经理

3.2.2测试预通知

在正式测试任务下达前，开发团队应提前一周左右向测试团队下达预通知，告之较为确切的测试日期，提供当前最新的相关资料。

测试部门经理可视具体情况决定是否需要调整人力。

测试人员可预先熟悉必要的背景资料，协助测试经理编写《测试计划》初稿。

过程要点

详细说明

输入条件

项目进入软件实现阶段（编码）

工作内容

项目/产品经理邮件通知测试经理正式测试交接时间，测试规模预估等

退出标准

预通知得到测试经理确认，并提交《测试计划书》初稿

责任人

产品经理，测试经理

3.2.3召开测试启动会议

过程要点

详细说明

输入条件

测试经理完成测试计划书初稿

工作内容

开发团队与测试团队交接测试内容，对测试目标达成一致，商讨测试计划初稿的可行性，统一项目组的目标和测试的工作重点。

退出标准

明确测试内容与重点，项目方提交《测试任务书》，测试方提交《测试计划》正稿。

责任人

项目经理，测试经理

3.2.4编写测试计划文档

1、测试计划制定的目的和意义

计划是关于如何做某件事情的思考。

所有胜仗未必都是有计划进行的，但是所有败仗试试没有很好计划的。

也可以把测试当作一场战争，一场对所有软件BUG展开的歼灭战。

对于这样的一场战斗，首先要考虑如何制定一种可行的计划。

项目成败由4个以上决定，而项目的4个因素由不同的文档来覆盖。

l时间：

由项目计划覆盖。

l成本：

由合同覆盖。

l范围：

由需求文档覆盖。

l质量：

由QA计划或测试计划覆盖。

测试计划通常作为质量的重要文档呈现给管理层。

测试计划通常分为内部作用和外部作用，内部作用有以下3种：

l作为测试计划的结果，让相关人员和开发人员来评审；

l存储计划执行的细节，让测试人员来进行同行评审；

l存储计划进度表、测试环境等更多的信息。

测试计划的外部作用是为顾客提供一种信心，通常向顾客交代有关测试的过程、人员的技能、资源、使用的工具等信息。

2、测试计划启动时间定义

测试计划的启动时间定义在产品规划完成后，需求文档大体定稿之前，在这个阶段基本上对于所有要测试的内容都已经基本清晰，这样定义出来的测试计划相对会比较准确。

注意：

测试计划相关规范请参考“测试规范”中的相关内容。

3.3设计阶段

3.3.1测试需求分析

1、测试需求的定义

所谓的测试需求就是在项目中要测试什么。

我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where），测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素，而测试需求是测试计划的基础与重点。

就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。

但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。

2、测试需求分析的意义

如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。

所谓知己知彼，百战不殆。

测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。

活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。

测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。

如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。

只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。

这样，我们就明白了整个测试活动的依据来源于测试需求。

3、测试需求的依据