验收测试方案样本.docx

验收测试方案样本.docx

《验收测试方案样本.docx》由会员分享，可在线阅读，更多相关《验收测试方案样本.docx（10页珍藏版）》请在冰豆网上搜索。

验收测试方案样本

XXX系统

验收测试方案

XXX发展有限公司

8月25日

1项目简介

对杰和科技GSM系统，使用客户真实场景和数据测试，覆盖所有功能与否满足需求。

客户使用真实场景和数据测试，覆盖所有功能点与否工作正常。

逐个验证系统使用手册与否有漏掉，描述与否精确。

1.1可用性测试

验证系统与否对于也许存在安全问题采用了各项相应办法，涉及软件安全和数据库安全。

测试内容如下表所示：

测试类型

测试重点

测试办法

UI测试

UI布局无错位无叠压

1、手工进行测试

2、测试时与原型与设计原图进行对比

3、参照“易用性规范”对系统进行检查

系统整体风格一致且美观

导航简朴易懂

界面文字描述对的，有关内容命名统一

各控件放置位置符合顾客使用习惯

业务交互测试

系统业务逻辑符合客户原始需求

流程简洁无冗余

逻辑清晰无歧义。

易用性测试

易理解性测试；

易学性测试；

易操作性测试；

有适合协助及错误提示

操作响应即时性（3s~5s）

国际化测试

英文语言版本界面测试

1.2容错性验证

验证系统在各种故障或意外时，与否依然可以保证系统正常工作。

测试内容如下表所示：

测试分类

测试点

测试办法

数据异常

操作异常数据或异常流程时，系统能给出提示不会浮现崩溃

　手工进行测试

违背操作流程时回绝数据进入并报错或给出有效引导

程序异常

系统卡死或进程被操作系统强行杀掉，当前操作数据与否所有丢失，流程与否被破坏无法后续操作

网络异常

数据传播时，网络浮现故障系统与否能给出提示并采用相应缓存办法

服务器异常

数据传播时，数据库服务器浮现故障系统与否能给出提示并采用相应缓存办法

环境异常

数据正在传播或是备份时，突然断电，电源恢复后系统仍能正常工作，且可恢复断电前状态。

正在传播数据时突然拔掉磁盘

1.3兼容性测试

验证系统在各种硬件环境、软件环境、不同浏览器、不同辨别率机器上使依然可以保证系统正常工作。

测试内容如下表所示：

模块

测试重点

测试办法

GSMWeb端

浏览器兼容性（IE10、IE11、Firefox43+、Chrome38+、Edge）

1、每位测试人员每轮测试都以不同机器配以不同操作系统和浏览器进行

2、重要页面用BroserShots和Viewlink.US进行测试

GSM助手

操作系统兼容性（涉及Windowsxp，windows7和windows10）

1、安装测试；

2、上传一种文献

3、同步一种文献夹

4、双击鼠标打开服务器上某个文献夹一种word文档

Androidapk

屏幕辨别率和android版本兼容性

1、分别测试720p和1080p时界面显示；

2、分别测试在Android4.4、Android5.1以及Android6.0上程序功能

1.4性能测试

通过并发顾客模仿实际生产环境压力，获得系统响应时间、服务器资源使用状况、最佳顾客及最大顾客数。

并试图寻找顾客实际遇到或也许遇到性能问题。

测试分类

测试点

测试办法

压力测试

针对每个核心功能进行单独性能测试，以得出各核心功能性能状况。

与否需要进行性能优化和配备调节。

使用Loadrunner及其他也许会使用到性能测试小工具。

负载测试

对惯用使用场景负载顾客由10个开始，每5分钟增长5个顾客直至系统无法承受。

记录硬件负载状况，从而寻找出系统最佳顾客数和最大顾客数。

稳定性测试

系统在持续压力状况下，长期运营时业务解决能力及系统与否存在内存泄露等性能问题。

将系统核心功能以比例方式进行持续8小时性能测试。

多顾客访问GSM系统

同步在线顾客为50，并发顾客为10正常使用GSM各个子系统

核心功能并发操作

并发各种顾客同步使用上传、下载、同步功能

传播效率测试

组建RAID1和RAID5时磁盘I/O读写速度；GSM各子系统上传、下载、同步速度；RAID5组建和同步完毕速度。

2测试筹划

2.1测试进度及产物

阶段

工作任务

持续时间

产物

项目启动

项目启动

一天

资源安排

测试设计

分析测试需求，整顿测试筹划与方案

三天

测试方案

测试环境

系统使用培训

测试环境、测试设备及测试数据准备

测试执行

对各模块逐个进行功能测试

五周

Bug列表

性能测试报告

交叉随机测试和回归测试

易用性测试和兼容性测试

性能测试及报告

测试报告

编写整体测试报告

二天

整体测试报告

2.2人员安排

测试团队人员安排因不同阶段而有所不同，如下是人员安排及职责阐明。

人员角色

介入阶段

人数

工作职责

测试项目组长

需求阶段开始

1人

负责所有工作指派和人员调节，监督项目测试流程进度和质量，对评测成果和报告负责，评估测试项目质量。

性能测试工程师

设计阶段开始

1人

负责设计功能及易用性测试用例，设计性能测试脚本及场景。

并负责后期有关测试执行工作。

测试工程师

执行阶段开始

3人

负责详细测试执行工作。

执行测试案例，记录案例运营成果，分析测试成果，提交缺陷报告

任务工作

测试组长

性能测试工程师

测试工程师

团队和项目管理,跟踪，规划

测试评估，方案，筹划，工期监控

任务分派

测试报告

用例详细编写

用例评审

执行测试

回归测试，缺陷跟踪

交叉测试

质量保证数据分析,纠错

2.3质量原则

测试质量合格须符合如下原则：

（产品上线五个月内所发现Bug）

A致命

B严重

C普通

D轻微

E建议优化

≤2

≤4

≤5

≤5

暂不作规定

1）为顾客或非测试人员发既有效缺陷，且改缺陷不是由需求、功能变更引起且在测试任务书规定测试内容范畴内缺陷。

2）顾客或非测试人员发既有效缺陷总数不得不不大于一定比例：

10%

顾客或非测试人员发既有效缺陷总数/测试总结报告提交有效缺陷总数×100% 

举例：

满足如下任何一条即视为测试质量不合格

Ø顾客或非测试人员发既有效A类错误>2  

Ø顾客或非测试人员发既有效B类错误>4   

Ø顾客或非测试人员发既有效缺陷总数与测试发既有效缺陷总数比例>10% 

Ø顾客或非测试人员发既有效C类错误、D类错误均>5

3项目沟通管理

3.1定期报告制度

1.报告机制

项目构成员定期向项目经理报告，原则上是每天报告一次。

项目经理每周通过周报形式将项目实际进度和人力资源投入状况向全国中小公司转让系统有关领导进行报告。

2.报告方式

采用周报方式进行报告，并通过邮件进行确认。

3.2寻常沟通记录

项目参加各方在项目进行过程中随时对有关问题进行沟通。

所有重要、有主题寻常沟通活动都应留下记录或形成备忘录。

寻常沟通重要渠道涉及：

Ø会议

Ø电话

Ø电子邮件

3.3定期例会制度

Ø评审会议：

在各个里程碑阶段召开，讨论有关输出；

Ø周例会：

每周二上午10点进行，由项目经理组织周例会，召集项目有关人员参加，以电话会议方式，总结上周开发进度，讨论本周开发筹划；

Ø风险沟通会：

当浮现较大风险时召开沟通会，讨论解决方案。

4Bug规范

4.1Bug内容描述

在Bug内容描述中需要包括如下元素：

No

元素

阐明

1

前提条件<可选>

重现问题所需要条件

2

测试环境

测试环境应涉及软硬件环境

3

测试环节

环节要尽量细化，特殊操作要描写清晰。

要可以让别人看到环节就能以便无误重现出问题。

4

预期成果

预期应用通过测试环节所能得到对的成果

5

实际成果

事实上应用通过测试环节所得到成果

6

附加信息<可选>

任何其他你以为可以协助到重现或是阐明问题其他信息。

7

附件

尽量提供问题截图或是有能力最佳能提供有关log文献。

4.2Bug严重度定义

在Bug严重级别定义如下：

Bug分级

Bug级别

Bug级别阐明

分类阐明

致命问题

Blocker

导致整个产品无法进行测试

系统无法开机或不断重启

其她导致无法测试问题

Critical

死机、数据丢失、重要功能完全丧失

运营过程中浮现一次死机、重启或系统崩溃

严重问题

Major

重要功能某些缺失或数据资料丢失

某些重要功能不能使用或某些数据资料丢失

普通问题

Normal

某些次要功能缺失，不太严重

概率性功能错误；

边界条件错误；

界面显示错误；

系统提示信息错误；

Minor

不影响系统正常使用问题

界面格式不规范；

核心操作未给顾客提示

轻微问题

Trivial

界面不美观

控件排列、格式不统一

文字排列不整洁

辅助功能描述不清

个别不影响产品使用错别字

Enhancement

使用性、以便性、易用性不够

建议