系统测试方案指引Word文档格式.docx

系统测试方案指引Word文档格式.docx

《系统测试方案指引Word文档格式.docx》由会员分享，可在线阅读，更多相关《系统测试方案指引Word文档格式.docx（16页珍藏版）》请在冰豆网上搜索。

2.8.2

2.8.3

2.8.4

2.8.5

2.8.6

2.8.7易用性测试..........................................................................................9功能测试............................................................................................10文档测试............................................................................................10安全性测试.........................................................................................11性能测试............................................................................................12数据测试............................................................................................13可扩展性测试.....................................................................................14

XXX项目测试方案1概述

1.1引言

本文档包含针对XXX项目的全面的测试方案,给出了对测试相关的文档指引，是完成XXX项目测试的指导性文件

1.2参考资料

参考资料如下:

1、软件评测师教程

2、软件工程

1.3项目简介

简单介绍项目

2系统测试

2.1概述

2.1.1范围

本测试计划是针对《XXX项目》中规定内容的测试计划，包括：

相关文档的测试

系统的功能的测试

数据和存储处理

应用软件对操作人员身份和权限验证

对非正常掉电、关机或其它软硬件故障具有一定的保护和恢复功能

启动任何一个有潜在风险的功能，对误操作造成不可恢复错误有一定的防

范机制

权限管理体系

安全性测试

2.1.2限制条件

本测试计划受限于产品开发人员提交测试的内容和时间的事实。

根据开发人员提交模块的实际情况，本计划会做出相应修改。

2.1.3参考文档

2.2约定

2.2.1测试目标

通过测试，达到以下目标：

测试已实现的产品是否达到设计的要求，包括：

各个功能点是否以实现，业务流程

是否正确。

产品规定的操作和运行稳定。

Bug数和缺陷率控制在可接收的范围之内（少于5/1000非严重问题）。

目的是为判定该系统是否满足《需求规格说明书》中规定的功能与性能指标提供客

观的依据。

2.2.2测试环境

2.2.2.1硬件环境

根据项目填写实际的硬件环境

2.2.2.2软件环境

根据项目填写实际的软件环境

2.2.2.3测试工具

根据项目填写实际的测试工具

示例：

TestDirector8.0工具来辅助对测试活动的管理和缺陷管理。

（填写实际中用到的工具）Winrunner等自动化工具来辅助自动化测试

LoadRunner8.0工具来辅助负载（压力）测试。

2.2.3送测要求

（即提交测试的标准,根据项目的实际情况定,会在V3.0版本在更新）

2.2.4文档命名规范

针对软件开发和测试相关内容和文档命名规范

具体内容和模板参看：

/测试/文档命名规范目录下的相关文档

2.3组织机构

2.3.1角色与职责

XXX项目测试过程参与者的角色,职责及其应具备的技能如下:

2.3.2培训

2.3.2.1系统业务知识培训2.3.2.2测试过程（流程）培训2.3.2.3工具培训2.3.2.4技术培训

根据实际情况来定夺

2.4测试计划和进度

根据开发计划制定详细的测试计划

2.5测试流程

2.5.1测试类型

2.5.2验收标准

在此规定用于确定测试任务是否完成的验收标准。

如一：

功能完备,满足用户需求

如二:

测试用例执行率要达到100%，测试用例的通过率要达到80%。

如三:

测试用例的覆盖率达到用户提出的主要功能点的百分率。

如四：

测试用例执行率要达到100%，再提供一次回归测试。

2.6可交付成果

规定本测试项目的可交付成果,如:

测试方案、测试计划、测试用例、测试报告、缺陷报告、操作手册

2.7预测风险

本次测试过程中，可能出现的风险如下：

bug的修复情况

模块功能的实现情况

系统整体功能的实现情况

代码的编写质量

人员经验以及对软件的熟悉度

开发人员、测试人员关于项目约定的执行情况

2.8测试内容

2.8.1易用性测试

易用性遵循三个基本原则:

1、易理解性

2、易学习性

3、易操作性

具体的细节测试逐步补充完善

易用性测试用例

2.8.2功能测试

主要体现在一下五个方面:

1、适合性

2、准确性

3、互操作性

4、依从性

5、安全性

软件所实现的功能达到它的设计规范和满足用户需求的程序.

2.8.3文档测试

用户文档包含了产品使用所需的信息，具有正确的信息，无歧异和错误的表达，便于用户要阅读使用。

文档测试用例：

2.8.4安全性测试

依据软件测试的标准，安全性测试应该包括以下几个方面：

系统网络的安全性、用户认证的安全性和数据库安全性。

2.8.4.1用户认证安全性测试

对系统权限测试，系统不可出现权限混乱，不同级别的用户执行操作的界面不

同。

系统不会出现同名用户冲突现象，在用户注册时，系统自动测试，对于同名的

注册，系统拒绝注册。

用户登录密码是否可见，是否可以复制。

对通过绝对路径登陆系统，系统拒绝登录。

用户退出系统后，不可再通过后退键再进入系统。

2.8.4.2数据库安全测试

数据是否机密

系统数据的完整性

系统数据的可管理性

系统数据的独立性

系统数据可备份和恢复能力

2.8.5性能测试

2.8.5.1测试内容

基本能力测试

模拟系统运行的业务压力和使用场景

系统的性能是否满足要求

测试参数响应时间（最小响应时间、平均响应时间、最大响应时间）是否符合需求响应时间：

用户所能感受到的响应时间，也是用户最重视的性能体验。

确立响应时间的原则：

2/5/10原则

2：

2秒钟用户会觉得是一个很好的体验。

5：

5秒钟用户可能会觉得差了一点，还行，比较好。

10：

10秒钟是用户所能承受的最大极限。

鉴于不同地区的网络环境，将用户所能承受的响应时间极限定为12～15秒。

负载测试

服务器端在高负载情况下的性能行为表现。

负载可以是最大用户数，交易数，事务

数等

系统的处理极限

容量测试

可处理同时在线的最大用户数

系统的最大吞吐量

最大并发数

压力测试

在一定的饱和状态下，系统是否会出现错误

查找系统的瓶颈

不能接受的性能点

疲劳强度测试

支持的最大并发用户数或者日常运行用户数

处理最大工作强度性能

大数据量测试

系统存储、传输、统计、查询等业务进行独立的大数据量测试

压力性能测试、负载性能测试、疲劳性能测试相结合进行综合数据量测试并发性测试

XXX项目测试方案系统是否存在内存泄漏

是否存在线程锁

资源竞争

性能测试的内容比较广泛,现在主要只列举一些平常工作中比较多的监控指标:

最大并发用户数

业务操作响应时间

服务器资源监控指标

内存

处理器

磁盘I/O

数据库相应的指标等

（性能测试是一个比较深的测试工作,需要更加深的研究和实践才能做的更好）

2.8.6数据测试

2.8.6.1大数据量测试

2.8.6.2SQL执行效率测试

宏观:

大数量执行sql语句,查看执行时间日志,用profile工具计算平均值等微观:

跟踪oracle执行计划看sql经过哪些分区,哪些索引,多少次全表扫描等.

2.8.7可扩展性测试

可扩展性测试是测试系统是否具有升级的空间，以及升级后对前版本的兼容情况。

可扩展性测试用例：

2.8.8可靠性测试

可靠性指在规定的时间和条件下,软件所能维持其性能水平的程度,主要体现3个方面:

1、成熟性

2、容错性

3、易恢复性

软件可靠性测试，主要是在实验室内仿真环境下进行，可以根据需要和可能在用户现场进行

验证软件可靠性满足一定的要求：

通过对软件可靠性测试中观测到的失效情况

进行分析，可以验证软件可靠性的定量要求是否得到满足

估计、预计软件可靠性水平：

通过对软件可靠性测试中观测到的失效数据进行

分析，可以评估当前软件可靠性的水平，预测未来可能达到的水平。

软件可靠性测试活动

测试数据：

系统的输入值用其按时间的分布或按它们在可能输入范围内的出现

概率的分布。

测试环境的准备：

需要软件的可靠性仿真测试环境。

测试运行：

在真实的测试环境或可靠性仿真测试环境中，对软件进行测试。

可靠性数据收集：

收集的数据包括软件的输入数据、输出结果，以便进行失效分

析和进行回归测试；

软件运行时间数据，可以是CPU执行时间、日历时间、时

钟时间等；

可靠性失效数据包括每次失效发生的时间或一段时间内发生的失效

数，失效数据可以实时分析得到，也可以事后分析得到。

可靠性数据分析：

失效分析根据运行结果判断软件时候失效，以及失效后果、原

因等；

可靠性分析根据失效数据，估计软件的可靠性水平，预计可能达到的水平。

失效纠正：

如果软件的运行结果与需求不一致，通过失效分析，找到并纠正引起

失效的程序中的缺陷，从而实现软件可靠性的增长。

2.8.8.1成熟性测试用例

主要体现在:

初期故障率2.8.8.2容错性测试用例

2.8.8.3易恢复性测试用例

平均失效恢复时间2.9测试关键过程域

在网上看到一些有用的资料整理如下（实际工作中也是根据这个来进行的）:

完成XXX项目测试的关键过程域包括：

测试计划制订；

测试用例设计；

测试环境准备；

测试执行；

测试结果分析；

测试情况汇报。

2.9.1测试计划制订

在此规定本项目的测试计划制订的步骤。

示例:

根据[项目名称]的业务需求和技术需求，确定测试的具体内容；

对测试内容进行评审并制订测试需求；

XXX项目测试方案根据测试需求，识别不同的测试过程以及测试条件，针对每个测试过程规定测试数

据的数量并对其特征进行规定，即对测试用例进行描述；

识别项目活动，定义输出成果，估算每项活动所需的时间；

识别项目风险，并确定应对策略；

综合有关内容，确定阶段目标，并形成测试计划；

对测试计划进行评审、修改，直至测试计划获得批准；

将测试计划分发给有关人员。

2.9.2测试用例设计

在此规定将如何进行测试用例开发。

根据测试计划中测试决策树的规定，按测试意图对每一个测试点分别设计在不同情

况下的测试动作、输入和预期的反映；

形成测试用例列表；

对测试用例列表的覆盖度进行检查，完善后形成测试用例；

对于自动测试，还需根据手工测试用例修改成自动测试用例。

2.9.3测试环境准备

在此规定为确保测试执行得以顺利进行所需的任何有关测试环境方面的准备活动。

示例：

准备硬件设备；

安装软件；

配置网络环境。

2.9.4测试执行

在此规定测试执行活动。

这些活动将使用根据测试计划制作的测试用例。

根据测试计划中有关测试环境的内容，检查测试环境（包括硬件及软件），确保测

试环境符合要求；

对于测试用例的描述信息，按测试意图为每一个测试用例设计其操作流程中重要环

节的动作、输入数据和预期的反映（注：

此流程可不必详细到每一个具体的步骤，但应确保测试执行人员可以据此信息顺利执行，而不必询问测试用例的开发人员）；

执行测试活动，并记录所使用的机器及执行日期，对于每个测试用例还应记录关键

操作步骤、输入数据以及任何与测试人员预期结果不符的系统响应；

每个测试用例执行完毕后，视具体情况对系统进行备份或根据备份数据对系统进行

恢复。

2.9.5测试结果分析

在此对测试结果进行评估，并将这些结果与验收标准（在测试计划中事先设定）进行比较。

在本项目中，测试工作应遵循如下主要步骤：

对记录的测试结果数据进行分析；

对于存在问题的数据，分析判断产生问题的原因；

由于测试用例开发过程不合理产生的原因，提出测试用例开发过程修订建议，并记

录相关数据；

由于测试执行方面的原因，提出测试用例开发过程修订建议，并记录相关数据；

由于被测软件的原因，将此情况记录在缺陷跟踪及管理系统中；

（该过程域是对测

试结果进行分析，软件有问题属于记录缺陷而不是分析缺陷）

根据测试结果数据计算各种度量值；

对各种度量值进行说明，给出明确的结果分析意见及有关建议。

2.9.6进行情况汇报

在此规定测试组通过什么形式将测试情况汇报给管理层、应用开发组以及用户。

在该报告中，测试组将给出测试结论及建议。

每周五给应用开发组反馈一周测试情况和缺陷报告，给管理者提交测试计划执行情

况的报告。