构建测试平台与对应的组织架构需要哪些能力？ 21/100

2022 年 9 月 14 日
北京
本文字数：1824 字
阅读完需：约 6 分钟

腾讯、阿里、百度、华为等知名公司里的测试平台与测试产品越来越多，他们是如何做的，又有什么样的价值，来听思寒仔细给你解答。

01

我们先来说下测试平台这几年开始火爆的原因。

随着 DevOps 与持续交付的成熟应用，交付速度越来越快，对测试的要求也会越来越高。很多测试团队中都有大量的测试过程需要执行，比如手工测试、UI 自动化测试、接口自动化测试、性能测试、安全测试以及大量的非功能/专项测试。在持续交付体系下同时还要覆盖多套环境，比如关键测试过程还需要在联调环境、测试环境、预发布环境、线上环境等多套环境里重复的执行测试验证。在 git flow 管理模式下，我们还要自动化的对相关的 branch、tag 甚至是 commit 进行细粒度的测试。以前通过 jenkins 来实现持续集成的方式已经很难管理这么多复杂的测试过程和测试数据了，测试行业里需要更高效的测试形态。

随着数据分析、图像识别、机器学习/深度学习/人工智能等相关技术在测试行业的落地，越来越多的智能化测试的方式开始涌现。

比如基于图形识别的自动化测试、测试用例自动生成、自动遍历与自动探索测试、diff 测试、精准测试、基于历史数据自动识别 bug，修正 bug 等等，这些测试技术与能力需要有好的封装以提供给整个团队进行高效的应用。

随着测试能力越来越丰富与强大，有些测试能力可以输出到测试之外的团队。比如通过测试左移的技术去支撑研发的质量改进，通过测试右移支撑 DevOps 的平稳运行，通过质量监控支撑产品与运营能力。

甚至阿里系的部分团队已经做到了可以直接支撑用户服务，比如在产品上线后，让客户自查质量问题以实现让客户快速响应跟进产品变化。部分测试能力不再局限于具体的岗位职责，而是逐渐的以测试服务的形式去服务更多的团队。

02

上述的三个趋势，给我们带来了一些思考。作为测试工程师，在这个趋势里应该如何发挥更大的价值？作为测试管理层，又该如何建设自己团队的测试能力呢？我们可以从康威定律里获得一些解答。

根据康威定律，测试团队如果想快速的提升团队的生产力，可以从四个方向入手。

增加沟通效率
快速迭代
根据产品组织团队
拆分为小规模团队

如果要满足前面提到的测试服务化、测试智能化、测试中台化趋势，结合康威定律可以得出这样的几个结论
通过成熟的测试产品，管理测试能力，降低应用门槛与沟通成本，从而最终提高测试效率
通过快速小规模的技术改进与创新，实现测试服务的快速迭代与能力提升
根据测试产品，来划分对应的测试团队，而不再简单的根据被测业务与职能。
让测试团队与其他团队之间像微服务那样调用，团队规模尽量不要超过经典邓巴数(5/15)

如果把这几点连接起来，我们就得到了一个未来的测试发展模式雏形。多个 5 到 15 人的测试团队，构建各种测试能力，管理团队测试过程，并持续改进，实现对自身和周围团队的产品级支持，这样就可以大大提高测试生产力。

从以上的发展趋势里我们可以看到，测试行业需要一种便捷的测试能力管理方式。他要具备如下能力

管理内部测试过程，让测试效率更高，流程更顺畅
管理内部测试能力与测试数据，降低应用门槛与应用成本，提高对测试数据的利用以提高质量
输出测试能力到外部团队，支撑整个团队的高效率高质量交付

大家可以明显的看到，产品化、SAAS 化是可以很好的满足测试行业的发展诉求的，也很好的符合了康威定律。

其实在阿里、腾讯、百度、华为等公司，对应的测试平台已经越来越多，小到自动化测试平台、测试用例录制平台、mock 服务平台，大到压测平台、精准测试平台等，都得到了非常多的应用。测试平台也逐渐成了很多测试团队，甚至是研发团队的一个重要业务。

整个测试行业先后经历了几个重要的测试发展形态
人工测试阶段
自动化测试框架阶段
低代码测试工具阶段
测试产品与测试服务平台阶段

每次的技术改进其实都是生产力飞跃的一次重要里程碑。

但是随着测试开发人群的崛起，人们对测试平台的打造已经进入了疯狂的阶段，很多设计错误的测试平台也喷涌而出，甚至还出现了一定程度的测试能力倒退。比如经典的行业反例

使用数据库维护测试用例，失去了强大的 git 版本管理能力
使用在线手工编写用例的方式，失去了良好的编程模型支持
使用了面条式的测试用例关键字结构，既缺乏 page object 模式支持，又缺乏复杂逻辑支持

这些问题会导致测试平台与产品不但不能提高测试效率，还会让测试能力退步，把测试团队拖入了难以维护的深渊。