Application user session timeout test method, backend, foreground and system

Abstract

The embodiment of the present application provides an application user session timeout test method, background, foreground and system, which can be used in the field of financial technology. The method includes: in a server that has currently started user session timeout detection for a target application, searching for a pre-stored user session identifier corresponding to the target application, the user session identifier corresponds to the pre-stored user session latest creation time, and the user session latest creation time is the basis for the server to detect whether the current user session of the target application has timed out; deleting the user session identifier from the server, so that after receiving an operation request for the target application, if the server does not find the user session identifier locally, it controls the target application to be in a timeout state for timeout testing. The present application can effectively improve the efficiency of the application user session timeout test and reduce the timeout test cost without affecting the normal test process and timeout parameters of the application.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, in particular to the field of financial technology, and specifically to an application user session timeout testing method, backend, foreground and system. Background Art

[0002] As an important carrier in the mobile Internet era, APP (Application) is increasingly used in our daily life. In the process of application development and design, user session and other technologies are generally used for user authentication and session control. And the timeout mechanism of the application is generally implemented by setting the user session timeout parameters on the server side. In order to ensure the effectiveness of the application of the timeout mechanism, it is necessary to verify whether the functions in the application that should not be open to the timed-out user are indeed unavailable after the user session of the application times out. Therefore, it is necessary to test the timeout mechanism of the application.

[0003] Currently, the test method for the user session timeout mechanism is to passively wait for the user session to time out and then perform subsequent related verifications. However, since this method has a long waiting time, it will greatly reduce the test efficiency and increase the test cost. Therefore, testers will also modify the user session timeout parameters to shorten the waiting time and complete the timeout test of the application timeout mechanism in a shorter time.

[0004] However, although the method of modifying the user session timeout parameter can shorten the timeout parameter by manual setting, the user session timeout parameter is unique to a single application and all functions in the application share the parameter. Therefore, if a tester frequently uses this method to verify the timeout business scenario, it will interfere with other testers who are verifying normal functions at the same time. At the same time, this method artificially causes inconsistency in the configuration of the timeout parameter in the test environment and the production environment, which also increases the test risk and production risks. Summary of the invention

[0005] In response to the problems in the prior art, the present application provides an application user session timeout test method, background, foreground and system, which can effectively improve the test efficiency of the application user session timeout test without affecting the normal test process and timeout parameters of the application, and can effectively reduce the timeout test cost.

[0006] In order to solve the above technical problems, this application provides the following technical solutions:

[0007] In a first aspect, the present application provides a method for testing an application user session timeout.

[0008] In a server that has currently started user session timeout detection for a target application, searching for a pre-stored user session identifier corresponding to the target application, wherein the user session identifier corresponds to a pre-stored latest creation time of the user session, and the latest creation time of the user session is a basis for the server to detect whether the current user session of the target application has timed out;

[0009] The user session identifier corresponding to the target application is deleted from the server, so that after receiving an operation request for the target application, if the server fails to find the user session identifier corresponding to the target application locally, the server controls the target application to be in a timeout state to perform a timeout test on the target application.

[0010] Furthermore, before searching the pre-stored user session identifier corresponding to the target application in the server that has currently started the user session timeout detection for the target application, the method further includes:

[0011] If it is known that the server has established a connection with the target application and has locally stored the user session identifier corresponding to the target application and the corresponding user session latest creation time on the server, it is determined that the server has currently started user session timeout detection for the target application.

[0012] Furthermore, the server is locally provided with a plurality of first distributed storage units;

[0013] The first distributed storage unit is used to store the corresponding relationship between the user session identifier and the second distributed storage unit; the second distributed storage unit is used to store the corresponding relationship between the login user account corresponding to the target application and the latest creation time of the user session;

[0014] The user account is obtained by the server from the user login information in the login request after receiving the login request from the target application, wherein the user login information also includes a login password;

[0015] The user session identifier is generated when the server creates a user session with the target application after determining that the corresponding user is a legitimate user of the target application according to the user account and login password.

[0016] Further, searching for a pre-stored user session identifier corresponding to the target application in a server that has currently started user session timeout detection for the target application includes:

[0017] Extracting a user session identifier corresponding to the target application from a user login success notification message sent by the server to the target application, or from a pre-acquired list of currently logged-in users of the server, wherein the user session identifier is generated by the server after determining that the corresponding user is a legitimate user of the target application according to the pre-acquired login user account and login password of the target application, and the list of currently logged-in users contains user session identifiers corresponding to respective login users currently logged in to the server;

[0018] The user session identifier corresponding to the target application is searched in each of the first distributed storage units in the server.

[0019] Further, searching for a pre-stored user session identifier corresponding to the target application in a server that has currently started user session timeout detection for the target application includes:

[0020] When or after determining that the server has currently started user session timeout detection for the target application, searching for a login user account corresponding to the target application from each of the second distributed storage units in the server;

[0021] A user session identifier of the target application is obtained from a first distributed storage unit corresponding to a second distributed storage unit storing the login user account.

[0022] In a second aspect, the present application provides a user session management background, including:

[0023] an identifier acquisition module, configured to search for a pre-stored user session identifier corresponding to the target application in a server that has currently started user session timeout detection for the target application, wherein the user session identifier corresponds to the pre-stored latest creation time of the user session, and the latest creation time of the user session is a basis for the server to detect whether the current user session of the target application has timed out;

[0024] A timeout test module is used to delete the user session identifier corresponding to the target application from the server, so that after receiving an operation request for the target application, if the server fails to find the user session identifier corresponding to the target application locally, the server controls the target application to be in a user session timeout state to perform a timeout test on the target application.

[0025] In a third aspect, the present application provides a user session management front end, which is used to send an identification deletion instruction to a user session management back end, so that the user session management back end executes the application user session timeout test method when or after receiving the identification deletion instruction.

[0026] In a fourth aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for testing an application user session timeout is implemented, or when the processor executes the program, the function of the user session management foreground is implemented.

[0027] In a fifth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the application user session timeout test method, or, when executed by a processor, implements the function of the user session management foreground.

[0028] In a sixth aspect, the present application provides an application user session timeout test system, comprising: a client device, a server, a user session management backend, and the user session management frontend;

[0029] The user session management background is used to implement the application user session timeout test method;

[0030] The target application is provided in the client device, and the client device is in communication connection with the server so that the server establishes a connection with the target application and initiates user session timeout detection for the target application;

[0031] The user session management backend is respectively connected to the server and the user session management frontend for communication.

[0032] It can be seen from the above technical solution that the present application provides an application user session timeout test method, background, foreground and system, the method comprising: searching for a pre-stored user session identifier corresponding to the target application in a server that has currently started user session timeout detection for the target application, wherein the user session identifier corresponds to the pre-stored latest creation time of the user session, and the latest creation time of the user session is the basis for the server to detect whether the current user session of the target application has timed out; deleting the user session identifier corresponding to the target application from the server, so that after receiving an operation request for the target application, if the server does not find the user session identifier corresponding to the target application locally, the control The target application is placed in a timeout state to perform a timeout test on the target application; by actively deleting the session identifier of the target application in the server that has currently started user session timeout detection for the target application, the timeout environment of the application can be actively simulated to perform a timeout test on the application in the user session timeout state, and the test efficiency of the application user session timeout test can be effectively improved without affecting the normal test process and timeout parameters of the application, and the inconsistency of timeout parameters caused by human factors in the test environment and the production environment can be avoided, which can effectively reduce the test risk and production risks, and can effectively reduce the cost of timeout testing, save manpower and time costs, and improve the user experience of user session timeout testers. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0034] Figure 1 This is a first flow chart of the application user session timeout testing method in an embodiment of the present application.

[0035] Figure 2 This is a second flow chart of the application user session timeout testing method in an embodiment of the present application.

[0036] Figure 3 This is a first flow chart of step 100 in the application user session timeout testing method in an embodiment of the present application.

[0037] Figure 4 This is a second flow chart of step 100 in the application user session timeout testing method in an embodiment of the present application.

[0038] Figure 5 It is a structural diagram of the user session management background in an embodiment of the present application.

[0039] Figure 6 It is a schematic diagram of the relationship between the user session management front end and the user session management back end in an embodiment of the present application.

[0040] Figure 7 It is a structural diagram of the application user session timeout testing system in an embodiment of the present application.

[0041] Figure 8 It is a schematic diagram of the relationship between the participants of the application user session timeout test system in the application example of this application.

[0042] Fig. 9 It is a schematic diagram of the interaction process between the APP client and the APP server in the application example of this application.

[0043] Fig.10 This is a schematic diagram of the interaction process between the Session management background and the APP server in the application example of this application.

[0044] Fig.11 It is a schematic diagram of the interaction process between the Session management frontend and the Session management backend in the application example of this application.

[0045] Fig.12 It is a schematic diagram of the structure of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0047] It should be noted that the application user session timeout testing method and device disclosed in the present application can be used in the field of financial technology, and can also be used in any field other than the field of financial technology. The application field of the application user session timeout testing method and device disclosed in the present application is not limited.

[0048] The interaction between the application client and the server usually adopts HTTP. Because HTTP itself is a stateless protocol, in the process of application development and design, user session and other technologies are generally used for user authentication and session control. In the specific development work, each application will design the life cycle of user session according to its own business needs, that is, the timeout mechanism.

[0049] The timeout mechanism of an application is generally implemented by setting the user session timeout parameter on the server side. Except for a few instant messaging application software that set the user session timeout parameter to permanent due to business scenarios, most applications generally set this parameter to a fixed time, such as 15 minutes. Since the user session itself is directly related to the user identity and involves the security verification of the user identity on the server side, the timeout test, which is a test for the application timeout mechanism, is an important abnormal test scenario, that is, to verify whether the application can control the unavailability of various functions that should not be open to the timed-out user after the user session times out.

[0050] The existing testing methods for user session timeout mechanism mainly include the following two methods:

[0051] 1. Passive waiting for user session timeout: After the user logs in successfully, he reaches the page or function to be tested. After the page or function actually waits for timeout (such as 15 minutes), subsequent related verification is performed;

[0052] 2. Modify the user session timeout parameters: During the test, shorten the timeout parameters of the application to be tested on the server side, for example, shorten the original 15 minutes to 1 minute, and then perform relevant verification operations later.

[0053] Among them, the first test method is relatively backward, especially when the application to be tested has many functions or pages, or when the tester needs to frequently reproduce timeout problems, he can only passively wait for the user session to time out repeatedly, which wastes a lot of time. The test method is too costly and the test efficiency is low. Although the second test method can shorten the timeout parameter by manual setting, the user session timeout parameter is unique to a single application, and all functions in the application share the parameter; if a tester frequently uses this method to verify the timeout business scenario, it will interfere with other testers who verify normal functions at the same time; at the same time, the second test method artificially causes the timeout parameter configuration to be inconsistent between the test environment and the production environment, increasing the test risk and production risks.

[0054] Based on this, the embodiments of the present application respectively provide an application user session timeout test method, a user session management background, a user session management front end, an electronic device, a computer-readable storage medium and an application user session timeout test system. By actively deleting the session identifier of the target application in the server that has currently started the user session timeout detection for the target application, the timeout environment of the application can be actively simulated to perform a timeout test on the application in the user session timeout state. On the basis of not affecting the normal test process and timeout parameters of the application, the test efficiency of the application user session timeout test can be effectively improved, and the situation where the timeout parameters caused by human factors are inconsistent in the configuration of the test environment and the production environment can be avoided. The test risk and production hidden dangers can be effectively reduced, and the timeout test cost can be effectively reduced, manpower and time costs can be saved, and the user experience of user session timeout testers can be improved.

[0055] The details are described in detail through the following embodiments and application examples.

[0056] In one or more embodiments of the present application, an application App (Application) refers to software installed on a smart phone, and may also be referred to as mobile phone software.

[0057] In one or more embodiments of the present application, a user session Session in a computer, especially in a network application, may also be referred to as a session control. The Session object stores the attributes and configuration information required for a specific user session. In this way, when a user jumps between web pages of an application, the variables stored in the Session object will not be lost, but will persist throughout the entire user session.

[0058] In one or more embodiments of the present application, a timeout test refers to a test by a tester, when the application is in a timeout state, to determine whether functions in the application that should not be open to timed-out users are indeed unavailable. For example, after displaying a timeout page on the application client, the tester determines that it has entered a timeout state, and then the tester can verify subsequent post-timeout business scenarios on the application client.

[0059] In order to solve the problem that the existing application user session timeout test method cannot simultaneously meet the requirements of improving test efficiency and not modifying timeout parameters, the present application provides an embodiment of an application user session timeout test method, see Figure 1 The application user session timeout test method specifically includes the following contents:

[0060] Step 100: In a server that has currently started user session timeout detection for a target application, a pre-stored user session identifier corresponding to the target application is searched, wherein the user session identifier corresponds to the pre-stored latest creation time of the user session, and the latest creation time of the user session is the basis for the server to detect whether the current user session of the target application has timed out.

[0061] It can be understood that the server that has currently started user session timeout detection for the target application means that after establishing a connection with the client device of the target application, the user session timeout detection is started for the target application. The specific method can be periodically detecting whether the latest user session between the target application and the server has timed out.

[0062] In one example, the tester operates the client of the target application manually or through an automated testing tool, enters the account (or user identifier such as mobile phone number, ID card number, etc.) and password, and initiates a login request to the server; after the server verifies that the account and password are correct, it will call the internal user session generation function to create a user session for the user. After the user session is created and stored, the server returns the user session identifier SessionId corresponding to the user session Session and the function page information after successful login to the APP client in the form of a cookie; the client of the target application obtains the SessionId information returned from the server, and at the same time displays the function page after successful login to the tester.

[0063] During the execution of step 100 and step 200, the server has been periodically judging whether each locally stored user session has timed out based on the time difference between the latest creation time of the user session and the preset timeout parameter. For example, the server's user session periodic check thread is started periodically (for example, every 10 seconds). Each time the thread program is started, the current application server time is compared with the creation time corresponding to each SessionId stored in the memory. If the difference between the current application server time and the creation time of a certain SessionId is greater than or equal to the timeout parameter set by the APP server, the thread will automatically clear the SessionId in the memory HashMap1; if the difference between the current application server time and the creation time of a certain SessionId is less than the timeout parameter set by the APP server, no operation is performed.

[0064] Step 200: The user session identifier corresponding to the target application is deleted from the server, so that after receiving an operation request for the target application, if the server does not find the user session identifier corresponding to the target application locally, the server controls the target application to be in a timeout state to perform a timeout test on the target application.

[0065] In step 200, the user session management backend may send an identifier deletion instruction to the server, so that the server can automatically delete the user session identifier corresponding to the target application locally; or, the user session management backend receives the identifier deletion instruction sent by the user session management frontend, and then the user session management backend automatically deletes the user session identifier corresponding to the target application in the server. Then, the tester uses the Sessionid (which has been cleared) to initiate a request again on the client of the target application; after the server receives the request with SessionId, it will use the SessionId as the query condition, call the local user session query function, and query in the memory; because it cannot be found, the user session verification fails, that is, the user session times out, and returns the "verification failure" information to the client of the target application; the client of the target application receives the return information from the server, and displays the timeout page on the client, so that the tester can verify the subsequent business scenario after the timeout on the client.

[0066] From the above description, it can be seen that the application user session timeout test method provided in the embodiment of the present application can actively simulate the timeout environment of the application by actively deleting the session identifier of the target application in the server that has currently started the user session timeout detection for the target application, so as to perform a timeout test on the application in the user session timeout state. It can effectively improve the test efficiency of the application user session timeout test without affecting the normal test process and timeout parameters of the application, avoid the situation where the timeout parameters are inconsistently configured between the test environment and the production environment due to human factors, effectively reduce the test risk and production risks, and can effectively reduce the cost of timeout testing, save manpower and time costs, and improve the user experience of user session timeout testers.

[0067] In order to improve the reliability of the application user session timeout test, in one embodiment of the application user session timeout test method provided in the present application, see Figure 2 The application user session timeout test method further specifically includes the following contents before step 100:

[0068] Step 010: If it is known that the server has established a connection with the target application and has locally stored the user session identifier corresponding to the target application and the corresponding user session latest creation time on the server, it is determined that the server has currently started user session timeout detection for the target application.

[0069] From the above description, it can be seen that the application user session timeout test method provided in the embodiment of the present application can effectively improve the reliability of the application user session timeout test by actively determining that the server has currently started the user session timeout mechanism for the APP, and further improve the test efficiency of the application user session timeout test.

[0070] In order to improve the storage reliability of the user session identifier and the latest creation time of the user session, in one embodiment of the application user session timeout test method provided in the present application, the server in the application user session timeout test method is locally provided with multiple first distributed storage units; the first distributed storage unit is used to store the correspondence between the user session identifier and the second distributed storage unit; the second distributed storage unit is used to store the correspondence between the login user account corresponding to the target application and the latest creation time of the user session; wherein the user account is obtained by the server from the user login information in the login request after receiving the login request from the target application, wherein the user login information also includes a login password; the user session identifier is generated when the server creates a user session with the target application after determining that the corresponding user is a legitimate user of the target application according to the user account and the login password.

[0071] Specifically, the first distributed storage unit and the second distributed storage unit can both be hash map objects, the first distributed storage unit can be written as HashMap1, and the second distributed storage unit can be written as HashMap2. Specifically, the user session is stored in a hash map HashMap object in the memory in the form of elements, defined as HashMap1, where the key of HashMap1 is SessionId (the unique identifier of the user session Session), and the value is also a HashMap object, defined as HashMap2, the key of HashMap2 is the account value of the user who just logged in, and the value of HashMap2 is the creation time of the user session Session (the current target application APP application server time).

[0072] From the above description, it can be seen that the application user session timeout test method provided in the embodiment of the present application can effectively improve the storage reliability of the user session identifier and the latest creation time of the user session, and thus can provide an effective and reliable data basis for searching the pre-stored user session identifier corresponding to the target application.

[0073] In order to improve the reliability of the application user session timeout test, in one embodiment of the application user session timeout test method provided in the present application, see Figure 3 , step 100 of the application user session timeout testing method specifically includes the following contents:

[0074] Step 111: extracting a user session identifier corresponding to the target application from a user login success notification message sent by the server to the target application, or from a pre-acquired list of currently logged-in users of the server, wherein the user session identifier is generated by the server after determining that the corresponding user is a legitimate user of the target application based on the pre-acquired login user account and login password of the target application, and the list of currently logged-in users contains user session identifiers corresponding to each logged-in user currently logged in to the server.

[0075] Specifically, in the interaction between the user session management frontend and the user session management backend, the user session management frontend is directly facing testers and mainly provides three functions:

[0076] A. Logged-in user query function: Testers manually initiate a query request for logged-in users on the page, supporting query by account or query all;

[0077] After receiving the query request, the user session management front desk calls the user session management back-end function to obtain the HashMap1 object, and performs different program processing on the HashMap1 object according to the different query methods selected by the tester:

[0078] A-1. If the tester chooses to query by account number and has entered the account number to be queried:

[0079] (1) First layer: poll HashMap1 and obtain each key (SessionID) in HashMap1 in turn, denoted as key1, and its corresponding value (i.e. HashMap2), denoted as value1;

[0080] (2) Second layer: poll each HashMap2 and compare the account value entered by the tester with the key (account number, denoted as key2) in HashMap2:

[0081] If the match is consistent, key1 (SessionID), key2, and the value corresponding to key2 (Session "creation time") are displayed to the tester on the front desk;

[0082] If the match is inconsistent, it will return to the first layer and continue to poll HashMap1. If there is still no match after polling HashMap1, the front desk will return "query failed" to prompt the tester;

[0083] A-2. If the tester chooses to query all:

[0084] (1) First layer: poll HashMap1 and obtain each key (SessionID) in HashMap1 in turn, denoted as key1, and its corresponding value (i.e. HashMap2);

[0085] (2) Second layer: poll each HashMap2 and display key1, the key of HashMap2 (account number, recorded as key2), and the value corresponding to key2 (the "creation time" of the Session) to the tester on the front desk;

[0086] B. Clear logged-in user function: This function is a post-function of the "Logged-in user query function". The tester manually selects the SessionId of the logged-in user on the function page and sends the SessionId information to the user session management backend. The user session management backend (clear logged-in user function) clears the SessionId stored in the memory of the APP server by interacting with the APP server and returns the clearing result to the user session management backend. The user session management backend returns the clearing result to the user session management frontend and displays it to the tester.

[0087] C. Clear logged-in user API interface: This interface is an external API interface for the user session management frontend, which supports users to call this interface in the automated testing tool to clear the SessionId of the logged-in user; the input field of this interface is the account used by the user to log in to the application client, and the return result is "0" (success) or "1" (failure). The internal processing logic of the interface is the same as the function of clearing logged-in users; when the automated script needs to test the application timeout scenario, the script directly calls this interface through code and sends the account information of the logged-in user, and executes subsequent scripts according to the result returned by the interface.

[0088] Step 112: Search each of the first distributed storage units in the server for a user session identifier corresponding to the target application.

[0089] From the above description, it can be seen that the application user session timeout test method provided in the embodiment of the present application can effectively improve the efficiency and pertinence of searching for the user session identifier in the server by first obtaining the user session identifier corresponding to the target application and then searching for the user session identifier in the server, thereby further improving the test efficiency of the application user session timeout test.

[0090] In order to improve the reliability of the application user session timeout test, in one embodiment of the application user session timeout test method provided in the present application, see Figure 4 Step 100 of the application user session timeout testing method may further specifically include the following contents:

[0091] Step 121: When or after determining that the server has currently started user session timeout detection for the target application, searching for a login user account corresponding to the target application from each of the second distributed storage units in the server.

[0092] Step 122: Obtain the user session identifier of the target application from the first distributed storage unit corresponding to the second distributed storage unit storing the login user account.

[0093] From the above description, it can be seen that the application user session timeout test method provided in the embodiment of the present application indirectly queries the user session identifier of the target application using the login user account corresponding to the target application, without the need to know the user session identifier of the target application in advance. Therefore, it can effectively improve the convenience and efficiency of searching for the user session identifier in the server, thereby further improving the test efficiency of the application user session timeout test.

[0094] In order to solve the problem that the existing application user session timeout test method cannot simultaneously meet the requirements of improving test efficiency and not modifying timeout parameters, the present application provides an embodiment of a user session management background for executing all or part of the content of the application user session timeout test method, see Figure 5 The user session management background 1 specifically includes the following contents:

[0095] The identifier acquisition module 10 is used to search for a pre-stored user session identifier corresponding to the target application in a server that has currently started user session timeout detection for the target application, wherein the user session identifier corresponds to the pre-stored latest creation time of the user session, and the latest creation time of the user session is the basis for the server to detect whether the current user session of the target application has timed out.

[0096] It can be understood that the server that has currently started user session timeout detection for the target application means that after establishing a connection with the client device of the target application, the user session timeout detection is started for the target application. The specific method can be periodically detecting whether the latest user session between the target application and the server has timed out.

[0097] In one example, the tester operates the client of the target application manually or through an automated testing tool, enters the account (or user identifier such as mobile phone number, ID card number, etc.) and password, and initiates a login request to the server; after the server verifies that the account and password are correct, it will call the internal user session generation function to create a user session for the user. After the user session is created and stored, the server returns the user session identifier SessionId corresponding to the user session Session and the function page information after successful login to the APP client in the form of a cookie; the client of the target application obtains the SessionId information returned from the server, and at the same time displays the function page after successful login to the tester.

[0098] During the execution of the identification acquisition module 10 and the timeout test module 20, the server has been periodically judging whether each locally stored user session has timed out based on the time difference between the latest creation time of the user session and the preset timeout parameter. For example, the server's user session periodic check thread is started periodically (for example, every 10 seconds). Each time the thread program is started, the current application server time is compared with the creation time corresponding to each SessionId stored in the memory one by one. If the difference between the current application server time and the creation time of a certain SessionId is greater than or equal to the timeout parameter set by the APP server, the thread will automatically clear the SessionId in the memory HashMap1; if the difference between the current application server time and the creation time of a certain SessionId is less than the timeout parameter set by the APP server, no operation is performed.

[0099] The timeout test module 20 is used to delete the user session identifier corresponding to the target application from the server, so that after receiving an operation request for the target application, if the server fails to find the user session identifier corresponding to the target application locally, the server controls the target application to be in a user session timeout state to perform a timeout test on the target application.

[0100] In the timeout test module 20, the timeout test module 20 can send an identifier deletion instruction to the server so that the server can automatically delete the user session identifier corresponding to the target application locally; or, the timeout test module 20 receives the identifier deletion instruction sent by the user session management front desk, and then the timeout test module 20 automatically deletes the user session identifier corresponding to the target application in the server. Then, the tester uses the Sessionid (which has been cleared) to initiate a request again on the client of the target application; after the server receives the request with SessionId, it will use the SessionId as the query condition, call the local user session query function, and query in the memory; because it cannot be found, the user session verification fails, that is, the user session times out, and returns the "verification failure" information to the client of the target application; the client of the target application receives the return information from the server, and displays the timeout page on the client, so that the tester can verify the subsequent business scenario after the timeout on the client.

[0101] The embodiment of the user session management background 1 provided in the present application can be specifically used to execute the processing flow of the embodiment of the application user session timeout test method in the above embodiment. Its functions are not repeated here, and reference can be made to the detailed description of the above method embodiment.

[0102] From the above description, it can be seen that the user session management background 1 provided in the embodiment of the present application can actively simulate the timeout environment of the application by actively deleting the session identifier of the target application in the server that has currently started the user session timeout detection for the target application, so as to perform a timeout test on the application in the user session timeout state. It can effectively improve the test efficiency of the application user session timeout test without affecting the normal test process and timeout parameters of the application, avoid the inconsistency of the timeout parameters caused by human factors in the test environment and the production environment, effectively reduce the test risk and production risks, and can effectively reduce the timeout test cost, save manpower and time costs, and improve the user experience of user session timeout testers.

[0103] In order to improve the reliability of the application user session timeout test, in one embodiment of the user session management background 1 provided in the present application, the user session management background 1 is further specifically used to perform the following contents:

[0104] Step 010: If it is known that the server has established a connection with the target application and has locally stored the user session identifier corresponding to the target application and the corresponding user session latest creation time on the server, it is determined that the server has currently started user session timeout detection for the target application.

[0105] From the above description, it can be seen that the user session management background 1 provided in the embodiment of the present application can effectively improve the reliability of the application user session timeout test by actively determining that the server has currently started the user session timeout mechanism for the APP, and further improve the test efficiency of the application user session timeout test.

[0106] In order to improve the reliability of the application user session timeout test, in one embodiment of the user session management background 1 provided in the present application, the identification acquisition module 10 in the user session management background 1 is specifically used to perform the following contents:

[0107] Step 111: extracting a user session identifier corresponding to the target application from a user login success notification message sent by the server to the target application, or from a pre-acquired list of currently logged-in users of the server, wherein the user session identifier is generated by the server after determining that the corresponding user is a legitimate user of the target application based on the pre-acquired login user account and login password of the target application, and the list of currently logged-in users contains user session identifiers corresponding to each logged-in user currently logged in to the server.

[0108] Step 112: Search each of the first distributed storage units in the server for a user session identifier corresponding to the target application.

[0109] From the above description, it can be seen that the user session management background 1 provided in the embodiment of the present application can effectively improve the efficiency and pertinence of searching for the user session identifier in the server by first obtaining the user session identifier corresponding to the target application and then searching for the user session identifier in the server, thereby further improving the test efficiency of the application user session timeout test.

[0110] In order to improve the reliability of the application user session timeout test, in one embodiment of the user session management background 1 provided in the present application, the identification acquisition module 10 in the user session management background 1 is further specifically used to perform the following contents:

[0111] Step 121: When or after determining that the server has currently started user session timeout detection for the target application, searching for a login user account corresponding to the target application from each of the second distributed storage units in the server.

[0112] Step 122: Obtain the user session identifier of the target application from the first distributed storage unit corresponding to the second distributed storage unit storing the login user account.

[0113] From the above description, it can be seen that the user session management background 1 provided in the embodiment of the present application indirectly queries the user session identifier of the target application by using the login user account corresponding to the target application, without having to know the user session identifier of the target application in advance. Therefore, it can effectively improve the convenience and efficiency of searching for the user session identifier in the server, and further improve the test efficiency of the application user session timeout test.

[0114] Based on the above user session management background 1, see Figure 6 The present application also provides a user session management front end 2 that is communicatively connected to the user session management front end 1, and the user session management front end 2 is used to send an identification deletion instruction to a user session management back end, so that the user session management back end executes the application user session timeout test method mentioned in the aforementioned embodiment when or after receiving the identification deletion instruction.

[0115] From the above description, it can be seen that the user session management front end 2 provided in the embodiment of the present application can effectively improve the application reliability of the user session management background in executing the application user session timeout test method by sending an identification deletion instruction to the user session management background according to the information input by the tester, and can effectively improve the operation convenience of the tester.

[0116] Based on the above user session management background 1 and user session management front end 2, see Figure 7 The present application also provides an application user session timeout test system, comprising: a client device 3, a server 4, the user session management background 1 mentioned in the aforementioned embodiment, and a user session management front desk 2; the user session management background 1 is used to implement the application user session timeout test method; the target application is provided in the client device 3, and the client device 3 is communicated with the server 4 so that the server 4 establishes a connection with the target application and starts a user session timeout detection for the target application; the user session management background 1 is communicated with the server 4 and the user session management front desk 2 respectively.

[0117] From the above description, it can be seen that the application user session timeout test system provided in the embodiment of the present application can actively simulate the timeout environment of the application by actively deleting the session identifier of the target application in the server that has currently started the user session timeout detection for the target application, so as to perform a timeout test on the application in the user session timeout state. It can effectively improve the test efficiency of the application user session timeout test without affecting the normal test process and timeout parameters of the application, avoid the situation where the timeout parameters are inconsistently configured between the test environment and the production environment due to human factors, effectively reduce the test risk and production risks, and can effectively reduce the cost of timeout testing, save manpower and time costs, and improve the user experience of user session timeout testers.

[0118] To further illustrate the present solution, the present application also provides a specific application example of an application user session timeout test method implemented by the application user session timeout test system, which can achieve efficient testing of the application APP timeout mechanism without interfering with the normal test process and timeout parameters of the application APP, and can significantly reduce the testing cost. In this application example, the client device 3 is the APP client, the server 4 is the APP server, the user session management background 1 mentioned in the aforementioned embodiment is the Session management background, and the user session management foreground 2 is the Session management foreground.

[0119] (I) The application user session timeout test system mainly solves the technical problems of low efficiency, high cost, great interference with normal testing work and certain testing risks in the existing application APP timeout mechanism testing method, see Figure 8 , specifically including the following contents:

[0120] (1) APP client: The APP client to be tested in the test environment is the test object of manual or automated testing by testers;

[0121] (2) APP server: The APP server in the test environment processes requests initiated by the APP client;

[0122] (3) Session management frontend: receives session operation requirements initiated by testers manually or through automated tools, generates operation instructions and sends them to the session management backend;

[0123] (4) Session management backend: It is a non-intrusive tool designed for this application example. It is deployed on the same server as the APP server and is responsible for interacting with the APP server to obtain or operate user session information.

[0124] (II) Interaction process between APP client and APP server

[0125] See also Fig. 9 , is the interaction flow chart between the APP client and the APP server. The specific steps are as follows:

[0126] Step 1: The tester operates the APP client manually or through an automated testing tool, enters the account number (or user identifier such as mobile phone number, ID card number, etc.) and password, and initiates a login request to the APP server;

[0127] Step 2, after the APP server verifies that the account and password are correct, it will call the internal Session generation function to create a Session for the user. The Session is stored in a HashMap object in the memory in the form of elements, defined as HashMap1, where the key of HashMap1 is SessionId (the unique identifier of the Session), and the value is also a HashMap object, defined as HashMap2. The key of HashMap2 is the account value that the user just logged in, and the value of HashMap2 is the creation time of the Session (the current APP application server time); after the Session is created and stored, the APP server returns the SessionId corresponding to the Session and the function page information after successful login to the APP client in the form of cookies;

[0128] Step 3, the APP client obtains the SessionId information returned from the APP server, and displays the function page after successful login to the tester;

[0129] Step 4: The tester initiates a transaction request again on the APP client, and the request will carry the SessionId information;

[0130] Step 5, after receiving the request with SessionId, the APP server will use SessionId as the query condition, call the server's Session query function, and query in the HashMap1 stored in the memory;

[0131] If it cannot be found, the session verification fails, that is, the session times out, and the "verification failure" message is returned to the APP client;

[0132] If it can be found, the Session verification is successful, and the "creation time" corresponding to the SessionId in HashMap1 is updated to the current APP application server time), and the "verification success" and request response information are returned to the APP client;

[0133] Step 6, the APP client receives the return information from the APP server. If "verification failed", the timeout function page will be displayed on the client to prompt the customer. If "verification succeeded", the normal business function page will be displayed according to the return response information of the APP server;

[0134] Step 7, the APP server's Session periodic check thread is started periodically (for example, every 10 seconds). Each time the thread program is started, it will compare the current application server time with the "creation time" corresponding to each SessionId stored in the memory. If the difference between the "current application server time and the "creation time" of a SessionId is greater than or equal to the timeout parameter set by the APP server, the thread will automatically clear the SessionId in the memory HashMap1; if the difference between the "current application server time and the "creation time" of a SessionId is less than the timeout parameter set by the APP server, no operation will be performed;

[0135] Step 8: The tester uses the Sessionid (which has been cleared) to initiate a request again on the APP client.

[0136] Step 9, after receiving the request with SessionId, the APP server will use the SessionId as the query condition, call the server-side Session query function, and query the HashMap1 stored in the memory; because it cannot be found, the Session verification fails, that is, the Session times out, and returns the "verification failure" information to the APP client;

[0137] Step 10: The APP client receives the return information from the APP server and displays the timeout page on the client. The tester verifies the subsequent business scenarios after the timeout on the client.

[0138] (III) Interaction process between APP server and Session management background

[0139] See also Fig.10 , which is the interaction flow chart between the APP server and the Session management backend in this application example. The "Session management backend" is one of the core designs of this application example. It is a non-intrusive tool independent of the APP server and is deployed on the same server as the APP server. It is responsible for interacting with the APP server to obtain or operate user Session information. The specific steps are as follows:

[0140] Step 1: After the APP client initiates a login request, the APP server verifies that the login information is correct, calls the internal Session generation function, generates a Session object and stores it in memory;

[0141] Step 2: After receiving the request of "query logged-in users" from the Session Management Front Desk, the Session Management Back Desk will call the Session Query function of the APP server to obtain the entire HashMap1 object and return it to the Session Management Front Desk;

[0142] Step 3. If the Session management backend receives a request to "clear logged-in users" from the Session management frontend, it will call the Session clearing function of the APP server and send the SessionId information to be cleared; the Session clearing function of the APP server will match the sent SessionId information with all keys in the HashMap1 that stores the Session, and delete the corresponding Session record if the match is successful.

[0143] IV) The interaction process between the Session management front desk and the Session management back desk

[0144] See also Fig.11 , which is the interaction flow chart between the Session management frontend and the Session management backend of this application example. The Session management frontend is directly facing testers and mainly provides three functions:

[0145] A. Logged-in user query function: Testers manually initiate "query logged-in users" on the page, supporting query by account or query all;

[0146] After receiving the query request, the Session management front desk calls the Session management back-end function to obtain the HashMap1 object, and performs different program processing on the HashMap1 object according to the different query methods selected by the tester:

[0147] 1. If the tester chooses to query by account number and has entered the account number to be queried:

[0148] (1) First layer: poll HashMap1 and obtain each key (SessionID) in HashMap1 in turn, denoted as key1, and its corresponding value (i.e. HashMap2), denoted as value1;

[0149] (2) Second layer: poll each HashMap2 and compare the account value entered by the tester with the key (account number, denoted as key2) in HashMap2:

[0150] If the match is consistent, key1 (SessionID), key2, and the value corresponding to key2 (Session "creation time") are displayed to the tester on the front desk;

[0151] If the match is inconsistent, it will return to the first layer and continue to poll HashMap1. If there is still no match after polling HashMap1, the front desk will return "query failed" to prompt the tester;

[0152] 2. If the tester chooses to query all:

[0153] (1) First layer: poll HashMap1 and obtain each key (SessionID) in HashMap1 in turn, denoted as key1, and its corresponding value (i.e. HashMap2);

[0154] (2) Second layer: poll each HashMap2 and display key1, the key of HashMap2 (account number, recorded as key2), and the value corresponding to key2 (the "creation time" of the Session) to the tester on the front desk;

[0155] B. Clear logged-in user function: This function is a post-function of the "Logged-in user query function". The tester manually selects the SessionId of the logged-in user on the function page and sends the SessionId information to the Session management backend. The Session management backend (clear logged-in user function) interacts with the APP server (see attached Figure 3 ), clear the SessionId stored in the APP server memory and return the clearing result to the Session management backend. The Session management backend returns the clearing result to the Session management frontend and displays it to the tester;

[0156] C. Clear logged-in user API interface: This interface is the external API interface of the "Session Management Front Desk", which supports users to call this interface in the automated testing tool to clear the SessionId of the logged-in user; the input field of this interface is the account used by the user to log in to the mobile APP client, and the return result is "0" (success) or "1" (failure). The internal processing logic of the interface is the same as "B. Clear logged-in user function"; when the automated script needs to test the APP timeout scenario, the script directly calls this interface through code and sends the account information of the logged-in user, and executes subsequent scripts according to the result returned by the interface.

[0157] Based on the above content, the application user session timeout testing method implemented by the application user session timeout testing system specifically includes the following content:

[0158] Step 1: Select the mobile APP client to be tested. The tester operates the APP client, selects the login function, enters the account and password, and initiates a login request to the APP server.

[0159] Step 2: After the APP server verifies that the account and password are correct, it notifies the client, and the client displays the login success page to the tester, and the tester enters the APP client login function;

[0160] Step 3: The tester operates in the mobile APP client to reach the function page where the timeout mechanism is to be tested;

[0161] Step 4. The tester accesses the "Session Management Front Desk" through the browser, enters the "Logged In User Query Function", enters the account just used to log in to the mobile APP for query, and obtains the SeesionId corresponding to the account after the query is successful; the tester continues to use the "Clear Logged In User" function to initiate a clear request for the SeesionId corresponding to the account. The request reaches the APP server through the "Session Management Front Desk" - "Session Management Backend". The APP server clears the SeesionId after matching it in the memory and returns the clearing success result. The successful result is displayed to the tester after passing through the "Session Management Backend" - "Session Management Front Desk";

[0162] Step 5. After receiving the clearing success result, the tester returns to Step 3 and can test the business scenario after the timeout on the function page to be tested. There is no need to wait for the time set by the timeout parameter (such as 15 minutes or even longer) as before, thereby achieving the purpose of improving test efficiency.

[0163] From the above description, it can be seen that the application user session timeout test method and related system provided by the application example of this application complete the Session interaction with the mobile APP server by designing the Session operation foreground / background, thereby solving the technical problems of low efficiency, high cost, large interference with normal testing work and certain testing risks of the existing mobile APP timeout mechanism testing method; this method realizes efficient testing of the mobile APP timeout mechanism without interfering with or modifying the normal testing process and timeout parameters of the mobile APP, which can significantly reduce the time cost of testing work. The method and the corresponding system have been put into production and have good application effects. The test time of the relevant timeout mechanism test scenario has been reduced by more than 90%, and the test efficiency has been significantly improved; the test method and system support both manual testing by testers and the use of automated testing tools, which can meet the multi-dimensional application needs of testers.

[0164] From a hardware perspective, in order to solve the problem that the existing application user session timeout test method cannot simultaneously meet the requirements of improving test efficiency and not modifying timeout parameters, the present application provides an embodiment of an electronic device for implementing all or part of the content of the application user session timeout test method or the user session management front-end function, and the electronic device specifically includes the following content:

[0165] Fig.12 FIG. 9 is a schematic block diagram of the system structure of the electronic device 9600 according to an embodiment of the present application. Fig.12 As shown, the electronic device 9600 may include a central processor 9100 and a memory 9140; the memory 9140 is coupled to the central processor 9100. It is worth noting that Fig.12 is exemplary; other types of structures may also be used to supplement or replace this structure to implement telecommunication functions or other functions.

[0166] In one embodiment, the application user session timeout test function may be integrated into the central processing unit. The central processing unit may be configured to perform the following control:

[0167] Step 100: In a server that has currently started user session timeout detection for a target application, a pre-stored user session identifier corresponding to the target application is searched, wherein the user session identifier corresponds to the pre-stored latest creation time of the user session, and the latest creation time of the user session is the basis for the server to detect whether the current user session of the target application has timed out.

[0168] It can be understood that the server that has currently started user session timeout detection for the target application means that after establishing a connection with the client device of the target application, the user session timeout detection is started for the target application. The specific method can be periodically detecting whether the latest user session between the target application and the server has timed out.

[0169] In one example, the tester operates the client of the target application manually or through an automated testing tool, enters the account (or user identifier such as mobile phone number, ID card number, etc.) and password, and initiates a login request to the server; after the server verifies that the account and password are correct, it will call the internal user session generation function to create a user session for the user. After the user session is created and stored, the server returns the user session identifier SessionId corresponding to the user session Session and the function page information after successful login to the APP client in the form of a cookie; the client of the target application obtains the SessionId information returned from the server, and at the same time displays the function page after successful login to the tester.

[0170] During the execution of step 100 and step 200, the server has been periodically judging whether each locally stored user session has timed out based on the time difference between the latest creation time of the user session and the preset timeout parameter. For example, the server's user session periodic check thread is started periodically (for example, every 10 seconds). Each time the thread program is started, the current application server time is compared with the creation time corresponding to each SessionId stored in the memory. If the difference between the current application server time and the creation time of a certain SessionId is greater than or equal to the timeout parameter set by the APP server, the thread will automatically clear the SessionId in the memory HashMap1; if the difference between the current application server time and the creation time of a certain SessionId is less than the timeout parameter set by the APP server, no operation is performed.

[0171] Step 200: The user session identifier corresponding to the target application is deleted from the server, so that after receiving an operation request for the target application, if the server does not find the user session identifier corresponding to the target application locally, the server controls the target application to be in a timeout state to perform a timeout test on the target application.

[0172] In step 200, the user session management backend may send an identifier deletion instruction to the server, so that the server can automatically delete the user session identifier corresponding to the target application locally; or, the user session management backend receives the identifier deletion instruction sent by the user session management frontend, and then the user session management backend automatically deletes the user session identifier corresponding to the target application in the server. Then, the tester uses the Sessionid (which has been cleared) to initiate a request again on the client of the target application; after the server receives the request with SessionId, it will use the SessionId as the query condition, call the local user session query function, and query in the memory; because it cannot be found, the user session verification fails, that is, the user session times out, and returns the "verification failure" information to the client of the target application; the client of the target application receives the return information from the server, and displays the timeout page on the client, so that the tester can verify the subsequent business scenario after the timeout on the client.

[0173] From the above description, it can be seen that the electronic device provided in the embodiment of the present application can actively simulate the timeout environment of the application by actively deleting the session identifier of the target application in the server that has currently started user session timeout detection for the target application, so as to perform a timeout test on the application in the user session timeout state. It can effectively improve the test efficiency of the application user session timeout test without affecting the normal test process and timeout parameters of the application, avoid the situation where the timeout parameters are inconsistently configured between the test environment and the production environment due to human factors, effectively reduce the test risk and production risks, and can effectively reduce the cost of timeout testing, save manpower and time costs, and improve the user experience of user session timeout testers.

[0174] For another example, the central processing unit may be configured to perform the following control:

[0175] Sending an identification deletion instruction to a user session management background, so that the user session management background executes the application user session timeout test method mentioned in the above embodiment when or after receiving the identification deletion instruction.

[0176] From the above description, it can be seen that the electronic device provided in the embodiment of the present application can effectively improve the application reliability of the user session management background in executing the application user session timeout test method by sending an identification deletion instruction to the user session management background according to the information input by the tester, and can effectively improve the operation convenience of the tester.

[0177] In another embodiment, the user session management background can be configured separately from the central processing unit 9100. For example, the user session management background can be configured as a chip connected to the central processing unit 9100, and the application user session timeout test function is implemented through the control of the central processing unit.

[0178] like Fig.12 As shown, the electronic device 9600 may also include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily have to include Fig.12 In addition, the electronic device 9600 may also include Fig.12 For components not shown, reference may be made to the prior art.

[0179] like Fig.12 As shown, the central processing unit 9100 is sometimes also referred to as a controller or an operation control, and may include a microprocessor or other processor device and / or logic device. The central processing unit 9100 receives input and controls the operation of various components of the electronic device 9600.

[0180] The memory 9140 may be, for example, one or more of a cache, a flash memory, a hard drive, a removable medium, a volatile memory, a non-volatile memory or other suitable devices. The above-mentioned information related to the failure may be stored, and a program for executing the relevant information may also be stored. The CPU 9100 may execute the program stored in the memory 9140 to implement information storage or processing, etc.

[0181] The input unit 9120 provides input to the central processing unit 9100. The input unit 9120 is, for example, a key or a touch input device. The power supply 9170 is used to provide power to the electronic device 9600. The display 9160 is used to display display objects such as images and texts. The display may be, for example, an LCD display, but is not limited thereto.

[0182] The memory 9140 may be a solid-state memory, such as a read-only memory (ROM), a random access memory (RAM), a SIM card, etc. It may also be a memory that saves information even when the power is off, can be selectively erased, and is provided with more data, examples of which are sometimes referred to as EPROMs, etc. The memory 9140 may also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142, which is used to store application programs and function programs or processes for executing the operation of the electronic device 9600 through the central processor 9100.

[0183] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for communication functions of the electronic device and / or for executing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0184] The communication module 9110 is a transmitter / receiver 9110 that sends and receives signals via an antenna 9111. The communication module (transmitter / receiver) 9110 is coupled to the central processor 9100 to provide input signals and receive output signals, which may be the same as the case of a conventional mobile communication terminal.

[0185] Based on different communication technologies, multiple communication modules 9110 may be provided in the same electronic device, such as a cellular network module, a Bluetooth module and / or a wireless LAN module, etc. The communication module (transmitter / receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide an audio output via the speaker 9131 and receive an audio input from the microphone 9132, thereby realizing a common telecommunication function. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. In addition, the audio processor 9130 is also coupled to the central processor 9100, so that recording can be performed on the local machine through the microphone 9132, and the sound stored on the local machine can be played through the speaker 9131.

[0186] The embodiments of the present application also provide a computer-readable storage medium capable of implementing all the steps of the application user session timeout test method in the above embodiments. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the computer program implements all the steps of the application user session timeout test method in the above embodiments, where the execution subject is a server or a client, or the user session management front-end function. For example, when the processor executes the computer program, the following steps are implemented:

[0187] Step 100: In a server that has currently started user session timeout detection for a target application, a pre-stored user session identifier corresponding to the target application is searched, wherein the user session identifier corresponds to the pre-stored latest creation time of the user session, and the latest creation time of the user session is the basis for the server to detect whether the current user session of the target application has timed out.

[0188] It can be understood that the server that has currently started user session timeout detection for the target application means that after establishing a connection with the client device of the target application, the user session timeout detection is started for the target application. The specific method can be periodically detecting whether the latest user session between the target application and the server has timed out.

[0189] In one example, the tester operates the client of the target application manually or through an automated testing tool, enters the account (or user identifier such as mobile phone number, ID card number, etc.) and password, and initiates a login request to the server; after the server verifies that the account and password are correct, it will call the internal user session generation function to create a user session for the user. After the user session is created and stored, the server returns the user session identifier SessionId corresponding to the user session Session and the function page information after successful login to the APP client in the form of a cookie; the client of the target application obtains the SessionId information returned from the server, and at the same time displays the function page after successful login to the tester.

[0190] During the execution of step 100 and step 200, the server has been periodically judging whether each locally stored user session has timed out based on the time difference between the latest creation time of the user session and the preset timeout parameter. For example, the server's user session periodic check thread is started periodically (for example, every 10 seconds). Each time the thread program is started, the current application server time is compared with the creation time corresponding to each SessionId stored in the memory. If the difference between the current application server time and the creation time of a certain SessionId is greater than or equal to the timeout parameter set by the APP server, the thread will automatically clear the SessionId in the memory HashMap1; if the difference between the current application server time and the creation time of a certain SessionId is less than the timeout parameter set by the APP server, no operation is performed.

[0191] Step 200: The user session identifier corresponding to the target application is deleted from the server, so that after receiving an operation request for the target application, if the server does not find the user session identifier corresponding to the target application locally, the server controls the target application to be in a timeout state to perform a timeout test on the target application.

[0192] In step 200, the user session management backend may send an identifier deletion instruction to the server, so that the server can automatically delete the user session identifier corresponding to the target application locally; or, the user session management backend receives the identifier deletion instruction sent by the user session management frontend, and then the user session management backend automatically deletes the user session identifier corresponding to the target application in the server. Then, the tester uses the Sessionid (which has been cleared) to initiate a request again on the client of the target application; after the server receives the request with SessionId, it will use the SessionId as the query condition, call the local user session query function, and query in the memory; because it cannot be found, the user session verification fails, that is, the user session times out, and returns the "verification failure" information to the client of the target application; the client of the target application receives the return information from the server, and displays the timeout page on the client, so that the tester can verify the subsequent business scenario after the timeout on the client.

[0193] From the above description, it can be seen that the computer-readable storage medium provided in the embodiment of the present application can actively simulate the timeout environment of the application by actively deleting the session identifier of the target application in the server that has currently started the user session timeout detection for the target application, so as to perform a timeout test on the application in the user session timeout state. It can effectively improve the test efficiency of the application user session timeout test without affecting the normal test process and timeout parameters of the application, avoid the situation where the timeout parameters are inconsistently configured between the test environment and the production environment due to human factors, effectively reduce the test risk and production risks, and can effectively reduce the cost of timeout testing, save manpower and time costs, and improve the user experience of user session timeout testers.

[0194] For another example, when the processor executes the computer program, the following steps are implemented:

[0195] Sending an identification deletion instruction to a user session management background, so that the user session management background executes the application user session timeout test method mentioned in the above embodiment when or after receiving the identification deletion instruction.

[0196] From the above description, it can be seen that the computer-readable storage medium provided in the embodiment of the present application can effectively improve the application reliability of the user session management background executing the application user session timeout test method by sending an identification deletion instruction to the user session management background according to the information input by the tester, and can effectively improve the operation convenience of the tester.

[0197] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, devices, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0198] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (apparatus), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0199] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0200] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0201] The present invention uses specific embodiments to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A method for testing application user session timeout, characterized in that: include: If it is known that the server has established a connection with the target application and has stored the user session identifier corresponding to the target application and the latest creation time of the corresponding user session locally on the server, it is determined that the server has currently started user session timeout detection for the target application; In a server that has currently started user session timeout detection for a target application, searching for a pre-stored user session identifier corresponding to the target application, wherein the user session identifier corresponds to a pre-stored latest creation time of the user session, and the latest creation time of the user session is a basis for the server to detect whether the current user session of the target application has timed out; deleting the user session identifier corresponding to the target application from the server, so that after receiving an operation request for the target application, if the server fails to find the user session identifier corresponding to the target application locally, the server controls the target application to be in a timeout state to perform a timeout test on the target application; Deleting the user session identifier corresponding to the target application from the server includes: Receive an identifier deletion instruction sent by the user session management front desk, and delete the corresponding user session identifier according to the identifier deletion instruction; the identifier deletion instruction is generated based on the user session identifier found by the tester or based on an automated testing tool.

2. The application user session timeout testing method according to claim 1, characterized in that: The server is locally provided with a plurality of first distributed storage units; The first distributed storage unit is used to store the corresponding relationship between the user session identifier and the second distributed storage unit; the second distributed storage unit is used to store the corresponding relationship between the login user account corresponding to the target application and the latest creation time of the user session; The user account is obtained by the server from the user login information in the login request after receiving the login request from the target application, wherein the user login information also includes a login password; The user session identifier is generated when the server creates a user session with the target application after determining that the corresponding user is a legitimate user of the target application according to the user account and login password.

3. The application user session timeout testing method according to claim 2, characterized in that: The step of searching, in a server that has currently started user session timeout detection for a target application, a pre-stored user session identifier corresponding to the target application, includes: Extracting a user session identifier corresponding to the target application from a user login success notification message sent by the server to the target application, or from a pre-acquired list of currently logged-in users of the server, wherein the user session identifier is generated by the server after determining that the corresponding user is a legitimate user of the target application according to the pre-acquired login user account and login password of the target application, and the list of currently logged-in users contains user session identifiers corresponding to respective login users currently logged in to the server; The user session identifier corresponding to the target application is searched in each of the first distributed storage units in the server.

4. The application user session timeout testing method according to claim 2, characterized in that: The step of searching, in a server that has currently started user session timeout detection for a target application, a pre-stored user session identifier corresponding to the target application, includes: When or after determining that the server has currently started user session timeout detection for the target application, searching for a login user account corresponding to the target application from each of the second distributed storage units in the server; A user session identifier of the target application is obtained from a first distributed storage unit corresponding to a second distributed storage unit storing the login user account.

5. A user session management backend, characterized in that: include: an identifier acquisition module, configured to search for a pre-stored user session identifier corresponding to the target application in a server that has currently started user session timeout detection for the target application, wherein the user session identifier corresponds to the pre-stored latest creation time of the user session, and the latest creation time of the user session is a basis for the server to detect whether the current user session of the target application has timed out; a timeout test module, configured to delete the user session identifier corresponding to the target application from the server, so that after receiving an operation request for the target application, if the server fails to find the user session identifier corresponding to the target application locally, the server controls the target application to be in a user session timeout state to perform a timeout test on the target application; The timeout test module is specifically used for: Receive an identifier deletion instruction sent by the user session management front desk, and delete the corresponding user session identifier according to the identifier deletion instruction; the identifier deletion instruction is generated based on the user session identifier selected by the tester or based on the automated testing tool; The user session management backend is also used for: If it is known that the server has established a connection with the target application and has locally stored the user session identifier corresponding to the target application and the corresponding user session latest creation time on the server, it is determined that the server has currently started user session timeout detection for the target application.

6. A user session management front end, characterized in that: The user session management front end is used to send an identification deletion instruction to a user session management back end, so that the user session management back end executes the application user session timeout test method as described in any one of claims 1 to 4 when or after receiving the identification deletion instruction.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, it implements the application user session timeout testing method described in any one of claims 1 to 4, or, when the processor executes the program, it implements the user session management foreground function described in claim 6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the application user session timeout testing method described in any one of claims 1 to 4, or when the computer program is executed by a processor, it implements the user session management foreground function described in claim 6.

9. A computer program product, characterized in that The computer program product includes a computer program, which, when executed by a processor, implements the application user session timeout testing method described in any one of claims 1 to 4, or, when executed by a processor, implements the user session management foreground function described in claim 6.

10. An application user session timeout testing system, characterized in that: include: A client device, a server, a user session management backend, and a user session management frontend as claimed in claim 6; The user session management backend is used to implement the application user session timeout test method according to any one of claims 1 to 4; The target application is provided in the client device, and the client device is in communication connection with the server so that the server establishes a connection with the target application and initiates user session timeout detection for the target application; The user session management backend is respectively connected to the server and the user session management frontend for communication.

Images