CN111209206B - Automatic test method and system for software products - Google Patents

Automatic test method and system for software products Download PDF

Info

Publication number
CN111209206B
CN111209206B CN202010030306.7A CN202010030306A CN111209206B CN 111209206 B CN111209206 B CN 111209206B CN 202010030306 A CN202010030306 A CN 202010030306A CN 111209206 B CN111209206 B CN 111209206B
Authority
CN
China
Prior art keywords
test
file
defect
software product
target
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.)
Active
Application number
CN202010030306.7A
Other languages
Chinese (zh)
Other versions
CN111209206A (en
Inventor
张金洋
齐龙涛
张庆新
沈晨
李春慧
张瑞
曹欣
杨菲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Casco Signal Beijing Ltd
Original Assignee
Casco Signal Beijing Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Casco Signal Beijing Ltd filed Critical Casco Signal Beijing Ltd
Priority to CN202010030306.7A priority Critical patent/CN111209206B/en
Publication of CN111209206A publication Critical patent/CN111209206A/en
Application granted granted Critical
Publication of CN111209206B publication Critical patent/CN111209206B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

The embodiment of the invention provides an automatic test method and system for a software product, wherein the method comprises the following steps: obtaining a target test file, wherein the check code of the target test file is consistent with the check code of the version to be detected of the 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; a test report is generated for the test record. Compared with the method and the system for automatically testing the software product, which are provided by the embodiment of the invention, have the advantages that the software product is easy to leak and longer in time consumption, the method and the system for automatically testing the software product can avoid the occurrence of the leak, and the time consumption is shorter, so that the accuracy and the efficiency of testing the software product are improved.

Description

Automatic test method and system for software products
Technical Field
The present invention relates to the field of computers, and in particular, to a method and system for automatically testing a software product.
Background
Software product testing is an essential element in the development of software products. In the conventional software product testing process, most of the process from validating test files to outputting test reports is performed manually. The software product is tested manually, error and leakage are easy to occur, the time consumption is long, and the accuracy and the efficiency of the software product testing can be reduced.
Disclosure of Invention
In view of the above problems, an object of an embodiment of the present invention is to provide an automatic testing method and system for a software product, which aims to improve the accuracy and efficiency of testing the software product.
In order to solve the technical problems, the embodiment of the invention provides the following technical scheme:
In a first aspect, an embodiment of the present invention provides a method for automatically testing a software product, the method comprising: obtaining a target test file, wherein the check code of the target test file is consistent with the check code of the version to be detected of the 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; a test report is generated for the test record.
In a second aspect, embodiments of the present invention provide an automatic 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 summarizing unit is used for generating a test report for the test record.
In a third aspect, an embodiment of the present invention provides an electronic device, including: at least one processor; and at least one memory, bus connected to the processor; the processor and the memory complete communication with each other through the bus; the processor is configured to invoke the program instructions in the memory to perform the method of one or more of the above-described aspects.
In a fourth aspect, an embodiment of the present invention provides a computer readable storage medium, where the storage medium includes a stored program, where the program when executed controls a device in which the storage medium is located to perform a method in one or more of the foregoing technical solutions.
The embodiment of the invention provides an automatic test method and an automatic test system for a software product, wherein, firstly, a target test file is obtained, and the check code of the target test file is consistent with the check code of a version to be detected of the software product; then, acquiring a test requirement from a 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 method and the system for automatically testing the software product, the method and the system for automatically testing the software product can automatically test the software product, can directly acquire a correct target test file, can automatically extract test requirements and automatically generate a test report, can avoid the occurrence of error and leakage, and are short in time consumption, so that the accuracy and the efficiency of testing the software product 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 designate like parts throughout the figures. In the drawings:
FIG. 1 is a block diagram of an automatic test method for software products in an embodiment of the present invention;
FIG. 2 is a 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 an automatic test method for a software product according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of an automated test system for software products in an embodiment of the invention;
FIG. 5 is a schematic diagram of a version verification unit according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of a version control unit according to an embodiment of the present invention;
FIG. 7 is a schematic diagram of a test execution unit according to an embodiment of the present invention;
FIG. 8 is a schematic diagram of a test summarizing unit according to an embodiment of the invention;
Fig. 9 is a schematic structural diagram of an electronic device in an embodiment of the 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 present invention are shown in the drawings, it should be understood that the present invention may 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 is required to explain that the automatic test method for the software product provided by the embodiment of the invention is applicable to the right side in a traditional V model. The so-called V model, i.e. the rapid application development (Rapid Application Development, RAD) model, is an important model in the software development process, also called V model, since its model composition resembles the letter V. On the right side of the V model, all links for software product testing 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 start of receiving the test task, the steps of confirmation of the test version, extraction of the test requirement, design and execution of the test, generation of the test report and the like are required to be sequentially carried out. The automatic test method for the software product provided by the embodiment of the invention is mainly described in the following four steps.
In practical application, the automatic test method for the software product provided by the embodiment of the invention can test various software products, as long as the software product to be tested is 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 traffic signal system product. Of course, other aspects of the signal system product are also possible, and are not specifically limited herein.
FIG. 1 is a block diagram of an automatic test method for software products in an embodiment of the present invention, and referring to FIG. 1, the block diagram may include: a configuration management library 101, an automatic test system 102, and a mail system 103. Wherein the automatic test system 102 may comprise: a version confirmation unit 1021, a version control unit 1022, a test execution unit 1023, and a test summarization unit 1024.
Here, the configuration management library stores therein test files of different versions provided by the developer, 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, the test summarization unit can generate test reports according to test results of the test execution unit, and then the test reports are sent to related personnel through the mail system.
FIG. 2 is a flowchart I of a method for automatically testing a software product in an embodiment of the invention, and referring to FIG. 2, the method may include:
s201: and obtaining a target test file.
The verification code of the target test file is consistent with the verification code of the version to be detected of the software product.
Specifically, after the development of the software product is completed, the developer uploads the test file to the configuration manager for storage. Since the software product is continuously updated during the development process of the software product, different versions of the test file 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 the research and development 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 particularly limited herein.
S202: and acquiring the test requirements from the target test file and displaying the test requirements to a user.
Typically, the test file will include: test requirements files, source code files, and software executable programs. In the test requirement file, the method comprises the following steps: the tags and tag content are tested. The developer fills in test items in the test tag in advance, and fills in specific test contents in the tag contents. Therefore, after the test file is obtained, the test requirement file can be extracted from the test file, the test tag and the test content are extracted from the test requirement file, and then the test requirement is obtained. The source code file and the software executable program are the core content of the software product, and are specifically used in the process of performing the test, and will not be described here.
After the test requirements are obtained, 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 refer to 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: and 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 implementation process, after the tester sees the test requirement, the tester can determine the proper test plan and test case according to the test requirement. Here, both the test plan and the test cases have a fixed format. The test plan includes: reference documents, test environments, test content, tester configuration, product admission conditions, allocation of test requirements and the like. The test cases include: test preconditions, requirements for test case coverage, steps and contents of the test, execution conditions of the test, test case execution records and the like. The tester only needs to fill in the corresponding content at the corresponding position.
The target test file is then tested according to the test plan and test cases. In the process of testing the target test file, a tester can record in a test record based on the actual condition of the test, wherein the test record is the record of the 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 process in the test record. Specifically, descriptions of problems, test dates, testers, levels of problems, components associated with the problems, and the like may be recorded in the test record. 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 may be written in the test record.
After the test is finished on the target file, the test record is filled in by the tester, and the test record is saved at the moment so as to be used as reference data of a test report later.
S204: a test report is generated for the test record.
Because the test record is a record of various encountered problems in the process of testing the target test file according to the test plan and the test case, the test plan and the test case are formulated by a tester according to the test requirement, and the test requirement is extracted from the target test file, all the problems possibly existing in the target test file are recorded in the test record, and then the test report generated aiming at the test record 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 provided by 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 version to be detected of the software product; then, acquiring a test requirement from a 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 method for automatically testing the software product by manually testing the software product, the method for automatically testing 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, and the test report can be automatically generated, so that the error and the leakage can be avoided, the time consumption is short, and the accuracy and the efficiency of the software product test are further improved.
Further, as a refinement and extension of the method shown in fig. 2, the embodiment of the invention further provides an automatic testing method for software products. FIG. 3 is a second flowchart of a method for automatically testing 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 a to-be-detected version of the software product.
Here, the user may be a developer of the software product or a tester of the software product. When a developer needs a tester to test a certain version of code of a software product developed by the developer, the developer fills the test application form with the check code of the test file containing the version of code. When a tester needs to test a code of a certain version of a software product developed by a developer, the tester fills the test application form with a check code of a test file containing the code of the version. The user is not particularly limited herein as to whether it is a developer, a tester, or other personnel.
Because the configuration management library stores test files with different versions and the check codes of the test files with different versions are different, after the test application form is acquired, the target test file consistent with the check codes in the test application form can be acquired from the configuration management library.
Specifically, the test application form not only includes the check code of the version to be detected of the software product, but also includes 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, each version of the software product is stored in different locations according to different storage paths, and is stored with the name of the version and the code of the version corresponding to each other. Therefore, the test file corresponding to the name in the test application form can be quickly found through the storage path in the test 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, it is necessary to calculate the check code of the test file corresponding to the name. The specific type of the check code is already described in step S201, and will not be described here again.
S304: and comparing the check code of the test file corresponding to the name with the check code in the test application form.
Because 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, whether the test file obtained from the configuration management library is the target file can be determined by comparing the check code of the test file corresponding to the name with the check code in the test application form.
Specifically, if the comparison result is consistent, it indicates that the test file obtained from the configuration management library is correct, that is, the target test file, and then step S305 is continued. If the comparison result is inconsistent, it indicates that the test file obtained from the configuration management library is incorrect, or the target test file does not exist in the configuration management library, then step S313 is continued.
S305: and taking the test file corresponding to the name as a target test file.
Meanwhile, the target test file is stored and archived so as to be convenient for subsequent reference to various files in the process of the test.
Thus, the test version verification process is completed.
S306: and acquiring the test requirements from the target test file and displaying the test requirements to a user.
The process of specifically acquiring the test requirement is described in detail in step S202, and thus will not be described herein.
S307: and judging whether the test requirement belongs to a regression test.
The regression test refers to a test performed on the current version again in the case of modifying the previous version (i.e. the last released version) to obtain the current version, so as to confirm that no new error is introduced in the modification or other code is caused to generate errors. Because the regression test can greatly reduce the cost of the stages of system test, maintenance and upgrading, and the like, 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 requirements belong to the 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, generating a change report, and displaying the change report to a user.
Wherein the change report is used to indicate the change content and scope of influence of the target test file compared to the file of the last released software product. The scope of influence herein may refer to a scope of influence in source code. Since the test file includes the test requirements indicating the test purpose and the core content (source code) of the software product, the change report includes the change content and the influence range of the test requirements 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, but not modify 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 test requirements are not modified, but the source code is modified, 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, the change report only comprises the content for generating the change, so that a user can conveniently and quickly and clearly know the place for generating the change in the test file.
In particular implementations, the particular manner in which the range of influence of the change in test requirements is determined may vary from the range of influence of the change in source code.
For determining the influence range of the change of the test requirement, specifically, the test requirement corresponding to the file of the software product released last time is compared with the test requirement of the target test file, and the changed test requirement and the influence range thereof in the target test file 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, the functional modules which need to be tested can be determined according to the changed test requirements, and the influence scope of the time is further determined.
For determining the influence range of the change of the source code, specifically, the source code in the file of the software product 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 logic structures, a certain position in the source codes changes, and other positions in the source codes, which have logic relations with the certain position, also change at any time, so that all changed codes in the source codes can be determined according to the logic structures among the source codes, and the influence scope of the time is further determined.
Here, the logical structure between source code includes the inter-calling relationship between source code.
It should be noted that when comparing the file of the software product released last time with the target test file, whether the content of the test requirement and the content of the source code change can be compared first, when determining that the content of the test requirement changes, the influence range of the changed test requirement is determined, and when determining that the content of the source code changes, the influence range of the changed source code is determined. In this way, the efficiency of generating the change report can be improved.
Thus, the extraction process of the test requirements is completed.
S309: and receiving a test plan and a test case input by a user according to the test requirement and the change report, and receiving a test record input by the user.
The specific contents of the test plan, the test case and the test record are described in detail in step S203, so that they will not be described here again.
S310: and 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 specific contents of the test plan, the test case and the test record are described in detail in step S203, so that they will not be described here again.
Thus, the design and execution process of the test is completed.
S311: when abnormal conditions exist in the test records, receiving the test questions input by the user aiming at the test records and feedback comments aiming at the test questions.
The user may refer to a developer, a tester, or other personnel, as long as the personnel can make a summary and feedback about the problems recorded in the test record, and the specific identity of the personnel is not limited herein.
Also, the user may write the test questions and feedback comments in the defect record and save the defect record in the configuration management library for subsequent extraction to generate the test report.
For example, when an abnormal situation exists in the test record, the tester may feed back the abnormal situation to the developer, and the developer may determine a test problem for the abnormal situation and provide feedback comments for the test problem, write the feedback comments into the defect record, and store the feedback comments in the configuration management library.
S312: and generating a test report aiming at the test record, the test problem and the feedback opinion.
In a specific implementation process, generating a test report for a test record, a test problem and a feedback opinion may include the following four steps:
The first step: and extracting the defect keywords from the test questions and the feedback opinions.
Here, the defect key is used to summarize anomalies in the test record.
And a second step of: and determining the defect generation reason and defect grade corresponding to the defect keywords from the preset defect corresponding relation.
Here, the defect correspondence is a correspondence between a defect keyword and a defect generation cause and a defect level, and may be previously generated based on a conventional test experience and stored in the system.
And a third step of: and determining defect distribution from the test record according to the defect keywords.
Since the test record records the problems occurring everywhere in the target test file, the distribution of defects in the target test file can be obtained from the test record according to the defect keywords.
Fourth step: a test report is generated based on the defect generation cause, defect level, and defect distribution.
In the specific implementation process, the test plan, the test case and the test record, as well as the defect generation reasons, the defect levels and the defect distribution, can be written into the corresponding positions in the test report to generate a test report in a fixed format, so that a user can clearly know the whole test process, the test results and the defect analysis.
The third step may be performed after the second step, may be performed simultaneously with the second step, or may be performed before the second step. The execution sequence of the second step and the third step is not particularly limited herein.
Of course, when no abnormal condition exists in the test record, the test report can be directly generated without receiving the test problem input by the user aiming at the test record and the feedback opinion aiming at the test problem, so that the test is displayed without the problem.
Thus, 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 stored correspondingly, so that the follow-up related personnel can check 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 current test condition. The relevant responsible person herein may refer to a tester, a developer, or a superior lead of a developer, without specific limitation herein.
S313: ending the test.
Thus, the whole test process of the software product is completed.
As can be seen from the above, in the automatic test method for a software product provided by 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 version to be detected of the software product; then, acquiring a test requirement from a 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 method for automatically testing the software product by manually testing the software product, the method for automatically testing 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, and the test report can be automatically generated, so that the error and the leakage can be avoided, the time consumption is short, and the accuracy and the efficiency of the software product test are further improved.
Based on the same inventive concept, as an implementation of the method, the embodiment of the invention also provides an automatic test system for software products. FIG. 4 is a schematic 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; a test summarization unit 1024 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 manifest import module 1021A, a file extraction module 1021B, a file verification module 1021C, and a file export module 1021D.
The list importing module is used for receiving the test application form, the file extracting module is used for extracting the test file from the configuration management library, the file checking module is used for comparing the check code of the extracted test file with the check code in the test application form, and the file exporting module is used for exporting the test file 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 demand extraction module 1022A, a change comparison module 1022B, an impact analysis module 1022C, and a file recording module 1022D.
The system comprises a demand extraction module, a change comparison module, an influence analysis module, a file recording module and a target test file, wherein the demand extraction module is used for extracting test demands in the target test file, the change comparison module is used for comparing the change of the target test file and the file released last time, the influence analysis module is used for analyzing the influence range of the change content in the target test file, and the file recording module is used for archiving the target test file.
Fig. 7 is a schematic structural diagram of a test execution unit in an embodiment of the present invention, and referring to fig. 7, the test execution unit 1023 may include: test plan module 1023A, test case module 1023B, test record module 1023C, and 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 summarizing unit according to an embodiment of the present invention, and referring to fig. 8, the test summarizing unit 1024 may include: a results analysis module 1024A, a report generation module 1024B, a document derivation module 1024C, and a conclusion reporting module 1024D.
The system comprises a result analysis module, a report generation module, a document export module, a conclusion report module and a test report processing module, wherein the result analysis module is used for analyzing reasons, grades, distribution and the like of 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 report module user sends the test report through 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 a version to be detected 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, a test file corresponding to a name in the test application form according to a 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 the regression test, comparing the file of the software product which is released last time with the target test file, generating 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 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 last time with a test requirement of a target test file, and determine a test requirement and an influence range thereof that change 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 released last time with the source code in the target test file, and determining the source code and the influence range of the source code in the target test file 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 for the test question when an abnormal situation exists in the test record; and the test summarizing 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, a test summarizing unit for extracting a defect keyword from a test question and a feedback opinion, the defect keyword being used for summarizing abnormal conditions in a 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 as well as the defect grade; determining defect distribution from the test record according to the defect keywords; a test report is generated based on the defect generation cause, defect level, and defect distribution.
Based on the foregoing embodiment, the system further includes: 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.
It should be noted here that: the description of the apparatus embodiments above is similar to that of the method embodiments above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus of the present invention, please refer to the description of the embodiments of the method of the present invention.
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 connected to the processor 901, a bus 903; the processor 901 and the memory 902 complete communication with each other through the bus 903; processor 901 is operative to invoke program instructions in memory 902 to perform the methods in one or more embodiments described above.
It should be noted here that: the description of the electronic device embodiments above is similar to that of the method embodiments above, with similar benefits as the method embodiments. 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 for understanding.
Based on the same inventive concept, the embodiments of the present invention also provide a computer readable storage medium, where the computer readable storage medium includes a stored program, where the program controls a device where the storage medium is located to perform the method in one or more embodiments.
It should be noted here that: the description of the computer-readable storage medium embodiments above is similar to that of the method embodiments described above, with similar benefits as the method embodiments. For technical details not disclosed in embodiments of the computer-readable storage medium of embodiments of the present invention, please refer to the description of method embodiments of the present invention.
It will be appreciated by those skilled in the art that 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 flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations 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 one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, etc., such as Read Only Memory (ROM) or flash RAM. 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 storage media for a computer 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, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
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 one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises an element.
It will be appreciated by those skilled in the art that 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 foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and variations of the present application will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. which come within the spirit and principles of the application are to be included in the scope of the claims of the present application.

Claims (5)

1. A method for automatically testing a software product, the method comprising:
obtaining a target test file, wherein the check code of the target test file is consistent with the check code of the version to be detected of the 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;
the obtaining the target test file includes:
Acquiring a test application form input by a user, wherein the test application form comprises a check code of a version to be detected of the software product;
Obtaining target test files consistent with the check codes 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;
The test application form also comprises a name and a storage path of a version to be detected of the software product; the obtaining the target test file consistent with the check code in the test application form from the configuration management library comprises the following steps:
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 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;
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;
wherein after the obtaining the test requirement from the target test file, the method further comprises:
judging whether the test requirement belongs to a regression test or not;
If the test requirement belongs to a regression test, comparing the file of the software product which is released last time with the target test file, generating 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 the test plan and the test case input by the user according to the test requirement comprises the following steps:
Receiving a test plan and a test case input by a user according to the test requirement and the change report;
Wherein comparing the file of the software product 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 and the influence range of the change in the target test file according to the relation between the test requirement and each functional module in the software product;
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 the following steps:
when an abnormal condition exists in the test record, receiving a test problem input by a user aiming at the test record and feedback comments aiming at the test problem;
the generating a test report for the test record includes:
Generating the test report for the test record, the test question, and the feedback opinion;
wherein the generating the test report for the test record, the test question, and the feedback opinion includes:
extracting a defect keyword from the test questions and the feedback comments, wherein the defect keyword is 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 relation, wherein the defect corresponding relation is the corresponding relation between the defect keyword and the defect generation reason as well as the defect grade;
determining defect distribution from the test record according to the defect keywords;
the test report is generated based on the defect generation cause, the defect level, and the defect distribution.
2. The method of claim 1, 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.
3. The method of claim 1, wherein comparing the file of the last released software product with the target test file comprises:
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 and the influence range of the source code which are changed in the target test file according to the logic structure in the source code.
4. The method according to claim 1, wherein the method further comprises:
and storing the target test file, the test requirement, the test plan, the test case, the test record and the test report.
5. An automatic test system for a software product, 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;
a test summarization unit for generating a test report for the test record;
The system comprises a version confirmation unit, a software product detection unit and a software product detection unit, wherein the version confirmation unit is used for acquiring a test application form input by a user, and the test application form comprises a check code of a to-be-detected version of the software product; obtaining 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;
the test application form also comprises a name and a storage path of a version to be detected of the software product; the version confirmation unit is used for 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 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; if the check code of the test file corresponding to the name is consistent with the check code in the test application form, the test file corresponding to the name is used as a target test file;
The version control unit is used for judging whether the test requirement belongs to a regression test or not; if the test requirement belongs to the regression test, comparing the file of the software product which is released last time with the target test file, generating 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 test execution unit is used for receiving a test plan and a test case input by a user according to the test requirement and the change report;
The version control unit is used for 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 changed test requirement and the influence range of the test requirement in the target test file according to the relation between the test requirement and each functional module in the software product;
The test execution unit is used for receiving the test questions input by the user aiming at the test records and feedback comments aiming at the test questions when abnormal conditions exist in the test records; the test summarizing unit is used for generating a test report aiming at the test record, the test problem and the feedback opinion;
The test summarizing unit is used for extracting defect keywords from the test problems 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 relation, wherein the defect corresponding relation is the corresponding relation between the defect keyword and the defect generation reason as well as the defect grade; determining defect distribution from the test record according to the defect keywords; a test report is generated based on the defect generation cause, defect level, and defect distribution.
CN202010030306.7A 2020-01-13 2020-01-13 Automatic test method and system for software products Active CN111209206B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010030306.7A CN111209206B (en) 2020-01-13 2020-01-13 Automatic test method and system for software products

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010030306.7A CN111209206B (en) 2020-01-13 2020-01-13 Automatic test method and system for software products

Publications (2)

Publication Number Publication Date
CN111209206A CN111209206A (en) 2020-05-29
CN111209206B true CN111209206B (en) 2024-05-24

Family

ID=70785185

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010030306.7A Active CN111209206B (en) 2020-01-13 2020-01-13 Automatic test method and system for software products

Country Status (1)

Country Link
CN (1) CN111209206B (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
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
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
CN116501653B (en) * 2023-06-30 2023-10-03 卡斯柯信号(北京)有限公司 Software regression testing method and device

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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

Family Cites Families (1)

* Cited by examiner, † Cited by third party
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

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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)

* Cited by examiner, † Cited by third party
Title
软件测评实验室软件测试项目的度量研究;梁成才;;计算机工程(23);第90-92页 *

Also Published As

Publication number Publication date
CN111209206A (en) 2020-05-29

Similar Documents

Publication Publication Date Title
CN111209206B (en) Automatic test method and system for software products
CN102831052B (en) Test exemple automation generating apparatus and method
CN110018954B (en) Code quality detection method, device and equipment, and code detection quality evaluation method, device and equipment
CN112181800A (en) Vehicle function testing device and control method thereof
CN111026080A (en) Hardware-in-loop test method and device for controller
CN114816993A (en) Full link interface test method, system, medium and electronic equipment
CN116991751B (en) Code testing method and device, electronic equipment and storage medium
CN112711563A (en) Method and system for detecting electronic file tetragonality
CN117194242A (en) Log playback method and device for transaction system, electronic equipment and storage medium
CN116662197A (en) Automatic interface testing method, system, computer and readable storage medium
CN115080426A (en) Program file detection method and device, storage medium and electronic equipment
CN109697161A (en) A kind of test method of storing process, storage medium and database server
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
CN115571202B (en) Method and device for duplicating train control center system
CN111179997B (en) Method and device for storing test data of semiconductor memory
CN116932399A (en) Message generation method and device and nonvolatile storage medium
CN115134819B (en) Test method and device for train control wireless block system
CN111008138B (en) Method and device for processing code coverage rate and computer equipment
CN115129579A (en) Data auditing method and device based on data cutover
CN113986764A (en) Data checking test method and device, electronic equipment and storage medium
CN117785651A (en) Test case processing method, case management platform, electronic equipment and storage medium
CN105912435A (en) Test method and device for disk pressure
CN113238963A (en) Test report generation method, device, equipment, storage medium and program product
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
GR01 Patent grant
GR01 Patent grant