# 测试低下论或现代测试行业所遇到的问题 前几天看到一篇 blog 讨论现代测试行业中存在的一些问题，我愿称之为测试行业的劝学篇。有些观点还是非常中肯的，翻译了一下，希望对大家有所帮助，下面是正文。 在这篇博文中，我想强调我在测试行业看到的问题，以及我们都可以如何解决它。(你可能有不同的经历--所以让我们在评论中分享吧！）。这是我在 2022 年初在阿布扎比 MoT 会议上发表的演讲的文字版。 ## 10 年来行业发生了什么变化 在过去的十年里，我们见证了技术的大幅提升--无人驾驶汽车、人工智能、AR / VR、区块链、无人机和机器人。许多测试和测试自动化从桌面转移到网络和移动设备上。 从瀑布模型，许多企业走向了敏捷和 Scrum。 从编写自动化测试的大型和昂贵的工具，我们已经转移到小型，灵活，最重要的是 - 免费的库和工具。现在我们有智能报告系统和 Docker 容器中的测试。现在在云端并行运行成千上万的测试用例并其实不那么昂贵。 但与此同时，许多事情和声明仍然没有改变。 以下是一些在测试人员中不断肆虐的无尽话题 > "手工测试已死！" > "让我们把一切都自动化吧! 通过 UI--这才是最好的！"\*。 > "SDET 是测试工程师进化的高峰! 我想成为像谷歌一样的人！" > "我在开发领域找不到工作，所以我将做一年左右的测试，然后再尝试转行。" > "测试人员的工资都在底部！" > "测试工程是一份低技能专业人士的工作！" 但为什么行业中会出现这样的情况？问题会不会是别的原因呢？我看到了哪些问题？ ## 现代测试的问题 我将把问题分为两个大组。 ### 对技术的追求 - **寻找银弹。**一些工程师为一个项目（和一个背景）创建了一个成功的框架，然后开始把它拉到所有其他的项目中作为一个 "完美的解决方案"。这不是可重用性，它只是将一把锤子怼所有的钉子和螺栓。 - **面向框架的自动化。**在一些项目中，工程师们急于编写完美的框架，而忘记了测试本身。结果是，我们有 3-6 个月的开发时间没有测试！。但是对于客户来说，没有测试是自动化应用不充分的的直接指标。 - **专注于流水线通过的崇拜者。**在这种情况下，已经成功地将测试纳入 CICD 管道的测试工程师开始迷恋于使测试一直保持绿色。这种痴迷往往导致忽略甚至删除不稳定的测试（这导致忽略了被忽略的测试背后的问题）。 - **简历驱动的开发。**许多测试人员只考虑工作和项目，作为在简历中获得一个花哨的新行的方式。没有任何关于深化技能和用测试和自动化解决业务问题的内容。 - **只专注于短期目标。**许多工程师只喜欢快速的解决方案。这种对自动化测试的态度是很普遍的。工程师们很快就写出了 "东西"，而没有考虑到可维护性，就跑去做新项目了。 ### 技能和知识水平不足 知识的缺乏可以有多种形式。 **技术知识** 在面试中，资深候选人往往能迅速回答任何关于测试的问题。他们可以为你画一个 "测试金字塔或任何你想要的数字"，告诉你世界上所有的测试设计技术，并写出完美的测试报告。但是，当你问及基本技术方面的问题（如 HTTP 或网络如何工作），候选人很快就会失去信心。 你可以告诉我，不是每个项目都需要特定的知识。这倒是真的。但测试工程师应该知道（或至少知道）基本的技术知识。理想情况下，比谷歌搜索中的第一个链接更深入一点。 90%的现代系统以这种或那种方式与网络一起工作，发送消息或请求，并使用数据库或分布式存储。多层的抽象可以覆盖它--但总的来说--它的工作原理都是类似的。 **编程和架构** 一些测试工程师仍然认为，学习编程是复杂和不必要的。让程序员来写代码吧! 另一部分是那些已经学会了一点代码，但只集中精力于 UI 测试的人。这些测试之外的世界似乎并不存在。 在测试工程师中，关于系统结构和它们如何工作的知识是一种稀缺的技能。所有这些都被认为是有经验的 "大胡子 "架构师的工作，或者只有有十几年经验的高级开发人员才能做。 但是，如果不知道系统的内部和相互之间是如何工作的，就很容易错过很多关键的错误。另一方面，缺乏技术知识将使我们很难在测试报告中描述这些问题。 我并不是说，如果不了解系统的组成部分，就不可能指出系统糟糕的不可测试性。结果是，我们继续编写脆弱的 XPath 定位器，因为没有人给元素添加 ID。 **对业务和产品的了解** 当然，这一切都取决于项目的情况。有一些项目，测试团队就像在工厂生产线上工作一样：开始构建，测试，然后传递给下一个环节（不问任何问题）。 测试工程师明显缺乏产品知识。很少有工程师与用户或客户支持一起工作。但是那些人可以提供关于应用中最危险的部分的有用信息，或者对可用性系统进行反馈。 甚至更少的测试和自动化工程师思考他们的工作如何影响业务。那些自动化测试是否为公司节省了资金？或者比人工测试更快地提供问题反馈？ **工程师的个人发展** 关于个人发展，有两个重要的工程师群体存在。 "我为什么要学习编程（任何其他技能）？那会使我成为一个不太熟练的测试工程师！" "据说我想学习，但我在等待一年后的反馈。我的经理或测试负责人会来告诉我需要学习什么。" 但这里有最关键的一点。只有你对个人的技能、知识和职业生涯的发展负责！你的经理只（或其他任何一个人）对你的工作负责。 你的经理（或互联网上的任何其他人）将无法为你创建一个技能地图。只有你知道自己的优势和劣势。只有你知道（或猜测）你在知识方面有哪些差距。只有你能了解如何获得这些知识并达到一个新的水平（并获得梦想的提升）。 你的上级只能调整你的计划并指出公司的资源投入情况：比如说参加会议或其他发展的预算。 ## 不确定性的恶性循环 那么，一个普通的测试工程师日常的灵魂拷问是什么呢？ > "我不会写代码--我不是一个开发者." > "我有什么资格和架构师讨论系统组件的架构或可测试性？" > "DevOps 团队已经关闭了流水线中不稳定的测试--好吧，他们更知道应该怎样做." > "经理一直问我：你到底在测试什么？为什么是那个？还有那个？" > "企业只是想削减成本，干掉整个部门的不必要的测试人员...." > "我怎么知道我们的用户有什么问题？" 结果，大多数测试工程师陷入了一个不确定的无限循环。 - 测试人员不能正确地向团队、其他工程师、管理层和企业证明他们的存在意义。在这种情况下，测试人员很难在团队内部建立信任和信心。 - 测试工程师的积极性越来越低。转向软件开发或管理的想法却随之增长。 - 许多有经验的高级工程师离开了测试行业。成功的测试人员的案例越来越少。测试工程师影响产品和流程并进行技术改进的案例--用手指都能数出来。会议上的成就和故事归结为 "嗯，我们得到了这个框架或这个测试管理的工具--现在一切都很美好"。缺少能够编写新库和工具的人。没有人去测试复杂且科学的软件。没有人做测试领域的研究。 - 业界继续认为，测试人员是 "只按按钮，几乎什么都不做 "的人。年轻的测试工程师也看到了同样的情况，因此他们的积极性和向上的动力更低。 ## 如何改变这种状况 - **为你的职业发展准备一个计划。**掌握什么技能，学习什么，以及如何在工作中使用这些技能。如果你能在公司获得知识和技能--那就很好! 如果不能--寻找另一个项目或公司。总有一个选择--它就在你的手中。 - **学习编程。**我不是在谈论高级开发人员水平的技能。但是写脚本的能力可以从部署或配置中去除很多单调的工作。阅读和理解别人的代码，可以更好地了解系统的总体工作原理，以及哪些情况还没有被涉及到。 - **加深你对应用程序和系统架构的了解。**从你现在正在测试的系统开始，分解它。拆解架构图。思考一个单独的组件如何和在哪里 "挂掉 "以及系统将如何反应。和架构师们聊一聊吧。 - **如果你正在编写脚本或自动化测试，总是问自己：谁将使用我的代码，他们如何使用我的代码（测试）？**它写得够清楚吗？是否有详细的报告？一个新的工程师会有多容易理解这些代码？ - **了解用户如何使用你的被测系统。**你的产品商业模式是什么？哪些是风险最大的部分？这些信息将帮助你测试对用户至关重要的部分，并为企业节省资金。