作者天士从事测试开发十多年，期间经历不少角色转换，以下是他在测开成长升级、质量体系建设、专项建设方面的总结，以及职场上的一些思考。
不知不知觉，已经从事测试开发这个行当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%。
当然，针对用工具解决问题的策略，个人觉得不要为了造轮子而造轮子，小而美的工具就挺好，重点还是要能快速解决问题，
不管白猫黑猫，能抓到耗子的就是好猫
。
质量体系搭建完，工具平台建设完，就不能再只守着自己眼前的一亩三分地了，文章开头介绍过APP、性能、稳定性、资金、效能等专项深耕，下面我想从最熟悉的资金专项来介绍下通盘的专项建设之路。
彼时还是跨境电商的业务，故障风险严峻，财年理论资损和实际资损风险高，但大家都没防控经验，线上也是0场景0布控，无问题发现能力，后续融合风险还高。于是我们向集团各BU前辈取经，快速明确了第一要务为快速挖掘全量资损场景，建设资损发现能力，高效推进监控/核对覆盖率，具备资损快速止血能力，因此在4月份开始从上到下正式拉起
资金安全专项攻坚战
。
在这过程中，我们沉淀了“三图一表”和“灵魂三问”的特色化防控方法，结合当时会员电商的业务特性，我们用了一年的时间分三阶段建设了一套资损防控体系：
人员带练+防控体系建设+数据化运营
。经过一年的运行，我们带练出了一批资金专家，同时推进前中后六大业务域挖掘几百个资损场景，新增布控脚本上千个，挖掘几十个潜在故障，财年的实际资损控制在了很小的一个数额，最终斩获集团的“攻坚克难奖”和“超强特攻队”奖项，不可谓不强。
存量风险基本防控完成后，我们就要开始考虑可持续问题，也就是
增量风险
和
人员效率
，于是我们结合原先的线下流程，建设了
资金安全中心
，把流程约束落进系统、把风险精准分析能力沉淀进工具，将看似割裂的经验和技术能力“无形”织入到高频工作的各环内，整体串成一条“线”来改变大家的工作模式，旨在尽可能动用少的人力，却能覆盖尽可能多的风险。
往细剖析了一下，在资金安全引擎中，我们实现了变更代码的资金风险精准分析，并且把风险识别和卡点到了研发流程中，首先利用系统上资金字段的沉淀，通过字节码分析代码拓扑资金入口，到资金方法，再到资金DB字段的链路调用图，来扫描识别变更代码diff中是否改动到该资金链路，然后再把这部分结果数据纳入风险评估引擎，实现
变更资金风险的精准识别
，一直到现在，这套流程还运行的非常好。
坦白讲，我自认为不是一个聪明人，在学习和工作的过程中，我见过不少我理解意义上的聪明人，他们的学习能力更强，可以短时间内学习和掌握一项技能，而且还轻轻松松，举一个最典型的例子就是一起玩同一个游戏，他们永远比你上手快，操作好，这也让我十分佩服。
工作中一路走来，我觉得天赋固然重要，但坚持，是一个后天可修炼的难能可贵的品质。很多人会吐槽工作都是“重复做相同的事”，但正是一开始的“重复” ，才给了一个新手成长最好的契机。而且重复并不代表一成不变，我们需要在重复中坚持不断学习，不断进阶，寻求坚持后创新和突破，才能让自己最终成为这个领域的专家。
近一两年行业变化比较多，大家也都会变的焦虑，但其实对于我们搬砖的同学来说，其实大部分消息和变化都没那么重要，可提前布局的事也不多，再说临时抱佛脚也晚了。适当的保持一份钝感力，不要为没有发生的事情而焦虑，
在“不确定”的世界中，不如更专注把当下确定的事情做好
，多学一点专业知识和技能，我觉得反而更有用。
多看书，多成长，与其焦虑，不如行动，知识和经验才是真正属于自己的。
有志者，事竟成，破釜沉舟，百二秦关终属楚；苦心人，天不负，卧薪尝胆，三千越甲可吞吴。
在日常工作过程中，肯定会碰到大大小小许多难题和挑战，比如主管给了一个新方向，或需要推一个新专项，很多时候一开始可能会让人觉得没有头绪，甚至产生自我怀疑：这个挑战我真的能解决/胜任吗？
问题的常见解决方式有很多，比如通用流行的5W2H法，PDCA循环，SMART原则等。我自己的一套体系化解题思路是，做一件事情或解决一个问题前自己先想清楚解题四象限，
所谓解题四象限就是：背景，挑战，解题思路，结果
，其实类似任务分解法（WBS）。
首先想清楚问题的背景，也就是核心要解决问题是什么，审题很重要。其次要明确解决上述问题，目前最大的几个挑战是什么，资源、时间还是方式方法。等理清楚了问题和挑战，那么接下来就是解题思路了，是流程机制优化，还是工具平台创新，最好是沙盘推演过的/数据论证过的，且有一点很重要的是一定要让共同协作的人理解和认可，多一些沟通，大家认可解题步骤才能有真正的驱动力。几个解题的核心点都拆成任务完成之后，只要沙盘推演/数据论证的没问题，结果大概率就能达成了。
之前负责的资金安全专项，就是用这个解题四象限去推进和解决的，事实证明效果还不错。
很多工作单凭一个人之力，是无法推进下去的，特别是跨团队协作和横向事项，那么势必就需要“借力”，而如何“借力”也是一个有很深学问的命题。
个人觉得有几个点可以参考：首先，要跟自己的产品、开发、运营同学们建立良好的革命友谊，平时有需要帮忙的地方积极伸手，站在对方的角度思考和解决问题，这样将来有你需要“借力”的时候相信他们也会很愿意帮忙。其次，
把事情从“借力”变为“合力”
，要想清楚这个“借力”能为对方带来什么价值，能帮他解决什么问题，做方案时换位思考，帮对方也多想一步，也许就能快速达成一致形成“合力”。最后，至上而下推进事情，大家认可共同价值，以合作模式推进，如果是一些关键事项，可以进合作双方的OKR，这样就能
形成真正的“合力”
。
