CN114706796A - UI (user interface) automatic diff assertion method and device based on DOM (document object model) tree structure - Google Patents
UI (user interface) automatic diff assertion method and device based on DOM (document object model) tree structure Download PDFInfo
- Publication number
- CN114706796A CN114706796A CN202210633670.1A CN202210633670A CN114706796A CN 114706796 A CN114706796 A CN 114706796A CN 202210633670 A CN202210633670 A CN 202210633670A CN 114706796 A CN114706796 A CN 114706796A
- Authority
- CN
- China
- Prior art keywords
- file
- baseline
- test
- assertion
- web page
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides a UI (user interface) automatic diff assertion method and device based on a DOM (document object model) tree structure, wherein the method comprises the following steps: in the UI automatic test execution process, when the test case code is run for the first time, establishing a baseline file on the premise of ensuring that the product has no bug; when the same test case code is repeatedly run, a state snapshot file is generated in the corresponding operation step; and comparing the state snapshot file with the baseline file, and judging that the test is passed when the comparison result meets the preset condition. The device uses the method. The invention ensures that testers do not need to manually write the assertion of the page, thereby improving the writing efficiency of the use case; meanwhile, by comparing the state snapshot file with the baseline file, the comparison mode is simpler compared with the manual compiling assertion, the comparison information is more comprehensive, the omission condition is not easy to occur, and the test efficiency and the test reliability are further improved.
Description
Technical Field
The invention relates to the technical field of software testing, in particular to a UI (user interface) automatic diff assertion method and device based on a DOM (document object model) tree structure.
Background
In UI automation test execution, the following technical rules are often followed: and automatically simulating that a user operates a page control on a page of the tested product, and after a section of operation is executed as expected, judging whether page feedback meets the expectation or not.
The automation program shown in fig. 1 and 2 simulates classroom interaction check-in service on a page, and needs the following steps:
the operation is as follows:
1. opening a check-in card by a program object of a teacher role;
2. inputting sign-in prompting words and sign-in countdown seconds on the sign-in card by the program object of the teacher role;
3. the program object of the teacher role clicks the send sign-in button.
Assertion:
a. whether the program object of the student role receives the check-in card from the teacher;
b. whether the prompt language of the check-in card received by the program object of the student role is consistent with that written by the teacher or not;
c. whether the countdown of the check-in card received by the program object of the student role is consistent with the filling of the teacher or not;
d. the program object of the student character waits for a few seconds and the countdown of the check-in card is decremented as expected.
Corresponding to the above-described operation steps, the pseudo code is as follows:
class TestCheckin:
def test_teacher_send_checkin_card(self):
teacher.open_checkin_card()
input check in the same place (content = 'each student starts to sign in')
teacher.setting_checkin_timeout(seconds=30)
teacher.send_checkincard()
student.assert_received_checkin_card()
student. assert _ the _ checkpoint _ card _ the (content = "each student started to sign in")
student.assert_the_checkin_card_timeout(30)
time.sleep(3)
student.assert_the_checkin_card_timeout(27)
Checking no error, the student executes the check-in operation
student.action_checkin()
The above code writing modes are performed alternately when writing the UI automation test case, and after writing a section of operation steps, a part of assertions needs to be written for the operation steps, which has the following disadvantages:
1. sometimes, one operation causes multi-dimensional change of the page, and the assertion needs to be written manually, so that the efficiency is not high;
2. omission occurs when the assertions are manually written, the test coverage is not high, and the case is easy to fail;
3. if the test case process has variable maintenance, the workload of the maintenance case is very huge.
Disclosure of Invention
Aiming at the defects of the prior art, the invention provides a UI automation diff assertion method and device based on a DOM tree structure, and solves the defects that when a UI automation test case in the prior art is used, assertion needs to be written manually, the efficiency is low, omission occurs easily, and the case is invalid.
The technical scheme of the invention is realized as follows: a UI automation diff assertion method based on DOM tree structure is characterized by comprising the following steps:
in the UI automatic test execution process, when the test case code is run for the first time, establishing a baseline file on the premise of ensuring that the product has no bug;
when the same test case code is repeatedly run, a state snapshot file is generated in the corresponding operation step;
comparing the state snapshot file with the baseline file, and judging that the test is passed when the comparison result meets the preset condition;
in the UI automatic test execution process, when the test case code is run for the first time, on the premise of ensuring that the product has no bug, the step of establishing the baseline file comprises the following steps:
in the UI automatic test execution process, acquiring a character string object of a dom structure of a Web page;
converting the character string object with the dom structure into a json format;
judging whether a baseline file exists or not, and if not, establishing;
saving the baseline state into a JSON file;
if the baseline file does not exist, newly building and writing baseline data;
if the baseline file exists but is empty, writing baseline data;
generating a baseline file according to the baseline data and the correct state value of the Web page object;
when the same test case code is repeatedly run, the step of generating the state snapshot file in the corresponding operation step comprises the following steps:
injecting a diff assertion buried point at an operation step needing assertion;
and when the same test case code is repeatedly operated, generating a state snapshot file according to the actual state value of the Web page object.
In one embodiment, the step of comparing the state snapshot file with the baseline file and determining that the test is passed when the comparison result meets the preset condition includes:
performing diff comparison on the baseline file and the state snapshot file in the whole Web page range;
and when the comparison results are consistent, judging that the test is passed.
In one embodiment, the step of determining that the test is passed when the comparison result is consistent includes:
acquiring a noise element feature library of a Web page;
judging the threshold value of each noise element in the Web page corresponding to the state snapshot file according to the noise element feature library of the Web page;
and when the threshold value of each noise element accords with the noise control rule, judging that the test is passed.
In one embodiment, before the step of generating the baseline file according to the baseline data and the correct state value of the Web page object, the method further includes:
when business modification or use case maintenance is carried out, the baseline data is newly established at the corresponding operation step.
The invention also provides a UI automation diff assertion device based on the DOM tree structure, which comprises:
the establishing module is used for establishing a baseline file on the premise of ensuring that a product has no bug when the test case code is initially operated in the UI automation test execution process;
the generating module is used for generating a state snapshot file in the corresponding operation step when the same test case code is repeatedly run;
the comparison module is used for comparing the state snapshot file with the baseline file and judging that the test is passed when the comparison result meets the preset condition;
the establishing module is specifically configured to:
in the UI automatic test execution process, acquiring a character string object of a dom structure of a Web page;
converting the character string object with the dom structure into a json format;
judging whether a baseline file exists or not, and if not, establishing the baseline file;
saving the baseline state into a JSON file;
if the baseline file does not exist, newly building and writing baseline data;
if the baseline file exists but is empty, writing baseline data;
generating a baseline file according to the baseline data and the correct state value of the Web page object;
the generation module is specifically configured to:
injecting diff assertion buried points at operation steps needing assertion;
when the same test case code is repeatedly operated, a state snapshot file is generated according to the actual state value of the Web page object;
the comparison module is specifically used for:
performing diff comparison on the baseline file and the state snapshot file in the whole Web page range;
and when the comparison results are consistent, judging that the test is passed.
The invention also provides computer equipment which comprises a memory, a processor and a computer program which is stored on the memory and can run on the processor, wherein the processor realizes the UI automation diff assertion method based on the DOM tree structure when executing the computer program.
The invention also provides a computer storage medium, on which a computer program is stored, and when the program is executed by a processor, the UI automation diff assertion method based on the DOM tree structure is realized.
In the embodiment of the invention, in the UI automatic test execution process, a baseline file is established on the premise of ensuring that a product has no bug when a test case code is initially operated, and a state snapshot file is generated in a corresponding operation step when the same test case code is repeatedly operated; and comparing the state snapshot file with the baseline file, and judging that the test is passed when the comparison result meets the preset condition. The tester does not need to manually write the assertion of the page, and only needs to put energy on the specific operation steps of writing the use case, so that the writing efficiency of the use case is improved; on the other hand, the state snapshot files correspond to the operation steps one to one, the state snapshot files are compared with the baseline files, the comparison mode is simpler compared with the manual compiling assertion, the comparison information is more comprehensive, the omission condition is not prone to occurring, and the testing efficiency and the testing reliability are further improved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.
FIG. 1 is a program interface diagram of a teacher's role in simulating classroom interaction check-in services in the background of the present invention;
FIG. 2 is a program interface diagram of a student role in simulating a classroom interaction check-in service in accordance with the background of the invention;
FIG. 3 is a flowchart of a UI automation diff assertion method based on DOM tree structure according to the first embodiment of the present invention;
FIG. 4 is a flowchart of a UI automation diff assertion method based on DOM tree structure according to a second embodiment of the present invention;
FIG. 5 is a flow chart of a preferred embodiment of S212 in a second example of the present invention;
FIG. 6 is a diagram of a baseline file corresponding to a simulated classroom interactive check-in service in accordance with a second embodiment of the present invention;
FIG. 7 is a block diagram illustrating a UI automation diff assertion apparatus based on a DOM tree structure according to a third embodiment of the present invention;
fig. 8 is a schematic diagram of the internal structure of a computer according to still another embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be described clearly and completely with reference to the accompanying drawings in the embodiments of the present invention, and it is to be understood that the described embodiments are only a part of the embodiments of the present invention, and not all embodiments, and well-known modules, units and their connections, links, communications or operations with each other are not shown or described in detail. Furthermore, the described features, architectures, or functions can be combined in any manner in one or more implementations. It will be understood by those skilled in the art that the various embodiments described below are illustrative only and are not intended to limit the scope of the present invention. It will also be readily understood that the modules or units or processes of the embodiments described herein and illustrated in the figures can be combined and designed in a wide variety of different configurations. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The first embodiment:
referring to fig. 3, an embodiment of the present invention discloses a UI automation diff assertion method based on a DOM tree structure, including:
and S11, in the UI automation test execution process, when the test case code is run for the first time, establishing a baseline file on the premise of ensuring that the product has no bug.
In this embodiment, the automated testing refers to automation of software testing, where the software testing is to run a system or an application under a preset condition, and evaluate a running result, where the preset condition includes a normal condition and an abnormal condition.
The automatic test of UI (User Interface Design) is a means for simulating case automation operation from an Interface to the tested software, and can achieve end-to-end automation effect by means of the automatic test of the UI and simulate the most real behavior of a User on the software.
The Test Case (Test Case) refers to the description of a Test task performed on a specific software product, and embodies Test schemes, methods, techniques and strategies. The contents of the test object, the test environment, the input data, the test steps, the expected results, the test scripts and the like are included, and finally, a document is formed. Simply considered, a test case is a set of test inputs, execution conditions, and expected results tailored for a particular purpose to verify whether a particular software requirement is met.
An assertion (assertion) is a first-order logic (e.g., a logical predicate whose result is true or false) in a program, and is intended to represent a result that is expected by a developer of the verification software-when the program is executed to the position of the assertion, the corresponding assertion should be true. If the assertion is not true, the program may halt execution and provide an error message.
In the step, the baseline file is established on the premise that the code is operated for the first time and no bug exists, so that the reliability of the baseline file is guaranteed, and the baseline file can be used for comparison with the state snapshot file in the subsequent process.
And S12, when the same test case code is repeatedly run, generating a state snapshot file in the corresponding operation step.
Under the conditions of UI version updating, UI version changing and the like, generally, the same test case is needed to be adopted to carry out UI automatic test again, software testers can inject assertion embedding points at corresponding operation steps according to needs, and when test case codes are repeatedly operated, state snapshot files are automatically generated according to operation states corresponding to the operation steps of injecting the assertion embedding points.
And S13, comparing the state snapshot file with the baseline file, and judging that the test is passed when the comparison result meets the preset condition.
The preset condition of this embodiment may be automatically determined, for example, the state snapshot file is consistent with the baseline file, or may be determined manually by a tester.
In the embodiment of the invention, in the UI automatic test execution process, a baseline file is established on the premise of ensuring that a product has no bug when a test case code is initially operated, and a state snapshot file is generated in a corresponding operation step when the same test case code is repeatedly operated; and comparing the state snapshot file with the baseline file, and judging that the test is passed when the comparison result meets the preset condition. The tester does not need to manually write the assertion of the page, and only needs to put energy on the specific operation steps of writing the use case, so that the writing efficiency of the use case is improved; on the other hand, the state snapshot files correspond to the operation steps one to one, the state snapshot files are compared with the baseline files, the comparison mode is simpler compared with the manual compiling assertion, the comparison information is more comprehensive, the omission condition is not prone to occurring, and the testing efficiency and the testing reliability are further improved.
Second embodiment:
referring to fig. 4 to fig. 6, another UI automation diff assertion method based on DOM tree structure is disclosed in the embodiments of the present invention.
First, the terms and abbreviations that may be involved in the embodiments of the present invention are explained:
resources _ path, a base line file storing root directory;
second _ dir: storing a secondary directory in the baseline file;
file _ name: naming of the baseline file;
align _ path: a list of noise points dom;
tag, namely obtaining the positioning mode of the evidence dom, and defaulting to tag;
element: and (4) defaulting the positioning expression of the evidence-obtaining dom to html and the whole page.
The UI automation diff assertion method based on the DOM tree structure comprises the following steps:
s201, in the process of executing the UI automatic test, acquiring a character string object of a dom structure of the Web page.
The data in this step is specifically:
html_string = self.web_getattribute(tag=tag, element=element, index=index,
attribute_name='innerHTML').json().get('data')
s202, converting the character string object with the dom structure into a json format.
The data in this step is specifically:
output_json=json.dumps(html_to_json.convert(html_string), ensure_ascii=False)
second_dir_resource = os.path.join(resources_path, second_dir)
s203, judging whether the baseline file exists or not, and if not, establishing.
And S204, saving the baseline state into a JSON file.
Due to the particularity of the DOM structure of the web page, the state base line is converted into the JSON format, so that various attributes of the state can be well expressed, and subsequent comparison and judgment are facilitated. The data in this step is specifically:
file_path = os.path.join(second_dir_resource, file_name)
if not os.path.exists(second_dir_resource):
format _ info _ log (f "folder: { second _ dir _ resource } does not exist, create folder = '#708090')
os.mkdir(second_dir_resource)
if not os.path.exists(file_path):
And S205, if the baseline file does not exist, newly building and writing baseline data.
The data in this step is specifically:
format _ info _ log (f "file: { file _ path } does not exist, data is written { output _ json }", color = '#708090')
with open(file_path, mode='w', encoding='utf-8') as f:
f.write(str(output_json))
with open(file_path, 'r+', encoding='utf-8') as f:
And S206, if the baseline file exists but is empty, writing baseline data.
The data in this step is specifically:
if not f.read():
format _ info _ log (f ' file { file _ path } content is empty, rewrite: = ' #708090')
f.write(str(output_json))
with open(file_path, "r", encoding='utf-8') as f:
flag_data = f.read()
And S207, when the service is modified or the use case is maintained, newly building baseline data at the corresponding operation step.
In the case of service modification or use case maintenance, the embodiment only needs to establish the base line again without modifying the use case, thereby greatly saving the use case maintenance time.
And S208, generating a baseline file according to the baseline data and the correct state value of the Web page object.
In this step, a DOM comparison baseline file to be compared may be automatically entered, and for example, the form of the baseline file is shown in fig. 6, relative to the classroom interaction check-in service mentioned in the background art. The data of this step specifically includes:
flag_data = json.loads(flag_data)
s209, inject diff assertion buried point at the operation step that needs assertion.
Under the conditions of UI version updating, UI version changing and the like, the UI automation test is generally required to be carried out again by adopting the same test case, and software testers can inject diff assertion burial points at corresponding operation steps according to the requirements. The data in this step is specifically:
def diff_dom_state(second_dir, file_name,
index=0, ignore_path=None, moment='after',
funName='diff_assert_dom',tag=tag, element=html):
"""
explanations of terms and abbreviations involved in this step:
tag: tag for evidence collection
element for obtaining evidence
second _ dir: service module secondary directory
Dom storage directory of file _ name
Align _ path: ignoring the evidentiary elements, noise removal
moment: the moment of insertion of the device, before or after operation, after defaults
funName: diff _ assert _ dom method injection
"""
def wrapper(fun):
def inner(*args, **kwargs):
cls = args[0]
if moment == 'after':
value = fun(*args, **kwargs)
methodcaller(funName, tag=tag, element=element, index=index, ignore_path=ignore_path,
second_dir=second_dir,
file_name=file_name)(cls)
if moment == 'before':
methodcaller(funName, tag=tag, element=element, index=index, ignore_path=ignore_path,
second_dir=second_dir,
file_name=file_name)(cls)
value = fun(*args, **kwargs)
return value
return inner
return wrapper
And S210, when the same test case code is repeatedly operated, generating a state snapshot file according to the actual state value of the Web page object.
And when the test case code is repeatedly operated, automatically generating a state snapshot file of the Web page object according to the operation state corresponding to the operation step of injecting the diff assertion buried point. The data of this step specifically includes:
current_data = json.loads(output_json)
s211, carrying out diff comparison on the baseline file and the state snapshot file in the whole Web page range.
The diff comparison of this embodiment can specify a specific DOM, if the option can be specified without relation to other elements.
S212, when the comparison result is consistent, the test is judged to be passed.
The data in this step is specifically:
result=Jcompare(print_before=False).compare(flag_data,current_data, ignore_list_seq=False,ignore_path=ignore_path)
logger.info(f'compare_result:{result}')
logo. info (f 'contrasting filename { file _ path }')
if not result:
Format _ info _ log (f 'dom contrast is inconsistent, contrast file { file _ path }', level = 'error')
else:
logo. info (f 'element dom tree base line comparison success, comparison file { file _ path }')
Usually, after a series of operations, the Web page presents the result expected to be seen by the user to the user, corresponding to the classroom interaction check-in service, and after the check-in is initiated, the normal expected result is that the student accurately receives the check-in box; the result can abstract the page object into a state from the program perspective, different operations can present different states, after a certain series of operations of each time, the states of the page object are kept consistent, the corresponding operation steps are indicated to be effective, on the contrary, if the same state as the baseline file is not achieved after a certain operation step, the feedback state of the page object in the next time is not in accordance with the expectation, at the moment, the program can be determined to have bug, and the automatic test fails.
Referring to fig. 5, as a preferred but non-limiting solution, S212 further includes S2121-S2123, wherein:
s2121, acquiring a noise element feature library of the Web page.
Since the state of some Web pages may change with the operation, but the corresponding change is expected, in order to improve the stability of the test case, and to distinguish from the change which is not expected, the embodiment further generates different sets of noisy elements for different programs through the noisy element feature library. For example, compared to the classroom interaction check-in service, the time for different students to click on check-in is different, and different check-in times may cause a change in the state of the Web page, and the change is considered to be expected, and the automated test may be considered to be successful. The noisy element feature library is automatically detected and provides a different set of noisy elements corresponding to different programs.
And S2122, judging the threshold value of each noise element in the Web page corresponding to the state snapshot file according to the noise element feature library of the Web page.
In this step, the threshold of the corresponding noise element in each set may be the same or may be customized, for example, the threshold may be a proportional value of the area where the noise is located relative to the entire Web page, or may be a messy code or a page display exception associated with a specific program.
And S2123, judging that the test is passed when the threshold value of each noise element accords with the noise control rule.
The noise control rule of this embodiment may include: complete exclusion, fuzzy matching, or regular matching rules.
For example, with respect to the classroom interaction check-in service, the code data after the injection in the embodiment of the present invention is:
class TestCheckin:
def test_teacher_send_checkin_card(self):
teacher.open_checkin_card()
input check in the same place (content = 'each student starts to sign in')
teacher.setting_checkin_timeout(seconds=30)
teacher.send_checkin_card()
# injection: comparing assertion to page state before student performs check-in operation
@diff_dom_state(second_dir='interactions_receiver_checkin',
moment='before',
file _ name = 'student to sign in status acquisition')
student.action_checkin()
# injection: before the teacher executes result check-in operation, the page state is asserted and compared, and check-in data of student operation can be obtained
@diff_dom_state(second_dir='interactions_launcher_checkin',
moment='before',
file _ name = 'student to sign in status acquisition')
teacher.stop_checkin()
The embodiment of the invention converts the state base line into the JSON format, can well express various attributes of the state, and is beneficial to subsequent comparison and judgment; meanwhile, under the condition of service modification or case maintenance, the base line is established again without modifying the case, so that the case maintenance time is greatly saved. In addition, the embodiment provides a controllable noise point selection scheme, so that the stability of the test case is improved, thresholds with different accuracies can be configured corresponding to different test services, and the stability of the whole case is improved compared with that of single element verification; finally, the diff comparison default range of the embodiment of the invention is the whole Web page, the assertion is large and complete, the test points can not be missed, and the test reliability is improved.
The third embodiment:
referring to fig. 7, the present invention further provides a UI automation diff assertion apparatus 100 based on DOM tree structure, including a building module 110, a generating module 120, and a comparing module 130, wherein:
the establishing module 110 is connected with the generating module 120 and is used for establishing a baseline file on the premise of ensuring that a product has no bug when the test case code is initially run in the UI automation test execution process;
the generating module 120 is connected to the comparing module 130, and is configured to generate a state snapshot file in a corresponding operation step when the same test case code is repeatedly executed;
the comparison module 130 is configured to compare the state snapshot file with the baseline file, and determine that the test is passed when a comparison result meets a preset condition.
In an embodiment of the present invention, the establishing module 110 is specifically configured to:
in the UI automatic test execution process, acquiring a character string object of a dom structure of a Web page;
converting the character string object with the dom structure into a json format;
judging whether a baseline file exists or not, and if not, establishing the baseline file;
saving the baseline state into a JSON file;
if the baseline file does not exist, newly building and writing baseline data;
if the baseline file exists but is empty, writing baseline data;
and generating a baseline file according to the baseline data and the correct state value of the Web page object.
The generating module 120 is specifically configured to:
injecting a diff assertion buried point at an operation step needing assertion;
and when the same test case code is repeatedly operated, generating a state snapshot file according to the actual state value of the Web page object.
The comparison module 130 is specifically configured to:
performing diff comparison on the baseline file and the state snapshot file in the whole Web page range;
and when the comparison results are consistent, judging that the test is passed.
The modules of this embodiment correspond to the steps of the two method embodiments one-to-one, and are not described here.
In the embodiment of the invention, in the UI automatic test execution process, a baseline file is established on the premise of ensuring that a product has no bug when a test case code is initially operated, and a state snapshot file is generated in a corresponding operation step when the same test case code is repeatedly operated; and comparing the state snapshot file with the baseline file, and judging that the test is passed when the comparison result meets the preset condition. The tester does not need to manually write the assertion of the page, and only needs to put energy on the specific operation steps of writing the use case, so that the writing efficiency of the use case is improved; on the other hand, the state snapshot files correspond to the operation steps one to one, the state snapshot files are compared with the baseline files, the comparison mode is simpler compared with the manual compiling assertion, the comparison information is more comprehensive, the omission condition is not prone to occurring, and the testing efficiency and the testing reliability are further improved.
It will be clear to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be performed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to perform all or part of the above described functions. For the specific working processes of the system, the apparatus and the unit described above, reference may be made to the corresponding processes in the foregoing method embodiments, and details are not described here again.
Embodiments of the present invention further provide a computer storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the UI automation diff assertion method based on the DOM tree structure in the above embodiments.
It will be understood by those skilled in the art that all or part of the processes of the methods according to the above embodiments may be implemented by instructing relevant hardware by a computer program, and the computer program may be stored in a non-volatile computer-readable storage medium, and when executed, may include the processes of the embodiments of the UI automatic diff assertion method according to the DOM tree structure. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
Alternatively, the integrated unit of the present invention may be stored in a computer-readable storage medium if it is implemented in the form of a software functional module and sold or used as a separate product. Based on such understanding, the technical solutions of the embodiments of the present invention or portions thereof that contribute to the related art may be embodied in the form of a software product, where the computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which may be a personal computer, a terminal, or a network device) to execute all or part of the methods of the embodiments of the present invention. And the aforementioned storage medium includes: a removable storage device, a RAM, a ROM, a magnetic or optical disk, or various other media that can store program code.
Corresponding to the computer storage medium, in one embodiment, there is also provided a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the DOM tree structure based UI automation diff assertion method in the embodiments.
The computer device may be a terminal, and its internal structure diagram may be as shown in fig. 8. The computer device comprises a processor, a memory, a network interface, a display screen and an input device which are connected through a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a method for UI automated diff assertion based on DOM tree structures. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on the shell of the computer equipment, an external keyboard, a touch pad or a mouse and the like.
In the embodiment of the invention, in the process of executing the UI automatic test, a baseline file is established on the premise of ensuring that a product has no bug when the test case code is initially operated, and a state snapshot file is generated in a corresponding operation step when the same test case code is repeatedly operated; and comparing the state snapshot file with the baseline file, and judging that the test is passed when the comparison result meets the preset condition. The tester does not need to manually write the assertion of the page, and only needs to put energy on the specific operation steps of writing the use case, so that the writing efficiency of the use case is improved; on the other hand, the state snapshot files correspond to the operation steps one to one, the state snapshot files are compared with the baseline files, the comparison mode is simpler compared with the manual compiling assertion, the comparison information is more comprehensive, the omission condition is not prone to occurring, and the testing efficiency and the testing reliability are further improved.
The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above examples only show some embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.
Claims (7)
1. A UI automation diff assertion method based on DOM tree structure is characterized by comprising the following steps:
in the UI automatic test execution process, when the test case code is run for the first time, establishing a baseline file on the premise of ensuring that the product has no bug;
when the same test case code is repeatedly run, a state snapshot file is generated in the corresponding operation step;
comparing the state snapshot file with the baseline file, and judging that the test is passed when the comparison result meets the preset condition;
in the UI automatic test execution process, when the test case code is run for the first time, on the premise of ensuring that the product has no bug, the step of establishing the baseline file comprises the following steps:
in the UI automatic test execution process, acquiring a character string object of a dom structure of a Web page;
converting the character string object with the dom structure into a json format;
judging whether a baseline file exists or not, and if not, establishing the baseline file;
saving the baseline state into a JSON file;
if the baseline file does not exist, newly building and writing baseline data;
if the baseline file exists but is empty, writing baseline data;
generating a baseline file according to the baseline data and the correct state value of the Web page object;
when the same test case code is repeatedly run, the step of generating the state snapshot file in the corresponding operation step comprises the following steps:
injecting a diff assertion buried point at an operation step needing assertion;
and when the same test case code is repeatedly operated, generating a state snapshot file according to the actual state value of the Web page object.
2. The method of claim 1, wherein the step of comparing the state snapshot file with the baseline file and determining that the test is passed when the comparison result meets a predetermined condition comprises:
performing diff comparison on the baseline file and the state snapshot file in the whole Web page range;
and when the comparison results are consistent, judging that the test is passed.
3. The method of claim 2, wherein the step of determining that the test passes when the comparison result is consistent comprises:
acquiring a noise element feature library of a Web page;
judging the threshold value of each noise element in the Web page corresponding to the state snapshot file according to the noise element feature library of the Web page;
and when the threshold value of each noise element accords with the noise control rule, judging that the test is passed.
4. The method of claim 3, wherein the step of generating a baseline file based on the baseline data and the correct state value of the Web page object is preceded by the step of:
when business modification or use case maintenance is carried out, the baseline data is newly established at the corresponding operation step.
5. A UI automation diff assertion apparatus based on DOM tree structure, comprising:
the establishing module is used for establishing a baseline file on the premise of ensuring that a product has no bug when a test case code is initially operated in the UI automatic test execution process;
the generating module is used for generating a state snapshot file in the corresponding operation step when the same test case code is repeatedly run;
the comparison module is used for comparing the state snapshot file with the baseline file and judging that the test is passed when the comparison result meets the preset condition;
the establishing module is specifically configured to:
in the UI automatic test execution process, acquiring a character string object of a dom structure of a Web page;
converting the character string object with the dom structure into a json format;
judging whether a baseline file exists or not, and if not, establishing the baseline file;
saving the baseline state into a JSON file;
if the baseline file does not exist, newly building and writing baseline data;
if the baseline file exists but is empty, writing baseline data;
generating a baseline file according to the baseline data and the correct state value of the Web page object;
the generation module is specifically configured to:
injecting a diff assertion buried point at an operation step needing assertion;
when the same test case code is repeatedly operated, a state snapshot file is generated according to the actual state value of the Web page object;
the comparison module is specifically configured to:
performing diff comparison on the baseline file and the state snapshot file in the whole Web page range;
and when the comparison results are consistent, judging that the test is passed.
6. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the DOM tree structure based UI automation diff assertion method of any one of claims 1 to 4 when executing the computer program.
7. A computer storage medium having stored thereon a computer program, wherein the program when executed by a processor implements the DOM tree structure based UI automation diff assertion method as claimed in any of claims 1 to 4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210633670.1A CN114706796A (en) | 2022-06-07 | 2022-06-07 | UI (user interface) automatic diff assertion method and device based on DOM (document object model) tree structure |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210633670.1A CN114706796A (en) | 2022-06-07 | 2022-06-07 | UI (user interface) automatic diff assertion method and device based on DOM (document object model) tree structure |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114706796A true CN114706796A (en) | 2022-07-05 |
Family
ID=82178130
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210633670.1A Pending CN114706796A (en) | 2022-06-07 | 2022-06-07 | UI (user interface) automatic diff assertion method and device based on DOM (document object model) tree structure |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114706796A (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070234293A1 (en) * | 2005-12-12 | 2007-10-04 | Archivas, Inc. | Automated software testing framework |
| CN109189686A (en) * | 2018-08-30 | 2019-01-11 | 中国平安人寿保险股份有限公司 | Automation regression testing method, apparatus, storage medium and computer equipment |
| CN110795325A (en) * | 2019-10-30 | 2020-02-14 | 江苏满运软件科技有限公司 | Visual point burying method, device, equipment and storage medium |
| CN112148579A (en) * | 2019-06-26 | 2020-12-29 | 腾讯科技（深圳）有限公司 | User interface testing method and device |
| CN112445693A (en) * | 2019-08-28 | 2021-03-05 | 腾讯科技（深圳）有限公司 | Page update detection method, device, equipment and storage medium |
| CN114168486A (en) * | 2021-12-27 | 2022-03-11 | 深圳前海微众银行股份有限公司 | Interface automation test method, device, medium, device, and program |
-
2022
- 2022-06-07 CN CN202210633670.1A patent/CN114706796A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070234293A1 (en) * | 2005-12-12 | 2007-10-04 | Archivas, Inc. | Automated software testing framework |
| CN109189686A (en) * | 2018-08-30 | 2019-01-11 | 中国平安人寿保险股份有限公司 | Automation regression testing method, apparatus, storage medium and computer equipment |
| CN112148579A (en) * | 2019-06-26 | 2020-12-29 | 腾讯科技（深圳）有限公司 | User interface testing method and device |
| CN112445693A (en) * | 2019-08-28 | 2021-03-05 | 腾讯科技（深圳）有限公司 | Page update detection method, device, equipment and storage medium |
| CN110795325A (en) * | 2019-10-30 | 2020-02-14 | 江苏满运软件科技有限公司 | Visual point burying method, device, equipment and storage medium |
| CN114168486A (en) * | 2021-12-27 | 2022-03-11 | 深圳前海微众银行股份有限公司 | Interface automation test method, device, medium, device, and program |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20210334093A1 (en) | Automating Identification of Code Snippets for Library Suggestion Models | |
| US11354225B2 (en) | Automating identification of test cases for library suggestion models | |
| US11494181B2 (en) | Automating generation of library suggestion engine models | |
| US10162611B2 (en) | Method and apparatus for business rule extraction | |
| Kim et al. | Industrial application of concolic testing on embedded software: Case studies | |
| Monteiro et al. | Bounded model checking of C++ programs based on the Qt cross‐platform framework | |
| US20170371630A1 (en) | Globalization template manager for automated globalization enablement on development operations | |
| Salehnamadi et al. | Groundhog: An automated accessibility crawler for mobile apps | |
| CN111752841A (en) | Single test simulation method, device, equipment and computer readable storage medium | |
| Planas et al. | Lightweight and static verification of UML executable models | |
| CN114706796A (en) | UI (user interface) automatic diff assertion method and device based on DOM (document object model) tree structure | |
| Chen et al. | Self-adaptive architecture evolution with model checking: A software cybernetics approach | |
| Gerasimou et al. | On software modernisation due to library obsolescence | |
| CN116860324B (en) | Development data processing method, development data processing apparatus, and readable storage medium | |
| Al-Azzoni et al. | A framework for the regression testing of model-to-model transformations | |
| Gerdes | Developing applications to automatically grade introductory visual basic courses | |
| Shahrokni et al. | Towards a framework for specifying software robustness requirements based on patterns | |
| KR102637045B1 (en) | Method for supporting data collection | |
| Nguyen et al. | A Graph Analysis Based Approach for Specification-Driven Testing of Model Transformations | |
| US8707101B2 (en) | Verification of operating self modifying code | |
| Gouveia | Fault injection in Android applications | |
| Yang et al. | ASVG: Automated Software Vulnerability Sample Generation Technology Based on Source Code | |
| CN116521539A (en) | Method for verifying complex data structure form of operating system kernel | |
| Ghorbani | Validation and Verification of Modular Software Applications | |
| Nguyen Tung et al. | Automated test data generation and stubbing method for C/C++ embedded projects |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20220705 |