Testin云测试的券商测试服务怎么样？谁了解来说说

Posted 2023-03-26

体验过，非常不错，有专门的证券行业解决方案，这是其他家都不具备的。
近年来,随着券商的各类业务系统功能日趋增加,系统模块越来越多,功能趋于完善,势必导致传统以手工测试为主的测试体系越来越难以满足日益增长的业务模块的测试需求。采用Testin测试管理自动化平台+专业软件测试专家的模式,在确保总体系统能力稳定性的前提下,构建高效高覆盖的自动化回归测试和验收测试能力,实现回归测试工作与验收测试工作的一体化和自动化,从而大幅提升保障测试准确性,降低测试成本。
有不清楚的，欢迎随时追问 参考技术A 以我在职的国内某Top10券商的为例，我们在IT建设投入名列行业前茅，有多个App端产品以及PC端系统，IT建设在国内券商一直被视为标杆之一，且建立了较为完善的测试体系。但在实际测试工作的进行中，存在测试工作以手工为主，测试人效偏低的情况。同时由于产品用户数量大，在产品迭代上线后，会经常收到关于产品闪退、界面展示不全等兼容性问题。为了全面提升测试工作效率并尽早发现产品兼容问题，券商引入Testin云测证券行业智能解决方案，结合自身的实际情况，针对其自身问题点从自动化测试平台建设、测试人员加入、兼容测试方案等多个方面进行升级。

　　从应用证券行业智能解决方案的实际效果来看，彻底解决了自动化工具和懂券商业务的专业测试人员的问题，实现了功能回归自动化测试的有序进行。覆盖测试用例近7000个，总脚本数超过2000个，脚本支持跨双平台（android+ios）执行，自动化目标覆盖率60％以上。彻底解决了兼容性的问题，实现了600款安卓机型、70款苹果全系列机型以及Web端多维度组合的兼容测试问题，测试任务下发24小时之内即可收到反馈测试报告，整体流程上使得券商发版提前了5天以上的时间，百度也查得到的。 参考技术B 在上家公司用过，产品、工具和方案都不错，他家比较懂证券的业务，这点比较关键，整体来说专业性和综合性很强，做测试就需要准确和专业，要不测试做了和没做一样，百度能查到相关资料的。

应用运维的红蓝演练：全链路压测在券商系统的落地实践

说明：本文根据林英老师在 GOPS 全球运维大会 2021 · 深圳站的演讲整理而成。

作者简介
林英，国信证券-资深测试经理
腾讯6年，负责服务端测试、精准测试、平台建设
国信证券，负责全链路压测及测试右移

大家好，我是来自国信证券的林英。之前在腾讯工作了6年，主要负责服务端各类测试、精准测试、测试平台建设工作。19年加入国信，现在在系统运行部，负责全链路压测和测试右移方面的工作。

今天我演讲的主题是应用运维的红蓝演练，主要内容分为四大部分：券商的数字化转型之路、券商行业的IT现状、应用运维的红蓝演练策略、国信的建设成果。

一、券商的数字化转型之路

近些年互联网浪潮给各行各业带来了颠覆性的变革，券商行业也在时代的裹挟下、监管要求下，走上了数字化转型之路。给我感受的最大的变化是，自助化，打破了地域空间的限制，极大的提升了业务的便利性和效率。

华尔街的老电影经常出现一个场景，大家乌泱泱挤满人的交易大厅，吃力的看着行情数据，排队等待着交易员帮他们交易，效率非常低。

现在，一部手机或者电脑足不出户就能搞定一切。第二个变化是智能化，借助大数据进行用户画像分析客户的不同需求，提供千人千面的个性化服务，为客户提供量身定制的个性化资产配置和财富管理建议。第三个变化是敏捷化。通过持续、快速交付高质量软件去加速业务的创新，最终实现商业价值。

二、券商的 IT 现状

在这场声势浩大的数字化转型过程中，我们也面临了很多问题，可以用外忧内患来概括。

首先，监管和用户对系统的稳定运行提出很高的要求。证券系统关系到用户的资产信息，天然敏感度极高。交易系统的响应时延和稳定性直接影响用户的利益。监管机构对开市期间的核心交易系统的故障有一个5分钟的红线。系统不可用超过5分钟可能面临严重的处罚。

其次，随机波动的行情给业务系统的稳定运行带来了极大挑战。毫不夸张的说，当行情来临时，天天都是双十一。但是，就跟拆盲盒一样，你永远也不知道双十一会在哪天到来。

第三，我们对系统容量认知也存在严重的不足。由于缺乏有效的性能测试结果作为参考基准，应用系统的部署主要依靠人工经验来推算。我们不确定系统能承受的最大容量是多少。当行情来临时，只能被动应对。

第四，复杂的架构导致线上故障定位困难。证券行业核心交易系统长期依赖外购，但是近些年业务创新对我们的软件交付速度提出了更高的要求。

我们走上了自研系统敏态核心交易稳态的双态IT系统路线。特殊的系统架构导致核心业务链路长，外购系统的非功能性需求无法满足运维要求，容量问题定位困难。

总得来说，外部挑战要求我们进行容量管理，来保障系统稳定运行，但是自身限制导致我们对容量认知不足，无法快速定位系统瓶颈和故障。我们如何才能胸有成竹的迎接大行情的到来？

三、应用运维的红蓝演练

我们如何才能胸有成竹的迎接大行情的到来？在信息安全领域有一种策略叫红蓝演练，本质上就是攻防对抗。

对应运维领域，就是红方通过模拟行情高峰，找出系统的最大容量以及应用瓶颈，提前暴露容量隐患；蓝方通过建设全面的监控体系和完善的故障定位工具，共同提升应急响应和协同水平，保障系统的稳定运行。

红方的设计思路

红方的设计思路主要是制定完善的压测方案，最终实现流程自动化、工具平台化、制度常态化。

我们先看一下传统的压测方案是怎么做的，是以交易中间件为界限，分别对渠道接入系统和交易系统做性能测试，达到的结果作为我们应用部署上线的参考。

实践证明效果并不是很好，为什么？对证券交易系统来说，测试数据对结果的影响非常大的，持仓较少的散户与持仓多的机构客户在查询效率上差别非常大。不同登陆方式：资金登陆、股票登陆的调用路径也不一样。

测试环境的机器大多采用的是低配的、单机部署。而监管机构对我们的要求是两地三中心的部署，跨中心、跨网络的测试环境无法完全模拟的。因此，在实验环境拿到的数据的参考价值并不大。

这是交易系统每天的用户访问量曲线。这个曲线每天的形态非常类似，在开市期间会有2个小高峰，分别是早上开市后5分钟和下午闭市前5分钟，连续竞价开市9:30-9:45期间，往往是当天的最高峰。

右图是天猫双十一的用户访问流量曲线。两者非常相似。假如将阿里应对天猫双十一的核武器——全链路压测引入到券商核心业务系统来，效果会怎样？

参考阿里应对天猫双十一的最佳实践，我们设计了基于流量回放的全链路压测方案，整个系统分为4大部分：

• 第一部分是全链路压测数据构造部分，基于大数据平台分析用户的分布情况，共同构成压测流量。

• 第二部分是压测集群，采用是两地三中心的部署架构，可以支持动态的横向扩展。

• 第三部分是应用系统，流量会从最外层的接入层进来，经过渠道接入部分、应用部分、交易中间件，最终到达集中交易后台，覆盖了前中后台的各个系统。

• 第四部分是监控系统，是基于现有的 Prometheus 和大数据平台，实现全方位立体化的监控。

在实施全链路之前，首先要保证流量能够顺利向下传递。我们在硬件层和应用层都有安全拦截策略。硬件层的拦截比较好处理，主要是用添加白名单的策略。

应用层则需要做针对性的改造，在每个流量向下传递的过程都做了配置化改造。

接下来我们依托运维自动化平台把流程串联起来，实现了环境准备、环境恢复、硬件检查的全自动化。

我们的数据应该怎么构造，怎么才能更好的模拟生产环境的用户分布模型，怎么模拟高峰期用户的访问操作呢？有多少用户是在每天高峰期下单，进行交易登陆，有多少用户在查询行情呢？我们的方案是直接选用生产的数据来进行测试。

我们利用现有的运维大数据平台抽取数据，分析用户访问高峰的模型，利用生产运行真实用户数据分析，然后进行脱敏、订正之后导入构造压测数据池。

如何构造压力呢？在工具选型方面我们从五个纬度进行分析。首先是并发能力强，其次是要支持多协议，因为我们不仅有标准的 HTTPS 和 HTTP 协议，还有私有的 TCP 协议。同时必须有很强的扩展性，支持二次开发。

为了在团队内进行顺利的推广，我们希望它有比较友好的界面，门槛低、上手简单、易推广。

当然它能够开源免费，用比较低的成本获取，那是最好的。根据监管要求，核心交易系统必须采用两地三中心的部署架构，因此我们的压测集群部署了对等的两地三中心，借助于容器化技术，可支持节点动态扩展。

工具、数据、方案都准备就绪后，可以撸起袖子开工了。问题又来了，全链路压测的最佳实践对象是生产运行环境。如何保证压测期间的中间数据不会被用户看到？压测产生的脏数据如何与生产的数据隔离？互联网的方案是对压测流量做标识、改造中间件识别压测流量，利用影子库隔离脏数据。

券商系统涉及自研、外购，前后链路非常长，改造的难度非常大，而且必然会引入风险。稳字当头，注定了这个方案不可行。幸好，证券行业与互联网不同，它并不是7*24小时提供服务的。休市之后应用系统的流量就会大幅下降。我们在非交易时间利用网络隔离和数据库备份恢复策略来保障实施的安全性。

全链路压测方案在国信落地实施后，经过不断的演进，我们对工具进行了工程化，实现了容量测试全流程的自动化，环境准备可以按需弹性扩容，压测数据可以一键生成，压测流量可以动态调节，自动的进行结果分析和报表输出。做到全程0人工干预。

自动化下一层是工具平台化，为了让我们的工具能够推广到更多的团队，实行了平台化处理。平台分为四大部分，最下面是应用系统，最上层是权限管控、数据报表展示，同时我们还与外部系统实现了对接和联动。

生产环境并不能每天都测试，所以我们按照生产环境等比例建设了预发环境，在预发环境里，我们会每天自动分析当天访问模型、抽取最新的用户数据，对待发布的金太阳应用版本，进行全自动的容量压测，从而建立容量的变化基线，并进行容量预警。

蓝方的设计思路

蓝军的防守策略主要从我们熟悉的故障预防、发现、定位、修复这4步开展。

故障预防方面，我们建设了全生命周期的容量管理。首先通过常态化压测容量基线更新，每天对容量做巡检，超过安全基准线进行告警。然后定期汇总容量告警，反馈给开发做持续的优化改进。

在故障发现方面，我们建设了全面覆盖的监控体系，可以简单抽象成四层。在采集层我们采集了基础的资源监控指标，调用监控信息和日志信息统一发送到处理层，进行数据的落地。通过运维大数据平台和安全大数据平台进行聚合分析，发送告警到事件平台，使对应的人进行处理。最后对事件进行复盘回顾。

故障定位方面，我们实现从系统、组件、再到用户级别的,从立体到平面再到单点的层层递进式定位。首先对系统健康检查识别到请求量、错误率、时延的异常，接着下钻组件层，看到系统下各个组件各台机器的请求量、时延的异常，进而追溯到每个用户每笔交易的明细。

尽管我们做了充分的准备，但是依然可能会面临各种突发情况。假如用户的流量远高于我们的预估，出现了部分服务故障或者机器故障，我们应该怎么处理？扩容、降本是我们的手段。在业务限流方面，我们通过自研框架管理中心方面进行解决。在业务降级方面我们通过自研平台实现快速业务降级。

四、国信的建设成果

下面我们看一下效果。全链路压测在每半年的生产演练和每月的灾备演练中使用。覆盖了10多个应用体系，上百个应用组件和上千个应用主机。通过系统调优，主数据中心每秒处理能力提升3倍。福田、金桥两大新数据中心性能分别提升了4.1倍和5倍，平稳度过了2020年的行情高峰。

这一路走来，我们对系统容量认知经过了四个阶段。第一是愚昧山峰，不知道自己不知道，容量不够，机器来凑。第二是绝望之谷，知道自己不知道，毫无头绪、惴惴不安。

第三阶段是开悟之坡，思路清晰，了然于心，我们知道系统的瓶颈会在哪里。第四个阶段是平稳高原，我们在实战中沉淀宝贵的经验，对未来更胸有成竹：如何快速进行故障定位，怎样及时评估应用的变更对系统容量影响，容量优化的方向和思路。

DevOps 风向标！DevOps 国际峰会 2021 · 北京站震撼来袭~想知道本届 DOIS 大会有哪些精彩？扫码提前了解~

扫码直达官网，早鸟票限时 7折优惠中~

近期好文：

“高效运维”公众号诚邀广大技术人员投稿，

投稿邮箱：[e-mail]，或添加联系人微信：greatops1118.

点个“在看”，一年不宕机