​​

我从事 QA 手动测试和自动化测试已经两年了。我的工作主要是手动测试，而自动化测试则是在业余时间完成的。我个人非常喜欢编码和自动化测试，但大部分任务仍然是手动测试。正如您可能知道的，同时处理手动测试和自动化测试的工作量非常大。因此，我现在处于这样一种状态：我热爱编写自动化测试代码，但却总是匆忙完成任务。当自动化脚本完成后，开发仍在继续，几个月过去了……当我试图再次运行这些脚本时，通常会因为用户界面（UI）的一些变化而导致它们无法正常运行。由于我已经创建了许多方法和场景，很难跟踪哪些脚本能运行，哪些不能。

我是团队中唯一的 QA，并且使用 Katalon Studio 进行自动化测试。我觉得 Katalon 对我的笔记本电脑来说太“重”了，因此我正在考虑学习 Playwright 来进行回归测试。

无论如何，我意识到我目前的自动化设置可能并不是最佳实践。那么在进行自动化测试时应该注意哪些策略呢？我还发现一些可以手动完成的场景，却很难实现自动化。有什么建议吗？提前感谢！

‍

Cendius 说：
这是许多软件团队最终都会遇到的典型情况。有几种方法可以解决这个问题，您可以混合使用以下三种方式：

1. 开发人员承担更多的自动化测试工作，并将其纳入“完成的定义”（Definition of Done）。
2. 利用个人时间提升自动化测试技能，直到能够快速完成任务。
3. 公司雇佣更多的测试资源。

Altruistic-Cloud1740 说：
我经历过完全相同的情况。我主要专注于手动测试，因为那是我的主要职责。我开始在家自学，并且在没有告诉任何人的情况下，基于 Pytest、UI 自动化和 AutoIt 创建了一个 UI 测试自动化项目。我首先开发了冒烟测试，当一切稳定运行并生成报告和指标后，我召开了一次管理层会议，展示了这个项目。我明确表示这是在工作时间之外完成的，并且为了维护和改进这个项目，我需要更多的人手。于是我们雇佣了两名新员工。目前我们的团队有四个人，一部分负责手动测试，另一部分负责自动化测试。

记住一点：UI 测试总是昂贵的，您无法独自完成。至少需要一个人专门负责维护它。

如果您打算开始实施一个测试框架，请研究并应用以下设计模式：页面对象模型（Page Object Model）、工厂模式（Factory）、外观模式（Facade）、单例模式（Singleton）。

EnableEdge 说：
明白了！

我认为您同时兼顾手动测试和自动化测试是非常忙碌的。以下是一些让事情更顺利的小建议：

• 尝试使用可重用代码（例如页面对象模型），这样当您的 UI 发生变化时，只需更新部分测试，而不是全部。
• 尝试自动化那些重复性高的内容（如后端或 API 测试）。将手动测试留给复杂或边缘情况。
• 如果可以的话，将测试集成到持续集成（CI）管道中。这样，当某些东西出现问题时，您会立即知道。
• 将脚本存储在 Git 中。这将帮助您轻松跟踪变更并管理更新。
• 如果 Katalon 太占用资源，Playwright 是一个更轻量的选择，速度更快且易于维护。

lketch001 说：
当应用程序开发人员进行更改时，他们应该始终告知您这些更改，以确保您的测试没有被破坏。这通常是解决潜在问题的更好方法。

如果某个场景无法自动化，尝试找到一种更高效的手动测试方法。如果问题是时间分配不足，我会尝试在日常任务中融入这些测试。

您正在使用什么框架进行测试？Selenium、Cucumber 等等？

Background-Tank-417 说：
这是我们也在努力解决的问题，但我们已经实施了一些策略来尽量减少影响：

• 与开发人员沟通 – 我们鼓励围绕元素变更展开讨论，并让自动化团队随时了解最新动态。
• 使用 Figma 进行设计和预定义选择器 – 使用 Figma 帮助我们跟踪 UI 更新，并建立预定义的 CSS 选择器，从而构建更稳定的页面对象模型（Page Object Model）。
• 更新完成的定义（DoD） – 我们在完成的定义中增加了一个步骤：“通知自动化团队任何元素的变更。” 这确保自动化不会被忽视。
• 在计划阶段提出问题 – 在冲刺计划期间，我们主动讨论可能影响自动化的 UI 变更。这有助于整个团队思考对所有用户故事的自动化影响。
• 夜间报告 – 我们使用 BrowserStack 并通过 Jenkins 管道每晚运行自动化测试。任何元素的变更都会在 BrowserStack 的每日报告中可见。然而，此时测试已经失败了，因此我们将其作为最后手段，并询问为什么这些变更没有提前告知我们。

michael383821 说：
您需要确保即使 UI 的其他部分发生变化，您的 UI 自动化仍然能够匹配到正确的元素。映射到不变的 ID，而不是元素的索引。这将减少所需的维护工作量。

您需要每天运行自动化测试，理想情况下是在 Docker 容器或服务器上运行，而不是在您自己的电脑上。这样可以让您安排在夜间运行测试，并在早上查看结果。

任何失败都需要在发现问题后尽快修复。保持测试的更新意味着输出更有用，假阴性率降到最低。这还将允许在开发者记忆犹新的时候识别回归或错误。能够在引入错误的一天内发现它们，会让您感到非常有成就感。

Emily_Smith05 说：
嘿！平衡手动测试和自动化测试确实很难，但绝对值得。以下是一个更简单的处理方法：

• 专注于那些您反复进行的测试。自动化这些测试可以为您节省大量时间，让您更深入地进行手动测试或处理那些难以自动化的棘手部分。
• 首先选择应用程序中较稳定的部分进行自动化。这使事情更易于管理，并打下坚实的基础。
• 将脚本分解为小的、可重用的部分。当需要更新或修复时，这种方式更容易操作。
• 如果可以的话，尝试将测试集成到 CI/CD 管道中。每当添加新代码时，测试都会自动运行，确保一切保持最新。
• 记录您的脚本。使用文档或工具记录每个脚本的功能，特别是因为您是唯一的测试人员。
• 如果 Katalon 让您的电脑变慢，切换到更轻量的工具（如 Playwright）可能会有所帮助。Playwright 更快，支持多种浏览器，并且可能在您的笔记本电脑上运行得更流畅。
• 定期留出时间更新您的脚本。尽早进行一些小调整可以避免以后的大麻烦。
• 抓住机会学习更多关于自动化的知识。网上有许多免费资源和社区提示，可以帮助您提高技能。

坚持下去！尽管面对快速变化的环境，自动化可能会充满挑战，但使用这些建议真的可以让事情变得更容易。

Few_Panic_9705 说：
啊，是的，经典的自动化困境——花了数月时间构建测试，结果开发人员只改了一个 div，测试就全挂了。以下是一些生存技巧：

1️⃣ 优先使用弹性定位器 – 像对待欠您钱的人一样远离绝对 XPath。使用不常变化的数据属性或 ID。
2️⃣ 模块化测试设计 – 编写可重用的函数，而不是在多个测试中复制步骤。未来的您会感谢现在的自己。
3️⃣ 视觉测试工具 – 有时 UI 的变更不会破坏功能，但会毁掉选择器。视觉差异工具可以帮助捕捉真正的问题。
4️⃣ CI/CD 集成 – 自动化您的自动化。定期运行测试，以便尽早发现问题，而不是几个月后才发现。
5️⃣ 平衡手动和自动化测试 – 某些测试永远更适合手动完成。自动化那些有意义的内容，而不是为了自动化而自动化。

切换到 Playwright 听起来是个很棒的选择——它更快、更可靠，并且非常适合 UI 回归测试。祝好运，孤独的 QA 战士！🚀