报文核对方法、装置、终端设备及计算机可读存储介质与流程

1.本技术属于软件测试技术领域，尤其涉及一种报文核对方法、装置、终端设备及计算机可读存储介质。


背景技术：

2.随着人们对软件(例如支付应用)质量的要求越来越高，软件测试也变得越来越重要，有些大中型客户对软件质量的要求更是苛刻，每次发布新版本都需要核对所有交易的报文。现有技术在核对报文时是采用人工比对的方式，这种方式效率较低，无论是在调试阶段或者测试阶段，均需要投入大量的时间，并且容易出错。


技术实现要素：

3.本技术实施例提供了一种报文核对方法、装置、终端设备及计算机可读存储介质，以提高报文核对的效率和准确性。
4.第一方面，本技术实施例提供了一种报文核对方法，所述报文核对方法包括：
5.获取支付应用在交易过程中产生的实际报文；
6.解析所述实际报文，得到对应的报文解析结果；
7.获取所述实际报文对应的预期报文；
8.根据所述预期报文中每个域的值，对所述报文解析结果进行核对。
9.第二方面，本技术实施例提供了一种报文核对装置，所述报文核对装置包括：
10.第一获取模块，用于获取支付应用在交易过程中产生的实际报文；
11.报文解析模块，用于解析所述实际报文，得到对应的报文解析结果；
12.第二获取模块，用于获取所述实际报文对应的预期报文；
13.报文核对模块，用于根据所述预期报文中每个域的值，对所述报文解析结果进行核对。
14.第三方面，本技术实施例提供了一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述报文核对方法的步骤。
15.第四方面，本技术实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的报文核对方法的步骤。
16.第五方面，本技术实施例提供了一种计算机程序产品，当所述计算机程序产品在终端设备上运行时，使得所述终端设备执行如上述第一方面所述的报文核对方法的步骤。
17.由上可见，本技术通过获取支付应用在交易过程中产生的实际报文，并解析该实际报文，可以得到该实际报文的报文解析结果，根据实际报文对应的预期报文中每个域的值，可以对报文解析结果进行核对，在核对时无需人工参与，提高了报文核对的效率和准确性。
附图说明
18.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
19.图1是本技术实施例一提供的报文核对方法的实现流程示意图；
20.图2是配置文件的示例图；
21.图3是报文核对的网络架构示例图；
22.图4是本技术实施例二提供的报文核对方法的实现流程示意图；
23.图5是excel中预期报文的示例图；
24.图6是excel中预期报文的另一示例图；
25.图7是本技术实施例三提供的报文核对装置的结构示意图；
26.图8是本技术实施例四提供的终端设备的结构示意图。
具体实施方式
27.以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本技术实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本技术。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本技术的描述。
28.应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
29.如在本技术说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
[0030]
另外，在本技术说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
[0031]
在本技术说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本技术的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
[0032]
应理解，本实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
[0033]
为了说明本技术所述的技术方案，下面通过具体实施例来进行说明。
[0034]
参见图1，是本技术实施例一提供的报文核对方法的实现流程示意图，该报文核对方法应用于终端设备。如图1所示，该报文核对方法可以包括以下步骤：
[0035]
步骤101，获取支付应用在交易过程中产生的实际报文。
[0036]
其中，上述支付应用可以是任一具有支付功能的应用。例如，支付宝、云闪付、paypal、掌上生活等。
[0037]
由于支付应用的一笔交易可能存在一条报文，或者至少两条报文，故上述101中实际报文的数量可能为一条，也可能为至少两条。
[0038]
上述实际报文是支付应用在交易过程中实际产生的报文，包括但不限于支付应用在交易过程中上送的报文、接收的报文等。
[0039]
在一可选实施例中，可以采用logcat的方式获取支付应用在交易过程中产生的实际报文。其实现方式包括：获取支付应用在交易过程中产生的交易日志；根据第一关键字和/或第二关键字，使用预设的正则表达式，从交易日志中截取实际报文，第一关键字表征支付应用在交易过程中上送的报文的截取开始位置，第二关键字表征支付应用在交易过程中接收的报文的截取开始位置。
[0040]
其中，上述正则表达式可以表示截取交易日志中与第一关键字位于同一行且位于第一关键字之后的所有字符，或者与第二关键字位于同一行且位于第二关键字之后的所有字符。
[0041]
在一示例中，第一关键字可以是“send”，第二关键字可以是“recv”。上述正则表达式可以是：(？《＝send:).*|(？《＝recv:).*。“(？《＝send:)”表示截取“send”之后的所有字符，例如字符串“msage_send:60
…”
，那么截取到的字符为“60
…”
。“.*”表示截取某一行的所有字符。(？《＝recv:)表示截取“recv”之后的所有字符。“(？《＝send:).*|(？《＝recv:).*”表示截取交易日志中与“send”位于同一行且位于“send”之后的所有字符，或者与“recv”位于同一行且位于“recv”之后的所有字符。
[0042]
步骤102，解析实际报文，得到对应的报文解析结果。
[0043]
可以根据预设的配置文件，解析实际报文，得到实际报文对应的报文解析结果。
[0044]
其中，配置文件用于定义iso8583报文中每个域的数据格式、数据长度等信息。配置文件中的名词解释如下：
[0045]
a：字母，向左靠，右部多余部分填空格。
[0046]
n：数值，右靠，首位有效数字前充零，若表示金额，则最右二位为角分。
[0047]
s：特殊“符号”。
[0048]
an：字母和/或数字，左靠，右部多余部分填空格。an可能同时包含a和n。
[0049]
ans：字母、数字和/或特殊符号，左靠，右部多余部分填空格。ans可能同时包含a、n和s。
[0050]
as：字母和/或特殊符号，左靠，右部多余部分填空格。
[0051]
b：二进制字节(bit位)。
[0052]
z：由iso7811和iso7813制定的磁卡第二、三磁道的数据类型。
[0053]
ans...999(lllvar)：该变量中可含字母、数字和特殊符号，最长不超过999个字符，长度由三位数字确定。
[0054]
n...999(lllvar)：在压缩时，其长度位用右靠的二进码十进数(binary-coded decimal，bcd)码压缩，而其后紧随的数字内容用左靠的bcd码压缩，可以保证有效内容和其位数中间无缺省填充值。若不为偶数位，左靠的数字内容后补零。由于有长度位表征该域有
效内容的长度，因此后补零不会改变该域的真实值。
[0055]
bcd：bcd转string，例如60域的30323030303030363430转0200000640。
[0056]
ascii：ascii码转string，例如38域的4d4330303030转mc0000。
[0057]
emvtlv：解析emv数据，例如55域的tag5f2a(5f2a020344)转[5f2a:0344]。
[0058]
tlv：解析自定义域的值，例如63域的tag11(3131000740213030322140)转['11','0007@！002！@']。
[0059]
ltv：解析自定义域的值，例如63域的tag12(0003313258)转['12','0001x]
[0060]
sp：解析特殊域的值，数据格式定义为sp之后，需要实现unpack接口，可支持自定义报文解析规则。
[0061]
如图2所示是配置文件的示例图。
[0062]
在一可选实施例中，可以调用报文解析接口，以根据配置文件定义的数据格式，解析实际报文。
[0063]
其中，报文解析接口是从报文解析模块单独开放的一个接口，通过报文解析接口可以传递配置文件和需要解析的实际报文，并能够以字典的形式返回实际报文对应的报文解析结果。其中，上述报文解析接口可以称之为unpack message接口，unpack message接口是一个java库。
[0064]
在一实际应用场景中，上述报文解析结果的获取流程包括：执行adb logcat-c，以清除在执行交易之前缓存的日志；执行adb logcat-s findstr tag命令，根据tag筛选logcat输出的日志；人工或者采用自动化脚本执行支付应用的交易，在此过程中logcat输出的日志即为上述交易日志；可以保存logcat输出的日志到txt文件，并存储在log_path参数指定的路径；读取txt文件内容，根据第一关键字和/或第二关键字，使用预设的正则表达式，截取txt文件中的实际报文；调用java库；java库加载xml格式的配置文件，根据配置文件定义的数据格式，解析实际报文；将解析实际报文得到的报文解析结果存储在字典中。由于一笔交易可能存在多条报文，故可以循环执行上述报文解析结果的获取流程，以将支付应用的交易产生的所有实际报文的报文解析结果存放在集合中。
[0065]
其中，可以使用python的os和subprocess、re三个库从交易日志中获取并截取实际报文。其实现步骤如下：
[0066]
1)调用os.system方法执行adb logcat-c，以清除在执行交易之前缓存的日志。
[0067]
2)调用subprocess.popen方法执行adb logcat-s findstr tag命令筛选logcat输出的日志。
[0068]
3)调用subprocess.popen方法创建文件句柄，将logcat输出的数据存储在txt文件中。
[0069]
4)调用open方法打开txt文件。
[0070]
5)调用re.findall()方法，使用预设的正则表达式截取实际报文。
[0071]
需要说明的是，本技术中的实际报文为iso8583报文，上述用于解析实际报文的java库可以称之为iso8583_telegramutil_v1.00.01.jar。
[0072]
使用python的jpype库引入的java库(iso8583_telegramutil_v1.00.01.jar)解析实际报文，java库可以根据配置文件定义的数据格式进行解析，java库最终返回解析后的报文解析结果。其实现步骤如下：
[0073]
1)调用jpype.getdefaultjvmpath()方法启动jvm。
[0074]
2)调用os.path.join()方法加载jar。
[0075]
3)调用jpype.jclass()方法加载java类。
[0076]
4)创建java库(iso8583_telegramutil_v1.00.01.jar)的实例对象。
[0077]
5)传入配置文件和实际报文，并接收java库解析完成的报文解析结果。
[0078]
步骤103，获取实际报文对应的预期报文。
[0079]
预期报文是支付应用在交易过程中应该产生的报文，是正确的报文。
[0080]
需要说明的是，支付应用在交易过程中产生的每条实际报文均对应一条预期报文，即预期报文的数量与实际报文的数量相同，根据每条实际报文对应的预期报文，可以实现对该实际报文的报文解析结果的核对。
[0081]
在一可选实施例中，获取实际报文对应的预期报文，包括：
[0082]
根据第三关键字从目标文档中读取预期报文，第三关键字表征预期报文的读取开始位置，目标文档存储有预期报文。
[0083]
其中，上述目标文档可以是任一格式的文档，在此不做限定。例如，上述目标文档的格式为excel格式、xml格式等。
[0084]
在一示例中，第三关键字可以是“message type”，在目标文档中读取到“message type”之后，可以开始匹配需要读取的预期报文，读取到下一个“message type”时结束这个预期报文的读取，这两个“message type”之间的内容为完整的一条预期报文。
[0085]
在一实际应用场景中，上述预期报文的获取流程包括：根据预期报文的填写规则，在excel中填写预期报文；选择以excel的方式获取预期报文；根据filepath参数打开excel文件；根据entry_mode参数选择需要读取的sheet表；在sheet表中读取到关键字“message type”后，则开始匹配需要读取的预期报文，读取到下一个“message type”时表示完整的一条预期报文已经读取完成，如果有多条预期报文则继续读取数据，直到后面内容为空时，则停止读取操作；将读取到的每条预期报文存储在字典中；由于一笔交易可能存在多条报文，所以可以循环执行以上步骤，以将所有的预期报文存放在集合中。
[0086]
步骤104，根据预期报文中每个域的值，对报文解析结果进行核对。
[0087]
根据预期报文中每个域的值，可以将实际报文对应的报文解析结果与预期报文进行比对，从而实现对报文解析结果的核对。
[0088]
如图3所示是报文核对的网络架构示例图，此网络架构包括数据层、基础层和逻辑层。数据层主要用于获取实际报文和预期报文；基础层主要是iso8583报文库，用于解析实际报文；逻辑层主要用于将解析实际报文得到的报文解析结果与预期报文进行核对，并输出核对结果。
[0089]
在一实际应用场景中，可以获取报文解析结果的集合和预期报文的集合；分别遍历报文解析结果的集合和预期报文的集合，得到报文解析结果的集合中的所有字典和预期报文的集合中的所有字典；遍历报文解析结果的集合中的所有字典和预期报文的集合中的所有字典，得到报文解析结果的集合中的每个字典存储的报文解析结果和预期报文的集合中的每个字典存储的预期报文；根据每个预期报文的每个域的值，核对与该预期报文对应的报文解析结果，可以实现对支付应用在交易过程中产生的每条实际报文的核对。所有报文解析结果的集合和预期报文的集合遍历完后，返回每条报文解析结果的核对结果，以及
输出详细的预期报文和报文解析结果的日志，便于后续查看。
[0090]
在一可选实施例中，还包括：
[0091]
调用报文指定域接口，以从报文解析结果中获取指定域的值；
[0092]
根据指定域的值，执行支付应用的特殊交易。
[0093]
通过调用报文指定域接口，可以传递报文类型和需要获取的指定域的集合，并以集合的形式返回指定域的值。其中，上述报文指定域接口可以称之为get parameter接口。
[0094]
在编写用户界面(user interface，ui)自动化脚本时，有些特殊交易需要输入支付应用的后台返回的参数才能完成交易，例如：执行退款、预授权取消、预授权完成等交易，都需要输入原交易上的检索参考号、授权标识应答码等参数才能完成交易，但是在应用层的ui上并没有显示这些参数，导致在编写ui自动化脚本时，无法从应用层的ui获取这些参数，因为ui自动化测试只能获取页面上显示的数据，无法获取页面上未显示的数据，如果ui自动化脚本随意输入检索参考号、授权标识应答码等参数，后台和终端设备都会校验失败，则达不到预期的测试效果。本技术通过报文指定域接口可以从后台返回的实际报文的报文解析结果中获取指定域的值，例如从返回的实际报文的报文解析结果中获取37域的值(检索参考号)、38域的值(授权标识应答码)等，再将获取到的检索参考号、授权标识应答码等参数应用到ui自动化脚本中，从而解决了无法采用自动化测试特殊交易的问题。
[0095]
本技术实施例通过获取支付应用在交易过程中产生的实际报文，并解析该实际报文，可以得到该实际报文的报文解析结果，根据实际报文对应的预期报文中每个域的值，可以对报文解析结果进行核对，在核对时无需人工参考，提高了报文核对的效率和准确性。
[0096]
参见图4，是本技术实施例二提供的报文核对方法的实现流程示意图，该报文核对方法应用于终端设备。如图4所示，该报文核对方法可以包括以下步骤：
[0097]
步骤401，获取支付应用在交易过程中产生的实际报文。
[0098]
该步骤与步骤101相同，具体可参见步骤101的相关描述，在此不再赘述。
[0099]
步骤402，解析实际报文，得到对应的报文解析结果。
[0100]
该步骤与步骤102相同，具体可参见步骤102的相关描述，在此不再赘述。
[0101]
解析实际报文所使用的配置文件预先根据iso8583的特性定义好了报文的header、message type、以及2至64域的数据类型、数据格式、数据长度以及每个域的注解，一般只需要修改自定义域的数据格式类型，就可以解析sale、void、refund、offline、preauth、adjust、installment、settlement等不同类型的交易报文。
[0102]
步骤403，获取实际报文对应的预期报文。
[0103]
该步骤与步骤103相同，具体可参见步骤103的相关描述，在此不再赘述。
[0104]
步骤404，根据预期报文中每个域的值，判断预期报文中的每个域在报文解析结果中的核对结果。
[0105]
示例性的，对于预期报文中的35域，根据预期报文中35域的值，可以判断预期报文中35域在报文解析结果中的核对结果。
[0106]
在一实施例中，可以根据支付应用在交易过程中应该产生的报文得到预期报文的填写规则，该填写规则至少包括预期报文中应该包含的域以及每个域的值，基于该填写规则可以在目标文档中填写并存储预期报文。
[0107]
在一可选实施例中，根据预期报文中每个域的值，判断预期报文中的每个域在报
文解析结果中的核对结果，包括：
[0108]
若预期报文中某个域的值为第一字符，则确定该域为第一域，并判断报文解析结果中是否包含第一域，第一字符表征报文解析结果中需包含第一域；
[0109]
若报文解析结果中包含第一域，则判定第一域在报文解析结果中的核对结果为正确；
[0110]
若报文解析结果中不包含第一域，则判定第一域在报文解析结果中的核对结果为错误；
[0111]
若预期报文中某个域的值为第二字符，则确定该域为第二域，并判断报文解析结果中是否不包含第二域，第二字符表征报文解析结果中不能包含第二域；
[0112]
若报文解析结果中不包含第二域，则判定第二域在报文解析结果中的核对结果为正确；
[0113]
若报文解析结果中包含第二域，则判定第二域在报文解析结果中的核对结果为错误；
[0114]
若预期报文中某个域的值为第三字符，则跳过该域在报文解析结果中的判断，第三字符表征对应域为报文解析结果中的可选域；
[0115]
若预期报文中某个域的值为其他字符，则确定该域为其他域，并判断报文解析结果中是否包含其他域，并在报文解析结果中包含其他域时，判断其他域的值在预期报文中和在报文解析结果中是否一致，其他字符是指除第一字符、第二字符和第三字符之外的字符；
[0116]
若报文解析结果中包含其他域且其他域的值在预期报文中和在报文解析结果中一致，则判定其他域在报文解析结果中的核对结果为正确；
[0117]
若报文解析结果中不包含其他域，或者包含其他域且其他域的值在预期报文中和在报文解析结果中不一致，则判定其他域在报文解析结果中的核对结果为错误。
[0118]
其中，第一域是报文解析结果中必须包含的域，即实际报文中必须包含的域；第二域是报文解析结果中不能包含的域，即实际报文中不能包含的域；第三域是报文解析结果中可有可无的域(即可选域)，即实际报文中可有可无的域。其他域是报文解析结果必须包含的域且该域的值在报文解析结果中与在预期报文中一致。判断其他域的值在预期报文中和在报文解析结果中是否一致可以是指判断其他域在报文解析结果中的值是否为其他域对应的其他字符，例如，预期报文中22域的值为051，那么可以判断051为其他字符，22域为其他域，判断报文解析结果中22域的值是否为051，若为051则可以判定22域在报文解析结果中的核对结果是正确的；若不为051则可以判定22域在报文解析结果中的核对结果是错误的。
[0119]
示例性的，可以采用“y”表示第一字符，采用“n”表示第二字符，采用“o”表示第三字符，其他字符可以是除“y”、“n”、“o”之外的字符。
[0120]
如图5所示是excel中预期报文的示例图。图5是在excel中存储预期报文。excel中填写规范如下：
[0121]
1)excel表名称：一般以交易类型命名，便于区分不同的交易，方便日后维护。
[0122]
2)sheet名称：一般以持卡方式命名，例如insert(插卡)、swipe(刷卡)、fallback(降级处理)、manual(手输卡号)、tap(拍卡)等，也可以自定义名称。
[0123]
3)表格颜色：深蓝色(title：不可修改，不可编辑，可追加)，水绿色(tag：可增删改)，浅绿色(card type：可增删改)，白色(需要填充的预期报文的数据)。
[0124]
4)message type(报文类型)：[0100]、[0200]、[0320]、[0400]、[0500]等等。
[0125]
5)card type(卡类型)：all(表示包含全部卡种)、default(表示包含visa，master，jcb)、unionpay、visa、master、jcb、amex等。
[0126]
6)input text(需要输入的报文数据)：n(表示必须不包含的域)、y(表示必须包含的域)、value(例如03域：000030，表示03域的值必须是000030)、o(表示可选的、未涉及的域)，填写de特殊域的值时可以附带2个字节的字符串长度。
[0127]
图5中的“condition”表示交易条件，“trans type”表示交易类型，“dcd”表示美元，“dcc”表示人民币，“tip”表示小费，“pin”表示密码。
[0128]
本技术通过在excel中设置第一字符、第二字符、第三字符以及其他字符等字符，可以灵活地设定预期报文的格式，从而得到较为详细的核对过程，并可以实现多样化配置。
[0129]
在从excel获取预期报文时，主要使用到python的xlrd、json、re三个库，xlrd负责处理excel表，json负责转换获取到的数据，re负责使用正则表达式筛选读取数据。其实现步骤如下：
[0130]
1)调用xlrd.open_workbook()方法打开excel表。
[0131]
2)调用row_values()方法获取excel表中的关键信息，例如sheet名称、message type等数据。
[0132]
3)校验sheet名称、message type、trans_type等数据。
[0133]
4)校验通过后，获取message type域(例如图5中的de)的值。
[0134]
5)获取de55或者de63等特殊域的值。
[0135]
6)将获取到的域的值调用json.dumps()方法转换成json格式。
[0136]
预期报文采用了excel管理，一张excel可以分多个sheet，一个sheet可以存储多条报文，例如：一笔sale交易会上送多条报文，并且支持多种类型的卡片，多种不同的用卡方式。如图6所示是excel中预期报文的另一示例图，图6中包括两条预期报文。
[0137]
步骤405，若预期报文中所有域在报文解析结果中的核对结果均为正确，则判定报文解析结果的核对结果为正确。
[0138]
在报文解析结果的核对结果为正确时，可以返回表示正确的标识符(例如true)。
[0139]
步骤406，若预期报文中存在至少一个域在报文解析结果中的核对结果为错误，则判定报文解析结果的核对结果为错误。
[0140]
在报文解析结果的核对结果为错误时，可以返回核对结果为错误的域。
[0141]
由于一笔交易可能产生多条实际报文，并且每条实际报文都包含了多个域，可以将整笔交易的所有实际报文一次性全部核对完成后，返回详细的核对结果，如果全部核对正确则返回true，如果核对失败则返回核对失败的域在预期报文中的值和在实际报文的报文解析结果中的值，不会因为核对过程中某条报文解析结果或者某个域和预期报文不一致而停止工作。
[0142]
本技术实施例在实施例一的基础上，可以根据预期报文中每个域的值，判断预期报文中的每个域在报文解析结果中的核对结果，此核对过程无需人工参考，提高了报文核对的效率和准确性。
[0143]
可选地，实现上述实施例一和实施例二的报文核对方案的程序代码可以存储在pax_check8583library库，pax_check8583library库作为robot framework自动化框架的一个python测试库，在运行自动化脚本时，可以自动地核对交易报文是否正确，从而提高测试效率，降低测试成本，有效地避免人工核对容易出错的问题，从而提高产品质量，也可以解决无法采用自动化测试特殊交易的问题。
[0144]
在一现有方案中解析实际报文通常都是采用pda报文解析工具，由于pda报文解析工具不能解析自定义域(例如iso8583报文的60/62/63域等自定义域)，导致需要测试和开发人员手动解析自定义域来确定自定义域上送的报文是否正确，pax_check8583library库在实现了pda解析报文功能的基础上，还提供了解析自定义域的接口(即unpack message接口)，只要实现了接口就可以将整个项目的每条ios8583报文以字符串的方式解析出来。
[0145]
本技术中的pax_check8583library库具有较好的易用性，无论是测试阶段还是调试阶段，只要有python环境都可以运行pax_check8583library库以核对交易报文。
[0146]
在实际应用中，本技术可以通过调用三个接口完成自动核对交易报文的功能，这三个接口分别是set attr(初始化数据)、start check iso8583(开启监听)、stop check iso8583(停止监听，并核对报文)。pax_check8583library库发布后，对外开放这三个接口，使用这个库的用户调用这三个接口即可实现交易报文的自动核对。pax_check8583library库是从交易日志中获取实际报文并解析实际报文，不需要被测应用(即支付应用)提供额外的接口，任意的支付应用只要在logcat打印了报文，都可以正常使用该库的所有功能。
[0147]
对应于上文实施例所述的报文核对方法，图7示出了本技术实施例三提供的报文核对装置的结构框图，为了便于说明，仅示出了与本技术实施例相关的部分。
[0148]
参照图7，该报文核对装置包括：
[0149]
第一获取模块71，用于获取支付应用在交易过程中产生的实际报文；
[0150]
报文解析模块72，用于解析所述实际报文，得到对应的报文解析结果；
[0151]
第二获取模块73，用于获取所述实际报文对应的预期报文；
[0152]
报文核对模块74，用于根据所述预期报文中每个域的值，对所述报文解析结果进行核对。
[0153]
可选地，上述报文核对模块74包括：
[0154]
核对判断单元，用于根据所述预期报文中每个域的值，判断所述预期报文中的每个域在所述报文解析结果中的核对结果；
[0155]
第一判定单元，用于若所述预期报文中所有域在所述报文解析结果中的核对结果均为正确，则判定所述报文解析结果的核对结果为正确；
[0156]
第二判定单元，用于若所述预期报文中存在至少一个域在所述报文解析结果中的核对结果为错误，则判定所述报文解析结果的核对结果为错误。
[0157]
可选地，上述核对判断单元具体用于：
[0158]
若所述预期报文中某个域的值为第一字符，则确定该域为第一域，并判断所述报文解析结果中是否包含所述第一域，所述第一字符表征所述报文解析结果中需包含所述第一域；
[0159]
若所述报文解析结果中包含所述第一域，则判定所述第一域在所述报文解析结果中的核对结果为正确；
[0160]
若所述报文解析结果中不包含所述第一域，则判定所述第一域在所述报文解析结果中的核对结果为错误；
[0161]
若所述预期报文中某个域的值为第二字符，则确定该域为第二域，并判断所述报文解析结果中是否不包含所述第二域，所述第二字符表征所述报文解析结果中不能包含所述第二域；
[0162]
若所述报文解析结果中不包含所述第二域，则判定所述第二域在所述报文解析结果中的核对结果为正确；
[0163]
若所述报文解析结果中包含所述第二域，则判定所述第二域在所述报文解析结果中的核对结果为错误；
[0164]
若所述预期报文中某个域的值为第三字符，则跳过该域在所述报文解析结果中的判断，所述第三字符表征对应域为所述报文解析结果中的可选域；
[0165]
若所述预期报文中某个域的值为其他字符，则确定该域为其他域，并判断所述报文解析结果中是否包含所述其他域，并在所述报文解析结果中包含所述其他域时，判断所述其他域的值在所述预期报文中和在所述报文解析结果中是否一致，所述其他字符是指除所述第一字符、所述第二字符和所述第三字符之外的字符；
[0166]
若所述报文解析结果中包含所述其他域且所述其他域的值在所述预期报文中和在所述报文解析结果中一致，则判定所述其他域在所述报文解析结果中的核对结果为正确；
[0167]
若所述报文解析结果中不包含所述其他域，或者包含所述其他域且所述其他域的值在所述预期报文中和在所述报文解析结果中不一致，则判定所述其他域在所述报文解析结果中的核对结果为错误。
[0168]
可选地，上述第一获取模块71具体用于：
[0169]
获取所述支付应用在交易过程中产生的交易日志；
[0170]
根据第一关键字和/或第二关键字，使用预设的正则表达式，从所述交易日志中截取所述实际报文，所述第一关键字表征所述支付应用在交易过程中上送的报文的截取开始位置，所述第二关键字表征所述支付应用在交易过程中接收的报文的截取开始位置。
[0171]
可选地，上述第二获取模块73具体用于：
[0172]
根据第三关键字从目标文档中读取所述预期报文，所述第三关键字表征所述预期报文的读取开始位置，所述目标文档存储有所述预期报文。
[0173]
可选地，上述报文解析模块72具体用于：
[0174]
调用报文解析接口，以根据配置文件定义的数据格式，解析所述实际报文。
[0175]
可选地，上述报文核对装置包括：
[0176]
接口调用模块，用于调用报文指定域接口，以从所述报文解析结果中获取指定域的值；
[0177]
交易执行模块，用于根据所述指定域的值，执行所述支付应用的特殊交易。
[0178]
需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本技术方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。
[0179]
图8是本技术实施例四提供的终端设备的结构示意图。如图8所示，该实施例的终
端设备8包括：一个或多个处理器80(图中仅示出一个)、存储器81以及存储在所述存储器81中并可在所述处理器80上运行的计算机程序82。所述处理器80执行所述计算机程序82时实现上述各个报文核对方法实施例中的步骤
[0180]
所述终端设备8可以是手机、销售点(point of sales，pos)机、桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于，处理器80、存储器81。本领域技术人员可以理解，图8仅仅是终端设备8的示例，并不构成对终端设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入输出设备、网络接入设备、总线等。
[0181]
所称处理器80可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
[0182]
所述存储器81可以是所述终端设备8的内部存储单元，例如终端设备8的硬盘或内存。所述存储器81也可以是所述终端设备8的外部存储设备，例如所述终端设备8上配备的插接式硬盘，智能存储卡(smart media card，smc)，安全数字(secure digital，sd)卡，闪存卡(flash card)等。进一步地，所述存储器81还可以既包括所述终端设备8的内部存储单元也包括外部存储设备。所述存储器81用于存储所述计算机程序以及所述终端设备所需的其他程序和数据。所述存储器81还可以用于暂时地存储已经输出或者将要输出的数据。
[0183]
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。上述装置中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0184]
本技术实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。
[0185]
本技术实施例还提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时实现可实现上述各个方法实施例中的步骤。
[0186]
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
[0187]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0188]
在本技术所提供的实施例中，应该理解到，所揭露的装置/终端设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/终端设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
[0189]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0190]
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
[0191]
以上所述实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。