持续交付2.0自动化测试--关键点和痛点

PS：文章内容和观点仅代表个人意见，与其他任何无关，如有雷同一定是被雷批啦！校稿能力薄弱，请见谅！

和乔帮主有过一面之缘，记得是2012年在北京国际会展中心，参加什么会议记不太清楚了，乔帮主主题演讲完后我跟乔帮主就老东家的转型问题进行了探讨，由于当时刚刚踏入转型的门槛，并没有现在的功力和阅历，聊完之后感觉不明觉厉。

今年乔帮主发布了新书《持续交付2.0》上周才完整的拜读了一遍，感觉帮主功力之深真的是令我深深佩服，全书里面最有价值的我个人觉得不是前面的各种理论和概念，而是最后面的实例，这些例子基本上涵盖了我们在转型过程中所有的各类团队的情况，真的是很贴切。当然这些例子也是全书理论最好的实践。

快速、安全、频繁的交付软件，意味着我们可以更快速的得到客户的反馈和可持续的优化改进，从而达到少做，避免浪费，并且持续收获。也能让团队更进快速和快乐的成长。

愿景是美好的，然而放眼我所熟知的领域能做好的真的是凤毛麟角。最近几年从老东家发布的各种信息看对此方面的宣传也不是太多。要达到书说理论所描述的状态对于大多数中小银行来说非常困难。

5G给银行理念上带来的最大的好处是敏捷、持续交付等词语正式的出现在管理层眼中（少部分以科技立行的城市商业银行除外）。现在敏捷银行，业务敏捷等已经随处可见。基础知识普及的好处就是科技吹的牛逼好像有人开始care啦。但是吹牛逼归吹牛逼，怎么落地，有可能落地吗？成为另外一个痛点问题。

在早期城商行的系统建设中基本都是烟囱式的，银行购买众多厂商的产品以满足银行业务发展的需要，团队不一样，技术栈不一样，工具不一样，质量保证不一样这些问题严重阻碍着标准化流程的实施，并且测试是城商行最薄弱也最不引起重视的环节，部分城商行科技对质量的容忍度的水位低的真的令人发指。这种复杂情况下，单一系统的存量重构或者标准化改造基本是不可能完成的任务，在体系中对于存量系统没有新的需求，是没有人愿意，也没有人敢去做重构和流程优化的（有点狭隘，但这确实是一个出力不讨好而且做好没人表扬，做错一定要背锅的事情）。

整个持续交付中我认为最关键的一环是自动化测试。测试特别是对于中小城商行并不是可以随便忽悠的做工作，而是软件开发工作的重中之中。但是在系统建设过程中科技条线认为测试是业务条线的事情，基本上很少插手具体的测试方法，有些行没有专门的测试团队，测试团队都是临时召集的，更有甚者连测试管理团队都没有，更不要说完善的测试体系。

如果要在城商行系统建设中推动自动化测试我比较认同帮主的观点，就是在测试金字塔偏上层位置--API接口层进行入手。各个厂商对于联调测试的态度基本不会太积极，除非行方有这个前瞻性在购买产品的时候就明确要求产品实施必须包含该产品的持续集成，厂商才有可能去搭建基于单元的持续集成。

基于API接口层的测试可以由测试厂商帮忙搭建，部分主流测试厂商是具备这个能力的，行方如果有自主研发能力的也可由行方自行研发，API自动化测试系统不需要对接各个系统，只要对接ESB即可，API测试是对经过ESB服务治理后的统一规范的接口进行测试。基于API接口自动化测试最关键的问题是要解决数据可测性的问题，解决这个问题的方法也很多，比较笨的办法是每一个案例造好自己的案例数据，每次跑完一次自动化测试之后，数据库恢复到初始状态（还有其他方法不一一介绍）。建立这样一套体系，前期的准备和调试工作肯定比较费时费力，但是一旦完成后，比如银行核心账务等高频但是变化比较低的服务的测试效率可以得到极大的提升。API接口自动化测试也不是所有接口都要做，调用频率高，但是接口需求变化不大的接口优先。

解决了API测试，有能力的银行可以在像测试金字塔的两侧延伸，流程自动化和持续集成都可以是下一个突破口，但是也都有很多阻碍。只有解决了自动化测试这个关键点，才有可能解决银行持续交付的问题。哪些吹出去的牛逼才有可能出现。

办法总会比问题多，只要愿意想，愿意改变，我相信城商行做持续交付不是什么大问题，当然如果不想做，放心，时代会推着你做的，迟早的问题。