自动化测试经验_自动化测试中的经验教训

自动化测试经验

我想讨论一些我作为质量保证（QA）软件开发人员所获得的收获。 我在质量检查方面的经验有两个方面：我最初是在Scrum团队中担任负责质量检查的软件工程师，后来又担任了负责实施自动化测试基础结构的质量检查工程师。 在后一个职位上，我确保团队没有遇到任何阻碍他们编写自动化测试的问题。

这两个角色使我对团队在使用自动化测试代码时面临的挑战有很多了解。 下面，我分享了敏捷团队在尝试编写自动化测试时面临的一些常见挑战，以及我认为可以应对这些挑战的方式。

挑战0 –没有时间。

当冲刺中的最后期限迫在眉睫，燃尽的图表保持不变时，所遭受的首要任务之一就是自动化测试的质量和完整性。 当产品所有者和Scrum Master接受不完全的自动化功能时，这个问题会进一步加剧，因为进行更多的自动化测试会导致用户故事被遗忘。

解决方案0 –预算自动测试的时间。

团队必须在其开发计划中包括自动测试的编写和实施。 同样重要的是，不应将自动化视为在日程紧张时可以在冲刺中途丢弃的东西。 每个利益相关者必须致力于利用自动化测试，并将其视为功能完整性的重要组成部分。

挑战1 –谁来修复损坏的测试？

关于自动测试具有大量代码覆盖的重要部分是，当进行更改时，自动测试将失败。 但是，当团队添加破坏测试的新功能时，可能由谁负责修复自动测试会感到沮丧。

解决方案1 ​​–修正测试是您的工作，而不破坏他人的测试是您的工作。

在一个完美的世界中，您团队的自动化测试写得很好，而且足够具体，以至于其他团队代码的更改不会破坏您的测试。 即使是编写良好的测试也不能总是与更改隔离开来，因为测试可能只是依赖于已更改的规范。 我经常遇到的一个问题是，当程序员觉得“ X团队”总是在破坏测试时，他们会感到沮丧。 我认为解决这些问题的最佳方法是通过团队之间的更好沟通，以及代表各个团队承担更多责任，以应对因变更而导致的级联问题。

挑战2 –测试环境中的噪声。

当自动测试运行持续（或随机）失败时，开发人员会Swift学会忽略结果。 可以理解，如果您有许多测试和测试运行，则要查看每个故障可能会很耗时。 当开发人员养成忽略嘈杂的测试失败的习惯时，他们通常会错过代码中的实际错误。

解决方案2 –消除噪音。

消除噪声时，有两个常见问题需要解决。 首先是评估和解决导致故障的基础结构问题（当故障不是测试的故障时）。 作为测试基础架构团队的一部分，我不得不解决许多情况，其中测试之间的交互性很差，或者测试对测试环境的状态做出了错误的假设。 其次，解决团队测试失败时的行为很重要。 团队应该以“停线”的心态应对失败的测试。 产品所有者执行此所需行为的最简单方法是，在测试失败时不接受团队的用户故事。 尽管这通常被视为严厉的政策，但我认为这是在测试失败时加强良好行为的有效方法。

挑战3 –无法自动执行此测试用例。

我经常会听到代码库的特定功能区域无法自动化。

解决方案3 –修改代码。

几乎不可能实现某项功能的自动化，但有时很难实施自动化测试。 尽我所能争取完整的自动化知识，我也了解软件开发的现实。

例如，在某些情况下，测试特定功能所花费的时间可能会（远远超过）那些测试的价值。 我确实认为，重要的是，团队必须仔细研究似乎难以为其编写自动测试的代码区域，并提出以下问题：是否有任何工具或测试基础结构变更可以帮助实现自动化测试？ 我可以重构代码以简化自动测试吗？ 将来，如何避免编写难以实现自动化的代码？

挑战4 –用户界面（UI）测试始终失败。

正如我在挑战2中所述，不断失败的测试会导致开发人员之间的冷漠感加剧。 经常失败的测试是自动化的UI测试，以我的经验，它通常是脆弱的，而且通常不够具体，无法胜任良好的自动化测试。 此外，许多开发人员缺乏UI自动化工具的专业知识。

解决方案4 –进行更多培训，并减少对自动UI测试的使用。

敏捷测试金字塔告诉我们，应该谨慎使用自动UI测试。 限制自动UI测试是避免它们导致沮丧的最简单方法。 这就要求团队在自动化测试的其他领域受训，以便只需要很少的UI测试。 同样重要的是，开发人员必须受过良好的自动UI测试创建方面的培训，否则，即使他们合适，他们也可能选择避免创建它们。

结论

我希望这些课程对您当前的自动化测试问题有所帮助，并在您的团队增加对自动化测试的使用时为您提供指导。 在评论中，请分享您在自动化测试中面临的最常见挑战以及如何解决这些挑战。

翻译自: https://www.javacodegeeks.com/2014/07/lessons-learned-in-automated-testing.html

自动化测试经验