Test case file management method, device and system, electronic equipment, storage medium and program product

Abstract

The present application is about a test case file management method, device and system, electronic device, storage medium and program product, and relates to the field of integrated circuit technology. The test case file management method includes: in response to receiving a workspace lock request sent by a user from a client, sending a user workspace that the user has created in a public directory to the client; in response to receiving a lock instruction for a target workspace in the user workspace sent by the user from the client, locking the target workspace, and sending a lock result of successfully locking the target workspace to the client. The present application can solve the problem of local test case file synchronization without delay and code being easily modified, and can improve the standardization and uniformity of test case file management, ensure the correctness of test case files, and avoid confusion in EDA software development work caused by changes in test case files.

Description

Technical Field

[0001] The present application relates to the field of integrated circuit technology, and in particular to a test case file management method, device and system, electronic equipment, storage medium and program product. Background Art

[0002] Electronic design automation (EDA) refers to the use of computer-aided design software to complete the functional design, synthesis, verification, physical design (such as layout, routing, layout, design rule checking, etc.) of very large scale integrated circuit (VLSI) chips.

[0003] The role of EDA tools is to verify whether the design files (for example, verilog.v files) provided by users are accurate, while test case files (also called test case files) are test files written by software testing to test the correctness of EDA software functions. In EDA software development projects that include software testing work, test case libraries (also called test case file libraries) and EDA software source code libraries are usually included.

[0004] For test case files, in related technologies, the code file management system (Git library) is generally used for management. Git is a distributed version control system. Each developer has a complete code repository locally, which makes collaboration more flexible. Even without a network connection, developers can submit code and view history. It is widely used in software development to track and manage code changes.

[0005] However, in traditional Git systems, since test case files are stored locally, there may be delays in the file synchronization process, resulting in different versions of test case files accessed by different developers. In addition, test case files can still be modified after confirmation, which may cause errors in the test work that has called the file, thereby triggering an inaccurate assessment of the correctness of the EDA source code and causing false positives in the EDA software code. Summary of the invention

[0006] The present application provides a test case file management method, device and system, electronic device, storage medium and program product to at least solve the problem of local test case file synchronization without delay and code being easily modified in the related art. The technical solution of the present application is as follows:

[0007] According to a first aspect of the present application, a method for managing test case files is provided, wherein the test case files are used in a code testing tool in integrated circuit electronic design automation, and the method for managing test case files is executed on a local area network server, wherein the method for managing test case files comprises: in response to receiving a workspace locking request sent by a user from a client, sending to the client a user workspace that the user has created in a public directory, wherein the public directory is located on the local area network server, the user workspace is used to store the test case files, and among all users, only the user who creates the user workspace has editing authority over the user workspace; in response to receiving a locking instruction for a target workspace in the user workspace sent by the user from the client, locking the target workspace, and sending to the client a locking result of successfully locking the target workspace, wherein locking the target workspace comprises removing all users' write authority over the test case files in the target workspace.

[0008] According to a second aspect of the present application, a method for managing test case files is provided, wherein the test case files are used in a code testing tool in integrated circuit electronic design automation, and the method for managing test case files is executed on a client, wherein the method for managing test case files comprises: sending a workspace locking request input by a user to a local area network server; receiving from the local area network server a user workspace that the user has created in a public directory, wherein the public directory is located on the local area network server, the user workspace is used to store the test case files, and among all users, only the user who creates the user workspace has editing authority over the user workspace; sending a locking instruction input by a user for a target workspace in the user workspace to the local area network server; and receiving a locking result of successfully locking the target workspace from the local area network server, wherein locking the target workspace comprises removing all users' write authority over the test case files in the target workspace.

[0009] According to a third aspect of the present application, a management device for test case files is provided, wherein the test case files are used in a code testing tool in integrated circuit electronic design automation, and the management device for test case files is arranged on a local area network server, wherein the management device for test case files comprises: a sending unit, configured to send a user workspace created by the user in a public directory to the client in response to receiving a workspace locking request sent by the user from a client, wherein the public directory is located on the local area network server, the user workspace is used to store the test case files, and among all users, only the user who creates the user workspace has the editing permission of the user workspace; a locking unit, configured to lock the target workspace in response to receiving a locking instruction for a target workspace in the user workspace sent by the user from the client, and send a locking result of successfully locking the target workspace to the client, wherein locking the target workspace comprises removing the write permission of all users to the test case files in the target workspace.

[0010] According to a fourth aspect of the present application, a management device for a test case file is provided, wherein the test case file is used for a code testing tool in integrated circuit electronic design automation, and the management device for the test case file is arranged on a client, wherein the management device for the test case file comprises: a first sending unit, configured to send a workspace locking request input by a user to a local area network server; a first receiving unit, configured to receive from the local area network server a user workspace that the user has created in a public directory, wherein the public directory is located on the local area network server, the user workspace is used to store the test case file, and among all users, only the user who creates the user workspace has the editing authority of the user workspace; a second sending unit, configured to send a locking instruction input by the user for a target workspace in the user workspace to the local area network server; a second receiving unit, configured to receive a locking result of successfully locking the target workspace from the local area network server, wherein locking the target workspace comprises removing the write authority of all users to the test case files in the target workspace.

[0011] According to a fifth aspect of the present application, a management system for test case files is provided, wherein the test case files are used in a code testing tool in integrated circuit electronic design automation, wherein the management system for the test case files comprises a local area network server and a client, wherein the client sends a workspace locking request input by a user to the local area network server; the local area network server sends a user workspace created by the user in a public directory to the client in response to the workspace locking request, wherein the public directory is located on the local area network server, the user workspace is used to store the test case files, and among all users, only the user who creates the user workspace has editing authority for the user workspace; the client sends a locking instruction input by the user for a target workspace in the user workspace to the local area network server; the local area network server locks the target workspace in response to the locking instruction, and sends a locking result of successfully locking the target workspace to the client, wherein locking the target workspace comprises removing all users' write authority for the test case files in the target workspace.

[0012] According to a sixth aspect of the present application, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions, wherein the processor-executable instructions, when executed by the processor, prompt the processor to execute the test case file management method described in the present application.

[0013] According to a seventh aspect of the present application, a computer-readable storage medium is provided. When instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the test case file management method described in the present application.

[0014] According to an eighth aspect of the present application, a computer program product is provided, comprising computer instructions, which, when executed by a processor, implement the test case file management method described in the present application.

[0015] The technical solution provided by this application brings at least the following beneficial effects:

[0016] In the present application, the public directory is located on the LAN server, and the public directory may include a user workspace for storing test case files, so that the user's test case files can be stored on the LAN server, avoiding the delay problem in the local synchronization process, and only the user who creates the user workspace has the editing authority of the user workspace, and the user can lock the workspace, and after locking, the write authority of all users to the test case files in the locked workspace will be removed, so that on the one hand, the test case files can be avoided from being modified by non-creating users, and on the other hand, after the user workspace is locked, all users including the creator do not have write authority, so that the test case files can be avoided from being modified again after confirmation, thereby causing the problem of error in the test work. Through such a scheme, the standardization and uniformity of test case file management can be improved, and the test case files can be ensured to be correct, avoiding the confusion of EDA software development work caused by the change of test case files.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification are used to explain the principles of the present application, and do not constitute an improper limitation on the present application.

[0019] Figure 1 is a schematic flowchart showing an example of a method for managing test case files according to an embodiment of the present application.

[0020] Figure 2 It is a schematic flow chart showing the steps of creating a user workspace in the test case file management method according to an embodiment of the present application.

[0021] Figure 3 It is a schematic flowchart of an example of creating a user workspace in a test case file management method according to an embodiment of the present application.

[0022] Figure 4 It is a schematic flowchart showing an example of operations in a test case file management method according to an embodiment of the present application.

[0023] Figure 5 , Figure 6 and Figure 7 The flowchart is an example of locking a target workspace in a test case file management method according to an embodiment of the present application.

[0024] Figure 8It is a schematic flowchart showing the steps of testing a target project test file in a test case file management method according to an embodiment of the present application.

[0025] Fig. 9 The present invention is a flowchart of an example of deleting a workspace in a test case file management method according to an embodiment of the present application.

[0026] Fig.10 is a schematic flowchart illustrating another example of a method for managing a test case file according to an embodiment of the present application.

[0027] Fig.11 is a schematic block diagram showing an example of a test case file management device according to an embodiment of the present application.

[0028] Fig.12 is a schematic block diagram showing another example of a test case file management device according to an embodiment of the present application.

[0029] Fig.13 is a block diagram showing a management system for test case files according to an embodiment of the present application.

[0030] Fig.14 is a block diagram illustrating an electronic device according to an embodiment of the present application.

[0031] Reference numerals:

[0032] 1110 - sending unit; 1120 - locking unit; 1210 - first sending unit; 1220 - first receiving unit; 1230 - second sending unit; 1240 - second receiving unit; 1310 - local area network server; 1320 - client; 10 - electronic device; 101 - processor; 102 - memory. DETAILED DESCRIPTION

[0033] In order to enable ordinary persons in the art to better understand the technical solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0034] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0035] It should be noted that the phrase "at least one of the items" in this application includes three types of parallel situations: "any one of the items", "a combination of any number of the items", and "all of the items". For example, "including at least one of A and B" includes the following three parallel situations: (1) including A; (2) including B; (3) including A and B. Another example is "executing at least one of step 1 and step 2" which means the following three parallel situations: (1) executing step 1; (2) executing step 2; (3) executing step 1 and step 2.

[0036] As mentioned above, in the related art, the Git library method is generally used to manage test case files. However, this method may cause problems such as local test case file synchronization without delay and code being easily modified.

[0037] Specifically, during the EDA software development process, a large number of test case files need to be read and maintained to verify the correctness and stability of the EDA software. A test case is a set of predefined inputs and expected outputs. By executing these test cases, developers can discover and fix potential errors as early as possible to ensure the reliability of the design.

[0038] The role of the test case file is to verify the functional correctness of the EDA software product during the EDA development process. In the EDA software testing (PV, Product Verification) phase, the EDA software needs to read a test case file (Test_Case) with a design error. If the EDA software can successfully detect and report the corresponding error, it can be said that the test case file and the relevant functional logic of the EDA software are valid. The software testing phase verifies a verification software (ie, EDA software) through the above process.

[0039] The roles played by test cases in the EDA software development process include: Functional verification: used to verify whether the various functional modules of the EDA tool work as expected, such as syntax analysis, logic synthesis, layout and routing, etc.; Performance evaluation: By executing test_cases of different sizes and complexities, the performance of the EDA tool can be evaluated, such as running speed, memory usage, etc.; Regression testing: During the software development process, regression testing is required after each code modification to ensure that the new modifications will not introduce new problems. The test case file library can effectively support regression testing.

[0040] The following are examples of the file types and characteristics of common test cases in EDA software.

[0041] Test cases corresponding to the read_lib command (files in ".lib" format): The read_lib command is mainly used to read standard library files (files in ".lib" format), which contain device attributes and model information. Since standard library files are relatively stable, the generated test_cases are also relatively stable, that is, the number of test cases may be large, but they will not change frequently.

[0042] Test cases (".v" format files) corresponding to the read_design command: Mainly used to read design files (".v" format files), which describe the logical structure of the circuit. Since design files often change, it is necessary to generate corresponding test cases for different designs. The number of test cases is large and they often need to be modified before confirming the test case files.

[0043] It can be seen that in an actual project, the number of test case files may be large, and the files may be frequently modified before they are finally confirmed. In the related art, such complex management of test case files is achieved through the Git system.

[0044] The Git system has a collaborative work function, in which team members can work together by pulling the latest changes from the remote repository and pushing local modifications to the remote repository. In addition, the Git system also has a version control function. Every time a test case is modified and committed, the Git system will generate a new version.

[0045] However, the traditional Git system has the following problems in the management and synchronization of test cases:

[0046] First, in traditional solutions, due to the delay in the synchronization process of test case files and the possibility that test case files may be modified after confirmation, the accurate evaluation of the correctness of the EDA source code may be triggered, causing false alarms in the EDA software code.

[0047] Specifically, in traditional solutions, changes in test case files may cause chaos in EDA software development. The PV department of EDA software will pre-produce some faulty test case files. These test case files cannot be modified after they are produced and are strongly related to the EDA code logic. Therefore, there are many problems using the traditional Git system. For example, after uploading, the test case files usually cannot be modified or need to be modified with extreme caution. If they are modified at will, the stability of the EDA software will be affected. For example, after the EDA software passes the verification using version 1 of the file, if version 1 is changed, the previous EDA verification result may be reported as an error. However, such an error result cannot reflect that the error is caused by the change of version 1 of the test case file.

[0048] In addition, in traditional solutions, in addition to the test case file changes that are prone to errors, the delay in the update and upload of the test case file is also prone to errors and confusion. Specifically, after the test case file 123.v is changed, at the beginning of the change or shortly after the change, the EDA software using the test case file 123.v may pass the test verification. The reason is the update delay, and the EDA software actually loads the old file. After a period of time after the change, the test case file 123.v in the Git system is successfully updated, which may cause the EDA code snippet test to fail and report an error (such as an error or a whole piece of error). Moreover, it is difficult to locate the cause of the error of the EDA code snippet test failure, and it is difficult to find that it is caused by the delay in the update of the test case file 123.v.

[0049] In general, software testing and the stability of EDA software require a test case file management system that can not only implement the addition, deletion, modification and query of test case files, but also avoid the development progress of EDA software caused by poor management of test case files, such as avoiding errors in previously verified codes due to changes in test case files.

[0050] In view of the above problems, the exemplary embodiments of the present application propose a test case file management method, a test case file management device, a test case file management system, an electronic device, a computer-readable storage medium and a computer program product, which can solve or at least alleviate the above problems.

[0051] In a first aspect of the exemplary embodiment of the present application, a method for managing a test case file is provided. Figures 1 to 10 Describe in detail.

[0052] According to the exemplary embodiment of the present application, the test case file management method can be executed on a local area network server, the test case file can be used in a code testing tool in integrated circuit electronic design automation, the local area network server and at least one client can be communicatively connected to form a local area network (LAN), and a management system for test case files can be formed. As an example, the management system for test case files according to the present application can be implemented based on a Linux system, for example, it can run in a Linux system environment.

[0053] The user can access the LAN server from the client and send a request or instruction to the LAN server. The LAN server can perform corresponding operations in response to the received request or instruction, for example, it can also return the result of the operation to the client.

[0054] As an example, code testing tools for EDA software may be loaded on the client, and these tools may use test case files to test the EDA software.

[0055] In response to receiving a workspace lock request sent by a user from a client, the LAN server may send a user workspace created by the user in a public directory to the client. Here, the public directory is located on the LAN server, and the user workspace is used to store test case files. Among all users, only the user who created the user workspace has the editing authority of the user workspace.

[0056] The local area network server can also lock the target workspace in response to receiving a locking instruction sent by the user from the client to the target workspace in the user workspace, and send a locking result of successfully locking the target workspace to the client. Here, locking the target workspace includes removing all users' write permissions to the test case files in the target workspace.

[0057] According to the test case file management method of the exemplary embodiment of the present application, it is possible to avoid the delay problem of the test case file during the local synchronization process, and to avoid the test case file being modified by a user other than the creator or the test case file being modified again after confirmation. Through such a solution, the standardization and uniformity of test case file management can be improved, the test case file can be ensured to be correct, and confusion in EDA software development work caused by changes in test case files can be avoided.

[0058] The above-mentioned LAN server and client may be, for example, a tablet computer, a laptop computer, a digital assistant, a wearable device, etc. Here, the LAN server may be an independent server, a server cluster, a cloud computing platform or a virtualization center.

[0059] The following will refer to Figure 1 An example of a test case file management method according to an embodiment of the present application is described. Here, the test case file can be used in a code testing tool in integrated circuit electronic design automation, and the test case file management method can be executed on a local area network server. Figure 1 As shown, the test case file management method includes the following steps:

[0060] In step S110 , in response to receiving a workspace locking request sent by a user from a client, a user workspace created by the user in a public directory may be sent to the client.

[0061] Here, the public directory is located on the LAN server, and the user workspace is used to store test case files. Among all users, only the user who creates the user workspace has the editing permission of the user workspace. Here, the editing permission may include the write permission, and in some examples, the editing permission may also include the delete permission.

[0062] As an example, a public directory can be created on a LAN server. Here, the public directory can be a File Transfer Protocol (FTP), allowing any user connected to the server to access and download files in it.

[0063] As an example, a public directory may include a public data storage area and a hidden data storage area. The public data storage area may be a public area, which is open to all users who have the right to access the public directory. The hidden data storage area may be a private area, which is used to store operation records, maintenance information, user information, etc. of the entire directory. The directories or contents in this area are not open to users and are managed uniformly by the tool. For example, the files in this area may be hidden from users, and users cannot see them or modify them.

[0064] The user workspace can be located in the public data storage area. The hidden data storage area can include a log directory, a user personal data directory, and a lock file directory, wherein the log directory can be used to store the operation log of the LAN server; the user personal data directory can be used to store personal data corresponding to each user, and the user workspace can be located in the user data directory; the lock file directory can be used to store currently locked file information, historically locked file information, and unlocked file information.

[0065] Specifically, the hidden data storage area (reg_dir) may include, for example but not limited to: a log directory including tool log files (logfile, reg), scheduled script log files, secondary lock file scheduled script log files, etc.; and a user personal data directory including user personal data system (usr_data), etc.

[0066] The tool log files include Reg log files, Reg tool error log files, and Reg tool all operation log files. Reg log files are used to store all major operation information of the Reg tool theme, and Reg tool error log files are used to store error logs. Reg tool all operation log files are used to store all operation information. Here, Reg refers to commands that perform addition, modification, import, export, and other operations on the values ​​in the registry subkey information and registry key values.

[0067] The scheduled script log files include the scheduled script log files for cleaning up unlocked files and the scheduled script log files for cleaning up empty folders.

[0068] The secondary lock file timing script log file includes the Reg directory structure check timing script file.

[0069] The user personal data system can be used for each user (whoami) is a data set created with the name of the user. The user data system may include a user workspace file, which is used to record the workspace currently opened by the user. For example, as will be described in detail later, the files and paths of the current workspace are recorded between the first identifier "begin init folder" and the second identifier "end initfolder" so that the subsequent lock command can select the files to be locked. The user personal data system also includes completed task information and other information records of the workspace operated by the user. Here, the completed task information is used to record the workspace that the user has completed (or locked).

[0070] File lock data (lock_data) is used for hard lock. File lock data can include a list of files to be locked, a total list of locked files, and a completed list of locked files. The list of files to be locked is used to store all files that have been marked as soft locks by the user (the timed script for secondary locks will traverse and search for locked files, and perform secondary locks at regular intervals) (this will be described in detail below). The total list of locked files is used to store all folders that have been hard locked. The completed list of locked files is used to store folders that have been locked.

[0071] In related technologies, the synchronization mechanism of the Git system relies on manual triggering and cannot achieve real-time synchronization of code changes. Its operation is cumbersome, and developers need to perform a series of "git push", "commit" and other operations to push local code changes to the remote repository, which increases the number of operation steps.

[0072] In this regard, according to the embodiments of the present application, as described above, by providing a public directory, all developers can easily access and use it, for example, by mounting it as a local disk, developers can quickly create a workspace in the public directory, and the operation can be the same as creating a folder on the local disk, which greatly simplifies the operational process of version control and no longer needs to execute complex "git push", "commit" and other commands.

[0073] For the Git system, when multiple people collaborate, due to the time difference in file synchronization, different users may read different versions of the same file, resulting in merge conflicts. Specifically, when multiple people collaborate on development, due to the reliance on pull, push, commit and other operations to synchronize code, the following problems are prone to occur: when multiple developers modify the same file at the same time, file conflicts frequently occur, which easily leads to merge conflicts, resulting in interruptions to development work, and the conflict resolution process is complicated and time-consuming, reducing the overall efficiency of the development team.

[0074] In this regard, according to the embodiments of the present application, naming rules can be preset according to products / modules / projects, R&D departments, work tasks, etc. As an example, the first-level path can be set to the regdata root directory, the middle path can be set to be named according to the software product (LPC, GPA) or R&D department (PE, PV, RD), and the last-level directory can be named according to the issue or task, which improves the clarity of file organization and reduces the possibility of misoperation.

[0075] In addition, as an example, different access permissions can be set for directories at different levels. For example, the last-level directory can be set to "only the creator can read, write and modify", and other intermediate-level directories can be set to "others in the same R&D team can modify", ensuring that each developer only has full write permissions to his or her own workspace, thereby avoiding file conflicts.

[0076] An example process of creating a public directory in a method according to an embodiment of the present application is given below.

[0077] In step 1, a custom directory may be created. Specifically, a Linux system may be set up on a server, and a custom directory such as reg_dir may be created to be used as a root directory for storing relevant data.

[0078] In step 2, a log directory may be created. A running log directory may be created under the created custom directory, for example, named ".log", which may be used to store system running logs. A log subdirectory may be created under the log directory, for example, named "regmgr_log", which may be used to store specific log files. The system on the server may create a log file named by date under the log subdirectory each time it runs.

[0079] In step 3, a user personal data directory may be created. For example, a user personal data directory may be created under a custom directory, such as a directory named ".data", which may be used to store user-related data. A user data subdirectory may be created under the user personal data directory, such as a directory named "userdata", which may be used to store each user's personal data. A subdirectory named after the user name may be created for each user under the user data subdirectory.

[0080] In step 4, a lock file directory may be created. A lock data directory may be created under the user's personal data directory, for example, named "lock_data", which may be used to store lock files. A list of files to be locked, a total list of locked files, and a lock file completion table may be created under the lock data directory. The list of files to be locked (lock_file_list) may be used to record the list of files currently locked; the total list of locked files (lock_file_list_all) may be used to record the list of all files that have been locked; and the lock file completion table (lock_file_list_finish) may be used to record the list of files that have been unlocked.

[0081] In step 5, you can set up a permission check mechanism. Specifically, you can set up the system to check the write permission of the custom directory. If the custom directory is not writable, the system will report an error.

[0082] In step 6, a parameter checking mechanism may be set. Specifically, the system may be set to check whether the user has entered the correct parameters. If no parameters are entered, the system will prompt the user to enter the parameters and explain the function of the parameters.

[0083] In step 7, a status record file can be created. A workspace file, completed task information, and deleted file information are created in each user's user data subdirectory. The workspace file can be used to record the current user's workspace; the completed task information can be used to record completed tasks; and the deleted file information can be used to record deleted files or directories. At this point, the creation of a public directory and the establishment of a management system for test case files can be completed.

[0084] After the public directory is created, users can create their own workspaces. Specifically, after the above preparations are ready, EDA software development engineers can use tools such as regmgr to create their own user file spaces in the public directory. Each user has the right to add permissions to the entire public directory, so that they can initialize a workspace (which can be equivalent to a folder) under the public directory ( / mnt / regdata) according to the project, R&D team, or any structure that meets the requirements. Later, basic data files such as test cases can be added to this folder.

[0085] After the EDA software development engineer creates his own user workspace in the public directory, he can define the user workspace as the work scope that only the EDA software development engineer can edit and operate (regmgr onlyeffect in this space). In addition, each user can initialize a space (or folder) in the / mnt / regdata directory to add basic data files to the folder later.

[0086] Users can create and transfer test case files in a user workspace. For example, a user workspace can store a set of test case files, and different groups of test case files can correspond to different user workspaces. A set of test case files can be used to test a certain function or a certain part of the EDA software. Users can store the written test case files in the corresponding user workspace. When a set of test case files in a user workspace is completed, the user can lock the user workspace. When locked, all users can call the test case files in the space to test the EDA software, but these files cannot be edited to ensure the correctness of the files and avoid problems such as false test reports caused by file version updates or file modifications. As an example, before the user workspace is locked, the test case files therein cannot be called or may be invisible to other users.

[0087] When a user needs to lock a user workspace, a workspace lock request can be sent from the client, and the server can send the user workspaces that the user has created in the public directory to the client. The client can display these created user workspaces to the user, allowing the user to select the space to be locked.

[0088] According to an embodiment of the present application, a user workspace may be created, for example, by using an "init" command. Figure 2 As shown, a user workspace can be created in the following ways:

[0089] In step S210 , in response to receiving a space creation instruction sent by a user from a client, it may be checked in a public directory whether a user workspace to be created specified in the space creation instruction exists.

[0090] Here, the space creation instruction may include a relative path of the user workspace to be created relative to the upper-level directory.

[0091] Specifically, when creating a workspace, the user needs to inform the server in the instruction of the file directory to which the user workspace to be created belongs, that is, its parent directory. After receiving the instruction, the server can search whether the current user workspace to be created has been created in the above-mentioned parent directory according to the relative path. For example, it can check whether there is a space renamed with the name of the user workspace to be created. In response to checking that the user workspace to be created exists, a prompt message or an error message can be returned to the client to prompt that the user workspace already exists. For example, the error code example can be as follows:

[0092] “userA: ~ regmgr init test

[0093] 2024-09-10 15-39-02 userA ERROR: folder path already exists.".

[0094] In step S220 , in response to detecting that the user workspace to be created does not exist, the absolute path of the user workspace to be created in the public directory may be determined based on the relative path.

[0095] Here, the absolute path can be recorded so that it can be found in the subsequent locking process. As an example, the sample code of the relative path and the absolute path can be as follows:

[0096] “userA :- regmgr init productA / task1

[0097] Info: Directory init at ' / home / userA / regdir / productA / task1'successfully.".

[0098] In the above code, "task1" is the user workspace to be created, "productA" is its parent directory, "productA / task1" can represent the above relative path, and " / home / userA / regdir / productA / task1" can represent the above absolute path.

[0099] In step S230, the write permission of each directory in the absolute path may be checked level by level according to the directory structure in the absolute path.

[0100] In this step, before completing the creation, the write permission of each subdirectory of the folder to be initialized can be checked level by level according to the absolute path. By checking the writability of the path in this way, file conflicts can be avoided.

[0101] In response to checking that any of the directories in the absolute path is not writable, a prompt "folder is locked" may be displayed, and an error message may be recorded in a log file. For example, a code example of the error message may be as follows:

[0102] “userA: ~ regmgr init test / zzz

[0103] 2024-09-10 15-39-02 userA ERROR: Path' / mnt / efs / fs1 / reg_test_data / CN / test / zzz' is locked (read-only) and cannot be written to.".

[0104] In step S240 , in response to checking that the write permissions of the directories in the absolute path are all writable, a user workspace to be created may be created.

[0105] By creating a user workspace in the above manner, it can be ensured that the created workspace will not conflict with the existing space, and each directory of the created workspace is writable, so that the workspace is also writable after creation, avoiding the problem of non-writable after creation.

[0106] In addition, as described above, the public directory may include a log directory, which can be used to store the operation log of the local area network server. As an example, in the above creation process, a user workspace can also be created in the following manner: in response to determining the absolute path, recording a first identifier in the operation log; in response to checking that the write permissions of each directory in the absolute path are writable, recording the absolute path in the operation log; after creating the user workspace to be created, recording a second identifier in the operation log.

[0107] Specifically, during the creation process, in order to record the creation process, an identifier can be added to the log at the beginning and end of the creation. The identifier can be used to prompt the log record location of a single creation operation, so that the creation information and creation process of each workspace can be easily located. The first identifier can be, for example, "begin init folder", and the second identifier can be, for example, "end init folder". The creation process can be recorded between the first identifier and the second identifier, and the absolute path of the created workspace can be recorded to facilitate finding the space created by the user when locking it later. The code examples of the first identifier, the second identifier, and the absolute path can be as follows:

[0108] "---begin init folder

[0109] init file / mnt / efs / fs1 / reg test data / cw / test / zzz

[0110] file init successfully

[0111] ----end init folder".

[0112] In addition, as an example, in the above creation process, a user workspace can also be created in the following way: before executing the step of checking whether the user workspace to be created specified in the space creation instruction exists in the public directory, verify whether the authority of the user sending the space creation instruction is the preset legal authority.

[0113] Specifically, the options of the "init" command may include a permission verification part, through which the "init" command will first verify the legitimacy of the command after receiving the data. For example, the operation legitimacy verification may be performed, specifically, it may be determined whether the operator has the authority to create a workspace. As an example, a whitelist may be pre-set, and users in the whitelist are deemed to have legal authority and can execute subsequent steps; users not in the whitelist are deemed to have no legal authority and may not execute subsequent steps.

[0114] Through the above-mentioned legal authority verification, the process of creating user workspaces can be improved to ensure the legality and reliability of the creation operation.

[0115] In addition, as an example, in the above creation process, a user workspace can also be created in the following way: after executing the step of creating the user workspace to be created, in response to querying the user database where the user exists in the public directory, the operation information of creating the user workspace is recorded in the user database.

[0116] Here, the user database is used to store the user's operation information. Accordingly, the options of the "init" command may also include, for example, a personal basic data detection part.

[0117] Specifically, after the permission verification is passed, the operator identity can be extracted and the basic information of the user database can be verified through the Linux system function whoami.

[0118] Here, when verifying the user database, it can be determined whether the user database of the current user has been constructed. In response to the user database not existing, a dedicated database can be created in the data area; in response to the user database already existing, a complete operation record of this operation can be recorded in the user database, for example, including but not limited to the user, time, operations performed, detailed operation process, operation results, etc. The following is a code example of the user database:

[0119] "2024-09-10 15-39-02 userA ---begin init folder

[0120] 2024-09-10 15-39-02 userA init file / mnt / efs / fs1 / reg_test_data / cN / test

[0121] 2024-09-10 15-41-09 userA ----begin init folder

[0122] 2024-09-10 15-41-09 userA init file / mnt / efs / fsl / reg test data / cN / test / zzz

[0123] 2024-09-10 15-41-09 userA file init successfully

[0124] 2024-09-10 15-41-09 userA ----end init folder

[0125] 2024-09-10 15-41-15 userA ----begin init folder

[0126] 2024-09-10 15-41-15 userA init file / mnt / efs / fsl / reg_test_data / cN / test / zzz

[0127] 2024-09-10 15-41-28 userA ----begin lock folder

[0128] 2024-09-10 15-41-28 userA lock file number:1

[0129] 2024-09-10 15-41-28 userA lock file" / mnt / efs / fs1 / reg_test_data / cN / test / zzz"successfully

[0130] 2024-09-10 15-41-28 userA rm datafile ' / mnt / efs / fs1 / reg_test_data / cN / .data / userdata / hzhong / morkspace' successfully

[0131] 2024-09-10 15-41-28 userA ----end lock folder

[0132] 2024-09-10 15-41-37 userA ----begin init folder

[0133] 2024-09-10 15-41-37 userA file path check fail”.

[0134] Through the above-mentioned personal basic data detection, it can be ensured that after the creation is completed, the creation process can be completely recorded, which is convenient for locating the user workspace of each user and finding relevant information later.

[0135] An example process of creating a user's personal workspace in a method according to an embodiment of the present application is given below. Figure 3 As shown, an example process of creating a user's personal workspace may include the following steps:

[0136] In step S301, the server may receive a workspace display request sent from the client, for example, the request may be sent through the "reg_mgr init" option. In step S302, it may be queried whether the current user's workspace exists. In response to the existence of the workspace, in step S303, the existing user workspace may be printed and an identifier may be added to it, for example, at the beginning, so that the space created by the user may be displayed to the user. If a certain path no longer exists, a prompt message, such as "Not exists", may be added at the end. In response to the non-existence of the workspace, in step S304, a prompt message may be returned to the client, such as "Work space is clean", indicating that the current user has not created a workspace, for example, the user database of the user does not exist.

[0137] In step S305, an instruction for creating a user workspace may be received from the client, wherein the instruction may include the file name of the user workspace to be created, and the instruction may also include a target path input by the user, operation authority configuration information, and the like.

[0138] The target path can be used to specify an available space as the user workspace to be created. The operation permission configuration information can fully open the permission to add, delete, modify, and search for the user workspace to be created. By inputting such a request or instruction, the server can be quickly provided with preliminary information about the space to be created, thereby improving the creation efficiency. Here, a parameter needs to be specified in the creation instruction "regmgr init" option. The parameter can be a relative path relative to the upper-level directory (for example, " / mnt / efs / fs1 / reg_test_data / CN"). For example, if the relative path is "dir1 / dir2", the absolute directory actually initialized is " / mnt / efs / fs1 / reg_test_data / CN dir1 / dir2".

[0139] In step S306, if the user has not created a space, a user database for storing user data (such as information about created spaces) may be created, and its path may be written into the log file. In addition, in this step, a first identifier may be written into the log file, such as initialization operation start information "----begin init folder", to indicate that the creation of the user workspace begins here. For example, an empty folder may be created based on mnt / regdata / , recorded as workspace and stored in the user data.

[0140] In step S307, the write permission of each directory in the absolute path can be checked level by level. In response to any directory being unwritable, it can be considered that the file is locked, and in step S308, a record indicating that the user workspace creation failed can be written in the log file, such as "----init file path check fail". In response to each directory being writable, in step S309, the absolute path of the user workspace to be created can be written in the log file.

[0141] In step S310, it can be checked whether the user workspace to be created (or the folder to be initialized) already exists. In response to the existence, in step S311, information indicating that the user workspace to be created already exists can be prompted, such as "Folder path already exists", where "Folder" can represent the user workspace; in response to the non-existence, it indicates that the new user workspace can be created, and the user can be prompted to open up this new space for his own use. In step S312, the user workspace can be created and the initialization is successful. For example, it can be executed at any location: regmgr init YOUR / PATH. The initialization success prompt message appears, which means the initialization is successful.

[0142] In step S313, a record of successful creation may be written into the log file, such as "file initialized successfully".

[0143] In step S314, the absolute directory path may be written into the user workspace to record the file path in the user workspace created by the user for subsequent steps to extract and display, etc. In step S315, a second identifier may be written into the log file, such as initialization operation end information "---end init folder".

[0144] The above creation function may be implemented by a tool script, and the tool script may be, for example, “option init: init workspace at / mnt / regdata”.

[0145] After all the previous steps are completed and there are no errors, the workspace can be considered to be created, and the address of the space is written into the user's personal workspace database (such as the above user database) to facilitate subsequent operations. The space is only open to the user, and other users have no right to operate. The user who is the creator can access the space and can copy, move, and create any required files. For example, if the file does not exist, it can be created.

[0146] The above describes an example process of creating a target workspace. As an example, according to an embodiment of the present application, before a user creates a workspace, the user can send a display instruction from the client to the server to obtain the current directory structure in the public directory. In this way, the user can be guided to determine the directory location of the workspace to be created (for example, determine the parent directory of the workspace to be created), and avoid the user providing erroneous space creation instructions as much as possible, such as creating a workspace in an unexpected directory, thereby improving work efficiency.

[0147] Specifically, the test case file management method may further include: in response to receiving a display instruction sent by a user from a client, checking whether a public directory exists; in response to checking that the public directory exists, sending a display object specified by the display instruction to the client.

[0148] Here, the user may input a display instruction on the client, and the display instruction may be used to display a display object in a public directory, and the display object may be directory information of the public directory and / or its subdirectories. Upon receiving the display instruction, the server may first check whether the public directory exists, and if not, may return a prompt message indicating that the public directory does not exist to the client; if so, may return the display object specified in the display instruction to the client.

[0149] As an example, the display instructions may include, for example, but not limited to, at least one of the following items: displaying the directory structure of the public directory; displaying the file names of all files in the public directory and the directory location of each file; displaying the file names of all files in the public directory and the user to whom each file belongs; displaying all directories in the public directory and the last modification time of each directory; displaying all directories in the public directory and the absolute path of each directory.

[0150] Figure 4 An example of display operation according to an embodiment of the present application is shown. Figure 4 As shown, in step S410, a display instruction regmgr show may be received, which is used to instruct the system to display information of a specified file or folder. In step S420, it may be determined whether a public directory (such as the above-mentioned custom directory reg_dir) exists. If it does not exist, in step S430, it may be prompted that the path does not exist; if it exists, different information display modes may be selected according to the display instruction input by the user. For example, Figure 4As shown, in step S440, the display object "xxx" specified by the user in the display instruction can be displayed, wherein the specific content of the object can be displayed, for example, "xxx is the first-level directory name or path name under the public directory (reg_dir)". If the display object is a file name, an error can be reported, and all directories and subdirectories under the directory will be printed out in the form of a tree.

[0151] In step S450, the current directory structure of the public directory and / or the specific contents in the directory can be displayed to facilitate the rapid creation of the corresponding workspace. For example, in the default state, the directory structure corresponding to regdata (excluding files) can be displayed, for example, it can include but is not limited to at least one of the following items: user name (user): used to display the folder to which it belongs; file (file): used to display which files are in the folder; path (path): used to display the complete file path for easy copying; time (time): used to display the file change time.

[0152] The above display function can be implemented by a tool script. For example, the tool script can be: option show: display structure (- file show all files -user show belong to -time show changetime -path show full path).

[0153] In addition, selecting different information display methods according to the display instructions input by the user may include: in response to no display parameters being given in the display instructions, displaying all directories and their subdirectories under the custom directory in a tree structure; in response to display parameters being given in the display instructions, selecting different display methods according to the type and value of the parameters.

[0154] For example, in response to the display parameter being a directory name, all directories and subdirectories under the directory can be displayed in a tree structure; in response to the display parameter being a file name, the user can be prompted that the parameter input is incorrect; in response to the display parameter containing keywords related to files, all files under the specified directory can be displayed, and the file names and the directories they are located in can be listed; in response to the display parameter containing keywords related to users, all files under the specified directory can be displayed, and the file names and the users to whom they belong can be listed; in response to the display parameter containing keywords related to time, the last modification time of all directories and subdirectories under the specified directory can be displayed; in response to the display parameter containing keywords related to paths, the absolute paths of all directories and subdirectories under the specified directory can be displayed.

[0155] As an example, the sample code including the display instruction without given display parameters may be as follows:

[0156] “userA: ~ regmgr show / / No display parameters are given, display all directories and their subdirectories

[0157] [drwxrwxr -x] / home / userA / regdir / / Display public directory

[0158] [drwxrwxr-x]productA / / Show product catalog

[0159] [drwxrwxr-x]productB

[0160] [dr-xr-xr-x]task1 / / Display the task directory under the product directory."

[0161] Here, "x" can represent the delete permission, "r" can represent the read permission, "w" can represent the write permission, and "product" can be, for example, the directory of each module (or product) in the EDA software, for example, the directory of the following modules (or products): unified power format (UPF) module, power management (PWR) module, testability function (DFT) module, clock domain crossing (CDC) module and static code analysis (LINT). "task" can represent the task directory under "product".

[0162] As an example, the sample code of the display instruction containing keywords related to the file may be as follows:

[0163] “userA: ~ regmgr show / file / / The display parameter is the keyword "file" related to the file

[0164] [drwxrwxr -x] / home / userA / regdir

[0165] [drwxrwxr-x]productA

[0166] [-rw-rw-r --] file1.lib

[0167] [drwxrwxr-x]productB

[0168] [dr-xr-xr-x]task1".

[0169] Here, the " / " in " / file" can represent the target path, and "file" represents the secondary option.

[0170] As an example, the sample code of the display instruction including the file path can be as follows:

[0171] “userA: ~ regmgr show / productA userA / / The display parameter is the user-related keyword "user"

[0172] [userA] / home / userA / regdir / productA

[0173] [userA] task1".

[0174] Here, "show / productA userA" means showing the files of user A under module A.

[0175] As an example, the sample code of the display instruction containing time-related keywords may be as follows:

[0176] “userA: ~ regmgr show / time / / The display parameter is the time-related keyword "time"

[0177] [Jul 26 16:02] productA

[0178] [Jul 26 15:53] productB".

[0179] As an example, the sample code including the display instruction without given display parameters may be as follows:

[0180] “userA: ~ regmgr show / productA path / home / userA / regdir / productA / home / userA / regdir / productA / task1 / / The display parameter is the file name".

[0181] Here, when the display parameter is a file name, an error message may be prompted.

[0182] The above describes the example process of creating a user workspace. Now return to the reference Figure 1 In step S110, after receiving the user's lock request, the server may search the public directory for all user workspaces created by the user to allow the user to select a desired workspace to be locked from these workspaces. As an example, the workspace lock request sent by the user from the client may indicate that an operation of locking a space needs to be performed without indicating a specific space to be locked.

[0183] As an example, in step S110 , sending the user workspace created by the user in the public directory to the client may include: sending the user workspace created by the user in the public directory and an abnormal state of the user workspace to the client.

[0184] Here, the abnormal state may include that the user workspace does not exist or the user workspace is locked.

[0185] Specifically, the server can send information about all workspaces created by the user to the client. When an abnormality occurs in a space, the abnormal workspace can be judged as abnormal and the operator can be informed of the problem in a timely manner. For example, for a space with an abnormal state, a description of the abnormal state can be added to the information of the corresponding space. For example, an example of information sent to the client can be as follows:

[0186] “userA: regmgr lock

[0187] All work space:

[0188] -1- / mnt / efs / fs1 / reg_test_data / cN / test / aaa

[0189] -2- / mnt / efs / fs1 / reg_test_data / CN / test / bbb ​​Not exists

[0190] -3- / mnt / efs / fs1 / reg_test_data / CN / test / ccc Already locked

[0191] Enter the folder number you want to lock(lock all=@): ”.

[0192] Here, for abnormal user workspaces, in order to ensure data security, the space itself will not be processed after the abnormality is determined, but the information will be sent to the client for the user to judge. When the user processes the abnormal workspace, the server can remove the workspace from the database and no longer operate the abnormal space in the future.

[0193] For example, in the above example, for the user workspace numbered 3, in response to the user's lock request, an exception message indicating that the space has been locked can be sent. If the user still chooses to lock the space, the subsequent locking process can be performed normally. For example, an example of the information sent to the client can be as follows:

[0194] “userA: regmgr lock

[0195] All work space:

[0196] -1- / mnt / efs / fs1 / reg_test_data / cN / test / aaa

[0197] -2- / mnt / efs / fs1 / reg_test_data / CN / test / bbb ​​Not exists

[0198] -3- / mnt / efs / fs1 / reg_test_data / CN / test / ccc Already locked

[0199] Enter the folder number you want to lock(lock all=@): 3

[0200] 2024-09-10 16-02-06 userA INF0 :Lock ' / mnt / efs / fs1 / reg_test_data / CN / test / ccc Already locked' successfully.".

[0201] In the subsequent process, if the user sends a workspace locking request again, the locked workspace is no longer displayed. For example, in response to receiving a workspace locking request sent by the user for the second time, an example of information sent to the client may be as follows:

[0202] “userA: regmgr lock

[0203] All work space:

[0204] -1- / mnt / efs / fs1 / reg_test_data / cN / test / aaa

[0205] -2- / mnt / efs / fs1 / reg_test_data / CN / test / bbb ​​Not exists

[0206] Enter the folder number you want to lock(lock all=@): ”.

[0207] When the user enters a correct workspace without any exceptions, the tool will use the lock behavior normally. For example, the information sent to the client can be as follows:

[0208] “userA: regmgr lock

[0209] All work space:

[0210] -1- / mnt / efs / fs1 / reg_test_data / cN / test / aaa

[0211] -2- / mnt / efs / fs1 / reg_test_data / CN / test / bbb ​​Not exists

[0212] -3- / mnt / efs / fs1 / reg_test_data / CN / test / ccc Already locked

[0213] Enter the folder number you want to lock(lock all=0): 1

[0214] 2024-08-17 09-41-45 userA INFO: Lock ' / mnt / efs / fs1 / regtest_data / CN / test / aaa' successfully.".

[0215] Through the above method, when the user needs to lock the workspace, the currently lockable space can be displayed to the user for selection. This can avoid writing errors or path specification errors when the user directly enters the path of the workspace to be locked, thereby improving the user's work efficiency. In addition, prompts can be given for abnormal spaces to allow the user to choose how to deal with the abnormal space by themselves, thereby ensuring the correctness of the locking operation.

[0216] Continue to refer to Figure 1 In step S120, in response to receiving a locking instruction for a target workspace in the user workspace sent from the client, the target workspace may be locked, and a locking result indicating successful locking of the target workspace may be sent to the client.

[0217] Here, locking the target workspace can include removing all users' write permissions to the test case files in the target workspace. When the write permissions are removed, users can view the files, but cannot add, delete, or modify the file contents. This ensures the correctness and reliability of the files, and prevents them from being easily modified, thus reducing the possibility of false test reports.

[0218] In addition, as an example, locking the target workspace may also include removing the deletion permission of all users on the test case files in the target workspace.

[0219] According to the embodiments of the present application, the "removal of write permissions" described here can be considered as a soft lock. Specifically, in response to receiving a lock instruction, a temporary lock can be performed immediately. Specifically, a lock command can be used to set the permissions of the workspace to read-only after the workspace is created and the file transfer operation is completed. When the lock is input, the folder is changed to read-only permissions with the user's permissions, and temporarily read-only locked. At this time, the user as the creator can change it back, that is, the write permission can be regained. Here, the temporary locking method refers to locking the file using local permissions or user permissions, for example, it can be set to read-only "chmod-w".

[0220] In addition, as an example, in order to further ensure that the test case file will not be modified at will, hard locking can be further performed on the basis of the above soft locking to increase the locking level of the file.

[0221] For example, the test case file management method may also include: in response to locking the target workspace, recording the file path of the target workspace to a preset recording container; in response to reaching a preset timing time, using a preset locking script, modifying the management permission of the file path recorded in the recording container to read-only permission.

[0222] Here, the locking script may have root authority, which is the highest authority. The soft lock described above is only a lock that can be achieved by user authority, so the locked file may be tampered with, etc. Therefore, according to an embodiment of the present application, the content of the temporary soft lock can be recorded in a preset recording container, and the recording container can be located at a specified location in the file database, so that the final lock of the lock (such as a crontab timing script) can be mounted, and the final lock can query the file content and lock it. When the preset timing time is reached, the locking script can be used to modify the management authority of one or more locking tasks mounted in the recording container to read-only authority.

[0223] Here, the locking script may have root permissions, which may be preset. The above-mentioned timing time may be, for example, considered to be reached once every preset time interval. The locking script may perform a timed scan of the recording container according to the preset time interval. In this way, after writing the temporarily locked file path to the recording container, when the next timed time arrives, the locking script scans the recording container, finds the temporarily locked file, and finally locks it (i.e., root lock), which is a hard lock.

[0224] Specifically, after soft locking through user permissions, the locked file path can be included in the record container to record the files waiting for hard locking, and the lock script is automatically scanned at intervals such as 2 minutes to perform the final lock. The hard lock can be the final lock of the root user permissions. The hard lock means that only the read permission of the file is retained, and the write permission and other editing permissions of the file are cancelled. After the hard lock, no one can modify the file. As an example, the root permission of the Linux system can be used for hard locking.

[0225] As an example, the hard lock method may include: using the permissions of the NFS machine to lock the file (chattr-i), specifically, by modifying the attributes of the file system on the NFS server, using the "chattr-i" command to set the file to an immutable state, prohibiting not only writing, but also deletion, renaming, and other operations. Here, the scheduled task can be executed through crontab with root permissions, for example, the command "comtab3: NFS system lock ("hardlock")" can be used to lock the file script twice using NFS permissions. The syntax can be " / 5 script", where script represents the detailed locking logic.

[0226] In addition, as an example, according to an embodiment of the present application, in order to leave room for modification in some special or emergency situations, a unique super editing permission can also be set for hard-locked files.

[0227] As an example, the test case file management method may further include: in response to receiving a file replacement instruction input by a user from a client, executing a file replacement operation using a preset replacement script.

[0228] Here, the file replacement instruction specifies the target file to be replaced and the new file used to replace the target file. The target file may be stored in the first file path in the locked user workspace, and the replacement script may have root authority.

[0229] The file replacement operation may include storing the new file to the second file path, moving the target file to a temporary directory, and moving the new file from the second file path to the first file path.

[0230] Specifically, files after hard locking require root permission scripts (such as the hard lock associated command regmgrreplace) to be further edited, which can provide unique super editing permissions. If you need to modify files after creating a workspace and after the timed script hard locks, you can only enable root permissions by entering the hard lock associated command to operate.

[0231] In the above file replacement process, you can enter the name of the file to be replaced and the new file path to replace the old file. The automatic replacement script gives the new path to save the new file, then moves the old file to a temporary directory (such as a trash directory), and then moves the new file to the original location of the old file to achieve replacement.

[0232] In the above manner, while ensuring that the file will not be modified by mistake through hard locking, it also leaves room for careful modification of the hard-locked file, so as to allow a script with root privileges to modify the file in some special or emergency situations.

[0233] In addition, as an example, before executing the above file replacement process, the user's permissions can be verified and the user can be prompted to make changes with caution by displaying preset guidance information. Here, the guidance information can include, for example, confirmation information asking the user to confirm again, prompt information prompting the user to make changes with caution, etc. In the case that the user does not have permission, an error can be directly reported, and the user can also be guided to complete the file replacement operation. For example, users with replacement permissions (or root permissions) can be displayed to the current user. The code example of the guidance information can be as follows:

[0234] "[userA] regmgr replace

[0235] 2024-09-10 16-27-45 userA INF0: Permissions validation passed

[0236] This is a dangerous operation. please make sure of the following:

[0237] 1. Make sure at least two people know what to do next.

[0238] 2. Think before you type

[0239] 3. Responsible for the consequences

[0240] Input 'yes' to continue(yes / no): ".

[0241] A code example to guide the user to complete the file replacement operation may be as follows: "2024-09-1016-28-54 zzha0ERROR[userA EnnocadProject] : Looks like you don't have permission. Perhaps you need to".

[0242] Through the above methods, you can lock the created user workspace through soft locking and hard locking, and set the permission of the workspace to read-only. This locking method can suppress the following common illegal operations: 1. Modify data at will: after locking, user permissions cannot be changed; 2. Modify others' unlocked data at will: when unlocked, only the creator has the modification permission.

[0243] The hard locking process can be implemented by a tool script, and the tool script can be, for example, "option lock: lock file (read only)". As an example, the code example for locking the target workspace can be as follows:

[0244] piper@Piperu:~ regmgr show

[0245] [drwxrwxr-x] / home / piper / regdir

[0246] [drwxrwxr-x] upf

[0247] [drwxrwxr -x] task1

[0248] 2 directories

[0249] piper@Piperu:~ regmgr lock

[0250] All work space:

[0251] -1- / home / piper / regdir / upf / task1 / / Provide operational options through usr data

[0252] Enter the folder number you want to lock(clean all=0):1

[0253] Info: Lock ' / home / piper / regdir / upf / task1'successfully.

[0254] Info: Work space is clean, it's time to get another case.

[0255] piper@PiperU:~ regmgr show

[0256] [drwxrwxr-x] / home / piper / regdir

[0257] [drwxrwxr-x] upf

[0258] [drwxrwxr-x] task1

[0259] The "regmgr lock" option can be used to lock the modified workspace. The Lock option data comes from the data center in the public directory, so users do not need to do any additional operations. They can directly select the workspace to be locked and lock it. The code example of the lock operation can be as follows:

[0260] "[userA cN] regmgr lock

[0261] All work space:

[0262] -1- / mnt / efs / fs1 / reg_test_data / cN / 1 /

[0263] -2- / mnt / efs / fs1 / reg_test_data / cN / dir1 / dir2

[0264] Enter the folder number you want to lock(lock all=0):

[0265] 12023-08-17 09-41-45 userA INF0: Lock / mnt / efs / fs1 / reg test_data / CN / 1 / 'successfully.".

[0266] As an example, the target workspace can also be locked in the following way: according to the directory structure in the file path of the target workspace, check level by level whether each directory in the file path of the target workspace has write permission; in response to checking that the write permission of each directory in the file path of the target workspace is writable, remove the write permission of all users to each directory to lock the target workspace.

[0267] Specifically, before locking the target workspace, its paths can be checked level by level to see if they are writable. If they are all writable, the lock can be performed normally; if there are unwritable directories, an error message can be prompted to exit the lock.

[0268] Through this process, the correctness of the space to be locked can be confirmed before locking. When there is a non-writable directory in the directory structure of its file path, it may mean that the parent directory of the space has been locked. It is necessary to confirm again whether the current locking operation is legal, which can further improve the rigor of file operations and avoid possible incorrect locking problems.

[0269] Combined with the above description of step S110 and step S120, the following reference Figure 5 , Figure 6 and Figure 7 An example process of locking a target workspace according to an embodiment of the present application is given.

[0270] like Figure 5 As shown, in step S501, a workspace lock request sent by a user from a client, such as "regmgr Lock", may be received. In step S502, it may be determined whether the workspace lock request has parameters, specifically, it may be checked whether redundant parameters are input. In response to having parameters, in step S503, a warning message may be prompted that the current option does not require parameters; in response to not having parameters, in step S504, it may be determined whether a user workspace of the user exists.

[0271] In response to the user workspace of the user not existing, it means that the user does not have any folders that need to be locked, please perform an initialization operation. For example, in step S505, it may be prompted that there are no folders that need to be locked, please perform a creation operation; in response to the user workspace of the user existing, the paths of all user workspaces can be read, and it can be checked one by one whether the paths exist.

[0272] For example, in step S506, the path in the user workspace may be printed and sent to the client to be displayed to the user. In step S507, it may be sequentially checked whether the path exists. In response to the path not existing, a prompt may be given that the path does not exist; in response to the path existing, in step S508, the write permission of the path may be sequentially checked. In response to the path not being writable, a prompt may be given that the path is locked.

[0273] In response to the path having write permission, in step S509, a prompt may be provided to enter the number of the folder (i.e., the user workspace) to be locked. In step S510, in response to receiving the user's locking instruction, the number specified in the locking instruction may be extracted, and it may be determined whether the number is valid. Here, the number may be composed of digits from 0 to 9, for example, and the number is a positive number that is less than or equal to the number of rows of the user workspace printed in step S506. When the number exceeds this range, the number in the locking instruction may be considered invalid. In response to the number being invalid, an error message may be provided in step S511, such as entering an invalid number.

[0274] In response to the number being valid, in step S512, the "lock number" may be written into a log file (eg, regmgr.log). Here, the log file may record detailed log information during the entire locking process, including but not limited to operation steps, error information, and the like.

[0275] In the above process, when the user inputs a lock request, the spaces created by the user can be listed, allowing the user to select the target workspace to be locked. For example, as shown in the following sample code, the user can specify to lock the workspace numbered 2:

[0276] "[userA AsyncRSDefMissed] regmg rock

[0277] All work space:

[0278] -1- / mnt / efs / fs1 / reg_test_data / CN / 1 /

[0279] -2- / mnt / efs / fs1 / reg_test_data / cN / dft_reg_data / checker / AsyncRsDefMissed /

[0280] Enter the folder number you want to lock(lock all=0): 2

[0281] 2023-08-16 17-28-55 userA IN0: Lock ' / mnt / efs / fs1 / reg_test_data / cN / dft_reg_data / checker / AsyncRSDefMissed / 'successfully.".

[0282] Then, if Figure 6 As shown, in step S601, it can be determined in sequence whether the corresponding folder has write permission based on the number specified by the user. In response to not having write permission, an error message can be prompted to prompt the user to check the locking instruction; in response to having write permission, in step S602, the chmod command can be used to remove the write permission.

[0283] In step S603, it can be determined again whether the folder still has write permission to confirm that the removal operation in step S602 is successfully executed. In response to the existence of write permission, an error message can be prompted in step S604; in response to the absence of write permission, a message that the path is locked successfully can be printed in step S605 to feedback corresponding information to the client. In step S606, successful locking information can be written to the log file.

[0284] In step S607, the path may be written to the finished file in the Isha folder. In step S608, the path may be written to the record container (e.g., lock_file_list) in the lock data folder. In step S609, the time, user, and path may be written to the record container in the lock data folder for subsequent hard locking, such as for a crontab script with root privileges to perform a privilege locking operation.

[0285] In addition, in response to the absence of write permission, in step S610, the user workspace can also be deleted from the user database, so that when the user subsequently requests to lock again, the currently locked space will no longer be displayed. In step S611, it can be detected whether the user workspace still exists. In response to the user workspace still existing, in step S612, an error message can be prompted and the system exits.

[0286] In response to the user workspace no longer existing, such as Figure 7 As shown, in step S701, information on successful deletion of the user workspace file may be written to a log file (eg, regmgr.log). In step S702, a non-zero valid number entered by the user may be received, and in step S703, it may be determined whether the corresponding file has write permission.

[0287] In response to the file not having the write permission, in step S704, the corresponding path in the user workspace may be removed.

[0288] In response to the file being writable, in step S705, the file write permission can be removed by the chmod command, and in step S706, it can be determined again whether the file has write permission. In response to the file still having write permission, an error message can be displayed in step S707, indicating that the lock has failed. In response to the file not having write permission, step S704 can be executed.

[0289] In step S708, the server may send a message to the client indicating that the selected folder has been successfully locked. Figure 6 The locking process in is similar to that in step S709, the selected folder can be successfully locked by recording and writing it in the log file. In step S710, the folder path can be written to the finish file under Isha. In step S711, the path can be written to the record container under the locked data folder.

[0290] In addition, after step S708, in step S712, it can also be determined whether the user workspace is empty. In response to the user workspace being empty, in step S713, the user workspace can be deleted; in response to the user workspace being empty, in step S714, the locking operation end information can be printed to the log file to complete the locking operation.

[0291] In addition, after step S713, in step S715, it can be determined again whether the user workspace still exists. In response to the user workspace still existing, in step S716, an error message can be printed, such as failure to delete the user workspace. In response to the user workspace no longer existing, in step S717, a prompt message can be printed, such as the user workspace has been cleaned up, and in step S718, information that the user workspace has been successfully deleted can be printed to the log file. Finally, step S714 can be executed to complete the locking operation.

[0292] In the above process, since the locking behavior will completely lock the user workspace, when the locking behavior occurs, multiple verifications can be performed to ensure that the locking behavior is correct.

[0293] For example, after receiving a workspace lock request from a user sent from a client, the user's personal information can be obtained through the Linux system interface whoami to ensure that the user has the authority to operate; in response to the user's authority verification, the user's historical personal data can be searched in the data storage area of ​​the public directory, and after obtaining the data of the user workspace created by the user, the authority of each workspace in the data can be determined. For example, the sample code for personal data in the user database can be as follows:

[0294] “All work space:

[0295] [userA aaa] regmgr lock

[0296] -1- / mnt / efs / fs1 / reg_test_data / CN / test / aaa

[0297] -2- / mnt / efs / fs1 / reg_test_data / cN / test / bbb

[0298] -3- / mnt / efs / fs1 / reg_test_data / cN / test / ccc

[0299] Enter the folder number you want to lock(lock all=0): ”.

[0300] The process of locking a user workspace is described above. In addition, as an example, according to an embodiment of the present application, the test case file management method may also include: in response to locking a target workspace, encrypting information of the target workspace, the file path of the target workspace, and operation data related to the locking behavior of the target workspace.

[0301] Specifically, after the target workspace is locked, the workspace can also be encrypted to prevent tampering and endangering the data center. As an example, the encryption algorithm can be predetermined by the tool and the timed encryption script, for example, the base64 algorithm, and the locking behavior itself will write the file path of the target workspace and the data related to the locking behavior of the target workspace into a preset locking form or log file, for example, "Dir: Path1 behavior: lock" can be written, and the text of the data encrypted by the base64 algorithm can be, for example: "RGly77yaUGF0aDEgIGJlaGF2aW91ciA6IGxvY2s=".

[0302] In addition, the information of the target workspace may also be locked. The information of the target workspace may include, but is not limited to, the directory, size, number of files, etc. in the target workspace. For example, a hash operation may be used to obtain the result. For example, for the information of the target workspace " / mnt / efs / fs1 / reg_test_data / CN / test / aaa 6545.83MB", the result after the operation is:

[0303] "f3987f1a25c9757bb85da50157a99d31d421bb88549a9c2f917649e73d39d34a".

[0304] The encrypted text obtained by the above encryption can be written into the database of the public directory for subsequent use. Through the above encryption method, the locking behavior itself can be encrypted to further prevent the file from being tampered with and ensure the data security of the server.

[0305] In addition, according to the embodiments of the present application, after encryption, the submitted behavior in the database can also be parsed as needed. Specifically, as mentioned above, the locking behavior will encrypt and write the data into the database, so the agreed encryption method can be used for decryption during parsing. Taking the above example as an example, the base64 algorithm can be used as the encryption and decryption scheme, and the agreed hash calculation is performed on the entire directory and the hash values ​​are compared to see if they are the same. If there is any difference, the decryption behavior is reported and terminated.

[0306] The above describes an example process of locking a user workspace. As an example, in an embodiment of the present application, Figure 8 As shown, before executing the step of locking the target workspace, the test case file management method may further include:

[0307] In step S810, a target test case file in a target workspace and a target project test file corresponding to the target test case file may be loaded.

[0308] In step S820, the target project test file may be tested using the target test case file to obtain a test result.

[0309] Specifically, since the target test case files stored in the user workspace are the data required for the test (case), the data such as ".lib" in the user workspace will be referenced during the test. Here, the data in the user workspace is loaded by loading the Init command, and the corresponding target project test files (such as ".tcl" format) are loaded for testing. Here, the loaded project test files can be the correct files confirmed in advance.

[0310] In step S830 , in response to the test result indicating that the test of the target project test file passes, a step of locking the target workspace may be performed.

[0311] If the test passes, it indicates that the data placed in the user's workspace is correct and the user can perform the locking operation.

[0312] In response to the test result indicating that the test of the target project test file failed, the user can be prompted to continue to modify the test case file in the user workspace, and can try to lock it again after the modification. The above test will still be performed before locking until the test passes to ensure that the file in the user workspace is correct before locking.

[0313] Through the above method, before locking, the correctness of the test case files in the user workspace to be locked can be pre-checked and confirmed to ensure that subsequent testing work can be carried out correctly.

[0314] In addition, as an example, according to an embodiment of the present application, the test case file management method may also include: in response to receiving a deletion request input by a user from a client, sending all user workspaces of the user and the abnormal status of the workspace to the client; in response to receiving a deletion instruction for the workspace to be deleted sent by the user from the client, deleting the workspace to be deleted.

[0315] Specifically, after creating a user workspace, if the user workspace is not locked, the user who created it can choose to delete the user workspace, thereby facilitating cleaning of data on the server and preventing redundant data from occupying storage space on the server.

[0316] Fig. 9 FIG. 2 shows an example process of deleting a user workspace according to an embodiment of the present application. Fig. 9 As shown, in response to receiving a delete instruction input by a user, in step S901, a delete instruction (e.g., regmgrdelete) may be accepted, which is used to instruct the system to delete a specified file or folder. In step S902, a first delete mark, such as "----begin delete folder", may be written to a log file (e.g., regmgr.log) to record the start of the delete operation in the log file. In step S903, it may be determined whether there are parameters after the delete instruction.

[0317] In response to the presence of parameters, in step S904, information indicating that no parameters are required may be displayed, such as "Option delete no need arg". In step S905, the path and number (or serial number) in the user workspace file may be printed, prompting the user to enter a number to delete the corresponding directory.

[0318] In response to the absence of parameters, in step S906, it can be determined whether the user workspace is empty. In response to the user workspace being empty, in step S907, information indicating that the user workspace is empty can be printed, such as "There is no folder in the workspace, no need to delete". In response to the user workspace being not empty, in step S908, all user workspaces of the user can be printed and the user can be prompted to enter the number of the folder (i.e., user workspace) to be deleted.

[0319] In step S909, it can be determined whether the path in each user workspace exists. In response to the path not existing, in step S910, the number of the space where the path does not exist, its absolute path and prompt information (such as "Not exists") that the path does not exist can be prompted.

[0320] In response to the existence of the path, in step S911, it can be determined whether the path in each user workspace has write permission. In response to not having write permission, in step S912, a temporary array can be written, which can include the number of the space without write permission, its absolute path, and prompt information of not having write permission (such as "Already locked").

[0321] In step S913, information requiring the user to enter a prompt may be printed, such as a preset default character "0" which may indicate deleting all, for example, "enter the number you want to delete (0 for all)".

[0322] In response to receiving the user's input, in step S914, it can be determined whether the input information is a positive number consisting of digits 0 to 9. In response to the input information not being a positive number consisting of digits 0 to 9, in step S915, the user can be prompted that the workspace number is invalid ("Invalid workspace number").

[0323] In step S916, the typed information can be determined, for example, 0. In step S917, all paths in the user workspace can be deleted. In step S918, it can be checked whether the folder still exists to ensure that the path is successfully deleted. In response to the folder still existing, in step S919, an error can be reported, indicating that the deletion failed. In response to the folder not existing, in step S920, the information of successful deletion can be printed, for example, "Delete number + path successfully" can be printed in sequence, and in step S921, the information of successful deletion of space can be written to the log file, such as "delete xx folder successfully". In addition, in step S922, the current time, user and file path can be written to deleted in the Isha directory in sequence. In step S923, the user workspace under the Isha directory can be deleted.

[0324] In step S924, information input again by the user may be received, such as typing a non-zero positive number. In step S925, the folder numbered corresponding to the typed number may be deleted. Similar to the above-mentioned deletion process, in step S926, it may be checked whether the corresponding file still exists. In response to the file still existing, in step S927, an error message "current time + user name + 'Delete single file error'" may be printed. In response to the file not existing, in step S928, the corresponding path in the user workspace may be deleted, and in step S929, the message "Delete [selected path] successfully." may be printed. In addition, in step S930, "Delete xx successfully" may be written to the log file under the current date, and in step S931, the time, user name and absolute path may be written to the deleted directory under Isha.

[0325] In addition, after step S928, in step S932, it can also be determined whether the user workspace is empty. In response to the user workspace not being empty, in step S933, a second deletion mark, such as "----enddelete folder", can be written into the log file to indicate that the deletion is complete. In response to the user workspace being empty, in step S934, the file user workspace can be deleted, and step S933 is executed.

[0326] Here, the response code example for the delete command can be as follows:

[0327] “userA: ~ regmgr delete

[0328] All work space:

[0329] -1- / home / userA / regdir / productA / task2

[0330] Enter the workspace number you want to delete(clean all=0): 1

[0331] Info: Delete" / home / userA / regdir / productA / task2'successfully.

[0332] Info:Work space is clean, it's time to get another case.".

[0333] An example process of deleting a user workspace is described above. In addition, as an example, according to an embodiment of the present application, the method may further include: performing regular cleanup, such as deletion, of an unlocked user workspace.

[0334] As an example, scheduled cleaning may include: cleaning up unlocked file scripts, such as can be implemented through the command "comtab:clean unlock file every sunday"; checking the entire directory structure script, such as can be implemented through the command "comtab2:check reg folder tree 1day"; cleaning up empty file scripts, such as can be implemented through the command "comtab3:clean empty folder".

[0335] The test case file management method according to the embodiment of the present application can reduce the dependence on remote warehouses and databases, reduce system maintenance costs, and provide a simplified writing process, improve work efficiency, and prevent illegal operations.

[0336] Specifically, in the traditional Git system, there is a lack of file locking function. Everyone has file editing permissions and cannot lock a single test case file. If this test case file is changed after the EDA software test passes, all EDA test codes that reference this file will have problems.

[0337] In addition, the Git system requires multiple commands to be entered for synchronization, which is cumbersome to operate, while the method of the present application can be easy to operate with NFS shared directories.

[0338] In addition, the synchronization mechanism of the Git system relies on manual triggering and cannot achieve real-time synchronization of code changes. Developers need to perform a series of operations such as git push and commit to push local code changes to the remote warehouse, which increases the number of operation steps. When the number of files in the warehouse is large, each push operation requires the transmission of a large amount of data, resulting in slow synchronization. The method of the present application can use the NFS shared file system as a storage medium, and all developers can directly access and modify files without the need for remote transmission via a third-party server. Since the NFS shared file system has the feature of real-time synchronization, any changes made by developers to files will be immediately reflected in the shared directory, achieving real-time synchronization of code changes. Compared with traditional Git operations, this method greatly simplifies the operating process of version control. Developers only need to create, modify, and delete files in the shared directory without executing complex git commands.

[0339] In addition, in order to avoid the problem of EDA software testing confusion caused by changes in test case files, the method of the present application detects duplicated files during the process of creating a workspace, ensuring that each test file has a unique file name and absolute path. When the subsequent EDA software reads these test files for software testing, it can ensure that the referenced test case files are unique and conflict-free. After creation, the file has only one name path, pointing to a specific test case file.

[0340] In addition, the method of the present application uses initial locking (soft locking) and deferred locking (hard locking) to make it possible to use user-level permissions for initial locking, and then use root permissions that are higher than user permissions in combination with a timing script to perform deferred hard locking, which not only ensures the timeliness of the locking, but also further ensures the stability of the file, reduces the probability of conflicts, and prevents unauthorized modifications.

[0341] In addition, when multiple people collaborate on the Git system, due to the time difference in file synchronization, merge conflicts may occur because different developers read different versions of the same file. Therefore, when dealing with complex projects, there are the following problems: When there are complex dependencies in the project, multiple developers modifying files at the same time can easily cause conflicts. For example, when a file is modified, other files that depend on it also need to be updated synchronously. If not handled properly, conflicts will occur. In addition, in order to avoid testing problems caused by synchronization delays, developers usually need to wait for a while after submitting the code, which undoubtedly reduces development efficiency.

[0342] In the method of the present application, each developer can only edit the workspace he or she created and has corresponding operation permissions for the files he or she submitted to the workspace. Through such a locking mechanism, the consistency of the files is ensured and conflicts caused by concurrent modifications are avoided.

[0343] The test case file management method according to the second aspect of the exemplary embodiment of the present application can be executed on the client, wherein the test case file is used for a code testing tool in integrated circuit electronic design automation, such as Fig.10 As shown, the test case file management method may include:

[0344] In step S1010, a workspace locking request input by a user may be sent to a local area network server.

[0345] In step S1020, a user workspace created by a user in a public directory can be received from a local area network server, wherein the public directory is located on the local area network server, the user workspace is used to store test case files, and among all users, only the user who creates the user workspace has editing authority for the user workspace.

[0346] In step S1030, a locking instruction input by the user for the target workspace in the user workspace may be sent to the local area network server.

[0347] In step S1040 , a locking result indicating successful locking of the target workspace may be received from the local area network server, wherein locking the target workspace includes removing the write permission of all users to the test case files in the target workspace.

[0348] As an example, the test case file management method further includes: sending a display instruction to the local area network server so that the local area network server checks whether the public directory exists; receiving a display object specified by the display instruction sent from the local area network server, and displaying it. The display instruction has been described above, so it will not be repeated here.

[0349] As an example, a user workspace is created in the following manner: a space creation instruction is sent to a local area network server, so that the local area network server performs the following operations: checking in a public directory whether the user workspace to be created specified in the space creation instruction exists, wherein the space creation instruction includes a relative path of the user workspace to be created relative to the upper-level directory; in response to checking that the user workspace to be created does not exist, determining the absolute path of the user workspace to be created in the public directory based on the relative path; checking the write permission of each directory in the absolute path level by level according to the directory structure in the absolute path; in response to checking that the write permission of each directory in the absolute path is writable, creating the user workspace to be created.

[0350] As an example, the public directory includes a log directory, which is used to store the operation log of the local area network server. The server also creates a user workspace in the following manner: in response to determining the absolute path, recording a first identifier in the operation log; in response to checking that the write permissions of each directory in the absolute path are writable, recording the absolute path in the operation log; after creating the user workspace to be created, recording a second identifier in the operation log.

[0351] As an example, the server also creates a user workspace in the following manner: before executing the step of checking in the public directory whether the user workspace to be created specified in the space creation instruction exists, verifying whether the authority of the user sending the space creation instruction is the preset legal authority; after executing the step of creating the user workspace to be created, in response to querying the user database of the user existing in the public directory, recording the operation information of this creation of the user workspace in the user database, wherein the user database is used to store the user's operation information.

[0352] As an example, receiving a user workspace that has been created by a user in a public directory from a local area network server includes: receiving a user workspace that has been created by a user in a public directory and an abnormal state of the user workspace from the local area network server, and displaying them, wherein the abnormal state includes that the user workspace does not exist or the user workspace is locked.

[0353] As an example, the test case file management method also includes: in response to locking the target workspace, the local area network server records the file path of the target workspace to a preset recording container; in response to reaching a preset timing time, the local area network server uses a preset locking script to modify the management permission of the file path recorded in the recording container to read-only permission, wherein the locking script has root permission.

[0354] As an example, the test case file management method also includes: sending a file replacement instruction to a local area network server so that the local area network server: uses a preset replacement script to perform a file replacement operation, wherein the file replacement instruction specifies a target file to be replaced and a new file used to replace the target file, the target file is stored in a first file path in a locked user workspace, the replacement script has root permissions, wherein the file replacement operation includes: storing the new file to a second file path, moving the target file to a temporary directory, and moving the new file from the second file path to the first file path.

[0355] As an example, the test case file management method further includes: in response to locking the target workspace, the local area network server encrypts the target workspace information, the file path of the target workspace, and the operation data related to the locking behavior of the target workspace.

[0356] As an example, before executing the step of locking the target workspace by the LAN server, the test case file management method also includes: the LAN server loads the target test case file in the target workspace and the target project test file corresponding to the target test case file; the LAN server uses the target test case file to test the target project test file to obtain a test result; in response to the test result indicating that the test of the target project test file has passed, the LAN server executes the step of locking the target workspace.

[0357] As an example, the LAN server locks the target workspace in the following manner: according to the directory structure in the file path of the target workspace, check level by level whether each directory in the file path of the target workspace has write permission; in response to checking that the write permission of each directory in the file path of the target workspace is writable, remove the write permission of all users to each directory to lock the target workspace.

[0358] As an example, the test case file management method also includes: sending a deletion request to a local area network server, and receiving all user workspaces of the user and abnormal status of the workspace from the local area network server, wherein the abnormal status includes that the user workspace does not exist or the user workspace is locked; sending a deletion instruction for the workspace to be deleted to the local area network server so that the local area network server deletes the workspace to be deleted.

[0359] An example of a user executing the above management method on a client is described below. A software developer can send a request or instruction to a local area network server through a client to create a user workspace, add files to the created user workspace, and lock the user workspace for which the work task has been confirmed to be completed.

[0360] Specifically, in creating or initializing a user workspace, the user can input a request to create a user workspace on the client, so that the local area network server executes the method of the first aspect above to complete the space creation. For example, the client can display the following sample code to inform the user that the space initialization is successful:

[0361] "[userA] regmgr init dft_reg_data / checker / AsyncRSDefMissed /

[0362] 2023-08-16 17-17-22 userA INF0: Directory init at' / mnt / efs / fs1 / reg_test_data / cN / dft_reg_data / checker / AsyncRSDefMissed / ' successfully.".

[0363] For the created user workspace, the user can access the corresponding directory through the client, and can copy, move, and create any required files from the local computer to the directory.

[0364] In addition, after the files in the user workspace are completed, the user can lock the workspace through the client. For example, the client can send a lock request input by the user to the local area network server: regmgr lock, so that the local area network server executes the method of the first aspect above to complete the lock. Within the predetermined synchronization time (for example, 5 minutes) after locking, the locked files will be synchronized to all servers.

[0365] The specific steps, variations and beneficial effects of the method in the above embodiment may be the same or similar to those in the test case file management method according to the first aspect of the embodiment of the present application described above, and will not be elaborated here.

[0366] According to a third aspect of the exemplary embodiment of the present application, a management device for a test case file is provided. The test case file is used for a code testing tool in integrated circuit electronic design automation. The management device for the test case file is arranged on a local area network server, wherein, Fig.11 As shown, the test case file management device includes a sending unit 1110 and a locking unit 1120 .

[0367] The sending unit 1110 can be configured to send a user workspace created by the user in a public directory to the client in response to receiving a workspace lock request sent by the user from the client, wherein the public directory is located on a local area network server, the user workspace is used to store test case files, and among all users, only the user who creates the user workspace has editing permissions for the user workspace.

[0368] The locking unit 1120 can be configured to lock the target workspace in response to receiving a locking instruction for the target workspace in the user workspace sent from the client by the user, and send a locking result of successfully locking the target workspace to the client, wherein locking the target workspace includes removing the write permission of all users to the test case files in the target workspace.

[0369] Regarding the device in the above-mentioned embodiment, the specific manner in which each unit performs the operation has been described in detail in the embodiment of the method. Its specific steps, variations and beneficial effects may be the same or similar to those in the test case file management method according to the first aspect of the embodiment of the present application described above, and will not be elaborated here.

[0370] According to a fourth aspect of the exemplary embodiment of the present application, a management device for a test case file is provided. The test case file is used for a code testing tool in integrated circuit electronic design automation. The management device for the test case file is arranged at a client. Fig.12 As shown, the test case file management device includes a first sending unit 1210 , a first receiving unit 1220 , a second sending unit 1230 and a second receiving unit 1240 .

[0371] The first sending unit 1210 may be configured to send a workspace locking request input by a user to the local area network server.

[0372] The first receiving unit 1220 can be configured to receive a user workspace that has been created by a user in a public directory from a local area network server, wherein the public directory is located on the local area network server, the user workspace is used to store test case files, and among all users, only the user who creates the user workspace has editing authority for the user workspace.

[0373] The second sending unit 1230 may be configured to send a locking instruction input by the user to the target workspace in the user workspace to the local area network server.

[0374] The second receiving unit 1240 may be configured to receive a locking result of successfully locking the target workspace from the local area network server, wherein locking the target workspace includes removing the write permission of all users to the test case files in the target workspace.

[0375] Regarding the device in the above-mentioned embodiment, the specific manner in which each unit performs the operation has been described in detail in the embodiment of the method. Its specific steps, variations and beneficial effects may be the same or similar to those in the test case file management method according to the first aspect of the embodiment of the present application described above, and will not be elaborated here.

[0376] According to a fifth aspect of the exemplary embodiment of the present application, a management system for test case files is provided, wherein the test case files are used in a code testing tool in integrated circuit electronic design automation, wherein Fig.13 As shown, the management system of the test case files includes a local area network server 1310 and a client 1320 .

[0377] The client 1320 sends a workspace locking request input by the user to the LAN server 1310 .

[0378] In response to the workspace lock request, the LAN server 1310 sends the user workspace created by the user in the public directory to the client 1320, where the public directory is located on the LAN server, the user workspace is used to store test case files, and among all users, only the user who creates the user workspace has editing permissions for the user workspace.

[0379] The client 1320 sends the locking instruction input by the user to the LAN server 1310 for locking the target workspace in the user workspace.

[0380] In response to the locking instruction, the LAN server 1310 locks the target workspace and sends a locking result indicating successful locking of the target workspace to the client 1320 , wherein locking the target workspace includes removing the write permission of all users to the test case files in the target workspace.

[0381] Regarding the system in the above-mentioned embodiment, the specific manner in which each unit performs the operation has been described in detail in the embodiment of the method. Its specific steps, variations and beneficial effects may be the same or similar to the test case file management method according to the first aspect of the embodiment of the present application described above, and will not be elaborated here.

[0382] According to the sixth aspect of the exemplary embodiment of the present application, an electronic device is provided, which includes: a processor; a memory for storing processor-executable instructions, wherein the processor-executable instructions, when executed by the processor, prompt the processor to execute the test case file management method described in the embodiment of the present application.

[0383] Fig.14 FIG. 1 is a block diagram of an electronic device according to an exemplary embodiment. Fig.14 As shown, the electronic device 10 includes a processor 101 and a memory 102 for storing processor executable instructions. Here, when the processor executable instructions are executed by the processor, the processor is prompted to execute the test case file management method as described in the above exemplary embodiment.

[0384] As an example, the electronic device 10 is not necessarily a single device, but may be any collection of devices or circuits that can execute the above instructions (or instruction sets) individually or in combination. The electronic device 10 may also be part of an integrated control system or system manager, or may be configured as a server that is interconnected with a local or remote (e.g., via wireless transmission) interface.

[0385] In the electronic device 10, the processor 101 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller or a microprocessor. As an example and not a limitation, the processor 101 may also include an analog processor, a digital processor, a microprocessor, a multi-core processor, a processor array, a network processor, etc.

[0386] The processor 101 may execute instructions or codes stored in the memory 102, wherein the memory 102 may also store data. Instructions and data may also be sent and received over a network via a network interface device, wherein the network interface device may employ any known transmission protocol.

[0387] The memory 102 may be integrated with the processor 101, for example, by placing RAM or flash memory within an integrated circuit microprocessor or the like. In addition, the memory 102 may include a separate device, such as an external disk drive, a storage array, or any other storage device that can be used by a database system. The memory 102 and the processor 101 may be operatively coupled, or may communicate with each other, such as through an I / O port, a network connection, etc., so that the processor 101 can read files stored in the memory 102.

[0388] In addition, the electronic device 10 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, a mouse, a touch input device, etc.) All components of the electronic device 10 may be connected to each other via a bus and / or a network.

[0389] According to the seventh aspect of the exemplary embodiment of the present application, a computer-readable storage medium is provided. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the test case file management method described in the embodiment of the present application.

[0390] The computer-readable storage medium may be, for example, a memory including instructions. Alternatively, the computer-readable storage medium may be: read-only memory (ROM), random access memory (RAM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disk storage, hard disk drive (HDD), solid state drive (SSD), card storage (such as, multimedia card, secure digital (SD) card or extreme digital (XD) card), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid state disk and any other device, any other device is configured to store computer programs and any associated data, data files and data structures in a non-transitory manner and provide the computer programs and any associated data, data files and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the above-mentioned computer-readable storage medium can be run in an environment deployed in a computer device such as a client, a host, an agent device, a server, etc. In addition, in one example, the computer program and any associated data, data files and data structures are distributed on a networked computer system, so that the computer program and any associated data, data files and data structures are stored, accessed and executed in a distributed manner by one or more processors or computers.

[0391] According to an eighth aspect of an exemplary embodiment of the present application, a computer program product is provided, comprising computer instructions, which, when executed by a processor, implement the test case file management method according to the embodiment of the present application.

[0392] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the claims.

[0393] In addition, it should be noted that although several examples of each step are described above with reference to specific drawings, it should be understood that the implementation methods of the present application are not limited to the combinations given in the examples, and the steps appearing in different drawings may be combined, which are not exhaustively listed here.

[0394] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the claims.

Claims

1. A method for managing test case files, characterized in that: The test case file is used for a code testing tool in integrated circuit electronic design automation. The test case file management method is executed on a local area network server. The local area network server and the client are connected to form a local area network. The test case file management method includes: In response to receiving a workspace locking request sent by a user from a client, sending a user workspace created by the user in a public directory to the client, wherein the public directory is located on the local area network server, the user workspace is used to store the test case file, among all users, only the user who created the user workspace has the editing authority of the user workspace, the public directory includes a public data storage area, and the user workspace is located in the public data storage area; In response to receiving a locking instruction for a target workspace in the user workspace sent from the client by the user, the target workspace is locked, and a locking result indicating successful locking of the target workspace is sent to the client, wherein locking the target workspace includes removing write permissions for test case files in the target workspace for all users.

2. The test case file management method according to claim 1, characterized in that: The public directory also includes a hidden data storage area, and the hidden data storage area includes a log directory, a user personal data directory and a lock file directory. The log directory is used to store the operation log of the local area network server. The user personal data directory is used to store personal data corresponding to each user. The lock file directory is used to store currently locked file information, historically locked file information, and unlocked file information.

3. The test case file management method according to claim 1, characterized in that: The test case file management method also includes: In response to receiving a display instruction sent by the user from the client, checking whether the public directory exists; In response to detecting that the public directory exists, sending the display object specified by the display instruction to the client, The display instruction includes at least one of the following items: Display the directory structure of the public directory; Display the file names of all files in the public directory and the directory locations of each file; Display the file names of all files in the public directory and the users to whom each file belongs; Display all directories in the public directory and the last modification time of each directory; Display all directories in the public directory and the absolute path of each directory.

4. The test case file management method according to claim 1, characterized in that: The user workspace is created by: In response to receiving a space creation instruction sent by the user from the client, checking in the public directory whether a user workspace to be created specified in the space creation instruction exists, wherein the space creation instruction includes a relative path of the user workspace to be created relative to the upper-level directory; In response to checking that the user workspace to be created does not exist, determining an absolute path of the user workspace to be created in the public directory based on the relative path; According to the directory structure in the absolute path, check the write permission of each directory in the absolute path level by level; In response to checking that the write permissions of the directories in the absolute path are all writable, the user workspace to be created is created.

5. The test case file management method according to claim 4, characterized in that: The public directory includes a log directory, and the log directory is used to store the operation log of the local area network server. The user workspace is also created in the following manner: In response to determining the absolute path, recording a first identifier in the operation log; In response to checking that the write permissions of the directories in the absolute path are all writable, recording the absolute path in the operation log; After the user workspace to be created is created, a second identifier is recorded in the operation log.

6. The test case file management method according to claim 4 or 5, characterized in that: The user workspace is also created by: Before executing the step of checking in the public directory whether the user workspace to be created specified in the space creation instruction exists, verifying whether the authority of the user who sends the space creation instruction is a preset legal authority, After executing the step of creating the user workspace to be created, in response to querying the user database of the user in the public directory, the operation information of creating the user workspace is recorded in the user database, wherein the user database is used to store the operation information of the user.

7. The test case file management method according to claim 1, characterized in that: The sending the user workspace created by the user in the public directory to the client comprises: The user workspace created by the user in the public directory and an abnormal state of the user workspace are sent to the client, wherein the abnormal state includes that the user workspace does not exist or the user workspace is locked.

8. The test case file management method according to claim 1, characterized in that: The test case file management method also includes: In response to locking the target workspace, recording a file path of the target workspace into a preset recording container; In response to reaching a preset timing time, the management authority of the file path recorded in the recording container is modified to a read-only authority using a preset locking script, wherein the locking script has root authority.

9. The test case file management method according to claim 8, characterized in that: The test case file management method also includes: In response to receiving a file replacement instruction input by the user from the client, a file replacement operation is performed using a preset replacement script, wherein the file replacement instruction specifies a target file to be replaced and a new file for replacing the target file, the target file is stored in a first file path in the locked user workspace, and the replacement script has root authority. The file replacement operation includes: storing the new file in a second file path, moving the target file to a temporary directory, and moving the new file from the second file path to the first file path.

10. The test case file management method according to claim 1, characterized in that: The test case file management method also includes: In response to locking the target workspace, information of the target workspace, a file path of the target workspace, and operation data related to the locking behavior of the target workspace are encrypted.

11. The test case file management method according to claim 1, characterized in that: Before executing the step of locking the target workspace, the test case file management method further includes: Loading the target test case file in the target workspace and the target project test file corresponding to the target test case file; Using the target test case file, testing the target project test file to obtain a test result; In response to the test result indicating that the test of the target project test file passes, the step of locking the target workspace is performed.

12. The test case file management method according to claim 1, characterized in that: Lock the target workspace by: According to the directory structure in the file path of the target workspace, check level by level whether each directory in the file path of the target workspace has write permission; In response to checking that the write permissions of the directories in the file path of the target workspace are all writable, the write permissions of all users on the directories are removed to lock the target workspace.

13. The test case file management method according to claim 1, characterized in that: The test case file management method also includes: In response to receiving a deletion request input by the user from the client, sending all user workspaces of the user and abnormal states of the workspaces to the client, wherein the abnormal state includes that the user workspace does not exist or the user workspace is locked; In response to receiving a deletion instruction for the workspace to be deleted sent by the user from the client, the workspace to be deleted is deleted.

14. A method for managing test case files, characterized in that: The test case file is used for a code testing tool in integrated circuit electronic design automation. The test case file management method is executed on a client. The client and a local area network server are connected in communication to form a local area network. The test case file management method includes: Sending a workspace lock request input by the user to the local area network server; Receive, from the local area network server, a user workspace created by the user in a public directory, wherein the public directory is located on the local area network server, the user workspace is used to store the test case file, among all users, only the user who created the user workspace has the editing authority of the user workspace, the public directory includes a public data storage area, and the user workspace is located in the public data storage area; Sending a locking instruction input by a user for a target workspace in the user workspace to the local area network server; A locking result indicating that the target workspace is successfully locked is received from the local area network server, wherein locking the target workspace includes removing write permissions of all users to the test case files in the target workspace.

15. A test case file management device, characterized in that: The test case file is used for a code testing tool in integrated circuit electronic design automation, and the management device of the test case file is arranged on a local area network server, and the local area network server and the client are connected in communication to form a local area network, wherein the management device of the test case file includes: A sending unit is configured to send, in response to receiving a workspace locking request sent by a user from a client, a user workspace created by the user in a public directory to the client, wherein the public directory is located on the local area network server, the user workspace is used to store the test case file, among all users, only the user who creates the user workspace has the editing authority of the user workspace, the public directory includes a public data storage area, and the user workspace is located in the public data storage area; A locking unit is configured to lock the target workspace in response to receiving a locking instruction for a target workspace in the user workspace sent from the client by the user, and send a locking result of successfully locking the target workspace to the client, wherein locking the target workspace includes removing the write permission of all users to the test case files in the target workspace.

16. A test case file management device, characterized in that: The test case file is used for a code testing tool in integrated circuit electronic design automation, and the management device of the test case file is arranged on a client, and the client and a local area network server are connected in communication to form a local area network, wherein the management device of the test case file includes: A first sending unit is configured to send a workspace locking request input by a user to a local area network server; A first receiving unit is configured to receive, from the local area network server, a user workspace created by the user in a public directory, wherein the public directory is located on the local area network server, the user workspace is used to store the test case file, among all users, only the user who created the user workspace has the editing authority of the user workspace, the public directory includes a public data storage area, and the user workspace is located in the public data storage area; A second sending unit is configured to send a locking instruction input by a user for a target workspace in the user workspace to the local area network server; The second receiving unit is configured to receive a locking result of successfully locking the target workspace from the local area network server, wherein locking the target workspace includes removing the write permission of all users to the test case files in the target workspace.

17. A test case file management system, characterized in that: The test case file is used in a code testing tool in integrated circuit electronic design automation, wherein the management system of the test case file includes a local area network server and a client, the local area network server and the client are connected in communication to form a local area network, The client sends a workspace locking request input by a user to the local area network server; In response to the workspace locking request, the LAN server sends the user workspace created by the user in the public directory to the client, wherein the public directory is located on the LAN server, the user workspace is used to store the test case file, among all users, only the user who created the user workspace has the editing authority of the user workspace, the public directory includes a public data storage area, and the user workspace is located in the public data storage area; The client sends a locking instruction input by a user to the local area network server for a target workspace in the user workspace; The LAN server locks the target workspace in response to the locking instruction, and sends a locking result indicating successful locking of the target workspace to the client, wherein locking the target workspace includes removing write permissions of all users to the test case files in the target workspace.

18. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing processor executable instructions, When the processor executable instructions are executed by the processor, the processor is prompted to execute the test case file management method according to any one of claims 1 to 14.

19. A computer-readable storage medium, characterized in that: When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the test case file management method according to any one of claims 1 to 14.

20. A computer program product comprising computer instructions, characterized in that When the computer instructions are executed by a processor, the test case file management method according to any one of claims 1 to 14 is implemented.

Images