使用基于模型的方法严格测试API的复杂链

API为企业提供了快速创新的灵活性，并将其核心产品扩展到新用户。但是，这种灵活性也带来了测试的巨大复杂性。基于模型的方法可用于匹配现代软件交付的速度和可变性。

API为企业提供了快速创新的灵活性，并将其核心产品扩展到新用户。但是，这种灵活性也带来了测试的巨大复杂性。基于模型的方法可用于匹配现代软件交付的速度和可变性。

严格的API测试必须克服大量的复杂性，并考虑大量可能的测试用例。到达端点所需的消息数据必须“覆盖”值的每个不同数据组合。其中包括用户输入的数据值，以及他们针对系统执行的独特操作。它还包括由用户活动生成的机器数据，例如内容类型和会话ID。

API测试还必须考虑数据可以通过API流动的过程。它们必须涵盖API动作和方法的组合，这些组合可以在到达特定端点的方式上转换数据。

但是API并不是孤立存在的。根据定义，它们连接了多个系统或组件，因此从某种意义上来说，每个测试都是端对端测试。因此，一组严格的API测试必须考虑大量组合动作或方法，这些动作或方法可以在数据流经连接的API时对其进行转换。

一个不切实际的简化示例将包括1000个用户输入数据的组合、1000个机器生成的数据的不同组合以及1000个通过组合动作的不同历程：

已经有10亿种组合，每种组合都可以进行API测试。因此，严格的API测试必须选择许多可以在冲刺中执行的测试用例，同时仍要保留足够的API测试覆盖率。

测试太多，时间不够！

不幸的是，API测试中使用的测试技术通常过于手工和不系统，无法进行严格的API测试。关键业务API可能会在测试生命周期的每个点上受到未充分测试的风险：

1. 在测试工具中或通过脚本一一创建API测试太慢且临时性，甚至无法达到可能的组合的一小部分。
2. 从服务定义和需求很难定义预期结果。再次猜测响应是否“正确”会破坏API测试的可靠性。
3. 因此，测试数据缺少严格的API测试所需的大多数组合。低多样性的生产数据副本侧重于过去发生的预期情况。它们缺少异常值和否定组合，以及缺乏用于测试未发布功能的数据。
4. 在执行API测试时，通常无法访问内部和第三方系统。组件可能未完成或正在由另一个团队使用，或者第三方可能未提供用于测试的沙箱。因此，环境限制进一步破坏了API测试的敏捷性。

相反，测试复杂的API链需要一种集成的自动化方法。API测试人员必须能够确定API测试严格性所需的最小一组API测试，并系统地创建执行它们所需的测试数据和环境。

基于模型的API测试

为了克服API调用链的复杂性，团队可以从基于模型的API测试方法中受益，在该方法中，测试人员可以从易于使用的模型中生成进行严格的API测试所需的一切。

运作方式如下：

• 基于模型的测试生成将创建API测试，以“覆盖”跨API链的数据和方法的每种不同组合。这将数学算法应用于数学上精确的模型。这些模型是通过导入的服务定义和消息记录快速构建的。通过拖放可重复使用的流程图，可以对复杂的API链进行端到端测试，从而可以在较短的迭代时间内进行严格的测试。
• 每次测试都会同时生成准确的测试数据和预期结果。预期的结果只是流程图中的终点，并且Test Modeller还会为其生成的每个测试“及时”查找或制作数据。 API测试人员可以在模型级别选择广泛的数据生成功能和可重复的测试数据管理（TDM）流程。这些解决方案在测试生成过程中“及时”解决，编译针对每个端到端测试量身定制的一致数据集。
• 虚拟数据生成产生模拟缺少或不可用组件所需的请求-响应对。虚拟数据生成为每个可能的请求创建准确的响应。在测试生成或执行期间也称为可重复的TDM过程，以确保从中央模型生成的每个测试都配备有准确的测试数据和环境。

通过这种集成方法，质量检查团队可以自行生成严格的API测试所需的一切。维护中央流程图可以使测试、数据和虚拟服务保持一致，并在短迭代中测试复杂的API链。

标签：

来源：慧都