Test method, system and equipment after code change in software test and medium

Abstract

The invention relates to a software testing technology, and discloses a testing method after code change in software testing, which comprises the following steps: acquiring code change record data after successful deployment of a preset software version, acquiring a change code according to the code change record data, judging whether the change code is covered by an automatic use case or not, and if the change code is covered by the automatic use case, executing the step 2; if the change code is covered by the automatic use case, executing the automatic use case on the software after successful deployment to obtain a test result, if the change code is not covered by the automatic use case, judging whether the change code is covered by a manual use case, and if the change code is not covered by the manual use case, executing the automatic use case on the software after successful deployment to obtain a test result; and if the change code is covered by the manual case, sending identification error information to a tester, and if the change code is covered by the manual case, sending an instruction for executing the manual case to the tester. The invention further provides a testing system after code change in software testing, electronic equipment and a storage medium. The reliability of software testing can be improved.

Description

Technical Field

[0001] The present invention relates to the fields of software testing technology and financial technology, and in particular to a testing method, system, device and medium after code changes in software testing. Background Art

[0002] With the rapid development of the software industry and the financial industry, the complexity of financial software systems continues to increase (such as mobile banking software), and software quality assurance has become a key link in the development process. In order to ensure the quality of software products, such as the convenience of mobile banking and transaction security, software testing, as an important means of discovering and repairing defects, is becoming increasingly important. In the life cycle of software, code changes are a common and frequent process, which may be caused by functional enhancements, performance optimization (such as interactive interfaces that facilitate identification of related module functions), security patches, or bug fixes. Every code change may introduce new errors or change the behavior of existing functions. Therefore, effective testing of the changed code is the key to ensuring software quality.

[0003] However, when entering the testing phase, developers may still change the code. With existing software testing methods, there may be a situation where the code of a function that has passed the test verification has changed. The tester may unknowingly believe that the function has finally passed the test, but the actual changed code causes the function to be defective, which results in insufficient reliability. Summary of the invention

[0004] The present invention provides a testing method, system, device and medium after code change in software testing, the main purpose of which is to solve the problem of insufficient reliability of existing software testing methods after code change.

[0005] To achieve the above object, the present invention provides a method for testing software after code changes, comprising:

[0006] Obtain code change record data after the preset software version is successfully deployed;

[0007] Acquire the change code according to the code change record data;

[0008] Determine whether the changed code is covered by the automation use case;

[0009] If the changed code is covered by the automated test case, the automated test case is executed on the successfully deployed software to obtain the test result;

[0010] If the changed code is not covered by the automated use case, determining whether the changed code is covered by the manual use case;

[0011] If the changed code is not covered by the manual use case, an identification error message is sent to the tester;

[0012] If the changed code is covered by the manual use case, an instruction to execute the manual use case is sent to the tester.

[0013] In order to solve the above problem, the present invention further provides a testing system after code change in software testing, the system comprising:

[0014] A data acquisition module is used to acquire code change record data after a preset software version is successfully deployed, and acquire the changed code according to the code change record data;

[0015] The automated use case judgment module is used to judge whether the changed code is covered by the automated use case. If the changed code is covered by the automated use case, the automated use case is executed on the successfully deployed software to obtain the test result;

[0016] A manual use case judgment module is used to judge whether the changed code is covered by the manual use case if the changed code is not covered by the automated use case, and to send an identification error message to the tester if the changed code is not covered by the manual use case;

[0017] The instruction sending module sends an instruction to execute the manual use case to the tester if the changed code is covered by the manual use case.

[0018] In order to solve the above problem, the present invention further provides an electronic device, the electronic device comprising:

[0019] at least one processor;

[0020] and, a memory communicatively coupled to the at least one processor;

[0021] The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the test method after the code is changed in the above-mentioned software test.

[0022] In order to solve the above problems, the present invention also provides a computer-readable storage medium, in which at least one computer program is stored. The at least one computer program is executed by a processor in an electronic device to implement the above-mentioned testing method after code change in software testing.

[0023] The embodiment of the present invention obtains the code change record data after the preset software version is successfully deployed, obtains the change code according to the code change record data, determines whether the change code is covered by the automated use case, and if the change code is covered by the automated use case, executes the automated use case on the successfully deployed software to obtain the test result. If the change code is not covered by the automated use case, determines whether the change code is covered by the manual use case, and if the change code is not covered by the manual use case, sends an identification error message to the tester, and if the change code is covered by the manual use case, sends an instruction to execute the manual use case to the tester. This ensures that the change code is tested, avoids the occurrence of missed tests, and can solve the problem of insufficient reliability of existing software testing methods after code changes. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is a schematic diagram of an application environment of a testing method after code change in software testing in one embodiment of the present invention;

[0025] Figure 2 A flowchart of a testing method after code change in software testing provided by an embodiment of the present invention;

[0026] Figure 3 A schematic diagram of a process for obtaining a code change record provided by an embodiment of the present invention;

[0027] Figure 4 A schematic diagram of a process for obtaining code change data provided by an embodiment of the present invention;

[0028] Figure 5 A functional module diagram of a test system after code changes in software testing provided by an embodiment of the present invention;

[0029] Figure 6 A schematic diagram of the structure of an electronic device for implementing the testing method after code change in software testing provided by an embodiment of the present invention.

[0030] The realization of the purpose, functional features and advantages of the present invention will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0031] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0032] The embodiment of the present application provides a test method after the code is changed in software testing. The execution subject of the test method after the code is changed in the software test includes but is not limited to at least one of the electronic devices that can be configured to execute the method provided in the embodiment of the present application, such as a server, a terminal, etc. In other words, the test method after the code is changed in the software test can be executed by software or hardware installed on a terminal device or a server device, and the software can be a blockchain platform. The server includes but is not limited to: a single server, a server cluster, a cloud server or a cloud server cluster, etc. The server can be an independent server, or it can be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (Content Delivery Network, CDN), and basic cloud computing services such as big data and artificial intelligence platforms.

[0033] The intelligent question-answering processing method based on artificial intelligence provided by the embodiment of the present invention can be applied in Figure 1 In an application environment, the client communicates with the server through a network. The server can obtain the code change record data after the preset software version is successfully deployed through the client, obtain the change code according to the code change record data, and judge whether the change code is covered by the automated use case. If the change code is covered by the automated use case, the automated use case is executed on the software after the successful deployment to obtain the test result. If the change code is not covered by the automated use case, it is judged whether the change code is covered by the manual use case. If the change code is not covered by the manual use case, an identification error message is sent to the tester. If the change code is covered by the manual use case, an instruction to execute the manual use case is sent to the tester. It can effectively improve the efficiency and reliability of software testing in software development. Among them, the client can be but not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0034] Reference Figure 2 FIG. 1 is a flow chart of a test method after code change in software testing provided by an embodiment of the present invention. In this embodiment, the test method after code change in software testing includes:

[0035] S1. Obtain code change record data after the preset software version is successfully deployed.

[0036] In the embodiment of the present invention, the code change record data refers to the change record data between the current version code and the previous version code.

[0037] In detail, the code change record data refers to the detailed records generated when the code is modified, updated or optimized during the software development process. These record data capture in detail all changes that have occurred from the previous version to the current version of the code, including but not limited to newly added lines of code, deleted lines of code, modified code segments, and adjustments to the code structure. These changes may involve the addition of functions, performance improvements, bug fixes, or the resolution of security issues. The collection and analysis of code change record data is crucial for software testing and quality assurance. They provide a clear change track for the development team, allowing team members to understand the evolution of the code, evaluate the possible impact of the changes on the software system, and design and execute targeted test cases accordingly. Through these records, testers can more accurately locate the scope of the impact of the changes, thereby improving the efficiency and effectiveness of the test.

[0038] In the embodiment of the present invention, the code change record data is obtained by using a code management tool.

[0039] In detail, the code management tool is a system used to manage source code and documents in software development, which usually provides functions such as version control, access control, task tracking, document management, etc. Common code management tools include Git and Subversion (SVN).

[0040] In detail, the version control function allows developers to record the change history of the code, allowing the team to track the detailed changes of each submission, including the addition, deletion and modification of the code. This allows team members to view the historical status of the code at any time, or roll back to the previous version when necessary. Version control also supports branch management, allowing developers to develop different functions in parallel without interfering with each other.

[0041] In detail, in order to protect the security and integrity of source code, code management tools provide access control mechanisms to ensure that only authorized users can view or modify the code. This includes functions such as user authentication, permission allocation, and access logging to ensure that code access and modification are controllable and auditable.

[0042] In detail, code management tools are usually integrated with task tracking systems, enabling teams to plan, assign, and monitor tasks during the software development process. These tools can help project managers and developers set milestones, assign tasks, set deadlines, and track the progress and status of tasks.

[0043] In detail, in order to ensure the consistency and accessibility of project documents, code management tools provide document management functions. This allows team members to share, update and store project documents such as requirements, design documents, user manuals, etc. The document management function also supports document version control to ensure that the team can always access the latest document version.

[0044] In the embodiment of the present invention, Git is the most popular distributed version control system, which supports code branching, merging, rollback and other operations, can be used through command line tools or graphical user interface (GUI) clients, and integrated with hosting services such as GitHub, GitLab, Bitbucket, etc. Git is an efficient distributed version control system, which is widely used in today's software development field and has become the de facto standard for version control. The core advantage of Git lies in its distributed architecture, which means that each developer's local working environment contains the complete code repository history and all versions of the code base, making code management more flexible and reliable.

[0045] In detail, Git allows developers to easily create new branches to facilitate the parallel development of new features or bug fixes without affecting the stability of the main branch. Branches can be developed and tested independently, and once ready, they can be merged back to the main branch. Merging is a basic operation in Git that allows developers to integrate code changes from different branches together. Git's merge algorithm can handle complex merge scenarios, including conflict resolution and automatic merging. During the code development process, errors may occur or some changes may need to be undone. Git provides a rollback function that allows developers to easily undo to a previous state, whether it is to roll back to a specific commit or completely reset the current branch.

[0046] In the embodiment of the present invention, the Subversion is a mature centralized version control system, which is designed to manage changes to source code and other types of files. Unlike distributed version control systems, Subversion relies on a central server that stores the latest versions of all files and complete historical change records. This centralized architecture makes it easier for teams to control access to and changes to code.

[0047] In detail, Subversion supports atomic commits, which means that all changes are committed to the repository as a single, indivisible unit. This ensures that the state of the repository is always consistent and that conflicts do not arise even in the case of concurrent updates. Subversion allows users to create branches, which are different version lines of the code. Developers can experiment and develop on branches without affecting the stability of the main branch (or trunk). Branches can be used to develop new features, make bug fixes, or prepare releases. Subversion provides a tagging feature that allows users to mark specific versions of code, usually releases. Tags are immutable, and they provide a fixed point so that teams can easily roll back to previous releases.

[0048] In the embodiment of the present invention, referring to Figure 3 As shown, a schematic diagram of a process of obtaining a code change record is provided in an embodiment of the present invention, wherein the process of obtaining the code change record data after the preset software version is successfully deployed includes:

[0049] S21, obtaining pre-deployment status data of a project file before deployment of a preset software version;

[0050] S22, obtaining post-deployment status data of the project file after the preset software version is deployed;

[0051] S23. Obtain code change record data by comparing the pre-deployment status data and the post-deployment status data.

[0052] In detail, the comparison of the pre-deployment state data and the post-deployment state data is to compare the blob objects pointed to by the corresponding files in the pre-deployment state data and the post-deployment state data. If the hash values ​​of the blob objects are different, it means that the file content has changed.

[0053] Specifically, the comparison of the pre-deployment status data and the post-deployment status data is performed by collecting and recording the status data of the file. These status data include the metadata of the file and a reference to the blob object that stores the file content. The blob object is a data structure used to represent file data in the storage system, which usually contains the content of the file and some additional information. During the comparison process, the system extracts the corresponding file records in the pre-deployment status data and the post-deployment status data, and obtains the blob objects pointed to by these records. Then, the system compares the hash values ​​of the two blob objects. The hash value is a unique value calculated by a hash function from the file content, which can be used as a fingerprint of the file content. If the hash values ​​of the two blob objects are the same, this means that the file content has not changed before and after the deployment. On the contrary, if the hash values ​​are different, it means that the file content has changed during the deployment process.

[0054] In detail, the blob object is an object used to store the content of a file. When the file content changes, Git creates a new blob object for the new file content. The blob object is mainly used to store binary data, which can be various types of file content such as images, audio, video, documents, etc. It plays an important role in storing large amounts of unstructured data in the object database.

[0055] In detail, the hash value is a fixed-length string obtained by processing data (such as files, messages or any other form of data) with a hash function. A hash function is an algorithm that accepts input data of any size and produces an output of a fixed size. Regardless of the size of the input data, the hash function will produce an output of a fixed length. Ideally, each unique input data set should produce a unique hash value.

[0056] In the embodiment of the present invention, referring to Figure 4 As shown, a schematic diagram of a process of obtaining code change data is provided in an embodiment of the present invention, wherein the code change record data is obtained by comparing the pre-deployment state data and the post-deployment state data, including:

[0057] S31, obtaining a binary object of each project file in the pre-deployment state data to obtain a pre-deployment binary object set;

[0058] S32, obtaining a binary object of each project file in the post-deployment state data to obtain a post-deployment binary object set;

[0059] S33, calculating the hash value of the pre-deployment binary object set to obtain a first hash value set;

[0060] S34, calculating the hash value of the post-deployment binary object set to obtain a second hash value set;

[0061] S35, comparing the hash values ​​of corresponding positions in the first hash value set and the second hash value set to see whether they are the same, and obtaining a comparison result;

[0062] S36. Analyze the change record of the project file after the preset software version is deployed according to the comparison result to obtain the code change record.

[0063] In the embodiment of the present invention, the binary object of each project file in the pre-deployment state data is obtained to obtain a pre-deployment binary object set. In order to ensure version control and change management during software deployment, it is necessary to record and analyze the pre-deployment project file status in detail. This step involves obtaining the binary representation of each file in the project, that is, their original data form, in order to ensure that every detail of the file can be accurately captured, including file content, structure, and attributes.

[0064] In detail, the system will identify all project files whose status needs to be recorded before deployment. These files may include source code files, configuration files, resource files, documents, etc., which are the basis of the software project. For each project file in the pre-deployment state data, the system will extract its binary object. The binary object refers to the original binary data of the file, which contains all the information of the file, but does not include any text or encoding interpretation. The extracted binary objects will be organized into a collection, namely the pre-deployment binary object collection. This collection is a complete snapshot of the project file in its pre-deployment state, which provides basic data for subsequent comparison and analysis.

[0065] In the embodiment of the present invention, the change record of the project file after the deployment of the preset software version is analyzed according to the comparison result to obtain the code change record, which is to identify and record the change of the project file through comparison analysis after the software version is updated or deployed. This process involves a detailed comparison of the status of the preset software version before and after deployment, so as to accurately capture all changes that occur and generate corresponding code change records.

[0066] In the embodiment of the present invention, by acquiring the code change record data after the preset software version is successfully deployed, the efficiency of subsequently acquiring the changed code is improved.

[0067] S2. Obtain a change code according to the code change record data.

[0068] In the embodiment of the present invention, the changed code refers to the part of the code that is updated in the current version compared to the previous version. When the developer modifies the code base and submits the update, the part of the code that has changed in the current version relative to the previous version. These changes may include the addition of new features, modification of existing features, bug fixes, performance optimization, or other necessary improvements.

[0069] In the embodiment of the present invention, the step of obtaining the change code according to the code change record data includes:

[0070] Obtain source code data after successful deployment of the preset software;

[0071] Acquire the code file that has been changed in the source code data according to the code change record to obtain a change file;

[0072] The changed code in the changed file is obtained according to the code change record.

[0073] In an embodiment of the present invention, code change management is a key process that involves tracking and analyzing changes to source code during software development. In order to ensure the effectiveness of code version control and change management, the system uses code change records to identify and process changes in source code. Code change records are usually automatically generated by a version control system and record all changes to the code from one version to another. These records include, but are not limited to, operations such as adding, deleting, modifying, and renaming files. By analyzing these change records, the system can accurately identify code files that have changed in the latest version.

[0074] In detail, the code files that have been changed in the source code data are obtained according to the code change records to obtain the changed files, which is to use the system to read the code change records, which list in detail all the files that have changed since the previous version. The system will parse these records and extract the list of changed files, including information such as file names, change types and change contents. Then, the system will extract the corresponding files from the source code data based on this information, and these files are the changed code files.

[0075] In the embodiment of the present invention, by acquiring the changed code according to the code change record data, the efficiency of subsequent determination of whether the changed code is covered by the automation use case is improved.

[0076] S3. Determine whether the changed code is covered by the automation use case.

[0077] In the embodiment of the present invention, the automated use cases are a series of automated scripts used in the software testing process, which are used to verify the specific functions or performance of the application. Automated use cases can simulate the interaction between the user and the software to check whether the behavior of the software meets expectations. Automated use cases can quickly execute a large number of repetitive tests, improve testing efficiency, and reduce the possibility of human operation errors. Automated use cases can be integrated into the continuous integration / continuous deployment (CI / CD) process to ensure that code changes do not introduce new errors.

[0078] In detail, in the field of software testing, automated use cases are a set of well-designed automated scripts that are specifically used to systematically verify the various functions and performance indicators of an application. These use cases can automatically perform a series of predefined operations by simulating the interaction process between users and software, and evaluate whether the software's response is consistent with the expected results. The core advantage of automated use cases is that they can efficiently perform large-scale repetitive testing tasks. In the traditional manual testing process, testers need to repeat the same operations constantly, which is not only time-consuming and labor-intensive, but also easily interfered by human factors, resulting in inconsistent test results. In contrast, automated use cases can verify a large number of test scenarios in a short period of time, significantly improving the efficiency and coverage of testing. In addition, automated use cases greatly reduce the error rate in the testing process by reducing human operations. Once the test script is developed and verified, it can be reused in different test cycles to ensure the consistency and accuracy of the test.

[0079] In the embodiment of the present invention, the determining whether the changed code is covered by the automation use case includes:

[0080] Use pre-set code coverage tools to obtain code coverage records;

[0081] Acquire covered code in the changed code according to the code coverage record;

[0082] If there is an automation use case execution mark in the covered code, it is determined that the changed code is covered by the automation use case;

[0083] If there is no automation use case execution mark in the covered code, it is determined that the changed code is not covered by the automation use case.

[0084] In the embodiment of the present invention, by judging whether the changed code is covered by the automated use case, the efficiency of the subsequent judgment on whether the changed code is covered by the manual use case is improved.

[0085] If the changed code is covered by the automated test case, S4 is executed to execute the automated test case on the successfully deployed software to obtain the test result.

[0086] In an embodiment of the present invention, if there is an automated test case execution mark in the covered code, it is determined that the changed code is covered by the automated test case, which means that when the tester writes the automated test case, they will place a predefined mark in the corresponding code area. This mark can be a specific comment, a special code tag or any agreed identifier, and its purpose is to clearly identify the tested code segment in the code library. These marks serve as direct evidence of the execution of the automated test case, so that the test results can be associated with a specific code section. When performing test coverage analysis of the changed code, the system or tool will check the covered code area and look for these automated test case execution marks. If such a mark is found in a certain section of the changed code, the system will determine that this part of the code has been covered by the automated test case. This means that the code segment has passed the verification of at least one automated test case, and its function and performance meet the expected requirements.

[0087] In addition, the system may also record detailed information about the automated test cases associated with these tags, such as case name, test results, execution time, etc. This information helps the test team track test progress, evaluate test quality, and adjust or optimize test cases when necessary.

[0088] In the embodiment of the present invention, the step of executing automated test cases on the successfully deployed software to obtain test results includes:

[0089] Execute the automation use case on the changed code in the local operating environment to obtain an execution result;

[0090] Comparing the execution result with a preset expected result to obtain a comparison result;

[0091] Analyze the execution passing use cases and the execution failing use cases in the automation use cases according to the comparison results;

[0092] The test cases that passed the execution and the test cases that failed the execution are summarized to obtain the test results.

[0093] In an embodiment of the present invention, the automated use case is executed on the changed code in the local operating environment to obtain the execution result, in order to verify the correctness and stability of the changed code, and a method for executing automated use cases in the local operating environment is proposed. This method allows developers or testers to quickly test the code after it is changed to ensure that the change does not introduce new errors or affect existing functions. Specifically, when developers modify, add or delete the source code of the software, these changes constitute the so-called changed code. In order to evaluate the impact of these changes on the behavior of the software, it is necessary to execute a series of pre-defined automated test cases in the local operating environment. These use cases are specially designed for testing specific functions or modules of the software, and they can be executed automatically without human intervention.

[0094] In the embodiment of the present invention, when it is determined that the changed code is covered by the automated use case, the automated use case is executed on the successfully deployed software to obtain the test result, thereby improving the test efficiency.

[0095] If the changed code is not covered by the automated use case, S5 is executed to determine whether the changed code is covered by the manual use case.

[0096] In the embodiment of the present invention, the determining whether the changed code is covered by the manual use case includes:

[0097] Obtaining the test target function by analyzing the test target of the manual use case;

[0098] Analyze the implementation function of the changed code to obtain the code function;

[0099] If the test target function includes the code function, determining that the changed code is covered by the manual use case;

[0100] If the test target function does not include the code function, it is determined that the changed code is not covered by the manual use case.

[0101] In the embodiment of the present invention, when it is determined that the changed code is not covered by the automated use case, by determining whether the changed code is covered by the manual use case, the subsequent instruction to execute the manual use case is sent to the tester.

[0102] If the changed code is not covered by the manual use case, S6 is executed to send an identification error message to the tester.

[0103] In an embodiment of the present invention, when it is determined that the change code is not covered by the automated use case or the manual use case, it means that there may be an identification error in the above identification step, and therefore it is necessary to send the identification error information to the tester to prompt the tester to make further confirmation.

[0104] In the embodiment of the present invention, when it is determined that the changed code is not covered by the automated use case or the manual use case, the reliability of the test is improved by sending an identification error message to the tester.

[0105] If the changed code is covered by the manual use case, S7 is executed to send an instruction to execute the manual use case to the tester.

[0106] In the embodiment of the present invention, the instruction to execute the manual use case is sent to the tester by notifying the tester through the office system.

[0107] In the embodiment of the present invention, when it is determined that the changed code is not covered by the automated use case and the changed code is covered by the manual use case, an instruction to execute the manual use case is sent to the tester to ensure that the software is tested, thereby improving the reliability of software testing.

[0108] It can be seen that in the embodiment of the present invention, by identifying the changed code based on the code change record data, and then judging whether the changed code is covered by the use case, the corresponding code test is performed according to the type of covered use case to ensure that the changed code is tested and avoid missed tests, thereby greatly improving the reliability of code testing.

[0109] like Figure 5 , is a functional module diagram of a test system after code changes in software testing provided by an embodiment of the present invention.

[0110] The test system 100 after the code change in the software test of the present invention can be installed in an electronic device. According to the functions implemented, the test system 100 after the code change in the software test can include a data acquisition module 101, an automated case judgment module 102, a manual case judgment module 103 and an instruction sending module 104. The module of the present invention can also be called a unit, which refers to a series of computer program segments that can be executed by an electronic device processor and can complete fixed functions, which are stored in the memory of the electronic device.

[0111] In this embodiment, the functions of each module / unit are as follows:

[0112] The data acquisition module 101 is used to acquire code change record data after the preset software version is successfully deployed, and acquire the changed code according to the code change record data;

[0113] The automation case judgment module 102 is used to judge whether the changed code is covered by the automation case. If the changed code is covered by the automation case, the automation case is executed on the successfully deployed software to obtain the test result;

[0114] The manual use case judgment module 103 is used to judge whether the changed code is covered by the manual use case if the changed code is not covered by the automated use case, and send an identification error message to the tester if the changed code is not covered by the manual use case;

[0115] The instruction sending module 104 sends an instruction to execute the manual use case to the tester if the changed code is covered by the manual use case.

[0116] In one embodiment, the data acquisition module 101 is specifically used for:

[0117] Obtain pre-deployment status data of project files before the deployment of a preset software version;

[0118] Get the post-deployment status data of the project file after the preset software version is deployed;

[0119] By comparing the pre-deployment status data and the post-deployment status data, code change record data is obtained.

[0120] In one embodiment, the data acquisition module 101 is specifically used for:

[0121] Obtaining a binary object of each project file in the pre-deployment state data to obtain a pre-deployment binary object set;

[0122] Obtaining a binary object of each project file in the post-deployment state data to obtain a post-deployment binary object set;

[0123] Calculating hash values ​​of the pre-deployment binary object set to obtain a first hash value set;

[0124] Calculating hash values ​​of the post-deployment binary object set to obtain a second hash value set;

[0125] Comparing the hash values ​​at corresponding positions in the first hash value set and the second hash value set to see whether they are the same, to obtain a comparison result;

[0126] The change record of the project file after the preset software version is deployed is analyzed according to the comparison result to obtain the code change record.

[0127] In one embodiment, the data acquisition module 101 is specifically used for:

[0128] Obtain source code data after successful deployment of the preset software;

[0129] Acquire the code file that has been changed in the source code data according to the code change record to obtain a change file;

[0130] The changed code in the changed file is obtained according to the code change record.

[0131] In one embodiment, the automated use case determination module 102 is specifically configured to:

[0132] Use pre-set code coverage tools to obtain code coverage records;

[0133] Acquire covered code in the changed code according to the code coverage record;

[0134] If there is an automation use case execution mark in the covered code, it is determined that the changed code is covered by the automation use case;

[0135] If there is no automation use case execution mark in the covered code, it is determined that the changed code is not covered by the automation use case.

[0136] In one embodiment, the automated use case determination module 102 is specifically configured to:

[0137] Execute the automation use case on the changed code in the local operating environment to obtain an execution result;

[0138] Comparing the execution result with a preset expected result to obtain a comparison result;

[0139] Analyze the execution passing use cases and the execution failing use cases in the automation use cases according to the comparison results;

[0140] The test cases that passed the execution and the test cases that failed the execution are summarized to obtain the test results.

[0141] In one embodiment, the manual use case judgment module 103 is specifically used to:

[0142] Obtaining the test target function by analyzing the test target of the manual use case;

[0143] Analyze the implementation function of the changed code to obtain the code function;

[0144] If the test target function includes the code function, determining that the changed code is covered by the manual use case;

[0145] If the test target function does not include the code function, it is determined that the changed code is not covered by the manual use case.

[0146] In detail, each module described in the test system 100 after the code change in the software test in the embodiment of the present invention is used in the same manner as described above. Figures 1 to 3 The same technical means are used as the testing method after code changes in the software testing described in , and can produce the same technical effects, so I will not go into details here.

[0147] like Figure 6 , which is a schematic diagram of the structure of an electronic device of a testing method after code change in software testing provided by an embodiment of the present invention.

[0148] The electronic device 1 may include a processor 10, a memory 11, a communication bus 12 and a communication interface 13, and may also include a computer program stored in the memory 11 and executable on the processor 10, such as a test program after code changes in software testing.

[0149] In some embodiments, the processor 10 may be composed of an integrated circuit, for example, a single packaged integrated circuit, or a plurality of packaged integrated circuits with the same or different functions, including one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and combinations of various control chips. The processor 10 is the control core (ControlUnit) of the electronic device, and uses various interfaces and lines to connect various components of the entire electronic device, and executes or executes programs or modules stored in the memory 11 (such as test programs after code changes in software testing, etc.), and calls data stored in the memory 11 to execute various functions of the electronic device and process data.

[0150] The memory 11 includes at least one type of readable storage medium, and the readable storage medium includes a flash memory, a mobile hard disk, a multimedia card, a card-type memory (for example, an SD or DX memory, etc.), a magnetic memory, a disk, an optical disk, etc. In some embodiments, the memory 11 may be an internal storage unit of an electronic device, such as a mobile hard disk of the electronic device. In other embodiments, the memory 11 may also be an external storage device of an electronic device, such as a plug-in mobile hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device. Further, the memory 11 may also include both an internal storage unit of the electronic device and an external storage device. The memory 11 may not only be used to store application software and various types of data installed in the electronic device, such as the code of the test program after the code is changed in the software test, but also be used to temporarily store data that has been output or is to be output.

[0151] The communication bus 12 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. The bus is configured to realize connection and communication between the memory 11 and at least one processor 10, etc.

[0152] The communication interface 13 is used for communication between the above-mentioned electronic device and other devices, including a network interface and a user interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a WI-FI interface, a Bluetooth interface, etc.), which is generally used to establish a communication connection between the electronic device and other electronic devices. The user interface may be a display (Display), an input unit (such as a keyboard (Keyboard)), and optionally, the user interface may also be a standard wired interface, a wireless interface. Optionally, in this embodiment, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, and an OLED (Organic Light-Emitting Diode, organic light-emitting diode) touch device, etc. Among them, the display may also be appropriately referred to as a display screen or a display unit, which is used to display information processed in the electronic device and to display a visual user interface.

[0153] The figure only shows an electronic device with components. Those skilled in the art will understand that the structure shown in the figure does not constitute a limitation on the electronic device, and may include fewer or more components than shown in the figure, or combine certain components, or arrange the components differently.

[0154] For example, although not shown, the electronic device may also include a power source (such as a battery) for supplying power to each component. Preferably, the power source may be logically connected to the at least one processor 10 through a power management device, so that the power management device can realize functions such as charging management, discharging management, and power consumption management. The power source may also include one or more DC or AC power sources, recharging devices, power failure detection circuits, power converters or inverters, power status indicators, and other arbitrary components. The electronic device may also include a variety of sensors, Bluetooth modules, Wi-Fi modules, etc., which will not be repeated here.

[0155] It should be understood that the embodiment is for illustration only and the scope of the patent application is not limited to this structure.

[0156] The test program after the code change in the software test stored in the memory 11 of the electronic device 1 is a combination of multiple instructions. When running in the processor 10, it can achieve:

[0157] Obtain code change record data after the preset software version is successfully deployed;

[0158] Acquire the change code according to the code change record data;

[0159] Determine whether the changed code is covered by the automation use case;

[0160] If the changed code is covered by the automated test case, the automated test case is executed on the successfully deployed software to obtain the test result;

[0161] If the changed code is not covered by the automated use case, determining whether the changed code is covered by the manual use case;

[0162] If the changed code is not covered by the manual use case, an identification error message is sent to the tester;

[0163] If the changed code is covered by the manual use case, an instruction to execute the manual use case is sent to the tester.

[0164] Specifically, the specific implementation method of the processor 10 for the above instructions can refer to the description of the relevant steps in the corresponding embodiment of the accompanying drawings, which will not be repeated here.

[0165] Furthermore, if the module / unit integrated in the electronic device 1 is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. The computer-readable storage medium can be volatile or non-volatile. For example, the computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, and a read-only memory (ROM).

[0166] The present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor of an electronic device, the computer program can implement:

[0167] Obtain code change record data after the preset software version is successfully deployed;

[0168] Acquire the change code according to the code change record data;

[0169] Determine whether the changed code is covered by the automation use case;

[0170] If the changed code is covered by the automated test case, the automated test case is executed on the successfully deployed software to obtain the test result;

[0171] If the changed code is not covered by the automated use case, determining whether the changed code is covered by the manual use case;

[0172] If the changed code is not covered by the manual use case, an identification error message is sent to the tester;

[0173] If the changed code is covered by the manual use case, an instruction to execute the manual use case is sent to the tester.

[0174] In the embodiments provided by the present invention, it should be understood that the disclosed devices, systems and methods can be implemented in other ways. For example, the system embodiments described above are only schematic, for example, the division of the modules is only a logical function division, and there may be other division methods in actual implementation.

[0175] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0176] In addition, each functional module in each embodiment of the present invention may be integrated into one processing unit, each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional modules.

[0177] It is obvious to those skilled in the art that the present invention is not limited to the details of the above exemplary embodiments, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0178] Therefore, no matter from which point of view, the embodiments should be regarded as illustrative and non-restrictive, and the scope of the present invention is limited by the appended claims rather than the above description, so it is intended that all changes falling within the meaning and scope of the equivalent elements of the claims are included in the present invention. Any attached figure mark in the claims should not be regarded as limiting the claims involved.

[0179] The embodiments of the present application can acquire and process relevant data based on artificial intelligence technology. Among them, artificial intelligence (AI) is the theory, method, technology and application system that uses digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain the best results.

[0180] In addition, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in the system claim can also be implemented by one unit or device through software or hardware. The words first, second, etc. are used to indicate names, and do not indicate any particular order.

[0181] Finally, it should be noted that if software tools or components other than those of the Company appear in the application embodiments, they are only used for illustration and do not represent actual use. The above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention is described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A testing method after code change in software testing, characterized in that: The method comprises: Obtain code change record data after the preset software version is successfully deployed; Acquire the change code according to the code change record data; Determine whether the changed code is covered by the automation use case; If the changed code is covered by the automated test case, the automated test case is executed on the successfully deployed software to obtain the test result; If the changed code is not covered by the automated use case, determining whether the changed code is covered by the manual use case; If the changed code is not covered by the manual use case, an identification error message is sent to the tester; If the changed code is covered by the manual use case, an instruction to execute the manual use case is sent to the tester.

2. The method for testing software after code change in claim 1, characterized in that: The step of obtaining the code change record data after the preset software version is successfully deployed includes: Obtain pre-deployment status data of project files before the deployment of a preset software version; Get the post-deployment status data of the project file after the preset software version is deployed; By comparing the pre-deployment status data and the post-deployment status data, code change record data is obtained.

3. The method for testing software after code change in claim 2, characterized in that: The obtaining of code change record data by comparing the pre-deployment state data and the post-deployment state data includes: Obtaining a binary object of each project file in the pre-deployment state data to obtain a pre-deployment binary object set; Obtaining a binary object of each project file in the post-deployment state data to obtain a post-deployment binary object set; Calculating hash values ​​of the pre-deployment binary object set to obtain a first hash value set; Calculating hash values ​​of the post-deployment binary object set to obtain a second hash value set; Comparing the hash values ​​at corresponding positions in the first hash value set and the second hash value set to see whether they are the same, to obtain a comparison result; The change record of the project file after the preset software version is deployed is analyzed according to the comparison result to obtain the code change record.

4. The method for testing software after code change in claim 1, characterized in that: The acquiring the change code according to the code change record data includes: Obtain source code data after successful deployment of the preset software; Acquire the code file that has been changed in the source code data according to the code change record to obtain a change file; The changed code in the changed file is obtained according to the code change record.

5. The method for testing software after code change in claim 1, characterized in that: The determining whether the changed code is covered by the automated use case includes: Use pre-set code coverage tools to obtain code coverage records; Acquire covered code in the changed code according to the code coverage record; If there is an automation use case execution mark in the covered code, it is determined that the changed code is covered by the automation use case; If there is no automation use case execution mark in the covered code, it is determined that the changed code is not covered by the automation use case.

6. The method for testing software after code changes in claim 1, characterized in that: The automated test cases are executed on the successfully deployed software to obtain the test results, including: Execute the automation use case on the changed code in the local operating environment to obtain an execution result; Comparing the execution result with a preset expected result to obtain a comparison result; Analyze the execution passing use cases and the execution failing use cases in the automation use cases according to the comparison results; The test cases that passed the execution and the test cases that failed the execution are summarized to obtain the test results.

7. The method for testing software after code change in claim 1, characterized in that: The determining whether the changed code is covered by the manual use case includes: Obtaining the test target function by analyzing the test target of the manual use case; Analyze the implementation function of the changed code to obtain the code function; If the test target function includes the code function, determining that the changed code is covered by the manual use case; If the test target function does not include the code function, it is determined that the changed code is not covered by the manual use case.

8. A testing system after code changes in software testing, characterized in that: The system comprises: A data acquisition module is used to acquire code change record data after a preset software version is successfully deployed, and acquire the changed code according to the code change record data; The automated use case judgment module is used to judge whether the changed code is covered by the automated use case. If the changed code is covered by the automated use case, the automated use case is executed on the successfully deployed software to obtain the test result; A manual use case judgment module is used to judge whether the changed code is covered by the manual use case if the changed code is not covered by the automated use case, and to send an identification error message to the tester if the changed code is not covered by the manual use case; The instruction sending module sends an instruction to execute the manual use case to the tester if the changed code is covered by the manual use case.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the testing method after code change in software testing as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for testing software after code change in any one of claims 1 to 7 is implemented.

Images