CN113626321B

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

Info

Publication number: CN113626321B
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: 2024-03-19
Anticipated expiration: 2041-07-29
Also published as: CN113626321A

Abstract

The present disclosure relates to a bridging test method, device, system and storage medium. The method comprises the following steps: receiving a page request sent by a test terminal, wherein the page request is constructed by the test terminal based on input target parameters, the target parameters are parameters of a bridge to be tested, and the bridge to be tested is used for communicating with an H5 terminal through a native program arranged in a client terminal; analyzing target parameters from the page request; generating a call method of the bridge to be tested based on the target parameter; calling the bridge to be tested by executing the calling method of the bridge to be tested so as to obtain an execution result of the client side for processing the bridge to be tested and returning the execution result; and outputting an execution result of the bridge to be tested. Therefore, the degree of automation of the test bridging is improved, and the test 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 bridging test method, apparatus, system, and storage medium.

Background

With the development of internet technology, services provided based on networks are more and more diversified, service scenes are complex, high dynamic performance is required for functions of clients, and H5 has the capability of adding functions without releasing a new version of clients, so that functions developed based on H5 pages are an indispensable part. H5 is an acronym for hypertext markup language (HTML, hyper Text Markup Language) 5, which is a language way to construct and present internet content. However, H5 often requires the ability to use the Native (Native) program of the client to perform some functions, such as obtaining device information, client information, opening a new Native page of the client, etc. To this end, a bridge (bridge) may be encapsulated according to the traffic scenario to enable interaction between H5 and the native program of the client. In the related art, in order to ensure the bridging function, the bridging needs to be tested. However, the bridging test method in the related art is too dependent on manpower, and the test efficiency is low.

Since H5 provides a front page that is presented to the user for browsing, H5 is also referred to as front H5. One bridge test method in the related art relies on H5 to provide an example code for invoking a bridge, and requires manual clicking on a front page, and verifies the function 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, tells the developer of H5 the tested bridge; step S12, a newly added bridging calling method is developed to update the front-end page of the H5 and is redeployed to the server. Then, a test is performed: step S13, manually clicking the test page; step S14, H5 calls the bridging call method to call the bridging of the native program and H5 communication set in the client; step S15, the client returns the bridging execution result to H5; s16, H5 outputs a bridging related log to a test end; and checking a result by a test engineer at the test end, and writing a test report in step S17. However, each new bridge needs to be modified by a developer relying on H5 to modify the front-end page, but the call grammar of the bridge is often relatively fixed, each new bridge needs to coordinate with the developer of H5 to modify only fields such as the name, parameters, return values and the like of the bridge, the modified front-end page needs to be redeployed to the server, and the simple work needs to be matched by multiple persons, so that the defects of time consumption and labor waste exist.

Disclosure of Invention

The disclosure provides a bridging test method, a bridging test device, a bridging test system and a storage medium, which are used for at least solving the problems of low test efficiency due to too much dependence on manpower in a bridging test mode in the related technology. The technical scheme of the present disclosure is as follows:

according to a first aspect of an embodiment 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 test terminal, wherein the page request is constructed by the test terminal based on input target parameters, the target parameters are parameters of a bridge to be tested, and the bridge to be tested is used for communicating with an H5 terminal through a native program arranged in a client terminal;

analyzing target parameters from the page request;

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

calling the bridge to be tested by executing the calling method of the bridge to be tested so as to obtain an execution result of the client side for processing the bridge to be tested and returning the execution result;

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

In one possible implementation manner, the step of generating the call method of the bridge to be tested based on the target parameter includes:

and transmitting the target parameters into a bridging call method template to generate a call method of the to-be-tested bridging.

In one possible implementation, the step of transferring the target parameter into the call method template of the bridge to generate the call method template of the bridge to be tested includes:

constructing target parameters into parameter objects;

and transmitting the parameter object into a bridging call method template to generate a call method of the bridging to be tested.

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

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

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

In one possible implementation manner, 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 the bridge test function of the test end through the client.

In one possible implementation, the target parameters include: the name space of the bridge to be tested, the 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 bridging test method, applied to a test terminal, the method including:

constructing a page request based on input target parameters, sending the page request to an H5 end, wherein the target parameters are parameters of the bridge to be tested, the bridge to be tested is used for communicating with the H5 end through a native program arranged in a client so that the H5 end analyzes the target parameters from the page request, generating a calling method of the bridge to be tested based on the target parameters, calling the bridge to be tested through executing the calling method of the bridge to be tested to obtain an execution result of the client for processing the bridge to be tested and returning, and outputting the execution result of the bridge to be tested;

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

In one possible implementation, the constructing the page request step based on the input target parameter includes:

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

And encoding the initial page request to obtain a page request which can be decoded by the H5 end.

In one possible implementation manner, the step of receiving the execution result of the bridge to be tested includes:

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

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

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

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

In one possible implementation manner, the step of verifying the execution result of the bridge to be tested 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 bridge to be tested completes the test, carrying out the back test on at least one tested target bridge outside the bridge to be tested, and recording the back test result.

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

the receiving unit is configured to execute the receiving of the page request sent by the testing end, the page request is constructed by the testing end based on the input target parameter, the target parameter is the parameter of the bridge to be tested, and the bridge to be tested is used for the communication between the native program arranged in the client and the H5 end;

the analyzing unit is configured to analyze the target parameters from the page request;

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

The calling unit is configured to execute the calling method for executing the bridge to be tested to call the bridge to be tested so as to obtain an execution result of the client side for processing the bridge to be tested and returning the execution result;

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

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

constructing target parameters into parameter objects;

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

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

the construction unit is configured to execute a page request based on input target parameters, send the page request to the H5 end, wherein the target parameters are parameters of the bridge to be tested, the bridge to be tested is used for communicating with the H5 end through a native program arranged in the client end, so that the H5 end analyzes the target parameters from the page request, generates a calling method of the bridge to be tested based on the target parameters, calls the bridge to be tested through executing the calling method of the bridge to be tested, so as to obtain an execution result of the client end for processing the bridge to be tested and returning the execution result, and outputs the execution result of the bridge to be tested;

And the receiving unit is configured to receive the 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 the bridge to be tested, which is sent by the H5 end through the client, through an interface of a bridge test function of the test end, wherein the bridge test function comprises a first function for checking the execution result and a second function for generating a test report for the checking result;

In one possible embodiment, the apparatus further comprises:

and the return unit is configured to perform the return of the tested at least one target bridge outside the bridge to be tested in response to determining that the bridge to be tested is tested, and record the return result.

According to a fifth aspect of embodiments of the present disclosure, there is provided a bridging test device, comprising:

a processor;

a memory for storing processor-executable instructions;

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

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

the system comprises a client, a first server and a second server, wherein the client is configured to execute processing of a bridge to be tested, and the bridge to be tested is used for communication between a native program set in the client and an H5 end;

The H5 terminal is configured to execute and receive a page request sent by the testing terminal, analyze target parameters from the page request, generate a call method of the bridge to be tested based on the target parameters, call the bridge to be tested by executing the call method of the bridge to be tested to obtain an execution result of the client terminal for processing the bridge to be tested and returning, and output the execution result of the bridge to be tested;

the testing end is configured to execute the page request constructed based on the input target parameters, send the page request to the H5 end and receive the 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, which when executed by a processor of a bridge test apparatus, enables the bridge test apparatus to perform the bridge test method as 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 the 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 method comprises the steps that a primary program arranged in a client side is communicated with an H5 end to be tested, a target parameter input by the H5 end through a testing end analyzed in a page request can automatically generate a calling method of the bridge to be tested, developers of the H5 end do not need to frequently rely on to modify front-end pages and deployment, then the calling method of the bridge to be tested is automatically executed to call the bridge to be tested, a test engineer does not need to manually click to trigger the call of the bridge to be tested, and finally, the execution result of the bridge to be tested is output, so that the test of the bridge to be tested is achieved, the automation degree of the bridge to be tested is improved on the whole, and the test 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 disclosure and together with the description, serve to explain the principles of the disclosure and do not constitute an undue limitation on the disclosure.

Fig. 1 is a flow chart illustrating a bridging test method according to an exemplary embodiment.

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

Fig. 3 is a flow chart illustrating a bridging test method according to an exemplary embodiment.

Fig. 4 is a flow chart illustrating a bridge test method according to an exemplary embodiment.

Fig. 5 is a flow chart illustrating a bridging test method according to an exemplary embodiment.

FIG. 6 is a flow chart illustrating a verification method according to an exemplary embodiment.

FIG. 7 is a schematic diagram of a test interface, according to an example embodiment.

FIG. 8 is a schematic diagram illustrating a test interface according to an example embodiment.

Fig. 9 is a block diagram illustrating a bridging test device according to an example embodiment.

Fig. 10 is a block diagram illustrating a bridging test device according to an example embodiment.

Fig. 11 is a block diagram illustrating a bridging test device according to an example embodiment.

Fig. 12 is a block diagram of an apparatus according to an example embodiment.

Fig. 13 is a block diagram of an apparatus according to an example embodiment.

Detailed Description

In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, the technical solutions of 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 foregoing 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 disclosure described herein may be capable of operation in sequences other than those illustrated or described herein. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.

In order to solve the technical problems of the bridging test method in the related art, such as too much depending on manpower and low test efficiency, the embodiments of the present disclosure provide a bridging test method, which is described in detail below.

Fig. 2 is a system architecture diagram illustrating a bridging test method according to an example embodiment. As shown in fig. 2, the bridging 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, where the server is deployed with H5, which is called H5 end 203. Part of the page of the client is realized by a native program, and the other part of the page of the client is realized by an H5 terminal. The client is provided with a bridge for communication between the native program and the H5 terminal. In practical application, when the bridging of the client needs to be tested, a test engineer can perform simple input operation on the test end, and then the bridging 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 end as an example, the bridging test method provided by the embodiment of the disclosure is described.

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

In step S31, a page request sent by the testing terminal is received, where the page request is configured by the testing terminal 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 the client to communicate with the H5 terminal.

The communication interaction between the native program arranged in the client and the H5 end is realized by relying on a set of specifications, for example, any bridging call needs some parameters, and the target parameters are parameters commonly needed by the bridging 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 parameters are parsed from the page request.

In the step, the transfer of the target parameters to the H5 end is realized through page request.

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

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

In practical application, after executing the method for calling the bridge to be tested, 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 acquiring 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 to-be-tested bridge that communicates with the H5 end by the native program set in the client may automatically generate the method for calling the to-be-tested bridge by using the target parameter input by the H5 end through the test end parsed in the page request, without frequently relying on the developer of the H5 end to modify the front end page and deploy, then automatically execute the method for calling the to-be-tested bridge, without requiring the test engineer to manually click to trigger the call of the to-be-tested bridge, and finally output the execution result of the to-be-tested bridge, thereby implementing the test of the to-be-tested bridge.

In an exemplary embodiment, the target parameters may include: the name space of the bridge to be tested, the name of the bridge to be tested and all parameters required to be carried when the bridge to be tested is called.

Wherein the namespaces are used to organize and reuse codes. In practical applications, there may be many bridges corresponding to different types of functions, and the bridges are classified by namespaces, so that different functions are distinguished, for example, the bridges of tools, and the namespaces may be tool.

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

By way of example, the namespace may be represented by the symbol namespace. The name of the bridge to be tested may be represented by the symbol name. All parameters that need to be carried when invoking the bridge to be tested can be represented by the symbol bridgeparam.

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

In practical application, a bridge call method template can be pre-stored, wherein the bridge call method template comprises a public code for calling the bridge, and parameters of the bridge to be called are required to be transmitted in the public code. The common code may also contain locally stored identification information of the bridging of the call. Based on the above, the target parameters are transferred into the bridge call method template, so that the final bridge call method to be tested can be obtained. Therefore, the method for quickly and automatically constructing the bridge to be tested is realized, and the developer at the H5 end is not required to be relied on.

In an exemplary embodiment, the implementation of the steps of the calling method for generating the bridge to be tested by transferring the target parameter into the calling method template of the bridge may include: constructing target parameters into parameter objects; and transmitting the parameter object into a bridging call method template to generate a call method of the bridging to be tested. In this embodiment, a mode of firstly constructing the target parameters into parameter objects and then transmitting the parameter objects into a bridging call method template is adopted, based on which, an object-oriented language, for example, a JS (JavaScript for short) language widely used in web pages can be adopted to write the bridging call method template.

For example, three parameters of namespace, name and bridgeparam may be structured into a call method template for the object bridgeInfo, namespace, name in bridgeInfo and bridgeparam incoming bridge, exemplary code is as follows:

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

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

Therefore, the calling method of the bridge to be tested can be generated by replacing the position of the parameter of the bridge to be called in the calling method template of the bridge with the value of the target parameter.

In addition, the target parameters can also be directly transmitted into the bridging call method template to generate the call method of the bridging to be tested. And (3) adopting an adaptive language to realize a preset bridging calling method.

The above examples illustrate the scheme of generating the call method of the bridge to be tested through the call method template of the bridge, and the call method of the bridge to be tested may also be generated in other manners, for example, the generation rule of the call method of the bridge may be formulated in advance, and the target parameter is processed according to the generation rule to generate the call method of the bridge to be tested.

In an exemplary embodiment, the parsing the target parameter from the page request may include: all parameters contained in the page request are resolved, and the target parameters are segmented from all the resolved parameters.

Illustratively, all parameters included in the constructed page request can be parsed by a window.location.search.subsystem (1) method (a systematic method), and then the target parameters are partitioned from all parameters included in the page request by a preset partitioning method (split), which is illustrative of partitioning three parameters of a name and a bridge page. 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 include: the method comprises the steps of sending an execution result of a bridge to be tested to an interface of a bridge test function of a test end, wherein the bridge test function comprises a first function for checking the execution result and a second function for generating a test report for the check result, so that the test end checks the execution result of the bridge to be tested based on the first function to obtain the check result of the bridge to be tested, and generates and outputs a test report for the check result of the bridge to be tested based on the second function.

In the embodiment, the automatic check and automatic generation of the output test report are carried out on the execution result, so that the problems of easy error and low efficiency in writing the test report and recording the manual check result in the related technology are avoided, 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 bridging, unit testing may also be performed on clients. Unit testing is the checking and verification of the smallest testable unit in software. In the logic of the unit test function, the execution result is automatically checked in addition to the unit test on the client, and a test report is automatically generated and output on the check 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 interaction process of H5 through bridging and native procedures. 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 the method is equivalent to that based on the original unit test function, the test function of the complete interaction process of the H5 through the bridge and the native program is further added, that is, the unit test of the client and the test of the complete interaction process of the H5 through the bridge and the native program are combined, and the unit test function is enriched. In addition, the implementation of the scheme can be simpler.

In an exemplary embodiment, the 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 the bridge test function of the test end through the client. Because the interface of the unit test function is in butt joint with the client so that the execution result of the unit test of the client is sent to the interface of the unit test function to realize the unit test, in the embodiment, the execution result of the bridge to be tested can be sent to the interface of the unit test function through the client during the bridge test, so that the implementation is simpler.

In implementation, for convenience of testing, a custom bridge may be packaged for the client, where the custom bridge is configured to send an execution result of the bridge to be tested to an interface of a unit testing 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 may specifically be to transfer the execution result of the bridge to be tested into the call method of the custom bridge, so as 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 block value transmission characteristic in the objective-c (a development language) can be adopted to forward the execution result of the bridge to be tested to the interface of the unit test function of the test end. The block value transmission method is simple, and the value transmission can be realized in other modes, which are not listed here.

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

__ yodaBridge __. Invoke ("test", "sendtestrequest", json. Stringing "2").

In addition, the execution result of the bridge to be tested can be sent to the testing end in other modes. The test end checks the execution result of the bridge to be tested to obtain the check result of the bridge to be tested, and generates and outputs a test report of the check result of the bridge to be tested. For this purpose, logic for verifying the execution result of the bridge to be tested, generating a test report from the verification result of the bridge to be tested, and outputting the test report may be preset in the test end.

The bridging test method provided by the embodiment of the present disclosure is described below by taking the execution of the test terminal 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 the input target parameter and sent to the H5 end, where the target parameter is a parameter of the bridge to be tested, and the bridge to be tested is used for communicating with the H5 end by a native program set in the client end, so that the H5 end 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 of the client end for processing the bridge to be tested and returning, and outputs an execution result of the bridge to be tested.

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

The specific implementation manner of this embodiment may refer to the related embodiments of the bridge test method of the H5 end, which is not described herein.

In an exemplary embodiment, constructing the page request step implementation based on the input target parameters may include: the target parameters are transmitted into a page request template to obtain an initial page request; and encoding the initial page request to obtain a page request which can be decoded by the H5 end. By constructing the page request template, the page request is constructed more quickly and accurately.

Wherein the page request template is pre-written 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 of the bridge that require incoming calls in the template.

Illustratively, the URL request template is as follows: https:// www.test.comcut _bridge = encoduriccomponent (@ { @ "nano space": @ "system", @ "name" @ "getAppInfo", @ "bridge space": @ { }).

Illustratively, after encoding, the resulting one URL request may be as follows: https =% of 22%3a%22system%22,%22name%22%3a%22getdeviceinfo%22,%22bridge parameters%22% 3a%7b% 7d.

It will be appreciated that the above description is merely exemplary of the manner in which page requests are constructed, and that other manners are possible, such as processing the target parameters according to the page request specification to construct the page request.

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

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 basis of the original unit test function, the test function of the complete interaction process of the H5 through the bridge and the native program is further added at the test end, that is, the unit test of the client and the test of the complete interaction process of the H5 through the bridge and the native program are combined, so that the unit test function is enriched, and the implementation of the scheme is simpler.

In an exemplary embodiment, the step of receiving, by 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 specifically include: and receiving an execution result of the bridge to be tested, which is sent by the H5 end through the client, through an interface of the bridge test function of the test end. Because the interface of the unit test function is in butt joint with the client so that the execution result of the unit test of the client is sent to the interface of the unit test function to realize the unit test, in the embodiment, the execution result of the bridge to be tested can be sent to the interface of the unit test function through the client during the bridge test, so that the implementation is simpler.

In an exemplary embodiment, the bridging test method of the test end may further include: and acquiring the input target parameters through an inlet of the unit test function. Therefore, on the basis of the unit test function, the input parameters are directly utilized to input the target parameters, so that the implementation complexity of the scheme is further reduced.

In addition, the execution result of the bridge to be tested sent by the H5 end may be received directly. Based on the result, the test end checks the execution result of the bridge to be tested to obtain the check result of the bridge to be tested, and the check result of the bridge to be tested generates a test report and outputs the test report. For this purpose, logic for verifying the execution result of the bridge to be tested, generating a test report from the verification result of the bridge to be tested, and outputting the test report may be preset in the test end.

In an exemplary embodiment, the implementation manner of the checking step of 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 accords with the expectation, the test is determined to pass, and if the comparison results are different, the function of the bridge to be tested does not accord with the expectation, and the test is determined not to pass. In practical application, the reference information may be input in advance. Therefore, the execution result is automatically checked without manual check, and the test efficiency is greatly improved.

The test bridging is that after the bridging is newly added, the original bridging needs to be tested again. 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. In the related art, the callback bridge needs to be manually verified, the content is repeated, and the time cost is high. If the number of the original bridges is large, the test needs to be carried out one by one, and even if the test needs to be carried out one by one, the test pages need to be clicked one by one manually, the result is verified manually, the content is repeated, and the time cost is high. To this end, in an exemplary embodiment, the bridge to be tested is a newly added bridge, and the bridge testing method may further include: and responding to the determination that the bridge to be tested completes the test, carrying out the back test on at least one tested target bridge outside the bridge to be tested, and recording the back test result.

The at least one target bridge may be a default tested bridge or a tested bridge of the selection input. Because the tested target bridge has the corresponding target parameters and the reference information, the tested target bridge can be tested after the to-be-tested bridge is determined to be tested, at least one tested target bridge outside the to-be-tested bridge is tested, and the test result is recorded. In this way, it can be determined whether the newly added bridge has an influence on the existing bridge. In this embodiment, after the bridge to be tested is tested, the tested at least one target bridge may be automatically tested and the test result is recorded, without manually clicking the page one by one, and recording the result, so that the problems of time and effort consumption and easy error in the test in the related art are avoided, and the test efficiency and accuracy are further improved.

In an exemplary embodiment, the above-mentioned target parameters include: the name space of the bridge to be tested, the 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 present disclosure is described in more detail below by taking a specific application scenario as an example.

In the bridge test method provided by the embodiment, the test engineer only needs to execute two steps for testing the new bridge, the first step inputs the information of the bridge to be tested, and the second step inputs the reference information for verification. The existing bridging can be tested by the information and the reference information of the existing bridging in the unit test, and manual participation is not needed.

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

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

the test engineer enters target parameters, such as, for example, nalespace, bridgename, bridgeparam, at the XCtest's entry. In step S51, the test terminal 501 acquires the input target parameter.

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

Because the H5 end is realized by the interaction of bridging and a native program depending on a set of specifications, for example, any bridged call needs some parameters, such as a name, a name and a bridge; in order to realize the call method for dynamically generating the H5-end bridge, the call method is realized by specifying the URL request parameter specification. Illustratively, the bridgeInfo parameter is used to fill out the bridge to be tested. Namespace: the namespace of the bridge to be tested is filled in. The name fills in the name of the bridge to be tested. The bridgeparam fills out all parameters that the call bridge needs to carry.

Based on the above, 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 encoded to obtain a final page request.

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

Specifically, the H5 end parses all parameters included in the URL page request from the URL page request through window. Location. Search. Substring (1), and then partitions target parameters, for example, three parameters of name, name and bridgeparam, from all parameters included in the page request through a preset partition method (split), so as to store the target bridgeInfo.

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

In step S55, the H5 end 503 executes a method for calling 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 transparently transmits the execution result of the bridge to be tested to the client 502 through the custom bridge.

In this step, an entry, such as bridgeParam, is provided in the custom bridge to pass through 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 XCtest interface of the test end.

In step S59, the test terminal 501 checks the execution result of the bridge to be tested through XCtest to obtain a check result.

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

For example, the bridge to be tested called by H5 is a bridge getDeviceInfo for obtaining the client device information, and the test end can compare the execution result of the bridge to be tested with the preset client actual device information through XCtest, so as to ensure that the function of the bridge to be tested meets the expectations. The result of the execution of the bridge to be tested may be stored in a first parameter, which is represented by the symbol oriRet, for example. The client actual device information may be stored in a second parameter, which is represented, for example, by the symbol realDeviceInfo. And comparing whether the values of the two parameters are the same, if so, passing the bridging test to be tested, and otherwise, failing the test. And finally, generating a test report for the verification result. Exemplary codes are as follows: the icotionary = @ realDeviceInfo = @ { @ system mname "@ ios" @ sys "@ KSMWDeviceInfosystemVersion ] };

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, the execution result of the bridge to be tested and the reference information are obtained. The reference information is the actual device information of the client.

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 same, step S63 is performed, and if not, step S64 is performed.

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

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

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

In this way, in the solution of this embodiment, the method of the bridge to be tested is automatically called, the parameters in the URL request are relied on to perform dynamic construction, the name, space and bridge of the bridge to be tested are transmitted to the URL request by designing the URL parameter specification, and the H5 end constitutes the call method of the bridge to be tested after parsing. H5 receives the execution result of the bridge to be tested and then transmits the result to the client, and the client needs to combine XCTest after receiving the execution result of the bridge to be tested, so as 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.

By the scheme of the embodiment, the following beneficial effects are brought:

1. the newly added bridge H5 end page is tested without modification of a developer.

2. The newly added bridge H5 end page is tested without redeployment.

3. Unit testing may cover the bridging and native program complete interaction process.

4. And outputting a test report through XCTest, namely recording a test result, and outputting the bridged test result accurately.

5. And the bridging return testing efficiency is improved. Fig. 7 illustrates a portion of a test report, and from the right box portion of the figure, the test time for a single bridge drops to 0.21-3s, and the efficiency improvement is very significant.

In addition, when the bridge test fails, the XCTest can also display the prompt information of the test failure, and the prompt information can contain the position of the test failure. In the test interface illustrated in fig. 8, the middle box portion illustrates the location of test failure.

Fig. 9 is a block diagram illustrating a bridging test device according to an example embodiment. Referring to fig. 9, the apparatus 900 is applied to the H5 end, and includes a receiving unit 901, an parsing unit 902, a generating unit 903, a calling unit 904, and an output unit 905.

The receiving unit 901 is configured to perform receiving a page request sent by the testing end, wherein the page request is constructed by the testing end based on input target parameters, the target parameters are parameters of a bridge to be tested, and the bridge to be tested is used for communicating with the H5 end by a native program set in the client;

A parsing unit 902 configured to perform parsing out the target parameters 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 calling unit 904 is configured to execute a calling method for executing the bridge to be tested to call the bridge to be tested, so as to obtain an execution result that the client processes the bridge to be tested and returns the execution result;

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

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

constructing target parameters into parameter objects;

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

The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.

Fig. 10 is a block diagram illustrating a bridging test device according to an example embodiment. Referring to fig. 10, the apparatus 1000 is applied to the H5 end, and includes a construction unit 1001 and a reception unit 1002.

The construction unit 1001 is configured to execute a page request based on an input target parameter, send the page request to the H5 end, where 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 the client to communicate with the H5 end, so that the H5 end 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 of the client to process the bridge to be tested and return, and outputs an execution result of the bridge to be tested;

The receiving unit 1002 is configured to perform receiving an execution result of the 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 one possible embodiment, as shown in fig. 11, the apparatus further includes:

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

Fig. 12 is a block diagram illustrating an apparatus 1200 for bridging testing, according to an example embodiment. For example, apparatus 1200 may be a mobile phone, computer, digital broadcast terminal, messaging device, game console, tablet device, medical device, exercise device, personal digital assistant, or the like.

Referring to fig. 12, 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 part of the steps of the test-end bridging test method described above. Further, the processing component 1202 may include one or more modules that facilitate interactions between the processing component 1202 and other components. For example, the processing component 1202 may 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 operations at the apparatus 1200. Examples of such data include instructions for any application or method operating on the apparatus 1200, contact data, phonebook data, messages, pictures, videos, and the like. 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 disk.

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

The multimedia component 1208 includes a screen between the device 1200 and the user that provides an output interface. 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 input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may sense not only the boundary of a touch or slide action, but also the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 1208 includes a front camera and/or a rear camera. The front camera and/or the rear camera may receive external multimedia data when the apparatus 1200 is in an operational 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 focal length and optical zoom capabilities.

The audio component 1210 is configured to output and/or input audio signals. For example, the audio component 1210 includes a Microphone (MIC) configured to receive external audio signals when the 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 be further stored in the memory 1204 or transmitted via the communications 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 a keyboard, click wheel, buttons, etc. These buttons may include, but are not limited to: homepage button, volume button, start button, and lock button.

The sensor assembly 1214 includes one or more sensors for providing status assessment of various aspects of the apparatus 1200. For example, the sensor assembly 1214 may detect the on/off state of the device 1200, the relative positioning of the components, such as the display and keypad of the device 1200, the sensor assembly 1214 may also detect a change in position of the device 1200 or a component of the device 1200, the presence or absence of user contact with the device 1200, the orientation or acceleration/deceleration of the device 1200, and a change in temperature of the device 1200. The sensor assembly 1214 may include a proximity sensor configured to detect the presence of nearby objects without 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 gyroscopic sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communications component 1216 is configured to facilitate communication between the apparatus 1200 and other devices, either wired or wireless. The apparatus 1200 may access a wireless network based on a communication standard, such as WiFi, an operator network (e.g., 2G, 3G, 4G, or 5G), or a combination thereof. In one exemplary embodiment, the communication component 1216 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one 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, microcontrollers, microprocessors, or other electronic elements for executing the methods described above.

Fig. 13 is a block diagram illustrating an apparatus 1300 for bridging testing, according to an example embodiment. For example, apparatus 1300 may be provided as a server. Referring to fig. 13, apparatus 1300 includes a processing component 1322 that further includes one or more processors and memory resources represented by memory 1332 for storing instructions, such as application programs, executable by processing component 1322. The applications stored in memory 1332 may include one or more modules each corresponding to a set of instructions. In addition, the processing component 1322 is configured to execute instructions to perform the H5-side bridging test method described above.

The apparatus 1300 may also include a power component 1326 configured to perform power management of 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 is also provided, such as a memory, comprising instructions executable by the processing component of apparatus 1200 or apparatus 1300 to perform the bridge test method described above. For example, the non-transitory computer readable storage medium may be ROM, random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

In an exemplary embodiment, a computer program product is also provided, comprising readable program code executable by the processing component of apparatus 1200 or 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 ROM, random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

In an exemplary embodiment, there is also provided a bridging test system comprising: the system comprises a client, a testing end and an H5 end;

The specific manner in which the operations are performed by the various terminals in the system of the above embodiments has been described in detail in relation to the embodiments of the method and will not be described in detail herein.

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 adaptations, 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 is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A bridging test method, applied to an H5 end, comprising:

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 a bridge to be tested, and the bridge to be tested is used for communicating with the H5 end through a native program arranged in a client;

analyzing the target parameters 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 the calling method of the bridge to be tested so as to obtain an execution result which is returned by the client side and used for processing the bridge to be tested;

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

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

And transmitting the target parameters into a bridging call method template to generate the bridging call method to be tested.

3. The bridge testing method according to claim 2, wherein the step of transferring the target parameter into a call method template of a bridge to generate the call method template of the bridge to be tested comprises:

constructing the target parameters into parameter objects;

and transmitting the parameter object into the bridging call method template to generate the bridging call method to be tested.

4. The bridge testing method according to claim 1, wherein the step of outputting the execution result of the bridge to be tested includes:

the method comprises the steps of sending an 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 checking the execution result and a second function for generating a test report for the check result, so that the test end checks the execution result of the bridge to be tested based on the first function to obtain the check result of the bridge to be tested, and generates and outputs a test report for the check result of the bridge to be tested based on the second function.

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 testing method according to claim 5, wherein the step of sending the execution result of the bridge to be tested to the interface of the bridge testing function of the testing terminal 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.

7. The bridge test method according to any one of claims 1 to 6, wherein the target parameters include: the name space of the bridge to be tested, the name of the bridge to be tested and all parameters required to be carried when the bridge to be tested is called.

8. A bridging test method, applied to a test terminal, comprising:

constructing a page request based on input target parameters, and sending the page request to an H5 end, wherein the target parameters are parameters of a bridge to be tested, the bridge to be tested is used for communicating with the H5 end by a native program arranged in a client so that the H5 end analyzes the target parameters from the page request, a calling method of the bridge to be tested is generated based on the target parameters, the bridge to be tested is called by executing the calling method of the bridge to be tested, so that an execution result of the client for processing the bridge to be tested and returning the execution result of the bridge to be tested 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.

9. The bridging test method according to claim 8, wherein the constructing a page request step based on the input target parameters includes:

10. The bridge testing method according to claim 8, wherein the step of receiving the execution result of the bridge to be tested comprises:

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

and based on the first function, checking the execution result of the bridge to be tested to obtain the check result of the bridge to be tested, and based on the second function, generating a test report for the check result of the bridge to be tested and outputting the test report.

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

12. The bridge testing method according to claim 11, wherein the step of receiving the execution result of the bridge to be tested sent by the H5 terminal through the interface of the bridge testing function of the testing terminal includes:

13. The bridge testing method according to claim 10, wherein the step of verifying the execution result of the bridge to be tested includes:

14. The bridge test method of claim 8, wherein the method further comprises:

and responding to the determination that the bridge to be tested is tested, carrying out loop-back testing on at least one tested target bridge outside the bridge to be tested, and recording a loop-back result.

15. The bridge test method according to any one of claims 8 to 14, wherein the target parameters include: the name space of the bridge to be tested, the name of the bridge to be tested and all parameters required to be carried when the bridge to be tested is called.

16. A bridging test device for application to an H5 terminal, the device comprising:

the receiving unit is configured to execute the step of 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 a bridge to be tested, and the bridge to be tested is used for communicating with the H5 end by a native program arranged in a client;

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

the calling unit is configured to execute the calling method for executing the bridge to be tested to call the bridge to be tested so as to obtain an execution result returned by the client for processing the bridge to be tested;

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

17. The bridging test device according to claim 16, wherein the generating unit is specifically configured to perform:

18. The bridging test device according to claim 17, wherein the generating unit is specifically configured to perform:

constructing the target parameters into parameter objects;

19. The bridge test apparatus according to claim 16, wherein the output unit is specifically configured to perform:

20. The bridge test device of claim 19, wherein the interface of the bridge test function is an interface of a unit test function.

21. The bridge test apparatus according to claim 20, wherein the output unit is specifically configured to perform:

22. The bridging test device according to any one of claims 16 to 21, wherein the target parameters include: the name space of the bridge to be tested, the name of the bridge to be tested and all parameters required to be carried when the bridge to be tested is called.

23. A bridging test device for use at a test site, the device comprising:

the construction unit is configured to execute a page request constructed based on input target parameters and send the page request to an H5 end, the target parameters are parameters of a bridge to be tested, the bridge to be tested is used for communication between a native program set in a client and the H5 end, so that the H5 end analyzes the target parameters from the page request, generates a calling method of the bridge to be tested based on the target parameters, calls the bridge to be tested by executing the calling method of the bridge to be tested to obtain an execution result of the client for processing the bridge to be tested and returning the execution result of the bridge to be tested, and outputs the execution result of the bridge to be tested;

24. The bridge test apparatus according to claim 23, wherein the construction unit is specifically configured to perform:

25. The bridging test device according to claim 23, wherein the receiving unit is specifically configured to perform:

26. The bridge test device of claim 25, wherein the interface of the bridge test function is an interface of a unit test function.

27. The bridging test device according to claim 26, wherein the receiving unit is specifically configured to perform:

28. The bridging test device according to claim 25, wherein the receiving unit is specifically configured to perform:

29. The bridge testing apparatus of claim 23, wherein the apparatus further comprises:

and the return testing unit is configured to perform the return testing of the tested at least one target bridge outside the bridge to be tested in response to determining that the bridge to be tested is tested, and record the return testing result.

30. The bridging test device according to any one of claims 23 to 29, wherein the target parameters include: the name space of the bridge to be tested, the name of the bridge to be tested and all parameters required to be carried when the bridge to be tested is called.

31. A bridging test device 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 15.

32. A bridging test system comprising: the system comprises a client, a testing end and an H5 end;

the client is configured to perform processing of a bridge to be tested, and the bridge to be tested is used for communication between a native program set in the client and the H5 end;

the H5 terminal is configured to execute and receive a page request sent by the testing terminal, parse a target parameter from the page request, wherein 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 to obtain an execution result that the client processes the bridge to be tested and returns, and output the execution result of the bridge to be tested;

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

33. A storage medium, which when executed by a processor of a bridging test device, causes the bridging test device to perform the bridging test method of any one of claims 1 to 15.