自动化化测试的局限性

出售软件时，没有什么比软件本身的质量更重要的了。如果您的软件无法实现用户期望的功能，那么您的业务将步履维艰。这意味着至关重要的是，您必须[1]知道用户希望软件执行的操作，并且[2]知道您的软件会执行此操作。最近，我一直在根据健康软件产品开发的两个基本要求来考虑自动化测试的局限性。

考虑限制之前，让我们首先考虑的自动化测试怎么  做 帮助我们满足用户的期望。在许多方面，您的开发团队都是您的第一位也是最重要的用户。自动化测试使这些“用户”可以非常清楚地描述他们期望软件如何运行。事实上，当你能描述软件应该如何与这样的精确度表现，计算机可以检查，就可以检查，在该软件的行为描述方式  快速 和  反复。这些是自动化测试的巨大收益，并且这些收益驱使商业软件行业在过去的几十年中认真对待自动化测试。

但是，即使只是简单地确认软件的行为符合预期，自动化测试也有一些限制。由于测试套件中编码了期望值，因此存在第一个限制。在大多数情况下，实现该功能的开发人员就是编写测试的人。对于开发人员而言，除了构建功能时他所考虑的方案之外，很难考虑其他方案。这意味着甚至可能不考虑可能的边缘情况，更不用说进行测试了。 

还有一个现实：从定义上说，任何具有足够价值的软件都将由他人支付，对于任何人的头脑来说，跟踪它的每个活动部分本质上太复杂了。因此，不可能以自动化测试套件的形式充分表达这种复杂性。即使有了强大的自动化测试套件，用户也将发现错误，因为没有开发团队可以预期用户可能会遇到的状态或条件的每种可能组合。此外，没有开发团队可以预见用户对应用程序的无数（通常是不同的）期望该软件将并且应该运行。

在构建“单页应用程序”（SPA）时，这些限制会更加严重。在传统的Web应用程序中，很大一部分计算发生在后端服务器上。然后将结果（HTML，CSS和JavaScript形式）返回给用户并由浏览器处理。当软件的核心复杂性集中在服务器上时，可以在高度相似的环境中（例如，在某些连续集成服务器上）测试该软件。但是，单页应用程序会将核心计算卸载到用户的浏览器中。期望 开发团队  以很高的精确度了解其服务器环境的详细信息，但很难  预期 您的各种用户浏览器的详细信息。他们可以使用多种不同浏览器中的一种，在少数操作系统之一的顶部运行几种浏览器引擎中的一种，并以多种可能的方式在多种设备之一上配置

尽管所有Web软件都  以  各种可能条件（和其他条件）的某种特定组合运行，但是SPA通过在某些特定环境中计算 出数以百万计的可能性中的主逻辑而引入的增加的复杂性  强烈地限制了自动化测试的效率。您的团队可以在一个特定环境中运行自动化测试，也可以尝试在多个环境中运行测试。但是，后一种选择会线性地增加测试套件的时间成本，同时也会增加测试套件的复杂性，因为现在要求它具有足够的通用性，可以在您选择的各种环境下运行。

最终，如果没有实际用户使用您的软件并确认其行为符合预期，就不可能确认您的软件是否达到了用户的期望。当然，这就是为用户提供软件的方式。您将软件交给他们，他们可以在他们拥有的任何特定环境中运行该软件，然后他们要么实现他们的期望，要么就没有达到他们的期望。 

确实，以最简单的形式，错误只不过是未满足的期望而已。有时，开发该软件的开发团队会考虑这些期望，但是在某些情况下实现是错误的。但是有时候，开发团队从未考虑过这种期望。但是，从客户的角度来看，没有区别。他们期望软件以一种方式，以一种方式进行结构，在某些地方提供某些信息的行为，而实际上却没有。 

开发团队通常根据原始考虑因素来组织此反馈。如果团队最初希望该软件以预期的方式运行，则客户报告的问题是一个错误。如果团队不希望软件以预期的方式运行，则客户报告的问题是功能请求。但是，在任何一种情况下，开发人员和产品经理都需要相同的核心信息：

当然，正如每个软件开发团队都知道的那样，用户根本不会或无法提供如此清晰的反馈。绝大多数用户甚至没有报告未满足的期望，而那些经常提供很少细节和不专心观点的用户。

没有比真正使用您的软件的真实人提供的结构更好的反馈更好的反馈了。而且，没有比人群测试更好的方法来收集此反馈。这是因为仅向要在真实环境中运行该软件的真实用户提供软件是不够的。这些用户还必须向您报告有用的详细信息，软件的行为方式，他们的期望值，原因，地点，条件以及其他条件等。 

自动化测试会在失败时为您的开发团队提供有用的详细信息，但它们永远无法提供期望。您的开发团队将不得不将它们自己编码为测试。您的真实用户总是在真实环境中“测试”您的软件，但是他们很少向您提供有关他们的期望，在特定情况下以及软件行为方式不同的有用的详细信息。单靠这些都不是足够的。