CN110119350B - Software development kit testing method, device and equipment and computer storage medium - Google Patents

Software development kit testing method, device and equipment and computer storage medium Download PDF

Info

Publication number
CN110119350B
CN110119350B CN201910259517.5A CN201910259517A CN110119350B CN 110119350 B CN110119350 B CN 110119350B CN 201910259517 A CN201910259517 A CN 201910259517A CN 110119350 B CN110119350 B CN 110119350B
Authority
CN
China
Prior art keywords
data packet
test
software development
development kit
sdk
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910259517.5A
Other languages
Chinese (zh)
Other versions
CN110119350A (en
Inventor
谢尧裕
刘杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Tencent Information Technology Co Ltd
Original Assignee
Shenzhen Tencent Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Tencent Information Technology Co Ltd filed Critical Shenzhen Tencent Information Technology Co Ltd
Priority to CN201910259517.5A priority Critical patent/CN110119350B/en
Publication of CN110119350A publication Critical patent/CN110119350A/en
Application granted granted Critical
Publication of CN110119350B publication Critical patent/CN110119350B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The invention discloses a software development kit testing method, device and equipment and a computer storage medium, belongs to the technical field of computers, and is used for improving the accuracy and the testing efficiency of testing results of an SDK (software development kit) test. The method comprises the following steps: monitoring a data package from a software development kit when the software development kit is called in response to a call instruction indicating to call the software development kit; when monitoring that the uplink data packet sent to the test server by the software development kit exists, intercepting the uplink data packet; the software development kit comprises a plurality of functions, each function comprises a plurality of process nodes when running, and the uplink data packet is a data packet sent by one of the functions in the software development kit when the function runs to the process node; and acquiring a test result of the function at the process node based on the uplink data packet.

Description

Software development kit testing method, device and equipment and computer storage medium
Technical Field
The invention relates to the technical field of computers, in particular to a software development kit testing method, a device and equipment and a computer storage medium.
Background
A Software Development Kit (SDK) is a set of Development tools used by a Software engineer to build Application Software for a specific Software package, software framework, hardware platform, or operating system, and is generally a service component provided for a specific service, one Application (APP) may access one or more SDKs, and different SDKs are used to provide different services, for example, an SDK may provide data service, map service, security service, or payment service.
After a software engineer designs an SDK, the SDK needs to be tested, and currently, for the SDK test, the most common method is to set an expected result for the SDK in advance, so that after the SDK is operated, an actual result output by the SDK is compared with the expected result to obtain a test result. However, when the test fails, the testing method cannot know which links the fault occurs in, and needs testers to check the fault one by one, so that the testing efficiency is low.
Disclosure of Invention
The embodiment of the invention provides a software development kit testing method, a software development kit testing device, software development kit testing equipment and a computer storage medium, which are used for improving the accuracy and the testing efficiency of a testing result of an SDK (software development kit) test.
In one aspect, a software development kit testing method is provided, and the method includes:
monitoring a data package from a software development kit when the software development kit is called in response to a calling instruction indicating that the software development kit is called;
when monitoring that the uplink data packet sent to the test server by the software development kit exists, intercepting the uplink data packet; the software development kit comprises a plurality of functions, each function comprises a plurality of process nodes when running, and the uplink data packet is a data packet sent by one of the functions of the software development kit at the process node where the function runs currently;
and acquiring a test result of the function at the process node based on the uplink data packet.
In one aspect, a software development kit testing apparatus is provided, the apparatus comprising:
the monitoring unit is used for monitoring a data package from the software development kit when the software development kit is called in response to a calling instruction for instructing to call the software development kit;
the intercepting unit is used for intercepting the uplink data packet when the uplink data packet sent to the test server by the software development kit is monitored; the software development kit comprises a plurality of functions, each function comprises a plurality of process nodes when running, and the uplink data packet is a data packet sent by one of the functions of the software development kit at the process node where the function runs currently;
and the test result acquisition unit is used for acquiring the test result of the function at the process node based on the uplink data packet.
Optionally, the test result obtaining unit is specifically configured to:
comparing the intercepted uplink data packet with an uplink data packet pre-configured for the process node; if the intercepted uplink data packet is consistent with the content of a preconfigured uplink data packet, determining that the function passes the test of the process node, otherwise, determining that the function does not pass the test of the process node.
Optionally, the test result obtaining unit is specifically configured to:
extracting key data of a key field from the uplink data packet, and comparing the key data with key data preconfigured for the process node; and if the key data in the intercepted uplink data packet is consistent with the content of the pre-configured key data, determining that the function passes the test of the process node, otherwise, determining that the function does not pass the test of the process node.
Optionally, the monitoring unit is further configured to: respectively monitoring the total time consumption of all functions included in the software development kit from the starting time of the first process node to the ending time of the last process node;
the test result obtaining unit is further configured to: if the test of one of the functions included in the software development kit at each process node is passed and the total time consumption of the functions is less than or equal to the preset time length, determining that the test of the function is passed, otherwise, determining that the test of the function is not passed.
Optionally, the apparatus further includes a data display unit, configured to:
and storing the test result of the function at the process node into a test file, and constructing a visual interface for displaying the test result of the function at the process node according to the test data in the test file.
Optionally, the data display unit is further configured to:
and when detecting that the version of the software development kit in the test server is higher than the version of the software development kit, displaying prompt information in a visual interface, wherein the prompt information is used for prompting to update the version of the software development kit.
Optionally, the apparatus further comprises a sending unit;
the sending unit is configured to send the uplink data packet to the test server when it is determined that the function passes the test at the process node; and the number of the first and second electrodes,
the monitoring unit is also used for monitoring the data packet from the test server;
the interception unit is further configured to intercept a downlink data packet sent to the software development kit by the test server when the downlink data packet is monitored;
the sending unit is further configured to compare the downlink data packet with a downlink data packet preconfigured for the process node when it is determined that the downlink data packet is a data packet fed back by the test server based on the uplink data packet; and if the intercepted downlink data packet is consistent with the content of a preconfigured downlink data packet, forwarding the downlink data packet to the software development kit.
In one aspect, a computer device is provided, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method of the above aspect when executing the program.
In one aspect, a computer-readable storage medium is provided that stores processor-executable instructions for performing the method of the above aspect.
In the embodiment of the invention, in the process of running the SDK after the test is started, the data packet from the SDK is monitored, when the uplink data packet sent to the server by the SDK is monitored, the uplink data packet is intercepted, and further, the test result of the currently running flow node of the function of sending the uplink data packet is determined based on the intercepted uplink data packet. Therefore, by monitoring the data packet of the SDK, the test result of each process node to which each function of the SDK runs can be known, that is, the SDK test method provided by the embodiment of the invention is accurate to each link of each function, so that whether the test of each link of each function passes or not is known, the accuracy of the test result is higher, and if the test of the SDK fails, the specific link can be directly known, so that the error can be timely corrected, and the test efficiency is relatively higher.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a schematic diagram of a prior art test scheme for SDK testing;
fig. 2 is a schematic view of a scenario provided by an embodiment of the present invention;
FIG. 3 is a schematic diagram of a test framework provided by an embodiment of the present invention;
fig. 4 is a schematic flow chart of an SDK testing method according to an embodiment of the present invention;
FIG. 5 is a diagram illustrating a display interface according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of a display interface for prompting an update according to an embodiment of the present invention;
FIG. 7 is a diagram illustrating a display interface of test results of feature downloads according to an embodiment of the present invention;
fig. 8 is a schematic flow chart of cloud search according to an embodiment of the present invention;
fig. 9 is a schematic view of a display interface of a cloud inspection test result according to an embodiment of the present invention;
FIG. 10 is a diagram illustrating a display interface of a test server according to an embodiment of the present invention;
fig. 11 is a schematic structural diagram of an SDK testing apparatus according to an embodiment of the present invention;
fig. 12 is a schematic structural diagram of a computer device according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be obtained by a person skilled in the art without making any creative effort based on the embodiments in the present invention, belong to the protection scope of the present invention. The embodiments and features of the embodiments of the present invention may be arbitrarily combined with each other without conflict. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.
For convenience of understanding the technical solutions provided by the embodiments of the present invention, some key terms used in the embodiments of the present invention are explained first:
and (3) SDK: the development tool set is a set of development tools used by software engineers to establish application software for a specific software package, a software framework, a hardware platform or an operating system and the like, and is generally a service component provided for a specific service, and the SDK can be applied to different APPs, so that during application development, developers of the APPs only need to concentrate on the functions of the APPs to design, and some services can be realized by using the existing SDK. For example, for the login of the user in the APP, the SDK providing the login service may be accessed, and the SDK may generally be provided by the software platform, for example, the game application in the game platform a, the login service SDK of the game platform a may be selected to be accessed; or, for the payment of the user in the APP, the SDK providing the payment service may be accessed; or, for the game APP, the game manufacturer generally limits and attacks the plug-in behavior of the user for fairness of the game, and then the SDK related to game safety can be accessed in the game APP, while for the SDK related to game safety, the game manufacturer can be designed by itself, and also can save the development period of the game by using the SDKs related to game safety provided by other manufacturers, and only an interface for calling the SDK needs to be added in the game program of the game manufacturer.
Host: in general, SDKs cannot be run independently, and need to be managed by a certain software environment, which is the host. For example, an SDK that is applied to a particular application is hosted by the SDK, e.g., in a gaming application, which may access game login SDKs, game payment SDKs, and game security SDKs, etc., the gaming application is hosted by these SDKs. However, for practical applications distributed on line, the running environment is usually complex, and the SDK test is not aimed at running the application, so the application is generally not used as a host during testing, but it is desirable to perform testing in a cleaner software environment, so a sample (Demo) host for testing the SDK can be generally designed, and the Demo host is generally a simpler application program, for example, for testing the game security SDK, a simple game can be designed to access the game security SDK. In the embodiment of the invention, the host is a set of test framework specially designed for SDK test, and the protocol of the SDK can be monitored so as to realize the monitoring of each process node of each function.
The test server: taking the game security SDK as an example, in practical application, the SDK generally interacts with a game background server, so that when the game security SDK is tested, a test server is needed to provide an environment required for the SDK to run, and in essence, the test server has the same function as the game background server.
In addition, the term "and/or" herein is only one kind of association relationship describing an associated object, and means that there may be three kinds of relationships, for example, a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" in this document generally indicates that the preceding and following related objects are in an "or" relationship unless otherwise specified.
After a software engineer designs an SDK, the SDK needs to be tested, and currently, for the SDK test, the most common method is to set an expected result for the SDK in advance, so that after the SDK is operated, an actual result output by the SDK is compared with the expected result to obtain a test result. As shown in fig. 1, the test scheme for testing the SDK in the prior art mainly includes three steps, that is, after the test data is input in step 1, the SDK is run through step 2, and then it is determined whether the test is passed through the data output by the SDK in step 3, that is, for this test scheme, only two results are finally obtained, that is, the test is passed or not passed, and whether the test is performed according to the expected execution flow in the SDK running process cannot be known, so the accuracy of the test result is substantially low. After the test scheme inputs data, the test result is judged according to the output data, the test result is unknown in the test process, the test method is completely a black box type test method, when the test fails, the links where faults occur cannot be known, testers need to check the links one by one, and the test efficiency is low.
In the method, in the process of running the SDK after the test is started, a data packet from the SDK is monitored, when an uplink data packet sent to a server by the SDK is monitored, the uplink data packet is intercepted, and further, a test result of a flow node currently running by a function of sending the uplink data packet is determined based on the intercepted uplink data packet. Therefore, by monitoring the data packet of the SDK, the test result of each process node to which each function of the SDK runs can be known, that is, the SDK test method of the embodiment of the present invention is a substantially white box type test method, and the method can be accurate to each link of each function, so as to know whether the test of each link of each function passes or not, and the accuracy of the test result is higher.
In addition, in the embodiment of the invention, besides the test of each link of each function can be monitored, the test result of each link of each function can be displayed in a visual mode, so that a tester can intuitively sense the test process of the SDK test, when the test has problems, the links with the problems can be quickly positioned, and the problem solving efficiency is improved.
After the design idea of the embodiment of the present invention is introduced, some simple descriptions are provided below for application scenarios to which the technical solution of the embodiment of the present invention can be applied, and it should be noted that the application scenarios described below are only used for illustrating the embodiment of the present invention and are not limited. In the specific implementation process, the technical scheme provided by the embodiment of the invention can be flexibly applied according to actual needs.
Please refer to fig. 2, which is a schematic diagram of a scenario applicable to the embodiment of the present invention, where the scenario includes a test server 101 and a plurality of terminals 102, that is, terminals 102-1 to 102-M shown in fig. 2, where M is a positive integer, and a value of M may be set according to a test requirement, for example, if the compatibility of an SDK needs to be tested, the test may be performed through M types of terminals with different models that are common in the market; or, if a small-range test of the SDK is required, fewer terminals 102 may be selected for testing based on the test requirement, for example, M is 10 or 20, and the SDK testing method according to the embodiment of the present invention may be implemented by the terminal 102 in fig. 2.
The test server 101 may include one or more processors 1011, memory 1012, and I/O interface 1013 to interact with the terminals, among other things. The test server 101 may further be configured with a display panel 1014 and a database 1014, where the database 1014 is used to store test related data of each terminal 102, for example, the test data may be device information, data required for testing, and test results of each terminal 102, and the display panel 1014 displays the test related data based on the control of the processor 1011.
The terminal 102 may include one or more processors 1021, memory 1022, an I/O interface 1023 to interact with the test server, a display panel 1024, and the like. The memory 1022 may store program instructions required for testing, such as program instructions of the SDK, program instructions of a host of the SDK, and program instructions of a monitoring module that monitors a testing process of the SDK, where the program instructions are executed by the processor 1021 to implement respective corresponding functions, and the display panel 1024 may display test-related data under the control of the processor 1021, such as functions required to be tested by the SDK, flow nodes required to be tested by each function, and test results of each flow node.
In this embodiment of the present invention, the terminal 102 may send the uplink data packet to the test server 101 through the I/O interface 1023, and accordingly, the test server 101 may receive the uplink data packet from the terminal 102 through the I/O interface 1013 and feed back a corresponding downlink data packet to the terminal 102 based on the uplink data packet, and the terminal 102 may receive the downlink data packet from the test server 101 through the I/O interface 1023, so as to implement data transmission between the terminal 102 and the test server.
Specifically, the terminal 102 is installed with a testing client, where the testing client includes an SDK to be tested and a host of the SDK, and after the test is started, the host can call the SDK in a running process, so that the SDK can be run. The terminal 102 may further include a monitoring module, configured to monitor flow nodes of each function of the SDK during the SDK testing process. For example, when the SDK is a secure SDK, when the SDK is called, the feature file version number needs to be checked, and then the SDK sends an uplink data packet to the test server 101 to inquire about the version number of the feature file of the test server 101, because the execution logic of the SDK is preset, the content that each process node needs to execute and the sent data packet are both fixed, so the monitoring module can intercept the uplink data packet and compare the uplink data packet with the preset uplink data packet, if the result is consistent, it indicates that the SDK passes the test of the process node that checks the feature file version number, otherwise, the result is not passed. Similarly, after the test server 101 carries the version number in the downlink data packet and sends the version number to the terminal 102, the terminal 102 compares the version number of the feature file with the version number sent by the test server 101, and if the version of the feature file of the test server 101 is updated, the terminal can also continue to send the uplink data packet to the test server 101 to request the test server 101 to send the latest feature file, the monitoring module can also intercept the uplink data packet and compare the uplink data packet with the preset uplink data packet, if the version number is consistent, the SDK passes the test at the flow node requesting to update the version number of the feature file, otherwise, the SDK does not pass the test at the flow node requesting to update the version number of the feature file.
Specifically, the terminal 102 may be a device such as a tablet Computer (PAD), a mobile phone, a notebook Computer, or a Personal Computer (PC), and certainly, may also be other possible devices, which is not limited in this embodiment of the present invention.
The test server 101 and the terminal 102 may be communicatively coupled via one or more networks 103. The network 103 may be a wired network or a WIreless network, for example, the WIreless network may be a mobile cellular network, or may be a WIreless-Fidelity (WIFI) network, or may also be other possible networks, which is not limited in this embodiment of the present invention.
Fig. 3 is a schematic view of a test framework according to an embodiment of the present invention, where the test framework may be a framework of a test client installed in the terminal 102 shown in fig. 2. The testing framework shown in fig. 3 is illustrated by taking an Android operating system as an example, but it should be noted that the descriptions of fig. 3 and fig. 3 are intended to describe the idea of the testing framework, and are not limited to be applied only to the Android operating system, and when the testing framework is applied to other operating systems, a person skilled in the art can design the testing framework according to the specific environment of the operating system.
The testing framework can comprise a Native terminal and a Java terminal, wherein the Native terminal is mainly used for realizing bottom functions, such as functions of host operation, scanning engine scheduling and core verification required in the SDK execution process and the like, and intercepting an uplink data packet sent by the SDK to the testing server, and the Java terminal is mainly used for obtaining basic information of equipment, comparing data and drawing to realize functions of User Interface (UI) display and the like.
The Native terminal can comprise a monitoring module, a test scheduling module and an SDK, wherein the test scheduling module is mainly used for realizing functions of a bottom layer, overall scheduling required by testing and interaction with an upper layer, and the monitoring module is mainly used for monitoring data packets transmitted between the monitoring module and a test server in the operation process of the SDK and extracting key data to store the key data in the test data storage module. Of course, in addition to the above-described modules, the Native terminal may also include other modules required for operation, and the embodiment of the present invention is not limited thereto.
The SDK in fig. 3 is an example of a security SDK, and illustrates some functions of the security SDK, that is, functions of feature downloading, cloud check testing, channel quality, a shell base, resource scanning, and performance monitoring, where the feature downloading function is used to download a feature file from a test server, the cloud check testing is used to implement a cloud check and kill function, the channel quality is used to monitor the quality of a transmission channel between a terminal and the test server, the shell base is used to monitor a specified basic function, and the performance monitoring may monitor a performance index of the terminal, such as memory usage and CPU utilization.
The Java terminal may include a data comparison module, a test data storage module, and a drawing module, where the data comparison module is configured to compare the key data stored in the test data storage module with pre-configured key data, so as to determine whether the process node of the SDK operates in a correct manner, to obtain a test result of the process node, and store the test result in the test data storage module, and the drawing module may draw according to the test data read from the test data storage module, so as to perform corresponding display on a display panel.
In the embodiment of the present invention, communication between the Native terminal and the Java terminal may be implemented through a Java Native Interface (JNI).
As shown in fig. 4, a flowchart of an SDK testing method according to an embodiment of the present invention is schematically shown, and the method may be executed by the terminal 102 in fig. 2, and the following describes a method flow according to an embodiment of the present invention with reference to the testing framework shown in fig. 3.
Step 401: the monitoring module monitors the data packets of the SDK.
In practical application, the SDK cannot be executed alone, but a certain software environment, that is, a host, needs to be provided for the SDK, so that when the SDK is tested in the embodiment of the present invention, the host is also run to call the SDK, so as to run the SDK. The Demo host, that is, the test client, in the embodiment of the present invention is a set of test framework specially designed for the SDK, and the test framework processes to create a certain software environment for the operation of the SDK and simultaneously can monitor the test process of the SDK, for example, the test framework shown in fig. 3. For example, for the game security SDK, the testing framework of the embodiment of the present invention includes a game logic code, that is, a necessary game environment is provided for the game security SDK, and meanwhile, when the game security SDK runs, the testing framework can monitor each process node of each function of the game security SDK, so as to achieve the purpose of obtaining the testing result of each process node.
In the embodiment of the invention, in order to ensure that the test of the SDK is more visual and convenient, the client can also provide a visual interface, and a tester can visually check the test information such as the tested function, the test process, the test result and the like through the visual interface. As shown in fig. 5, the display interface of the client is a schematic diagram, the display interface of fig. 5 is an initial display interface before the test is not started, where the display interface may include a test progress display area, a test start button, a test item, and test status of each item, and the test item is a function to be tested in the SDK, and some functions to be tested are illustrated in fig. 5 by taking the SDK to be tested as a secure SDK.
In addition, the display interface may also display basic information of the device of the terminal where the client is located, for example, the processor of the terminal shown in fig. 5 is arm64, and may also display a viewing entry of the settings and related information of the test client, that is, a "settings & about" entry shown in fig. 5, through which a viewing page of configuration information, version information, and the like of the test client may be entered.
Specifically, when the tester operates the start test button in the display interface, the Demo host may receive a test start instruction to start the test.
In practical applications, after the host of the SDK runs, the SDK is not necessarily directly run, and generally needs a certain condition to trigger, for example, for the SDK providing the login service, the SDK providing the login service may be called when the host detects that the user does not log in, so as to implement login of the user; alternatively, for the security SDK, the server may instruct the host to invoke the security SDK for security checking when the host has suspicious data. For the test, the purpose is mainly to test whether the SDK can operate correctly, so that a call instruction for calling the SDK may be directly added to the Demo host program, and when the Demo host operates to the call instruction, the SDK is called in response to the call instruction, so that the SDK may operate. For example, for the game security SDK, the user can continuously perform game operation at the front end, the game process can also respond to the game operation of the user, and the game security SDK can continuously perform monitoring at the background so as to ensure the game security of the user and monitor whether the user normally plays the game, namely whether a third-party plug-in program is used.
In the embodiment of the invention, when the Demo host calls the SDK, namely when the Demo host is detected to execute the calling instruction, the monitoring module is triggered to start monitoring the SDK. Specifically, the data packet of the SDK may be monitored by a monitoring module in the Demo host.
In the embodiment of the invention, after the SDK is operated, the SDK can also verify the version of the SDK, namely, the SDK requests to acquire the version information of the test server, and if the version of the SDK is lower, the SDK can also request the server to issue the latest version. Meanwhile, the monitoring module can monitor the interaction between the SDK and the test server, so that the fact that the version of the SDK in the test server is higher than the version of the SDK in the test client is detected, and prompt information can be displayed in a visual interface and used for prompting updating of the version of the software development kit. As shown in fig. 6, which is an interface schematic diagram for prompting a version update, a popup may be displayed on a visual interface after a test client is opened and an SDK version update is detected to prompt whether the SDK needs to be updated, and yes and no selectable items are displayed, where of course, a style of the display interface shown in fig. 6 is merely an example, and in an actual application process, other possible display styles are also included, which is not limited in this embodiment of the present invention.
Step 402: and the monitoring module intercepts and captures the uplink data packet when monitoring the uplink data packet sent to the test server by the SDK.
In the embodiment of the present invention, the SDK may include multiple functions, each function includes multiple flow nodes during running, when the flow node is finished, the SDK generally sends an uplink data packet to the test server to notify the test server of a result of the flow node, and if the SDK runs in a correct manner, that is, runs according to an execution logic of a test case configured for the SDK in advance, an uplink data packet sent by the SDK each time is predictable, for example, the uplink data packet sent by the flow node a is configured in advance to carry data B, if the SDK runs correctly, the uplink data packet sent by the flow node a necessarily carries data B, so that it is possible to determine whether the function of the SDK runs correctly in the flow node by comparing the uplink data packet sent in an actual test process of the SDK with the uplink data packet configured in advance, thereby determining whether the test passes or not.
For example, the Demo host calls the SDK, and typically calls an initialization function of the SDK, for example, the call instruction may be "tssdk. Taking the security SDK as an example, when the security SDK is initialized, the security SDK checks the feature file, and the feature file is used to drive execution of each function of the SDK, so when the feature file does not exist, the security SDK sends an uplink data packet to the test server to request the test server to issue the feature file, and meanwhile, the monitoring module in the Demo host can monitor the uplink data packet sent by the security SDK and intercept the uplink data packet.
Specifically, the monitoring module may intercept an uplink data packet sent by the SDK to the test server by using a HOOK (HOOK) technique. The HOOK technology can be implemented in three ways, namely inline HOOK, export HOOK and import HOOK. Optionally, in the embodiment of the present invention, an import table hook mode may be selected, that is, import functions send and recv of hook libtersafe.
After the HOOK arrives at the packet, because the packet received and transmitted in the terminal is not completely a packet of the SDK, the packet needs to be filtered, and an Internet Protocol (IP) address connected to a Client/server (C/S) channel formed between the terminal and the test Client is usually fixed, so that the filtering manner may be performed according to the IP address.
Optionally, since data is received and sent by the network very frequently, it is obviously more performance-consuming to filter by obtaining the ip address each time, so that the ip and socket mapping tables can be established in advance, and the filtering efficiency is improved.
Step 403: and the data comparison module acquires the test result of the flow node with the corresponding function based on the uplink data packet.
In the embodiment of the invention, after intercepting the uplink data packet, the Demo host can obtain the test result of the flow node with the corresponding function according to the uplink data packet. Specifically, in order to enable the test server to know which function the uplink data packet is sent, the uplink data packet generally carries a function Identifier (ID), so that the Demo host can distinguish a source of the uplink data packet by the function ID carried in the uplink data packet, and based on the process node to which the function has been executed, the process node to which the function is currently running can also be determined, so as to compare the intercepted uplink data packet with the uplink data packet preconfigured by the process node, thereby obtaining a test result of the function at the process node.
Following the above example of requesting the test server to issue the feature file, after the Demo host intercepts the uplink data packet sent by the SDK, the uplink data packet may be compared with the uplink data packet configured for the process node requesting the test server to issue the feature file, if the contents of the two uplink data packets are consistent, it may be determined that the test at the process node passes, otherwise, if the contents of the two uplink data packets are inconsistent, it may be determined that the test at the process node does not pass. The monitoring module can store the intercepted uplink data packet into the test data storage module, and the data comparison module included by the Demo host can read the uplink data packet from the test data storage module and compare the uplink data packet with the preconfigured uplink data packet to obtain a test result.
Specifically, because the uplink data packet includes more contents and some information is substantially useless for determining the test result, in order to reduce the comparison amount of data, the monitoring module only stores the key data into the test data storage module after acquiring the uplink data packet and extracting the key data from the uplink data packet, so that the data comparison module can only compare the extracted key data when performing data comparison, thereby reducing the comparison data amount, improving the processing speed, and avoiding occupying excessive resources of the terminal.
In the embodiment of the present invention, the key data may be predefined fields that are required, and when the uplink data packet is obtained, only the data of the fields need to be extracted from the uplink data packet. After extracting the key data, the key data may be stored according to a certain data structure, for example, the key data may be stored in an Extensible Markup Language (xml) format, and the key data may be stored in an xml file in the form of key-value key value pairs. Meanwhile, after the key data are stored, when a problem occurs in the test, the problem can be checked based on the stored key data and the like.
In the embodiment of the present invention, after the data comparison module obtains the test result, the test result may also be stored in the test data storage module, for example, in the xml file, and the drawing module may read the relevant test data from the test data storage module and draw the test data, so as to display the test process and the test result through the visual interface. As shown in fig. 7, which is a schematic diagram of a display interface of a test result, fig. 7 specifically illustrates, by way of example, a feature downloading function of the secure SDK, and information such as the test failure and the total test time consumption shown in fig. 7 can be viewed through the display interface shown in fig. 7. And it can be seen that the tests of other functions except the feature download function all show that the test is passed, but only the test of the feature download function does not pass, and after the "feature download" display area is operated, a sub-page of the feature download test result can be entered, so that it can be seen that specifically which feature file has a problem in download, as shown in fig. 7, in the SDK test, the feature file downloaded by the feature download function includes five, i.e., "comm.dat", "tss _ base.dat", "tss _ tcj.dat", "tcjcfg.dat" and "test _ sig _ appver", and "comm.dat" download is unsuccessful, and the rest four downloads are all tested, and after entering the "comm.dat" sub-page, it can be seen that the specific reason why the download test of the feature has not passed is a test, and as shown in fig. 7, the reason why the download test has not passed is a Redundancy Check test is a Redundancy Check (Cyclic Redundancy Check, crc), so that a test interface is very mismatched, so that a test person can visually Check the test result and visually and see that the test efficiency also can be visually improved when a problem occurs.
Step 404: and when the flow node of the function corresponding to the uplink data packet passes the test, the test scheduling module in the Demo host sends the uplink data packet to the test server.
In the embodiment of the invention, when the data comparison module determines that the test of the flow node of the function corresponding to the intercepted uplink data packet passes, the test scheduling module can send the uplink data packet to the test server so as to facilitate the SDK to continue executing. If the test of the flow node of the function corresponding to the uplink data packet fails, the test of the function is terminated, an error code is returned, and a tester can visually check that the problem occurs in the flow node, so that the problem is solved in time, and the development and test efficiency of the SDK is improved.
Step 405: the monitoring module monitors data packets from the test server.
In the embodiment of the invention, in order to ensure the normal operation of the test, the monitoring module can also monitor the data packet from the test server, so that the downlink data packet sent to the SDK by the test server can be ensured to be correct, and the inaccuracy of the test result caused by the inconsistency between the downlink data packet sent by the test server and the pre-configured downlink data packet is avoided. The monitoring of the test server by the monitoring module may be triggered together with the monitoring of the SDK data packet, or may be triggered by sending the first uplink data packet to the test server.
Step 406: and the test server sends a downlink data packet to the SDK.
In the embodiment of the invention, after receiving the uplink data packet, the test server can respond to the request of the uplink data packet to generate the downlink data packet and send the downlink data packet to the SDK.
Following the above example of requesting the test server to send the feature file, after the test server receives the uplink data packet, the feature file may be carried in the downlink data packet and sent to the SDK.
It should be noted that, in the embodiment of the present invention, the number of the step is not limited to the order of the step, for example, the step 406 and the step 407 do not have a substantial order, and may be executed simultaneously or sequentially.
Step 407: and the monitoring module intercepts and captures the downlink data packet when monitoring the downlink data packet sent to the SDK by the test server.
Step 408: and the data comparison module compares the intercepted downlink data packet with a preconfigured downlink data packet.
The way of comparing the downlink data packet by the data comparison module may be the same as the way of comparing the uplink data packet, so that the part may refer to the description of the part of comparing the uplink data packet, and redundant description is not repeated again.
Step 409: and when the intercepted downlink data packet is determined to be consistent with the content of the preconfigured downlink data packet, forwarding the downlink data packet to a software development kit.
In the embodiment of the invention, if the intercepted downlink data packet is determined to be consistent with the content of the preconfigured downlink data packet, the downlink data packet responded by the test server to the uplink data packet is correct, so that the downlink data packet needs to be forwarded to the SDK, so that the SDK process can be continuously executed. Of course, if the contents of the intercepted downlink data packet and the preconfigured downlink data packet are determined to be inconsistent, it indicates that the test server has a fault, and the test cannot be continued, so the test can be terminated, and an error code is returned.
In the embodiment of the present invention, the above description is given by taking the primary data packet interaction between the SDK and the test server as an example, but in practical applications, the number of data packet interactions between the SDK and the test server is large, the process of each interaction can be verified according to the above process, so as to ensure that the operation process of the SDK is executed according to a correct manner, and once the data packet verification is inconsistent, it is indicated that the SDK fails to operate correctly at the process node, thereby facilitating the troubleshooting of the SDK problem.
In the embodiment of the present invention, the execution of each function in the SDK is generally time-limited, and if the consumed time is too long, it indicates that the performance of the SDK may not meet the standard, for example, the cloud check function in the SDK needs to be scanned at regular time, and if the consumed time is too long, a situation that the next cloud check cannot be executed on time may occur, and excessive resources of the terminal may be occupied, so that a user is stuck when using a host of the SDK, and therefore, the total consumed time of each function of the SDK is also an index of a test, while monitoring the interaction of a data packet, the monitoring module also monitors the total consumed time of each function, and the total consumed time of each function refers to the consumed time between the start time of the function from a first process node and the end time of a last process node.
For a function, if the test result of the function at each process node passes and the total time consumption is less than or equal to the preset time length, determining that the test of the function passes, and if the test result of the function at each process node passes but the total time consumption is greater than the preset time length, determining that the test of the function does not pass.
In the embodiment of the invention, sufficient test cases are required to be prepared in advance aiming at different functions and different use scenes of the SDK to be tested, when the SDK meets the preset conditions, the corresponding functions are triggered, and further, in the operation process of the SDK, the state of the SDK and data generated in the execution process are obtained through monitoring of a data packet, so that whether the execution result of the SDK meets the expectation is judged, if the execution result meets the expectation, the test is passed, otherwise, the test is not passed.
Next, the test method is described by taking one of the flows of the cloud inspection test, that is, the refined cloud inspection task test as an example.
Before cloud check testing, a test case with the number Yun Chace required by a test needs to be established in advance, and for the specification of the test case, each flow node of the cloud check function needs to be known, so that a judgment strategy is established for each flow node. The following description is made in conjunction with steps included in the fine cloud inspection task, please refer to fig. 8.
Step 701: and the SDK of the test client sends an initialization uplink data packet to the test server.
Before starting the test, firstly, a feature file for a refined cloud search task test needs to be made, and the content needing to be reported for the refined cloud search and refined control options are indicated in the feature file. The feature file is extracted in advance, for example, for the game security SDK, the feature file includes the feature of the previously detected plug-in. The refined cloud search is a cloud search strategy specified by a specific user, and only users meeting specific conditions can issue feature files to the refined cloud search. For example, a gen _ tcj _ cfg.py script may be used to generate a feature file tcjcfg.dat, and the issuing condition is that only a user located in a set user ID list will issue the feature file to the feature file, so that after the feature file is made, the feature file tcjcfg.dat and the configured user ID list may be uploaded to the test server to complete the configuration of the test server.
After the SDK is operated, an initialization uplink data packet is sent to the test server to request the test server to send the feature file. Meanwhile, the Demo host intercepts and captures the initialization uplink data packet, extracts key data in the initialization uplink data packet, and compares the key data with the key data configured in advance to determine whether the flow node of the uplink data packet of the initialization session is correctly operated when the SDK sends the initialization session. And when the Demo host determines that the test of the flow node for sending the initialization session uplink data packet passes, sending the initialization session uplink data packet to a test server so as to continue the test.
Step 702: the test server sends the profile to the SDK.
In the embodiment of the present invention, the test server may issue the feature file to the SDK at multiple trigger occasions, for example, when the test service receives an initialization uplink data packet, the test service may issue the feature file to the test SDK, and the initialization uplink data packet may be, for example, a TERSAFE _ CS _ PKG _ INIT packet or a TERSAFE _ CS _ CSCHANNEL _ RE _ INIT packet.
Specifically, when the feature file is issued, a trigger condition is set for the issued feature file, that is, when the trigger time is satisfied, whether the trigger condition is satisfied is also verified. For example, the triggering condition may be that a user of the user is indicated in a user list configured for the feature file to be delivered, for example, when the user identifier is an openID, the openID of the user is required to be in a preconfigured openID list; or, the triggering condition may be that the number of online users is not greater than the preconfigured number of users, or the user online rate is not greater than the preconfigured user online rate, and when the triggering condition is applied to the range test of the SDK, the testing is generally performed from the clients of a small part of users, and then the testing range is gradually expanded, so that the number of online users is limited for each test.
The downlink data packet carrying the feature file issued by the test server is also intercepted by the Demo host, the key data in the downlink data packet is extracted and compared with the key data configured in advance to determine whether the response of the test server is expected or not, for example, whether the name of the issued feature file is tcjcfg. The key data extracted by the Demo host and the verification result are stored so as to trace the source when the test has problems. In addition, in addition to the verification of the data packet, since the first step executed by the SDK is initialization, the Demo host may also verify whether the first step of the SDK operation is sending an initialization uplink data packet, and if not, the test fails, that is, in addition to checking the content of the SDK packet, the sequence of the SDK packet sending may also be checked.
In the embodiment of the invention, each function of the safety SDK is generally performed by scanning, wherein the scanning refers to scanning process information, module information, a storage space occupied by a process and the like of the process of a host of the SDK at regular time according to a set scanning strategy, and analyzing data obtained by scanning based on a judgment strategy indicated by characteristics so as to determine whether the data is abnormal. The scanning strategy may be different for different features, and may be specifically configured in each feature, for example, the scanning interval of different features may be different, or the scanning area may be different, and the like. Some data in the storage space occupied by the process hosted by the SDK generally changes dynamically, so the scanning process may be a process of acquiring data dynamically. For the data obtained by scanning, comparing the data obtained by the current scanning with the data obtained by the last scanning based on the indication of the characteristics to determine whether the data is changed; alternatively, the data obtained from this scan may be compared with preconfigured data based on the indication of the feature to determine whether the data is abnormal, for example, for a game where the maximum injury value for skill D is 100 and the injury value obtained from the scan is 1000, the data is obviously abnormal, where the feature in this example plays a role substantially equivalent to comparing the obtained data with the preset data.
Specifically, after the feature file issued by the test server is obtained, scanning may be performed based on the feature file, and after each scanning, the execution result is fed back to the test server, and similarly, when the SDK feeds back the result, an uplink data packet may be sent to the test server, so that the Demo host may also intercept the uplink data packet, and since the test cases are all pre-designed and the execution result is known, the Demo host may verify the content of the uplink data packet to determine whether the SDK correctly executes the scanning action.
Step 703: and the SDK sends an inquiry uplink data packet to the test server.
In the embodiment of the invention, the SDK also sends an inquiry uplink data packet to the test server in a polling mode in a timing mode, and the inquiry uplink data packet is used for inquiring whether the test server has a new cloud check task. In the query upstream data packet, the ID of the cloud check event may be carried, so that the test server knows that the cloud check function queries whether a new cloud check task exists, for example, the query upstream data packet carries a field "TCJ _ ENUM _ BUSINESS _ ID _ CLIENT _ START _ REPORT".
Step 704: and the test server sends a cloud searching task to the SDK.
When the test server receives the inquiry uplink data packet of the SDK and a new cloud check task exists in the test server, the test server will issue the new cloud check task to the SDK, for example, the test server may request the SDK to cloud check whether an a file exists, and carry a Message Digest (MD 5) code of the a file, for example, a downlink data packet issued by the test server to the SDK carries a "TCJ _ ENUM _ BUSINESS _ ID _ CLIENT _ CONTROL" field.
Certainly, the Demo host intercepts the cloud check task, and forwards the cloud check task to the SDK when verification is completed and the cloud check task is determined to be the cloud check task specified according to the test process.
Step 705: and the SDK carries out cloud check based on the issued cloud check task.
And when the SDK receives the cloud searching task issued by the test server, cloud searching is carried out in a scanning mode. Similarly, taking cloud search of the file a as an example, the SDK scans and determines whether the file a of the designated MD5 exists in the terminal, if so, the SDK uploads the file a to the test server, otherwise, the SDK returns a cloud search result indicating that the file a does not exist to the test server.
Step 706: and the SDK sends a file uploading uplink data packet to the test server.
Similarly, for example, when the SDK searches for the a file in the cloud, the SDK needs to send a file UPLOAD uplink packet to the test server to send information such as MD5 and size of the uploaded a file to the test server, for example, the file UPLOAD uplink packet carries "TCJ _ UPLOAD _ bus _ ID _ DATA _ INFO".
Certainly, the Demo host also intercepts the file upload uplink data packet to verify the content of the file upload uplink data packet, for example, the MD5 of the cloud-checked file sent by the SDK must be consistent with the MD5 specified by the test server, and when the verification is completed, the file upload uplink data packet is forwarded to the test server if the file upload uplink data packet is determined to be correct.
Step 707: the test server sends file slice information to the SDK.
In the embodiment of the present invention, the test server may send file SLICE information to the SDK to notify the SDK of an UPLOAD scheme of the a file, that is, how many SLICEs the file is divided into, and how large each SLICE is, for example, a downlink DATA packet sent to the SDK by the test server carries a field "TCJ _ UPLOAD _ BUSINESS _ ID _ REQ _ DATA _ SLICE".
Step 708: and the SDK sends a file uplink data packet to the test server.
The SDK sends one or more file uplink DATA packets to the test server according to the indication of the Slice information of the test server, and when the file uplink DATA packets are multiple, each file uplink DATA packet may include a Slice of a file to be uploaded, so as to UPLOAD the file searched by cloud to the test server, for example, the file uplink DATA packet may carry "TCJ _ UPLOAD _ BUSINESS _ ID _ DATA _ Slice".
Meanwhile, the Demo host intercepts the file uplink data packet, verifies the content of the file uplink data packet, and forwards the file uplink data packet to the test server after the verification is confirmed to be correct.
Step 709: and the test server feeds back cloud check completion information to the SDK.
After the test server receives the file slices uploaded by the SDK, the test server splices the files, and after no problem is determined, cloud check completion information is fed back to the SDK to end the current cloud check process, for example, a downlink DATA packet sent to the SDK by the test server carries a field of 'TCJ _ UPLOAD _ BUSINESS _ ID _ NOTIFY _ DATA _ COMPLETE'.
Fig. 9 is a schematic diagram showing a test result of a refined cloud inspection task. Through the display interface shown in fig. 9, the information of the passing of the test of the refined cloud search task, the total test time consumption and the like can be checked, and it can be seen that each process node of the refined cloud search task is required to be firstly downloaded according to the characteristics shown in fig. 9, then the server is requested to issue the cloud search task, and then the server responds to the process nodes and the like, the process nodes are all corresponding to the actual operation of the SDK, and only if the test of each process node is passed, the test of the refined cloud search task is passed. And through the cloud check test result interface shown in fig. 9, it can also be checked that the cloud check file is a file a, the size of the file and MD5, so that the whole test is transparent, and the tester can intuitively perceive the test process and result.
In summary, if the SDK is not executed correctly, the content of the interaction is definitely inconsistent with the pre-configured content, and in each round of interaction between the SDK and the test server, the content of the interaction is monitored to determine whether the SDK is executed as expected, so as to achieve the purpose of testing the SDK. For example, in the above flow, when the SDK interacts with the test server, the interaction must be performed through a C/S channel between the test client and the test server, and the channel connection must be normal, otherwise the test does not pass, the SDK and the test server must send each interaction data according to the protocol flow, otherwise the test does not pass; the cloud search file sent by the SDK to the test server and the file MD5 requested by the test server are required to be consistent, otherwise, the test is not passed; in the testing time, the cloud check task must be completed completely, otherwise, the testing is not passed, so that the testing mode of the embodiment of the invention can monitor each link of the SDK to achieve the effect of white box testing, thereby improving the testing efficiency, and improving the efficiency of problem solving when problems occur, and the testing results are traceable, so that the testing results have higher reliability.
In the embodiment of the invention, the test related data can be stored in the terminal and can also be sent to the test server, so that the test server can compare and display the data from different terminals so as to check the test data more intuitively. Fig. 10 is a schematic diagram of a display interface for displaying test data for a test server.
The test server may analyze the test data from different terminals to determine the overall test passing rate of the SDK, for example, the test passing rate of the SDK with the version "3.3.33.487082" shown in fig. 10 is 72%, and the average performance data of the terminals during the test process. In addition to the above information, as shown in fig. 10, the test server may also display a test data summary of each terminal, where the test data summary may include configuration information of the terminal and a final test result of the terminal, and when a test data summary of one terminal is selected, the detailed test data of the terminal may also be viewed, as shown in fig. 10, the detailed test data may be displayed in a right window, and of course, other possible display manners may also be used, which is not limited to the embodiment of the present invention.
Referring to fig. 11, based on the same inventive concept, an embodiment of the present invention further provides a software development kit testing apparatus 110, which may be, for example, the terminal shown in fig. 2 or the testing client shown in fig. 3, and includes:
a monitoring unit 1101 configured to monitor a data package from a software development kit when the software development kit is called in response to a call instruction instructing to call the software development kit;
an intercepting unit 1102, configured to intercept an uplink data packet sent to a test server by a software development kit when the uplink data packet is monitored; the software development kit comprises a plurality of functions, each function comprises a plurality of process nodes when running, and the uplink data packet is a data packet sent by one of the functions of the software development kit at the currently running process node;
a test result obtaining unit 1103, configured to obtain a test result of the function at the flow node based on the uplink data packet.
Optionally, the test result obtaining unit 1103 is specifically configured to:
comparing the intercepted uplink data packet with an uplink data packet pre-configured for the process node; if the intercepted uplink data packet is consistent with the content of the pre-configured uplink data packet, determining that the test of the function at the flow node passes, otherwise, determining that the test of the function at the flow node does not pass.
Optionally, the test result obtaining unit 1103 is specifically configured to:
extracting key data of a key field from the uplink data packet, and comparing the key data with key data pre-configured for the process node; and if the key data in the intercepted uplink data packet is consistent with the content of the pre-configured key data, determining that the test of the function at the flow node passes, otherwise, determining that the test of the function at the flow node does not pass.
Optionally, the monitoring unit 1101 is further configured to: respectively monitoring the total time consumption of all functions included in the software development kit from the starting time of a first process node to the ending time of a last process node;
the test result obtaining unit 1103 is further configured to: and if the test of one of the functions included in the software development kit at each process node is passed and the total time consumption of the functions is less than or equal to the preset time length, determining that the test of the function is passed, otherwise, determining that the test of the function is not passed.
Optionally, the apparatus further comprises a data display unit 1104 for:
and storing the test result of the function at the process node into a test file, and constructing a visual interface for displaying the test result of the function at the process node according to the test data in the test file.
Optionally, the data display unit 1104 is further configured to:
and when detecting that the version of the software development kit in the test server is higher than the version of the software development kit, displaying prompt information in a visual interface, wherein the prompt information is used for prompting the update of the version of the software development kit.
Optionally, the apparatus further includes a sending unit 1105;
a sending unit 1105, configured to send the uplink data packet to the test server when it is determined that the function passes the test of the flow node; and the number of the first and second electrodes,
a monitoring unit 1101, configured to monitor a data packet from the test server;
the intercepting unit 1102 is further configured to intercept a downlink data packet sent to the software development kit by the test server when the downlink data packet is monitored;
a sending unit 1105, configured to compare the downlink data packet with a downlink data packet preconfigured for the process node when the downlink data packet is determined to be a data packet fed back by the test server based on the uplink data packet; and if the intercepted downlink data packet is consistent with the content of the preconfigured downlink data packet, forwarding the downlink data packet to a software development kit.
The apparatus may be configured to execute the method shown in the embodiment shown in fig. 4, and therefore, for functions and the like that can be realized by each functional module of the apparatus, reference may be made to the description of the embodiment shown in fig. 4, which is not repeated here. Although data display section 1104 and transmission section 1105 are shown together in fig. 11, it should be noted that data display section 1104 and transmission section 1105 are not indispensable functional sections and are shown by broken lines in fig. 11.
Referring to fig. 12, based on the same technical concept, an embodiment of the present invention further provides a computer device 120, which may include a memory 1201 and a processor 1202.
The memory 1201 is used for storing computer programs executed by the processor 1202. The memory 1201 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function, and the like; the storage data area may store data created according to use of the computer device, and the like. The processor 1202 may be a Central Processing Unit (CPU), a digital processing unit, or the like. The embodiment of the present invention does not limit the specific connection medium between the memory 1201 and the processor 1202. In fig. 12, the memory 1201 and the processor 1202 are connected by a bus 1203, the bus 1203 is shown by a thick line in fig. 12, and the connection manner between other components is only schematically illustrated and not limited. The bus 1203 may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 12, but this is not intended to represent only one bus or type of bus.
Memory 1201 may be a volatile memory (volatile memory), such as a random-access memory (RAM); the memory 1201 may also be a non-volatile memory (non-volatile memory) such as, but not limited to, a read-only memory (rom), a flash memory (flash memory), a Hard Disk Drive (HDD) or a solid-state drive (SSD), or any other medium which can be used to carry or store desired program code in the form of instructions or data structures and which can be accessed by a computer. The memory 1201 may be a combination of the above memories.
A processor 1202 for executing the method performed by the apparatus in the embodiment shown in fig. 4 when invoking the computer program stored in the memory 1201.
In some possible embodiments, various aspects of the methods provided by the present invention may also be implemented in the form of a program product including program code for causing a computer device to perform the steps of the methods according to various exemplary embodiments of the present invention described above in this specification when the program product is run on the computer device, for example, the computer device may perform the methods performed by the devices in the embodiment shown in fig. 4.
The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
The program product of the method of embodiments of the present invention may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a computing device. However, the program product of the present invention is not limited in this regard and, in the present document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims (9)

1. A software development kit testing method, the method comprising:
monitoring a data package from a software development kit when the software development kit is called in response to a call instruction indicating to call the software development kit;
when monitoring that an uplink data packet sent to a test server by the software development kit exists, intercepting the uplink data packet; the software development kit comprises a plurality of functions, each function comprises a plurality of process nodes when running, and the uplink data packet is a data packet sent by one of the functions of the software development kit at the process node where the function runs currently;
acquiring a test result of the function at the process node based on the uplink data packet;
if the function passes the test of the process node according to the test result, sending the uplink data packet to the test server;
monitoring data packets from the test server;
when a downlink data packet sent to the software development kit by the test server is monitored, intercepting the downlink data packet;
when the downlink data packet is determined to be a data packet fed back by the test server based on the uplink data packet, comparing the downlink data packet with a downlink data packet preconfigured for the process node;
and if the intercepted downlink data packet is consistent with the content of a preconfigured downlink data packet, forwarding the downlink data packet to the software development kit.
2. The method of claim 1, wherein said obtaining the test result of the function at the flow node based on the upstream data packet comprises:
comparing the intercepted uplink data packet with an uplink data packet preconfigured for the process node;
if the contents of the intercepted uplink data packet are consistent with the contents of the pre-configured uplink data packet, determining that the function passes the test of the process node, otherwise, determining that the function does not pass the test of the process node.
3. The method of claim 1, wherein obtaining the test result of the function at the flow node based on the upstream data packet comprises:
extracting key data of a key field from the uplink data packet, and comparing the key data with key data pre-configured for the process node;
and if the key data in the intercepted uplink data packet is consistent with the content of the pre-configured key data, determining that the test of the function at the process node passes, otherwise, determining that the test of the function at the process node does not pass.
4. The method of claim 1, wherein the method further comprises:
respectively monitoring the total time consumption of all functions included in the software development kit from the starting time of a first process node to the ending time of a last process node;
if the test of one of the functions included in the software development kit at each process node is passed and the total time consumption of the functions is less than or equal to the preset time length, determining that the test of the function is passed, otherwise, determining that the test of the function is not passed.
5. The method of any of claims 1 to 3, wherein after said obtaining a test result of said function at said flow node based on said upstream data packet, said method further comprises:
and storing the test result of the function at the process node into a test file, and constructing a visual interface for displaying the test result of the function at the process node according to the test data in the test file.
6. The method of claim 4, wherein the method further comprises:
and when detecting that the version of the software development kit in the test server is higher than the version of the software development kit, displaying prompt information in a visual interface, wherein the prompt information is used for prompting to update the version of the software development kit.
7. A software development kit testing apparatus, the apparatus comprising:
the monitoring unit is used for monitoring a data package from the software development kit when the software development kit is called in response to a calling instruction for instructing to call the software development kit;
the intercepting unit is used for intercepting the uplink data packet when the uplink data packet sent to the test server by the software development kit is monitored; the software development kit comprises a plurality of functions, each function comprises a plurality of process nodes when running, and the uplink data packet is a data packet sent by one of the functions of the software development kit at the process node where the function runs currently;
a test result obtaining unit, configured to obtain a test result of the function at the process node based on the uplink data packet;
a sending unit, configured to send the uplink data packet to the test server when it is determined that the function passes the test on the process node; and the number of the first and second electrodes,
the monitoring unit is also used for monitoring the data packet from the test server;
the interception unit is further configured to intercept a downlink data packet sent to the software development kit by the test server when the downlink data packet is monitored;
the sending unit is further configured to compare the downlink data packet with a downlink data packet preconfigured for the process node when it is determined that the downlink data packet is a data packet fed back by the test server based on the uplink data packet; and if the intercepted downlink data packet is consistent with the content of a preconfigured downlink data packet, forwarding the downlink data packet to the software development kit.
8. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 1 to 6 when executing the program.
9. A computer-readable storage medium storing processor-executable instructions for performing the method of any one of claims 1-6.
CN201910259517.5A 2019-04-02 2019-04-02 Software development kit testing method, device and equipment and computer storage medium Active CN110119350B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910259517.5A CN110119350B (en) 2019-04-02 2019-04-02 Software development kit testing method, device and equipment and computer storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910259517.5A CN110119350B (en) 2019-04-02 2019-04-02 Software development kit testing method, device and equipment and computer storage medium

Publications (2)

Publication Number Publication Date
CN110119350A CN110119350A (en) 2019-08-13
CN110119350B true CN110119350B (en) 2023-02-03

Family

ID=67520590

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910259517.5A Active CN110119350B (en) 2019-04-02 2019-04-02 Software development kit testing method, device and equipment and computer storage medium

Country Status (1)

Country Link
CN (1) CN110119350B (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110677312B (en) * 2019-08-15 2023-07-25 北京百度网讯科技有限公司 Time delay monitoring method and system for SDK (software development kit) package, computer equipment and readable medium
CN110727716B (en) * 2019-10-24 2022-04-22 北京智游网安科技有限公司 Identification method for integrated SDK in application, intelligent terminal and storage medium
CN111309551B (en) * 2020-02-10 2023-08-08 北京达佳互联信息技术有限公司 Method and device for determining event monitoring SDK integration correctness
CN113282311A (en) * 2020-02-19 2021-08-20 北京小米移动软件有限公司 System upgrading method and device and storage medium
CN113835990B (en) * 2020-06-23 2024-01-30 中科寒武纪科技股份有限公司 Detection method, detection device, computer equipment and storage medium
CN111949421B (en) * 2020-08-12 2023-09-05 北京奇艺世纪科技有限公司 SDK calling method, device, electronic equipment and computer readable storage medium

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6981180B1 (en) * 2000-03-16 2005-12-27 Akamai Technologies, Inc. Method and apparatus for testing request-response service using live connection traffic
CN101001183A (en) * 2007-01-10 2007-07-18 网之易信息技术（北京）有限公司 Test method and system for network application software
CN103825783A (en) * 2014-03-10 2014-05-28 珠海市君天电子科技有限公司 Test method and device
US9531614B1 (en) * 2015-10-30 2016-12-27 AppDynamics, Inc. Network aware distributed business transaction anomaly detection
CN106598831A (en) * 2015-10-16 2017-04-26 北京国双科技有限公司 Method and device for testing SDK (software development kit)
CN107391380A (en) * 2017-03-09 2017-11-24 北京融信易安信息技术有限公司 A kind of method and system of application program of computer network test process monitoring
CN108763074A (en) * 2018-05-21 2018-11-06 陕西学前师范学院 A kind of method and device of SDK tests
CN109254914A (en) * 2018-08-15 2019-01-22 中国平安人寿保险股份有限公司 Software development kit test method, system, computer installation and readable storage medium storing program for executing

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10614221B2 (en) * 2016-11-16 2020-04-07 International Business Machines Corporation Method and apparatus for security testing of application flows that cannot be automated through HTTP replay

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6981180B1 (en) * 2000-03-16 2005-12-27 Akamai Technologies, Inc. Method and apparatus for testing request-response service using live connection traffic
CN101001183A (en) * 2007-01-10 2007-07-18 网之易信息技术（北京）有限公司 Test method and system for network application software
CN103825783A (en) * 2014-03-10 2014-05-28 珠海市君天电子科技有限公司 Test method and device
CN106598831A (en) * 2015-10-16 2017-04-26 北京国双科技有限公司 Method and device for testing SDK (software development kit)
US9531614B1 (en) * 2015-10-30 2016-12-27 AppDynamics, Inc. Network aware distributed business transaction anomaly detection
CN107391380A (en) * 2017-03-09 2017-11-24 北京融信易安信息技术有限公司 A kind of method and system of application program of computer network test process monitoring
CN108763074A (en) * 2018-05-21 2018-11-06 陕西学前师范学院 A kind of method and device of SDK tests
CN109254914A (en) * 2018-08-15 2019-01-22 中国平安人寿保险股份有限公司 Software development kit test method, system, computer installation and readable storage medium storing program for executing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Android SDK测试(二);NotOrdinary;《https://blog.csdn.net/u013059441/article/details/86564241》;20190120;3-4页 *

Also Published As

Publication number Publication date
CN110119350A (en) 2019-08-13

Similar Documents

Publication Publication Date Title
CN110119350B (en) Software development kit testing method, device and equipment and computer storage medium
US10372600B2 (en) Systems and methods for automated web performance testing for cloud apps in use-case scenarios
CN111796858B (en) Method, system and related equipment for detecting access of application programs in Kubernetes cluster
CN106919485B (en) System based on hardware testing tool configured on server
CN110908909B (en) Automatic test method, device, storage medium and equipment
US10698797B2 (en) Mobile application program testing method, server, terminal, and storage medium
WO2019242162A1 (en) Middleware installation method and apparatus, and computer device and storage medium
CN106484611B (en) Fuzzy test method and device based on automatic protocol adaptation
CN108228444B (en) Test method and device
CN109683997B (en) Method for accessing application program interface through sandbox, sandbox and sandbox equipment
CN113312064B (en) Method and device for installing and configuring physical machine and computer readable medium
CN112988485A (en) Simulation test method and device for power Internet of things equipment
CN110928770B (en) Software testing method, device, system, storage medium and electronic equipment
CN110943984B (en) Asset safety protection method and device
CN106776346B (en) Test method and device of CCMTS (China center testing System) equipment
CN109218407B (en) Code management and control method based on log monitoring technology and terminal equipment
CN108427639B (en) Automated testing method, application server and computer readable storage medium
CN111831567B (en) Application test environment configuration method, device, system and medium
CN111782530B (en) Remote debugging method, device, system, electronic equipment and storage medium
CN111159019A (en) Application program testing method, testing control terminal and testing terminal
CN111651232A (en) One-machine multi-control method, device and system and electronic equipment
CN106708727B (en) Distributed virus characteristic sample verification method and system
CN112699034B (en) Virtual login user construction method, device, equipment and storage medium
CN109388420A (en) Application upgrade test method, device, computer equipment and storage medium
CN114726789A (en) Method, device, equipment and medium for traffic management and traffic management policy configuration

Legal Events

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