CN111209206A - Automatic test method and system for software product - Google Patents
Automatic test method and system for software product Download PDFInfo
- Publication number
- CN111209206A CN111209206A CN202010030306.7A CN202010030306A CN111209206A CN 111209206 A CN111209206 A CN 111209206A CN 202010030306 A CN202010030306 A CN 202010030306A CN 111209206 A CN111209206 A CN 111209206A
- Authority
- CN
- China
- Prior art keywords
- test
- file
- target
- record
- software product
- 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
Abstract
The embodiment of the invention provides an automatic test method and system of a software product, wherein the method comprises the following steps: acquiring a target test file, wherein a check code of the target test file is consistent with a check code of a to-be-detected version of a software product; acquiring a test requirement from the target test file, and displaying the test requirement to a user; receiving a test plan and a test case input by a user according to the test requirement, and receiving a test record input by the user, wherein the test record is a record of the condition when the target test file is tested according to the test plan and the test case; generating a test report for the test record. Compared with the problem that the software product is easily subjected to error and leakage and the consumed time is long when the software product is tested manually, the automatic testing method and the automatic testing system for the software product provided by the embodiment of the invention can avoid the occurrence of error and leakage and have short consumed time, so that the accuracy and the efficiency of software product testing are improved.
Description
Technical Field
The invention relates to the field of computers, in particular to an automatic testing method and system of a software product.
Background
Software product testing is an essential link in the software product development process. In the conventional software product testing process, the test files are confirmed and test reports are output, which are mostly performed manually. And the software product is tested manually, so that mistakes and omissions are easy to occur, and the consumed time is long, so that the accuracy and the efficiency of the software product test are reduced.
Disclosure of Invention
In view of the foregoing problems, an object of the embodiments of the present invention is to provide an automatic testing method and system for software products, aiming to improve the accuracy and efficiency of software product testing.
In order to solve the above technical problems, embodiments of the present invention provide the following technical solutions:
in a first aspect, an embodiment of the present invention provides an automatic testing method for a software product, where the method includes: acquiring a target test file, wherein a check code of the target test file is consistent with a check code of a to-be-detected version of a software product; acquiring a test requirement from the target test file, and displaying the test requirement to a user; receiving a test plan and a test case input by a user according to the test requirement, and receiving a test record input by the user, wherein the test record is a record of the condition when the target test file is tested according to the test plan and the test case; generating a test report for the test record.
In a second aspect, an embodiment of the present invention provides an automatic test system for a software product, where the system includes: the version confirmation unit is used for acquiring a target test file, and the check code of the target test file is consistent with the check code of the version to be detected of the software product; the version control unit is used for acquiring the test requirements from the target test file and displaying the test requirements to a user; the test execution unit is used for receiving a test plan and a test case input by a user according to the test requirement and receiving a test record input by the user, wherein the test record is a record of the condition when the target test file is tested according to the test plan and the test case; and the test summary unit is used for generating a test report aiming at the test record.
In a third aspect, an embodiment of the present invention provides an electronic device, where the electronic device includes: at least one processor; and at least one memory, bus connected with the processor; the processor and the memory complete mutual communication through the bus; the processor is configured to call the program instructions in the memory to perform the method according to one or more of the above-mentioned embodiments.
In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, where the storage medium includes a stored program, and when the program runs, a device in which the storage medium is located is controlled to perform a method in one or more of the above technical solutions.
The automatic test method and the system for the software product provided by the embodiment of the invention comprise the following steps of firstly, acquiring a target test file, wherein a check code of the target test file is consistent with a check code of a to-be-detected version of the software product; then, acquiring a test requirement from the target test file, and displaying the test requirement to a user; then, receiving a test plan and a test case input by a user according to the test requirement, and receiving a test record input by the user, wherein the test record is a record of the condition when the target test file is tested according to the test plan and the test case; finally, a test report is generated for the test record. Compared with the problem that the software product is easily tested by manpower, mistakes and omissions are easy to occur, and the time consumption is long, the automatic testing method and the system for the software product provided by the embodiment of the invention can automatically test the software product, can directly acquire correct target test files, can automatically extract test requirements, and can automatically generate test reports, so that mistakes and omissions can be avoided, the time consumption is short, and the accuracy and the efficiency of software product testing are improved.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 is a block diagram of a method for automatically testing a software product according to an embodiment of the present invention;
FIG. 2 is a first flowchart of a method for automatically testing a software product according to an embodiment of the present invention;
FIG. 3 is a second flowchart of a method for automatically testing a software product according to an embodiment of the present invention;
FIG. 4 is a schematic structural diagram of an automatic test system for software products according to an embodiment of the present invention;
FIG. 5 is a diagram illustrating a structure of a version verification unit according to an embodiment of the present invention;
FIG. 6 is a schematic structural diagram of a version control unit according to an embodiment of the present invention;
FIG. 7 is a block diagram of a test execution unit according to an embodiment of the present invention;
FIG. 8 is a schematic structural diagram of a test summary unit according to an embodiment of the present invention;
fig. 9 is a schematic structural diagram of an electronic device in an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
The embodiment of the invention provides an automatic test method for a software product, and firstly, it needs to be explained that the automatic test method for the software product provided by the embodiment of the invention is suitable for the right side in a traditional V model. The so-called V model, namely, Rapid Application Development (RAD) model, is an important model in the software Development process, and is also called V model because its model composition is similar to the letter V. On the right side of the V model, all the links of the software product test are mainly included. Specifically, the method comprises the following steps: software integration test, software validation test, system integration test, and system validation test. From the time of receiving the test task, the steps of confirming the test version, extracting the test requirement, designing and executing the test, generating the test report, and the like need to be performed in sequence. The automatic testing method of the software product provided by the embodiment of the invention is mainly described according to the four steps.
In practical application, the automatic test method for the software product provided by the embodiment of the invention can be used for testing various software products, and the software product to be tested is only suitable for each test link in the V model. For example: the software product may be a signal system product. In particular, it may be a rail transit signal system product. Of course, other aspects of the signal system product are also possible, and are not specifically limited herein.
Fig. 1 is an architecture diagram of an automatic testing method for a software product according to an embodiment of the present invention, and referring to fig. 1, the architecture may include: a configuration management library 101, an automatic test system 102, and a mail system 103. The automatic test system 102 may include: version confirmation unit 1021, version control unit 1022, test execution unit 1023, and test summary unit 1024.
Here, the configuration management library stores different versions of test files provided by developers, where the test files may be codes. The version confirmation unit can extract corresponding test files from the configuration management library, the version control unit can extract test requirements from the test files extracted by the version confirmation unit, the test execution unit can test the test files according to the test requirements extracted by the version confirmation unit, and the test summary unit can generate test reports according to test results of the test execution unit and then send the test reports to relevant personnel through a mail system.
Fig. 2 is a first flowchart of a method for automatically testing a software product according to an embodiment of the present invention, and referring to fig. 2, the method may include:
s201: and acquiring a target test file.
And the check code of the target test file is consistent with the check code of the version to be detected of the software product.
Specifically, after the software product is developed, the developer uploads the test file to the configuration manager for storage. Because the software product is continuously upgraded in the development process of the software product, test files of different versions are stored in the configuration manager. The check codes of different test files are different, so that the target test file can be accurately found in the configuration management library according to the check code of the to-be-detected version of the software product provided by research personnel.
In practical applications, the check code may be an MD5 value. Of course, other types of check codes are also possible, and are not limited in particular.
S202: and acquiring the test requirements from the target test file, and displaying the test requirements to the user.
Generally, the test file includes: test requirements files, source code files, and software executables. The test requirement file comprises the following components: the label and the label content are tested. The developer will fill the test item in the test label in advance, and fill the specific test content in the label content. Therefore, after the test file is obtained, the test requirement file can be extracted from the test file, the test label and the test content can be extracted from the test requirement file, and the test requirement can be further obtained. The source code file and the software executable program are both core contents of the software product, and are specifically used in the process of executing the test, so that the description is not repeated here.
After the test requirements are acquired, a test requirement list can be generated according to the test requirements, the test requirements are listed orderly and displayed to a user, and the user can be a tester. By showing the test requirements to the tester, the tester can clearly know what kind of test needs to be performed at this time.
S203: receiving a test plan and a test case input by a user according to the test requirement, and receiving a test record input by the user.
In the specific implementation process, after the testing personnel see the testing requirements, a proper testing plan and a proper testing case can be determined according to the testing requirements. Here, both the test plan and the test cases have a fixed format. The test plan includes: reference documents, test environments, test contents, tester configuration, product admission approval conditions, distribution of test requirements and the like. The test case comprises: the method comprises the following steps of testing a precondition, the requirement covered by a test case, the testing step and content, the testing execution condition, the test case execution record and the like. The tester only needs to fill in corresponding content at the corresponding position.
And then testing the target test file according to the test plan and the test case. In the process of testing the target test file, a tester can record in the test record based on the actual test situation, wherein the test record is the record of problems occurring when the target test file is tested according to the test plan and the test case. For example: the tester can record the product problems, the test environment problems, the observed abnormal phenomena and the like in the test record. Specifically, the test record may record a description of the problem, a test date, a tester, a rating of the problem, a component associated with the problem, and the like. Of course, other contents may be recorded, and are not particularly limited herein.
However, in the process of testing the target test file, if no problem occurs, a text or a mark capable of indicating that the test is normal can be written in the test record.
After the target file is tested, the tester fills the test record, and at this time, the test record is saved for being used as reference data of a test report in the following.
S204: a test report is generated for the test record.
The test records are records of various problems encountered in the process of testing the target test file according to the test plan and the test cases, the test plan and the test cases are formulated by testers according to test requirements, and the test requirements are extracted from the target test file, so that all problems possibly existing in the target test file are recorded in the test records, and further, the test reports generated aiming at the test records can comprehensively reflect the problems existing in the target test file.
As can be seen from the above, in the automatic test method for a software product according to the embodiment of the present invention, first, a target test file is obtained, and a check code of the target test file is consistent with a check code of a to-be-detected version of the software product; then, acquiring a test requirement from the target test file, and displaying the test requirement to a user; then, receiving a test plan and a test case input by a user according to the test requirement, and receiving a test record input by the user, wherein the test record is a record of the condition when the target test file is tested according to the test plan and the test case; finally, a test report is generated for the test record. Compared with the problem that the software product is easily tested by manpower, the automatic testing method of the software product provided by the embodiment of the invention has the advantages that the software product can be automatically tested, the correct target test file can be directly obtained, the test requirement can be automatically extracted, the test report can be automatically generated, the occurrence of error and leakage can be avoided, the consumed time is short, and the accuracy and the efficiency of the software product test are improved.
Further, as a refinement and an extension of the method shown in fig. 2, the embodiment of the present invention further provides an automatic testing method for a software product. Fig. 3 is a second flowchart of an automatic testing method for a software product according to an embodiment of the present invention, and referring to fig. 3, the method may include:
s301: and acquiring a test application form input by a user.
The test application form comprises a check code of the to-be-detected version of the software product.
Here, the user may be a developer of the software product, or may be a tester of the software product. When a developer needs a tester to test a code of a certain version of a software product developed by the developer, the developer fills a test application form with a check code of a test file containing the code of the version. When a tester needs to test a code of a certain version of a software product developed by a certain developer, the tester fills the check code of a test file containing the code of the version into a test application form. The user is not specifically limited to the developer, the tester, or other personnel.
Because the configuration management library stores the test files of different versions, and the check codes of the test files of different versions are different, after the test application form is obtained, the target test file consistent with the check codes in the test application form can be obtained from the configuration management library.
Specifically, the test application form includes not only the check code of the version to be detected of the software product, but also the name and the storage path of the version to be detected of the software product.
S302: and extracting the test file corresponding to the name in the test application form from the configuration management library according to the storage path in the test application form.
In the configuration management library, all versions of the software products are stored in different positions according to different storage paths, and are correspondingly stored by version names and version codes. Therefore, the test file corresponding to the name in the test application form can be quickly found by testing the storage path in the application form.
S303: and calculating the check code of the test file corresponding to the name.
In order to further verify whether the test file corresponding to the name is the target test file, the check code of the test file corresponding to the name needs to be calculated. The specific type of the check code is already described in step S201, and thus is not described herein again.
S304: and comparing the check code of the test file corresponding to the name with the check code in the test application form.
Since the check codes of the test files of different versions of the software product are different, that is, the check codes of the same version of the software product are the same, the check codes of the test files corresponding to the names are compared with the check codes in the test application form, and whether the test files acquired from the configuration management library are the target files can be determined.
Specifically, if the comparison result is consistent, it indicates that the test file obtained from the configuration management library is correct, and is the target test file, then the step S305 is executed continuously. If the comparison result is not consistent, it indicates that the test file obtained from the configuration management library is not correct, or the target test file does not exist in the configuration management library, then step S313 is executed continuously.
S305: and taking the test file corresponding to the name as a target test file.
Meanwhile, the target test file is stored and filed so as to be convenient for looking up various files in the test process in the following.
At this point, the validation process of the test version is completed.
S306: and acquiring the test requirements from the target test file, and displaying the test requirements to the user.
The process of specifically acquiring the test requirement has already been described in detail in step S202, and thus is not described herein again.
S307: and judging whether the test requirement belongs to regression test.
The regression test refers to a test performed on the current version again when the last version (i.e. the version released last time) is modified to obtain the current version, so as to confirm that no new error is introduced into the modification or that no error is generated in other codes. The regression test can greatly reduce the cost of the system test, the maintenance upgrade and other stages, so that whether the test requirement belongs to the regression test is judged, and if the test requirement belongs to the regression test, the regression test on the test file is necessary.
Specifically, if it is determined that the test requirement belongs to a regression test, steps S308-S309 are performed. If it is determined that the test requirement does not belong to the regression test, step S310 is performed.
S308: and comparing the file of the software product which is released last time with the target test file to generate a change report, and displaying the change report to a user.
Wherein the change report is used for indicating the change content and the influence range of the target test file compared with the file of the software product which is released last time. The scope of influence here may refer to the scope of influence in the source code. Since the test file includes the test requirement indicating the test purpose at that time and the core content (source code) of the software product, the change report includes the content of change and the influence range of the test requirement and the source code.
It should be noted that, compared with the file of the software product released last time, the target test file may only modify the test requirement without modifying the source code, and at this time, the change report only includes the change content and the influence range of the test requirement; it is also possible that the source code is modified without modifying the test requirement, and the change report only includes the change content and the influence range of the source code; it is also possible to modify both the test requirements and the source code, and the change report includes both the change content and the influence range of the test requirements and the change content and the influence range of the source code. Therefore, only the content of the change is included in the change report, so that the user can quickly and clearly know the place of the change in the test file.
In particular implementations, the specific determination may be different when determining the impact of a change in test requirements than when determining the impact of a change in source code.
For determining the influence range of the test requirement change, specifically, the test requirement corresponding to the file of the software product which is released most recently is compared with the test requirement of the target test file, and the test requirement which changes in the target test file and the influence range thereof are determined according to the relation between the test requirement and each functional module in the software product. Because different test requirements correspond to different functional modules in the software product, which functional modules need to be tested can be determined according to the changed test requirements, and then the influence range of the time is determined.
For determining the influence range of the source code change, specifically, the source code in the file of the software product which is released last time is compared with the source code in the target test file, and the source code and the influence range of the change in the target test file are determined according to the logic structure in the source code. Because the source codes have the logic structure, when a certain position in the source codes is changed, other positions in the source codes having the logic relation with the certain position are also changed at any time, so that all the changed codes in the source codes can be determined according to the logic structure between the source codes, and the influence range of the time is further determined.
Here, the logical structure between the source codes includes a mutual calling relationship between the source codes.
It should be noted that, when comparing the file of the software product that is released last time with the target test file, it may be first to compare whether the content of the test requirement and the content of the source code change, when it is determined that the content of the test requirement changes, the influence range of the changed test requirement is determined, and when it is determined that the content of the source code changes, the influence range of the changed source code is determined. Thus, the generation efficiency of the change report can be improved.
Thus, the extraction process of the test requirement is completed.
S309: and receiving a test plan and a test case which are input by a user according to the test requirement and the change report, and receiving a test record input by the user.
The details of the test plan, the test case, and the test record have been described in detail in step S203, and therefore are not described herein again.
S310: receiving a test plan and a test case input by a user according to the test requirement, and receiving a test record input by the user.
The details of the test plan, the test case, and the test record have been described in detail in step S203, and therefore are not described herein again.
Thus, the design and execution process of the test is completed.
S311: when an abnormal condition exists in the test record, receiving a test question input by a user aiming at the test record and a feedback opinion aiming at the test question.
The user may refer to a developer, a tester, or other personnel, as long as the personnel can summarize and feed back the problems recorded in the test record, and the specific identity of the personnel is not limited herein.
Also, the user may write test questions and feedback comments in the defect record and save the defect record in the configuration management library for subsequent extraction to generate test reports.
For example, when there is an abnormal situation in the test record, the tester may feed back the abnormal situation to the research and development personnel, and the research and development personnel can determine the test problem for the abnormal situation and provide a feedback suggestion for the test problem, write the feedback suggestion into the defect record, and store the defect record in the configuration management library.
S312: test reports are generated for the test records, test questions and feedback opinions.
In the specific implementation process, the test report is generated according to the test record, the test problem and the feedback opinion, and the method comprises the following four steps:
the first step is as follows: and extracting defect keywords from the test questions and the feedback opinions.
Here, the defect key is used to summarize the abnormal situation in the test record.
The second step is that: and determining the defect generation reason and the defect grade corresponding to the defect keyword from the preset defect corresponding relation.
Here, the defect correspondence relationship is a correspondence relationship between the defect keyword and the defect occurrence cause and the defect level, and may be generated in advance from a conventional test experience and stored in the system.
The third step: and determining defect distribution from the test records according to the defect keywords.
Since the test record records the problems occurring at various places in the target test file, the distribution of the defects in the target test file can be obtained from the test record according to the defect key.
The fourth step: and generating a test report based on the defect generation reason, the defect grade and the defect distribution.
In the specific implementation process, the test plan, the test cases and the test records, as well as the defect generation reasons, the defect levels and the defect distribution can be written into corresponding positions in the test report to generate the test report with a fixed format, so that a user can clearly know the whole test process, the test result and the defect analysis.
It should be noted that the third step may be performed after the second step, simultaneously with the second step, or before the second step. The execution order of the second step and the third step is not particularly limited.
Of course, when there is no abnormal condition in the test record, it is not necessary to receive the test problem input by the user for the test record and the feedback opinion for the test problem, and the test report can be directly generated to show that there is no problem in the test.
At this point, the generation process of the test report is completed.
In addition, after the test report is generated, the target test file, the test requirement, the test plan, the test case, the test record and the test report can be correspondingly stored so that the following relevant personnel can check the test report at any time. Furthermore, the test report can be sent to the relevant responsible person through the mail system so as to inform the relevant responsible person of the test condition. The related responsible person may refer to a superior leader of a tester, a developer or a developer, and is not particularly limited herein.
S313: the test is ended.
At this point, the entire testing process of the software product is completed.
As can be seen from the above, in the automatic test method for a software product according to the embodiment of the present invention, first, a target test file is obtained, and a check code of the target test file is consistent with a check code of a to-be-detected version of the software product; then, acquiring a test requirement from the target test file, and displaying the test requirement to a user; then, receiving a test plan and a test case input by a user according to the test requirement, and receiving a test record input by the user, wherein the test record is a record of the condition when the target test file is tested according to the test plan and the test case; finally, a test report is generated for the test record. Compared with the problem that the software product is easily tested by manpower, the automatic testing method of the software product provided by the embodiment of the invention has the advantages that the software product can be automatically tested, the correct target test file can be directly obtained, the test requirement can be automatically extracted, the test report can be automatically generated, the occurrence of error and leakage can be avoided, the consumed time is short, and the accuracy and the efficiency of the software product test are improved.
Based on the same inventive concept, as the implementation of the method, the embodiment of the invention also provides an automatic test system of the software product. Fig. 4 is a schematic structural diagram of an automatic test system for software products in an embodiment of the present invention, and referring to fig. 4, the system 102 may include: the version confirmation unit 1021 is used for acquiring a target test file, and the check code of the target test file is consistent with the check code of the version to be detected of the software product; the version control unit 1022 is configured to obtain a test requirement from the target test file, and display the test requirement to a user; the test execution unit 1023 is used for receiving a test plan and a test case input by a user according to the test requirement and receiving a test record input by the user, wherein the test record is a record of the condition when the target test file is tested according to the test plan and the test case; and the test summary unit 1024 is used for generating a test report for the test record.
Fig. 5 is a schematic structural diagram of a version confirmation unit according to an embodiment of the present invention, and referring to fig. 5, the version confirmation unit 1021 may include: a list import module 1021A, a file extraction module 1021B, a file check module 1021C, and a file export module 1021D.
The file verification module is used for comparing the extracted verification codes of the test files with the verification codes in the test application form, and the file export module is used for exporting the test files when the comparison is consistent.
Fig. 6 is a schematic structural diagram of a version control unit in an embodiment of the present invention, and referring to fig. 6, the version control unit 1022 may include: a requirement extraction module 1022A, a change comparison module 1022B, an influence analysis module 1022C, and a file recording module 1022D.
The system comprises a requirement extraction module, a change comparison module, an influence analysis module and a file recording module, wherein the requirement extraction module is used for extracting a test requirement in a target test file, the change comparison module is used for comparing the change of the target test file with a file which is released last time, the influence analysis module is used for analyzing the influence range of the content of the change in the target test file, and the file recording module is used for filing the target test file.
Fig. 7 is a schematic structural diagram of a test execution unit according to an embodiment of the present invention, and referring to fig. 7, the test execution unit 1023 may include: the test plan module 1023A, the test case module 1023B, the test record module 1023C and the test question module 1023D.
The test plan module is used for receiving a test plan, the test case module is used for receiving a test case, the test record module is used for receiving a test record, and the test problem module is used for receiving a test problem.
Fig. 8 is a schematic structural diagram of a test summary unit in an embodiment of the present invention, and referring to fig. 8, the test summary unit 1024 may include: a result analysis module 1024A, a report generation module 1024B, a document export module 1024C, and a conclusion reporting module 1024D.
The result analysis module is used for analyzing reasons, grades, distribution and the like of the defects, the report generation module is used for generating a test report, the document export module is used for exporting a target test file, and a conclusion reporting module user sends out the test report through a mail.
Based on the foregoing embodiment, the version confirmation unit is configured to obtain a test application form input by a user, where the test application form includes a check code of the to-be-detected version of the software product; and acquiring a target test file consistent with the check code in the test application form from a configuration management library, wherein the configuration management library is used for storing test files of different versions, and the check codes of the test files of different versions are different.
Based on the foregoing embodiment, the version confirmation unit is configured to extract, from the configuration management library, the test file corresponding to the name in the test application form according to the storage path in the test application form; calculating a check code of the test file corresponding to the name; comparing the check code of the test file corresponding to the name with the check code in the test application form; and if the check code of the test file corresponding to the name is consistent with the check code in the test application form, taking the test file corresponding to the name as a target test file.
Based on the foregoing embodiment, the version confirmation unit is configured to end the test if the check code of the test file corresponding to the name is inconsistent with the check code in the test application form.
Based on the foregoing embodiment, the version control unit is configured to determine whether the test requirement belongs to a regression test; if the test requirement belongs to regression test, comparing the file of the software product which is released last time with the target test file to generate a change report, and displaying the change report to a user, wherein the change report is used for indicating the test requirement in the file and/or the change content and the influence range of the source code; and the test execution unit is used for receiving the test plan and the test case which are input by the user according to the test requirement and the change report.
Based on the foregoing embodiment, the version control unit is configured to compare a test requirement corresponding to a file of a software product that is released most recently with a test requirement of a target test file, and determine a test requirement and an influence range thereof that vary in the target test file according to a relationship between the test requirement and each functional module in the software product; and/or comparing the source code in the file of the software product which is released last time with the source code in the target test file, and determining the source code which changes in the target test file and the influence range thereof according to the logic structure in the source code.
Based on the foregoing embodiment, the test execution unit is configured to receive a test question input by a user for the test record and a feedback opinion about the test question when an abnormal condition exists in the test record; and the test summary unit is used for generating a test report aiming at the test record, the test problem and the feedback opinion.
Based on the foregoing embodiment, the test summary unit is configured to extract a defect keyword from the test question and the feedback opinion, where the defect keyword is used to summarize an abnormal situation in the test record; determining a defect generation reason and a defect grade corresponding to the defect keyword from a preset defect corresponding relation, wherein the defect corresponding relation is the corresponding relation between the defect keyword and the defect generation reason and the defect grade; determining defect distribution from the test records according to the defect keywords; and generating a test report based on the defect generation reason, the defect grade and the defect distribution.
Based on the foregoing embodiment, the system further comprises: a storage unit; and the storage unit is used for storing the target test file, the test requirement, the test plan, the test case, the test record and the test report.
Here, it should be noted that: the above description of the apparatus embodiments, similar to the above description of the method embodiments, has similar beneficial effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus according to the invention, reference is made to the description of the embodiments of the method according to the invention for understanding.
Based on the same inventive concept, the embodiment of the invention also provides electronic equipment. Fig. 9 is a schematic structural diagram of an electronic device in an embodiment of the present invention, and referring to fig. 9, the electronic device 90 may include: at least one processor 901; and at least one memory 902, bus 903 connected to processor 901; the processor 901 and the memory 902 complete communication with each other through the bus 903; the processor 901 is configured to call program instructions in the memory 902 to perform the method in one or more embodiments described above.
Here, it should be noted that: the above description of the embodiments of the electronic device is similar to the description of the embodiments of the method described above, and has similar advantageous effects to the embodiments of the method. For technical details not disclosed in the embodiments of the electronic device according to the embodiments of the present invention, please refer to the description of the method embodiments of the present invention.
Based on the same inventive concept, the embodiment of the present invention further provides a computer-readable storage medium, where the computer-readable storage medium includes a stored program, and when the program runs, the apparatus on which the storage medium is located is controlled to execute the method in one or more embodiments described above.
Here, it should be noted that: the above description of the computer-readable storage medium embodiments is similar to the description of the method embodiments described above, with similar beneficial effects as the method embodiments. For technical details not disclosed in the embodiments of the computer-readable storage medium of the embodiments of the present invention, reference is made to the description of the method embodiments of the present invention for understanding.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in the process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The above are merely examples of the present application and are not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.
Claims (10)
1. A method for automated testing of a software product, the method comprising:
acquiring a target test file, wherein a check code of the target test file is consistent with a check code of a to-be-detected version of a software product;
acquiring a test requirement from the target test file, and displaying the test requirement to a user;
receiving a test plan and a test case input by a user according to the test requirement, and receiving a test record input by the user, wherein the test record is a record of the condition when the target test file is tested according to the test plan and the test case;
generating a test report for the test record.
2. The method of claim 1, wherein obtaining the target test file comprises:
acquiring a test application form input by a user, wherein the test application form comprises a check code of a to-be-detected version of the software product;
and acquiring a target test file consistent with the check code in the test application form from a configuration management library, wherein the configuration management library is used for storing test files of different versions, and the check codes of the test files of different versions are different.
3. The method according to claim 2, wherein the test application form further comprises a name and a storage path of the to-be-detected version of the software product; the obtaining of the target test file consistent with the check code in the test application form from the configuration management library includes:
extracting a test file corresponding to the name in the test application form from the configuration management library according to the storage path in the test application form;
calculating the check code of the test file corresponding to the name;
comparing the check code of the test file corresponding to the name with the check code in the test application form;
and if the check code of the test file corresponding to the name is consistent with the check code in the test application form, taking the test file corresponding to the name as the target test file.
4. The method of claim 3, wherein after comparing the check code of the test file corresponding to the name with the check code in the test application form, the method further comprises:
and if the check code of the test file corresponding to the name is inconsistent with the check code in the test application form, ending the test.
5. The method of claim 1, wherein after said obtaining test requirements from said target test file, said method further comprises:
judging whether the test requirement belongs to regression test;
if the test requirement belongs to regression test, comparing the file of the software product which is released most recently with the target test file to generate a change report, and displaying the change report to a user, wherein the change report is used for indicating the test requirement in the file and/or the change content and the influence range of the source code;
the receiving of the test plan and the test case input by the user according to the test requirement includes:
and receiving a test plan and a test case which are input by a user according to the test requirement and the change report.
6. The method of claim 5, wherein comparing the file of the software product most recently released with the target test file comprises:
comparing the test requirement corresponding to the file of the software product which is released last time with the test requirement of the target test file, and determining the test requirement which changes in the target test file and the influence range thereof according to the relation between the test requirement and each functional module in the software product; and/or the presence of a gas in the gas,
comparing the source code in the file of the software product which is released last time with the source code in the target test file, and determining the source code which changes in the target test file and the influence range thereof according to the logic structure in the source code.
7. The method of claim 1, wherein after receiving the test plan and the test case input by the user according to the test requirement and receiving the test record input by the user, the method further comprises:
when an abnormal condition exists in the test record, receiving a test question input by a user aiming at the test record and a feedback opinion aiming at the test question;
generating a test report for the test record, comprising:
generating the test report for the test record, the test question, and the feedback opinion.
8. The method of claim 7, wherein generating the test report for the test record, the test question, and the feedback opinion comprises:
extracting defect keywords from the test questions and the feedback opinions, wherein the defect keywords are used for summarizing abnormal conditions in the test records;
determining a defect generation reason and a defect grade corresponding to the defect keyword from a preset defect corresponding relationship, wherein the defect corresponding relationship is the corresponding relationship between the defect keyword and the defect generation reason and the defect grade;
determining defect distribution from the test record according to the defect keyword;
generating the test report based on the defect generation cause, the defect grade and the defect distribution.
9. The method of claim 1, further comprising:
and storing the target test file, the test requirement, the test plan, the test case, the test record and the test report.
10. An automated test system for software products, the system comprising:
the version confirmation unit is used for acquiring a target test file, and the check code of the target test file is consistent with the check code of the version to be detected of the software product;
the version control unit is used for acquiring the test requirements from the target test file and displaying the test requirements to a user;
the test execution unit is used for receiving a test plan and a test case input by a user according to the test requirement and receiving a test record input by the user, wherein the test record is a record of the condition when the target test file is tested according to the test plan and the test case;
and the test summary unit is used for generating a test report aiming at the test record.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010030306.7A CN111209206A (en) | 2020-01-13 | 2020-01-13 | Automatic test method and system for software product |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010030306.7A CN111209206A (en) | 2020-01-13 | 2020-01-13 | Automatic test method and system for software product |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111209206A true CN111209206A (en) | 2020-05-29 |
Family
ID=70785185
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010030306.7A Pending CN111209206A (en) | 2020-01-13 | 2020-01-13 | Automatic test method and system for software product |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111209206A (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112731910A (en) * | 2021-03-31 | 2021-04-30 | 卡斯柯信号(北京)有限公司 | Simulation test method and device for vehicle-mounted equipment |
| CN112965743A (en) * | 2021-03-10 | 2021-06-15 | 中国民航信息网络股份有限公司 | Software change management method and device, electronic equipment and storage medium |
| CN113238963A (en) * | 2021-06-16 | 2021-08-10 | 中国农业银行股份有限公司 | Test report generation method, device, equipment, storage medium and program product |
| CN115269443A (en) * | 2022-09-29 | 2022-11-01 | 中邮消费金融有限公司 | Software defect automatic positioning test method and system |
| CN116501653A (en) * | 2023-06-30 | 2023-07-28 | 卡斯柯信号(北京)有限公司 | Software regression testing method and device |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030182652A1 (en) * | 2001-12-21 | 2003-09-25 | Custodio Gabriel T. | Software building and deployment system and method |
| CN102521700A (en) * | 2011-12-13 | 2012-06-27 | 广东电网公司信息中心 | Electrical network informatization evaluation rapid test system |
| CN103246600A (en) * | 2012-02-10 | 2013-08-14 | 广州博纳信息技术有限公司 | Fast verification method for software testing and evaluation |
| CN103577319A (en) * | 2012-08-07 | 2014-02-12 | 腾讯科技（深圳）有限公司 | Source code file detection method, source code file detection device and file release system |
| CN107729227A (en) * | 2017-07-26 | 2018-02-23 | 上海壹账通金融科技有限公司 | Application testing range determining method, system, server and storage medium |
| CN110109834A (en) * | 2019-04-30 | 2019-08-09 | 贝壳技术有限公司 | A kind of test report automatically generating device and method |
| CN110147312A (en) * | 2019-04-09 | 2019-08-20 | 平安科技（深圳）有限公司 | Software development test method, device, computer installation and storage medium |
-
2020
- 2020-01-13 CN CN202010030306.7A patent/CN111209206A/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030182652A1 (en) * | 2001-12-21 | 2003-09-25 | Custodio Gabriel T. | Software building and deployment system and method |
| CN102521700A (en) * | 2011-12-13 | 2012-06-27 | 广东电网公司信息中心 | Electrical network informatization evaluation rapid test system |
| CN103246600A (en) * | 2012-02-10 | 2013-08-14 | 广州博纳信息技术有限公司 | Fast verification method for software testing and evaluation |
| CN103577319A (en) * | 2012-08-07 | 2014-02-12 | 腾讯科技（深圳）有限公司 | Source code file detection method, source code file detection device and file release system |
| CN107729227A (en) * | 2017-07-26 | 2018-02-23 | 上海壹账通金融科技有限公司 | Application testing range determining method, system, server and storage medium |
| CN110147312A (en) * | 2019-04-09 | 2019-08-20 | 平安科技（深圳）有限公司 | Software development test method, device, computer installation and storage medium |
| CN110109834A (en) * | 2019-04-30 | 2019-08-09 | 贝壳技术有限公司 | A kind of test report automatically generating device and method |
Non-Patent Citations (1)
| Title |
|---|
| 梁成才;: "软件测评实验室软件测试项目的度量研究", 计算机工程 * |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112965743A (en) * | 2021-03-10 | 2021-06-15 | 中国民航信息网络股份有限公司 | Software change management method and device, electronic equipment and storage medium |
| CN112731910A (en) * | 2021-03-31 | 2021-04-30 | 卡斯柯信号(北京)有限公司 | Simulation test method and device for vehicle-mounted equipment |
| CN112731910B (en) * | 2021-03-31 | 2021-07-30 | 卡斯柯信号(北京)有限公司 | Simulation test method and device for vehicle-mounted equipment |
| CN113238963A (en) * | 2021-06-16 | 2021-08-10 | 中国农业银行股份有限公司 | Test report generation method, device, equipment, storage medium and program product |
| CN115269443A (en) * | 2022-09-29 | 2022-11-01 | 中邮消费金融有限公司 | Software defect automatic positioning test method and system |
| CN116501653A (en) * | 2023-06-30 | 2023-07-28 | 卡斯柯信号(北京)有限公司 | Software regression testing method and device |
| CN116501653B (en) * | 2023-06-30 | 2023-10-03 | 卡斯柯信号(北京)有限公司 | Software regression testing method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111209206A (en) | Automatic test method and system for software product | |
| CN107665171B (en) | Automatic regression testing method and device | |
| CN108897724B (en) | Function completion progress determining method and device | |
| CN102831052B (en) | Test exemple automation generating apparatus and method | |
| US20050204241A1 (en) | Method and device for analyzing software error | |
| CN1908895B (en) | System and method for application program globalization problem verification | |
| US11599453B2 (en) | Vehicle function test apparatus and method of controlling the same | |
| CN110018954B (en) | Code quality detection method, device and equipment, and code detection quality evaluation method, device and equipment | |
| CN112181854B (en) | Method, device, equipment and storage medium for generating process automation script | |
| CN112306855A (en) | Interface automation test method, device, terminal and storage medium | |
| CN111026080A (en) | Hardware-in-loop test method and device for controller | |
| CN115328784A (en) | Agile interface-oriented automatic testing method and system | |
| CN116991751B (en) | Code testing method and device, electronic equipment and storage medium | |
| CN112711563A (en) | Method and system for detecting electronic file tetragonality | |
| CN115080426A (en) | Program file detection method and device, storage medium and electronic equipment | |
| CN114661615A (en) | FPGA software testing method and device | |
| CN114490413A (en) | Test data preparation method and device, storage medium and electronic equipment | |
| CN109374038B (en) | Change test method of nuclear security level instrument control product based on application prototype | |
| CN112015658A (en) | Method and device for generating software integration test case | |
| CN111143220A (en) | Training system and method for software test | |
| CN114791886B (en) | Software problem tracking method and system | |
| CN110688144B (en) | Method and device for optimizing service interface configuration and electronic equipment | |
| CN117785651A (en) | Test case processing method, case management platform, electronic equipment and storage medium | |
| CN117093490A (en) | Code processing method, device, computer equipment and storage medium | |
| CN116383049A (en) | Automatic count making method and device based on big data test |
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 |