验收测试方案.docx
- 文档编号:12407131
- 上传时间:2023-06-05
- 格式:DOCX
- 页数:10
- 大小:23.64KB
验收测试方案.docx
《验收测试方案.docx》由会员分享,可在线阅读,更多相关《验收测试方案.docx(10页珍藏版)》请在冰点文库上搜索。
验收测试方案
XXX系统
验收测试方案
XXX发展有限公司
2017年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
使用性、方便性、易用性不够
建议
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 验收 测试 方案
![提示](https://static.bingdoc.com/images/bang_tan.gif)