很多企业会把承担测试的工程师称为QA（quality assurance），但QA和Tester其实是两个不同的岗位，但不可否认，测试工程师的主要职责也是面向质量的，是通过评估质量状态来帮助团队进行质量改进的。

但即便这样，测试工程师的工作就一定是对质量改进有帮助的吗？在实际工作中，有些误区反而会让测试人员的工作对质量产生负面影响。

这里秋草梳理总结了测试人员可能伤害质量的十大误区，以及对应的正确做法。

1. 测试的职责是发现并汇报Bug，但不是确认

误区：经常有开发同学和测试同学就某个问题是否应该报Bug进行争论， “需求中没要求”， “这个问题不影响用户使用” 等等是经常出现的理由。很多测试同学也确实会因为这些原因不再报这些问题，甚至在报Bug前会去和开发确认能不能报。

这是一个对质量伤害极大的误区。测试的价值在于评估质量状态，而评估的关键在于独立性。质量没有对错，只有好坏。需求中没定义的行为，不代表就是不需要的；不影响用户使用也不代表就是好的实现。测试是站在评估质量的视角，指出缺陷或者提出优化建议都是分内工作。开发则负责分析、认定并解决缺陷。如果开发和测试在认定上有分歧，还有PO或业务分析师、CCB成员可以进行仲裁。

但对于测试人员来说，汇报一切觉得有问题或者质量不好的产品行为则是工作义务。有意或无意去隐瞒或掩盖缺陷，才是对产品质量真正的伤害。

2. 发现Bug只是开始，还应为修复Bug提供尽可能多的上下文

误区：有的测试同学会认为我发现了问题，并且也进行了报告，那么工作就已经完成，后续修复过程与我无关，只需修复后进行验证即可

测试是整个软件产品研发生命周期中的一个环节，最终是为产品整体质量服务的。而Bug本身其实对产品是无价值的，因为只有解决掉的Bug才会对产品质量有帮助。 从这个角度来说，虽然报告Bug是测试人员的主要工作，但对产品来说，最终解决Bug才是目的。所以测试作为产品研发的一环，即便解决Bug不是测试直接负责，但我们也应该为解决Bug提供必要的支撑。

这部分在之前地文章 【】中有详细探讨，大家有兴趣可以参阅

3. 测试不只是验证需求

误区：测试只要将需求中明确定义的部分进行验证无误即可，未定义的部分无需测试

这里和第一个误区有些关联，是很多开发和测试争论bug的前提。在前文 【】中我们对测试目标的认识误区中，也说过这一点。就是测试除了验证需求之外，还有更多探索性工作应该覆盖。测试并不止是检查。

而除此之外，这里我还想更要强调产品的整体性、系统性。特别是在敏捷研发模式下，这个误区很容易被扩大。

在敏捷中，敏捷迭代的输出是Increment（产品增量），这个对开发工作是成立的。但测试工作是面向整个产品系统的，并不能只覆盖增量部分。需求也是增量的，所以当然不能仅覆盖增量部分的需求，这就是为什么回归测试是测试中必须包含的范畴，也是自动化测试越来越受重视的根本原因。（关于敏捷相关的分析介绍可以参看之前敏捷系列）

4. 测试无止境，好钢用在刀刃上

误区：要想更多发现Bug，尽量探索、发散，并利用Bug的集群效应，尽可能多地发现Bug

还是在 【】一文中，我们也澄清过，测试的目标也并不是为了发现更多Bug。而且测试其实无止境的，测试最终的目的是对整个产品或系统提供一个可靠、完整的质量状态评估。而这个质量状态是否客观准确，跟Bug的多少其实并不一定是一个正相关的关系。

测试在尽可能发现Bug的同时，还是认识到，我们是要系统地对质量进行评估，但测试又是无法穷尽的，所以必须要把有限的时间进行科学地分配，优先关注高优先的部分，比如新功能、代码出现变更、高风险模块这些都是应该优先进行测试并重点保证的部分。

精准测试、基于风险的测试RBT等都是这种思路下，把我们的测试资源、时间优先放到高价值部分的实践。

5. 测试工作不是提测才开展，从产品需求讨论就已经开始

误区：测试应该在产品提测以后才能正式展开，Bug也应该在提测以后才应该报告

在当今，以上误区当然是不正确的，因为不管是测试左移还是各种测试理论都强调了测试早期参与的重要性。

但理论归理论，实际实践中，测试通常还是在提测以后才真正开展工作。

一方面是产品前期，测试的存在感低，参与度低，容易被忽视；

另一方面，很多测试团队的考核重Bug数量，这其实更加消磨了测试早期参与的积极性，导致测试并不太愿意在早期协助团队暴露产品的问题。

但从产品交付角度，越是后期，问题修复的成本就越高。所以从产品管理来说，摒弃以Bug考核的导向，引导测试前期的积极参与，测试可以发挥其对问题的敏感度，从需求讨论开始就能识别、考虑到很多异常场景，并帮助团队提前规避。

6. 设计和架构讨论，测试不应是小透明

误区：架构和系统设计、详细设计是开发团队的任务，测试无需了解或参与讨论，等待产品开发完成后根据需求进行测试即可

和上一条类似，测试左移并不只是说测试更多了解需求，同样也要求测试参与到设计、甚至编码环节。

还是要谈测试的目标：是要尽可能准确评估出产品的质量状态。而质量必然是和产品的具体实现紧密相关的，对产品的实现细节了解得越清晰，那么在测试时就越能够有的放矢，也包括可以在设计、编码阶段就提前帮助团队规避质量问题。

相反，如果对设计、代码完全是黑盒，很可能遗漏掉一些关键的测试场景导致问题泄露。

• 不了解云应用的负载均衡机制实现，只在单节点上验证，就无法验证负载均衡失效导致的问题
• 不了解系统的缓存实现机制，就难以针对性地去构建缓存命中场景
• 不了解界面的响应式适配实现，就难以高效地进行完成兼容性测试
• 不了解接口的校验机制，就难以构造有效的接口测试数据

以上种种，都是测试不应该游离于设计环节之外，认为产品设计不属于测试范畴而忽略对这个环节的参与

7. 独立的测试环境是充分测试的前提

误区：测试执行只需要关注产品本身，可以在集成环境甚至开发环境上进行测试，并不影响测试效果

确实，测试的对象是产品本身。但测试环境其实是能否对产品进行全面、高效测试的一个关键制约。

软件测试和探索过程中，对产品的使用，通常是很多不同的操作、交互的相互叠加。而在发现产品问题时，对问题的判断，一个重要的前提就是产品本身的相关前置条件、关联因素是清晰、明确的。而要保证这一点，一个独立、无干扰的测试环境就尤为必要。如果使用开发环境来进行测试，在测试同时，开发人员同时也在环境上进行调测、变更，不仅会增加大量无效问题的出现，也是对测试、问题定位等资源的极大浪费。

除此之外，测试中，不可避免还有各种异常场景的营造，而一个独立的测试环境，更便于测试人员调整不同的测试场景，比如：

• 修改网络配置，营造代理访问、内外部IP、弱网等场景
• 修改系统时间、定时任务触发、模拟不同时段数据等场景
• 模拟资源不足、空间占满、海量或巨大文件等场景
• 产品中的部分限制因素，开启Debug模式、不同的鉴权设定、各种配置变更

这些测试都是建立在一个独立、可控的测试环境基础上的。

8. 自动化测试代码也是程序，像对待产品一样对待测试代码

误区：编写自动化测试，就是为了替代部分手工测试的执行，完成自动化代码部分的编写，让它能执行并覆盖相关用例即可

自动化测试的目的确实是为了代替很多人工测试工作，达到效率提升的目的。但自动化测试的实施并非一锤子买卖，它也是一个长期的过程。而且自动化测试，本身也是通过程序代码来实现，是程序就会有bug，因此对自动化测试脚本、工具本身的质量保证和维护也是测试人员的重要工作。

并不是我们编写出一个可跑的自动化脚本就是进行了自动化。对自动化脚本同样要像软件产品一样经过需求分析、设计、编码、测试以及后续的维护这样的生命周期。

所以自动化测试本身也是一个较大投入，要让相关脚本长期发挥作用并真正起到提升执行效率的目的，那么对自动化测试代码的良好设计和持续维护就必不可少。

9. CI/CD管道同样也是测试的职责

误区：CI/CD作为现在很多研发团队的基础设施，通常会有专门的DevOps工程师负责搭建、维护，作为测试人员，负责其中自动化测试部分脚本的编写即可

诚然，整个CI/CD管道中，和测试直接相关的部分主要就是自动化测试。但还是那句话：测试作为整个研发过程的一分子，是不可能独立于研发过程之外的。特别是敏捷研发中，更加强调团队的整体性，团队整体对研发过程负责。

所以CI/CD管道建立、运作和保持畅通的过程，并不存在明显的测试只需要负责自动化测试环节的说法。

作为质量视角的专业人员，在CI/CD管道建设中，我们也可以发挥更多的作用：

• 定义管道中各个环节流转的质量门禁，将测试左移反映到CI/CD管道中
• 代码变更的管控和识别，这部分对于测试阶段的精准测试，意义重大
• 包括开发环境、集成环境、测试环境以至线上生产环境的监控，特别是很多质量相关指标的收集实现
• 可视化，包括自动化测试报告、各种数据跟踪的状态呈现等

10. 珍惜所有了解终端用户使用场景的机会

误区：作为研发团队成员，测试无须主动接触终端用户。和用户对接更多是销售、售后、客服团队的工作

测试工作面向质量，而质量的最终判断，其实是终端用户。所以很多团队都强调，测试是终端用户的代言人，是要站在用户视角来使用、体验产品并提前发现问题的角色。

因此，从这个意义上，测试其实应该更多地去接触用户，了解用户使用产品的不同场景，诉求以至偏好。

所以，在有机会接触用户的场景下，测试应该是主动而非抗拒。作为测试，这方面的机会还是比较多的，充分利用和用户接触的机会，丰富我们对于产品所属行业的理解并应用到我们的测试工作中来。

• 用户问题支持。在一些反馈到研发团队的客户问题，需要提供技术支持时，作为测试，是经常会要直接面向客户的，这时也是我们直观了解用户对产品使用场景和面临问题的地方。
• 对外测试。很多用户在选择产品前，都会有针对产品的验收测试。这些测试往往在客户方进行，但产品测试人员往往会作为产品方来提供支持或实施测试，也就是外场测试。这也是一个很好的深入了解用户场景的窗口
• 客户拜访。有的企业在产品研发初期或过程中，会安排和终端客户的拜访、访谈，有时也会邀请研发团队参与，虽然大多情况下是系统分析师、架构等角色参与更多，但测试也会参与到此类拜访中，这是在初期就深入了解产品应用场景的一个绝佳机会。
• 行业报告。除了直接和终端客户的沟通外，关注产品所属行业的行业报告、资讯和趋势分析等资料，同样也是一个深入理解产品所处行业和用户的上佳渠道。

以上就是对测试人员伤害质量十大误区的梳理总结，欢迎大家讨论补充。 另外秋草关于测试技能体系化提升的课程，可以回复 “大纲” 或在公众号菜单中查看课程目录。