证券交易类系统质量保障体系思考

2018-11-07   出处:大商所行业测试中心  作/译者: 大连飞创  

摘要交易类系统对实时性、稳定性、可靠性要求较高,风险等级和质量保障优先级较高,面对激烈的市场竞争,各家券商研发的交易类系统也越来越多样化、复杂化、个性化,新技术层出不穷,业务复杂度也在不断加大,质量保障工作的难度也随之加大,迫切需要建立一套高效高质的交易类系统的质量保障体系解决交易类系统普遍存在的风险等级高、质量保障要求高、难度大等行业痛点。我司团队在体系建立及质量保障工作中也在不断的摸索及学习中,借此机会与大家进行如何建立质量保障体系经验分享,期待与行业同仁共勉。

一、识别系统特点及保障重点

1.1了解系统特点

标准的交易系统内部包含客户端、接口、中间件、事务处理、数据库、管理平台、外部服务和其它个性化增值服务。外部关联交易所系统、风控系统、银证转账系统、结算系统等。由此可见交易类系统关联的外围系统较多,复杂性较高。除此之外,交易系统的分类也富有多样性。

图1 交易类系统架构简图

1.2如何识别质量保障重点

交易系统业务复杂性较高,关联的外围系统较多,对实时性、可靠性、稳定性要求极高,受国家、证监会和交易所法律法规约束强,属于强监管、高风险系统。在整个研发和测试交付流程中,对项目组成员的业务和技术能力要求较高,质量保障难度大。因此,建议一套高效高质的交易类系统质量保障体系解决行业普遍存在的交易类系统风险等级高、质量保障优先级高、质量保障难度大等行业痛点成为亟待解决的问题。

按照系统的实时性,可分为:实时、非实时和交易外围系统。按照研发模式,可分为:自研、联合开发和外购类交易系统。我司将交易类系统的风险等级分为高、中、低三级,质量保障的优先级分为A、B、C三个等级。风险等级越高表示系统的风险越高,优先级越高,表示系统的质量保障的重要程度越高。经过调研,我司将不同类型的系统风险等级和优先级总结如下表:

图2 交易系统风险等级和优先级

(1)按照是否实时交易分为:实时交易系统、非实时交易系统、交易外围系统。

(2)按照项目研发模式分为:自研交易系统、外购交易系统及联合开发交易系统。

从上表风险等级和优先级列可看出,无论何种类型的交易系统,其风险等级和质量保障的优先级均比较高。

二、建立质量保障体系要素

在产品研发的全生命周期过程中,参与方包含需求、研发、测试、运行等各个环节。由于各环节均有自己的KPI指标,但最终产品的质量是一个整体性考量,因此高效高质的质量体系首要任务就是确定质量目标,牵引测试团队并驱动其他团队一起提高产品质量。具体由测试团队对研发过程中各阶段输出、线上质量给出客观准确的度量报告及改进建议,作为质量改进的参考依据。

  图3  证券交易类系统质量保障体系要素

2.1明确质量目标

明确的质量目标,可以使整个团队明确工作输入输出标准,按质量目标实施作业。质量目标不仅应包括公司战略发展与公司文化的特性价值指标,还应遵循行业通用指标,如缺陷逃逸率、性能压力、兼容性、代码安全等。交易类系统更为关注实时性、稳定性、可靠性等质量目标。但是质量目标值的设定并不是一个套用过程,而是根据公司的实际情况及公司战略要求制定的,而且质量目标也不是一成不变的,质量目标定期会根据公司目标、实际客户需求而变化的。

2.2建立工作机制

无论是刚开始建立质量保障体系还是根据某种模型建立的体系,核心都是要建立一个适合现状的工作机制。简单的工作机制要包括生命周期模型、角色任务、准入准出标准、项目管理过程与产物、作业指导书及相关的模板。

生命周期模型选择:可以根据项目实际需要及公司原则进行选择或裁剪,业界也提供了瀑布、迭代、敏捷等模型可供选择。

角色任务定义:项目所有干系人角色定义及分工进行详细说明。定义出项目生命周期所有干系人包含需求、开发、测试和运行,清晰定义各干系人的职责分工和作业边界。

流程规范化标准化:编写所有作业流程及作业规范要求,如代码规范、提测流程、需求变更流程等。

2.3定义组织协同

组织协同包括审机制、反馈渠道和跨团队推动,主要解决横向纵向的沟通问题。

评审机制:包括需求评审、概要设计评审及用例评审。

反馈渠道:定义了各阶段集中沟通的方式及对工作认识的反馈渠道:如邮件、QQ或微信群;意见反馈平台及专人收集等保障问题传达的效率。

跨团队推动:明确牵头人、平台化任务跟踪流程等手段推动跨团队任务的顺利跟踪及推进。

2.4采集使用度量指标

   测试不仅要运用各种专业知识技能帮助团队发现潜在缺陷,同时要对产品及过程进行数据采集及数据度量,通过度量数据采集及分析为团队提供过程及产品质量改进点。 度量指标包括但不仅限于代码行缺陷率,单元测试覆盖率,自动化覆盖率&通过率,缺陷reopen率等,也包括评审效率、评审缺陷率、不符合问题等管理类度量数据。 

三、质量保障体系的实践与优化

建立了明确的质量保障体系,整个生命周期的实施在质量保障体系指导思想和框架下开展,完成了从无到有的过程,如何完成从有到优的转变呢?我们需要建立一套可以持续改进的质量保障体系。

3.1优化质量目标

    前面我们提到,交易类系统对实时性、可靠性、稳定性方面要求极高,因此我们选择以下度量指标作为质量度量的关键指标,能比较好的反应市场对交易类软件的质量要求。

特性价值指标:客户增长率、总资产量、总成交量、佣金增长率等比较符合公司对交易类系统的价值要求。

开发活动质量输出指标:开发提测打回次数、缺陷数、单元测试覆盖率、缺陷重新打开率等可以帮助项目经理和开发经理调整开发活动。

测试全面性指标:线上缺陷逃逸率可以有效检验测试用例评审的有效性和测试用例设计及执行的全面性。

客户比较关注的重要指标:实时性、稳定性、可靠性、易用性是客户比较关注的重要指标,因此需要作为质量目标重点关注。

3.2优秀实践化工作机制

     建立优秀实践的工作机制便于组织使用及掌握。以敏捷模型为例,组织分工角色定位为产品(需求)、开发、测试、运行四个角色,其主要职责依次为需求文档输出、代码实现、测试报告产出和上线运维。流程包括需求变更流程、日常事务(需求、开发、缺陷)跟踪流程、提测流程、上线发布流程及应急流程等。

图4  敏捷模型工作机制

   

从上图可以看出,我们基本列出的软件活动的整体工作机制,横纵向的对应关系大体可见。需求确定之后,产品经理输出需求文档,组织需求评审;需求评审通过后,开发人员输出概要设计和详细设计并组织评审;评审通过后,测试提供测试计划,测试方案和测试用例,并组织评审;同时开发从主干拉取代码基线进入编码阶段;开发人员编码完成并自测通过后,提交测试人员进行测试;测试人员对开发提测物进行冒烟测试;冒烟测试通过后,测试人员在测试环境执行事先准备好的测试案例;如果不通过,则退回给开发人员继续修改,直到测试冒烟测试通过才能进入正式测试阶段。

测试人员在与开发同一分支进行系统测试,测试通过后,将需要发布的需求对应的分支代码并入主干,被并入主干的分支工作结束。将主干代码进行打包、编译、部署后,在主干上进行回归测试,回归测试通过后即准备发布,同时,并入主干的分支工作结束。测试输出系统测试报告和上线部署包,产品经理组织业务验收,开发提供上线操作文档、应急回退方案及升级清单等。业务验收通过后,测试发起上线送审流程,并经领导审批,审批通过后,运行组织在仿真环境进行验证,验证通过后即可部署生产环境。此时项目组各阶段可进行总结,包括上线总结,缺陷分析总结,项目总结等,项目组主要成员一起讨论优化意见并在下一轮迭代中进行优化改进。


图5  分支开发主干发布

3.3制定测试方法和测试策略

测试是质量保障的基础也是最重要的环节。因此在测试的具体执行过程中,制定出合理有效的测试计划和测试策略尤为重要,测试经理和组内比较资深的测试工程师对于制定的测试方法和测试策略进行技术评审,并在测试过程中把控执行情况,对方法及策略进行优化,确保各场景及各测试阶段按计划及质量目标完成测试工作。

测试方法及测试策略按四个围度制定:

测试业务分析:测试业务包括分析被测对象的业务流程、业务优先级、业务API、应用场景、输入输出、前后置条件、合规风控等属性。

测试类型选择:针对不同的测试阶段和测试目标选择不同的测试类型。例如在系统非稳定期集中执行功能测试;在系统趋于稳定后可选用自动化测试进行回归测试;针对业务流程和容易产生瓶颈的场景做性能测试;在上线之前做全面安全测试;涉及外围系统时,需要做好联调测试。

测试策略制定。从纵向来分,需要对系统进行分层测试:如UI层、业务逻辑层、接口层、数据层、底层框架等。从横向方面需要关注完整的业务流程、正常和异常分支、全链路性能和整体安全性及稳定性、实时性、易用性等测试属性,通过横纵交叉选择系统各层的测试策略。

测试计划制定。主要是对测试范围进行工作量的评估,根据质量保障质量目标识别项目资源、风险,进度及输出成果物。

图6  测试方法和测试策略


3.4管理测试过程

测试经理需对测试过程进行管理,确保测试活动尽量按计划进行。主测试过程的管理主要包括管理、全面、正确、效率、风险五大方面,具体内容详见图7。

图7 测试过程管理

3.5确定组织协同

测试需要驱动需求、开发、测试、运行等各环节优化质量输出。那么如何驱动各环节,整合现有资源,在现有工作机制的范围内合力达成质量目标,就是组织协同的核心目标。

测试需要驱动需求,对产品做好长期短期规划,需求及需求变更严格遵循需求规范。

测试需要驱动开发,扭转现有开发认知,质量不是被测试出来的,开发阶段需要关注代码质量及代码可测性,底层架构需要合力可扩展,核心模块需要持续解耦,接口定义清晰明确。

测试需持续促进产品覆盖的深度和广度,提升反馈速度,丰富度量和改进手段,改进工具和方法,同时对缺陷和线上产品质量进行分析,反向指导线下测试工作。

测试需要驱动运行,选取合适的用户群体进行灰度验证,快速收集有效反馈,对上线及运行过程中存在的问题及时总结和反馈。

测试团队必须参与需求评审,概设评审,用例评审的时机与其他团队充分沟通,统一认知。

3.6抽取度量指标

有效的质量度量指标能更好的指导软件研发过程的改进。如何选取组织适合的度量指标呢?需要组织紧贴质量目标并结合项目实际情况选取合适的度量维度和指标。

不难看出,单个度量指标参考价值有限:统计缺陷率,因前端后端的缺陷发生概率不同就不能单用此指标说明开发质量的优劣;统计案例个数时,案例的颗粒度不一致也不能反应测试工程师的工作量;统计缺陷数时,同一功能发现缺陷越多表示测试工作越有效,但反之开发质量相对较差。因此要建立组织级PDB,实现端到端的全流程质量度量,不要使用单一指标度量产品质量,需要结合全流程的实际情况选取多维度的度量指标进行横向比较。

四、小结

质量保障活动不是一蹴而就的工作,建立及优化质量保障体系需要做好充足的准备,这是一个人力、精力及过程的历练,只有通过不断的体系实践优化才能保障系统的实时性、稳定性和可靠性。


欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
129°|1293 人阅读|0 条评论

登录 后发表评论
最新文章