我们新推出大淘宝技术年度特刊《学如逆水行舟，不进则退——工程师2023年度成长总结专题》，专题收录10余篇工程师2023真诚心路历程与经验思考，覆盖终端、服务端、技术质量等技术领域，这是他们的心得体会，欢迎同行的你一起沟通交流。
作者天士从事测试开发十多年，期间经历不少角色转换，以下是他在测开成长升级、质量体系建设、专项建设方面的总结，以及职场上的一些思考。
引言
不知不知觉，已经从事测试开发这个行当10来年了，从上大学到参加工作，从南方到北方再回南方，辗转了大半个中国，如今算算进公司已经开启了第五个年头，今年就要五年陈了。
兜兜转转这十多年间，虽然一直都在质量领域，但其实也经历过不少的角色转换，这几年学习了很多，也收获了很多，希望借此机会跟大家分享自己这些年在质量域和职场上自己的一点思考和总结，写在现在，也写给未来的自己，记录今天的所思所想。
Part1：测开的成长
▐ 我眼中的测试开发
质量的概念最初仅用于产品，在工业时代兴起的时候，质量的概念就已经存在，生产线上下来的产品质量决定着公司的良次品率、成本乃至公司的兴衰，慢慢的也诞生了国际质量认证体系，而在这之后质量逐渐扩展到服务、过程、体系和组织，以及以上几项的组合。
如今互联网公司的测试开发，最重要的就是通过多手段保障软件产品的质量和稳定性，保持对质量的高度敏感和追求。作为一个测试开发，传统意义上的职责主要负责测试用例，测试方法，测试框架的设计，支持测试流程的自动化、持续集成和持续交付，更深一步的职责需要同时具备测试和开发技能，熟悉项目技术架构，根据研发流程中的痛点，能够开发测试工具和平台，用技术解决问题，降低门槛，减少人工操作和测试周期，提高测试效率和质量。
▐ 测开的成长之路
不得不承认，我们算是赶上了一个好时代，21世纪互联网浪潮开启，随之而来诞生了非常多职业，我们测开也是其中之一。个人总结一个测开的成长，可分为功能测试->自动化测试->测试开发->专项保障->测试架构这个几个阶段，而测开的工作职责，也从业务测试->质量保障->效能保障->用户体验不断递进。
在初级功能测试阶段，我们需要熟悉测试流程和理论，软件研发流程和生命周期，数据库&Linux，测试流程体系，各种测试方法等。进阶接口测试阶段，需要了解前后端接口测试框架，接口协议和抓包，web端，移动端的交互体系，灰盒/白盒测试方法等，总而言之，需要全方面了解业务和软件生命周期。
业务功能稳定后，我们就要想办法提高测试效率，而通过编写可重复执行的测试脚本和程序来自动执行测试，可减少人工测试周期，提高测试和回归效率，实现测试左移和测试右移。当年在北京时，各种UI自动化UIAutomator，APP自动化Appium，web自动化Selenium，录制回放自动化QTP，接口自动化Robot Framework，Pytest，单元测试JUnit，TestNG等，都尝试在业务中使用过，也有一两年的时间，主要一大块工作内容就是用python，C#，java等语言通过各种自动化测试框架编写自动化脚本，然后在Jenkins实现持续集成和持续交付，也为版本回归大大提高了效率。
2019年进入阿里之后，我们开始测开转型，测试角色不再局限于功能和自动化测试，我们需要熟悉编程语言，熟悉自己业务的技术架构，参与开发的技术评审，根据业务测试、数据、流程，运维上的痛点，通过编写脚本，开发工具和平台等方式来提高测试效率、测试广度、测试深度，用更高的测试覆盖率来保障项目质量，随之而来也诞生了各种自动化平台，持续集成devops，数据生产平台等等。
掌握了测开技能，下一阶段就需要在各个专项上横向拓展了，在2020年后开始接触各种各样的专项，比如APP专项（启动性能、安全测试、弱网测试、兼容性测试等），性能专项（压测，性能监控，帧率/卡顿率），稳定性专项（容量规划，监控预警，1-5-10，预案，限流等），资金专项（三图一表，资损场景，离线/实时对账，应急止血），效能专项（测试效能、研发效能）等，而在这些专项上的深耕，有助于真正了解整个软件全生命周期的质量保障，也能让测开不只停留于质量保障，可以往前一步做的更多。
再往后一步的测试架构，个人觉得应该是可以根据不同项目类型，合理规划测试资源和测试手段，具备敏锐的风险识别和应对能力，通过质量分析和评估，给出一些开发架构和测试策略上的有效建议，同时也能联动多方整合资源进行有效沟通，还能持续探索，引入新技术或新方法以不断提升测试效能。
▐ 一阶：如何搭建一个合格的业务质量保障体系
一个新业务完整+健康的质量保障体系建设，应是能串通整个研发生命周期，解决需求交付上各个节点的核心痛点的。就拿之前做用增时搭建的一个质量保障体系举例，首先最重要的是业务全流程梳理和技术架构分析，这个节点花的时间最多，也最复杂，但一定记得磨刀不误砍柴工，只有摸清了前中后整条链路业务流转，以及上下游依赖，包括接口数据传递情况，才能总结出真正的痛点，比如当时用增需求交付就存在触点多验证周期长，跨平台配置链路长，排查问题难，链路数据构造难等核心痛点。
摸清了全链路痛点，接下来就简单了，对症下药即可，我们通过数据驱动&基建完善，让新触点验证从3天缩短到0.5天，策略曝光率提升20%。同时推动研发模式升级和测试左移，让自动化发现Bug率提升10%，保障线上0故障。另外针对运营全链路配置难&排查难的问题，由点到面搭建全链路测试工具，可实现每月提效10+人日。从下图可见，一个符合业务特性的精细化用户运营质量保障体系就基本建设完成了。
一个新业务完整+健康的质量保障体系建设，应是能串通整个研发生命周期，解决需求交付上各个节点的核心痛点的。就拿之前做用增时搭建的一个质量保障体系举例，首先最重要的是业务全流程梳理和技术架构分析，这个节点花的时间最多，也最复杂，但一定记得磨刀不误砍柴工，只有摸清了前中后整条链路业务流转，以及上下游依赖，包括接口数据传递情况，才能总结出真正的痛点，比如当时用增需求交付就存在触点多验证周期长，跨平台配置链路长，排查问题难，链路数据构造难等核心痛点。
摸清了全链路痛点，接下来就简单了，对症下药即可，我们通过数据驱动&基建完善，让新触点验证从3天缩短到0.5天，策略曝光率提升20%。同时推动研发模式升级和测试左移，让自动化发现Bug率提升10%，保障线上0故障。另外针对运营全链路配置难&排查难的问题，由点到面搭建全链路测试工具，可实现每月提效10+人日。从下图可见，一个符合业务特性的精细化用户运营质量保障体系就基本建设完成了。
▐ 二阶：巧用工具解决重复问题
在测试开发的工作过程中，肯定会遇到不少数据上、效率上、问题排查等方面重复性问题，这时候可以运用一些脚本、工具、平台来解决。首先可以横向了解集团内同类型业务是否有对应的解决方案，有的话快速复用即可，如果没有，可以考虑先用低成本的方式开发一个小工具，可高效解决问题即可，如果后续有可复用、可拓展性，再考虑搭建平台来系统化的解决一类问题。
比如我们之前运营策略配置，每天总有同学来问我为什么他配的策略无法透出，而排查时跨业务系统多、沟通成本高，链路异常问题排查耗时长，各域局限单节点排查，一个个系统往下捋非常耗时。于是我在日常工作之余花了差不多两周时间写了一个全链路测试工具，用户可自由选择业务链路，进行链路节点可视化串联，支持按域快速排查与定位问题，针对异常节点明确标识 ，同时有可读性强的异常错误原因&解决方案，也能看到接口数据透传详情，让不熟悉上下游链路的运营&PD&产技同学也可无门槛进行自查，策略无法透出原因一查便知，排查时间可降低95%。
当然，针对用工具解决问题的策略，个人觉得不要为了造轮子而造轮子，小而美的工具就挺好，重点还是要能快速解决问题，不管白猫黑猫，能抓到耗子的就是好猫。
▐ 三阶：从0到1建设资金安全专项
质量体系搭建完，工具平台建设完，就不能再只守着自己眼前的一亩三分地了，文章开头介绍过APP、性能、稳定性、资金、效能等专项深耕，下面我想从最熟悉的资金专项来介绍下通盘的专项建设之路。
彼时还是跨境电商的业务，故障风险严峻，财年理论资损和实际资损风险高，但大家都没防控经验，线上也是0场景0布控，无问题发现能力，后续融合风险还高。于是我们向集团各BU前辈取经，快速明确了第一要务为快速挖掘全量资损场景，建设资损发现能力，高效推进监控/核对覆盖率，具备资损快速止血能力，因此在4月份开始从上到下正式拉起资金安全专项攻坚战。
在这过程中，我们沉淀了“三图一表”和“灵魂三问”的特色化防控方法，结合当时会员电商的业务特性，我们用了一年的时间分三阶段建设了一套资损防控体系：人员带练+防控体系建设+数据化运营。经过一年的运行，我们带练出了一批资金专家，同时推进前中后六大业务域挖掘几百个资损场景，新增布控脚本上千个，挖掘几十个潜在故障，财年的实际资损控制在了很小的一个数额，最终斩获集团的“攻坚克难奖”和“超强特攻队”奖项，不可谓不强。
存量风险基本防控完成后，我们就要开始考虑可持续问题，也就是增量风险和人员效率，于是我们结合原先的线下流程，建设了资金安全中心，把流程约束落进系统、把风险精准分析能力沉淀进工具，将看似割裂的经验和技术能力“无形”织入到高频工作的各环内，整体串成一条“线”来改变大家的工作模式，旨在尽可能动用少的人力，却能覆盖尽可能多的风险。
往细了剖析一下，在资金安全引擎中，我们实现了变更代码的资金风险精准分析，并且把风险识别和卡点到了研发流程中，首先利用系统上资金字段的沉淀，通过字节码分析代码拓扑资金入口，到资金方法，再到资金DB字段的链路调用图，来扫描识别变更代码diff中是否改动到该资金链路，然后再把这部分结果数据纳入风险评估引擎，实现变更资金风险的精准识别，一直到现在，这套流程还运行的非常好。
聊聊我做测试开发的十年心路历程（下）:https://developer.aliyun.com/article/1480486
