Page element positioning determination method, electronic device, readable storage medium and product

Abstract

The application discloses a page element positioning determination method, an electronic device, a readable storage medium and a product, and relates to the technical field of automatic testing. The method comprises the following steps: acquiring hierarchical path information of a to-be-operated element in a page operation process and technical positioning parameters of the to-be-operated element; generating a semanticized identifier of the to-be-operated element based on the hierarchical path information; and storing the semanticized identifier and the technical positioning parameters in a configuration file in association, so that, when a target script associated with the configuration file is executed, positioning information of the to-be-operated element is acquired based on the technical positioning parameters corresponding to the semanticized identifier. By introducing the semanticized identifier as an intermediate bridge, the operation path meaning of an element is decoupled from a technical positioning mode, and the technical problems that an automatic testing script code is poor in readability, element positioning modes are scattered and difficult to maintain are solved.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, specifically to a method for determining the location of page elements, an electronic device, a readable storage medium, and a product. Background Technology

[0002] In the field of software automation testing, especially in the practice of automated testing for web pages, the size of automated test scripts has expanded along with the increasing complexity of the business logic of the system under test. Currently, mainstream automated test scripts generally adopt a development model that hard-codes the location information of page elements directly into the test case code. In this model, test developers need to write fixed location expressions for each page element to be operated, such as element identifiers or path expressions, to simulate interactive operations such as clicks and input.

[0003] However, when the same page element is reused by multiple different test modules or test cases, its corresponding positioning expression is scattered throughout the code, resulting in a large number of repetitive and fragmented positioning configurations. Once the front-end page undergoes structural changes due to version iterations, causing changes in the positioning attributes of elements, maintenance personnel must check and modify all test scripts involving that element one by one. This full-scale update method is highly susceptible to omissions, leading to test script failures and significantly increasing maintenance costs and technical debt. Furthermore, a large number of technical parameters related to interactive positioning are directly embedded in the test business logic, confusing the business operation intent with the underlying technical implementation, resulting in poor test code readability and difficulty in quickly understanding the operational flow and business meaning of test cases.

[0004] Therefore, how to effectively manage the positioning information of page elements, reduce maintenance complexity, and improve the readability of test code has become an urgent technical problem to be solved. Summary of the Invention

[0005] In view of the above-mentioned shortcomings of the prior art, the purpose of this application is to provide a method for determining page element positioning, an electronic device, a readable storage medium, and a product.

[0006] To achieve the above objectives, the first aspect of this application provides a method for determining the positioning of page elements, including: Obtain the hierarchical path information of the element to be operated on in the page operation process, as well as the technical positioning parameters of the element to be operated on. Generate semantic identifiers for the elements to be operated on based on hierarchical path information; Semantic identifiers and technical positioning parameters are associated and stored in a configuration file, so that when the target script associated with the configuration file is executed, it can obtain the positioning information of the element to be operated based on the technical positioning parameters corresponding to the semantic identifier.

[0007] In this embodiment of the application, obtaining the hierarchical path information of the element to be operated on in the page operation flow includes: Obtain the order of operations included in the page operation process, wherein the operation order includes at least one operation level; In accordance with the operation sequence, determine the element identifier associated with the element to be operated in each operation level in turn; The element identifiers are combined according to the operation order to generate the hierarchical path information of the element to be operated on.

[0008] In this embodiment of the application, the semantic identifier of the element to be operated on is generated based on the hierarchical path information, including: Extract the identifiers of each level of elements contained in the hierarchical path information; According to the preset combination rules, the extracted element identifiers at each level are combined using the preset hierarchical separation information to generate semantic identifiers for the elements to be operated on.

[0009] In this embodiment of the application, the technical positioning parameters include positioning indication information and positioning value information. The positioning indication information is used to characterize the technical strategy adopted when positioning the element to be operated, and the positioning value information is used to characterize the specific positioning data corresponding to the technical strategy.

[0010] In this embodiment of the application, semantic identifiers and technical positioning parameters are associated and stored in a configuration file, including: Semantic identifiers are used as keys, and location indication information and location value information are used as associated values, stored in the configuration file in key-value pairs.

[0011] In this embodiment of the application, the method for determining the location of page elements further includes: When executing the target script, the configuration file is queried through semantic identifiers to obtain the target key-value pairs corresponding to the semantic identifiers; Extract target location indication information and target location value information from target key-value pairs; The target positioning strategy is determined based on the target positioning indication information, and the element to be operated is located based on the target positioning value information and the target positioning strategy.

[0012] In this embodiment of the application, the method for determining the location of page elements further includes: Upon receiving a command to change the technical positioning parameters of the element to be operated, determine the target semantic identifier corresponding to the element to be operated; Based on the target semantic identifier, query the configuration file and locate the key-value pair in the configuration file that corresponds to the target semantic identifier and needs to be updated; The location indication information and / or location value information in the key-value pair to be updated are updated based on the change instruction.

[0013] A second aspect of this application provides an electronic device, comprising: The memory is configured to store instructions; The processor is configured to retrieve instructions from memory and, when executing the instructions, to implement the page element location determination method as described in the above embodiments.

[0014] A third aspect of this application provides a machine-readable storage medium storing instructions that cause a machine to perform the page element location determination method as described in the above embodiments.

[0015] A fourth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the page element positioning determination method as described in the above embodiments.

[0016] The above technical solution obtains the hierarchical path information of the element to be operated on in the page operation flow, as well as the technical positioning parameters of the element. This centralizes the collection of element positioning information scattered throughout the code, laying the foundation for unified management. Based on the hierarchical path information, semantic identifiers for the elements to be operated on are generated, replacing the difficult-to-understand technical positioning code with readable identifiers that convey the meaning of the operation path, making the code logic clear at a glance. The semantic identifiers and technical positioning parameters are associated and stored in a configuration file. This allows the target script associated with the configuration file to obtain the positioning information of the element to be operated on based on the technical positioning parameters corresponding to the semantic identifier when it is executed, achieving complete separation of configuration and code. Subsequent changes to the element positioning method only require modification of the configuration file without altering the script code, greatly reducing maintenance difficulty. By introducing semantic identifiers as an intermediary bridge, the meaning of the element's operation path is decoupled from its technical positioning method, solving the technical problems of poor readability of automated test script code and the scattered and difficult-to-maintain element positioning methods.

[0017] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings: Figure 1 The illustration shows a flowchart of a page element positioning determination method according to an embodiment of this application; Figure 2 A schematic block diagram of an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0020] It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solution of this application all comply with relevant laws and regulations. In the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0021] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0022] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0023] Figure 1 The illustration shows a flowchart of a page element positioning determination method according to an embodiment of this application. Figure 1 As shown in the figure, this application embodiment provides a method for determining the location of page elements, which may include the following steps: Step 100: Obtain the hierarchical path information of the element to be operated on in the page operation process and the technical positioning parameters of the element to be operated on. It should be noted that in the field of automated testing technology, with the continuous increase in the scale and complexity of web applications, the management of page element location information in test scripts has become a key factor affecting testing efficiency and maintenance costs. Traditional methods hard-code element location expressions into the test logic, resulting in the repeated and scattered location information of the same element across different test cases, and a mixture of business intent and technical implementation. To solve this problem, embodiments of this application provide a method for determining page element location. By constructing a semantic identifier system, element location configuration is separated from test execution code, thereby improving code readability and reducing maintenance complexity.

[0024] Specifically, in automated testing, no element to be operated on exists in isolation, but rather within a complete page operation flow chain. For example, in a web application, to reach a deeper functional page, a user often needs to click through multiple levels, such as the first-level navigation menu, the second-level sidebar, and the third-level tabs. If only the attributes of the element to be operated on are recorded, lacking an overall description of its operation path, the subsequently generated identifiers will not accurately reflect the page position of the element to be operated on and its hierarchical relationship with other elements, thus losing the readability and uniqueness that semantic identifiers should possess. Therefore, this embodiment first needs to obtain hierarchical path information to characterize the navigation context in which the element to be operated on is located within the page operation flow. There are multiple ways to obtain this hierarchical path information. In one optional implementation, the hierarchical path information can be extracted by parsing the document object model tree of the target page, identifying nodes with navigation or interactive attributes on the page, and automatically determining the operation level based on the nesting depth or hierarchical relationship of the nodes. In another alternative implementation, the user's actual operation trajectory can be recorded, and the text of the element labels clicked or focused by the user in chronological order can be recorded to automatically generate an operation flow path as hierarchical path information. Alternatively, test developers can pre-define the navigation hierarchy of each functional module based on the page structure and business logic through manual annotation or configuration, and directly read the configured hierarchical relationship as hierarchical path information. Regardless of the acquisition method used, hierarchical path information is essentially a sequence of element identifiers arranged in the order of operation, used to represent the operation levels required to complete the target operation.

[0025] Simultaneously, this embodiment also needs to obtain the technical positioning parameters of the element to be operated on. Technical positioning parameters refer to the technical implementation information required to accurately locate the element on the page during actual automated operations. The form of technical positioning parameters can vary in different automated testing frameworks or technology stacks. For example, in a document object model-based positioning framework, technical positioning parameters can be any one or a combination of element identifiers, document path expressions, cascading style sheet selectors, element names, link text, tag names, or class names. In an image recognition-based positioning framework, technical positioning parameters can be screenshot features or template images of the element. In a coordinate-based positioning framework, technical positioning parameters can be the relative position parameters of the element in the page coordinate system. The specific content and form of technical positioning parameters can be determined according to the actual positioning technology solution adopted, and this application does not impose specific limitations on them.

[0026] In this embodiment, by simultaneously acquiring hierarchical path information and technical positioning parameters, both the location information of the element in the business operation process and the positioning implementation information of the element at the technical level are obtained. The two complement each other, providing complete input materials for the subsequent generation of semantic identifiers, effectively avoiding the problem of inaccurate or unlocatable identifiers due to missing information in downstream links.

[0027] Step 200: Generate semantic identifiers for the elements to be operated on based on hierarchical path information; It's important to note that after obtaining the hierarchical path information, it cannot be directly used as the final identifier. While the hierarchical path information reflects the order of operations, its original form may be a fragmented, unprocessed set of data, lacking a standardized expression and making it unsuitable as a unique identifier for indexing and retrieval across various storage media. Therefore, it's necessary to further generate a semantically readable identifier based on the hierarchical path information. This semantically readable identifier transforms the hierarchical structure of the page operation flow into an identity marker that is both program-recognizable and easily understood by humans.

[0028] Specifically, there are several ways to generate semantic identifiers. In one optional implementation, the element identifiers at each level of the hierarchical path information can be concatenated sequentially according to their order in the operation flow, and a preset specific symbol can be inserted between adjacent levels to generate a semantic identifier. This specific symbol can be any specified character or string, as long as it can distinguish the hierarchical boundaries. For example, when the operation flow involves clicking the first-level menu, the second-level sub-menu, and the third-level tab in sequence, the extracted first-level element identifier, second-level element identifier, and third-level element identifier are global policy, intrusion detection, and threat intelligence, respectively. Combining these three using a preset hierarchical separator generates the corresponding semantic identifier. In another optional implementation, instead of using a flat string concatenation method, the element identifiers at each level can be maintained as a hierarchical data structure, and then a structured semantic identifier can be generated through serialization. In yet another optional implementation, natural language identifiers with descriptive features can be automatically generated based on the semantics of each element identifier in the hierarchical path information, combined with preset naming templates or conversion rules. Regardless of the specific generation method and expression form used, the generated semantic markup must possess uniqueness, hierarchy, and readability. Uniqueness requires that the semantic markup corresponding to the elements to be operated on in different positions within the same page operation flow must not be repeated; hierarchy requires that the semantic markup can clearly express the hierarchical progression from the initial operation to the target operation; readability requires that the semantic markup itself can intuitively reflect the business operation path, enabling test developers to understand the position of the page element represented by the markup without having to delve into the page source code.

[0029] This embodiment transforms the original hierarchical path information into standardized semantic identifiers, providing a standardized key-value basis for subsequent storage and retrieval in configuration files. This transforms the references to elements in automated test scripts from past technical address-based references to business path-based references, improving code readability and business expressiveness.

[0030] Step 300: The semantic identifier and technical positioning parameters are associated and stored in the configuration file so that when the target script of the associated configuration file is executed, it can obtain the positioning information of the element to be operated based on the technical positioning parameters corresponding to the semantic identifier.

[0031] It should be noted that after generating semantic identifiers and technical positioning parameters, simply storing this information in memory or distributing it throughout the code does not solve the problems of information dispersion and difficulty in modification. Therefore, a persistent and centralized storage mechanism is needed to solidify the mapping relationship between semantic identifiers and technical positioning parameters within a configuration file, thereby achieving complete separation between the storage layer and the execution layer. The specific format of the configuration file can be flexibly chosen according to the actual application scenario. In one optional implementation, the configuration file can adopt a structured text format in key-value pair form, using the semantic identifier as the key and the technical positioning parameter as the corresponding value, establishing a one-to-one correspondence through key-value mapping. In another optional implementation, the configuration file can adopt a table format, storing the semantic identifier and technical positioning parameter in different columns, establishing a relationship through row records. In yet another optional implementation, the configuration file can also adopt a database table format, setting the semantic identifier as the primary key and storing the technical positioning parameter as a related field. Regardless of the specific storage format used, the core storage logic is to establish a searchable and unique mapping relationship between the semantic identifier and the technical positioning parameter. After the configuration file is associated and stored, the target script can obtain the location information through the configuration file when it is executed.

[0032] Specifically, when a target script needs to interact with a specific element, it doesn't need to directly write the technical positioning parameters of that element into the script code. Instead, it uses the semantic identifier corresponding to the element as a query basis to retrieve the associated technical positioning parameters from the configuration file. Then, based on these parameters, it performs subsequent positioning and interaction operations on the element. When the front-end page of the element changes, requiring updates to its technical positioning parameters, maintenance personnel only need to modify the record corresponding to the semantic identifier in the configuration file to complete the adaptation, without needing to modify the business logic code scattered across various test scripts one by one. This mechanism reduces maintenance costs and the risk of test failures due to missed modifications.

[0033] This embodiment achieves persistent storage of semantic identifiers and technical positioning parameters, separating the positioning configuration of page elements from the test execution code at the architectural level. This not only improves the clarity and maintainability of the code, but also provides reliable technical support for the large-scale continuous maintenance of automated test cases.

[0034] In this embodiment, the hierarchical path information of the element to be operated on in the page operation flow and the technical positioning parameters of the element to be operated on are obtained. This centralizes the collection of element positioning information scattered throughout the code, laying the foundation for unified management. Based on the hierarchical path information, a semantic identifier for the element to be operated on is generated. A readable identifier with operational path meaning replaces the difficult-to-understand technical positioning code, making the code logic clear at a glance. The semantic identifier and technical positioning parameters are associated and stored in a configuration file. This allows the target script associated with the configuration file to obtain the positioning information of the element to be operated on based on the technical positioning parameters corresponding to the semantic identifier when it is executed. This achieves complete separation of configuration and code. Subsequent changes to the element positioning method only require modification of the configuration file without altering the script code, greatly reducing maintenance difficulty. By introducing a semantic identifier as an intermediary bridge, the operational path meaning of an element is decoupled from its technical positioning method, solving the technical problems of poor readability of automated test script code and the scattered and difficult-to-maintain element positioning methods.

[0035] In one embodiment, obtaining the hierarchical path information of the element to be operated on in the page operation flow includes: Obtain the order of operations included in the page operation process, wherein the operation order includes at least one operation level; In accordance with the operation sequence, determine the element identifier associated with the element to be operated in each operation level in turn; The element identifiers are combined according to the operation order to generate the hierarchical path information of the element to be operated on.

[0036] In this embodiment, it should be noted that, in order to accurately depict the navigation position of the element to be operated on in the page operation flow, it is necessary to first obtain the operation sequence included in the page operation flow. A page operation flow usually consists of multiple consecutive operation steps. For example, the user needs to first expand the first-level navigation menu, then click on a second-level menu item, and finally locate the target button on the opened page. There is a clear sequential dependency between these steps, which correspond to different operation levels. This operation sequence can be automatically identified by parsing the page structure, such as by traversing the nodes with navigation attributes and their nesting relationships in the document object model tree; it can also be extracted from recorded user interaction trajectories sorted by timestamp; or it can be predefined by test developers according to the business process. After obtaining the operation sequence, the element identifier associated with the element to be operated on in each operation level is determined in sequence according to the operation sequence. Here, the element identifier refers to the identification information that can represent the identity of the page element corresponding to that level, such as the text name displayed on the page element, the identifier attribute value of the page element in the source code, or a custom business alias for the page element, etc. Taking the user's operation flow of clicking the global policy menu and then the intrusion detection submenu as an example, the element identifier associated with the element to be operated on in the first operation level can be the global policy, and the element identifier in the second operation level can be the intrusion detection. And so on, by combining the element identifiers determined at each operation level according to the operation sequence, hierarchical path information representing the operation path of the element to be operated on can be generated.

[0037] Obtaining hierarchical path information through the above method ensures that the information accurately reflects the sequence and hierarchical relationship between each level in the page operation process, providing a structured and reliable input source for the subsequent generation of readable and unique semantic identifiers.

[0038] In one embodiment, generating a semantic identifier for the element to be operated on based on hierarchical path information includes: Extract the identifiers of each level of elements contained in the hierarchical path information; According to the preset combination rules, the extracted element identifiers at each level are combined using the preset hierarchical separation information to generate semantic identifiers for the elements to be operated on.

[0039] In this embodiment, it should be noted that after obtaining the hierarchical path information, the element identifiers of each level contained in the hierarchical path information are extracted. These element identifiers correspond to the page element identification information associated with each operation level in the operation flow. Subsequently, according to preset combination rules, the extracted element identifiers of each level are combined using preset hierarchical separation information. The preset combination rules define the specifications for integrating these scattered element identifiers into a whole identifier, and the preset hierarchical separation information is used to indicate the boundaries between different levels in the combined identifier. The preset hierarchical separation information can use any specified symbol or string, such as hash, greater than sign, forward slash, period, or underscore. For example, when the element identifiers of each level contained in the hierarchical path information are global policy, intrusion detection, and threat intelligence in sequence, and the preset hierarchical separation information is "#", the semantic identifier generated according to the sequential concatenation combination rules is global policy#intrusion detection#threat intelligence. In another embodiment, the preset hierarchical separation information can also be a word or abbreviation with special meaning, such as using a backslash plus a hierarchical word as hierarchical separation information. Different preset hierarchical separation information and combination rules can be flexibly set according to the naming specifications of the actual project, as long as the generated semantic identifiers are unique, hierarchically distinguishable and business readable throughout the entire system.

[0040] In this embodiment, semantic identifiers are generated by extracting and using preset hierarchical separation information to combine the identifiers of each hierarchical element. This achieves the transformation from the original path information to a standardized identifier, so that the hierarchical structure of the operation process can be compressed into a unique identifier that is easy to index and reference.

[0041] In one embodiment, the technical positioning parameters include positioning indication information and positioning value information. The positioning indication information is used to characterize the technical strategy used when locating the element to be operated, and the positioning value information is used to characterize the specific positioning data corresponding to the technical strategy.

[0042] In this embodiment, it should be noted that the technical positioning parameters include two parts: positioning indication information and positioning value information. Positioning indication information characterizes the technical strategy used when locating the element to be operated on, that is, it specifies the mechanism used to find and match page elements. Positioning value information characterizes the specific positioning data corresponding to the technical strategy, that is, the specific numerical value or expression used to uniquely identify the page element under this technical strategy. By splitting the technical positioning parameters into positioning indication information and positioning value information, a structured separation of the positioning strategy and the specific positioning data is achieved. In different automated testing frameworks or technical scenarios, positioning indication information and positioning value information can have various combinations. For example, when using a strategy based on element identifier positioning, the positioning indication information is the identifier positioning strategy, and the positioning value information is the identifier attribute value of the element in the page source code. When using a strategy based on document path expression positioning, the positioning indication information is the path expression positioning strategy, and the positioning value information is the complete path expression of the element in the document object model tree. When using a strategy based on Cascading Style Sheets (CSS) selectors, the positioning indication information is the selector positioning strategy, and the positioning value information is the corresponding selector expression.

[0043] It is understood that the optional positioning strategies in this embodiment include, but are not limited to: positioning by element identifier, positioning by element name, positioning by document path expression, positioning by Cascading Style Sheet selector, positioning by class name, positioning by link text, and positioning by tag name. In practical applications, any of the above positioning strategies can be flexibly selected as positioning indication information according to the specific front-end technology stack and element characteristics of the page under test, and the corresponding specific attribute values ​​can be used as positioning value information. The support of the above optional positioning strategies enables this embodiment to be compatible with the positioning mechanisms of different front-end frameworks and different automated testing tools, and has strong versatility.

[0044] Through the above structured definition, the technical positioning parameters can not only fully describe the positioning implementation of a page element, but also independently adjust the positioning strategy or positioning data, providing granular technical support for flexible modification of positioning information in subsequent configuration files.

[0045] In one embodiment, semantic identifiers and technical positioning parameters are associated and stored in a configuration file, including: Semantic identifiers are used as keys, and location indication information and location value information are used as associated values, stored in the configuration file in key-value pairs.

[0046] In this embodiment, it should be noted that during storage, the semantic identifier is used as the key, and the location indication information and location value information are used as associated values, stored in the configuration file in key-value pair form. This key-value pair structure establishes a precise one-to-one mapping relationship between the semantic identifier and the corresponding location technology parameters. The configuration file can implement this mapping in various formats. For example, the configuration file can be a JavaScript object representation JSON format file. In the JSON object, the semantic identifier is used as the property name, and the associated value contains both the location indication information and the location value information in the form of nested objects or arrays. The configuration file can also be in Extensible Markup Language (XML), YAML, or property file format, as long as it supports a key-value pair or similar mapping structure storage mechanism. Taking JSON format as an example, assuming the semantic identifier is global policy #intrusion detection #threat intelligence #add #name, the location indication information is identifier location policy, and the location value information is rule_name, then the key-value pair is represented in the JSON configuration file as follows: the semantic identifier string is used as the key name, and the associated value part can contain two subfields, one subfield recording the specific value of the location indication information, and the other subfield recording the specific value of the location value information.

[0047] Understandably, in actual automated testing projects, this configuration file can be created in a specific directory within the project structure, such as the `config` folder under the project root directory, to facilitate centralized management of all configuration files. The configuration file can be named `element_position_table.json` or use any other filename that identifies its purpose. By placing the configuration file in the project's standard configuration directory, the testing framework can load it uniformly during the initialization phase, and version control tools can easily track and manage changes to the configuration file, further improving configuration maintenance efficiency in collaborative team scenarios.

[0048] In this embodiment, by storing semantic identifiers and associated values ​​containing location indication information and location value information in the configuration file in the form of key-value pairs, centralized management and persistent storage of element location configuration are achieved, providing a clear data foundation for the calling and querying of target scripts and subsequent targeted modifications.

[0049] In one embodiment, the page element positioning determination method further includes: When executing the target script, the configuration file is queried through semantic identifiers to obtain the target key-value pairs corresponding to the semantic identifiers; Extract target location indication information and target location value information from target key-value pairs; The target positioning strategy is determined based on the target positioning indication information, and the element to be operated is located based on the target positioning value information and the target positioning strategy.

[0050] In this embodiment, it should be noted that during the execution of the target script, when the target script needs to interact with a certain element to be operated on, the target script obtains the semantic identifier corresponding to the current operation step and queries the configuration file through the semantic identifier. The configuration file can be a set of key-value pairs pre-loaded into memory or a structured file stored locally. Specifically, during the initialization phase of the target script, the contents of the configuration file can be read into memory all at once, for example, the configuration file can be parsed into a dictionary variable and stored. This dictionary variable uses the semantic identifier as the key and the corresponding technical positioning parameter as the value. During the execution of the target script, it can directly and quickly look up the corresponding positioning parameter from this memory dictionary based on the semantic identifier, without having to read and write files for each operation, thereby improving test execution efficiency. At the same time, when the contents of the configuration file are updated, the changes only need to be reloaded during the next script initialization to make the changes take effect.

[0051] Furthermore, the target script retrieves the target key-value pair corresponding to the semantic identifier from the configuration file. From this target key-value pair, it extracts target location indication information and target location value information. The target location indication information specifies the appropriate technical strategy to be used to locate the element to be operated on, while the target location value information provides the location data required by that strategy. Subsequently, based on the target location indication information, a target location strategy is determined, which corresponds to the location mechanism supported by the automated testing framework. For example, if the target location indication information indicates the use of an identifier location strategy, then the target location strategy is to find page elements by element identifiers; if the target location indication information indicates the use of a path expression location strategy, then the target location strategy is to match page elements by document path expressions. After determining the target location strategy, based on the target location value information and the target location strategy, the target element to be operated on is located, and subsequent interactions such as clicks and inputs are performed.

[0052] In this way, the target script does not rely on hard-coded positioning parameters in the code at runtime. Instead, it uses semantic identifiers as an intermediary to dynamically obtain positioning strategies and data from the configuration file, thus achieving runtime separation between test execution logic and element positioning configuration. When changes in the page structure require adjustments to element positioning parameters, only the record corresponding to the semantic identifier in the configuration file needs to be modified. There is no need to modify the business operation code of the target script, reducing maintenance costs and the risk of missed modifications.

[0053] In one embodiment, to more intuitively illustrate the improved code readability brought about by this embodiment, the following compares test code written without this embodiment with test code written using this embodiment. In the traditional implementation without this embodiment, the test code directly writes the location method of the page element to be operated into the operation statement. For example, the code to switch to the global policy page and enter the audit policy page might be written as: find the element with the value Global_Policy by using the identifier location method and click it, and then find the element with the value of the specified path expression by using the document path expression location method and click it. When the number of page elements increases and the operation steps become complex, the code will be filled with a large number of scattered location parameters, making it difficult to quickly understand the business process. However, with this embodiment, the test code uses semantic identifiers to refer to the elements to be operated. For example, the above operation is written as: find the location value corresponding to the semantic identifier Global_Policy by using the identifier location method and click it, and then find the location value corresponding to the semantic identifier Global_Policy#Audit_Policy by using the document path expression location method and click it. At this point, terms such as global strategy and audit strategy appearing in the code are consistent with the actual navigation label names on the business page. Test developers can understand the operational intent of the current step without having to view the page source code or locate the parameter table, and the business readability of the code is significantly improved.

[0054] In one embodiment, taking the scenario of adding threat intelligence rules in a network auditing system as an example, the specific application of this embodiment will be fully described. The operation process of this scenario includes the following steps: After logging into the system, click the Global Policy menu, click the Intrusion Detection submenu, click the Threat Intelligence tab, click the Add button, enter the rule name in the Name input box, select the Malicious IP type in the Type drop-down box, enter the IP address in the IP address input box, and finally click the OK button to complete the addition.

[0055] According to this embodiment, the operation levels involved in the operation process and the element identifiers associated with each level are first determined. The first level corresponds to the global policy menu, the second level corresponds to the intrusion detection submenu, the third level corresponds to the threat intelligence tab, the fourth level corresponds to the add button, and in the form area expanded by the add operation, the fifth level includes a name input box, a type drop-down box, an IP address input box, and an OK button. After obtaining the element identifiers of each level, the element identifiers of each level are combined sequentially using the preset level separator "#" to generate semantic identifiers for each element to be operated, such as "Global Policy#Intrusion Detection#Threat Intelligence#Add#Name", "Global Policy#Intrusion Detection#Threat Intelligence#Add#Type", "Global Policy#Intrusion Detection#Threat Intelligence#Add#IP Address", "Global Policy#Intrusion Detection#Threat Intelligence#Add#OK", etc.

[0056] Simultaneously, the technical positioning parameters for each element to be operated on are obtained, including positioning indication information and positioning value information. For example, the positioning indication information for the name input box is an identifier positioning strategy, and the positioning value information is the identifier attribute value of the input box in the page source code. The positioning indication information for the type dropdown box is a name positioning strategy, and its positioning value information is the corresponding element name attribute value. The positioning indication information for each menu and button can be an identifier positioning strategy or a document path expression positioning strategy, and the corresponding positioning value information is their respective identifier value or path expression.

[0057] Using the aforementioned semantic identifiers as keys, and the corresponding location indication information and location value information as associated values, these are stored in the configuration file as key-value pairs. The stored configuration file can contain the following mapping relationships: the semantic identifier "Global Policy" corresponds to its location parameters; the semantic identifier "Global Policy#Intrusion Detection" corresponds to its location parameters; the semantic identifier "Global Policy#Intrusion Detection#Threat Intelligence" corresponds to its location parameters; the semantic identifier "Global Policy#Intrusion Detection#Threat Intelligence#Add" corresponds to its location parameters; the semantic identifier "Global Policy#Intrusion Detection#Threat Intelligence#Add#Name" corresponds to its location parameters; the semantic identifier "Global Policy#Intrusion Detection#Threat Intelligence#Add#Type" corresponds to its location parameters; the semantic identifier "Global Policy#Intrusion Detection#Threat Intelligence#Add#IP Address" corresponds to its location parameters; and the semantic identifier "Global Policy#Intrusion Detection#Threat Intelligence#Add#OK" corresponds to its location parameters.

[0058] Within the target script, a function can be written to add threat intelligence rules. This function receives the rule name, type, and IP address as input parameters. Inside the function, it first logs into the system and waits for the page to load. Then, it sequentially queries the configuration file using each semantic identifier to obtain the corresponding location parameters and performs the corresponding click or input operation. For example, it queries the configuration file using the semantic identifier "Global Policy" to obtain its location indication and value information, then clicks it; it queries the configuration file using the semantic identifier "Global Policy#Intrusion Detection#Threat Intelligence" and clicks it; it queries the configuration file using the semantic identifier "Global Policy#Intrusion Detection#Threat Intelligence#Add#Name" and passes the rule name parameter to the input box, and so on, until the "OK" button is clicked.

[0059] When the front-end page of the network auditing system is redesigned and the location attributes of certain elements change (e.g., the identifier attribute value of the name input box changes), maintenance personnel only need to find the record with the semantic identifier "Global Policy#Intrusion Detection#Threat Intelligence#Add#Name" in the configuration file and update its location value to the new identifier attribute value. The add threat intelligence rule function in the test script does not require any code modification and will automatically adapt to the updated page the next time it is executed.

[0060] As can be seen from this complete application example, this embodiment transforms the hierarchical structure of page operation paths into semantic identifiers and centrally stores the scattered page element location parameters in the configuration file. In the test script, semantic identifiers replace hard-coded location parameters, realizing the separation of configuration and code, significantly improving the readability and maintainability of test code, and providing an efficient and stable element location management solution for large-scale automated testing in complex business scenarios.

[0061] In one embodiment, this embodiment can also be further applied to scenarios involving shared test cases. In an automated testing platform shared by multiple projects or teams, different projects or modules may share the same set of page operation flows. However, due to differences in front-end implementation or customization requirements, the technical positioning parameters of the element to be operated corresponding to the same semantic identifier may differ in different project versions. Through the configuration and code separation mechanism provided in this embodiment, separate configuration files can be maintained for different projects or environments, so that the same semantic identifier in each configuration file points to its corresponding technical positioning parameters. The shared test case code only uses semantic identifiers to write operation logic and does not contain any positioning data bound to a specific project environment. When executing tests, the corresponding configuration file is selected and loaded according to the current project or execution environment, thus achieving the reuse of the same set of test case code in different project environments, without the need to write and maintain test scripts separately for each project. When the front-end page of a certain project version changes, only the configuration file corresponding to that project version needs to be modified.

[0062] In this way, this embodiment not only solves the problems of scattered configuration and difficult maintenance within a single project, but also provides unified technical support for sharing test assets across projects and environments, further reducing the overall maintenance cost of the automated testing system.

[0063] In one embodiment, when executing an automated test script, situations may arise where locating the element to be operated on fails due to page loading delays, front-end fine-tuning, or dynamic changes in element attributes, caused by the currently read technical positioning parameters. To improve the robustness of the test script, a fallback strategy can be preset, configuring multiple sets of backup technical positioning parameters for the same semantic identifier, all stored in the associated values ​​corresponding to the same semantic identifier in a configuration file. When the target script reads the target technical positioning parameters from the configuration file based on the current semantic identifier and attempts to locate the element, if the location fails, the preset fallback strategy is followed to read the backup technical positioning parameters associated with that semantic identifier from the configuration file. The backup technical positioning parameters can be a combination of a set of alternative positioning indication information and positioning value information. For example, when the primary positioning strategy fails with identifier positioning, the fallback strategy can specify to try document path expression positioning, cascading style sheet selector positioning, or text content positioning, etc., in sequence. Based on the backup technical positioning parameters, the positioning and operation of the element to be operated on is retried according to its corresponding backup positioning strategy and backup positioning data. If a set of backup parameters is successfully located, the subsequent operation steps continue; if all backup parameters fail to be located, the failure information is recorded and the exception handling process is triggered. This rollback strategy can be preset to try parameters sequentially according to priority, or it can be preset to randomly select parameters or dynamically adjust the attempt order based on historical success rates.

[0064] By configuring multiple sets of backup positioning parameters and preset rollback strategies, the tolerance and execution stability of automated test scripts to page changes are effectively improved, test interruptions caused by the failure of a single element positioning method are reduced, and the reliability and adaptability of this embodiment in actual engineering applications are further enhanced.

[0065] In one embodiment, the page element positioning determination method further includes: Upon receiving a command to change the technical positioning parameters of the element to be operated, determine the target semantic identifier corresponding to the element to be operated; Based on the target semantic identifier, query the configuration file and locate the key-value pair in the configuration file that corresponds to the target semantic identifier and needs to be updated; The location indication information and / or location value information in the key-value pair to be updated are updated based on the change instruction.

[0066] In this embodiment, it should be noted that during the continuous maintenance of automated testing, the element positioning attributes of the front-end page may change due to version iterations. When a change instruction for the technical positioning parameters of the element to be operated is received, the target semantic identifier corresponding to the element to be operated is first determined. This target semantic identifier is the unique identifier of the element to be operated in the configuration file. The change instruction may carry updated positioning indication information or positioning value information, or both. After determining the target semantic identifier, the configuration file is queried based on the target semantic identifier to locate the key-value pair to be updated corresponding to the target semantic identifier in the configuration file. This key-value pair to be updated is the record currently storing the original positioning parameters of the element. Subsequently, the positioning indication information or positioning value information in the key-value pair to be updated is updated based on the change instruction, or both are updated simultaneously. The updated key-value pair replaces the original key-value pair and is saved to the configuration file. When the change command carries new location indication information, the location indication information in the key-value pair to be updated is replaced with the new location indication information; when the change command carries new location value information, the location value information in the key-value pair to be updated is replaced with the new location value information.

[0067] Using the above method, when element location parameters change, maintenance personnel only need to accurately locate the corresponding record in the configuration file using semantic identifiers and make targeted modifications, without having to traverse and modify each instance in multiple test scripts. This mechanism narrows the scope of location configuration maintenance to a single configuration file, enabling independent maintenance of location configuration and test code, reducing the risk of test failure due to missed modifications, and improving the long-term maintainability of automated test assets.

[0068] The page element location determination method provided in this application achieves at least the following technical effects: First, by separating and storing page element location configurations from test execution code, centralized management of location configurations is realized. When element location parameters need to be changed, only the corresponding record in the configuration file needs to be modified, without having to modify the code scattered in each test script, reducing maintenance costs and the risk of missed modifications. Second, by generating semantic identifiers with hierarchical and business meanings based on the hierarchical path information of the page operation flow, and using semantic identifiers to replace technical location parameters in writing test operation code, the business intent of the test scripts is clear and readable, and test developers can understand the operation flow without consulting the page source code. Third, by splitting technical location parameters into location indication information and location value information, structured separation of location strategies and location data is achieved, allowing the same semantic identifier to be flexibly configured with multiple location strategies and corresponding location data, improving the flexibility of element location. Fourth, by configuring backup technical location parameters for the same semantic identifier and pre-setting a fallback strategy, the robustness and execution stability of automated testing in response to page changes are improved. Fifth, by maintaining configuration files and test case code independently, the same set of test case code can be adapted to different projects or operating environments by switching configuration files, providing a technical foundation for sharing test assets across projects and further reducing the overall construction and maintenance costs of the automated testing system.

[0069] Figure 2 A schematic block diagram of an electronic device according to an embodiment of this application is shown. Figure 2 As shown, this application provides an electronic device that may include: Memory 10 is configured to store instructions; The processor 20 is configured to retrieve instructions from the memory 10 and, when executing the instructions, to implement the page element location determination method described above.

[0070] This application also provides a machine-readable storage medium storing instructions that cause a machine to execute the page element location determination method described above.

[0071] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the page element positioning determination method as described in the above embodiments.

[0072] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0073] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0074] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0075] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0076] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0077] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0078] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0079] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0080] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method of page element positioning determination, the method comprising: include: Obtain the hierarchical path information of the element to be operated on in the page operation process, as well as the technical positioning parameters of the element to be operated on. Generate a semantic identifier for the element to be operated on based on the hierarchical path information; The semantic identifier and the technical positioning parameter are associated and stored in a configuration file so that when the target script associated with the configuration file is executed, it can obtain the positioning information of the element to be operated based on the technical positioning parameter corresponding to the semantic identifier.

2. The method of claim 1, wherein, The step of obtaining the hierarchical path information of the element to be operated on in the page operation flow includes: Obtain the operation sequence included in the page operation process, wherein the operation sequence includes at least one operation level; According to the operation sequence, the element identifier associated with the element to be operated in each operation level is determined sequentially; The element identifiers are combined according to the operation sequence to generate the hierarchical path information of the element to be operated on.

3. The method for determining page element positioning according to claim 1, characterized in that, The step of generating a semantic identifier for the element to be operated on based on the hierarchical path information includes: Extract the identifiers of each level of elements contained in the hierarchical path information; According to the preset combination rules, the extracted element identifiers at each level are combined using preset hierarchical separation information to generate the semantic identifier of the element to be operated.

4. The method for determining page element positioning according to claim 1, characterized in that, The technical positioning parameters include positioning indication information and positioning value information. The positioning indication information is used to characterize the technical strategy used when positioning the element to be operated, and the positioning value information is used to characterize the specific positioning data corresponding to the technical strategy.

5. The method of claim 4, wherein, The step of associating and storing the semantic identifier and the technical positioning parameters in a configuration file includes: The semantic identifier is used as the key, and the location indication information and location value information are used as associated values, stored in the configuration file in the form of key-value pairs.

6. The method of claim 5, wherein, Also includes: When the target script is executed, the configuration file is queried through the semantic identifier to obtain the target key-value pair corresponding to the semantic identifier; Extract target location indication information and target location value information from the target key-value pairs; Based on the target positioning indication information, a target positioning strategy is determined, and based on the target positioning value information and the target positioning strategy, the element to be operated is located.

7. The method of claim 5, wherein, Also includes: Upon receiving an instruction to change the technical positioning parameters of the element to be operated, determine the target semantic identifier corresponding to the element to be operated; Based on the target semantic identifier, query the configuration file to locate the key-value pair in the configuration file that corresponds to the target semantic identifier and needs to be updated; The location indication information and / or location value information in the key-value pair to be updated are updated based on the change instruction.

8. An electronic device, comprising: include: The memory is configured to store instructions; A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the page element location determination method according to any one of claims 1 to 7.

9. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to perform the page element location determination method according to any one of claims 1 to 7.

10. A computer program product, characterised in that, The method includes a computer program that, when executed by a processor, implements the page element positioning determination method according to any one of claims 1 to 7.

Images