Packaging and nesting methods for test steps, head-mounted display devices, and media

Abstract

Embodiments of the present disclosure disclose a packaging and nesting method of test steps, a head-mounted display device and a medium. A specific implementation of the method comprises: performing parsing processing on original operation data to obtain an operation type; performing packaging processing on the original operation data according to the operation type to obtain standardized test steps; generating an initial test case according to a target case template and the obtained standardized test steps; generating a composite step node according to the initial test case and a preset nesting condition; performing updating processing on a step sequence of a target test case based on the composite step node to obtain a hierarchical nested case; and in response to detecting an execution instruction corresponding to the hierarchical nested case, generating a to-be-executed step sequence according to the hierarchical nested case. The implementation reduces the waste of storage resources and computing resources, shortens the time-consuming of case maintenance, and improves the reusability of test cases and the test execution efficiency.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of virtual vision technology, specifically to methods for encapsulating and nesting test steps, head-mounted display devices, and media. Background Technology

[0002] In the field of automated testing for augmented reality devices (e.g., VR glasses), test cases typically consist of multiple operational steps (e.g., gesture recognition, voice commands, interface interactions, etc.) to verify the functional correctness of the augmented reality device system. Currently, the common methods for managing test steps are linear step-based test cases or script-level reuse.

[0003] However, in practice, the following technical problems often arise when using the above method for test step management: (1) Linear step test cases consist of a series of sequentially executed operation steps. The test cases are independent of each other. The same operation sequence needs to be stored and executed repeatedly in different test cases, which wastes storage resources and consumes a lot of computing resources due to repeated execution. When the underlying interface changes, all test cases containing the operation steps need to be modified one by one, which results in long test case maintenance time.

[0004] (2) Script-level reuse encapsulates common logic through functions or common scripts, which depends on specific scripting languages ​​or runtime environments and has a coarser reuse granularity. Each function call requires stack operations and parameter passing, and dynamic type checking consumes additional computation cycles, resulting in a waste of computing resources and an increase in execution time.

[0005] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not form prior art known to those skilled in the art. Summary of the Invention

[0006] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0007] Some embodiments of this disclosure propose methods for encapsulating and nesting test steps, head-mounted display devices, and media to address one or more of the technical problems mentioned in the background section above.

[0008] In a first aspect, some embodiments of this disclosure provide a method for encapsulating and nesting test steps, applied to a head-mounted display device, comprising: performing the following steps based on each of the acquired raw operation data: parsing the raw operation data to obtain an operation type; encapsulating the raw operation data according to the operation type to obtain standardized test steps; generating initial test cases based on a target test case template and the obtained standardized test steps; generating composite step nodes based on the initial test cases and preset nesting conditions; updating the step sequence of the target test cases based on the composite step nodes to obtain hierarchical nested test cases; and generating a sequence of steps to be executed based on the hierarchical nested test cases in response to detecting an execution instruction corresponding to the hierarchical nested test cases.

[0009] Optionally, the method further includes: generating a unique identifier corresponding to the original operation data based on the original operation data; generating execution parameters, execution conditions, and return result descriptions corresponding to the original operation data based on the unique identifier and the original operation data; and determining the unique identifier, execution parameters, execution conditions, and return result descriptions as standardized test steps corresponding to the original operation data.

[0010] Optionally, the method further includes: according to the above step type, obtaining each standardized test step corresponding to the above step type from each of the above standardized test steps as each target standardized test step; and according to the above execution order, performing concatenation processing on each of the above target standardized test steps to obtain initial test cases.

[0011] Optionally, the method further includes: in response to detecting that the initial test case satisfies the preset nesting condition, determining the initial test case as a nested test case; and abstracting the nested test case to obtain a composite step node.

[0012] Optionally, the method further includes: inserting the composite step node into the original step sequence according to the insertion position of the original step sequence corresponding to the target test case, so as to obtain an updated step sequence as an updated step sequence; and establishing a hierarchical association between the target test case and the nested test cases corresponding to the composite step node according to the updated step sequence, so as to obtain hierarchical nested test cases.

[0013] Optionally, the method further includes: obtaining the nested test cases corresponding to the composite step nodes in the hierarchical nested test cases according to the hierarchical relationship in the hierarchical nested test cases; performing recursive expansion processing on the nested test cases to obtain each standardized test step; and merging the standardized test steps with the original execution steps in the hierarchical nested test cases to obtain a sequence of steps to be executed.

[0014] In a second aspect, some embodiments of this disclosure provide a head-mounted display device, including: one or more processors; a storage device for storing one or more programs; an optomechanical system and optical elements for imaging in front of a user; and when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any of the implementations of the first aspect.

[0015] Thirdly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0016] The above embodiments of this disclosure have the following beneficial effects: By encapsulating and nesting test steps through some embodiments of this disclosure, the waste of storage and computing resources can be reduced and the time spent on test case maintenance can be shortened. The reasons for the large waste of storage and computing resources and the long time spent on test case maintenance are: (1) Linear step test cases consist of a series of sequentially executed operation steps. The test cases are independent of each other. The same operation sequence needs to be repeatedly stored and executed in different test cases, resulting in the waste of storage resources. Moreover, repeated execution leads to the consumption of a lot of computing resources. When the underlying interface changes, all test cases containing the operation steps need to be modified one by one, resulting in the long time spent on test case maintenance. (2) Script-level reuse encapsulates general logic through functions or common scripts. It depends on specific scripting languages ​​or runtime environments and has a coarser reuse granularity. Each function call needs to perform stack operations and parameter passing, and dynamic type checking will consume additional computing cycles, resulting in the waste of computing resources and the increase in execution time. Based on this, the encapsulation and nesting method for test steps in some embodiments of this disclosure firstly performs the following steps based on each of the acquired original operation data: parsing the original operation data to obtain the operation type. This yields the operation type of the original operation data. Then, based on the operation type, the original operation data is encapsulated to obtain standardized test steps. This yields standardized test steps. Secondly, initial test cases are generated based on the target test case template and the obtained standardized test steps. This yields initial test cases. Then, composite step nodes are generated based on the initial test cases and preset nesting conditions. This abstracts the initial test cases into callable composite step nodes. Next, the step sequence of the target test cases is updated based on the composite step nodes to obtain hierarchical nested test cases. This yields hierarchical nested test cases containing composite step nodes. Finally, in response to detecting an execution instruction corresponding to the hierarchical nested test cases, a sequence of steps to be executed is generated based on the hierarchical nested test cases. This yields the sequence of steps to be executed. Because it doesn't repeatedly store and execute the same sequence of operations, but instead encapsulates the raw operation data into reusable standardized test steps, the same standardized test steps can be shared and invoked by multiple test cases, thus reducing the waste of storage resources. It also doesn't rely on a specific scripting language runtime environment for function calls; instead, it abstracts nested test cases as placeholders by generating compound step nodes, which are then expanded into specific standardized test steps during execution. Furthermore, when the underlying interface changes, only the corresponding standardized test steps need to be modified; all test cases referencing these standardized test steps automatically take effect without needing to be modified individually.Therefore, it can reduce the waste of storage and computing resources, thereby shortening the time spent on test case maintenance and improving the reusability of test cases and the efficiency of test execution. Attached Figure Description

[0017] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0018] Figure 1 This is an exemplary system architecture diagram of a method for encapsulating and nesting test steps according to some embodiments of this disclosure; Figure 2 This is a flowchart of some embodiments of the encapsulation and nesting methods for the test steps according to this disclosure; Figure 3 This is a flowchart of some other embodiments of the encapsulation and nesting method of the test steps according to this disclosure; Figure 4 This is a schematic diagram of the hardware structure of a head-mounted display device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0019] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0020] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0021] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0022] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0023] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0024] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] Figure 1 An exemplary system architecture 100 is shown, which can be applied to an embodiment of the encapsulation and nesting method for testing steps of a head-mounted display device disclosed herein.

[0026] like Figure 1 As shown, the exemplary system architecture 100 may include a head-mounted display device 11 and a terminal device 12.

[0027] The head-mounted display device 11 may include one or two optomechanical and optical elements 111. These optomechanical and optical elements are used to display a virtual interface. Furthermore, the head-mounted display device 11 also includes a frame 112. In some embodiments, the sensors, processing unit, memory, and battery of the head-mounted display device 11 may be housed within the frame 112. In some alternative implementations, one or more components of the sensors, processing unit, memory, and battery may be integrated into another separate accessory (not shown), connected to the frame 112 via a data cable 13. In some alternative implementations, the head-mounted display device 11 may only have display functionality and some sensors, while providing data processing, data storage, power supply, and other capabilities through a terminal device 12.

[0028] The terminal device 12 includes a touch component 121, which can be a touch screen or a touchpad. The touch screen can be used to display content and control window dragging, and the touchpad can be used to control window dragging. In some embodiments, the head-mounted display device 11 and the terminal device 12 can be communicatively connected. The communication connection can be a wired connection or a Bluetooth connection.

[0029] It should be understood that Figure 1 The number of head-mounted display devices and terminal devices shown is merely illustrative. Any suitable number of head-mounted display devices and terminal devices can be included depending on the implementation requirements.

[0030] Further reference Figure 2 The diagram illustrates a flow 200 of some embodiments of a method for encapsulating and nesting test steps according to the present disclosure. This method for encapsulating and nesting test steps includes the following steps: Step 201: Based on each piece of raw operation data obtained, perform the following steps: Step 2011: Parse and process the original operation data to obtain the operation type.

[0031] In some embodiments, the execution entity of the test step encapsulation and nesting method (e.g., a head-mounted display device) can parse and process the aforementioned raw operation data to obtain the operation type. Each of the aforementioned raw operation data can represent an atomic operation performed by the user on the aforementioned head-mounted display device. For example, the raw operation data could be {timestamp:10:01:23,action:"click",target:"settings_icon",coordinates:{x:100,y:200}}. The aforementioned user can represent a user wearing the aforementioned head-mounted display device. The aforementioned operation type can represent the type of the aforementioned raw operation data. The aforementioned operation type can include, but is not limited to: click operation, input operation, and swipe operation. In practice, firstly, the execution entity can extract the value of the action field from the aforementioned raw operation data using a field extraction method. Then, the read value is determined as the operation type.

[0032] In addressing the technical challenges mentioned above, the following technical problem arises when parsing raw operational data from head-mounted display devices using eye-tracking modules from different manufacturers (e.g., well-known manufacturer A, B, and C). This is because different manufacturers use different data formats, leading to different parsing rules. Changing field names or adding new manufacturers necessitates modifying these rules individually, resulting in lengthy test case maintenance. Furthermore, using regular expressions to match deeply nested coordinate structures results in low parsing efficiency and consumes significant computational resources in 90Hz real-time eye-tracking scenarios. Without boundary checks during parsing, invalid coordinates passed to the application layer can cause program crashes, increasing recovery time and computational overhead. To address the specific requirements of this application scenario—adapting to variations in field names from different manufacturers' output formats, accurately decomposing deeply nested coordinate structures, and handling low-latency parsing under high-frequency sampling—we have decided to adopt the following solution: In some optional implementations of certain embodiments, the aforementioned execution entity may parse and process the original operation data through the following steps to obtain the operation type: The first step is to perform character traversal processing on the original operation data to obtain the original character sequence. The original character sequence can represent a sequence formed according to the natural order of the characters in the original operation data. For example, the original character sequence can be ['{', 'a', 'c', 't', 'i', 'o', 'n', ':', '"', 'c', 'l','i', 'c', 'k', '"', ',', 'c', 'o', 'o', 'r', 'd', 'i', 'n', 'a', 't', 'e', ​​'s', ':', '{', 'x', ':', '1', '0', '0', ',', 'y', ':', '2', '0', '0', '}','}']. In practice, firstly, the execution entity can use a string reading function to iterate through each character in the original operation data. Then, the obtained characters are stored in an array structure according to the traversal order. Finally, the resulting array structure is used to represent the original character sequence. For example, the string reading function could be the C language's `fgets()` function.

[0033] The second step is to determine the start and end marker characters corresponding to the original character sequence. The start marker character represents the first character in the original character sequence, and the end marker character represents the last character. In practice, the executing entity can traverse the original character sequence, determining the first character as the start marker character and the last character as the end marker character.

[0034] The third step is to generate a valid data subsequence based on the aforementioned start and end marker characters. This valid data subsequence can represent the sequence of characters located after the start marker character and before the end marker character. In practice, firstly, the executing entity can use array slicing to obtain each character in the original character sequence from the position following the start marker character to the position preceding the end marker character. Then, these characters are determined as the valid data subsequence.

[0035] The fourth step involves splitting the valid data subsequence into key-value pairs based on the target delimiter, resulting in a set of field names and a set of field values. The target delimiter represents the character used to divide the key-value pairs in the valid data subsequence; for example, a colon can be used. The set of field names represents a list containing all key names extracted from the key-value pairs. The set of field values ​​represents a list containing all key values ​​extracted from the key-value pairs. In practice, firstly, the execution entity can use a string splitting function to divide the valid data subsequence into multiple key-value pairs, using commas as delimiters. Then, for each key-value pair, using a colon as a delimiter, the pair is split into a key name and a key value, resulting in individual key names and their corresponding key values. Next, the key names are sequentially stored in a first list to obtain the set of field names, and the key values ​​are sequentially stored in a second list to obtain the set of field values. For example, when the key-value pair is "action:click", the key is "action" and the value is "click". It should be noted that there is a one-to-one correspondence between the field names in the above set of field names and the field values ​​in the above set of field values. For example, the string splitting function can be the `split()` function.

[0036] Fifth, for each field name in the above set of field names, perform the following steps: First, the aforementioned field names are compared with a preset key field list to obtain a comparison result. The preset key field list represents a pre-defined set of field names corresponding to various operation types. Here, the specific type of operation is not limited; for example, when the operation type is a click operation, the corresponding field name is "action". The comparison result represents a Boolean value indicating whether the aforementioned field name exists in the preset key field list. The comparison result can be a first comparison result or a second comparison result. The first comparison result represents a Boolean value of true. The second comparison result represents a Boolean value of false. In practice, the executing entity can traverse the preset key field list using a linear search. In response to determining that a string with the same field name exists in the preset key field list, the Boolean value of the comparison result is set to true; otherwise, the Boolean value of the comparison result is set to false.

[0037] Then, in response to determining the above comparison result as the first comparison result, the field value corresponding to the above field name is determined as the key field value.

[0038] Step 6: Based on the aforementioned key field values, perform coordinate decomposition on the coordinate structure field in the aforementioned field value set to obtain the x-coordinate and y-coordinate values. The coordinate structure field can represent a nested data structure containing x and y coordinate values; for example, the coordinate structure field could be "coordinates":{"x":100,"y":200}. The x-coordinate value represents the horizontal coordinate value. The y-coordinate value represents the vertical coordinate value. In practice, firstly, the executing entity can use key name indexing to find the data structure containing the x and y fields in the aforementioned field value set. Then, it reads the value corresponding to the x field from the data structure as the x-coordinate value and the value corresponding to the y field as the y-coordinate value. It should be noted that the above coordinate decomposition process can be used for operation types that contain coordinate structure fields (e.g., click operations, long press operations, swipe start and end points, drag operations); for operation types that do not contain coordinate structure fields (e.g., input operations, voice command operations), the above coordinate decomposition process can be skipped.

[0039] Step 7: Perform boundary range verification on the aforementioned horizontal and vertical coordinate values ​​to obtain the coordinate verification result. The coordinate verification result represents a Boolean value indicating whether both the horizontal and vertical coordinate values ​​are within a valid range. The valid range can represent the numerical interval defined by pre-defined minimum and maximum values ​​for the horizontal and vertical coordinates. For example, the minimum horizontal coordinate value can be 0, the maximum horizontal coordinate value can be 1920, the minimum vertical coordinate value can be 0, and the maximum vertical coordinate value can be 1080. In practice, firstly, the executing entity can use a threshold comparison algorithm to determine whether the horizontal coordinate value is greater than or equal to the minimum horizontal coordinate value and less than or equal to the maximum horizontal coordinate value, and whether the vertical coordinate value is greater than or equal to the minimum vertical coordinate value and less than or equal to the maximum vertical coordinate value. Then, in response to determining that both of the above judgments are true, the coordinate verification result is set to true; otherwise, the coordinate verification result is set to false. It should be noted that both of the above judgments being true can indicate that the above horizontal coordinate value is greater than or equal to the above horizontal coordinate minimum value and less than or equal to the above horizontal coordinate maximum value, and the above vertical coordinate value is greater than or equal to the above vertical coordinate minimum value and less than or equal to the above vertical coordinate maximum value.

[0040] Step 8: In response to the confirmation that the above coordinate decomposition process has been performed and the above coordinate verification result is true, an operation type is generated based on the above key field value, the above horizontal coordinate value, and the above vertical coordinate value. In practice, firstly, the executing entity can look up the type corresponding to the above key field value in the operation type mapping table. Then, the found type is associated and stored with the above horizontal coordinate value and the above vertical coordinate value. Finally, the data record obtained after the above association and storage is determined as the operation type. The above operation type mapping table can represent the data table that stores the correspondence between the above key field values ​​and types. For example, the operation type mapping table can be "...key field value: click; type: click operation...".

[0041] Step nine: In response to the determination that the above coordinate decomposition process was not performed, an operation type is generated based on the aforementioned key field values. In practice, firstly, the executing entity can look up the type corresponding to the aforementioned key field values ​​in the operation type mapping table. Then, the found type is determined as the operation type.

[0042] The above technical solution, as an inventive point of this disclosure, solves technical problem two: "long maintenance time for test cases, high consumption of computing resources, and increased time and additional computational overhead for exception recovery." The reasons for the long maintenance time for test cases, high consumption of computing resources, and increased time and additional computational overhead for exception recovery are as follows: different manufacturers have different data formats and corresponding parsing rules. When field names change or new manufacturers are added, the parsing rules need to be modified one by one, resulting in long maintenance time for test cases; if regular expressions are used to match deeply nested coordinate structures, the parsing efficiency is low, which will consume a lot of computing resources in a 90Hz real-time eye-tracking scenario; if boundary verification is not performed during the parsing phase, invalid coordinates passed to the application layer will cause program crashes, increasing the time and additional computational overhead for exception recovery. Solving the above factors can shorten the maintenance time for test cases, reduce the consumption of computing resources, and reduce the time and additional computational overhead for exception recovery. To achieve this effect, the encapsulation and nesting method of the test steps disclosed herein matches field name variations from different vendors using a pre-defined list of key fields. This eliminates the need to modify the core parsing logic, reducing the time required for test case maintenance and avoiding the need to modify parsing rules one by one due to field name changes or the addition of new vendors. Furthermore, by directly decomposing the nested coordinate structure using key name indexes, inefficient backtracking matching using regular expressions is avoided. Therefore, computational resource consumption under high-frequency eye-tracking sampling can be reduced, meeting the low-latency requirements of real-time processing. In addition, by embedding boundary range validation during the parsing phase, invalid coordinates exceeding the screen range are intercepted in advance, preventing invalid coordinates from being passed to the application layer and causing program crashes. This reduces the time and additional computational overhead of exception recovery, improving system stability.

[0043] Step 2012: Based on the operation type, the original operation data is encapsulated to obtain standardized test steps.

[0044] In some embodiments, the execution entity may encapsulate the original operation data according to the operation type to obtain standardized test steps. These standardized test steps can characterize the structured data obtained after encapsulating the original operation data.

[0045] In some optional implementations of certain embodiments, the aforementioned execution entity can encapsulate the aforementioned raw operation data according to the aforementioned operation type through the following steps to obtain standardized test steps: The first step is to generate a unique identifier corresponding to the aforementioned original operation data. This unique identifier can be a string used to distinguish different original operation data. In practice, the executing entity can first use the snowflake algorithm to process the timestamp field in the original operation data as input, obtaining a 64-bit integer as the first value. Then, this first value is converted into a hexadecimal string as the unique identifier. The specific content of the unique identifier is not limited here; for example, the unique identifier could be STEP_001.

[0046] The second step involves generating execution parameters, execution conditions, and a return result description corresponding to the aforementioned original operation data, based on the unique identifier and the original operation data. The execution parameters represent the input data extracted from the original operation data. For example, the input data could be the coordinates of a click operation. The execution conditions represent the environmental state that needs to be satisfied when executing the original operation data. For example, the environmental state could be that the page has finished loading. The return result description represents the expected output result after the execution of the original operation data. For example, the output result could be a page redirect. In practice, firstly, the execution entity can use a regular expression matching algorithm to extract the value of the `coordinates` field from the original operation data as the execution parameters. Then, a preset rule engine is used to match the execution conditions corresponding to the operation type. Finally, using the expected result mapping table, the expected output is queried based on the operation type and the unique identifier, and the queried expected output is used as the return result description. For example, the preset rule engine could be "If the operation type is a click operation, the execution condition is that the page has finished loading; if the operation type is an input operation, the execution condition is that the input box is in an editable state." The expected result mapping table can be "Unique identifier: STEP_001; Operation type: Click operation; Expected output: Jump to settings page".

[0047] The third step is to define the aforementioned unique identifier, execution parameters, execution conditions, and return result description as standardized test steps corresponding to the aforementioned original operation data.

[0048] Step 202: Generate initial test cases based on the target test case template and the obtained standardized test steps.

[0049] In some embodiments, the aforementioned execution entity can generate initial test cases based on the target test case template and the obtained standardized test steps. The target test case template may include step types and the execution order corresponding to those step types. The step types can characterize the description of the business function of each test step in the test case. For example, the step type could be "enter username". The execution order can characterize the order in which the various step types are executed. For example, the execution order could be to execute the test step of entering the username first, then the test step of entering the password, and finally the test step of clicking the login button.

[0050] In some optional implementations of certain embodiments, the aforementioned execution entity can generate initial test cases based on the target test case template and the obtained standardized test steps through the following steps: The first step is to obtain the corresponding standardized test steps from the various standardized test steps described above, based on the step types mentioned. In practice, the executing entity can use a string matching algorithm, using the step types as matching keys, to iterate through the standardized test steps and find those matching the step types as the target standardized test steps. For example, the string matching algorithm could be the KMP algorithm.

[0051] The second step involves chaining the standardized test steps according to the execution order described above to obtain initial test cases. These initial test cases can represent test cases composed of multiple standardized test steps executed in the aforementioned order. In practice, firstly, the executing entity can sort the standardized test steps according to the order of each step type in the execution sequence, obtaining a sorted sequence of steps. Then, each standardized test step in the sorted sequence is sequentially stored in a list, and this list is used as the initial test cases.

[0052] Step 203: Generate composite step nodes based on the initial test cases and preset nested conditions.

[0053] In some embodiments, the execution entity can generate a composite step node based on the initial test case and preset nesting conditions. The preset nesting conditions can be receiving a user selection operation on the initial test case. The composite step node can represent a referenceable object obtained after encapsulating the initial test case. It should be noted that the placeholder object can be used to represent the initial test case in the step sequence.

[0054] In some optional implementations of certain embodiments, the aforementioned execution entity can generate composite step nodes based on the initial test cases and preset nested conditions through the following steps: The first step is to determine the initial test case as a nested test case upon detecting that it satisfies the preset nesting conditions. The nested test case can represent a test case referenced by other test cases.

[0055] The second step involves abstracting the nested test cases to obtain a composite step node. In practice, firstly, the execution entity can instantiate the node object using its constructor, calling the node class's constructor with the unique identifier of the nested test case as a parameter. This node object automatically acquires a unique identifier. Then, the node object stores a reference pointer to the nested test case, and the resulting node object serves as the composite step node. It should be noted that the unique identifier of the nested test case can be assigned by the execution entity when the nested test case is generated.

[0056] In addressing the technical problems mentioned above, and considering the application scenario—specifically, when multiple test cases in a head-mounted display device need to dynamically load and reference the same nested test case at runtime—the following technical problem often arises: If linear step-by-step test cases are used, each referencing test case needs to independently store a complete copy of the nested test case. When the bytecode of the nested test case is large and referenced by dozens of test cases, this results in duplicate occupation of storage resources. Furthermore, when the version of the nested test case is updated, all referencing test cases need to be modified individually, leading to lengthy test case maintenance. To meet the following requirements of this application scenario—adapting to efficient reuse of the same nested test case by multiple test cases and automatic synchronization updates after version changes—we have decided to adopt the following solution: In some optional implementations of certain embodiments, the aforementioned execution entity can abstract the nested test cases through the following steps to obtain composite step nodes: The first step is to perform bytecode scanning on the nested test cases to obtain a bytecode stream to be processed. This bytecode stream represents continuous binary data read from the bytecode file of the nested test cases. In practice, the execution entity can first map the bytecode file of the nested test cases directly to the virtual memory address space using a memory-mapped file, obtaining a mapped bytecode file. Then, by accessing the memory address through pointers, the binary data in the mapped bytecode file is read, and this read binary data is used as the bytecode stream to be processed.

[0057] The second step involves extracting interface signatures from the bytecode stream to be processed, resulting in an interface signature set. Each interface signature represents a string concatenated from a list of parameter types and a return value type. The format of the interface signature can be a left parenthesis followed by the parameter type encoding, and a right parenthesis followed by the return value type encoding. For example, in Java bytecode, the interface signature "(I)V" indicates a parameter type of int and a return value type of void; "(Ljava / lang / String;)Z" indicates a parameter type of String and a return value type of boolean. The interface signature set can represent a list composed of multiple such interface signatures. In practice, the executing entity first uses the KMP string matching algorithm to find byte subsequences in the bytecode stream that match the format of the interface signatures. Then, each obtained byte subsequence is converted into a string. Finally, each string is stored in a list as the interface signature set.

[0058] The third step involves hashing each interface signature in the aforementioned interface signature set to obtain a hash value set. Each hash value represents a fixed-length numerical value output from the hash calculation of the interface signature. For example, performing SHA-256 on the string "(I)V" yields the hash value "e5a3c9f2b1d4e7f8a9b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4". This hash value set represents a list of hash values. In practice, the executing entity first uses the SHA algorithm to hash each string corresponding to each interface signature in the aforementioned interface signature set, obtaining individual hash values. Then, these hash values ​​are stored in a list as the hash value set.

[0059] The fourth step is to determine a unique node identifier based on the aforementioned set of hash values. This unique node identifier can represent a string used to distinguish nodes in different composite steps. In practice, firstly, the executing entity can use a string concatenation operation to sequentially concatenate all hash values ​​in the aforementioned hash value set into a long string. Then, this long string is used as the unique node identifier.

[0060] Step 5: Generate query results corresponding to the aforementioned unique node identifiers based on the global node registry. The global node registry can represent key-value pairs consisting of registered unique node identifiers as keys. The specific content of these key-value pairs is not limited; for example, a key-value pair could be {key name: "a3f5c2e1d4b6", key value: "storage address of the composite step node object"}. The query result can represent a Boolean value indicating whether the aforementioned unique node identifier exists in the global node registry. The Boolean value can represent a logical value of true or false. The query result can be a first query result or a second query result. The first query result indicates that the aforementioned unique node identifier exists in the global node registry. The second query result indicates that the aforementioned unique node identifier does not exist in the global node registry. In practice, the aforementioned executing entity can perform a dictionary lookup operation, using the aforementioned unique node identifier as the lookup key, to search the aforementioned global node registry. In response to determining that a key identical to the aforementioned lookup key exists in the aforementioned global node registry, the first query result is determined as the query result; in response to determining that a key identical to the aforementioned lookup key does not exist in the aforementioned global node registry, the second query result is determined as the query result.

[0061] Step 6: In response to determining that the above query result is the second query result, an initialization node object is generated based on the current timestamp and a random number. The current timestamp represents the current moment. The random number represents a randomly generated value. The specific value of the random number is not limited here; for example, it could be 12345678. The initialization node object represents a newly created empty node. In practice, the execution entity can create an empty object through object instantiation. Then, the current milliseconds are obtained as the current timestamp using the system time function. Next, a random number is obtained using a random number generator. Finally, the current timestamp and the random number are stored as attribute values ​​in the empty object to obtain the initialization node object.

[0062] Step 7: Based on the storage path and version number of the nested test cases, perform metadata population on the initialization node object to obtain a metadata-populated node object. The storage path represents the location of the nested test cases in the file system. The version number represents the version identifier of the nested test cases. The metadata-populated node object represents a node object containing the storage path and version number. For example, the metadata-populated node object could be {storage path: " / usr / testcase / login", version number: "v2.1.0"}. In practice, the execution entity can read the storage path and version number of the nested test cases using a dot assignment operation. Then, it assigns the storage path to the path attribute field of the initialization node object and the version number to the version attribute field. Finally, the object obtained after the assignment is determined as the metadata-populated node object. For example, the dot assignment operation could be obj.path = pathValue.

[0063] Step 8: Establish a weak reference to the nested test case on the aforementioned metadata-populated node object, resulting in a weak reference node object. This weak reference node object can represent a node object containing a weak reference field. In practice, firstly, the execution entity can create a weak reference object by passing the memory address of the nested test case as an input parameter. Then, assign this weak reference object to the reference field of the metadata-populated node object. Finally, the node object obtained after the assignment is identified as the weak reference node object.

[0064] Step nine involves generating serialized node data based on the aforementioned weak reference node object. This serialized node data represents the conversion of the weak reference node object into a storable or transmittable byte stream. In practice, the executing entity can use Java serialization to write all field values ​​of the weak reference node object into a byte output stream in the order they are declared within the weak reference node object. Then, all bytes in the byte output stream are identified as the serialized node data.

[0065] Step 10: Generate a composite step node based on the unique node identifier and the serialized node data. In practice, firstly, the execution entity can create a new node object using an instance constructor. Then, assign the unique node identifier to the identifier field of the node object, and assign the serialized node data to the data field of the node object. The resulting encapsulated object is then used as the composite step node. For example, a composite step node could be {unique node identifier: "a3f5c2e1d4b6", serialized node data: [0x72, 0x65, 0x64, ...]}.

[0066] The above technical solution, as an inventive point of this disclosure, solves technical problem three: "duplicated use of storage resources, leading to prolonged maintenance time for test cases." The reasons for this duplicated use of storage resources and prolonged maintenance time for test cases are as follows: If linear step-based test cases are used, each referencing test case needs to independently store a complete copy of the nested test case. When the bytecode of the nested test case is large and referenced by dozens of test cases, it causes duplicate use of storage resources. When the version of the nested test case is updated, all referencing test cases need to be modified one by one, resulting in prolonged maintenance time. Solving these factors reduces duplicate storage resource usage and shortens the maintenance time for test cases. To achieve this effect, the encapsulation and nesting method of test steps in this disclosure extracts interface signatures through bytecode scanning and performs hash calculations on the interface signature set to generate unique node identifiers. Therefore, it ensures that nested test cases with different content generate different identifiers, avoiding identifier conflicts. Furthermore, by utilizing a global node registry for existence checks, a new node is created only when the identifier does not exist. This avoids the same nested test case being repeatedly abstracted into multiple composite step nodes, thus reducing redundant storage resource usage. In addition, storage paths and version numbers are populated as metadata into node objects, and weak references are established. When a version is updated, only the nested test case itself needs to be modified; all referrers automatically load the new version via the version number, eliminating the need for individual modifications. This further reduces redundant storage resource usage and shortens the time spent maintaining test cases.

[0067] Step 204: Based on the composite step node, update the step sequence of the target test case to obtain hierarchical nested test cases.

[0068] In some embodiments, the execution entity can update the step sequence of the target test case based on the composite step node to obtain hierarchically nested test cases. The target test case can represent a test case that needs to be embedded in a composite step node. The hierarchically nested test cases can represent a test case containing at least one composite step node.

[0069] Step 205: In response to the detection of the execution instruction of the corresponding hierarchical nested use case, generate a sequence of steps to be executed based on the hierarchical nested use case.

[0070] In some embodiments, in response to detecting an execution instruction corresponding to the aforementioned hierarchical nested use case, the execution entity can generate a sequence of steps to be executed based on the aforementioned hierarchical nested use case. The execution instruction can represent an instruction that triggers the execution of the aforementioned hierarchical nested use case. The sequence of steps to be executed can represent a sequence of steps that can be directly executed.

[0071] In some optional implementations of certain embodiments, in response to detecting an execution instruction corresponding to the aforementioned hierarchical nested use case, the execution entity can generate a sequence of steps to be executed based on the aforementioned hierarchical nested use case through the following steps: The first step is to obtain the nested test cases corresponding to the compound step nodes in the aforementioned hierarchical nested test cases, based on the hierarchical relationships within them. In practice, the executing entity can first extract the key-value pairs corresponding to the key names in the hierarchical relationships using a key-value pair query method. These key-value pairs serve as the unique identifiers of the nested test cases. Then, the test cases in the test case library that correspond to these unique identifiers are identified as the nested test cases.

[0072] The second step involves recursively expanding the nested test cases to obtain standardized test steps. In practice, firstly, the executing entity can use a type-determination method to check whether the nested test cases contain compound step nodes. If it is determined that the nested test cases do not contain compound step nodes, the standardized test steps within those nested test cases are identified as the expansion results. If it is determined that the nested test cases contain compound step nodes, the type-determination and expansion operations are performed again on the next-level nested test cases pointed to by the compound step nodes, until the nested test cases no longer contain compound step nodes. The standardized test steps obtained from each expansion are sequentially stored in a list, and this list serves as the standard test steps.

[0073] The third step involves merging the standardized test steps mentioned above with the original execution steps in the hierarchical nested test cases to obtain a sequence of steps to be executed. The original execution steps can represent test steps in the hierarchical nested test cases that are not part of a composite step node. In practice, the execution entity can use a sequential traversal method to read each step in the order of the original step sequence in the hierarchical nested test cases. Upon determining that a read step is an original execution step, it is directly stored in the output list; upon determining that a read step is a composite step node, the standardized test steps obtained from the recursive expansion of the composite step node are stored sequentially in the output list; upon determining that all steps in the original step sequence have been traversed, the output list is used as the sequence of steps to be executed.

[0074] The above embodiments of this disclosure have the following beneficial effects: By encapsulating and nesting test steps through some embodiments of this disclosure, the waste of storage and computing resources can be reduced and the time spent on test case maintenance can be shortened. The reasons for the large waste of storage and computing resources and the long time spent on test case maintenance are: (1) Linear step test cases consist of a series of sequentially executed operation steps. The test cases are independent of each other. The same operation sequence needs to be repeatedly stored and executed in different test cases, resulting in the waste of storage resources. Moreover, repeated execution leads to the consumption of a lot of computing resources. When the underlying interface changes, all test cases containing the operation steps need to be modified one by one, resulting in the long time spent on test case maintenance. (2) Script-level reuse encapsulates general logic through functions or common scripts. It depends on specific scripting languages ​​or runtime environments and has a coarser reuse granularity. Each function call needs to perform stack operations and parameter passing, and dynamic type checking will consume additional computing cycles, resulting in the waste of computing resources and the increase in execution time. Based on this, the encapsulation and nesting method for test steps in some embodiments of this disclosure firstly performs the following steps based on each of the acquired original operation data: parsing the original operation data to obtain the operation type. This yields the operation type of the original operation data. Then, based on the operation type, the original operation data is encapsulated to obtain standardized test steps. This yields standardized test steps. Secondly, initial test cases are generated based on the target test case template and the obtained standardized test steps. This yields initial test cases. Then, composite step nodes are generated based on the initial test cases and preset nesting conditions. This abstracts the initial test cases into callable composite step nodes. Next, the step sequence of the target test cases is updated based on the composite step nodes to obtain hierarchical nested test cases. This yields hierarchical nested test cases containing composite step nodes. Finally, in response to detecting an execution instruction corresponding to the hierarchical nested test cases, a sequence of steps to be executed is generated based on the hierarchical nested test cases. This yields the sequence of steps to be executed. Because it doesn't repeatedly store and execute the same sequence of operations, but instead encapsulates the raw operation data into reusable standardized test steps, the same standardized test steps can be shared and invoked by multiple test cases, thus reducing the waste of storage resources. It also doesn't rely on a specific scripting language runtime environment for function calls; instead, it abstracts nested test cases as placeholders by generating compound step nodes, which are then expanded into specific standardized test steps during execution. Furthermore, when the underlying interface changes, only the corresponding standardized test steps need to be modified; all test cases referencing these standardized test steps automatically take effect without needing to be modified individually.Therefore, it can reduce the waste of storage and computing resources, thereby shortening the time spent on test case maintenance and improving the reusability of test cases and the efficiency of test execution.

[0075] Further reference Figure 3 This illustrates a flow 300 of another embodiment of the encapsulation and nesting method for test steps. The flow 300 of this encapsulation and nesting method for test steps includes the following steps: Step 301: Based on each piece of raw operation data obtained, perform the following steps: Step 3011: Parse and process the original operation data to obtain the operation type.

[0076] Step 3012: Based on the operation type, encapsulate the raw operation data to obtain standardized test steps.

[0077] Step 302: Generate initial test cases based on the target test case template and the obtained standardized test steps.

[0078] Step 303: Generate composite step nodes based on the initial test cases and preset nested conditions.

[0079] Step 304: Based on the insertion position of the original step sequence of the corresponding target test case, insert the composite step node into the original step sequence to obtain the updated step sequence as the updated step sequence.

[0080] In some embodiments, the execution entity can insert the composite step node into the original step sequence according to the insertion position of the original step sequence corresponding to the target test case, resulting in an updated step sequence. The original step sequence can represent each existing test step in the target test case. The insertion position can represent a sequence number in the original step sequence. The sequence number can represent the position where the new test step is inserted. The updated step sequence can represent the new step sequence obtained after inserting the composite step node into the original step sequence. In practice, firstly, the execution entity can slice the original step sequence using the insertion position as a dividing point to obtain a first sequence before the insertion position and a second sequence after the insertion position. Then, through sequence concatenation, the first sequence, the composite step node, and the second sequence are concatenated into a complete sequence in chronological order, and the concatenated sequence is used as the updated step sequence. For example, the sequence concatenation operation can be list addition (e.g., list 1 + list 2). The first sequence can represent the sequence composed of all test steps in the original step sequence preceding the insertion position. The second sequence described above can characterize the sequence consisting of all test steps located after the insertion position in the original step sequence described above.

[0081] Step 305: Based on the update step sequence, establish a hierarchical relationship between the target test case and the nested test cases corresponding to the composite step nodes to obtain hierarchical nested test cases.

[0082] In some embodiments, the executing entity can establish a hierarchical relationship between the target test case and the nested test cases corresponding to the composite step nodes based on the update step sequence, thereby obtaining hierarchical nested test cases. The hierarchical relationship represents the subordinate relationship between the target test case and the nested test cases. The hierarchical nested test cases represent test cases that include the update step sequence and the hierarchical relationship. In practice, firstly, the executing entity can create a key-value pair record using a key-value pair storage method, using the unique identifier of the target test case as the key name and the unique identifier of the nested test case as the key value, and using the key-value pair record as the hierarchical relationship. Then, the update step sequence and the hierarchical relationship are assigned to the target test case, and the target test case after assignment is used as the hierarchical nested test case.

[0083] Step 306: In response to the detection of the execution instruction of the corresponding hierarchical nested use case, generate a sequence of steps to be executed based on the hierarchical nested use case.

[0084] In some embodiments, the specific implementation of steps 301-303 and step 306 and the resulting technical effects can be found in [reference]. Figure 2 Steps 201-203 and 205 in the corresponding embodiments will not be repeated here.

[0085] from Figure 3 It can be seen from this that, with Figure 2 Compared to the description of some corresponding embodiments, Figure 3 The process 300 of the test step encapsulation and nesting method in some corresponding embodiments demonstrates that by determining the insertion position and inserting the compound step node into the original step sequence, the nested test case can be accurately embedded into the target test case as a placeholder, avoiding the repeated storage of the same operation step sequence and thus reducing the waste of storage resources. By establishing hierarchical relationships, the parent-child inclusion relationship between test cases can be maintained without expanding the step sequence included in the nested test case, thereby reducing the overhead of repeated parsing of nested test cases and shortening the preprocessing time before test case execution.

[0086] The following is for reference. Figure 4 It shows a schematic diagram of the hardware structure of a head-mounted display device 400 with display function.

[0087] like Figure 4 As shown, the head-mounted display device 400 includes a processing unit (CPU) 401, a memory (ROM) 402, an input unit 403, and an output unit 404, wherein the processing unit 401, memory 402, input unit 403, and output unit 404 are interconnected via a bus 405. Here, the methods according to some embodiments of this disclosure can be implemented as computer programs and stored in the memory 402. The processing unit 401 in the head-mounted display device 400 implements the encapsulation and nesting functions of the test steps defined in some embodiments of this disclosure by calling the aforementioned computer program stored in the memory 402. In some implementations, the input unit 403 may include devices such as a camera, microphone, gyroscope, accelerometer, and magnetometer, and the output unit 404 may be devices that can display content, such as optomechanical and optical components. The aforementioned optomechanical and optical components may be microdisplays. Therefore, when the processing device 401 calls the above-mentioned computer program to perform the encapsulation and nesting functions of the test steps, it can control the input unit 403 to obtain the user's gestures, voice and other operation commands, and control the output unit 404 to display the display content.

[0088] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0089] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0090] The aforementioned computer-readable medium may be included in the aforementioned head-mounted display device; or it may exist independently and not assembled into the head-mounted display device. The aforementioned computer-readable medium carries one or more programs, which, when executed by the head-mounted display device, cause the head-mounted display device to: perform the following steps based on each of the acquired raw operation data: parse the aforementioned raw operation data to obtain an operation type; encapsulate the aforementioned raw operation data according to the aforementioned operation type to obtain standardized test steps; generate initial test cases based on the target test case template and the obtained standardized test steps; generate composite step nodes based on the aforementioned initial test cases and preset nesting conditions; update the step sequence of the target test cases based on the aforementioned composite step nodes to obtain hierarchical nested test cases; and generate a sequence of steps to be executed based on the aforementioned hierarchical nested test cases in response to the detection of an execution instruction corresponding to the aforementioned hierarchical nested test cases.

[0091] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0093] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0094] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for encapsulating and nesting test steps, applied to a head-mounted display device, comprising: Based on each piece of raw operation data obtained, perform the following steps: The original operation data is parsed to obtain the operation type; Based on the operation type, the original operation data is encapsulated to obtain standardized test steps; Generate initial test cases based on the target test case template and the obtained standardized test steps; Based on the initial test cases and preset nested conditions, generate composite step nodes; Based on the composite step node, the step sequence of the target test case is updated to obtain hierarchical nested test cases. In response to the detection of an execution instruction corresponding to the hierarchical nested use case, a sequence of steps to be executed is generated based on the hierarchical nested use case.

2. The method according to claim 1, wherein, The step of encapsulating the original operation data according to the operation type to obtain standardized test steps includes: Based on the original operation data, generate a unique identifier corresponding to the original operation data; Based on the unique identifier and the original operation data, generate the execution parameters, execution conditions, and return result description corresponding to the original operation data; The unique identifier, the execution parameters, the execution conditions, and the return result description are determined as standardized test steps corresponding to the original operation data.

3. The method according to claim 1, wherein, The target use case template includes step types and the execution order corresponding to the step types; as well as The process of generating initial test cases based on the target test case template and the obtained standardized test steps includes: Based on the step type, each standardized test step corresponding to the step type is obtained from each standardized test step as a target standardized test step; Based on the execution order, the standardized test steps for each target are chained together to obtain initial test cases.

4. The method according to claim 1, wherein, The step of generating composite step nodes based on the initial test cases and preset nested conditions includes: In response to the detection that the initial test case satisfies the preset nesting condition, the initial test case is determined to be a nested test case; The nested test cases are abstracted to obtain composite step nodes.

5. The method according to claim 1, wherein, The step sequence of the target test case is updated based on the composite step node to obtain hierarchical nested test cases, including: Based on the insertion position of the original step sequence corresponding to the target test case, the composite step node is inserted into the original step sequence to obtain the updated step sequence as the updated step sequence; Based on the update step sequence, a hierarchical relationship is established between the target test case and the nested test cases corresponding to the composite step nodes, resulting in hierarchical nested test cases.

6. The method according to claim 1, wherein, In response to detecting an execution instruction corresponding to the hierarchical nested use case, the step of generating a sequence of steps to be executed based on the hierarchical nested use case includes: Based on the hierarchical relationship in the hierarchical nested test cases, obtain the nested test cases corresponding to the composite step nodes in the hierarchical nested test cases; The nested test cases are recursively expanded to obtain each standardized test step. The standardized test steps are merged with the original execution steps in the hierarchical nested test cases to obtain a sequence of steps to be executed.

7. A head-mounted display device, comprising: One or more processors; Storage device for storing one or more programs; Optical mechanisms and optical components used to create images in front of the user's eyes; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-6.

8. A computer-readable medium having a computer program stored thereon, wherein, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6.

Images