导言

俗话说，一个团队，没有龙头哪行啊，开个玩笑。后来淘宝的于平、于凡的花名也是我起的，寓意着平凡普通。俗话说，一个团队，没有龙头哪行啊，开个玩笑。后来淘宝的于平、于凡的花名也是我起的，寓意着平凡普通。俗话说，一个团队，没有龙头哪行啊，开个玩笑。后来淘宝的于平、于凡的花名也是我起的，寓意着平凡普通。俗话说，一个团队，没有龙头哪行啊，开个玩笑。后来淘宝的于平、于凡的花名也是我起的，寓意着平凡普通。

2007年，在微软的这段经历，对于我.net系列技术体系有了长足的进步，在工作之余，自己也接了一些外面的小项目，所以我对软件需求把控、数据库设计、系统设计、实现、交付等都有更加深入的实践和理解，也为我后来负责工具研发团队奠定了一定的技术和业务基础。此期间，让我深深感受到测试也要会开发。

2008年，在SAP这段期间，我主导研发了SAP Business One的云测试平台OnDemand平台，主要功能模块有测试项目管理、测试资源（用例、测试机）管理、测试报告管理、执行调度管理、测试任务管理、客户端执行器等，记得当时我的manager告诉“OnDemand就是你的Baby”，我至今记忆犹新，一个软件产品的孕育确实需要太多的思考和付出，那时候加班加点，一个人主导研发并顺利交付，历时4个月，目前这套平台还在持续运营（已经5年过去了，还是稳定运行，还是满引以为豪的），后来逐步负责一个小team，主要负责测试工具平台建设，业务涉及自动化框架、测试数据管理、环境管理、自动化执行调度器、任务管控系统等。此期间，让我深刻感受到实践出真知。

2011年，顺利加入阿里巴巴淘宝网的kelude测试平台团队（我一直都在说，淘宝的kelude测试平台团队是互联网界测试工具的黄埔军校），负责PC自动化框架团队，之所以从SAP跳槽过来，主要是希望自己在互联网领域有所沉淀，也想提升下自己的互联网技术体系，在加入淘宝网的时候，由于自己之前是从事.net系列，对java体系了解甚少，入职的时候自己的岗位是技术专家（层级P7），能感受到周边的同事都对于我较大的期待，尤其是我的主管，所以刚加入淘宝网那段时间，倍感压力，真是如坐针毡，有想过逃避（甚至外出面试过其他公司）。既来之、则安之，后来逐步深入的去了解业务和相关技术，寻求业务痛点，虚心向他人请教，由于我有一定的.net的经验，所以对java技术的学习进展还可以，最关键的是kelude测试平台团队有着各方面的技术人才，平时可以多一些交流和学习，在这样的环境下，不成长都不行。在淘宝网的这段时间，主导研发了PC端自动化框架AutomanX，最大的成就感就是将原先用ruby写自动化用例的小二转向了用java写自动化用例，自动化领域的技术统一化，同时打破原先的多套框架（Automan、itest等），实现了统一化的集成自动化框架，此期间，也积极参加集团的一些创新学习，也带领团队分别在2012年和2013年拿到浏览器同步工具和爱吐槽2个赛马项目并顺利通过。此期间，让我深刻感受到的是坚持与感恩，千里马常有，而伯乐不常有，遇到一个好主管很重要，很感谢前主管，能够站在业务的高度去影响和感染下属，很难得，所以在某种意义上来说，跳槽是为了寻找好主管。

2013年，由于平时有一些业务交流，和支付宝的研发或测试还较为熟悉，加上由于希望回上海发展，所以在2013年的6月份，我有幸加入到支付宝测试技术团队（现在叫质量技术部），负责组建工具平台研发团队，由于我有较好的测试工具研发的业务和技术背景，加上又是兄弟公司，所以很快就熟悉了这边的业务和技术体系，基于团队的现状，提出了统一化研发模式、统一化工具平台的理念，也得到了主管和领导们的高度认可，所以从2013年7月开始，逐步开始打造了蚂蚁金服全站质量技术平台AQC，业务涉及无线测试、全站分层自动化回归、代码测试平台、PC与移动端覆盖率、资损与核对、持续集成、CTU事件管控、用例管控、线下工具平台基础化建设等，在团队组建和工具平台建设方面有了一定的成效（如构建了全站无线测试平台、全站T+1资损核对平台、工具平台研发效率提升30%等），2014年上半年，有幸从原来的P7层级晋升到P8层级，也非常感谢主管和领导们的认可，当前正致力于工程化能力提升的工具平台建设，一直思考着返璞归真的研发模式，如开发自测、开发对产品质量等，也一直思考着数据驱动研发模式（Data Driven Development）的未来。由于负责的是工具平台研发团队，和一般的研发团队有所区别，在工具研发团队，我们人人都是产品经理、人人都是开发、人人都是测试，在人才引进和培养方面，需要有足够的耐心，我们的组员更多的是来自测试领域，当然后续更多的会引入开发背景的同学，所以，我们每2周会举行一次技术分享交流会，另外，在组内工具平台建设过程中，我们也会适当采取组内任务轮岗制，以提升各位同学的技术深度和广度。此外，让我感受到如何去做的一个好的主管（当然，我目前还不是好的主管，我还在努力中），更多的是以身作则，多站在对方的角度去思考，在管理方面，实行了专人专职专事与组内任务轮岗制，积极点燃下属，一起奋进，沿袭公司质量策略研发出好的产品，促进全站工程化研发效能。另外，非常感谢和我一起战斗的同学，目前所负责的工具研发团队的每个同学都肩负着和我一样的使命，没有和我一起战斗的同学，什么都是浮云。

硬生生将他们俩割裂对立开来似乎不太可取，用金融的思维做互联网，或者用互联网的思维做金融，无非争论的是谁服务谁的问题。但是无论是互联网金融还是金融互联网，都离不开互联网技术。

由于金融业务天然所具备的复杂性和高安全性，所以对测试人员的要求要格外的高，不但要具备一定的行业领域知识，更需要具备较强的编码能力和特定技术体系化能力（如java编码能力、spring、ORM、数据库、大数据、中间件、软件生命周期、无线客户端、互联网思维等），同时，也要具备金融领域的一些测试技能，如资损防控等。

在研发模式方面，开发自测、开发对产品质量负责也许会是方向，在这样的变化下，工具平台将会透明化研发产品生命周期各个环节的研发数据，用数据去驱动研发，也就是我之前所提及的数据驱动研发模式（Data Driven Development），测试人员将会充当测试顾问的角色，提供一些测试方法论和最佳实践，引入一些新的测试方法、测试技术、效率工具，去协助开发做好测试、风险、质量防控等活动。

万变不离其宗，作为测试从业人员，一定要不断积累测试理论基础（如黑盒测试、白盒测试、边界值测试、模型驱动测试、自动化测试、性能测试、安全测试等）、开源测试技术或工具（如junit、jmeter、loadrunner、testng、selenium、watir、quality center、qtp、robot framework、app scan等）、领域测试知识（如硬件测试、移动专项测试、移动自动化测试、金融资损与安全测试等）、行业业务（如ERP、金融、保险、电商、物流等）、开发能力（如java、c#、javascript、html5、sql、hadoop等）等，以不变应万变。培养自己技术体系化、业务深入化、专业化的能力，当然，沟通能力、项目管理能力也是不可或缺的，需要不断的沉淀。

目前应用安全测试团队也在打造应用安全测试中心；业务层面来说，蚂蚁金服有相应的大安全部门，也有相应的安全防控平台，这块我不是很了解，不好意思。

关于安全问题，设计及开发实现必须满足安全研发checklist，至于checklist，基于公司安全考虑，不便于分享，望大家理解。另外，资金类的项目，会要求部署T+1核对和实时资损核对等。

集群性能（应用集群、核心系统、集群应用依赖等）、性能建模（阈值预案、趋势分析、基线分析等）。

关于应用服务端性能，通常会考虑到JVM调优（FGC、参数优化、OOM、内存泄露等）、DB调优（索引、参数、业务等）、中间件容器（如死锁和线程数、JBOSS线程优化）、文件读写（如序列化和反序列化、对象拷贝、日志等）、代码方面（如服务调用的网络消耗、同步异步、velocity等）、底层系统（如缓存、消息中间件等）。

蚂蚁的性能测试完成了由原来的性能测试到全站性能保障的华丽转身，构建了线上线下多重性能压测保障体系，准确评估系统容量，提前做好扩容和性能隐患的排除；

在线上，进行关键链路的真实场景的压测，模拟双十一的压力进行峰值压测，这样保障了系统在双十一之前就已经进行了性能的实战演练；在线下，持续的进行关键链路性能回归，针对重要业务，性能容量评估甚至涉及到了接口层面；  此外，工具团队也在协助打造线上与线下压测平台，至于性能平台的建设，我就不在这里详述了。

试，这三者，也就是通常意义上的分层自动化测试，或者是所谓的倒三角自动化测试。

面对支付宝的一些应用，我个人认为要强化单元测试和接口测试，同时也要兼顾其代码覆盖率情况。至于基于UI的功能自动化测试，要case by case分析，还是按照常规思路去分析，对于变更不太频繁的一些冒烟测试用例集，还是比较适合用自动化测试的，另外，基于支付宝的技术架构和业务复杂度，后期的全站性的链路回归测试，也是比较适合自动化测试的。

对于单元测试、接口测试、UI自动化测试，大家应该能够深刻感受到，其实任何一个用例case，如果用自动化去实现，最后都会变成一个测试方法method，从某种意义上来说，可以认为case等于method，正是基于这点考虑，我们打造了蚂蚁金服全站分层自动化回归平台AQC-Auto，大家可以参考下我的那篇文章，见http://www.51testing.com/html/72/n-867872.html

在蚂蚁金服，目前的自动化程度还是比较高的，管理层对自动化的重视程度也在不断的提升，全站拥有A1级应用的接口测试回归、A2级接口测试回归、A3级接口测试回归、WEBUI集成测试回归、环境监控监测回归以及各业务团队自己的回归等，这些回归用例的管控和执行调度，都是work在我们的AQC-Auto平台上，至于实施的一些数据，不太便于分享。

在支付宝，自动化测试也许将会在全站性的回归测试、全链路的回归测试中发挥更大作用，我们的AQC-Auto平台提供多维度的自动化用例审计报告，如阶段内自动化效率提升率、UI自动化回归频率、各类型自动化用例增长情况等，详情见下图：

关于自动化框架，统一化测试框架的趋势将还会持续前行，框架的设计要秉承简单易用、易扩展的理念，要解决的应该是高度抽象的技术组件问题，比如数据驱动（解决单method多自动化用例的问题）、数据初始化（解决批量数据初始化能力）、运行日志框架（捕获用例的每个步骤关键信息，便于问题排查）、页面对象模型（解决基于UI自动化的页面元素复用和组织问题）、执行机runner（适配不同类型用例执行的监测，便于与执行调度中心进行协调）以及常见工具类。

部分的接口测试用例，是用的我们自己研发的接口测试框架ATS框架（基于testng、junit以及支付宝的开发框架sofa等）。

同时，我们要强化自己的项目沟通与协调能力，单打独奏的年代已成为历史。

走出去，引进来，可以适当参加一些技术活动，如top100summit、chinatesting、infoq等相关活动，可以接触到一些业界的测试新技术等，同时，可以适当买一些经典专业书籍，汲取其养分，为己所用。

测试这个岗位很长一段时间内一定不会消失，但一定会更加的技术化，工程化研发效能提升的意识将逐步被强化。

数据驱动研发模式（Data Driven Development）即将到来，整个研发生命周期（需求、立项、设计、实现、稳定化、交付、运维等）会更加的透明化，将给研发带来更大的挑战，只有拥有过硬的专业和沟通技能，才能立于不败之地。届时，工程化研发团队的效能度量体系将再一次被刷新。

大家将会更加关注团队研发效能的提升，只要是可以促进产品发展的，不论白猫还是黑猫，那就是好猫。

至于跳槽的话，擦亮眼睛，跟对人，做对事，找到适合自己的平台，当然，自己的能力过硬才是硬道理。

作为一个IT从业人员，深深感受到技术发展带来的挑战和机遇，路漫漫其修远兮，吾将上下而求索，也很期待有更多新的东西和大家分享。