从事测试开发十多年，期间经历不少角色转换，以下是他在测开成长升级、质量体系建设、专项建设方面的总结，以及职场上的一些思考。
不知不知觉，已经从事测试开发这个行当 10 来年了，从上大学到参加工作，从南方到北方再回南方，辗转了大半个中国，如今算算进公司已经开启了第五个年头，今年就要五年陈了。兜兜转转这十多年间，虽然一直都在质量领域，但其实也经历过不少的角色转换，这几年学习了很多，也收获了很多，希望借此机会跟大家分享自己这些年在质量域和职场上自己的一点思考和总结，写在现在，也写给未来的自己，记录今天的所思所想。
质量的概念最初仅用于产品，在工业时代兴起的时候，质量的概念就已经存在，生产线上下来的产品质量决定着公司的良次品率、成本乃至公司的兴衰，慢慢的也诞生了国际质量认证体系，而在这之后质量逐渐扩展到服务、过程、体系和组织，以及以上几项的组合。如今互联网公司的测试开发，最重要的就是通过多手段保障软件产品的质量和稳定性，保持对质量的高度敏感和追求。作为一个测试开发，传统意义上的职责主要负责测试用例，测试方法，测试框架的设计，支持测试流程的自动化、持续集成和持续交付，更深一步的职责需要同时具备测试和开发技能，熟悉项目技术架构，根据研发流程中的痛点，能够开发测试工具和平台，用技术解决问题，降低门槛，减少人工操作和测试周期，提高测试效率和质量。
不得不承认，我们算是赶上了一个好时代，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+ 人日。从下图可见，一个符合业务特性的精细化用户运营质量保障体系就基本建设完成了。
在测试开发的工作过程中，肯定会遇到不少数据上、效率上、问题排查等方面重复性问题，这时候可以运用一些脚本、工具、平台来解决。首先可以横向了解集团内同类型业务是否有对应的解决方案，有的话快速复用即可，如果没有，可以考虑先用低成本的方式开发一个小工具，可高效解决问题即可，如果后续有可复用、可拓展性，再考虑搭建平台来系统化的解决一类问题。比如我们之前运营策略配置，每天总有同学来问我为什么他配的策略无法透出，而排查时跨业务系统多、沟通成本高，链路异常问题排查耗时长，各域局限单节点排查，一个个系统往下捋非常耗时。于是我在日常工作之余花了差不多两周时间写了一个全链路测试工具，用户可自由选择业务链路，进行链路节点可视化串联，支持按域快速排查与定位问题，针对异常节点明确标识 ，同时有可读性强的异常错误原因&解决方案，也能看到接口数据透传详情，让不熟悉上下游链路的运营&PD&产技同学也可无门槛进行自查，策略无法透出原因一查便知，排查时间可降低 95%。
当然，针对用工具解决问题的策略，个人觉得不要为了造轮子而造轮子，小而美的工具就挺好，重点还是要能快速解决问题，不管白猫黑猫，能抓到耗子的就是好猫。
更多内容可以学习《测试工程师 Python 工具开发实战》书籍、《大话性能测试 JMeter 实战》书籍
质量体系搭建完，工具平台建设完，就不能再只守着自己眼前的一亩三分地了，文章开头介绍过 APP、性能、稳定性、资金、效能等专项深耕，下面我想从最熟悉的资金专项来介绍下通盘的专项建设之路。彼时还是跨境电商的业务，故障风险严峻，财年理论资损和实际资损风险高，但大家都没防控经验，线上也是 0 场景 0 布控，无问题发现能力，后续融合风险还高。于是我们向集团各 BU 前辈取经，快速明确了第一要务为快速挖掘全量资损场景，建设资损发现能力，高效推进监控/核对覆盖率，具备资损快速止血能力，因此在 4 月份开始从上到下正式拉起资金安全专项攻坚战。在这过程中，我们沉淀了 “三图一表” 和 “灵魂三问” 的特色化防控方法，结合当时会员电商的业务特性，我们用了一年的时间分三阶段建设了一套资损防控体系：人员带练 + 防控体系建设 + 数据化运营。经过一年的运行，我们带练出了一批资金专家，同时推进前中后六大业务域挖掘几百个资损场景，新增布控脚本上千个，挖掘几十个潜在故障，财年的实际资损控制在了很小的一个数额，最终斩获集团的 “攻坚克难奖” 和 “超强特攻队” 奖项，不可谓不强。
存量风险基本防控完成后，我们就要开始考虑可持续问题，也就是增量风险和人员效率，于是我们结合原先的线下流程，建设了资金安全中心，把流程约束落进系统、把风险精准分析能力沉淀进工具，将看似割裂的经验和技术能力 “无形” 织入到高频工作的各环内，整体串成一条 “线” 来改变大家的工作模式，旨在尽可能动用少的人力，却能覆盖尽可能多的风险。
往细剖析了一下，在资金安全引擎中，我们实现了变更代码的资金风险精准分析，并且把风险识别和卡点到了研发流程中，首先利用系统上资金字段的沉淀，通过字节码分析代码拓扑资金入口，到资金方法，再到资金 DB 字段的链路调用图，来扫描识别变更代码 diff 中是否改动到该资金链路，然后再把这部分结果数据纳入风险评估引擎，实现变更资金风险的精准识别，一直到现在，这套流程还运行的非常好。
坦白讲，我自认为不是一个聪明人，在学习和工作的过程中，我见过不少我理解意义上的聪明人，他们的学习能力更强，可以短时间内学习和掌握一项技能，而且还轻轻松松，举一个最典型的例子就是一起玩同一个游戏，他们永远比你上手快，操作好，这也让我十分佩服。工作中一路走来，我觉得天赋固然重要，但坚持，是一个后天可修炼的难能可贵的品质。很多人会吐槽工作都是 “重复做相同的事”，但正是一开始的 “重复” ，才给了一个新手成长最好的契机。而且重复并不代表一成不变，我们需要在重复中坚持不断学习，不断进阶，寻求坚持后创新和突破，才能让自己最终成为这个领域的专家。近一两年行业变化比较多，大家也都会变的焦虑，但其实对于我们搬砖的同学来说，其实大部分消息和变化都没那么重要，可提前布局的事也不多，再说临时抱佛脚也晚了。适当的保持一份钝感力，不要为没有发生的事情而焦虑，在 “不确定” 的世界中，不如更专注把当下确定的事情做好，多学一点专业知识和技能，我觉得反而更有用。多看书，多成长，与其焦虑，不如行动，知识和经验才是真正属于自己的。 有志者，事竟成，破釜沉舟，百二秦关终属楚；苦心人，天不负，卧薪尝胆，三千越甲可吞吴。
在日常工作过程中，肯定会碰到大大小小许多难题和挑战，比如主管给了一个新方向，或需要推一个新专项，很多时候一开始可能会让人觉得没有头绪，甚至产生自我怀疑：这个挑战我真的能解决/胜任吗？问题的常见解决方式有很多，比如通用流行的 5W2H 法，PDCA 循环，SMART 原则等。我自己的一套体系化解题思路是，做一件事情或解决一个问题前自己先想清楚解题四象限，所谓解题四象限就是：背景，挑战，解题思路，结果，其实类似任务分解法（WBS）。首先想清楚问题的背景，也就是核心要解决问题是什么，审题很重要。其次要明确解决上述问题，目前最大的几个挑战是什么，资源、时间还是方式方法。等理清楚了问题和挑战，那么接下来就是解题思路了，是流程机制优化，还是工具平台创新，最好是沙盘推演过的/数据论证过的，且有一点很重要的是一定要让共同协作的人理解和认可，多一些沟通，大家认可解题步骤才能有真正的驱动力。几个解题的核心点都拆成任务完成之后，只要沙盘推演/数据论证的没问题，结果大概率就能达成了。之前负责的资金安全专项，就是用这个解题四象限去推进和解决的，事实证明效果还不错。
很多工作单凭一个人之力，是无法推进下去的，特别是跨团队协作和横向事项，那么势必就需要 “借力”，而如何 “借力” 也是一个有很深学问的命题。
个人觉得有几个点可以参考：首先，要跟自己的产品、开发、运营同学们建立良好的革命友谊，平时有需要帮忙的地方积极伸手，站在对方的角度思考和解决问题，这样将来有你需要 “借力” 的时候相信他们也会很愿意帮忙。其次，把事情从 “借力” 变为 “合力” ，要想清楚这个 “借力” 能为对方带来什么价值，能帮他解决什么问题，做方案时换位思考，帮对方也多想一步，也许就能快速达成一致形成 “合力”。最后，至上而下推进事情，大家认可共同价值，以合作模式推进，如果是一些关键事项，可以进合作双方的 OKR，这样就能形成真正的 “合力” 。
这些年来，遇到过很多的挑战，也碰到过很多机会。有位职场前辈曾经跟我说过一句话，让我记忆深刻：这辈子，能够让你往前跨一大步的机会也许就这么几个，可能几年才会有一个，所以，日常需要多积累，当机会来临时，付出百分之两百的努力，牢牢抓住他，不要给自己留遗憾。 我始终相信，机会，是留给有准备的人。还记得几年前刚做迁移融合，做资金安全专项，写工具平台的时候，都觉得挑战很大，但办法总比困难多，也许要比别人付出更多的努力，但真正达成目标的时候，还是会有很大的认同感和成就感的，说实话这也将会是你以后跳槽的资本。所以，挑战也是机会，当一个人有更大的概率能把事情做好，那么他在赢得信任后通常又会有更大的机会。其实回头看，你觉得最难的时候，也是你成长最快的时候。 我就是抱着这种信念感一步步往前走，过程中肯定也有失败，但不要害怕犯错，犯错会让人变的更好，在犯错后总结经验再前进，这样的成功才更有意义，也才能真正的实现自我价值。这几年来，不管是做资金专项时取得的 “春雷·春雨 行动先锋奖”，还是财年取得的阿里安全生产 “FY22 红苹果” 奖，以及中间水到渠成的晋升成功，作为讲师参加 MTSC 2022 第十届中国互联网测试开发大会，还有最近 2023 年双 11 作为大促 PTM 取得的 “舍我其谁奖”，都是对自己抓住机会，努力拼搏后最好的褒奖。
它山之石，可以攻玉，保持学习的习惯，开放性是我们干互联网这行的一个重要特点，所以每天都会有很多新的技术更新迭代，因此我们需要保持一份危机感，如果一直在吃老本，终有被淘汰的那一天。比如十几年前的手机，前几年的电动汽车、短视频、直播，以及这两年大火的 AI，都会或多或少影响我们的行业技术栈和业务方向。前几天看到一个关于 AI 行业分析的文章，对我触动蛮大的，ChatGPT 的横空出世，让大家都有了危机感，AI 领域上每天这种快速的变化是在以往的科技史上都还没出现过的，而未来大概率是 AI 的时代，这也可能是接下来增长最快的一个领域，但也是我们代差最大的一个领域，所以这中间就存在巨大的挑战和机遇，因为 “算力” 未来可能就会像钱一样变为现金等价物。所以对新鲜事物，保持学习和探索，会让我们始终都领先别人一步。保持阅读，保持自律，这是一个很好的习惯，书对人的影响是潜移默化的，家里有小朋友的建议一定从小培养好阅读的习惯，会让人终身受益，这在很多公司主管和名人身上都见过。但说实话我没有做的很好，我家里有好几个书架，但都是我家属的书，我看过的只有一小部分，所以新一年里我也给自己定个小目标，先从 6 本开始。
更多内容可以学习《测试工程师 Python 工具开发实战》书籍、《大话性能测试 JMeter 实战》书籍
在文章的结尾，借用康德的一句话来总结：我始终只求克服自己，不求克服命运；只求改变自己的欲望，不求改变世界秩序。 这也是罗翔老师前几天来公司讲座时赠予大家的一句话，希望我们都从一点一滴改变自己开始，也许你能改变的就不止一点点，谨以此句赠予一路上披荆斩棘且奋勇前行的质量人们，加油！吾心自有光明月,千古团圆永无缺。
