三句话背景

　　科技子公司或者IT部门在一个大金融团体里面只能算是个成本中心，对IT团队来说，核心使命就是稳定运营、降低成本。这对于自动化测试来说，意味着非常有限的资源预算、不稳定的测试环境、复杂的系统耦合关系、严苛的测试数据要求，还有那近乎无理的信息安全规范。如此种种，让我们并不能按照自己想象的那样去实施自己的规划，以致会走很多弯路；而再回首你会觉得，有时候只是方法欠妥而不是资源不够，有时候只是导向错误而非技术不够高。

　　关键字：金融系统；自动化测试；单元测试；环境监控；测试数据；持续集成；

　　传统金融系统

　　以往，很多传统金融企业所使用的系统依赖采购和外包开发、维护的占比较大，这可能会让他们自己的IT队伍的经验少一些，而对商业工具、产品和解决方案的依赖性较强。而现在，这些IT队伍要么在新技术和互联网的压力下做艰难的转型，要么还在坚持着古老的体制文化，要么非常年轻，经验不足。他们的开发流程也有可能会臃肿僵化，也可能会做敏捷做得些敏而不捷，也可能测试自动化水平低下，也可能太过冒进——在我看来，这个行业里优秀的IT队伍远少于外面精彩的大世界，但是，无论是主动地还是被动地，他们都在随着时代在慢慢改变。

　　对于金融核心业务系统来说，大部分都是将前端按照业务属主的部门划分而做模块化设计。例如我们的保险系统，被拆分为网销、新契约、保全、理赔、渠道人管、财务、电销与客服、查询与报表等等很多子系统；银行则可能会有客户管理、存贷款、外汇、国际结算、渠道、报表等等，有更多的模块。而无论前端如何拆分，一个子公司的业务数据和大部分核心业务逻辑在后端都是共享的，所以整个系统群的基础业务数据和业务逻辑都是紧密耦合的。

　　在这个行业里，我体会到，为了领先同业，仓促启动和上线的产品项目不胜枚举。因为这些项目的经营策略相关性或者政治敏感性较高，所以无论在DeadLine之前实现了多少，只要没有致命问题，总要如期上线，而把遗留的问题通过后续排期解决。这种快餐式的设计和实现让很多项目和产品看似风光的按期上线，都附带了相当多的系统债务的产生：紧耦合、难重构、难以自动化测试、运维成本高。而且这种债务是增量累积的，没有额外的人力很难清理掉。要么在日常工作之外付出额外的努力，要么任其自生自灭，造就“前人宿醉、后人埋单”的奇观。

　　在当今综合金融的大潮中，这些子系统必须满足的条件不仅是数据在系统群内共享，还要与集团其他子公司共享、与监管部门共享，以后也许会和医院与医疗机构、社保机构甚至其他政府部门共享。看起来在我们现有的架构下，综合金融就意味着更多、更复杂的耦合，对测试来说就意味着测试数据使用难度的提升，从而对测试的要求更高。同互联网一样，如今的金融产品也需要抢占市场先机，也需要快速的发布，但是快速发布不等于快餐式开发，否则久而久之系统维护债务的累积迟早将达到无法负担的地步。而谢绝快餐式的发布，就需要新的开发模式，作为开发流程中的一个重要环节，软件测试也在被逼无奈地随着改变、转型，来面临新的要求。

　　时之沙聚金字塔

　　我们反复被教导，测试要越早越好：越早发现，修复成本就越低，所以就有了个分层测试的金字塔概念，而这个理论也经过很多优秀的公司的成功实践和论证，我们不怀疑其正确性。但如果要做更多的单元测试，就需要代码有足够好的可测性，而现有的系统动辄就有着几十万、几百万行的陈旧代码，跨系统的逻辑调用比比皆是，离传说中的高内聚、低耦合相去甚远。所以，在我们的实际操作中看起来，要做多少单元测试就要做多少代码重构，而做多少代码重构就需要多少能够守护代码重构行为的测试。在这种情况下，只做代码重构或者只做单元测试的编写都是不靠谱的，这看起来是个死循环。

　　但是，不仅通过单元测试自动化能够达成质量守护，通过GUI去做的自动化测试和手动测试也能够做到。虽然长期使用通过业务展示层去做测试自动化的成本很高，但是它的建设可以快速完成。同时须知，同步做代码重构和单元测试编写的风险很大，如果在做的时候没有稳定的质量守护，作为涉费的金融核心业务系统，这种发布风险是不能被接受的。所以比较现实的路看起来只有一条路：快速建设好GUI层驱动的自动化测试，用它来守护代码重构和单元测试。

　　我想借用这个沙漏图来说明我的观点：推动这种系统测试的转型，不能幻想一蹴而就的单元测试的建设，可以考虑通过GUI来做测试自动化，将其做扎实，以其为基础来推动这些陈旧的系统群的自动化测试转型。而接下来，要慢慢地用单元测试自动化来逐步替换这个基于用户展示层的测试自动化，直到它们之间形成一个合理的比例。在测试水平提高和转型的过程中，每个类型的测试都有可能成为瓶颈；尤其是通过业务展示层来做的自动化测试，没有它，代码重构和单元测试自动化也无法稳步地推动。在现实中的人力配比下，聚沙成塔对我们来说是一个神话，信念支持我们朝着目标持续迈进，但是在短时间内却不易企及。