CN106612204B - Service checking method and device - Google Patents

Service checking method and device Download PDF

Info

Publication number
CN106612204B
CN106612204B CN201510708776.3A CN201510708776A CN106612204B CN 106612204 B CN106612204 B CN 106612204B CN 201510708776 A CN201510708776 A CN 201510708776A CN 106612204 B CN106612204 B CN 106612204B
Authority
CN
China
Prior art keywords
service
sub
executed
checker
verification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201510708776.3A
Other languages
Chinese (zh)
Other versions
CN106612204A (en
Inventor
石雷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Advantageous New Technologies Co Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201510708776.3A priority Critical patent/CN106612204B/en
Publication of CN106612204A publication Critical patent/CN106612204A/en
Application granted granted Critical
Publication of CN106612204B publication Critical patent/CN106612204B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H04L41/0869—Validating the configuration within one network element
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/14—Arrangements for monitoring or testing data switching networks using software, i.e. software packages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The application provides a service checking method and a device, wherein the method comprises the following steps: the client sends a service check request aiming at the executed service to the server; the service checking request comprises an identifier of a sub checker configured for the executed service; the server side searches a corresponding sub-checker locally according to the identifier of the sub-checker; the local sub-checker is formed by packaging service check scripts uploaded by each service subsystem of the executed service; the server side performs service verification on the executed service based on the searched sub-verifier and sends a corresponding service verification result to the client side; and the client outputs the received service verification result to a user on a preset interface. The method and the device can reduce the complexity of service verification.

Description

Service checking method and device
Technical Field
The present application relates to the field of communications, and in particular, to a service checking method and apparatus.
Background
At present, in some large service systems, the system call is usually complex, and when a service is executed, multiple subsystems of the service are usually required to be executed respectively, so that the service link is relatively long. Moreover, after a service occurs, if it is necessary to check the occurred service to check whether the service is processed correctly, each service subsystem of the service is usually checked separately, so that the service check cannot be performed with global scheduling.
Disclosure of Invention
The application provides a service checking method, which comprises the following steps:
receiving a service check request aiming at an executed service, which is sent by a client; the service checking request comprises an identifier of a sub checker configured for the executed service;
locally searching a corresponding sub-checker according to the identifier of the sub-checker; the local sub-checker is formed by packaging service check scripts uploaded by each service subsystem of the executed service;
and performing service verification on the executed service based on the searched sub-verifier, and sending a corresponding service verification result to the client.
Optionally, the method further includes:
receiving service checking scripts uploaded by each service subsystem of the executed service;
locally packaging the received service verification script into sub-verifiers respectively corresponding to the service subsystems, and setting marks for the sub-verifiers;
and creating a sub-verifier list based on the corresponding relation between the identifier of the sub-verifier and each service subsystem, and sending the sub-verifier list to the client, so that the client configures the corresponding sub-verifier for the executed service based on the sub-verifier list.
Optionally, the performing service check on the executed service based on the searched sub-checker includes:
and running the service verification script packaged in the searched sub-verifier to perform service verification on the executed service.
The application also provides a service checking method, which comprises the following steps:
sending a service checking request aiming at the executed service to a server; the service checking request comprises an identifier of a sub checker configured for the executed service;
receiving a service verification result which is sent by the server and corresponds to the service verification request;
and outputting the received service verification result to a user on a preset interface.
Optionally, the method further includes:
receiving a sub-checker list which is sent by the server and corresponds to the executed service; the sub-checker list comprises corresponding relations between the identifications of a plurality of sub-checkers and the service subsystems of the executed services;
outputting the sub-checker list on a preset interface;
and acquiring the identifier of the sub verifier configured for the executed service by the user in the sub verifier list.
The present application further provides a service checking device, which includes:
the first receiving module is used for receiving a service checking request aiming at the executed service sent by the client; the service checking request comprises an identifier of a sub checker configured for the executed service;
the searching module is used for locally searching the corresponding sub-checker according to the identifier of the sub-checker; the local sub-checker is formed by packaging service check scripts uploaded by each service subsystem of the executed service;
and the checking module is used for carrying out service checking on the executed service based on the searched sub-checker and sending a corresponding service checking result to the client.
Optionally, the apparatus further comprises:
the second receiving module is used for receiving the service verification script uploaded by each service subsystem of the executed service;
the packaging module is used for locally packaging the received service verification script into sub-verifiers respectively corresponding to the service subsystems and setting marks for the sub-verifiers;
and the creating module is used for creating a sub-checker list based on the corresponding relation between the identifier of the sub-checker and each service subsystem, and sending the sub-checker list to the client, so that the client configures the corresponding sub-checker for the executed service based on the sub-checker list.
Optionally, the verification module is specifically configured to:
and running the service verification script packaged in the searched sub-verifier to perform service verification on the executed service.
The present application further provides a service checking device, which includes:
the sending module is used for sending a service checking request aiming at the executed service to the server; the service checking request comprises an identifier of a sub checker configured for the executed service;
a third receiving module, configured to receive a service verification result sent by the server and corresponding to the service verification request;
and the output module is used for outputting the received service verification result to a user on a preset interface.
Optionally, the apparatus further comprises:
a fourth receiving module, configured to receive a sub verifier list corresponding to the executed service and sent by the server; the sub-checker list comprises corresponding relations between the identifications of a plurality of sub-checkers and the service subsystems of the executed services;
the output module is used for outputting the sub-checker list on a preset interface;
and the obtaining module is used for obtaining the identifier of the sub verifier configured for the executed service by the user in the sub verifier list.
In the method, a service checking request aiming at the executed service sent by a client is received, and a corresponding sub-checker is searched locally according to the identifier of the sub-checker configured for the executed service in the service checking request; after the corresponding sub-verifier is found, the service verification can be performed on the executed service based on the found sub-verifier, and a corresponding service verification result is sent to the client. In the application, the local sub-verifiers are formed by packaging the service verification scripts uploaded by each service subsystem based on the executed services, so that the sub-verifiers of each service subsystem can be managed conveniently in a centralized manner, the complexity of service verification can be reduced when the services are verified aiming at the executed services, testers can conveniently carry out global scheduling on each sub-verifier, and the verification conditions of all the subsystems are controlled globally.
Drawings
Fig. 1 is a flowchart of a service verification method according to an embodiment of the present application;
fig. 2 is a logic block diagram of a service checking apparatus according to an embodiment of the present application;
fig. 3 is a hardware structure diagram of a server that carries the service checking apparatus according to an embodiment of the present application;
fig. 4 is a logic block diagram of another service checking apparatus provided in an embodiment of the present application;
fig. 5 is a hardware structure diagram of a client that carries the another service checking apparatus according to an embodiment of the present application.
Detailed Description
In some large service systems, since the system call is usually complicated and the service link is usually long, the service check is performed in the large service system to check whether the service is processed correctly, and usually, the service subsystem is checked individually by a tester of each service subsystem in the service system.
However, the individual verification is performed on each service subsystem, the verification process is complicated, and the verification needs to be performed on each subsystem, so that the tester cannot perform the correlation check between the subsystems, and after the service verification is completed, the tester cannot control the verification conditions of all the subsystems globally.
In view of this, the present application provides a service checking method, which includes receiving a service checking request for an executed service sent by a client, and locally searching a corresponding sub-checker according to an identifier of a sub-checker configured for the executed service in the service checking request; after the corresponding sub-verifier is found, the service verification can be performed on the executed service based on the found sub-verifier, and a corresponding service verification result is sent to the client. In the application, the local sub-verifiers are formed by packaging the service verification scripts uploaded by each service subsystem based on the executed services, so that the sub-verifiers of each service subsystem can be managed conveniently in a centralized manner, the complexity of service verification can be reduced when the services are verified aiming at the executed services, testers can conveniently carry out global scheduling on each sub-verifier, and the verification conditions of all the subsystems are controlled globally.
The present application is described below with reference to specific embodiments and specific application scenarios.
Referring to fig. 1, fig. 1 is a service verification method according to an embodiment of the present application, where the method performs the following steps:
step 101, a client sends a service check request aiming at an executed service to a server; the service checking request comprises an identifier of a sub checker configured for the executed service;
102, the server side searches a corresponding sub-checker locally according to the identifier of the sub-checker; the local sub-checker is formed by packaging service check scripts uploaded by each service subsystem of the executed service;
103, the server performs service verification on the executed service based on the searched sub-verifier, and sends a corresponding service verification result to the client;
and 104, the client outputs the received service verification result to a user on a preset interface.
In this embodiment, the client may include client software that provides a service verification service for a tester; for example, the verification client software may be a business verification tool developed by a developer to provide business verification services to testers. In this embodiment, the hardware environment for carrying the client software is not particularly limited; for example, it may be a PC host. The server may include a verification server, a server cluster, or a cloud platform based on a server cluster architecture, which provides services for the client.
In a large service system, a plurality of different service subsystems are usually included, and when a service is executed, the service can be executed smoothly only after being processed in each service subsystem according to a scheduling sequence of each service subsystem.
For example, taking a payment service as an example, in a large-scale payment system, according to a general flow of the payment service, subsystems such as a cash register subsystem, an order submitting subsystem, a billing subsystem, and a balance management subsystem may be generally included. When a user initiates an order through a payment client, the subsystems can be respectively scheduled to process the order according to the scheduling sequence of the subsystems, and the order can be successfully executed only after the order is processed in the subsystems.
For an executed service, a tester can check the executed service to detect whether each service subsystem correctly processes the service in the execution process of the service.
When the tester performs service verification on the executed service, the subsystem needing verification can be selected through the client, and a corresponding sub-verifier is configured for the selected subsystem. After the configuration is completed, the client interacts with the server, and the configured sub-verifier is locally called from the server to perform service verification on the executed service.
The following describes in detail an interactive process in which the client locally calls the configured sub-verifier from the server to perform service verification on the executed service.
In an initial state, a system manager of each service subsystem can respectively edit a service verification script for verifying the current subsystem in the system environment of each service subsystem, and then upload the edited service verification script to the server through the current subsystem.
The service verification script may include executable codes or programs in a standard format, which are edited by a system administrator when performing a service verification operation such as service verification or regression testing on a current subsystem.
After receiving the service verification scripts uploaded by each service subsystem, the service end can independently package the received service verification scripts into corresponding sub-verifiers locally, and set identifiers for the packaged sub-verifiers, and then store the identifiers locally, so that the service end can conveniently perform centralized management. The server side sets an identifier for the sub-verifier, and a corresponding relation exists between the identifier and a subsystem which uploads a service verification script in the sub-verifier.
It should be noted that the system administrator of each service subsystem may also perform real-time maintenance on the edited service verification script, and if the system environment of the current service subsystem changes, the system administrator may also re-edit the service verification script and send the re-edited service verification script to the server, and the server re-encapsulates the service verification script to update the original sub-verifier.
In this embodiment, for each sub-verifier stored locally, the server may create a sub-verifier list based on a correspondence between the identifier of each sub-verifier and each service subsystem, where the sub-verifier list may include the correspondence between the identifiers of all encapsulated sub-verifiers and each service subsystem.
For the generated sub verifier list, the server may send the sub verifier list to the client, so as to provide a call service of the sub verifier for the client. After the client receives the sub-verifier list sent by the server, the sub-verifier list can be output to a tester in a visual user interface provided by the client, the tester can visually select the sub-system needing verification in the sub-verifier list, and the selected sub-system is configured with the corresponding sub-verifier.
If the tester needs to perform full link verification, the tester may select all subsystems in the sub-verifier list as the subsystems that need to be verified. On the contrary, if the tester does not need to perform full link verification, the tester can select one or more subsystems as the subsystems to be verified according to the actual verification requirements.
On one hand, after a tester selects a subsystem to be verified in the sub-verifier list and configures a corresponding sub-verifier for the selected subsystem, the client may generate a corresponding service verification request based on information configured by the tester, where the service verification request may include an identifier of the sub-verifier configured for the selected subsystem to be verified, and then the client may further send the service verification request to the server to schedule the corresponding sub-verifier to verify the subsystem selected by the tester
On the other hand, after receiving the service verification request sent by the client, the server may analyze the service verification request to obtain the identifier of the sub-verifier carried in the request, and locally search the corresponding sub-verifier according to the obtained identifier of the sub-verifier. After the corresponding sub-verifier is found, the service end can run the service verification script packaged in the found sub-verifier at the moment, and perform service verification on the executed service.
When the executed service is verified, the service end can verify the service subsystems which are selected by the tester and need to be verified respectively according to the scheduling sequence of each service subsystem by running the service verification script packaged in the searched sub-verifier, and when the service subsystems which are selected by the tester and need to be verified are verified respectively, the executed service is verified.
After the service verification is completed for the executed service, the server may send a service verification result to the client, where the service verification result includes a verification result after the service verification is performed for each service subsystem selected by the tester and needing to be verified. After receiving the service verification result sent by the server, the client can output the service verification result in a visual user interface provided by the client, so that the tester can visually check the verification results of all the sub-verifiers which need to be verified and are selected from the sub-verifier list.
For example, assuming that the executed service includes a subsystem 1, a subsystem 2, and a subsystem 3, a tester selects a sub-verifier list that needs to be verified for the subsystem 1 and the subsystem 2, when the service end runs a service verification script packaged in a sub-verifier corresponding to the subsystem 1 and the subsystem 2, and after the verification for the subsystem 1 and the subsystem 2 is completed, the client end outputs a service verification result, which may be characterized by prompt characters True and False, and assuming that the verification fails for the subsystem 1, the client end may output a prompt character False at a position in the user interface corresponding to the subsystem 1, and mark a reason of the verification failure. If the verification of the subsystem 2 is successful, a prompt character True can be output at a position corresponding to the subsystem 2 in the user interface, and a tester can visually check the verification results of the subsystem 1 and the subsystem 2 by checking the verification result output by the client, so that the verification results of the subsystems in the current service system can be controlled globally.
According to the embodiment, the service end can independently package the service verification scripts uploaded by each subsystem of the executed service into the corresponding sub-verifiers locally, and perform centralized management on the packaged sub-verifiers, when the service verification is performed on the executed service, a tester can perform global scheduling on the local sub-verifiers of the service end through the client end to complete verification, and does not need to perform individual verification on each service subsystem, so that the complexity of service verification is obviously reduced.
Moreover, because the local sub-verifier at the server is isolated from each subsystem of the executed service, and the service verification script encapsulated in the local sub-verifier at the server is provided and maintained by the system management personnel of each subsystem, during the service verification of the executed service, the tester can globally control the result of the service verification without understanding the service verification logic in each sub-verifier, which is beneficial to saving the service verification cost.
The executed service is taken as a payment service as an example, and the above embodiment is described with reference to an application scenario of a payment system.
In a large-scale payment system, a plurality of different subsystems are usually included, and when an order is paid, the order can be successfully completed only after being processed in each subsystem according to a scheduling sequence of each subsystem.
It is assumed that the payment system includes 4 subsystems, such as a cash register subsystem, an order submitting subsystem, an accounting subsystem and a balance management subsystem. When a user initiates an order through a payment client, according to the scheduling sequence of the subsystems, the cash register subsystem can be scheduled to carry out cash register operation firstly, then the order submitting subsystem is scheduled to submit the order, after the order is processed successfully, the accounting subsystem is scheduled to account the amount related to the order, and finally the balance management subsystem is scheduled to update the balance of the user account.
In the related art, it is usually required that the testers of the subsystems respectively edit service verification scripts for verifying the current subsystem in the system environment of the respective service subsystem, and then complete verification by running the service verification scripts.
However, when the service verification of the full link is performed in the above manner, because each service subsystem needs to be separately verified, the tester cannot perform correlation check between the subsystems, and after the service verification is completed, the tester cannot globally control the verification of all the subsystems.
In this example, the system administrator of each service subsystem may respectively edit the service verification script for verifying the current subsystem in the system environment of each service subsystem, and then upload the edited service verification script to the server through the current subsystem. The server side can package the received service verification script to generate corresponding sub-verifiers, and stores the generated sub-verifiers locally after setting identifiers for the generated sub-self-verification.
Assume that the server-side encapsulated sub-verifier is as follows:
subsystem name Sub-verifier name Sub-verifier ID
Cash register subsystem Sub-checker 1 1
Order submission subsystem Second sub-checker 2
Accounting subsystem Sub-checker III 3
Balance management subsystem Fourth sub-checker 4
The server side can create a sub-verifier list according to the corresponding relation between the identifier of each sub-verifier in the upper table and each service subsystem in the upper table.
The sub-checker list at this time is as follows:
subsystem name Sub-verifier ID
Cash register subsystem 1
Order submission subsystem 2
Accounting subsystem 3
Balance management subsystem 4
The generated sub-verifier list can be sent to the client by the server so as to be output to a tester at the user interface of the client, so that the tester can intuitively select the subsystem needing verification in the sub-verifier list and configure the corresponding sub-verifier for the selected subsystem.
Because the tester needs to perform the service verification of the full link, the tester can select all the subsystems in the sub-verifier list as the subsystems needing to be verified, and configure the corresponding sub-verifier ID for the selected subsystem according to the corresponding relationship in the sub-verifier list, and at this time, the sub-verifier corresponding to the sub-verifier ID is the available sub-verifier of the subsystem.
After the configuration of the tester in the sub-verifier list is completed, the client may create a service verification request based on the configuration information of the tester, and the server may locally search for a corresponding sub-verifier after analyzing the service verification request and acquiring the sub-verifier ID configured for the selected subsystem by the tester, which is carried in the service verification request.
Because the service verification is the service verification of a full link, the service verification request carries four sub-verifier IDs (1, 2, 3, 4, and the like), the service end can search the four sub-verifiers including the first sub-verifier, the second sub-verifier, the third sub-verifier and the fourth sub-verifier after locally searching based on the sub-verifier IDs, at the moment, the service end can firstly run the service verification script packaged in the first sub-verifier to verify the cash-receiving subsystem according to the scheduling sequence of the subsystems corresponding to the four sub-verifiers, when the verification of the cash-receiving subsystem is completed, then run the service verification script packaged in the second sub-verifier to verify the order-submitting subsystem, when the verification of the order-submitting subsystem is completed, then run the service verification script packaged in the third sub-verifier to verify the subsystems, and when the verification of the bookkeeping subsystem is completed, and then, the business verification script packaged in the sub-verifier IV is operated to verify the balance management subsystem, when the balance management subsystem is verified, the full-link business verification aiming at the order is finished, and the server side can pack and return the verification results aiming at the four subsystems to the client side.
Assuming that the verification of the accounting subsystem and the balance management subsystem fails and the verification of the cashier subsystem and the order submitting subsystem succeeds, the client may output the verification results shown in the following table to the tester:
subsystem name Verification result
Cash register subsystem TRUE
Order submission subsystem TRUE
Accounting subsystem False：xxxx
Balance management subsystem False：xxxx
Wherein xxxx in the above table represents the reason for the failure of the verification.
After the client outputs the verification results to the tester, the tester can visually check the verification results of the subsystems of the payment system and the correlation among the subsystems through the table, so that the verification results of the subsystems can be controlled globally.
In the above embodiment, a service verification request for an executed service sent by a client is received, and a corresponding sub-verifier is locally searched according to an identifier of the sub-verifier configured for the executed service in the service verification request; after the corresponding sub-verifier is found, the service verification can be performed on the executed service based on the found sub-verifier, and a corresponding service verification result is sent to the client. The local sub-verifiers are formed by packaging the service verification scripts uploaded by each service subsystem executing the service, so that the sub-verifiers of each service subsystem can be managed in a centralized manner, the complexity of service verification can be reduced when the service verification is carried out on the executed service, testers can carry out global scheduling on each sub-verifier, and the verification conditions of all the subsystems are controlled in a global manner.
Corresponding to the method embodiment, the application also provides an embodiment of the device.
Referring to fig. 2, the present application provides a service checking apparatus 20, which is applied to a server, where the server may be a server, a server cluster, or a cloud platform constructed based on the server cluster; referring to fig. 3, a hardware architecture related to a server that carries the service checking device 20 generally includes a CPU, a memory, a non-volatile memory, a network interface, an internal bus, and the like; taking a software implementation as an example, the service verification apparatus 20 may be generally understood as a computer program loaded in a memory, and a logic apparatus formed by combining software and hardware after being run by a CPU, where the apparatus 20 includes:
a first receiving module 201, configured to receive a service check request for an executed service, where the service check request is sent by a client; the service checking request comprises an identifier of a sub checker configured for the executed service;
the searching module 202 is configured to locally search a corresponding sub-verifier according to the identifier of the sub-verifier; the local sub-checker is formed by packaging service check scripts uploaded by each service subsystem of the executed service;
the checking module 203 is configured to perform service checking on the executed service based on the found sub-checker, and send a corresponding service checking result to the client.
In this embodiment, the apparatus 20 further includes:
a second receiving module 204, configured to receive a service verification script uploaded by each service subsystem that has executed the service;
the encapsulating module 205 is configured to locally encapsulate the received service verification script into sub-verifiers corresponding to the service subsystems, and set identifiers for the sub-verifiers;
a creating module 206, configured to create a sub verifier list based on a correspondence between the identifier of the sub verifier and each service subsystem, and send the sub verifier list to the client, so that the client configures a corresponding sub verifier for the executed service based on the sub verifier list.
In this embodiment, the verification module 203 is specifically configured to:
and running the service verification script packaged in the searched sub-verifier to perform service verification on the executed service.
Referring to fig. 4, the present application provides a service verification apparatus 40, which is applied to a client, where the client may include a PC host installed with client software for providing service verification service for testers; referring to fig. 5, a hardware architecture related to a client that carries the service checking apparatus 40 generally includes a CPU, a memory, a non-volatile memory, a network interface, an internal bus, and the like; taking a software implementation as an example, the service verification apparatus 40 may be generally understood as a computer program loaded in a memory, and a logic apparatus formed by combining software and hardware after being run by a CPU, where the apparatus 40 includes:
a sending module 401, configured to send a service check request for an executed service to a server; the service checking request comprises an identifier of a sub checker configured for the executed service;
a third receiving module 402, configured to receive a service verification result sent by the server and corresponding to the service verification request;
an output module 403, configured to output the received service verification result to a user on a preset interface.
In this embodiment, the apparatus 40 further includes:
a fourth receiving module 404, configured to receive a sub verifier list corresponding to the executed service and sent by the server; the sub-checker list comprises corresponding relations between the identifications of a plurality of sub-checkers and the service subsystems of the executed services;
an output module 405, configured to output the sub verifier list on a preset interface;
an obtaining module 406, configured to obtain an identifier of a sub verifier configured by the user for the executed service in the sub verifier list.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.
The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims (10)

1. A method for service verification, the method comprising:
receiving a service check request aiming at an executed service, which is sent by a client; the executed service comprises services executed in a plurality of service subsystems respectively; the service checking request comprises an identifier of a sub checker configured for the executed service;
locally searching a corresponding sub-checker according to the identifier of the sub-checker; the local sub-checker is formed by packaging service check scripts uploaded by each service subsystem of the executed service;
and performing service verification on the executed service based on the searched sub-verifier, and sending a corresponding service verification result to the client.
2. The method of claim 1, further comprising:
receiving service checking scripts uploaded by each service subsystem of the executed service;
locally packaging the received service verification script into sub-verifiers respectively corresponding to the service subsystems, and setting marks for the sub-verifiers;
and creating a sub-verifier list based on the corresponding relation between the identifier of the sub-verifier and each service subsystem, and sending the sub-verifier list to the client, so that the client configures the corresponding sub-verifier for the executed service based on the sub-verifier list.
3. The method according to claim 2, wherein the performing service check on the executed service based on the searched sub-checker comprises:
and running the service verification script packaged in the searched sub-verifier to perform service verification on the executed service.
4. A method for service verification, the method comprising:
sending a service checking request aiming at the executed service to a server; the service checking request comprises an identifier of a sub checker configured for the executed service;
receiving a service verification result which is sent by the server and corresponds to the service verification request;
and outputting the received service verification result to a user on a preset interface.
5. The method of claim 4, further comprising:
receiving a sub-checker list which is sent by the server and corresponds to the executed service; the sub-checker list comprises corresponding relations between the identifications of a plurality of sub-checkers and the service subsystems of the executed services;
outputting the sub-checker list on a preset interface;
and acquiring the identifier of the sub verifier configured for the executed service by the user in the sub verifier list.
6. A service checking apparatus, comprising:
the first receiving module is used for receiving a service checking request aiming at the executed service sent by the client; the executed service comprises services executed in a plurality of service subsystems respectively; the service checking request comprises an identifier of a sub checker configured for the executed service;
the searching module is used for locally searching the corresponding sub-checker according to the identifier of the sub-checker; the local sub-checker is formed by packaging service check scripts uploaded by each service subsystem of the executed service;
and the checking module is used for carrying out service checking on the executed service based on the searched sub-checker and sending a corresponding service checking result to the client.
7. The apparatus of claim 6, further comprising:
the second receiving module is used for receiving the service verification script uploaded by each service subsystem of the executed service;
the packaging module is used for locally packaging the received service verification script into sub-verifiers respectively corresponding to the service subsystems and setting marks for the sub-verifiers;
and the creating module is used for creating a sub-checker list based on the corresponding relation between the identifier of the sub-checker and each service subsystem, and sending the sub-checker list to the client, so that the client configures the corresponding sub-checker for the executed service based on the sub-checker list.
8. The apparatus of claim 7, wherein the verification module is specifically configured to:
and running the service verification script packaged in the searched sub-verifier to perform service verification on the executed service.
9. A service checking apparatus, comprising:
the sending module is used for sending a service checking request aiming at the executed service to the server; the service checking request comprises an identifier of a sub checker configured for the executed service;
a third receiving module, configured to receive a service verification result sent by the server and corresponding to the service verification request;
and the output module is used for outputting the received service verification result to a user on a preset interface.
10. The apparatus of claim 9, further comprising:
a fourth receiving module, configured to receive a sub verifier list corresponding to the executed service and sent by the server; the sub-checker list comprises corresponding relations between the identifications of a plurality of sub-checkers and the service subsystems of the executed services;
the output module is used for outputting the sub-checker list on a preset interface;
and the obtaining module is used for obtaining the identifier of the sub verifier configured for the executed service by the user in the sub verifier list.
CN201510708776.3A 2015-10-27 2015-10-27 Service checking method and device Active CN106612204B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510708776.3A CN106612204B (en) 2015-10-27 2015-10-27 Service checking method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510708776.3A CN106612204B (en) 2015-10-27 2015-10-27 Service checking method and device

Publications (2)

Publication Number Publication Date
CN106612204A CN106612204A (en) 2017-05-03
CN106612204B true CN106612204B (en) 2020-04-10

Family

ID=58614531

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510708776.3A Active CN106612204B (en) 2015-10-27 2015-10-27 Service checking method and device

Country Status (1)

Country Link
CN (1) CN106612204B (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110795709B (en) * 2019-10-31 2022-08-12 北京达佳互联信息技术有限公司 Method and device for performing business operation, electronic equipment and storage medium
CN111158739A (en) * 2019-12-11 2020-05-15 苏宁云计算有限公司 Task checking method and device
CN111444224B (en) * 2020-03-24 2023-08-15 政采云有限公司 Service data verification method and device
CN111563075B (en) * 2020-05-06 2024-01-23 政采云有限公司 Service verification system, method and equipment and storage medium
CN113360369A (en) * 2021-04-30 2021-09-07 江苏康众汽配有限公司 Automatic testing method and system based on MQ message
CN113626314B (en) * 2021-07-16 2023-12-22 济南浪潮数据技术有限公司 Verification method, device and equipment for cloud platform resource parameters and readable medium
CN113778535B (en) * 2021-08-10 2024-02-23 济南浪潮数据技术有限公司 Cloud host operation verification method, system, equipment and storage medium

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5715373A (en) * 1994-10-20 1998-02-03 Tandem Computers Incorporated Method and apparatus for preparing a suite of test scripts for testing a proposed network management application
CN101727389A (en) * 2009-11-23 2010-06-09 中兴通讯股份有限公司 Automatic test system and method of distributed integrated service
CN102752770A (en) * 2011-04-21 2012-10-24 中国移动通信集团北京有限公司 Method and device for polling service system
CN103544074A (en) * 2012-07-09 2014-01-29 阿里巴巴集团控股有限公司 Method and device for verifying service

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5715373A (en) * 1994-10-20 1998-02-03 Tandem Computers Incorporated Method and apparatus for preparing a suite of test scripts for testing a proposed network management application
CN101727389A (en) * 2009-11-23 2010-06-09 中兴通讯股份有限公司 Automatic test system and method of distributed integrated service
CN102752770A (en) * 2011-04-21 2012-10-24 中国移动通信集团北京有限公司 Method and device for polling service system
CN103544074A (en) * 2012-07-09 2014-01-29 阿里巴巴集团控股有限公司 Method and device for verifying service

Also Published As

Publication number Publication date
CN106612204A (en) 2017-05-03

Similar Documents

Publication Publication Date Title
CN106612204B (en) Service checking method and device
US11467952B2 (en) API driven continuous testing systems for testing disparate software
CN105302716B (en) Test method, device under the development mode of interflow
US10229039B2 (en) Testing a virtual network function by a virtual network tester
CN106354645B (en) Test method and test platform based on background system service or interface
CN109977012B (en) Joint debugging test method, device, equipment and computer readable storage medium of system
CN104834602B (en) A kind of program dissemination method, device and program delivery system
CN107241315B (en) Access method and device of bank gateway interface and computer readable storage medium
CN113312064B (en) Method and device for installing and configuring physical machine and computer readable medium
CN112433944A (en) Service testing method, device, computer equipment and storage medium
CN112631919B (en) Contrast test method, device, computer equipment and storage medium
CN110727575A (en) Information processing method, system, device and storage medium
CN109447384A (en) Verification method, device, equipment and the storage medium of air control system
CN111221727A (en) Test method, test device, electronic equipment and computer readable medium
CN110990289B (en) Method and device for automatically submitting bug, electronic equipment and storage medium
CN107357721B (en) Method and device for testing system
CN109586946B (en) Exception handling method and device and computer readable storage medium
US7962789B2 (en) Method and apparatus for automated testing of a utility computing system
CN116909936B (en) Big data automatic test method, equipment and readable storage medium
KR20150030297A (en) Verification apparatus, terminal device, system, method and computer-readable medium for verifying application
CN116069334B (en) Cloud-protogenesis-based online development and code hosting method and system
CN114579473B (en) Application testing method, device, equipment and storage medium
CN113360365A (en) Flow testing method and flow testing system
CN110737426A (en) Program block creating method, program block creating device, computer equipment and storage medium
CN115587048A (en) Regression testing method, terminal device and computer readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20200918

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee after: Innovative advanced technology Co.,Ltd.

Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee before: Advanced innovation technology Co.,Ltd.

Effective date of registration: 20200918

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee after: Advanced innovation technology Co.,Ltd.

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Patentee before: Alibaba Group Holding Ltd.

TR01 Transfer of patent right