功能测试是确保向客户交付高质量系统的关键步骤。功能测试侧重于业务价值与技术正确性，确保系统解决基本的客户问题。不幸的是，它通常被视为过于耗时和痛苦。就其本质而言，功能测试是一项比大多数开发人员级别的测试（例如单元、集成或系统/API 测试）更复杂的任务。

自动化功能测试可以为项目带来非凡的价值。通过使团队能够持续测试其软件中关键、有价值的方面，转向并行执行使该价值更进一步。

什么是功能测试？

功能测试确保系统解决客户在各种对话和文档中提出的需求。功能测试，也称为验收测试，从其他类型的测试中脱颖而出，因为它更多地关注业务问题而不是技术方面。

沟通

从根本上说，所有测试都是关于有效的沟通。功能测试尤其如此，因为它的性质是检查系统的形式并满足客户/用户的需求。而且，功能测试的基础更多地在于业务领域而不是技术领域。这使得有效沟通的需求变得更加重要。

尽早明确预期至关重要，这意味着功能测试需要尽早开始——如果可能的话，好在产品/系统构思阶段进行。尽早开始功能测试可确保明确的期望，并且还可以调整系统开发以好地满足客户和用户的真正需求。

准备功能测试

如上所述，良好的功能测试几乎在项目的初始阶段就开始了。

明确你在测试什么

首先，团队需要明确的系统功能验收标准。对于大多数场景，这些需要表达为用户任务，而不是深入的技术陈述。少考虑“订单摘要页面应在预期系统负载下在不到两秒内返回”，多考虑“缺货的订单将在库存管理消息队列中创建一个摘要通知消息。该摘要消息将包括该商品的库存编号以及无法完成的客户订单链接。”

有所有正确的依赖项

功能测试将需要一个尽可能接近生产的环境：与完整数据、外部系统等的集成。测试显然应该在系统开发过程中进行，但最终的功能测试将需要访问所有适用的依赖项. 然而，“尽可能接近生产”并不意味着完整的硬件。请记住，功能测试（通常！）与性能测试不同。因此，团队应该更关注集成而不是硬件。

谨慎管理您的数据

良好的功能测试数据至关重要，这也是在您的阶段早期开始功能测试的另一个原因。您的系统可能依赖上游系统为您创建或转换数据。在复杂环境中确定数据是一个耗时且高度迭代的过程。您不想在计划进行功能测试之前几天就开始这样做！

准备好您的测试工具

大多数团队至少会寻求自动化高价值、高风险的功能测试场景。这意味着您需要让您的团队准备好使用 Selenium、API 框架、部署工具集、数据管理工具等。您是否拥有合适的基础设施，不仅可以运行您的系统，还可以运行测试反对那个制度？如果您正在运行并行测试，您将需要某种形式的网格或群来运行您的测试代理。您还需要所有相关的管理基础设施来处理这些测试的执行，更不用说报告要求了。

设定成功方向

不幸的是，测试自动化一直是一个被严重误解的领域。它经常被视为减少回归和发布测试所需时间的灵丹妙药。更糟糕的是，太多组织不了解自动化功能测试是一项软件工程工作，需要与开发系统软件所用的许多相同的技能和学科。成功的自动化意味着从一开始就进行规划，并了解如何处理自动化测试。

什么自动化

永远不应该从“我们将自动化所有手动测试！”的心态来处理功能自动化。这是对时间的不良利用，并且几乎没有实际价值。

相反，良好的功能自动化侧重于高风险、高价值的业务用例。显然，自动化应该只关注重复的场景。检查网页上第三方控件的成功集成对于自动化通常没有意义——快速的探索性测试可以确认控件已正确连接、正确接收和显示数据等。自动化该测试没有意义，因为第三方控件不在团队的开发之下，也没有任何关于它在页面上的绑定更改的内容。

测试自动化代码是生产代码

对测试代码给予与生产代码同样的关注和关注非常重要——因为它是生产代码。

创建精心设计、可维护的自动化测试脚本对于任何项目的长期成功都至关重要。这意味着您的团队中至少需要一些了解软件工艺原则并可以帮助指导和指导其他人编写自动化的人。您的团队将需要了解页面对象模式、抽象、不要重复自己 (DRY) 和其他工艺原则等概念。

编写好的自动化测试

一旦你明确了哪些测试需要自动化，就花点时间清楚地说明你将如何编写这些测试。良好的测试结构将有助于在项目的整个生命周期中保持这些测试的准确性、可维护性和高价值。

一次测试一件事

好的测试只执行一项功能，它们不会将多个功能或工作流程混为一谈。一个特定的功能/工作流程可能是一个复杂的测试，需要对多个项目进行多次检查；但是，您仍在评估一项特定操作的结果。

例如，让我们看一个工资系统，该系统根据员工的时薪和工作小时数计算其每周工资。（为简单起见，我们将不考虑税收、福利、预扣税等的复杂性。）需要考虑加班时间，以及有关工时和费率的业务规则。还需要检查无效的输入。测试值和预期结果表可能如下所示：

标准时间

随着时间的推移

业务规则限制

无效输入

人们可以轻松地编写一个测试来检查所有这些输入；然而，这最终会变得过于复杂，并且在出现故障时更难以理解发生了什么。

保持测试相互独立

很容易看出在测试之间共享状态（数据、环境等）的吸引力：设置一次，然后使用相同的数据轻松运行一堆测试。不幸的是，历史表明这实际上是一种可怕的做法。

由于时间原因，在测试之间共享状态会定期注入细微的错误，尤其是在并行运行测试时。一个测试可能正在编辑另一个正在执行的测试所依赖的数据集中的值——而第二个测试由于意外的、不清楚的原因而失败。当一个测试删除另一个测试的先决条件时，经常会出现更明显的问题……

请注意，基线数据集是一个独立的问题。创建诸如零件目录之类的东西以用作背景数据非常有意义。将新零件添加到目录中的测试应该为该新零件随机创建数据，而不是重新使用模板。

设置处理数据设置和供应的定制框架要好得多。通过这种方式，可以轻松快速创建一个测试，该测试可以快速清晰地创建特定于该测试的复杂环境。例如，检查汽车零件订单的测试可以使用类似于以下伪代码的设置步骤。

` // 使用自定义框架/API 测试设置客户 ID =框架。CreateRandomTestCustomer ( ) ;FirstPartId =框架。CreateRandomTestPart ( ) ;SecondPartId =框架。CreateRandomTestPart ( ) ;

这种设置风格让您在系统中创建先决条件，并留下您可以在 UI 中使用的数据，例如作为测试客户登录并通过他们的 ID 向订单添加部件。

推荐阅读:

真机兼容测试

真机调试

掌上真机

多机联动

标准兼容性测试