为了收集当前有关自动测试状态的观点，我们与20个熟悉自动化测试的高管进行交谈并询问“什么是使用自动测试去提高速度与质量的关键”。答案大多关于两个主题：战略自动化;  测试和数据的使用。
1战略自动化

当人们说他们不能将人工测试自动化的时候，不要相信他们。惠普为打印机和传真机进行自动测试的Gary Gruver。有一个好的测试过程。将自动化链接到持续集成、持续交付和开发运行组合的过程。没有它，就不能获得速度和敏捷。

涅槃发生在当没有工程师在测试中编码的时候。自动化整个持续集成、持续交付过程。利用Artifactory ( 业界先进的二进制存储库管理工具) 和其他常用的工作流自动化工具进行单元测试和回归测试。1）开发者整合合适的单元测试 2）自动进行夜间构建测试 3）回归测试

有前端/UI测试和后端/API测试。现在的重点更多是移动后端和更多的API连接。前端和后端测试的关键是减少人工测试。运行整夜的测试作为持续集成过程的一部分。并行化你的测试因为自动化的改变需要花费6-8个小时并成为一个冲突点。开始并行化测试，特别是在DevOps（Development和Operations的组合）中。

让持续化测试更好的集成到DevOps。使测试团队独立于IT和运营团队。这对速度和质量来说是至关重要的。

将应用和编排自动化嵌入在广泛的API中，因此它才将会扩展。在企业和云端中有多个客户。获取一个内部视角的端口。企业需要看到保护和吞吐量。可以使部分VM投入使用。持续报告和可视化。

在每个步骤中都提高速度和质量。构建管道并且构建自动测试去在其中运行。仅仅在通过测试时才切换分支。回归测试是在框架发布前。确保对框架的信心。速度优化浏览器渲染增加虚拟机的数量为50,40000个测试在不同的版本，在20-60分钟内有4200000个测试用例。并发多线程测试。这必须平行运行因为IE10和IE11运行比chrome慢。

在大多数情况下，这两个方面有相同的答案。自动化停止了对重复进行一些相同测试的需要。相反，他们需要时间和自由去探索更多的外来的测试用例。在现代化发展中，每个人都意识到测试的常用区域，还有开发者写了越来越多的单元层次测试。这意味着我们不太可能像以前一样去找常见的bug，相反，，对于我们的测试我们需要变得更创造性，自动化允许我们去追寻更好的覆盖和质量。

你首先要要有一个稳定的测试设施在工作，在这里你可以捕捉回归并且能够合适的通知开发者。在这一点上，你需要明确的策略来确定去做什么当回归被检测到的时候：谁被安排去修复他们，必须得多快它们才能被重新解决与完成其他任务，模糊回归测试发生了什么(是代码错了还是测试出错了)等等。我们已经见识到了一种错误反复出现在好几个组织中：他们已经建立了一种自动测试系统，但是失败测试的噪音淹没了来自工作测试的信号，所以每个人都忽略了测试系统。这种情况比没有自动测试基础测试还要糟糕。你必须积极维持他们周围的测试和人员流程，或者你要终止这种功能障碍。

快速的开发与运行时准时开发是高质量软件的核心成分。重复的，自动覆盖允许我们去关注当前产品的变化，而回归内容------内容已经被交付到现场或者已经被提前检查过，对于任意集成层次缺陷已经被充分覆盖。对大多数自动化而言，更少的人的参与是我们所期待的。这适用于实际的测试，也适用于设置测试工具，分析结果，查找有关测试的历史详细信息以及为已发布或已提交的内容提供一般稳定性度量。

架构的敏捷度是支持多个供应商的关键。它需要更高敏捷性的和高质量的自动化测试-集成测试和耐久性测试24*17在特定的测试场景中去检测内存泄漏。我们从手动测试开始，直到我们让它自动化。我们必须在开发一个新功能的时候解决差距。自动化测试团队编写自动化插件。我们正在转向测试驱动发展，但是我们不知一直在往那靠。你需要一个平台去确保你能够持续的利用和使用自动化测试发展在一个持续的偏差并且懂得如何写自动化测试用例。

对于网络测试，使用Selenium和Appium去测试跨浏览器和跨平台。你不需要学习测试脚本语言就可以写测试。编写自动化可重复核心功能的测试。开发人员应该学习如何写测试和QA人员应该学习一点代码。你需要团队去跨职能上工作才能够扩大规模。并行运行测试。它能将测试时间降低到几分钟。一旦自动化开始运行，开始考虑持续集成和交付。

如果你将自己努力限制在追求纯粹的自动化上，你非常有可能会失败。这是因为维持测试用例将会成为一个巨大的负担。为了成功的测试自动化，你需要解决你正在运行的系统中基础设施的稳定性问题。而且，你需要确保测试数据存在以此来保证测试样例可以顺利地运行在期望的状态和数量。除非你解决了核心自动化问题，测试数据管理问题，服务虚拟化来确保系统稳定可用，你才能成功的自动化。

2使用测试和数据

我们每秒追踪14W个事件抱着优化UX的目标。1)从分析开始并且看到人们在哪遇到了问题。2）优化UX 3) 运动消息，对话，A/B测试，层次，语言，事件，内容和地点。 4) 数据和事件自动化有营销系统的记录。

我们发现的关键是去维持和缩小测试范围。这个从总是决定测试的最佳等级开始，我们是否应该在UI中测试这个，还是在单元测试中更加有效？下一步，我们必须确保我们的测试步骤不被经验范围所限制特别是UI测试，可能变得过于昂贵难以创建和维持。为了实现这个，我们专注于优先使用我们的测试用例和后续测试，并寻求优先顺序自动化。这允许我们能够快速产生涵盖端到端情景的理智检查。保证我们的范围能够极大地影响我们努力的速度和质量。

另一个关键是重点覆盖数据驱动的测试。这帮助我们的队伍去写确定性的测试，只有在实际使用改变的时候才会失败，并减少片段测试的维护时间。这个的解决方案可以取决于上下文，但是主要利用工具像Chance.js去产生随机数据，然后使用Factory和Data Builder模式去允许测试建立和有效清除数据。

在提高速度和质量方面，标识和安排真正的商业价值至关重要。能够通过新产品快速上市，减少客户影响事件和总体降低开销和费用来衡量和清晰地显示组织的价值。这种理解有助于创建持续投资于测试自动化的业务案例。开发者需要负责他们的工作。测试不是别人的工作。质量是从功能和非功能的角度定义的。

那么，从你的角度来看，你认为自动测试的关键是什么呢？

原创：
Tom Smith

为了收集当前有关自动测试状态的观点，我们与20个熟悉自动化测试的高管进行交谈并询问“什么是使用自动测试去提高速度与质量的关键”。答案大多关于两个主题：战略自动化;  测试和数据的使用。
1战略自动化

当人们说他们不能将人工测试自动化的时候，不要相信他们。惠普为打印机和传真机进行自动测试的Gary Gruver。有一个好的测试过程。将自动化链接到持续集成、持续交付和开发运行组合的过程。没有它，就不能获得速度和敏捷。

涅槃发生在当没有工程师在测试中编码的时候。自动化整个持续集成、持续交付过程。利用Artifactory ( 业界先进的二进制存储库管理工具) 和其他常用的工作流自动化工具进行单元测试和回归测试。1）开发者整合合适的单元测试 2）自动进行夜间构建测试 3）回归测试

有前端/UI测试和后端/API测试。现在的重点更多是移动后端和更多的API连接。前端和后端测试的关键是减少人工测试。运行整夜的测试作为持续集成过程的一部分。并行化你的测试因为自动化的改变需要花费6-8个小时并成为一个冲突点。开始并行化测试，特别是在DevOps（Development和Operations的组合）中。

让持续化测试更好的集成到DevOps。使测试团队独立于IT和运营团队。这对速度和质量来说是至关重要的。

将应用和编排自动化嵌入在广泛的API中，因此它才将会扩展。在企业和云端中有多个客户。获取一个内部视角的端口。企业需要看到保护和吞吐量。可以使部分VM投入使用。持续报告和可视化。

在每个步骤中都提高速度和质量。构建管道并且构建自动测试去在其中运行。仅仅在通过测试时才切换分支。回归测试是在框架发布前。确保对框架的信心。速度优化浏览器渲染增加虚拟机的数量为50,40000个测试在不同的版本，在20-60分钟内有4200000个测试用例。并发多线程测试。这必须平行运行因为IE10和IE11运行比chrome慢。

在大多数情况下，这两个方面有相同的答案。自动化停止了对重复进行一些相同测试的需要。相反，他们需要时间和自由去探索更多的外来的测试用例。在现代化发展中，每个人都意识到测试的常用区域，还有开发者写了越来越多的单元层次测试。这意味着我们不太可能像以前一样去找常见的bug，相反，，对于我们的测试我们需要变得更创造性，自动化允许我们去追寻更好的覆盖和质量。

你首先要要有一个稳定的测试设施在工作，在这里你可以捕捉回归并且能够合适的通知开发者。在这一点上，你需要明确的策略来确定去做什么当回归被检测到的时候：谁被安排去修复他们，必须得多快它们才能被重新解决与完成其他任务，模糊回归测试发生了什么(是代码错了还是测试出错了)等等。我们已经见识到了一种错误反复出现在好几个组织中：他们已经建立了一种自动测试系统，但是失败测试的噪音淹没了来自工作测试的信号，所以每个人都忽略了测试系统。这种情况比没有自动测试基础测试还要糟糕。你必须积极维持他们周围的测试和人员流程，或者你要终止这种功能障碍。

快速的开发与运行时准时开发是高质量软件的核心成分。重复的，自动覆盖允许我们去关注当前产品的变化，而回归内容------内容已经被交付到现场或者已经被提前检查过，对于任意集成层次缺陷已经被充分覆盖。对大多数自动化而言，更少的人的参与是我们所期待的。这适用于实际的测试，也适用于设置测试工具，分析结果，查找有关测试的历史详细信息以及为已发布或已提交的内容提供一般稳定性度量。

架构的敏捷度是支持多个供应商的关键。它需要更高敏捷性的和高质量的自动化测试-集成测试和耐久性测试24*17在特定的测试场景中去检测内存泄漏。我们从手动测试开始，直到我们让它自动化。我们必须在开发一个新功能的时候解决差距。自动化测试团队编写自动化插件。我们正在转向测试驱动发展，但是我们不知一直在往那靠。你需要一个平台去确保你能够持续的利用和使用自动化测试发展在一个持续的偏差并且懂得如何写自动化测试用例。

对于网络测试，使用Selenium和Appium去测试跨浏览器和跨平台。你不需要学习测试脚本语言就可以写测试。编写自动化可重复核心功能的测试。开发人员应该学习如何写测试和QA人员应该学习一点代码。你需要团队去跨职能上工作才能够扩大规模。并行运行测试。它能将测试时间降低到几分钟。一旦自动化开始运行，开始考虑持续集成和交付。

如果你将自己努力限制在追求纯粹的自动化上，你非常有可能会失败。这是因为维持测试用例将会成为一个巨大的负担。为了成功的测试自动化，你需要解决你正在运行的系统中基础设施的稳定性问题。而且，你需要确保测试数据存在以此来保证测试样例可以顺利地运行在期望的状态和数量。除非你解决了核心自动化问题，测试数据管理问题，服务虚拟化来确保系统稳定可用，你才能成功的自动化。

2使用测试和数据

我们每秒追踪14W个事件抱着优化UX的目标。1)从分析开始并且看到人们在哪遇到了问题。2）优化UX 3) 运动消息，对话，A/B测试，层次，语言，事件，内容和地点。 4) 数据和事件自动化有营销系统的记录。

我们发现的关键是去维持和缩小测试范围。这个从总是决定测试的最佳等级开始，我们是否应该在UI中测试这个，还是在单元测试中更加有效？下一步，我们必须确保我们的测试步骤不被经验范围所限制特别是UI测试，可能变得过于昂贵难以创建和维持。为了实现这个，我们专注于优先使用我们的测试用例和后续测试，并寻求优先顺序自动化。这允许我们能够快速产生涵盖端到端情景的理智检查。保证我们的范围能够极大地影响我们努力的速度和质量。

另一个关键是重点覆盖数据驱动的测试。这帮助我们的队伍去写确定性的测试，只有在实际使用改变的时候才会失败，并减少片段测试的维护时间。这个的解决方案可以取决于上下文，但是主要利用工具像Chance.js去产生随机数据，然后使用Factory和Data Builder模式去允许测试建立和有效清除数据。

在提高速度和质量方面，标识和安排真正的商业价值至关重要。能够通过新产品快速上市，减少客户影响事件和总体降低开销和费用来衡量和清晰地显示组织的价值。这种理解有助于创建持续投资于测试自动化的业务案例。开发者需要负责他们的工作。测试不是别人的工作。质量是从功能和非功能的角度定义的。

那么，从你的角度来看，你认为自动测试的关键是什么呢？

原创：
Tom Smith