以下文章来源于阿里巴巴技术质量，作者张晓霞

蚂蚁集团17年资深测试老炮的职业生涯阶段小结，从产品形态、研发模式、组织视角看测试工作、测试技术，到个体角度看测试能力结构，探讨个人成长。万字长文，全是干货，小编真心希望大家能找一个固定不被打扰时间仔细阅读，相信这些真实的技术成长经验，能给到你一些有益的启发。

写在前面

当年我还在上学的时候，很喜欢一本漫画：《关于上班这件事》--朱德庸，于是，我毕业入职后第一年，我老板让我做的第一个ppt，我很高兴的写了大大的标题：《关于测试这件事》，后来被老板勒令改为《xx项目测试经验分享》。

时间一晃，上周也刚过了加入蚂蚁的6周年，还差10天就是我测试从业17周年，终于可以用这个题目，把我这些年的工作经历、经验、思考串起来，分享给大家。

如果你已经在测试、质量行业摸爬滚打了几年，并且有过这样的疑问或困惑：

一直都在做项目感觉没积累怎么办？
我想做些新专项，但不知道做什么？
质量的职业发展规划是怎样的？怎样晋升到下一个层级？
为什么质量团队分分合合？
我这一年成长不明显了怎么办？要不要换个团队，或是换个岗位？

希望这些分享能给你一些视角或思路，透过表面，把问题看得更清楚。

本文分为六个部分，前三个部分从产品形态、研发模式看测试工作、测试技术，后面四、五部分从组织视角看测试工作、测试组织，第六部分从个体角度看测试能力结构，简单探讨个人成长。

一、产品形态决定测试工作

本节要点：产品形态的不同带来测试重点不同，测试方法、工具也随之演变发展。传统的工程产品测试方法论已经比较完善，新业务，可以借鉴已有的方法、工具快速建立一套全面有效的基础测试体系，测试工作重点通常落在针对业务特点的专项测试技术上。除工程产品外，数据算法模型等智能化业务的测试是近几年测试行业的热点，有着巨大的发展空间。

详细内容见本次发布的第2篇

二、研发模式对测试工作的要求

本节要点：研发模式对测试工作提出了更具体的要求，研发模式越敏捷，对测试工作的技术积累要求越高，最终要通过自动化、持续集成等方式把测试工作串联起来。

详细内容见本次发布的第3篇

三、测试技术演化

本节要点：测试技术持续向质量、效能两个方向演进，为质量人提供了广阔的技术发展空间。

业务（产品形态和研发模式）对测试工作提出的要求，要由测试技术来回答。

业务向测试工作提的要求有两类，一是质量，二是效能（含效率、成本），由此测试技术也分为两个方向：

1 如何保证测试质量：测全、测对

最基本的方法，如等价类划分、边界值分析等不再赘述，业务实践中，用户操作等价类的覆盖和代码覆盖是两个重要的衡量。由此演化出的各种度量方式，都是为了牵引这两个方向的100%覆盖。

用例设计的两个重要来源是prd和系分，prd代表用户操作行为，系分代表系统实现逻辑，互联网服务经过二十余年的发展，用户功能日益强大，功能背后的实现逻辑也更复杂，同一个操作背后可能有成千上万的等价类（想想双十一下单的优惠策略）。

为了100%覆盖这个终极目标，测试人员需要对被测对象有深刻的理解，从功能、代码、正常逻辑、异常处理等多维度拆解出等价类，最终设计出能够运行的用例来覆盖每一个等价类。

测试技术的发展也依托于此而发展：

被测对象理解：prd分析，系统链路分析，变更影响分析等。

等价类拆解&覆盖：代码覆盖率度量、fuzz测试、流量场景聚类、代码规则扫描、用例生成等。

用例校验关系识别与判定：代码数据血缘、校验自动推导、测试结果判定等。

2 如何测得快，且成本低

在测全基础上，提高效率，降低成本是永远的诉求。

这里有一条很清晰的技术演进路线：

手工测试->测试工具化->自动化测试->测试平台化/服务化->智能化测试

测试工具：

测试工作天然有重复性：版本间的重复工作是回归，不同功能case间的重复是环境、数据初始化；同一个功能不同等价类case间的重复是用例执行，结果验证。同一个case也会在版本内多次提测中重复执行，以及开发自测和测试工作之间也有重复，最极端的重复是兼容性测试，所有环节动作都是重复的。

如果把手工测试拆解为：环境搭建、数据准备、用例执行、结果读取、结果校验、报告撰写这些环节，那么每个环节都可以通过工具化解决提高人工执行的效率。

自动化：

如果每个环节都实现了工具化，把所有环节通过工具、脚本进一步串联起来，做到单个用例的一键执行，就实现了单用例自动化。在解决用例间执行干扰/依赖后，实现所有用例的批量执行，就可以和代码提交联动实现持续集成了。

测试平台化/服务化：

用例自动化程度越高，用例自动化成本也会越高，用例覆盖越高，用例间的重复也会越高。业务和团队共同发展到一定程度时，可以进一步抽象测试的通用能力，把跨团队跨业务重复使用的测试能力以更灵活的平台化服务化方式提供给更广范围，支持百人到千人技术团队（开发+测试）。如自动化测试框架、通用mock、通用扫描规则、通用校验、代码扫描、性能测试平台等。

智能化测试：

和上文讲的智能化业务的测试不同，测试智能化是指用智能化的技术做测试。我曾有幸在19年带领经济体质量小组之智能化测试小组，对智能化测试进行了一些探索，也尝试梳理了智能化测试标准等级定义。我们小组通过把测试活动分为三大领域共8个子领域，对每个子领域的智能化空间进行了拆解和部分实践案例的对应。

标准的制定是为了牵引技术发展方向，标准中潜在体现了智能化测试的领域难点：通过算法模型/机器学习解决测试过程中强依赖人的环节，如场景规划覆盖、结果判定，做到无人介入。

测试中无人介入相当于：测试效率=机器执行效率，测试中人的周期占用->0，目前看得到的一些探索有：用例自动生成、用例自动校验（通过图像识别做UI自动校验，通过数据关系推导做数据自动校验等）、用例失败自动定位、用例自动修复等。

智能化测试在行业里已经尝试了若干年，但还没看到有完全替代人的实践案例，我个人对此方向仍很乐观：伴随测试过程持续标准化、测试数据资产的积累、算法模型技术发展、测试人员算法模型能力的提升，智能化测试一定会产生越来越大的贡献。

四、质量职责范围演进

太长不看版：随着行业诉求和技术发展，测试的概念外延逐步扩大，质量人承接的职责范围也在逐步扩大。阿里蚂蚁的质量团队逐步承接了技术风险这个更大的职责，对质量人的职业发展带来了新的领域空间。

讲完了测试工作，也要讲讲测试这个角色职责的演进过程。

类比测试技术，行业中测试职责也有一条明显的演进路线，对标互联网行业头部公司，也能在每个公司发展历程中看到同样的发展历程。

测试->质量->质量+效能->质量效能+技术风险

测试 vs 质量：

在前文中，测试和质量这两种职责基本已经同义了，但在行业发展初期，从测试到质量，代表了做测试过程交付和做质量结果交付两种职责的重大区别。但凡被称为质量团队，就可以突破测试工作的局限性，从各个角度做质量保障，如研发流程管理，sqa(软件质量保证), 这些工作内容都可以属于质量团队。结合业务需要，质量团队也可以承担业务质量评测、业务竞品对比等工作内容。

效能：

当业务质量到达稳定状态时，效能要求一定会被提出来。效能可以分为质量效能、研发效能两层scope。

质量效能由于天然重复的特性，通常会被先提出来。常见方式是依托于devops流程做工具平台提效，对每个成本高、重复度高的环节沉淀能力。这部分工作在测试技术之如何测的更快环节已有较多展开，不做重复分析。

研发效能的范围更广，通过对研发全局工作的重复性识别，找到提效空间，沉淀能力，如相似的营销活动需求多次开发，可以沉淀低代码营销配置能力+运营自助预跑验收能力，同类的机构、商户多次接入，可以沉淀机构自助接入+自助联调能力等。落在研发侧的工作通常由研发角色承担，落在质量侧的工作可以由质量角色承担。

技术风险：

这是我加入蚂蚁后学习最多的领域，也是行业近几年的新趋势。

先讲一个大概9年前的亲身经历：

当时我作为质量团队负责人，业务范围包括一个pv千万的web网站，某天我老板（大质量团队负责人）电话打过来：“网站挂了？网上都说打不开，我试了下也首页白屏。”我查了一圈，回复他：“不是程序bug，这几天也没项目发布，说是服务器挂了。”我老板说：“那然后呢？”我说：“不是bug呀，也就不是漏测，跟咱们团队没关系，运维在处理了。”然后我老板花了一些时间让我理解，网站挂了怎么可能跟质量没关系，质量团队不应该不知道网站挂了，质量团队应该做点什么让产品质量更好，我们毕竟叫质量团队啊等等… 后来就做了精细化业务监控，分级报警，高频报警的规则自动定位等线上质量专项。对标现在的蚂蚁用词，差不多是技术风险、高可用、稳定性、高保治理、应急快反这类工作。

为什么讲这个经历呢，这个事情当时给了我很大的触动：我们是质量团队，我们测试每一行发布上线的代码，但线上还会出严重影响用户的质量问题，那质量团队应该如何做（定义职责、承担职责），来为这部分质量负责？在那时，我们把它定义为线上质量，即不论是否由程序bug、设计导致，会对线上质量产生影响的问题，都是职责范围，为此我们要从发现问题，快速定位，解决恢复这些角度形成方法论，和其他角色协同，建立联合流程。对我来说，这个职责在前公司叫线上质量，在蚂蚁叫技术风险。

（注1：这里有个概念逻辑冲突：线上质量=技术风险，所以质量（线下+线上）包含了技术风险。但同时，受上述个人经历强影响，在我心里技术风险 = 会让线上出问题的所有问题，那么技术风险反向涵盖了传统质量概念，因为程序质量也属于线上出问题的一种来源。）

（注2：由于技术风险的职责注定由多个团队、角色共同承担，在各大技术组织里又存在团队角色职责设定的差异，在不同场合语境下，技术风险在指代事、问题、团队时也会有细微差异。）

技术风险工作，可按阶段分为风险识别，预防，发现，止血，定位，恢复，预案演练、红蓝攻防等。类比测试阶段的单元测试、接口测试、集成测试、系统测试、用户测试，这些阶段划分只代表前后依赖，不代表绝对的串行。相信阅读本文的同学对技术风险都有非常多的了解，此处不对具体方法论进行过多展开，只列一下我想强调的几个关键点：

风险识别要从问题的最终表现形式、问题引入来源两个视角来分析。

1）由于技术风险=线上出问题，线上问题的表现自然是最重要的视角。16年蚂蚁定义过技术风险的6个领域：高可用、资金安全、数据质量、性能容量、成本、安全，质量角色涉及较多的前四类风险，就是从问题表现来定义的。虽然这几个概念也不完全正交（比如性能容量问题会表现为高可用问题，数据质量也会引发资金安全表现），在工作中用于区分技术风险主要类型是比较易用的。

2）问题引入来源是多样的，有句经典的话：“没有变更就没有伤害。”提供服务的整条链路，从网关、应用、配置、中间件、云、机房硬件、网络、等都有可能引入变更，导致线上问题。（自家没有变更可能光缆有变更-_-）。

3）在风险识别环节，一定要有正向逆向两个思路才能保证风险识别完整：从可能出现的问题反推会有哪些原因（服务挂掉可能因为bug，机器，机房，网络），从可能的变更正推会导致的问题（配置错误可能导致服务挂掉，金额错误，文案客诉）。

针对问题引入来源建预防能力，针对问题表现形式建发现能力。
止血和定位恢复两条线要解耦并行。

在测试概念中，定位后修复bug = 解决问题，但在技术风险中，止血和定位恢复是两个概念，止血只代表问题不再被持续触发，影响面不再扩大，但已发生的问题后果仍在，（比如卡单，数据错误，资金收付错误），恢复才是彻底回到出问题前一切正常的状态。所以，技术风险的时间正相关特性要求我们，不能同时止血&恢复时，一定优先止血，止血恢复要解耦。

预案需要定期评估、演练来保持有效性，预案的错误会引发次生故障。
红蓝攻防是为了验证发现、止血、恢复、预案这一系列技术风险体系能力。类似测试的回归能力，确保线上系统、负责人的技术风险防控能力。
文化意识很重要。技术风险相对线下测试来说，涉及人的工作内容更多样：风险分析，应急的响应速度，应急的决策判断，多部门协同（如客满运营，产品，pr，gr，商务，财务等）等，并且，风险的线上伤害性决定了不能靠实战来积累经验。所以在日常工作中，团队更要强调对风险的敬畏，对流程的严格执行，对每次攻防演练的认真对待，要通过持续的风险文化运营来保持风险文化传承。

技术风险的技术发展也是围绕这几个阶段展开，类似测试过程，每个阶段也正在经历从人工到自动化到智能化的过程。由于风险表现是基于线上生产环境的，所以风险的基础数据相比测试的基础数据更容易标准化（变更单、操作单、监控项、核对规则、调用链路、数据血缘等），这几年风险数据的积累也为风险业务的智能化铺好了道路，也出现了很多不错的技术实践。

如前所述，质量和技术风险已经是水乳交融的两个概念，身为质量人，一定不能缺席技术风险领域的探索和开拓，从职责承担到经验积累到能力建设都要实打实的做起来。

五、质量组织设计

要点：要理解自己的质量团队，才能更好地评价自己的现在，规划自己的未来。

详细内容见本次发布的第4篇

六、质量人的职业发展规划

要点：了解能力结构要求，拆解分析自己。

最后说一下质量人的职业发展规划。

其实促使我写这篇文章的最主要动力，就来自于这些年质量同学问我最多的这个问题。而要回答这个问题，一定要如上文所述，先看清楚所处的环境（行业，公司，业务，团队），然后看清楚自己，最后才能自己回答自己的职业发展问题。

前面从产品形态、研发模式谈到测试技术的发展，又从角色职责谈到了组织设计，其实1-3部分是讲质量人能做什么，4-5部分讲的是组织需要质量人做什么，这一章才可以回归个体，我已在做什么，我还能做什么，我的未来要做什么？

经过这些年的发展，各大公司都已经建立了一套稳定的质量专业晋升体系，晋升标准背后就是能力结构，我们要看清楚自己，最方便的方式就是按能力结构拆解自己，并对应到晋升层级的具体标准分析自己。

质量专业能力可以拆解为三个维度：

业务、架构理解力，这是质量角色基础能力，体现为：理解业务模式、产品设计、流程逻辑、以及技术侧的架构设计、技术栈、实现细节。理解不仅是为了做质量效能风险环节的工作，还需要以质量视角尽早参与到产品、架构设计，在最早阶段交付质量价值。
质量技术能力，这是质量角色的核心能力，从测试分析到测试策略，从人工到自动化，从基础测试能力建设到测试创新技术落地，需要对行业技术发展保持敏锐，不断扩展视野，促进前沿技术落地，针对业务特点提供质量技术解决方案。
工程数据算法等通用技术能力，这些是质量角色的催化剂能力，工程能力从自动化用例代码编写，到质量工具、平台的建设、质量架构设计和交付，数据算法能力体现在如何测试智能化业务，以及如何用智能化进行测试。

随着行业发展，这三个维度也各自具有了足够的技术纵深，短期内想要兼顾发展并不容易。能力规划有个很重要的原则：发挥优势。我个人建议，初期要适当涉猎多个技术方向（充分借助团队给予的机会），对自己在每个方向的能力水平、潜力、兴趣度有所了解；中期固定一到两个自己擅长或自己喜欢，最好是又擅长又喜欢的方向，深耕2-3年，再重复这个评估-选择的过程。

如何评估自身能力到达什么程度呢？记住一个原则：实至名归。拿到结果才能证明能力。

门槛要求是负责大项目，负责复杂业务（按能力级别对标多大多复杂），进阶要求是在过程中有技术方法、体系、创新的落地体现，终极要求是证明以上过程结果是因你而达成的。

分享给大家一个实用小技巧：

每年总结自己做的最难的事情，跟上一年最难的事情作对比。更难了吗？

每年回顾自己用的最牛的技能，跟上一年最牛的技能比，更牛了吗？

每年想想自己的工作，换成两年前的自己，觉得那时候的自己就能胜任的，请举手。举手的同学，请注意你的成长自评。

个人成长和组织发展大部分时候是正相关的，如果两者出现了不协调，那么一定有一方需要做出变化。每个人是自己的职业发展第一责任人，需要更主动迈出一步，跟自己的主管谈谈，对齐认知，获得反馈，寻求支持。

最后，质量人的职业发展规划可以跳出质量线，由于质量工作的特性，接触业务多样化，专业能力涉及广，只要下定决心调整能力结构，转岗业务，研发，效能，项目管理、技术风险的成功案例每年都有很多。

彩蛋时间

回到文初的几个问题，我日常收到的绝大部分这类问题，其实都是基于提问人自身的询问，哪怕对行业的问题背后也是对自身的关心。所以回答问题的人，一定要对提问人有所了解，才能更准确的回答。

以下提供三种方法，操作难度从易到难分为三个等级。

最简单办法，我称之为快照分析法：找主管聊聊，只要是带你超过半年的主管，一定是最了解（也最关心）你当下状态的人，给出的分析反馈也自然是比较准确的。以师为友，做好当下每个任务。

有点麻烦法，我称之为历史回顾法：自己分析下自己从业以来，自己的成长过程，重点分析有哪些关键事件，带来哪些技能的显著提升，是什么样的场景给到你这个机会，你能一路成长到今天（在阿里蚂蚁工作），一定是你做对了什么，把自己的成长关键点提取出来，以史为鉴，再次寻找机会触发。

相当难办法，我称之为未来预判法：找到你信任认可的相对资深的同行（包括你主管），一起讨论未来业务、行业发展，分析对你的岗位，你的技能会有哪些的要求，以终为始，有目标的发展自我。

-------- THE END --------

关于测试这件事：十七年测试老兵的经验分享与思考