
第1章测试验收方案
1.1验收标准
1.1.1功能项测试
对软件需求规格说明书中的所有功能项进行测试。
1.1.2业务流程测试
对软件项目的典型业务流程进行测试。
1.1.3容错测试
容错测试的检查内容包括:
1) 软件对用户常见的误操作是否能进行提示;
2) 软件对用户的的操作错误和软件错误, 是否有准确、清晰的提示;
3) 软件对重要数据的删除是否有警告和确认
提示;
4) 软件是否能判断数据的有效性, 屏蔽用户的错误输入, 识别非法值, 并有相应的错误提示。
1.1.4安全性测试
安全性测试的检查内容包括:
1) 软件中的密钥是否以密文方式存储;
2) 软件是否有留痕功能, 即是否保存有用户的操作日志;
3) 软件中各种用户的权限分配是否合理。
1.1.5性能测试
对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明书中的各项性能指标。
1.1.6易用性测试
易用性测试的内容包括:
1) 软件的用户界面是否友好, 是否出现中英文混杂的界面;
2) 软件中的提示信息是否清楚、易理解, 是否存在原始的英文提示;
3) 软件中各个模块的界面风格是否一致;
4) 软件中的查询结果的输出方式是否比较直观、合理。
1.1.7适应性测试
参照用户的软、硬件使用环境和需求规格说明书中的规定, 列出开发的软件需要满足的软、硬件环境。对每个环境进行测试。
1.1.8文档测试
用户文档包括: 安装手册、操作手册和维护手册。
对用户文档测试的内容包括:
1) 操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块;
2) 用户文档描述的信息是否正确, 是否没有歧义和错误的表达;
3) 户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达;
4) 用户文档对主要功能和关键操作是否提供应用实例;
5) 用户文档是否有详细的目录表和索引表。
1.1.9用户有特别要求的测试
略
1.2测试用例编写方案及标准
1.2.1编写原则
(1)基本的原则就是:“一点多例”,就是针对一个测试点或者功能点,编写多个测试用例,从多个方面进行测试。各个部分的用例编写的都贯穿着这一基本思想。
(2)单元测试由开发人员执行,可以自身决定是否编写单元测试用例。
(3)对于每个用例事件流,测试需求的详细列表至少会包括一个测试需求。对于需求规格说明书中的功能描述,将至少派生一个测试需求。
(4) 测试项描述-简要说明测试用例所要涉及的项和特性、对于每一项、可考虑引用以下文件:需求说明书、设计说明书、用户手册、操作手册。
(5)输入说明描述-规定执行测试用例所需的各个输入。有些输入可以用值(允许适当的误差)来规定。而另一些输入,如常数表或事务文件可以用名来规定。规定所有合适的数据库、文件、终端信息传送的值。
(6)输出说明描述- 规定测试项的所有输出和特性(如:响应时间)。提供各个输出或特性的正确值。
(7)测试用例的设计,始终要考虑测试的执行,同时测试发现的问题和总结的经验也可以用来完善测试设计。
1.2.2衡量测试用例设计的质量标准
(1)可测性: 测试用例的所有步骤是可测的,测试的步骤是具体可实施后的,按照每个步骤是可以走通的。
(2)可验证: 测试的每个步骤验证点是具体、可验证的。期望结果不是抽象的描述,而是可获得的。
(3)全面性:测试执行人员,无须考虑怎么测、而是参照测试用例设计的步骤执行,测试数据的准备也要在测试设计时考虑,而且要具备高覆盖率和全面性。
1.2.3测试用例与开发的对应关系约定
| 开发阶段 | 依据文档 | 编写的用例 |
| 需求分析阶段结束后 | 需求文档 | 系统测试对应的用例 |
| 概要设计阶段结束后 | 概要设计、体系设计文档 | 集成测试对应的用例 |
| 详细设计阶段 | 详细设计文档 | 单元测试对应的用例 |
1.2.4测试用例类型约定
| 测试用例 | 对应测试类型 | 测试覆盖率(测试人员) |
| 功能测试用例 | 主要包括功能测试 | 90%~100% |
| 性能测试用例 | 性能测试、压力测试、强度测试 | 10% |
| 集成测试用例 | 接口测试、健壮性测试、可靠性测试 | 40%~50% |
| 安全测试用例 | 安全测试 | 10% |
| 用户界面测试用例 | 用户界面测试、少量功能测试 | 100% |
| 测试阶段 | 测试类型 | 执行角色 |
| 单元测试 | 主要包括功能测试 | 开发人员,测试人员可配合部分基础数据准备 |
| 集成测试 | 模块功能测试。含部分接口测试、路径测试 | 测试人员、开发人员 |
| 系统测试 | 功能测试,含部分接口测试、路径测试。 | 测试人员 |
| 验收测试 | 功能测试(含一定健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试。 | 测试人员,建议包含用户 考虑工作量可以和系统测试合并。 |
| 用户界面测试用例 | 基本同上,并包含文档测试,对于软件产品主要测试相关技术文档 | 开发人员,测试人员可配合部分基础数据准备 |
可参照测试范围-测试清单。
1.3测试策略
1.3.1数据和数据库完整性测试
| 测试目标: | [确保数据库访问方法和进程正常运行,数据不会遭到损坏] |
| 测试范围: | 据实际情况进行 |
| 技术: | [调用各个数据库访问方法和进程,并在其中填充有效的和无效的数据(或对数据的请求)。 检查数据库,确保数据已按预期的方式填充,并且所有的数据库事件已正常发生;或者检查所返回的数据,确保正当的理由检索到了正确的数据] |
| 开始标准: | |
| 完成标准: | [所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭到损坏。] |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | [测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。 进程应该以手工方式调用。 应使用小型或最小的数据库(记录的数量有限)来使所有无法接受的事件具有更大的可视度。] |
| 测试目标 | 确保接口调用的正确性 |
| 测试范围: | 所有软件接口,记录输入输出数据(短信接口、传真接口、支付接口、机票接口) |
| 技术: | 实际操作触发调用接口 |
| 开始标准: | |
| 完成标准: | |
| 测试重点和优先级: | 均为重点 |
| 需考虑的特殊事项: | 接口的条件 |
| 测试目标 | 检测需求中业务流程,数据流的正确性 |
| 测试范围: | 测试清单中所列项 |
| 技术: | [利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容: 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。 与其他网元对接测试。] |
| 开始标准: | 在完成某个集成测试时必须达到标准 各模块接口都已完成编码 |
| 完成标准: | [所计划的测试已全部执行。 所发现的缺陷已全部解决。] |
| 测试重点和优先级: | 重点:测试清单中所列项 |
| 需考虑的特殊事项: | [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)] |
| 测试目标 | 基本功能,业务流程,有效性校验等功能。 |
| 测试范围: | 测试清单中所列项 |
| 技术: | [利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容: 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。] |
| 开始标准: | [各功能项都已完成开发] |
| 完成标准: | [具体参照本文通过测试的标准。] |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | 1)功能是否符合需求 2)功能是否完整 3)功能是否有作用 4)功能是否无错误 |
| 测试目标 | [核实以下内容: 通过测试进行的浏览可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(Tab键、鼠标移动、和快捷键)的使用 窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准。] |
| 测试范围: | 测试清单中所列项 |
| 技术: | [为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。] |
| 开始标准: | |
| 完成标准: | [成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准] |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | [并不是所有定制或第三方对象的特征都可访问。] |
| 测试目标 | [核实所指定的事务或业务功能在以下情况下的性能行为: 正常的预期工作量 预期的最繁重工作量] |
| 测试范围: | 据实际情况进行 |
| 技术: | [使用为功能或业务周期测试制定的测试过程。 通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务的迭代数量。 脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准),并在多个客户机(虚拟的或实际的客户机,请参见下面的“需要考虑的特殊事项”)上重复。] |
| 开始标准: | |
| 完成标准: | [单个事务或单个用户:在每个事务所预期时间范围内成功地完成测试脚本,没有发生任何故障。] [多个事务或多个用户:在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。] |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | [综合的性能测试还包括在服务器上添加后台工作量。 可采用多种方法来执行此操作,其中包括: 直接将“事务强行分配到”服务器上,这通常以“结构化语言”(SQL)调用的形式来实现。 通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户机。此负载可通过“远程终端仿真(Remote Terminal Emulation)工具来实现。此技术还可用于在网络中加载“流量”。 使用多台实际客户机(每台客户机都运行测试脚本)在系统上添加负载。 性能测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。 性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。] |
| 测试目标 | [核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。] |
| 测试范围: | 据实际情况进行 |
| 技术: | [使用为功能或业务周期测试制定的测试。 通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务发生的次数。] |
| 开始标准: | |
| 完成标准: | [多个事务或多个用户:在可接受的时间范围内成功地完成测试,没有发生任何故障。] |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | [负载测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。 负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。] |
| 测试目标 | [核实测试对象能够在以下强度条件下正常运行,不会出现任何错误: 服务器上几乎没有或根本没有可用的内存(RAM和DASD) 连接或模拟了最大实际(实际允许)数量的客户机 多个用户对相同的数据或帐户执行相同的事务 最繁重的事务量或最差的事务组合(请参见上面的“性能测试”)。 注:强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的情况或条件。 客户机的强度测试在“配置测试”的第3.1.11节中进行了说明。] |
| 测试范围: | 据实际情况进行 |
| 技术: | [使用为性能评测或负载测试制定的测试。 要对有限的资源进行测试,就应该在一台计算机上运行测试,而且应该减少或服务器上的RAM和DASD。 对于其他强度测试,应该使用多台客户机来运行相同的测试或互补的测试,以产生最繁重的事务量或最差的事务组合。] |
| 开始标准: | |
| 完成标准: | [所计划的测试已全部执行,并且在达到或超出指定的系统时没有出现任何软件故障,或者导致系统出现故障条件的并不在指定的条件范围之内。] |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | [如果要增加网络工作强度,可能会需要使用网络工具来给网络加载消息或信息包。 应该暂时减少用于系统的DASD,以数据库可用空间的增长。 使多个客户机对相同的记录或数据帐户同时进行的访问达到同步。] |
| 测试目标 | [核实测试对象在以下高容量条件下能否正常运行: 连接或模拟了最大(实际或实际允许)数量的客户机,所有客户机在长时间内执行相同的、且情况(性能)最坏的业务功能。 已达到最大的数据库大小(实际的或按比例缩放的),而且同时执行多个查询或报表事务。] |
| 测试范围: | 据实际情况进行 |
| 技术: | [使用为性能评测或负载测试制定的测试。 应该使用多台客户机来运行相同的测试或互补的测试,以便在长时间内产生最繁重的事务量或最差的事务组合(请参见上面的“强度测试”) 创建最大的数据库大小(实际的、按比例缩放的、或填充了代表性数据的数据库),并使用多台客户机在长时间内同时运行查询和报表事务。] |
| 开始标准: | |
| 完成标准: | [所计划的测试已全部执行,而且达到或超出指定的系统时没有出现任何软件故障。] |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | [对于上述的高容量条件,哪个时间段是可以接受的时间?] |
[安全性和访问控制测试侧重于安全性的两个关键方面:
应用程序级别的安全性,包括对数据或业务功能的访问。
系统级别的安全性,包括对系统的登录或远程访问。
| 测试目标 | 应用程序级别的安全性:[核实Actor只能访问其所属用户类型已被授权访问的那些功能或数据。] 系统级别的安全性:[核实只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。] |
| 测试范围: | 据实际情况进行 |
| 技术: | 应用程序级别的安全性:[确定并列出各用户类型及其被授权访问的功能或数据。] [为各用户类型创建测试,并通过创建各用户类型所特有的事务来核实其权限。] 修改用户类型并为相同的用户重新运行测试。对于每种用户类型,确保正确地提供或拒绝了这些附加的功能或数据。 系统级别的访问:[请参见以下的“需考虑的特殊事项”。] |
| 开始标准: | |
| 完成标准: | [各种已知的Actor类型都可访问相应的功能或数据,而且所有事务都按照预期的方式运行,并在先前的应用程序功能测试中运行了所有的事务。] |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | [必须与相应的网络或系统管理员一直对系统访问权进行检查和讨论。由于此测试可能是网络管理可系统管理的职能,可能会不需要执行此测试。] |
| 测试目标 | [核实测试可在所需的硬件和软件配置中正常运行。] |
| 测试范围: | 测试清单中所列项 |
| 技术: | ✧[使用功能测试脚本。 ✧在测试过程中或在测试开始之前,打开各种与非测试对象相关的软件(例如Microsoft应用程序:Excel和Word),然后将其关闭。 ✧ 执行所选的事务,以模拟Actor与测试对象软件和非测试对象软件之间的交互。 ✧重复上述步骤,尽量减少客户机工作站上的常规可用内存。] |
| 开始标准: | |
| 完成标准: | [对于测试对象软件和非测试对象软件的各种组合,所有事务都成功完成,没有出现任何故障。] |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | ✧[需要、可以使用并可以通过桌面访问哪种非测试对象软件? ✧通常使用的是哪些应用程序? ✧应用程序正在运行什么数据?例如,在Excel中打开的大型电子表格,或是在Word中打开的100页文档。 ✧作为此测试的一部分,应将整修系统、Netware、网络服务器、数据库等都记录下来。] |
| 测试目标 | 核实在以下情况下,测试对象可正确地安装到各种所需的硬件配置中: 1.首次安装。以前从未安装过<项目名称>的新计算机 2.更新。以前安装过相同版本的<项目名称>的计算机 3.更新。以前安装过<Project Name>的较早版本的计算机安装后立即正常运行 |
| 测试范围: | 据实际 情况进行 |
| 技术: | ✧[手工开发脚本或开发自动脚本,以验证目标计算机的状况 首次安装<项目名称>从未安装过;<项目名称>安装过相同或较早的版本。 ✧启动或执行安装。 ✧使用预先确定的功能测试脚本子集来运行事务。] |
| 开始标准: | 系统可以正常运行,配置和设备齐备 |
| 完成标准: | 成功执行,没有出现任何故障。 |
| 测试重点和优先级: | |
| 需考虑的特殊事项: | [应该选择<项目名称>的哪些事务才能准确地测试出<项目名称>应用程序已经成功安装,而且没有遗漏主要的软件构件?。] |
| 测试目标 | [主要检查文档的正确性、完备性和可理解性] |
| 测试范围: | [主要测试开发过程中针对用户的文档,以需求、用户手册、安装手册等为主] |
| 技术: | 浏览 |
| 开始标准: | [相关文档评审完成] |
| 完成标准: | 没有明显的遗漏、不一致、和描述的不准确 |
| 测试重点和优先级: | [文档内容前后矛盾、描述项遗漏] |
| 需考虑的特殊事项: |
1.4.1程序
应用软件的安装程序及代码。
1.4.2需求覆盖
需求清单:
| 编号 | 功能分类 | 功能点 | 结果 | 备注 |
| 12 | 微信客户端营销服务子系统 | 主动推送 | ||
| 人工服务 | ||||
| 标准表情传递 | ||||
| 13 | 用户区域自助选择 | |||
| 14 | 在线留言支持 | |||
| 15 | 满意度调查支持 | |||
| 16 | 消息通道 | |||
| 17 | 图片传输 | |||
| 18 | 自定义菜单 | |||
| 19 | 专属渠道区分 | |||
| 20 | 消息处理子系统 | 微信或其它渠道接口适配 | ||
| 21 | 微信或其它渠道消息格式处理 | |||
| 22 | 系统配置控制 | |||
| 23 | 内部统一IM协议处理 | |||
| 24 | 消息队列处理模块 | |||
| 25 | 网络数据处理模块 | |||
| 26 | 会话映射控制模块 | |||
| 27 | 会话消息传输模块 | |||
| 28 | 坐席坐席客户端登录模块 | |||
| 29 | 客户端状态控制模块 | |||
| 30 | 图片传输处理模块 | |||
| 31 | 会话转移处理模块 | |||
| 32 | 用户session切换模块 | |||
| 33 | 会话状态控制模块 | |||
| 34 | 会话分配逻辑处理模块 | |||
| 35 | 消息加密安全通道模块 | |||
| 36 | 会话标注功能模块 | |||
| 37 | 主动请求会话模块 | |||
| 38 | 会话队列信息查看模块 | |||
| 39 | 客服代表信息查询模块 | |||
| 40 | 客服分组业务处理模块 | |||
| 41 | 分组信息查询模块 | |||
| 42 | 在线客服信息查看模块 | |||
| 43 | 知识库接口处理模块 | |||
| 44 | 配置管理模块 | |||
| 45 | 日志处理模块 | |||
| 46 | 会话记录模块 | |||
| 47 | 分层接入处理模块(黑名单等) | |||
| 48 | 消息处理模块 | |||
| 49 | 业务流程解析模块 | |||
| 50 | 自动应答业务逻辑 | |||
| 51 | 知识库内部接口处理以及与智能语义识别机器人对接 | |||
| 52 | 可视化导航流程解析逻辑 | |||
| 53 | 客户Rich消息处理 | |||
| 54 | 回复消息的Rich协议转换 | |||
| 55 | 系统消息发送模块 | |||
| 56 | 消息路由处理模块 | |||
| 57 | 客服接续 | |||
| 58 | 接入与分配 | |||
| 59 | 客服机器人 | |||
| 60 | 服务端配置 |
| 61 | 客服子系统 | 标注会话 | ||
| 62 | 文字编辑 | |||
| 63 | 表情选择 | |||
| 屏幕截图 | ||||
| 65 | 知识检索 | |||
| 66 | 消息提醒 | |||
| 67 | 消息置顶 | |||
| 68 | 会话切换 | |||
| 69 | 历史会话查看 | |||
| 70 | 当前客户资料 | |||
| 71 | 客户信息列表 | |||
| 72 | 信息采集 | |||
| 73 | 快捷回复 | |||
| 74 | 会话标记 | |||
| 75 | 常见问题反馈 | |||
| 76 | 恶意用户举报 | |||
| 77 | 快捷键 | |||
| 78 | 会话记录 | |||
| 79 | 质检管理 | |||
| 80 | 客服主动外呼客户 | |||
| 81 | QQ绑定和解绑 | |||
| 82 | 微信绑定和解绑 |
| 83 | 运营管理子系统 | 营销任务管理 | ||
| 84 | 任务审核 | |||
| 85 | 任务执行和监控 | |||
| 86 | 管理配置信息 | |||
| 87 | 留言总览 | |||
| 88 | 留言查询 | |||
| 留言处理 | ||||
| 90 | 留言提醒 | |||
| 91 | 可视化导航配置 | |||
| 92 | 组织架构管理 | |||
| 93 | 业务参数配置 | |||
| 94 | 系统管理 | |||
| 95 | 客户分组管理 | |||
| 96 | 黑名单管理 | |||
| 97 | 来话原因维护 | |||
| 98 | 质检管理 | |||
| 99 | 售前渠道接入 | |||
| 100 | 报表子系统 | 系统汇总报表 | ||
| 101 | 上周月受理类型统计 | |||
| 102 | 人工服务类型报表 | |||
| 103 | 客户来源报表 | |||
| 104 | 受理类型统计 | |||
| 105 | 个人工作统计报表 | |||
| 106 | 客服工作统计 | |||
| 107 | 满意度评价表 | |||
| 108 | 客服满意度评价报表 | |||
| 109 | 客服登录时间统计 | |||
| 110 | 新增好友数量 |
| 128 | 系统接口 | 与微信接入接口 | ||
| 129 | 与网银接入接口 | |||
| 130 | 其它渠道服务端接口 | |||
| 131 | 智能语义识别接口 | |||
| 132 | 知识库接口 | |||
| 133 | 坐席客户端和服务端接口 | |||
| 134 | 内部统一消息接口 |
项目文档清单如下:
| 编号 | 名称 | 形式 | 介质 |
| 1 | 项目开发计划 | 文档 | 电子、纸质 |
| 2 | 软件需求说明书 | 文档 | 电子、纸质 |
| 3 | 系统概要设计说明书 | 文档 | 电子、纸质 |
| 4 | 总体设计说明书 | 文档 | 电子、纸质 |
| 5 | 数据库设计说明书 | 文档 | 电子、纸质 |
| 6 | 详细设计文档 | 文档 | 电子、纸质 |
| 7 | 验收测试报告 | 文档 | 电子、纸质 |
| 8 | 项目实施报告 | 文档 | 电子、纸质 |
| 9 | 操作手册 | 文档 | 电子、纸质 |
| 10 | 应用软件清单 | 文档 | 电子、纸质 |
| 11 | 项目总结报告 | 文档 | 电子、纸质 |
| 用途 | 工具 | 生产厂商/自产 | 版本 | 备注 |
| 缺陷管理工具 | JIRA | |||
| 性能测试 | LoadRunner | Mercury InterActive | 8.0 |
1. 项目组按计划完成项目,将要提交的软件作品安装于指定电脑,并完成调试。
2. 完成试点单位的培训实施上线,检查人员根据需求功能实现情况进行验收评价。
1.7成绩评定标准
1.优秀
1)材料完整
2)软件可正常运行
3)实现项目软件需求说明书要求的各项功能需求
4)软件界面友好,易于交互
5)软件功能新颖,有较强创新
2.合格
1)本标准第3条要求的材料完整
2)可正常运行实现功能达到软件需求说明书要求的三分之二以上
3.不合格
1)标准第3条要求的材料不完整
2)软件不能运行
3) 软件需求说明书要求的主要功能
第2章技术服务方案
2.1服务范围
在项目验收后,xxx信息技术有限公司承诺将提供一年的免费软件维护,在不新增加需求的情况下,原有设计或程序中的的缺陷将获得免费的补丁进行修正。并对软件的使用、维护提供免费的技术支持。
保修期结束后,甲方和乙方签订维保协议,共同商定乙方应提供的软硬件系统的服务支持方式、内容、费用。
如需要对系统进行审计,xxx信息技术有限公司将对系统的升级发展做出说明。
xxx信息技术有限公司会按xxx银行的需求进行产品开发,如果有遗漏,则必须由xxx信息技术有限公司无条件补足,且不另外收取任何费用。
xxx信息技术有限公司会在保修期(一年)内免费提供最新软件版本的升级(不包含新功能)。
产品生命期内,由于xxx信息技术有限公司的软件的缺陷或不完善等原因造成需要软件打补丁、软件更新或升级,xxx信息技术有限公司不会收取任何费用。
2.2服务方式及内容
2.2.1驻场+现场服务
xxx信息技术有限公司提供驻场及现场服务,解决xxx银行在线客服平台系统在上线前、试运行及终验后出现的问题,内容如下:
1、平台开发期间3个月在民生场地驻场办公
2、提供现场平台操作培训服务
3、负责所提供的软件系统现场安装设计、安装施工的督导工作
4、在xxx银行网络和设备扩容,xxx信息技术有限公司须根据xxx银行要求派技术人员到场指导
5、试运行期间出现的系统故障,xxx信息技术有限公司在接到通知后2小时到现场,5小时处理完毕,恢复系统无故障运行,并交给xxx银行详细的故障处理分析报告。该报告将视为试运行期间的统计报告,作为日后确定是否结束试运行的依据之一。
6、系统验收完毕后,出现重大系统故障,xxx信息技术有限公司会在1小时响应,3小时到现场,恢复系统无故障运行,并交给xxx银行社交网络客户服务详细的故障处理分析报告。
2.2.2远程支持
xxx信息技术有限公司提供的远程支持服务内容如下:
1、xxx信息技术有限公司提供7×24小时技术服务,安排多人轮流进行平台的日常巡检服务, 因公司的相关人员都在深圳本地,若需要则可以按照民生规定的时间要求到达现场提供现场服务
2、平台升级、bug处理等操作可通过远程操作完成
3、系统验收完毕后,xxx信息技术有限公司及时解决系统中存在的各种问题,免费维修或修改bug。
4、xxx信息技术有限公司在保修期内软件免费升级服务
2.3故障处理流程
说明:
1、客户/客户/客服/运维人员提出系统存在的问题或操作上的问题
2、民生保障组负责收集相关报障,并分发给云软公司的维护组
3、若为操作问题,则维护组人员直接解答给保障组人员,由保障组人员反馈给报障人员
4、若为系统问题,则维护组反馈给开发组,开发组处理问题并准备补丁升级,开发组再将补丁给到维护组
5、维护组通知民生保障组,并确认补丁升级时间,同时给出故障报告
6、保障组将问题解决情况反馈给报障人员
7、维护组根据约定时间进行补丁升级,升级成功后通知保障组升级成功
2.4软件升级
说明:
系统软件升级将会严格按照民生内部规定进行
1)在具备升级条件前2周提交升级申请
2)民生体系内审核
3)审批通过后项目经理升级当晚通知相关人员(包括台上座席等)
4)项目经理实施升级操作
5)升级完成后发送升级报告给民生相关项目组成员
第3章技术培训方案
3.1培训的对象及目标
●培训对象:
客服人员:与客户进行会话的人员
管理人员:台上座席或业务管理人员
运维支撑人员:负责平台日常正常运行的人员
业务人员:负责业务推广的人员
●培训目标:
通过专业人员培训指导下,达到如下目标:
1)相关人员掌握平台的操作,以便社交化只能服务平台能够顺利运行;
2)客服人员能够熟练的操作客服端相关功能,如:会话信息发送、回复语使用等;
3)管理人员能够熟悉掌握通过运营管理子系统的使用,如:查看相关的考勤统计、配置回复语等功能;
4)运维支撑人员能够熟练的通过运营管理子系统配置业务基本配置,系统平台硬件环境结构有所了解,使维护人员达到对整个系统的日常运行管理、维护、优化系统的水平,如:熟练配置客服开通地、组织结构、系统故障基本排查等;
5)业务人员能够熟练的通过运营管理子系统查看报表,配置营销信息
3.2培训时间及人数
时间:
客服人员培训:5人天
管理人员培训:2人天
运维支撑人员培训:6人天
业务人员培训:2人天
人数:
客服人数:30人
管理人员:4人
运营支撑:2人
业务人员:2人
3.3培训方式及内容
培训方式:
●现场培训
针对客服人员、管理人员、业务人员在民生场地进行培训指导,主要的培训内容包括:
1)客服人员:针对客服端系统操作功能进行培训,包括基本会话、客户切换、会话转接、回复语使、快捷方式使用等操作进行培训
2)管理人员:针对运营管理子系统界面操作进行培训,包括绩效考核统计、回复语管理、质检管理等操作进行培训
3)业务人员:针对运营管理子系统中业务人员相关的操作进行培训,包括系统业务报表、营销任务配置等操作进行培训
●常规培训:
针对运维支撑人员在民生场地进行的常规培训,主要内容包括:
1)针对运营管理子系统界面操作进行培训,包括系统运营的基础数据配置、用户权限管理等操作进行培训
2)培训如何根据系统统计数据调整系统相关工作参数,包括数据库数据文件增加、系统报警日志处理等
3)针对常见基本操作及故障进行培训,使运维支撑人员能够针对常见故障及问题进行初步判断
