APP login state construction method and system, electronic equipment and medium
By simulating and generating the login state of a large number of APP accounts, the problem of not being able to log in enough APP accounts in the existing technology is solved, and the pressure testing requirement of the write type interface in the APP is realized.
Patent Information
- Application Number
- CN202510038311.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-09
- Publication Date
- 2025-05-09
Smart Images
Figure CN119961157A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of computer technology, and in particular to an APP login state construction method, an APP login state construction system, an electronic device and a computer-readable storage medium. Background Art
[0002] In daily testing work, various welfare activities of the APP, such as flash sales, need to be stress tested before they are officially launched to verify whether the performance of the relevant interfaces can meet the activity requirements. If they do not meet the requirements, performance tuning must be performed. In general, the interfaces of the stress test need to cover all interfaces involved in the activity, including query interfaces and write interfaces. Query interfaces refer to business interfaces that involve data query and do not modify data. For stress testing of such interfaces, the data of the same logged-in user can be used for querying; write interfaces refer to business interfaces where data modification will occur. For such interfaces, the data of the logged-in user only needs to be requested once. The next time it is requested, the interface will report an error because the data has been modified. Therefore, the data of the same logged-in user cannot be used for requests during stress testing. For example, if Figure 1 As shown in the figure, it is a rights collection page. After the user logs in to the page, he will first request the query interface to check whether he is eligible to collect the rights. If the user is eligible, he can click the collect button to trigger the request to collect the rights interface to collect the rights. After the collection is successful, when the user enters the page again, the query interface will return that the user has collected the rights. At this time, the user will not be able to click the collect button again. In this example, two interfaces are involved: the collection qualification query interface and the rights collection interface. For the collection qualification query interface, if you want to stress test, you can use the login state of the same login user (such as number 18600000001) for stress testing, that is, use the stress testing tool (such as jmeter) to configure the interface with the user's cookie; for the rights collection interface, because the data will be modified, the cookie of the same user cannot be used, and the cookies of different users must be used.
[0003] When using stress testing tools (such as jmeter) to configure the interface, the user's cookie must be carried. This means adding a cookie item to the interface request header, and its content is usually sessionid=xxxxx. The value of sessionid is obtained from the application server. When the user logs in successfully, the application server returns it to the client. In subsequent interface requests, as long as the client carries the sessionid returned by the application server, it is considered to be logged in and can be processed normally by the application server. Otherwise, it is considered not logged in and no business processing will be performed.
[0004] In the flash sale activities carried out by the APP, if you want to perform stress testing on the interface (such as the benefit collection interface in the previous example), you must use different users (that is, different WeChat accounts) to log in first to obtain the login state (that is, the valid sessonid), and then use the stress testing tool to configure the interface in batches to carry these login states for stress testing. At present, this stress testing scenario cannot be implemented in the industry because it is impossible to find enough APP accounts to log in separately (assuming that the concurrency is set to 10,000 during the stress test, 10,000 APP accounts are required). Summary of the invention
[0005] In order to at least solve the problem in the prior art that it is impossible to find enough APP accounts to log in separately. The present disclosure provides an APP login state construction method, an APP login state construction system, an electronic device, and a computer-readable storage medium; the login states of a large number of different APP account users can be simulated, thereby realizing the scenario requirements of write-type interface stress testing in the APP.
[0006] In the first aspect, the present disclosure provides a method for constructing an APP login state.
[0007] include:
[0008] Determine the target application, key method and redirect link that need to generate the login state; the key method is the internal method that processes the step of obtaining the openid from the APP server in the login logic, and the redirect link is the request link initiated to the target application with the code parameter;
[0009] Mount monitoring on key methods to execute monitoring logic before the key methods are called;
[0010] Generate each random code value and its corresponding random openid value, and store them in redis (RemoteDictionary Server, remote dictionary service);
[0011] Initiate an http request for the key method, the request address is the redirect link, and replace the placeholder in the key method with the generated code value before the request;
[0012] Execute the monitoring logic, read the code of the key method, and query the value corresponding to the code of the key method in redis;
[0013] If it can be found, the value corresponding to the read code will replace the openid value in the template string of the APP when the key method is executed, and the replaced template string will be directly returned to the caller as the return content of the key method.
[0014] Furthermore, the method further comprises:
[0015] Determine the number of sessions that need to be generated;
[0016] The number of codes to be generated and the number of random openid values corresponding thereto are determined according to the number of sessions to be generated.
[0017] Furthermore, the method further comprises:
[0018] If the value corresponding to the code of the key method cannot be found in redis, it means that the key method called this time does not need to be mocked, and the key method is executed normally.
[0019] Furthermore, the method further comprises:
[0020] Get the set-cookie header information contained in the response header of the returned content of the request, and extract the value of sessionid in the header information;
[0021] Save the sessionid value, the corresponding openid value, and the mobile phone number into a Map variable, and then save the Map variable into a List variable. The mobile phone number is generated when each random code value is generated.
[0022] At the end of the http request of all key methods, save the content of the List variable to a csv format file and update the execution progress to 100%.
[0023] Furthermore, the method further comprises:
[0024] Save the execution progress data in redis;
[0025] When a query request is initiated to query the current generation progress, the progress data in redis is read and the progress value is returned to the front-end page.
[0026] In a second aspect, the present disclosure provides an APP login state construction system, the system comprising:
[0027] A determination module is configured to determine a target application, a key method, and a redirection link for generating a login state; the key method is an internal method for processing the step of obtaining an openid from an APP server in the login logic, and the redirection link is a request link initiated to the target application and carrying a code parameter;
[0028] The mounting module is configured to mount a listener on a key method so as to execute the listening logic before the key method is called;
[0029] A generation module is configured to generate each random code value and its corresponding random openid value and store them in redis;
[0030] A request module is configured to initiate an http request of a key method, the request address is the redirect link, and the generated code value is used to replace the placeholder in the key method before the request;
[0031] A monitoring module is configured to execute monitoring logic, read the code of the key method, and query the value corresponding to the code of the key method in redis;
[0032] The return module is configured to replace the openid value in the template string of the APP with the value corresponding to the read code when the key method is executed if the listening module can query it, and return the replaced template string directly to the caller as the return content of the key method.
[0033] Furthermore, the generation module is also configured to:
[0034] Determine the number of sessions that need to be generated; and,
[0035] The number of codes to be generated and the number of random openid values corresponding thereto are determined according to the number of sessions to be generated.
[0036] Furthermore, the system also includes a storage module;
[0037] The storage module is configured to obtain the set-cookie header information contained in the response header returned by the request, and extract the value of the sessionid in the header information;
[0038] Save the sessionid value, the corresponding openid value, and the mobile phone number into a Map variable, and then save the Map variable into a List variable. The mobile phone number is generated when each random code value is generated; and,
[0039] At the end of the http request of all key methods, save the content of the List variable to a csv format file and update the execution progress to 100%.
[0040] In a third aspect, the present disclosure provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the APP login state construction method as described in any one of the first aspects.
[0041] In a fourth aspect, the present disclosure provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the APP login state construction method described in any one of the above-mentioned first aspects is implemented.
[0042] Beneficial effects:
[0043] The APP login state construction method, APP login state construction system, electronic device and storage medium provided by the present invention are used to solve the problem of batch construction of login state during internal stress testing. According to actual needs, enough APP accounts can be constructed to log in separately, so that testers can simulate the login states of a large number of users with different APP accounts, thereby meeting the scenario requirements of write-type interface stress testing in APP. BRIEF DESCRIPTION OF THE DRAWINGS
[0044] Figure 1 A schematic diagram of a benefit claiming page provided by the present disclosure;
[0045] Figure 2 A schematic diagram of the overall process of WeChat public account authorization login provided by the present disclosure;
[0046] Figure 3 A flowchart of a method for constructing an APP login state provided in the first embodiment of the present disclosure;
[0047] Figure 4 A schematic diagram of a target application, key method, and redirection link filling page provided in an embodiment of the present disclosure;
[0048] Figure 5 A schematic diagram of a display page after a successful monitoring mount provided by an embodiment of the present disclosure;
[0049] Figure 6 A schematic diagram of a page for filling in the number of sessions to be generated provided in an embodiment of the present disclosure;
[0050] Figure 7 A schematic diagram of a generation progress display page provided in an embodiment of the present disclosure;
[0051] Figure 8 A schematic diagram of a generated display page provided in an embodiment of the present disclosure;
[0052] Fig. 9 A schematic diagram of a generated data sample provided by an embodiment of the present disclosure;
[0053] Fig.10 A schematic diagram of a code for performing monitoring processing logic provided by an embodiment of the present disclosure;
[0054] Fig.11This is an architecture diagram of an APP login state construction system provided in Embodiment 3 of the present disclosure;
[0055] Fig.12 This is an architecture diagram of an electronic device provided in Embodiment 4 of the present disclosure. DETAILED DESCRIPTION
[0056] In order to enable those skilled in the art to better understand the technical solution of the present disclosure, the present disclosure is further described in detail below in conjunction with the drawings and embodiments. It should be understood that the specific embodiments and drawings described herein are only used to explain the present invention, rather than to limit the present invention.
[0057] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence; and, in the absence of conflict, the embodiments in the present disclosure and the features in the embodiments can be arbitrarily combined with each other.
[0058] The terms used in the embodiments of the present disclosure are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure. The singular forms of "a", "said" and "the" used in the embodiments of the present disclosure and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings.
[0059] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present disclosure, and have no specific meanings. Therefore, "module", "component" or "unit" can be used in a mixed manner.
[0060] When using the stress testing tool to configure the interface, the user's cookie must be carried, and its content is usually sessionid=xxxxx; the value of sessionid is obtained from the application server. When the user logs in successfully, the application server returns it to the client. In subsequent interface requests, as long as the client carries the sessionid returned by the application server, it is considered to be logged in and can be processed normally by the application server. Otherwise, it is considered not logged in and no business processing will be performed.
[0061] For example, if you visit an H5 event page in WeChat and the event requires you to log in before you can participate, you will usually use WeChat official account authorization login to complete automatic authentication login. Figure 2As shown in the figure, at the beginning, the user will click on the activity page link provided by the application. The link is usually an interface address (not an HTML link). Clicking the link will request the application server. At this time, since it is the first request to the application server, the request will not carry a valid cookie, so the application server will generate a session and return a valid sessionid to the WeChat client; in subsequent redirect link requests, the sessionid will be carried in the cookie; when the application server generates the session, it will save the relevant information of the session (such as creation time, expiration time) in redis; after multiple redirections, one of the redirection requests (such as the redirected WeChat link 2 in the figure) will initiate a request to the WeChat server (not the application server). The purpose of this request is to obtain an authorization code (code) from the WeChat service. The application service will request the WeChat server (such as the redirected active link 2) according to the code to query the user's openid (the unique identifier of each user (WeChat account) in the WeChat service); after successfully obtaining the openid, the application service will query the corresponding user information from the application database according to the openid (usually the user information saved after the number is bound to the public account), and save the user information to the session information (which is saved in redis), and return the sessionid to the WeChat client. At this time, the WeChat client page will then initiate a query interface request and carry the sessionid in the request. Since the session identified by the sessionid already contains the user information, it will be processed as logged in on the server side, thereby executing the query interface logic normally and returning the content to the WeChat client, and the client page will also be displayed as a logged in page.
[0062] From the above process, we can see that to obtain the user's openid, the prerequisite is to first obtain the authorization code (code) provided to the user by the WeChat service; this authorization code can only be used once and has a short expiration time; different users and the same user at different times will obtain different and unique codes; based on this unique code, the corresponding user's openid can be obtained from the WeChat service, and only by obtaining the openid can the corresponding user information be queried in the application to complete the login.
[0063] The technical solution of the present invention and how the technical solution of the present invention solves the technical problems existing in the prior art are described in detail below with specific embodiments. It is understandable that in the embodiments of the present application, the execution subject can perform some or all of the steps in the embodiments of the present application, and these steps or operations are only examples. The embodiments of the present application can also perform other operations or deformations of various operations. In addition, each step can be performed in a different order presented in the embodiments of the present application, and it is possible not to perform all the operations in the embodiments of the present application. And, the following several specific embodiments can be combined with each other, and may not be repeated in some embodiments for the same or similar concepts or processes.
[0064] Figure 3 A flowchart of a method for constructing an APP login state provided in the first embodiment of the present disclosure is shown in FIG. Figure 3 As shown, the method includes:
[0065] Step S101: Determine the target application, key method and redirection link that need to generate the login state; the key method is the internal method that processes the step of obtaining the openid from the APP server in the login logic, and the redirection link is the request link initiated to the target application and carrying the code parameter;
[0066] Step S102: Mount a monitor on the key method to execute the monitor logic before the key method is called;
[0067] Step S103: Generate each random code value and its corresponding random openid value, and store them in redis;
[0068] Step S104: Initiate an http request for the key method, the request address is the redirect link, and the generated code value is used to replace the placeholder in the key method before the request;
[0069] Step S105: Execute the monitoring logic, read the code of the key method, and query the value corresponding to the code of the key method in redis;
[0070] Step S106: If it can be found, when the key method is executed, the value corresponding to the read code will replace the value of openid in the template string of the APP, and the replaced template string will be directly returned to the caller as the return content of the key method.
[0071] The purpose of the disclosed embodiment is to provide a login state construction method, so that testers can simulate the login states of a large number of different APP account users, thereby realizing the scenario requirements of write-type interface stress testing in APP. The APP can be WeChat, Alipay, etc. The target application can log in through the information of the APP, and the corresponding user information can be queried in the target application by obtaining the openid of the APP.
[0072] Below, we will take WeChat as an example to explain how to simulate the login status of a large number of users with different WeChat accounts. To achieve this goal, first determine the target application, key method, and redirect link that need to generate the login status;
[0073] The test personnel provided in the embodiment of the present disclosure Figure 4 Fill in the target application, key method, and redirect link 2 on the page shown (where code is assigned to the placeholder ${}), and click the Mount button;
[0074] 1. Target application: refers to the name of the application that handles the login logic;
[0075] 2. Key method: refers to the name of the internal method that handles the step of obtaining openid from the WeChat server in the login logic. Since it is necessary to query the WeChat server for openid based on the code, this key method must require a code parameter. The full path name of the key method must be filled in and the code must be the first parameter. For example, com.kcard.api.WxAuthBaseService#getOpenidBycode#1 means that the method getOpenidBycode under the class com.kcard.api.WxAuthBaseService is the key method, and code is the first parameter.
[0076] 3. Redirect link: refers to the request link initiated to the target application with code parameter transmission (see the schematic Figure 2 The redirected active link 2 in the redirection is renamed as Redirect Link 2); wherein, code is assigned a value of a placeholder ${}, which will be replaced by a specific value by service A (the service provided by the present disclosure) later; here is a supplementary explanation: when a request for redirect link 2 is initiated to the target application, if the request does not carry a valid sessionid, the target application will generate a valid session for this session (i.e., this request) when receiving the request, and will put the sessionid into the response header when returning the response content of the request.
[0077] Mount monitoring on key methods to execute monitoring logic before the key methods are called;
[0078] After clicking the mount button, a request will be triggered to service A (the service provided by the present disclosure). After receiving the request, service A monitors the key method. A preferred monitoring logic execution process is as follows:
[0079] 1. Execute the remote command to mount and monitor the target application. The command is . / sandbox.sh-p7-d'service-monitor / authMonit', where 7 is the application process, which is obtained by executing the command ps-ef|grep-i kcard-xxx|awk'{print$2}' (for example, the target application is kcard-xxx); sandbox.sh is the mount monitoring execution script of the jvm-sandbox installed in advance on the server where the application is located; jvm-sandbox is a jvm-based process monitoring tool that can monitor the java process (i.e., application process) in the jvm. Similar tools include trace, arthas, etc. Therefore, if jvm-sandbox is not used, other monitoring tools can also be used to achieve the purpose; service-monitor / authMonit is the name of the monitoring logic implementation package provided in this embodiment.
[0080] 2. Return the successful mounting information to the front-end page.
[0081] exist Figure 4 After clicking the mount button on the page, you will jump to Figure 5 The page shown (provided by the present disclosure) will show the status of the configuration line as "mounted successfully" at this time, and the tester can then click the edit button;
[0082] Edit the number of sessions to be generated by clicking the Edit button, and then start generating them:
[0083] (1) Use the random number tool method to generate a random code value (such as ikoksjiuKliwwa9ssa) and a random openid value (such as Hauckkokil9sVI8sa). You can also generate other corresponding additional information, such as a random 11-digit mobile phone number (assuming that the additional data is a mobile phone number). Concatenate the code value and the prefix mock:data:code: into the key of redis and the openid value as the value of redis, and save them in redis (the code is: set mock:data:code:ikoksjiuKliwwa9ssa Hauckkokil9sVI8sa), and then execute the logic of (2);
[0084] (2) Initiate an http request for the key method, and the request address is the redirect link 2 filled in; before the request, replace the placeholder ${} with the code value generated in the previous step.
[0085] Because this key method is monitored, the monitoring logic will be executed before the key method is executed. The implementation logic of service-monitor / authMonit is as follows:
[0086] (1) Monitor the configured key method (such as com.kcard.api.WxAuthBaseService#getOpenidBycode). When the key method is called, execute the following logic (2) before it is executed;
[0087] (2) Get the value of the parameter at the specified position of the key method (if #1 is configured, get the value of the parameter at the first position, that is, the parameter of code), concatenate the value with the prefix mock:data:code: into a redis key (for example, if the value is ikoksjiuKliwwa9ssa, the concatenated key is mock:data:code:ikoksjiuKliwwa9ssa), and try to get the value corresponding to the key from redis (the command is get mock::data:code:ikoksjiuKliwwa9ssa). If the value can be obtained (that is, the openid generated and stored in redis when the code is generated), it means that the call of this key method needs to be mocked, and then execute the logic of (3).
[0088] (3) Replace the template string {"access_token":"82_HJrJp69vtRj7od3_QWBJcHjpxkcqiDFZEfimW Q-59jwl8QUATL_ix_O0LlJPqxZkVoHamSqkX1F5VoUFYK9Cw8YHyrVEadlgov16Q_Jb1fI","refresh_token":"82_fMnTr_AqgSBsXolIl" with the obtained value V2wl-5GHmGIy7NvB9o5T88DLZ3_algblmS0ZYRH1IaLfE_wqxorT3VwH2XCyKfxoORs_tgOQoKf_Je3zrG7zLESkko","openid":"${}","scope":"snsapi_base","expires_in":7200}, the replaced template string is directly returned to the caller as the return content of the key method (the code of the key method will not be actually executed at this time). Here is an explanation: Under normal circumstances, when the WeChat server is queried for openid with code, the information returned by the WeChat server is like the template string, in addition to openid, it also contains other field information, but the application service generally only needs to use openid, so other field information does not need to be paid attention to (it can remain unchanged).
[0089] Execute the above steps multiple times according to the number of sessions that need to be generated by the editor. Use different codes each time you initiate an HTTP request for a key method to get the corresponding number of returned contents.
[0090] After the generation is complete, the generated data is downloaded locally for subsequent use.
[0091] The disclosed embodiment can construct enough APP accounts to log in separately according to actual needs, so that testers can simulate the login states of a large number of users with different APP accounts, thereby meeting the scenario requirements of write-type interface stress testing in APP.
[0092] Furthermore, the method further comprises:
[0093] Determine the number of sessions that need to be generated;
[0094] The number of codes to be generated and the number of random openid values corresponding thereto are determined according to the number of sessions to be generated.
[0095] After clicking the Edit button, a pop-up Figure 6In the pop-up window shown, the tester fills in the number of sessions to be generated (for example, 10,000) and clicks the Start Generation button;
[0096] After clicking the Start Generation button, a request will be triggered to Service A. After receiving the request, Service A executes the generation logic: it starts to execute the generation logic in a loop according to the number of sessions filled in (such as 10000): Service A will start to generate the specified number of session data (shown as Figure 7 ), and display the progress; after the generation is completed, the button will change to Figure 8 As shown, the tester can click a button to download the generated data to the local computer for subsequent use (data sample is Fig. 9 As shown, each line will contain sessionid, mobile number, openid).
[0097] Furthermore, the method further comprises:
[0098] If the value corresponding to the code of the key method cannot be found in redis, it means that the key method called this time does not need to be mocked, and the key method is executed normally.
[0099] If the value can be obtained, it means that the call of this key method needs to be mocked, and the logic of (3) in the monitoring logic is executed; if the value cannot be obtained, it means that the call of this key method is normal and does not need to be mocked, so no intervention is required (no need to execute the logic of (3)). By querying the value corresponding to the code in redis, it can be determined whether the corresponding openid has been generated, that is, whether to simulate the login state or actually request the target application.
[0100] Furthermore, the method further comprises:
[0101] Get the set-cookie header information contained in the response header of the returned content of the request, and extract the value of sessionid in the header information;
[0102] Save the sessionid value, the corresponding openid value, and the mobile phone number into a Map variable, and then save the Map variable into a List variable. The mobile phone number is generated when each random code value is generated.
[0103] At the end of the http request of all key methods, save the content of the List variable to a csv format file and update the execution progress to 100%.
[0104] The response header returned by the request will contain the set-cookie header information (such as sessionid=ewlis98dd1lstbUi1klass). At this time, extract the value of sessionid in the header information, save the value together with the previous openid value and mobile phone number into a Map variable, and then save the Map variable into a List variable for subsequent processing;
[0105] At the end of the loop, the contents of the List variable are written to a csv file and the execution progress is updated to 100% (set mock:progress 100).
[0106] Furthermore, the method further comprises:
[0107] Save the execution progress data in redis;
[0108] When a query request is initiated to query the current generation progress, the progress data in redis is read and the progress value is returned to the front-end page.
[0109] Save the execution progress data in redis (such as set mock:progress20, indicating that the progress is 20%);
[0110] The above generated http request loop processing is executed asynchronously, that is, during the execution of the loop, service A will first return the request response content to the front-end page to inform the execution status;
[0111] After clicking the Start Generation button, the page will continue to send query requests to service A to query the current generation progress. After receiving the request, service A will read the progress data in redis (set mock:progress) and return the progress value to the front-end page. When the progress is 100%, the button on the front-end changes to "Generation completed, click to download data". At this time, clicking the button will download the csv file to the local computer.
[0112] This public embodiment generates a random code value, a corresponding random openid value and a random mobile phone number through a random tool according to the number of sessions filled in, and monitors the key method. Before initiating the http request of the key method, the generated code value is replaced with the placeholder ${}; thereby, when monitoring, by obtaining the value of the parameter at the specified position of the key method, that is, the code parameter, and querying the corresponding openid value through the saved redis, it is identified that the called key method needs to be mocked, and the obtained value replaces the openid value ${} in the template string, and the replaced template string is directly returned to the caller as the return content of the key method, so that the caller can obtain the openid of the corresponding users in batches, thereby querying the corresponding user information in the application, and simulating the login state of a large number of users with different APP accounts, meeting the scenario requirements of write-type interface stress testing in the APP.
[0113] The second embodiment of the present disclosure also provides an APP login state construction method, and the implementation steps are as follows:
[0114] 1. Testers Figure 4 Fill in the target application, key method, and redirect link 2 (where code is assigned to the placeholder ${}) on the page shown (provided by the present disclosure), and click the Mount button;
[0115] 2. After clicking the mount button, it will jump to Figure 5 The page shown (provided by the present disclosure) will show the status of the configuration line as "mounted successfully" at this time, and the tester can then click the edit button;
[0116] 3. After clicking the Edit button, a pop-up window will appear. Figure 6 In the pop-up window shown, the tester fills in the number of sessions to be generated (for example, 10,000) and clicks the Start Generation button;
[0117] 4. After clicking the Start Generate button, Service A will start generating the specified amount of session data (as shown in the following figure). Figure 7 ), and display the progress; after the generation is completed, the button will change to Figure 8 As shown, the tester can click a button to download the generated data to the local computer for subsequent use (data sample is Fig. 9 As shown, each line will contain sessionid, mobile number, openid).
[0118] The description and principle of each step are as follows:
[0119] For step 1:
[0120] 1. Target application: refers to the name of the application that handles the login logic;
[0121] 2. Key method: refers to the name of the internal method that handles the step of obtaining openid from the WeChat server in the login logic. Since it is necessary to query the WeChat server for openid based on the code, this key method must require a code parameter. The full path name of the key method must be filled in and the code must be the first parameter. For example, com.kcard.api.WxAuthBaseService#getOpenidBycode#1 means that the method getOpenidBycode under the class com.kcard.api.WxAuthBaseService is the key method, and code is the first parameter.
[0122] 3. Redirect link 2: refers to the request link initiated to the target application with code parameter (see the schematic Figure 2 The redirected active link 2 in the code is assigned a value of ${}, which will be replaced by a specific value by service A (the service provided by the present disclosure) later. Here is a supplementary explanation: when a redirect link 2 request is initiated to the target application, if the request does not carry a valid sessionid, the target application will generate a valid session for this session (i.e., this request) when receiving the request, and put the sessionid into the response header when returning the response content of the request.
[0123] For step 2:
[0124] After clicking the mount button, a request will be triggered to service A. After receiving the request, service A executes the following logic:
[0125] 1. Execute the remote command to mount and monitor the target application. The command is . / sandbox.sh-p7-d'service-monitor / authMonit', where 7 is the application process, which is obtained by executing the command ps-ef|grep-i kcard-xxx|awk'{print$2}′ (for example, the target application is kcard-xxx); sandbox.sh is the mount monitoring execution script of the jvm-sandbox installed in advance on the server where the application is located; jvm-sandbox is a jvm-based process monitoring tool that can monitor the java process (i.e., the application process) in the jvm. Similar tools include trace, arthas, etc. Therefore, if jvm-sandbox is not used, other monitoring tools can also be used to achieve the purpose; service-monitor / authMonit is the name of the monitoring logic implementation package provided by the present invention, and the implementation logic is as follows:
[0126] (1) Monitor the configured key method (such as com.kcard.api.WxAuthBaseService#getOpenidBycode). When the key method is called, execute the logic of (2) before the key method is executed;
[0127] (2) Get the value of the parameter at the specified position of the key method (if #1 is configured, get the value of the parameter at the first position), concatenate the value with the prefix mock:data:code: to form a redis key (for example, if the value is ikoksjiuKliwwa9ssa, the concatenated key is mock:data:code:ikoksjiuKliwwa9ssa), and try to get the value corresponding to the key from redis (the command is get mock::data:code:ikoksjiuKliwwa9ssa). If the value can be obtained, it means that the call of this key method needs to be mocked, and the logic of (3) is executed; if the value cannot be obtained, it means that the call of this key method is a normal call and does not need to be mocked, so no intervention is required (no need to execute the logic of (3)).
[0128] (3) Replace the template string {"access_token":"82_HJrJp69vtRj7od3_QWBJcHjpxkcqiDFZEfimW Q-59jwl8QUATL_ix_O0LlJPqxZkVoHamSqkX1F5VoUFYK9Cw8YHyrVEadlgov16Q_Jb1fI","refresh_token":"82_fMnTr_AqgSBsXolIl" with the obtained value V2wl-5GHmGIy7NvB9o5T88DLZ3_algblmS0ZYRH1IaLfE_wqxorT3VwH2XCyKfxoORs_tgOQoKf_Je3zrG7zLESkko","openid":"${}","scope":"snsapi_base","expires_in":7200}, the replaced template string is directly returned to the caller as the return content of the key method (the code of the key method will not be actually executed at this time). Here is an explanation: Under normal circumstances, when the WeChat server is queried for openid with code, the information returned by the WeChat server is like the template string, in addition to openid, it also contains other field information, but the application service generally only needs to use openid, so other field information does not need to be paid attention to (it can remain unchanged).
[0129] 2. Return the successful mounting information to the front-end page.
[0130] For step 3:
[0131] After clicking the Generate button, a request will be triggered to Service A. After receiving the request, Service A executes the following logic:
[0132] 1. According to the number of sessions filled in (such as 10000), start looping and executing the following logic:
[0133] (1) Use the random number tool method to generate a random code value (such as ikoksjiuKliwwa9ssa), a random openid value (such as Hauckkokil9sVI8sa), and a random 11-digit mobile phone number (assuming that the additional data is a mobile phone number), concatenate the code value and the prefix mock:data:code: into the redis key and the openid value as the redis value, and save them in redis (the code is: set mock:data:code:ikoksjiuKliwwa9ssaHauckkokil9sVI8sa), and then execute the logic of (2);
[0134] (2) Initiate an HTTP request, and the request address is the redirect link 2 filled in; before the request, replace the placeholder ${} with the code value generated in the previous step.
[0135] (3) The response header returned by the request will contain the set-cookie header information (such as sessionid=ewlis98dd1lstbUi1klass). At this time, the sessionid value in the header information is extracted, and the value, the previous openid value, and the mobile phone number are saved in a Map variable. The Map variable is then saved in a List variable for subsequent processing;
[0136] (4) Save the execution progress data in redis (such as set mock:progress 20, indicating that the progress is 20%);
[0137] 2. The above loop processing is executed asynchronously, that is, during the execution of the loop, service A will first return the request response content to the front-end page to inform the execution status;
[0138] 3. At the end of the above loop, the contents of the List variable are written and saved to a csv file, and the execution progress is updated to 100% (set mock:progress 100).
[0139] For step 4:
[0140] After clicking the Start Generation button, the page will continue to send query requests to service A to query the current generation progress. After receiving the request, service A will read the progress data in redis (set mock:progress) and return the progress value to the front-end page. When the progress is 100%, the button on the front-end changes to "Generation completed, click to download data". At this time, clicking the button will download the csv file to the local computer.
[0141] The present disclosure has built a test assistance system in the test environment, which can monitor the application under test;
[0142] A container with jvm-sandbox installed is deployed in the instance of the application under test, and the container will share jvm-sandbox with the application under test.
[0143] Refer to the disclosed solution to develop the code for monitoring processing logic, and you can implement it. The code example is as follows: Fig.10 As shown:
[0144] In this example, a method cn.chinaunicom.open.nlgxptconnection.COMPConnection#excute is monitored, and then the monitored method is changed to a key method such as com.kcard.api.WxAuthBaseService#getOpenidBycode, and the monitoring processing logic is implemented in the monitoring event.
[0145] The third embodiment of the present disclosure also provides an APP login state construction system, such as Fig.11 As shown, the system comprises:
[0146] Determination module 11, which is configured to determine the target application, key method and redirection link that need to generate the login state; the key method is an internal method for processing the step of obtaining the openid from the APP server in the login logic, and the redirection link is a request link initiated to the target application with the code parameter;
[0147] A mounting module 12, which is configured to mount a monitor on a key method so as to execute a monitoring logic before the key method is called;
[0148] A generating module 13 is configured to generate each random code value and its corresponding random openid value, and store them in redis;
[0149] A request module 14 is configured to initiate an http request of a key method, the request address is the redirect link, and the generated code value is used to replace the placeholder in the key method before the request;
[0150] A monitoring module 15 is configured to execute monitoring logic, read the code of the key method, and query the value corresponding to the code of the key method in redis;
[0151] The return module 16 is configured to replace the openid value in the template string of the APP with the value corresponding to the read code when the key method is executed if the monitoring module can query it, and return the replaced template string directly to the caller as the return content of the key method.
[0152] Furthermore, the generating module 13 is further configured to:
[0153] Determine the number of sessions that need to be generated; and,
[0154] The number of codes to be generated and the number of random openid values corresponding thereto are determined according to the number of sessions to be generated.
[0155] Furthermore, the system also includes a storage module 17;
[0156] The storage module 17 is configured to obtain the set-cookie header information contained in the response header returned by the request, and extract the value of the sessionid in the header information;
[0157] Save the sessionid value, the corresponding openid value, and the mobile phone number into a Map variable, and then save the Map variable into a List variable. The mobile phone number is generated when each random code value is generated; and,
[0158] At the end of the http request of all key methods, save the content of the List variable to a csv format file and update the execution progress to 100%.
[0159] Furthermore, the monitoring module 15 is also configured to:
[0160] If the value corresponding to the code of the key method cannot be found in redis, it means that the key method called this time does not need to be mocked, and the key method is executed normally.
[0161] Furthermore, the system further comprises a query module 18:
[0162] The query module 18 is configured to save execution progress data in redis;
[0163] When a query request is initiated to query the current generation progress, the progress data in redis is read and the progress value is returned to the front-end page.
[0164] The APP login state construction system of the disclosed embodiment is used to implement the APP login state construction method in method embodiment 1 and embodiment 2, so the description is relatively simple. For details, please refer to the relevant description in the previous method embodiment, which will not be repeated here.
[0165] In addition, if Fig.12 As shown, the fourth embodiment of the present disclosure further provides an electronic device, including a memory 100 and a processor 200, wherein the memory 100 stores a computer program, and when the processor 200 runs the computer program stored in the memory 100, the processor 200 executes the above-mentioned various possible methods.
[0166] The memory 100 is connected to the processor 200. The memory 100 may be a flash memory, a read-only memory or other memory, and the processor 200 may be a central processing unit or a single-chip microcomputer.
[0167] In addition, an embodiment of the present disclosure further provides a computer-readable storage medium, on which a computer program is stored, and the computer program is executed by a processor to perform the above-mentioned various possible methods.
[0168] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable read only memory), flash memory or other memory technology, CD-ROM (Compact Disc Read-Only Memory), Digital Video Disc (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.
[0169] It is to be understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of the present disclosure, but the present disclosure is not limited thereto. For those of ordinary skill in the art, various modifications and improvements can be made without departing from the spirit and substance of the present disclosure, and these modifications and improvements are also considered to be within the scope of protection of the present disclosure.
Claims
1. A method for constructing an APP login state, characterized in that: The method comprises: Determine the target application, key method and redirect link that need to generate the login state; the key method is the internal method that processes the step of obtaining the openid from the APP server in the login logic, and the redirect link is the request link initiated to the target application with the code parameter; Mount monitoring on key methods to execute monitoring logic before the key methods are called; Generate each random code value and its corresponding random openid value, and store them in the remote dictionary service redis; Initiate an http request for the key method, the request address is the redirect link, and replace the placeholder in the key method with the generated code value before the request; Execute the monitoring logic, read the code of the key method, and query the value corresponding to the code of the key method in redis; If it can be found, the value corresponding to the read code will replace the openid value in the template string of the APP when the key method is executed, and the replaced template string will be directly returned to the caller as the return content of the key method.
2. The method according to claim 1, characterized in that: The method further comprises: Determine the number of sessions that need to be generated; The number of codes to be generated and the number of random openid values corresponding thereto are determined according to the number of sessions to be generated.
3. The method according to claim 1, characterized in that The method further comprises: If the value corresponding to the code of the key method cannot be found in redis, it means that the key method called this time does not need to be mocked, and the key method is executed normally.
4. The method according to claim 1, characterized in that: The method further comprises: Get the set-cookie header information contained in the response header of the returned content of the request, and extract the value of sessionid in the header information; Save the sessionid value, the corresponding openid value, and the mobile phone number into a Map variable, and then save the Map variable into a List variable. The mobile phone number is generated when each random code value is generated. At the end of the http request of all key methods, save the content of the List variable to a csv format file and update the execution progress to 100%.
5. The method according to claim 4, characterized in that The method further comprises: Save the execution progress data in redis; When a query request is initiated to query the current generation progress, the progress data in redis is read and the progress value is returned to the front-end page.
6. An APP login state construction system, characterized in that: The system comprises: A determination module is configured to determine a target application, a key method, and a redirection link for generating a login state; the key method is an internal method for processing the step of obtaining an openid from an APP server in the login logic, and the redirection link is a request link initiated to the target application and carrying a code parameter; The mounting module is configured to mount a listener on a key method so as to execute the listening logic before the key method is called; A generation module is configured to generate each random code value and its corresponding random openid value and store them in redis; A request module is configured to initiate an http request of a key method, the request address is the redirect link, and the generated code value is used to replace the placeholder in the key method before the request; A monitoring module is configured to execute monitoring logic, read the code of the key method, and query the value corresponding to the code of the key method in redis; The return module is configured to replace the openid value in the template string of the APP with the value corresponding to the read code when the key method is executed if the listening module can query it, and return the replaced template string directly to the caller as the return content of the key method.
7. The system according to claim 6, characterized in that The generation module is also configured to: Determine the number of sessions that need to be generated; and, The number of codes to be generated and the number of random openid values corresponding thereto are determined according to the number of sessions to be generated.
8. The system according to claim 6, characterized in that The system also includes a storage module; The storage module is configured to obtain the set-cookie header information contained in the response header returned by the request, and extract the value of the sessionid in the header information; Save the sessionid value, the corresponding openid value, and the mobile phone number into a Map variable, and then save the Map variable into a List variable. The mobile phone number is generated when each random code value is generated; and, At the end of the http request of all key methods, save the content of the List variable to a csv format file and update the execution progress to 100%.
9. An electronic device, characterized in that: It includes a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the APP login state construction method as described in any one of claims 1-6.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by the processor, the APP login state construction method according to any one of claims 1 to 6 is implemented.