[发明专利]一种服务网络系统的测试方法及系统

说明书

技术领域

本发明涉及分布式系统性能测试技术领域，特别涉及一种服务网络系统的测试方法及系统。

背景技术

目前的面向组合服务的服务资源分发网络（服务网络系统）的仿真和性能测试存在两个方面问题。

（1）首先，如果在开发阶段希望针对分布式系统进行性能测试，只能分别面向特定的服务，施加大规模的模拟访问数据包来测试该服务的性能指标。但这些请求未必能够真实反映系统在实际运行过程中的访问情况。对于各个模块之间基于业务逻辑的自动访问（非用户直接访问），如果单纯使用模拟请求数据，不能反映模块之间的逻辑关系这对于逻辑关系复杂的服务网络系统，难以真实的反应各服务之间的调用关系。这会造成性能评价结果的失真。例如有些服务虽然性能指标较低，但由于在系统中被调用频度也较低，因此也不会成为系统瓶颈，如若简单的加大对这类服务节点的资源配置，反而浪费了资源。由此可见模拟的服务间访问数据不能脱离各服务模块之间真实的逻辑关系，而基于这个逻辑关系的真实场景数据又很难在实验的环境下模拟出来。

（2）另外，为了在开发阶段模拟出大量用户访问网站系统的实际情况，出现了很多Web服务测试工具，如：LoadRunner、WebLoad、JMeter等，它们通过采集用户访问网站的实际数据，进而模拟更大规模的访问强度，来实现压力测试。但这些工具往往采用CS结构，只能模拟客户端对一个服务端的大量请求，达到对服务的压力测试的目的。但是对于复杂的网络组合服务系统，这些工具只能实现请求发送到系统的入口服务（即与客户端直接连接的服务模块），不能实现对系统其他服务模块的性能测试和性能评价。如果要使用这些工具对其他服务模块进行测试，也只能把这个模块从整体割裂出来，单独进行测试。例如通过向数据库服务接口发请求来测试数据库服务，但这个测试不能与其他业务服务的测试协同。因此，目前在实验室环境中，如果希望针对基于组合服务的网络软件系统进行压力测试，只能对不同的服务模块发送独立的模拟访问数据，这不利于从整体的视角发现服务组合中的性能瓶颈。

举例来说，一个组合服务软件系统由Service1、Service2、Service3三个分布式服务模块构成，系统运行时，模块Service3可能很少被调用到，这样即使Service3的性能不高，服务器能力差，也不会影响软件整体性能。而这种情况用传统的单独压力测试是难以发现的（只能发现Service3性能差）。

另外，如果单纯的增加应用入口的访问强度，虽然也可能按比例增大各模块的访问强度，但某些中间节点的瓶颈，可能会造成后续的模拟数据无法送达。例如，各服务有如下调用关系，Service1→Service2→Service3，Service2处的瓶颈可能造成更大规模的访问数据无法到达Service3，从而不能发现Service3中存在的性能问题。

发明内容

本发明旨在至少解决上述技术问题之一。

为此，本发明的一个目的在于提出一种能够真实、客观且可靠地反映出服务网络系统的性能的服务网络系统的测试方法。

本发明的另一目的在于提出一种服务网络系统的测试方法。

为了实现上述目的，本发明第一方面的实施例提出了一种服务网络系统的测试方法，所述服务网络系统包括多个服务节点，所述方法包括以下步骤：运行所述服务网络系统；对所述多个服务节点进行监听，并获取所述多个服务节点的通讯信息；根据所述通讯信息生成模拟测试数据，并向所述多个服务节点发送测试命令，其中，所述测试命令具有配置信息；所述多个服务节点根据对应的测试命令和模拟测试数据进行压力测试，并获取所述多个服务节点的测试信息；以及对所述多个服务节点的测试信息进行统计和分析以根据分析结果得到所述服务网络系统的测试结果。

根据本发明实施例的服务网络系统的测试方法，能够对服务网络系统的整体（多个服务节点）进行测试，对多个服务节点进行综合测试，能够从服务网络系统整体的视角发现服务组合中的性能瓶颈，测试结果具有客观性、真实性和可靠性，进一步地，本发明实施例的服务网络系统的测试方法可以从服务网络系统的测试数据产生测试用例，以便对服务网络系统进行测试，从而测试结果能够真实、客观且可靠地反映出服务网络系统的性能。

另外，根据本发明上述实施例的服务网络系统的测试方法还可以具有如下附加的技术特征：

在本发明的示例中，所述通讯信息包括：每个服务节点的接收数据、发送数据以及发送节点信息和接收节点信息。

在本发明的示例中，分别通过控制每个服务节点的访问数据的强度、并行度和数据量对所述每个服务节点进行压力测试。