Regression test method, test terminal and server

Abstract

The invention discloses a regression test method, a test terminal and a server. The method comprises the following steps: step S201, screening use cases, and establishing a use case set; s202, establishing an automatic use case set; performing an automatic regression test by using the automatic case set; s203, performing regression testing on problems found in the testing environment and the gray environment again before online version issuing, and performing online comprehensive testing according to the use case set; step S204, performing an exploration test on the version; s205, after the exploration test is completed, the problems are settled, and comprehensive test is carried out again after development and repair; s206, performing online regression verification test on each channel package of the new version, and performing online regression on the old version; and S207, after the edition issuing is completed, the tester comprehensively tests the new edition again at the first time.

Description

This application is a divisional application based on a patent application with an application date of January 13, 2021, application number 202110045302.0, and invention name “Software Regression Testing Method”. Technical Field

[0001] The present application relates to the technical field of software testing, and in particular to a regression testing method, a testing terminal and a server. Background Art

[0002] With the development of software technology and the increasing market demand for software, the scale of software is getting larger and more complex. Therefore, there are many bugs in software products after they are put into operation. In the existing technology, products are generally only tested once before they are put into operation; after the products are put into operation, many bugs often appear. Summary of the invention

[0003] The main purpose of this application is to provide a software regression testing method to solve the problem in the prior art that there are many bugs in the product after it is launched due to simple testing.

[0004] In order to achieve the above object, according to one aspect of the present application, a regression testing method is provided, comprising:

[0005] Perform exploratory testing on the target software to be tested; if the exploratory testing passes;

[0006] A comprehensive set of pre-established test cases is used for comprehensive testing;

[0007] If the comprehensive test is passed, the software is tested using various channel packages;

[0008] If the software passes the test using each channel package, the software will be put online.

[0009] In one embodiment, performing exploratory testing on the target software to be tested includes:

[0010] Use different brands of terminals with the same operating system to test the target software; or

[0011] For any brand, different series of terminals are used to install different operating systems in sequence to test the target software to be tested;

[0012] For terminals of the same brand and series, different operating systems are used to test the target software to be tested.

[0013] In one implementation, if the exploratory test or the comprehensive test fails, the BUG in the login process is recorded; the BUG is sent to the server; after the BUG is fixed, the exploratory test is performed again.

[0014] In one embodiment, the method further includes: calculating the number n of each type of BUG;

[0015] Calculate the theoretical standard time for solving multiple bugs in this test based on the pre-stored single solution time t and n of each bug;

[0016] Where m is the number of BUG types; i is a variable;

[0017] Compare the sizes of TL and T;

[0018] If TL is less than T, it is determined that the efficiency of solving the BUG is lower than the average efficiency;

[0019] If TL is greater than T, it is determined that the efficiency of solving the BUG is higher than the average efficiency.

[0020] In one embodiment, the method further includes: performing an upgrade test on the software, including:

[0021] Upgrade the current version of the software to the latest version; determine whether the upgrade is normal;

[0022] If there is no BUG, ​​uninstall the current version and install the latest version of the software.

[0023] In one implementation, the method further includes: updating the test case set.

[0024] In one implementation, updating the test case set includes:

[0025] Write new test cases according to the current project;

[0026] storing the new test case in a test case set; or,

[0027] Corresponding test cases are written for the newly added functions; and the newly written test cases are stored in the test case set.

[0028] In one embodiment, the software is tested using various channel packages, including:

[0029] Get channel packages from various app stores;

[0030] Use different channel packages to test the software and record the corresponding BUGs respectively;

[0031] Establish a correspondence table between channel packages and corresponding BUGs according to the identifier of the channel package;

[0032] The relationship table is sent to the server of the R&D department to fix the BUG.

[0033] In a third aspect, the present application further proposes a test terminal, including a sending module, for sending BUG information to a server after the exploratory software test is completed;

[0034] The BUG information includes: BUG type and quantity; if it is an exploratory test, the BUG information also includes the brand and model of the terminal;

[0035] The receiving module is used to receive the message sent by the server that the BUG has been repaired;

[0036] A calculation module, which is used to calculate the theoretical standard time for solving multiple bugs according to the pre-stored average single solution time for solving each bug and the number of the bugs after the test is completed;

[0037] Where m is the number of BUG types; i is a variable;

[0038] Compare the size of TL and T;

[0039] If TL is less than T, it is determined that the efficiency of solving the BUG is lower than the average efficiency;

[0040] If TL is greater than T, it is determined that the efficiency of solving the BUG is higher than the average efficiency;

[0041] It includes a sending module, and is also used to send the efficiency comparison result to the server.

[0042] In a fourth aspect, the present application further proposes a server, comprising:

[0043] A receiving module, configured to receive BUG information sent by each first terminal; and receive the efficiency comparison result sent by the first terminal; wherein the BUG information includes: BUG type, quantity, and generation time of the BUG; if it is an exploratory test, the BUG information also includes the brand and model of the first terminal;

[0044] A storage module, used for storing the BUG information;

[0045] A sending module, used to send the BUG information to the second terminal so that the R&D personnel can fix the BUG; and send the information that the BUG is fixed to the first terminal; and send the efficiency result to the second terminal;

[0046] The first terminal is used to test the software;

[0047] The second terminal is used to maintain the software and fix bugs.

[0048] The above-mentioned technical solution of the present invention effectively avoids the problem of insufficient online regression testing through the automated regression testing, comprehensive testing, exploratory testing, channel package testing, and old version testing performed by a complete set of use cases before the version is released online, greatly reduces or even avoids the occurrence of online accidents, and greatly improves the online quality of the project. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The drawings constituting a part of this application are used to provide a further understanding of this application, so that other features, purposes and advantages of this application become more obvious. The schematic embodiment drawings and their descriptions of this application are used to explain this application and do not constitute an improper limitation on this application. In the drawings:

[0050] Figure 1 is a flowchart of a software regression testing method according to an embodiment of the present application;

[0051] Figure 2 It is a flowchart of another software regression testing method according to an embodiment of the present application. DETAILED DESCRIPTION

[0052] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0053] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0054] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0055] First, let's introduce the professional terms of this application.

[0056] Regression testing refers to retesting after modifying the old code to confirm that the modification has not introduced new errors or caused errors in other codes. Automatic regression testing will greatly reduce the cost of system testing, maintenance and upgrades. As an integral part of the software life cycle, regression testing accounts for a large proportion of the workload in the entire software testing process.

[0057] This application proposes a software regression testing method, see Attachment Figure 1 Flowchart of the software regression testing method shown; the method comprises:

[0058] Step S102, performing exploratory testing on the target software to be tested;

[0059] Among them, exploratory testing refers to the installation of the target software on the test terminal; because the software can be successfully installed on test terminal A; but it may fail to install on test terminal B. Different operating systems may have different installation results. Therefore, it is necessary to conduct preliminary exploratory testing on test terminals of different brands and models with different operating systems.

[0060] The test terminal may be a smart phone, a tablet computer, a notebook, etc.

[0061] For any brand, use different series of test terminals and install different operating systems in sequence for testing;

[0062] For test terminals of the same brand and series, different operating systems are installed for testing.

[0063] Exemplarily, the test terminal is a smart phone; different brands of mobile phones are used for testing; for example, Huawei phones, Xiaomi phones, Nubia phones, OPPO phones, etc., respectively install applications and log in; and the mobile phones can also install different operating systems.

[0064] See Table 1;

[0065]

[0066] Table 1

[0067] When conducting exploratory testing, for each model of mobile phone and each operating system, the corresponding test results are recorded separately, including the BUG name, the number of BUGs, the type of BUG, ​​etc.

[0068] For the same brand, different models of mobile phones can be used for separate tests, see Table 2.

[0069]

[0070] Table 2

[0071] Check the installation and login process; if a bug occurs, record it and return it to the software developer for maintenance.

[0072] Step S104, if the exploratory test passes, a comprehensive test is performed using a pre-established comprehensive test case set;

[0073] Among them, the comprehensive test case set includes use cases for all processes from downloading and installing applications, registering and logging in, browsing pages, placing orders to purchase medicines, and logging out.

[0074] Step S106, if the comprehensive test passes, then the software is tested using each channel package;

[0075] Among them, the channel package is downloaded from the page of the corresponding application store; each channel package is set with an identification.

[0076] Step S108: If the software passes the test using each channel package, the software is put online.

[0077] The technical solution of the present invention can find some initial problems in the software installation process by conducting exploratory testing. The present application proposes a complete and effective regression testing method, which improves the testing effect and can find more bugs. It reduces the bug incidence rate after going online.

[0078] The iteration frequency of versions in the software development process is getting faster and faster. In response to this situation, in one implementation, the software is upgraded and tested, and the current version of the software is upgraded to the latest version; it is determined whether the upgrade is normal; if there are no bugs, the current version is uninstalled and the latest version of the software is installed.

[0079] For example, the software version currently in the mobile phone is an old version of the software; the old version of the software on the mobile phone is upgraded to the latest version. It is determined whether there are bugs during the upgrade process; if there are no bugs and the upgrade is normal, the old version of the software is uninstalled and the latest version of the software is installed. If the upgrade cannot be normal, the new version of the software is maintained.

[0080] In one embodiment, the method further includes: updating the test case set. Writing corresponding new test cases according to the current project; storing the new test cases in the test case set;

[0081] For example, for a project to recommend doctors, users are required to register and enter their current medical information. When the user enters a disease in the search interface, a list of doctors for the disease is displayed.

[0082] For such a new project, new test cases need to be written. During the test, the user may log into the system even if the user name or password is incorrect. Or after logging into the system, a doctor's portrait cannot be displayed or is distorted, which indicates that there is a BUG.

[0083] Corresponding test cases are written for the newly added functions; and the newly written test cases are stored in the test case set.

[0084] For example, a new function is added to the product. For example, the address management function allows users to add or delete existing addresses. New test cases need to be written for testing. During the test, possible bugs include: the address cannot be deleted normally; the address cannot be edited normally; or the address of other users is displayed.

[0085] For example, when testing the address, the address information in the information confirmation page is obtained; if the address information can be obtained, the test is normal; if there is no address, it is determined to be a BUG. For example, Zhang San buys medicine for Li Si, but forgets to fill in Li Si's address, and the delivery person cannot deliver it.

[0086] In one implementation, if the exploratory test or the comprehensive test fails, the bug in the login process is recorded; the bug is sent to the server of the R&D department; after the bug is fixed, the exploratory test is performed again.

[0087] Exemplarily, the tester performs the test on a test terminal, which may be a mobile phone or a laptop computer; and performs exploratory testing or comprehensive testing.

[0088] If the test fails, the test terminal records the bug and sends the bug information to the server of the software development department;

[0089] The BUG information includes: the number of BUGs found in this test; the type of BUG; and the name of each BUG.

[0090] In order to remind the R&D personnel to modify the BUG in time, in one implementation mode, after receiving the BUG information, the server sends a prompt message to the client of the R&D personnel to prompt that a BUG has occurred.

[0091] In specific implementation, after the BUG modification is completed, the server sends a modification completion message to the test terminal. The test terminal performs the test again. The test terminal can record the time point T1 when the BUG is discovered; the time point T2 when the BUG is resolved; the type of BUG; and the number of BUGs. Calculate the time difference T=T2-T1; calculate the efficiency of the BUG resolution of R&D according to the type of BUG, ​​the number of BUGs; and the time difference. Generate a responsive grade score, which can promote the enthusiasm of R&D personnel.

[0092] Specifically, if multiple BUGs are resolved within a short period of time and the types of the BUGs are serious, it is determined that the efficiency of resolving the BUGs is high.

[0093] Among them, the BUG level can be set in advance.

[0094] If the number of bugs is small and the level is minor, but it takes a long time to resolve, and the time is greater than the average resolution time or the time threshold, then the bug resolution efficiency is determined to be low.

[0095] The time threshold may be 24 hours; the average resolution time may be obtained by pre-statistical analysis of the big data.

[0096] In order to quantitatively measure the efficiency of solving BUGs, in one embodiment, the test terminal can store the average resolution time t of each BUG individually;

[0097] The above t is obtained by pre-statisticing a large amount of data.

[0098] After the test is completed, the test terminal calculates the number n of each type of BUG;

[0099] The test terminal calculates the theoretical standard time of multiple BUGs in this test according to the above parameters;

[0100] Where m is the number of BUG types; i is a variable;

[0101] The test terminal compares the sizes of the above TL and T;

[0102] If TL is less than T, it is determined that the efficiency of solving the BUG is lower than the average efficiency;

[0103] If TL is greater than T, it is determined that the efficiency of solving the BUG is higher than the average efficiency.

[0104] In one implementation, the test terminal may also send the above calculation result to the server.

[0105] Today's software is frequently upgraded. In one implementation, the process also includes: performing an upgrade test on the software, upgrading the current version of the software to the latest version; determining whether the upgrade is normal; and if there are no bugs, uninstalling the current version and installing the latest version of the software.

[0106] In one embodiment, when the software is tested using various channel packages, the channel packages of various application stores are obtained;

[0107] Exemplarily, the channel package is downloaded according to the URLs of Huawei App Store and Xiaomi App Store respectively; the channel package is provided with an identification.

[0108] Use different channel packages to test the software and record the corresponding BUGs;

[0109] Establish a correspondence table between channel packages and corresponding BUGs according to the identifier of the channel package;

[0110] The relationship table is sent to the server of the R&D department to fix the BUG.

[0111] See another regression testing method proposed in this application, see Attachment Figure 2 A flowchart of another regression testing method is shown; the method comprises:

[0112] Step S201, screening use cases and establishing a use case set.

[0113] During implementation, you can write a new set of use cases based on the current project, or you can filter from the existing use case sets and maintain them to be fully prepared for comprehensive testing.

[0114] Step S202, establishing an automated use case set; and using the automated use case set to perform automated regression testing.

[0115] Exemplarily, the automated use cases are obtained by removing non-automated use cases from the use case set. Use cases that cannot be automated, for example, require manual operation to drag a picture to a predetermined position for verification during the login verification process.

[0116] Update and maintain software versions.

[0117] Step S203, before going online and releasing the version, the problems found in the test environment and the grayscale environment are re-regressed and then a comprehensive online test is performed based on the use case set.

[0118] The stages before product release include the testing stage and the pre-release stage. The grayscale environment is the pre-release environment. Before release, the bugs in the testing environment and the pre-release stage are re-regressed.

[0119] Step S204, performing exploratory testing on the version;

[0120] During the specific implementation, various brands and models of test terminals and different operating systems are used to perform more in-depth regression.

[0121] Step S205, after the exploratory test is completed, the problems are sorted out and comprehensive testing is performed again after development and repair.

[0122] Step S206, perform online regression verification test on each channel package of the new version, and perform online regression on the old version.

[0123] Step S207: After the release is completed, the tester will conduct a comprehensive test on the new version again as soon as possible.

[0124] In a second aspect, the present application also proposes a test terminal; the test terminal is used for software testing.

[0125] It includes a sending module, which is used to send BUG information to the server after the exploratory software test is completed.

[0126] BUG information includes: BUG type and quantity; if it is exploratory testing, the BUG information also includes the brand and model of the test terminal.

[0127] The receiving module is used to receive the message sent by the server that the BUG has been repaired.

[0128] A calculation module, which is used to calculate the theoretical standard time for solving multiple bugs according to the pre-stored average single solution time for solving each bug and the number of the bugs after the test is completed;

[0129] Among them, m is the number of BUG types; i is a variable.

[0130] The test terminal compares the sizes of the above TL and T.

[0131] If TL is less than T, it is determined that the efficiency of solving the BUG is lower than the average efficiency.

[0132] If TL is greater than T, it is determined that the efficiency of solving the BUG is higher than the average efficiency.

[0133] It includes a sending module, which is also used to send the above efficiency comparison result to the server.

[0134] In a third aspect, the present application further proposes a server, comprising a receiving module, for receiving BUG information sent by each first terminal; wherein the BUG information includes: BUG type, quantity, and generation time of the BUG; if it is an exploratory test, the BUG information also includes the brand and model of the first terminal;

[0135] A storage module, used for storing the BUG information;

[0136] It is worth emphasizing that there are multiple first terminals, and the server will store information of multiple first terminals of different brands, different models, and different operating systems.

[0137] A sending module, used to send the BUG information to the second terminal so that the R&D personnel can fix the BUG; and send the information that the BUG is fixed to the first terminal;

[0138] The first terminal is a terminal used by the testing department to test the software;

[0139] The second terminal is used by the software development department to maintain the software and fix bugs.

[0140] The receiving module is further used to receive the efficiency comparison result sent by the first terminal.

[0141] The present application also proposes a testing system, comprising the above-mentioned first terminal, server and second terminal.

[0142] The second terminal is used to repair the BUG after receiving the BUG information; and receive the efficiency result forwarded by the server.

[0143] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0144] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the present invention can be implemented using a combination of hardware and software. When software is used, the corresponding functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any media that facilitates the transmission of computer programs from one place to another. Storage media can be any available media that can be accessed by general or special-purpose computers.

[0145] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A regression testing method, the method comprising: Step S201, screening use cases and establishing a use case set; Step S202, establishing an automated use case set, and using the automated use case set to perform automated regression testing; Step S203, before the release is online, the problems found in the test environment and the grayscale environment are re-regressed and then a comprehensive online test is performed according to the use case set; Step S204, performing exploratory testing on the version; Step S205, after the exploratory test is completed, sort out the problems and conduct comprehensive testing again after the development and repair; Step S206, performing online regression verification test on each channel package of the new version, and performing online regression on the old version; Step S207: After the release is completed, the tester will conduct a comprehensive test on the new version again as soon as possible.

2. The regression testing method according to claim 1, characterized in that: Write new use case sets or filter from existing use case sets based on current projects.

3. The regression testing method according to claim 2, characterized in that: In step S202, non-automated use cases are removed from the use case set to obtain automated use cases.

4. The regression testing method according to claim 3, characterized in that: In step S203, the stage before product release includes a testing stage and a pre-release stage. The grayscale environment is a pre-release environment. Before the release, the bugs in the test environment and pre-release stage will be re-regressed.

5. The regression testing method according to claim 4, characterized in that: In step S204, various brands and models of test terminals and various operating systems are used to perform a deeper regression.

6. A test terminal, comprising: A sending module is used to send BUG information to the server after the exploratory software test is completed, wherein the BUG information includes: BUG type and quantity; if it is an exploratory test, the BUG information also includes the brand and model of the terminal; The receiving module is used to receive the message sent by the server that the BUG has been repaired; A calculation module, which is used to calculate the theoretical standard time for solving multiple bugs according to the pre-stored average single solution time for solving each bug and the number of the bugs after the test is completed; Among them, m is the number of BUG types; i is a variable.

7. The test terminal according to claim 6, characterized in that: The calculation module is used to compare the size of TL and T; If TL is less than T, it is determined that the efficiency of solving the BUG is lower than the average efficiency; If TL is greater than T, it is determined that the efficiency of solving the BUG is higher than the average efficiency.

8. The test terminal according to claim 6, characterized in that: The test terminal also includes: The sending module is also used to send the efficiency comparison result to the server.

9. A server, comprising: A receiving module, used for receiving BUG information sent by each first terminal; and receiving the efficiency comparison result sent by the first terminal; wherein the BUG information includes: BUG type, quantity, and BUG generation time; if it is an exploratory test, the BUG information also includes the brand and model of the first terminal; A storage module, used for storing the BUG information; A sending module, used to send the BUG information to the second terminal so that the R&D personnel can fix the BUG; and send the information that the BUG is fixed to the first terminal; and send the efficiency result to the second terminal; The first terminal is used to test the software; The second terminal is used to maintain the software and fix bugs.

10. The server according to claim 9, characterized in that The receiving module is further configured to receive the efficiency comparison result sent by the first terminal. When there are multiple first terminals, the server will store information of multiple first terminals of different brands, different models, and different operating systems.

Images