产品研发-测试经理

01角色定义

传统的测试经理，是集成测试或者系统测试团队的负责人，负责测试开发的软件，保证软件产品有一定质量标准可以发布，是质量把关者。

敏捷开发模式下的测试经理，角色从单纯的质量把关者向整体质量体系搭建者转变，其核心职责不仅在于发现缺陷，更在于通过流程优化、资源协调和技术推动，系统性提升团队测试效率与产品质量。

02术业有专攻

传统测试流程

传统的软件研发，大多会配一个测试团队。如果软件开发流程正规，产品经理会先写功能需求书（FRS），研发团队根据FRS开发功能，测试团队根据FRS写测试用例并执行测试。

测试团队如果发现缺陷，会将其录入系统。研发团队收到缺陷报告，尝试复现，定位和修复。修复之后，测试团队复测通过，关闭缺陷。

一般缺陷会分级，常规是分四级或者五级：重大缺陷，严重缺陷，一般缺陷和改进建议。在产品发布的时候，是不允许有没有修复的重大缺陷和严重缺陷存在的。

如果研发流程不是那么正规，产品经理或者老板随时找研发提需求，改需求，没有专门FRS。而测试就是几个人坐在研发旁边，研发做完了直接让测试人工测一下，测试点头就算过了。第二天交付客户，皆大欢喜。

这两种流程笔者都亲身经历过，而且第二种还并不是少数。

敏捷开发测试流程

传统的瀑布式研发和迭代式研发，从需求到测试的反馈周期太长，不符合现代软件产品对需求快速响应的要求，所以现在许多研发团队采用敏捷开发模式。在敏捷开发模式中，原来一些系统测试的工作左移到开发团队，让产品开发及时反馈，迅速形成闭环。但是这并不意味着可以取消系统测试团队了，系统测试团队的工作会从简单的功能覆盖测试升级到产品全面质量保障。事实上，测试左移也并不意味着开发团队来承担原来系统测试的所有任务。能够左移到研发团队的，主要是研发团队自己开发的功能，就是功能测试。功能测试之外，还有压力测试，项目应用场景测试，各种版本兼容性测试，安全测试等，这些都不是研发团队能够兼顾的，依然需要有专门的测试团队完成。测试工控产品，不仅仅涉及软件，还会涉及很多的硬件和设备。搭建一个类似现场的测试环境，技术复杂，成本昂贵。所以公司一般会集中搭建一个测试中心，来模拟和复现现场复杂环境的场景。

 测试左移缩短了研发反馈周期，提高了软件开发的敏捷性，但同时也带来了新的挑战。原来功能测试全部集中在专门的测试团队，团队专注于测试，而且他们的任务就是能够更多找到缺陷，所以测试覆盖率的保障相对容易控制。现在功能测试左移到了敏捷开发团队，而开发团队的主要任务是交付的功能（当然在保证质量的前提下）。当时间紧迫，在功能和质量二者不可得兼的时候，你说开发团队会保功能还是保质量？事实可能是，嘴上说保质量，身体却诚实地保功能。德国有一句俗语，"Vertrauen ist gut, Kontrolle ist besser." ，翻译成中文就是“信任诚可贵，监管价更高”，这算是历来出哲学家的德国对人性的深刻认识。所以为了保证开发质量，测试经理必须检查每个开发团队的测试覆盖率和测试质量。测试覆盖率是决定软件产品是否能够发布的最基本的数据之一。软件版本发布的先决条件，行外的人可能认为是全部测试通过。但是行内人知道，“全部测试通过”是一个伪命题，因为理论上测试是可以无限的。特别是negative test，就是测试产品在错误场景中的反应。而错误场景，理论上是无限的。笔者曾经工作的一个上位机软件项目，因为下位机开发遇到瓶颈，工期严重滞后了半年。在等待下位机开发结束期间，大家也不敢开发新功能，所以就陪跑多测试了半年。在这半年里面大家依然找到各种缺陷，把前几个版本隐藏的缺陷都翻出来了，修复的时候还是鸡飞狗跳。我相信，即使是多给我们一年时间测试，我们还是会发现缺陷。所以，“完全测试”即没有理论基础，也没有实际可操作性。测试得越多，产品质量越好，但是同时意味着成本越高，交付的时间延迟越大。所以，把握测试的广度和深度，让整个研发性价比最高，这是对测试经理的核心能力的要求。而测试经理对这个度的掌控，依靠的最基本数据就是测试覆盖率。在实践中，功能测试的正向测试覆盖率必须达到100%，反向测试，就是错误场景测试，必须覆盖大多数常见的错误场景，比如网线插拔，负载过载，从站掉站，用户误操作等。除了功能测试，其他的如性能测试，安全测试，压力测试等，依然是系统测试团队的任务，测试经理仍然需要为此制定测试计划，保证测试覆盖率。产品发布之前，各种测试的覆盖率必须达标。当测试覆盖率达标，而且测试全部执行以后，测试经理可以宣布进入回归期。回归期是产品发布的最后冲刺阶段，在这个阶段，不再执行新的测试用例，整个团队集中精力修复现有测试中发现的缺陷。回归期的设定是为了避免测试工作没完没了导致发布无限延期。当严重缺陷和重大缺陷归零以后，回归期结束，测试经理向管理层提交报告，走产品发布流程。产品发布之后，研发团队主要精力开始专注于下一个版本的研发，同时兼顾已经发布版本在现场发现的缺陷修复。因为现场情况比实验室更为复杂，所以即使所测非常完全，在现场的严酷环境下依然会发现新的缺陷。这时研发会修复缺陷，发布hotfix。Hotfix是官方发布版本，所以测试流程和发布一样，需要通过全部回归测试。测试经理同样要保证hotfix的发布质量。

质量保证系统
测试经理如何保证各开发团队的测试覆盖率？人工检查肯定是不现实的，所以测试经理需要搭建一套质量保证系统。质量保证系统不仅仅包括检查测试覆盖率，还包括其他质量保障措施。检查测试覆盖率不仅仅是使用工具，更重要的是制定规则。现成的工具只能检查代码层面的测试覆盖率，并不能够检查用户故事层面的测试覆盖率。所以，我们规定PO在拆解用户故事的时候，同时要定义相应的测试用例，而且用户故事的颗粒度应该和一个功能测试用例基本对齐。这样，测试经理就可以通过系统自动拉取功能测试的覆盖率和执行情况。让所有的团队PO全部按照这样的规则工作，也花了不少时间。最后终于能够实践落地，测试经理搭建自动化系统和不断地贯宣的努力功不可没。除此以外，质量保证系统可以加入迁入规则检查，每次代码迁入的时候自动检查代码规范，不合规范的代码会自动拒绝迁入，这对刚入职的新大学生非常有帮助。因为代码规范标准贯宣固然重要，但德国人的“信任诚可贵，监管价更高”的智慧也必不可少。还有静态代码检查，常用的如SonarQube，Fortify都可以定期运行，在产品发布的时候，静态代码检查发现的严重缺陷（Critical Error）必须清零。当这些自动化的工具成为质量保证系统的必要成分的时候，一些基本质量保证就是水到渠成的事情，并不会让研发感到特别的不便。

测试框架笔者一直坚持认为，高覆盖率的自动化测试是现代软件研发的基本因素，人工测试只是在一些特定场景下的补充。现代互联网产品的开发许多已经是CI/CD（持续集成/持续部署），就是当研发团队将代码迁入之后，集成测试和系统测试在流水线自动完成。如果测试通过，产品自动发布。工业产品的测试相对于纯IT产品复杂许多，牵涉到硬件部署和远程设备，完全自动化不现实。但是，我们现在已经可以把最后发布时间控制在三天：在SP结束的那一周，下位机周三测试发布固件版本，上位机在周四完成集成并测试后发布，周五晚上，系统测试报告就可以出来，整体产品完成发布。所有这些，都离不开高度自动化的测试框架。研发团队的单元测试框架是每个研发团队自己搭建的，他们各自都会根据自己的需要八仙过海，各显神通。我们并不强求团队内部的测试系统完全统一，因为业务不同，比如下位机实时现场总线的业务，和上位机编译器的业务实在相差甚远。但是到了集成测试和系统测试阶段，测试经理需要负责搭建统一测试框架。测试框架主要包括集成测试需要的通用基本功能。比如PLC的集成测试框架，需要支持自动生成各种IEC61131-3的程序，提供编译调用接口，提供上位机和PLC建立连接，下载，上传，对IO点监控等功能。而SCADA的集成测试框架，需要支持自动生成各种画面，绑点，自动设定报警等。测试框架搭建完成，研发团队和系统测试团队就可以在测试框架上编写各种测试用例，让集成测试与系统测试的开发成本和时间大为降低。以上这些，都是测试经理的责任。当然，测试经理不可能凡事亲力亲为，但是负责计划和安排执行，推动研发团队的质量意识，这些工作，非测试经理莫属。

03天生我材必有用

成为一位优秀的测试经理，还是有不少硬性要求的。这些要求，不仅仅是技术层面和管理层面的，还有更重要前提，就是职业素养，是对产品质量不妥协的精神。

职业素养在整个研发体系里面，测试经理其实是一个吃力不讨好的角色：质量把关不严自然会被骂，质量把关太严往往也不受欢迎，因为这样会导致产品延迟发布。
笔者认为，一位优秀的测试经理，首先需要对产品的质量有执着和坚持。因为测试经理是产品出厂前的最后一道护城河，好比是守门员。一旦测试经理放水，就是门户大开，质量守无可守。而工业产品的质量尤为重要，产品质量出现问题，在现场轻则停机停工，重则机毁人亡，损伤巨大而不可逆。笔者曾经参与开发公司新一代旗舰工业软件，负责中间件。由于用了许多新的技术，集成的时候出现了许多意想不到的问题。最后产品临近发布，在大家紧张修复各种缺陷的时候，测试发现整个系统在监控PLC变量的时候会偶发完全无预兆崩溃，最后反复定位到是我们中间件的问题。当时我们尝试各种方法修复，我把自己工作十年的十八般武艺全部拿出来，测试依然能够复现崩溃。最高层老大每天亲自上阵开会跟踪缺陷修复情况，折腾了两周，而我的缺陷却毫无进展。到临近发布还有三天的缺陷跟踪会上，老大说，这个崩溃问题虽然严重，但是偶发，是不是可以降为一般缺陷，让产品先发布？老大的考量，上千人的团队，耗不起。在一片寂静之中，测试经理打破沉默发言，说如果该缺陷被强行降级处理，他将拒绝在发布文件上签字。当时会场局势完全僵住，大家都转头看我。

人有急智，我的领导提醒我找找专家。我打听到了整个集团有关.NET互操作性的大神级专家的办公地点，抱着复现缺陷的机器当天驱车170公里杀到大神在慕尼黑的办公室，直接把机器放在了他的办公桌上。大神和我一起分析了一下午，最后找到了问题根源，改了三行代码，问题迎刃而解，产品得以如期发布。经此一役，我在整个研发部门(坏）声名远扬，而我自己却对测试经理的印象颇深。测试经理凭着自己对产品质量的执着，顶住了高层的压力，也赢得了我们这些有时候自视甚高的研发的尊重。

技术能力

在技术能力方面，测试经理需要掌握全面的测试技术体系。传统技术能力包括熟悉各种测试工具，代码检查工具，还有功能测试、性能测试、安全测试等专项测试方法。在敏捷开发时代，测试经理还需具备自动化测试框架设计能力，能够将自动化测试集成到CI/CD流水线中，实现每次代码提交后的自动验证。

在AI时代，测试经理需要开始学习"AI工具的驾驭能力"，即能够利用AI技术提高测试效率。例如，使用Testim等AI视觉测试工具，结合DeepSeek生成测试用例，利用机器学习模型预测缺陷。这些AI工具能够自动生成测试用例、测试脚本和测试报告，将测试覆盖率提升80%-90%，同时大幅降低测试成本。此外，测试经理还需了解对抗性测试、蜕变测试等AI测试方法，以解决AI模型误报问题  。

管理和沟通能力

测试经理和产品负责人一样，属于技术管理岗。所以在懂技术的同时，需要懂管理。

在团队管理方面，测试经理需带领测试团队执行测试计划并监督进程。在项目管理方面，测试经理需根据测试需求分析提出测试和自动化软件设计方案，开发测试程序，完成测试结果交付与改进建议反馈。测试经理还需制定测试工作计划，确定人员分配、进度安排等细节，确保项目按计划高质量交付。

此外，随着测试技术的日益更新，特别是AI时代的到来，测试经理还需要定期组织技术培训，提升团队成员的内功外功。所以，测试经理也需要具备良好的沟通能力，和团队成员保持良好沟通，了解每个人的优势与不足，以便合理分配任务，激发团队潜力。

而测试经理的沟通还不仅仅是在测试团队内部，其沟通范围覆盖整个Stakeholders：为了检查测试覆盖率和搭建测试框架，测试经理需要时常对接产品负责人；因为集成测试用例和缺陷定级，测试经理和产品经理的沟通也很频繁；而为了搭建自动化测试框架和设计可测试接口，测试经理也需要咨询架构师。不仅如此，测试经理还要时常反馈管理层对发布时间和质量保证的关切。

最后，是抗压能力。测试经理面对的，不仅仅是每次发布时间紧迫性的压力，还要面对现场出问题时候的灵魂拷问：为什么没有在实验室发现这个缺陷？神经不够坚韧，测试经理这个职位干不长。

04前途无量

在讨论测试经理的职业发展之前，我们需要讨论一下如何成为测试经理。

测试经理和产品负责人类似。是技术管理岗，需要经验的积累，很少有人一出校门就可以胜任的。测试经理通常从测试工程师做起，有5-10年测试工作经验，慢慢积累能够独立构建测试团队并进行有效管理，掌握项目管理知识（如范围管理、质量管理、成本管理、时间管理、风险管理、人力管理），以及具备跨部门协作能力，成为测试经理。

测试经理的发展方向，可以是技术路线，向测试专家或测试架构师方向发展。测试专家通常在性能测试、安全测试、测试开发等特定领域有技术专长，能够设计性能测试整体方案，定位和优化软件系统性能问题等。而测试架构师则负责产品测试的整体架构设计，为测试组织提供最优的测试方法，协助测试经理制定测试项目计划和控制测试项目进度。

笔者认为，测试经理更有可能的发展方向是成为复合型人才，同时发展管理与技术能力，成为全面的质量管理者。测试经理角色向质量总监或研发效能负责人演变是长期趋势。目前测试人才缺口在30万人以上，这使得具备复合能力的测试经理更具市场竞争力。

复合路线的测试经理通常从测试组长（2-5年经验，管理2-5名测试工程师）开始，逐步晋升为测试经理（5-8年经验，管理10-20名测试工程师），再到测试总监（10年以上经验，负责产品线或公司级测试工作）。这一过程中，测试经理需要不断平衡技术深度与管理广度，既保持对测试技术的敏感度，又提升对团队和项目的整体把控能力。

当然，抗压性也非常重要。没有大条神经，测试经理的职位会非常痛苦。

不同行业的测试经理发展路径也略有差异。在制造业，测试经理可能需要先积累硬件测试经验，再转向软硬协同测试管理；在互联网行业，测试经理则更侧重于自动化测试与AI测试技术，以及持续集成（CI/CD）体系建设。无论那种行业，测试经理最终成都可能成为质量总监或研发效能负责人。

测试经理的职业发展没有固定模式，但无论选择哪条路线，都需要在技术与管理两个领域持续深耕。

05结语

测试经理是质量保障的关键角色，其工作不仅关乎产品质量，还影响企业创新能力和市场竞争力。

测试经理守护着产品的最后一道质量防线，是产品研发的质量护城河和守门员。