CN102761453A - 一种测试客户端可用性的方法及客户端 - Google Patents

Abstract

本发明公开了一种测试客户端可用性的方法及客户端。该方法包括：建立可用客户端与服务器的网络连接，通过可用客户端内置的测试组件获取输入可用客户端的信息以及可用客户端输出的信息；启动内置测试组件的待测试客户端，确定进行待测试客户端可用性测试，拉取输入可用客户端的信息以及可用客户端输出的信息；测试组件解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向待测试客户端发送，实时监测并获取待测试客户端输出的信息；根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用。应用本发明，可以降低测试维护成本、提高测试效率。

Description

一种测试客户端可用性的方法及客户端

技术领域

本发明涉及计算机通信技术，特别涉及一种测试客户端可用性的方法及客户端。

背景技术

随着计算机通信技术的发展，基于客户端/服务器(C/S，Client/Server)架构开发的大型多人在线角色扮演游戏(MMORPG，Massively MultiplayerOnline Role Playing Game)，由于具有高流畅度、操作手感好、即时战斗等特点，因而，深受用户喜爱。其中，客户端的可用性对于保证MMORPG游戏的正常运行以及游戏运行的准确性十分重要，因而，在客户端投入使用前，也就是在开发过程中，需要对客户端的可用性进行测试，只有测试合格的客户端，才被允许投放市场。

现有技术中，一般采用脚本外挂、按键精灵等外挂类的第三方软件实现对客户端可用性的测试，该方案的实现流程主要包括：首先启动游戏进程，接着启动一个作为外挂的第三方软件进程，通过外挂接口将第三方软件注入到游戏进程中，然后，使用外挂的第三方软件程序对客户端进行测试，获取测试信息并根据测试信息分析该客户端的可用性。但该方案需要将第三方软件注入到客户端游戏程序的内部，而客户端游戏程序本身一般都含一定程度的保护机制，需要在注入过程中绕开或者关闭游戏程序自身的防入侵功能，这样，增加了测试的复杂性，测试效率较低，同时，如果不能关闭游戏程序的防入侵功能，容易导致注入失败的情况发生，使得测试失败；进一步地，第三方软件通过外挂接口测试得到的客户端信息，可能是客户端或服务器经过封装、加密的信息，因此，还需要获取相应的解密密钥，对获取的封装、加密的信息进行解封装以及解密处理，使得处理较为复杂。

现有技术中，还有一种采用脚本的方式实现对客户端可用性的测试，该方案通过开发人员手写脚本，按照预先设定的顺序调用客户端或服务器相应的接口实现测试，其流程主要包括：开发人员在开发阶段注重对提供给脚本调用的接口的安排和统计，在开发完成后，开发人员通过写游戏项目内部脚本的方式，按照测试的目的和要求，手写对应的脚本来依次调用游戏项目本身提供的接口，获取相应客户端的测试信息。该方法可以在客户端内部实现，避免了游戏程序本身保护机制的防入侵功能导致的注入失败以及无法获取相应解密密钥的问题，但游戏项目接口的改动将导致所有脚本必须被全部筛选修改一遍，而新添加的任何功能都必须重新写脚本，使得测试效率较低、测试维护成本高；进一步地，需要专门的脚本编程技术人员，对测试人员要求高；而且，测试需要在与服务器进行网络连接的状态下，增加了网络流量开销。

发明内容

有鉴于此，本发明的主要目的在于提出一种测试客户端可用性的方法，降低测试维护成本、提高测试效率。

本发明的另一目的在于提出一种客户端，降低测试维护成本、提高测试效率。

为达到上述目的，本发明提供了一种测试客户端可用性的方法，该方法包括：

建立可用客户端与服务器的网络连接，通过可用客户端内置的测试组件获取输入可用客户端的信息以及可用客户端输出的信息；

启动内置测试组件的待测试客户端，确定进行待测试客户端可用性测试，拉取输入可用客户端的信息以及可用客户端输出的信息；

测试组件解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向待测试客户端发送，实时监测并获取待测试客户端输出的信息；

根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用。

所述通过可用客户端内置的测试组件获取输入可用客户端的信息以及可用客户端输出的信息具体包括：

可用客户端运行游戏程序；

接收用户通过输入设备向客户端输入的游戏相关指令信息，按照游戏设置的策略，进行相应处理，向服务器输出游戏相关指令信息对应的请求信息；

接收服务器返回的请求响应信息，执行相应操作，输出请求响应反馈信息；

客户端内置的测试组件实时监测并获取游戏相关指令信息、请求信息、请求响应信息以及请求响应反馈信息。

所述输入可用客户端的信息包括输入设备输入的游戏相关指令信息、和/或，服务器返回可用客户端的请求响应信息。

所述可用客户端输出的信息包括请求信息、和/或，请求响应反馈信息。

所述输入可用客户端的信息为输入设备输入的游戏相关指令信息，所述根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用具体包括：

测试组件根据获取的待测试客户端输出的请求信息，与拉取的可用客户端输出的游戏相关指令信息对应的请求信息进行匹配，如果匹配成功，确定该待测试客户端可用，否则，确定该待测试客户端不可用，所述请求信息为待测试客户端对接收的游戏相关指令信息进行相应处理得到的信息。

所述输入可用客户端的信息为输入设备输入的游戏相关指令信息和服务器返回可用客户端的请求响应信息，所述根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用具体包括：

测试组件根据获取的待测试客户端输出的游戏相关指令信息对应的请求信息以及请求响应信息对应的请求响应反馈信息，分别与拉取的可用客户端输出的游戏相关指令信息对应的请求信息以及请求响应信息对应的请求响应反馈信息分别进行相应匹配，如果分别匹配成功，确定该待测试客户端可用，否则，确定该待测试客户端不可用。

按照功能操作对测试组件监测并获取的信息进行分类存储。

进一步包括：

将分类存储的信息中的游戏相关指令信息以及请求响应信息封装为测试数据包，将请求信息以及请求响应反馈信息封装为验证数据包。

所述分类存储的信息置放于预先设置的共享区，并将该共享区的地址信息存储于测试组件中。

根据客户端配置文件中设置的客户端启动模式对应的测试模式确定进行客户端可用性测试。

所述启动模式包括：联机录制模式、普通模式、脱机播放模式以及联机播放模式。

所述启动模式为脱机播放模式，所述客户端断开与外部的连接。

所述启动模式为联机播放模式，所述客户端断开与外部输入设备的连接，所述测试组件解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向待测试客户端发送具体包括：

测试组件解析测试数据包，过滤外部输入设备发送的信息，按照测试数据包包含的时间戳信息，顺序将过滤后的输入信息发送给待测试客户端。

进一步包括：

通过待测试客户端向用户展示该待测试客户端是否可用的具体信息。

所述通过待测试客户端向用户展示该待测试客户端是否可用的具体信息具体包括：

对于通过可用性测试的待测试客户端，直接向用户展示可用性测试通过信息；

对于没有通过可用性测试的待测试客户端，分别展示待测试客户端以及可用客户端匹配不一致的数据信息。

一种客户端，该客户端包括：拉取模块、测试组件模块以及输入信息处理模块，其中，

拉取模块，用于在确定待测试客户端进行可用性测试后，拉取预先设置的输入可用客户端的信息以及可用客户端输出的信息，该输入可用客户端的信息以及可用客户端输出的信息为可用客户端与服务器建立网络连接后，通过可用客户端内置的测试组件获取的，输出至测试组件模块；

测试组件模块，用于解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向输入信息处理模块发送，实时监测并获取输入信息处理模块输出的信息；根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用；

输入信息处理模块，用于接收测试组件模块输出的信息，按照预先设置的游戏策略进行处理后输出。

所述测试组件模块包括：解析单元、模拟输入信息生成单元、监测单元以及匹配单元，其中，

解析单元，用于解析接收的输入可用客户端的信息以及可用客户端输出的信息，将解析得到的输入可用客户端的信息向模拟输入信息生成单元发送；

模拟输入信息生成单元，用于按照接收的输入可用客户端的信息中包含的时间戳信息，模拟输入信息向输入信息处理模块发送，

监测单元，用于实时监测并获取输入信息处理模块输出的信息，获取待测试客户端输出的信息，输出至匹配单元；

匹配单元，用于接收监测单元输出的待测试客户端输出的信息，与解析单元解析得到的可用客户端输出的信息进行匹配，以确定该待测试客户端是否可用。

由上述的技术方案可见，本发明提供的一种测试客户端可用性的方法及客户端，建立可用客户端与服务器的网络连接，通过可用客户端内置的测试组件获取输入可用客户端的信息以及可用客户端输出的信息；启动内置测试组件的待测试客户端，确定进行待测试客户端可用性测试，拉取输入可用客户端的信息以及可用客户端输出的信息；测试组件解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向待测试客户端发送，实时监测并获取待测试客户端输出的信息；根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用。这样，通过获取可用客户端的输入输出信息，相应形成测试数据包以及验证数据包，使得游戏项目接口的改动并不影响测试组件的应用，也不需要对测试组件进行改动，提高了测试效率、降低了测试维护成本；进一步地，测试不需要在与服务器进行网络连接的状态下，有效降低了网络流量开销。

附图说明

图1为本发明实施例处于网络连接的基于C/S架构的客户端输入、输出信息结构示意图；

图2为本发明实施例测试客户端可用性的方法流程示意图；

图3为本发明实施例客户端处于联机录制模式的交互流程示意图；

图4为本发明实施例客户端处于联机录制模式的结构示意图；

图5为本发明实施例客户端处于脱机播放模式的交互流程示意图；

图6为本发明实施例客户端处于脱机播放模式的结构示意图；

图7为本发明实施例客户端处于联机播放模式的交互流程示意图；

图8为本发明实施例客户端处于联机播放模式的结构示意图；

图9为本发明实施例录制和播放中对于时间的控制示意图；

图10为本发明实施例客户端结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步地详细描述。

现有基于C/S架构的用于MMOG游戏的客户端在开发过程中，需要随时保证客户端版本的可用性，然而，客户端的可用性在开发的进展过程中是难以控制的，特别是项目早期，采用自动构建方式产生的客户端，很多时候其实是不可用的。而现有测试客户端的方法，在游戏项目接口改动后，需要对应修改脚本中的相关内容，在新添加功能时，需要重新进行脚本编辑，使得测试效率较低、测试维护成本高，不能测试的需求。本发明实施例中，通过在可用的客户端中设置测试组件，在客户端与服务器建立网络连接进行游戏交互时，按照游戏功能分别获取输入客户端的数据信息以及经过客户端处理后输出的数据信息，相应形成测试数据包以及验证数据包，在对测试客户端进行测试时，通过内置的测试组件导入测试数据包，解析测试数据包中包含的数据信息，向测试客户端发送，获取经该测试客户端处理后输出的数据信息，与验证数据包进行比对以确定该测试客户端是否可用，从而实现支持联机和脱机对客户端进行自动测试。

下面先对本发明实施例客户端的输入、输出信息进行说明。

图1为本发明实施例处于网络连接的基于C/S架构的客户端输入、输出(I/O，Input/Output)信息结构示意图。参见图1，用户通过鼠标、键盘等输入设备触发向客户端输入游戏相关指令信息(Win32消息)，例如，用户在游戏进程中，通过按下键盘按键、弹起按键、长按按键、单击鼠标、双击鼠标以及滑动滚轮等，触发向客户端输入游戏相关指令信息；客户端处理如下的消息或信息：输入设备输入信息，即游戏相关指令信息，包括通过键盘、鼠标以及其他的输入设备等输入的信息，将用户输入的信息，根据游戏设置的策略，进行相应处理，例如，游戏设置的策略为用户按下键盘按键表示拾取物品，则客户端在监测到用户按下键盘按键后，将该户按下键盘按键的操作处理为拾取物品请求，以协议消息的方式向服务器发送；客户端时间变更(当前时间，以时钟点形式)的输入；以及处理服务器下发到客户端的消息，例如，如前所述，在客户端以协议消息的方式向服务器发送拾取物品请求后，服务器根据接收的拾取物品请求，确认用户可以拾取该物品后，向客户端以协议消息的方式返回拾取物品请求响应，客户端根据拾取物品请求响应中包含的信息，执行拾取物品的操作并将对应的动画通过引擎实现画面的展示以及音效的播放，从而让用户感知到，然后将根据拾取物品请求响应进行的操作信息向服务器反馈，以使服务器获知客户端的游戏进程情况。

图2为本发明实施例测试客户端可用性的方法流程示意图。参见图2，该流程包括：

步骤201，建立可用客户端与服务器的网络连接，通过可用客户端内置的测试组件获取输入可用客户端的信息以及可用客户端输出的信息；

本步骤中，首先确定一可用客户端，确定该可用客户端的流程可以采用现有技术，具体可参见相关技术文献，在此不再赘述。

设置监测并截获输入及输出客户端信息的测试组件，该测试组件的程序可通过现有技术人员通过编程实现，由于只需截获输入及输出客户端信息，通用性广，维护成本低；而且，测试组件内置在客户端中，因而，可以获取输入客户端中的经客户端解密处理的数据、以及，客户端准备向外输出的还未经加密处理的数据信息。

客户端的输入输出信息如前述图1所述。

本发明实施例中，通过可用客户端内置的测试组件获取输入可用客户端的信息以及可用客户端输出的信息具体包括：

可用客户端运行游戏程序；

接收用户通过输入设备向客户端输入的游戏相关指令信息，按照游戏设置的策略，进行相应处理，向服务器输出游戏相关指令信息对应的请求信息；

本步骤中，用户可以针对游戏中某一功能进行操作，每一功能操作分别对应客户端的处理以及服务器的处理。当然，实际应用中，用户也可以针对游戏中的多个功能或整个游戏分别进行操作。

客户端按照游戏设置的策略，处理相应输入的游戏相关指令信息，与现有用户进行游戏处理流程相同，在此不再赘述。

接收服务器返回的请求响应信息，执行相应操作，输出请求响应反馈信息；

本步骤中，客户端根据服务器返回的请求响应信息，执行相应操作，具体也可参见相关技术文献。

实际应用中，客户端可以与服务器进行多次交互以完成相应的功能操作，这样，存在多个请求信息及其对应的请求响应信息以及请求响应反馈信息。

客户端内置的测试组件实时监测并获取游戏相关指令信息、请求信息、请求响应信息以及请求响应反馈信息。

较佳地，按照功能操作对测试组件监测并获取的信息进行分类存储。

本步骤中，按照信息处理的先后时间顺序分类存储每一功能操作对应的游戏相关指令信息、请求信息、请求响应信息以及请求响应反馈信息，以便后续中进行客户端测试。例如，记录游戏相关指令信息内容及其时间戳信息，其中，游戏相关指令信息可以以具体数据结构进行记录，也可以将游戏相关指令信息作为一个数据块直接记录，在读取时再根据协议进行解析，时间戳可以是全局时间，也可以是当前游戏相关指令信息和前一游戏相关指令信息的时间间隔。

实际应用中，还可以将分类存储的信息中的游戏相关指令信息以及请求响应信息封装为测试数据包，将请求信息以及请求响应反馈信息封装为验证数据包。

较佳地，分类存储的信息置放于预先设置的共享区，并将该共享区的地址信息存储于测试组件中。

步骤202，启动内置测试组件的待测试客户端，确定进行待测试客户端可用性测试，拉取输入可用客户端的信息以及可用客户端输出的信息；

本步骤中，每个客户端中内置有测试组件，在启动客户端后，确定进行客户端可用性测试，则测试组件根据存储的共享区的地址信息拉取输入可用客户端的信息以及可用客户端输出的信息。

本发明实施例中，确定进行客户端可用性测试可在客户端的配置文件中进行预先设置，即预先设置测试对应的客户端启动模式，也就是在客户端的配置文件中，预先设置客户端启动模式对应的测试模式，这样，在启动客户端后，客户端根据配置文件中的设置进行相应处理。

较佳地，待测试客户端具有三种启动模式，分别为普通模式、脱机播放模式以及联机播放模式，待测试客户端可以处于三种启动模式中的一种，需要在开启待测试客户端之前设置好，并在待测试客户端测试运行过程中不可变更。对于可用客户端来说，还包括联机录制模式，即步骤201中可用客户端与服务器建立网络连接以获取测试数据包以及验证数据包的情形，普通模式即为图1中所示的情形。

关于启动模式对应的测试模式，后续再进行详细描述。

步骤203，测试组件解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向待测试客户端发送，实时监测并获取待测试客户端输出的信息；

本步骤中，测试组件解析拉取的输入可用客户端的信息，根据输入可用客户端的信息中包含的时间戳信息，模拟输入设备、和/或，服务器向待测试客户端发送相应指令，以获取该待测试客户端对该指令进行处理后的相应信息。

实际应用中，输入可用客户端的信息包括输入设备输入的游戏相关指令信息以及服务器返回可用客户端的请求响应信息，本发明实施例中，测试组件可以按照预先的设置，只将游戏相关指令信息向待测试客户端发送，或者，只将请求响应信息向待测试客户端发送，当然，也可以将游戏相关指令信息以及请求响应信息按照时间戳信息依序向待测试客户端发送。这样，可以获取待测试客户端相应的处理结果。

较佳地，还可以根据功能操作，将预先设置的功能操作对应的测试数据包信息向待测试客户端发送。

步骤204，根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用。

本步骤中，如前所述，如果测试组件只将游戏相关指令信息向待测试客户端发送，则测试组件根据获取的待测试客户端输出的请求信息，与拉取的可用客户端输出的游戏相关指令信息对应的请求信息进行匹配，如果匹配成功，表明该待测试客户端通过可用性测试，如果匹配失败，表明该待测试客户端可用性测试失败；只将请求响应信息向待测试客户端发送与只将游戏相关指令信息向待测试客户端发送的判断流程相同。

上述通过单一发送信息进行判断的方法，虽然简洁，但对待测试客户端可用性的测试不够全面，因而，本发明实施例中，结合游戏相关指令信息以及请求响应信息以确定该待测试客户端是否可用，即按照时间戳信息依序向待测试客户端发送游戏相关指令信息以及请求响应信息，分别获取游戏相关指令信息对应的请求信息以及请求响应信息对应的请求响应反馈信息，与拉取的可用客户端输出的请求信息以及请求响应反馈信息分别进行相应匹配，如果匹配都成功，表明该待测试客户端通过可用性测试，否则，表明该待测试客户端可用性测试失败。

较佳地，本发明实施例进一步包括：

步骤205，通过待测试客户端向用户展示该待测试客户端是否可用的具体信息。

本步骤中，对于通过可用性测试的待测试客户端，直接向用户展示可用性测试通过信息，对于没有通过可用性测试的待测试客户端，将匹配不成功的相关信息进行展示，例如，分别展示待测试客户端以及可用客户端匹配不一致的数据信息，以便于测试人员或开发人员进行分析。

至此，本发明实施例的测试客户端可用性的方法流程结束。

下面对待测试客户端以及可用客户端涉及的启动模式及其对应的测试模式进行详细说明。

图3为本发明实施例客户端处于联机录制模式的交互流程示意图。

图4为本发明实施例客户端处于联机录制模式的结构示意图。参见图3和图4，应用于可用客户端，基于C/S架构的客户端联机录制模式交互流程包括：

步骤301，预先设置客户端以联机录制模式启动；

本步骤中，通过更改客户端中配置文件的参数，选择联机录制模式进行启动，然后启动客户端，启动后客户端将进入联机录制模式。

步骤302，建立与服务器的网络连接；

步骤303，启动游戏运行程序，与服务器进行游戏交互；

本步骤中，用户可以通过鼠标、键盘输入游戏命令参数，即游戏相关指令信息，客户端将用户输入的游戏命令参数进行处理，转换后形成请求消息，并对请求消息封装、加密后输出至服务器，接收服务器输出的经相应处理并封装、加密的游戏命令参数响应信息，即请求响应信息，进行解密以及解封装后，执行相应游戏操作，并根据游戏进程与服务器交互。

步骤304，触发内置的测试组件获取客户端输入及输出信息；

本步骤中，由于测试组件预置在客户端中，因而，可以获取输入客户端的经客户端解密及解封装后的数据信息(输入信息)，以及未经客户端进行封装及加密处理的输出数据信息(输出信息)。

联机录制模式中，用户可以进行正常的互联网游戏，客户端的I/O与普通模式相比，增加了测试组件对客户端输入信息以及输出信息的截获。

步骤305，将获取的客户端输入信息写入测试数据包，将获取的客户端输出信息写入验证数据包。

本步骤中，测试组件将截获的输入信息写入测试数据包，在信息从客户端发出的过程中，测试组件进行截获并写入验证数据包中。

所应说明的是，联机录制模式并非用于测试，而是生成用于测试的测试案例，即测试数据包。在联机录制模式下，客户端一方面连接到服务器进行普通模式操作，所以在联机录制模式下，服务器必须可用，并且需要人工通过键盘、鼠标等方式输入相关网络游戏指令信息，对客户端进行操作，以便针对特定的测试流程生成相应的测试案例，而不是自动进行的。记录的文件包括：测试数据包以及验证数据包，客户端输入端的记录，即测试数据包用于回放测试；输出端的记录，即验证数据包可用于比较测试中的客户端对同一测试案例的响应，以确认该测试中的客户端是否可用。

图5为本发明实施例客户端处于脱机播放模式的交互流程示意图。

图6为本发明实施例客户端处于脱机播放模式的结构示意图。参见图5和图6，基于C/S架构的客户端脱机播放模式交互流程包括：

步骤501，预先设置待测试客户端以脱机播放模式启动；

本步骤中，通过更改客户端中配置文件的参数，选择脱机播放模式进行启动，然后启动客户端，启动后客户端将进入脱机播放模式，对应其中的一种测试模式。

步骤502，内置的测试组件拉取预先设置的测试数据包以及验证数据包；

本步骤中，测试组件根据配置文件中脱机播放模式映射的测试地址信息，从映射的测试地址中拉取测试所需的测试数据包以及验证数据包，该测试数据包以及验证数据包为联机录制模式中可用客户端截获的输入信息以及输出信息。

步骤503，断开与外部的连接；

本步骤中，待测试客户端将断开所有原有的输入信息，即在普通模式下存在的输入信息都不能到达待测试客户端，待测试客户端的输出信息也不能向外输出，测试组件接管待测试客户端，启动测试进程，这样，可以在待测试客户端处于脱机状态下进行测试。

步骤504，测试组件解析测试数据包，按照测试数据包包含的时间戳信息，顺序将输入信息发送给待测试客户端；

本步骤中，测试组件打开联机录制模式下存储的文件，按照记录的时间顺序以及时间间隔，顺序的将这些记录作为消息发送给客户端以模拟游戏进程。实际应用中，测试组件可以根据预先设置的策略，选取存储文件中的一项功能操作或多项功能操作对应的记录作为消息发送给待测试客户端。

步骤505，接收待测试客户端的输出信息并存储；

本步骤中，待测试客户端接收测试组件发送的消息，并根据消息进行相应处理，在处理完消息后，对应产生需要输出的信息，即对接收的消息的响应。测试组件截获待测试客户端产生的需要输出的信息，并进行存储。

步骤506，比对存储的信息以及拉取的验证数据包，确定存储的信息与拉取的验证数据包中相对应的信息一致，确定该待测试客户端可用。

本步骤中，测试组件将截获的待测试客户端产生的需要输出的信息与联机录制模式时记录的输出信息(验证数据包)比较，产生比较日志，如果与联机录制模式时记录的相应输出信息一致，表明该待测试客户端通过可用性测试，如果不一致，测试人员或开发人员可以根据比较日志分析待测试客户端存在的问题并进行改进。

本发明实施例中，在进行比较之后，测试组件可将存储的待测试客户端产生的需要输出的信息执行丢弃处理，由于待测试客户端断开了与外部的连接，其输出信息也不会发往服务端。

在脱机播放模式下，通过拉取预先设置的测试数据包以及验证数据包，使得待测试客户端可以完全脱离服务器进行单独的测试，不需要进行网络交互，因此，即使不进行网络连接，也将不影响可用性测试的进行。在服务器没有准备好，或者客户端和服务器端版本不匹配时，本发明实施例的脱机播放模式的测试方式能很大程度上节约等待时间、提高测试效率。

图7为本发明实施例客户端处于联机播放模式的交互流程示意图。

图8为本发明实施例客户端处于联机播放模式的结构示意图。参见图7和图8，基于C/S架构的客户端联机播放模式交互流程包括：

步骤701，预先设置待测试客户端以联机播放模式启动；

本步骤中，通过更改客户端中配置文件的参数，选择联机播放模式进行启动，然后启动客户端，启动后客户端将进入联机播放模式。

步骤702，测试组件拉取预先设置的测试数据包以及验证数据包；

本步骤中，测试组件根据配置文件中联机播放模式映射的测试地址信息，从映射的测试地址中拉取测试所需的测试数据包以及验证数据包，该测试数据包以及验证数据包为联机录制模式中可用客户端截获的输入信息以及输出信息。

本发明实施例中，联机播放模式映射的测试地址信息与脱机播放模式映射的测试地址信息相同。

步骤703，断开与外部输入设备的连接；

本步骤中，待测试客户端将断开与键盘、鼠标等外部输入设备的连接，但不断开系统时间和服务器的发包，测试组件接管待测试客户端，启动测试进程。

步骤704，测试组件解析测试数据包，过滤外部输入设备发送的信息，按照测试数据包包含的时间戳信息，顺序将过滤后的输入信息发送给待测试客户端；

本步骤中，测试组件打开联机录制模式下存储的文件，筛选出其中包含的键盘、鼠标等外部输入设备的输入信息，即按照请求响应信息进行测试，将筛选出的信息按照记录的时间顺序以及时间间隔，顺序的将这些记录作为消息发送给客户端以模拟游戏进程。

步骤705，接收待测试客户端的输出信息并存储；

本步骤中，待测试客户端接收测试组件发送的消息，并根据消息进行相应处理，在处理完消息后，对应产生需要输出的信息，即对接收的消息的响应。测试组件截获待测试客户端产生的需要输出的信息，并进行存储。

步骤706，比对存储的信息以及拉取的验证数据包，确定存储的信息与拉取的验证数据包中相对应的信息一致，确定该待测试客户端可用。

本步骤中，待测试客户端产生的需要输出的信息，可以与普通模式一样，被发送至服务端进行处理。

在联机播放模式下，网络连接必须可用，并且服务器端准备好的情况下进行，可以用于进行客户端与服务器组成系统的整体验证，其验证结果可以保证产品整体是可用的。

由上可见，本发明实施例中，只需对客户端进行修改，挂接一个测试组件，该测试组件在客户端启动的时候加载，使客户端可以以不同模式启动，启动模式写在配置文件中，在启动的时候，通过读取配置文件判断启动的模式。如果没有设置启动模式，则以普通模式启动，以保证用户能够正常使用客户端。

以联机录制方式启动客户端的时候，客户端连接到服务器，人工对客户端进行操作。此时，客户端在正常执行的同时，测试组件将服务器发送的所有包，以及客户端自身收到的鼠标、键盘消息，保存于预先设置的文件。文件包含的内容是包的数据内容以及收到包的时间戳。同时测试组件还记录客户端在收到消息以后做出的响应，响应以另外的文件进行记录，记录的内容也是响应包的数据内容以及时间戳，这样，方便管理。

以脱机播放模式启动的时候，客户端将本机输入和服务器消息挂起，同时读取存储的记录文件，获得所录制的客户端收到的消息。将这些消息按照录制时的时间顺序，以及当时的时间间隔，模拟收到的消息向自身发送。这些消息作为客户端的输入将驱动客户端按照和录制时完全相同的情况执行下去。播放的时候，客户端产生的响应用于和录制时产生的响应相比较，可以得到播放时的客户端和录制时的不同。

进行对比时，如果记录的数据信息经过封装，需要对记录的数据进行解析，以预先指定的字段进行比较，可以避免因为随机数值的存在而误认为测试失败，例如，选项的索引可以加入对比中，而自主运动的非玩家控制角色(NPC，Non-Player Character)或者其他玩家所在的位置不应该进行对比。

同时，本发明实施例中，测试组件作为一个模块存在，为了完全符合录制时的条件，将连同系统时间一起托管，即回放时输入的时间点也是在录制的时候记录下的，这样，可以保证回放和录制的环境完全相同，从而避免一些因为消息延迟而可能导致的错误。

图9为本发明实施例录制和播放中对于时间的控制示意图。参见图6，当前录制的时间点为t0，下一录制的时间点为t2，间隔为(t2-t0)，当前播放的时间点为t1，则通过将播放时的实际时间点值t1换成录制时间点值t0(t1＝t0)，如果播放中出现延迟t′，则下一播放的时间点调节为(t2-t1+t′)，客户端按照读取、发送、更新时间的节奏执行，直到文件读取结束。

由上述可见，本发明实施例的测试客户端可用性的方法，建立可用客户端与服务器的网络连接，通过可用客户端内置的测试组件获取输入可用客户端的信息以及可用客户端输出的信息；启动内置测试组件的待测试客户端，确定进行待测试客户端可用性测试，拉取输入可用客户端的信息以及可用客户端输出的信息；测试组件解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向待测试客户端发送，实时监测并获取待测试客户端输出的信息；根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用。这样，通过获取可用客户端的输入输出信息，相应形成测试数据包以及验证数据包，使得游戏项目接口的改动并不影响测试组件的应用，且对于新添加的任何功能，也不需要对测试组件进行改动，提高了测试效率、降低了测试维护成本；进一步地，测试组件的应用不需要专门的脚本编程技术人员，对测试人员要求低；在对待测试客户端进行测试时，通过内置的测试组件导入测试数据包，将输入信息向测试客户端发送，获取经该测试客户端处理后的输出信息，与可用客户端的输出信息进行比对以确定该测试客户端是否可用，测试不需要在与服务器进行网络连接的状态下，从而可以实现脱机对客户端进行自动测试，有效降低了网络流量开销。

图10为本发明实施例客户端结构示意图。参见图10，该客户端包括：拉取模块、测试组件模块以及输入信息处理模块，其中，

拉取模块，用于在确定待测试客户端进行可用性测试后，拉取预先设置的输入可用客户端的信息以及可用客户端输出的信息，该输入可用客户端的信息以及可用客户端输出的信息为可用客户端与服务器建立网络连接后，通过可用客户端内置的测试组件获取的，输出至测试组件模块；

测试组件模块，用于解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向输入信息处理模块发送，实时监测并获取输入信息处理模块输出的信息；根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用；

输入信息处理模块，用于接收测试组件模块输出的信息，按照预先设置的游戏策略进行处理后输出。

测试组件模块包括：解析单元、模拟输入信息生成单元、监测单元以及匹配单元，其中，

解析单元，用于解析接收的输入可用客户端的信息以及可用客户端输出的信息，将解析得到的输入可用客户端的信息向模拟输入信息生成单元发送；

模拟输入信息生成单元，用于按照接收的输入可用客户端的信息中包含的时间戳信息，模拟输入信息向输入信息处理模块发送，

监测单元，用于实时监测并获取输入信息处理模块输出的信息，获取待测试客户端输出的信息，输出至匹配单元；

匹配单元，用于接收监测单元输出的待测试客户端输出的信息，与解析单元解析得到的可用客户端输出的信息进行匹配，以确定该待测试客户端是否可用。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换以及改进等，均应包含在本发明的保护范围之内。

Claims (16)

1.一种测试客户端可用性的方法，其特征在于，该方法包括：

建立可用客户端与服务器的网络连接，通过可用客户端内置的测试组件获取输入可用客户端的信息以及可用客户端输出的信息；

启动内置测试组件的待测试客户端，确定进行待测试客户端可用性测试，拉取输入可用客户端的信息以及可用客户端输出的信息；

测试组件解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向待测试客户端发送，实时监测并获取待测试客户端输出的信息；

根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用。

2.如权利要求1所述的方法，其特征在于，所述通过可用客户端内置的测试组件获取输入可用客户端的信息以及可用客户端输出的信息具体包括：

可用客户端运行游戏程序；

接收用户通过输入设备向客户端输入的游戏相关指令信息，按照游戏设置的策略，进行相应处理，向服务器输出游戏相关指令信息对应的请求信息；

接收服务器返回的请求响应信息，执行相应操作，输出请求响应反馈信息；

客户端内置的测试组件实时监测并获取游戏相关指令信息、请求信息、请求响应信息以及请求响应反馈信息。

3.如权利要求2所述的方法，其特征在于，

所述输入可用客户端的信息包括输入设备输入的游戏相关指令信息、和/或，服务器返回可用客户端的请求响应信息。

所述可用客户端输出的信息包括请求信息、和/或，请求响应反馈信息。

4.如权利要求3所述的方法，其特征在于，所述输入可用客户端的信息为输入设备输入的游戏相关指令信息，所述根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用具体包括：

测试组件根据获取的待测试客户端输出的请求信息，与拉取的可用客户端输出的游戏相关指令信息对应的请求信息进行匹配，如果匹配成功，确定该待测试客户端可用，否则，确定该待测试客户端不可用，所述请求信息为待测试客户端对接收的游戏相关指令信息进行相应处理得到的信息。

5.如权利要求3所述的方法，其特征在于，所述输入可用客户端的信息为输入设备输入的游戏相关指令信息和服务器返回可用客户端的请求响应信息，所述根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用具体包括：

测试组件根据获取的待测试客户端输出的游戏相关指令信息对应的请求信息以及请求响应信息对应的请求响应反馈信息，分别与拉取的可用客户端输出的游戏相关指令信息对应的请求信息以及请求响应信息对应的请求响应反馈信息分别进行相应匹配，如果分别匹配成功，确定该待测试客户端可用，否则，确定该待测试客户端不可用。

6.如权利要求2所述的方法，其特征在于，按照功能操作对测试组件监测并获取的信息进行分类存储。

7.如权利要求6所述的方法，其特征在于，进一步包括：

将分类存储的信息中的游戏相关指令信息以及请求响应信息封装为测试数据包，将请求信息以及请求响应反馈信息封装为验证数据包。

8.如权利要求7所述的方法，其特征在于，所述分类存储的信息置放于预先设置的共享区，并将该共享区的地址信息存储于测试组件中。

9.如权利要求8所述的方法，其特征在于，根据客户端配置文件中设置的客户端启动模式对应的测试模式确定进行客户端可用性测试。

10.如权利要求9所述的方法，其特征在于，所述启动模式包括：联机录制模式、普通模式、脱机播放模式以及联机播放模式。

11.如权利要求10所述的方法，其特征在于，所述启动模式为脱机播放模式，所述客户端断开与外部的连接。

12.如权利要求10所述的方法，其特征在于，所述启动模式为联机播放模式，所述客户端断开与外部输入设备的连接，所述测试组件解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向待测试客户端发送具体包括：

测试组件解析测试数据包，过滤外部输入设备发送的信息，按照测试数据包包含的时间戳信息，顺序将过滤后的输入信息发送给待测试客户端。

13.如权利要求1至12任一项所述的方法，其特征在于，进一步包括：

通过待测试客户端向用户展示该待测试客户端是否可用的具体信息。

14.如权利要求13所述的方法，其特征在于，所述通过待测试客户端向用户展示该待测试客户端是否可用的具体信息具体包括：

对于通过可用性测试的待测试客户端，直接向用户展示可用性测试通过信息；

对于没有通过可用性测试的待测试客户端，分别展示待测试客户端以及可用客户端匹配不一致的数据信息。

15.一种客户端，其特征在于，该客户端包括：拉取模块、测试组件模块以及输入信息处理模块，其中，

拉取模块，用于在确定待测试客户端进行可用性测试后，拉取预先设置的输入可用客户端的信息以及可用客户端输出的信息，该输入可用客户端的信息以及可用客户端输出的信息为可用客户端与服务器建立网络连接后，通过可用客户端内置的测试组件获取的，输出至测试组件模块；

测试组件模块，用于解析输入可用客户端的信息，按照输入可用客户端的信息中包含的时间戳信息向输入信息处理模块发送，实时监测并获取输入信息处理模块输出的信息；根据获取的待测试客户端输出的信息以及可用客户端输出的信息，确定该待测试客户端是否可用；

输入信息处理模块，用于接收测试组件模块输出的信息，按照预先设置的游戏策略进行处理后输出。

16.如权利要求15所述的客户端，其特征在于，所述测试组件模块包括：解析单元、模拟输入信息生成单元、监测单元以及匹配单元，其中，

解析单元，用于解析接收的输入可用客户端的信息以及可用客户端输出的信息，将解析得到的输入可用客户端的信息向模拟输入信息生成单元发送；

模拟输入信息生成单元，用于按照接收的输入可用客户端的信息中包含的时间戳信息，模拟输入信息向输入信息处理模块发送，

监测单元，用于实时监测并获取输入信息处理模块输出的信息，获取待测试客户端输出的信息，输出至匹配单元；

匹配单元，用于接收监测单元输出的待测试客户端输出的信息，与解析单元解析得到的可用客户端输出的信息进行匹配，以确定该待测试客户端是否可用。

Images