简化整个技术体系的自动化测试

　　测试自动化的传统方法依赖于基于脚本的技术。在开始自动化之前，必须先开发一个测试自动化框架。一旦最终实现，测试和调试了框架，就可以添加测试脚本以利用该框架。随着应用程序的发展，还需要检查，可能更新和调试这些测试脚本以及测试自动化框架本身。

　　通常，仅使用一项技术(例如Web UI或移动界面)就需要大量资源来进行测试自动化。这可能包括对现有测试人员进行关于您选择的特定脚本编制方法的培训，将开发资源重新分配给测试，或雇用已经掌握了该特定方法的基于脚本的测试自动化的新资源。

　　即使是精通脚本的测试人员也发现，构建、扩展和维护测试自动化是一项繁琐且耗时的任务。这通常会分散测试人员的核心能力：利用他们的领域专业知识来确定会损害用户体验并带来业务风险的问题。

　　如果您具有要测试的异构应用程序堆栈(例如打包的应用程序，例如SAP、Salesforce、ServiceNow或Oracle EBS以及API、ESB、大型机、数据库以及Web和移动前端)，则需要学习多个框架，构建和链接以自动化端到端测试用例。Selenium是迄今为止所有现代测试自动化框架中最受欢迎的框架，它专门专注于自动化Web UI。对于移动用户界面，您需要类似的框架Appium。还测试API、数据、打包的应用程序等吗?这意味着需要获取、配置、学习和链接更多的工具和框架。

　　现在，让我们退后一步，记住自动化的最终目标：加快测试速度，以便可以根据需要快速而频繁地执行测试。为此，你需要一种测试自动化方法，使您的测试团队能够为您的应用程序快速构建端到端测试自动化。

　　如果您的测试团队由脚本专家组成，并且你的应用程序是一个简单的Web应用程序，那么Selenium或基于Selenium的免费工具可能更适合你。如果你的团队由业务领域专家主导，并且你的应用程序依赖于广泛的技术组合，那么你可能需要一种测试自动化方法，该方法可以简化测试企业应用程序的复杂性，并使典型的企业用户能够通过最小的学习曲线。

　　你可能会发现组织的不同部门喜欢不同的方法(例如面向客户界面(如移动应用程序)的团队可能不希望与后端处理系统的团队使用相同的测试方法。只需确保所有方法和技术以促进协作和重用的方式连接，同时提供集中的可见性即可。

　　重要注意事项

　　这对于在涉及多种技术的复杂企业环境中进行测试最为重要，例如打包的应用程序以及API、ESB、Web和移动设备。你要测试的接口越多，你应该对它们进行优先级排序。如果你是测试单个界面的小型团队，那么这可能对你来说不是问题。

　　结束测试维护噩梦

　　如果你的测试难以维护，则测试自动化计划将失败。如果你真正致力于检查脆弱的脚本，那么你将在测试维护中投入大量时间和资源——侵蚀了测试自动化所承诺的节省时间，并使测试(再次)成为过程瓶颈。如果你不是100%致力于维护测试，则测试结果将被误报(和误报)困扰，以至于测试结果不再受信任。

　　维护问题源于两个核心问题：测试不稳定、难以更新的测试

　　解决不稳定问题的关键是找到一种表达测试的更可靠的方法。如果在未更改应用程序的情况下自动化测试开始失败，则说明你遇到了稳定性问题。有很多技术解决方案可以解决此问题(例如使用更稳定的标识符)。这些策略对于掌握至关重要。但是，从测试自动化计划的一开始就考虑测试稳定性也很重要。在评估测试自动化解决方案时，请密切注意该工具如何响应可接受和预期的变化以及需要多少工作才能使该工具与不断发展的应用程序保持同步。此外，请注意，即使是最稳定的测试，如果它们使用不合适的测试数据或在不稳定或不完整的测试环境中运行，也会遇到问题。为了解决更新问题，模块化和重用是关键。开发团队每次改进或扩展现有功能时(现在可以每天、每小时甚至更频繁地进行)，你都负担不起更新每个受影响的测试的费用。为了使测试与开发保持同步所需的效率和“精简性”，应从易于更新的模块构建测试，这些模块可在整个测试套件中重复使用。当业务流程更改时，你希望能够更新单个模块并自动同步受影响的测试。重要注意事项对于希望实现高度自动化水平的团队和积极开发应用程序的团队而言，此策略至关重要。如果要针对相对静态的应用程序自动化一些基本测试，则可能有足够的时间和资源来解决所需的维护。但是，构建的测试自动化程度越高或应用程序更改的频率越高，越早进行测试维护将成为一个噩梦。此外，快速增长和高周转的团队更容易受到“测试膨胀”的影响：大量的冗余测试在风险覆盖率方面没有任何价值，但仍需要执行，检查和更新的资源。专注于重用和应用良好的测试设计策略将使膨胀降至最低。

　　以上内容为大家介绍了简化整个技术体系的自动化测试，希望对大家有所帮助，如果想要了解更多接口自动化测试相关知识，请关注多测师。https://www.aichudan.com/xwzx/