CN114840410A - 测试分析方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请实施例提出一种测试分析方法、装置、计算机设备及存储介质，涉及互联网技术领域，该方法包括：获取待测试程序对应的测试源码，并基于测试源码构建抽象语法树；对抽象语法树进行分析，获取待测试程序对应的接口函数列表，并对接口函数列表中的各个接口函数配置测试用例参数；对抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，并对各个函数断点配置测试操作参数，参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数；测试用例参数和测试操作参数用于对待测试程序进行测试。通过本申请，可以配置测试用例参数和测试操作参数，从而提高测试效率。

Description

测试分析方法、装置、计算机设备及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种测试分析方法、装置、计算机设备及存储介质。

背景技术

随着互联网科技技术的不断发展，计算机设备中的各种应用程序应运而生。针对计算机设备中的各种应用程序，程序测试是软件开发中一个重要的环节。

现有技术实现程序测试，往往是基于测试框架对代码进行单元测试，或者结合mock测试屏蔽外部依赖，为单元测试提供补充。现有方案中，主要停留在编写测试用例，生成mock测试代码，mock操作等维度，需要用户根据问题表现，多次重复测试操作步骤才能顺利完成一次完整的程序测试，这样的测试方法操作繁琐，并且测试效率较低。

发明内容

本申请实施例提出了一种测试分析方法、装置、计算机设备及存储介质，可以提高测试效率。

本申请实施例一方面提供了一种测试分析方法，所述方法包括：

获取待测试程序对应的测试源码，并基于所述测试源码构建抽象语法树；

对所述抽象语法树进行分析，获取所述待测试程序对应的接口函数列表，并对所述接口函数列表中的各个接口函数配置测试用例参数；

对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，并对各个函数断点配置测试操作参数，所述参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数；

所述测试用例参数和测试操作参数用于对所述待测试程序进行测试。

本申请实施例一方面提供了一种测试分析装置，所述装置包括：

获取单元，用于获取待测试程序对应的测试源码；

构建单元，用于基于所述测试源码构建抽象语法树；

分析单元，用于对所述抽象语法树进行分析，获取所述待测试程序对应的接口函数列表；

配置单元，用于对所述接口函数列表中的各个接口函数配置测试用例参数；

分析单元，用于对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点；

配置单元，还用于对各个函数断点配置测试操作参数，所述参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数，所述测试用例参数和测试操作参数用于对所述待测试程序进行测试。

本申请实施例一方面提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述各实施例中的方法。

本申请实施例一方面提供了一种计算机存储介质，计算机存储介质存储有计算机程序，计算机程序包括程序指令，程序指令当被处理器执行时，执行上述各实施例中的方法。

本申请实施例一方面提供了一种计算机程序产品或计算机程序，计算机程序产品或计算机程序包括计算机指令，计算机指令存储在计算机可读存储介质中，计算机指令被终端设备的处理器执行时，执行上述各实施例中的方法。

通过本申请实施例的测试分析方法，首先，计算机设备可以获取待测试程序对应的测试源码，并基于测试源码构建抽象语法树；然后，计算机设备可以基于抽象语法树进行分析，获取待测试程序对应的接口函数列表，并对接口函数列表中的各个接口函数配置测试用例参数进行配置；并且，计算机设备对抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，并对各个函数断点配置测试操作参数，其中，参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数；最后，计算机设备将测试用例参数和测试操作参数用于对待测试程序进行测试。由于本申请的方法旨在对测试用例参数和测试操作参数进行配置，以根据测试用例参数和测试操作参数对待测试程序进行测试，相比于编写每个待测试程序对应的测试函数而言，通过本申请提供的方法使得用户可以专注于维护测试用例(包括测试用例参数和测试操作参数)，针对不同的待测试程序，只需要修改测试用例参数和测试操作参数即可，减少了测试的操作步骤，用户所需的操作较为简单，因此提高了测试效率。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种程序测试系统的结构示意图；

图2a是本申请实施例提供的一种集成开发环境的界面示意图；

图2b是本申请实施例提供的一种对待测试程序进行测试的界面示意图；

图2c是本申请实施例提供的一种第一交互界面的示意图；

图2d是本申请实施例提供的一种第二交互界面的示意图；

图3是本申请实施例提供的一种测试分析方法的流程示意图；

图4是本申请实施例提供的一种配置测试用例参数的流程示意图；

图5是本申请实施例提供的一种配置测试操作参数的流程示意图；

图6是本申请实施例提供的一种测试分析装置的结构示意图；

图7是本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素，此外，本申请不同实施例中具有同样命名的部件、特征、要素可能具有相同含义，也可能具有不同含义，其具体含义需以其在该具体实施例中的解释或者进一步结合该具体实施例中上下文进行确定。

应当理解，尽管在本文可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本文范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语"如果"可以被解释成为“在……时”或“当……时”或“响应于确定”。

为了能够更好地理解本申请实施例，下面对本申请实施例涉及的专业术语进行介绍：

单元测试：单元测试(unit testing)，是软件测试领域的一种常见方法，主要用来对软件的各个单元/组件的功能正确性进行验证。具体来说，单元测试是指对软件中的最小可测试单元进行检查和验证，对于单元测试中单元的含义，一般要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是保证软件质量的重要方法。不同的编程语言都有配套的单元测试框架，如Go语言使用内置的gotest进行测试。

Mock测试：mock测试是单元测试的重要辅助手段。具体来说，mock测试就是在测试过程中，对于某些不容易构造(如HttpServletRequest必须在Servlet容器中才能构造出来)或者不容易获取的比较复杂的对象(如JDBC中的ResultSet对象)，用一个虚拟的对象(mock对象)来创建以便测试的测试方法。代码中会涉及到与外部的诸多交互，如RPC请求、访问MySQL、Redis等组件。单元测试时如果待测试路径中涉及上述依赖时，为方便验证代码逻辑本身、模拟各种外部问题场景，需通过mock操作来辅助完成单元测试。通俗地理解，mock就是用精心设计的一些操作来替换代码逻辑中的默认操作，以方便模拟不同问题场景。Go语言可以使用mockgen、gomonkey等辅助mock测试。

研发效能：研发效能关注的不仅仅是用户的研发效率，也要关注研发的质量。敏捷开发模式下，用户尤其需要关注单元测试的质量。互联网产品快速迭代过程中，既要关注研发效率，又要关注质量，这对用户提出了十分苛刻的要求，必须提供更便捷高效的工具支撑才能更好地兼顾效率与质量的问题。在一些实施例中，用户可以指开发人员。

TDD：Test-Driven Development，测试驱动开发。

DWARF：Debugging With Attributed Record Formats，使用属性记录格式进行调试。

AST：Abstract Syntax Tree，是源代码的抽象语法结构的树状表示，树上的每个节点都表示源代码中的一种结构，这所以说是抽象的，是因为抽象语法树并不会表示出真实语法出现的每一个细节，比如说，嵌套括号被隐含在树的结构中，并没有以节点的形式呈现。抽象语法树并不依赖于源语言的语法，也就是说语法分析阶段所采用的上下文无文文法，因为在写文法时，经常会对文法进行等价的转换(消除左递归，回溯，二义性等)，这样会给文法分析引入一些多余的成分，对后续阶段造成不利影响，甚至会使合个阶段变得混乱。因些，很多编译器经常要独立地构造语法分析树，为前端，后端建立一个清晰的接口。并且，抽象语法树在很多领域有广泛的应用，比如浏览器，智能编辑器，编译器。

栈帧：也叫过程活动记录，是编译器用来实现过程/函数调用的一种数据结构。实际上，可以简单理解为：栈帧就是存储在用户栈上的(当然内核栈同样适用)每一次函数调用涉及的相关信息的记录单元。具体来说，栈帧表示程序的函数调用记录，而栈帧又是记录在栈上面，很明显栈上保持了N个栈帧的实体，那就可以说栈帧将栈分割成了N个记录块，但是这些记录块大小不是固定的，因为栈帧不仅保存诸如：函数入参、出参、返回地址和上一个栈帧的栈底指针等信息，还保存了函数内部的自动变量(甚至可以是动态分配内存，alloca函数就可以实现，但在某些系统中不行)，因此，不是所有的栈帧的大小都相同。

基于以上分析，本申请实施例提供的一种测试分析方法，可以工具化实现的，具体可以应用到如下场景：例如，可以将本申请实施例提供的测试分析方法实现为一个命令行工具，或者一个继承开发环境的插件，都是可行的。后续，用户只需使用该命令行工具或者插件，即可完成对待测试程序的测试工作，减少了操作步骤，操作简单，并且提高了对待测试程序的测试效率。

请参见图1，图1是本申请实施例提供的一种程序测试系统的结构示意图。该程序测试系统包括服务器140以及终端设备集群，其中，终端设备集群可以包括：终端设备110、终端设备120、...、终端设备130等。终端设备集群与服务器140可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

图1所示的服务器140可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

图1所示的终端设备110、终端设备120、终端设备130等可以是手机、平板电脑、笔记本电脑、掌上电脑、移动互联网设备(MID，mobile internet device)、车辆、路边设备、飞行器、可穿戴设备，例如智能手表、智能手环、计步器等具有各种操作系统的硬件设备；也可以是配置在上述硬件设备中的软件，如应用程序。其中，操作系统可以但不限于包括Android(安卓)操作系统、IOS操作系统，Android系统是一种基于Linux的自由及开放源代码的操作系统，IOS系统是苹果公司为移动设备所开发的专有移动操作系统。

其中，图1所示的终端设备110、终端设备120、终端设备130等配置有待测试程序和执行测试指令的测试执行引擎，可以理解的，测试执行引擎与所在终端设备的操作系统类型相适配，不同终端设备中的待测试程序可以相同也可以不同。

在一种可能的实现方式中，以终端设备110为例进行详细说明。服务器140获取终端设备110对应的待测试程序，服务器140获取待测试程序对应的测试源码，服务器140基于测试源码构建抽象语法树；服务器140对所述抽象语法树进行分析，获取所述待测试程序对应的接口函数列表，并对所述接口函数列表中的各个接口函数配置测试用例参数进行配置；服务器140对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，并对各个函数断点配置测试操作参数，所述参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数；其中，测试用例参数和测试操作参数用于对所述待测试程序进行测试。

进一步地，服务器140向终端设备110发送测试指令，其中，测试指令包括测试用例参数和测试操作参数，以使终端设备110根据测试用例参数和测试操作参数对待测试程序进行测试。后续，终端设备110可以根据测试用例参数和测试操作参数对待测试程序进行测试生成的测试反馈信息发送至服务器140。

当然，本申请实施例提供的测试分析方法所涉及的操作步骤也可以由终端设备110执行，或者终端设备集群中的任意终端设备执行。具体来说，服务器140向终端设备110发送测试指令，测试指令包括待测试程序的程序标识，终端设备110根据待测试程序的程序标识获取待测试程序以及待测试程序对应的测试源码，并基于所述测试源码构建抽象语法树。然后，终端设备110对所述抽象语法树进行分析，获取所述待测试程序对应的接口函数列表，并对所述接口函数列表中的各个接口函数配置测试用例参数进行配置。然后，终端设备110对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，并对各个函数断点配置测试操作参数，所述参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数。最后，终端设备110根据测试用例参数和测试操作参数对待测试程序进行测试。

进一步地，可以将本申请提供的测试分析方法可以在终端设备110中的集成开发环境中以插件形式提供，用户只需点击终端设备110中的插件，即可完成对待测试程序的测试工作。

当然，本申请提供的测试分析方法的具体执行步骤也可以集成于终端设备中的测试执行引擎中，即可直接通过终端设备中的测试执行引擎对待测试程序进行测试操作，无需引入服务器对终端设备中的待测试程序进行测试操作。

可以理解的是，本申请实施例描述的系统架构示意图是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

请参见图2a，图2a是本申请实施例提供的一种集成开发环境的界面示意图。具体的，集成开发环境运行在终端设备中，在集成开发环境中安装有测试插件。如图2a所示，终端设备中显示了集成开发环境对应的界面，该界面中包含测试插件，该测试插件可以用于对待测试程序进行测试操作。

在一种可能的实现方式中，测试插件可以安装在集成开发环境的工具栏窗口，并且测试插件和其他的工具，例如工具1(50)，工具2(60)，工具3(70)等并行排列。测试插件包括“个人中心”控件(10)，“在线测试”控件(20)，“离线测试”控件(30)以及“离线信息查看”控件(40)。用户可以点击“个人中心”控件，当用户点击“个人中心”控件之后，可以在终端设备的界面中显示个人中心对应的界面。具体的，个人中心对应的界面可以展示当前登录人，以及当前登录人(测试人员)需要负责的用户反馈问题。个人中心对应的界面还可以展示项目栏，开发者在该项目栏中可以选择当前对应的产品。另外，个人中心对应的界面可以展示创建时间、反馈ID，反馈内容，反馈人，在线操作，离线操作，日志查看等。对于每一条需要处理的反馈问题，开发者可以直接发起在线测试，离线测试或者离线信息查看。其中，在线操作对应“在线测试”控件，测试人员可以触发“在线测试”控件，即代表测试人员发起一次在线测试；同样的，离线操作对应“离线测试”控件，测试人员可以触发“在线测试”控件，即代表测试人员发起一次离线测试；同样的，日志查看对应“日志查看”控件，测试人员可以触发“日志查看”控件，即代表测试人员可以查看离线测试情况下对待测试程序进行测试后的测试反馈信息。

请参见图2b，图2b是本申请实施例提供的一种对待测试程序进行测试的界面示意图。如图2b所示，当测试人员发起在线测试后，可以从图2a所示的界面跳转至图2b所示的在线测试界面。在线测试界面中，测试人员可以在代码窗口针对需要测试的待测试程序设置响应的断点信息，其中，断点信息包括至少一个函数断点。具体的，测试人员可以点击启动按钮启动测试，即可完成测试指令的下发。命令执行成功以后，在图2b所示的在线测试界面的左侧展示断点堆栈调用信息(如图2b中堆栈展示区所示)，在线调试界面的右侧展示函数断点处对应的函数变量等信息(如图2b中结果展示区所示)，测试人员点击在线调试界面左侧的堆栈时，还能进行简单的代码跳转，便于查看，从而便于测试人员查看此次测试过程的测试反馈结果。

请参见图2c，图2c是本申请实施例提供的一种第一交互界面的示意图。在一种可能的实现方式中，计算机设备对抽象语法树进行分析，获取待测试程序对应的接口函数列表，并对接口函数列表中的各个接口函数配置测试用例参数进行配置时，可以显示第一交互界面，其中，第一交互界面包括接口函数列表、以及接口函数列表中每一个接口函数的请求参数配置项以及响应参数配置项。用户可以在第一交互界面中填写数据，具体为，用户可以在第一交互界面中的请求参数配置项中为一个或者多个接口函数配置请求参数，以及用户可以在第一交互界面中的响应参数配置项中为一个或者多个接口函数配置响应参数。当然，请求参数和响应参数即可作为测试用例对应的测试用例参数。如图2c所示，第一交互界面中包括接口函数列表，接口函数列表可以包括接口函数1、接口函数2、接口函数3、接口函数4等等，以及每个接口函数对应的请求参数配置项和响应参数配置项，用户可以在对应的请求参数配置项输入需要的请求参数，以及对应的响应参数配置项处输入需要的响应参数。对接口函数列表中所有的接口函数的请求参数配置项和响应参数配置项均配置完成之后，用户可以点击第一交互界面中的右上方处的“测试”按钮，即可启动对接口函数的测试。当然，用户也可以每对一个接口函数对应的请求参数额响应参数配置完成之后，即可启动一次对该接口函数的测试。

请参见图2d，图2d是本申请实施例提供的一种第二交互界面的示意图。在一种可能的实现方式中，计算机设备在对待测试程序进行运行测试过程中，当运行至函数断点位置时，显示第二交互界面，其中，第二交互界面包括该断点位置对应的函数信息、输入值配置项以及返回值配置项。用户可以在第二交互界面中填写数据，具体为，用户可以在第二交互界面中的输入值配置项中为一个或者多个参考接口函数配置函数入参信息，以及用户可以在第二交互界面中的返回值配置项中为一个或者多个参考接口函数配置的函数出参信息。并且，函数入参信息和函数出参信息作为测试操作参数。如图2d所示，第一交互界面中包括目标参考接口函数，其中，目标参考接口函数是指接口函数列表的接口函数中当前正在被测试的接口函数。目标参考接口函数可以包括函数断点1、函数断点2、函数断点3、函数断点4等等，以及每个函数断点对应的输入值配置项和返回值配置项，用户可以在对应的输入值配置项输入需要的函数入参信息，以及对应的返回值配置项处输入需要的函数出参信息。

通过本申请实施例提供的队程序的测试分析方法，可以允许以交互式方式输入mock数据，即用户可以在第一交互界面中输入测试用例参数，以及用户可以在第二交互界面中输入测试操作参数。后续，可以直接基于交互式方式完成对测试用例的重写操作，使得测试过程操作简单，并且提高了测试效率。

请参见图3，图3是本申请实施例提供的一种测试分析方法的流程示意图。该方法应用于计算机设备。如图3所示，该测试分析方法可包括步骤S310～S330。其中：

步骤S310：获取待测试程序对应的测试源码，并基于所述测试源码构建抽象语法树。

具体实现时，为了能够正确识别出需要进行mock的所有函数，必须对源代码(测试源码)建立足够的认识，因此，计算机设备获取待测试程序对应的测试源码之后，接着，计算机设备解析测试源码并构建抽象语法树AST。

在一种可能的实现方式中，计算机设备构建抽象语法树AST之后，通过AST识别出所有的RPC调用、数据库访问、Redis访问等函数调用语句，或者匹配用户自定义规则的任意函数。识别出这类函数的目的，是为了方便后面添加“函数断点”，以在函数断点处停下来与用户交互，获取被mock函数的输入参数、期望出参。

具体来说，在代码测试过程中，mock测试指的是mock一些涉及外部依赖的函数，比如访问网络、数据库等，单元测试是要做到与外部环境无关，即便没有实际部署数据库、没有网络，也要对代码进行测试。所以这里就需要mock(可以理解成替换)掉涉及访问网络、数据库等的这样的一些函数。那么，识别这些函数的具体做法可以为：在开发框架建设比较规范的企业中，对网络、数据库等的访问，通常都会以rpc的形式进行调用，如rsp，err：＝dbClientProxy.Select(ctx，req)，这样的函数是有规律可循的，“基于AST的源代码理解”，主要是为了识别出代码中对这类函数的调用，为后面mock测试做准备。

通过上述方法，在测试过程中进行数据mock至少存在以下好处：(1)可以用来解除测试对象对外部服务的依赖(比如数据库，第三方接口等)，使得测试用例可以独立运行；(2)替换外部服务调用，提升测试用例的运行速度。任何外部服务调用至少是跨进程级别的消耗，甚至是跨系统、跨网络的消耗，而Mock可以把消耗降低到进程内；(3)提升测试效率。具体来说，测试效率有两层含义：第一层含义是单位时间运行的测试用例数，这是运行速度提升带来的直接好处；第二层含义是一个测试人员单位时间创建的测试用例数。

在一种可能的实现方式中，用户编码阶段，期望对服务进行测试，接下来可以具体以go程序服务接口测试为例进行描述。首先，计算机设备通过编译工具链对待测试程序进行编译，需要说明的是，在编译过程中务必带上调试信息。如go程序在编译时需通过`gobuild-gcflags＝”all＝-N-l”`来确保构建程序包含了调试器、链接器生成的使用属性记录格式的调试信息进行调试(Debugging With Attributed Record Formats，DWARF)，缺失这部分信息将使得失去调试支持。

其中，将程序源代码构建为可执行程序，需要经过编译、链接过程，这个过程中会可选地生成一些辅助信息，比如这里提到的调试信息，通过这些调试信息获取内存地址处的某个变量对应的类型信息、名称、源代码中的定义位置等等，除了这些还有其他调试相关的信息，这些统称为调试信息。

步骤S320：对所述抽象语法树进行分析，获取所述待测试程序对应的接口函数列表，并对所述接口函数列表中的各个接口函数配置测试用例参数进行配置。

举例来说，计算机设备对测试源码进行AST分析，如通过go标准库`parser.ParseDir()`对整个工程进行分析，确定服务包含的接口函数。并且，接口函数一定是有规律可循的，以Google远程过程调用(Google Remote Procedure Call，grpcgRPC)为例，通常grpc服务注册是通过执行语句`pb.RegisterService(server，serviceImpl)`来实现的，其中server对应一个grpc server。因此，serviceImpl是一个service接口的实现，该service接口在package pb中予以定义。通过go ast分析，计算机设备可以遍历抽象语法树找到对应的语句，并进一步获取对应的参数serviceImpl类型信息，包括其上定义的导出方法列表，接口函数就包含在这些导出方法列表中。进一步结合package pb中的service接口方法，可以剔除不是接口的函数。

其中，举例来说，比如基于grpc框架进行开发，通常会包括如下几个部分：(1)协议，通过protobuf编写协议文件，里面定义好服务接口，接口请求参数、响应参数；(2)自动代码生成，通过protoc、protoc-gen-go基于上述协议文件转换成go代码，其中包括：Service接口定义；(3)用户自行编写service接口实现代码，即serivceImpl。这里的AST分析，只需要分析出service接口或者serviceImpl的导出方法，这些方法都应该有对应的单元测试函数。

进一步地，举例来说，假定有如下协议文件(pb文件)：

文件名：hello.proto

Package hello；

Message req{}

Message rsp{}

Service hello_service{

Rpc Hello(req)returns(rsp)；

}

Protoc–go_out＝.Hello.proto

会生成一个go文件hello.pb.go，

其中会有一个接口定义：

type HelloService interface{

Hello(ctx context.Context,req Req)(rsp,error)

}

开发写代码的时候会实现这样的一个类型：

Type helloServiceImpl struct{

}

func(s*helloServiceImpl)Hello(ctx context.Context,req*pb.Req,rsp*pb.Rsp)error{'

....

}

基于以上pb文件，通过AST分析该类型，识别出其中的方法func(s*helloServiceImpl)Hello(ctx,req,rsp)error，对于该示例而言，分析出的方法列表中就是这个函数。

步骤S330：对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，并对各个函数断点配置测试操作参数，所述参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数。

具体来说，在测试方法中集成符号级调试能力，如通过调试器暴露的JSON RPC接口请求调试器在待mock函数位置处自动添加函数断点，并获取被调试进程(当前测试服务)的暂停事件，然后和用户通过某种方式进行交互，如弹出WEB表单、Native应用程序界面或者命令行的方式，总之通过交互以获取被mock函数的返回值信息。然后继续通过调试器JSON RPC接口请求设置被调试进程当前调用函数栈帧的返回值信息。

在一种可能的实现方式中，计算机设备对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点的具体过程主要包括：首先，计算机设备遍历所述抽象语法树并进行分析，确定目标参考接口函数，所述目标参考接口函数是指所述接口函数列表的接口函数中当前正在被测试的接口函数。

然后，计算机设备对所述目标参考接口函数进行分析，确定所述目标参考接口函数对应的至少一个目标函数语句以及所述各个目标函数调用语句各自对应的源文件位置。

最后，计算机设备根据各个目标函数调用语句各自对应的源文件位置，请求所述测试服务模块在所述参考接口函数中添加函数断点，其中，在一个源文件位置处添加有一个函数断点。需要说明的是，目标函数语句是指所有的RPC调用语句、数据库访问、Redis访问语句，或者匹配用户自定义规则的函数调用语句。其中，测试服务模块是指具有debuggerserver的能力的模块。

举例来说，以访问数据库为例。假定有个账号数据库，现在初始化一个对应的一个客户端来访问此数据库，大致的代码如下：

1 clientProxy,err:＝mysql.NewClientProxy(ctx,“account”,“user”,“passwd”)

2 if err！＝nil{

3 panic(err)

4}

5 name,err:＝clientProxy.Query(ctx,“select name from user where id＝？”,id)

6 if err！＝nil{

7 return err

8}

上面的代码先初始化一个client，然后通过client查询用户id为`id`的用户名。涉及到网络访问的语句为clientProxy.Query这个函数调用，在前面AST分析确定这个函数需要mock的情况下，可以在源码行5这里设置函数断点。

当程序停在此位置之后，通过界面交互，借助AST分析，可以知道这里有什么输入变量(如id)、输出变量(name、err)，以及其类型(类型表明了数据在内存中的存储形式)。可以让用户来输入，如id字段输入10000，对应输出为name＝xiaoming，err＝nil，甚至可以允许输入多个用例：

Id＝10000,name＝xiaoming,err＝nil

Id＝20000,name＝xiaohong,err＝nil

Id＝-1,name＝””,err＝not found

这些用例会被记录下来，后续沉淀为mock测试的设置代码。

最后，将步骤S320和步骤S330分别配置的测试用例参数和测试操作参数用于对待测试程序进行测试操作。

在一种可能的实现方式中，计算机设备对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，并对各个函数断点配置测试操作参数之后。本方案要求在用户输入测试数据之后，能够自动化生成测试函数、mock测试桩代码、mock特定函数的设置代码。其中，这里的设置代码，主要指的是mock测试设置，比如gomonkey.ApplyFunc、gomonkey.ApplyMethod。至于如何生成代码，这必然要建立在测试源码的充分认识基础上。基于对测试源码的理解和基于AST的代码重写，将使得能够在现有代码基础上修改代码，如某个测试函数中采用了表驱动的测试，可以实现在表中继续追加用户输入的新的用例数据，并自动添加对应的mock设置代码。

通过本申请实施例提供的测试分析方法，用户补充一个测试用例，对应的代码执行路径上的所有mock测试准备工作，一次就可以全部完成，而且是以交互界面输入的方式，非常直观方便，减少了以往的“测试失败->补充mock->测试失败->补充mock”这样频繁的中断开发测试流程的情况，用户可以更加专注的完成手上的工作。并且，用户真正地有意愿、有时间精心维护有价值测试用例，切实提高了服务质量，而不再是迫于测试覆盖率的数据指标而应付。既更好地提高了代码质量，消灭了代码中的问题，也比以往大大提高了效率。

请参见图4，图4是本申请实施例提供的一种配置测试用例参数的流程示意图。该方法应用于计算机设备。其中，图4实施例为图3实施例中步骤S320中的一个具体实施例。如图4所示，该测试分析方法可包括步骤S410～S430。其中：

步骤S410：显示第一交互界面，所述第一交互界面包括所述接口函数列表、以及所述接口函数列表中每一个接口函数的请求参数配置项以及响应参数配置项。

具体实现时，其中，第一交互界面包括但不限于：WEB表单、Native应用程序界面或者命令行。结合图3实施例中对服务接口列表(导出方法列表)的理解，可以动态构建一个交互界面(第一交互界面)，其中包含了接口函数列表，以及每个接口函数对应的请求参数列表、响应参数列表，用户可以在这个第一交互界面中填写请求参数信息以及期望的响应结果信息。这部分数据在后续将作为一个测试用例的输入、输出。当用户输入了请求、响应信息之后(其实这就是一个测试用例数据)，点击页面上的按钮请求对服务接口函数进行测试。此时将进一步触发如下操作。

在一种可能的实现方式中，第一交互界面还包括测试按钮(如图2c所示)，计算机设备接收所述目标用户针对所述测试按钮的触发操作。计算机设备响应所述触发操作生成远程过程调用请求，并请求通过服务端口发送调试命令，所述调试命令用于指示测试服务模块在各个参考接口函数中添加函数断点。其中，测试服务模块具有debugger server(调试服务器)的能力。计算机设备向所述测试服务模块发送所述远程过程调用请求，所述远程过程调用请求用于请求对所述待测试程序进行运行测试。并且，远程过程调用请求包括接口函数、以及所述接口函数对应的请求参数和响应参数。

步骤S420：在所述第一交互界面中获取用户输入数据，所述用户输入数据包括：在所述请求参数配置项中为一个或者多个接口函数配置的请求参数、在所述响应参数配置项中为一个或者多个接口函数配置的响应参数。

具体实现时，请参见图2c，计算机设备可以在第一交互界面中输入请求参数和响应参数。具体来说，第一交互界面中包括接口函数列表，接口函数列表可以包括接口函数1、接口函数2、接口函数3、接口函数4等等，以及每个接口函数对应的请求参数配置项和响应参数配置项，用户可以在对应的请求参数配置项输入需要的请求参数，以及对应的响应参数配置项处输入需要的响应参数。对接口函数列表中所有的接口函数的请求参数配置项和响应参数配置项均配置完成之后，用户可以点击第一交互界面中的右上方处的“测试”按钮，即可启动对接口函数的测试。当然，用户也可以每对一个接口函数对应的请求参数额响应参数配置完成之后，即可启动一次对该接口函数的测试。

在一种可能的实现方式中，计算机设备请求通过服务端口发送调试命令之前，还包括：首先，通过后台进程模式启动并运行所述测试服务模块。然后，启动调试器，启动的所述调试器用于跟踪所述待测试程序对应的程序执行状态，并用于在所述服务端口开启监听接收所述远程过程调用请求，以及用于对所述待测试程序进行调试处理。其中，后台进程模式是指headless模式。

举例来说，针对构建好的程序，假定构建出的程序名为“__debug_bin”，将以headless模式启动运行一个debugger server。其中，headless模式指的是以daemon方式在后台运行，并不是前台进程与用户交互，比如go调试器dlv就是这样。如采用流行的go调试器go-delve/delve，执行命令`dlv exec path-to/__debug_bin–headless–listen＝127.0.0.1:8000`。其中，该命令具体是指：将加载程序path-to/__debug_bin，启动一个调试进程，并监听地址127.0.0.1:8000，并接受调试请求(如设置断点的请求)。此时dlv调试器将启动__debug_bin并跟踪其执行状态，同时在端口8000启动监听，允许接收JSON RPC请求响应对tracee__debug_bin的调试操作。其中，tracee是指：被调试进程，准确地说是，被调试线程。

接下来，对dlv调试器跟踪程序的执行状态做具体说明：根据进程的执行情况，程序的状态可以细分为几种状态，包括就绪、运行、挂起、退出等等，其中有一种状态是traced状态。这里的traced状态指的是被调试进程(专业术语tracee)正在被调试器(专业术语tracer)跟踪。被调试进程(tracee)会被内核暂停执行，tracer可以借助内核系统调用(如linux ptrace)对tracee的代码、数据等进行修改。

需要说明的是，本申请实施例引用调试跟踪技术的目的：写针对一个函数的单元测试时，代码执行路径上可能涉及到多个函数需要mock，人为确认有哪些函数需要mock费时、费力。调试器执行程序时是机器自动执行指令，其经过的代码执行路径上有哪些函数需要mock，这个不需要开发者提前知道，前面提到过通过AST技术可以分析出数据库访问、网络等相关的函数源代码位置，并基于调试器添加断点，当调试器执行到断点位置时，自然就会停下来，用户自然就知道当前要mock什么函数，只关心mock数据就可以，省时省力，因此可以提高单元测试的效率。

步骤S430：将所述请求参数和所述响应参数作为所述测试用例参数。

在一种可能的实现方式中，在前述步骤中已经分析出了服务接口方法列表(接口函数列表)，并且现在选择了某个接口函数并填写了请求、响应参数，当点击测试按钮之后。将通过反射动态构造一个rpc请求请求服务予以处理。其中，在计算机学中，反射(reflection)是指计算机程序在运行时(run time)可以访问、检测和修改它本身状态或行为的一种能力，用比喻来说，反射就是程序在运行的时候能够“观察”并且修改自己的行为。但是在发送此请求之前，要通过JSON RPC请求8000端口发送调试命令，请求debuggerserver(调试服务器，本申请是指测试服务模块)对tracee的服务接口方法的定义处添加函数断点，以方便接下来的操作，此时被测试服务处于暂停执行状态。

在一种可能的实现方式中，本申请实施例提供的待测试程序，测试前和测试后的程序，以及在第一交互界面和第二交互界面中填写的参数信息(测试用例参数、测试操作参数)等，均可以存储于区块链中。区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

本申请中，将测试用例参数和测试操作参数等存储于区块链中，有利于数据的安全，防止数据篡改。从而，进一步提高通过测试用例参数和测试操作参数对待测试程序进行测试的效率。

需要说明的是，通过本申请实施例提供的测试分析方法，是一种高效测试方法，在实际实现落地的时候，肯定要开发一款软件，这个软件中既要使用前面提及的调试能力，也要利用AST分析来识别哪些源代码位置需要添加函数断点。

请参见图5，图5是本申请实施例提供的一种配置测试操作参数的流程示意图。其中，图5实施例为图3实施例中步骤S330中的一个具体实施例。如图5所示，该测试分析方法可包括步骤S510～S530。其中：

步骤S510：在对所述待测试程序进行运行测试过程中，当运行至函数断点位置时，显示第二交互界面，所述第二交互界面包括该断点位置对应的函数信息、输入值配置项以及返回值配置项。

具体实现时，基于AST对源码进行分析，遍历找到当前正在被测试的服务接口函数，查找函数体，遍历函数体，从中以递归的形式筛选出所有的RPC调用语句、数据库访问、Redis访问语句，或者匹配用户自定义规则的函数调用语句，根据这些语句的源文件位置，请求debugger server全部为其添加断点。然后恢复执行，之后待测试程序将在执行代码路径上第一个断点处停下来，每个断点都是一个期望被mock的函数位置。当然，执行到任何一个函数断点的时候，都需要显示界面(第二交互界面)，这个界面(第二交互界面)如图2d所示，就是为了显示函数入参、出参类型的表单，让用户输入mock数据用的。

其中，当前正在被测试的服务接口函数是指：调试服务器(测试服务模块)启动调试程序时，通过系统调用exec+内核ptrace请求TRACEME来跟踪进程，进程的代码没有执行，会停下来等待tracer操作。“恢复执行”是指让其执行到下一个函数断点处，这个函数断点也是AST分析识别出的需要mock的函数位置。恢复执行是为了让测试程序执行到下一个需要mock的函数处停下来，与用户交互，好获取mock数据。这么做的目的是为了将开发者从“我需要mock哪些函数”的负担中解脱出来。

步骤S520：在所述第二交互界面中获取模拟操作数据，所述模拟操作数据包括：在所述输入值配置项中为一个或者多个参考接口函数配置的函数入参信息、在所述返回值配置项中为一个或者多个参考接口函数配置的函数出参信息。

具体实现时，请参见图2d，计算机设备可以在第二交互界面中输入函数入参信息和函数出参信息。具体来说，第一交互界面中包括目标参考接口函数，其中，目标参考接口函数是指接口函数列表的接口函数中当前正在被测试的接口函数。目标参考接口函数可以包括函数断点1、函数断点2、函数断点3、函数断点4等等，以及每个函数断点对应的输入值配置项和返回值配置项，用户可以在对应的输入值配置项输入需要的函数入参信息，以及对应的返回值配置项处输入需要的函数出参信息。

在一种可能的实现方式中，待测试程序继续执行，遇到第一个断点，该位置是一个期望被mock的函数，当停下来之后，查询debugger server(测试服务模块)会获得该程序已经暂停的状态变更事件。具体来说，由于进程有父子关系，子进程状态变化会通知父进程，被调试进程tracee(子进程)和调试器进程tracer(父进程)也有这样的关系。Tracee状态变化后，通知tracer，tracer才知道，现在执行到了一个需要mock的函数位置，可以将这个函数对应的出入参界面(第二交互界面)显示给用户了。在第二交互界面中，展示该源文件位置对应的函数信息、函数参数信息、返回值信息，这些信息也是基于AST对代码的理解。需要说明的是，函数信息、函数参数信息、返回值信息，要想方便人来理解，就是需要借助AST中的语言结构，AST是基于源码分析得到，并不是人为输入设置。

同样的，用户在第二交互界面上填写函数入参信息、函数出参信息。具体来说，填写的是出入参的值，即函数入参值和函数出参值。分析AST得到的是类型，用户基于每个类型填入具体的参数值。

在一种可能的实现方式中，计算机设备对各个函数断点配置测试操作参数之后，还包括：首先，通过测试服务模块进入目标参考函数的函数体，并通过栈帧描述条目获取目标参考函数对应的调用栈帧信息表。然后，根据调用栈帧信息表，获取目标参考函数对应的返回值地址信息。最后，在对目标参考函数运行结束之后，根据模拟操作数据对返回值地址信息进行修改处理。

举例来说，获得用户输入的mock数据后，将请求debugger server执行stepin指令以进入函数体，然后通过此栈帧的栈帧描述条目(Frame Description Entry，FDE)中包含的调用栈信息表，可以获得返回地址信息，可以将直接将返回地址设置为寄存器RIP的值，然后执行continue命令，此时待测试程序已经退出了函数。接下来通过AST分析或知当前函数的返回值列表信息，并根据用户输入的mock数据对返回值逐一进行赋值。

举例来说，在每一次单元测试中，可能涉及到多个函数需要mock，假定现在有两个函数f1、f2需要mock。当用户mock f1时，用户需要填写函数f1的mock数据(函数入参信息、函数出参信息)，在此基础上再去mock函数f2。如果想让代码执行能够正常执行到f2，要保证函数调用f1、f2之间的代码执行符合预期。如果涉及到f1的返回值赋值给变量的情况，要保证符合预期，就要保证函数f1的返回值是填写的mock的返回值数据(函数出参信息)，能够正确赋值给变量。因为后续逻辑可能是基于这个变量走不同的分支。所以，调试器必须要在该函数执行前、执行后做特殊处理，每个函数都有栈帧，通过FDE可以精确计算出其返回地址，在函数执行之后，利用mock数据篡改返回值，使得对变量的赋值正确。

综上所述，以此类推，重复上述过程，通过第二交互界面以获取被mock函数的返回值信息，然后继续通过调试器JSON RPC接口请求设置被调试进程当前调用函数栈帧的返回值信息。直到接口函数当前代码执行路径上的所有函数的mock数据都被设置完毕。

举例来说，以访问数据库为例。假定有个账号数据库，现在初始化一个对应的一个客户端来访问此数据库，大致的代码如下：

1 clientProxy,err:＝mysql.NewClientProxy(ctx,“account”,“user”,“passwd”)

2 if err！＝nil{

3 panic(err)

4}

5 name,err:＝clientProxy.Query(ctx,“select name from user where id＝？”,id)

6 if err！＝nil{

7 return err

8}

基于前面分析，在源码行5这里设置函数断点之后，当程序停在此位置之后，会有界面交互，借助AST分析，可以知道这里有什么输入变量(如id)、输出变量(name、err)，以及其类型(类型表明了数据在内存中的存储形式)。就可以让用户来输入，如id字段输入10000，对应输出为name＝xiaoming，err＝nil，甚至可以允许输入多个用例：

Id＝10000,name＝xiaoming,err＝nil

Id＝20000,name＝xiaohong,err＝nil

Id＝-1,name＝””,err＝not found

这些用例会被记录下来，后续沉淀为mock测试的设置代码。

步骤S530：将所述函数入参信息和所述函数出参信息作为所述测试操作参数。

具体实现时，本方案要求在用户输入测试数据之后，能够自动化生成测试函数、mock测试桩代码、mock特定函数的设置代码。具体来说，可以将把用户输入的所有数据进行记录，一开始输入的接口请求、响应参数将作为一个表驱动测试中的一个用例数据，请求作为接口调用的输入，响应作为输出，并用作后续的断言校验。过程中mock其他函数输入的数据将作为mock测试代码的输入、输出。

举例来说，一个被测试函数执行期间，当收集到了需要mock的函数f1、f2、f3…的mock数据后(函数入参信息、函数出参信息)，每个函数的mock数据，都会被记录下来。可以将基于这里的mock数据生成gomonkey设置代码。根据前面提到过一个name,err:＝accountClientProxy.Query(ctx,“select name from account where id＝？”,id)的例子。

可以生成这样的设置代码：

生成这样的设置代码才是的最终目的。并且后续可能希望补充param＝＝30000、40000时的情况，也需要对上述生成的代码进行AST修改、AST重写为代码的操作，都需要AST的支持。于是结合AST对测试代码的理解，在AST结构中动态添加新的测试函数或表驱动用例，最后完成AST到源代码的一个重写，实现自动化测试代码、自动化mock测试代码设置的生成工作。

综上所述，由于测试用例、测试代码、mock测试代码已经全部沉淀为测试源文件，后续用户可以像以前一样运行测试程序对测试覆盖率、测试用例通过率等进行验证，当发现测试覆盖率比较低、有些路径没有覆盖到的时候，可以随时重复前面的步骤来完成。

进一步地，本申请实施例所提供的测试分析方法所涉及到所有步骤均可以工具化实现。比如可以将其实现为一个命令行工具，或者一个继承开发环境的测试插件，都是可行的。这意味着，用户只要执行一个命令或者点一下测试插件按钮，就可以轻松完成添加一个测试用例所需要的全部的mock测试准备工作。

请参见图6，图6是本申请实施例提供的一种测试分析装置的结构示意图。图6是本申请实施例提供的一种测试分析装置的结构示意图。该测试分析装置可应用于图3～图5对应的方法实施例中的计算机设备。测试分析装置可以是运行于计算机设备中的一个计算机程序(包括程序代码)，例如该测试分析装置为一个应用软件；该装置可以用于执行本申请实施例提供的方法中的相应步骤。该测试分析装置可包括：

获取单元610，用于获取待测试程序对应的测试源码；

构建单元620，用于基于所述测试源码构建抽象语法树；

分析单元630，用于对所述抽象语法树进行分析，获取所述待测试程序对应的接口函数列表；

配置单元640，用于对所述接口函数列表中的各个接口函数配置测试用例参数；

分析单元630，还用于对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点；

配置单元640，还用于对各个函数断点配置测试操作参数，所述参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数，所述测试用例参数和测试操作参数用于对所述待测试程序进行测试。

在一种可能的实现方式中，配置单元640对所述接口函数列表中的各个接口函数配置测试用例参数，包括：

显示第一交互界面，所述第一交互界面包括所述接口函数列表、以及所述接口函数列表中每一个接口函数的请求参数配置项以及响应参数配置项；

在所述第一交互界面中获取用户输入数据，所述用户输入数据包括：在所述请求参数配置项中为一个或者多个接口函数配置的请求参数、在所述响应参数配置项中为一个或者多个接口函数配置的响应参数；

将所述请求参数和所述响应参数作为所述测试用例参数。

在一种可能的实现方式中，所述第一交互界面还包括测试按钮，本申请实施例提供的测试分析装置还包括：处理单元650。

处理单元650用于执行以下操作：

接收所述目标用户针对所述测试按钮的触发操作；

响应所述触发操作生成远程过程调用请求，并请求通过服务端口发送调试命令，所述调试命令用于指示测试服务模块在各个参考接口函数中添加函数断点；

向所述测试服务模块发送所述远程过程调用请求，所述远程过程调用请求用于请求对所述待测试程序进行运行测试，所述远程过程调用请求包括接口函数、以及所述接口函数对应的请求参数和所述接口函数对应的响应参数。

在一种可能的实现方式中，本申请实施例提供的测试分析装置还包括：启动单元660。

启动单元660用于在处理单元650请求通过服务端口发送调试命令之前，执行以下操作：

通过后台进程模式启动并运行所述测试服务模块；

启动调试器，启动的所述调试器用于跟踪所述待测试程序对应的程序执行状态，并用于在所述服务端口开启监听接收所述远程过程调用请求，以及用于对所述待测试程序进行调试处理。

在一种可能的实现方式中，分析单元630对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，包括：

遍历所述抽象语法树并进行分析，确定目标参考接口函数，所述目标参考接口函数是指所述接口函数列表的接口函数中当前正在被测试的接口函数；

对所述目标参考接口函数进行分析，确定所述目标参考接口函数对应的至少一个目标函数语句以及所述各个目标函数调用语句各自对应的源文件位置；

根据各个目标函数调用语句各自对应的源文件位置，请求所述测试服务模块在所述目标参考接口函数中添加函数断点，其中，在一个源文件位置处添加有一个函数断点。

在一种可能的实现方式中，配置单元640对各个函数断点配置测试操作参数，包括：

在对所述待测试程序进行运行测试过程中，当运行至函数断点位置时，显示第二交互界面，所述第二交互界面包括该断点位置对应的函数信息、输入值配置项以及返回值配置项；

在所述第二交互界面中获取模拟操作数据，所述模拟操作数据包括：在所述输入值配置项中为一个或者多个参考接口函数配置的函数入参信息、在所述返回值配置项中为一个或者多个参考接口函数配置的函数出参信息；

将所述函数入参信息和所述函数出参信息作为所述测试操作参数。

在一种可能的实现方式中，配置单元640对各个函数断点配置测试操作参数之后，处理单元650还用于执行以下操作：

通过所述测试服务模块进入所述目标参考函数的函数体，并通过栈帧描述条目获取所述目标参考函数对应的调用栈帧信息表；

根据所述调用栈帧信息表，获取所述目标参考函数对应的返回值地址信息；

在对所述目标参考函数运行结束之后，根据所述模拟操作数据对所述返回值地址信息进行修改处理。

请参见图7，图7是本申请实施例提供的一种计算机设备的结构示意图。上述图3～图5对应实施例中的计算机设备可以为计算机设备700，如图7所示，计算机设备700可以包括：用户接口702、处理器704、编码器706以及存储器708。信号接收器716用于经由蜂窝接口710、WIFI接口712、...、或NFC接口714接收或者发送数据。编码器706将接收到的数据编码为计算机处理的数据格式。存储器708中存储有计算机程序，处理器704被设置为通过计算机程序执行上述任一项方法实施例中的步骤。存储器708可包括易失性存储器(例如，动态随机存取存储器DRAM)，还可以包括非易失性存储器(例如，一次性可编程只读存储器OTPROM)。在一些实例中，存储器708可进一步包括相对于处理器1004远程设置的存储器，这些远程存储器可以通过网络连接至计算机设备700。用户接口7002可以包括：键盘718和显示器720。

在图7所示的计算机设备700中，处理器704可以用于调用存储器708中存储计算机程序，以实现：

获取待测试程序对应的测试源码，并基于所述测试源码构建抽象语法树；

对所述抽象语法树进行分析，获取所述待测试程序对应的接口函数列表，并对所述接口函数列表中的各个接口函数配置测试用例参数；

对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，并对各个函数断点配置测试操作参数，所述参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数；

所述测试用例参数和测试操作参数用于对所述待测试程序进行测试。

在一种可能的实现方式中，处理器704对所述接口函数列表中的各个接口函数配置测试用例参数，包括：

显示第一交互界面，所述第一交互界面包括所述接口函数列表、以及所述接口函数列表中每一个接口函数的请求参数配置项以及响应参数配置项；

在所述第一交互界面中获取用户输入数据，所述用户输入数据包括：在所述请求参数配置项中为一个或者多个接口函数配置的请求参数、在所述响应参数配置项中为一个或者多个接口函数配置的响应参数；

将所述请求参数和所述响应参数作为所述测试用例参数。

在一种可能的实现方式中，所述第一交互界面还包括测试按钮，所述方法处理器704还用于执行以下操作：

接收所述目标用户针对所述测试按钮的触发操作；

响应所述触发操作生成远程过程调用请求，并请求通过服务端口发送调试命令，所述调试命令用于指示测试服务模块在各个参考接口函数中添加函数断点；

向所述测试服务模块发送所述远程过程调用请求，所述远程过程调用请求用于请求对所述待测试程序进行运行测试，所述远程过程调用请求包括接口函数、以及所述接口函数对应的请求参数和所述接口函数对应的响应参数。

在一种可能的实现方式中，处理器704请求通过服务端口发送调试命令之前，还用于执行以下操作：

通过后台进程模式启动并运行所述测试服务模块；

启动调试器，启动的所述调试器用于跟踪所述待测试程序对应的程序执行状态，并用于在所述服务端口开启监听接收所述远程过程调用请求，以及用于对所述待测试程序进行调试处理。

在一种可能的实现方式中，处理器704对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，包括：

遍历所述抽象语法树并进行分析，确定目标参考接口函数，所述目标参考接口函数是指所述接口函数列表的接口函数中当前正在被测试的接口函数；

对所述目标参考接口函数进行分析，确定所述目标参考接口函数对应的至少一个目标函数语句以及所述各个目标函数调用语句各自对应的源文件位置；

根据各个目标函数调用语句各自对应的源文件位置，请求所述测试服务模块在所述目标参考接口函数中添加函数断点，其中，在一个源文件位置处添加有一个函数断点。

在一种可能的实现方式中，处理器704对各个函数断点配置测试操作参数，包括：

在对所述待测试程序进行运行测试过程中，当运行至函数断点位置时，显示第二交互界面，所述第二交互界面包括该断点位置对应的函数信息、输入值配置项以及返回值配置项；

在所述第二交互界面中获取模拟操作数据，所述模拟操作数据包括：在所述输入值配置项中为一个或者多个参考接口函数配置的函数入参信息、在所述返回值配置项中为一个或者多个参考接口函数配置的函数出参信息；

将所述函数入参信息和所述函数出参信息作为所述测试操作参数。

在一种可能的实现方式中，处理器704对各个函数断点配置测试操作参数之后，还用于执行以下操作：

通过所述测试服务模块进入所述目标参考函数的函数体，并通过栈帧描述条目获取所述目标参考函数对应的调用栈帧信息表；

根据所述调用栈帧信息表，获取所述目标参考函数对应的返回值地址信息；

在对所述目标参考函数运行结束之后，根据所述模拟操作数据对所述返回值地址信息进行修改处理。

应当理解，本申请实施例中所描述的计算机设备700可执行前文图3～图5所对应实施例中对测试分析方法的描述，也可执行前文图6对应实施例中对测试分析装置的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法、装置和系统，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的；例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式；例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

此外，这里需要指出的是：本申请实施例还提供了一种计算机存储介质，且计算机存储介质中存储有前文提及的测试分析装置所执行的计算机程序，且该计算机程序包括程序指令，当处理器执行上述程序指令时，能够执行前文图3～图5所对应实施例中的方法，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，程序指令可以被部署在一个计算机设备上，或者在位于一个地点的多个计算机设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算机设备上执行，分布在多个地点且通过通信网络互连的多个计算机设备可以组成区块链系统。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备可以执行前文图3～图5所对应实施例中的方法，因此，这里将不再进行赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上所揭露的仅为本申请的部分实施例而已，当然不能以此来限定本申请之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本申请权利要求所作的等同变化，仍属于发明所涵盖的范围。

Claims (10)

1.一种测试分析方法，其特征在于，所述方法包括：

获取待测试程序对应的测试源码，并基于所述测试源码构建抽象语法树；

对所述抽象语法树进行分析，获取所述待测试程序对应的接口函数列表，并对所述接口函数列表中的各个接口函数配置测试用例参数；

对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，并对各个函数断点配置测试操作参数，所述参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数；

所述测试用例参数和测试操作参数用于对所述待测试程序进行测试。

2.如权利要求1所述的方法，其特征在于，所述对所述接口函数列表中的各个接口函数配置测试用例参数，包括：

显示第一交互界面，所述第一交互界面包括所述接口函数列表、以及所述接口函数列表中每一个接口函数的请求参数配置项以及响应参数配置项；

在所述第一交互界面中获取用户输入数据，所述用户输入数据包括：在所述请求参数配置项中为一个或者多个接口函数配置的请求参数、在所述响应参数配置项中为一个或者多个接口函数配置的响应参数；

将所述请求参数和所述响应参数作为所述测试用例参数。

3.如权利要求2所述的方法，其特征在于，所述第一交互界面还包括测试按钮，所述方法还包括：

接收所述目标用户针对所述测试按钮的触发操作；

响应所述触发操作生成远程过程调用请求，并请求通过服务端口发送调试命令，所述调试命令用于指示测试服务模块在各个参考接口函数中添加函数断点；

向所述测试服务模块发送所述远程过程调用请求，所述远程过程调用请求用于请求对所述待测试程序进行运行测试，所述远程过程调用请求包括接口函数、以及所述接口函数对应的请求参数和所述接口函数对应的响应参数。

4.如权利要求3所述的方法，其特征在于，所述请求通过服务端口发送调试命令之前，还包括：

通过后台进程模式启动并运行所述测试服务模块；

启动调试器，启动的所述调试器用于跟踪所述待测试程序对应的程序执行状态，并用于在所述服务端口开启监听接收所述远程过程调用请求，以及用于对所述待测试程序进行调试处理。

5.如权利要求1所述的方法，其特征在于，所述对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点，包括：

遍历所述抽象语法树并进行分析，确定目标参考接口函数，所述目标参考接口函数是指所述接口函数列表的接口函数中当前正在被测试的接口函数；

对所述目标参考接口函数进行分析，确定所述目标参考接口函数对应的至少一个目标函数语句以及所述各个目标函数调用语句各自对应的源文件位置；

根据各个目标函数调用语句各自对应的源文件位置，请求所述测试服务模块在所述目标参考接口函数中添加函数断点，其中，在一个源文件位置处添加有一个函数断点。

6.如权利要求5所述的方法，其特征在于，所述对各个函数断点配置测试操作参数，包括：

在对所述待测试程序进行运行测试过程中，当运行至函数断点位置时，显示第二交互界面，所述第二交互界面包括该断点位置对应的函数信息、输入值配置项以及返回值配置项；

在所述第二交互界面中获取模拟操作数据，所述模拟操作数据包括：在所述输入值配置项中为一个或者多个参考接口函数配置的函数入参信息、在所述返回值配置项中为一个或者多个参考接口函数配置的函数出参信息；

将所述函数入参信息和所述函数出参信息作为所述测试操作参数。

7.如权利要求5所述的方法，其特征在于，所述对各个函数断点配置测试操作参数之后，还包括：

通过所述测试服务模块进入所述目标参考函数的函数体，并通过栈帧描述条目获取所述目标参考函数对应的调用栈帧信息表；

根据所述调用栈帧信息表，获取所述目标参考函数对应的返回值地址信息；

在对所述目标参考函数运行结束之后，根据所述模拟操作数据对所述返回值地址信息进行修改处理。

8.一种测试分析装置，其特征在于，所述装置包括：

获取单元，用于获取待测试程序对应的测试源码；

构建单元，用于基于所述测试源码构建抽象语法树；

分析单元，用于对所述抽象语法树进行分析，获取所述待测试程序对应的接口函数列表；

配置单元，用于对所述接口函数列表中的各个接口函数配置测试用例参数；

分析单元，用于对所述抽象语法树进行分析，确定参考接口函数集合中各个参考接口函数对应的至少一个函数断点；

配置单元，还用于对各个函数断点配置测试操作参数，所述参考接口函数集合中包括的参考接口函数为所述接口函数列表中的部分或者全部接口函数，所述测试用例参数和测试操作参数用于对所述待测试程序进行测试。

9.一种计算机设备，其特征在于，包括存储器以及处理器，所述存储器存储一组程序代码，所述处理器调用所述存储器中存储的程序代码，用于执行1～7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如权利要求1～7中任一项所述的方法。

Images