彩票走势图

在与Coveros测试自动化总监Max Saperstone的第二部分对话中（第一部分在这里），我们深入了解了如何建立有效的测试策略以及他对商业测试自动化工具的想法。

Max在他的客户中发现的情况与Parasoft在我们这里遇到的情况相同。许多组织在测试以及如何在每个测试阶段分配资源方面都面临挑战。Max随后讨论了他对商用工具的看法，并围绕无代码测试进行了更多讨论。

测试策略和测试金字塔

Mark Lambert：制定API测试策略意味着您可以在流程中尽早发现问题，并且尽早隔离问题显然是业界所追求的。但是，当我与人们交谈时，他们将测试策略描述为更像蛋卷冰淇淋或倒金字塔。那也是你看到的吗？如果是这样，那么您看到软件团队面对这种冰激凌类型的情况有哪些挑战？

Max Saperstone：我在倒金字塔上看到了各种各样的变化。有些差不多是一个沙漏，底部有很多活动，顶部有很多活动，而中间却很少。

 确实，问题归结为成本和速度，老实说，速度也流入成本。单元测试很便宜，应该在几秒钟内即可完成。这些单元测试确实应该构成金字塔的底部。它们创建起来应该相对便宜，维护起来也相对便宜。如果它们不是快速，可维护的东西，那么它们要么不是真正的单元测试，要么就是您做的不好。

我要做的很多事情都是与开发人员，测试人员和需求分析人员一起工作。我需要了解在不同区域进行真正测试的必要条件，并且每个人都在同一页面上。例如，当您测试数据库时，它不再是单元测试，而是真正的组件测试。我看到团队中有很多单元测试，但也有很多集成测试。隔离差和复杂的单元测试会减慢单元测试过程。

您希望单元测试更快的原因是即使在代码编译之前也要迅速获得反馈。您要确保代码至少能达到开发人员想要的功能。因为如果它没有按照开发人员的意愿进行操作，则没有任何理由进一步发展。

通常以UI测试的形式进行的功能测试本质上是脆弱的，它们更难以维护。那么，为什么一个团队想要更多呢？我进入不同的组织，他们说：“嗯，自动化对我们没有用。”我说：“好吧，让我们看看您的测试。”我发现这是三件事的结合：它们有太多的UI测试，它们太难以维护，并且编写得不好。我告诉他们他们可以减少UI测试的数量，因为所有其他这些测试层（单元和组件）都可以支持它们，并且当他们改进它们时，我可以帮助他们编写比目前更好的功能测试。

Mark Lambert：您提到了我想回到的话题，因为自15年前加入Parasoft以来，我就一直看到这个问题。当有人说“是的，我正在进行单元测试”，但是当您进入那里时，他们实际上并未在进行单元测试，实际上他们在金字塔上更高。如您所说，仅使用单元测试框架并不一定意味着他们正在进行单元测试。你为什么这么认为呢？有人要创建正确的或真实的单元测试有什么挑战？

Max Saperstone：这绝对不是我在一两个地方见过的孤立事件。坦白地说，与集成或系统测试相比，编写好的单元测试很困难。如果要进行良好的单元测试，则必须模拟单元依赖的所有内容。

编写模拟并不容易。这需要更多的工作；它需要更多的库。开发人员实际上为此苦苦挣扎。他们可能不知道该怎么做，或者可能没有时间去做。由于这些原因，他们可能决定采取捷径来快速连接数据库，例如，这是短期解决方案。一周后，其他所有人都在使用相同的代码，现在更改它已为时已晚。当我指出这些问题时，对此的回答是“嗯，我们正在编写测试。总比没有好。”确实如此，但是这些团队很快就进入了他们的测试效果不佳的地方。

我实际上并不认为这大部分都是无知。我真的认为在大多数情况下，这是一个时间紧缩。当涉及到这一点时，我在每个组织中都看到了这一点，与最初做正确的事情相比，管理层更关心的是发布产品。因此，这些团队积累了技术债务，并且在短期内没有问题。但是，真正的问题在于，当他们不找回并减少债务时，当他们重构代码或进行某些更改时，这些复杂的，非隔离的“单元测试”变得越来越脆弱，并且事情越来越多，开始崩溃。尽管起初他们有良好的意愿，但不良测试和技术债务的累积却造成了我所看到的问题。

测试自动化工具

Mark Lambert：在帮助客户部署其测试策略并确定要在何处应用自动化时，他们必须做出一些技术决策。例如，他们需要决定是否要使用开源或商业解决方案？还是只是建立自己的框架？您建议他们从哪里开始决策过程？

Max Saperstone：这是一个很好的问题，Mark。这实际上是我最常被问到的问题之一：我应该使用哪种工具？我应该使用什么框架？客户通常将开始进行自动化或进入API测试。不幸的是，我总是给出的答案是“哦，我不知道”，因为我不喜欢工具优先方法。

我非常希望客户退后一步，考虑他们的要求是什么。他们从测试结果分析和可追溯性角度看什么？他们想要完成什么？他们希望工具支持什么级别的测试金字塔？只是在UI，API和单元测试上进行测试？总体测试策略是什么？

一旦我回答了所有这些问题。然后我将研究市场上存在的一些框架和工具，并根据研究客户的需求做出决策。我总是建议先使用开源工具。我非常乐于尝试做尽可能敏捷的事情，其中很大一部分是实验。众所周知，有时候失败是实验的一部分。您可能会找到正确的工具，并且一开始可能工作正常，也可能无法正常工作。如果您必须为这些工具付费，那么实验会变得很昂贵，而且您可能无法获得所需的东西。

在尝试了开放源代码工具之后，我建议我的客户看一下具有免费试用期的商业工具来尝试检查。在这一点上，我建议他们开始对商业解决方案进行更多分析。

在考虑开放源代码工具时，要考虑的一大问题是支持。那里有不同的开源框架和工具，仅仅因为它们是免费的，并不意味着它们是垃圾，但这也不意味着它们也很不错。例如，Selenium周围存在一种污名，人们质疑免费工具是否有好处。现在有一个庞大的社区对此做出了贡献，尽管您可以继续免费下载它，但它是用于UI测试的第一大自动化工具。

知道那里提供了哪些支持对于开源工具很重要。这也是区分优秀开源项目的关键因素之一；社区的支持。您提出问题，人们会相对迅速地得到答案。Selenium有很多人专门在那里回答问题。这样的社区支持，无论是付费工具还是免费工具，都非常重要。

开源工具的危险在于可能会陷入错误或使用问题，并且项目会被放弃，尽管这在商业工具中也可能发生。但是，如果我没有将测试便携式化，那就是我创建的问题。

当您查看所有这些不同的工具和方法时，都需要权衡取舍。对我而言，有了适当水平的支持和支持，这总是会使开源社区更有价值。

商业工具

Mark Lambert：如果担心供应商锁定，您是否正在寻找可以轻松在不同框架之间移植测试的技术？换句话说，评估商业解决方案的一个关键方面是能否在工具之间切换并确保您不被其平台锁定？

Max Saperstone：是的，这确实。对于许多供应商而言，互换性支持是一件好事，而对于某些工具，它确实运作良好。但是，当您最初进行首次实验时，您不一定要从商业工具开始。如果我不得不重写六个不同的测试套件以仅尝试六个不同的软件，那将是一件痛苦的事情。

Mark Lambert：因此，首先开放源代码，直到遇到障碍，然后寻找可以帮助您超越障碍的东西？

Max Saperstone：可能吧。有很多不同的解决方案，它们有免费版本或“免费增值”模型，您可以在上面付费购买其他功能。除此之外，还有付费版本。我非常喜欢这些工具，因为一旦研究它们，我就意识到我可以做所有这些很棒的事情。对我来说，很多时候值得这样做，因为如果该工具具有所有正确的功能，并且我可以事先进行很多开发，则在构建期间只需要一两个许可证即可运行该工具。还算不错

同样，这也取决于团队的技术水平。付费产品的好处是，它们通常会为您准备好支持。如果该小组在技术上不熟练使用测试工具，并且他们需要更多支持，则可以使用该工具。对于Parasoft的产品，支持是客户要付费的事情之一，这在战略上很有意义。

无代码测试

Mark Lambert：针对您对非技术用户的评论，例如，对Selenium编码不满意的人，无编码测试工具是否可以解决？无代码测试对您意味着什么？你怎么看？

Max Saperstone：大约五年来，我已经看到无代码测试自动化工具。我回想起我最初意识到它们的时候，它们真的很光滑。我喜欢它们可以使很多事情变得相对简单，并且其中一些超越了无代码方面。例如，有些工具使您可以在需要时开始学习并开始用Java或Python编写东西。当您的技术团队较少时，具备无代码测试能力和必要时添加代码的能力就很重要。

在我看来，每种单一类型的工具都有其成本。您必须为具有编码背景的人员支付更多的费用，而为技术测试人员较少的人员支付更少的费用。但是，这可能会被技术抵消并向供应商支持付出更多。因此，我认为无代码测试确实为此提供了一个很好的解决方案。

我看到的最大挑战是在这个领域中存在许多不同的参与者。我还没有真正看到一个供应商领先于其他供应商。供应商似乎仍然站不住脚。尽管这肯定意味着测试自动化工具的市场正在增长，但是这些工具可能无法解决我们在测试自动化领域中存在的主要问题。

前面我提到过，我通常认为有两件事是问题：团队花太多时间来维护他们的测试，因为它们很脆弱并且很容易损坏。另一个是人们正在编写糟糕的测试。通常，这些就是我认为测试自动化的主要痛点。我认为无代码自动化实际上不能解决这些问题。它们确实使编写测试变得容易得多，但是我认为这不是最常见的问题。这些工具可能会更容易编写相同的不良测试。

这些问题很多，自动化缺乏成功，这可以归结为缺乏测试策略。我认为工具和自动化还没有真正爆发，它们确实在解决问题，但是并没有解决该领域最大的问题。

在下一篇文章中，我们与Max谈谈他在测试和测试自动化方面的失败和成功经验。