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

一 总体概述共有两个测试项目：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、环境克隆申请，即可以通过提交Form/Link/环境克隆申请完成，由应用处进行审批，统一授权后，由系统处开通路径完成此操作。1 报表/功能及Bug开发申请关键用户在自助服务平台提交了开发申请后，信息部成员可以在客户端查看到此申请。同时在描述信息中，可以看到变更的相关信息，例如应用模块，使用的请求组名称等。然后按照工作流程的定义，将此变更推进到报表/功能及Bug开发申请的流程中。应用处成员判断是否需要开发，如果需要开发，将事件状态改为开发受理（提交开发）。由外部实施商进行开发，开发完成，提交开发文档，进行用户测试。提交文档及用户测试，通过子事件完成，在开发过程中，系统会创建出开发完成-提交安装文档和用户测试两个子事件，完成这两个子事件并在此关闭，这样才完成了开发。测试通过由应用处提交安装到系统处。系统处进行规范审核操作。规范审核通过，进行发布。发布完成后，交由应用处验证，完成一个程序变更。这是整个变更流程的操作记录，通过这个记录我们可以清楚的了解整个的发展过程，以便于日后查看。2 Form申请在需求开发的过程中，外部实施商当需要授权某代码时，即会提交Form申请。先由应用处进行审核。此时会创建Form检查这个子事件，检查Form相关文档是否齐全、以前是否申请过、名称/格式是否正确，通过会才能提交系统处开通。检查完后，修改子事件的状态为完成。审核通过后，提交系统处完成开通路径的操作。系统处完成开通路径后，通知外部实施商及应用处知晓。关闭此申请。由下图中的历史记录，可以看到Form申请处理的全过程，信息、时间及负责人的相关流转。3 系统DB访问（Link）申请此标准服务的处理流程与Form申请相同，请参考Form申请部分。4 环境克隆申请申请此标准服务的处理流程与Form申请相同，请参考Form申请部分。5 技术架构审核技术架构审核通过子事件完成。在开发解决过程中，系统会自动创建一个技术架构审核子事件，如果不需要技术架构审核，状态为无此类申请，则只作为记录，这时默认的负责人是应用处；如果有技术架构申请，则将状态改为提交申请，并且将负责人改为系统处成员，此时系统会触发邮件通知，通知系统处负责人。四 用户管理用户视图用来管理关键用户及外部实施商的信息。用户信息如下图所示，员工角色字段用来定义用户在系统中的角色及相应的权限，当前有两种类型：ERP关键用户及外部实施商。对于ERP关键用户，记录了相应的部门信息等。此用户所提交的事件、子事件都可以在事件和子事件页签下面看到。五 个性化设置在设置视图中，每个用户可以根据自己的喜好对页面的风格、显示的事件个数等进行自定义设置。关键设置说明如下登录控制：定义登录系统后默认的登录项目和视图，默认进入系统后都在首页，可以通过选择跳过首页。例如定义登录后看到事件视图，从而还可以定义看到