A test method, device and equipment for CAE software and a storage medium

Abstract

The embodiment of the present specification relates to the technical field of software testing, and provides a test method, device and equipment for CAE software and a storage medium, the method comprises: splitting a target computer aided engineering (CAE) test task into a plurality of CAE test subtasks, each CAE test subtask corresponding to a test script; determining the task type of each CAE test subtask according to the metadata of each test script; assigning the CAE test subtasks to a plurality of virtual desktops and configuring a running environment for each virtual desktop according to the task type; and executing the test script corresponding to each CAE test subtask on each virtual desktop after the running environment is configured. Through the embodiment of the present specification, the problems of low test efficiency and poor stability of CAE software in the prior art can be solved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification relate to the technical field of software testing, and in particular to a CAE software-oriented testing method, device, equipment and storage medium. BACKGROUND

[0002] In the field of computer-aided engineering (CAE), with the continuous improvement of the complexity of industrial products, the functions of CAE software are increasingly rich, and comprehensive and efficient testing of the CAE software becomes a key link to guarantee the quality of the software. Traditional CAE software testing methods mostly rely on a single physical device or a simple test environment, and have many limitations. On the one hand, CAE testing tasks often involve a large amount of complex numerical calculation, multi-physical field coupling analysis, etc., and have a very high demand for hardware resources. The computing power and storage capacity of a single physical device are difficult to meet the demand of large-scale testing tasks, and problems such as low testing efficiency and task backlog are likely to occur. On the other hand, different CAE testing tasks may require different running environments. In the traditional testing method, frequent switching and configuration of these environments on the same physical device is not only cumbersome to operate, but also likely to result in inaccurate test results due to environment conflicts, and even test failures.

[0003] In addition, with the acceleration of the iteration speed of CAE software, the number and types of testing tasks are increasing, and the traditional manual allocation of testing tasks and monitoring of the testing process not only consumes a large amount of labor cost, but also makes it difficult to achieve fine management of the testing process and optimized scheduling of resources, which seriously restricts the development of the scale and automation of CAE software testing. Therefore, how to improve the testing efficiency and reliability of CAE testing tasks has become a problem to be solved in the current CAE software testing field. SUMMARY

[0004] In view of the above problems of the prior art, the purpose of the embodiments of the present specification is to provide a CAE software-oriented testing method, device, equipment and storage medium to solve the problems of low testing efficiency and poor stability of CAE software in the prior art.

[0005] To solve the above technical problems, the specific technical solutions of the embodiments of the present specification are as follows:

[0006] On the one hand, the embodiments of the present specification provide a CAE software-oriented testing method, which comprises:

[0007] splitting a target computer-aided engineering (CAE) testing task into a plurality of CAE testing subtasks, each of the CAE testing subtasks corresponding to a test script;

[0008] determining the task type of each of the CAE testing subtasks according to the metadata of each of the test scripts;

[0009] allocating the CAE test sub-tasks to a plurality of virtual desktops, and configuring a running environment for each virtual desktop according to the task type;

[0010] respectively executing a test script corresponding to each CAE test sub-task on each virtual desktop after the running environment is configured.

[0011] Further, the metadata of the test script includes a task type identifier; the task type is determined according to the task type identifier, and the task type includes a GUI test sub-task and a non-interface test sub-task.

[0012] Further, the allocating the CAE test sub-tasks to a plurality of virtual desktops includes:

[0013] allocating each CAE test sub-task to a corresponding scheduling queue according to a historical execution time of each test script;

[0014] allocating the CAE test sub-tasks in the scheduling queue to the plurality of virtual desktops in sequence.

[0015] Further, the scheduling queue includes at least a first scheduling queue and a second scheduling queue; the allocating each CAE test sub-task to a corresponding scheduling queue according to a historical execution time of each test script includes:

[0016] allocating a CAE test sub-task corresponding to a CAE test script with a historical execution time less than a preset threshold to the first scheduling queue;

[0017] allocating a CAE test sub-task corresponding to a CAE test script with a historical execution time greater than a preset threshold to the second scheduling queue; the first scheduling queue has a higher priority than the second scheduling queue.

[0018] Further, the allocating the CAE test sub-tasks in the scheduling queue to the plurality of virtual desktops includes:

[0019] sequentially obtaining a CAE test sub-task from the first scheduling queue and allocating the CAE test sub-task to an idle virtual desktop;

[0020] when the sub-tasks in the first scheduling queue are all allocated, sequentially obtaining a CAE test sub-task from the second scheduling queue and allocating the CAE test sub-task to an idle virtual desktop.

[0021] Further, the configuring a running environment for each virtual desktop according to the task type includes:

[0022] if the task type is a GUI test subtask, configuring a running environment of the virtual desktop as a graphic environment stack including a window manager, an X server, a GPU driver and a 3D rendering library;

[0023] if the task type is a non-interface test subtask, configuring a running environment of the virtual desktop as a computing environment including a basic command line and a computing library.

[0024] Further, the metadata of the test script further includes: a name and a version number of a target solver; and after the running environment is configured for each virtual desktop, the method further includes:

[0025] generating an isolated environment path of each CAE test subtask according to the name and the version number of the target solver;

[0026] judging whether a corresponding solver environment exists in an environment directory of a physical machine to which the virtual desktop belongs according to the isolated environment path;

[0027] if yes, performing hash calculation according to the name and the version number of the target solver to obtain a hash value of the target solver;

[0028] judging whether an environment record with the same hash value as the target solver exists in a pre-constructed cache;

[0029] if yes, returning a reusable path corresponding to the environment record;

[0030] if no, installing the target solver in the isolated environment path by calling a preset installation script, and storing the isolated environment path in the environment directory of the physical machine to which the virtual desktop belongs after installation is completed.

[0031] Further, the method further includes:

[0032] monitoring the virtual desktop state and the CAE test subtask state respectively according to a preset monitoring period;

[0033] if the CAE test subtask state is monitored as abnormal, terminating the CAE test subtask and reinserting it into a tail of a corresponding scheduling queue;

[0034] if the virtual desktop state is monitored as abnormal, reinserting a CAE test subtask being executed by the virtual desktop into a tail of a corresponding scheduling queue and restarting the virtual desktop.

[0035] On the other hand, an embodiment of the present specification provides a test device for CAE software, the device including:

[0036] The splitting module is configured to split a target computer-aided engineering (CAE) test task into a plurality of CAE test subtasks, each of the CAE test subtasks corresponding to a test script;

[0037] The determining module is configured to determine a task type of each of the CAE test subtasks according to metadata of each of the test scripts;

[0038] The assigning and configuring module is configured to assign the CAE test subtasks to a plurality of virtual desktops and configure a running environment for each of the virtual desktops according to the task type;

[0039] The testing module is configured to execute the test script corresponding to each of the CAE test subtasks on each of the virtual desktops after the running environment is configured.

[0040] In another aspect, the embodiments of the present specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory, when the computer program is executed by the processor, instructions of any one of the above-mentioned methods are executed.

[0041] In another aspect, the embodiments of the present specification also provide a computer readable storage medium, which stores a computer program, when the computer program is executed by a processor of a computer device, instructions of any one of the above-mentioned methods are executed.

[0042] In another aspect, the embodiments of the present specification also provide a computer program product, when the computer program product is executed by a processor of a computer device, instructions of any one of the above-mentioned methods are executed.

[0043] By adopting the above technical solutions, the test method for CAE software provided by the embodiments of the present specification breaks through the limitation of the computing power of a single device by splitting a complex test task into subtasks and assigning the subtasks to a plurality of virtual desktops for parallel execution, greatly shortens the total test time, and is especially suitable for CAE test requirements in multiple scenarios and with multiple parameters. Meanwhile, the exclusive running environment is configured for each virtual desktop according to the task type, the environment conflict between different tasks is avoided by using the isolation feature of the virtual desktop, the test environment is ensured to be accurate, the result deviation caused by environmental interference is reduced, and the reliability of the key numerical calculation in the CAE test is ensured. The task assignment, environment configuration, and script execution can be automatically implemented in the whole process, the manual intervention is greatly reduced, and the risk of failure in the test is reduced.

[0044] The above description is only a summary of some technical solutions of the embodiments of the present specification. In order to enable a clearer understanding of the technical means of some embodiments of the present specification, the above and other purposes, characteristics and advantages of the embodiments of the present specification can be more obvious and easy to understand, the preferred embodiments are specifically described below, and the accompanying drawings are described in detail as follows. BRIEF DESCRIPTION OF DRAWINGS

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the present specification or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present specification, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0046] Figure 1 A schematic diagram of a test system for CAE software in some embodiments of the present specification is shown;

[0047] Figure 2 A schematic diagram of the steps of a test method for CAE software in some embodiments of the present specification is shown;

[0048] Figure 3 A schematic diagram of the steps of assigning CAE test sub-tasks to multiple virtual desktops in some embodiments of the present specification is shown;

[0049] Figure 4 A schematic diagram of the steps of assigning each CAE test sub-task to a corresponding scheduling queue in some embodiments of the present specification is shown;

[0050] Figure 5 A schematic diagram of the steps of assigning CAE test sub-tasks in the scheduling queue to multiple virtual desktops in sequence in some embodiments of the present specification is shown;

[0051] Figure 6 A schematic diagram of the steps of configuring a solver environment for each test task in some embodiments of the present specification is shown;

[0052] Figure 7 A schematic diagram of the steps of monitoring the life cycle state of each virtual desktop in some embodiments of the present specification is shown;

[0053] Figure 8 A schematic diagram of the test flow in the CAE software regression test scenario in some embodiments of the present specification is shown;

[0054] Figure 9 A schematic diagram of the structure of a test device for CAE software in some embodiments of the present specification is shown;

[0055] Figure 10 A schematic diagram of the structure of a computer device is shown in this specification.

[0056] Explanation of symbols in the attached drawings:

[0057] 110. Task scheduling unit;

[0058] 120. Virtual Desktop Management Unit;

[0059] 130. Environmental Configuration Unit;

[0060] 140. Node monitoring unit;

[0061] 150. Redis caching unit;

[0062] 160. PostgreSQL database;

[0063] 901. Module splitting;

[0064] 902. Determine the module;

[0065] 903. Allocation and Configuration Module;

[0066] 904, Test Module;

[0067] 1002. Computer equipment;

[0068] 1004, Processor;

[0069] 1006. Memory;

[0070] 1008. Drive mechanism;

[0071] 1010. Input / Output Module;

[0072] 1012. Input devices;

[0073] 1014. Output devices;

[0074] 1016. Presentation device;

[0075] 1018. Graphical User Interface;

[0076] 1020. Network interface;

[0077] 1022. Communication link;

[0078] 1024. Communication bus. Detailed Implementation

[0079] With reference to the drawings of the embodiments of the present specification, the technical solutions in the embodiments of the present specification will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present specification, rather than all the embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those of ordinary skill in the art without creative work are within the scope of protection of the present specification.

[0080] It should be noted that the terms "first", "second" and the like in the present specification and claims and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present specification described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, device, product or apparatus that includes a series of steps or units does not necessarily have to include only those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or apparatuses.

[0081] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties. And the acquisition, storage, use, processing, etc. of data in the technical solutions described in the embodiments of the present application comply with relevant regulations.

[0082] The embodiments of the present specification provide a test system for CAE software. The system builds a unified virtual desktop resource pool, and establishes an upper layer logic capable of intelligently identifying task types, differentially configuring running environments, and performing unified coroutine scheduling, so as to efficiently and stably execute GUI and nogui two test tasks. The test system for CAE software of the present specification is deployed on a computing cluster composed of multiple physical servers. Each physical server is virtualized into multiple independently operable virtual desktops (Virtual Simulation Desktop) through VNC (Virtual Network Computing) technology. These desktops collectively constitute a unified, scalable, and physically homogeneous distributed CAE test resource pool. Figure 1For the schematic diagram of an embodiment of a test system for CAE software in the present specification, the system comprises: a task scheduling unit 110, a virtual desktop management unit 120, an environment configuration unit 130, a node monitoring unit 140, a Redis cache unit 150, and a PostgreSQL database 160.

[0083] The task scheduling unit 110 is configured to receive a CAE test task submitted by a user, and to decompose the task into subtasks according to the characteristics of the task, and assign the subtasks to corresponding scheduling queues; and to distribute the subtasks to appropriate virtual desktops for execution based on the idle state of the virtual desktops; and to track the running state of the task, and synchronize the state to the PostgreSQL database 160, to ensure that the task flow is in order.

[0084] The virtual desktop management unit 120 is configured to manage the full life cycle of the virtual desktop and adapt the running environment, and is responsible for the creation, registration, monitoring, and destruction of the virtual desktop, supports elastic scaling based on system load, and can dynamically increase or decrease the number of virtual desktop instances according to the overall pressure of the scheduling queues.

[0085] Each virtual desktop is bound to an independent coroutine after activation, which acts as a task consumer and can continuously obtain test tasks from multiple scheduling queues of the task scheduling unit, and apply for idle virtual desktops from the virtual desktop management unit, to further promote the execution of the test tasks. After obtaining the test task and the configured virtual desktop, the coroutine will call different executors according to the type of the test task: for GUI test tasks, the coroutine will start the GUI test framework to execute the test script. For non-interface test tasks, the coroutine directly executes the background computing script or command in the command line terminal of the virtual desktop.

[0086] The environment configuration unit 130 is configured to realize the automated and isolated deployment of the CAE solver environment.

[0087] The node monitoring unit 140 is configured to monitor the resource usage of the physical machines and virtual desktops in real time, to avoid resource overload; and to track exceptions during task execution, and feed back to the task scheduling unit 110 in a timely manner, to trigger retry or resource adjustment.

[0088] The Redis cache unit 150 not only serves as a high-performance cache, but also acts as a distributed control coordinator. On the one hand, it can be used to store environment metadata and task metadata, where the environment metadata includes the installed solver path, hash value, and installation state, and can provide fast queries for environment reuse. The task metadata includes the historical execution time of each test task, to provide a basis for decision-making for the scheduling queues. On the other hand, a distributed lock can be assigned to a coroutine when the coroutine issues an environment installation request, to control the concurrent installation of solvers on the same physical machine, to avoid version conflicts.

[0089] The PostgreSQL database 160 is used to store full information of test tasks, such as task ID, submission time, priority, associated solver version, execution result, running state of the test task, and the like, to support task tracing and analysis; and save historical verification results, such as benchmark data, numerical comparison error, and image comparison record, to provide a reference benchmark for subsequent verification.

[0090] In the embodiments of the present specification, the number of virtual desktops can be dynamically increased or decreased according to the overall pressure of the scheduling queue. By periodically monitoring the scheduling queue length, CPU and memory utilization, when it is monitored that the system is in a high load state and there is a resource bottleneck, the user is allowed to manually trigger the expansion operation through the interface or command; the system starts a new VNC desktop on the specified physical machine, and after successful creation, automatically registers the coroutine and is included in the scheduling; the test task can also be safely dynamically added to the new desktop during execution, without affecting the current task flow; after the desktop is executed, it is released, and the related cache and temporary files are cleaned up, and the system resources can be recycled and reused. This mechanism combines task awareness, resource detection and manual control, improves the concurrent adaptability of the system, and meets the real-time dynamics of test tasks.

[0091] Based on the above system, the embodiments of the present specification provide a test method for CAE software, Figure 2 is a step schematic diagram of a test method for CAE software provided by the embodiments of the present specification, the present specification provides the method operation steps as described in the embodiments or flowcharts, but based on conventional or non-creative labor, more or fewer operation steps can be included. The order of the steps listed in the embodiments is only one of the many execution orders of the steps, and does not represent the only execution order. In actual system or device product execution, the method order shown in the embodiments or the drawings can be executed or executed in parallel. Specifically, as shown in Figure 2 The method can include the following steps:

[0092] S201: split a target computer-aided engineering (CAE) test task into a plurality of CAE test subtasks, each of the CAE test subtasks corresponding to a test script;

[0093] S202: determine the task type of each of the CAE test subtasks according to the metadata of each of the test scripts;

[0094] S203: assign the CAE test subtasks to a plurality of virtual desktops, and configure a running environment for each of the virtual desktops according to the task type;

[0095] S204: execute the test script corresponding to each of the CAE test subtasks on each of the virtual desktops after the running environment is configured.

[0096] By splitting the complex test task into subtasks and assigning them to multiple virtual desktops for parallel execution, the technical solution breaks through the limitation of the computing power of a single device, significantly shortens the total test time, and is especially suitable for CAE test requirements in multiple scenarios and multiple parameters. At the same time, according to the type of the task, a dedicated running environment is configured for each virtual desktop, and the isolation feature of the virtual desktop is used to avoid environmental conflicts between different tasks, ensure the accuracy of the test environment, reduce the result deviation caused by environmental interference, and ensure the reliability of the key numerical calculation in the CAE test. The entire process can automatically implement task allocation, environment configuration, and script execution, greatly reducing manual intervention and reducing the risk of errors in testing.

[0097] In the embodiments of the present specification, the target CAE test task refers to a complex test task containing a mixed test mode, covering comprehensive verification of CAE software functions, performance, reliability, etc. The CAE test subtask is a smaller and relatively independent test unit split from the overall CAE test task. These subtasks are components of the overall task and each focuses on a specific function module, scene, or test point of the CAE software, and can be executed individually. Each test subtask corresponds to a test script, which is a set of automated instructions written to execute a specific CAE test subtask. It contains information such as test steps, input parameters, and expected results, and can automatically drive the CAE software to complete the test process of the corresponding subtask, reducing manual operation and improving test efficiency.

[0098] In some embodiments of the present specification, during the splitting process, the task type of each test subtask can be automatically identified by analyzing the metadata of the test script or following the naming specification. The metadata of the test script includes a task type identifier; the task type is determined according to the task type identifier, and the task type includes a GUI test subtask and a non-interface test subtask. The GUI test subtask is a test task that requires graphical user interface support, mainly used for geometry preprocessing, mesh partitioning, solution setting, and result post-processing, which requires complex user interaction. Its script is usually recorded by a GUI test framework (such as squish). The non-interface test subtask is a test task that does not require a graphical interface. Such tasks only need to call the solver core library or command line tool in the background to perform non-interactive operations such as background calculation and data processing of the CAE software. Its script is a set of instructions for calling the background solver core or command line tool. Based on the determined task type, each CAE test subtask is assigned to multiple virtual desktops, wherein the virtual desktops are built on virtual machines, and each virtual desktop has an independent running space. In this way, assigning each independent test subtask to a virtual desktop can avoid environmental conflicts between different tasks, thereby ensuring the stability and reliability of the test.

[0099] To solve the waste problem caused by the "one-size-fits-all" resource allocation, such as starting unnecessary graphic services for non-GUI test, the embodiment of the present specification configures a corresponding running environment for each virtual desktop according to the task type, that is, when the task type is a GUI test subtask, the running environment of the virtual desktop is configured as a graphic environment stack including a window manager, an X server, a GPU driver and a 3D rendering library; when the task type is a non-GUI test subtask, the running environment of the virtual desktop is configured as a computing environment including only a basic command line and necessary computing libraries. In this way, the differential environment configuration of each test subtask according to the task type avoids unnecessary graphic environment overhead for non-GUI test subtasks, greatly reduces the memory and CPU overhead of the test task, so that more test subtasks can be concurrently run on the same physical machine, thereby improving the resource utilization.

[0100] In the embodiment of the present specification, referring to Figure 3 , the CAE test subtasks are allocated to a plurality of virtual desktops, specifically including the following steps:

[0101] S301: According to the historical execution time of each test script, each CAE test subtask is allocated to a corresponding scheduling queue;

[0102] S302: The CAE test subtasks in the scheduling queue are allocated to a plurality of virtual desktops in sequence.

[0103] It can be understood that in the execution process of the historical test task, the historical execution time of each test script is recorded by using Redis-based cache persistence, and when a new test task is performed, each test subtask is allocated to different scheduling queues according to the historical execution time. This mechanism treats GUI test subtasks and non-GUI test subtasks equally, and sorts them according to the historical execution time, ensuring that fast verification tasks (such as unit testing and small model snapshots) in both types can be responded to preferentially, thereby improving the feedback speed of the overall R&D process.

[0104] In the embodiment of the present specification, the scheduling queue includes at least a first scheduling queue and a second scheduling queue, and in other embodiments, the number of scheduling queues can be determined according to the number of tasks and actual needs. Referring to Figure 4 , according to the historical execution time of each test script, each CAE test subtask is allocated to a corresponding scheduling queue, specifically including the following steps:

[0105] S401: The CAE test subtask corresponding to the CAE test script with a historical execution time less than a preset threshold is allocated to the first scheduling queue;

[0106] S402: assign the CAE test sub-tasks corresponding to the CAE test scripts with the historical execution time greater than the preset threshold to a second scheduling queue; the priority of the first scheduling queue is greater than the second scheduling queue.

[0107] In the embodiments of the present specification, with reference to Figure 5 , the CAE test sub-tasks in the scheduling queue are sequentially assigned to a plurality of virtual desktops, specifically including the following steps:

[0108] S501: sequentially obtain CAE test sub-tasks from the first scheduling queue and assign them to idle virtual desktops;

[0109] S502: when all the sub-tasks in the first scheduling queue are assigned, sequentially obtain CAE test sub-tasks from the second scheduling queue and assign them to idle virtual desktops.

[0110] It can be understood that first, the sub-tasks are extracted in the order of the arrangement of the sub-tasks in the first scheduling queue (such as a preset rule of first-in first-out) and assigned to the virtual desktops currently in the idle state, so as to ensure that the tasks of the first scheduling queue have priority to obtain resources and ensure efficient start and execution. After all the sub-tasks in the first scheduling queue are assigned, the sub-tasks in the second scheduling queue are executed. At this time, the sub-tasks are extracted in the order of the arrangement of the sub-tasks in the second scheduling queue and assigned to the virtual desktops currently in the idle state. In this way, by executing the sub-tasks with shorter time consumption first, the priority processing of different scheduling queues is realized, the task allocation is avoided to be chaotic, the resource is ensured to meet the demand of the tasks of the first queue first, and the orderliness of the overall scheduling is improved.

[0111] In the process of executing test tasks, different test tasks may require different versions of solvers, and different versions of solvers may have conflicts in version requirements for dependent libraries (such as compilers, mathematical libraries, etc.). Since the solver runs not only the program itself but also depends on a large number of auxiliary libraries, if the version of any dependent library does not match, it may cause the solver to fail in the test process. In the traditional way, engineers need to manually configure the environment for each version of the solver, which is tedious and may cause different performances of the same version on different machines due to operation differences, affecting the reliability of the test results. In a large-scale or complex CAE test scenario, multiple virtual desktops are often required to execute tasks concurrently. At this time, the traditional environment management method will expose more serious problems: if multiple virtual desktops need the same version of the solver at the same time, they may trigger the installation process respectively, repeatedly occupy disk space, CPU / memory resources, and thus affect the overall test efficiency. Considering the above problems, the embodiments of the present specification eliminate the chaos of manual configuration by standardizing the deployment process, and improve the efficiency and stability of environment preparation in a concurrent test scenario. Specifically, as Figure 6As shown, after configuring a running environment for each virtual desktop, the following steps are taken to configure a solver environment for each test task:

[0112] S601: Generate an isolated environment path for each CAE test subtask according to the name and version number of the target solver;

[0113] S602: Determine whether a corresponding solver environment exists in the environment directory of the physical machine to which the virtual desktop belongs according to the isolated environment path;

[0114] S603: If yes, perform a hash calculation according to the name and version number of the target solver to obtain a hash value of the target solver;

[0115] S604: Determine whether an environment record with the same hash value as the target solver exists in the pre-constructed cache;

[0116] S605: If yes, return a reusable path corresponding to the environment record;

[0117] S606: If no, call a preset installation script to install the target solver under the isolated environment path, and store the isolated environment path in the environment directory of the physical machine to which the virtual desktop belongs after installation is completed.

[0118] It can be understood that when preparing to execute a test task, the coroutine first checks whether the required solver environment already exists in the local physical machine. If yes, the reuse process is directly entered. If no, the installation process is triggered. In the embodiments of the present specification, the metadata of the test script further includes the name and version number of the target solver. According to this information, a unique isolated environment path of the target solver can be generated, and the format is: / apps / <solver_name> / <version>If the path does not exist in the environment directory of the local physical machine, it is determined that the target solver environment is not installed, and the subsequent installation process is entered. If the path exists, it indicates that the local physical machine may have a corresponding environment. To avoid the case where the path exists but the file is damaged or incomplete, the integrity and matching of the environment need to be further verified through the hash value of the target solver. Specifically, the MD5 value of the solver environment installation package under the path and the GitCommit Hash value of the dependent library are calculated according to the name and version number of the target solver, and then compared with the historical hash values recorded in the cache. The MD5 value is a 128-bit unique identifier obtained by hashing the complete binary content of the installation package using the MD5 message digest algorithm, which is used to verify whether the installation package file has been tampered with or damaged. The Git Commit Hash is a unique identifier generated by hashing the information of a single commit of the dependent library in the Git version control system, which is used to precisely locate a specific version of the dependent library and ensure that the content and version of the dependent library match the expected version. If there is an environment record with the same hash value in the cache, it indicates that the environment is complete and the version is matched. If there is no matching record in the cache, it indicates that the environment file may be damaged or the version is not matched, so the environment is determined to be an invalid environment and needs to be reinstalled.

[0119] When a new environment needs to be installed, the coroutine sends a request to the Redis cache unit to try to obtain a distributed lock based on the current physical machine IP and solver name. The key name format of the lock is IP_Address + Solver_Name. The purpose of this lock is to ensure that only one coroutine can execute the installation operation of a specific solver on the same physical machine at the same time, avoiding file conflicts, resource contention, and other problems caused by multiple coroutine installations, and ensuring the stability of the installation process. If the lock is successfully obtained, it indicates that there is no other coroutine currently installing the solver on the current physical machine, and the exclusive installation permission can be obtained. The next step can be entered. If the lock is not obtained, it indicates that another coroutine is currently installing the solver, and the current coroutine will enter a waiting state until the lock is released and the installed environment is directly reused.

[0120] After acquiring the lock, the system queries the Redis cache unit again whether there is an environment record with the same hash value. If there is, it means that during the waiting process, other physical machines or coroutines have installed the matching environment, at which time the installation is directly skipped, the lock is released, and the environment is reused. If there is no matching record in the cache, the automated installation script is executed, and the installation is performed according to the unique isolated environment path. In the embodiments of the present specification, the installation script supports.sh installation package or conda environment in two formats. After the new environment is installed, the key information of the environment, such as the isolated environment path, hash value, installation time, solver name, version number, etc., is written into the Redis cache unit and is associated with the identifier of the physical machine IP + solver name + version number. When subsequent other coroutines request the same solver environment, they can directly reuse the environment after the hash check is confirmed to be matched, without the need to repeat the installation. At the same time, the distributed lock is actively released, allowing other waiting coroutines to detect that the environment already exists and to reuse it. After updating the cache, the virtual desktop corresponding to the current coroutine accesses the newly deployed solver environment through the unique isolated environment path, and simultaneously starts executing the corresponding CAE test subtask. In this way, by constructing a unique isolated environment path, the solver environments of different versions are independent of each other, preventing version conflicts from interfering with the verification results. Through the distributed lock and hash check during installation, repeated installation operations are reduced and conflicts caused by concurrent installation of the same solver on the same physical machine are avoided, greatly improving the efficiency of environment configuration in a concurrent test scenario, while ensuring the stability of the environment when multiple tasks are executed in parallel.

[0121] In some embodiments of the present specification, to ensure the stability and integrity of large-scale, long-time running CAE test tasks, the life cycle state of each virtual desktop is monitored during the execution of the test task, and a recovery mechanism is automatically triggered when an exception occurs. As shown in Figure 7 The method further includes the following steps:

[0122] S701: The virtual desktop state and the CAE test subtask state are monitored according to a preset monitoring period, respectively.

[0123] S702: If the CAE test subtask state is monitored to be abnormal, the CAE test subtask is terminated and reinserted into the tail of the corresponding scheduling queue.

[0124] S703: If the virtual desktop state is monitored to be abnormal, the CAE test subtask being executed by the virtual desktop is reinserted into the tail of the corresponding scheduling queue, and the virtual desktop is restarted.

[0125] It can be understood that in the embodiments of the present specification, the life cycle of a virtual desktop is defined as the following states:

[0126] Unactivated: The node has been registered in the system, but has not been started or initialized.

[0127] Activated: The system has detected that the desktop has successfully started and is online through the VNC protocol, and can accept the coroutine assigned by the dispatcher at any time.

[0128] Idle: The virtual desktop has been bound to a coroutine, but currently has no simulation example execution, and is waiting to pull a new task from the scheduling queue.

[0129] Running: The virtual desktop is currently executing a simulation example.

[0130] Subtask disconnection: The virtual desktop itself communicates normally, but the CAE solver process running on it terminates unexpectedly or is unresponsive.

[0131] Desktop disconnection: Unable to establish a connection with the virtual desktop through the VNC protocol, the virtual desktop is completely unresponsive.

[0132] In the embodiments of the present specification, through the agent program deployed in the virtual desktop, the expected CAE solver application window or process is detected periodically by calling wmctrl or similar command line tools to determine whether it still exists and is active. If the solver process fails to start successfully or exits unexpectedly during calculation within a predetermined time (e.g. 3 minutes), it is determined that the subtask is in a disconnection state. Through the above operation, the solver crash caused by numerical divergence, memory overflow or segment error can be effectively captured. For desktop disconnection detection, the system periodically attempts to establish a connection with each virtual desktop through VNC commands and obtain its status. If the connection times out or is refused, it indicates that the desktop environment may have been stuck or its VNC service has crashed, and the system determines that the virtual desktop is in a disconnection state.

[0133] In the embodiments of the present specification, for subtask disconnection, the automatic recovery mechanism is to immediately terminate all operations of the current coroutine on the virtual desktop, reinsert the failed CAE test subtask into the tail of the scheduling queue it belongs to, and wait for the next round of scheduling. At the same time, the virtual simulation desktop is placed in an idle state so that it can be immediately used to execute other CAE test subtasks. For desktop disconnection, the automatic recovery mechanism is to immediately terminate the coroutine bound to the virtual desktop, and also return the CAE test subtask being executed or about to be executed to the tail of the scheduling queue. At the same time, the system automatically sends instructions to the physical server where the desktop is located to force restart of the corresponding VNC service to rebuild a completely new and clean virtual desktop. After the new desktop is successfully started, it will automatically re-register with the central dispatcher and be marked as activated, and can participate in scheduling again.

[0134] When each test subtask is executed, its test results need to be automatically verified. To break through the limitations of single-dimensional verification in traditional testing, in the embodiments of the present specification, the verification results of the CAE software in the GUI test subtask and the non-interface test subtask are comprehensively checked through automatic, multi-dimensional and differential comparison, so as to ensure the accuracy and stability of the software function. Specifically, according to the verification template associated with the test subtask, the corresponding comparison module is called for verification. The verification template can be understood as a preset comparison rule, such as which indicators to compare, what benchmark data to use, etc., wherein the benchmark data sources are diverse, including the calculation results of recognized commercial benchmark software, the results of stable historical versions that have passed verification, or the data obtained through physical experiments. Since the output forms of the GUI test subtask and the non-interface test subtask are different, the present specification proposes three verification templates to cover the core verification needs of the two modes.

[0135] The first verification template is based on numerical level comparison, which is applicable to both GUI test subtasks and non-interface test subtasks. The verification logic is: automatically parsing the log file or structured data file output by the software, extracting key performance indicators, such as the maximum stress value in structural analysis, the minimum displacement, the pressure peak value in fluid simulation, and other numerical values with clear physical meaning, and then comparing these numerical values with the benchmark data to calculate the absolute error or relative error, thereby verifying the accuracy of the calculation results. The second verification template is based on image level comparison, which is only applicable to GUI test subtasks. The verification logic is: in the post-processing stage of the GUI subtask, the automatic script will intercept key images according to the preset rules (such as fixed viewing angle, rendering parameters, legends), and then perform numerical analysis on these images, such as extracting stress values from stress contour maps, judging whether the color mapping is consistent with the calculation data, and comparing the numerical information of the benchmark image to ensure that the graphical display is consistent with the underlying calculation data, avoiding problems such as correct calculation but incorrect graphical rendering. The third verification template is based on logical level integrity comparison, which is mainly aimed at GUI test subtasks. Because the GUI mode involves user and interface interaction (such as clicking buttons, inputting parameters, switching menus, etc.), the stability of the interaction process directly affects the user experience, and the verification logic is: parsing the execution report generated by the GUI test framework to check whether the entire user operation process is executed completely and whether there are exceptions such as pop-up error pop-up, control not found, operation unresponsive, etc. Through these checks, the stability of the GUI interface as an interactive tool is ensured, and user operation failures caused by interface logic vulnerabilities are avoided.

[0136] The following describes the complete workflow of the embodiments of the present specification in combination with a typical CAE software regression test scenario containing mixed verification modes.

[0137] As Figure 8 As shown in a complex cross-platform desktop application automation testing task, the test team deployed the following environment: 3 physical servers were deployed as a computing cluster, each with a 64-core CPU and 512 GB of memory. 10 virtual desktops were initialized on each physical server through VNC, a total of 30 physically homogeneous computing nodes, each bound to a standby coroutine. In this regression testing task, there are 1000 independent test subtasks, including: 300 GUI test subtasks, which drive the CAE software GUI test from model import to post-processing cloud image display through squish script, and 700 non-interface test subtasks, which directly call the background solver to perform core numerical tests on different algorithm parameters or boundary conditions.

[0138] After the regression test task is submitted to the task scheduling system, the system automatically decomposes it into 1000 test subtasks. Each test subtask is attached with its corresponding CAE solver package name, version number, and historical execution time read from the Redis cache. The scheduler marks 300 of them as "GUI-Test" and the remaining 700 as "nogui-Test" (non-interface test) by parsing the metadata of their corresponding test scripts. Then according to the historical execution time of each subtask, set a lower priority for the subtasks with longer execution time, i.e. exceeding the preset threshold, and a higher priority for the subtasks with shorter execution time, and distribute all 1000 subtasks to the corresponding scheduling queue cache, ready to be pulled by the coroutine. The 30 coroutines in the system request tasks from the scheduling queue. When a coroutine gets a "GUI-Test" task, the virtual desktop it is bound to will be configured by the desktop manager to load the complete graphics environment stack mode. When a coroutine gets a "nogui-Test" task, its desktop is configured as a minimal computing environment without graphics services. The desktop bound to the coroutine first checks whether the corresponding solver environment exists in the local physical machine's environment directory according to the task's solver name and version number after receiving the test task. If it does not exist, the coroutine tries to acquire the distributed installation lock of the solver on the current physical machine, successfully acquires it, and performs automated environment installation. After installation is complete, the lock is released, and information such as the hash value of the new environment is recorded to the Redis cache for subsequent coroutine reuse. After the solver environment is prepared, the coroutine calls the test script and starts the CAE solver for computation. For GUI, the coroutine calls the squish framework to execute the full-process automation script, and for nogui job, the coroutine directly executes the background computation script in the command line. The running status of all test subtasks (start, in progress, complete, mode type, etc.) is transmitted to the PostgreSQL database in real time.

[0139] In the test process, in order to ensure the stability of the system and the integrity of the task, the node monitoring unit is continuously running, responsible for identifying the disconnection of subtasks and abnormal state of the desktop, and when the test subtask state and the virtual desktop state are monitored to be abnormal, the corresponding automatic recovery mechanism is enabled for processing. After each virtual desktop completes a test task, the coroutine bound to it will immediately trigger the resource cleaning and release logic, including: deleting the temporary files, solver logs and other intermediate data generated by the desktop; stopping the occupied system resources, such as terminating the solver process; notifying the scheduler to update the coroutine state to "idle" so that it can immediately participate in the next round of task allocation; when the overall verification load decreases, part of the desktop can be stopped by manual or strategic instructions to completely release the physical machine memory / CPU resources. Through this efficient resource use and recycling strategy, the waste of system resources caused by the suspension of resources after the completion of the task is avoided.

[0140] Through the above test process, all 1000 test subtasks are executed in parallel under the support of 30 coroutines, and the efficiency is greatly improved compared with the traditional serial mode. All verification results (including state, log, execution time, etc.) are written into the PostgreSQL database in real time. After the test task is completed, the system automatically aggregates the running results of all test tasks to generate a standardized test report for regression analysis and defect positioning by the development or test engineer. Through the embodiment, the complex mixed verification task that needs to be executed separately and manually compared is integrated into a fully automatic and high-concurrency process, which greatly improves the verification efficiency and depth, and at the same time, the system test success rate is significantly improved, and excellent performance and stability are exhibited in the scene of high concurrency of tasks, complex environment and limited system resources.

[0141] Based on the test method for CAE software described above, the embodiment of the present specification also provides a test device for CAE software. The device can include a system (including a distributed system), software (application), module, component, server, client, etc. using the method described in the embodiment of the present specification, and a device combined with necessary implementation hardware. Based on the same innovative concept, the device in one or more embodiments provided by the embodiment of the present specification is as described in the following embodiments. Since the implementation scheme of the device to solve the problem is similar to the method, the implementation of the specific device of the embodiment of the present specification can be referred to the implementation of the foregoing method, and the repeated parts will not be described herein. The term "unit" or "module" used below can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware or a combination of software and hardware is also possible and is conceived.

[0142] Specifically, Figure 9 is a schematic diagram of a module structure of one embodiment of a test device for CAE software provided by an embodiment of the present specification, referring to Figure 9 A test device for CAE software provided by an embodiment of the present specification includes:

[0143] A splitting module 901 is configured to split a target computer-aided engineering (CAE) test task into a plurality of CAE test sub-tasks, each of the CAE test sub-tasks corresponding to a test script.

[0144] A determining module 902 is configured to determine a task type of each of the CAE test sub-tasks according to metadata of each of the test scripts.

[0145] An allocating and configuring module 903 is configured to allocate the CAE test sub-tasks to a plurality of virtual desktops, and configure a running environment for each of the virtual desktops according to the task type.

[0146] A testing module 904 is configured to execute the test script corresponding to each of the CAE test sub-tasks on each of the virtual desktops after the running environment is configured.

[0147] The beneficial effects achieved by the device provided by the embodiments of the present specification are consistent with the beneficial effects achieved by the above method, which will not be repeated here.

[0148] Referring to Figure 10 Based on the above-mentioned test method for CAE software, an embodiment of the present specification further provides a computer device 1002, wherein the above-mentioned method runs on the computer device 1002. The computer device 1002 can include one or more processors 1004, such as one or more central processing units (CPUs), each of which can implement one or more hardware threads. The computer device 1002 can also include any memory 1006 for storing any kind of information, such as code, settings, data, etc. Without limitation, for example, the memory 1006 can include any one or a combination of more than one of the following: any type of RAM, any type of ROM, a flash memory device, a hard disk, an optical disk, etc. More generally, any memory can store information using any technology. Further, any memory can provide volatile or non-volatile retention of information. Further, any memory can represent a fixed or removable component of the computer device 1002. In one case, the computer device 1002 can perform any operation of the associated instructions when the processor 1004 executes the associated instructions stored in any memory or combination of memories. The computer device 1002 also includes one or more drive mechanisms 1008 for interacting with any memory, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.

[0149] The computer device 1002 can also include an input / output module 1010 (I / O) for receiving input (via input device 1012) and for providing output (via output device 1014). One specific output mechanism can include a presentation device 1016 and associated graphical user interface (GUI) 1018. In other embodiments, the input / output module 1010 (I / O), the input device 1012, and the output device 1014 can not be included, and the computer device 1002 can be a standalone computer device in a networked environment.

[0150] The communication links 1022 can be implemented in any manner, such as through a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication links 1022 can include any combination of hardwired links, wireless links, routers, gateway functionality, name servers, etc., governed by any protocol or combination of protocols.

[0151] Corresponding to the method as shown in Figures 2 to 8 The computer program stored in the computer readable storage medium is run by the processor to execute the steps of the method.

[0152] The computer readable instructions are executed by the processor, and the program in the computer readable instructions causes the processor to execute the method as shown in Figures 2 to 8 .

[0153] The computer program product includes at least one instruction or at least one program, which is loaded and executed by the processor to implement the method as shown in Figures 2 to 8 .

[0154] It should be understood that the size of the sequence number of each process described above in various embodiments of the present specification does not mean the order of execution, and the execution order of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present specification.

[0155] It should also be understood that in the embodiments of the present specification, the term "and / or" is only a description of the association relationship of the associated objects, which means that there can be three relationships. For example, A and / or B can represent three cases of A alone, A and B together, and B alone. In addition, the character " / " in the present specification generally represents a "or" relationship between the front and rear associated objects.

[0156] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this specification.

[0157] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0158] In the several embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0159] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments described in this specification, depending on actual needs.

[0160] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0161] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the specification or the entire or part of the technical solutions that essentially contribute to the prior art can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the specification. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0162] The principles and implementation manners of the specification are described by using specific embodiments in the specification. The above embodiment description is only used to help understand the method and its core idea of the specification; meanwhile, for those skilled in the art, according to the idea of the specification, the specific implementation manners and application ranges will have changes. In summary, the content of the specification should not be understood as a limitation of the specification.< / version>

Claims

1. A test method for CAE software, characterized by, The method comprises: splitting a target computer aided engineering (CAE) test task into a plurality of CAE test subtasks, each of the CAE test subtasks corresponding to a test script; determining a task type of each of the CAE test subtasks according to metadata of each of the test scripts, the metadata of the test script comprising a name and a version number of a target solver; allocating the CAE test subtasks to a plurality of virtual desktops and configuring a running environment for each of the virtual desktops according to the task type; respectively executing the test script corresponding to each of the CAE test subtasks on each of the virtual desktops after the running environment is configured; wherein after the running environment is configured for each of the virtual desktops, the method further comprises: generating an isolated environment path of each of the CAE test subtasks according to the name and the version number of the target solver; judging whether a corresponding solver environment exists in an environment directory of a physical machine to which the virtual desktop belongs according to the isolated environment path; if yes, performing hash calculation according to the name and the version number of the target solver to obtain a hash value of the target solver; judging whether an environment record with the same hash value as the target solver exists in a pre-constructed cache; if yes, returning a reusable path corresponding to the environment record; if no, calling a preset installation script to install the target solver under the isolated environment path, and storing the isolated environment path into the environment directory of the physical machine to which the virtual desktop belongs after the installation is completed.

2. The method of claim 1, wherein, The metadata of the test script comprises a task type identifier, and the task type is determined according to the task type identifier, wherein the task type comprises a GUI test subtask and a non-interface test subtask.

3. The method of claim 1, wherein, The allocation of the CAE test subtasks to the plurality of virtual desktops comprises: allocating each of the CAE test subtasks to a corresponding scheduling queue according to a historical execution time consumption of each of the test scripts; allocating the CAE test subtasks in the scheduling queue to the plurality of virtual desktops in sequence.

4. The method of claim 3, wherein, The scheduling queue comprises at least a first scheduling queue and a second scheduling queue, and the allocation of each of the CAE test subtasks to a corresponding scheduling queue according to a historical execution time consumption of each of the test scripts comprises: allocating the CAE test subtask corresponding to the CAE test script with a historical execution time consumption less than a preset threshold to the first scheduling queue; allocating the CAE test subtask corresponding to the CAE test script with a historical execution time consumption greater than the preset threshold to the second scheduling queue, wherein the first scheduling queue has a higher priority than the second scheduling queue.

5. The method of claim 4, wherein, The allocation of the CAE test subtasks in the scheduling queue to the plurality of virtual desktops comprises: sequentially obtaining the CAE test subtasks from the first scheduling queue and allocating the CAE test subtasks to idle virtual desktops; when the CAE test subtasks in the first scheduling queue are all allocated, sequentially obtaining the CAE test subtasks from the second scheduling queue and allocating the CAE test subtasks to idle virtual desktops.

6. The method of claim 2, wherein, The configuration of the running environment for each of the virtual desktops according to the task type comprises: if the task type is a GUI test subtask, configuring a running environment of the virtual desktop as a graphic environment stack including a window manager, an X server, a GPU driver and a 3D rendering library; if the task type is a non-interface test subtask, configuring a running environment of the virtual desktop as a computing environment including a basic command line and a computing library.

7. The method of claim 1, wherein, The method further comprises: monitoring the virtual desktop state and the CAE test subtask state respectively according to a preset monitoring period; if the CAE test subtask state is monitored as abnormal, terminating the CAE test subtask and reinserting it into a tail of a corresponding scheduling queue; if the virtual desktop state is monitored as abnormal, reinserting a CAE test subtask being executed by the virtual desktop into a tail of a corresponding scheduling queue and restarting the virtual desktop.

8. A test device for CAE software, characterized by, The apparatus comprises: a splitting module configured to split a target computer aided engineering (CAE) test task into a plurality of CAE test subtasks, each of the CAE test subtasks corresponding to a test script; a determining module configured to determine a task type of each of the CAE test subtasks according to metadata of each of the test scripts, the metadata of the test script including a name and a version number of a target solver; an allocating and configuring module configured to allocate the CAE test subtasks to a plurality of virtual desktops and configure a running environment for each of the virtual desktops according to the task type; a testing module configured to execute each of the test scripts corresponding to each of the CAE test subtasks on each of the virtual desktops after the running environment is configured; wherein after the running environment is configured for each of the virtual desktops, the method further comprises: generating an isolated environment path of each of the CAE test subtasks according to the name and the version number of the target solver; judging whether a corresponding solver environment exists in an environment directory of a physical machine to which the virtual desktop belongs according to the isolated environment path; if yes, performing a hash calculation according to the name and the version number of the target solver to obtain a hash value of the target solver; judging whether an environment record with the same hash value as the target solver exists in a pre-constructed cache; if yes, returning a reusable path corresponding to the environment record; if no, installing the target solver in the isolated environment path by invoking a preset installation script and storing the isolated environment path in the environment directory of the physical machine to which the virtual desktop belongs after the installation is completed.

9. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the method of any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, which, when executed by a processor, implements the method of any one of claims 1 to 7.

11. A computer program product, characterised in that, The computer readable storage medium stores a computer program, which, when executed by a processor, implements the method of any one of claims 1 to 7. The computer readable storage medium stores a computer program, which, when executed by a processor, implements the method of any one of claims 1 to 7.

Images