企业测试自动化如何突破顶级障碍

企业测试自动化如何突破顶级障碍？具有复杂系统的成熟公司如何才能达到现代交付计划和流程所要求的测试自动化水平？优测小编整理了五个能够帮助企业突破测试自动化的策略，同大家分享。

策略一：简化整个技术体系的自动化

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

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

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

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

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

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

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

策略需要注意的事项

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

策略二：一定要结束测试维护的噩梦

如果你的测试难以维护，则测试自动化计划将失败。如果你真正致力于检查脆弱的脚本，那么你将在测试维护中投入大量时间和资源——侵蚀了测试自动化所承诺的节省时间，并使测试（再次）成为过程瓶颈。

如果你不是100％致力于维护测试，则测试结果将被误报（和误报）困扰，以至于测试结果不再受信任。

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

解决不稳定问题的关键是找到一种表达测试的更可靠的方法。如果在未更改应用程序的情况下自动化测试开始失败，则说明你遇到了稳定性问题。

有很多技术解决方案可以解决此问题（例如使用更稳定的标识符）。这些策略对于掌握至关重要。但是，从测试自动化计划的一开始就考虑测试稳定性也很重要。在评估测试自动化解决方案时，请密切注意该工具如何响应可接受和预期的变化以及需要多少工作才能使该工具与不断发展的应用程序保持同步。此外，请注意，即使是最稳定的测试，如果它们使用不合适的测试数据或在不稳定或不完整的测试环境中运行，也会遇到问题。

为了解决更新问题，模块化和重用是关键。开发团队每次改进或扩展现有功能时（现在可以每天、每小时甚至更频繁地进行），你都负担不起更新每个受影响的测试的费用。为了使测试与开发保持同步所需的效率和“精简性”，应从易于更新的模块构建测试，这些模块可在整个测试套件中重复使用。当业务流程更改时，你希望能够更新单个模块并自动同步受影响的测试。

策略需要注意的事项

对于希望实现高度自动化水平的团队和积极开发应用程序的团队而言，此策略至关重要。如果要针对相对静态的应用程序自动化一些基本测试，则可能有足够的时间和资源来解决所需的维护。但是，构建的测试自动化程度越高或应用程序更改的频率越高，越早进行测试维护将成为一个噩梦。

此外，快速增长和高周转的团队更容易受到“测试膨胀”的影响：大量的冗余测试在风险覆盖率方面没有任何价值，但仍需要执行，检查和更新的资源。专注于重用和应用良好的测试设计策略将使膨胀降至最低。

策略三：选择适合你需求的工具

市场上不乏开源和免费测试自动化工具。如果你要将测试自动化引入一个测试单个Web或移动界面或隔离的API的小型团队中，则可能会找到一个免费工具，该工具将帮助你入门并获得可观的测试自动化收益。

另一方面，如果你是一家大型企业，负责测试通过SAP、API、大型机、Web、移动设备等进行的业务交易，则需要一个测试自动化工具，该工具可以简化所有这些技术的测试——使团队成员能够有效地重用并基于彼此的工作。

但是，在专注于选择工具之前，请考虑以下问题：组织在测试自动化计划中犯下的最大错误是，认为获取测试自动化工具是采用测试自动化的最重要步骤。不幸的是，这并不容易。无论选择哪种工具，都必须将其视为涉及流程、人员和技术的更广泛的转换的一个组成部分，这一点至关重要。

策略需要注意的事项

不可否认，成本是每个工具采购决策中的一个因素。确保考虑总成本，包括培训和增加现有资源（或雇用其他资源），构建测试框架以及构建和维护测试所需的资源。

策略四：转向API测试

如今，UI测试占据了功能测试自动化的绝大多数，只有一小部分的测试是在API级别上进行的。但是，对持续测试Rainbow的第二次观察表明，我们需要达到一种实质上相反的状态：

为什么？API测试被广泛认为更适合现代开发流程，由于API（“交易层”）被认为是与被测系统最稳定的接口，因此与UI测试相比，API测试不那么脆弱并且更易于维护

API测试可以在每个sprint中比UI测试更早地实现和执行（此外，通过服务虚拟化模拟尚未完成的API，你可以使用TDD方法向左移动测试）

API测试通常可以验证UI测试范围之外的详细“幕后”功能

API测试执行起来要快得多，因此适合检查每个新版本是否会影响现有的用户体验

实际上，Tricentis的最新研究已经量化了使用API??测试相对于UI测试自动化的一些关键优势：

这时我建议对测试金字塔采取以下措施；金字塔的红色尖端表明了手动测试（通常通过探索性测试）最适合在现代开发过程中发挥的作用。绿线表示我们已被视为UI测试自动化的“最佳地点”。API测试涵盖了三角形的绝大部分，它基于开发级单元测试。

顺便提一下，重要的是要认识到，随着时间的流逝，测试金字塔实际上会腐蚀成钻石。底部掉出，使金字塔变得不稳定，但是你可以采取一些措施来防止这种情况的发生。

从实际的角度来看，你如何确定应该在API层进行哪些测试以及应该在UI层进行哪些测试？一般的经验法则是，你希望尽可能接近业务逻辑。如果业务逻辑是通过API公开的，请使用API??测试来验证该逻辑。然后，在需要验证可能会在设备，浏览器等之间变化的UI元素或功能的存在和位置的情况下，保留UI测试。同时，开发人员应在单元级别测试API的基础代码以暴露一旦引入实施错误。

策略需要注意的事项

显然，如果你承担的测试功能没有通过API公开，那么这对你来说不是可行的策略。例如，如果要测试未利用API的SAP应用程序，则根本无法选择API测试。你需要以其他方式确保测试的可重复性和稳定性。

● 每个元素必须有ID和Name，至少要保证一个属性不能频繁变化

● 和开发共同维护一个元素属性表单，开发和测试都是从其中取数据

● 与开发充分沟通，在自动化测试支持的原则下选择一些技术实现

要想成功实施自动化，需尽量保证下面三个最小化

策略需要注意的事项

任何一个新工具或者新技术的引入都应该快速的融入到现有的工作流程中，而不是另外开辟一个新流程。因为只有这样才能够达到成本最低化，利益最大化，对原有工作的影响最小化。

所以我一直非常反对为自动化测试重新制定一套新流程，这样做的结果往往是自动化测试和业务流测试各自成体系，不能够实现联动，而使得重复工作量巨大，效益低下；同时在测试内部也不能有效形成合力，不利于提升团队整体能力，甚至导致小团队对立。