本发明属于软件测试技术领域，尤其涉及一种应用程序编程接口测试用例的生成方法及装置。
背景技术：
随着人们对软件质量的要求越来越高，软件测试也变得越来越重要。其中，应用程序编程接口(applicationprogramminginterface，api)测试作为一种有效实用且可以持续进行的测试方式就显得更加重要了。在api测试过程中，api测试用例作为测试指导，是软件测试质量稳定的根本保障。api测试用例的设计是api测试活动中最关键的一步，它是测试执行的正确性、有效性的基础。
但是，随着软件规模越来越大，导致一些功能模块的api庞杂繁多，牵涉的测试点越来越多，导致测试用例设计者很容易遗漏许多隐藏的测试点，而无法较全面的设计测试用例。然而这些隐藏的测试点又有可能是挖掘软件中存在但难以发现的质量隐患的测试点；因此，当测试用例设计者遗漏较多测试点时，将降低软件测试的覆盖率，影响软件的质量。
技术实现要素：
有鉴于此，本发明实施例提供了一种应用程序编程接口测试用例的生成方法及装置，以解决现有技术中由于测试点的遗漏，无法较全面的设计测试用例的问题。
本发明实施例的第一方面提供了一种应用程序编程接口api测试用例的生成方法，包括：
将模块中的多个api组合成测试api组合，所述测试api组合为模块中的多个api除按照正常业务流程排序形成的api组合外的api组合；
根据每个所述测试api组合结合应用场景编写测试覆盖点；
结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
本发明实施例的第二方面提供了一种应用程序编程接口api测试用例的生成方法，包括：
获取单个api的测试返回码，所述测试返回码为所述api的除操作成功返回码外的返回码；
针对所述api的每个所述测试返回码，结合应用场景分别编写测试覆盖点；
结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
本发明实施例的第三方面提供了一种应用程序编程接口api测试用例的生成装置，包括：
组合单元，用于将模块中的多个api组合成测试api组合，所述测试api组合为模块中的多个api除按照正常业务流程排序形成的api组合外的api组合；
第一编写单元，用于根据每个所述测试api组合结合应用场景编写测试覆盖点；
第一生成单元，用于结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
本发明实施例的第四方面提供了一种应用程序编程接口api测试用例的生成装置，包括：
获取单元，用于获取单个api的测试返回码，所述测试返回码为所述api的除操作成功返回码外的返回码；
第二编写单元，用于针对每个所述api的每个所述测试返回码，结合应用场景分别编写测试覆盖点；
第二生成单元，用于结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
本发明实施例的第五方面提供了一种应用程序编程接口api测试用例生成的终端设备，包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述第一方面和第二方面的生成方法的步骤。
本发明实施例的第六方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面和第二方面的生成方法的步骤。
本发明实施例基于现有技术中使用正向思维的方式设计api测试用例的基础上，提出一种基于逆向思维模拟应用场景的api测试用例的设计方法。即，破坏api间正常完整的业务流程，生成不同的测试api组合，并模拟、推导在实际应用中所述测试api组合可能发生的错误场景，然后结合所述测试api组合和模拟的所述错误场景，设计编写可能的隐藏的测试覆盖点，最后结合针对该测试覆盖点设计的测试数据输出有效的测试用例；或排除单个api的操作成功的返回码，得到测试返回码，模拟、推导在实际应用中所述api出现测试返回码时的错误场景，结合该api的返回码和模拟的所述错误场景分别编写测试覆盖点，最后结合针对该测试覆盖点设计的测试数据输出有效的测试用例，解决了现有技术中由于测试点的遗漏，无法较全面的设计测试用例的问题。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的一种应用程序编程接口api测试用例的生成方法的流程示意图；
图2是本发明实施例提供的另一种应用程序编程接口api测试用例的生成方法的流程示意图；
图3是本发明实施例提供的一种应用程序编程接口api测试用例的生成装置的示意图；
图4是本发明实施例提供的另一种应用程序编程接口api测试用例的生成装置的示意图；
图5是本发明实施例提供的应用程序编程接口api测试用例生成的终端设备的示意图。
具体实施方式
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。
为了说明本发明所述的技术方案，下面通过具体实施例来进行说明。
api的主要目的是提供应用程序与开发人员访问一组例程的能力，使得开发人员无需访问源码，或理解例程内部工作机制的细节，直接使用所述例程。提供api所定义的功能的软件称作此api的实现。api的设计使软件系统的职责得到合理划分，降低系统各部分的相互依赖，提高了组成单元的内聚性，降低了组成单元间的耦合程度，提高了系统的维护性和扩展性。
而api测试是软件测试的重要组成部分。在api测试过程中，api测试用例的设计是api测试活动中最关键的一步，是测试执行的正确性、有效性的基础。
但是，随着软件规模越来越大，导致一些功能模块的api庞杂繁多，牵涉的测试点越来越多，使得测试用例设计者较难实现较全面的设计测试用例，最终导致软件测试的覆盖率降低，影响软件的开发质量。
例如，现有技术中，对api测试用例的设计大多使用正向思维的方式进行，即主要按需求或接口文档，得到模块中每个api的功能，然后据此按每个api的功能和正常的业务流程，采用等价类划分、临界值、因果图等方法设计api测试用例。从表面上看该api测试用例的设计方法中测试信息点较全面，实际上却遗漏了大量测试覆盖点，并导致测试出来的程序比较脆弱，即影响了软件的开发质量。
本发明实施例基于现有技术中使用正向思维的方式设计api测试用例的基础上，提出一种基于逆向思维模拟应用场景的api测试用例的设计方法。
具体地，如图1所示，本发明实施例提供一种应用程序编程接口测试用例的生成方法，该方法适用于设计测试用例的情形，包括：步骤s101至步骤s104。
在s101中，将模块中的多个api组合成测试api组合，所述测试api组合为模块中的多个api除按照正常业务流程排序形成的api组合外的api组合。
由于仅仅按照正常业务流程排序形成的api组合进行测试用例的设计，很容易遗漏许多隐藏的测试点，无法较全面的设计测试用例，因此，本发明实施例中，所述测试api组合为模块中的多个api除按照正常业务流程排序形成的api组合外的api组合。
在本发明实施例中，一个软件应用的一个模块可能由多个相关功能的api结合完成一个正常的整体业务流程。例如，在串口通讯模块中，可以包括4个相关功能的api{open，close，send，recv}完成信息的串口通讯，即，通讯口打开api，通讯口关闭api，信息发送api，信息接收api；此时，可以将所述串口通讯模块中的4个相关功能的api组合成测试api组合。
可选地，在所述将模块中的多个api组合成测试api组合之前，还包括：将模块中的多个api按照正常业务流程进行排序。
也就是说，在将模块中的多个api组合成除按照正常业务流程排序形成的api组合外的api组合之前，需要将所述多个api按照正常业务流程进行排序。
例如，所述串口通讯模块中，所述4个相关功能的api{open，close，send，recv}按照正常业务流程的排序为{open，send，recv，close}，即先将通讯口打开，然后发送数据，接着接收数据，最后通讯口关闭。
可选地，本发明实施例中，在将所述模块中的多个api按照正常业务流程进行排序之后，还包括，对排序后的所述多个api依序编号，例如，将所述4个相关功能的api{open，close，send，recv}依序编号为api1、api2、api3、api4，再生成所述测试api组合，如，所述测试api组合为{(api2、api3)，(api2、api4)，(api3、api4)，(api2、api3、api4)……}。
可选地，在所述将模块中的多个api组合成测试api组合之后，还包括：若所述测试api组合中存在等价的测试api组合，则保留等价的测试api组合中包括api接口数量最多的测试api组合。
例如，所述串口通讯模块中的4个相关功能的api{open，close，send，recv}在实际设计中，其测试api组合{(api2、api4)，(api3、api4)，(api2、api3、api4)，(api3、api2、api4)……}属于等价的测试api组合，即，均为不打开通讯口的情况下收发数据并关闭通讯口的应用场景，因此，可以只保留其中一个较全面的测试api组合(api2、api3、api4)和(api3、api2、api4)，即api接口数量最多的测试api组合，进行测试用例的设计即可，提高测试用例设计的效率。
可选地，在所述保留等价的测试api组合中包括api接口数量最多的测试api组合之后，还包括：若包括api接口数量最多的测试api组合为多个，则删除其中不符合业务逻辑的测试api组合。
例如，在测试api组合(api2、api3、api4)和(api3、api2、api4)中，若所述测试api组合(api3、api2、api4)为不符合业务逻辑的测试api组合，则将其删除，进一步提高测试用例设计的效率。
可选地，在所述将模块中的多个api组合成测试api组合之后，还包括：删除所述测试api组合中不符合业务逻辑的测试api组合。
在s102中，根据每个所述测试api组合结合应用场景编写测试覆盖点。
其中，所述测试覆盖点表示测试目的。例如，所述测试api组合(api2、api3、api4)的测试目的为用户未打开通讯口时收发数据的情况。
在s103中，结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
在进行api测试时，一般需要预备一些测试用的测试数据，例如，串口通讯模块的测试中，所述测试数据可以为发送的数据大小和发送的数据内容。其中，所述测试数据的设计可以采用等价类划分、临界值等方法设计。
如图2所示，本发明实施例另外还提供一种应用程序编程接口api测试用例的生成方法，该方法适用于针对单个api设计测试用例的情形，包括：步骤s201至步骤s203。
在s201中，获取单个api的测试返回码，所述测试返回码为所述api的除操作成功返回码外的返回码。
所述api的测试返回码可以通过查找需求文件或api开发文档进行获取，例如，串口通讯中的api3除操作成功返回码外的返回码包括{通道未打开、发送缓冲区未空、参数错误、无效的通讯参数……}
在s202中，针对每个所述api的每个所述测试返回码，结合应用场景分别编写测试覆盖点。
例如，依据api每种返回码的含义模拟、推导在实际应用中可能出现该种状态的应用场景。
例如，串口通讯中的api3返回码“参数错误”，本领域的技术人员根据该返回码的含义，可以推导出该返回码对应的应用场景可以为“发送的数据量大于限制的最大数据量”或者“发送的数据中存在不支持的发送的字符”，因此，所述返回码“返回码为参数错误”的测试覆盖点为：“设置发送的数据量大于限制的最大数据量，函数返回参数错误”或者“发送的数据中存在不支持的发送的字符，函数返回参数错误”。
在s203中，结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
在步骤s202中，编写完测试覆盖点之后，即可设计所述测试覆盖点的测试数据。其中，所述测试数据的设计可以采用等价类划分、临界值等方法设计。
例如，所述测试覆盖点为：“设置发送的数据量大于限制的最大数据量，函数返回参数错误”，则其对应的测试数据可以为大于限制的最大数据量(临界值)的数据。最后，结合所述测试覆盖点和针对该测试覆盖点的测试数据，即可生成测试用例。
如图3示出了本发明实施例提供的一种应用程序编程接口api测试用例的生成装置300的结构示意图，包括：组合单元301，第一编写单元302，第一生成单元303。
组合单元301，用于将模块中的多个api组合成测试api组合，所述测试api组合为模块中的多个api除按照正常业务流程排序形成的api组合外的api组合；
第一编写单元302，用于根据每个所述测试api组合结合应用场景编写测试覆盖点；
第一生成单元303，用于结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
可选地，所述装置300还包括第一保留单元，用于若所述测试api组合中存在等价的测试api组合，则保留等价的测试api组合中包括api接口数量最多的测试api组合。
可选地，所述装置300还包括删除单元，用于删除所述测试api组合中不符合业务逻辑的测试api组合。
可选地，所述装置300还包括排序单元，用于将模块中的多个api按照正常业务流程进行排序。
如图4示出了本发明实施例提供的另一种应用程序编程接口api测试用例的生成装置400的结构示意图，包括：获取单元401，第二编写单元402，第二生成单元403。
获取单元401，用于获取单个api的测试返回码，所述测试返回码为所述api的除操作成功返回码外的返回码；
第二编写单元402，用于针对每个所述api的每个所述测试返回码，结合应用场景分别编写测试覆盖点；
第二生成单元403，用于结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
图5是本发明一实施例提供的应用程序编程接口api测试用例生成的终端设备的示意图。如图5所示，该实施例的应用程序编程接口api测试用例生成的终端设备5包括：处理器50、存储器51以及存储在所述存储器51中并可在所述处理器50上运行的计算机程序52，例如应用程序编程接口api测试用例生成程序。所述处理器50执行所述计算机程序52时实现上述各个应用程序编程接口api测试用例的生成方法实施例中的步骤，例如图1所示的步骤101至103。或者，所述处理器50执行所述计算机程序52时实现上述各装置实施例中各模块/单元的功能，例如图3所示单元301至304的功能。
示例性的，所述计算机程序52可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器51中，并由所述处理器50执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序52在所述应用程序编程接口api测试用例生成的终端设备5中的执行过程。例如，所述计算机程序52可以被分割成组合单元、第一编写单元和第一生成单元，各单元具体功能如下：
组合单元，用于将模块中的多个api组合成测试api组合，所述测试api组合为模块中的多个api除按照正常业务流程排序形成的api组合外的api组合；
第一编写单元，用于根据每个所述测试api组合结合应用场景编写测试覆盖点；
第一生成单元，用于结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
又例如，所述计算机程序52可以被分割成获取单元、第二编写单元和第二生成单元，各单元具体功能如下：
获取单元，用于获取单个api的测试返回码，所述测试返回码为所述api的除操作成功返回码外的返回码；
第二编写单元，用于针对每个所述api的每个所述测试返回码，结合应用场景分别编写测试覆盖点；
第二生成单元，用于结合所述测试覆盖点和针对该测试覆盖点的测试数据，生成测试用例。
所述应用程序编程接口api测试用例生成的终端设备5可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述应用程序编程接口api测试用例生成的终端设备可包括，但不仅限于，处理器50、存储器51。本领域技术人员可以理解，图5仅仅是应用程序编程接口api测试用例生成的终端设备5的示例，并不构成对应用程序编程接口api测试用例生成的终端设备5的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述应用程序编程接口api测试用例生成的终端设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器50可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器51可以是所述应用程序编程接口api测试用例生成的终端设备5的内部存储单元，例如应用程序编程接口api测试用例生成的终端设备5的硬盘或内存。所述存储器51也可以是所述应用程序编程接口api测试用例生成的终端设备5的外部存储设备，例如所述应用程序编程接口api测试用例生成的终端设备5上配备的插接式硬盘，智能存储卡(smartmediacard，smc)，安全数字(securedigital，sd)卡，闪存卡(flashcard)等。进一步地，所述存储器51还可以既包括所述应用程序编程接口api测试用例生成的终端设备5的内部存储单元也包括外部存储设备。所述存储器51用于存储所述计算机程序以及所述应用程序编程接口api测试用例生成的终端设备所需的其他程序和数据。所述存储器51还可以用于暂时地存储已经输出或者将要输出的数据。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
在本发明所提供的实施例中，应该理解到，所揭露的装置/终端设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/终端设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。