图书管理系统需求分析-【啄木鸟】重构系统之测试需求分析和需求管理的探索和实践

提示：点击上方"我们的开心"↑关注我们

文/秦红梅

按照我行“互联网化、数据化、智能化、开放化”的数字化转型要求，研发中心正在积极推进各信息系统的技术升级和重构。这些系统的运行时间一般都有数年之久，期间多次优化改造，业务需求和技术文档或严重缺失、或零散分散、或与现行系统实现大不相符。众所周知，需求是进行测试需求分析的重要依据，基于需求，测试人员才知道测什么，怎么测，才能判断系统是否满足用户需要。因此，如何跨越需求缺失这道鸿沟？如何防止需求不明可能造成的需求变更和蔓延？这些问题成为了项目测试前移工作，尤其是升级重构类项目测试前移亟待解决的问题。

一、技术升级及重构类系统的特点

首先我们需要了解什么是系统重构？它都有哪些特点？系统重构是指在不改变软件外部行为的基础上，改善软件的内部结构，使程序的设计模式和架构更趋合理，从而提高软件的扩展性和维护性。

我行的系统重构又有哪些特点呢？首先，大多数系统通常“不改变软件的外部行为”也就是说不改变系统的现有功能，因此，我行的系统重构一般是服务端的改造；其次，重构系统会采用行内最新的技术栈，构建新平台，抽取和整合各业务产品共性功能，构建公共服务模块。由此可见，重构系统的测试需求分析也会和以往的系统有所不同。下面我们以对公业务数字化转型项目为例，探索技术升级及重构类系统的测试需求分析和需求管理方法。

二、技术升级及重构系统之测试需求分析框架

通常，测试人员进行测试需求分析的主要依据是业务需求说明书，而重构系统的特点，需要我们从多种途径收集需求，我们将从业务视角和技术视角两个维度，以全业务场景梳理为主线进行需求收集和分析，如图所示：

图1 业务视角的测试需求分析框架示意图

图2 从测试角度对需求进行不同维度的拆分示意图

业务视角分析方面，我们始终要以本次项目需求作为测试需求分析的依据；由于重构系统一般不改变现有功能，老系统的操作规则、操作手册就有较高的参考价值，可以作为本次项目需求的补充，并进行二者的差异分析，将其反馈给业务和开发人员进行确认；此外，历史缺陷和生产缺陷的收集、统计和分析，可以作为典型测试场景的补充；为了能更好地了解业务特点，准确分析，我们还需要了解相关业务法律、法规、操作规程等制度类文档。最后，根据业务特点，从测试的视角对需求进行联机、批量、敞口、权限、打印等不同维度的拆分，满足重构系统测试需求分析的全面性要求。

图3 技术视角的测试需求分析框架示意图

技术视角分析方面，总体方案是非常重要的测试需求分析依据，通过研读总体架构、应用架构、数据架构、开发架构等内容，我们可以分析系统间、系统内模块间的调用关系，了解数据类型、数据分布、数据与交易的关系，数据清理机制、数据流向等，了解新技术、新架构、开发平台的特点，以及部署的关键节点等情况，为测试需求分析提供诸多有价值的信息；同时比对新老系统的总体方案，找出改造差异。其次，通过老系统的数据库字典，了解不同字段的不同赋值，补充和丰富测试场景；再次，将老系统的随机测试和错误码分析相结合，梳理异常测试场景；有条件的还可以通过查阅代码进行测试需求分析。最后，将业务需求、总体方案以及项目规模估算书等收集的需求进行匹配和核对，避免需求的相互矛盾和不合理性。

完成需求收集后，还需要将其剥丝抽茧，层层细化，形成结构化的测试点分析框架，满足测试需求分析的科学性要求。

图4 测试点分析框架示意图

作为大工程的重构系统，一般都有众多测试人员和外协参与，很多人员可能是第一次接触这个业务领域和系统，如何能让这些测试人员快速上手？让需求更具可读性？测试点的表现形式显得尤为重要。根据重构系统一般不改变界面布局和要素，我们创造性地编写了测试点分析模板，以菜单交易和字段为主导，进行需求、测试类型和测试点的梳理和匹配，增强业务需求和系统的融合和可视化，增加了需求的可读性，大大减少了沟通和学习成本。

图5 测试点分析模板

三、技术升级及重构系统之需求管理

需求的明确和定版是一个循序渐进的过程。重构系统的需求来源庞杂而繁多，又涉及众多干系人，很容易出现需求的变更和蔓延，因此一套行之有效的需求管理办法和机制对项目的落地实现必不可少。

我们建立了需求评审逐级、多轮次、线上线下并行走的管理办法图书管理系统需求分析，大大提高了工作效率。

图6 需求管理示意图

逐级：测试小组先通过内部讨论和学习等方式进行问题过滤，解决部分问题，再与项目组沟通确认业务难点、技术难点等问题，最后业务、开发、测试三方根据工期、人力、技术实现等综合因素进行需求一致性、优先级、难点要点等问题的确认。

多轮次：随着对业务和技术的深入认识，各方都会带动问题的迭代，因此需要展开多次的评审和确认，直至最终得到确定的需求。

线上线下并行走：重构系统需求不明确的特点让如何保证项目周期成了最头疼的事。为了解决这个难题，线下的编码和需求确认，线上的需求评审流程需要同步走，但这会产生技术实现和需求文档不一致的问题。测试前移很重要的工作就是建立业务和技术协调统一视角，跟踪需求的三方确认进度，并将需求确认结果反馈给业务，反哺需求。事实证明，通过此方法大大提高了需求文档质量，为项目的后续实施、资产的积累和管理奠定了优质基础。

为了将办法落到行动实处，我们建立了测试需求评审和确认进度表，依据需求评审会议结果，更新需求文档的评审进度以及每个需求文档中具体的问题确认情况。落实时间、责任人、关联用例修改等情况，达到项目进度和质量的管控要求。截止目前，完成需求反哺约248项。

图7 需求评审和确认进度表模板

四、对测试前移的思考

测试前移很大一部分工作是在进行文档测试，而文档测试是静态测试的一种形式。目前，无论是重构系统还是优化升级系统，或多或少都使用了静态测试这一手段，并且有些项目还形成了自己的静态测试文档体系。然而，在制度、流程和资产积累方面，静态测试尚未形成体系化的机制要求。我们认为图书管理系统需求分析，静态测试产生的一系列资料、方法和经验是具有较高利用价值和深度挖掘空间的资产。首先，通过收集、比对、优化各项目组制作的优秀静态测试文档模板，形成一套规范的、分级分类的静态测试文档体系，可丰富测试人员的测试手段；其次，通过需求问题的积累、分析和共性提炼，可优化和细化需求说明书规范模板；最后，丰富项目经理、测试经理和质量管控角色对项目的分析和评价手段，强化对项目实施质量的预警、跟踪、管控能力。

作者简介

秦红梅，高级专员，现就职于测试二部投资理财组。从事外汇类及衍生业务测试。乐于进行测试前移工作探索。