CN113626321A

CN113626321A - Bridging test method, device, system and storage medium

Info

Publication number: CN113626321A
Application number: CN202110866524.9A
Authority: CN
Inventors: 孙传兴
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2021-07-29
Filing date: 2021-07-29
Publication date: 2021-11-09
Anticipated expiration: 2041-07-29
Also published as: CN113626321B

Abstract

The disclosure relates to a bridge test method, device, system and storage medium. The method comprises the following steps: receiving a page request sent by a testing end, wherein the page request is constructed by the testing end based on input target parameters, the target parameters are parameters of bridges to be tested, and the bridges to be tested are used for a native program set in a client to communicate with an H5 end; target parameters are analyzed from the page request; generating a calling method of the bridge to be tested based on the target parameter; calling the bridge to be tested by executing a calling method of the bridge to be tested so as to obtain an execution result which is processed by the client and returned by the client; and outputting the execution result of the bridge to be tested. Therefore, the automation degree of testing bridging is improved, and the testing efficiency is improved.

Description

Bridging test method, device, system and storage medium

Technical Field

The present disclosure relates to the field of computers, and in particular, to a bridge test method, apparatus, system, and storage medium.

Background

With the development of internet technology, services provided based on a network are more and more diversified, service scenes are complex, high dynamic performance is required for functions of a client, and H5 has the capability of adding new functions without releasing a new version of the client, so that functions developed based on an H5 page become an indispensable part. H5 is an abbreviation for hypertext Markup Language (HTML) 5, which is a Language way to build and present internet content. However, H5 often needs to use the capabilities of the Native (Native) program of the client to implement some functionality, such as obtaining device information, client information, opening a new client Native page, etc. To this end, a bridge (bridge) may be encapsulated according to the business scenario to enable interaction between H5 and the native program of the client. In the related art, in order to guarantee the function of bridging, the bridging needs to be tested. However, the bridge test method in the related art is too dependent on manual work, and the test efficiency is low.

Since H5 provides the front end page that is presented to the user for browsing, H5 is also referred to as front end H5. One approach to bridge testing in the related art relies on H5 to provide example code that invokes the bridge and requires a manual click on the front-end page to verify the functionality of the bridge through log (log) output. When the test engineer needs to test a newly added bridge, the developer of H5 needs to be coordinated, as shown in fig. 1, step S11, the developer of H5 is informed of the bridge under test; step S12, developing a new bridge calling method to update the front page of H5 and redeploy to the server. Then, a test is performed: step S13, manually clicking a test page; step S14, the H5 calls a bridge calling method to call the bridge of the native program arranged in the client and H5 communication; step S15, the client returns the execution result of the bridging to H5; step S16, H5 outputs the bridging related log to the test terminal; the test engineer at the test end checks the result, and in step S17, writes a test report. However, each new bridge needs a developer relying on H5 to modify the front-end page, but the invocation grammar of the bridge is often relatively fixed, each new bridge needs to coordinate the developer of H5 to modify the fields of the name, the parameter, the return value and the like of the bridge, and needs to redeploy the modified front-end page to the server, so that the simple work needs many persons to cooperate, and the defects of time consumption and labor waste exist.

Disclosure of Invention

The present disclosure provides a bridge test method, device, system and storage medium, which at least solve the problem of low test efficiency due to excessive dependence on manual work in the bridge test mode in the related art. The technical scheme of the disclosure is as follows:

according to a first aspect of the embodiments of the present disclosure, there is provided a bridge test method applied to an H5 terminal, the method including:

receiving a page request sent by a testing end, wherein the page request is constructed by the testing end based on input target parameters, the target parameters are parameters of bridges to be tested, and the bridges to be tested are used for a native program set in a client to communicate with an H5 end;

target parameters are analyzed from the page request;

generating a calling method of the bridge to be tested based on the target parameter;

calling the bridge to be tested by executing a calling method of the bridge to be tested so as to obtain an execution result which is processed by the client and returned by the client;

and outputting the execution result of the bridge to be tested.

In one possible embodiment, the step of generating the call method to be tested for bridging based on the target parameter includes:

and transmitting the target parameters into a calling method template of the bridge connection so as to generate a calling method to be tested.

In one possible embodiment, the step of inputting the target parameter into the bridged calling method template to generate the bridged calling method template to be tested comprises the following steps:

constructing a target parameter into a parameter object;

and transmitting the parameter object into a calling method template of the bridge connection so as to generate a calling method to be tested.

In one possible embodiment, the step of outputting the execution result of the bridge to be tested includes:

and sending the execution result of the bridge to be tested to an interface of a bridge test function of the test end, wherein the bridge test function comprises a first function for verifying the execution result and a second function for generating a test report for the verification result, so that the test end verifies the execution result of the bridge to be tested based on the first function to obtain the verification result of the bridge to be tested, and generates and outputs the test report for the verification result of the bridge to be tested based on the second function.

In one possible embodiment, the interface of the bridge test function is an interface of the unit test function.

In a possible embodiment, the step of sending the execution result of the bridge to be tested to the interface of the bridge test function of the test end includes:

and sending the execution result of the bridge to be tested to an interface of a bridge test function of the test end through the client.

In one possible embodiment, the target parameters include: the method comprises the following steps of setting a name space of a bridge to be tested, a name of the bridge to be tested and all parameters required to be carried when the bridge to be tested is called.

According to a second aspect of the embodiments of the present disclosure, there is provided a bridge test method applied to a test end, the method including:

constructing a page request based on an input target parameter, and sending the page request to an H5 terminal, wherein the target parameter is a parameter of a bridge to be tested, the bridge to be tested is used for a native program arranged in a client terminal to communicate with an H5 terminal, so that the H5 terminal analyzes the target parameter from the page request, a calling method of the bridge to be tested is generated based on the target parameter, the bridge to be tested is called by executing the calling method of the bridge to be tested, so that an execution result which is obtained by processing and returning the bridge to be tested by the client terminal is obtained, and the execution result of the bridge to be tested is output;

an execution result of the bridge to be tested is received.

In one possible embodiment, the step of constructing a page request based on the input target parameters comprises:

transmitting the target parameters into a page request template to obtain an initial page request;

and encoding the initial page request to obtain the page request which can be decoded at the H5 end.

In one possible embodiment, the step of receiving the execution result of the bridge to be tested comprises:

receiving an execution result of a bridge to be tested sent by an H5 terminal through an interface of a bridge test function of a test terminal, wherein the bridge test function comprises a first function for verifying the execution result and a second function for generating a test report for the verification result;

and based on the second function, generating and outputting a test report for the verification result of the bridge to be tested.

In a possible implementation manner, the step of receiving, through an interface of a bridge test function of the test end, an execution result of the bridge to be tested sent by the H5 end includes:

and receiving an execution result of the bridge to be tested, which is sent by the H5 through the client, through an interface of a bridge test function of the test end.

In a possible embodiment, the step of verifying the execution result of the bridge under test includes:

comparing whether the execution result of the bridge to be tested is the same as the input reference result;

and taking the comparison result as a verification result of the bridge to be tested.

In one possible embodiment, the method further comprises:

and responding to the determination that the testing of the bridge to be tested is finished, carrying out the retest of at least one tested target bridge except the bridge to be tested, and recording the retest result.

According to a third aspect of the embodiments of the present disclosure, there is provided a bridging test apparatus applied to an H5 terminal, the apparatus including:

the receiving unit is configured to execute a page request sent by the receiving testing terminal, the page request is constructed by the testing terminal based on input target parameters, the target parameters are parameters of bridges to be tested, and the bridges to be tested are used for a native program set in the client to communicate with the H5 terminal;

the parsing unit is configured to parse target parameters from the page request;

the generating unit is configured to generate a calling method of the bridge to be tested based on the target parameter;

the calling unit is configured to call the bridge to be tested by executing a calling method of the bridge to be tested so as to obtain an execution result which is obtained by the client processing the bridge to be tested and returning;

and the output unit is configured to output the execution result of the bridge to be tested.

In a possible implementation, the generating unit is specifically configured to perform:

constructing a target parameter into a parameter object;

In a possible implementation, the output unit is specifically configured to perform:

According to a fourth aspect of the embodiments of the present disclosure, there is provided a bridge test apparatus applied to a test terminal, the apparatus including:

the construction unit is configured to execute a page construction request based on input target parameters and send the page construction request to an H5 terminal, wherein the target parameters are parameters of bridges to be tested, the bridges to be tested are used for a native program arranged in a client terminal to communicate with an H5 terminal, so that the H5 terminal analyzes the target parameters from the page request, a calling method of the bridges to be tested is generated based on the target parameters, the bridges to be tested are called by executing the calling method of the bridges to be tested, an execution result of the client terminal processing the bridges to be tested and returning is obtained, and the execution result of the bridges to be tested is output;

a receiving unit configured to perform receiving an execution result of the bridge to be tested.

In a possible embodiment, the construction unit is specifically configured to perform:

In a possible implementation, the receiving unit is specifically configured to perform:

receiving an execution result of a bridge to be tested sent by an H5 end through a client through an interface of a bridge test function of a test end, wherein the bridge test function comprises a first function for verifying the execution result and a second function for generating a test report for the verification result;

In one possible embodiment, the apparatus further comprises:

and the test-back unit is configured to execute test-back on at least one tested target bridge except the bridge to be tested in response to the fact that the bridge to be tested is determined to be tested, and record a test-back result.

According to a fifth aspect of the embodiments of the present disclosure, there is provided a bridge test apparatus, including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the bridge test method as any one of the first and second aspects.

According to a sixth aspect of embodiments of the present disclosure, there is provided a bridge test system, comprising: a client, a testing end and an H5 end;

the client is configured to execute processing of bridges to be tested, and the bridges to be tested are used for communication of a native program arranged in the client and the H5;

the H5 terminal is configured to execute the page request sent by the receiving test terminal, analyze a target parameter from the page request, the target parameter is a parameter of the bridge to be tested, generate a calling method of the bridge to be tested based on the target parameter, call the bridge to be tested by executing the calling method of the bridge to be tested, so as to obtain an execution result which is returned by the client terminal after processing the bridge to be tested, and output the execution result of the bridge to be tested;

and the testing terminal is configured to execute a page construction request based on the input target parameters, send the page construction request to the H5 terminal and receive an execution result of the bridge to be tested.

According to a seventh aspect of embodiments of the present disclosure, there is provided a storage medium having instructions that, when executed by a processor of a bridge test apparatus, enable the bridge test apparatus to perform the bridge test method as in any one of the first and second aspects.

According to an eighth aspect of embodiments of the present disclosure, there is provided a computer program product comprising a computer program which, when executed by a processor, implements a bridge test method according to any one of the first and second aspects.

The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects:

the bridge to be tested for communicating the native program set in the client with the H5 terminal can automatically generate a calling method of the bridge to be tested through a target parameter input by the testing terminal analyzed from the page request by the H5 terminal without frequently depending on the modification and deployment of a front-end page by a developer at the H5 terminal, then automatically execute the calling method of the bridge to be tested to call the bridge to be tested, without manually clicking by a testing engineer to trigger the calling of the bridge to be tested, and finally, the execution result of the bridge to be tested is output, so that the testing of the bridge to be tested is realized, the automation degree of the bridge to be tested is integrally improved, and the testing efficiency is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the disclosure and are not to be construed as limiting the disclosure.

FIG. 1 is a flow diagram illustrating a bridge test method in accordance with an exemplary embodiment.

Fig. 2 is a system architecture diagram illustrating a bridge test method according to an example embodiment.

FIG. 3 is a flow diagram illustrating a bridge test method in accordance with an exemplary embodiment.

FIG. 4 is a flow diagram illustrating a method of bridge testing according to an example embodiment.

FIG. 5 is a flow diagram illustrating a bridge test method in accordance with an exemplary embodiment.

FIG. 6 is a flow chart illustrating a verification method in accordance with an exemplary embodiment.

FIG. 7 is a schematic diagram illustrating a test interface in accordance with an exemplary embodiment.

FIG. 8 is a schematic diagram illustrating a test interface in accordance with an exemplary embodiment.

FIG. 9 is a block diagram illustrating a bridge test apparatus in accordance with an exemplary embodiment.

FIG. 10 is a block diagram illustrating a bridge test apparatus in accordance with an exemplary embodiment.

FIG. 11 is a block diagram illustrating a bridge test apparatus in accordance with an exemplary embodiment.

FIG. 12 is a block diagram illustrating an apparatus in accordance with an example embodiment.

FIG. 13 is a block diagram illustrating an apparatus in accordance with an example embodiment.

Detailed Description

In order to make the technical solutions of the present disclosure better understood by those of ordinary skill in the art, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the disclosure described herein are capable of operation in sequences other than those illustrated or otherwise described herein. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

In order to solve the technical problems that the bridging test mode in the related art is too dependent on manual work and the test efficiency is low, the embodiment of the disclosure provides a bridging test method, which is described in detail below.

Fig. 2 is a system architecture diagram illustrating a bridge test method according to an example embodiment. As shown in fig. 2, the bridge test method provided by the embodiment of the present disclosure may be applied to the system architecture shown in fig. 2, where the system architecture includes a test end 201, a client 202, and a server corresponding to the client, and the server is deployed with H5, which is referred to as an H5 end 203. The page of the client is partly realized by a native program, and partly by the H5 terminal. The client is provided with a bridge for the native program to communicate with the H5 terminal. In practical application, when the bridge of the client is required to be tested, a test engineer can perform simple input operation at a test end, then, the bridge test is automatically realized through the cooperation of the test end, the H5 end and the client, and the test end can quickly obtain a result, so that the test efficiency is improved.

First, taking the execution of the H5 terminal as an example, the bridge test method provided by the embodiment of the disclosure is described.

Fig. 3 is a flowchart illustrating a bridge test method according to an exemplary embodiment, which is used in the H5 terminal, as shown in fig. 3, and includes the following steps.

In step S31, a page request sent by the test end is received, where the page request is constructed by the test end based on the input target parameters, and the target parameters are parameters of bridges to be tested, which are used for the native program set in the client to communicate with the H5 end.

The native program arranged in the client and the H5 end perform communication interaction depending on a set of specifications, for example, any bridge call requires some parameters, where the target parameters are parameters that are commonly required by the bridge calls. In practical application, the target parameters are obtained by the test end through input operation of a test engineer.

In step S32, the target parameter is parsed from the page request.

The target parameters are transmitted to the end of H5 by page request in this step.

In step S33, a calling method of the bridge to be tested is generated based on the target parameter.

In step S34, the bridge to be tested is called by executing the call method of the bridge to be tested, so as to obtain an execution result that the client processes and returns the bridge to be tested.

In practical application, after the calling method of the bridge to be tested is executed, the bridge to be tested can be called, and correspondingly, the client can process the bridge to be tested and return the execution result of the bridge to be tested. For example, if the bridge to be tested is an interface for obtaining the device information, the corresponding execution result is the device information.

In step S35, the execution result of the bridge to be tested is output.

In this embodiment, the bridge to be tested, which communicates with the H5 end for the native program set in the client, may be automatically generated by the H5 end through the target parameter input by the test end parsed from the page request, without frequently relying on the developer at the H5 end to modify the front-end page and deploy, then automatically execute the method to be tested to call the bridge to be tested, without the test engineer manually clicking to trigger the call of the bridge to be tested, and finally, the execution result of the bridge to be tested is output, thereby implementing the test on the bridge to be tested.

In an exemplary embodiment, the target parameter may include: the method comprises the following steps of setting a name space of a bridge to be tested, a name of the bridge to be tested and all parameters required to be carried when the bridge to be tested is called.

Where the namespace is used to organize and reuse the code. In practical applications, there may be many bridges, which correspond to different types of functions respectively, and are classified by a namespace, so as to distinguish different functions, for example, bridging of tool classes, where the namespace may be tool.

All parameters required to be carried when the bridge to be tested is called can be represented by symbols, at least a name space of the bridge to be tested and a name of the bridge to be tested can be included, and other parameters can be included.

Illustratively, the namespace may be represented by the symbol namespace. The name of the bridge to be tested may be denoted by the symbol name. All parameters that need to be carried when a bridge to be tested is called can be denoted by the notation bridge.

In an exemplary embodiment, a specific implementation manner of the step of generating the call method to be tested for bridging based on the target parameter may include: and transmitting the target parameters into a calling method template of the bridge connection so as to generate a calling method to be tested.

In practical application, a bridge calling method template may be pre-stored, where the bridge calling method template includes a common code for calling the bridge, and the common code needs parameters of the incoming call bridge. The public code may also contain identification information of the locally stored bridge of calls. Based on the method, the target parameters are transmitted into the bridge calling method template, and the final bridge calling method to be tested can be obtained. Therefore, the method realizes the quick and automatic construction of the calling method of the bridge to be tested without depending on developers at the H5 end.

In an exemplary embodiment, the specific implementation manner of the step of passing the target parameter into the bridge-connected calling method template to generate the bridge-to-be-tested calling method may include: constructing a target parameter into a parameter object; and transmitting the parameter object into a calling method template of the bridge connection so as to generate a calling method to be tested. In this embodiment, a method of constructing a target parameter into a parameter object and then inputting a bridge-connected invocation method template is adopted, and based on this, the bridge-connected invocation method template may be written in an object-oriented language, for example, a JS (java description script for short) language widely applied to a web page.

For example, the three parameters namespace, name and bridgeparam may be constructed as the object bridgeInfo, and the namespace, name and bridgeparam in the bridgeInfo are imported into the bridged calling method template, and the exemplary code is as follows:

__yodaBridge__.invoke(bridgeInfo.namespace,bridgeInfo.name,JSON.Stringify(bridgeInfo.bridgeparam)，“1”)。

where "1" is identification information of the bridge to be tested.

Therefore, the position of the parameter of the bridge to be transferred in the bridge calling method template is replaced by the value of the target parameter, and the bridge calling method to be tested can be generated.

In addition, the target parameter can also be directly transmitted into the bridge calling method template to generate the bridge calling method to be tested. And adopting a proper language to realize a preset bridging calling method.

The above example shows a scheme of generating a calling method of a bridge to be tested through a calling method template of the bridge, and the calling method of the bridge to be tested may also be generated through other manners, for example, a generation rule of the calling method of the bridge may be preset, and according to the generation rule, a target parameter is processed to generate the calling method of the bridge to be tested.

In an exemplary embodiment, a specific implementation manner of the step of parsing the target parameter from the page request may include: all parameters contained in the page request are analyzed, and target parameters are segmented from all the analyzed parameters.

Illustratively, all parameters included in the constructed page request can be parsed by a window. The segmentation method can be realized based on word segmentation technology.

In an exemplary embodiment, the step of outputting the execution result of the bridge to be tested may specifically include: and sending the execution result of the bridge to be tested to an interface of a bridge test function of the test end, wherein the bridge test function comprises a first function for verifying the execution result and a second function for generating a test report for the verification result, so that the test end verifies the execution result of the bridge to be tested based on the first function to obtain the verification result of the bridge to be tested, and generates and outputs the test report for the verification result of the bridge to be tested based on the second function.

In the embodiment, the execution result is automatically checked and the output test report is automatically generated, so that the problems that errors are easy to occur and the efficiency is low when the test report is compiled by manually checking and recording the execution result in the related technology are solved, and the efficiency and the accuracy are improved.

In an exemplary embodiment, the interface of the bridge test function may be an interface of the unit test function.

In practical applications, in addition to testing the bridge, unit testing may also be performed on the client. Unit testing is the checking and verification of the smallest unit under test in software. In the logic of the unit test function, besides the unit test for the client, the execution result is automatically verified, and a test report is automatically generated and output for the verification result. Common tools with unit test functionality include XCTest, etc. However, the conventional unit test of the client in the related art can only cover the client code, and cannot cover the complete interactive process of H5 through bridging and the native program. In this embodiment, the execution result of the bridge to be tested is sent to the interface of the unit test function of the test end, and the first function and the second function in the existing unit test functions are utilized to perform automatic verification of the execution result and automatic generation and output of the test report, so that, on the basis of the original unit test function, the test function of the complete interaction process of the bridge and the native program for H5 is added, that is, the unit test for the client and the test for the complete interaction process of the bridge and the native program for H5 are combined, and the unit test function is enriched. In addition, the scheme can be more simply realized.

In an exemplary embodiment, a specific implementation manner of the interface step of sending the execution result of the bridge to be tested to the bridge test function of the test end may include: and sending the execution result of the bridge to be tested to an interface of a bridge test function of the test end through the client. In this embodiment, during the bridge test, the execution result of the bridge to be tested can also be sent to the interface of the unit test function through the client, so that the implementation is simpler.

In implementation, for convenience of testing, a custom bridge may be packaged for the client, and the custom bridge is used to send an execution result of the bridge to be tested to an interface of a unit test function of the testing end. After testing is complete, the custom bridge may be removed. Based on this, the step of sending the execution result of the bridge to be tested to the interface of the unit test function of the test end through the client specifically may be to transmit the execution result of the bridge to be tested into a calling method of the custom bridge to call the custom bridge, and forward the execution result of the bridge to be tested to the interface of the unit test function of the test end. The execution result of the bridge to be tested can be forwarded to the interface of the unit test function of the test end by adopting a block value transfer characteristic in object-c (a development language). The method for transmitting the value by using the block is simple, and the value transmission can be realized by other methods, which are not listed one by one.

Illustratively, the code that invokes custom bridging is as follows:

__ yoda bridge __. invoke ("test", "sendtest result", json. stringfy (bridge references), "2").

In addition, the execution result of the bridge to be tested can also be sent to the testing end in other ways. And the test end verifies the execution result of the bridge to be tested to obtain a verification result of the bridge to be tested, and generates and outputs a test report according to the verification result of the bridge to be tested. Therefore, the test end can preset logic for verifying the execution result of the bridge to be tested and generating and outputting a test report according to the verification result of the bridge to be tested.

The following describes a bridge test method provided by the embodiments of the present disclosure by taking the execution of a test end as an example.

Fig. 4 is a flowchart illustrating a bridge test method, as shown in fig. 4, for use in a test terminal, according to an exemplary embodiment, including the following steps.

In step S41, a page request is constructed based on an input target parameter and sent to the H5 terminal, where the target parameter is a parameter of a bridge to be tested, the bridge to be tested is used for a native program set in the client to communicate with the H5 terminal, so that the H5 terminal parses the target parameter from the page request, generates a call method of the bridge to be tested based on the target parameter, calls the bridge to be tested by executing the call method of the bridge to be tested, so as to obtain an execution result that the client processes and returns the bridge to be tested, and outputs the execution result of the bridge to be tested.

In step S42, an execution result of the bridge to be tested is received.

For a specific implementation of this embodiment, reference may be made to a related embodiment of a bridge test method at an H5 end, which is not described herein again.

In an exemplary embodiment, a specific implementation manner of the step of constructing the page request based on the input target parameter may include: transmitting the target parameters into a page request template to obtain an initial page request; and encoding the initial page request to obtain the page request which can be decoded at the H5 end. The page request is constructed in a mode of a page request template, so that the page request is quicker and more accurate.

The page request template is written in advance according to the page request specification. The page request template may be a URL request template. In practical application, the URL request template may be written in advance according to the URL request specification. The URL requests parameters in the template that require bridging of incoming calls.

Illustratively, the URL request template is as follows: https:// www.test.comcut _ bridge ═ encoderURIComponent (@ { @ "namespace": @ "system", - @ "name": @ getAppInfo ", - @" bridged beam ": @ }).

For example, after encoding, a URL request may be obtained as follows: https:// middle-test-center.corp.kuaisou.com/resource/yoda _ js _ bridge _ test/project/scx _ yoda _ bridge.htmlct _ bridge%.

It is understood that the above is only an exemplary way to construct the page request, and other ways may be adopted, for example, the page request may also be constructed by processing the target parameters according to the page request specification.

In an exemplary embodiment, the step of receiving the execution result of the bridge to be tested may specifically include: receiving an execution result of a bridge to be tested sent by an H5 terminal through an interface of a bridge test function of a test terminal, wherein the bridge test function comprises a first function for verifying the execution result and a second function for generating a test report for the verification result; and based on the second function, generating and outputting a test report for the verification result of the bridge to be tested.

In an exemplary embodiment, the interface of the bridge test function may be an interface of the unit test function. As described above, on the testing side, on the basis of the original unit testing function, the testing function of the complete interaction process of the H5 through the bridge and the native program is added, that is, the unit testing of the client and the testing of the complete interaction process of the H5 through the bridge and the native program are combined, so that not only are the unit testing functions enriched, but also the scheme implementation is simpler.

In an exemplary embodiment, a specific implementation manner of the step of receiving, through an interface of a bridge test function of a test end, an execution result of a bridge to be tested sent by an H5 end may include: and receiving an execution result of the bridge to be tested, which is sent by the H5 through the client, through an interface of a bridge test function of the test end. In this embodiment, during the bridge test, the execution result of the bridge to be tested can also be sent to the interface of the unit test function through the client, so that the implementation is simpler.

In an exemplary embodiment, the method for testing bridging of the test end may further include: and acquiring the input target parameters through the entrance of the unit test function. Therefore, on the basis of the unit test function, the target parameter is input by directly utilizing the entry of the input parameter, and the implementation complexity of the scheme is further reduced.

In addition, the execution result of the bridge to be tested sent by the end H5 may also be received directly. Based on the test result, the test end verifies the execution result of the bridge to be tested to obtain the verification result of the bridge to be tested, and generates and outputs a test report for the verification result of the bridge to be tested. Therefore, the test end can preset logic for verifying the execution result of the bridge to be tested and generating and outputting a test report according to the verification result of the bridge to be tested.

In an exemplary embodiment, a specific implementation manner of the step of verifying the execution result of the bridge to be tested may include: comparing whether the execution result of the bridge to be tested is the same as the input reference information; and taking the comparison result as a verification result of the bridge to be tested. If the comparison results are the same, the function of the bridge to be tested is in accordance with the expectation, the test is determined to pass, and if the comparison results are not the same, the function of the bridge to be tested is not in accordance with the expectation, the test is determined not to pass. In practical applications, the reference information may be input in advance. Therefore, the execution result is automatically checked without manual checking, and the testing efficiency is greatly improved.

The bridge test is to test the original bridge again after the new bridge is added. In practical application, when the bridge to be tested is a newly added bridge, the tested at least one target bridge except the bridge to be tested can be tested back. In the related art, the loopback bridge needs manual verification, the content is repeated, and the time cost is high. If the number of original bridges is large, the test needs to be conducted one by one, even if the test is conducted, the test pages need to be clicked one by one manually, results are verified manually, contents are repeated, and time cost is high. For this reason, in an exemplary embodiment, the bridge to be tested is a newly added bridge, and the bridge test method may further include: and responding to the determination that the testing of the bridge to be tested is finished, carrying out the retest of at least one tested target bridge except the bridge to be tested, and recording the retest result.

Wherein, at least one target bridge can be a default tested bridge or a tested bridge selected to be input. Because the tested target bridge has corresponding target parameters and reference information, the test of the bridge to be tested can be finished, the retest of at least one tested target bridge except the bridge to be tested is carried out, and the retest result is recorded. Thus, it can be determined whether the new bridge affects the existing bridge. In the embodiment, after the test of the bridge to be tested is completed, the tested at least one target bridge can be automatically retested, and the retesting result is recorded, so that the pages do not need to be manually clicked one by one, and the result is recorded, thereby avoiding the problems of time and labor consumption and easy error recording in the retesting in the related technology, and further improving the test efficiency and accuracy.

In an exemplary embodiment, the target parameters include: the method comprises the following steps of setting a name space of a bridge to be tested, a name of the bridge to be tested and all parameters required to be carried when the bridge to be tested is called.

The bridge test method provided by the embodiment of the disclosure is described in more detail below by taking a specific application scenario as an example.

In the bridge testing method provided by this embodiment, a test engineer only needs to perform two steps for testing a new bridge, where the first step is to input information of the bridge to be tested, and the second step is to input reference information for verification. The existing bridging can be tested through the existing bridging information and reference information in the unit test without manual participation.

In this embodiment, the testing end of the testing engineer is provided with a unit testing tool XCtest, and based on the XCtest, the unit testing can be performed on the client and the testing can be performed on the bridge to be tested.

As shown in fig. 5, the flow of this embodiment is as follows:

the test engineer enters target parameters, such as namespace, bridgeame, bridgeparam, at the entry of XCtest. In step S51, the test terminal 501 acquires the input target parameters.

In step S52, the test terminal 501 constructs a page request based on the target parameters and sends it to the H5 terminal 503.

Because the interaction between the H5 end through the bridge and the native program depends on a set of specifications, for example, any bridge call requires some parameters, such as namespace, name, bridge; in order to realize the dynamic generation of the calling method of the H5-end bridge, the method is realized by specifying URL request parameter specifications. Illustratively, the parameter bridge info is used to fill in the bridge to be tested. namespace: filling out the name space of the bridge to be tested. The name fills in the name of the bridge to be tested. The bridge fills in all the parameters that the call bridge needs to carry.

Based on the method, a URL request template is constructed in advance, then target parameters are transmitted into the URL request template to obtain an initial page request, and the initial page request is coded to obtain a final page request.

In step S53, the H5 peer 503 receives the page request sent by the test peer, and parses the target parameters from the page request.

Specifically, the H5 parses all parameters included in the URL page request from the URL page request by window.

In step S54, the H5 end 503 transmits the target parameter into the calling method template of the bridge, and generates a calling method to be tested.

In step S55, the H5 terminal 503 executes a call method of the bridge to be tested to call the bridge to be tested.

In step S56, the client 502 processes the bridge to be tested and sends the execution result to the H5 end 503.

In step S57, the H5 end 503 transmits the execution result of the bridge to be tested to the client 502 through the custom bridge.

In this step, the custom bridge provides the entry parameter, such as bridge parameter, for transparently transmitting the execution result of the bridge to be tested to the client.

In step S58, the client 502 forwards the execution result of the bridge to be tested to the interface of XCtest of the testing end.

In step S59, the test terminal 501 verifies the execution result of the bridge to be tested through XCtest, so as to obtain a verification result.

In step S510, the test terminal 501 generates and outputs a test report for the verification result through XCtest.

For example, the bridge to be tested called by H5 is bridge getDeviceInfo for obtaining client device information, and the test end can compare the execution result of the bridge to be tested with the preset client device information through XCtest, so as to ensure that the function of the bridge to be tested conforms to the expectation. The result of the execution of the bridge to be tested may be stored in a first parameter, which is exemplarily indicated by the symbol oriRet. The client actual device information may be stored in a second parameter, illustratively denoted by the symbol realDeviceInfo. And comparing whether the values of the two parameters are the same, if so, passing the bridge test to be tested, otherwise, failing to pass the test. And finally, generating a test report for the checking result. Exemplary codes are as follows: iconationry @ { @ "systemName": @ ios @, @ "sys: [ ksmwdeviceinfesystemversion ] };

XCTAssertTrue([oriRet[@"systemName"]isEqualToString:realDeviceInfo[@"systemName"]])；

XCTAssertTrue([oriRet[@"sys"]isEqualToString:realDeviceInfo[@"sys"]])。

as shown in fig. 6, the flow of this step is as follows:

in step S61, an execution result of the bridge to be tested and reference information are obtained. The reference information is the client actual device information.

In step S62, it is compared whether the execution result of the bridge to be tested is the same as the reference information. If the two are the same, step S63 is executed, and if the two are not the same, step S64 is executed.

In step S63, it is determined that the bridge test to be tested passes, step S65 is performed.

In step S64, it is determined that the bridge test to be tested fails, step S65 is performed.

In step S65, a test report is generated and output.

Thus, in the scheme of this embodiment, the method for automatically calling the bridge to be tested relies on the parameters in the URL request to perform dynamic construction, the name, the space, and the bridge to be tested are transmitted into the URL request by designing the URL parameter specification, and the H5 terminal forms the calling method for the bridge to be tested after parsing. And the H5 end receives the execution result of the bridge to be tested and then transmits the execution result to the client, and the client needs to combine XCtest after obtaining the execution result of the bridge to be tested to realize the capability of outputting the test report. XCtest checks the execution result of the bridge to be tested and outputs a single test report.

Through the scheme of this embodiment, bring following beneficial effect:

first, the new bridge H5 end page is tested without modification by the developer.

Second, the end page of the test new bridge H5 does not need to be redeployed.

And thirdly, unit testing can cover the whole interaction process of bridging and native programs.

And fourthly, outputting a test report through XCtest, namely recording a test result, wherein the bridged test result is accurately output.

And fifthly, the bridge connection back measurement efficiency is improved. Fig. 7 illustrates a portion of a test report, and as can be seen from the right side frame portion of the figure, the test time for a single bridge decreased to 0.21-3s, and the efficiency improvement was very significant.

In addition, when the bridge test fails, prompt information of the test failure can be displayed through XCtest, and the prompt information can include the position of the test failure. In the test interface illustrated in FIG. 8, the middle box section illustrates the location of the test failure.

FIG. 9 is a block diagram illustrating a bridge test apparatus according to an exemplary embodiment. Referring to fig. 9, the apparatus 900 is applied to the H5 side, and includes a receiving unit 901, a parsing unit 902, a generating unit 903, a calling unit 904, and an output unit 905.

A receiving unit 901, configured to execute receiving a page request sent by a testing end, where the page request is constructed by the testing end based on an input target parameter, the target parameter is a parameter of a bridge to be tested, and the bridge to be tested is used for a native program set in a client to communicate with an H5 end;

a parsing unit 902 configured to perform parsing out a target parameter from the page request;

a generating unit 903 configured to generate a calling method of the bridge to be tested based on the target parameter;

the invoking unit 904 is configured to execute invoking the bridge to be tested by executing the invoking method of the bridge to be tested, so as to obtain an execution result that the client processes the bridge to be tested and returns;

an output unit 905 configured to perform outputting an execution result of the bridge to be tested.

In a possible implementation, the generating unit 903 is specifically configured to perform:

constructing a target parameter into a parameter object;

In a possible implementation, the output unit 905 is specifically configured to perform:

With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

FIG. 10 is a block diagram illustrating a bridge test apparatus according to an exemplary embodiment. Referring to fig. 10, the apparatus 1000 is applied to the H5 terminal, and includes a construction unit 1001 and a receiving unit 1002.

The constructing unit 1001 is configured to execute a page constructing request based on an input target parameter and send the page constructing request to an H5 terminal, wherein the target parameter is a parameter of a bridge to be tested, the bridge to be tested is used for a native program set in a client to communicate with an H5 terminal, so that the H5 terminal analyzes the target parameter from the page request, a calling method of the bridge to be tested is generated based on the target parameter, the bridge to be tested is called by executing the calling method of the bridge to be tested, an execution result obtained by the client processing the bridge to be tested and returning is obtained, and an execution result of the bridge to be tested is output;

a receiving unit 1002 configured to perform receiving an execution result of a bridge to be tested.

In a possible implementation, the construction unit 1001 is specifically configured to perform:

In a possible implementation, the receiving unit 1002 is specifically configured to perform:

In a possible embodiment, as shown in fig. 11, the apparatus further comprises:

and a retest unit 1003 configured to perform a retest on at least one tested target bridge other than the bridge to be tested in response to determining that the testing of the bridge to be tested is completed, and record a retest result.

FIG. 12 is a block diagram illustrating an apparatus 1200 for bridge testing in accordance with an exemplary embodiment. For example, the apparatus 1200 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, an exercise device, a personal digital assistant, and the like.

Referring to fig. 12, the apparatus 1200 may include one or more of the following components: a processing component 1202, a memory 1204, a power component 1206, a multimedia component 1208, an audio component 1210, an input/output (I/O) interface 1212, a sensor component 1214, and a communications component 1216.

The processing component 1202 generally controls overall operation of the apparatus 1200, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 1202 may include one or more processors 1220 to execute instructions to perform all or some of the steps of the test-side bridge test method described above. Further, the processing component 1202 can include one or more modules that facilitate interaction between the processing component 1202 and other components. For example, the processing component 1202 can include a multimedia module to facilitate interaction between the multimedia component 1208 and the processing component 1202.

The memory 1204 is configured to store various types of data to support operation at the apparatus 1200. Examples of such data include instructions for any application or method operating on the device 1200, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 1204 may be implemented by any type or combination of volatile or non-volatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

A power supply component 1206 provides power to the various components of the device 1200. Power components 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for device 1200.

The multimedia components 1208 include a screen that provides an output interface between the device 1200 and a user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 1208 includes a front facing camera and/or a rear facing camera. The front camera and/or the rear camera may receive external multimedia data when the apparatus 1200 is in an operation mode, such as a photographing mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

Audio component 1210 is configured to output and/or input audio signals. For example, audio component 1210 includes a Microphone (MIC) configured to receive external audio signals when apparatus 1200 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may further be stored in the memory 1204 or transmitted via the communication component 1216. In some embodiments, audio assembly 1210 further includes a speaker for outputting audio signals.

The I/O interface 1212 provides an interface between the processing component 1202 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button.

The sensor assembly 1214 includes one or more sensors for providing various aspects of state assessment for the apparatus 1200. For example, the sensor assembly 1214 may detect an open/closed state of the apparatus 1200, the relative positioning of the components, such as a display and keypad of the apparatus 1200, the sensor assembly 1214 may also detect a change in the position of the apparatus 1200 or a component of the apparatus 1200, the presence or absence of user contact with the apparatus 1200, orientation or acceleration/deceleration of the apparatus 1200, and a change in the temperature of the apparatus 1200. The sensor assembly 1214 may include a proximity sensor configured to detect the presence of a nearby object in the absence of any physical contact. The sensor assembly 1214 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 1214 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communications component 1216 is configured to facilitate communications between the apparatus 1200 and other devices in a wired or wireless manner. The apparatus 1200 may access a wireless network based on a communication standard, such as WiFi, an operator network (such as 2G, 3G, 4G, or 5G), or a combination thereof. In an exemplary embodiment, the communication component 1216 receives the broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communications component 1216 further includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

In an exemplary embodiment, the apparatus 1200 may be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic components for performing the above-described methods.

FIG. 13 is a block diagram illustrating an apparatus 1300 for bridge testing in accordance with an exemplary embodiment. For example, the apparatus 1300 may be provided as a server. Referring to fig. 13, apparatus 1300 includes a processing component 1322, which further includes one or more processors, and memory resources, represented by memory 1332, for storing instructions, such as application programs, that may be executed by processing component 1322. The application programs stored in memory 1332 may include one or more modules that each correspond to a set of instructions. In addition, the processing component 1322 is configured to execute instructions to perform the bridge test method described above with respect to end H5.

The apparatus 1300 may also include a power component 1326 configured to perform power management for the apparatus 1300, a wired or wireless network interface 1350 configured to connect the apparatus 1300 to a network, and an input-output (I/O) interface 1358. The apparatus 1300 may operate based on an operating system stored in the memory 1332, such as Windows Server, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, or the like.

In an exemplary embodiment, a non-transitory computer readable storage medium, such as a memory, comprising instructions executable by a processing component of apparatus 1200 or apparatus 1300 to perform the bridge test method described above is also provided. For example, the non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

In an exemplary embodiment, a computer program product is also provided, which comprises readable program code executable by a processing component of the apparatus 1200 or the apparatus 1300 to perform the above described bridge test method. Alternatively, the program code may be stored in a storage medium, which may be a non-transitory computer-readable storage medium, such as a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

In an exemplary embodiment, there is also provided a bridge test system, including: a client, a testing end and an H5 end;

With regard to the system in the above-described embodiment, the specific manner in which each end performs operations has been described in detail in the embodiment related to the method, and will not be elaborated upon here.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure 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 present disclosure is limited only by the appended claims.

Claims

1. A bridge test method is applied to an H5 terminal, and comprises the following steps:

receiving a page request sent by a testing terminal, wherein the page request is constructed by the testing terminal based on input target parameters, the target parameters are parameters of bridges to be tested, and the bridges to be tested are used for a native program set in a client to communicate with the H5 terminal;

analyzing the target parameter from the page request;

calling the bridge to be tested by executing the calling method of the bridge to be tested so as to obtain an execution result which is processed by the client and returned by the client;

and outputting the execution result of the bridge to be tested.

2. The bridge test method of claim 1, wherein the step of generating the call method of the bridge to be tested based on the target parameter comprises:

and transmitting the target parameters into a calling method template of the bridge connection to generate the calling method of the bridge connection to be tested.

3. The bridge test method of claim 2, wherein the step of passing the target parameter into a bridge calling method template to generate the bridge to be tested calling method template comprises:

constructing the target parameter into a parameter object;

and transmitting the parameter object into the calling method template of the bridge connection so as to generate the calling method of the bridge connection to be tested.

4. The bridge test method of claim 1, wherein the step of outputting the result of the execution of the bridge under test comprises:

5. The bridge test method of claim 4, wherein the interface of the bridge test function is an interface of a unit test function.

6. The bridge test method according to claim 5, wherein the step of sending the execution result of the bridge to be tested to the bridge test function of the test end comprises:

7. A bridge test method is applied to a test end, and the method comprises the following steps:

constructing a page request based on an input target parameter, and sending the page request to an H5 terminal, wherein the target parameter is a parameter of a bridge to be tested, the bridge to be tested is used for a native program arranged in a client terminal to communicate with the H5 terminal, so that the H5 terminal analyzes the target parameter from the page request, a calling method of the bridge to be tested is generated based on the target parameter, the bridge to be tested is called by executing the calling method of the bridge to be tested, an execution result obtained by processing and returning the bridge to be tested by the client terminal is obtained, and the execution result of the bridge to be tested is output;

and receiving an execution result of the bridge to be tested.

8. A bridge test apparatus, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the bridge test method of any one of claims 1 to 7.

9. A bridge test system, comprising: a client, a testing end and an H5 end;

the client is configured to execute processing of bridges to be tested, and the bridges to be tested are used for communication between a native program arranged in the client and the H5 terminal;

the H5 terminal is configured to execute receiving of a page request sent by the test terminal, parse a target parameter from the page request, where the target parameter is a parameter of the bridge to be tested, generate a calling method of the bridge to be tested based on the target parameter, call the bridge to be tested by executing the calling method of the bridge to be tested, so as to obtain an execution result that the client processes and returns the bridge to be tested, and output the execution result of the bridge to be tested;

the testing terminal is configured to execute a page construction request based on the input target parameters, send the page construction request to the H5 terminal, and receive an execution result of the bridge to be tested.

10. A storage medium having instructions that, when executed by a processor of a bridge test apparatus, enable the bridge test apparatus to perform a bridge test method as claimed in any one of claims 1 to 7.