本發(fā)明實(shí)施例涉及軟件測(cè)試技術(shù)領(lǐng)域，尤其涉及一種應(yīng)用程序編程接口API測(cè)試方法、裝置及移動(dòng)設(shè)備。

背景技術(shù)：

隨著科技水平的發(fā)展，各種移動(dòng)設(shè)備(如智能手機(jī)等)的應(yīng)用日益廣泛。目前大部分移動(dòng)設(shè)備為CS(Client/Server Structs，客戶機(jī)和服務(wù)器結(jié)構(gòu))，通過(guò)與服務(wù)器的交互執(zhí)行各項(xiàng)操作。這種情況下，移動(dòng)設(shè)備中設(shè)置有API(Application Programming Interface，應(yīng)用程序編程接口)，當(dāng)用戶需要移動(dòng)設(shè)備執(zhí)行某一操作時(shí)，移動(dòng)設(shè)備產(chǎn)生相應(yīng)的請(qǐng)求信息，并通過(guò)API將所述請(qǐng)求信息傳輸至服務(wù)器，以便服務(wù)器根據(jù)所述請(qǐng)求信息產(chǎn)生相應(yīng)的響應(yīng)數(shù)據(jù)。然后，所述移動(dòng)設(shè)備通過(guò)API接收所述服務(wù)器反饋的響應(yīng)數(shù)據(jù)，并根據(jù)所述響應(yīng)數(shù)據(jù)執(zhí)行相應(yīng)操作。因此，API的性能會(huì)影響到移動(dòng)設(shè)備的使用，需要對(duì)API進(jìn)行測(cè)試。

目前，在對(duì)API進(jìn)行測(cè)試時(shí)，通常需要測(cè)試人員在移動(dòng)設(shè)備中安裝測(cè)試應(yīng)用，并對(duì)移動(dòng)設(shè)備進(jìn)行觸控操作，以使所述移動(dòng)設(shè)備產(chǎn)生所述觸控操作相應(yīng)的請(qǐng)求信息，然后再將所述請(qǐng)求信息傳輸至服務(wù)器，通過(guò)所述測(cè)試應(yīng)用對(duì)服務(wù)器反饋的響應(yīng)數(shù)據(jù)進(jìn)行分析，獲取API的性能測(cè)試結(jié)果。

但是，發(fā)明人在本申請(qǐng)的研究過(guò)程中發(fā)現(xiàn)，采用現(xiàn)有技術(shù)進(jìn)行API測(cè)試時(shí)，需要測(cè)試人員對(duì)移動(dòng)設(shè)備進(jìn)行手動(dòng)操作，會(huì)耗費(fèi)大量人力和時(shí)間。

技術(shù)實(shí)現(xiàn)要素：

為克服相關(guān)技術(shù)中存在的問(wèn)題，本發(fā)明實(shí)施例提供一種應(yīng)用程序編程接口API測(cè)試方法、裝置及移動(dòng)設(shè)備。

為了解決上述技術(shù)問(wèn)題，本發(fā)明實(shí)施例公開(kāi)了如下技術(shù)方案：

根據(jù)本發(fā)明實(shí)施例的第一方面，提供一種應(yīng)用程序編程接口API測(cè)試方法，包括：

獲取各個(gè)API的測(cè)試參數(shù)并存儲(chǔ)；

若所述各個(gè)API中存在待測(cè)API，根據(jù)所述待測(cè)API的功能確定所述待測(cè)API與服務(wù)器的交互類(lèi)型，并根據(jù)所述待測(cè)API與服務(wù)器的交互類(lèi)型以及所述待測(cè)API的測(cè)試參數(shù)，生成所述待測(cè)API的測(cè)試請(qǐng)求；

將所述待測(cè)API的測(cè)試請(qǐng)求通過(guò)所述待測(cè)API傳輸至所述服務(wù)器，并在所述服務(wù)器產(chǎn)生響應(yīng)信息后，通過(guò)所述待測(cè)API接收所述響應(yīng)信息；

根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能。

可選的，還包括：

檢測(cè)所述各個(gè)API中是否存在待測(cè)API。

可選的，所述檢測(cè)所述各個(gè)API中是否存在待測(cè)API，包括：

若預(yù)先分別為各個(gè)API設(shè)置相應(yīng)的測(cè)試周期，獲取目標(biāo)API最近一次測(cè)試的時(shí)間，在當(dāng)前時(shí)間與所述最近一次測(cè)試的時(shí)間的時(shí)間差不小于測(cè)試周期時(shí)，確定所述目標(biāo)API為待測(cè)API，其中，所述目標(biāo)API為所述各個(gè)API中的任一API。

可選的，所述檢測(cè)所述各個(gè)API中是否存在待測(cè)API，包括：

檢測(cè)所述各個(gè)API是否發(fā)生軟件重構(gòu)；

若所述各個(gè)API中存在發(fā)生軟件重構(gòu)的API，確定所述發(fā)生軟件重構(gòu)的API為待測(cè)API。

可選的，還包括：

預(yù)先存儲(chǔ)目標(biāo)郵箱的郵箱地址；

在根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能后，根據(jù)存儲(chǔ)的所述郵箱地址，將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱。

可選的，所述待測(cè)API與服務(wù)器的交互類(lèi)型包括：查找類(lèi)型和修改類(lèi)型。

根據(jù)本發(fā)明實(shí)施例的第二方面，提供一種應(yīng)用程序編程接口API測(cè)試裝置，包括：

參數(shù)存儲(chǔ)模塊，用于獲取各個(gè)API的測(cè)試參數(shù)并存儲(chǔ)；

測(cè)試請(qǐng)求生成模塊，用于若所述各個(gè)API中存在待測(cè)API，根據(jù)所述待測(cè)API的功能確定所述待測(cè)API與服務(wù)器的交互類(lèi)型，并根據(jù)所述待測(cè)API與服務(wù)器的交互類(lèi)型以及所述待測(cè)API的測(cè)試參數(shù)，生成所述待測(cè)API的測(cè)試請(qǐng)求；

響應(yīng)信息接收模塊，用于將所述待測(cè)API的測(cè)試請(qǐng)求通過(guò)所述待測(cè)API傳輸至所述服務(wù)器，并在所述服務(wù)器產(chǎn)生響應(yīng)信息后，通過(guò)所述待測(cè)API接收所述響應(yīng)信息；

測(cè)試性能確定模塊，用于根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能。

可選的，還包括：

檢測(cè)模塊，用于檢測(cè)所述各個(gè)API中是否存在待測(cè)API。

可選的，所述檢測(cè)模塊包括：

第一檢測(cè)單元，若預(yù)先分別為各個(gè)API設(shè)置相應(yīng)的測(cè)試周期，所述第一檢測(cè)單元用于獲取目標(biāo)API最近一次測(cè)試的時(shí)間，在當(dāng)前時(shí)間與所述最近一次測(cè)試的時(shí)間的時(shí)間差不小于測(cè)試周期時(shí)，確定所述目標(biāo)API為待測(cè)API，其中，所述目標(biāo)API為所述各個(gè)API中的任一API。

可選的，所述檢測(cè)模塊包括：

第二檢測(cè)單元，用于檢測(cè)所述各個(gè)API是否發(fā)生軟件重構(gòu)，若所述各個(gè)API中存在發(fā)生軟件重構(gòu)的API，確定所述發(fā)生軟件重構(gòu)的API為待測(cè)API。

可選的，還包括：

地址存儲(chǔ)模塊，用于預(yù)先存儲(chǔ)目標(biāo)郵箱的郵箱地址；

測(cè)試結(jié)果傳輸模塊，用于在根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能后，根據(jù)存儲(chǔ)的所述郵箱地址，將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱。

可選的，所述待測(cè)API與服務(wù)器的交互類(lèi)型包括：查找類(lèi)型和修改類(lèi)型。

根據(jù)本發(fā)明實(shí)施例的第三方面，提供一種移動(dòng)設(shè)備，包括：

處理器；

用于存儲(chǔ)處理器可執(zhí)行指令的存儲(chǔ)器；

其中，所述處理器被配置為：

獲取各個(gè)API的測(cè)試參數(shù)并存儲(chǔ)；

若所述各個(gè)API中存在待測(cè)API，根據(jù)所述待測(cè)API的功能確定所述待測(cè)API與服務(wù)器的交互類(lèi)型，并根據(jù)所述待測(cè)API與服務(wù)器的交互類(lèi)型以及所述待測(cè)API的測(cè)試參數(shù)，生成所述待測(cè)API的測(cè)試請(qǐng)求；

將所述待測(cè)API的測(cè)試請(qǐng)求通過(guò)所述待測(cè)API傳輸至所述服務(wù)器，并在所述服務(wù)器產(chǎn)生響應(yīng)信息后，通過(guò)所述待測(cè)API接收所述響應(yīng)信息；

根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能。

本發(fā)明的實(shí)施例提供的技術(shù)方案可以包括以下有益效果：

通過(guò)本發(fā)明實(shí)施例公開(kāi)的方案，能夠?qū)崿F(xiàn)對(duì)API的測(cè)試，并且測(cè)試過(guò)程中不需要測(cè)試人員進(jìn)行手動(dòng)操作，從而節(jié)省人力和時(shí)間。

應(yīng)當(dāng)理解的是，以上的一般描述和后文的細(xì)節(jié)描述僅是示例性和解釋性的，并不能限制本發(fā)明。

附圖說(shuō)明

此處的附圖被并入說(shuō)明書(shū)中并構(gòu)成本說(shuō)明書(shū)的一部分，示出了符合本發(fā)明的實(shí)施例，并與說(shuō)明書(shū)一起用于解釋本發(fā)明的原理。

圖1是根據(jù)本發(fā)明一示例性實(shí)施例示出的一種應(yīng)用程序編程接口API測(cè)試方法的架構(gòu)示意圖；

圖2是根據(jù)本發(fā)明一示例性實(shí)施例示出的一種應(yīng)用程序編程接口API測(cè)試方法的工作流程示意圖；

圖3是根據(jù)本發(fā)明一示例性實(shí)施例示出的又一種應(yīng)用程序編程接口API測(cè)試方法的工作流程示意圖；

圖4是根據(jù)本發(fā)明一示例性實(shí)施例示出的又一種應(yīng)用程序編程接口API測(cè)試方法的工作流程示意圖；

圖5是根據(jù)本發(fā)明一示例性實(shí)施例示出的一種應(yīng)用程序編程接口API測(cè)試裝置的結(jié)構(gòu)示意圖；

圖6是根據(jù)本發(fā)明一示例性實(shí)施例示出的又一種應(yīng)用程序編程接口API測(cè)試裝置的結(jié)構(gòu)示意圖。

具體實(shí)施方式

這里將詳細(xì)地對(duì)示例性實(shí)施例進(jìn)行說(shuō)明，其示例表示在附圖中。下面的描述涉及附圖時(shí)，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實(shí)施例中所描述的實(shí)施方式并不代表與本發(fā)明相一致的所有實(shí)施方式。相反，它們僅是與如所附權(quán)利要求書(shū)中所詳述的、本發(fā)明的一些方面相一致的裝置和方法的例子。

本發(fā)明實(shí)施例公開(kāi)一種應(yīng)用程序編程接口API測(cè)試方法、裝置及移動(dòng)設(shè)備，以解決利用現(xiàn)有技術(shù)對(duì)API進(jìn)行測(cè)試時(shí)，會(huì)耗費(fèi)大量人力和時(shí)間的問(wèn)題。

參見(jiàn)圖1所示的架構(gòu)示意圖，該示意圖中包括移動(dòng)設(shè)備100和服務(wù)器200。其中，所述移動(dòng)設(shè)備100中內(nèi)置有API，能夠通過(guò)本發(fā)明實(shí)施例公開(kāi)的API測(cè)試方法及裝置產(chǎn)生測(cè)試請(qǐng)求，并通過(guò)內(nèi)置的API將測(cè)試請(qǐng)求傳輸至所述服務(wù)器200，再通過(guò)所述API接收所述服務(wù)器200反饋的響應(yīng)信息，然后根據(jù)所述響應(yīng)信息，獲取所述待測(cè)API的測(cè)試性能。

本發(fā)明實(shí)施例一公開(kāi)一種應(yīng)用程序編程接口API測(cè)試方法。參見(jiàn)圖2所示的工作流程示意圖，所述API測(cè)試方法包括以下步驟：

步驟S11、獲取各個(gè)API的測(cè)試參數(shù)并存儲(chǔ)。

其中，所述測(cè)試參數(shù)指的是對(duì)API進(jìn)行測(cè)試時(shí)所需要的各種信息，通常包括API的版本號(hào)、運(yùn)行平臺(tái)(例如Android平臺(tái)或IOS平臺(tái))和API的渠道號(hào)等，本申請(qǐng)對(duì)此不做限定。

步驟S12、若所述各個(gè)API中存在待測(cè)API，根據(jù)所述待測(cè)API的功能確定所述待測(cè)API與服務(wù)器的交互類(lèi)型，并根據(jù)所述待測(cè)API與服務(wù)器的交互類(lèi)型以及所述待測(cè)API的測(cè)試參數(shù)，生成所述待測(cè)API的測(cè)試請(qǐng)求。

其中，所述待測(cè)API與服務(wù)器的交互類(lèi)型包括：查找類(lèi)型(即GET類(lèi)型)和修改類(lèi)型(即POST類(lèi)型)等。根據(jù)所述待測(cè)API的功能，即可確定所述待測(cè)API與服務(wù)器的交互類(lèi)型。

另外，若兩個(gè)API與服務(wù)器的交互類(lèi)型不同，則測(cè)試請(qǐng)求的格式往往不同。因此，本發(fā)明實(shí)施例中，根據(jù)所述待測(cè)API與服務(wù)器的交互類(lèi)型以及所述待測(cè)API的測(cè)試參數(shù)生成所述測(cè)試請(qǐng)求。

步驟S13、將所述待測(cè)API的測(cè)試請(qǐng)求通過(guò)所述待測(cè)API傳輸至所述服務(wù)器，并在所述服務(wù)器產(chǎn)生響應(yīng)信息后，通過(guò)所述待測(cè)API接收所述響應(yīng)信息。

其中，所述響應(yīng)信息通常為JSON(基于JavaScript語(yǔ)言的輕量級(jí)的數(shù)據(jù)交換格式，JavaScript Object Notation)格式。所述服務(wù)器在接收到所述待測(cè)API傳輸?shù)臏y(cè)試請(qǐng)求后，會(huì)根據(jù)所述測(cè)試請(qǐng)求產(chǎn)生相應(yīng)的響應(yīng)信息，并反饋至移動(dòng)設(shè)備，所述移動(dòng)設(shè)備通過(guò)所述待測(cè)API接收所述響應(yīng)信息。

步驟S14、根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能。

在移動(dòng)設(shè)備中，可預(yù)先存儲(chǔ)API在性能良好的情況下，應(yīng)該獲取到的響應(yīng)信息，并將其與本次測(cè)試過(guò)程中接收到的響應(yīng)信息相對(duì)比，根據(jù)二者的匹配程度確定所述待測(cè)API的測(cè)試性能。其中，二者匹配程度越高，說(shuō)明所述待測(cè)API的測(cè)試性能越好。

本發(fā)明的實(shí)施例一公開(kāi)一種應(yīng)用程序編程接口API測(cè)試方法，通過(guò)該方法，移動(dòng)設(shè)備能夠?qū)崿F(xiàn)對(duì)API的測(cè)試，并且測(cè)試過(guò)程中不需要測(cè)試人員進(jìn)行手動(dòng)操作，從而節(jié)省人力和時(shí)間。

進(jìn)一步的，在本發(fā)明實(shí)施例一公開(kāi)的應(yīng)用程序編程接口API測(cè)試方法中，還包括：

預(yù)先存儲(chǔ)目標(biāo)郵箱的郵箱地址；

在根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能后，根據(jù)存儲(chǔ)的所述郵箱地址，將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱。

其中，所述目標(biāo)郵箱可以為項(xiàng)目負(fù)責(zé)人的郵箱，或者其他測(cè)試人員的郵箱。將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱，能夠使項(xiàng)目負(fù)責(zé)人或者其他測(cè)試人員及時(shí)獲取API的測(cè)試結(jié)果。

另外，在傳輸之前，還可以對(duì)所述性能測(cè)試結(jié)果進(jìn)行分類(lèi)，只將表明API性能較差的性能測(cè)試結(jié)果傳輸至目標(biāo)郵箱，以便項(xiàng)目負(fù)責(zé)人或者其他測(cè)試人員及時(shí)對(duì)性能差的API采取措施。

進(jìn)一步的，在本申請(qǐng)公開(kāi)的應(yīng)用程序編程接口API測(cè)試方法中，還包括：檢測(cè)各個(gè)API中是否存在待測(cè)API。該操作可通過(guò)多種方式實(shí)現(xiàn)。

本發(fā)明實(shí)施例二公開(kāi)一種應(yīng)用程序編程接口API測(cè)試方法，該方法中根據(jù)API的測(cè)試周期檢測(cè)各個(gè)API中是否存在待測(cè)API。參見(jiàn)圖3所示的工作流程示意圖，所述API測(cè)試方法包括以下步驟：

步驟S21、獲取各個(gè)API的測(cè)試參數(shù)并存儲(chǔ)。

步驟S22、檢測(cè)所述各個(gè)API中是否存在待測(cè)API。所述檢測(cè)所述各個(gè)API中是否存在待測(cè)API，包括：若預(yù)先分別為各個(gè)API設(shè)置相應(yīng)的測(cè)試周期，獲取目標(biāo)API最近一次測(cè)試的時(shí)間，在當(dāng)前時(shí)間與所述最近一次測(cè)試的時(shí)間的時(shí)間差不小于測(cè)試周期時(shí)，確定所述目標(biāo)API為待測(cè)API，其中，所述目標(biāo)API為所述各個(gè)API中的任一API。

例如，若目標(biāo)API的測(cè)試周期為一個(gè)小時(shí)，當(dāng)前時(shí)間距離目標(biāo)API最近一次測(cè)試的時(shí)間之間的時(shí)間差達(dá)到一個(gè)小時(shí)后，則確定該目標(biāo)API為待測(cè)API。

步驟S23、若所述各個(gè)API中存在待測(cè)API，根據(jù)所述待測(cè)API的功能確定所述待測(cè)API與服務(wù)器的交互類(lèi)型，并根據(jù)所述待測(cè)API與服務(wù)器的交互類(lèi)型以及所述待測(cè)API的測(cè)試參數(shù)，生成所述待測(cè)API的測(cè)試請(qǐng)求。

步驟S24、將所述待測(cè)API的測(cè)試請(qǐng)求通過(guò)所述待測(cè)API傳輸至所述服務(wù)器，并在所述服務(wù)器產(chǎn)生響應(yīng)信息后，通過(guò)所述待測(cè)API接收所述響應(yīng)信息。

步驟S25、根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能。

其中，步驟S21與步驟S11的操作過(guò)程相同，步驟S23至步驟S25與步驟S12至步驟S14的操作過(guò)程相同，可相互參照，此處不再贅述。

通過(guò)本發(fā)明實(shí)施例二公開(kāi)的API測(cè)試方法，能夠根據(jù)各個(gè)API的測(cè)試周期確定各個(gè)API中是否存在待測(cè)API，從而能夠?qū)崿F(xiàn)對(duì)各個(gè)API進(jìn)行周期性的測(cè)試。

進(jìn)一步的，在本發(fā)明實(shí)施例二公開(kāi)的API測(cè)試方法中，還可以包括：

預(yù)先存儲(chǔ)目標(biāo)郵箱的郵箱地址；

在根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能后，根據(jù)存儲(chǔ)的所述郵箱地址，將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱。

其中，所述目標(biāo)郵箱可以為項(xiàng)目負(fù)責(zé)人的郵箱，或者其他測(cè)試人員的郵箱。將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱，能夠使項(xiàng)目負(fù)責(zé)人或者其他測(cè)試人員及時(shí)獲取API的測(cè)試結(jié)果。

另外，在傳輸之前，還可以對(duì)所述性能測(cè)試結(jié)果進(jìn)行分類(lèi)，只將表明API性能較差的性能測(cè)試結(jié)果傳輸至目標(biāo)郵箱，以便項(xiàng)目負(fù)責(zé)人或者其他測(cè)試人員及時(shí)對(duì)性能差的API采取措施。

本發(fā)明實(shí)施例三公開(kāi)一種應(yīng)用程序編程接口API測(cè)試方法，該方法中根據(jù)API是否發(fā)生軟件重構(gòu)檢測(cè)各個(gè)API中是否存在待測(cè)API。參見(jiàn)圖4所示的工作流程示意圖，所述應(yīng)用程序編程接口API測(cè)試方法包括以下步驟：

步驟S31、獲取各個(gè)API的測(cè)試參數(shù)并存儲(chǔ)。

步驟S32、檢測(cè)所述各個(gè)API中是否存在待測(cè)API。其中，所述檢測(cè)所述各個(gè)API中是否存在待測(cè)API，包括：檢測(cè)所述各個(gè)API是否發(fā)生軟件重構(gòu)，若所述各個(gè)API中存在發(fā)生軟件重構(gòu)的API，確定所述發(fā)生軟件重構(gòu)的API為待測(cè)API。

其中，API若發(fā)生代碼build事件，則認(rèn)為該API發(fā)生軟件重構(gòu)。另外，移動(dòng)設(shè)備中通?？蓜?chuàng)建Jenkins任務(wù)，并通過(guò)Jenkins任務(wù)檢測(cè)API是否發(fā)生代碼build事件，并在檢測(cè)到某一API發(fā)生代碼build事件后，確定該API為待測(cè)API。

步驟S33、若所述各個(gè)API中存在待測(cè)API，根據(jù)所述待測(cè)API的功能確定所述待測(cè)API與服務(wù)器的交互類(lèi)型，并根據(jù)所述待測(cè)API與服務(wù)器的交互類(lèi)型以及所述待測(cè)API的測(cè)試參數(shù)，生成所述待測(cè)API的測(cè)試請(qǐng)求。

步驟S34、將所述待測(cè)API的測(cè)試請(qǐng)求通過(guò)所述待測(cè)API傳輸至所述服務(wù)器，并在所述服務(wù)器產(chǎn)生響應(yīng)信息后，通過(guò)所述待測(cè)API接收所述響應(yīng)信息。

步驟S35、根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能。

其中，步驟S31與步驟S11的操作過(guò)程相同，步驟S33至步驟S35與步驟S12至步驟S14的操作過(guò)程相同，可相互參照，此處不再贅述。

通過(guò)本發(fā)明實(shí)施例三公開(kāi)的API測(cè)試方法，能夠在API發(fā)生軟件重構(gòu)時(shí)對(duì)其進(jìn)行測(cè)試，從而及時(shí)獲取軟件重構(gòu)后的API的性能測(cè)試結(jié)果。

進(jìn)一步的，在本發(fā)明實(shí)施例三公開(kāi)的API測(cè)試方法中，還可以包括：

預(yù)先存儲(chǔ)目標(biāo)郵箱的郵箱地址；

在根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能后，根據(jù)存儲(chǔ)的所述郵箱地址，將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱。

其中，所述目標(biāo)郵箱可以為項(xiàng)目負(fù)責(zé)人的郵箱，或者其他測(cè)試人員的郵箱。將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱，能夠使項(xiàng)目負(fù)責(zé)人或者其他測(cè)試人員及時(shí)獲取API的測(cè)試結(jié)果。

另外，在傳輸之前，還可以對(duì)所述性能測(cè)試結(jié)果進(jìn)行分類(lèi)，只將表明API性能較差的性能測(cè)試結(jié)果傳輸至目標(biāo)郵箱，以便項(xiàng)目負(fù)責(zé)人或者其他測(cè)試人員及時(shí)對(duì)性能差的API采取措施。

相應(yīng)的，本發(fā)明實(shí)施例四公開(kāi)一種應(yīng)用程序編程接口API測(cè)試裝置。參見(jiàn)圖5所示的API測(cè)試裝置的結(jié)構(gòu)示意圖，所述API測(cè)試裝置包括：參數(shù)存儲(chǔ)模塊110、測(cè)試請(qǐng)求生成模塊120、響應(yīng)信息接收模塊130和測(cè)試性能確定模塊140。

其中，所述參數(shù)存儲(chǔ)模塊110，用于獲取各個(gè)API的測(cè)試參數(shù)并存儲(chǔ)。所述測(cè)試參數(shù)指的是對(duì)API進(jìn)行測(cè)試時(shí)所需要的各種信息，通常包括API的版本號(hào)、運(yùn)行平臺(tái)(例如Android平臺(tái)或IOS平臺(tái))和API的渠道號(hào)等，本申請(qǐng)對(duì)此不做限定。

所述測(cè)試請(qǐng)求生成模塊120，用于若所述各個(gè)API中存在待測(cè)API，根據(jù)所述待測(cè)API的功能確定所述待測(cè)API與服務(wù)器的交互類(lèi)型，并根據(jù)所述待測(cè)API與服務(wù)器的交互類(lèi)型以及所述待測(cè)API的測(cè)試參數(shù)，生成所述待測(cè)API的測(cè)試請(qǐng)求。

所述待測(cè)API與服務(wù)器的交互類(lèi)型包括：查找類(lèi)型(即GET類(lèi)型)和修改類(lèi)型(即POST類(lèi)型)等。根據(jù)所述待測(cè)API的功能，即可確定所述待測(cè)API與服務(wù)器的交互類(lèi)型。

所述響應(yīng)信息接收模塊130，用于將所述待測(cè)API的測(cè)試請(qǐng)求通過(guò)所述待測(cè)API傳輸至所述服務(wù)器，并在所述服務(wù)器產(chǎn)生響應(yīng)信息后，通過(guò)所述待測(cè)API接收所述響應(yīng)信息。

所述測(cè)試性能確定模塊140，用于根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能。

在移動(dòng)設(shè)備中，可預(yù)先存儲(chǔ)API在性能良好的情況下，應(yīng)該獲取到的響應(yīng)信息，并將其與本次測(cè)試過(guò)程中接收到的響應(yīng)信息相對(duì)比，根據(jù)二者的匹配程度確定所述待測(cè)API的測(cè)試性能。其中，二者匹配程度越高，說(shuō)明所述待測(cè)API的測(cè)試性能越好。

通過(guò)本發(fā)明實(shí)施例公開(kāi)的API測(cè)試裝置，能夠?qū)崿F(xiàn)對(duì)API的測(cè)試，并且測(cè)試過(guò)程中不需要測(cè)試人員對(duì)移動(dòng)設(shè)備進(jìn)行手動(dòng)操作，從而節(jié)省人力和時(shí)間。

進(jìn)一步的，在本發(fā)明實(shí)施例四公開(kāi)的API測(cè)試裝置中，還包括：檢測(cè)模塊150，所述檢測(cè)模塊用于檢測(cè)所述各個(gè)API中是否存在待測(cè)API。

參見(jiàn)圖6所示的結(jié)構(gòu)示意圖，其中，所述檢測(cè)模塊150包括：第一檢測(cè)單元151，和/或第二檢測(cè)單元152。

其中，若預(yù)先分別為各個(gè)API設(shè)置相應(yīng)的測(cè)試周期，所述第一檢測(cè)單元151用于獲取目標(biāo)API最近一次測(cè)試的時(shí)間，在當(dāng)前時(shí)間與所述最近一次測(cè)試的時(shí)間的時(shí)間差不小于測(cè)試周期時(shí)，確定所述目標(biāo)API為待測(cè)API，其中，所述目標(biāo)API為所述各個(gè)API中的任一API。

例如，若目標(biāo)API的測(cè)試周期為一個(gè)小時(shí)，當(dāng)前時(shí)間距離目標(biāo)API最近一次測(cè)試的時(shí)間之間的時(shí)間差達(dá)到一個(gè)小時(shí)后，則確定該目標(biāo)API為待測(cè)API。

通過(guò)所述第一檢測(cè)單元151，能夠根據(jù)各個(gè)API的測(cè)試周期確定各個(gè)API中是否存在待測(cè)API，從而能夠?qū)崿F(xiàn)對(duì)各個(gè)API進(jìn)行周期性的測(cè)試。

所述第二檢測(cè)單元152用于檢測(cè)所述各個(gè)API是否發(fā)生軟件重構(gòu)，若所述各個(gè)API中存在發(fā)生軟件重構(gòu)的API，確定所述發(fā)生軟件重構(gòu)的API為待測(cè)API。

其中，API若發(fā)生代碼build事件，則認(rèn)為該API發(fā)生軟件重構(gòu)。另外，移動(dòng)設(shè)備中通?？蓜?chuàng)建Jenkins任務(wù)，并通過(guò)Jenkins任務(wù)檢測(cè)API是否發(fā)生代碼build事件，并在檢測(cè)到某一API發(fā)生代碼build事件后，確定該API為待測(cè)API。

通過(guò)第二檢測(cè)單元152，能夠及時(shí)獲取軟件重構(gòu)后的API的性能測(cè)試結(jié)果。

進(jìn)一步的，本發(fā)明實(shí)施例公開(kāi)的API測(cè)試裝置還包括：

地址存儲(chǔ)模塊，用于預(yù)先存儲(chǔ)目標(biāo)郵箱的郵箱地址；

測(cè)試結(jié)果傳輸模塊，用于在根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能后，根據(jù)存儲(chǔ)的所述郵箱地址，將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱。

其中，所述目標(biāo)郵箱可以為項(xiàng)目負(fù)責(zé)人的郵箱，或者其他測(cè)試人員的郵箱。將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱，能夠使項(xiàng)目負(fù)責(zé)人或者其他測(cè)試人員及時(shí)獲取API的測(cè)試結(jié)果。

關(guān)于上述實(shí)施例中的裝置，其中各個(gè)模塊執(zhí)行操作的具體方式已經(jīng)在有關(guān)該方法的實(shí)施例中進(jìn)行了詳細(xì)描述，此處將不做詳細(xì)闡述說(shuō)明。

相應(yīng)的，本發(fā)明實(shí)施例五公開(kāi)一種移動(dòng)設(shè)備。所述移動(dòng)設(shè)備包括：

處理器；

用于存儲(chǔ)處理器可執(zhí)行指令的存儲(chǔ)器；

其中，所述處理器被配置為：

獲取各個(gè)API的測(cè)試參數(shù)并存儲(chǔ)；

若所述各個(gè)API中存在待測(cè)API，根據(jù)所述待測(cè)API的功能確定所述待測(cè)API與服務(wù)器的交互類(lèi)型，并根據(jù)所述待測(cè)API與服務(wù)器的交互類(lèi)型以及所述待測(cè)API的測(cè)試參數(shù)，生成所述待測(cè)API的測(cè)試請(qǐng)求；

將所述待測(cè)API的測(cè)試請(qǐng)求通過(guò)所述待測(cè)API傳輸至所述服務(wù)器，并在所述服務(wù)器產(chǎn)生響應(yīng)信息后，通過(guò)所述待測(cè)API接收所述響應(yīng)信息；

根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能。

進(jìn)一步的，所述處理器還被配置為：檢測(cè)所述各個(gè)API中是否存在待測(cè)API。

其中，所述檢測(cè)所述各個(gè)API中是否存在待測(cè)API，包括：若預(yù)先分別為各個(gè)API設(shè)置相應(yīng)的測(cè)試周期，獲取目標(biāo)API最近一次測(cè)試的時(shí)間，在當(dāng)前時(shí)間與所述最近一次測(cè)試的時(shí)間的時(shí)間差不小于測(cè)試周期時(shí)，確定所述目標(biāo)API為待測(cè)API，其中，所述目標(biāo)API為所述各個(gè)API中的任一API。

或者，所述檢測(cè)所述各個(gè)API中是否存在待測(cè)API，包括：

檢測(cè)所述各個(gè)API是否發(fā)生軟件重構(gòu)；

若所述各個(gè)API中存在發(fā)生軟件重構(gòu)的API，確定所述發(fā)生軟件重構(gòu)的API為待測(cè)API。

進(jìn)一步的，所述處理器還被配置為：

預(yù)先存儲(chǔ)目標(biāo)郵箱的郵箱地址；

在根據(jù)所述響應(yīng)信息，確定所述待測(cè)API的測(cè)試性能后，根據(jù)存儲(chǔ)的所述郵箱地址，將所述待測(cè)API的性能測(cè)試結(jié)果傳輸至所述目標(biāo)郵箱。

其中，所述待測(cè)API與服務(wù)器的交互類(lèi)型包括：查找類(lèi)型和修改類(lèi)型。

通過(guò)本發(fā)明實(shí)施例公開(kāi)的移動(dòng)設(shè)備，能夠?qū)崿F(xiàn)對(duì)API的測(cè)試，并且測(cè)試過(guò)程中不需要測(cè)試人員對(duì)移動(dòng)設(shè)備進(jìn)行手動(dòng)操作，從而節(jié)省人力和時(shí)間。

本領(lǐng)域技術(shù)人員在考慮說(shuō)明書(shū)及實(shí)踐公開(kāi)的發(fā)明后，將容易想到本發(fā)明的其它實(shí)施方案。本申請(qǐng)旨在涵蓋本發(fā)明的任何變型、用途或者適應(yīng)性變化，這些變型、用途或者適應(yīng)性變化遵循本發(fā)明的一般性原理并包括本發(fā)明未公開(kāi)的本技術(shù)領(lǐng)域中的公知常識(shí)或慣用技術(shù)手段。說(shuō)明書(shū)和實(shí)施例僅被視為示例性的，本發(fā)明的真正范圍和精神由下面的權(quán)利要求指出。

應(yīng)當(dāng)理解的是，本發(fā)明并不局限于上面已經(jīng)描述并在附圖中示出的精確結(jié)構(gòu)，并且可以在不脫離其范圍進(jìn)行各種修改和改變。本發(fā)明的范圍僅由所附的權(quán)利要求來(lái)限制。