从业17年，聊聊关于测试这件事_被测试测试产品形态的演进

作者：小瑕 蚂蚁数字金融线技术团队

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

写在前面

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

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

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

1. 一直都在做项目感觉没积累怎么办？

2. 我想做些新专项，但不知道做什么？

3. 质量的职业发展规划是怎样的？怎样晋升到下一个层级？

4. 为什么质量团队分分合合？

5. 我这一年成长不明显了怎么办？要不要换个团队，或是换个岗位？

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

    

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

        

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

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

“所谓测试,就是以检验产品是否满足需求为目标，通过运行产品发现产品bug。”

这些年来，测试的对象----产品---一直在演变，我们先以产品演变过程中出现的一些产品形态来分析测试工作内容的异同。

1、单机软件

最早的软件测试书籍，是从单机软件的测试开始的，最典型的就是微软的office系列产品。单机软件由于单机安装的特性，以及那时的软件更新频率非常低，所以测试工作除了常规的功能、性能测试外，还需要重点考虑安装包测试，系统兼容性测试，还有很重要的用户反馈bug的复现。按照prd设计测试用例，模拟用户操作，通过界面交互验证功能。这也是测试被称为点点点的缘起。

2、Web服务

05年我开始测试的产品是搜索，典型的web服务。

Web服务的测试可以分为前后端两类测试，前端页面的测试仍可以模拟用户操作来进行用例执行，后端测试由于没有用户界面，需要开发测试工具辅助用例发起和结果查询。这时开始有了接口测试的概念，强调后端应用的可测性。

同时，相比单机软件的功能明确，搜索产品的搜索策略实现更为重要，用例设计不能局限于prd，而要综合考虑系统内部逻辑的实现，如搜索query（测试数据）的选取，抓取排序策略的验证，测试用例设计要以prd和系分为综合输入。

其他更偏功能性的web服务，如论坛，下载站，门户浏览，可以相对简单的通过前端页面进行大部分用例测试，以及对主流浏览器做兼容性测试。前端页面录制回放开始发展。

性能测试在前后端开始分化，后端强调应用处理速度以及硬件占用指标，前端强调页面响应速度。

3、客户端软件

典型产品：社交软件pc版，音乐下载软件pc版，输入法pc版。客户端安装部署在用户电脑，有点类似单机软件，这部分的测试要考虑到用户环境的差异性，尽可能提升模拟覆盖度，同上由于客户端和服务端的连通性，客户端日志可以自动回流辅助监控定位，比单机时代的bug复现方便了很多。

服务端仍以接口测试为主要手段，接口自动化开始逐步发展。

性能测试继续细化，要按每个用户功能进行多维度指标评估。

4、移动app

移动app的兴起大概在10年初，本质和客户端软件是类似的，只不过由于测试环境从pc转到手机，基于界面操作录制回放的自动化测试工具在那时迎来了一波刷新。移动app的渠道发布和更新特性，带来了灰度发布，灰度更新的技术发展。用户行为日志一方面辅助问题发现和定位，一方面也用来做产品迭代参考。日志回传则要考虑用户手机流量占用，标准做法是等用户连wifi时才回传。

兼容性要考虑top20-100机型。

移动互联时代，性能测试开始变得非常重要，显然用户在手机上没有pc上那么耐心。并且还要关注电量，流量，发热、弱网等手机场景特有指标。

5、硬件

14年左右，智能硬件爆发，机缘巧合我也涉及过一点硬件测试：电视盒子。本质跟app类似，多了固件和软件的区分。同时，要考虑到硬件交付质量，可以和厂家联动做批次质量保障等。

6、移动web服务

兼容性由Pc时的浏览器版本覆盖换成了手机浏览器和手机型号的组合覆盖，伴随H5兴起，页面也不再局限于浏览器内展示。

围绕页面的性能测试更精细化，如页面打开的指标有：首字符展示、页面框架展示、首屏展示、全部展示等，一切为了用户体感的快。

7、国际化业务

注意：这个分类和上述分类并不正交，所有上述产品形态都可能是国际化业务，如果只是针对一个特定国家做产品业务，在本地化环境搭建、本地化网络模拟、时区逻辑验证、本地化文案验证、本地化监管合规等方面需要重点关注。

如果国际化业务是面向多国家多语言的，也就是说，一个产品要同时支持至少两套语言，并且可能随时扩展支持更多语言。在产品设计开发上要重点考虑语言无关、语言相关的功能架构设计，在测试过程更要支持国际化、本地化的多版本多语言快速并发测试。开发改一行代码，测试验证10个语言版本，将成为测试效率的噩梦。噩梦的反面则是机会，如何从架构设计、case自动化、case的语言逻辑分离等角度考虑提效，有很大的空间。

8、微服务分布式架构

本质还是服务端测试，接口测试，集成联调，系统测试仍然适用，但因为分布式架构特性，以及单用户功能所涉及的微服务应用/接口数量激增，带来了一些特定问题和解法：通用mock提高mock开发效率，测试环境稳定性要持续治理，接口/异步调用的异常用例覆盖，全链路性能测试在线上做，接口自动化成本激增带来接口测试录制回放的发展等。

9、云上产品/服务

全面上云！！！被测对象的上云，带来测试过程的上云，以及测试工具、测试平台上云。

如果一个云产品部署在单一云上，那么和传统测试的区别主要在于环境相关工作（测试环境、联调环境、性能测试环境、测试工具平台上云等），如果一个云产品部署在多版本云上，以及进一步作为saas产品交付给另一个主体，那么云集成测试、多云适配、客户版本管理、部署方案验证、容灾多活、版本管理、问题复现定位等需要重点考虑。

云上业务的产品形态变化不大，背后的业务模式如saas，toB的研发模式变化对测试带来的影响会更大。

10、大数据/算法模型/智能业务

12年底有一本经典书籍《大数据时代》，明确指出大数据时代最大的转变是，弱化因果性，更关注相关性。对产品带来的变化是：首先要有非常多的数据，其次基于大数据用机器学习等智能方法寻找数据和结果的相关性，最后只要输出结果的准确率足够高，就可以（替代人工实现逻辑）对外提供服务。我所接触的产品有：智能化搜索、个性化推荐、语音图像识别、智能对话等。

这一类产品形态给测试带来了非常大的冲击：因为被测对象的内部逻辑不再清楚可见，测试用例按照实现逻辑覆盖的思路已经完全走不通。同样，即使改为数据覆盖，也很难对数据进行等价类划分，代码覆盖率面对神经网络的节点组合也失去了度量作用。唯一能够对抗的方式是用大数据进行测试。比如把数据分成两部分，一个作为训练/验证集，一个作为测试集，但实际研发过程中，测试的过程和训练验证的过程是极其相似的，没必要把测试过程单独交给测试团队来执行，再加上很多智能业务由于对客质量容忍度高，可以直接在线上进行分桶验证/评测/迭代，整个研发过程很容易就可以跳过测试团队。（所以有些智能业务真的就没有测试团队了。。。）

当然测试还是可以做很多事情。

1）把数据部分拆出来做数据质量保障。

智能业务背后有大数据，除此以外也有纯数据业务：如地图的海量数据，如以数据形态交付给机构的文件，可以把这些纯数据业务的输出数据、智能业务的输入数据、输出数据作为数据类测试对象做全面质量保障。相比服务端、客户端、app端的以用例为核心、面向被测对象的运行过程做测试，数据领域更倾向于面向结果（数据）做测试。我总结原因有以下几种：一，有些数据就是采集/购买的数据，处理过程不在测试范围内。二、即使数据处理过程在测试范围内，面向数据处理逻辑做用例设计、数据构造的精确覆盖成本太高，不如直接测试结果数据。三、  数据服务每次输出结果天然有差异，相比应用服务在发布前做一次测试即可长期运行，数据服务更需要在运行态对每批次数据结果进行测试覆盖/质量保障（测一次不够管用）。

数据质量的方法论、工具服务这几年在阿里体系蓬勃发展，包括但不限于：数据规则校验，数据巡检，数据监控，数据攻防，数据链路稳定性保障等。基于大数据特性也催生了一波测试智能化方案，如核对自动推导，自动攻防等。

2）智能业务的业务效果评测是个大领域。智能业务形态不同，评测分析的角度也各有不同，这里很考验测试人员对业务、数据、算法实现的理解能力。首先定义评测维度，指标，口径，然后圈定评测数据范围进行评测分析，对指标结果不符合预期的做进一步归因分析，最后把整套过程沉淀为工具平台，还可以直接整合在研发流程中。

3）结合智能业务研发特性做提效，如数据集标注/管理/评测平台，badcase归因分析工具，发布流程卡点能力等。这部分工作在智能业务发展初期会起到很大作用。

4）最有挑战的自然是算法模型本身的测试，在性价比约束下还没看到成熟完整的方法论，更现实的处理是在针对业务特性解决局部问题，做投入产出的平衡。我团队有在尝试蜕变测试，badcase归因分析等。

智能业务已经有十年以上的发展，目前持续高速增长中，覆盖了越来越多的行业、业务、产品，最乐观的未来，几乎所有业务都会演进为智能业务（就像几乎所有行业都可以称之为互联网+）。所以面向智能业务的质量保障必将有一波技术升级创新，进而带动测试行业的发展。我的团队也在努力探索这个方向，有兴趣者欢迎来函来电来钉钉交流讨论。

以上列举了我接触的一些产品形态和测试工作，可以看到，产品形态决定了测试工作内容，进而决定测试技术，产品形态的行业成熟度也因此决定行业测试技术/工具的成熟度。在开展新业务测试时，务必要用业界/公司的成熟测试工具，节约组织成本，把宝贵的测试人力用于针对业务特点的测试工作。产品形态越成熟的业务，越要快速建立高效的初始测试体系，产品形态偏新颖的，则要加强对测试技术的预研，充分利用潜在发展空间。

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

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

除了产品形态，另一个对测试工作有决定性影响的是研发模式。

研发模式在09-11年有一波明显的敏捷化趋势：从大版本的瀑布开发转为持续集成/敏捷开发，但随着敏捷狂热的逐步退去，很多团队回归理性，不以追求极致敏捷（每天n次发布）为目标，而是以业务诉求为牵引做迭代平衡（每周/双周发布+月级别大项目发布）。

这里不去评论研发模式的好坏优劣适用性，只分析研发模式对测试带来的影响。

先定义一下我所说的大瀑布和敏捷开发的区别：

大瀑布模式下，研发过程和测试过程是各自独立的，所有需求实现后进行整体提测。测试过程有完整的需求评审、系分评审、测分评审、接口测试、集成测试、系统测试、预发验证等环节，所有测试过程完成后整体发布。

敏捷开发（以每周发布为例），所有需求拆成n个story（用户故事），开发按story进行实现，每个story完成后就提测，story测试完成后，就可以直接发布这个story。在测试测当下这个story的时候，开发已经在开发下一个story，这样形成一个交错的流水线，每个story从需求提出到发布上线的周期可以缩短到周级别。由于开发过程和测试过程实现了错开式并行，所有需求完成发布上线的周期=开发所有story的时间+测试一个story时间。

以做三层蛋糕打比方，大瀑布是一层层做完整个蛋糕（大版本）后，提交给测试整个蛋糕进行测试，所以开发、测试环节有一个明显的提测作为边界。而敏捷开发则是拆成很多小蛋糕（story），做完一个提测一个，测完一个发布一个。测试在测当下这个小蛋糕的时候，开发已经在开发下一个小蛋糕，形成交错流水线机制，最后开发完所有小蛋糕时，测试只需要测完最后一个小蛋糕即可完成所有蛋糕的发布。

听起来敏捷非常理想吧？

实际上，对story、架构而言，敏捷实施的难度都很高。需求是否能拆成一个个独立的story，以及每个story规模大小差不多（才能保障开发测试的交错进行）？架构上能否一个个三层小蛋糕逐个实现，以及做到每个三层小蛋糕的解耦？如何避免最底层蛋糕修改对所有最上层蛋糕的影响？

假设以上问题都能解决，对测试的最大冲击在于，如何保证每个story测试周期的可控。测试过程包括了新功能、回归、性能等，对成熟产品来说，回归用例集可能会非常巨大。测试过程发现的bug也有不确定的影响。那么答案呼之欲出：测试全流程自动化是周期的最强保障手段，通过自动化把周期由人的不确定时间转为可预知可加速的机器运行时间，自动化覆盖流程越全，周期确定性越高，而自动化开发/维护本身带来的成本，要藏在这些自动化的运行时间里，最好是藏在每个story提测前的准备时间里。

说了这么多，其实结论很简单：发布越敏捷，越要求测的快，越需要自动化程度越高，越需要团队的自动化能力越高。

或许这就是互联网测试人员比传统软件测试人员更技术的原因了吧，互联网的快速试错、小步快跑、用户迭代思路要求了互联网的发布效率，促进了测试技术发展。而传统软件公司，包括一些传统金融机构，测试人员还可以在几个月的版本周期里，用少量自动化+点点点的方式做测试交付。

我曾接触过极致敏捷（每天多次发布）的团队，自动化测试技术也因此发展到了极致：自动化用例覆盖率超高（>90%），自动化运行速度超快(小时级甚至分钟级)，由此促进自动化用例、代码、配置同源管理、环境一键搭建、覆盖率度量卡点、CI （持续集成）pipeline等技术实践。

回到现实，业务发展未必需要那么极致的敏捷，极致的敏捷是用周期外的投入换取周期内的快速，会带来各种技术成本（机器资源、架构能力、人员能力）的增加，迭代节奏通常会落在周级别，以此达到比较平衡的状态。对应的，测试人员会以自动化成本收益作为自动化范围的选择原则，收益取决于自动化后节省的时间，并由自动化被重复运行次数进行增益，成本来源于自动化编写的花费，以及被测程序变化时的更新维护。比如，性能测试、接口测试、单元测试因重复运行次数多而入选，录制回放因自动化编写花费小而入选，代码扫描因适用业务范围广泛可以摊薄成本，界面变化频繁的不适合做UI自动化等等。

三、测试技术演化

太长不看版：测试技术持续向质量、效能两个方向演进，为质量人提供了广阔的技术发展空间。

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

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

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

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

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

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

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

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

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

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

2、如何测的快，且成本低

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

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

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

1）测试工具

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

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

2）自动化

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

3）测试平台化/服务化

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

4）智能化测试

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

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

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

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

四、质量职责范围演进

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

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

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

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

1、测试 vs 质量

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

2、效能

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

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

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

3、技术风险

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

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

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

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

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

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

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

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

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

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

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

2）针对问题引入来源建预防能力，针对问题表现形式建发现能力。

3）止血和定位恢复两条线要解耦并行。

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

4）预案需要定期评估、演练来保持有效性，预案的错误会引发次生故障。

5）红蓝攻防是为了验证发现、止血、恢复、预案这一系列技术风险体系能力。类似测试的回归能力，确保线上系统、负责人的技术风险防控能力。

6）文化意识很重要。技术风险相对线下测试来说，涉及人的工作内容更多样：风险分析，应急的响应速度，应急的决策判断，多部门协同（如客满运营，产品，pr，gr，商务，财务等）等，并且，风险的线上伤害性决定了不能靠实战来积累经验。所以在日常工作中，团队更要强调对风险的敬畏，对流程的严格执行，对每次攻防演练的认真对待，要通过持续的风险文化运营来保持风险文化传承。

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

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

五、质量组织设计

太长不看版：要理解自己的质量团队，才能更好的评价自己的现在，规划自己的未来。

职责赋予来源于组织设计，组织设计来源于业务战略。为了做好质量本职工作，还需要站在更高视角来理解质量组织设计，看到自己所处的位置。下文仅代表个人思考分析，欢迎拍砖。

注：考虑到业界通用情况，下文均以质量团队作为前文所述职责的承接团队代称。

在招聘中，候选者除了关心业务、技术外，对团队最关心的问题经常是：这是个多大的质量团队？这个朴素的问题实际是在问：这个质量团队是设计在哪一层组织结构的？

由于测试工作和开发工作有天然映射，通常质量团队的组织架构和开发团队的组织架构也会保持映射，从业务协同上下游看，保证一个开发团队单元只对接唯一测试团队单元，最能节省开发测试协同成本。所以问一个质量团队多大时，潜台词是在问：这个质量团队在对接一个多大的开发团队？这个质量团队的leader汇报给多高层级的leader？答案显而易见，质量团队越大，质量团队所属的组织层级有可能越高，质量团队所能承接的职责scope有可能越大。

大公司的质量团队但凡经历过5年以上的发展，基本都经历过合合分分的过程：

初创公司，通常从几个开发开始，没有专职测试，单产品成型后开始有专职测试，产品发展期，测试团队和开发团队共同发展壮大，成熟产品孵化出产品矩阵后，测试团队从单产品对应小测试团队聚合为一个大产品矩阵的测试团队，甚至继续向上聚合作为多业务的测试团队。多业务发展到一定阶段后，由于多业务多线发展带来的种种影响，多业务测试团队会拆分，回归到单业务测试团队形态支撑每个业务，甚至拆到更小单元团队。多业务继续发展到一定阶段，需要业务间更多协同联动时，出于更整体性的统一规划，测试团队会再次被聚合起来。

通常来说，合的组织形态，有利于承接更大范围的横向职责，在大技术组织内强调质量、效能、技术风险的策略整体性一致性，进而促进质量效能风险能力充分复用，避免重复投入，同时有利于潜力测试人员在合适的时机做跨业务云动，促进测试人员能力提升。如果大技术组织对应支持了多个业务，且业务间的战略目标、阶段、发展方式有明显区别，质量、效能、技术风险的整体策略会倾向考虑占比最高的业务类型，很可能就会给特型业务带来不适感。业务差异越大，不适感越强，对业务的潜在伤害越大。如果质量团队放弃整体性策略，强调业务个性化策略和差异化能力建设，那么一是无法充分体现大团队的复用优势，二是多业务对质量团队的差异性要求（质量标准、配比、规模、人员能力）最终将把冲突都体现在质量团队内部，对质量团队内部管理带来非常大甚至无法承受的压力。

分的组织形态，有利于质量团队紧跟业务，灵动调整策略，快速建设针对性能力，对于快速发展变化的业务最为适合，不利之处则是，受限于团队规模和人员能力储备，测试技术发展与能力沉淀速度会受影响，测试人员长期对应一个业务，视野受限，也会影响测试人员能力积累发展。且由于多质量团队间由于信息不畅，决策不统一，极易出现重复能力建设，造成更大组织层面的重复投入。

总体而言，质量团队的组织结构设计影响组织管理的两大方面：上传和下达，即信息流和决策执行流，合理的组织设计能在信息风暴和信息散失之间做好平衡，也能提升决策执行、反馈调整的管理效率。不管何种状态，质量团队都最好同时接收业务线和职能线的上传下达，并且基于组织形态背后的诉求，做具体策略决策，兼顾两条线的要求，平衡潜在冲突。分合本身无优劣，适合业务和组织的才是最好的。但同时也应坚持，团队在什么组织形态就应该充分发挥当下优势，规避劣势，让质量成为业务的加速器而不是减速带。

业务战略决定技术组织设计，在技术组织内确定测开比范围，质量团队规模就基本确定了。这里简单谈谈质量组织设计中很重要的测开比。

十几年前我就问过某任老板，到底测开比多少是适合的？我老板说：测开比是个魔鬼数字，我设多少都行，然后你来做到就ok。

我思考了好多年，思考出了这么几个意思:

1）测开比被设成多少都有可能。

2）像魔鬼数字一样乍看无含义，不知道为啥，但背后隐藏了很多信息。

3）不管多少的测开比，都要拿到质量结果。

4）测开比还可能继续变，变了也要保证质量结果。

5）好的老板要跟同学讲清楚背后的思考，不能在重要沟通上偷懒，要考虑成员感受，否则怨念可能会持续很久。

还是那句话：业务战略决定组织设计，可以从以下几个角度综合考虑测开比设计。

1）业务本身的质量属性

a.质量出问题会给业务带来多大伤害？

b.好的质量能否给业务带来增长？

c.行业环境对质量的要求是怎样的？

2）业务当下对质量的要求

a.质量、效率、成本是一组不可能三角，业务当下的取舍策略是怎样？

b.业务和其他竞品的质量对比是怎样？

3）当下质量水位

a.质量结果

b.质量能力

c.质量组织能力

4）面向未来看变化

a.行业发展对质量要求的变化

b.业务发展阶段的变化

c.新技术发展对质量技术的挑战

5）人员招聘、团队发展、行业竞争力等其他组织考虑。

有人问，测开比测试人员比例低，是否代表这个业务不重视质量？先要消除一个误区：质量角色承担质量工作，但不代表所有质量工作都由质量角色承担。测开比是专职质量人员：非专职质量人员的比例，不是质量：非质量 工作量的比例。那另一个影响因素是非专职质量人员承担的质量工作的分工，比如开发自测、产品验证、运营验收等。

不管测开比多少，质量团队都要协同所有角色的质量工作，制定质量策略、提供工具平台、设计质量流程、监督各角色执行，做到整体质量效能成本的平衡。所以答案自然是否定的，不同业务的测开比没有可比性，测开比和业务重视度没有必然联系。

（还有人问，同一个业务下，历史测开比能说明业务的重视度吗？答案同样是否定的，同一个业务下也要看发展阶段，测试成熟度、对应开发人员能力、测试团队实际职责等综合因素。）

一个小技巧，要看业务是否重视质量，可以看质量角色在其他角色质量工作上的话语权。

确定质量团队的组织架构位置、规模后，要赋予质量团队明确的职责。参见上文提到的质量、效能、技术风险，要确定这三个方向的具体职责，并分解对应的战略目标给到质量团队。

具体某个质量团队承接的职责可以从团队名称有所体现：比如质量部->质量技术部->质量与技术风险部这串名字变化就代表了团队职责的升级过程。

总结：质量组织设计是从业务战略到技术战略到质量风险策略逐层分解出来的，从组织架构到规模配比到职责赋予，不同的组织设计没有天生优劣，只有适合才是最好的。在互联网语境下，还要加上快速变化的大前提。要理解自己身处的质量组织设计，才有可能更好的顺势而为，发挥优势，交付质量价值。

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

太长不看版：了解能力结构要求，拆解分析自己。

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

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

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

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

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

1）业务、架构理解力，这是质量角色基础能力，体现为：理解业务模式、产品设计、流程逻辑、以及技术侧的架构设计、技术栈、实现细节。理解不仅是为了做质量效能风险环节的工作，还需要以质量视角尽早参与到产品、架构设计，在最早阶段交付质量价值。

2）质量技术能力，这是质量角色的核心能力，从测试分析到测试策略，从人工到自动化，从基础测试能力建设到测试创新技术落地，需要对行业技术发展保持敏锐，不断扩展视野，促进前沿技术落地，针对业务特点提供质量技术解决方案。

3）工程数据算法等通用技术能力，这些是质量角色的催化剂能力，工程能力从自动化用例代码编写，到质量工具、平台的建设、质量架构设计和交付，数据算法能力体现在如何测试智能化业务，以及如何用智能化进行测试。

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

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

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

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

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

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

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

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

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

彩蛋时间

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

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

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

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

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