聊聊测试工程师的核心能力模型

这是鼎叔的第二篇原创文章。

行业大牛和刚毕业的小白，都可以进来聊聊。

多年大厂技术总监和质量通道委员经验，横跨多个不同领域，微信公众号“敏捷测试转型”，欢迎多多交流。

鼎叔过往接触过各个团队的测试（测试开发）工程师，有时会发现，受限于不太合理的分工和培养导向，有些工程师走错了能力修炼的方向，面临职业发展的困惑选择。本篇文章就讲讲测试工程师的核心能力模型是什么，如何识别一些宝贵的能力特征，其他工程师同样可以借鉴。

不同的公司对于测试工程师的能力及发展要求，有一定的差异，但整体而言差不多，主管深入理解这些能力的定义和发展阶段的要求，才能更好的帮助团队提升基础下限，并寻求更级别的上限突破。

测试人员的核心能力可以分为两大类，专业硬能力和通用素质能力。下面将对测试核心能力的具体理解，以及如何识别和培养，给出一些可借鉴的思路。

第一部分测试核心专业能力

大学应该掌握的高级语言编程等能力属于学科基础能力，不再赘述。

需求分析能力和测试设计能力

测试工程师的本质工作，确保深刻理解被测需求，包括它的起源，背后的用户特征，用户使用场景，有丰富的输入才能进行完善的测试分析，明确测试策略（用有限的精力覆盖最多有价值的验证点），利用多种方法设计完善的用例场景。在执行过程中还要不断的自我审视和调整下一阶段的执行策略。

测试工程师只有被人信任其设计能力，不会轻易遗漏重要用户场景，及时抓住主要风险，才能获得向上晋升的影响力。

类似的架构理解能力也是需求分析能力的拓展，充分掌握产品业务的架构，软件前后端的架构，工程师才能具备全局视角，规划策略中的测试重点，避免跨模块边界不要遗漏。

最常见的发展歧路，就是工程师变成了测试工作的项目经理，没有足够的精力分析客户需求，没有时间进行测试策略和用例设计，甚至把这些工作都给其他执行人员，自己成了甩手掌柜（监工），不了解关键的技术背景，也不能对遗漏风险做靠谱的把控。

自动化测试工具能力

这块并不是只考察原创工具平台的开发能力，鼎叔认为即使不是一个优秀的测试工具开发者，也可以获得高度认可，避免各个工程师仅仅为了晋升而做新工具、新平台。

相关考察的重点在于，自动化测试落地的调研思考和最终效果，价值体现在这几个方面：

l 是否充分了解测试用户的诉求（可能包含开发用户，可能是需要低代码平台的合作方用户）。

l 能否不开发新工具而是完全复用开源平台？理由是否充分？

l 决策使用自研平台，而不是采用商业平台的理由。

l 对各种行业工具框架的选型分析，实践案例分析。

l 是否成为制定工具/平台需求的优秀产品经理（PO）？是否有良好的工具架构设计体现？

l 是否成为工具平台建设和交付的项目经理？是否善于在团队落地新工具，数据成效斐然？

质量分析和改进能力

能否从测试过程和交付效果的表现和数据中，敏锐地找到要改进的地方，并采取专项行动，落实改进措施？典型的能力表现证据有：

l 对现有研发质量相关的流程，是否能识别浪费或低效的地方，实施改进，真实地提高了效能。

l 对阶段性的版本交付上线，能否周期地进行缺陷分析，科学分类，抓住可重点改进的预防措施。

l 整个研发流程的测试活动产生的度量数据，暴露了什么不足？

l 所有改进的效果，是长期性的，经验可复用的，还是暂时性的，局限单一问题域的？你如何用数据证明？

鼎叔看到过很多工程师的质量总结，仅仅满足于抓到了多少个问题，而没有系统分析聚类，没有试图抓住问题的共性规律，也没有逐层深挖。对高级别工程师来说，难以充分体现价值。

另外一个极端反例是，针对单个质量事故给出大而不当的解决措施，动不动要“提高开发自测质量”，“要做好架构评审活动”，“不能夹带代码发布”，这些都是“正确的废话”。质量改进一定是抓住每个事故的本质原因来改进，所有措施都需要在现有资源下可以持续地进行，执行者清晰的知道how to的步骤。

专项测试能力

测试领域和知识博大精深，测试团队规模通常不大，具备专项测试能力的人才往往是很缺乏的。我们可以在招聘和人才培养中，有意识地识别具备专项测试发展潜力和强烈兴趣的人。

特定时期下，专才对于团队的价值是非常大，能弥补团队短板，满足业务特定需求，值得投入更多成本。为了让专项测试人员顺利成长，除了在能力模型中可以加以引导，在工作安排和考核上可以进行聚焦及倾斜，把这类人才从繁复的业务测试需求中抽离出来，专心向自己擅长的领域深入挖掘和实践。

主要的高价值专项测试方向有：终端专项性能分析或工具开发，服务端性能测试分析或平台开发，安全测试，AI评测，大数据测试，中间件/组件测试，协议测试等等。

第二部分测试核心素质能力

素质能力，也有人称为“软能力”，“通用能力”，即不同岗位的成功都可能要依赖的重要能力。

敏捷项目管理能力

深入理解敏捷原则，在测试活动中身体力行，同时掌握项目管理的基本知识和推动技巧，才能保障测试交付的目标。

系统思考能力

测试角色在复杂项目中坚守质量标准，捍卫用户价值，又要取舍和平衡，按时输出报告，面对不同角色的压力和各类突发状况。因此系统思考能力非常关键，避免陷入越忙越乱，吃力不讨好的境地。

所谓系统思考，就是观察事情被阻碍（或者被加速）背后的闭环是如何形成的，找到关键抓手，事半功倍。复杂问题背后甚至可能有双重闭环互相影响，有兴趣的同学可以参阅彼得圣吉的书《系统思考》。

以“如何提升外包同学的工作效率”话题为例，抛出话题的工程师，本能想到的解决思路是提供更专业的外包培训和更耐心的辅导。但是如果我们深入理解外包效率不高的成因，是因为内部工程师自己的工作安排不过来，也不清楚如何让外包的工作更加丰富而有价值，外包同学在单调重复的工作中难以提升，产出成果缺乏变化，进一步削弱了内部工程师分派工作的积极性，这就是一个负向循环。

因此，正确的做法应该是：提升内部工程师的测试体系化水平，掌握更丰富多彩的任务类型。当手中有丰富的测试任务类型，就可以把流程成熟的，易于传播的任务给到外包团队进行尝试，外包人员也有更多的机会学习新东西，最终找到产出效率最高的任务模式。

追求极致

这听起来像是产品经理的价值观，但是对于一个优秀的测试工程师，这是值得追求的职业态度。追求极致可以有几个不同的追求方向，第一个是勘查被测试场景的蛛丝马迹，包括用户描述，环境和设备信息，消息，日志，内部状态，哪些可能导致缺陷的出现，如果隔离掉，缺陷是否会消失。

第二个方向是不断追问失效的本质，是什么导致了问题的发生，以及过往为啥会忽略，从开发层面追问这个失效是如何引入的，为什么需求设计的时候没有想到。类似的优秀表现还体现上性能问题的调试分析上，比如5M的内存空间泄漏或者10帧的流畅度损失，背后是什么原因和什么代码引起的，什么改进措施是最佳做法，进而总结出共性的调优技巧。

第三个方向是关联模块知识的追寻。面试时经常遇到测试人员针对某个事故的成因回答到“这是其他团队负责的，我不太清楚”。经典软件事故是最好的老师，从中可以学到模块边界和协同工作的知识，也能理解业务风险的整体视角。虽然我是测试人员，但是有义务理解背后的技术原理、开发实现的思路和遇到的麻烦，不能局限于自己负责的测试模块，限制自己的成长。