验证方法、装置、电子设备及计算机可读存储介质与流程

1.本技术涉及计算机技术领域，具体涉及一种验证方法、装置、电子设备及计算机可读存储介质。


背景技术：

2.随着计算机和互联网技术的不断发展，越来越多的用户在互联网上进行信息交互，如：网络购物、即时聊天、在线游戏、浏览各大网站、登录各种应用、观看视频、线上交易等。为了保障网络信息安全，用户在进行网络信息交互时，往往会进行验证。进行验证时通常是输入验证码，验证码是一种区分用户是计算机还是人类的公共全自动程序，可以有效防止某个黑客对某一个特定注册用户用特定程序暴力破解以进行不断的登陆尝试。
3.相关技术中，在进行验证时，可以显示一张验证图片，验证图片上有对应的字符，如：中文、英文或数字等，用户需要识别验证图片上的字符并输入到验证框，系统将会对用户输入的字符进行验证，若与验证图片上的字符一致，就完成了验证。
4.然而，在实际应用中，用户根据验证图片中的字符输入验证码往往并不需要付出脑力劳动，只需要根据肉眼识别出来的字符进行机械的输入，导致验证过程枯燥乏味，使得用户对验证方法失去兴趣，降低了用户体验。


技术实现要素：

5.本技术提供了一种验证方法、装置、电子设备及计算机可读存储介质，能够增加验证过程的趣味性，提升用户对验证方法的感兴趣程度，从而提升用户体验。具体方案如下。
6.第一方面，本技术实施例提供了一种验证方法，其特征在于，所述方法包括：
7.接收第一客户端发送的验证请求，为所述第一客户端匹配交互端；
8.将所述第一客户端和所述交互端中的一个确定为讲述端，另一个确定为倾听端；
9.接收所述讲述端发送的验证问题，并将所述验证问题发送给所述倾听端；
10.接收所述倾听端发送的第一验证答案，所述第一验证答案为所述倾听端接收到的针对所述验证问题的答案；
11.根据所述验证问题及所述第一验证答案判定所述第一客户端是否验证成功。
12.第二方面，本技术实施例提供了一种验证装置，所述装置包括：
13.匹配单元，用于接收第一客户端发送的验证请求，为所述第一客户端匹配交互端；
14.确定单元，用于将所述第一客户端和所述交互端中的一个确定为讲述端，另一个确定为倾听端；
15.第一处理单元，用于接收所述讲述端发送的验证问题，并将所述验证问题发送给所述倾听端；
16.第二处理单元，用于接收所述倾听端发送的第一验证答案，所述第一验证答案为所述倾听端接收到的针对所述验证问题的答案；
17.判定单元，用于根据所述验证问题以及所述第一验证答案判定所述第一客户端是
否验证成功。
18.第三方面，本技术还提供了一种电子设备，包括：
19.处理器；以及
20.存储器，用于存储数据处理程序，该电子设备通电并通过所述处理器运行该程序后，执行如第一方面任一项所述的方法。
21.第四方面，本技术实施例还提供了一种计算机可读存储介质，存储有数据处理程序，该程序被处理器运行，执行如第一方面任一项所述的方法。
22.与现有技术相比，本技术具有以下优点：
23.本技术提供的验证方法，服务端为进行验证的第一客户端匹配交互端，从第一客户端和交互端中确定讲述端、倾听端，本技术实施例通过讲述端输入验证问题，并将讲述端输入的验证问题发送给倾听端，之后倾听端基于验证问题回答第一验证答案，并将第一验证答案发送给服务端，服务端根据第一验证答案来判断第一客户端是否验证成功。本技术实施例提供的验证方法使得倾听端和讲述端进行了良好的互动，通过讲述端和倾听端之间进行的交互验证来判断第一客户端是否验证成功。
24.可见，本技术提供的验证方法，为进行验证的第一客户端匹配交互端，其中一端输入验证问题，另一端回答验证答案来进行验证，通过第一客户端和交互端之间交互验证增加了验证过程的趣味性，提升了用户对验证方法的感兴趣程度，进而提升了用户体验。
25.另外，本技术提供的验证方法，可以锻炼用户的沟通能力，并且视障用户也可以基于本技术提供的验证方法进行验证，提升了验证方法对用户的友好程度。
附图说明
26.图1是本技术实施例提供的验证方法的应用场景的架构图；
27.图2是本技术实施例提供的验证方法的应用场景的流程图；
28.图3是本技术实施例提供的验证方法的流程图；
29.图4是本技术实施例提供的验证方法的具体细节示意图；
30.图5是本技术实施例提供的验证方法的客户端示意图；
31.图6是本技术实施例提供的验证装置的一例的结构框图；
32.图7是本技术实施例提供的电子设备的一例的结构框图。
具体实施方式
33.在下面的描述中阐述了很多具体细节以便于充分理解本技术。但是本技术能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本技术内涵的情况下做类似推广，因此本技术不受下面公开的具体实施的限制。
34.随着计算机和互联网技术的不断发展，越来越多的用户在互联网上进行信息交互，如：网络购物、即时聊天、在线游戏、浏览各大网站、登录各种应用、观看视频等。为了保障网络信息安全，用户在进行网络信息交互时，往往会进行验证。进行验证时通常是输入验证码，验证码是一种区分用户是计算机还是人的公共全自动程序，可以有效防止某个黑客对某一个特定注册用户用特定程序暴力破解方式进行不断的登陆尝试。
35.相关技术中，在进行验证时，会出现一张验证图片，验证图片上有对应的字符，如：
中文、英文以及数字，用户需要识别验证图片上的字符并输入到验证框，系统将会对用户输入的字符进行验证，若与验证图片上的字符一致，则验证成功。
36.或者，展示分割为滑块和缺口的验证图片，此时，滑块和缺口处于显示屏上的不同位置，用户根据提示将滑块拖动到缺口的位置来进行验证，系统获取滑块与缺口之间的距离，若二者之间的距离小于预设阈值，则验证成功。
37.然而，在实际应用中，用户根据验证图片中的字符输入验证码往往并不需要付出脑力劳动，只需要根据肉眼识别出来的字符进行机械的输入，导致验证过程枯燥乏味，使得用户对验证方法失去兴趣，降低了用户体验。
38.基于上述原因，为了增加验证过程的趣味性，提升用户对验证方法的感兴趣程度，本技术第一实施例提供了一种验证方法，该方法应用于电子设备，该电子设备可以是台式电脑、笔记本电脑、手机、平板电脑、服务器、终端设备等，也可以是其他能够进行数据统计的电子设备，本技术实施例不具体限定。
39.为了更清楚地展示本技术，以下介绍本技术实施例中提供的验证方法的应用场景。如图1所示，是本技术实施例提供的验证方法的应用场景的架构图，包括：第一客户端101和交互端，其中，交互端可以是服务端102或第二客户端103。第一客户端101包括但不限于：手机、电脑、pad以及便携终端等，服务端102可以指为客户端提供计算、存储等功能的服务端，包括服务器。第二客户端103包括但不限于：手机、电脑、pad以及便携终端等，第一客户端101、服务端102以及第二客户端103之间通过通信网络相互连接，通信网络可以包含移动网络、网关、因特网，也可以由局域网、因特网组成。
40.如图2所示，是本技术实施例提供的验证方法的应用场景的流程图，其中，讲述端为第一客户端和交互端中的一端，倾听端为另一端，在该场景中，验证方法为使用验证码进行验证。本技术提供的应用场景包括如下步骤：步骤s101：第一客户端向服务端发送验证请求；步骤s102：服务端为第一客户端匹配交互端；步骤s103：服务端将第一客户端和交互端中的一个确定为讲述端，另一个确定为倾听端；步骤s104：讲述端向服务端发送验证问题；步骤s105：服务端将验证问题发送给倾听端；步骤s106：倾听端基于验证问题发送验证答案；步骤s107：服务端根据验证答案判断第一客户端是否验证成功。
41.以一种游戏应用作为本技术实施例提供的验证方法的应用场景的示例，在用户a登录该游戏时，向服务端发送验证请求，服务端接收到验证请求后在10秒内为用户a匹配用户b，用户b为10秒内也需要登录该游戏的用户，若超过10秒未匹配到到用户b，则服务端为用户a分配智能机器人c。当用户a与用户b匹配时，随机分配用户a和用户b中的一个为讲述端，另一个为倾听端；当用户a与智能机器人c匹配时，机器人c为讲述端，用户a为倾听端。讲述端向服务端发送验证答案、讲述内容以及验证问题，服务端将讲述内容以及验证问题实时发送给倾听端，倾听端根据验证问题以及讲述内容输入第一验证答案，并发送给服务端，服务端对比第一验证答案和验证答案，当两者一致时，用户a和用户b验证成功，即验证请求验证通过，用户a和用户b都可以成功登录该游戏。
42.可以理解的，上述应用场景示例仅仅是本技术实施例提供的验证方法的一个应用场景实施例，提供这个应用场景实施例的目的是便于理解本技术提供的验证方法，而并非用于限定本技术提供的方法。具体涉及到的方法介绍，请参照以下实施例。
43.以下结合图3和图4对本技术第一实施例提供的验证方法进行详细说明。
44.图3是本技术第一实施例提供的验证方法的流程图。图4是本技术第一实施例提供的验证方法的具体细节流程图。
45.如图3所示，本技术提供的验证方法包括以下步骤301～步骤305。
46.步骤301：接收第一客户端发送的验证请求，为所述第一客户端匹配交互端。
47.本技术实施例中，在第一客户端的用户进行网络信息交互时，如图2所示，第一客户端可以向服务端发送验证请求，服务端可以为第一客户端匹配交互端，通过交互验证的方式进行验证，第一客户端为当前时刻还未成功匹配到交互端的客户端，交互端是用来和第一客户端进行交互以使得第一客户端完成验证，交互端可以是与第一客户端处于相同状态的客户端，即所匹配的交互端可以是发送了验证请求，且当前时刻还未匹配到交互端的客户端。验证请求可以是针对手机端的应用、小程序、电脑端的网站等，本技术实施例不具体限定。
48.作为一种实施方式，在第一客户端的用户进行验证时，还可以向自己的好友发送邀请，以使好友所对应的另一客户端作为第一客户端的交互端，与第一客户端进行交互验证。此时，第一客户端界面可以显示邀请好友进行验证相关信息的控件，用户可以通过点击该控件来邀请好友，在好友成功响应后与用户进行交互验证，具体的，用户点击该控件可以将邀请消息通过验证方法对应的应用发送给好友，还可以将邀请消息分享到第三方即时聊天软件。在实际应用中，服务端还可以从第一客户端在验证方法对应的应用上的好友中，筛选已经成功登录该应用的好友发送帮忙进行验证的消息，将最快确认帮忙验证的好友匹配为第一客户端的交互端。通过这一步骤，快速的为进行验证的第一客户端匹配到了可以与之进行交互验证的交互端。
49.步骤302：将所述第一客户端和所述交互端中的一个确定为讲述端，另一个确定为倾听端。
50.图3中的步骤s302即图2中的步骤s103。
51.可以理解的，验证方法中包含了验证问题，以及相应的验证答案，在成功匹配到交互端后，第一客户端与交互端进行交互验证时，可以从第一客户端与交互端中确定出谁是提出验证问题的一方，即本技术中的讲述端，谁是基于验证问题回答验证答案的一方，即本技术中的倾听端。
52.在具体实施方式中，服务端可以储存有所有已经进行验证过的客户端成为讲述端的次数以及成为倾听端的次数这一历史数据，在某一客户端进行验证时，根据其历史数据来确定该客户端成为讲述端还是成为倾听端，具体为计算成为讲述端次数与成为倾听端次数的比值，比值大的一端可以认为更愿意成为讲述端，将比值大的一端确定为讲述端，比值小的一端确定为倾听端。如客户端a成为讲述端的次数为200，成为倾听端的次数为20，成为讲述端次数与成为倾听端次数的比值为10，与客户端a匹配成功的交互端为客户端b，客户端b成为讲述端的次数为200，成为倾听端的次数为50，成为讲述端次数与成为倾听端次数的比值为4，则将客户端a确定为讲述端，将交互端b确定为倾听端。通过这一技术手段，可以快速将匹配到的第一客户端与交互端确定为两者更擅长的角色。
53.步骤303：接收所述讲述端发送的验证问题，并将所述验证问题发送给所述倾听端。
54.本技术实施例中，讲述端可以向服务端发送验证问题。服务端接收到该验证问题
后，可以向倾听端发送该验证问题。讲述端发送的验证问题可以是讲述端的用户临场发挥的验证问题，也可以为讲述端提前存储在电子设备上的验证问题，如已经录入并保存在手机上的验证问题，还可以是服务端提供的预设验证问题，其中，预设验证问题可以按照预设周期更新。验证问题为语音形式的数据或者文本形式的数据，具体的，讲述端可以直接输入语音形式的验证问题，也可以输入文本形式的验证问题，当讲述端输入语音形式的验证问题并发送给服务端时，服务端可以识别语音形式的验证问题的数据，并将其转换为文本形式的验问题。
55.讲述端可以通过讲述端界面的输入框输入验证问题，也可以点击讲述端界面的上传控件上传已经提前储存在电子设备上的验证问题，讲述端还可以输入文本形式的验证问题，可以通过键盘/虚拟键盘打字，也可以直接在显示屏上进行手写输入。验证问题的形式可以为数学运算、歇后语接龙、歌曲名称、歌手名称、影视剧名称、地理知识、历史知识等，因此在为第一客户端进行匹配交互端之前，可以将进行验证的用户进行兴趣爱好的划分，服务端可以根据用户的兴趣爱好，为第一客户端的用户匹配与之爱好相同的用户作为交互端。可以理解的，服务端可以将讲述端发送的音频形式的验证问题实时的发送给倾听端，为了使得倾听端的用户能够听懂验证问题，可以将用户进行区域的划分，为用户匹配同一区域的用户，这样，在讲述端的用户使用地方方言实时发送验证问题时，倾听端也可以很容易的听懂。此外，将用户按照区域划分，同一地区的用户之间进行交互式验证还可以有效解决验证过程中数据传输慢的问题。
56.作为一种实施方式，在进行验证之前，用户还可以在客户端界面选择自己更感兴趣的验证类型，此时，客户端界面可以包含有影视剧、歌曲、歌手、数学运算、歇后语接龙、地理、历史等验证类型，用户可以自己选择想进行哪一种类的验证。如表1所示，是验证类型和讲述端发送的验证问题示例表，当用户选择的验证类型是地理时，讲述端可以发送“世界第一大高峰是什么”等地理问题。表1仅为本技术实施例提供的一种示例表，并非用于限定本技术提供的方法。
57.表1.验证类型和讲述端发送的验证问题示例表
[0058][0059]
步骤304：接收所述倾听端发送的第一验证答案。
[0060]
所述第一验证答案为所述倾听端接收到的针对所述验证问题的答案。
[0061]
步骤304即图2中的步骤s106。
[0062]
倾听端接收到的验证问题可以是音频形式的验证问题，也可以是文本形式的验证问题，倾听端所发送的第一验证答案可以是音频形式的第一验证答案，也可以是文本形式的第一验证答案。倾听端的用户可以点击指示语音录入的控件录入语音形式的第一验证答案，也可以手动输入文本形式的第一验证答案，当服务端接收到的是语音形式的第一验证答案时，可以将其转换为文本形式的第一验证答案，储存至服务端。
[0063]
可以理解的，倾听端接收到的针对所述验证问题的第一验证答案可以是倾听端的
用户根据接收到的验证问题所输入的答案，即第一验证答案是由用户主观得到的，因此，倾听端输入的第一验证答案可能是正确的，也可能是错误的，此时，可以根据第一验证答案来判断第一客户端是否验证成功。
[0064]
步骤305：根据所述第一验证答案判定所述第一客户端是否验证成功。
[0065]
步骤305即图2中的步骤s107。
[0066]
可以理解的，当第一验证答案为文本形式的数据时，可以直接根据第一验证答案的正确性判断第一客户端是否验证成功，当第一验证答案正确时，判定第一客户端验证成功。当第一验证答案为语音形式的数据时，可以判断该语音形式的第一验证答案是否为真人语音，当为真人语音时，判断第一验证答案是否正确，当第一验证答案正确时，判定第一客户端验证成功。
[0067]
具体的，本技术实施例可以通过服务端设定的合成语音识别模型来识别语音形式的第一验证答案是否为真人语音，合成语音识别模型内包含有已经收集并提取到的合成语音的音色特征，当服务端接收到语音形式的第一验证答案时，提取第一验证答案的音色特征，并输入到合成语音识别模型，若检测到有相同的音色特征，则说明该语音形式的第一验证答案来自合成的智能机器人语音，反之，则为真人语音。本技术实施例也可以通过训练好的语音判别模型判别语音形式的第一验证答案是真人语音还是合成的智能机器人语音，语音判别模型的训练过程为，输入大量的样本真人语音，样本真人语音可以通过互联网下载已有的真人语音，提取样本真人语音的语速特征和语言风格特征，生成真人语音特征集，且服务端的语音判别模型处于持续学习的状态，即真人语音特征集也在持续不断的更新。当服务端接收到语音形式的第一验证答案时，提取第一验证答案的语速特征和语言风格特征，并输入到语音判别模型，若第一验证答案的语速特征和语言风格特征包含在真人语音特征集内，则说明该语音形式的第一验证答案来自真人语音，反之，则为合成的智能机器人语音。
[0068]
作为一种实施方式，讲述端发送的验证问题可以是服务端提供的预设验证问题，此时，服务端也会储存有相应的正确验证答案(验证问题的正确答案)，服务端可以根据已储存的正确验证答案，判断第一验证答案是否与正确验证答案一致，若一致，则第一客户端验证成功。讲述端发送的验证问题还可以是讲述端临场发挥的问题，此时，服务端可以实时识别验证问题，并从验证问题库进行检索，若检索到相同的问题，从答案库中提取出正确答案，将第一验证答案和正确答案进行对比，若一致，可以判定第一客户端验证成功。具体的，验证问题库和答案库为预先设置好的验证问题对应的答案库，在每个讲述端用户发送完验证问题后，服务端都会实时检测该验证问题是否存在验证问题库中，若不存在，则将该验证问题和对应的答案分别储存到验证问题库和答案库，并建立对应关系。
[0069]
可以理解的，服务端还可以将倾听端发送的第一验证答案发送到讲述端，由讲述端的用户判断第一验证答案是否正确，并将判断结果发送到服务端，当判断结果为第一验证答案正确时，服务端可以判定第一客户端验证成功。在这种情况下，讲述端界面可以显示确认验证答案正确和确认验证答案错误的控件，当讲述端的用户点击了确认验证答案正确控件，表示倾听端发送的第一验证答案为正确的。在验证问题是由讲述端的用户临场发挥发送到服务端的情况下，讲述端在发送验证问题时，已经知晓正确验证答案，因此，讲述端在接收到服务端发送的倾听端输入的第一验证答案时，可以第一时间判断出第一验证答案
是否正确。通过这一技术手段使得本技术实施例提供的验证方法的互动性更强，且服务端能够更加高效的判定第一客户端是否验证成功。
[0070]
在具体实施中，若第一客户端匹配到的交互端也是需要验证的客户端，即讲述端的用户和倾听端的用户都为真实的用户，当判定第一验证答案正确，第一客户端验证成功时，交互端也验证成功。
[0071]
如表2所示，是本技术实施例提供的验证类型、验证问题、第一验证答案以及验证结果示例表，是倾听端基于表1中的验证问题发送的第一验证答案，以及根据第一验证答案得出的验证结果，验证问题从左往右对应的正确验证答案分别是：珠穆朗玛峰、1914年、213、一去不回头，因此，关于验证问题“第一次世界大战是什么时候爆发的”所对应的第一验证答案与正确验证答案不一致，可以由服务端通过检索验证问题以及对应的正确验证答案，判定第一客户端验证失败，也可以由讲述端确认第一验证答案错误，并将确认结果发送到服务端，服务端基于讲述端发送的确认结果判定第一客户端验证失败。
[0072]
表2.验证类型、验证问题、第一验证答案以及验证结果示例表
[0073][0074]
可以理解的，在服务端根据第一验证答案和检索到的正确验证答案判定第一客户端是否验证成功时，由于第一验证答案是由倾听端的用户主观输入的，第一验证答案跟用户的回答习惯有着直接关系，会出现第一验证答案和正确验证答案并不完全相同的情况，因此，还可以根据第一验证答案和正确验证答案的关联度来判断第一验证答案是否正确，当第一验证答案包含或者包含于正确验证答案时，可以认为第一验证答案是正确的，判定第一客户端验证成功。
[0075]
如表3所示，是本技术实施例提供的验证类型、验证问题、第一验证答案以及验证结果另一示例表。由表可知，第一验证答案“珠穆朗玛”包含于对应的正确验证答案“珠穆朗玛峰”，第一验证答案“1914”包含于对应的正确验证答案“1914年”，第一验证答案“213”和对应的正确验证答案“213”完全相同，第一验证答案“肉包子打狗，一去不回头”包含对应的正确验证答案“一去不回头”，基于此，可以判定表3中第一验证答案均为正确的，因此，第一客户端均验证成功。
[0076]
表3.验证类型、验证问题、第一验证答案以及验证结果另一示例表
[0077][0078]
步骤305中，服务端确定出第一客户端的验证结果后，可以将验证结果发送至第一客户端，使得第一客户端的用户及时得知自己是否验证成功。
[0079]
本技术提供的验证方法，服务端为进行验证的第一客户端匹配交互端，从第一客户端和交互端中确定讲述端、倾听端，本技术实施例通过讲述端输入验证问题，并将讲述端输入的验证问题发送给倾听端，之后倾听端基于验证问题回答第一验证答案，并将第一验证答案发送给服务端，服务端根据第一验证答案来判断第一客户端是否验证成功。本技术实施例提供的验证方法使得倾听端和讲述端进行了良好的互动，通过讲述端和倾听端之间进行的交互验证来判断第一客户端是否验证成功。
[0080]
可见，本技术提供的验证方法，为进行验证的第一客户端匹配交互端，其中一端输入验证问题，另一端回答验证答案来进行验证，通过第一客户端和交互端之间交互验证增加了验证过程的趣味性，提升了用户对验证方法的感兴趣程度，进而提升了用户体验。
[0081]
另外，本技术提供的验证方法，可以锻炼用户的沟通能力，并且视障用户也可以基于本技术提供的验证方法进行验证，提升了验证方法对用户的友好程度。
[0082]
可选的，步骤301还包括图4中的步骤401和步骤402。
[0083]
步骤401：查找在距离当前时刻预设时长的时间段内发送了验证请求、且未匹配交互端的第二客户端，若查找到所述第二客户端，将所述第二客户端确定为与所述第一客户端匹配的交互端。
[0084]
可以理解的，在接收到第一客户端发送的验证请求后，首先为第一客户端匹配进行验证的第二客户端，这样，匹配两个真实用户进行交互验证，可以在验证成功时，两个用户都能完成验证并成功登录应用。但，实际应用中，在第一客户端进行验证时，可能会出现该时刻没有发送验证请求或者不存在未匹配交互端的第二客户端的情况，因此，在步骤401中，可以设定一个预设时长，查找在距离当前时刻预设时长的时间段的第二客户端，第二客户端为发送了验证请求，且未匹配交互端的客户端。具体的，可以查找在当前时刻之前预设时长的时间段内发送验证请求，待匹配交互端的第二客户端，也可以查找在当前时刻之后预设时长的时间段内发送验证请求，待匹配交互端的第二客户端，若查找到第二客户端，则将第二客户端确定为第一客户端的交互端。
[0085]
进一步地，服务端还可以设定一个预设查找时长，在距离当前时刻预设查找时长的时间段内，为第一客户端查找第二客户端。通常情况下，预设查找时长等于预设时长。具体的，若在距离当前时刻之前预设时长的时间段内存在第二客户端，则在接收到第一客户
端发送的验证请求时，第一时间查找到第二客户端，若在距离当前时刻之后预设时长的时间段内最后一秒查找到第二客户端，则在接收到第一客户端发送的验证请求后，查找到第二客户端时的查找时长为预设时长。
[0086]
在具体实施方式中，当第一客户端匹配交互端时，可能会查找到多个发送了验证请求、且未匹配交互端的第二客户端，此时，可以从多个第二客户端中选择与第一客户端当前地理距离最近的目标客户端作为第一客户端的交互端。其中，可以通过定位系统，例如全球定位系统(global positioning system，gps)或北斗卫星导航系统确定第一客户端及多个第二客户端的空间位置，进而基于第一客户端及多个第二客户端的空间位置，分别确定多个第二客户端与第一客户端的当前地理距离。或者从多个第二客户端中随机选择一个第二客户端作为第一客户端的交互端，以提高交互验证匹配的时效性或灵活性。
[0087]
示例性的，服务端可以预先设定10秒为预设时长，10秒为查找时长，在08：50接收到第一客户端发送的验证获取请求时，查找在08：40到08：50之间发送验证请求，待匹配交互端的第二客户端，或者在08：50到09：00之间发送验证请求，待匹配交互端的第二客户端，并在第一客户端界面显示正在匹配的信息以及匹配倒计时的信息，匹配倒计时为：10s、9s
……
0s，若第5秒即08：55时，匹配到第二客户端，则第一客户端和第二客户端都显示匹配成功的信息。通过这一技术手段能够及时为发送验证请求的客户端匹配同样发送了验证请求的客户端，并且使得第一客户端能够明确匹配第二客户端的进度。
[0088]
步骤402：若未查找到所述第二客户端，将所述服务端确定为与所述第一客户端匹配的交互端。
[0089]
作为一种实施方式，当没有查找到在距离当前时刻预设时长的时间段内发送验证请求、且未匹配交互端的第二客户端时，服务端可以作为第一客户端的交互端，与第一客户端进行交互，使得第一客户端能够进行验证。服务端可以设置智能机器模型，即智能机器人，智能机器人可以是合成的虚拟角色，包括男性女性或者老人小孩成年人等。可以理解的，在未查找到第二客户端时，服务端还可以向已经验证成功完成登录的第一客户端的好友发送协助验证的消息，若好友同意协助验证，则将好友确定为第一客户端的交互端，若好友不同意协助验证，则继续将机器人确定为交互端。
[0090]
通过这一技术手段，能够优先为第一客户端匹配到第二客户端，并且在未匹配到第二客户端时及时为第一客户端分配智能机器人作为交互端，并且避免第一客户端因为匹配交互端时间过长而失去进行验证的兴趣。
[0091]
可选的，步骤302可以按照图4中的步骤403和步骤404实现。
[0092]
步骤403：若所述交互端为所述第二客户端，将所述第一客户端和所述第二客户端中的一个确定为讲述端，另一个确定为倾听端。
[0093]
步骤404：若所述交互端为所述服务端，将所述服务端确定为讲述端，将所述第一客户端确定为倾听端。
[0094]
在步骤403中，若交互端为第二客户端时，服务端可以从第一客户端和第二客户端中随机确定出讲述端和倾听端。也可以如步骤302中所言，统计第一客户端和第二客户端的历史数据，计算各自作为讲述端的次数与作为倾听端的次数的比值，将比值高的一端确定为讲述端，另一端确定为倾听端。
[0095]
在步骤404中，若交互端为服务端时，由于智能机器人不具备主观思考的能力，不
能基于验证问题得到验证答案，因此在这种情况下，可以将服务端确定为讲述端，第一客户端确定为倾听端。此时，智能机器人发送的验证问题可以是服务端提供的预设验证问题，第一客户端作为倾听端基于服务端的智能机器人发送的验证问题得到第一验证答案，其中，预设验证问题可以按照预设周期更换。
[0096]
可选的，步骤403还可以包括以下至少一个步骤：
[0097]
步骤403-1：接收所述第一客户端与所述第二客户端发送的成为第一端的选择信息，将所述第一客户端和所述第二客户端中发送所述选择信息时刻较早的客户端确定为所述第一端，将所述第一客户端和所述第二客户端中除所述第一端以外的另一客户端确定为第二端。
[0098]
步骤403-2：接收所述第一客户端发送的成为第一端的选择信息、所述第二客户端发送的成为第二端的选择信息，将所述第一客户端确定为所述第一端，将所述第二客户端确定为所述第二端。
[0099]
其中，所述第一端为所述讲述端，所述第二端为所述倾听端；或所述第一端为所述倾听端，所述第二端为所述讲述端。
[0100]
作为一种实施方式，当为第一客户端匹配到的交互端为第二客户端时，在从第一客户端和第二客户端中确定讲述端、倾听端时，可以根据第一客户端和第二客户端对应的用户的喜好进行确定。具体的，在匹配到两个客户端进行交互验证时，在客户端界面可以显示成为讲述端和成为倾听端控件，若用户在进行验证时，想成为发送验证问题的一方，则该用户可以点击成为讲述端控件，并发送给服务端，若用户在进行验证时，想成为基于验证问题回答验证答案的一方，则该用户可以点击成为倾听端控件，并发送给服务端。
[0101]
在具体实施中，可能出现第一客户端和第二客户端都想成为讲述端或者都想成为倾听端的情况，此时，将第一客户端和第二客户端中最早选择成为讲述端的一方确定为讲述端，另一端确定为倾听端，或者将第一客户端和第二客户端中最早选择成为倾听端的一方确定为倾听端，另一端确定为讲述端。此外，也可能出现第一客户端和第二客户端中一方想成为倾听端，另一方想成为讲述端的情况，则按照两者的选择来确定第一客户端和第二客户端的角色。
[0102]
可以理解的，在实际应用中，在第一客户端和第二客户端中任一客户端先发送成为第一端的消息后，另一客户端的显示界面上的成为讲述端和成为倾听端对应的控件变为灰色控件，不可进行点击。换言之，服务端在接收到任一客户端发送的成为第一端的消息时，另一端无需进行选择，服务端可以将其确定为第二端。
[0103]
通过这种方式，将第一客户端和第二客户端能够按照对应用户的喜好来确定讲述端和倾听端，提升了用户对于本技术提供的验证方法的好感度和满意度。
[0104]
可选的，步骤403还可以按照以下步骤实现：
[0105]
步骤403-3：接收第一端发送的角色互换请求，向第二端发送角色互换信息。
[0106]
步骤403-4：接收所述第二端发送的同意更换的消息，将所述第一端与所述第二端进行角色交换，所述角色交换为将倾听端与讲述端进行互换。
[0107]
可以理解的，第一客户端的用户和第二客户端的用户可能存在都想成为讲述端的情况，假设第一客户端在交互验证时，较快选择了成为讲述端，则第二客户端就被确定为了倾听端，而第二客户端的用户也想成为讲述端，此时，第二客户端的用户可以发送角色互换
请求，用以请求和第一客户端互换角色，当第一客户端的用户发送了同意更换的反馈消息后，第二客户端将成为讲述端，第一客户端成为倾听端。
[0108]
此外，用户还可以在第二客户端上触发重新匹配交互端的指令，服务端为第二客户端匹配交互端，第二客户端与新匹配的交互端在进行交互验证时，第二客户端的用户可以尽快选择成为讲述端，若在第二客户端的用户选择成为讲述端之前，新匹配的交互端的用户已经优先选择了成为讲述端，此时第二客户端最终被确定为倾听端。
[0109]
进一步地，服务端可以限制重新匹配的次数，例如可以设置用户不满意角色(讲述端或倾听端)分配时有3次重新匹配的机会，在用户第三次重新匹配后，确定的角色即为该客户端的最终角色。第一客户端和第二客户端都想成为倾听端的情况与都想成为讲述端的情况类似，此处不予赘述。
[0110]
通过这一技术方案，使得第一客户端和第二客户端可以进行角色的交换，增加了验证过程的乐趣。此外，客户端还可以重新匹配交互端以重新选择心仪角色，使得验证过程更加人性化，更加友好。
[0111]
可选的，当交互端为第二客户端时，在步骤304之前，还可以进行图4中的步骤405。
[0112]
步骤405：接收讲述端发送的验证答案。
[0113]
验证答案为验证问题的预设答案。
[0114]
作为一种实施方式，当第一客户端匹配的交互端为第二客户端时，在倾听端发送第一验证答案之前，讲述端可以向服务端发送验证答案，验证答案是讲述端的用户在提供验证问题时，就已经知晓的验证答案。具体的，当验证问题是讲述端临场发挥提供的，验证答案为讲述端的用户自身提供的；当验证问题为服务端提供的预设验证问题，验证答案可以由讲述端的用户基于预设验证问题得到验证答案，也可以由服务端在提供预设验证问题时，同时提供对应的正确验证答案，并将正确验证答案发送给讲述端，由讲述端的用户基于正确验证答案输入验证答案。
[0115]
相应的，与验证问题的数据形式一样，输入讲述端的验证答案可以是语音形式的数据，也可以是文本形式的数据，当讲述端发送的验证答案为语音形式的数据时，服务端可以识别并将其转换为文本形式的验证答案。
[0116]
可选的，步骤305可以按照图4中的步骤411来实现。
[0117]
步骤411：根据所述第一验证答案与所述验证答案是否一致判定所述第一客户端是否验证成功。
[0118]
可以理解的，在服务端接收到验证答案时，可以判断倾听端输入的第一验证答案和讲述端输入的验证答案是否一致，若两者一致，可以认为第一客户端验证成功。
[0119]
进一步地，当交互端为第二客户端时，还可以根据第一验证答案与验证答案是否一致判定第二客户端是否验证成功。换言之，交互验证的过程中，若交互端为第二客户端，由于第二客户端也为发送验证请求的客户端，第二客户端可能为讲述端，也可能为倾听端，可以基于第一验证答案与验证答案是否一致来判断第二客户端是否验证成功。判定方法与第一客户端是否验证成功的判定方法类似，此处不予赘述。
[0120]
通过这一技术手段，讲述端在提供验证问题的基础上还提供了验证答案，使得服务端能够基于讲述端提供的验证答案来判断第一验证答案是否正确，进而判断第一客户端是否验证成功，通过倾听端和讲述端的交互来进行验证，提升了验证过程的趣味性。
[0121]
可选的，上述验证方法还可以包括图4中的步骤412～步骤414。
[0122]
步骤412：当检测到所述第一验证答案错误时，向所述倾听端发送重新输入验证答案的信息，并接收所述倾听端重新发送的第一验证答案。
[0123]
步骤413：当检测到所述第一验证答案的错误次数达到第一预设次数时，向所述倾听端发送所述验证答案。
[0124]
步骤414：接收所述倾听端发送的第二验证答案，所述第二验证答案为用户基于所述验证答案输入所述倾听端的内容。
[0125]
根据所述第二验证答案判定所述第一客户端是否验证成功。
[0126]
可以理解的，在实际应用中，倾听端基于验证问题并不能确定唯一的正确答案，可能会想要输入好几个第一验证答案，当输入第一个验证答案后，该第一验证答案可能与正确验证答案不符，即该第一验证答案是错误的，在这种情况下若直接判定第一客户端验证失败，会使得验证过程对用户的友好程度降低，久而久之，用户可能会出现对验证方法失去兴趣的情况。因此，可以在检测到倾听端发送的第一验证答案错误时，倾听端有机会再重新输入第一验证答案进行验证，服务端可以设定第一预设次数x，x大于等于1，第一预设次数为倾听端输入第一验证答案的限制次数，即倾听端最多可以输入x次第一验证答案。示例性的，服务端可以设定第一预设次数3，在第一次检测到倾听端发送的第一验证答案错误时，倾听端还有2次机会重新输入第一验证答案。
[0127]
作为一种实施方式，当检测到第一验证答案的错误次数达到第一预设次数包括如下两种情况。情况一：讲述端提供的验证答案为正确的验证答案，倾听端的用户在第一预设次数内输入的第一验证答案一直是错误的。情况二：讲述端提供的验证答案是错误的，导致倾听端无论输入的是正确的第一验证答案还是错误的第一验证答案，均与讲述端所输入的验证答案不一致，此时，到第一预设次数时，系统根据错误的验证答案还是判定倾听端输入的第一验证答案为错误的。若直接判定第一客户端验证失败对用户不够友好，久而久之，也会降低用户对验证方法的好感度，使得用户对验证方法失去兴趣。
[0128]
因此，可以在检测到第一验证答案的错误次数达到第一预设次数时，向倾听端发送验证答案，倾听端基于验证答案输入第二验证答案。换言之，在第一验证答案的错误次数达到一定次数时，可以再给倾听端一次输入验证答案的机会，此时向倾听端展示验证答案，倾听端接收到的验证答案可以是语音形式的数据，也可以是文本形式的数据，倾听端的用户基于听到的或者看到的验证答案输入第二验证答案。相应的，第二验证答案也可以是语音形式的数据或者文本形式的数据，当第二验证答案为语音形式的数据时，服务端可以将其转换为文本形式的数据方便后续的对比。
[0129]
之后，再根据第二验证答案判断第一客户端是否验证成功，其判断方法与步骤305中根据第一验证答案判断第一客户端是否验证成功类似，此处不予赘述。
[0130]
进一步地，当倾听端在接收到服务端发送的验证答案，发现由讲述端提供的验证答案为错误答案时，可以发送正确验证答案和反馈信息用以指示验证答案错误，接收到倾听端发送的反馈信息时，服务端可以将反馈信息发送到讲述端，再由讲述端进行确认，并重新输入替换验证答案，接收讲述端发送的替换验证答案，根据替换验证答案和正确验证答案是否一致判定第一客户端是否验证成功。
[0131]
通过这一技术手段，可以在第一次验证失败时，倾听端有机会进行重新验证，使得
本技术提供的验证方法更加人性化，并且用户基于本技术提供的验证方法大概率会通过验证，提升了验证过程的友好程度。
[0132]
或者，在步骤412倾听端重新发送第一验证答案之后，本技术实施例提供的验证方法还可以进行以下步骤：
[0133]
当检测到所述第一验证答案的错误次数到达第二预设次数时，向所述讲述端发送自行验证的提示信息。
[0134]
接收所述讲述端发送的第三验证答案，当检测到所述第三验证答案正确时，判定所述第一客户端与所述第二客户端中的所述讲述端验证成功。
[0135]
作为一种实施方式，还可能出现倾听端第一验证答案在输入好几次都验证错误，讲述端在发送完验证问题后，需要等待较长的时间，直到第一验证答案正确后才能完成验证，甚至于最终第一验证答案错误导致验证失败。此时，若由于倾听端的原因导致讲述端无法很快验证成功，会使得讲述端的用户对验证方法的好感度大大降低。因此服务端还可以设定第二预设次数，在检测到第一验证答案的错误次数达到第二预设次数时，服务端可以发送消息用以提示讲述端可以自行验证。
[0136]
具体的，讲述端在接收到自行验证的提示消息后，可以在讲述端输入第三验证答案，当验证问题为服务端提供的预设验证问题时，讲述端基于预设验证问题得出第三验证答案，并输入服务端，此时服务端存储有对应的正确答案，可以将第三验证答案与正确答案进行对比，若一致，则第三验证答案正确。当验证问题为讲述端的用户自身提供的，可以将第三验证答案与步骤405中讲述端发送的验证答案进行对比，若一致，则第三验证答案正确。当第三验证答案正确时，讲述端验证成功登录应用，并退出验证过程，倾听端可以接着进行验证直到验证成功，当然倾听端还可以重新匹配交互端，以进行验证。
[0137]
此外，倾听端在接收到验证问题时，可能长时间不发送第一验证答案，因此服务端可以设定一个回答时长，当倾听端超过回答时长未发送第一验证答案时，也可以认为第一验证答案错误。
[0138]
通过这一技术手段，可以在讲述端为客户端时，当发送验证问题后，能够及时完成验证，提高了讲述端验证的效率。
[0139]
又或者，在步骤412倾听端重新发送第一验证答案之后，本技术实施例提供的验证方法还可以包括以下步骤：
[0140]
当检测到所述第一验证答案错误的次数到达第三预设次数时，向所述讲述端发送重新匹配交互端的提示信息。
[0141]
接收所述讲述端发送的重新匹配交互端的请求，为所述讲述端重新匹配发送验证请求、且未匹配交互端的第三客户端作为倾听端。
[0142]
将所述讲述端发送的所述验证问题发送给所述第三客户端以进行验证。
[0143]
作为一种实施方式，服务端还可以预设第三预设次数，在第一验证答案错误次数达到第三预设次数时，服务端可以向讲述端发送消息用以提示讲述端可以重新匹配交互端，讲述端匹配交互端的过程与第一客户端匹配交互端的方法类似，此处不予赘述。
[0144]
在匹配到第三客户端为讲述端的交互端时，将第三客户端作为倾听端，服务端可以将讲述端之前发送的验证问题发送给第三客户端进行验证，不需要讲述端重新输入验证问题等相关的验证信息，之后的过程与第一客户端和第二客户端的验证过程类似，此处不
予赘述。
[0145]
通过这一技术手段，可以在一定次数验证失败后，重新为讲述端匹配倾听端进行验证，并且不需要讲述端再重新输入验证问题，使得验证方法更为灵活。
[0146]
可选的，在步骤303之前，还可以进行图4中的步骤406。
[0147]
步骤406：接收所述讲述端发送的讲述内容，并将所述讲述内容发送给所述倾听端。
[0148]
其中，所述讲述内容用于推导出所述验证问题对应的答案。
[0149]
可以理解的，为了增加验证过程的趣味性，本技术实施例中，讲述端还可以向服务端发送讲述内容，讲述内容可以为一个故事，一段歌曲，一段影视剧经典台词，在讲述端发送完讲述内容后，再发送验证问题，验证问题为与讲述内容相关联的问题。相应的，与验证问题和验证答案的数据形式一样，讲述内容既可以为语音形式的数据，也可以为文本形式的数据，此处不予赘述。在具体实施方式中，服务端可以设置最小讲述时长和最大讲述时长，录入的讲述内容不能少于最小讲述时长，且不能超过最大讲述时长，这样可以避免讲述内容过短或者过长从而使得验证过程变得无趣。
[0150]
在具体实施方式中，讲述内容中还可以包括验证问题，这样，倾听端在接收到讲述内容后，操控倾听端的用户可以根据讲述内容来推导获得验证问题的对应的答案。
[0151]
如表4所示，是本技术实施例提供的讲述内容、验证问题以及验证答案示例表。
[0152]
表4.讲述内容、验证问题以及验证答案示例表
[0153][0154]
作为一种实施方式，步骤303-1还可以包括图4中的步骤407～步骤408。
[0155]
步骤407：当检测到所述讲述内容中未包含预设信息时，将所述讲述内容发送给所述倾听端。
[0156]
所述预设信息至少包括：所述验证答案。
[0157]
步骤408：当检测到所述讲述内容中包含所述预设信息时，向所述讲述端发送通知消息以指示重新录入问题相关信息，所述问题相关信息至少包括讲述内容。
[0158]
作为一种实施方式，问题相关信息还包括：讲述内容、验证答案、验证问题中的至少一个。
[0159]
可以理解的，讲述端的用户发送的讲述内容中可能会包含验证答案，因此可以在讲述端发送验证问题时，服务端根据讲述端所发送的验证问题和验证答案对讲述内容进行检测，若检测到讲述内容中包含有验证答案，发送通知消息用以指示讲述端重新录入问题相关信息，讲述端可以重新录入讲述内容，还可以重新录入讲述内容和/或验证答案和/或验证问题。
[0160]
此外，服务端还可以检测讲述内容中是否包含敏感关键词，如色情、暴力等信息，具体的，服务端中可以预先设置有敏感关键词库，当操控讲述端的用户在讲述端发送讲述
内容时，服务端实时检测讲述内容中是否出现了所预设的敏感关键词库中的词，当检测到讲述内容中包含敏感关键词时，将讲述端正在录入讲述内容的操作中断，并发送通知消息用以指示讲述端重新录入问题相关信息，讲述端可以重新录入讲述内容，还可以重新录入讲述内容和/或验证答案和/或验证问题。
[0161]
如表5所示，是本技术实施例提供的重新录入问题相关信息示例表，由表5可知，原讲述内容中包含了验证答案70，因此可以重新录入问题相关信息，情况一为重新录入验证问题和验证答案，讲述内容不变；情况二：重新录入讲述内容，验证问题和验证答案不变；情况三为重新录入讲述内容和验证答案，验证问题不变；情况四为重新录入讲述内容和验证问题，验证答案不变；情况五为重新录入讲述内容、验证问题以及验证答案。具体请参照表5。
[0162]
表5.重新录入问题相关信息示例表
[0163][0164]
可选的，当验证问题与所述讲述内容为语音形式的数据时，在步骤304之前，上述验证方法还可以包括图4中的步骤409～步骤410。
[0165]
步骤409：接收所述倾听端发送的针对所述讲述内容的细节询问请求，向所述讲述端发送所述细节询问请求所询问的内容。
[0166]
步骤410：接收所述讲述端发送的针对所述询问的内容的回复消息，向所述倾听端发送所述回复消息。
[0167]
在一种实施方式中，当讲述内容为语音形式的数据时，为了使得倾听端能够清楚讲述内容，通常情况下，服务端不仅会发送语音形式的讲述内容，还会将其转换为文本形式，并发送给倾听端，以使得倾听端能够知晓讲述内容的细节。
[0168]
另一种实施方式中，当服务端向倾听端发送了语音形式的讲述内容后，倾听端还可以针对讲述内容发送细节询问消息，用以了解讲述内容的细节，进而更好的得到验证答案。具体的，倾听端向服务端发送细节询问消息，服务端将细节询问消息发送到讲述端，讲述端基于细节询问消息向服务端发送回复消息，服务端将回复消息发送到倾听端。在此过程中，倾听端界面可以显示询问细节和进行回答相关控件，讲述端界面可以显示回答细节和不回答控件，因此，回复消息可以是讲述端输入的回答细节内容，也可以是对方不做回答
消息。这样，在验证过程中讲述端和倾听端进行了良好的细节交互。
[0169]
通常情况下，当讲述端为服务端的智能机器人时，验证问题以及讲述内容为较为简单的内容，此时倾听端可以发送细节询问消息，服务端可以向讲述端发送不支持细节询问，请直接发送验证答案的信息；在另一种情况中，当讲述端为服务端的智能机器人时，此时倾听端界面的细节询问消息相关控件为不可选择状态。换言之，进行细节交互的基础为倾听端和讲述端都是客户端。
[0170]
进一步地，服务端可以设置最大细节交互次数，倾听端发送细节询问消息的次数不能超过最大细节交互次数。如设置最大细节交互次数为3，则倾听端最多可以发送3次细节询问消息。如表6所示，是本技术实施例提供的细节交互示例表。
[0171]
表6.细节交互示例表
[0172][0173]
通过这一技术手段，使得讲述端和倾听端进行了良好的互动，提升了讲述端的用户和倾听端的用户的沟通能力，使验证方法更具有趣味性。
[0174]
如图5所示，是本技术实施例提供的验证方法的客户端示意图，客户端的用户可以点击获取发送验证请求控件，此时，客户端显示正在匹配，并显示匹配倒计时，当匹配到交互端时，客户端显示匹配成功。之后，客户端的用户可以点击成为讲述端或者成为倾听端控件，当点击成为讲述端控件时，客户端可以被确定为讲述端，此时客户端的界面将显示输入验证问题控件，客户端的用户可以点击输入验证问题控件，输入验证问题；当点击成为倾听端控件时，客户端可以被确定为倾听端，此时客户端的界面将显示输入验证答案控件，客户端的用户可以点击输入验证答案控件，输入验证答案。
[0175]
与本技术第一实施例提供的验证方法相对应的，本技术第二实施例还提供了验证装置，应用于服务端，如图6所示，所述装置包括：
[0176]
匹配单元601，用于接收第一客户端发送的验证请求，为所述第一客户端匹配交互端；
[0177]
确定单元602，用于将所述第一客户端和所述交互端中的一个确定为讲述端，另一个确定为倾听端；
[0178]
第一处理单元603，用于接收所述讲述端发送的验证问题，并将所述验证问题发送给所述倾听端；
[0179]
第二处理单元604，用于接收所述倾听端发送的第一验证答案，所述第一验证答案为所述倾听端接收到的针对所述验证问题的答案；
[0180]
判定单元605，用于根据所述验证问题以及所述第一验证答案判定所述第一客户端是否验证成功。
[0181]
可选的，所述匹配单元601具体用于：查找在距离当前时刻预设时长的时间段内发
送了验证请求、且未匹配交互端的第二客户端，若查找到所述第二客户端，将所述第二客户端确定为与所述第一客户端匹配的交互端。
[0182]
可选的，所述匹配单元601还具体用于：将所述服务端确定为与所述第一客户端匹配的交互端。
[0183]
可选的，所述确定单元602具体用于：将所述服务端确定为讲述端，将所述第一客户端确定为倾听端。
[0184]
可选的，所述确定单元602还具体用于：接收所述第一客户端与所述第二客户端发送的成为第一端的选择信息，将所述第一客户端和所述第二客户端中发送所述选择信息时刻较早的客户端确定为所述第一端，将所述第一客户端和所述第二客户端中除所述第一端以外的另一客户端确定为第二端，或者，接收所述第一客户端发送的成为第一端的选择信息、所述第二客户端发送的成为第二端的选择信息，将所述第一客户端确定为所述第一端，将所述第二客户端确定为所述第二端，其中，所述第一端为所述讲述端，所述第二端为所述倾听端；或所述第一端为所述倾听端，所述第二端为所述讲述端。
[0185]
可选的，所述第一处理单元603具体用于：接收第一端发送的角色互换请求，向第二端发送角色互换信息，接收所述第二端发送的同意更换的消息，将所述第一端与所述第二端进行角色交换，所述角色交换为将倾听端与讲述端进行互换，其中，所述第一端为所述讲述端，所述第二端为所述倾听端，或所述第一端为所述倾听端，所述第二端为所述讲述端。
[0186]
可选的所述第一处理单元603还具体用于：接收所述讲述端发送的验证答案，所述验证答案为用户输入所述讲述端的所述验证问题的答案，根据所述第一验证答案与所述验证答案是否一致判定所述第一客户端是否验证成功。
[0187]
可选的，所述判定单元605具体用于：根据所述第一验证答案与所述验证答案是否一致判定所述第二客户端是否验证成功。
[0188]
可选的，所述装置还包括：
[0189]
第三处理单元，用于当检测到所述第一验证答案错误时，向所述倾听端发送重新输入验证答案的信息，并接收所述倾听端重新发送的第一验证答案，当检测到所述第一验证答案的错误次数达到第一预设次数时，向所述倾听端发送所述验证答案，接收所述倾听端发送的第二验证答案，所述第二验证答案为用户基于所述验证答案输入所述倾听端的内容，根据所述第二验证答案判定所述第一客户端是否验证成功。
[0190]
可选的，所述第三处理单元具体用于：当检测到所述第一验证答案错误时，向所述倾听端发送重新输入验证答案的信息，并接收所述倾听端重新发送的第一验证答案，当检测到所述第一验证答案的错误次数到达第二预设次数时，向所述讲述端发送自行验证的提示信息，接收所述讲述端发送的第三验证答案，当检测到所述第三验证答案正确时，判定所述第一客户端与所述第二客户端中的所述讲述端验证成功。
[0191]
可选的，所述第三处理单元还具体用于：当检测到所述第一验证答案错误时，向所述倾听端发送重新输入验证答案的信息，并接收所述倾听端重新发送的第一验证答案，当检测到所述第一验证答案错误的次数到达第三预设次数时，向所述讲述端发送重新匹配交互端的提示信息，接收所述讲述端发送的重新匹配交互端的请求，为所述讲述端重新匹配发送验证请求、且未匹配交互端的第三客户端作为倾听端，将所述讲述端发送的所述验证
问题发送给所述第三客户端以进行验证。
[0192]
可选的，所述第一处理单元603具体用于：接收所述讲述端发送的讲述内容，并将所述讲述内容发送给所述倾听端，其中，所述讲述内容用于推导出所述验证问题对应的答案。
[0193]
可选的，所述装置还包括：
[0194]
转换单元，用于将所述验证问题、所述讲述内容转换为文本数据，并将所转换的文本数据发送给所述倾听端。
[0195]
可选的，所述第二处理单元604还具体用于：接收所述倾听端发送的针对所述讲述内容的细节询问请求，向所述讲述端发送所述细节询问请求所询问的内容，接收所述讲述端发送的针对所述询问的内容的回复消息，向所述倾听端发送所述回复消息。
[0196]
可选的，所述第一处理单元603还具体用于：当检测到所述讲述内容中未包含预设信息时，将所述讲述内容发送给所述倾听端，所述预设信息至少包括：所述验证答案。
[0197]
可选的，所述第一处理单元603还具体用于：当检测到所述讲述内容中包含所述预设信息时，向所述讲述端发送通知消息以指示重新录入问题相关信息，所述问题相关信息包括：讲述内容、验证答案、验证问题中的至少一个。
[0198]
可选的，所述判定单元605还具体用于：当检测到所述第一验证答案正确、且所述第一验证答案为真人语音时，判定所述第一客户端验证成功。
[0199]
可选的，所述第一处理单元603还具体用于：将预设验证问题、预设讲述内容发送给所述讲述端，所述讲述端发送的所述验证问题是用户根据所述预设验证问题输入的，所述讲述端发送的所述讲述内容是用户根据所述预设讲述内容输入的，按照预设更新周期对所述预设验证问题、所述预设讲述内容进行更新。
[0200]
与本技术第一实施例提供的验证方法相对应的，本技术第三实施例还提供了一种用于运行验证方法的电子设备。如图7所示，所述电子设备包括：处理器701；以及存储器702，用于存储验证方法的程序，该设备通电并通过所述处理器运行验证方法的程序后，执行如下步骤：
[0201]
接收第一客户端发送的验证请求，为所述第一客户端匹配交互端；
[0202]
将所述第一客户端和所述交互端中的一个确定为讲述端，另一个确定为倾听端；
[0203]
接收所述讲述端发送的验证问题，并将所述验证问题发送给所述倾听端；
[0204]
接收所述倾听端发送的第一验证答案，所述第一验证答案为所述倾听端接收到的针对所述验证问题的答案；
[0205]
根据所述验证问题及所述第一验证答案判定所述第一客户端是否验证成功。与本技术第一实施例提供的验证方法相对应的，本技术第四实施例提供了一种计算机可读存储介质，存储有验证方法的程序，该程序被处理器运行，执行下述步骤：
[0206]
接收第一客户端发送的验证请求，为所述第一客户端匹配交互端；
[0207]
将所述第一客户端和所述交互端中的一个确定为讲述端，另一个确定为倾听端；
[0208]
接收所述讲述端发送的验证问题，并将所述验证问题发送给所述倾听端；
[0209]
接收所述倾听端发送的第一验证答案，所述第一验证答案为所述倾听端接收到的针对所述验证问题的答案；
[0210]
根据所述验证问题及所述第一验证答案判定所述第一客户端是否验证成功。需要
说明的是，对于本技术第二实施例、第三实施例和第四实施例提供的装置、电子设备及计算机可读存储介质的详细描述可以参考对本技术第一实施例的相关描述，这里不再赘述。
[0211]
本技术虽然以较佳实施例公开如上，但其并不是用来限定本技术，任何本领域技术人员在不脱离本技术的精神和范围内，都可以做出可能的变动和修改，因此本技术的保护范围应当以本技术权利要求所界定的范围为准。
[0212]
在一个典型的配置中，区块链中的节点设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
[0213]
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
[0214]
1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他属性的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储介质或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
[0215]
2、本领域技术人员应明白，本技术的实施例可提供为方法、系统或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0216]
本技术虽然以较佳实施例公开如上，但其并不是用来限定本技术，任何本领域技术人员在不脱离本技术的精神和范围内，都可以做出可能的变动和修改，因此本技术的保护范围应当以本技术权利要求所界定的范围为准。