软件测试方案（整体方案）.docx

软件测试方案（整体方案）.docx

《软件测试方案（整体方案）.docx》由会员分享，可在线阅读，更多相关《软件测试方案（整体方案）.docx（25页珍藏版）》请在冰豆网上搜索。

软件测试

整体测试计划与方案

文件状态：

文件标识：

草稿

当前版本:

VI.1.1

[]正式发布

者：

马彦东

[]正在修改

I凫成目期：

2010-11-23

★★★★★

内部资料，可为以后规范测试行为使用

版本历史

版本/状态 作者参与者 起止日期 备注

1.概述 5

2.适用对象和范围 5

3.术语、名词定义 5

3.1. 系统测试 5

3.2.黑盒测试（功能测试） 5

3.3. 白盒测试 5

3.4. 灰盒测试 5

3.5.健壮性测试（容错能力/恢复能力测试） 6

3.6. 接口测试 6

3.7. 强度测试 6

3.8. 压力测试 6

3.9. 性能测试 6

3.10. 安全测试 7

3.11.可靠性测试 7

3.12. 安装/反安装测试（公司一般系统不需要进行该测试） 7

3.13. 文档测试 7

4.测试工作流程 8

4.1. 测试管理总流程 8

4.2.制定测试计划工作流程 8

4.3.设计测试用例工作流程 9

4.4. 执行测试工作流程 9

4.4.1.测试工作总体流程 9

4.4.2.单元测试工作流程 10

4.4.3.集成测试工作流程 11

4.4.4.系统测试工作流程 12

4.4.5.验收测试工作流程 14

4.5. 缺陷管理与改错流程 15

5.测试参考文档和测试提交文档 16

5.1. 测试参考文档 16

5.2. 测试提交文档 16

6.测试资源 17

6.1.人力资源 17

6.1.1.人员、角色及职责 17

6.2.测试工具 17

7.测试方法和方式 17

8.测试中断与开始的标准 18

9.测试范围与测试任务 18

9.1.测试任务 19

10.测试用例编写方案及相关约定 20

10.1. 编写原则 20

10.2. 衡量测试用例设计的质量标准 20

10.3. 测试用例管理 21

10.4. 测试用例与开发的对应关系约定 21

10.5. 测试用例类型约定 21

10.6. 测试阶段、类型与执行角色的关系约定 22

10.7. 测试用例清单 22

11.缺陷管理与改错计划 22

11.1.流程图 22

11.2.缺陷管理手段 22

11.3.缺陷管理规则 22

12.实施建议 23

附录一缺陷分类 23

附录二缺陷严重程度 24

1.概述

为了提高检测出错误的几率，使测试能有计划地、有条不紊地进行，就必须要编制测试相关文件。

而标准化的测试文件就如同一种通用的参照体系，可达到便于交流的目的。

文件中所规定的内容可以作为对测试过程完备性的对照检查表，故采用这些文件将会提高测试过程的每个阶段的能见度，极大地提高测试工作的可管理性。

2.适用对象和范围

主要针对对象为软件管理人员、软件开发人员和软件测试人员。

3.术语、名词定义

3.1.系统测试

系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。

它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对计算机系统进行的测试。

3.2.黑盒测试（功能测试）

黑盒测试是基于系统需求规格，在不知道系统或组件的内部结构的情况下进行的测试。

通常又将黑盒测试叫做：

基于规格的测试、输入输出测试、功能测试或数据驱动测试。

是基于用户观点出发的测试。

主要是验证功能是否符合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。

3.3.白盒测试

白盒测试也叫结构测试、逻辑驱动测试或给予程序的测试。

主要是分析程序的内部构造，并根据内部构造设计测试用例。

3.4.灰盒测试

可以理解为静态的白盒测试或动态的黑盒测试，灰盒就是界于黑白之间，对软件内部有所了解，但不见得到了如指掌的程度，却可以结合这些了解做些比黑盒多点的测试。

3.5.健壮性测试（容错能力/恢复能力测试）

侧重于程序容错能力的测试。

本测试在单元测试阶段和系统测试阶段都要进行。

如数据边界测试、非法数据测试、异常中断测试等等，主要是验证程序对各种异常情况是否进行正确处理。

3.6.接口测试

程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。

这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。

建议由开发人员进行。

3.7.强度测试

强度测试检查程序对异常情况的抵抗能力。

强度测试总是迫使系统在异常的资源配置下运行。

例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。

3.8.压力测试

对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。

3.9.性能测试

在交替进行负荷和强迫测试时常用的术语。

性能测试关注的是系统的整体。

它和通常所说的强度、压力/负载测试有密切关系。

所以压力和强度测试应该于性能测试一同进行。

3.10.安全测试

主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据的安全。

测试人员可以学习一些黑客技术，来对系统进行攻击。

3.11.可靠性测试

这里是比较狭义的可靠性测试，它主要是对系统能否稳定运行进行一个统计，在实际工作中如果没有条件可以不必特意去做。

重点做好与之紧密相关的功能测试、健壮性测试就可以了。

3.12.安装/反安装测试（公司一般系统不需要进行该测试）

安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后能否影响原系统；反安装是逆过程，测试是否删除干净，是否会影响原系统等。

3.13.文档测试

主要测试开发过程中针对用户的文档，以需求、用户手册等为主，检验文档是否和实际应用存在差别。

文档测试主要检查文档的正确性、完备性和可理解性。

正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。

完备性是指文档不可以“虎头蛇尾”，更不许漏掉关键内容。

文档测试不需要编写测试用例。

4.测试工作流程

4.1.测试管理总流程

4.2.制定测试计划工作流程

4.3.设计测试用例工作流程

4.4.执行测试工作流程

4.4.1.测试工作总体流程

说明：

集成测试和系统测试的反馈意见可能导致设计文档（需求或数据库）的修改。

4.4.2.单元测试工作流程

4.4.3.集成测试工作流程

4.4.4.系统测试工作流程

说明：

压力测试为模拟用户正常使用时，系统正常工作的最小时间。

（最多使用人数和数据库的极限容量）。

说明：

测试系统的崩溃极限

4.4.5.验收测试工作流程

说明：

验收测试的人员应包含非本系统的人员。

4.5.缺陷管理与改错流程

5.测试参考文档和测试提交文档

5.1.测试参考文档

下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性:

文档

（版本/日期）

上创建或可用

被接收或已经过复审

作者或来源

备注

软件需求规格说明书

是口否]]

是1]否1]

软件概要设计

是口否]]

是1]否1]

软件详细设计

是口否]]

是1]否1]

模块开发手册

是口否]]

是1]否1]

测试计划及方案

是口否]]

是1]否1]

测试报告

是口否]]

是1]否1]

用户操作手册

是口否]]

是1]否1]

安装指南

是口否]]

是1]否1]

5.2.测试提交文档

文档

（版本/日期）

已创建或可用

已被接收或已经过复审

作者或来源

备注

测试计划及方案

是1]

否[]

是[]

否[]

可考虑通过

测试用例

是[]

否[]

是[]

否[]

td产生

可考虑通过

测试报告

是[]

否[]

是[]

否[]

td产生

6.测试资源

6.1.人力资源

6.1.1.人员、角色及职责

人员

角色

职责、任务

备注

项目经理

测试小组长、

测试设计员

测试设计员

测试员

测试设计员

测试员

开发人员

6.2.测试工具

测试管理

TestDirector

MercuryInterActive

具体使用约定请参照《测试工具使用约定及软件开发与测试配合工作规范》

压力测试

LoadRunner

MercuryInterActive

功能测试

WinRunner

MercuryInterActive

XML工具

XmlSpy

解析、验证XML,通过

XSD生成XML文件

DB2数据库工具

DBTool

自产

对TIPS数据库进行操作

日志文件监控工

具

LogFileMonitor

自产

MQ队列监控工具

Monitor

自产

通过MQ的BROWSE或

GET方式监控系统信息

备注

用途

工具

生产厂商/自产 版本

7.测试方法和方式

测试方式主要以手工测试为主，在条件允许的情况下使用自动化测试工具进行测试。

测试方法

测试

覆盖率

执行人员

描述

黑盒测试

100%

测试人员

功能测试或数据驱动测试

灰盒测试

10-20%

测试或开发

人员

静态的白盒测试或动态的黑盒测试

白盒测试

5%

开发人员

结构测试或逻辑驱动测试

说明：

黑盒测试是依据用户能看到的规格说明，即针对命令、信息、报表等用户界面及体现他们的输入数据与输出数据之间的对应关系，特别是针对功能进行测试。

主要由测试小组人员完成执行黑盒测试。

黑盒测试覆盖范围

•测试用例覆盖：

测试用例的没一个用例都被测试过

•输入覆盖：

测试过程中所输入的数据或资料必须一再的试验，如在程序安装过程中

输入用户名时，测试者必须反复输入不同长度的中文、英文或数字等来做测试。

•输出覆盖：

测试过程中程序所产生的行为、反映及数据必须都一再地试验，如不同情况的对话窗口的内容、运算结果数据等都必须反复地测试审核。

8.测试中断与开始的标准

当优先级1的问题超过总体问题的1/3时

当优先级2的问题超过总体问题的1/2时

当优先级3的问题超过总体问题的3/4时

测试重新开始时的回归测试项目

9.测试范围与测试任务

根据业务需求和用例,来确定测试项