Linux system automatic testing method and system based on Excel

Abstract

The invention discloses a Linux system automatic test method and system based on Excel. The method comprises the steps that test requirements are collected and converted into test case parameters, and an Excel table is generated; triggering an assembly line tool through an Excel table; the Linux system is automatically installed through an assembly line tool, the Excel table is automatically analyzed after the Linux system is installed, automatic testing is automatically executed according to test case parameters in the Excel table, and a test result is collected; the collected test results are backfilled to an Excel table; and informing a tester of the Excel table. The invention aims to solve the problems of low test requirement and case conversion efficiency, unstable quality, large workload and high labor cost of automatic test programming, tedious and error-prone test environment establishment and management, and difficulty in forming a closed loop due to splitting of each link of the existing test.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology for Linux systems, and specifically to an automated testing method and system for Linux systems based on Excel. Background Technology

[0002] With the continuous expansion of software development scale and the increase in complexity, traditional manual testing methods are inefficient and prone to errors when faced with a huge testing workload, making it difficult to meet the needs of rapid iteration and efficient development. In order to improve testing efficiency, automated testing methods have emerged. By using testing tools and scripts, user operations can be simulated to achieve automated testing of software systems. However, existing automated testing methods still have many bottlenecks that need to be addressed in practice. The existing technologies mainly have the following defects: (1) The test preparation stage is highly dependent on manual labor, the process is lengthy and information transmission is prone to distortion: In the traditional process, from the front-end technical support personnel collecting requirements, to the product manager writing the test requirements specification, to the testers manually designing and writing specific test cases based on their own understanding, the entire early preparation stage relies heavily on personal experience and manual operation. This process is not only time-consuming, but also prone to misunderstanding and errors in multiple manual transmissions, resulting in test cases that do not match the original requirements, ultimately making it difficult to guarantee test coverage and effectiveness, and unable to support an efficient agile development pace. (2) High technical threshold for automation implementation and heavy burden of script development and maintenance: Existing automated testing solutions require testers to have considerable programming skills, and the design of test cases and the writing of test programs are almost entirely completed by manual coding. This not only requires a large investment of professional manpower, resulting in high testing costs, but also the test scripts generated are often unreusable and tightly coupled with business logic. When functions change, maintaining and updating these scripts will bring a huge workload, and the test quality and stability are difficult to guarantee systematically. (3) Insufficient automation of test environment management restricts overall testing efficiency: Especially when conducting automated testing on server environments such as Linux systems, the setup, configuration and management of the test environment still require a lot of manual preparation and intervention. For example, the steps of installing the operating system, configuring the network, and deploying the dependency libraries are not only time-consuming and labor-intensive, but also difficult to ensure the consistency of the environment. It is easy to cause test failure due to configuration errors, which has become a prominent shortcoming that hinders the realization of full automation and efficient management of the test process. (4) The testing processes are fragmented, making it difficult to form an efficient automated closed loop: In existing technologies, key processes such as test requirement analysis, test case writing, environment preparation, script execution, and result analysis are usually handled by different tools or manually coordinated by personnel in different roles. This fragmentation leads to poor information flow, forming "information silos" and making it impossible to build an end-to-end automated pipeline from requirement input to result feedback. The manual handover and data conversion between each process not only create efficiency bottlenecks but also increase the probability of errors, making it difficult for the testing process to achieve true continuity, traceability, and self-optimization capabilities. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide an automated testing method and system for Linux systems based on Excel, addressing the aforementioned problems in the prior art. This invention aims to solve the problems of low efficiency and unstable quality in the conversion of test requirements and test cases, large workload and high labor costs in automated testing programming, cumbersome and error-prone test environment setup and management, and the fragmented nature of existing testing processes, making it difficult to form a closed loop.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: An automated testing method for Linux systems based on Excel includes the following steps: S101 is used to collect test requirements for automated testing tasks on Linux systems. S102, convert the collected test requirements into test case parameters and generate an Excel spreadsheet; S103 is a pipeline tool that triggers automated testing of Linux systems based on an Excel spreadsheet submitted by the tester. S104 automatically installs the Linux system using a pipeline tool. After the Linux system is installed, it automatically parses the Excel spreadsheet, executes automated tests based on the test case parameters in the Excel spreadsheet, and collects the test results. S105, populate the collected test results back into an Excel spreadsheet; S106, notify the testers of the completed Excel spreadsheet.

[0005] Optionally, in step S102, when converting the collected test requirements into test case parameters and generating an Excel spreadsheet, the Excel spreadsheet defines test cases row by row. Each row stores some or all of the following fields for the test case parameters: parameter number, functional module number, functional module name, submodule number, submodule name, whether the submodule is required, manual, mount CD / DVD, fixed verification, partition name, partition size, default file system format, storage directory path, supported file system formats, and uninstallation package name. The parameter number is the test case parameter number; the functional module number and functional module name are attributes of the functional module to be tested in the test case; the submodule number, submodule name, and whether the submodule is required are attributes of the submodule to be tested in the test case; manual indicates whether additional manual operation testing is required; mount CD / DVD, partition name, partition size, default file system format, storage directory path, and supported file system formats are file system-related attributes; fixed verification is the test method executed by the test case; and the uninstallation package name is the name of the software package to be uninstalled by the test case.

[0006] Optionally, step S103 includes: obtaining the pipeline tool selected and submitted by the tester in the web interface of the pipeline tool, the bare metal server to be used, the storage address of the Linux system image file, the webhook address of the communication tool, and an Excel spreadsheet, triggering the pipeline tool for automated testing of the Linux system, wherein the webhook address of the communication tool is used to notify the tester of the specified message.

[0007] Optionally, step S106 includes using a webhook address based on a communication tool to notify the testers of the populated Excel spreadsheet.

[0008] Optionally, step S104 includes: S201. Determine whether the tester selected to automatically install the Linux system when submitting the Excel spreadsheet. If the tester selected to automatically install the Linux system, call the automatic installation server to perform an automatic system installation job on the bare metal server to be used for the specified Linux system version to complete the installation and configuration of the target Linux system. Otherwise, determine the target Linux system based on the IP, username, password and connection port information of the manually installed Linux system filled in by the tester when submitting the Excel spreadsheet. S202: After waiting for a specified time, determine whether the connection to the target Linux system can be established. If the connection fails, notify the tester of the connection failure message, end the process, and exit. Otherwise, proceed to step S203. S203: Based on the test case parameters, the code of the corresponding test case is sent to the target Linux system, the dependent environment required by the test case is obtained, and the deployment of the dependent environment is completed. S204: Obtain the test method selected by the tester in the Web interface of the pipeline tool. If the tester selects the test method as table verification and submits an Excel spreadsheet, proceed to step S205. S205, Obtain the Excel spreadsheet, modify the configuration parameters in the table verification test suite according to the test case parameters in the Excel spreadsheet, and interpret the extracted verification data from the Excel spreadsheet; S206, Execute the table verification test suite to test the Linux system; S207, Collect logs from the execution of the table validation test suite as test results.

[0009] Optionally, when obtaining the test method selected by the tester in the web interface of the pipeline tool in step S204, the process also includes jumping to step S301 if the test method selected by the tester is smoke testing: S301, Obtain the specified smoke test set, which includes basic functional test cases required for Linux system testing, to verify whether the Linux system has basic operability; S302, Modify the configuration parameters of the smoke test suite based on the parameters entered by the tester in the web interface of the pipeline tool; S303 executes the smoke test suite to test the Linux system; S304, collect the logs from the execution of the smoke test suite as the test results.

[0010] Optionally, when filling the collected test results back into the Excel spreadsheet in step S105, the collected test results include: test passed (TPASS), test passed but manual test (TPASS_HAND), test failed and manual test (TFAIL_HAND), test failed (TFAIL), and parameter data is empty (NULLDATA). The parameter data being empty (NULLDATA) is the test result collected when the test exits due to incomplete test case parameters.

[0011] The present invention also provides an Excel-based automated testing system for Linux systems, comprising a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the Excel-based automated testing method for Linux systems.

[0012] The present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the Excel-based Linux system automated testing method by a processor.

[0013] The present invention also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the Excel-based Linux system automated testing method via a processor.

[0014] Compared with the prior art, the present invention can mainly achieve the following beneficial effects: (1) The present invention can solve the problems of low efficiency and unstable quality in the conversion of test requirements and test cases: In view of the problems of long time consumption, easy error and reliance on personal experience caused by the traditional process that requires front-end technical support personnel to collect requirements, product managers to write test requirement specifications, and testers to manually write test cases based on these specifications, the present invention can manually convert test requirements described in natural language into structured Excel tables, and then automatically convert Excel tables into executable test cases, thereby significantly improving the efficiency and quality of pre-test preparation. (2) The present invention can solve the problems of large workload and high labor cost in automated test programming: In view of the problem that existing automated test methods require testers to invest a lot of energy in script programming and test program design, the present invention provides general functions, lowers the technical threshold, enables non-developers to quickly create automated tests, reduces reliance on professional programming skills, and saves human and material costs. (3) This invention can solve the problems of cumbersome and error-prone test environment setup and management: In Linux system automated testing, the preparation, configuration and management of the test environment still require a lot of manual intervention, resulting in low efficiency and poor consistency. This invention can realize the automated installation, deployment and configuration of the test environment, provide one-click environment preparation capability, ensure the standardization and reusability of the test environment, and improve the overall efficiency and reliability of the testing process. (4) This invention can solve the problem of fragmented testing links and difficulty in forming a closed loop: This invention can build an integrated automated testing method that seamlessly connects multiple links such as test requirement analysis, test case generation, test environment management, test execution and result analysis, forming a complete automated testing pipeline, fundamentally overcoming the efficiency bottleneck and quality risk brought about by traditional segmented and manual information transmission. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0016] Figure 2 This is a schematic diagram of a multi-role automation process in an embodiment of the present invention.

[0017] Figure 3 This is a schematic diagram of the workflow of the pipeline tool in an embodiment of the present invention. Detailed Implementation

[0018] This invention, an Excel-based automated testing method for Linux systems, aims to trigger automated testing by filling in and uploading an Excel spreadsheet to a CI / CD pipeline. This achieves full automation of the entire process: automatic Linux system installation, automatic parsing of the Excel spreadsheet, automatic execution of automated tests, automatic collection of test results back into the Excel spreadsheet, and notification of testers. To enable those skilled in the art to better understand the technical solution of this invention, the following will provide a more detailed description of the technical solution in conjunction with the accompanying drawings of the embodiments of this invention.

[0019] like Figure 1 As shown, the automated testing method for Linux systems based on Excel in this embodiment includes the following steps: S101 is used to collect test requirements for automated testing tasks on Linux systems. S102, convert the collected test requirements into test case parameters and generate an Excel spreadsheet; S103 is a pipeline tool that triggers automated testing of Linux systems based on an Excel spreadsheet submitted by the tester. S104 automatically installs the Linux system using a pipeline tool. After the Linux system is installed, it automatically parses the Excel spreadsheet, executes automated tests based on the test case parameters in the Excel spreadsheet, and collects the test results. S105, populate the collected test results back into an Excel spreadsheet; S106, notify the testers of the completed Excel spreadsheet.

[0020] As an optional implementation method, such as Figure 2 As shown, the method of this embodiment can be used to implement testing in actual application through the cooperation of roles. The roles involved include: technical support / pre-sales, product manager, R&D and testing. The cooperation methods include: (1) technical support / pre-sales collects requirements and outputs a requirement excel table; (2) product manager organizes / analyzes requirements and submits a requirement specification; (3) R&D develops the system version of the Linux system and develops self-testing; (4) testing generates test cases and their test case parameters based on the requirement specification. The test cases include smoke test suite and table verification test suite, and the test cases are output and automated testing is performed using pipeline tools.

[0021] In step S102 of this embodiment, when the collected test requirements are converted into test case parameters and an Excel spreadsheet is generated, the Excel spreadsheet defines test cases row by row. Each row stores the following fields for the test case parameters: parameter number, functional module number, functional module name, submodule number, submodule name, whether the submodule is required, manual, mount CD / DVD, fixed verification, partition name, partition size, default file system format, storage directory path, supported file system formats, and uninstallation package name. The parameter number is the number of the test case parameter, which can be numbered as needed. For example, in this embodiment, three test cases are included, numbered M10.R01, M10.R02, and M10.R03. The functional module number and functional module name are attributes of the functional modules that the test cases need to test, such as a certain functional module... The functional module number and name of the block are "M10" and "File System and Storage" respectively. The submodule number, submodule name, and whether the submodule is required are the attributes of the submodule that the test case needs to test. For example, under "File System and Storage", there are three submodules with the names "System Partition", "File System", and "Multi-path Software" respectively, and the corresponding submodule numbers are R01, R02 and R03 respectively. Among them, "System Partition" is required, while "File System" and "Multi-path Software" are optional. "Manual" indicates whether additional manual operation tests are required. Mounting CD, partition name, partition size, default file system format, storage directory path and supported file system formats are file system related attributes. Fixed verification is the test method executed by the test case. The uninstallation package name is the name of the software package that the test case needs to uninstall. The fields for file system related attributes, fixed verification, and uninstallation package name are all optional parameters. For example, under the submodule name "System Partition", the partition name, partition size, default file system format, and storage directory path are [ / , / KSData], [100G, Remaining space on system disk], [ext4,ext4], and [ / KSData / var, / KSData / home], respectively, with the remaining fields empty. Under the submodule name "File System", the supported file system formats are [exfat,ntfs], with the remaining fields empty. Under the submodule name "Multi-path Software", all fields are empty, used to simulate the situation where test case parameters are insufficient.

[0022] Step S103 of this embodiment includes: obtaining the pipeline tool, the bare metal server to be used, the storage address of the Linux system image file, the webhook address of the communication tool, and an Excel spreadsheet selected and submitted by the tester in the web interface of the pipeline tool; triggering the pipeline tool for automated testing of the Linux system; the webhook address of the communication tool is used to notify the tester of a specified message. Users can log in to the web interface of the CI / CD pipeline tool, select the corresponding pipeline, select the bare metal server to be used, fill in the storage address of the ISO and the webhook address of the enterprise collaboration tool, upload the completed Excel spreadsheet, and click "Build" to trigger the pipeline tool. Step S106 of this embodiment includes notifying the tester of the completed Excel spreadsheet based on the webhook address of the communication tool.

[0023] like Figure 3 As shown, step S104 in this embodiment includes: S201: Determine whether the tester selected automatic Linux system installation when submitting the Excel spreadsheet. If so, invoke the automatic installation server to perform an automatic system installation job on the bare metal server using the specified Linux system version to complete the installation and configuration of the target Linux system. Otherwise, determine the target Linux system based on the IP address, username, password, and connection port information of the manually installed Linux system filled in by the tester when submitting the Excel spreadsheet. Specifically, the automatic installation server automatically installs the specified Linux system on the target server according to the preset Kickstart file, and automatically restarts after installation. Manual installation requires manual installation. S202: After waiting for a specified time, determine whether the connection to the target Linux system can be established. If the connection fails, notify the tester of the connection failure message, end the process, and exit. Otherwise, proceed to step S203. S203: Based on the test case parameters, the code of the corresponding test case is sent to the target Linux system, the dependent environment required by the test case is obtained, and the deployment of the dependent environment is completed. S204: Obtain the test method selected by the tester in the Web interface of the pipeline tool. If the tester selects the test method as table verification and submits an Excel spreadsheet, proceed to step S205. S205, Obtain the Excel spreadsheet, modify the configuration parameters in the table verification test suite according to the test case parameters in the Excel spreadsheet, and interpret and extract the verification data from the Excel spreadsheet; In this embodiment, specifically, each test case (row) in the Excel spreadsheet is converted into a parameter Txt file named after the corresponding submodule name, and the test case parameters are dynamically passed to the test script in the table verification test suite by traversing the parameter Txt file. S206, Execute the table verification test suite to test the Linux system; S207, Collect logs from the execution of the table validation test suite as test results.

[0024] like Figure 3 As shown, in step S204 of this embodiment, when obtaining the test method selected by the tester in the Web interface of the pipeline tool, the process further includes, if the test method selected by the tester is smoke testing, then proceeding to step S301: S301, Obtain the specified smoke test set, which includes basic functional test cases required for Linux system testing, to verify whether the Linux system has basic operability; S302, Modify the configuration parameters of the smoke test suite based on the parameters entered by the tester in the web interface of the pipeline tool; S303 executes the smoke test suite to test the Linux system; S304, collect the logs from the execution of the smoke test suite as the test results.

[0025] In step S105 of this embodiment, when the collected test results are backfilled into the Excel spreadsheet, the collected test results include: test passed (TPASS), test passed but with manual testing (TPASS_HAND), test failed and with manual testing (TFAIL_HAND), test failed (TFAIL), and parameter data is empty (NULLDATA). The empty parameter data (NULLDATA) is the test result collected when the test exits due to incomplete test case parameters. For example, in this embodiment, the test results for the three test cases numbered M10.R01, M10.R02, and M10.R03 are: test passed (TPASS), test failed (TFAIL), and empty (NULLDATA) (because the test case parameters in test case numbered M10.R03 are insufficient). Specifically, these results are backfilled into the last column of the corresponding row in the Excel spreadsheet.

[0026] In summary, the Linux system automated testing method based on Excel in this embodiment includes the following technical mechanisms: 1) Automatic conversion and execution mechanism from test requirements to scripts based on Excel templates: By automatically converting structured Excel test requirements directly into executable test scripts, a seamless automated pipeline from "requirement definition" to "automatic execution" is established, eliminating the manual coding and secondary transcription steps in the traditional process. 2) Excel template-driven test definition and management mode: The traditional "code as test case" mode is innovated into the "data table as test case" mode, and the carrier of test cases changes from program scripts to structured Excel tables. 3) End-to-end automated test pipeline with deep integration and orchestration of multiple toolchains: Multiple independent subsystems such as Excel template management, automated test environment deployment system (automatic installation), CI / CD integration interface, automatic execution of test scripts, result backfilling module, and instant messaging notification service are deeply integrated. 4) A closed-loop mechanism for automatically backfilling test results to the source Excel file: This innovative approach combines the test execution system with Excel file editing functionality, enabling "in-situ" updates of test results to the original input file. This forms a complete and traceable data loop from "test case input" to "result output," achieving the following technical effects: 1) Achieving an intelligent parsing and automated execution loop for test requirements: By automatically converting test requirements from Excel spreadsheets into executable test scripts, the manual intervention required from requirement understanding to test case writing and test execution is significantly reduced. This not only significantly shortens the testing cycle but also fundamentally avoids errors caused by human error transmission and misunderstanding, achieving a qualitative leap in testing efficiency. 2) Achieving a high degree of decoupling between test cases and the testing environment through parameterized and templated design: This invention innovatively abstracts and centrally manages the variable parameters in test cases within a structured Excel spreadsheet. When the testing environment changes, only the parameter configuration in the Excel spreadsheet needs to be modified, without affecting the core logic code of the test cases. This design greatly improves the portability, reusability, and maintainability of test cases in different testing environments, significantly reducing the overall maintenance cost of the test suite. 3) Adopting a modular approach greatly simplifies test case writing and maintenance: By using Excel sub-sheets to manage different test modules, testers only need to fill in business logic data in the spreadsheets, without needing to focus on the underlying source code or write complex test scripts. This elevates test case writing from the code level to the business logic level, significantly reducing the technical threshold and code complexity, thereby comprehensively improving the work efficiency of the testing team. 4) Enables real-time monitoring of the testing process and intelligent feedback of test results: The system has automatic collection, analysis, and backfilling functions for test results, and can proactively and in real-time push test results to relevant personnel through integration with instant messaging tools.This provides intuitive, comprehensive, and timely test status feedback, facilitating rapid problem identification and version quality assessment by the team. It effectively improves the transparency and responsiveness of the testing process, thereby ensuring the final test quality. 5) It constructs an end-to-end automated testing system: This invention organically integrates multiple previously isolated processes, such as test requirement processing, test case generation, test environment configuration, test script execution, and test result collection, into a seamless automated pipeline. This system minimizes the uncertainty and randomness of human intervention, ensuring high accuracy and consistency in every test process, providing a reliable guarantee for rapid software iteration and high-quality delivery.

[0027] This embodiment also provides an Excel-based automated testing system for Linux systems, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute the Excel-based automated testing method for Linux systems. This embodiment also provides a computer-readable storage medium storing a computer program or instructions programmed or configured to execute the Excel-based automated testing method for Linux systems via a processor. This embodiment also provides a computer program product, including a computer program or instructions programmed or configured to execute the Excel-based automated testing method for Linux systems via a processor.

[0028] Those skilled in the art will understand that the technical solutions provided by this invention may take the form of a method, system, or computer program product. Therefore, this invention may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this invention may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce an implementation of the flowchart... Figure 1 One or more processes and / or boxes Figure 1The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0029] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. An automated testing method for Linux systems based on Excel, characterized in that, Includes the following steps: S101 is used to collect test requirements for automated testing tasks on Linux systems. S102, convert the collected test requirements into test case parameters and generate an Excel spreadsheet; S103 is a pipeline tool that triggers automated testing of Linux systems based on an Excel spreadsheet submitted by the tester. S104 automatically installs the Linux system using a pipeline tool. After the Linux system is installed, it automatically parses the Excel spreadsheet, executes automated tests based on the test case parameters in the Excel spreadsheet, and collects the test results. S105, populate the collected test results back into an Excel spreadsheet; S106, notify the testers of the completed Excel spreadsheet.

2. The automated testing method for Linux systems based on Excel according to claim 1, characterized in that, In step S102, when the collected test requirements are converted into test case parameters and an Excel spreadsheet is generated, the Excel spreadsheet defines test cases row by row. The fields of the test case parameters stored in each row include parameter number, functional module number, functional module name, submodule number, submodule name, whether the submodule is required, manual, mount CD-ROM, fixed verification, partition name, partition size, default file system format, storage directory path, supported file system formats, and some or all of the following: parameter number is the number of the test case parameter, functional module number and functional module name are the attributes of the functional module to be tested by the test case, submodule number, submodule name, and whether the submodule is required are the attributes of the submodule to be tested by the test case, manual indicates whether additional manual operation test is required, mount CD-ROM, partition name, partition size, default file system format, storage directory path, and supported file system formats are file system related attributes, fixed verification is the test method executed by the test case, and the uninstallation package name is the name of the software package to be uninstalled by the test case.

3. The automated testing method for Linux systems based on Excel according to claim 1, characterized in that, Step S103 includes: obtaining the pipeline tool selected and submitted by the tester in the pipeline tool's web interface, the bare metal server to be used, the Linux system image file storage address, the webhook address of the communication tool, and an Excel spreadsheet; triggering the pipeline tool for automated testing of the Linux system; the webhook address of the communication tool is used to notify the tester of the specified message.

4. The automated testing method for Linux systems based on Excel according to claim 3, characterized in that, Step S106 includes using the webhook address of the communication tool to notify the testers of the updated Excel spreadsheet.

5. The automated testing method for Linux systems based on Excel according to claim 2, characterized in that, Step S104 includes: S201. Determine whether the tester selected to automatically install the Linux system when submitting the Excel spreadsheet. If the tester selected to automatically install the Linux system, call the automatic installation server to perform an automatic system installation job on the bare metal server to be used for the specified Linux system version to complete the installation and configuration of the target Linux system. Otherwise, determine the target Linux system based on the IP, username, password and connection port information of the manually installed Linux system filled in by the tester when submitting the Excel spreadsheet. S202: After waiting for a specified time, determine whether the connection to the target Linux system can be established. If the connection fails, notify the tester of the connection failure message, end the process, and exit. Otherwise, proceed to step S203. S203: Based on the test case parameters, the code of the corresponding test case is sent to the target Linux system, the dependent environment required by the test case is obtained, and the deployment of the dependent environment is completed. S204: Obtain the test method selected by the tester in the Web interface of the pipeline tool. If the tester selects the test method as table verification and submits an Excel spreadsheet, proceed to step S205. S205, Obtain the Excel spreadsheet, modify the configuration parameters in the table verification test suite according to the test case parameters in the Excel spreadsheet, and interpret the extracted verification data from the Excel spreadsheet; S206, Execute the table verification test suite to test the Linux system; S207, Collect logs from the execution of the table validation test suite as test results.

6. The automated testing method for Linux systems based on Excel according to claim 5, characterized in that, When obtaining the test method selected by the tester in the web interface of the pipeline tool in step S204, it also includes jumping to step S301 if the test method selected by the tester is smoke testing: S301, Obtain the specified smoke test set, which includes basic functional test cases required for Linux system testing, to verify whether the Linux system has basic operability; S302, Modify the configuration parameters of the smoke test suite based on the parameters entered by the tester in the web interface of the pipeline tool; S303 executes the smoke test suite to test the Linux system; S304, collect the logs from the execution of the smoke test suite as the test results.

7. The automated testing method for Linux systems based on Excel according to claim 1, characterized in that, When filling the collected test results back into the Excel spreadsheet in step S105, the collected test results include: test passed (TPASS), test passed but manual test (TPASS_HAND), test failed and manual test (TFAIL_HAND), test failed (TFAIL), and parameter data is empty (NULLDATA). The parameter data being empty (NULLDATA) is the test result collected when the test exits due to incomplete test case parameters.

8. An automated testing system for Linux systems based on Excel, comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to execute the Excel-based automated testing method for Linux systems as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Excel-based automated testing method for Linux systems as described in any one of claims 1 to 7 via a processor.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Excel-based automated testing method for Linux systems as described in any one of claims 1 to 7 via a processor.

Images