CN112597000A - 一种基于WebScoket协议的即时通讯软件自动化测试方法 - Google Patents

Abstract

本申请公开了一种基于WebScoket协议的自动化测试方法，用以解决现有技术中人工软件测试效率低，导致资源浪费的问题。该方法包括：预先初始化配置文件，所述配置文件中包括预置的测试用户；与服务端建立WebScoket连接，读取所述配置文件，根据所述服务端支持的消息结构模拟所述测试用户发送测试消息，并将所述测试消息存储到Redis数据库；监听所述服务端接收并广播的测试消息，将所述服务端接收并广播的测试消息存储到Redis数据库；接收所述服务端广播的测试消息，验证获得的测试消息是否符合预期，之后验证所述Redis数据库中的向所述服务端发送的测试消息与所述服务端接收并广播的测试消息的一致性。

Description

一种基于WebScoket协议的即时通讯软件自动化测试方法

技术领域

本申请涉及软件测试领域，尤其涉及一种基于WebScoket协议的即时通讯软件自动化测试方法。

背景技术

随着信息化进程的推进，越来越多的企业将会有引入了私有化部署的，用于企业成员高效沟通即时通讯软件的需求。此类软件上线前，需要经过充分测试保证软件的功能、性能以及稳定性。

现有技术有专门的从事软件测试的工作人员，对即时通讯软件测试时，可以利用人工模拟用户的方式，来测试软件的功能是否正常。

但是人工测试需要消耗大量人力，而且效率不高，尤其针对需要短时间发送大批量消息的场景，人工基本不可能实现。

发明内容

本发明提供了一种基于WebScoket协议的即时通讯软件自动化测试方法，可以解决了上述问题。

一种基于WebScoket协议的即时通讯软件自动化测试方法，包括：

预先初始化配置文件，所述配置文件中包括预置的测试用户；

与服务端建立WebScoket连接，读取所述配置文件，根据所述服务端支持的消息结构模拟所述测试用户发送测试消息，并将所述测试消息存储到Redis数据库；

监听所述服务端接收并广播的测试消息，将所述服务端接收并广播的测试消息存储到Redis数据库；

接收所述服务端广播的测试消息，验证获得的测试消息是否符合预期，之后验证所述Redis数据库中的向所述服务端发送的测试消息与所述服务端接收并广播的测试消息的一致性。

通过本方法，使计算机代替了人工的工作，降低了测试成本，节约了人力和测试资源，提高了对软件的测试效率。

在本申请的一种实施例中，将所述测试用户的登录令牌存储到所述Redis数据库，通过访问所述Redis数据库获取所述登录令牌。避免了每次发送测试消息就要重复登录所造成的资源浪费，提高了测试效率。

在本申请的一种实施例中，与服务端建立WebScoket连接后，所述方法还包括：

监听所述客户端连接状态，所述客户端接收到连接成功的状态码后，通过emit方法给所述服务端发送测试消息；

监听并接收服务端广播的测试消息，将所述服务端接收并转发的测试消息存储到Redis数据库；

监听webSocket的自身连接，并利用回调方法记录测试日志。

在本申请的一种实施例中，监听到所述客户端接收到连接成功的状态码后，创建发送测试消息的定时器，创建所述定时器的参数根据所述配置文件传入，所述定时器功能利用Java定时器实现。定时器的使用可定时发送具有一定时间间隔的测试消息，定时器创建参数通过配置文件传入，结构灵活，方便个性化需求定制。

在本申请的一种实施例中，采用Java的TestNG测试框架完成测试流程，通过testng.xml配置文件，实现只通过修改配置参数就能模拟不同测试场景的需求。

在本申请的一种实施例中，预先初始化配置文件，具体包括：

预先配置所述测试用户、消息频道、所述服务端地址、所述Redis库信息、测试日志信息、监听器配置、模拟的测试场景参数；

所述配置文件采用yaml格式。

在本申请的一种实施例中，模拟的测试场景，具体包括：

单用户单频道发送消息、多用户单频道发送消息、单用户多频道发送消息、多用户多频道发送消息，其中，每个所述测试用户发送测试消息的条数、在哪个消息频道发送测试消息以及发送测试消息的频率可以参数化预置。

在本申请的一种实施例中，所述方法还包括：

所述测试用户在预置的消息频道按规则发送不同类型的消息，将图片和文件信息参数化到配置文件，通过读取所述配置文件将不同类型的测试消息发送到对应测试场景的消息频道。

在本申请的一种实施例中，在构建测试消息时，将所述测试用户的信息作为参数的一部分进行预置，模拟某条测试消息是某个用户发送的场景。

在本申请的一种实施例中，验证获得的测试消息是否符合预期，具体包括：

在安装被测软件的设备中验证客户端接收到的测试消息是否符合预期，要验证的验证点包括：消息通知、应用未读消息数角标显示、消息频道未读消息数显示、接收消息是否按预期的顺序显示、接收消息是在预期的消息频道显示、接收大批量消息时更多消息加载的显示、图片显示、图片评论消息显示。

本发明提供了一种基于WebScoket协议的即时通讯软件自动化测试方法，能能够模拟多种实际的测试场景，通过配置文件预置好参数后，模拟场景测试简单方便又可反复执行，尤其针对需要短时间发送大批量消息的场景，人工基本不可能实现，本发明在验证即时通讯软件稳定性和可靠性方面有极大的优势，同时能够很大程度节约测试资源；采用Java的TestNG测试框架，基本的测试逻辑编写好后，测试执行人员只需调整配置文件参数就可以实现不同的测试场景的模拟，简单易用，具有良好的推广应用价值；本发明将发送的测试消息与监听到服务端广播的消息都存于redis数据库，TestNG测试框架在运行发送测试消息的同时自身也充当了即时通讯软件的客户端，消息存储方便测试结果比对，能按需生成需要的测试报告，方便测试结果展示。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种基于WebScoket协议的即时通讯软件自动化测试方法的过程示意图。

图2为本申请实施例提供的一种基于WebScoket协议的即时通讯软件自动化测试方法的实施例过程示意图。

图3为本申请实施例提供的结果验证场景示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例对本申请进行清楚、完整的描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在现有技术中，WebSocket协议是基于TCP的一种新的网络协议。它实现了浏览器与服务器全双工(full-duplex)通信--允许服务器主动发送信息给客户端。WebSocket协议之前，双工通信是通过不停发送HTTP请求，HTTP协议是一种无状态的、无连接的、单向的应用层协议，它采用了请求/响应模型，通信请求只能由客户端发起，服务端对请求做出应答处理，这种通信模型有一个弊端，就是HTTP协议无法实现服务器主动向客户端发起消息，这导致了效率低下、非常浪费资源。WebSocket解决了这个问题。

当下越来越多的企业引入了私有化部署，拥有用于企业成员高效沟通即时通讯软件的需求，由此，许多通讯软件应运而生，但目前来说，即时通讯软件测试需要投入大量人力，人工对此类软件通讯消息进行测试的效率不高，而且人工操作有限，无法完成像计算机一样在短时间内发送大量消息的作业。

本申请的方案可以解决上述问题，下面进行具体说明。

图1为本申请实施例提供的一种基于WebScoket协议的即时通讯软件自动化测试方法的过程示意图，可以包括以下步骤：与

预先初始化配置文件，配置文件中包括预置的测试用户；

与服务端建立WebScoket连接，读取配置文件，根据服务端支持的消息结构模拟测试用户发送测试消息，并将测试消息存储到Redis数据库；

监听服务端接收并广播的测试消息，将服务端接收并广播的测试消息存储到Redis数据库；

接收服务端广播的测试消息，验证获得的测试消息是否符合预期，之后验证Redis数据库中的向服务端发送的测试消息与服务端接收并广播的测试消息的一致性。

在本申请的一种实施例中，预置初始化的配置文件，TestNG测试框架运行与服务端建立WebScoket连接，读取配置文件，模拟第一测试用户登录，根据服务端支持的消息结构模拟测试用户发送测试消息，并将测试消息存储到Redis数据库；服务端对测试用户发送的测试消息接收并将其广播出去，TestNG测试框架运行监听服务端接收并广播的测试消息，并将服务端接收并广播的测试消息存储到Redis数据库；

被测通讯软件端的第二测试用户接收服务端广播的测试消息，经过TestNG测试框架运行验证被测通讯软件端的第二测试用户接收到的测试消息是否符合预期，之后验证Redis数据库中的由模拟的第一测试用户向服务端发送的测试消息与TestNG测试框架运行监听到的服务端接收并广播的测试消息的一致性。

图2为本申请实施例提供的一种基于WebScoket协议的即时通讯软件自动化测试方法的实施例过程示意图。在本申请的一种实施例中，预先初始化配置文件，具体包括：预先配置测试用户、消息频道、服务端地址、Redis库信息、测试日志信息、监听器配置、模拟的测试场景参数；配置文件采用yaml格式。

首先，预置初始化配置文件，用户配置文件就是在用户登录电脑时，或是用户在使用软件时，软件系统为用户所要加载所需环境的设置和文件的集合。本申请中包括以下几部分：

1)测试数据预置，包含测试用户和消息频道两部分，通常情况服务端会提供REST接口创建测试用户和消息频道；该部分只需执行一次，预置的测试用户和消息频道可以被不同的测试场景反复利用。

2)测试项目参数配置，包括服务端地址、测试使用的Redis库信息以及日志信息。

3)测试项目监听器配置，比如失败重发机制以及测试报告格式等。

4)测试项目测试方法参数配置，设计不同测试场景的配置入口，运行时可以根据不同的场景对配置文件修改，通过配置不同参数来驱动测试执行；

在本申请的一种实施例中，模拟的测试场景，具体包括：单用户单频道发送消息、多用户单频道发送消息、单用户多频道发送消息、多用户多频道发送消息，其中，每个测试用户发送测试消息的条数、在哪个消息频道发送测试消息以及发送测试消息的频率可以参数化预置。

本发明可模拟的测试场景包括，单用户单频道发送消息，例如一个用户在一个聊天界面发送消息；多用户单频道发送消息，比如像群聊方式，多个用户在一个群里，在一个聊天界面发送消息；单用户多频道发送消息，一个用户给不同的用户发送消息；多用户多频道发送消息，模拟多个用户在不同聊天界面给多个不同用户发送消息；其中每个测试用户发送消息的条数、在哪个频道发送消息以及发送消息的频率均可以参数化预置。

在本申请的一种实施例中，采用Java的TestNG测试框架完成测试流程，通过testng.xml配置文件，实现只通过修改配置参数就能模拟不同测试场景的需求。

配置文件初始化完成后，采用TestNG(Next Generation)测试框架运行管理测试进程，TestNG是一个测试框架，它受到JUnit和Nunit(Java类测试中两种测试软件的框架)的启发，而引入了许多新的创新功能，如依赖测试，分组概念，使测试更强大，更容易做到。它旨在涵盖所有类别的测试：单元，功能，端到端，集成等。通过配置testng.xml文件，可以实现只通过修改文本配置就能模拟不同测试场景的需求，并将测试数据参数化，部分配置举例如下：

在本申请的一种实施例中，将测试用户的登录令牌存储到Redis数据库，通过访问Redis数据库获取登录令牌。

模拟用户登录，即时通讯系统通常需要用户登录后才能发送消息，为了避免反复登录造成资源浪费，本申请一种实施例采用的策略是将请求到的测试用户Token(令牌)保存到Redis数据库，测试时只需要通过访问Redis数据库就可以获取登录Token，提高测试效率，通常Token的有效期为8小时。

在本申请的一种实施例中，方法还包括：测试用户在预置的消息频道按规则发送不同类型的消息，将图片和文件信息参数化到配置文件，通过读取配置文件将不同类型的测试消息发送到对应测试场景的消息频道。

发送测试消息之前，需要测试用户在测试频道按规则发送不同类型的消息，消息类型包括：文本、图片、图片评论以及文件，文本消息构造相对容易，只需要一个字符串类型的参数就可以实现按需预置，图片与文件相对麻烦，消息发送过程对图片和文件本身的多样性要求不高，TestNG测试框架运行只需要预置几个必须的即可，并将图片和文件信息参数化到配置文件，通过运行代码读取配置文件可以将不同的测试消息发送到对应测试场景的消息频道。本发明测试数据配置文件采用yaml格式，部分测试数据举例如下：

TestNG测试框架运行读取配置文件完成测试用户的登录，读取配置文件中预置好的测试消息，测试消息和服务端交互，必须遵守服务端规定的消息结构，列举部分服务器消息结构如下：

服务器消息类型：

枚举值	说明
		SendMsg(0)	发送消息
ChangeMsgState	修改消息状态
		UnreadMsg	上次登出后未读消息数
HistoryMsg	历史消息
		Comment	根据消息ID获取评论内容
CommentNum	根据消息ID获取评论个数
		Text	消息内容类型为文本
Image	消息内容类型为图片
		File	消息内容类型为文件

基于不同的测试场景，根据上述描述的消息结构，初始化对应的测试消息，测试消息类型为JSONObject，JSONObject只是一种数据结构，可以理解为JSON格式的数据结构(key-value结构)，可以使用put方法给json对象添加元素。JSONObject可以很方便的转换成字符串，也可以很方便的把其他对象转换成JSONObject对象。消息结构，以文本为列举如下：

在本申请的一种实施例中，根据服务端支持的消息结构明确即时通讯软件的消息结构；要和即时通讯软件的服务端建立通讯，发送的消息结构必须满足服务端本身的消息结构定义，因此首先需要明确即时通讯软件服务端支持的消息结构、消息类型等相关结构，一般开发者会提供给测试方相应的文档说明，现以本实施例被测方文本消息结构为例举例如下：

在本申请的一种实施例中，明确即时通讯软件定义的消息发送接口；WebSocket连接的建立需要明确的服务地址和端口，该部分内容一般开发者也会提供给测试方，现以本实施例被测方消息接口为例说明如下：

TestNG测试框架中配置文件用Yaml格式，便于TestNG测试框架运行读取，举例如下(其中消息频道的数据可用借助创建频道的API获取)：

基于上述前期准备开始编写TestNG测试框架的测试逻辑，本发明重点在于测试逻辑运行建立与即时通讯软件服务建立WebSocket通道，在预置的消息频道使用线程模拟测试用户发送测试消息，本实施例中自动化测试程序采用了配置化、模块化的设计方式，使得程序通过修改配置文件就能满足不同测试场景需求，测试执行简单，易于推广使用。以模拟单用户在某个测试频道每隔2秒发送一条测试消息，一共发送200条为例举例如下：

1)TestNG配置文件配置参数：

<parameter name＝"msgSender"value＝"testUser"></parameter>

<parameter name＝"channelName"value＝"testChannel"/>

<parameter name＝"msgCount"value＝"200"/>

<parameter name＝"msgContent"value＝"测试消息"></parameter>

<parameter name＝"delay"value＝"2000"/>

执行的测试方法配置：

<include name＝"testTimeSingleSend"/>

其中参数msgContent可在测试逻辑中修改，将其Value拼接发送次数，以验证频道接收的消息顺序是否正确。

2)测试逻辑中方法testTimeSingleSend的实现，主要代码举例如下：

3)建立WebSocket连接后，借助Java定时器Timer发送消息的部分代码举例如下：

在本申请的一种实施例中，TestNG测试框架运行实现和服务端建立WebSocket连接后，就可以模拟用户发送消息，测试消息发送是基于WebSocket协议实现的，采用的是Java版本的socket.io库，Socket.IO是一个基于Node.js的实时应用程序框架，在即时通讯、通知与消息推送，实时分析等场景中有较为广泛的应用，WebSocket的产生源于Web开发中日益增长的实时通信需求，对比基于http的轮询方式，它大大节省了网络带宽，同时也降低了服务器的性能消耗；socket.io支持websocket、polling两种数据传输方式以兼容浏览器不支持WebSocket场景下的通信需求。

在本申请的一种实施例中，与服务端建立WebScoket连接后，监听客户端连接状态，客户端接收到连接成功的状态码后，通过emit方法给服务端发送测试消息；

监听并接收服务端广播的测试消息，将服务端接收并转发的测试消息存储到Redis数据库；

监听webSocket的自身连接，并利用回调方法记录测试日志。

TestNG测试框架运行实现和服务端建立WebSocket连接后，实现客户端与服务端的交互，交互过程包括：1)建立连接；监听“status”事件，接收到客户端与服务端连接成功的状态码后，就可以通过emit方法给服务端发送消息；2)监听服务端消息事件，该部分可以接收服务端广播的消息，并将接收到消息存储到redis库，测试结束后用于验证发送的测试消息和服务端接收到的测试消息是否一致；3)监听webSocket连接自身事件，包括Socket.EVENT_CONNECTING、Socket.EVENT_CONNECT_TIMEOUT、Socket.EVENT_CONNECT_ERROR、Socket.EVENT_DISCONNECT，在回调方法中记录测试日志，协助分析测试结果；其中关键参数以及部分代码如下:

ConnectionPool pool＝newConnectionPool(10,N*1000,TimeUnit.SECONDS)；

OkHttpClient okHttpClient＝new OkHttpClient().newBuilder()

.connectionPool(pool).build()；

Options opts＝new Options()；

Map<String,String>query＝new HashMap<String,String>()；

query.put("client",this.jedis.get("test:ClientID:"+user))；

query.put("authorization",this.jedis.get("test:Token:"+user))；

query.put("enterprise",enterprise)；

opts.path＝"/chat/socket/handshake"；

opts.query＝ParseQS.encode(query)；

opts.reconnectionAttempts＝10；//失败重试次数

opts.reconnectionDelay＝1000；//失败重连的时间间隔

opts.timeout＝500；//连接超时，单位ms

opts.transports＝new String[]{WebSocket.NAME}；

opts.forceNew＝true；

IO.setDefaultOkHttpWebSocketFactory(okHttpClient)；

Socket st＝IO.socket("http://server/api/v1",opts)；

在本申请的一种实施例中，在构建测试消息时，将测试用户的信息作为参数的一部分进行预置，模拟某条测试消息是某个用户发送的场景。

TestNG测试框架运行中测试用户的信息是作为测试消息的一部分存在的，在构建测试消息时将配置文件中创建的测试用户信息作为参数的一部分预置进去，便可以实现模拟某条消息是某个用户发送的场景。

在本申请的一种实施例中，监听到客户端接收到连接成功的状态码后，创建发送测试消息的定时器，创建定时器的参数根据配置文件传入，定时器功能利用Java定时器实现。

TestNG测试框架运行实现指定频率的消息发送；为了模拟不同的测试场景，TestNG测试框架运行需要支持不同频率的消息发送，本发明借助Java定时器Timer实现该功能的模拟。基于建立的WebSocket连接，当监听到事件status返回连接成功的状态码后，创建发送消息的定时器，其中定时器创建参数通过配置文件传入，结构灵活，方便个性化需求定制。部分消息发送的关键代码举例如下：

socket.on("status",new Emitter.Listener(){

public void call(Object...args){

JSONObject obj＝(JSONObject)args[0]；

try{

int code＝obj.getInt("code")；

if("success"＝＝code){

Timer timer＝new Timer()；

timer.schedule(new TimerTask(){

@Override

public void run(){

if(count<param.getMsgCount()){

param.setMsgText(Integer.toString(count)+":"

+param.getDeviceName()+":by"+param.getUser())；

JSONObject msg＝MsgBody.MakeRequestBody(msgType,param)；

socket.emit("com.inspur.ecm.chat",msg)；

}else{

timer.cancel()；}

count++；}},0,delay)；}

else{

logger.error("socket.on.stauts,握手返回的code为:"+code)；}}

catch(Exception e){

logger.error("socket.on.stauts,抛异常:"+e.getMessage())；}

}})；

在本申请的一种实施例中，验证获得的测试消息是否符合预期，具体包括：

在安装被测软件的设备中验证客户端接收到的测试消息是否符合预期，要验证的验证点包括：消息通知、应用未读消息数角标显示、消息频道未读消息数显示、接收消息是否按预期的顺序显示、接收消息是在预期的消息频道显示、接收大批量消息时更多消息加载的显示、图片显示、图片评论消息显示。

图3为本申请提供的结果验证场景示意图，包括设备界面的应用未读消息数角标显示、消息频道未读消息数显示、接收消息是否按预期的顺序显示、接收消息是在预期的频道显示。服务端接收到测试消息，将该测试消息广播给接收测试消息的客户端，同时也广播给发送测试消息的客户端，确保每个客户端都能接收到服务端广播的消息；被测即时通讯软件通常会有三个版本，Android移动端、iOS移动端以及桌面应用。因此测试逻辑中结果验证会分为两部分，一部分是在安装被测软件的设备中验证，该部分的验证点包括：消息通知、应用未读消息数角标显示、消息频道未读消息数显示、接收消息是否按预期的顺序显示、接收消息是在预期的频道显示、大批量消息时更多消息加载的显示、图片显示显示、图片评论消息显示等，本部分的验证目前只能在测试消息服务执行完成后人工验证；另一部分是测试程序本身发送测试消息的验证，因为建立的WebSocket连接有可能是不稳定的，测试消息有发送不成功的可能性，如果不验证发送成功的消息与预期发送的测试消息的一致性，就不能确定当客户端接收的消息和预期不一致时，问题是否由客户端安装的被测软件导致的，该部分的验证是通过比较redis数据库中测试用户端发送的测试消息和服务端广播的消息实现的。经过两部分的组合验证可以极大提高测试效率，保证验证的准确性。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种基于WebScoket协议的即时通讯软件自动化测试方法，其特征在于，包括：

预先初始化配置文件，所述配置文件中包括预置的测试用户；

与服务端建立WebScoket连接，读取所述配置文件，根据所述服务端支持的消息结构模拟所述测试用户发送测试消息，并将所述测试消息存储到Redis数据库；

监听所述服务端接收并广播的测试消息，将所述服务端接收并广播的测试消息存储到所述Redis数据库；

接收所述服务端广播的测试消息，验证获得的测试消息是否符合预期，之后验证所述Redis数据库中的向所述服务端发送的测试消息与所述服务端接收并广播的测试消息的一致性。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

将所述测试用户的登录令牌存储到所述Redis数据库，通过访问所述Redis数据库获取所述登录令牌。

3.根据权利要求1所述的方法，其特征在于，与服务端建立WebScoket连接后，所述方法还包括：

监听客户端连接状态，所述客户端接收到连接成功的状态码后，通过emit方法给所述服务端发送测试消息；

监听并接收服务端广播的测试消息，将所述服务端接收并转发的测试消息存储到所述Redis数据库；

监听WebSocket的自身连接，并利用回调方法记录测试日志。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

监听到所述客户端接收到连接成功的状态码后，创建发送测试消息的定时器，创建所述定时器的参数根据所述配置文件传入，所述定时器功能利用Java定时器实现。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

采用Java的TestNG测试框架完成测试流程，通过testng.xml配置文件，实现只通过修改配置参数就能模拟不同测试场景的需求。

6.根据权利要求1所述的方法，其特征在于，预先初始化配置文件，具体包括：

预先配置所述测试用户、消息频道、所述服务端地址、所述Redis库信息、测试日志信息、监听器配置、模拟的测试场景参数；

所述配置文件采用yaml格式。

7.根据权利要求6所述的方法，其特征在于，模拟的测试场景，具体包括：

单用户单频道发送消息、多用户单频道发送消息、单用户多频道发送消息、多用户多频道发送消息，其中，对每个所述测试用户发送测试消息的条数、在哪个消息频道发送测试消息以及发送测试消息的频率进行参数化预置。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述测试用户在预置的消息频道按规则发送不同类型的消息，将图片和文件信息参数化到配置文件，通过读取所述配置文件将不同类型的测试消息发送到对应测试场景的消息频道。

9.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在构建测试消息时，将所述测试用户的信息作为参数的一部分进行预置，模拟某条测试消息是某个用户发送的场景。

10.根据权利要求1所述的方法，其特征在于，验证获得的测试消息是否符合预期，具体包括：

在安装被测软件的设备中验证客户端接收到的测试消息是否符合预期，要验证的验证点包括：消息通知、应用未读消息数角标显示、消息频道未读消息数显示、接收消息是否按预期的顺序显示、接收消息是在预期的消息频道显示、接收大批量消息时更多消息加载的显示、图片显示、图片评论消息显示。

Images