验收测试实施方案

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上的程序功能通过并发用户模拟实际生产环境压力，获得系统响应时间、服务器资源使用情况、最佳用户及最大用户数.并试图寻找用户实际遇到或可能遇到的性能问题.测试分类测试点测试方法压力测试针对每个核心功能进行单独的性能测试，以得出各核心功能的性能情况。是否需要进行性能优化和配置调整.使用Loadrunner及其它可能会使用到的性能测试小工具。负载测试对常用的使用场景负载用户由10个开始，每5分钟增加5个用户直至系统无法承受。记录硬件的负载情况，从而寻找出系统的最佳用户数和最大用户数.稳定性测试系统在持续的压力情况下，长期运行时的业务处理能力及系统是否存在内存泄露等性能问题。将系统的核心功能以百分比方式进行持续8小时的性能测试。多用户访问GSM系统同时在线用户为50，并发用户为10正常使用GSM各个子系统核心功能的并发操作并发多个用户同时使用上传、下载、同步功能传输效率测试组建RAID1和RAID5时的磁盘I/O读写速度；GSM各子系统上传、下载、同步的速度；RAID5组建和同步完成的速度。2测试计划2.1测试进度及产物阶段工作任务持续时间产物项目启动项目启动一天资源安排测试设计分析测试需求，整理测试计划与方案三天测试方案测试环境系统使用培训测试环境、测试设备及测试数据准备测试执行对各模块逐一进行功能测试五周Bug列表性能测试报告交叉随机测试和回归测试易用性测试和兼容性测试性能测试及报告测试报告编写整体测试报告二天整体测试报告测试团队人员安排因不同的阶段而有所不同，以下是人员安排及职责说明.人员角色介入阶段人数工作职责测试项目组长需求阶段开始1人负责所有工作的指派和人员调整,监督项目的测试流程进度和质量，对评测结果和报告负责，评估测试项目质量。性能测试工程师设计阶段开始1人负责设计功能及易用性测试用例,设计性能测试脚本及场景.并负责后期相关的测试执行工作.测试工程师执行阶段开始3人负责具体的测试执行工作。执行测试案例，记录案例运行结果，分析测试结果，提交缺陷报告任务工作测试组长性能测试工程师测试工程师团队和项目管理,跟踪,规划测试评估,方案,计划,工期监控任务分配测试报告用例详细编写用例评审执行测试回归测试,缺陷跟踪交叉测试质量保证数据分析,纠错测试质量合格须符合以下标准：（产品上线五个月内所发现的Bug）A致命的B严重的C一般的D轻微的E建议优化的≤2≤4≤5≤5暂不作要求1）为用户或非测试人员发现的有效缺陷，且改缺陷不是由需求、功能的变更引起的且在测试任务书规定的测试内容范围内的缺陷。

2)用户或非测试人员发现的有效缺陷的总数不得大于一定的比例:10％用户或非测试人员发现的有效缺陷的总数/测试总结报告提交有效缺陷总数×100%

举例：满足以下任何一条即视为测试质量不合格用户或非测试人员发现的有效A类错误>2

用户或非测试人员发现的有效B类错误>4

用户或非测试人员发现的有效缺陷的总数与测试发现的有效缺陷总数的比例>10％

用户或非测试人员发现的有效C类错误、D类错误均>53项目沟通管理3.1定期汇报制度1.汇报机制项目组成员定期向项目经理汇报，原则上是每天汇报一次。项目经理每周通过周报的形式将项目实际进度和人力资源投入情况向全国中小企业转让系统相关领导进行汇报。2.报告方式采用周报的方式进行汇报，并通过邮件进行确认。3.2日常沟通记录项目参加各方在项目进行过程中随时对相关问题进行沟通.所有重要的、有主题的日常沟通活动都应留下记录或形成备忘录.日常沟通的主要渠道包括：会议电话电子邮件3。3定期例会制度评审会议：在各个里程碑阶段召开，讨论相关输出；周例会：每周二上午10点进行,由项目经理组织周例会，召集项目相关人员参加，以电话会议的方式,总结上周开发进度，讨论本周开发计划；风险沟通会：当出现较大风险时召开沟通会，讨论解决方案。4Bug规范4.1Bug内容描述在Bug的内容描述中需要包含以下元素:No元素说明1前提条件<可选〉重现问题所需要的条件2测试环境测试环境应包括软硬件环境3测试步骤步骤要尽量细化，特殊操作要描写清楚。要能够让别人看到步骤就能方便无误的重现出问题。4预期结果预期应用通过测试步骤所能得到的正确结果5实际结果实际上应用通过测试步骤所得到的结果6附加信息<可选〉任何其它你认为能够帮助到重现或是说明问题的其它信息。7附件尽量提供问题的截图或是有能力最好能提供相关的log文件。在Bug的严重级别定义如下：Bug分级Bug等级Bug等级说明分类说明致命问题Blocker导致整个产品无法进行测试系统无法开机或不停重启其他导致无法测试的问题Critical死机、数据丢失、主要功能完全丧失运行过程中出现一次死机、重启或系统崩溃严重问题Major主要功能部分缺失或数据资料丢失部分主要功能不能使用或部分数据资料丢失一般问题Normal部分次要功能缺失，不太严重概率性