Method, device and medium for automatically generating interface automation test project architecture

Abstract

The present invention discloses a method, device and medium for automatically generating an interface automation test project architecture, comprising: constructing an interface automation test project architecture; installing a corresponding Python package according to a dependent library file; calling public and basic files for use according to project requirements to complete the writing of an interface test script; generating components under an interface automation script source code file according to adding component files and the written interface test script; deleting components under an interface automation script source code file according to deleting component files and the written interface test case; executing an interface test process according to the complete component and function script code written under the interface automation script source code file, and obtaining interface test data; storing the interface test data in a target database according to a database file; obtaining the interface test data from the target database according to an interface automation test report file, and generating a test report. The present invention can unify automation project specifications.

Description

Technical Field

[0001] The present invention relates to the field of software test automation, and in particular to a method, device and medium for automatically generating an interface automation test project architecture. Background Art

[0002] In the software testing process, interface testing is a critical step in ensuring the correct interaction between different software components. Traditional interface testing requires a significant amount of time to encapsulate low-level functionality, which is not only time-consuming but also prone to human error. With the rise of DevOps and continuous integration (CI), automated interface testing has become increasingly important.

[0003] However, existing automated testing frameworks and tools often lack flexibility and scalability, and the automation code written for each project lacks standardization, which increases a lot of script maintenance costs and limits the widespread application of automated testing. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to propose a method for automatically generating an interface automation test project architecture, which is a more reasonable, more standardized and unified method for automation project specifications to simplify the construction of the test environment, the writing of test cases and the maintenance of test scripts.

[0005] In order to achieve the above technical objectives, the technical solution adopted by the present invention is:

[0006] The present invention provides a method for automatically generating an interface automation test project architecture, comprising the following steps:

[0007] Step 1. Build an interface automation test project architecture on the client. The interface automation test project architecture has a first-level directory, including common and basic files, database files, interface automation test report files, interface automation script source code files, add component files, delete component files, and dependent library files; the common and basic files have a second-level directory, including use case basic files, communication protocol basic files, user center management files, and common function files; the interface automation script source code files have a second-level directory, including interface layer files, configuration layer files, operation layer files, service layer files, and use case layer files; the configuration layer files have a third-level directory, including account configuration files and component configuration files; determine the target file according to the hierarchical relationship among the first-level directory, the second-level directory, and the third-level directory, and pre-configure the corresponding function script code under the target file;

[0008] Step 2: Install the corresponding Python package according to the function script code configured in the dependency library file;

[0009] Step 3: Call the corresponding function script code in the second-level directory of the public and basic files according to project requirements, and complete the writing of the interface test script through the Python package;

[0010] Step 4: Generate the corresponding version number and component in the target file corresponding to the interface automation script source file according to the function script code configured by the added component file and the written interface test script;

[0011] Step 5: Delete the corresponding version number and component in the target file corresponding to the interface automation script source code file according to the function script code configured by deleting the component file and the interface test case written;

[0012] Step 6: Write complete components and corresponding functional script codes in the target file corresponding to the interface automation script source code file to execute the interface test process and obtain interface test data;

[0013] Step 7: Store the interface test data into the corresponding target database according to the function script code configured in the database file;

[0014] Step 8: Acquire interface test data from the target database according to the functional script code configured in the interface automation test report file, and generate a test report.

[0015] Furthermore, the step 1 specifically includes:

[0016] Step 11: Determine the first-level directory of the interface automation test project architecture based on functional characteristics and basic data types, including common and basic files, database files, interface automation test report files, interface automation script source code files, added component files, deleted component files, and dependent library files;

[0017] Step 12: Structurally organize the first-level directory to determine the second-level directory of the public and basic files, including use case basic files, communication protocol basic files, user center management files, and common function files; the second-level directory of the interface automation script source code files includes interface layer files, configuration layer files, operation layer files, service layer files, and use case layer files; the interface layer files are used to store interfaces of different components, the configuration layer files are used to configure account information and component information, the operation layer files are used to execute commands, the service layer files are used to call different components, and the use case layer files are used to store test cases for each component;

[0018] Step 13: Structuring the second-level directory to determine the third-level directory of the configuration layer file, including account configuration files and component configuration files; the first-level directory, the second-level directory, and the third-level directory are arranged in order from top to bottom;

[0019] Step 14: First, determine whether there is a second-level directory under the file corresponding to the first-level directory according to the hierarchical relationship among the first-level directory, the second-level directory, and the third-level directory. If not, the file corresponding to the first-level directory is used as the target file; if so, continue to determine whether there is a third-level directory under the file corresponding to the second-level directory. If not, the file corresponding to the second-level directory is used as the target file; if so, the file corresponding to the third-level directory is used as the target file; obtain all target files including use case basic files, communication protocol basic files, user center management files, common function files, database files, interface automation test report files, interface layer files, account configuration files, component configuration files, operation layer files, service layer files, use case layer files, add component files, delete component files, and dependent library files;

[0020] Step 15. The use case basic file is configured with a use case basic class, the communication protocol basic file is configured with a communication protocol basic class, the user center management file is configured with user center management information, and the commonly used function file is configured with commonly used functions; the database file is configured with configuration information of the target database; the interface automation test report file is configured with configuration information for generating a report; the interface layer file is configured with interface information of different components, the account configuration file is configured with account information, and the component configuration file is configured with component information; the operation layer file is configured with operation information required for interface testing, the service layer file is configured with call information between different components, the use case layer file is configured with format information of test cases for each component, the add component file is configured with script code corresponding to the component, the delete component file is configured with script code corresponding to the component, and the dependency library file is configured with all Python packages required for the project and their version information.

[0021] Furthermore, the step 2 specifically includes:

[0022] Step 21: Encapsulate the Python package management command, the name of the dependency library file, and the link address of the Python package index into a dependency package installation command, and the client sends the dependency package installation command to the Python server;

[0023] Step 22: The Python server receives the dependency package installation command and parses the Python package management command, the name of the dependency library file, and the link address of the Python package index;

[0024] Step 23: The Python server reads a dependency library file that matches the name of the dependency library file according to the Python package management command, and obtains all Python packages and their version information recorded in the dependency library file;

[0025] Step 24: The Python server sets the link address of the Python package index as the default source for subsequent operations according to the Python package management command;

[0026] Step 25: The Python server downloads the Python packages that match all the Python packages and their version information recorded in the dependency library file from the link address of the Python package index according to the Python package management command, and installs them into the current Python environment;

[0027] Step 26: The Python server determines whether there are any dependent packages associated with the downloaded Python package. If so, all associated dependent packages are downloaded; if not, no download is required.

[0028] Furthermore, the step 3 specifically includes:

[0029] Step 31: Call the communication protocol basic class configured in the communication protocol basic file according to the protocol mode used by the interface to be tested;

[0030] Step 32: When writing an interface test case, call the use case base class configured in the use case base file for use;

[0031] Step 33: When writing an interface test script, call the common functions configured in the common function file for use;

[0032] Step 34: When the interface needs to be authenticated, the user center management information configured in the user center management file is called for use;

[0033] Step 35: Write an interface test script based on the communication protocol basic class, use case basic class, common functions, user center management information and Python package.

[0034] Furthermore, the step 4 specifically includes:

[0035] Step 41: When a component adding operation is required, the interpreter call function and the name of the added component file are encapsulated into a component adding command, and the client sends the component adding command to the Python server;

[0036] Step 42: The Python server receives the component adding command and parses the interpreter calling function and the name of the added component file;

[0037] Step 43: The Python server searches for and starts a corresponding Python interpreter through an interpreter call function, and loads and executes the script code configured in the add-in component file that matches the name of the add-in component file through the Python interpreter;

[0038] Step 44: Enter the corresponding version number and component name according to the written interface test script, and generate the corresponding version number and component under the interface layer file, component configuration file, operation layer file, service layer file and use case layer file under the interface automation script source code.

[0039] Furthermore, the step 5 specifically includes:

[0040] Step 51: When a component deletion operation is required, the interpreter call function and the name of the component file to be deleted are encapsulated into a component deletion command, and the client sends the component deletion command to the Python server;

[0041] Step 52: The Python server receives the component deletion command and parses the interpreter call function and the name of the deleted component file;

[0042] Step 53: The Python server searches for and starts a corresponding Python interpreter through an interpreter call function, and loads and executes the script code configured in the deletion component file that matches the name of the deletion component file through the Python interpreter;

[0043] Step 54: Enter the corresponding version number and component name according to the written interface test script, and delete the corresponding version number and component under the interface layer file, component configuration file, operation layer file, service layer file and use case layer file under the interface automation script source code.

[0044] Furthermore, the step 7 specifically includes:

[0045] Step 71: The database file contains the configuration information of the target database, including the target database's IP address, port number, redis connection method, mq connection method, database username, and password.

[0046] Step 72: When the interface test data is obtained, the target database is found according to the IP and port of the target database;

[0047] Step 73: Log in to the target database using the database user name and password;

[0048] Step 74: Establish a connection channel with the target database according to the Redis connection mode or the MQ connection mode, and store the interface test data in the corresponding target database.

[0049] Furthermore, the step 8 specifically includes:

[0050] Step 81: The interface automation test report file is configured with the Allure tool;

[0051] Step 82: Obtain interface test data from the target database, use the Allure tool to generate a test report based on the interface test data, and display the report.

[0052] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, the method for automatically generating an interface automation test project architecture as described above is implemented.

[0053] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned method for automatically generating an interface automation test project architecture.

[0054] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art:

[0055] 1. Quick construction: Build the interface automation test project architecture, set common functions (such as: use case basic class, communication protocol basic class, user center management and common functions and other relatively fixed information) in the public and basic files, so that they can be directly called when writing interface test scripts without the need for additional writing; and by adding component files and deleting script codes under component files, the corresponding components can be generated or deleted under the corresponding target files under the interface automation script source code file at the same time, which improves the efficiency of writing components; and through the functional script codes under the interface layer files, configuration layer files, operation layer files, service layer files and use case layer files, interface testing can be quickly executed; by combining public and basic files with interface automation script source code files, interface test scripts that meet the needs of different projects can be quickly written.

[0056] 2. Standardization: The interface automation test project framework is divided into common and basic files, database files, interface automation test report files, interface automation script source code files, add component files, delete component files and dependent library files according to different functional characteristics; different projects will use, write, run, save and generate reports according to the corresponding functional script codes of different functions when writing interface test scripts, and conduct unified management, so as to achieve the unification of interface automation environment, rapid construction of automation environment and consistent interface automation implementation specifications.

[0057] 3. Easy to maintain: Simplify the maintenance of interface test scripts and reduce maintenance costs.

[0058] 4. Highly configurable: The interface automation test project framework is divided into first-level directories, second-level directories, and third-level directories according to different functional characteristics. Each level of directory contains files with corresponding functions. Each target file is configured with functional script codes of corresponding functions for execution and calling, providing flexible configuration options to adapt to different testing needs.

[0059] 5. Good scalability: supports project expansion and easily copes with new testing requirements.

[0060] 6. Use the Allure tool to uniformly manage test reports and improve the efficiency of test report analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0062] Figure 1 This is an execution flow chart of a method for automatically generating an interface automation test project architecture provided by an embodiment of the present invention.

[0063] Figure 2 It is a structural diagram of the interface automation test project architecture provided by an embodiment of the present invention.

[0064] Figure 3 is a schematic diagram of an electronic device provided by an embodiment of the present invention.

[0065] Figure 4 It is a schematic diagram of a computer-readable storage medium provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0066] The present invention will be described in further detail below with reference to the accompanying drawings and examples. It is particularly noted that the following examples are intended only to illustrate the present invention and are not intended to limit the scope of the present invention. Similarly, the following examples are only some embodiments of the present invention and are not intended to be all embodiments. All other embodiments obtained by those of ordinary skill in the art without creative effort are intended to fall within the scope of protection of the present invention.

[0067] See Figure 1 and Figure 2The present invention provides a method for automatically generating an interface automation test project architecture, comprising the following steps:

[0068] Step 1. Build an interface automation test project architecture on the client. The interface automation test project architecture has a first-level directory, including common and basic files, database files, interface automation test report files, interface automation script source code files, add component files, delete component files, and dependent library files; the common and basic files have a second-level directory, including use case basic files, communication protocol basic files, user center management files, and common function files; the interface automation script source code files have a second-level directory, including interface layer files, configuration layer files, operation layer files, service layer files, and use case layer files; the configuration layer files have a third-level directory, including account configuration files and component configuration files; determine the target file according to the hierarchical relationship among the first-level directory, the second-level directory, and the third-level directory, and pre-configure the corresponding function script code under the target file;

[0069] In this embodiment, step 1 specifically includes:

[0070] Step 11. Determine the first-level directory of the interface automation test project architecture based on functional characteristics and basic data types, including public and basic files, database files, interface automation test report files, interface automation script source code files, add component files, delete component files and dependent library files; among them, public and basic files are managed by \common, database files are managed by \config, interface automation test reports are managed by \report, interface automation script source code is managed by \src, add component files are managed by \add_component_common.py, delete component files are managed by

[0071] It is managed by \del_component_common.py, and the dependent library files are managed by \requirements.txt;

[0072] The common and basic files are mainly used to encapsulate common and basic class methods. These encapsulations must be used every time as basic methods. Such encapsulation reduces a lot of repetitive work.

[0073] The database file is used to transfer the interface test data to the target database, which makes data analysis more convenient. The database file configuration is mainly managed through the dbcfg array object under the \config\basecfg.ini file, which mainly configures the target database's IP, port, redis connection method, mq connection method, database user name, password and other contents.

[0074] The interface automation test report file is used to generate a test report;

[0075] The interface automation script source code file is used to provide interface automation script componentization;

[0076] The added component file is used to automatically add the corresponding component under the interface automation script source code file;

[0077] The component deletion file is used to automatically delete the corresponding component under the interface automation script source code file;

[0078] The dependency library file is used to record the names of all third-party dependency libraries associated with the interface automation test project architecture;

[0079] Step 12. Structuralize the first-level directory and determine the second-level directory of the public and basic files, including use case basic files, communication protocol basic files, user center management files and common function files; in the interface automation test project architecture, the public and basic files mainly encapsulate public and basic class methods, such as: encapsulation of use case step splitting and conversion public methods (configured in the use case basic file), http / https request protocol basic method encapsulation and request return processing encapsulation (configured in the communication protocol basic file), account center (uc) management method encapsulation (configured in the user center management file), third-party plug-in reference class encapsulation (configured in the common function file). These encapsulations must be used every time as basic methods, and such encapsulation reduces a lot of repetitive work.

[0080] The second-level directory of the interface automation script source code file includes interface layer files, configuration layer files, runtime layer files, service layer files, and use case layer files; the interface layer files are used to store interfaces of different components, the configuration layer files are used to configure account information and component information, the runtime layer files are used to run commands, the service layer files are used to call different components, and the use case layer files are used to store test cases for each component; among them, the interface layer files are managed by \src\api_call, the configuration layer files are managed by \src\config, the runtime layer files are managed by \src\runner, the service layer files are managed by \src\service, and the use case layer files are managed by \src\testcases;

[0081] By executing the "\add_component_common.py" file and entering the content (such as version number, component name, etc.) according to the prompts, the corresponding component files will be generated in each directory of \src;

[0082] Corresponding file 1: \src\api_call (api_call provides interface name management used by the corresponding component);

[0083] Corresponding file 2: The \src\config directory provides the \config\accounts\production.py production environment configuration file and the \config\accounts\test.py test environment configuration file, which configure the accounts and passwords for different environments respectively. The test engineer needs to use which environment currently by simply specifying the current environment through the "type = environment configuration file name" under the [cfg] tag of the \config\cfgtype.ini file. If there are other environments, you can produce corresponding environment configuration files under \config\accounts\, such as: pre-production environment, etc., and also specify the required environment through the "type = environment file name" under the [cfg] tag of the \config\cfgtype.ini file; and in the \config\components\ component directory, you can configure the environment and account that each component needs to use (for example: component A uses 5 accounts [1,5] in the test environment);

[0084] Corresponding file three: \src\runner provides splicing management of the commands used by the use cases under the components when DOS commands need to be executed during the test;

[0085] Corresponding file 4: \src\service provides services for cross-component business calls, reduces cross-references of automation codes between different components, and provides unified services for external call codes of components;

[0086] Corresponding file five: \src\testcases This directory is mainly used to write and manage the interface automation use case script codes of each component.

[0087] Since public and basic files (common types) and interface automation script source code files (different interface test scripts are written according to different projects) are managed separately, public and basic files only need to call pre-configured functional script codes without the need for separate writing, reducing repeated basic class method writing and encapsulation; allowing automation test engineers to only focus on writing interface test scripts, reducing cost waste and reduced efficiency due to code implementation such as public method encapsulation and environment configuration.

[0088] Step 13: Structuring the second-level directory to determine the third-level directory of the configuration layer file, including account configuration files and component configuration files; the first-level directory, the second-level directory, and the third-level directory are arranged in order from top to bottom;

[0089] Step 14: First, determine whether there is a second-level directory under the file corresponding to the first-level directory according to the hierarchical relationship among the first-level directory, the second-level directory, and the third-level directory. If not, the file corresponding to the first-level directory is used as the target file; if so, continue to determine whether there is a third-level directory under the file corresponding to the second-level directory. If not, the file corresponding to the second-level directory is used as the target file; if so, the file corresponding to the third-level directory is used as the target file; obtain all target files including use case basic files, communication protocol basic files, user center management files, common function files, database files, interface automation test report files, interface layer files, account configuration files, component configuration files, operation layer files, service layer files, use case layer files, add component files, delete component files, and dependent library files;

[0090] Step 15. The use case basic file is configured with a use case basic class, the communication protocol basic file is configured with a communication protocol basic class, the user center management file is configured with user center management information, and the commonly used function file is configured with commonly used functions; the database file is configured with configuration information of the target database; the interface automation test report file is configured with configuration information for generating a report; the interface layer file is configured with interface information of different components, the account configuration file is configured with account information, and the component configuration file is configured with component information; the operation layer file is configured with operation information required for interface testing, the service layer file is configured with call information between different components, the use case layer file is configured with format information of test cases for each component, the add component file is configured with script code corresponding to the component, the delete component file is configured with script code corresponding to the component, and the dependency library file is configured with all Python packages required for the project and their version information.

[0091] Step 2: Install the corresponding Python package according to the functional script code configured in the dependency library file; the purpose of this step is to better use various methods within the interface automation test project architecture, and these third-party dependency libraries need to be installed first.

[0092] In this embodiment, step 2 specifically includes:

[0093] Step 21: Encapsulate the Python package management command, the name of the dependency library file, and the link address of the Python package index into a dependency package installation command, and the client sends the dependency package installation command to the Python server;

[0094] Step 22: The Python server receives the dependency package installation command and parses the Python package management command, the name of the dependency library file, and the link address of the Python package index;

[0095] Step 23: The Python server reads a dependency library file that matches the name of the dependency library file according to the Python package management command, and obtains all Python packages and their version information recorded in the dependency library file;

[0096] Step 24: The Python server sets the link address of the Python package index as the default source for subsequent operations according to the Python package management command;

[0097] Step 25: The Python server downloads the Python packages that match all the Python packages and their version information recorded in the dependency library file from the link address of the Python package index according to the Python package management command, and installs them into the current Python environment;

[0098] Step 26: The Python server determines whether there are any dependent packages associated with the downloaded Python package. If so, all associated dependent packages are downloaded; if not, no download is required.

[0099] The specific embodiments are:

[0100] 1) Install the plugin and plugin version according to the requirements.txt file, and use the statement according to the environment. The command is as follows:

[0101] pip3 install -r requirements.txt-i https: / / pypi.tuna.tsinghua.edu.cn / simple

[0102] Command Explanation:

[0103] pip3: This is the Python package management command used to install and manage Python packages. pip3 is often used to specify the Python 3.x version of pip to distinguish it from the Python 2.x version of pip that may exist at the same time;

[0104] install: This is a subcommand of pip, used to install Python packages;

[0105] -r: is an option that stands for "requirement" and is usually followed by a file name that contains the Python packages to be installed and their version information. In this command, -r requirements.txt specifies the requirements.txt file, which lists all the dependency packages required by the project;

[0106] The -i option stands for "index-url," followed by the URL of the Python Package Index. In this command, -i https: / / pypi.tuna.tsinghua.edu.cn / simple specifies the mirror provided by Tsinghua University. Using this option can speed up package downloads.

[0107] 2) The command execution process is as follows:

[0108] Parse command line arguments: Parse out the pip3 command, the install subcommand, the -r requirements.txt option, and the -i https: / / pypi.tuna.tsinghua.edu.cn / simple option.

[0109] Read requirements.txt file: pip3 reads the specified requirements.txt file, which contains all Python packages required by the project and their version information.

[0110] Set the package index source: The -i option specifies the PyPI mirror provided by Tsinghua University, https: / / pypi.tuna.tsinghua.edu.cn / simple, as the package index source. pip3 will set this URL as the default source for subsequent operations.

[0111] Download and install packages: pip3 downloads the corresponding Python packages from the specified PyPI mirror source based on the Python packages and version information listed in the requirements.txt file, and installs them into the current Python environment.

[0112] Handling dependencies: During the installation process, if a package depends on other packages, pip3 will also try to download and install these dependent packages.

[0113] Completing the installation: Once all the specified packages and their dependencies are successfully downloaded and installed, pip3 will output a message stating that the installation was successful.

[0114] Step 3: Call the corresponding function script code in the second-level directory of the public and basic files according to project requirements, and complete the writing of the interface test script through the Python package;

[0115] In this embodiment, step 3 specifically includes:

[0116] Step 31: Call the communication protocol basic class configured in the communication protocol basic file according to the protocol mode used by the interface to be tested;

[0117] Step 32: When writing an interface test case, call the use case base class configured in the use case base file for use;

[0118] Step 33: When writing an interface test script, call the common functions configured in the common function file for use;

[0119] Step 34: When the interface needs to be authenticated, the user center management information configured in the user center management file is called for use;

[0120] Step 35: Write an interface test script based on the communication protocol basic class, use case basic class, common functions, user center management information and Python package.

[0121] Step 4: Generate the corresponding version number and component in the target file corresponding to the interface automation script source file according to the function script code configured by the added component file and the written interface test script;

[0122] In this embodiment, step 4 specifically includes:

[0123] Step 41: When a component adding operation is required, the interpreter call function and the name of the added component file are encapsulated into a component adding command, and the client sends the component adding command to the Python server;

[0124] Step 42: The Python server receives the component adding command and parses the interpreter calling function and the name of the added component file;

[0125] Step 43: The Python server searches for and starts a corresponding Python interpreter through an interpreter call function, and loads and executes the script code configured in the add-in component file that matches the name of the add-in component file through the Python interpreter;

[0126] Step 44: Enter the corresponding version number and component name according to the written interface test script, and generate the corresponding version number and component under the interface layer file, component configuration file, operation layer file, service layer file and use case layer file under the interface automation script source code.

[0127] The specific embodiments are:

[0128] 1) Encapsulate the component and add the command: python add_component_common.py

[0129] Command Explanation:

[0130] python: This is the command used to invoke the Python interpreter. In most cases, when you type python followed by a script name at the command line, it will start the Python interpreter and execute the specified script. Note that some systems may use python3 to specify Python 3.x, especially if both Python 2.x and 3.x are installed.

[0131] add_component_common.py: This is the file name of the Python script to be executed. This script should contain Python code that defines the script's functionality. In this example, the name of the script suggests that it might be used to add some common components.

[0132] 2) The command execution process is as follows:

[0133] The system looks for an executable file named python (usually the Python interpreter).

[0134] The Python interpreter starts and loads the specified file add_component_common.py.

[0135] The Python interpreter executes the code in the script and generates corresponding version numbers and components in the directories at all levels under the interface automation script source code.

[0136] 3) Specific implementation logic:

[0137] The specific implementation logic is to execute the command when the command is executed: python

[0138] add_component_common.py (python is a command to call the Python interpreter, followed by the add_component_common.py file name, which means that the automation code in the file name is executed by the python interpreter). A prompt will appear asking you to enter the component name (such as: user_login), version number (such as: V1.0.0), etc. for the interface automation, that is, the corresponding version number and component name (such as: \src\api_call\user_login\V1.0.0\user_login) will be generated in each level of directory under \src. The present invention uses Python language encapsulation in the add_component_common.py file to automatically generate structured project names, version numbers, component files, and code frameworks for implementing interface automation scripts in component files under the project directory of the project architecture. Engineers can quickly and conveniently fill in the corresponding interface use case script code to be implemented in the generated component file according to the automatically generated script architecture.

[0139] 4) The execution process is as follows:

[0140] After the command is executed, the following content will appear:

[0141] [Tip] Enter 'e' and press Enter to exit the program. Entering and pressing Enter is the default!

[0142] Enter the component name (letters + _, such as api_class):

[0143] Enter the version number (default v1.0):

[0144] >Is this a third-party component? Y / N? (Default is N):

[0145] After entering the relevant content for the above three prompts, the following results are output:

[0146] [Tip] The api_class component was created successfully, and 4 new files were created:

[0147] src / api_call / api_class / v1_0 / api_class_api.py

[0148] src / service / api_class / v1_0 / api_class_service.py

[0149] src / testcases / api_class / v1_0 / api_class_testcases.py

[0150] src / config / components / api_class_config.py

[0151] Enter according to the prompts, then press Enter, and the code will be automatically generated.

[0152] Step 5: Delete the corresponding version number and component in the target file corresponding to the interface automation script source code file according to the function script code configured by deleting the component file and the interface test case written;

[0153] In this embodiment, step 5 specifically includes:

[0154] Step 51: When a component deletion operation is required, the interpreter call function and the name of the component file to be deleted are encapsulated into a component deletion command, and the client sends the component deletion command to the Python server;

[0155] Step 52: The Python server receives the component deletion command and parses the interpreter call function and the name of the deleted component file;

[0156] Step 53: The Python server searches for and starts a corresponding Python interpreter through an interpreter call function, and loads and executes the script code configured in the deletion component file that matches the name of the deletion component file through the Python interpreter;

[0157] Step 54: Enter the corresponding version number and component name according to the written interface test script, and delete the corresponding version number and component under the interface layer file, component configuration file, operation layer file, service layer file and use case layer file under the interface automation script source code.

[0158] The specific embodiments are:

[0159] 1) Encapsulate component deletion command, the command is: python del_component_common.py

[0160] Command Explanation:

[0161] python: This command is used to call the Python interpreter. It tells the system to use the Python interpreter to run the script specified afterwards. On some systems, you may use python3 to specify Python 3.x, especially if both Python 2.x and 3.x are installed.

[0162] del_component_common.py: This is the file name of the Python script to be executed. This script should contain Python code that defines the script's functionality. In this example, the name of the script suggests that it might be used to delete some common component.

[0163] 2) The command execution process is as follows:

[0164] The system looks for an executable file named python (usually the Python interpreter).

[0165] The Python interpreter starts and loads the specified file del_component_common.py.

[0166] The Python interpreter executes the code in the script and deletes the corresponding version numbers and components in the directories at all levels under the interface automation script source code.

[0167] 3) Specific implementation logic:

[0168] When you need to delete a component, you want to delete all the related content of the component (if it is not easy to delete the related files of the component manually), you can execute the command: python

[0169] del_component_common.py (python is a command to call the Python interpreter, followed by the del_component_common.py file name, which means that the automation code in the file name is executed through the python interpreter). After the code is executed, the files in the automation script\src directory will be traversed according to the component to be deleted (such as user_login), and the files related to this component will be found and the deletion operation will be automatically performed.

[0170] 4) The execution process is as follows:

[0171] After the command is executed, the existing components will be prompted:

[0172] [1]user_login

[0173] [2]user_outlogin

[0174] [Tip] To exit the program, please enter 'e' and press Enter!

[0175] >Enter the serial number of the component to be deleted (enter all to clear, enter c to clear the cache): 1

[0176] >Are you sure you want to delete 'user_login' (yes or no): > ? yes

[0177] result:

[0178] ('delete: / src / api_call / abc112',)

[0179] [success]

[0180] ('delete: / src / service / abc112',)

[0181] [success]

[0182] ('delete: / src / testcases / abc112',)

[0183] [success]

[0184] ('delete: / src / config / components / abc112.py',)

[0185] [success]

[0186] Note: The cache deletion function cleans up the py files in the project.

[0187] Step 6: Write complete components and corresponding functional script codes in the target file corresponding to the interface automation script source code file to execute the interface test process and obtain interface test data;

[0188] Step 7: Store the interface test data into the corresponding target database according to the function script code configured in the database file;

[0189] In this embodiment, step 7 specifically includes:

[0190] Step 71: The database file contains the configuration information of the target database, including the target database's IP address, port number, redis connection method, mq connection method, database username, and password.

[0191] Step 72: When the interface test data is obtained, the target database is found according to the IP and port of the target database;

[0192] Step 73: Log in to the target database using the database user name and password;

[0193] Step 74: Establish a connection channel with the target database according to the redis connection mode or the mq connection mode, and store the interface test data in the corresponding target database. Transferring the interface test data to the target database makes data analysis more convenient.

[0194] Step 8: Acquire interface test data from the target database according to the functional script code configured in the interface automation test report file, and generate a test report.

[0195] In this embodiment, step 8 specifically includes:

[0196] Step 81: The interface automation test report file is configured with the Allure tool;

[0197] Step 82: Obtain interface test data from the target database and use the Allure tool to generate and display a test report based on the interface test data. Test reports are centrally managed using the industry-standard Allure test report. Within the interface automation test project architecture, test reports are generated using the \report function according to Allure's code specifications. Finally, the test report for the interface automation use case is displayed on Allure. Using the Allure tool for unified management of test reports improves test report analysis efficiency.

[0198] The entire interface automation testing project architecture can effectively and quickly support test engineers in writing interface test scripts. After the script is written, it can generally be scheduled and executed by Jenkins (a continuous integration and continuous delivery (CI / and continuous deployment CD) automation tool written in Java) according to the commonly used methods in the industry.

[0199] The advantages of the present invention are:

[0200] 1. Improve development efficiency: By automatically generating test project architectures through interface automation, test engineers can save approximately 80% of their environment setup time. For example, an environment that previously took several days to configure can now be generated with a single command, allowing for minor adjustments based on project needs.

[0201] 2. Reduce human errors: Automated processes reduce manual operations, thereby reducing the rate of configuration errors to close to 0%, significantly improving the accuracy of test execution.

[0202] 3. Enhanced test coverage: The modular design makes test case writing more systematic, helping to improve test coverage. According to actual cases, test coverage has increased by an average of 30%.

[0203] 4. Improved environment consistency: Unified configuration and dependency library management ensures consistency between different test environments, reduces problems caused by environmental differences, and reduces related errors by about 60%.

[0204] 5. Simplified maintenance: The clear project structure and component-based design simplify subsequent maintenance and expansion. Maintenance costs are reduced by approximately 40% compared to traditional methods, while improving code readability and maintainability.

[0205] 6. Quick response to interface changes: The automated testing framework can quickly adapt to interface changes, shortening the time for test script updates by 50%, thereby improving the response speed and adaptability of the test.

[0206] 7. Improve test quality: Through the test reports generated by Allure, the analysis time of test results is reduced by about 25%, and the accuracy of problem location is improved by 20%.

[0207] 8. Optimize resource utilization: Automated testing reduces dependence on test engineers, allowing them to invest more time in more valuable test design and strategy planning rather than environment configuration and script writing.

[0208] 9. Improve team collaboration efficiency: The automated testing architecture allows multiple test engineers to work in parallel while maintaining consistency in test cases and scripts, improving team collaboration efficiency by approximately 30%.

[0209] 10. Reduce overall costs: Taking all the above points into consideration, the overall testing costs (including time costs and labor costs) were reduced by an average of about 35%, bringing significant economic benefits to the company.

[0210] like Figure 3 As shown, an embodiment of the present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the above-mentioned method for automatically generating an interface automation test project architecture is implemented.

[0211] like Figure 4 As shown, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which implements the above-mentioned method for automatically generating an interface automation test project architecture when the program is executed by a processor.

[0212] In addition, the functional units in various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0213] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0214] The above descriptions are only some embodiments of the present invention and do not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made by using the contents of the description and drawings of the present invention, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for automatically generating an interface automation test project architecture, characterized in that: The steps include: Step 1: Build an interface automation test project architecture on the client. The interface automation test project architecture has a first-level directory, including common and basic files, database files, interface automation test report files, interface automation script source code files, add component files, delete component files, and dependent library files; the common and basic files have a second-level directory, including use case basic files, communication protocol basic files, user center management files, and common function files; the interface automation script source code files have a second-level directory, including interface layer files, configuration layer files, operation layer files, service layer files, and use case layer files; The configuration layer file has a third-level directory, including account configuration files and component configuration files; Determine the target file according to the hierarchical relationship among the first-level directory, the second-level directory, and the third-level directory, and pre-configure the corresponding function script code under the target file; Step 2: Install the corresponding Python package according to the function script code configured in the dependency library file; Step 3: Call the corresponding function script code in the second-level directory of the public and basic files according to project requirements, and complete the writing of the interface test script through the Python package; Step 4: Generate the corresponding version number and component in the target file corresponding to the interface automation script source file according to the function script code configured by the added component file and the written interface test script; Step 5: Delete the corresponding version number and component in the target file corresponding to the interface automation script source code file according to the function script code configured by deleting the component file and the interface test case written; Step 6: Write complete components and corresponding functional script codes in the target file corresponding to the interface automation script source code file to execute the interface test process and obtain interface test data; Step 7: Store the interface test data into the corresponding target database according to the function script code configured in the database file; Step 8: Acquire interface test data from the target database according to the functional script code configured in the interface automation test report file, and generate a test report.

2. The method for automatically generating an interface automation test project architecture according to claim 1, wherein: The step 1 specifically includes: Step 11: Determine the first-level directory of the interface automation test project architecture based on functional characteristics and basic data types, including common and basic files, database files, interface automation test report files, interface automation script source code files, added component files, deleted component files, and dependent library files; Step 12: Structurally organize the first-level directory to determine the second-level directory of the public and basic files, including use case basic files, communication protocol basic files, user center management files, and common function files; the second-level directory of the interface automation script source code files includes interface layer files, configuration layer files, operation layer files, service layer files, and use case layer files; the interface layer files are used to store interfaces of different components, the configuration layer files are used to configure account information and component information, the operation layer files are used to execute commands, the service layer files are used to call different components, and the use case layer files are used to store test cases for each component; Step 13: Structuring the second-level directory to determine the third-level directory of the configuration layer file, including account configuration files and component configuration files; the first-level directory, the second-level directory, and the third-level directory are arranged in order from top to bottom; Step 14: First, determine whether there is a second-level directory under the file corresponding to the first-level directory according to the hierarchical relationship among the first-level directory, the second-level directory, and the third-level directory. If not, the file corresponding to the first-level directory is used as the target file; if so, continue to determine whether there is a third-level directory under the file corresponding to the second-level directory. If not, the file corresponding to the second-level directory is used as the target file; if so, the file corresponding to the third-level directory is used as the target file; obtain all target files including use case basic files, communication protocol basic files, user center management files, common function files, database files, interface automation test report files, interface layer files, account configuration files, component configuration files, operation layer files, service layer files, use case layer files, add component files, delete component files, and dependent library files; Step 15. The use case basic file is configured with a use case basic class, the communication protocol basic file is configured with a communication protocol basic class, the user center management file is configured with user center management information, and the commonly used function file is configured with commonly used functions; the database file is configured with configuration information of the target database; the interface automation test report file is configured with configuration information for generating a report; the interface layer file is configured with interface information of different components, the account configuration file is configured with account information, and the component configuration file is configured with component information; the operation layer file is configured with operation information required for interface testing, the service layer file is configured with call information between different components, the use case layer file is configured with format information of test cases for each component, the add component file is configured with script code corresponding to the component, the delete component file is configured with script code corresponding to the component, and the dependency library file is configured with all Python packages required for the project and their version information.

3. The method for automatically generating an interface automation test project architecture according to claim 2, wherein: The step 2 specifically includes: Step 21: Encapsulate the Python package management command, the name of the dependency library file, and the link address of the Python package index into a dependency package installation command, and the client sends the dependency package installation command to the Python server; Step 22: The Python server receives the dependency package installation command and parses the Python package management command, the name of the dependency library file, and the link address of the Python package index; Step 23: The Python server reads a dependency library file that matches the name of the dependency library file according to the Python package management command, and obtains all Python packages and their version information recorded in the dependency library file; Step 24: The Python server sets the link address of the Python package index as the default source for subsequent operations according to the Python package management command; Step 25: The Python server downloads the Python packages that match all the Python packages and their version information recorded in the dependency library file from the link address of the Python package index according to the Python package management command, and installs them into the current Python environment; Step 26: The Python server determines whether there are any dependent packages associated with the downloaded Python package. If so, all associated dependent packages are downloaded; if not, no download is required.

4. The method for automatically generating an interface automation test project architecture according to claim 2, wherein: The step 3 specifically includes: Step 31: Call the communication protocol basic class configured in the communication protocol basic file according to the protocol mode used by the interface to be tested; Step 32: When writing an interface test case, call the use case base class configured in the use case base file for use; Step 33: When writing an interface test script, call the common functions configured in the common function file for use; Step 34: When the interface needs to be authenticated, the user center management information configured in the user center management file is called for use; Step 35: Write an interface test script based on the communication protocol basic class, use case basic class, common functions, user center management information and Python package.

5. The method for automatically generating an interface automation test project architecture according to claim 2, wherein: The step 4 specifically includes: Step 41: When a component adding operation is required, the interpreter call function and the name of the added component file are encapsulated into a component adding command, and the client sends the component adding command to the Python server; Step 42: The Python server receives the component adding command and parses the interpreter calling function and the name of the added component file; Step 43: The Python server searches for and starts a corresponding Python interpreter through an interpreter call function, and loads and executes the script code configured in the add-in component file that matches the name of the add-in component file through the Python interpreter; Step 44: Enter the corresponding version number and component name according to the written interface test script, and generate the corresponding version number and component under the interface layer file, component configuration file, operation layer file, service layer file and use case layer file under the interface automation script source code.

6. The method for automatically generating an interface automation test project architecture according to claim 2, wherein: The step 5 specifically includes: Step 51: When a component deletion operation is required, the interpreter call function and the name of the component file to be deleted are encapsulated into a component deletion command, and the client sends the component deletion command to the Python server; Step 52: The Python server receives the component deletion command and parses the interpreter call function and the name of the deleted component file; Step 53: The Python server searches for and starts a corresponding Python interpreter through an interpreter call function, and loads and executes the script code configured in the deletion component file that matches the name of the deletion component file through the Python interpreter; Step 54: Enter the corresponding version number and component name according to the written interface test script, and delete the corresponding version number and component under the interface layer file, component configuration file, operation layer file, service layer file and use case layer file under the interface automation script source code.

7. The method for automatically generating an interface automation test project architecture according to claim 2, wherein: The step 7 specifically includes: Step 71: The database file contains the configuration information of the target database, including the target database's IP address, port number, redis connection method, mq connection method, database username, and password. Step 72: When the interface test data is obtained, the target database is found according to the IP and port of the target database; Step 73: Log in to the target database using the database user name and password; Step 74: Establish a connection channel with the target database according to the Redis connection mode or the MQ connection mode, and store the interface test data in the corresponding target database.

8. The method for automatically generating an interface automation test project architecture according to claim 7, wherein: The step 8 specifically includes: Step 81: The interface automation test report file is configured with the Allure tool; Step 82: Obtain interface test data from the target database, use the Allure tool to generate a test report based on the interface test data, and display the report.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method for automatically generating an interface automation test project architecture as described in any one of claims 1 to 8 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for automatically generating an interface automation test project architecture as described in any one of claims 1 to 8 is implemented.

Images