Database maintenance method and apparatus, storage medium, and electronic device

Abstract

This application provides a database maintenance method, apparatus, storage medium, and electronic device. The database maintenance method includes obtaining the latest submitted version file from the project's public database; testing the latest submitted version file based on preset acceptance test items, and obtaining test results. The acceptance test items include basic instance simulation tests. The database maintenance method, apparatus, storage medium, and electronic device provided in this application can maintain the health of the project's public database.

Description

Technical Field

[0001] This application relates to the fields of integrated circuit design and verification technology, specifically to a database maintenance method, apparatus, storage medium, and electronic device. Background Technology

[0002] In integrated circuit design and verification projects, there is usually a public database. Developers download the latest submitted version files from the public database to their local databases, add or modify relevant files locally to create new submitted version files, and submit them to the public database after passing acceptance testing, thereby updating the public database.

[0003] However, because multiple developers modify and submit their own work within the project, errors can easily occur during modification or submission. This can lead to corruption of the project's public database after submission, causing issues such as environment process failures, compilation failures, and simulation initialization failures. Consequently, on the one hand, complete regression tests on the latest submission file become invalid, wasting data server resources. On the other hand, it can also cause developers to download erroneous, uncompileable, or unrunnable latest submission files. Modified submission files based on these erroneous latest submission files also cannot be compiled or simulated, wasting the manpower and time spent on modifications.

[0004] Therefore, maintaining the health of the project's public database has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of this, embodiments of this application provide a database maintenance method, apparatus, storage medium, and electronic device to maintain the health of a project's public database in a timely manner.

[0006] To achieve the above objectives, the embodiments of this application provide the following technical solutions:

[0007] In a first aspect, embodiments of this application provide a database maintenance method, including:

[0008] Retrieve the latest commit version file from the project's public database;

[0009] Based on the preset acceptance test items, the latest submitted version file is tested and the test results are obtained. The acceptance test items include basic instance simulation tests.

[0010] Secondly, embodiments of this application provide a database maintenance apparatus, comprising:

[0011] The module for retrieving the latest commit version file is suitable for retrieving the latest commit version file from the project's public database.

[0012] The acceptance testing module is suitable for testing the latest submitted version file based on preset acceptance testing items and obtaining test results. The acceptance testing items include basic instance simulation tests.

[0013] Thirdly, embodiments of this application provide a storage medium having a program suitable for database maintenance to implement the database maintenance method as described in any embodiment of the first aspect.

[0014] Fourthly, embodiments of this application provide an electronic device including at least one memory and at least one processor; the memory stores a program, and the processor invokes the program to perform the database maintenance method as described in any of the first aspects.

[0015] The database maintenance method provided in this application monitors files submitted to the project's public database. By accepting and testing the latest submitted versions of files in the public database and using basic example simulation tests, it quickly and promptly identifies submission errors, thus initially maintaining the health of the project's public database. Therefore, the database maintenance method provided in this application, by accepting and testing the latest submitted versions of files in the project's public database, initially maintains the health of the project's public database. On the one hand, it can improve the effectiveness of full regression testing, reduce the probability of performing full regression testing on erroneous submitted versions, and save server resources. On the other hand, it can reduce the possibility of developers downloading and updating erroneous submitted versions or making modifications based on erroneous submitted versions, saving manpower and time and reducing the impact on project progress. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1a This is a schematic diagram of a system for an integrated circuit project.

[0018] Figure 1b Another schematic diagram of the integrated circuit project system;

[0019] Figure 2a This is a flowchart of a database maintenance method provided in an embodiment of this application;

[0020] Figure 2b A schematic diagram illustrating the version number of the version file submitted to the project public database for the database maintenance method provided in this application embodiment;

[0021] Figure 3 This is another flowchart of the database maintenance method provided in the embodiments of this application;

[0022] Figure 4 This is another flowchart of the database maintenance method provided in the embodiments of this application;

[0023] Figure 5 This is another flowchart of the database maintenance method provided in the embodiments of this application;

[0024] Figure 6 This is another flowchart of the database maintenance method provided in the embodiments of this application;

[0025] Figure 7 This is a block diagram of a database maintenance apparatus provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] The following section introduces a database maintenance method.

[0028] It's easy to understand that the database described in this article can be a project-wide public database used for designing and verifying integrated circuits, while each participating developer has their own local database. The integrated circuits are represented as files in both the project-wide database and the local databases. By downloading the latest commit file from the project-wide database to their local database, developers can complete their development work there. New commit files created by adding or modifying related files can then be uploaded to the project-wide database to update the latest commit files for other developers to download and use. For details, please refer to [link / reference needed]. Figure 1a , Figure 1a This is a schematic diagram of a system for an integrated circuit project.

[0029] like Figure 1a As shown, the integrated circuit project system includes a project public database 110, a local database 0 belonging to user 0, a local database 1 belonging to developer user 1, ..., and a local database n belonging to developer user n. To illustrate the specific operations of the developer users, specific examples are given below:

[0030] Suppose that developer user 1 and developer user 2 download commit file A containing module A from the project's public database 110. This commit file A is the latest commit file in the project's public database 110. Developer user 1 uploads commit file B containing module A and the added module B before developer user 2. Developer user 3 downloads the file from the project's public database after developer user 1 uploads the file and before developer user 2 uploads the file.

[0031] Developer User 3 downloads commit file B from the database because Developer User 1 uploaded commit file B to the project's public database 110, updating the latest commit file in the project database to commit file B. Developer User 2 encounters an upload failure when trying to upload commit file C (containing module A and the newly added module C) from the project's public database 110. They are informed that the project's public database 110 has been updated and they need to modify it based on the latest commit file in the project database—commit file B. This ensures that the final commit file uploaded to the public project database contains modules A, B, and C. Similarly, Developer User 3 will also consider modules A, B, and C when uploading to the project's public database 110.

[0032] However, commit files may contain errors. Errors in commit files can mean that some instances expected to succeed in simulation are failing. These errors typically fall into three categories: The first category is errors that prevent the commit file from compiling. This is easy to understand; any instance is compiled before simulation. Therefore, when an error in a commit file prevents it from compiling, all instance simulations will fail due to compilation errors. New commit files created by adding or modifying related files based on this commit file will also fail to compile, resulting in errors for all instances. The second category is basic instance errors, which occur in the project's public database. The file is the representation of the integrated circuit designed in this project. Therefore, each module of the integrated circuit can correspond to each submitted version file. The basic instance is usually an instance that reflects the most basic characteristics of each functional module of the integrated circuit, and the simulation time is usually short. An error in the basic instance will cause all instances of the functional module to which the basic instance belongs to to report errors. Therefore, it is difficult to determine the cause of errors in the simulation results for both uncompile instance errors and basic instance errors. The last category is other errors besides the two types mentioned above. Other errors usually only cause themselves and a few related instances to report errors, and will not cause a large number of instances to report errors. Therefore, errors in the submitted version file can be determined and fixed based on the instances that report errors in the simulation.

[0033] It's easy to understand that uncompileable errors and basic instance errors in a commit file will cause errors in related files added or modified in a new commit file based on that commit file. Other instance errors, however, only cause errors in themselves and a few related instances. Therefore, even if other errors occur in a commit file, as long as the developer correctly adds or modifies the related files, those files themselves do not need to be modified. The developer of the new commit file only needs to wait for the fixed commit file to be uploaded and then modify the erroneous parts to completely fix the new commit file. Therefore, when the commit files in the project database do not contain uncompileable errors and basic instance errors, the project database can be considered healthy.

[0034] To maintain the health of the project's public database, developers are required to conduct acceptance tests on the submitted version files before committing them to the public database. Please refer to [link / reference needed] for details. Figure 1b , Figure 1b This is another schematic diagram of the integrated circuit project system.

[0035] like Figure 1b As shown, each developer needs to first conduct acceptance testing on the submitted version file. Only after the acceptance test is passed can the submitted version file that has passed the acceptance test be submitted to the project's public database 120. If it fails, it needs to be modified again until it passes the acceptance test.

[0036] The instances tested in the acceptance test are usually basic instances of various functional modules of an integrated circuit. Therefore, through acceptance testing, errors that cannot be compiled and errors in basic instances can be found.

[0037] However, the above methods require developers to strictly and correctly execute the submission process to achieve acceptance testing. In practice, as integrated circuit designs become increasingly complex and projects expand in scale, it is not uncommon for developers to submit erroneous commit files due to improper operation. This damages the health of the project's public database, causing other developers to download incorrect, uncompileable, or unrunnable latest commit files, wasting manpower and time spent on repairs, and seriously affecting project progress. Therefore, the technical challenge of maintaining the health of the project's public database remains.

[0038] To address the aforementioned problems, this application provides a database maintenance method, please refer to... Figure 2a , Figure 2a This is a flowchart of a database maintenance method provided in an embodiment of this application.

[0039] In step S11, the latest commit version file is obtained from the project's public database.

[0040] First, retrieve the latest committed file from the project's public database, i.e., the latest commit version file.

[0041] Specifically, to easily determine the latest commit, a version number can be added to each commit file in the project database. This allows you to identify the latest commit file by checking the version number of the commit file in the project database. Please refer to [link / reference]. Figure 2b , Figure 2b This is a schematic diagram illustrating the version number of the version file submitted to the public database of the database maintenance method provided in this application embodiment.

[0042] like Figure 2b As shown, each commit version file in the project's public database has a corresponding version number. The version numbers are usually sorted from smallest to largest according to the order in which they were committed to the project's public database. Therefore, the latest commit version file can be determined based on the size of the version number.

[0043] It is worth noting that the latest commit files can be obtained from a developer's local database or from a separate local database that does not belong to any developer. The user of this local database can be called a machine user, that is, a machine user downloads the latest commit files from the project's public database.

[0044] Of course, you can also obtain the latest commit files through other means, such as the commit date of each commit file.

[0045] In step S12, the latest submitted version file is tested based on preset acceptance test items to obtain test results. The acceptance test items include basic instance simulation tests.

[0046] After obtaining the latest submitted version file, acceptance testing is performed on it. It should be noted that the specific acceptance testing only includes basic instance simulation testing. The basic instance simulation testing mentioned in the text refers to the simulation testing of the most basic characteristics of each functional module of the integrated circuit after compiling the latest submitted version file of the integrated circuit. Therefore, the simulation testing of basic instances usually takes less time. Furthermore, the basic instances will vary depending on the integrated circuit.

[0047] In some embodiments, preset acceptance test items can be written into a script, and the latest submitted version file can be tested through the script to obtain test results.

[0048] As can be seen, acceptance testing can determine whether the latest submitted version of the file can be compiled and whether it can pass the preset basic instance simulation test.

[0049] It's easy to understand that the latest commit file is compiled before simulation. Therefore, if an error in the latest commit file prevents compilation, a new commit file created by adding or modifying related files based on the latest commit file will also fail to compile. All instances will fail to compile and report errors. In other words, the errors of instances that cannot be compiled will have the greatest impact on the simulation of other instances. The impact of basic instance errors on other instances is second only to those that cannot be compiled. They will cause all instances of the functional module to which the basic instance belongs to to report errors. Therefore, it is difficult to determine the cause of errors in both instances that cannot be compiled and basic instance errors based on the instances that fail to be simulated.

[0050] Therefore, error commits containing instances that cannot be compiled and basic instance errors will cause new commits created by adding or modifying related files based on those error commits to report instance errors. Thus, timely detection of the latest commits that fail acceptance testing is beneficial for ensuring the health of the project's public database.

[0051] As can be seen, the database maintenance method provided in this application maintains the health of the project's public database by conducting acceptance tests on the latest submitted version files. On the one hand, this improves the effectiveness of full regression testing, reduces the probability of performing full regression testing on erroneous version files, and saves server resources. On the other hand, it reduces the likelihood of developers downloading and updating erroneous version files or making modifications based on erroneous version files, saving manpower and time and reducing the impact on project progress.

[0052] In another specific implementation, to facilitate subsequent acquisition of the health status of the corresponding submitted version file, the database maintenance method provided in this application embodiment may further include:

[0053] In step S13, the test result is identified in the latest submission version file in the project's public database.

[0054] After obtaining the test results, to facilitate subsequent processing, the test results can be further identified in the latest submitted version file in the project's public database.

[0055] The test result is either pass or fail, and can be described in different ways, such as "healthy" for pass and "not healthy" for fail.

[0056] Please continue to refer to Figure 2b ,like Figure 2bAs shown, commit files 129528 and 129525 correspond to the tags not_healthy and healthy_379, respectively. not_healthy indicates a failed test, and healthy_379 indicates a passed test, where 379 indicates that commit file 129525 was the 379th commit to pass the test. The tags for commit files 129527 and 129526 are empty, meaning they did not undergo acceptance testing, and their test results are unknown.

[0057] By marking the test results in the latest submitted version file in the project's public database, acceptance test information can be saved in the project's public database, which is beneficial for the subsequent use of the test results.

[0058] In another specific implementation, in order to promptly repair the latest submitted version of the file that failed the acceptance test, this application embodiment also provides a database maintenance method, please refer to... Figure 3 , Figure 3 Another flowchart of the database maintenance method provided in the embodiments of this application.

[0059] like Figure 3 As shown, the database maintenance method provided in this application includes:

[0060] In step S21, the latest commit version file is obtained from the project's public database.

[0061] In step S22, the latest submitted version file is tested based on preset acceptance test items to obtain test results. The acceptance test items include basic instance simulation tests.

[0062] Please refer to the details of steps S21-S22. Figure 2a Steps S11-S12 shown will not be repeated here.

[0063] In step S23, it is determined whether the test result is an acceptance failure. If so, step S24 is executed; otherwise, step S25 is executed.

[0064] If the test result is "failed", it means that the latest submitted version file is a submission version file that damages the health of the project's public database. In order to maintain the health of the project's public database, it is necessary to repair the latest submitted version file in a timely manner. The most suitable person to repair the latest submitted version file is the developer user who submitted it. Therefore, step S24 can be executed to send the test result to the developer user of the latest submitted version file. Otherwise, step S25 is executed.

[0065] In step S24, the test results are sent to the developer user of the latest submitted version file.

[0066] Specifically, the developer who submitted the latest version of the file can be notified via email.

[0067] Of course, in some embodiments, test results may not be sent, but only the developer user may be notified that the acceptance test failed. The developer user can then conduct the acceptance test themselves and make repairs based on the test results.

[0068] In step S25, the process ends.

[0069] When the acceptance test passes, it means that the latest commit file does not contain any uncompileable errors or basic instance errors that would cause other developers to add or modify parts of the new commit file based on this commit file. Therefore, the project's public database has not been corrupted and no further operations are required.

[0070] In this way, when the test result is that the acceptance fails, the test result is sent to the developer of the latest submission file that was tested. This helps the developer to modify the latest submission file into a correct submission file in a timely manner, thereby ensuring the health of the project's public database and reducing the impact of damage to the project's public database on the project schedule.

[0071] In another specific implementation, to more quickly repair all the latest submissions in the project's public database that have failed acceptance tests, this application also provides a database maintenance method, please refer to... Figure 4 , Figure 4 Another flowchart of the database maintenance method provided in the embodiments of this application.

[0072] like Figure 4 As shown, the database maintenance method provided in this application embodiment may include:

[0073] In step S31, the latest commit version file is obtained from the project's public database.

[0074] In step S32, the latest submitted version file is tested based on preset acceptance test items to obtain test results. The acceptance test items include basic instance simulation tests.

[0075] Please refer to the details of steps S31-S32. Figure 2a The descriptions of steps S11-S12 shown will not be repeated here.

[0076] In step S33, it is determined whether the test result is an acceptance failure. If so, steps S34 and S38 are executed; otherwise, step S37 is executed.

[0077] Please refer to the details of step S33. Figure 3 The description of step S23 is only applicable if the test result is that the acceptance test fails, in which case step S34 must also be performed. Other details will not be repeated here.

[0078] In step S38, the test results are sent to the developer user of the latest submitted version file.

[0079] Please refer to the details of step S38. Figure 3 The description of step S24 shown will not be repeated here.

[0080] In step S34, the latest accepted version file is determined.

[0081] When the test result of the latest submitted version file is not passed, the latest accepted version file is found among the submitted version files that have passed the acceptance test. That is, the latest accepted version file.

[0082] In some embodiments, when the latest submission version file in the project's common database is subjected to acceptance testing and the test result is identified in the latest submission version file, the latest acceptance-passed submission version file can be determined by the identifier of the test result; in other embodiments, the version number of the acceptance-passed submission version file can be updated after each acceptance test, and the latest acceptance-passed submission version file can be determined by the version number of the record; of course, it can also be implemented in other ways, which will not be elaborated here.

[0083] In step S35, the development user information of each unaccepted test submission version file submitted after the latest accepted submission version file is obtained.

[0084] After confirming the latest accepted version file, further obtain the development user information of the unaccepted test version files submitted after it but which have not undergone acceptance testing.

[0085] Please continue to refer to this. Figure 2b When the latest submitted version file 129528 fails the test, submitted version file 129525 is the latest accepted submitted version file. Submitted version files 129526 and 129527 are unaccepted test submitted version files after the latest accepted submitted version file 129525.

[0086] It's easy to understand that after confirming the latest accepted version file has been submitted, the version number can be used to quickly identify the version files to be submitted for each subsequent unaccepted test.

[0087] In step S36, the test results are sent to each of the untested submitted version files according to the developer user information.

[0088] The reason why the latest submission failed the acceptance test may be that only the latest submission failed the acceptance test, or it may be that the submissions before it failed the acceptance test. Therefore, all potential submissions that may fail the acceptance test, that is, untested submissions submitted after the latest accepted submissions, should be notified to prevent developers from fixing files that were not added or modified by them.

[0089] In step S37, the process ends.

[0090] Please refer to the details of step S37. Figure 2a The description of step S25 shown will not be repeated here.

[0091] In this way, when the acceptance test fails, all developers who submitted version files that were not accepted before the latest accepted version file are notified. This allows for comprehensive notification to all developers whose version files may fail the acceptance test. As a result, if the error in the latest version file is due to an incorrect version file based on an improved version file, the version file can be modified more quickly, further avoiding any impact on the project schedule.

[0092] In another specific implementation, in order to reduce the burden on development users while repairing the latest submission file that failed the acceptance test, this application embodiment also provides a database maintenance method, please refer to... Figure 5 , Figure 5 Another flowchart of the database maintenance method provided in the embodiments of this application.

[0093] like Figure 5 As shown, the database maintenance method provided in this application embodiment may include:

[0094] In step S41, the latest commit version file is obtained from the project's common database.

[0095] In step S42, the latest submitted version file is tested based on preset acceptance test items to obtain test results. The acceptance test items include basic instance simulation tests.

[0096] Please refer to the content of steps S41-S42. Figure 2aSteps S11-S12 shown will not be repeated here.

[0097] In step S43, it is determined whether the test result is an acceptance failure. If so, step S44 is executed; otherwise, step S410 is executed.

[0098] In step S44, it is determined whether there is an intermediate submission version file that has not undergone acceptance testing between the latest submission version file and the latest acceptance-passed submission version file that has passed the acceptance test. If so, step S45 is executed; otherwise, step S472 is executed.

[0099] In step S45, the acceptance test is performed on the intermediate commit version file to obtain the intermediate test results.

[0100] In step S46, it is determined whether the intermediate test results before all acceptance tests are completed are acceptable. If yes, step S471 is executed; otherwise, step S472 is executed.

[0101] In step S471, the intermediate submission version file that has passed acceptance is determined to be the current submission version file that has passed acceptance.

[0102] It's easy to understand that when a commit fails acceptance testing, any commit based on that commit will also fail. Since the version numbers of failed commits are closely adjacent, acceptance testing can begin with the intermediate commit whose version number is closest to the latest commit, proceeding sequentially from closest to closest. When the first intermediate commit passes acceptance testing, it means that the commit following it was not the source of the error that caused the acceptance test failure. Therefore, this passed intermediate commit is the currently accepted commit.

[0103] In one specific implementation, to more quickly obtain the intermediate commit files arranged by commit time, a binary search method can be used to perform acceptance tests on each intermediate commit file and obtain the intermediate test results. However, since the acceptance tests are not performed sequentially from the intermediate commit file with the closest version number to the latest commit file, in descending order of similarity, the appearance of the first intermediate commit file that passes the acceptance test does not necessarily indicate that the subsequent commit file is the source of the error causing the acceptance test to fail. Therefore, it is necessary to perform acceptance tests on all intermediate commit files to determine the latest commit file among those that pass the acceptance test as the currently accepted commit file.

[0104] In step S472, the latest accepted submission version file is determined to be the current accepted submission version file.

[0105] Of course, if no submission file passes the acceptance tests by the time all acceptance tests are completed, then the latest submission file that passes the acceptance tests is the current submission file that passes the acceptance tests.

[0106] In step S48, the development user information of each unaccepted test submission version file submitted after the latest accepted version file is obtained.

[0107] In step S49, the test results are sent to each of the development users who submitted the unaccepted test version files, based on the development user information.

[0108] It is easy to understand that, given that acceptance testing generally takes a short time, in order to reduce the burden on development users, acceptance testing can be performed on intermediate commit files, intermediate test results can be obtained, and only development users of intermediate commit files whose intermediate test results are notified.

[0109] In step S410, the process ends.

[0110] In this way, when the acceptance test result of the latest submission file is unsuccessful, instead of directly notifying all developers of all intermediate submission files that have not undergone acceptance testing between the latest submission file and the latest acceptance-passing submission file that has already passed acceptance testing, the short acceptance testing time of the intermediate submission files is fully utilized to conduct acceptance testing on the untested intermediate submission files, resulting in the latest acceptance-passing submission file. This further distinguishes developers who do not need to be notified, achieving precise notification.

[0111] In one specific embodiment, the latest submitted version file within the acceptance testing period can be periodically retrieved from the project's public database according to a preset acceptance testing period.

[0112] It's easy to understand that because acceptance testing is usually short and developers submit relatively frequently, the acceptance testing cycle should not be set too long in order to promptly identify errors in submitted files and maintain the health of the project's public database.

[0113] In some embodiments, existing acceptance testing tools can be invoked via scripts to periodically retrieve the latest submitted version files within the acceptance testing period from the project database. This simplifies the implementation complexity of this solution by leveraging existing tools.

[0114] In other embodiments, when the entire acceptance testing method is implemented through a script, a script command to periodically retrieve the latest submitted version can be directly written into the script.

[0115] In this way, by setting a pre-defined acceptance testing cycle, the latest submitted version files in the project database can be periodically tested, ensuring the health of the project's public database throughout the project development process.

[0116] In one specific embodiment, before obtaining the latest commit version file from the project's public database, it can also be determined that the latest commit version file has not received test results.

[0117] It is easy to understand that because the acceptance testing cycle is short, it is entirely possible that there will be no new commit files in a cycle. In this case, at the beginning of the next cycle, it can be detected that the latest commit file has already undergone acceptance testing and does not need to be tested again. Therefore, the acceptance testing for this cycle can be ended.

[0118] In some implementations, a script can be used to automatically determine whether the latest submitted version of the file has received test results.

[0119] In some embodiments, when the latest commit version file in the project's public database is accepted and the test result is obtained, the test result is marked on the latest commit version file. The test result can be used to confirm whether the commit version file has undergone acceptance testing. In other embodiments, the version number of the accepted version is recorded after each acceptance test. When a new acceptance test begins, the version number of the latest commit version file in the project's public database is compared with the stored version number to determine whether the latest commit version has been accepted.

[0120] In this way, acceptance testing is only performed on the latest submission version that has not been tested before, which avoids duplicate acceptance testing and allows for more flexible maintenance of the project database health.

[0121] In one specific embodiment, a script can be used to determine that the latest submitted version of the file has not received test results.

[0122] In this way, using a script to determine whether the latest submitted version of the file has not obtained test results can ensure the automated implementation of the determination that no test results have been obtained.

[0123] Assuming the public project database remains initially healthy, the database maintenance method provided in this embodiment of the invention can further ensure complete regression testing. Please refer to [link / reference needed] for details. Figure 6 , Figure 6 Another flowchart of the database maintenance method provided in the embodiments of this application.

[0124] like Figure 6 As shown, another flowchart of the database maintenance method provided in this application embodiment includes:

[0125] In step S51, the latest accepted submission version file is obtained from the project's public database.

[0126] It's worth noting that the latest accepted submission file can be obtained from either the developer's local database or a separate local database not belonging to any developer. This user of the separate local database can be referred to as the "machine user." The machine user's local database can be connected to... Figure 2a The local database shown is the same local database used to retrieve the latest commit version file.

[0127] In step S52, a full regression test is performed on the latest accepted version file to obtain the full regression test results.

[0128] Full regression testing involves performing the most complete instance simulation test on the integrated circuit. This most complete instance includes all instances that could be run in the previous commit version of the commit file being fully regressed, as well as the additional instances that the commit file being fully regressed is expected to be able to implement compared to the previous commit version. Therefore, the simulation test time for full regression testing is usually long.

[0129] If the commit file undergoing a full regression test contains uncompileable instance errors or basic instance errors, it will cause a large number of instances to fail in the full regression test, rendering the full regression test invalid. Therefore, to prevent wasting time on full regression tests, the commit file undergoing full regression testing should ideally have passed acceptance testing.

[0130] In this way, by performing full regression testing only on the latest accepted version file submitted in the project's public database, the effectiveness of the full regression testing is ensured, and the waste of data server resources is avoided.

[0131] In one specific implementation, the latest accepted submission version file within the full regression test cycle can be periodically retrieved from the project's public database according to a preset full regression test cycle.

[0132] Of course, because full regression testing takes a long time and consumes a lot of server resources, the preset full regression testing period should not be too short.

[0133] Specifically, scripts can be used to periodically perform full regression tests on the project's public database.

[0134] In this way, by pre-setting a complete regression test cycle and periodically obtaining the latest acceptance submission version file within that regression test cycle from the project's public database, it is possible to continuously maintain the health of the database during the project development process.

[0135] In step S53, it is determined whether the complete regression test result is unsuccessful. If so, step S54 is executed; otherwise, step S57 is executed.

[0136] In some embodiments, when the full regression test result is a failure, the full regression test result is sent to the developer user of the latest acceptance submission version file.

[0137] In this way, when the full regression test result is unsuccessful, the test result is sent to the developer who submitted the latest version of the file that was fully regressed. This helps the developer to promptly modify the latest accepted version of the file into the correct version, thereby ensuring the health of the project's public database and reducing the impact of damage to the project's public database on the project schedule.

[0138] In step S54, the latest regression is determined by submitting the version file.

[0139] In some embodiments, the results of the most complete regression test can be identified in the submitted version file, such as... Figure 2b As shown.

[0140] In step S55, the developer user information of each submitted version file that has not undergone complete regression testing is obtained after the latest regression submission version file.

[0141] In step S56, each developer who submitted a version file that has not undergone complete regression testing is notified according to the developer user information.

[0142] In step S57, the process ends.

[0143] It is easy to understand that full regression testing takes a long time. Therefore, in order to reduce the burden on development users, it would be too time-consuming to perform full regression testing on all submissions of the latest regression file that have not been fully tested, and on all submissions of the latest regression file that have been fully tested. Therefore, we only notify the development users of the submissions of the files that have not been fully tested.

[0144] In this way, when a complete regression test fails, all developers who submitted versions of files that did not pass the complete regression test after the latest successful regression test submission are notified. This allows for comprehensive notification to all developers whose versions of files may fail the complete regression test. As a result, if the error in the latest version of a file is due to an incorrect version of a file based on an improved version, the submission can be modified more quickly, further avoiding any impact on the project schedule.

[0145] To address the aforementioned problems, this application also provides a database maintenance apparatus, which can be considered as a functional module required to implement the database maintenance method provided in this application. The apparatus described herein corresponds to the method described above.

[0146] Please refer to Figure 7 , Figure 7 This is a block diagram of a database maintenance apparatus provided in an embodiment of this application, as shown below. Figure 7 As shown, the database maintenance device includes:

[0147] The latest commit version file retrieval module 710 is suitable for retrieving the latest commit version file from the project's public database.

[0148] The acceptance test module 720 is adapted to test the latest submitted version file based on preset acceptance test items and obtain test results. The acceptance test items include basic instance simulation tests.

[0149] As can be seen, the database maintenance device provided in this application embodiment maintains the health of the project's public database by conducting acceptance tests on the latest submitted version files of the project's public database. On the one hand, it can improve the effectiveness of full regression testing, reduce the probability of conducting full regression testing on submitted erroneous version files, and save server resources. On the other hand, it can reduce the possibility of developers downloading and updating erroneous submitted version files or making modifications based on erroneous submitted version files, thereby saving manpower and time and reducing the impact on project progress.

[0150] In one specific embodiment, the database maintenance device further includes:

[0151] The identification module 730 is adapted to identify the test results in the latest submitted version file in the project's public database.

[0152] In one specific embodiment, the integrated circuit verification apparatus further includes:

[0153] The first sending module 750 is adapted to send the test result to the developer user of the latest submitted version file when the test result is that the acceptance fails.

[0154] In one specific embodiment, the database maintenance device further includes a second sending module 750, which is also adapted to:

[0155] When the test result is that the acceptance test fails, the latest accepted version file is determined. The latest accepted version file includes the latest submitted version file that has passed the acceptance test in the project's public database.

[0156] Obtain the development user information for each unaccepted test submission version file after the latest accepted version file is submitted.

[0157] Based on the developer user information, the test results are sent to each of the developer users who submitted the unaccepted test version files.

[0158] In one specific embodiment, the second sending module 750 is further adapted to determine the latest accepted submission version file, including:

[0159] When there is an intermediate submission file that has not undergone acceptance testing between the latest submission file and the latest acceptance-passed submission file, acceptance testing is performed on the intermediate submission file to obtain the intermediate test results. This process continues until the intermediate test results are accepted or all acceptance tests are completed. Then, the intermediate submission file that has passed acceptance or the latest acceptance-passed submission file is determined to be the current latest acceptance-passed submission file.

[0160] In one specific embodiment, the second sending module 750 is further adapted to perform acceptance testing on the intermediate commit version file and obtain intermediate test results, including:

[0161] The acceptance test is performed on each intermediate commit version file arranged by commit time using a binary search method to obtain the intermediate test results.

[0162] In one specific implementation, the latest commit version file acquisition module 710 is adapted to acquire the latest commit version file in the project's public database, including:

[0163] According to the preset acceptance testing cycle, the latest submitted version file within the acceptance testing cycle is periodically retrieved from the project's public database.

[0164] In one specific implementation, the latest commit version file acquisition module 710 is further adapted to:

[0165] Before retrieving the latest commit version file from the project's public database, ensure that the latest commit version file has not been tested.

[0166] In one specific embodiment, the latest commit version file acquisition module 710 is further adapted to determine that the latest commit version file has not obtained test results, including:

[0167] The script determined that the latest submitted version of the file had not received any test results.

[0168] In one specific embodiment, the database maintenance device further includes:

[0169] The complete regression test module 740 is adapted to obtain the latest accepted submission version file in the project's public database, wherein the latest accepted submission version file is the latest accepted test submission version file in the project's public database.

[0170] Perform a full regression test on the latest accepted version file and obtain the full regression test results.

[0171] In one specific implementation, the full regression testing module 740 is adapted to obtain the latest accepted submission version file from the project's public database, including:

[0172] According to the preset full regression test cycle, the latest acceptance-passed submission version file within the full regression test cycle is periodically retrieved from the project's public database.

[0173] In one specific embodiment, the transmitting module 750 is further adapted to:

[0174] When the full regression test result is that the regression fails, the full regression test result will be sent to the development user who submitted the latest accepted version file.

[0175] In one specific embodiment, the complete regression test module 740 is further adapted to:

[0176] When the full regression test result is that the regression fails, the latest regression version file is determined to have passed and submitted.

[0177] Obtain the development user information for each submitted version file that has not undergone complete regression testing after the latest regression submission version file;

[0178] The developer users who submitted version files that have not undergone complete regression testing will be notified according to the aforementioned developer user information.

[0179] This application also provides a storage medium having a program suitable for database maintenance to implement the database maintenance method described in any embodiment of this application.

[0180] As can be seen, the storage medium provided in this application embodiment, through acceptance testing of the latest submitted version files of the project's public database, initially maintains the health of the project's public database. On the one hand, it can improve the effectiveness of full regression testing, reduce the probability of performing full regression testing on submitted erroneous version files, and save server resources; on the other hand, it can reduce the possibility of developers downloading and updating erroneous submitted version files or making modifications based on erroneous submitted version files, which can save manpower and time and reduce the impact on project progress.

[0181] This application also provides an electronic device, including at least one memory and at least one processor; the memory stores a program, and the processor calls the program to execute the database maintenance method described in any embodiment of this application.

[0182] As can be seen, the electronic device provided in this application embodiment maintains the health of the project's public database by conducting acceptance tests on the latest submitted version files of the project's public database. On the one hand, this can improve the effectiveness of full regression testing, reduce the probability of conducting full regression testing on submitted erroneous version files, and save server resources. On the other hand, it can reduce the possibility of developers downloading and updating erroneous submitted version files or making modifications based on erroneous submitted version files, thereby saving manpower and time and reducing the impact on project progress.

[0183] The foregoing describes multiple embodiment schemes provided by the embodiments of this application. The optional methods described in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending to a variety of possible embodiment schemes. These can all be considered as the embodiment schemes disclosed and published by the embodiments of this application.

[0184] While the embodiments disclosed above are described in this application, this application is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application should be determined by the scope defined in the claims.

Claims

1. A database maintenance method, characterized in that, include: Retrieve the latest commit version file from the project's public database; Based on the preset acceptance test items, the latest submitted version file is tested and the test results are obtained. The acceptance test items include basic instance simulation tests. The basic instance simulation test refers to the simulation test performed on instances of the basic characteristics of each functional module of the integrated circuit after compiling the latest submitted version file of the integrated circuit. Different integrated circuits correspond to different basic instances. When the test result is that the acceptance test fails, the latest accepted version file is determined. The latest accepted version file includes the latest submitted version file that has passed the acceptance test in the project's public database. Obtain the development user information for each unaccepted test submission version file after the latest accepted version file is submitted. Based on the developer user information, the test results are sent to each of the developer users who submitted the unaccepted test version files.

2. The database maintenance method as described in claim 1, characterized in that, Also includes: The test results are identified in the latest commit file in the project's public database.

3. The database maintenance method as described in claim 1, characterized in that, Also includes: When the test result is that the acceptance fails, the test result will be sent to the developer user of the latest submitted version file.

4. The database maintenance method as described in claim 1, characterized in that, The steps for determining the latest accepted and submitted version file include: When there is an intermediate submission file that has not undergone acceptance testing between the latest submission file and the latest acceptance-passed submission file, acceptance testing is performed on the intermediate submission file to obtain the intermediate test results. This process continues until the intermediate test results are accepted or all acceptance tests are completed. Then, the intermediate submission file that has passed acceptance or the latest acceptance-passed submission file is determined to be the current latest acceptance-passed submission file.

5. The database maintenance method as described in claim 4, characterized in that, The step of performing acceptance testing on the intermediate commit version file and obtaining the intermediate test results includes: The acceptance test is performed on each intermediate commit version file arranged according to the commit time using a binary search method to obtain the intermediate test results.

6. The database maintenance method according to any one of claims 1-5, characterized in that, The steps for obtaining the latest commit version file from the project's public database include: According to the preset acceptance testing cycle, the latest submitted version file within the acceptance testing cycle is periodically retrieved from the project's public database.

7. The database maintenance method as described in claim 6, characterized in that, The step of retrieving the latest commit version file from the project's public database also includes: It was determined that the latest submitted version of the file had not been tested.

8. The database maintenance method as described in claim 7, characterized in that, The step of determining that the latest submitted version file has not obtained test results includes: The script determined that the latest submitted version of the file had not received any test results.

9. The database maintenance method as described in claim 6, characterized in that, Also includes: Obtain the latest accepted submission version file from the project's public database. The latest accepted submission version file is the latest accepted submission version file from the project's public database. Perform a full regression test on the latest accepted version file and obtain the full regression test results.

10. The database maintenance method as described in claim 9, characterized in that, The step of obtaining the latest accepted submission version file from the project's public database includes: According to the preset full regression test cycle, the latest acceptance-passed submission version file within the full regression test cycle is periodically retrieved from the project's public database.

11. The database maintenance method as described in claim 9, characterized in that, Also includes: When the full regression test result is that the regression fails, the full regression test result will be sent to the development user who submitted the latest accepted version file.

12. The database maintenance method as described in claim 9, characterized in that, Also includes: When the full regression test result is that the regression fails, the latest regression version file is determined to have passed and submitted. Obtain the development user information for each submitted version file that has not undergone complete regression testing after the latest regression submission version file; The developer users who submitted version files that have not undergone complete regression testing will be notified according to the aforementioned developer user information.

13. A database maintenance device, characterized in that, include: The module for retrieving the latest commit version file is suitable for retrieving the latest commit version file from the project's public database. The acceptance testing module is suitable for testing the latest submitted version file based on preset acceptance testing items and obtaining test results. The acceptance testing items include basic instance simulation tests. The basic instance simulation test refers to the simulation test performed on instances of the basic characteristics of each functional module of the integrated circuit after compiling the latest submitted version file of the integrated circuit. Different integrated circuits correspond to different basic instances. The second sending module is adapted to determine the latest accepted submission version file when the test result is that the acceptance test has failed. The latest accepted submission version file includes the latest submission version file that has passed the acceptance test in the project's public database. Obtain the development user information for each unaccepted test submission version file after the latest accepted version file is submitted. Based on the developer user information, the test results are sent to each of the developer users who submitted the unaccepted test version files.

14. The database maintenance apparatus as described in claim 13, characterized in that, Also includes: An identification module is adapted to identify the test results in the latest submission version file in the project's public database.

15. The database maintenance apparatus as described in claim 13, characterized in that, Also includes: The first sending module is adapted to send the test result to the developer of the latest submitted version file when the test result is that the acceptance has failed.

16. The database maintenance apparatus as described in claim 13, characterized in that, The second sending module is further adapted to determine the latest accepted submission version file, including: When there is an intermediate submission file that has not undergone acceptance testing between the latest submission file and the latest acceptance-passed submission file, acceptance testing is performed on the intermediate submission file to obtain the intermediate test results. This process continues until the intermediate test results are accepted or all acceptance tests are completed. Then, the intermediate submission file that has passed acceptance or the latest acceptance-passed submission file is determined to be the current latest acceptance-passed submission file.

17. The database maintenance apparatus as described in claim 16, characterized in that, The second sending module is further adapted to perform acceptance testing on the intermediate commit version file and obtain intermediate test results, including: The acceptance test is performed on each intermediate commit version file arranged according to the commit time using a binary search method to obtain the intermediate test results.

18. The database maintenance apparatus according to any one of claims 13-17, characterized in that, The latest commit version file acquisition module is adapted to acquire the latest commit version file from the project's public database, including: According to the preset acceptance testing cycle, the latest submitted version file within the acceptance testing cycle is periodically retrieved from the project's public database.

19. The database maintenance apparatus as described in claim 18, characterized in that, The module for obtaining the latest submitted version file is also adapted to: Before retrieving the latest commit version file from the project's public database, ensure that the latest commit version file has not been tested.

20. The database maintenance apparatus as described in claim 19, characterized in that, The latest commit version file acquisition module is further adapted to determine that the latest commit version file has not obtained test results, including: The script determined that the latest submitted version of the file had not received any test results.

21. The database maintenance apparatus as described in claim 18, characterized in that, Also includes: The complete regression testing module is suitable for obtaining the latest accepted submission version file in the project's public database, where the latest accepted submission version file is the latest accepted test submission version file in the project's public database. Perform a full regression test on the latest accepted version file and obtain the full regression test results.

22. The database maintenance apparatus as described in claim 21, characterized in that, The complete regression testing module is adapted to obtain the latest accepted submission version file from the project's public database, including: According to the preset full regression test cycle, the latest acceptance-passed submission version file within the full regression test cycle is periodically retrieved from the project's public database.

23. The database maintenance apparatus as described in claim 21, characterized in that, The transmitting module is also adapted to: When the full regression test result is that the regression fails, the full regression test result will be sent to the development user who submitted the latest accepted version file.

24. The database maintenance apparatus as described in claim 21, characterized in that, The complete regression test module is also suitable for: When the full regression test result is that the regression fails, the latest regression version file is determined to have passed and submitted. Obtain the development user information for each submitted version file that has not undergone complete regression testing after the latest regression submission version file; The developer users who submitted version files that have not undergone complete regression testing will be notified according to the aforementioned developer user information.

25. A storage medium, characterized in that, The storage medium has a program suitable for database maintenance to implement the database maintenance method as described in any one of claims 1-12.

26. An electronic device, characterized in that, It includes at least one memory and at least one processor; the memory stores a program, and the processor invokes the program to perform the database maintenance method as described in any one of claims 1-12.

Images