测试用例报告_应用处.docVIP

一 总体概述 共有两个测试项目：1 ERP系统运维事件管理项目，负责处理ERP故障服务申请、值集申请2 程序变更管理项目，负责处理报表/功能及Bug开发申请、Form申请、Link申请、环境克隆申请的处理。 信息部成员登陆地址：3/scripts/texcel/ServiceWise/ServiceWise.dll 登录用户名（密码与登录名相同） 秦红艳：qinhy 邢永芳：xingyf 吕庆梅：lvqm 雍超：yongc 王俊：wangjun 张强：zhangqiang 袁海娟：yuanhj3 通过Web地址登录客户端： 登录后进入客户端首页，在首页上面，可以看到信息部成员参与的项目，信息部的公告等。 在信息部成员客户端，信息部成员可以查看所有最终用户提交的事件，对事件进行处理；可以管理最终用户的信息；可以定义并查看相应的报表；可以按照权限建立和搜索知识库等。 二 ERP系统运维事件管理项目 ERP系统运维事件管理项目负责ERP系统的日常维护工作及值集申请。参与的人员涉及到：应用处、系统处及网络处。在这个项目中，事件的处理工作流程如下图所示：所有的事件提交时都处于新提交事件这个状态，然后分配事件的负责人并将事件推进到处理中状态，处理完成通知关键用户，如果事件不能解决，可以提交问题或者变更处理。 1 ERP故障事件 当ERP关键用户在自助服务平台提交了一个ERP故障服务请求时，信息部成员可以在事件视图中查看到这个服务请求。 当前的设置是这样的：所有的服务请求都默认分配到了{+待分配的新建事件}这个分组中，由信息部成员统一指定处理的负责人进行处理；日后我们会按照提交人所在公司和事件发生的模块信息，匹配负责人，进行自动分配。 那么通过对负责人搜索，查找{+待分配的新建事件}就可以看到所有新提交但未分配的事件。 点击到一个事件为例，我们可以看到关键用户填写的相关事件信息，这时由信息部成员判断事件的影响程度、故障类别的信息。 并且通过改变工作流的状态至故障事件处理操作，由统一的接口人将事件分配给对应的人员处理。 这样当相应的负责人登录信息后，就可以在事件视图下面看到自己要处理的事件。 当负责人发现，此事件是其他人负责的，可以通过递交操作改变负责人 。 同时，如果这个事件处理需要系统处或者网络处完成，那么也可以通过递交操作改变负责人，递交此事件给系统处或网络处的相关人员。需要系统处帮助解决的话，递交到{+系统处待处理ERP故障事件}这个分组中即可。 当系统处或网络处处理完成，需要再递交给应用处人员，由应用处统一通知关键用户。 注：递交操作并不改变此事件的当前状态，只是负责人的递交。 当事件处理完成后，通过改变事件的工作流状态，就可以将此事件的状态改成已解决，同时事件处理的过程要在工作描述中进行记录。 在历史信息页签下，可以查看事件的处理过程，相关信息的变更日志。 在子事件页签下面，可以查看关键用户提交的相关文档。 同时如果当前负责人需要提交或上传与此事件相关的文档，也可以通过新建子事件完成。子事件类型选择上传文档附件类型。 在关键用户信息页签下面，可以看到ERP关键用户的相关信息。 2 值集申请处理 值集申请的处理过程同ERP故障事件处理流程类似，只是对应的事件类型不同，值集申请记录的信息不同。其他请参考ERP故障事件处理说明。 三 程序变更管理项目 在程序变更管理项目中，主要负责两类事件的处理：报表/功能及Bug开发及Form申请、Link申请、环境克隆申请。事件的处理流程如下图所示：由最终用户提交新的需求后，我们按照事件的类型按不同的流程来处理。参与的人员：应用处、系统处。 报表/功能及Bug开发申请由应用处进行审批，如果不需要开发，需将反馈意见返回给关键用户，如果需要开发，由外部实施商开发解决；开发完成后，外部实施商需要提交相应的开发文档，然后由应用处进行功能测试复核，通过则提交给系统处进行正式环境安装，不通过则重新开发；正式环境安装过程中，由系统处进行规范审核，不通过重新开发，通过后进行备份然后发布。完成发布后再提交给应用处进行验证，至此一个程序变更的流程完成。 在发布过程中，如果发现有问题，即进行回滚，此次发布无效，则重新开发；如果发布后，在关键用户使用过程中发现问题，关键用户通知应用处，应用处会通知系统处然后进行回滚，回滚后打回开发重新处理。 其中涉及到黑名单处理问题：在系统处负责的发布过程中，当系统处进行规范审核时，如果规范审核不通过，则打回开发重新解决，此时如果是紧急发布，应用处可以提出发布黑名单处理；如果测试通过，正常备份，发布；不过此时的发布是属于黑名单状态发布，发布完成后还需要重新回到开发解决进行重新开放解决黑名单问题才能完成关闭这个开发。 在程序变更开发过程中，如果外部实施商需要某些代码授权、访问DB、环境克