WO2017005148A1

WO2017005148A1 - Automatic software-testing method and device

Info

Publication number: WO2017005148A1
Application number: PCT/CN2016/088183
Authority: WO
Inventors: 孟雷
Original assignee: 上海触乐信息科技有限公司
Priority date: 2015-07-03
Filing date: 2016-07-01
Publication date: 2017-01-12
Also published as: CN104978270A

Abstract

Provided are an automatic software-testing method and device. The automatic software-testing method comprises: (101) taking a screenshot of a user interface of a beta software package, and saving the screenshot as a test screenshot; (102) comparing the test screenshot with a reference screenshot; and (103) determining a test result of the beta software package according to a comparison result. Using the automatic software-testing method and device increases efficiency and accuracy of an automatic test.

Description

Automatic software testing method and device

Technical field

The present invention relates to the technical field of software testing, and in particular to an automated software testing method and apparatus.

technical background

Testing plays a more important role in the process of software development. The rapid iteration of modern software has higher requirements for the efficiency and quality of testing, so automated testing has become an inevitable choice.

Existing automated test methods usually have the following methods:

1) Get the return value and verify it by writing a code call to the program interface.

2) Write code to get some elements of the user interface, such as buttons; then directly verify some of the attributes of these elements, such as text, color, images, and so on.

3) Write code to get some elements of the user interface, and operate on these elements, such as clicks; finally verify the results of the operation.

This kind of automated test brings convenience and accuracy, but also has some drawbacks, such as long running time, high probability of error, and high maintenance cost. Specifically, the main drawbacks of existing automated test solutions are:

1) The amount of code for writing automated tests is large and takes a lot of time;

2) When the interface or function of the product has been modified, most of the automated test code will be invalid and need to be rewritten;

3) Automated test runs for a long time, often takes hours or even longer to complete a complete round of automated testing;

4) When the automated test case runs wrong, it is often difficult to distinguish whether it is a product function. Or the interface has been modified, or there is a software bug. It takes a long time to analyze and research to locate the problem and finally reach a conclusion.

Therefore, there is a need for a test method that can save time and effort while ensuring the effectiveness of the test.

Summary of the invention

In view of this, the embodiments of the present invention mainly solve the technical problems of low efficiency and poor performance of traditional automated testing, and provide an automated software testing solution with higher efficiency and better effect.

In one aspect of the invention, an automated software testing method is provided. The method includes:

Take a screenshot of the user interface of the software to be tested, and save the obtained screenshot as the screenshot to be tested;

Compare the obtained screenshots to be tested with the reference screenshots; and,

The test result of the software to be tested is judged according to the comparison result.

According to one embodiment of the invention, the reference screenshot may be obtained in advance. The software to be tested is operated by an automated method or a manual method, and a set of reference screenshots are obtained. This set of reference screenshots represents the correct state of the software.

According to an embodiment of the present invention, the user-operated interface of the version that corresponds to the well-recognized version of the screenshot corresponding software is obtained, and the obtained screenshot to be tested corresponds to the user operation interface of the new version of the software to be tested. In this case, the test result of the software to be tested is judged according to the obtained comparison result of the screenshot to be tested and the reference screenshot, including whether the software of the new version has a problem.

Specifically, in accordance with an embodiment of the present invention, an automated software testing method is provided that includes:

The software is operated by an automated method or a manual method, and a set of reference screenshots are obtained. This set of reference screenshots represents the correct status of the software.

Take a screenshot of the user interface of the new version of the software to be tested, and save the obtained screenshot as the screenshot to be tested;

Compare the obtained screenshots to be tested with reference screenshots; and

Judging the test result of the software to be tested according to the comparison result to determine whether the new version of the software has a problem.

An embodiment of the present invention further provides an automated testing device, including:

The screenshot module is used for taking a screenshot of the user operation interface of the software to be tested, and saving the obtained screenshot as a screenshot to be tested;

a comparison module for comparing the obtained screenshot to be tested with a reference screenshot; and

The judging module is configured to judge the test result of the software to be tested according to the comparison result.

The beneficial effects of the automated software testing method provided by the embodiments of the present invention are as follows:

1. The preparation of automated test procedures is simple. Only need to operate on the key elements of the interface, most of the rest of the verification is achieved through screenshot comparison, so the amount of code will be greatly reduced.

2. Running fast. It only needs to operate the key interface elements of the user interface, and the process of screen comparison can be completed in a few seconds, and the total test time will be greatly shortened.

3. Error positioning is more accurate. By comparing the screenshots to draw conclusions about whether the software is defective, the test is very intuitive, and it can be quickly learned whether the difference is caused by a new design or a software defect.

4. Low maintenance costs. Because the amount of code is small, and the software only needs to update the reference screenshot after the revision, the maintenance of the overall automated test code is relatively simple.

DRAWINGS

FIG. 1 is a flowchart of an automated software testing method according to an embodiment of the present invention.

2 is a flow chart of an automated software testing method provided by an embodiment of the present invention.

3(a) to 3(d) are examples of an automated software testing method provided by an embodiment of the present invention.

detailed description

In order to make the objects, technical solutions and advantages of the present invention more clear, the present invention will be described below with reference to the accompanying drawings. For further detailed description.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality and operation of possible implementations of apparatus, methods and computer program products in accordance with various embodiments of the invention. In this regard, each block of the flowchart or block diagram can represent a module, a program segment, or a portion of code, the module, the program segment, or a portion of code comprising one or more Functional executable instructions. It should also be noted that each block of the block diagrams and/or flowcharts, and combinations of blocks in the block diagrams and/or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified function or operation, or It can be implemented in a combination of dedicated hardware and computer instructions.

FIG. 1 is a flowchart of an automated software testing method according to an embodiment of the present invention. As shown in Figure 1, the automated software testing method includes:

Step 101: Take a screenshot of the operation interface of the software to be tested, and save the obtained screenshot as a screenshot to be tested.

Specifically, it may be a screenshot of all or part of the operation interface of the software to be tested, and the operation interface may be obtained by manual or automatic operation of the software to be tested. In an embodiment of the present invention, since the subsequent comparison with the reference screenshot is performed, in order to improve the test efficiency, only part of the operation interface corresponding to the reference screenshot of the software to be tested may be screenshotd. For example, when referring to the screenshot as the user operation interface after the login operation, only the user operation interface after the corresponding login operation of the software to be tested is taken as a screenshot to be tested.

Step 102: Compare the obtained screenshot to be tested with a reference screenshot.

According to an embodiment of the present invention, referring to the screenshot, the user operation interface of the test-qualified version of the software to be tested (ie, confirming the well-behaved version or the reference version) can be looped and traversed to measure all the screenshots and the reference screenshots. Or compare the attributes of some interface elements, and judge whether the software to be tested is qualified according to the comparison result, avoiding writing verification code and testing for each element in the screenshot to be tested, thereby greatly reducing the workload of the test. It also simplifies the complexity of testing and improves work efficiency.

Specifically, the interface element may include one or more of the following items: a button, a text box, Charts, status bars, and web links. The attributes of the interface element may include one or more of the following: text of the interface element, color of the interface element, picture of the interface element, and stress reflection of the interface element on the incentive operation. The incentive operation may include one or more of the following items: click, double-click, drag, slide, long press, dial, and enter operations, such as entering characters/letters.

Those skilled in the art can understand that the interface elements for comparison, the attributes of the interface elements, and the types of the incentive operations can all be determined according to the specific content of the software operation interface, and the attributes of the interface elements and interface elements used for comparison in the present invention and The type of incentive operation is not limited.

Those skilled in the art can still understand that it is not necessary to compare each attribute of each element and element of the user operation interface one by one. When the tester mainly focuses on some key interface elements on the user operation interface, only the screenshot can be measured. Compare with the properties of the key interface elements in the reference screenshot. The present invention does not limit the kind and number of interface elements used for comparison.

In an embodiment of the invention, the reference screenshot may be a defect-free standard operating interface. In order to ensure that the user operation interface presented by the reference screenshot is the required non-defective standard operation interface, the reference screenshot may be manually checked to determine that the user operation interface corresponding to the reference screenshot has no software defects. That is, those skilled in the art can understand that the reference screenshot can be a screenshot of the operation interface after the standard manual/automatic operation of the software reference version.

In another embodiment of the present invention, the reference screenshot may also be a screenshot of any standard operation interface pre-stored by the software reference version. The present invention does not limit the acquisition manner and acquisition timing of the reference screenshot. For example, the reference screenshot may be before step 101. The pre-acquisition can also be obtained during the test process when the screenshot is needed in step 102, for example, executing the verified software version to obtain its standard operation interface without defects.

Step 103: Determine a test result of the software version to be tested according to the comparison result. According to an embodiment of the present invention, by comparing the to-be-tested screenshot of the software to be tested with the reference screenshot, it is determined whether the version to be tested has a software defect according to the difference of the comparison.

In an embodiment of the present invention, the comparison result of the two screenshots may be displayed by using a picture and/or a number, by determining whether the operation interface shown by the screenshot to be tested is relative to the standard shown in the reference screenshot. The operation interface has changed and the test results are obtained.

In an embodiment of the present invention, the first version of the software to be tested may be tested, and the screenshot of the user operation interface obtained after the test is correct is saved as a reference screenshot. Then, the method of the present invention is executed in the second version of the software to be tested, and the obtained screenshot of the user operation interface is saved as a screenshot to be tested. Then, the obtained screenshot to be tested is compared with the reference screenshot, and the test result of the second version of the software to be tested is determined according to the comparison result.

The first version here can be a version that confirms that it works well, that is, a reference version, and the second version can be a modified or upgraded version, that is, a version to be tested. In this case, the method of the embodiment of the present invention can be used for automatic testing. The process of the automatic test may specifically be: determining the difference between the two versions according to the comparison result of the screenshot to be tested and the reference screenshot, and optionally also combining the product design requirements to determine whether the second version has a software defect.

In an embodiment of the present invention, when the comparison result shows that the second version does not change compared to the first version, the test is considered to be qualified; or when the comparison result shows that the second version has a predetermined change with respect to the first version, The second version passed the test.

In an embodiment of the present invention, when it is determined that the second version does not have a defect when the second version is completely consistent with the first version, the comparison result is output only when the comparison result between the second version and the first version is different. Then, based on the comparison result, it is judged whether the second version is really defective.

In another embodiment of the present invention, the first version and the second version may be any version specified by the user. In this case, the method provided by the embodiment of the present invention may be used for version confirmation and comparison.

It will also be understood by those skilled in the art that it is not necessary to perform an automatic operation by confirming that the test software is in a well-functioning version to obtain a reference screenshot. The reference screenshot may also be a preset or stored picture with standard operation data recorded.

With the technical solution provided by the embodiment of the present invention, since the difference between the software to be tested version and the reference version is verified by using the screenshot comparison method, only some key interface elements of the software to be tested are automatically operated, and the automatic operation is saved. The screenshot of the operation interface can obtain the screenshot to be tested, which makes it necessary to write some points on the user interface of the software user to be tested when writing the automated test program. The key interface element writes the automatic operation code, and does not need to write the corresponding test code and test each element on each interface in the test version, thereby greatly reducing the amount of code written by the automated test program. At the same time, with the change of the software to be tested, the reference version is also changing. At this time, only the corresponding reference screenshot and the test program code need to be updated accordingly. Since the code amount of the test program is relatively small, the maintenance of the overall automated test code is performed. It is also relatively simple. In addition, the process of screen comparison can be completed in a few seconds, and the total test time is greatly shortened. Through the comparison of screenshots, the conclusion that the software version has software defects is obtained, and the test results are also very intuitive and fast.

The following embodiments illustrate the process of the method provided by the embodiments of the present invention for automatic testing. 2 is an automated software testing method according to an embodiment of the present invention. As shown in FIG. 2, the method includes:

Step 201: Perform an automatic operation on a version of the software that works well, such as a reference version, and save the user operation interface obtained after the operation step.

In the embodiment of the present invention, the user may save each user operation interface obtained after each operation step, and finally obtain a screenshot set; or may only save the final user operation interface obtained by the operation step of the test.

In an embodiment of the invention, automatic operation of the software is implemented by an automated script.

First, write an automatic script that performs the automatic operation of the specified interface elements of the user interface and performs a screen capture of the user interface generated after the automatic operation. Automated operations can be any test operation, such as swiping, long press, dialing, entering characters/letters, clicking on a button, and clicking on a web link. Here you can take the loop traversal method until you ensure that all interface elements or interfaces that can be opened are operated, and the corresponding screenshots of the operation interface are saved. These screenshots are used as a comparison reference for subsequent automated testing. For the convenience of the subsequent description, the reference screenshot or the screenshot set is temporarily named as screenshot A.

In an embodiment of the present invention, the intercepted screenshot may be further manually checked to determine that the reference screenshot as a subsequent automatic test comparison is completely correct or has no software bugs.

Step 202: Perform automatic operation on the tested version of the software, and save the user operation interface obtained after each operation step.

In an embodiment of the present invention, when the software to be tested has a new change on the basis of the reference version, and the software test is required, the running script mentioned in step 201 may also be run on the test version of the software. And get the corresponding screenshot. For the convenience of the following description, the screenshot or screenshot set of the test version may be temporarily named as screenshot B.

Since step 202 and step 201 run the same set of automatic running scripts, the strategy and order of clicking on the interface elements of the target software are the same. When a strategy for saving each user interface obtained after each operation step is adopted, a screenshot set B is finally obtained, and in this case, the corresponding pictures in the screenshot set A and the screenshot set B can be automatically correlated. Joint comparison. The association between the screenshots contained in the screenshot collection can be simply related by the naming of the screenshots, for example, the name of the screenshot is automatically sequenced with the step number executed by the script, so that the screenshots in the screenshot set A may be named A01 in turn. , A02, A03, etc., and the screenshots in the screenshot set B may be named B01, B02, B03, and so on.

If the interface element is reduced or increased because the version to be tested is compared with the reference version, manual intervention can be used for fine adjustment. Of course, you can also make minor adjustments to the running script and update the click strategy of the interface elements of the software you are testing.

Step 203: Compare the reference screenshot with the screenshot to be tested.

In an embodiment of the present invention, the batch image comparison tool can be run by the machine to automatically compare the corresponding images in the screenshot set A and the screenshot set B one by one, and output the comparison result. For example, the RGB values of each of the pixels in the screenshot A01 and the screenshot B01 can be obtained, and then the similarity or peak signal to noise ratio is calculated, and the similarity or peak signal to noise ratio is taken as the final comparison result.

In the embodiment of the present invention, the comparison operation result may be displayed in a digital manner, or may be displayed in the form of a picture, or two display modes may be utilized at the same time. For example, the difference between the two pictures can be represented by digital information such as the numerical difference of the pixel values and the coordinate position where the difference is located. For example, specific differences can be identified on screenshot A or screenshot B in a highlighted or otherwise identifiable manner. The way images are displayed is usually more intuitive, but it's clear that digital presentations are more efficient.

In an embodiment of the invention, in order to improve the test efficiency, only the comparison result may be set differently. When the comparison operation result is output, if the comparison result shows that the two corresponding pictures are identical, the comparison operation result is not output.

Those skilled in the art can understand that in the case that some key interface elements require special attention, the comparison process of referring to the screenshot and the screenshot to be tested can also be performed manually. However, the present invention does not limit the manner in which the reference screenshot and the screenshot to be tested are compared.

Step 204: Determine a test result of the software to be tested according to the comparison result.

Based on the results of the image comparison and the product design requirements, the tester can quickly conclude whether the software version to be tested has software defects.

For example, if there is no difference between the screenshot A01 and the screenshot B01, but there should be a difference between the two according to the product design requirements, then it can be determined that there is a software defect; if there is a specific difference between the screenshot A02 and the screenshot B02, but according to the product Design requirements, there should be no difference between the two, as well as the existence of software defects.

Step 205: Once it is determined that there is no software defect in the software version to be tested, the original reference screenshot is replaced by the screenshot of the software to be tested, as a reference for the subsequent automatic test comparison of the next software version.

Let us give an example to illustrate.

First, write an automated test program to automatically test the first version of an existing mobile phone software, that is, to automatically operate an interface element of the first version, and save the screenshot of the obtained user interface, Figure 3 (a ) Screenshot of the saved results. Take this screenshot image as a normal reference screenshot of the software.

Next, run the same test code on the second version of the software, and save the obtained operation interface. Figure 3(b) shows the screenshot to be tested corresponding to the second version.

Next, the picture comparison program is run to compare the two pictures. In an embodiment of the invention, the picture comparison tool is imagemagick. Those skilled in the art can understand that the programmer can also use other image comparison tool software to complete the picture comparison process, and any picture comparison tool capable of batch processing pictures can be used to complete the picture comparison process. Picture pair of the invention The types of sheet contrast tools are also not limited.

For a more specific example, you can run the following command line:

Compare-verbose-metric PSNR imageA.png imageB.png diff.png

Where compare is the main running program; -verbose-metric PSNR is the running parameter, specifically for screenshot A imageA.png, screenshot B imageB.png, and contrast output file diff.png. The content of the command line is specifically: calculating the peak signal-to-noise ratio of the two images imageA and imageB, and outputting the digital result, and simultaneously highlighting the different points in the image and outputting them to the diff.png file. Among them, if the two images are different, different parts will be marked in the comparison output file. If the two images are identical, the digital output is 0 and the output image has no highlights.

The diff.png example obtained after the image comparison program is run is shown in Figure 3(c). Among them, imageA.png=>diff.png PNG 480............ is a numerical result, indicating that the two pictures are different, and the numbers of specific differences are given in latitudes such as red, blue and green. From these numerical results, it is already clear which position between the two pictures is different. When there is no difference between the two images, no digital result will be output.

Further, the output file diff.png can be opened with an image viewing tool. Figure 3 (d) is the output image corresponding to diff.png, which will mark the different points of the two images in a specific form, for example, with a dashed frame, or highlight, or a specific line thickness or font size or Colors and other forms highlight the differences.

As can be clearly seen from Figure 3(d), the main difference between screenshot A and screenshot B is the back button at the top left of the screen. In the second version, this back button can be deleted.

At this point, the tester can determine whether the deletion of the back button is a known change or a bug caused by the negligence of the developer. If the deletion of the back button is a known change intentionally made by the product design, then the screenshot A shown in Figure 3(b) is used instead of the screenshot A as a comparison reference for subsequent versions. If the deletion of the back button is caused by negligence, the bug found will be returned to the developer for modification.

In this way, a complete automated test process is over.

The comparison method in the above example is not limited to a single picture. For a large number of pictures, we can also compare and draw conclusions in batches. At the same time, the way of automatic screening of such screenshots is not limited to mobile applications. Any software with a graphical interface can test functions and user interfaces in this way. For example, this test method can be adopted for ordinary computer software, web pages, mobile applications, and web pages within mobile applications.

In the traditional automated testing process, taking FIG. 3(b) as an example, for the interface to be tested shown in FIG. 3(b), the testing step generally includes: defining each element on the user interface, such as a button, Tags, etc.; then, write test code for each element to verify the properties of those elements, such as text, color, position, size, and so on. Specifically, for example, verify that the color, position, and size of the box of “number search” at the top of the page are correct, verify that the font, size, color, and position of the display text “number search” are correct, and verify the list displayed on the page. Whether the item is correct or not, for example, whether a list item having a preferential information such as "KFC Xinyi Street Store" or "KFC Tianlin Store" has a corner mark or the like displayed in the upper right corner. Due to the many elements on the interface, it is conceivable that the code tested is quite complicated. In addition, since each interface of the software to be tested needs to be written with a similar verification code, and for, for example, three vertical rows of dots in the upper right corner (into the set entry), even at different interfaces are located at similar positions due to It's a different interface, so programmers need to re-define and test validation. This results in the use of traditional automated testing, which is quite lengthy when testing the user interface shown in Figure 3(b). In contrast, according to the present invention, when testing a new version of the software, it is only necessary to form a test screenshot as shown in FIG. 3(b), which is compared with the reference screenshot shown in FIG. 3(a) by means of a graphic comparison. Detection. As long as the same is true, even if there are differences, it is possible to quickly determine whether there are software defects and accurately locate software defects. This not only saves the workload of writing code, but also has high efficiency and can find software defects more accurately; it solves the problem of low efficiency and poor effect of traditional automated testing.

In another embodiment of the present invention, the software to be tested is a mobile phone application, and the pseudo code for executing the automated software testing method of the present invention may be specifically as follows:

First, test the program entry

Class TestMainPages(CoolerTestCase):

Then, test the main interface of the current version of the application by the following function:

Def test_main_pages(self):

Here's the first step in automated testing: Execute test cases and save screenshots.

Os.system("adb shell am instrument-w-e class com.cootek.smartdialer.testmoudle.webview.WebViewTestCaseDemo com.cootek.smartdialer.test/android.test.InstrumentationTestRunner")

The following is the second step of the automated test, copying the screenshot from the SD card of the phone to the specified folder of the computer.

Util.get_folder(self.machine_center.get_property("android_image_folder"),self.machine_center.get_property("local_image_folder"))

The following is the third step of the automated test, run the image comparison program, compare the screenshots of this run with the previous images, and get the comparison results.

Diff=util.compare_images(self.machine_center.get_property("local_image_folder"),self.machine_center.get_property("template_image_folder"),self.machine_center.get_property("diff_image_folder"),self.machine_center.get_property("diff_file"))

The following steps are used to determine the test results of the current version of the application based on the comparison results. If the comparison result is different, an exception message is displayed indicating that the test case failed to run, that is, the current version of the application is defective.

If diff:

Raise Exception("Image compare fails!")

An embodiment of the invention also provides an automated test device. As shown in FIG. 4, the automated test apparatus includes:

The screenshot module is configured to take a screenshot of the user operation interface of the software to be tested version, and save the obtained screenshot as a screenshot to be tested;

a comparison module, configured to compare the to-be-tested screenshot obtained by the screenshot module with a reference screenshot; and

And a judging module, configured to determine, according to the comparison result obtained by the comparison module, a test result of the software to be tested.

In an embodiment of the invention, the automated testing device may further include:

An automatic script module for implementing automatic operation of the software version; for example, the automatic script module detects whether the software can implement the set function by automatically operating elements on one or more user interfaces of the software. In an embodiment of the present invention, after the screenshot module invokes the automatic script module to perform an automatic operation on the version to be tested, the obtained user operation interface is saved as a screenshot to be tested. In another embodiment of the present invention, the screenshot module may further invoke the automatic script module to automatically perform a reference operation on the reference version to obtain a reference screenshot.

Referring to the screenshot obtaining module, when the determining module determines that the test result of the software to be tested is qualified for testing, the screenshot to be tested is called as a reference screenshot.

Additionally or alternatively, the reference screenshot acquisition module may also invoke an automatic script module to perform an automated operation on the tested qualified software, and save the user interface obtained after the automatic operation as a reference screenshot.

Those skilled in the art will appreciate that while the above embodiments describe several modules or sub-modules of an automated test set, such division is merely not mandatory. Indeed, in accordance with embodiments of the present invention, the features and functions of the two or more modules described above may be embodied in one module. Conversely, the features and functions of one of the modules described above may be further divided into multiple modules. Those skilled in the art can understand that the technical solution of the present invention can be implemented by using software, and in particular, can be implemented by a computer program. For example, executable code may be stored in a RAM, ROM, hard disk, and/or any suitable storage medium, and when the executable code is executed, the functions mentioned in the above embodiments of the present invention may be implemented.

It should be noted that embodiments of the present invention may also be implemented by hardware, or a combination of software and hardware. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated design hardware. In the field One of ordinary skill in the art will appreciate that the apparatus and methods described above can be implemented using computer-executable instructions and/or embodied in processor control code, such as a carrier medium such as a magnetic disk, CD or DVD-ROM, such as read-only memory (firmware). Such code is provided on a programmable memory or data carrier such as an optical or electronic signal carrier. The apparatus of the present invention and its modules may be implemented by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, and the like. It can also be implemented by software executed by various types of processors, or by a combination of the above-described hardware circuits and software such as firmware.

It should also be understood that the descriptions of the present invention are merely illustrative of some key, non-essential techniques and features, and may not be described in a manner that can be realized by those skilled in the art.

The above are only the preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalents, and the like made within the spirit and scope of the present invention are intended to be included in the scope of the present invention. .

Claims

An automated software testing method, comprising:

Take a screenshot of the user operation interface of the software to be tested version, and save the obtained screenshot as the screenshot to be tested;

Compare the obtained screenshots to be tested with the reference screenshots; and,

The test result of the software to be tested is judged according to the comparison result.
The method according to claim 1, wherein the user operation interface of the part of the version to be tested is screenshotd, including:

A screenshot is taken on a part of the user operation interface corresponding to the reference screenshot of the to-be-tested version.
The method of claim 2 wherein said reference screenshot corresponds to all or a portion of a user interface of a reference version of said software that is qualified for testing.
The method according to claim 3, wherein the screenshot of the user operation interface of the software to be tested version comprises:

A screenshot is taken of all or part of the user operation interface of the test version to be tested.
The method according to any one of claims 1 to 4, wherein comparing the obtained screenshot to be tested with the reference screenshot comprises:

The measured screenshots are compared to the properties of all or part of the interface elements in the reference screenshot.
The method of claim 5, wherein the interface element comprises one or more of the following: a button, a text box, a chart box, a status bar, and a web page link, and attributes of the interface element Includes one or more of the following: text, color, picture, and interface elements reflect the stress of the stimulus.
The method of claim 5 wherein said stimulating operation comprises one or more of the following: clicking, double clicking, dragging, sliding, long pressing, dialing, and entering operations.
The method according to any one of claims 1 to 4, further comprising:

Performing an automatic operation on the reference version of the software that confirms that the operation is good, and saving the user operation interface obtained after the automatic operation as the reference screenshot;

Automatically operating the test version of the software, and saving the user operation interface obtained after the automatic operation as the screenshot to be tested.
The method according to claim 8, wherein the determining the test result of the software version to be tested according to the comparison result further comprises:

When it is determined that the software to be tested does not have a software defect, the screenshot to be tested is used as a reference screenshot in the subsequent test.
The method according to any one of claims 1 to 4, wherein the screenshot to be tested is a screenshot or a collection of screenshots, wherein comparing the obtained screenshot to be tested with the reference screenshot includes:

Compare one of the obtained screenshots to be taken with a reference screenshot; or

The one-to-one or one-to-many comparison is performed in batches corresponding to the screenshots in the reference screenshot set.
An automated software testing device, comprising:

The screenshot module is configured to take a screenshot of the user operation interface of the software to be tested version, and save the obtained screenshot as a screenshot to be tested;

a comparison module, configured to compare the to-be-tested screenshot obtained by the screenshot module with a reference screenshot; and

And a judging module, configured to determine, according to the comparison result obtained by the comparison module, a test result of the software to be tested.
The device according to claim 11, further comprising:

An automatic script module for automatically operating an element on one or more user interfaces of the software to detect whether the software can implement the set function.
The device according to claim 12, wherein the screenshot module further comprises:

After the automatic script module is invoked to perform automatic operation on the to-be-tested version, the obtained user operation interface is saved as a screenshot to be tested; or

After the automatic script module is invoked to automatically operate the reference version of the software that confirms the operation, the obtained user operation interface is saved as a reference screenshot.
The device according to claim 11, further comprising:

Referring to the screenshot acquisition module, when the determining module determines that the test result of the software to be tested is qualified, the screenshot to be tested is called, and is used as a reference screenshot in the subsequent test and saved.