CN110825609B - Service testing method, device and system - Google Patents

Abstract

The invention discloses a service testing method, device and system. Wherein the method comprises the following steps: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data; matching the query request with at least one piece of verification data, and determining the verification data hit by the query request; and testing the verification data hit by the query request by using the data to be pushed. The invention solves the technical problem of poor test effect on the query system in the prior art.

Description

Service testing method, device and system

Technical Field

The present invention relates to the field of system testing, and in particular, to a method, an apparatus, and a system for testing services.

Background

In engineering test technology, the conventional method verifies products through fixed query strings and advertisements, and the verification through the fixed query strings has the following defects: (1) testing that the query string used is stale. The query strings are all manually constructed and contain incomplete parameters. For example, for some parameters related to the filtering function, that is, some parameters that may cause the query result to be empty, because it is uncertain whether corresponding advertisement data exists on the line, similar parameters are often avoided when constructing the query string to avoid that the query result is empty, so that the corresponding filtering function is difficult to be verified in the daily on-line monitoring test after the product release is completed. In addition, once the query string is constructed, the follow-up operation is basically not adjusted, and even if new query parameters are added in follow-up items, the query string cannot be synchronized into the test query string, so that the actually used query string is poor in authenticity. (2) the query string used for the test is single. The old online test smoke has about m use cases, corresponding to m query strings, most of the query strings are only adjusted on partial parameter values, so that the range which can be covered by the query strings is limited. (3) Each query string verifies one or more fixed verification points. Each query string is constructed based on the functional point to be verified, so that the relationship between the query string and the point to be verified is fixed, which makes each query string have limited functions and further limits the verification of the diversity of the returned advertisement data of the system by the on-line test.

Aiming at the problem of poor test effect on a query system in the prior art, no effective solution is proposed at present.

Disclosure of Invention

The embodiment of the invention provides a service testing method, device and system, which at least solve the technical problem of poor testing effect on a query system in the prior art.

According to an aspect of an embodiment of the present invention, there is provided a method for testing a service, including: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data; matching the query request with at least one piece of verification data, and determining the verification data hit by the query request; and testing the verification data hit by the query request by using the data to be pushed.

According to another aspect of the embodiment of the present invention, there is also provided a service testing apparatus, including: the system comprises an acquisition module, a push module and a push module, wherein the acquisition module is used for acquiring a query request and data to be pushed requested from the system based on the query request, and the query request comprises a request which is acquired from a network and is generated based on input data; the matching module is used for matching the query request with at least one piece of verification data and determining the verification data hit by the query request; and the testing module is used for testing the verification data hit by the query request by using the data to be pushed.

According to another aspect of the embodiment of the present invention, there is also provided a storage medium including a stored program, wherein the program controls a device in which the storage medium is located to execute the following steps when running: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data; matching the query request with at least one piece of verification data, and determining the verification data hit by the query request; and testing the verification data hit by the query request by using the data to be pushed.

According to another aspect of the embodiment of the present invention, there is also provided a processor for running a program, wherein the program executes the following steps: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data; matching the query request with at least one piece of verification data, and determining the verification data hit by the query request; and testing the verification data hit by the query request by using the data to be pushed.

According to another aspect of the embodiment of the present invention, there is also provided a service testing system, including: a processor; and a memory, coupled to the processor, for providing instructions to the processor for processing the steps of: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data; matching the query request with at least one piece of verification data, and determining the verification data hit by the query request; and testing the verification data hit by the query request by using the data to be pushed.

In the embodiment of the invention, the system is tested by using the real query request acquired from the online and the data to be pushed corresponding to the real query request, so that the test coverage rate is extremely high, and the data to be pushed returned by the system based on the query request used by the actual query is richer, thereby being capable of discovering the possible problems on the online to the greatest extent. Furthermore, because the query request and the verification data are dynamically matched, no data is needed to be prepared for the verification data manually, and verification data which needs to be verified is not needed to be fixed for the query request, so that the aim of improving the test efficiency is also achieved.

Therefore, the embodiment of the application solves the technical problem that the test effect on the query system is poor in the prior art.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiments of the invention and together with the description serve to explain the invention and do not constitute a limitation on the invention. In the drawings:

fig. 1 shows a hardware block diagram of a computer terminal (or mobile device) for implementing a test method of a service;

FIG. 2 is a flow chart of a method of testing services according to embodiment 1 of the present application;

FIG. 3 is a schematic diagram of a query request matching authentication data according to embodiment 1 of the present application;

FIG. 4 is a schematic diagram of a testing device for a service according to embodiment 2 of the present application;

FIG. 5 is a schematic block diagram of a processor in a test system according to embodiment 3 of the present application; and

fig. 6 is a block diagram of a computer terminal according to embodiment 4 of the present invention.

Detailed Description

In order that those skilled in the art will better understand the present invention, a technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.

It should be noted that the terms "first," "second," and the like in the description and the claims of the present invention and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the invention described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

First, partial terms or terminology appearing in describing embodiments of the present application are applicable to the following explanation:

verification point: the point of action needs to be verified in the system.

And (3) testing: the test is an audit or comparison between the actual output and the expected output, and the purpose of testing the system is to verify whether the system has potential problems, so that the system can be found out in real time and the formal operation of the system is ensured. In the scheme, the system is tested in the final stage of product delivery, and the final quality of the product can be ensured by using the testing scheme of full scene big data.

Example 1

There is also provided, in accordance with an embodiment of the present invention, an embodiment of a method of testing services, it being noted that the steps shown in the flowchart of the figures may be performed in a computer system, such as a set of computer executable instructions, and, although a logical sequence is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than what is shown or described herein.

The method embodiment provided in the first embodiment of the present application may be executed in a mobile terminal, a computer terminal or a similar computing device. Fig. 1 shows a block diagram of a hardware structure of a computer terminal (or mobile device) for implementing a test method of a service. As shown in fig. 1, the computer terminal 10 (or mobile device 10) may include one or more processors 102 (shown as 102a, 102b, … …,102 n) which may include, but are not limited to, a microprocessor MCU or a processing device such as a programmable logic device FPGA, a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, the method may further include: a display, an input/output interface (I/O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of the I/O interface), a network interface, a power supply, and/or a camera. It will be appreciated by those of ordinary skill in the art that the configuration shown in fig. 1 is merely illustrative and is not intended to limit the configuration of the electronic device described above. For example, the computer terminal 10 may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.

It should be noted that the one or more processors 102 and/or other data processing circuits described above may be referred to generally herein as "data processing circuits. The data processing circuit may be embodied in whole or in part in software, hardware, firmware, or any other combination. Furthermore, the data processing circuitry may be a single stand-alone processing module, or incorporated, in whole or in part, into any of the other elements in the computer terminal 10 (or mobile device). As referred to in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of the path of the variable resistor termination to interface).

The memory 104 may be used to store software programs and modules of application software, such as program instructions/data storage devices corresponding to the testing method of services in the embodiments of the present invention, and the processor 102 executes the software programs and modules stored in the memory 104, thereby executing various functional applications and data processing, that is, implementing the vulnerability detection method of application program. Memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory located remotely from the processor 102, which may be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission means 106 is arranged to receive or transmit data via a network. The specific examples of the network described above may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC) that can connect to other network devices through a base station to communicate with the internet. In one example, the transmission device 106 may be a Radio Frequency (RF) module for communicating with the internet wirelessly.

The display may be, for example, a touch screen type Liquid Crystal Display (LCD) that may enable a user to interact with a user interface of the computer terminal 10 (or mobile device).

It should be noted here that, in some alternative embodiments, the computer device (or mobile device) shown in fig. 1 described above may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that fig. 1 is only one example of a specific example, and is intended to illustrate the types of components that may be present in the computer device (or mobile device) described above.

In engineering test technology, products providing commodity recommendation service have the concept of test backward movement, namely, the products are tested in the final stage of product delivery, and the final quality of the products can be ensured only by using a test scheme of full scene big data as the final stage is the final stage. In the case of test back-off, in the above-described operating environment, the present application provides a method of testing services as shown in fig. 2. Fig. 2 is a flowchart of a test method of a service according to embodiment 1 of the present application.

Step S21, collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data.

Specifically, the collected query request and data to be pushed are the query request actually received by the system when the system runs on line, and the data to be pushed actually returned to the requester by the system.

The query request may include a query parameter, where the query parameter is used to request content that accords with the query parameter from the system, and the data to be pushed is a query result obtained by the system running a predetermined query rule based on the query request. The input data may be data input by a main search, may include user information and the like, and is used for providing the system with the selection of optimal data to be pushed according to a predetermined algorithm.

The system is a tested system, the query request can be input into the system in the form of a query string, the query request comprises a query parameter, the query parameter can be the type, the source and the attribute of data, the user information of a target pushing user and the like, and the target pushing user is a pushing target of data to be pushed corresponding to the query request.

In an alternative embodiment, taking advertisement inquiry as an example, a user searches for a commodity to be purchased through a shopping website, the shopping website (i.e. the main search) returns commodity information to the user, and simultaneously returns a certain number of advertisements to the user, wherein the advertisements are data to be pushed, which are requested by the shopping website to the system by using an inquiry request. The shopping website generates a query request according to the user information and the query keyword input by the user in the search, the system searches by using the query request, and the searched result is returned to the shopping website.

The part of the process is the working process when the system runs on line, and the step S21 is to collect the query request and the data to be pushed generated in the process. In an alternative embodiment, multiple real query requests can be periodically fetched from the line according to the on-line traffic ratio as query requests used by the system test, and the data to be pushed is also data returned by the system when the system receives the real query requests.

The query request and the data to be pushed for testing are real, so that the flow change and the parameter change on the line can be fed back to the system testing process in time, the possible problems on the line can be found more fully, and the query request for testing is richer.

Step S23, the query request is matched with at least one piece of verification data, and the verification data hit by the query request is determined.

Specifically, the verification data is used for characterizing verification points, namely functional points which need to be verified in the tested system.

The query requests are matched with the verification data for determining which query request is used to match the verification point corresponding to the verification data. Because the query request is not generated manually according to the verification data, but is directly acquired from the online, no corresponding relation exists between the query request and the verification data, and the query request and the verification data need to be matched in order to determine the corresponding relation between the query request and the verification data.

The verification data is generally used for testing a certain function of the system, so that the requirements of the verification data on the test data are different, one query string from the PC end is difficult to test the verification data for testing the function on the mobile terminal, and therefore, the condition which is required to be met by the query request capable of testing the verification data can be determined according to the function required by the verification data, and the query request meeting the condition can hit the verification data.

In an alternative embodiment, it is necessary to verify whether the screening function of the price screening interval of the system is normal, so the requirement of the verification data on the query request may include that the query request includes the price interval. During the matching process, a query request with a price range may hit the verification data.

Step S25, testing the verification data hit by the query request by using the data to be pushed.

In the above step S25, the hit verification data is tested using the query request, which may be performed during the system operation.

And testing hit verification data by using the query request, namely analyzing the data to be pushed corresponding to the query request to determine whether the data to be pushed is accurate, wherein the system is used for determining the correct data to be pushed corresponding to the query request according to the data to be pushed returned by the query request under normal conditions.

If the data to be pushed is correct data to be pushed, the verification point corresponding to the verification data passes the test, and if the data to be pushed is incorrect, the verification point corresponding to the verification data cannot pass the test, which means that the system may have a fault at the verification point.

In an alternative embodiment, taking still whether the screening function of the price screening interval of the test system is normal as an example, after determining that the query request of the verification data is hit, testing the verification data through the data to be pushed of the query request. The data to be pushed is an advertisement returned by the system, and if n query requests hit the verification data exist, the verification data test is passed if the prices of the commodities in the data to be pushed corresponding to the n query requests are all in the price interval in the query request; if the price of the commodity in the data to be pushed corresponding to any one inquiry request is not in the price interval in the inquiry request, the verification data test fails.

In another alternative embodiment, a plurality of query nodes exist in the system, each query node queries the query request in a separate query mode, and each query node adds a query node identifier to the data to be pushed when returning the data to be pushed. For example: the method comprises the steps that two query nodes A and B are arranged, different query rules are used for querying a query request, the query results returned by the query node A comprise identifiers A, and the query results returned by the query node B comprise identifiers B. In this case, the verification data may be set to verify whether each query node is normal. And in all query requests hitting the verification data, if the data to be pushed corresponding to each query request comprises the data to be pushed identified as A and the data to be pushed identified as B, the verification data test is considered to pass, and if the query result corresponding to each query request comprises only the data to be pushed identified as A or only the data to be pushed identified as B, the verification data test is determined to fail.

In the embodiment of the application, the system is tested by using the real query request acquired from the online and the data to be pushed corresponding to the real query request, so that the test coverage rate is extremely high, and the data to be pushed returned by the system based on the query request used by the actual query is richer, so that the possible problems on the online can be found to the greatest extent. Furthermore, because the query request and the verification data are dynamically matched, no data is needed to be prepared for the verification data manually, and verification data which needs to be verified is not needed to be fixed for the query request, so that the aim of improving the test efficiency is also achieved.

Therefore, the embodiment of the application solves the technical problem that the test effect on the query system is poor in the prior art.

As an alternative embodiment, matching the query request with at least one verification data, determining the verification data hit by the query request, includes: acquiring an admission condition and a rule tag of verification data, wherein the admission condition of the verification data is used for representing a condition for allowing a query request to enter verification of the verification data, and the rule tag of the verification data is used for representing a service function verified by the verification data; and determining verification data hit by the query request based on the admission condition and rule labels of the verification data according to the content and the data to be pushed in the query request.

In the above scheme, the admission condition and the rule tag are the requirements of the verification data on the query request, and the query string meeting the admission condition of the verification data and the rule tag can hit the verification point.

Specifically, an admission condition of verification data refers to a condition that a query request that allows testing of verification data needs to satisfy. The verification data is actually a rule, and the rule label can be the name of the verification point corresponding to the verification data.

In an alternative embodiment, taking a test engine to test the verification data as an example, the number of query requests entering the test engine is larger, the test engine uses the admission condition and the rule tag of the verification data to screen out the query requests meeting the admission condition and the rule tag, the screened query requests are query strings hitting the verification data, and only the screened query requests can enter the verification point corresponding to the verification data to verify the verification data.

As an alternative embodiment, according to the content in the query request and the data to be pushed, determining the verification data hit by the query request based on the admission condition and rule tag of the verification data includes: screening the query request by using the rule tag of the verification data to obtain the query request meeting the rule tag; and screening the query requests meeting the rule labels by using the admission conditions of the verification data to obtain the query requests meeting the admission conditions.

Specifically, each verification data has its own rule tag for indicating the function to be verified by the verification data, which may be a function name, and the query request satisfying the rule tag may be a query request including the same field as the rule tag.

The admission conditions may include two kinds, one is an admission condition for the query request, and the other is an admission condition for data to be pushed, and when both the query request and the data to be pushed satisfy the admission conditions, it is determined that the query request hits the verification data.

In an alternative embodiment, taking a test engine as an example, for one verification data, the test engine uses a rule tag of the verification data first, finds a query request containing the rule tag from a plurality of incoming query requests, and further screens the query request containing the rule tag by using an admission condition, thereby obtaining a query request hitting the verification data.

It should be noted that the screening in the two steps may be performed with one or more screening results, or may be performed without a screening result, and in the case without a screening result, it is indicated that there is no query request capable of hitting the verification data. In the case where no query request hits the verification data, the following processes may be performed, respectively, according to the type of the verification data:

The verification data in one test engine can comprise two types, wherein the first type of verification data can be hit at least once, the test engine can complete the verification data of the test, and the second type of verification data can be hit even if the verification data is missed once, and the test engine can complete the verification data of the test. If the first type of verification data is not hit by the query request, other query requests need to be acquired, and matching is continued until the first type of verification data is hit at least once; and for the second type of verification data, if the second type of verification data is not hit by the query request, special processing is not needed.

As an alternative embodiment, filtering the query request using the rule tag of the verification data to obtain the query request satisfying the rule tag includes: acquiring a first field corresponding to a rule tag in a query request; searching a query request of which the first field is consistent with the rule tag of the verification data in the query request; the query request with the first field consistent with the rule tag of the verification data is determined to be the query request meeting the rule tag.

Specifically, the searching for the first field in the query request is consistent with the rule tag of the verification data, which may be searching for the first field which is completely the same as the rule tag of the verification data in the query request, or searching for the first field which has a preset corresponding relationship with the rule tag of the verification data.

For example: the query request includes a plurality of fields, the field corresponding to the rule tag may be a "name" field in the query request, and if the content of the field in the query request is the same as the rule tag of the verification data, it is determined that the query request satisfies the rule tag of the verification data.

In an alternative embodiment, a rule tag of verification data is tbead, when matching it, the "name" field in each query request is matched with tbead, and if the "name" field in a query request is found to be tbead, that is, name=tbead, the rule tag that the query request satisfies the verification data is determined.

As an alternative embodiment, using the admission condition of the verification data, the filtering the query request meeting the rule tag to obtain the query request meeting the admission condition includes: judging whether the query parameters in the query request meet a first admission condition in the admission conditions, wherein the first admission condition corresponds to the query string; and determining the query request with the query parameter meeting the first admission condition as the query request meeting the admission condition.

Specifically, the first admission condition is a condition that the query request needs to meet, and if the query request meets the first admission condition, it is determined that the query request hits the validation data. The query parameters are represented by different fields in the query request, and the manner of determining whether the query request satisfies the first verification condition may be to determine whether the query parameters in the query request satisfy the first admission condition.

In an alternative embodiment, one authentication data is used to test the traffic of the mobile terminal, so that the first admission condition of the authentication data comprises at least: the query request is from the mobile terminal. The first admission condition may be source=2 if the source field in the query request indicates the source of the query request, source=1 indicates that the query request is from a PC, and source=2 indicates that the query request is from a mobile terminal. When screening is performed, the query request with source=2 in the query requests is a query request meeting the first admission condition.

It should be noted that, in the above embodiment, if the verification data has only one admission rule, it is determined that the query request satisfying the admission rule hits the verification data, and if the verification data has other admission rules, the filtering needs to be continued by using other admission rules, so that the query request satisfying all admission rules of the verification data does not hit the query request of the verification data.

As an alternative embodiment, using the admission condition of the verification data, the filtering the query request meeting the rule tag to obtain the query request meeting the admission condition includes: judging whether the query parameters in the query request meet the first admission condition or not; judging whether the data to be pushed in the query request meets a second access condition in the access conditions, wherein the second access condition corresponds to the data to be pushed; and determining that the query parameters meet the first admission condition, and the data to be pushed meet the query request of the second admission condition, wherein the query request meets the admission condition.

Specifically, the second admission condition is an admission condition of data to be pushed corresponding to the query request. After the query requests hit the verification data, the verification data needs to be tested by using the data to be pushed corresponding to the query requests, so that certain requirements are required for some special verification data to be pushed, and the requirements form the second admittance condition. In the above scheme, not only the query request is required to meet the first admission condition, but also the data to be pushed is required to meet the second admission condition.

In an alternative embodiment, the second admission condition for verifying the data may be a condition that the number of data to be pushed corresponding to the query request is greater than m. And under the condition that the query request meets the first admission condition, judging whether the quantity of data to be pushed corresponding to the query request is more than m pieces, and if the quantity of data to be pushed corresponding to the query request is more than m pieces, determining that the query request hits the verification data.

Fig. 3 is a schematic diagram of matching a query request with verification data according to embodiment 1 of the present application, and in conjunction with fig. 3, a query string (i.e. a query request) and a query result (i.e. data to be pushed) are fished on line through a data engineering model, where an interface name is a field in the query request. Since the same request may be different from the returned data to be pushed by multiple queries, the same query request may hit different verification data according to the different returned data to be pushed.

In this example, the query result obtained by the first query of the query string is a query result M, then the query string and the rule (i.e., the verification data) are matched, whether the interface name in the query string meets the rule label of the rule is detected, whether the query parameter in the query string and the query result M meet the admission condition is detected, and finally the rule hit by the query string is obtained, namely, the rule B.

And (3) the query result obtained by the second query of the query string is a query result N, then the query string and the rule are matched, whether the interface name in the query string is the same as the rule label of the rule or not is detected, whether the query parameter in the query string and the query result N meet the admission condition or not is detected, and finally the rule hit by the query string, namely the rule F, is obtained.

As an optional embodiment, after matching the query request with the verification data according to the content in the query request and the data to be pushed, and determining the verification data hit by the query request, the method further includes: detecting the coverage rate of the query request, wherein the coverage rate of the query request is used for representing the proportion of verification data hit by the query request in all the verification data; if the coverage rate of the query request is smaller than a preset value, testing by using the next query request; and stopping the test if the coverage rate of the query request is greater than or equal to a preset value.

Specifically, the total verification data may refer to all verification data in the test engine, and the preset value may be a preset reference value of the coverage rate of the verification data.

Under the condition that the coverage rate of the verification data is smaller than a preset value, the real query request and the data to be pushed corresponding to the query request can be obtained from the online again, namely, the steps S21 and S23 are executed again until the coverage rate is larger than or equal to the preset value, and then the testing step in the step S25 is executed again.

If the coverage of the verification data is greater than or equal to the preset value, the hit rate of the verification data in the test engine is considered to have satisfied the requirement, so that the continuous matching can be stopped, and the step S25 is entered to test the hit verification data.

In an alternative embodiment, a test engine is used for verifying a plurality of verification data, after a group of inquiry requests enter the test engine, the verification data are serially or parallelly matched with each inquiry request, the coverage rate of the verification data is redetermined once every time one verification data is hit or every preset time passes in the matching process, if the proportion of the hit verification data in all verification data in the test engine is greater than or equal to the preset value, the matching is stopped, the currently hit verification data is tested, if the proportion of the hit verification data in all verification data in the test engine is less than the preset value, the matching needs to be continued, and if the proportion of the hit verification data in all verification data in the test engine is still less than the preset value when the inquiry requests are matched with the verification data, a new inquiry request is input to the test engine, and the matching is continued with the verification data.

According to the scheme, the coverage rate of the verification data is determined, the test data (and the query request) is added when the coverage rate is insufficient, and the continuous matching is stopped when the coverage rate reaches a preset value, so that the dynamic management of the matching of the verification data is realized.

As an alternative embodiment, after testing the verification data hit by the query request with the query request, the method further comprises: if the test fails, matching a test record corresponding to the verification data in a system vulnerability database, wherein the system vulnerability database is used for recording the test record of the test failure; and generating an analysis result of the verification according to the test record.

After the hit verification data is tested by using the query request, two test results of test success and test failure can be obtained, the verification data which is tested to be failed corresponds to a system vulnerability, and after the test failure, the reason of the test failure is usually required to be analyzed, namely the system vulnerability which causes the test failure at the time is found.

The test engine maintains a system database for storing test records of test failure and corresponding system loopholes, and after the test failure, other test records corresponding to verification data of the test failure can be searched from the system loophole database, so that an analysis result of the test failure can be directly obtained from the system loophole database, and time spent in positioning and analysis is reduced.

If other test records corresponding to the verification data failing to the test are not found in the system vulnerability database, the test is required to be analyzed to obtain the system vulnerability corresponding to the test, and the analysis result is recorded in the system vulnerability database.

As an alternative embodiment, the validation data comprises a first type of validation data that must be hit and a second type of validation data that is allowed to be miss, wherein all of the first type of validation data in the test engine is hit, determining that the test engine completes the test.

In the above scheme, the verification data in one test engine may include two types, the first type of verification data is verification data that can be hit at least once, the test engine can complete the test, and the second type of verification data is verification data that can be hit even once, and the test engine can complete the test. If the first type of verification data is not hit by the query request, other query requests need to be acquired, and matching is continued until the first type of verification data is hit at least once; and for the second type of verification data, if the second type of verification data is not hit by the query request, special processing is not needed.

It should be noted that, for simplicity of description, the foregoing method embodiments are all described as a series of acts, but it should be understood by those skilled in the art that the present invention is not limited by the order of acts described, as some steps may be performed in other orders or concurrently in accordance with the present invention. Further, those skilled in the art will also appreciate that the embodiments described in the specification are all preferred embodiments, and that the acts and modules referred to are not necessarily required for the present invention.

From the description of the above embodiments, it will be clear to a person skilled in the art that the method according to the above embodiments may be implemented by means of software plus the necessary general hardware platform, but of course also by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) comprising several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method of the various embodiments of the present invention.

Example 2

According to an embodiment of the present invention, there is further provided a service testing apparatus for implementing the service testing method, and fig. 4 is a schematic diagram of a service testing apparatus according to embodiment 2 of the present application, as shown in fig. 4, and the apparatus 400 includes:

the collection module 402 is configured to collect a query request and data to be pushed requested from the system based on the query request, where the query request includes a request that is collected from a network and generated based on input data.

A matching module 404, configured to match the query request with at least one verification data, and determine the verification data hit by the query request.

And the testing module 406 is configured to test the verification data hit by the query request by using the data to be pushed.

It should be noted that, the above-mentioned acquisition module 402, matching module 404 and test module 406 correspond to steps S21 to S25 in embodiment 1, and the two modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the above-mentioned embodiment one. It should be noted that the above-described module may be operated as a part of the apparatus in the computer terminal 10 provided in the first embodiment.

As an alternative embodiment, the matching module includes: the acquisition sub-module is used for acquiring the admission condition and rule tag of the verification data, wherein the admission condition of the verification data is used for representing the condition for allowing the query request to enter the verification of the verification data, and the rule tag of the verification data is used for representing the service function verified by the verification data; and the determining submodule is used for determining verification data hit by the query request based on the admission condition and rule labels of the verification data according to the content in the query request and the data to be pushed.

As an alternative embodiment, the determining submodule includes: the first screening unit is used for screening the query request by using the rule tag of the verification data to obtain the query request meeting the rule tag; and the second screening unit is used for screening the query requests meeting the rule labels by using the admission conditions of the verification data to obtain the query requests meeting the admission conditions.

As an alternative embodiment, the first screening unit comprises: the acquisition subunit is used for acquiring a first field corresponding to the rule tag in the query request; a searching subunit, configured to search a query request in which a first field is consistent with a rule tag of verification data in the query request; and the first determining subunit is used for determining that the query request of which the first field is consistent with the rule tag of the verification data is the query request meeting the rule tag.

As an alternative embodiment, the second screening unit comprises: a first judging subunit, configured to judge whether a query parameter in the query request meets a first admission condition in the admission conditions, where the first admission condition corresponds to the query string; and the second determining subunit is used for determining that the query request with the query parameter meeting the first admission condition is the query request meeting the admission condition.

As an alternative embodiment, the second screening unit comprises: the second judging subunit is used for judging whether the query parameters in the query request meet the first admission condition; a third judging subunit, configured to judge whether the data to be pushed in the query request meets a second access condition of the access conditions, where the second access condition corresponds to the data to be pushed; and the third determining subunit is used for determining that the query parameter meets the first admission condition, and the data to be pushed meets the query request of the second admission condition, and is the query request meeting the admission condition.

As an alternative embodiment, the above device further comprises: the detection module is used for detecting the coverage rate of the query request after testing the hit verification data of the query request by using the data to be pushed, wherein the coverage rate of the query request is used for representing the proportion of the hit verification data of the query request in all the verification data; the continuous testing module is used for testing by using the next query request if the coverage rate of the query request is smaller than a preset value; and the stopping module is used for stopping the test if the coverage rate of the query request is greater than or equal to a preset value.

As an alternative embodiment, the above device further comprises: after testing verification data hit by a query request by using data to be pushed, a searching module is used for matching test records corresponding to the verification data in a system vulnerability database if the test fails, wherein the system vulnerability database is used for recording the test records of the test failure; and the generating module is used for generating an analysis result of the verification according to the test record.

As an alternative embodiment, the validation data comprises a first type of validation data that must be hit and a second type of validation data that is allowed to be miss, wherein all of the first type of validation data in the test engine is hit, determining that the test engine completes the test.

Example 3

An embodiment of the present invention may provide a service testing system, including:

a processor; and

a memory, coupled to the processor, for providing instructions to the processor for processing the steps of: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data; matching the query request with at least one piece of verification data, and determining the verification data hit by the query request; and testing the verification data hit by the query request by using the data to be pushed.

Specifically, the above memory also provides instructions for the processor to process other steps in embodiment 1, which are not described herein.

Fig. 5 is a schematic diagram of a processor in a test system according to embodiment 3 of the present application, and in combination with fig. 5, a data factory module is configured to capture a custom query string and a query result for testing on line, analyze and manage the captured data, store the data in a DB database, and a dispatch service module includes a dispatch Master for sending a request to a rule engine, performing rule invocation, index statistics and exception handling of the rule engine, and is further connected to a trace server and a trace engine for performing trace analysis on the result test result. The rule engine is the test engine and comprises a plurality of rules, namely verification data, and is used for managing the rules and comprises rule preprocessing, rule mapping, rule matching and rule execution. The WEB front-end module is used for performing task triggering according to a user instruction, performing data set display, rule set display and test result display.

Example 4

Embodiments of the present invention may provide a computer terminal, which may be any one of a group of computer terminals. Alternatively, in the present embodiment, the above-described computer terminal may be replaced with a terminal device such as a mobile terminal.

Alternatively, in this embodiment, the above-mentioned computer terminal may be located in at least one network device among a plurality of network devices of the computer network.

In this embodiment, the computer terminal may execute the program code of the following steps in the vulnerability detection method of the application program: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data; matching the query request with at least one piece of verification data, and determining the verification data hit by the query request; and testing the verification data hit by the query request by using the data to be pushed.

Alternatively, fig. 6 is a block diagram of a computer terminal according to embodiment 4 of the present invention. As shown in fig. 6, the computer terminal a may include: one or more (only one is shown) processors 602, memory 604, and a transmission 606.

The memory may be used to store software programs and modules, such as program instructions/modules corresponding to the security vulnerability detection method and device in the embodiments of the present invention, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-mentioned method for detecting a system vulnerability attack. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further include memory remotely located with respect to the processor, which may be connected to terminal a through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The processor may call the information and the application program stored in the memory through the transmission device to perform the following steps: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data; matching the query request with at least one piece of verification data, and determining the verification data hit by the query request; and testing the verification data hit by the query request by using the data to be pushed. .

Optionally, the above processor may further execute program code for: acquiring an admission condition and a rule tag of verification data, wherein the admission condition of the verification data is used for representing a condition for allowing a query request to enter verification of the verification data, and the rule tag of the verification data is used for representing a service function verified by the verification data; and determining verification data hit by the query request based on the admission condition and rule labels of the verification data according to the content and the data to be pushed in the query request.

Optionally, the above processor may further execute program code for: screening the query request by using the rule tag of the verification data to obtain the query request meeting the rule tag; and screening the query requests meeting the rule labels by using the admission conditions of the verification data to obtain the query requests meeting the admission conditions.

Optionally, the above processor may further execute program code for: acquiring a first field corresponding to a rule tag in a query request; searching a query request of which the first field is consistent with the rule tag of the verification data in the query request; the query request with the first field consistent with the rule tag of the verification data is determined to be the query request meeting the rule tag.

Optionally, the above processor may further execute program code for: judging whether the query parameters in the query request meet a first admission condition in the admission conditions, wherein the first admission condition corresponds to the query string; and determining the query request with the query parameter meeting the first admission condition as the query request meeting the admission condition.

Optionally, the above processor may further execute program code for: the admission conditions further include: judging whether the query parameters in the query request meet the first admission conditions or not according to the second admission conditions corresponding to the data to be pushed; judging whether the data to be pushed in the query request meets a second access condition in the access conditions, wherein the second access condition corresponds to the data to be pushed; and determining that the query parameters meet the first admission condition, and the data to be pushed meet the query request of the second admission condition, wherein the query request meets the admission condition.

Optionally, the above processor may further execute program code for: detecting the coverage rate of the query request after testing the hit verification data of the query request by using the data to be pushed, wherein the coverage rate of the query request is used for representing the proportion of the hit verification data of the query request in all the verification data; if the coverage rate of the query request is smaller than a preset value, testing by using the next query request; and stopping the test if the coverage rate of the query request is greater than or equal to a preset value.

Optionally, the above processor may further execute program code for: after testing verification data hit by a query request by using data to be pushed, if the test fails, matching test records corresponding to the verification data in a system vulnerability database, wherein the system vulnerability database is used for recording the test records of the test failure; and generating an analysis result of the verification according to the test record.

Optionally, the above processor may further execute program code for: the validation data includes a first type of validation data that must be hit and a second type of validation data that is allowed to be missed, wherein all of the first type of validation data in the test engine is hit, determining that the test engine completes the test.

By adopting the embodiment of the invention, the system is tested by using the real query request acquired from the online and the data to be pushed corresponding to the real query request, so that the test coverage rate is extremely high, and the data to be pushed returned by the system based on the query request used by the actual query is richer, thereby being capable of discovering the possible problems on the online to the greatest extent. Furthermore, because the query request and the verification data are dynamically matched, no data is needed to be prepared for the verification data manually, and verification data which needs to be verified is not needed to be fixed for the query request, so that the aim of improving the test efficiency is also achieved.

Therefore, the embodiment of the application solves the technical problem that the test effect on the query system is poor in the prior art.

It will be appreciated by those skilled in the art that the configuration shown in fig. 6 is only illustrative, and the computer terminal may be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a palm-phone computer, a mobile internet device (Mobile Internet Devices, MID), a PAD, etc. Fig. 6 is not limited to the structure of the electronic device. For example, the computer terminal 60 may also include more or fewer components (e.g., network interfaces, display devices, etc.) than shown in FIG. 6, or have a different configuration than shown in FIG. 6.

Those of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be implemented by a program for instructing a terminal device to execute in association with hardware, the program may be stored in a computer readable storage medium, and the storage medium may include: flash disk, read-Only Memory (ROM), random-access Memory (Random Access Memory, RAM), magnetic or optical disk, and the like.

Example 5

The embodiment of the invention also provides a storage medium. Alternatively, in this embodiment, the storage medium may be used to store program codes executed by the test method for the service provided in the first embodiment.

Alternatively, in this embodiment, the storage medium may be located in any one of the computer terminals in the computer terminal group in the computer network, or in any one of the mobile terminals in the mobile terminal group.

Alternatively, in the present embodiment, the storage medium is configured to store program code for performing the steps of: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data; matching the query request with at least one piece of verification data, and determining the verification data hit by the query request; and testing the verification data hit by the query request by using the data to be pushed.

The foregoing embodiment numbers of the present invention are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.

In the foregoing embodiments of the present invention, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed technology content may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and the division of the units, such as the division of the units, is merely a logical function division, and may be implemented in another manner, for example, multiple units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present invention may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a removable hard disk, a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely a preferred embodiment of the present invention and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present invention, which are intended to be comprehended within the scope of the present invention.

Claims (12)

1. A method for testing a service, comprising:

collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data;

matching the query request with at least one piece of verification data, and determining the verification data hit by the query request;

testing the verification data hit by the query request by using the data to be pushed;

wherein matching the query request with at least one verification data, determining the verification data hit by the query request, comprises:

obtaining an admission condition and a rule tag of verification data, wherein the admission condition of the verification data is used for representing a condition for allowing a query request to enter verification on the verification data, the rule tag of the verification data is used for representing a service function verified by the verification data, and the admission condition comprises: admission conditions for the query request and admission conditions for the data to be pushed;

And determining the verification data hit by the query request based on the admission condition and the rule tag of the verification data according to the content in the query request and the data to be pushed.

2. The method of claim 1, wherein determining the validation data hit by the query request based on the admission condition and rule tag of the validation data based on the content in the query request and the data to be pushed comprises:

screening the query request by using the rule tag of the verification data to obtain a query request meeting the rule tag;

and screening the query requests meeting the rule labels by using the admission conditions of the verification data to obtain the query requests meeting the admission conditions.

3. The method of claim 2, wherein screening the query request using the rule tag of the validation data to obtain a query request that satisfies the rule tag comprises:

acquiring a first field corresponding to a rule tag in the query request;

searching a query request with a first field consistent with the rule tag of the verification data in the query request;

And determining the query request of which the first field is consistent with the rule tag of the verification data as the query request meeting the rule tag.

4. The method of claim 2, wherein using the admission condition for the validation data, screening the query requests that satisfy the rule tag for query requests that satisfy the admission condition comprises:

judging whether query parameters in the query request meet a first admission condition in the admission conditions or not, wherein the first admission condition corresponds to a query string;

and determining the query request with the query parameters meeting the first admission condition as the query request meeting the admission condition.

5. The method of claim 4, wherein using the admission condition for the validation data, screening the query requests that satisfy the rule tag for query requests that satisfy the admission condition comprises:

judging whether the query parameters in the query request meet the first admission condition or not;

judging whether data to be pushed in the query request meets a second access condition in the access conditions or not, wherein the second access condition corresponds to the data to be pushed;

And determining that the query parameters meet the first admission condition, and the data to be pushed meet the query request of the second admission condition, wherein the query request is the query request meeting the admission condition.

6. The method of claim 1, wherein after testing the validation data for the query request hit using the data to be pushed, the method further comprises:

detecting the coverage rate of the query request, wherein the coverage rate of the query request is used for representing the proportion of verification data hit by the query request in all the verification data;

if the coverage rate of the query request is smaller than a preset value, testing by using the next query request;

and stopping the test if the coverage rate of the query request is greater than or equal to the preset value.

7. The method of claim 6, wherein after testing the validation data for the query request hit using the data to be pushed, the method further comprises:

if the test fails, matching a test record corresponding to the verification data in a system vulnerability database, wherein the system vulnerability database is used for recording the test record of the test failure;

And generating an analysis result of the verification according to the test record.

8. The method of claim 1, wherein the validation data comprises a first type of validation data that must be hit and a second type of validation data that is allowed to be miss, wherein all of the first type of validation data in a test engine is hit, determining that the test engine completes testing.

9. A service testing apparatus, comprising:

the system comprises an acquisition module, a push module and a push module, wherein the acquisition module is used for acquiring a query request and data to be pushed requested from a system based on the query request, and the query request comprises a request which is acquired from a network and is generated based on input data;

the matching module is used for matching the query request with at least one piece of verification data and determining the verification data hit by the query request;

the testing module is used for testing the verification data hit by the query request by using the data to be pushed;

wherein the apparatus further comprises:

the system comprises an acquisition module, a rule tag and a query module, wherein the acquisition module is used for acquiring admission conditions of verification data and rule tags, the admission conditions of the verification data are used for representing conditions for allowing a query request to enter verification of the verification data, the rule tags of the verification data are used for representing service functions verified by the verification data, and the admission conditions comprise: admission conditions for the query request and admission conditions for the data to be pushed;

And the determining module is used for determining the verification data hit by the query request based on the admission condition and the rule label of the verification data according to the content in the query request and the data to be pushed.

10. A storage medium comprising a stored program, wherein the program, when run, controls a device on which the storage medium resides to perform the steps of:

collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data;

matching the query request with at least one piece of verification data, and determining the verification data hit by the query request;

testing the verification data hit by the query request by using the data to be pushed;

wherein matching the query request with at least one verification data, determining the verification data hit by the query request, comprises:

obtaining an admission condition and a rule tag of verification data, wherein the admission condition of the verification data is used for representing a condition for allowing a query request to enter verification on the verification data, the rule tag of the verification data is used for representing a service function verified by the verification data, and the admission condition comprises: admission conditions for the query request and admission conditions for the data to be pushed;

And determining the verification data hit by the query request based on the admission condition and the rule tag of the verification data according to the content in the query request and the data to be pushed.

11. A processor for running a program, wherein the program when run performs the steps of:

collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data;

matching the query request with at least one piece of verification data, and determining the verification data hit by the query request;

testing the verification data hit by the query request by using the data to be pushed;

wherein matching the query request with at least one verification data, determining the verification data hit by the query request, comprises:

obtaining an admission condition and a rule tag of verification data, wherein the admission condition of the verification data is used for representing a condition for allowing a query request to enter verification on the verification data, the rule tag of the verification data is used for representing a service function verified by the verification data, and the admission condition comprises: admission conditions for the query request and admission conditions for the data to be pushed;

And determining the verification data hit by the query request based on the admission condition and the rule tag of the verification data according to the content in the query request and the data to be pushed.

12. A system for testing services, comprising:

a processor; and

a memory, coupled to the processor, for providing instructions to the processor to process the following processing steps: collecting a query request and data to be pushed requested from a system based on the query request, wherein the query request comprises a request which is collected from a network and is generated based on input data;

matching the query request with at least one piece of verification data, and determining the verification data hit by the query request;

testing the verification data hit by the query request by using the data to be pushed;

wherein matching the query request with at least one verification data, determining the verification data hit by the query request, comprises:

obtaining an admission condition and a rule tag of verification data, wherein the admission condition of the verification data is used for representing a condition for allowing a query request to enter verification on the verification data, the rule tag of the verification data is used for representing a service function verified by the verification data, and the admission condition comprises: admission conditions for the query request and admission conditions for the data to be pushed;

And determining the verification data hit by the query request based on the admission condition and the rule tag of the verification data according to the content in the query request and the data to be pushed.

Images