Test account management methods, devices, equipment and storage media

Abstract

This application provides a test account management method, apparatus, device, and storage medium. The method includes: determining a target test account for fulfilling the test requirements based on acquired test requirements; searching for candidate test accounts with an inheritance relationship to the target test account in a test data platform that stores at least one test account in a tree structure; determining a first set of steps required to create the target test account based on the test requirements; obtaining a second set of steps included in the candidate test accounts; and creating the target test account based on at least one set of the first and second steps. Thus, by creating the target test account based on the candidate test accounts in the test data platform, the utilization rate of test accounts in the test data platform is improved.

Description

Technical Field

[0001] This application relates to the field of software testing, and in particular to methods, apparatus, devices and storage media for test account management. Background Technology

[0002] In the R&D testing process, the need for constructing relevant test data is becoming increasingly frequent. Consequently, data construction across multiple test accounts often proceeds independently, and with the increasing number of test accounts, data construction may even be duplicated. This process easily leads to a lot of dirty data, hindering subsequent use, making maintenance difficult, and resulting in low utilization of test accounts. Summary of the Invention

[0003] This application provides a test account management method, apparatus, device, and storage medium, which can improve the efficiency of automated testing and the utilization rate of test accounts in the test data platform.

[0004] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a test account management method, including: Based on the obtained testing requirements, determine the target testing account to complete the testing requirements; From a test data platform that uses a tree structure to store at least one test account, find candidate test accounts in the tree structure that have an inheritance relationship with the target test account; Based on the testing requirements, a first set of steps required to create the target test account is determined; wherein, the first set of steps includes the steps required to create the target test account; Obtaining the candidate test account includes a second set of steps; wherein, the second set of steps includes the steps required to create the candidate test account; The target test account is created based on at least one of the first step set and the second step set.

[0005] Secondly, embodiments of this application provide a test account management device, comprising: The first determining module is used to determine the target test account for completing the test requirements based on the obtained test requirements; The first search module is used to search for candidate test accounts that have an inheritance relationship with the target test account in the tree structure of the test data platform that stores at least one test account in a tree structure. The second determining module is used to determine, based on the testing requirements, a first set of steps required to create the target test account; wherein the first set of steps includes the steps required to create the target test account; The first acquisition module is used to acquire the second set of steps included in the candidate test account; wherein, the second set of steps includes the steps required to create the candidate test account; The first creation module is used to create the target test account based on at least one of the first step set and the second step set.

[0006] Thirdly, embodiments of this application provide a computer storage medium storing executable instructions, which, when executed by a processor, implement the test account management method provided in embodiments of this application.

[0007] The embodiments of this application have the following beneficial effects: After obtaining the test requirements, the target test account for fulfilling the test requirements is obtained, and candidate test accounts with inheritance relationships with the target test account are searched from the test data platform that stores at least one test account in a tree structure. In this way, after obtaining the test requirements, the candidate test accounts with inheritance relationships are searched from the test data platform first, which can greatly improve the efficiency of automated testing. Then, based on the candidate test accounts, the target test account is created by combining the set of steps required to fulfill the test requirements. In this way, the target test account is created based on the candidate test accounts in the test data platform that stores test accounts in a tree structure, which improves the utilization rate of test accounts in the test data platform. Attached Figure Description

[0008] Figure 1 This is an optional architecture diagram of the test account management system provided in the embodiments of this application; Figure 2A This is another optional architecture diagram of the test account management system provided in the embodiments of this application; Figure 2B This is a schematic diagram of the structure of the test account management system provided in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the implementation process of the test account management method provided in this application embodiment; Figure 4A This is a schematic diagram of another implementation process of the test account management method provided in the embodiments of this application; Figure 4B This is another implementation flowchart of the test account management method provided in the embodiments of this application; Figure 5 This is a schematic diagram of the page of the test account management system provided in the embodiments of this application; Figure 6 This is another schematic diagram of the test account management system provided in the embodiments of this application; Figure 7 This is another schematic diagram of the test account management system provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structural composition of the test account management method implemented in an embodiment of this application; Figure 9 This is a schematic diagram of the composition structure for implementing tag inheritance in an embodiment of this application; Figure 10 This is a schematic diagram of the account application process provided in the embodiments of this application. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0010] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0011] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0012] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0013] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0014] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0015] 1) Dynamic testing method: This method involves running the program under test, checking the differences between the running results and the expected results, and analyzing performance aspects such as running efficiency, correctness, and robustness. This method consists of three parts: constructing test cases, executing the program, and analyzing the program's output.

[0016] 2) Dynamic Testing: The measured quantity changes with time or space, and the instrument's input and test results (data or signals) also change with time. The measurement system is in a dynamic state, and the measurement error is correlated. Dynamic test data contains a large amount of information about the measured physical quantity, the measuring instruments used, and interference from the external environment. Correctly analyzing and processing dynamic test data can yield a lot of useful information reflecting the laws of objective things.

[0017] 3) During testing, testers (or developers) always need to construct various types of test data to meet their needs. The role of the data factory is to provide a unified interface, allowing testers or developers to quickly and easily generate test data, improving testing efficiency. "Quick and easy" means that other testers and developers (not from this business line) can generate the test data they need through simple input, without needing to understand the interface or database design, or construct data by calling interfaces or directly writing to the database. The data factory is just a framework; the business logic (module) for constructing test data needs to be developed by testers from each business line.

[0018] 4) Common Gateway Interface (CGI) is a specification for external programs that run on World Wide Web servers. Programs written using CGI can extend server functionality. CGI applications can interact with browsers and communicate with external data sources such as database servers through data APIs to retrieve data from the database servers.

[0019] 5) Remote Procedure Call (RPC): The principle of system RPC calls is actually very simple. It is similar to a three-tier operating system. A third-party client program calls the system's internal standard or custom functions through an interface, obtains the data returned by the function, processes it, and then displays or prints it. Simply put, it is a node requesting a service provided by another node.

[0020] 6) The design style and development method of web applications (RESTful) are suitable for scenarios where mobile Internet vendors use it as a business enablement interface to enable third parties to provide various application services to users via the Internet (Over The Top, OTT). RESTful refers to the function of calling mobile network resources, and the action type is to add, change or delete the called resources.

[0021] 7) An Application Programming Interface (API) is a set of predefined functions, or an agreement between different components of a software system. Its purpose is to provide applications and developers with the ability to access a set of routines based on certain software or hardware, without needing to access the source code or understand the details of the internal workings.

[0022] 8) Blockchain: An encrypted, chain-like storage structure for transactions formed by blocks.

[0023] 9) Blockchain Network: A collection of nodes that incorporate new blocks into a blockchain through consensus.

[0024] In related technologies, a test data factory is an archive of existing test accounts. In the R&D testing process, the need for constructing relevant test data is becoming increasingly frequent; over time, both R&D and testing personnel accumulate a certain number of test accounts, leading to fragmented data construction efforts that continue to increase and even result in duplicate data construction. This account usage process easily leads to a lot of dirty data, hindering subsequent use and making maintenance difficult. Furthermore, test data factories cannot dynamically generate test accounts or perform batch attribute settings for them, failing to address issues such as high data preparation thresholds and long processing times.

[0025] To address the aforementioned technical problems, embodiments of this application provide a method, apparatus, device, and storage medium for managing test accounts. This allows for the rapid creation of required test accounts based on needs, and supports the pipelined connection of multiple attribute setting steps to quickly set attributes for test accounts. It also provides the ability to dynamically manage test accounts, including managing data attributes, acquiring and locking test accounts, releasing test accounts, and dynamically expanding test accounts.

[0026] The following describes exemplary applications of the test account management device provided in this application embodiment. The device provided in this application embodiment can be implemented as various types of user devices such as laptops, tablets, desktop computers, set-top boxes, and mobile devices (e.g., mobile phones, portable music players, personal digital assistants, dedicated messaging devices, portable gaming devices), or as a server. Exemplary applications when the device is implemented as a device or server will be described below.

[0027] See Figure 1 , Figure 1This is an optional architecture diagram of the test account management system provided in this application embodiment. To support an exemplary application, firstly, after receiving a test account request sent by client 10, the target test account 101 requested by the test account request is determined, and the target tag 102 of the target test account 101 is obtained in combination with the attribute information of the target test account 101. Candidate tags 103 that have an inheritance relationship with the target tag are searched in the test data platform 12. Then, based on the candidate test accounts 104 to which the candidate tag 103 belongs, the target test account 101 is created in combination with the set of steps required to achieve the test requirement. Finally, the target test account 101 is encrypted and fed back to the user. In this way, the test account with the target tag that already exists in the test data platform is given priority, which can improve the efficiency of automated testing. Moreover, the creation of the target test account based on the candidate test accounts improves the utilization rate of test accounts in the test data platform.

[0028] See Figure 2A , Figure 2A This is another optional architecture diagram of the test account management system provided in the embodiments of this application, including a blockchain network 20 (a server 200 as a native node is shown as an example) and a monitoring system 30 (a device 300 belonging to the monitoring system 30 and its graphical interface 301 are shown as an example), which will be described below.

[0029] Blockchain network 20 is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0030] The type of blockchain network 20 is flexible and diverse, and can be any of the following: public chain, private chain, or consortium chain. Taking a public chain as an example, electronic devices of any business entity, such as user devices and servers, can access the blockchain network 20 without authorization. Taking a consortium chain as an example, after obtaining authorization, the electronic devices (such as devices / servers) under the business entity can access the blockchain network 20, and at this time, they become a special type of node in the blockchain network 20, namely client nodes.

[0031] It should be noted that client nodes may only provide functionality to support business entities in initiating transactions (e.g., for storing data on-chain or querying on-chain data). For the functions of the native nodes of blockchain network 20, such as the sorting function, consensus service, and ledger function described below, client nodes may implement them by default or selectively (e.g., depending on the specific business needs of the business entity). This allows for the maximum migration of business entity data and business processing logic to blockchain network 20, achieving trustworthiness and traceability of data and business processing through blockchain network 20.

[0032] Blockchain network 20 receives data from business entities (e.g.) Figure 2A The client node of the monitoring system 30 shown in the figure (e.g., Figure 2A Transactions submitted by the device 300 (as shown in the diagram) belonging to the monitoring system 30 are executed to update or query the ledger, and various intermediate or final results of the executed transactions are displayed on the device's user interface (e.g., the graphical interface 301 of the device 300).

[0033] The following example illustrates an exemplary application of a blockchain network: a monitoring system connecting to a blockchain network to create a target test account on the chain.

[0034] Device 300 of monitoring system 30 connects to blockchain network 20, becoming a client node of blockchain network 20. Device 300 receives a test account request, and then, based on the target tag of the requested target test account, searches for candidate tags with inheritance relationships in the test data platform. Finally, based on the candidate test accounts to which the candidate tags belong, and combined with the steps required to achieve the test requirement, it creates the target test account. The target test account is then given to server 200 in blockchain network 20 or stored in device 300. If upload logic has been deployed on device 300 or user operations have been performed, device 300 generates a corresponding update / query transaction based on the pending item / synchronization time query request. The transaction specifies the smart contract to be called to implement the update / query operation, as well as the parameters passed to the smart contract. The transaction also carries a digital signature signed by monitoring system 30 (e.g., obtained by encrypting the transaction digest using the private key in monitoring system 30's digital certificate) and broadcasts the transaction to blockchain network 20. The digital certificate can be obtained by monitoring system 30 through registration with certification authority 31.

[0035] When a native node in blockchain network 20 receives a transaction, such as server 200, it verifies the digital signature carried in the transaction. If the digital signature verification is successful, it checks whether the monitoring system 30, as indicated in the transaction, has the necessary transaction permissions. Either verification of the digital signature or the permission verification will cause the transaction to fail. After successful verification, the native node signs its own digital signature (e.g., by encrypting a transaction digest using its private key) and continues broadcasting it within blockchain network 20.

[0036] After receiving a successfully verified transaction, the node with sorting function in the blockchain network 20 fills the transaction into a new block and broadcasts it to the nodes in the blockchain network 20 that provide consensus services.

[0037] In blockchain network 20, nodes providing consensus services conduct a consensus process for new blocks to reach agreement. Nodes providing ledger functionality append the new block to the end of the blockchain and execute the transactions in the new block. For received test account requests, a search is performed based on the inheritance relationship of tags to find candidate tags rooted at the target tag. Based on these candidate tags, a target test account is created. The obtained target test account and synchronization time can be displayed on the graphical interface 301 of device 300.

[0038] Native nodes in blockchain network 20 can read the target article set from the blockchain and present the target article set on the native node's monitoring page. Native nodes can also respond to test account requests, search for candidate tags rooted in the target tag based on the tag inheritance relationship, and create target test accounts based on the candidate tags.

[0039] In practical applications, different functions can be configured for different native nodes of the blockchain network 20. For example, server 200 can be configured with test account management and accounting functions, such as responding to test account requests uploaded by devices. In this case, during a transaction, server 200 receives a test account request sent by device 300, obtains the target tag of the target test account, searches for candidate tags rooted in the target tag based on the tag inheritance relationship, and creates the target test account based on the candidate tags. In this way, the target test account is created based on the existing candidate test accounts, improving the utilization rate of test accounts in the test data platform.

[0040] See Figure 2B , Figure 2B This is a schematic diagram of the structure of the test account management system provided in the embodiments of this application. Figure 2BThe illustrated device 400 includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in device 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2B The general labeled all buses as Bus System 440.

[0041] Processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, digital signal processor, or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0042] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls in some examples.

[0043] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0044] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0045] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0046] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; The network communication module 452 is used to reach other computing devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, wireless compatibility authentication, and Universal Serial Bus (USB), etc. Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., a display screen, a speaker, etc.). The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0047] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2B A test account management server 455 stored in memory 450 is shown. This server can be software in the form of programs and plugins, and includes the following software modules: a first determination module 4551, a first search module 4552, a second determination module 4553, a first acquisition module 4554, and a first creation module 4555. These modules are logically connected and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0048] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the test account management method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0049] The test account management method provided in this application will be described in conjunction with exemplary applications and implementations of the devices provided in the embodiments of this application.

[0050] See Figure 3 , Figure 3 This is a schematic diagram illustrating the implementation flow of the test account management method provided in this application embodiment, combined with... Figure 3 The steps shown are explained.

[0051] Step S301: Based on the obtained test requirements, determine the target test account to complete the test requirements.

[0052] Here, the test requirements can be carried in test account requests sent by other devices, or they can be automatically obtained. For example, a test account request for a target test account can be obtained, carrying the test requirements. Based on these requirements, the target test account to be created can be determined. The test account request can be any request for a target test account. This target test account stores test cases that implement the test requirements; that is, users can obtain the target test account to fulfill the test requirements by logging in to this target test account.

[0053] Step S302: From the test data platform that uses a tree structure to store at least one test account, search for candidate test accounts in the tree structure that have an inheritance relationship with the target test account.

[0054] Here, at least one test account is stored in the test data platform in a tree structure according to different tags, where each test account includes at least one tag.

[0055] In some possible implementations, test requirements are carried in the test account request. When this request is received, the target tags for the target test account are determined. Then, based on the target tags, candidate tags are searched from the test data platform's tree structure to obtain candidate test accounts. The process is as follows: First, obtain a test account request carrying the test requirements. This request can include both the test requirements and target tags. For example, target tags can be pre-defined based on the test requirements and then included in the request. The test account request can be entered by the tester through a webpage or sent to the test data platform from another device. In some possible implementations, upon receiving a test requirement, the tester enters a test account request through a webpage to obtain a target test account capable of fulfilling that requirement. The target test account can be stored on the test data platform. After obtaining the target test account, the tester logs in and uses the corresponding test cases to complete the test requirement.

[0056] Secondly, based on the test requirements and attribute information of the target test account carried in the request, the target tag for the target test account is determined. Here, after receiving the test account request, a target tag can be set for the account based on the attribute information of the target test account carried in the request; where the target tag represents the main function implemented by the test cases included in the target test account. In some possible implementations, the attribute information of the account is determined first, and a tag is set for each test account. This can be achieved through the following steps: First, based on the test requirements carried in the test account request, the attribute information of the target test account is determined; whereby the attribute information of the test account includes at least one of the following: the identity identifier (ID) of the device to which the account belongs, the role of the account, the account's friend information, current session count, attendance data, approval form data, and account occupancy status, etc. In a specific example, the test requirement could be testing customer service-related functions, then the attribute information includes: the ID of the device to which the customer service personnel account belongs, the occupancy status of the customer service personnel and created customer service personnel accounts, etc. Then, the target tag is determined based on the attribute information of the target test account. For example, if the target test account is a customer service personnel account, the main function of the account can be determined from the attribute information of the target test account. This is to test the problems that occur during the customer service process. Therefore, the target tag can be set as customer service personnel.

[0057] Next, from the test data platform, search for candidate tags in the tree structure that have an inheritance relationship with the target tag. Here, inheritance relationship can be understood as finding the parent node of the node to which the target tag belongs as a child node in the tree structure; that is, establish the inheritance relationship between the tags of the test accounts stored in the test data platform according to the tree structure, and find the parent node of the node to which the target tag belongs as a child node from the test data platform. The tags recorded in the parent node are the candidate tags.

[0058] Finally, test accounts with candidate labels are identified as candidate test accounts. For example, test accounts stored in nodes with candidate labels in the tree structure are selected as candidate test accounts.

[0059] Step S303: Based on the testing requirements, determine the set of first steps required to create the target test account.

[0060] Here, the first set of steps includes the steps required to create the target test account. By analyzing the test requirements and combining them with the attribute information of the target test account, the first set of steps required to create the target test account is determined.

[0061] Step S304: Obtain the second set of candidate test accounts.

[0062] Here, the second set of steps includes the steps required to create the candidate test account; obtaining the candidate test account includes the second set of steps and the first set of steps. For example, if the target test account to be created is an account with external contacts in a social application, the required first set of steps includes: create account -> real-name authentication -> set as customer service personnel -> add external contacts in the social application as friends; if the candidate test account is a customer service personnel account, the second set of steps includes: create account -> real-name authentication -> set as customer service personnel.

[0063] Step S305: Create a target test account based on at least one of the first step set and the second step set.

[0064] Here, since the first and second step sets are stored in an inheritance relationship, a target test account can be created by combining different steps from the two step sets based on the second step set. As can be seen from the example above, the first step set has one more step than the second step set. Therefore, the target test account can be obtained by concatenating this extra step based on the second step set. In this way, the target test account is created based on the existing candidate test accounts, which improves the utilization rate of test accounts in the test data platform.

[0065] In some embodiments, in order to set the inheritance relationship between tags of test accounts, the method further includes the following steps before step S303, see below. Figure 4A , Figure 4A This is another implementation flowchart of the test account management method provided in the embodiments of this application, combined with Figure 3 The steps shown are explained below: Step S401: Obtain multiple used test accounts.

[0066] Here, multiple used test accounts can be test accounts created by multiple testers, or test accounts created by the same tester.

[0067] Step S402: Based on the attribute information of each used test account, set the used tag for each used test account.

[0068] In some possible implementations, the main function of a test account is determined by the attribute information of the account already in use, and the account's used tags are set accordingly.

[0069] Step S403: Based on the association between the third step set including multiple used test accounts, set the inheritance relationship between the used tags corresponding to the third step set.

[0070] Here, the third set of steps includes the steps required to create a used test account. Based on this relationship, an inheritance relationship is established between the used tags corresponding to multiple third set of steps, following a tree structure. For example, there are three used test accounts: a customer service account, an account with external contacts on the social application, and an account with a group of people who have external contacts on the social application; where: The third step in setting up a customer service representative account is: create an account -> real-name authentication -> set as a customer service representative; The third set of steps to having an external contact account on a social application is: create an account -> real-name authentication -> set up as a customer service representative -> add external contact friends on the social application; The third set of steps to having an account with external contacts on a social application is: create an account -> real-name authentication -> set up as a customer service representative -> add external contacts as friends on the social application -> create an external group chat on the social application -> invite external contacts as friends to the group; In some possible implementations, the inheritance relationship between tags can be set according to the sequential order of the steps in the execution sequence, which can be achieved through the following process: First, based on the association between the sets of third steps included in each used test account, determine the sequential relationship of execution among the sets of third steps.

[0071] For example, the order of execution of the third step set, which includes customer service personnel accounts, accounts with external contacts on social applications, and accounts with external contacts on social applications, is as follows: customer service personnel accounts, accounts with external contacts on social applications, and accounts with external contacts on social applications.

[0072] Then, according to the aforementioned sequence, the sets of steps for multiple used test accounts are sorted to obtain the sorting result.

[0073] For example, the three accounts mentioned above can be ordered in the following order: customer service personnel account, account with external contacts on social applications, and account with external contacts on social applications.

[0074] Finally, based on the sorting results, the inheritance relationship between the used tags corresponding to the step set is set.

[0075] First, the used tags corresponding to the set of steps in a specific position in the sorted results are assigned to the root node; for example, if the sorted results are arranged in ascending order of execution, the used tags of the first set in the sorted results are assigned to the root node. Then, the used tags corresponding to the next set of steps in the set to which the root node belongs are assigned to the child nodes of the root node; for example, the used tags of the second set of steps are assigned to the child nodes of the root node. Finally, the set of steps that were executed last in the sorted results is assigned to the leaf nodes of the child nodes to establish the inheritance relationship. For example, since the sorted results are arranged in the order of execution, the last set of steps is the most complex step combination, so the used tags corresponding to the last set of steps in the sorted results are assigned to the leaf nodes; this establishes the inheritance relationship between tags of multiple accounts.

[0076] Taking the above example, the relationship between the customer service account, the account with external contacts on the social application, and the group account with external contacts on the social application is that the account with external contacts on the social application adds one step on top of the customer service account; the group account with external contacts on the social application adds two steps on top of the account with external contacts on the social application. Based on this relationship, according to the tree structure, it is determined that the customer service account should be the root node among these three accounts. Then, the node to which the account with external contacts on the social application belongs is the child node of the root node to which the customer service account belongs. Finally, the node to which the group account with external contacts on the social application belongs is the leaf node of the node to which the account with external contacts on the social application belongs. In this way, the inheritance relationship between the tags of multiple accounts is established.

[0077] Step S404: Store the inheritance relationship, multiple used test accounts, and the used tags of each used test account in the test data platform.

[0078] Here, all account-related information is stored in the test data platform, which provides a unified interface for testers using the platform, making it easy to access the platform and use the created accounts.

[0079] In this embodiment of the application, the inheritance relationship between the tags of these used test accounts, multiple used test accounts and the used tags of each used test account are stored in the test data platform, which facilitates the rapid use of the platform in automated testing scenarios such as protocol testing, user interface automated testing, and unit testing.

[0080] In some embodiments, to improve the utilization rate of test accounts, based on candidate test accounts with inherited tags, the steps required to fulfill the test requirements are chained together to create a target test account. Step S303 can be implemented in various ways: Method 1: See Figure 4B , Figure 4B This is another implementation flowchart of the test account management method provided in the embodiments of this application, combined with Figure 3 The steps shown are explained below: Step S421: Find the tag that is the same as the target tag from the test data platform.

[0081] Here, the tag that is the same as the target tag can be a tag of a test account that was used last time on the device that made the request, or it can be a tag that has not been used on the device but is the same as the target tag.

[0082] Step S422: If the test data platform includes a tag that is the same as the target tag, and the test account to which the tag that is the same as the target tag belongs is in an unoccupied state.

[0083] Here, if the test account belonging to the same tag as the target tag is in an idle state, it means that the test account is currently available.

[0084] Step S423: Select the tag that is the same as the target tag as the candidate tag.

[0085] Steps S421 to S423 above provide a method for "finding candidate tags in the tree structure that have an inheritance relationship with the target tag from the test data platform". In this method, after receiving a test account request, the system first searches for used test accounts with the target tag from the test data platform. If the test data platform includes tags that are the same as the target tag, the tags that are the same as the target tag are used as candidate tags.

[0086] Step S424: Select the candidate test accounts with candidate tags as target test accounts.

[0087] Here, the test account corresponding to the candidate tag is directly used as the target test account, without the need to create a new target test account. In this way, the test account already used in the test data platform for the target tag is given priority, which can greatly improve the efficiency of automated testing.

[0088] Method 2: After step S421, if the test account belonging to the same tag as the target tag is occupied, or the test data platform does not include tags with the same tag as the target tag, candidate tags can be determined through the following steps: The first step is to determine the parent target node from the tree structure of the test platform if the test account to which the target tag belongs is occupied, or if the test data platform does not contain the same tag as the target tag.

[0089] Here, if the test account belonging to the same tag as the target tag is in use, or if the test data platform does not include a used test account belonging to the target tag, it means that there is currently no test account available for this test requirement. In this case, the parent node of the node to which the target tag belongs is found in the tree structure of the test data platform to obtain the parent target node.

[0090] The second step is to search for tags in the tree structure that are the same as the tags stored on the parent target node, in order to obtain candidate tags.

[0091] Here, tags that are the same as the tags stored on the parent target node are searched from the tags stored on the test data platform to obtain candidate tags.

[0092] The third step is to determine the candidate tag as a candidate tag if the test account to which the candidate tag belongs is not occupied.

[0093] When there are no available accounts for the target tag, the system will search based on the inheritance relationship of the target tag, searching for parent nodes with the target tag as a child node, which can greatly improve the utilization rate of test accounts.

[0094] The first to third steps described above achieve the goal of "finding candidate tags that have an inheritance relationship with the target tag from the test data platform that stores tags of at least one test account". By searching for candidate tags that have a storage inheritance relationship with the target tag in the data platform that stores used test accounts, the priority allocation of the target tag to the account already used in the test data platform can greatly improve the efficiency of automated testing.

[0095] The fourth step is to determine the different steps between the first set and the second set.

[0096] Here, since the node of the candidate label to which the second step set belongs is the parent node of the target label, the steps contained in the first step set overlap with the steps contained in the second step set. For example, the first step set contains more steps than the second step set. For instance, if the second step set contains 5 steps, then the first step set, in addition to containing 5 steps, also includes a 6th step.

[0097] The fifth step involves performing different steps based on the candidate test accounts to create the target test account.

[0098] Here, the portion of the first set of steps that exceeds the second set of steps is chained into the second set of steps and executed to create the target test account. For example, if the second set of steps includes 5 steps, then the first set of steps, in addition to including 5 steps, also includes a 6th step. This 6th step is then chained into the second set as the last step and executed to create the target test account.

[0099] In some embodiments, after performing the second step above, "finding a tag in the tree structure that is the same as the tag stored on the parent target node", if no candidate tag with an inheritance relationship with the target tag can be found in the test data platform, or if the test account to which the candidate tag belongs is occupied, then a target test account that can fulfill the test requirement is dynamically created according to the content of the test requirement. The target test account can be created through the following process: First, if the tree structure does not include the candidate tag, or the test account to which the candidate tag belongs is occupied, obtain the first step set for fulfilling the test requirements and the attribute information of the target test account.

[0100] Here, if there are no available test accounts in the test data platform that can be used to fulfill the test requirement, and there are no tags with an inheritance relationship with the target test account, then the target test account will be created automatically. First, the set of first steps required to create the target test account and the attribute information of the target test account are obtained. For example, creating the target test account requires 5 steps, and the target test account includes: the ID of the device to which it belongs, the role of the account, the account's friend information, the current number of sessions, attendance data, approval form data, and the account's occupancy status, etc.

[0101] Secondly, based on the attribute information of the set from the first step and the target test account, create the target test account.

[0102] Here, the attribute information is carried into the corresponding step in the first step set to create the target test account; in this way, if the test data platform does not include nodes that have an inheritance relationship with the node of the target tag, the target test account will be automatically created, thereby reducing the situation where other processes are blocked due to insufficient test accounts.

[0103] In some embodiments, after creating a target test account, the target test account is locked and notified to the user. After use, the test account is released so that other users can use the account. This can be achieved through the following steps: First, encrypt the target test account and then return the encrypted target test account.

[0104] Here, the target test account is locked to prevent other users from using the encrypted target test account, thereby ensuring that the encrypted target test account is currently not used by other users.

[0105] Then, when an instruction indicating that the encrypted target test account has been used up is received, the encrypted target test account is decrypted.

[0106] Here, after the current user finishes using the encrypted target test account, the encrypted target test account is decrypted, that is, the target test account is released and stored in the test data platform so that other users can reuse it, thereby improving the utilization rate of the test account.

[0107] The following will illustrate an exemplary application of the embodiments of this application in a real-world application scenario, taking the dynamic generation and management of test accounts on a data platform as an example: In related technologies, test data factory platforms are basically archives of existing test accounts. First, because data needs to be generated one by one according to requirements and attributes need to be set for accounts through complex steps, the data preparation threshold is high. Second, because some test accounts have passing attributes, they cannot be effectively reused, resulting in low data utilization. Finally, because account attributes and account usage cannot be effectively managed, data maintenance costs are high.

[0108] Based on this, this application implements a dynamically generated and managed test data factory platform, enabling quick, convenient, standardized, and systematic construction and maintenance of test data. It possesses the following features: First, it encapsulates commonly used test data attribute setting units and supports the pipelined connection of these units, covering the needs for test accounts and data in common scenarios, thus achieving rapid data construction; second, it manages test accounts by tag dimension, supports tag inheritance, improves the reusability of test accounts, and achieves tag-based account management; third, the platform can obtain static and dynamic attributes of accounts, supports secondary processing of pre-constructed data, and supports dynamically expanding account attributes and the number of accounts to achieve dynamic account attribute management; finally, it provides a simple, user-friendly web interface, allowing any role member to quickly construct and obtain test accounts, thereby enabling rapid use of the platform in automated testing scenarios such as protocol testing, user interface automated testing, and unit testing.

[0109] This application provides a concise web page that facilitates rapid data construction and management for team members in various roles. On the product side, it generally appears as follows: Figure 5 As shown, Figure 5 This is a schematic diagram of the page of the test account management system provided in the embodiments of this application, combined with Figure 5 The following explanation is provided: On operation page 501, the menu bar includes: My Enterprise 502, Data Construction 503, Task List 504, Advanced Mode 505, Q&A Documentation 506, Location Tool 507, Operation Instructions 508, and API Documentation 509. The enterprise list for the test accounts used to draw this business includes: Administrator Name 511, Administrator VID 512, Company Name 513, Company ID 514, Company Size 515, Mobile Number 516, Validity Period 517, and Operation 518. Each row in this list represents a test account, meaning that operation page 501 displays a total of 8 test accounts. Taking an enterprise social application scenario as an example, operation page 501 displays the list of test accounts.

[0110] Figure 6 This is another page illustration of the test account management system provided in the embodiments of this application, combined with... Figure 6 The following explanation is provided: In the data construction page 601, the menu bar includes: My Enterprise 502, Data Construction 503, Task List 504, Advanced Mode 505, Questions & Answers (Q&A) Documentation 506, Location Tool 507, Operation Instructions 508, and API Documentation 509. When a tester selects Data Construction 503, an editable window is displayed in area 602 to set the attributes of a test account, including: Creation Content 611, Enterprise Name 612, Administrator Name 613, Number of Members 614, Number of Departments 615 (limited to a maximum of 5,000 new department members), Mobile Phone Number 616 (optional, used for login in new enterprises; defaults to test accounts if not filled in), Number of Login Accounts 617 (default mobile phone number assigned; can log in directly using data number and verification code, maximum 10 people), and Purpose 618 (limited to creating more than 100,000 enterprises, operating more than 1,000 VIDs, and Enterprise Identifier). When the number of Identity (corpid) exceeds 50, a fault notification will be sent to the background fault group. In this way, you can enter the corresponding content in each editable box to set the attributes of the test account; for example, in the content creation 611, you can select the commonly used items that have been set (such as creating an enterprise 621, creating an internal group chat 622, creating an external group chat 623, sending a message 624, adding friends 625, and setting up applications 626, etc.), or you can customize the input.

[0111] Here, page 601, which constructs data, covers the ability to construct high-frequency account requirements in enterprise social application testing scenarios. Through simple selection and parameter passing on the page, test accounts and data can be created, and batch attribute settings can be made for test accounts.

[0112] Figure 7 This is another page illustration of the test account management system provided in the embodiments of this application, combined with... Figure 7 The following explanation is provided: In the advanced mode operation page 701, the menu bar includes: My Enterprise 502, Data Construction 503, Task List 504, Advanced Mode 505, Q&A Documentation 506, Location Tool 507, Operation Instructions 508, and API Documentation 509. When testers select advanced mode 505, area 702 provides support for users to call the platform's interfaces to customize test accounts, as well as to connect complex steps such as test account generation and test account attribute settings, thereby facilitating rapid account expansion.

[0113] Figure 8 This is a schematic diagram of the structural composition of the test account management method implemented in this application embodiment, as shown below. Figure 8 As shown, the method includes the following modules: a simple human-computer interaction web page 801, a tag management module 802, an attribute setting unit 803, an account attribute management module 804, an account usage management module 805, tag and account storage 806, and an open RESTful API 807, wherein: The 801 web page features a simple human-computer interaction interface, providing testers with a way to input commands and engage in human-computer interaction.

[0114] The tag management module 802 is used to manage test accounts by tag.

[0115] Here, the tag management module 802 provides the following two core capabilities: First, define labels and set information such as label name, inheritance relationship, purpose, and remarks.

[0116] Second, define the method for generating account attributes corresponding to tags. For example, whether to directly create a target test account based on the target tag, or to obtain the target test account by connecting subsequent steps based on an existing test account.

[0117] This application's embodiments abstract certain attributes of test accounts into tag concepts. A test account can have multiple tags, and these tags have inheritance relationships. This means that test accounts can be used based on tag inheritance relationships to improve their utilization rate. Furthermore, the account generation and attribute setting methods also have inheritance relationships, further improving account generation efficiency.

[0118] Here, as Figure 9 As shown, Figure 9 This is a schematic diagram of the structural composition of tag inheritance implemented in an embodiment of this application. Figure 9Taking the "External Contacts" tag of enterprise social applications as an example, the account labeled "Customer Service Personnel 901" is used as the root node. The child nodes of this tag include: "Having External Contacts in Social Applications 902" and "Having External Enterprise Contacts 903". Among them, "Having External Contacts in Social Applications 902" is used as the leaf node "Having External Contacts in Social Applications 904".

[0119] In a specific example, suppose there are 10 accounts each of four types: customer service personnel, accounts with external contacts on social applications, accounts with external corporate contacts, and accounts with external contact groups on social applications. In the test account management system provided in this application embodiment, if a customer service personnel account is to be used, the account attributes are abstracted into tags, and their inheritance relationships are defined. Since the tags for external contacts on social applications, external corporate contacts, and external contact groups on social applications are all directly or indirectly inherited from the customer service personnel tag, there are 40 available test accounts when obtaining the customer service personnel tag, thus greatly improving the utilization rate of test accounts.

[0120] The attribute setting unit 803 is used to set attributes for each test account through calls between interfaces.

[0121] Based on business needs, this application encapsulates and provides commonly used account attribute setting units during development, testing, and user experience. These account attribute setting units implement attribute settings through business open interfaces 808, business private CGI 809, business backend RPC 810, and business backend tools 811. It also supports a pipelined approach, connecting multiple attribute setting units to achieve complex attribute settings. Furthermore, leveraging the inheritable nature of tags in this application, attribute setting methods are also inheritable. For example: The steps to create a customer service representative account include: Create account -> Real-name authentication -> Set as customer service representative; The steps to create an account with external contacts on social apps include: create an account -> real-name authentication -> set up as a customer service representative -> add external contacts on social apps as friends; The steps to create an account with external contacts on a social application include: create an account -> real-name authentication -> set it as a customer service representative -> add external contacts on the social application as friends -> create an external group chat on the social application -> invite external contacts on the social application to the group; Therefore, generating test accounts with external contacts on social applications involves numerous and complex steps. However, in this embodiment, the creation process of test data, like tags, has an inheritance relationship. Thus, accounts with external contacts on social applications can be created by adding two steps to the existing accounts with external contacts: "Create a social application external group chat -> Invite external contacts to the group." This significantly improves the maintainability and efficiency of account generation attribute settings.

[0122] The account attribute management module 804 is used to create and store test accounts.

[0123] Here, in this embodiment of the application, based on the inheritance relationship between account tags, the target test account is obtained by chaining the steps that occur after the steps included in the used test account in the target test account, based on the already used test account, which further improves the efficiency of account use and testing.

[0124] In some possible implementations, the test account application process is as follows: Figure 10 As shown, Figure 10 This is a schematic diagram of the account application process provided in the embodiments of this application, combined with Figure 10 The steps shown are explained below: Step S1001: Obtain a test account request.

[0125] Here, the request contains the target tag and device ID of the target test account to be requested; in some possible implementations, when using a system page or API to obtain a test account request, the required account tag and a device ID used to identify the device are passed.

[0126] Step S1002: Determine whether the target tag is consistent with the tag used on the device last time, based on the device ID in the request.

[0127] In some possible implementations, the system first identifies whether the tag of the test account previously applied for by the ID is consistent with the target tag of this application. If they are consistent, the target tag is consistent with the tag used on the device last time, and the tag used on the device last time is determined as a candidate tag, and the process proceeds to step S1003; otherwise, the process proceeds to step S1005.

[0128] Step S1003: Determine whether the test account used on the device last time has been occupied.

[0129] Here, it is determined whether the test account corresponding to the candidate label has been used, and whether the account used last time on the device has been occupied by another ID. If it has not been occupied, proceed to step S1004; if it has been occupied, proceed to step S1005.

[0130] Step S1004: Obtain the static and dynamic attributes of the candidate account, lock the account, and return it to the user.

[0131] Here, static attributes include: account ID, role, some friends of the account, etc.; dynamic attributes include: current session count, attendance data, approval form data, and test account usage, etc., which are data that may change at any time.

[0132] Step S1005: Determine if there is an idle test account containing the target tag.

[0133] Here, we check if there is an idle test account for the target tag. If there is an idle test account, we proceed to step S1004, which is to obtain the static and dynamic attributes of the account, lock the account, and return it to the user; otherwise, we proceed to step S1006.

[0134] Step S1006: Determine the tags of the parent nodes that have an inheritance relationship with the target tag, and whether there are any idle test accounts.

[0135] Here, based on the inheritance attributes of the tag, the inheritance tree rooted at the target tag is searched. If an idle account exists, proceed to step S1004, which retrieves the static and dynamic attributes of the account, locks the account, and returns it to the user; otherwise, proceed to step S1007.

[0136] Step S1007: Dynamically create the target test account based on the attribute information.

[0137] Here, after dynamically creating the target test account, step S1004 is taken, which involves obtaining the static and dynamic attributes of the target test account, locking the account, and returning it to the user.

[0138] The account management module 805 is used to lock the created target test account and provide feedback to the user. When the user is finished using the account, the target test account is released so that other users can use it.

[0139] Tag and account storage 806, which stores tags, inheritance relationships between tags, and test accounts on the data platform.

[0140] The open RESTful API 807 provides a complete and rich set of API interfaces, enabling rapid use of the platform's capabilities in automated testing scenarios such as protocol testing, user interface (UI) automated testing, and unit testing.

[0141] In automated testing scenarios such as protocol testing, UI automation testing, and unit testing, significant account switching overhead occurs when different accounts are assigned each time. This embodiment prioritizes assigning the last used account for a given ID when acquiring test accounts, greatly improving automated testing efficiency. Furthermore, when applying for test accounts, if no available accounts are available for a target tag, a search is performed based on the target tag's inheritance relationship, searching the inheritance tree rooted at the target tag, which significantly improves test account utilization. Simultaneously, if no available accounts are found, test accounts are automatically created, reducing the likelihood of other processes being blocked due to insufficient test accounts.

[0142] The following description continues to illustrate the exemplary structure of the test account management server 455 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2B As shown, the software modules stored in the test account management server 455 in the memory 450 may include: The first determining module 4551 is used to determine the target test account for completing the test requirements based on the obtained test requirements. The first search module 4552 is used to search for candidate test accounts that have an inheritance relationship with the target test account in the tree structure of the test data platform that stores at least one test account in a tree structure. The second determining module 4553 is used to determine, based on the testing requirements, a first set of steps required to create the target test account; wherein the first set of steps includes the steps required to create the target test account; The first acquisition module 4554 is used to acquire the second set of steps included in the candidate test account; wherein, the second set of steps includes the steps required to create the candidate test account; The first creation module 4555 is used to create the target test account based on at least one of the first step set and the second step set.

[0143] In some embodiments, the first determining module 4551 is further configured to: determine the attribute information of the target test account according to the test requirements; determine the target tag according to the attribute information of the target test account; correspondingly, search for candidate tags in the tree structure that have an inheritance relationship with the target tag from the test data platform; and determine the test account with the candidate tag as the candidate test account.

[0144] In some embodiments, the first lookup module 4552 is further configured to: obtain multiple used test accounts; set a used tag for each used test account according to the attribute information of each used test account; set an inheritance relationship between the used tags corresponding to the third step set according to the tree structure based on the association relationship between the multiple used test accounts and the third step set; and store the inheritance relationship, the multiple used test accounts, and the used tags of each used test account in the test data platform.

[0145] In some embodiments, the first lookup module 4552 is further configured to: determine the sequential relationship in execution time among the third step sets of each used test account based on the association relationship among the third step sets included in each used test account; sort the third step sets of multiple used test accounts according to the sequential relationship to obtain a sorting result; and set the inheritance relationship between the used tags corresponding to the third step sets according to the tree structure based on the sorting result.

[0146] In some embodiments, the first search module 4552 is further configured to: assign the used label corresponding to the set of steps arranged at a specific position in the sorting result to the root node of the tree structure; assign the used label corresponding to the next set of steps to which the root node belongs to the child node of the root node; and assign the set of steps that were last executed in the sorting result to the leaf node of the child node to obtain the inheritance relationship.

[0147] In some embodiments, the first search module 4552 is further configured to: search for a tag that is the same as the target tag from the test data platform; if the test data platform includes a tag that is the same as the target tag, and the test account to which the tag that is the same as the target tag belongs is in an unoccupied state; and use the tag that is the same as the target tag as the candidate tag; Correspondingly, the first creation module 4555 is further configured to: determine the candidate test accounts that include the set of the second step and have the candidate tags as the target test accounts.

[0148] In some embodiments, the first search module 4552 is further configured to: if the test account to which the tag identical to the target tag belongs is occupied, or the test data platform does not include a tag identical to the target tag, determine the parent node with an inheritance relationship with the node to which the target tag belongs from the tree structure of the test platform to obtain the parent target node; search for a tag identical to the tag stored on the parent target node from the tree structure to obtain the candidate tag; if the test account to which the candidate tag belongs is unoccupied, determine the candidate tag as a candidate tag.

[0149] In some embodiments, the first creation module 4555 is further configured to: determine the different steps between the first set of steps and the second set of steps; and, based on the candidate test account, perform the different steps to create the target test account.

[0150] In some embodiments, the first search module 4552 is further configured to: if the tree structure does not include the candidate tag, or the test account to which the candidate tag belongs is occupied, obtain a first set of steps for creating the target test account and attribute information of the target test account; and create the target test account according to the first set of steps and attribute information of the target test account.

[0151] In some embodiments, the first creation module 4555 is further configured to: encrypt the target test account and return the encrypted target test account; and decrypt the encrypted target test account when receiving an instruction indicating that the encrypted target test account has been used up.

[0152] This application provides a storage medium storing executable instructions, wherein the executable instructions, when executed by a processor, will cause the processor to perform the method provided in this application. In some embodiments, the storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories. In some embodiments, the executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. As an example, the executable instructions may, but do not necessarily, correspond to a file in a file system, and may be stored as part of a file that stores other programs or data, for example, stored in one or more scripts in a Hyper Text Markup Language (HTML) document, stored in a single file dedicated to the program in question, or stored in multiple co-located files (e.g., a file storing one or more modules, subroutines, or code portions). As an example, executable instructions can be deployed to execute on a single in-vehicle computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network. In summary, this application embodiment, upon receiving a test account request, searches for candidate tags with inheritance relationships in the test data platform based on the target tag of the requested target test account; then, based on the candidate test accounts to which the candidate tags belong, and combining the set of steps required to achieve the test requirement, it creates the target test account. This prioritizes the allocation of test accounts already used by the target tag in the test data platform, which can greatly improve the efficiency of automated testing; moreover, creating the target test account based on the candidate test accounts in the test data platform improves the utilization rate of test accounts in the test data platform. The above descriptions are merely embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for managing test accounts, characterized in that, The method includes: Based on the testing requirements in the test account request, determine the target test account to complete the testing requirements; Based on the testing requirements, determine the attribute information of the target test account; Based on the attribute information of the target test account, determine the target tags; If, based on the device ID in the test account request, it is determined that the target tag is consistent with the tag used on the device last time, and the test account to which the tag used on the device last time belongs is not occupied, then the test account to which the tag used on the device last time belongs is determined as the target test account; if the target tag is inconsistent with the tag used on the device last time, or the test account to which the tag used on the device last time belongs is occupied, then the following steps are performed: From a test data platform that uses a tree structure to store at least one test account, search for candidate tags in the tree structure that have an inheritance relationship with the target tag; Test accounts with the aforementioned candidate tags are identified as candidate test accounts; Based on the testing requirements, a first set of steps required to create the target test account is determined; wherein, the first set of steps includes the steps required to create the target test account; the steps in the first set of steps implement attribute settings through business open interfaces, business private public gateway interfaces, business backend remote procedure calls or business backend tools, and multiple steps are connected in a pipeline manner to achieve complex attribute settings; Obtaining the candidate test account includes a second set of steps; wherein, the second set of steps includes the steps required to create the candidate test account; Based on the candidate test accounts, the steps that differ between the first set of steps and the second set of steps are executed to create the target test account; If the tree structure does not include candidate tags, or the test account to which the candidate tag belongs is occupied, the target test account is created according to the first step set and the attribute information of the target test account. The target test account is encrypted, and the encrypted target test account is returned; when an instruction indicating that the encrypted target test account has been used up is received, the encrypted target test account is decrypted.

2. The method according to claim 1, characterized in that, Before searching for candidate tags in the tree structure that have an inheritance relationship with the target tag, the method further includes: Obtain multiple used test accounts; Based on the attribute information of each used test account, set a used tag for each used test account; Based on the association between the third step sets including multiple used test accounts, the inheritance relationship between the used tags corresponding to the third step sets is set according to the tree structure; wherein, the third step set includes the steps required to create the used test accounts; The inheritance relationship, the multiple used test accounts, and the used tags of each used test account are stored in the test data platform.

3. The method according to claim 2, characterized in that, The step of setting the inheritance relationship between the used tags corresponding to the third step set according to the tree structure, based on the association relationship between the third step set including multiple used test accounts, includes: Based on the association between the sets of third steps included in each of the used test accounts, determine the sequential relationship in execution time between the sets of third steps of each of the used test accounts. According to the aforementioned sequence, the third step set of multiple used test accounts is sorted to obtain the sorting result; Based on the sorting results, the inheritance relationship between the used tags corresponding to the third step set is set according to the tree structure.

4. The method according to claim 3, characterized in that, The step of setting the inheritance relationship between the used tags corresponding to the third step set according to the sorting result and the tree structure includes: The used labels corresponding to the set of steps arranged at specific positions in the sorting results are assigned to the root node of the tree structure. Assign the used label corresponding to the next step set of the step set to which the root node belongs to the child node; The set of steps that were last executed in the sorting result is assigned to the leaf node of the child node to obtain the inheritance relationship.

5. The method according to any one of claims 1 to 4, characterized in that, The process of finding candidate tags in the tree structure that have an inheritance relationship with the target tag includes: From the test data platform, find tags that are the same as the target tag; If the test data platform includes tags that are the same as the target tag, and the test account to which the tag that is the same as the target tag belongs is in an unoccupied state; The tags that are the same as the target tag are used as candidate tags; Correspondingly, creating the target test account includes: Candidate test accounts with the aforementioned candidate tags are identified as the target test accounts.

6. The method according to claim 5, characterized in that, The process of finding candidate tags in the tree structure that have an inheritance relationship with the target tag includes: If the test account to which the tag that is the same as the target tag belongs is in a state of being occupied, or if the test data platform does not include a tag that is the same as the target tag, determine the parent node that has an inheritance relationship with the node to which the target tag belongs from the tree structure of the test data platform, and obtain the parent target node; From the tree structure, search for tags that are the same as the tags stored on the parent target node to obtain candidate tags; If the test account to which the candidate tag belongs is in an unoccupied state, the candidate tag is determined to be a candidate tag.

7. A test account management device, characterized in that, The device includes: The first determining module is used to determine the target test account for completing the test requirements based on the test requirements in the test account request; The first determining module is further configured to determine the attribute information of the target test account based on the test requirements; Based on the attribute information of the target test account, determine the target tags; The account attribute management module is used to determine the test account to which the last used tag belongs is the target test account if, based on the device ID in the test account request, the target tag is consistent with the tag used on the device last time, and the test account to which the tag used on the device last time belongs is not occupied; if the target tag is inconsistent with the tag used on the device last time, or the test account to which the tag used on the device last time belongs is occupied, the following steps are performed: The first search module is used to search for candidate tags in the tree structure that have an inheritance relationship with the target tag from the test data platform that uses a tree structure to store at least one test account; Test accounts with the aforementioned candidate tags are identified as candidate test accounts; The second determining module is used to determine, based on the test requirements, a first set of steps required to create the target test account; wherein, the first set of steps includes the steps required to create the target test account; the steps in the first set of steps implement attribute settings through business open interfaces, business private public gateway interfaces, business backend remote procedure calls, or business backend tools, and multiple steps are connected in a pipeline manner to achieve complex attribute settings; The first acquisition module is used to acquire the second set of steps included in the candidate test account; wherein, the second set of steps includes the steps required to create the candidate test account; The first creation module is used to create the target test account by executing steps different from those in the first set of steps and the second set of steps, based on the candidate test accounts; if the tree structure does not include candidate tags, or the test account to which the candidate tag belongs is occupied, the target test account is created according to the attribute information of the first set of steps and the target test account; the target test account is encrypted and the encrypted target test account is returned; when an instruction indicating that the encrypted target test account has been used is received, the encrypted target test account is decrypted.

8. The apparatus according to claim 7, characterized in that, The first search module is also used to obtain multiple used test accounts; Based on the attribute information of each used test account, set a used tag for each used test account; Based on the association between the third step sets including multiple used test accounts, the inheritance relationship between the used tags corresponding to the third step sets is set according to the tree structure; wherein, the third step set includes the steps required to create the used test accounts; The inheritance relationship, the multiple used test accounts, and the used tags of each used test account are stored in the test data platform.

9. The apparatus according to claim 8, characterized in that, The first search module is further configured to determine the sequential relationship in execution time between the sets of third steps of each used test account based on the association relationship between the sets of third steps included in each of the used test accounts. According to the aforementioned sequence, the third step set of multiple used test accounts is sorted to obtain the sorting result; Based on the sorting results, the inheritance relationship between the used tags corresponding to the third step set is set according to the tree structure.

10. The apparatus according to claim 9, characterized in that, The first search module is further configured to assign the used labels corresponding to the set of steps arranged in a specific position in the sorting result to the root node of the tree structure; Assign the used label corresponding to the next step set of the step set to which the root node belongs to the child node; The set of steps that were last executed in the sorting result is assigned to the leaf node of the child node to obtain the inheritance relationship.

11. The apparatus according to any one of claims 7 to 10, characterized in that, The first search module is further configured to search for a tag that is the same as the target tag from the test data platform; If the test data platform includes tags that are the same as the target tag, and the test account to which the tag that is the same as the target tag belongs is in an unoccupied state; The tags that are the same as the target tag are used as candidate tags; The first creation module is further configured to identify the candidate test account with the candidate tag as the target test account.

12. The apparatus according to claim 11, characterized in that, The first search module is further configured to determine, from the tree structure of the test data platform, the parent node that has an inheritance relationship with the node to which the target tag belongs if the test account to which the tag is the same as the target tag is occupied, or if the test data platform does not include a tag to which the target tag is the same as the target tag, and obtain the parent target node. From the tree structure, search for tags that are the same as the tags stored on the parent target node to obtain candidate tags; If the test account to which the candidate tag belongs is in an unoccupied state, the candidate tag is determined to be a candidate tag.

13. A device for testing account management, characterized in that, include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the method according to any one of claims 1 to 6.

14. A computer storage medium, characterized in that, It stores executable instructions for causing a processor to execute, thereby implementing the method of any one of claims 1 to 6.

Images