技术文章

并非所有测试自动化框架和工具都是一样的——它们在成本、优势、功能以及扩展和定制能力方面可能存在很大差异。有些是“低代码”，有些需要精通的技术知识。那么哪一个是您团队的最佳选择？你可以使用一些 帮助指导此决策的参数：

谁将使用该框架并进行测试？

相关团队成员的技能和优势应该是您做出决定的主要因素。当然，人们可以学习新技能，但如果你的框架需要 JavaScript，而使用它的人都已经了解 JavaScript，那么这不是一朝一夕就能学会的东西。还要考虑学习框架所需的学习曲线以及这将如何影响入职。

还要考虑谁将进行测试 - 如果您计划让手动测试团队也管理自动化测试，那么低代码选项可能是最好的。如果您要让开发人员编写自己的测试代码，请选择使用他们已经熟悉的相同语言的工具。如果您有专门的测试自动化工程师，请咨询他们的建议和经验。如果每个人都参与其中，您需要就项目背景下的最佳方案达成一致。

谁将使用该框架并进行测试？

并非每个框架都是满足每种战略需求的最佳选择。确保在比较自动化框架时考虑这些要求：

• 正在测试的技术（移动应用程序、网络应用程序等）

• 测试级别（组件测试、端到端测试等）

• 限制（例如跨浏览器测试）

• 与其他工具集成（例如您的测试管理平台）

• 定制（您是否有能力为您需要的一切添加/创建插件？）

• 报告（当测试开始失败时显示结果和调试有多容易？）

一般框架质量指标有哪些？

即使一个框架在纸面上看起来很完美，您也应该考虑一些一般质量指标。

支持和可用性

• 它有可靠的文档吗？

• 它似乎想帮助您以更简单的方式开发测试吗？

维护和更新

• 框架最后一次更新是什么时候？

• 框架多久更新一次？

• 看起来保养得很好吗？

社区规模和支持

• 是否有一个庞大且活跃的用户社区？

• 如果您需要帮助，是否可以去某个地方（例如社区论坛）寻求社区支持？

你的概念证明有意义吗？

在使用框架之前，您应该始终在实际项目中使用该框架进行概念验证。这将确保它能够在上下文中使用您需要测试的所有技术。

作为其中的一部分，请确保让每个将开发测试用例的人都参与到这个概念验证中。如果你不这样做，你最终可能会得到一个适合你但不适合团队其他成员的框架——这只会在未来带来问题。