WO2019080426A1

WO2019080426A1 - Electronic apparatus, test method, system and storage medium

Info

Publication number: WO2019080426A1
Application number: PCT/CN2018/077624
Authority: WO
Inventors: 韩先跃
Original assignee: 平安科技（深圳）有限公司
Priority date: 2017-10-27
Filing date: 2018-02-28
Publication date: 2019-05-02
Also published as: CN108415825B; CN108415825A

Abstract

The present application relates to an electronic apparatus, a test method, a system and a storage medium. The test method comprises: in a pre-constructed Jekins environment, carrying out version classification on all service versions of each service type; when a full version coverage test instruction is received, extracting the version-classified service versions by utilizing a typical extraction manner, and establishing a rule table based on the extracted service versions; after a Jekins API service is established, reading the rule table based on a service type of the service so as to acquire the corresponding version information in the rule table; and acquiring the corresponding code branch according to the acquired version information, and executing a full version coverage test based on the acquired code branch. In the present application, a full coverage test is simulated, saving on both time and labor, and the test efficiency is improved.

Description

Electronic device, test method, system and storage medium

Priority claim

The present application is based on the priority of the Chinese Patent Application entitled "Electronic Device, Test Method and Storage Medium", filed on October 27, 2017, with the application number of CN201711023107.8, the entire contents of which are hereby incorporated by reference. The way is combined in this application.

Technical field

The present application relates to the field of communications technologies, and in particular, to an electronic device, a testing method, a system, and a storage medium.

Background technique

At present, APM (application performance monitor) products and JAVA application services are becoming more and more abundant. When technicians conduct javaagent probe development on APM products or JAVA application services, service version testing is required. Since there are dozens of versions of the client jar package corresponding to one service or JAVA application service in the APM product, in addition, the application topology of a project generally includes many services, and the jar package corresponding to each service includes multiple versions. If you test all the full-service versions, it will be time-consuming, labor-intensive, and inefficient.

Summary of the invention

The purpose of the present application is to provide an electronic device, a test method, a system, and a storage medium, which are intended to improve test efficiency.

To achieve the above object, the present application provides an electronic device including a memory and a processor coupled to the memory, wherein the memory stores a test system operable on the processor, the test The system implements the following steps when executed by the processor:

Version categorization step, versioning all service versions of each service type in a pre-built Jekins environment;

The rule table establishing step is: when receiving the full version coverage test command, extracting the versioned service version by using a typical extraction manner, and establishing a rule table based on the extracted service version;

a reading step, after the Jekins API service is established, reading the rule table based on the service type of the service, to obtain corresponding version information in the rule table;

The version testing step acquires a corresponding code branch according to the obtained version information, and performs a full version coverage test based on the acquired code branch.

To achieve the above object, the present application further provides a testing method, the testing method comprising:

S1, versioning all the service versions of each service type in a pre-built Jekins environment;

S2, when receiving the full version coverage test command, extracting the versioned service version by using a typical extraction manner, and establishing a rule table based on the extracted service version;

S3, after the Jekins API service is established, the rule table is read based on the service type of the service, to obtain corresponding version information in the rule table;

S4. Acquire a corresponding code branch according to the obtained version information, and perform a full version coverage test based on the acquired code branch.

To achieve the above object, the present application further provides a test system, the test system comprising:

A categorization module for categorizing all service versions of each service type in a pre-built Jekins environment;

Establishing a module, configured to extract a version of the service version after the version is extracted by using a typical extraction method, and establish a rule table based on the extracted service version;

a reading module, configured to: after the Jekins API service is established, read the rule table according to the service type of the service, to obtain corresponding version information in the rule table;

The testing module is configured to obtain a corresponding code branch according to the obtained version information, and perform a full version coverage test based on the acquired code branch.

The application further provides a computer readable storage medium having a test system stored thereon, the test system being implemented by the processor to implement the steps:

Version categorization of all service versions for each service type in a pre-built Jekins environment;

When receiving the full version coverage test command, extracting the versioned service version by using a typical extraction manner, and establishing a rule table based on the extracted service version;

After the Jekins API service is established, the rule table is read based on the service type of the service, to obtain corresponding version information in the rule table;

A corresponding code branch is obtained according to the obtained version information, and a full version version coverage test is performed based on the acquired code branch.

The beneficial effects of the present application are as follows: after the service version is classified, when a full version coverage test command is received, a representative small service version creation rule table is obtained after the classification, and the corresponding rule is obtained based on the rule table. The version information finally obtains the code branch corresponding to the version information for the full version coverage test. This application extracts a representative small part version information to simulate the full coverage test, which saves time and effort and improves test efficiency.

DRAWINGS

1 is a schematic diagram of a hardware architecture of an embodiment of an electronic device according to the present application;

2 is a schematic flow chart of an embodiment of a test method of the present application.

Detailed ways

In order to make the objects, technical solutions, and advantages of the present application more comprehensible, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

It should be noted that the descriptions of "first", "second" and the like in the present application are for the purpose of description only, and are not to be construed as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. . Thus, features defining "first" or "second" may include at least one of the features, either explicitly or implicitly. In addition, the technical solutions between the various embodiments may be combined with each other, but must be based on the realization of those skilled in the art, and when the combination of the technical solutions is contradictory or impossible to implement, it should be considered that the combination of the technical solutions does not exist. Nor is it within the scope of protection required by this application.

1 is a schematic diagram of a hardware architecture of an embodiment of an electronic device according to the present application. The electronic device 1 is a device capable of automatically performing numerical calculation and/or information processing according to an instruction set or stored in advance. The electronic device 1 may be a computer, a single network server, a server group composed of multiple network servers, or a cloud-based cloud composed of a large number of hosts or network servers, where cloud computing is a type of distributed computing. A super virtual computer consisting of a group of loosely coupled computers.

In the present embodiment, the electronic device 1 may include, but is not limited to, a memory 11, a processor 12, and a network interface 13 communicably connected to each other through a system bus. The memory 11 stores a test system executable on the processor 12. It should be noted that FIG. 1 only shows the electronic device 1 having the components 11-13, but it should be understood that not all illustrated components are required to be implemented, and more or fewer components may be implemented instead.

The memory 11 includes a memory and at least one type of readable storage medium. The memory provides a cache for the operation of the electronic device 1; the readable storage medium may be, for example, a flash memory, a hard disk, a multimedia card, a card type memory (eg, SD or DX memory, etc.), a random access memory (RAM), a static random access memory (SRAM). A non-volatile storage medium such as a read only memory (ROM), an electrically erasable programmable read only memory (EEPROM), a programmable read only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, or the like. In some embodiments, the readable storage medium may be an internal storage unit of the electronic device 1, such as a hard disk of the electronic device 1; in other embodiments, the non-volatile storage medium may also be external to the electronic device 1. A storage device, such as a plug-in hard disk equipped with an electronic device 1, a smart memory card (SMC), a Secure Digital (SD) card, a flash card, or the like. In this embodiment, the readable storage medium of the memory 11 is generally used to store an operating system for installing the electronic device 1 and various types of application software, such as program code for storing the test system in an embodiment of the present application. Further, the memory 11 can also be used to temporarily store various types of data that have been output or are to be output.

The processor 12 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data processing chip in some embodiments. The processor 12 is typically used to control the overall operation of the electronic device 1, such as performing control and processing related to data interaction or communication with other devices. In this embodiment, the processor 12 is configured to run program code or process data stored in the memory 11, such as running a test system or the like.

The network interface 13 may comprise a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the electronic device 1 and other electronic devices.

The test system is stored in the memory 11 and includes at least one computer readable instruction stored in the memory 11, the at least one computer readable instruction being executable by the processor 12 to implement the methods of various embodiments of the present application; The at least one computer readable instruction can be classified into different logic modules depending on the functions implemented by its various parts.

In an embodiment, the above test system is implemented by the processor 12 to implement the following steps:

Version categorization step, versioning all versions of services for each service type in a pre-built Jekins environment;

In this embodiment, the Jekins environment that can be automatically tested can be pre-built, and all service versions of each service type are versioned, and the service version includes versions of all jar packages corresponding to each service type, and the service type includes the mysql service. , redis services, etc.

Preferably, the version categorization of the service version includes: classifying the service versions belonging to the same large version into the same class, and arranging the small versions belonging to the same large version in the order of the version numbers. For example, if there are large versions: v1.xx, v2.xx, v3.xx, all service versions belonging to the large version v1 are classified into the same class, and all service versions belonging to the large version v2 are classified into the same class, which will belong to the same category. All service versions of version v3 are classified into the same class. Then, for small versions under the same major version, for example, all minor versions under the large version of v1.xx are: v1.0.1, v1.0.5, v1.0.3, then The small versions are arranged and stored according to the order of the version numbers, and the smaller versions are v1.0.1, v1.0.3, v1.0.5.

When the full version coverage test is performed, that is, when the full version coverage test command is received, the version of the service version after the version is extracted is extracted by a typical extraction method. Preferably, the typical extraction method is to extract the first minor version and the last minor version of the service version belonging to the same major version, and extract between the first minor version and the last minor version based on the predetermined extraction rule. A small version; builds a rules table based on the minor versions extracted from the service versions that belong to the same major version.

In an embodiment, the typical extraction method is a dichotomy method, for example, a large version of a service version is v1.x, a minimum version of a large version v1.x is v1.0.1, and a maximum version is v1.0.5. The intermediate version is v1.0.3, and for the large version v1.x, the minimum version v1.0.1, the maximum version v1.0.5, and the intermediate version v1.0.3 are extracted.

In other embodiments, the typical extraction method is a dichotomy-like extraction method, for example, a large version of a service version is v1.x, a minimum version of a large version v1.x is v1.0.1, and a maximum version is v1.0.5. For the large version v1.x, the minimum version v1.0.1, the maximum version v1.0.5, and any version in the middle are extracted. Preferably, the smaller or the smaller version with the largest intermediate transition is extracted.

Other service versions also use the above extraction methods, and are not illustrated here.

In order to facilitate subsequent testing, the embodiment also establishes a rule table for the extracted service version. In an embodiment, the established rules table is as shown in Table 1 below:

IDID	groupIdgroupId	artifactIdartifactId	min_versionMin_version	max_versionMax_version	random_versionRandom_version
v2.0V2.0	mysqlMysql	Mysql-connector-javaMysql-connector-java	v2.0.14V2.0.14	v2.0.14V2.0.14
v3.0V3.0	mysqlMysql	Mysql-connector-javaMysql-connector-java	v3.0.8V3.0.8	v3.1.14V3.1.14
v5.0V5.0	mysqlMysql	Mysql-connector-javaMysql-connector-java	v5.0.2V5.0.2	v5.1.42V5.1.42	v5.1.21V5.1.21

Table 1

The rule table has a total of six fields: the ID is a large version number, the groupId and the artifactId respectively correspond to the groupId and artifactId contents of the software project management and synthesis tool maven, and the min_version and max_version are respectively the minimum version and the maximum version under the large version. For example, the minimum version v3.0.8 and the largest version v3.1.14 under the large version v3.0.

In this embodiment, after the Jekins API service is established, if the service is a mysql service, the version information corresponding to the mysql service in the rule table is read, and if it is another service, the version corresponding to the other service is read. The information, as shown in Table 1 above, reads the version information of the mysql service including: large version of mysql service v2.0, v3.0 and v5.0, groupId and artifactId of each major version, minimum version v2.0.14 , v3.0.8 and v5.0.2, maximum version v2.0.14, v3.1.14 and v5.1.42, intermediate version v5.1.21.

In this embodiment, the code branch of each service version may be pre-created in the code base. After obtaining the version information, the corresponding code branch in the code base may be obtained according to the version information, for example, obtaining the large version v3.0 respectively. The small version v3.0.8 and v3.1.14 correspond to the code branch, and then use the obtained code branch to execute the full version coverage test, or by recompiling the code branch corresponding to the version information, and execute the full version coverage test based on the code branch.

Compared with the prior art, after the service version is classified, the embodiment extracts a representative partial service version establishment rule table after the classification is received, and obtains a corresponding rule based on the rule table. The version information is obtained by the code branch corresponding to the version information, and the full version coverage test is performed. This embodiment extracts a representative small part version information to simulate the full coverage test, which saves time and labor and has high test efficiency.

In a preferred embodiment, on the basis of the foregoing embodiment of FIG. 1, the step of acquiring a corresponding code branch according to the obtained version information, and performing a full version version coverage test based on the acquired code branch, specifically includes:

Analyze whether the code branch corresponding to the obtained version information has been constructed in the code base;

If yes, the code branch corresponding to the version information obtained in the code base is pulled;

If not, modifying the dependent version information in the configuration file pom to recompile the code branch corresponding to the obtained version information based on the modified configuration file pom;

Calling the relevant component in the Jekins environment to build the version packaging task of the code branch, uploading the packaged code branch to the ftp directory through the Jekins plugin to pull the code branch from the ftp directory when performing the full version coverage test carry out testing.

In this embodiment, if the code branch corresponding to the obtained version information is pre-built in the code library, the corresponding code branch in the code library may be directly pulled; if the version information corresponding to the obtained version information is not pre-built in the code library, The code branch needs to modify the dependent version information in the configuration file pom, and then recompile the code branch corresponding to the obtained version information according to the modified configuration file pom.

In this embodiment, the code branch corresponding to the version information can be flexibly obtained, so that the code branch can be pulled for testing when performing the full version coverage test, thereby further improving the testing efficiency.

As shown in FIG. 2, FIG. 2 is a schematic flowchart of an embodiment of a test method according to the present application, where the test method includes the following steps:

Step S1, versioning all the service versions of each service type in a pre-built Jekins environment;

Step S2, when receiving the full version coverage test command, extracting the versioned service version by using a typical extraction manner, and establishing a rule table based on the extracted service version;

In order to facilitate subsequent testing, the embodiment also establishes a rule table for the extracted service version. In an embodiment, the established rules table is as shown in Table 1 above.

Step S3, after the Jekens API service is established, the rule table is read based on the service type of the service, to obtain corresponding version information in the rule table.

Step S4: Acquire a corresponding code branch according to the obtained version information, and perform a full version version coverage test based on the acquired code branch.

In a preferred embodiment, on the basis of the foregoing embodiment of FIG. 2, the step of acquiring a corresponding code branch according to the obtained version information, and performing a full version version coverage test based on the acquired code branch, specifically includes:

The application further provides a computer readable storage medium having a test system stored thereon, the test system being implemented by a processor to implement the steps of the test method described above.

The serial numbers of the embodiments of the present application are merely for the description, and do not represent the advantages and disadvantages of the embodiments.

Through the description of the above embodiments, those skilled in the art can clearly understand that the foregoing embodiment method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is better. Implementation. Based on such understanding, the technical solution of the present application, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk, The optical disc includes a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the methods described in various embodiments of the present application.

The above is only a preferred embodiment of the present application, and is not intended to limit the scope of the patent application, and the equivalent structure or equivalent process transformations made by the specification and the drawings of the present application, or directly or indirectly applied to other related technical fields. The same is included in the scope of patent protection of this application.

Claims

An electronic device, comprising: a memory and a processor coupled to the memory, wherein the memory stores a test system operable on the processor, the test system being The processor implements the following steps when it executes:

Version categorization step, versioning all versions of services for each service type in a pre-built Jekins environment;

The rule table establishing step is: when receiving the full version coverage test command, extracting the versioned service version by using a typical extraction manner, and establishing a rule table based on the extracted service version;

a reading step, after the Jekins API service is established, reading the rule table based on the service type of the service, to obtain corresponding version information in the rule table;

The version testing step acquires a corresponding code branch according to the obtained version information, and performs a full version coverage test based on the acquired code branch.
The electronic device according to claim 1, wherein the step of classifying all the service versions of each service type comprises: classifying the service versions belonging to the same large version into the same class. The minor versions belonging to the same large version are arranged in the order of the version number.
The electronic device according to claim 1 or 2, wherein the step of extracting the versioned service version by using a typical extraction method, and establishing a rule table based on the extracted service version, specifically includes:

Extracting the first minor version and the last minor version of the service version belonging to the same major version, and extracting a small version between the first minor version and the last minor version based on the predetermined extraction rule;

A rule table is created based on the minor version extracted in the service version belonging to the same major version.
The electronic device according to claim 3, wherein the predetermined extraction rule comprises: extracting a small version having the largest transition between the first small version and the last small version, or extracting the located A small version scheduled between the first minor version and the last minor version.
The electronic device according to claim 3, wherein the step of acquiring a corresponding code branch according to the obtained version information, and performing a full version version coverage test based on the acquired code branch, specifically includes:

Analyze whether the code branch corresponding to the obtained version information has been constructed in the code base;

If yes, the code branch corresponding to the version information obtained in the code base is pulled;

If not, modifying the dependent version information in the configuration file pom to recompile the code branch corresponding to the obtained version information based on the modified configuration file pom;

Calling the relevant component in the Jekins environment to build the version packaging task of the code branch, uploading the packaged code branch to the ftp directory through the Jekins plugin to pull the code branch from the ftp directory when performing the full version coverage test carry out testing.
A test method, characterized in that the test method comprises:

S1, versioning all the service versions of each service type in a pre-built Jekins environment;

S2, when receiving the full version coverage test command, extracting the versioned service version by using a typical extraction manner, and establishing a rule table based on the extracted service version;

S3, after the Jekins API service is established, the rule table is read based on the service type of the service, to obtain corresponding version information in the rule table;

S4. Acquire a corresponding code branch according to the obtained version information, and perform a full version coverage test based on the acquired code branch.
The testing method according to claim 6, wherein the step of classifying all the service versions of each service type comprises: classifying the service versions belonging to the same large version into the same class. The minor versions belonging to the same large version are arranged in the order of the version number.
The testing method according to claim 6 or 7, wherein the step of extracting the version of the service version by using the typical extraction method, and establishing the rule table based on the extracted service version, specifically includes:

Extracting the first minor version and the last minor version of the service version belonging to the same major version, and extracting a small version between the first minor version and the last minor version based on the predetermined extraction rule;

A rule table is created based on the minor version extracted in the service version belonging to the same major version.
The testing method according to claim 8, wherein the predetermined extraction rule comprises: extracting a small version having the greatest transition between the first small version and the last small version, or extracting the located A small version scheduled between the first minor version and the last minor version.
The test method according to claim 8, wherein the step of acquiring a corresponding code branch according to the obtained version information, and performing a full version version coverage test based on the acquired code branch, specifically includes:

Analyze whether the code branch corresponding to the obtained version information has been constructed in the code base;

If yes, the code branch corresponding to the version information obtained in the code base is pulled;

If not, modifying the dependent version information in the configuration file pom to recompile the code branch corresponding to the obtained version information based on the modified configuration file pom;

Calling the relevant component in the Jekins environment to build the version packaging task of the code branch, uploading the packaged code branch to the ftp directory through the Jekins plugin to pull the code branch from the ftp directory when performing the full version coverage test carry out testing.
A test system, characterized in that the test system comprises:

A categorization module for categorizing all service versions of each service type in a pre-built Jekins environment;

Establishing a module, when receiving the full version coverage test command, extracting the version of the service class after the version is extracted by using a typical extraction manner, and establishing a rule table based on the extracted service version;

a reading module, configured to: after the Jekins API service is established, read the rule table according to the service type of the service, to obtain corresponding version information in the rule table;

The testing module is configured to obtain a corresponding code branch according to the obtained version information, and perform a full version coverage test based on the acquired code branch.
The test system according to claim 11, wherein the categorization module is specifically configured to classify service versions belonging to the same large version into the same class, and to reduce the minor versions belonging to the same large version according to the version number. The order of the order is arranged.
The test system according to claim 11 or 12, wherein the establishing module is specifically configured to extract the first minor version and the last minor version of the service version belonging to the same major version, and based on the predetermined The extraction rule extracts a small version between the first minor version and the last minor version; the rules table is built based on the minor version extracted in the service version belonging to the same major version.
The test system according to claim 13, wherein said predetermined extraction rule comprises: extracting a small version having the greatest transition between said first small version and a last small version, or extracting is located A small version scheduled between the first minor version and the last minor version.
The test system according to claim 13, wherein the test module is specifically configured to analyze whether a code branch corresponding to the obtained version information has been constructed in the code base; if yes, the obtained code library obtains The code branch corresponding to the version information; if not, modify the dependent version information in the configuration file pom to recompile the code branch corresponding to the obtained version information based on the modified configuration file pom; call related components in the Jekins environment to build The version packaging task of the code branch uploads the packaged code branch to the ftp directory through the Jekins plugin to pull the code branch from the ftp directory for testing when performing the full version coverage test.
A computer readable storage medium, wherein the computer readable storage medium stores a test system, and when the test system is executed by the processor, the steps are implemented:

Version categorization of all service versions for each service type in a pre-built Jekins environment;

When receiving the full version coverage test command, extracting the versioned service version by using a typical extraction manner, and establishing a rule table based on the extracted service version;

After the Jekins API service is established, the rule table is read based on the service type of the service, to obtain corresponding version information in the rule table;

A corresponding code branch is obtained according to the obtained version information, and a full version version coverage test is performed based on the acquired code branch.
The computer readable storage medium according to claim 16, wherein the step of classifying all the service versions of each service type comprises: classifying the service versions belonging to the same large version as In the same category, the minor versions that belong to the same large version are arranged in the order of the version number.
The computer readable storage medium according to claim 16 or 17, wherein the step of extracting the versioned service version by using a typical extraction method, and establishing a rule table based on the extracted service version, specifically includes:

Extracting the first minor version and the last minor version of the service version belonging to the same major version, and extracting a small version between the first minor version and the last minor version based on the predetermined extraction rule;

A rule table is created based on the minor version extracted in the service version belonging to the same major version.
The computer readable storage medium according to claim 18, wherein said predetermined extraction rule comprises: extracting a small version having the greatest transition between said first small version and a last small version, or , extracting a small version scheduled between the first minor version and the last minor version.
The computer readable storage medium according to claim 18, wherein the step of obtaining a corresponding code branch according to the obtained version information, and performing a full version version coverage test based on the acquired code branch, specifically includes:

Analyze whether the code branch corresponding to the obtained version information has been constructed in the code base;

If yes, the code branch corresponding to the version information obtained in the code base is pulled;

If not, modifying the dependent version information in the configuration file pom to recompile the code branch corresponding to the obtained version information based on the modified configuration file pom;

Calling the relevant component in the Jekins environment to build the version packaging task of the code branch, uploading the packaged code branch to the ftp directory through the Jekins plugin to pull the code branch from the ftp directory when performing the full version coverage test carry out testing.