系统试运行报告是谁写的_费控系统项目实施情况说明

费用控制系统项目为今年我司信息化建设重大项目，项目旨在对费用预算进行实时的系统管控和严格执行，促进财务管理和会计核算流程的标准化和精简化，同时为员工的费用报销、出差商旅等经济事项提供灵活高效的处理通道。项目自 7 月 6 日正式开始实施以来，计划财务部、信息技术部、实施方元年科技三方紧密配合，现已经按计划完成了系统的开发和配置工作，正式进入到了系统测试阶段。目前项目组对系统上线的时间计划过于乐观，实施方对测试工作的重视程度还不足。出于项目质量考虑，实施方一定要在和信息技术部、计划财务部的充分沟通后，才能确认最终的试运行和上线时间。若 11 月 2 日正式上线，项目实施周期将不足 4 个月，未经充分测试仓促上线的系统质量也将无法得到保障。现就项目实施中发现的主要问题总结如下：

一、需求确认延期，导致开发赶工

按照项目计划，项目组应在 7 月份完成需求分析和系统设计，由于业务复杂度比预想要高，需求细节调整情况多，需求经过反复讨论和变更，部分需求到 9 月下旬才确认完成。项目原计划开发时间为 8-9 两个月，由于前期项目启动时间和需求最终确认时间延后，项目组 8 月 17 日才开始开发工作，9 月底赶工完成，系统开发工期被压缩了 32%。一方面，需求阶段实施偏差达到 147%，需求实际确认完成时间只比开发完成时间早一周，需求不能严格按照确认文档进行开发，导致开发返工；另一方面，赶工导致系统开发的质量下降，项目的风险增加。

二、需求文档质量不达标

需求讨论确认后，项目组应该提供正式的需求设计说明书，但目前需求文档并未得到业务部门的完全认可，没有最终确认或签字的版本。从 IT 的角度来看，也存在一些较为严重的问题，比如：需求文档没有结合系统实际页面进行流程分析与问题确认，系统中的数据流转未明确；需求文档中缺少系统校验的提示内容，缺少关键数据的关联控制说明。

三、测试执行不到位

由于前两个环节的问题，测试作为项目实施的最后一个环节，应该执行的更加仔细。实际上，项目组开发结束后，对整个系统的测试只安排了一周的时间，随即开始用户验证测试。单元测试、功能测试、集成测试等几项测试内容都在一周内交叉进行，测试环节上有很大的遗漏和缺失。目前发现项目组在测试阶段主要存在以下几个问题。

3.1 测试流程混乱、缺失

实施方对费控系统未开展全面的单元测试和集成测试，没有提供单元测试和集成测试结果。元年科技项目组人员为了赶上 UAT 测试阶段，未来得及做集成测试，而是忙于用户测试前的一些准备工作和外部系统联调。对于单元测试发现的问题，没有看到跟进解决，也没有安排回归测试验证。

3.2 测试用例不全面

测试用例没有与详细功能需求说明书关联，测试覆盖率没有办法精确评估。当前元年科技项目组提供的测试用例，经过我们的评审，发现也存在一些问题，比如：测试用例覆盖面不全，有部分菜单涉及的功能未覆盖；测试用例对需求文档中涉及的功能未提及；测试用例只有正常流程场景用例，没有非正常场景用例。

3.3 测试结果无法掌控

供应商元年科技没有提供费控系统的测试报告。测试报告应把测试的过程和结果写成标准文档，对测试发现的问题和缺陷进行分析，直接反映出测试的情况和开发的质量。目前没有提供测试报告，我方无法准确判断系统开发的质量情况。

四、仓促准备试运行

系统赶工开发，系统质量下降，项目风险增加，经过匆忙的测试和 UAT 也难以发现和解决全部的问题。生产系统试运行需要纳入生产系统管理规范，项目组对数据、配置、系统的任何改动都需要经过严格的审批程序。系统未经严格的测试，上线初期系统的 bug 和配置调整肯定会非常频繁，但严格的审批程序，势必会影响生产环节实际业务处理的时效。同时，生产系统数据直接连财务系统和资金系统，发生数据错误，造成其他系统的错误数据也将会是一个很大的隐患。综上，费控系统目前存在的问题还比较多，从元年科技项目组处理解决问题的效率来看，费控系统 11 月初在生产试点上线运行欠妥。应该再进行一轮严格的系统集成测试，出具详细的测试报告，测试合格后再评估正式上线时间。但目前系统上线计划和安排已经通知各分支机构，通知内容不便再进行修改。建议 11 月初，在预生产环境做试运行(双轨运行)，试运行机构 11 月完整的月度数据，核对无误后，12 月切换正式生产环境试运行，1 月全辖上线时间不变，调整后的上线计划如下。