如何面对测试的各类偏见？

📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

---

在瞬息万变的信息技术领域，当置身于机遇的海洋中时，保持方向感至关重要。围绕自动化及相关工具的热潮，正促使我们重新思考测试人员在数字产品开发中的角色。测试相关的偏见，塑造了科技公司对测试专业人员的认知 —— 这种认知有时会将测试人员看作是 “回归测试维护者” 或 “缺陷检测员”。同样的刻板印象也可能影响测试人员的自我认知，让他们产生被低估的感受，进而导致薪资待遇偏低。

然而，在敏捷团队中，测试人员的工作远不止是运用各类测试技术：他们还需要分析用户故事、评审原型、编写测试用例脚本、监控系统运行状态、调研用户反馈、维护测试工具及测试管理工具等等。

与此同时，现存的偏见可能会简化测试人员的职责。据我观察，测试人员会在专业社群内积极表达自己的担忧，但在这个 “圈子之外”，相关讨论却寥寥无几，这种现状亟待改变。根据我的经验，现代测试人员面临几大痛点：对自动化的盲目追捧、重工具轻测试策略的倾向，以及不恰当的职业标签。

自动化崇拜

“你在自动化方面有哪些经验？”—— 这是招聘面试官经常会提出的问题。如果这个问题被放在首位，会让人感觉该公司要找的是一位能将大量无人问津的测试用例自动化的测试人员。但事实上，任何团队在急于推进自动化之前，都需要注意几个问题。

首先，存在一种不切实际的想法：将重复性（回归）测试自动化，就能解决所有质量痛点。试想一下，要是我们已经把当前大部分重复性测试都实现了自动化，那确实很棒，值得松一口气。但如果以为这样就能有更多时间 “摸鱼”，那就与现实相去甚远了。新功能上线时需要新增的测试该怎么办？某个功能一更新就得随之修改的测试该怎么处理？那些无法自动化的测试又该如何应对？团队需要有人来统筹协调所有这些事情。如果产品规模较大，甚至可能需要多个人来负责。

其次，有些公司甚至没意识到自动化测试的成本有多高。用某种工具编写脚本只是第一步：以 Cypress或 Playwright这类工具为例，背后需要投入大量编码工时。更重要的是，自动化测试还需要维护，要确保其与产品的所有更新保持同步 —— 这意味着还得花大量时间 “修复” 之前写好的测试代码。幸好，随着人工智能驱动工具的发展，这种情况有望得到改善。但并非所有公司都已引入 AI 工具用于测试工作，有些公司更倾向于 “安于现状”，继续使用团队多年来一直依赖的工具（比如 Cypress）。

第三，当一批新功能需要在明天完成测试时，自动化几乎不可能成为优先选项。很多时候，自动化远没有听起来那么 “酷炫”。第一轮测试中，我们会采用探索性测试技术来验证新功能，因为测试自动化太耗费时间了。即便测试新功能没有紧迫的截止日期，在使用特定工具实现测试自动化之前，我们仍需进行探索性测试。而这除了自动化工作本身，还需要质量保证（QA）工程师投入大量时间和精力。

招聘公司若能转变心态，以更全面的视角看待测试岗位，情况定会有所改善。科技行业也需要做出类似转变：团队在启动任何自动化项目前，都应正视自动化的局限性，仔细分析当前状况与可用资源。因为测试自动化本身就是一个项目！

重工具轻策略的倾向

从最近的招聘面试中我发现，人们总喜欢谈论自己使用过的工具和框架。或许在我们看来，学会使用某款工具就已经是一种成就了。但真正的测试策略呢？团队在使用这些工具时，是否有遵循明确的策略？我们采用的测试技术，是随意选择的，还是根据客户需求（比如客户要求进行安全性测试等特定类型测试）来定的？

只有当我们知道如何在测试策略框架内运用工具和框架时，它们才能发挥作用。如果产品连测试策略都没有，那情况就另当别论了（想想都让人无奈）。我们或许会把一些热门工具当作 “锦上添花” 的选择，但使用这款或那款工具时，我们真的清楚方向吗？团队在测试方面的真实需求究竟是什么？

因此，一套涵盖各类技术与工具的整体测试策略，是每个团队的核心资产，也是测试工作的根本依据。这就好比语言学习者需要语法书来掌握规则，测试策略则承载着测试方法与工具的体系。但这个策略该由谁来负责呢？

为提高效率，韦恩・罗斯伯里（Wayne Roseberry）建议设立 “测试负责人”（test owner）一职：“测试负责人需在测试策略中明确测试方法，团队将按照双方商定的方法执行测试工作。” 在我看来，让专人发起相关讨论并持续关注团队的测试策略，是个非常好的想法。

而最适合承担这项任务的角色，显然是测试人员（Tester）！不过，如果团队中没有专职测试人员，就应该将这个职责委派给熟悉测试基础原理且具备战略规划能力的团队成员 —— 但这绝非一份轻松的差事。

有时候，停下脚步思考当下的处境是明智之举。我们可以将测试策略以文字或图表的形式呈现出来。若想理清现状，运用 “敏捷测试四象限”（Agile Testing Quadrants）会很有帮助 —— 这一概念最初由莉萨・克里斯平（Lisa Crispin）和珍妮特・格雷戈里（Janet Gregory）提出。通过与团队共同探讨这一模型，我们能判断当前方向是否正确，并填补专属测试策略中的漏洞。

不恰当的职业标签

作为人类，我们总喜欢用标签来定义身边的人。这种方式固然能让我们更轻松地理解周遭世界，却也可能局限我们对某些事物的认知。我认为，如今测试工作之所以被低估，正是源于不当标签引发的偏见。

在职位名称前加上 “手动” 或 “自动化” 这类形容词，或许会让角色定义变得简单，但也容易产生误解。例如，“手动 QA（质量保证）” 可能会被刻板地视为低技能岗位 —— 仿佛只是开发流程末尾做手动检查的人，类似工厂里的操作工；而 “自动化专员” 可能会被误解读为 “测试 + 开发二合一” 的角色，没人清楚这个人究竟只是编写重复性测试代码，还是还承担其他工作。

然而，“手动” 或 “自动化” 这类标签，其实是对软件测试人员角色的片面简化。测试工作的范畴远不止对已开发数字产品进行质量检查。因此，我们需要找到问题的根源。

迈克尔・博尔顿（Michael Bolton）精准地指出了这一点，他表示：“那种认为‘测试可以完全自动化’的错误且无益的观点，催生了‘手动测试’与‘自动化测试’的划分。” 我完全认同这一说法。正如科技行业中有些人所主张的那样，我们根本无法 “用自动化取代手动测试”—— 测试本质上是一项由人主导的活动。

鲁道夫・格罗茨（Rudolf Groetz）则用一个精妙的比喻，说明了 “手动测试与自动化测试之争” 的无意义：“我不妨直截了当地说：‘手动测试 vs 自动化测试’这场争论本身就毫无意义。拿二者做比较，就像拿锤子和螺丝刀比高低 —— 它们本就是用于不同工作的工具而已。”

杰夫・尼曼（Jeff Nyman）认为，“手动测试” 与 “自动化测试” 的划分，源于测试社群对企业趋势的被动应对：“在测试范畴的界定上，测试人员把话语权让给了其他人 —— 主要是开发人员。”

确实，我们很少听到有人说 “手动开发人员” 或 “自动化开发人员”，不是吗？🙂

总的来说，我认为测试人员有责任使用恰当的术语。尽管科技行业中 “将测试划分为手动（人主导）和自动化两类” 的做法很流行，但这种划分本身毫无意义。有时，你可能会看到 “自动化专员” 或 “手动测试员” 这样的职位标签 —— 或许，我们测试人员需要从自身做起，主动成为我们希望在行业中看到的改变。

总结

总而言之，作为测试专业人员，我们应当更积极地发声，分享观点，引导科技行业的讨论走向正确方向 —— 即采用更全面的视角看待测试（不再将其分割为 “手动” 或 “自动化”）。测试人员不仅要在企业内部推动产品质量提升，还需主动分享行业知识 —— 毕竟在某些情况下，测试这一职业仍被低估和误解。
对于团队而言，明智的做法是：在适用且必要的场景下运用自动化，创造性地规划整体测试策略，并谨慎对待各类职业标签。如果你的团队中有测试人员，一定要珍惜他们！毕竟优秀的测试人员就像 “稀有物种” 一样难得。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

​

​​​