彩票走势图

在这三篇博客文章中，我们深入了解了如何构建有效的测试策略以及如何将测试自动化用作该策略的一部分。我采访了Coveros测试自动化总监Max Saperstone。Max是一位经验丰富的测试工程师，专注于CI/CD流程中的测试自动化。他向各种客户伸出援手，以帮助他们开展测试和自动化工作。Max还是一位经验丰富且经过认证的敏捷开发人员，在测试和敏捷开发人员会议上的演讲活动受到追捧。我们很幸运能在此关头拥有Max的经验，在Parasoft讨论我们心中最接近的话题。

这是一个由三部分组成的系列文章的一部分，该系列文章讨论了Max关于测试自动化入门的想法。一件事很明显，Max希望帮助客户退后一步，在进入测试自动化之前考虑一下全局。帮助他的客户回答重要问题，例如“我为什么要自动化测试？”这样他们可以为自己的工作设定明确的目标。我们还简短地讨论了API测试，Max似乎和我们在同一页面上——API测试至关重要。让我们看看Max怎么说：

测试自动化入门

Mark Lambert：嗨，Max，很高兴再次与您在一起。我知道您在Coveros的职责是帮助和协助客户制定有效的测试自动化策略。您能告诉我们您认为什么是有效的测试自动化策略吗？团队应该从哪里开始？

Max Saperstone：嗨，Mark，这是一个很好的问题！有趣的是，正如您所知道的，我的专长是自动化，尽管如此，当团队开始时，我的建议通常是：“不要仅仅涉足自动化。”

真正最好的起点是从整体上看质量检查。因此，首先要了解的是“整体质量”对您的项目意味着什么，以及如何进行验证。只有知道了这些问题的答案后，您才可以真正地决定要自动化什么，以及不想自动化什么。

对我而言，这始终是最大的挑战之一。我看到很多团队开始涉足开始编写Selenium脚本或QTP脚本，并且他们有一堆“东西”。但最终，这些东西是如何使用的？您如何处理测试结果？您如何决定何时发货？

我的建议通常是退后一步，弄清楚您需要验证的内容以及如何进行验证。有一种非常酷的方法叫MSCW。

Mark Lambert：MSCW方法是什么？

Max Saperstone：MSCW方法实际上只是一个缩写。这是您必须自动化的东西，您应该自动化的东西，您可以自动化的东西，以及不能自动化的东西。这个想法实际上是在您的自动化策略中花一些时间和思想，以找出最大的收益所在。

对我而言，这总是可以追溯到ROI。持续运行的测试有哪些？您的应用程序真正有价值的地方是什么，您不能在其中犯任何错误？对用户的影响最大的是什么？您从永远属于“野性”的东西开始，并且始终属于“应有的”东西。

然后，您进入了“可能”和“想要”的其他区域。例如，测试可用性，要实现自动化确实是一件非常困难且困难的事情：如何告诉机器感觉正确与不感觉正确？

另一个难以自动化的领域是第三方集成。例如，假设您具有FitBit集成，则最终可以使它自动化。但这将需要数周或数月的时间。真正值得花这么长时间来使之自动化吗？

当我编写测试策略时，我会花一些时间来制定我的测试计划。我真正关心的应用程序领域是什么？哪些领域将易于实现自动化？我通常从那开始。

Mark Lambert：那么您如何组织这个呢？

Max Saperstone：当然，这实际上仍是从功能层面上讲。只要退后一步，就考虑一下测试金字塔和质量所涉及的不同角色来考虑您的策略，因为它不仅仅是测试人员。开发人员应该在测试金字塔的下部编写单元测试和集成测试。在某个时刻，测试人员像冰山一角一样接管了工作。在表面之下，您要确保所有代码都已通过单元测试进行了测试-确保代码执行开发人员认为代码应执行的操作。下一步是集成测试，它可以确保应用程序的不同部分以其他部分认为的实际方式工作。最后，您拥有测试人员，他们坐在冰山的顶端，他们真的想确保整个应用程序都能完成最终客户的实际需求。

如果您没有正确地完成这两个基础部分-自动化会获得回报，并且在这些低层级上又快速又容易-顶层的错误将很难调试和修复。你不知道。 “这是功能问题吗？是组件问题？还是代码问题？”但是，如果您知道所有其他所有功能均正常运行，则可以很轻松地解决这些问题。

但是，如果您知道所有单元测试和集成测试均已通过，那么将故障诊断为可能的功能问题会更快。相反的情况是，自动化策略较差，要找出根本原因，需要大量调试，而好的自动化策略问题则要简单得多。

API测试

Mark Lambert：在Parasoft，我们已经讨论API测试已有近二十年了，但是，对于许多人来说，采用API测试仍然是新鲜事物。这可能是由于API的隐藏特性所致，它位于UI和代码之间的层中，许多人看不到它。您认为前进的方向是什么？组织如何真正以最有效的方式利用API测试？

Max Saperstone：这是一个很好的问题。我喜欢API测试，因为来自测试人员（不一定访问所有代码），这是从黑匣子角度进行大量测试的好方法。仅仅因为我不知道代码是做什么的，并不意味着我对API没有很好的了解。

希望我能看到一个API期望输入什么以及它正在生成的输出，无论是否有WSDL或相关的草率文档。API测试使我能够以非常快速的方式进行测试，因为那时它是数据驱动的。我有一个端点，我抛出了许多我认为有效的不同输入组合，并检查了所有不同的输出。我不一定真的需要了解很多关于代码的知识，并且有很多非常好的框架可以为我处理这些事情。

因此，从测试人员的角度来看，这绝对是我喜欢API测试的原因。另外，它们速度快，通常不易碎。如果您有一个组织来设置合同并具有定义明确的端点（并且不会经常更改），那么对API测试的维护就很少，它们可以为您提供有关系统的大量信息。

Mark Lambert：我认为您刚才谈到的关于API测试快速且稳定的原因，确实是它们变得非常有价值的原因。而且，它们是组织内测试人员和开发人员之间的一种很好的沟通机制。

Max Saperstone：绝对。通常，当我谈到组织的集成测试时，API测试是其中的很大一部分。它们速度很快，为您提供了许多真正有价值的信息，并且比UI测试更加稳定。

在下一篇文章中，我们与Max讨论建立测试策略以及他对测试金字塔的看法。

在我们录制的网络研讨会中，Max Saperstone提供了更多信息，内容涉及如何更有效地交付具有行为驱动开发（BDD）的高质量软件。查看更多视频。