CN110096424B - Test processing method and device, electronic equipment and storage medium - Google Patents

Test processing method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN110096424B
CN110096424B CN201910396921.7A CN201910396921A CN110096424B CN 110096424 B CN110096424 B CN 110096424B CN 201910396921 A CN201910396921 A CN 201910396921A CN 110096424 B CN110096424 B CN 110096424B
Authority
CN
China
Prior art keywords
task
environment
target
script executor
target script
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910396921.7A
Other languages
Chinese (zh)
Other versions
CN110096424A (en
Inventor
王镇佳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing ByteDance Network Technology Co Ltd
Original Assignee
Beijing ByteDance Network Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing ByteDance Network Technology Co Ltd filed Critical Beijing ByteDance Network Technology Co Ltd
Priority to CN201910396921.7A priority Critical patent/CN110096424B/en
Publication of CN110096424A publication Critical patent/CN110096424A/en
Application granted granted Critical
Publication of CN110096424B publication Critical patent/CN110096424B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The disclosure provides a test processing method, a device, an electronic device and a storage medium, wherein the method comprises the following steps: acquiring a continuous integrated script corresponding to a target item, wherein the continuous integrated script comprises at least one task information, the task information comprises task type identifiers and task contents corresponding to the task type identifiers, and each task type identifier corresponds to a script executor of an operating system of one type; and calling a target script executor under the corresponding operating system to execute the task content according to the task type identifier. The method and the device can call the target script executor under the corresponding operating system to execute the task content according to the task type identifier during the test, can realize the automatic test of the project under the environments of the windows system and the macos system, and effectively ensure the online release performance of the project under the environments of the windows system and the macos system.

Description

Test processing method and device, electronic equipment and storage medium
Technical Field
The disclosure relates to the technical field of testing, and in particular relates to a testing processing method, a testing processing device, electronic equipment and a storage medium.
Background
In the process of developing software projects, it is very important to test the developed projects to verify the stability, correctness and other performances of the software. And front-end development is an integral part of the project development. In front-end development, end-to-end testing is typically used to ensure that the interactions and functions of the project UI are in line with expectations.
In the prior art, project development is typically performed using a gitlab platform, and end-to-end testing is initiated by a gitlab runner.
However, the machine on which the gitlab runner is built is typically a linux system environment, so that end-to-end testing can only guarantee the performance of the project in the linux system environment. When an item needs to be online in a windows or macos system environment, the online performance of the item cannot be guaranteed.
Disclosure of Invention
The disclosure provides a test processing method, a test processing device, an electronic device and a storage medium, so as to solve the defect that the prior art can only ensure the performance of a project in a linux system environment.
A first aspect of the present disclosure provides a method for processing a test, including:
acquiring a continuous integrated script corresponding to a target item, wherein the continuous integrated script comprises at least one task information, the task information comprises task type identifiers and task contents corresponding to the task type identifiers, and each task type identifier corresponds to a script executor of an operating system of one type;
and calling a target script executor under the corresponding operating system to execute the task content according to the task type identifier.
A second aspect of the present disclosure provides a test handler, comprising:
the system comprises an acquisition module, a script execution module and a script execution module, wherein the acquisition module is used for acquiring a continuous integrated script corresponding to a target item, the continuous integrated script comprises at least one task information, the task information comprises task type identifiers and task contents corresponding to the task type identifiers, and each task type identifier corresponds to a script executor of one type of operating system;
and the calling module is used for calling a target script executor under the corresponding operating system to execute the task content according to the task type identifier.
A third aspect of the present disclosure provides an electronic device, comprising: at least one processor and memory;
the memory stores a computer program; the at least one processor executes the computer program stored in the memory to implement the method provided in the first aspect.
A fourth aspect of the present disclosure provides a computer readable storage medium having a computer program stored therein, which when executed implements the method provided by the first aspect.
According to the test processing method, device, electronic equipment and storage medium, through continuously integrating the script to include at least one task information, each task corresponds to a script executor of one type of operating system, the target script executor under the corresponding operating system can be called according to the task type identification to execute task content during testing, automatic testing of the project under the environments of the windows system and the macos system is achieved, and the online performance of the project issued under the environments of the windows system and the macos system is effectively guaranteed.
Drawings
In order to more clearly illustrate the embodiments of the present disclosure or the solutions in the prior art, a brief description will be given below of the drawings that are needed in the embodiments or the description of the prior art, it being obvious that the drawings in the following description are some embodiments of the present disclosure, and that other drawings may be obtained from these drawings without inventive effort to a person of ordinary skill in the art.
FIG. 1 is a flow chart of a test processing method according to an embodiment of the disclosure;
FIG. 2 is a flow chart of a method for processing a test according to another embodiment of the present disclosure;
FIG. 3 is a schematic diagram of a test handler according to an embodiment of the present disclosure;
fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the disclosure;
fig. 5 is an exemplary structural schematic diagram of an electronic device according to an embodiment of the present disclosure.
Specific embodiments of the present disclosure have been shown by way of the above drawings and will be described in more detail below. These drawings and the written description are not intended to limit the scope of the disclosed concepts in any way, but rather to illustrate the disclosed concepts to those skilled in the art by reference to specific embodiments.
Detailed Description
For the purposes of making the objects, technical solutions and advantages of the embodiments of the present disclosure more apparent, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure, and it is apparent that the described embodiments are some embodiments of the present disclosure, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without inventive effort, based on the embodiments in this disclosure are intended to be within the scope of this disclosure.
The terms involved in the present disclosure will be explained first:
gitlab: a private code management platform is an open source project for a warehouse management system, uses git as a code management tool, and builds web services on the basis of the git.
Continuous integration: continuous Integration is a software development practice, i.e. team development members often integrate their work, usually at least once a day per member, meaning that multiple integration may occur per day. Each integration is verified by automated build-up (including compilation, release, automated testing) to discover integration errors as soon as possible. This process can greatly reduce the problem of integration, allowing teams to develop cohesive software more quickly.
gitlab-ci: also called gitlab ci, is a set of continuous integrated systems for use with gitlab, which can be located in a server.
gitlab-runner: may be referred to as script executors, also known as gitlab runners, are used in conjunction with the gitlab-ci, responsible for executing scripts that are continuously integrated on the gitlab. Typically, each project (also called project) in the gitlab defines a software integration script (i.e., persistent integration script) belonging to the project, which is used to automatically complete some software integration tasks. When the warehouse code of the project changes, for example, someone pushes the code, the gitlab will inform the gitlab-ci of the change. The gitlab-ci will then find the gitlab-runners associated with this project and inform these to update the code locally and execute the predefined persistent integration script. The premise is that the gitlab-runners register in the gitlab-ci so that the gitlab-ci can find the corresponding gitlab-runner.
End-to-end test: it can be understood that the UI automation test automatically simulates the operation behavior of the user.
And linux is an open source operating system taking UNIX as a kernel. linux, macos, and windows are the mainstream three-mainframe computer operating systems. Windows refers to the microsoft operating system, and macos refers to the apple operating system.
The test processing method provided by the embodiment of the disclosure is suitable for projects developed under the linux system environment, and besides automatic tests under the linux system environment, the test scenes under windows and macos system environments are needed. For a windows system, codes can be set, environment language support is provided, local user permission is set and the like, an automatic test environment is built, independent tasks are set for different systems in a continuous integrated script, and for the windows system, a call prefix is added to a script command and a cross-platform command and the like are used, so that the same development project can be automatically tested under different systems, and the online performance of the project issued by the windows system and the macos system environment is ensured.
Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. In the following description of the embodiments, the meaning of "a plurality" is two or more, unless explicitly defined otherwise.
The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present invention will be described below with reference to the accompanying drawings.
An embodiment of the present disclosure provides a test processing method for implementing an automated test in windows and macos system environments. The execution subject of the embodiments of the present disclosure is a processing apparatus for testing, which may be provided in a server.
As shown in fig. 1, a flow chart of a method for processing a test according to an embodiment of the disclosure is shown, where the method includes:
step 101, obtaining a continuous integrated script corresponding to a target item, wherein the continuous integrated script comprises at least one task information, and the task information comprises a task type identifier and task content corresponding to the task type identifier.
Wherein each task type identifies a gitlab runner corresponding to one type of operating system, and the types of operating systems include windows systems, macos systems, and linux systems.
Specifically, at least one task information is set in the continuous integrated script, and each task information corresponds to different operating systems, for example, a windows system, a linux system and a macos system, a windows system and a macos system, and three types of tasks including a linux system, a windows system and a macos system. The target item is the item to be tested currently. The task type identifier may be an identifier specified for the task that must be performed by what type of gitlab runner, e.g., in the. Gitlab-ci. Yml file, three tasks are to be configured. The task linux-ci specifies that a linux machine configured with a gitlab runner can execute. The task windows-ci, specifies that the windows machine configured with the gitlab runner can execute, macos is the same. Correspondingly, each of the gitlab runners will have a corresponding tag, such as a linux-tag, windows-tag, mac-tag. The task content is the script to be executed by the corresponding gitlab runner. And calling the corresponding type of the gitlab runner according to the task type identifier to execute task content for testing.
The script command of the windows system is added with a call prefix, and the running command of the front end is a cross-platform command. The cross-platform command may be a cross-platform applicable command provided by a third party.
Optionally, in order to ensure availability of the gitlab runner in the windows system environment, the windows system environment needs to be set first:
1. the code is first set.
The visual interface of the windows system can be set to UTF-8 codes to provide environmental language support. For example, the following setting procedures are used for setting: region= > management= > change system region settings= > global language support is provided using UTF-8.
The code setting may also be implemented by sending a corresponding code setting command to the windows system when the gitlab runner is installed, or before installation.
2. And setting the local user permission.
A user or group may be added by searching for a local security policy= > local policy= > user permission assignment= > as service login= >. The current local user, e.g., ee.sz.webdriver, is added to the user group.
The user permission setting can also be realized by sending a corresponding permission setting command to the windows system when the gitlab runner is installed or before the installation.
After setting up the environment of the windows system, the gitlab runner can be installed.
After the installation of the gitlab runner is completed, the user and the password to which the user belongs are set as the current user, so that the user has the installation content and the authority of the local account.
And 102, calling a target gitlab runner under a corresponding operating system to execute task content according to the task type identifier.
Specifically, after the persistent integrated script corresponding to the target item is obtained, the target gitlab runner under the corresponding operating system can be called to execute task content according to the task type identifier in the task information included in the persistent integrated script, so as to complete the test of the target item and obtain a test result.
The gitlab runner may obtain the test result according to the preset test case of the target item and the operation of the target item code, and the specific operation is the prior art and will not be described herein.
According to the test processing method provided by the embodiment of the disclosure, the continuous integrated script comprises at least one task information, each task corresponds to one type of the gitlab runner of the operating system, so that the target gitlab runner under the corresponding operating system can be called according to the task type identifier to execute task content during test, automatic test on the project under the environments of the windows system and the macos system is realized, and the online performance of the project issued under the environments of the windows system and the macos system is effectively ensured.
Another embodiment of the present disclosure further provides a supplementary explanation of the method provided in the above embodiment.
Fig. 2 is a schematic flow chart of a test processing method according to an embodiment of the disclosure.
As an implementation manner, on the basis of the foregoing embodiment, optionally, before step 101, the method further includes:
in step 2011, according to the task type identifier, an environment dependent package of the target gitlab runner is obtained, where the environment dependent package includes parameters corresponding to environment variables of the target gitlab runner.
In step 2012, the environment dependent package is sent to the destination gitlab runner to cause the destination gitlab runner to configure the environment variables of the destination gitlab runner according to the environment dependent package.
The environment dependent package refers to environment parameters on which the gitlab runner is installed and run. Such as the memory address of the item.
Before the gitlab runner executes the task, the tested processing device can acquire the environment dependent package of the target gitlab runner according to the task type identifier and send the environment dependent package to the target gitlab runner to configure the environment variable of the target gitlab runner. The environment dependent package may be a processing device or other location that is pre-configured and stored in the test. Specifically, the method may be set according to actual requirements, and the embodiments of the disclosure are not limited.
Because each operating system has its own file directory structure, and is different from each other, when an item is to be able to execute the same test code in three system environments, in order to facilitate configuration, in an embodiment of the disclosure, these unique parameters that depend on the environments are extracted, and expressed as variables, it is sufficient to configure the variables in the gitlab runner of each machine. For example, by modifying the configuration file of the gitlab runner, a variable of the storage address of the item, such as the name program WEB, can be added to it, which variable records its unique location on the respective machine. When the gitlab runner is installed in a different system environment, the variable is configured with a memory address corresponding to an item on the machine. Namely, the environment dependent package includes the item storage address in the system environment where the environment dependent package is installed, and the item storage address in the system environment where the variable is configured is given to the item storage address. Thus, in the front-end item, this variable PROJECT_WEB can be used directly to find the item location. The user name may be arbitrarily configured as new running end-to-end test machines are added later, so long as the correct project address is provided in the configuration environment.
It will be appreciated that many other parameters that are dependent on the system environment may be included in the environment dependent package, and may be represented in a different environment variable in the gitlab configuration file, not limited to the item storage path. By setting the environment variables, the configuration efficiency of the gitlab in different system environments is effectively improved.
By extracting common variables in a plurality of platform environments, flexibility and expansibility of cross-system platform testing based on automatic test of the gitlab are improved. For example, when the system is a windows system, because windows systems typically have account concepts, the path of the Desktop of Li Hua may be C: \Users\Lihua\desktop, and the Desktop path of Zhangsan\desktop may be C: \Users\Zhangsan\desktop, which is different, and by extracting common variables for testing in multiple system environments, these different characteristics may be allowed, allowing Zhang Sanlai to determine where he wants to place content.
As another implementation manner, on the basis of the foregoing embodiment, optionally, before step 101, the method may further include:
in step 2021, according to the task type identifier, the storage address of the environment-dependent packet of the target gitlab runner is obtained, where the environment-dependent packet includes the parameters corresponding to the environment variables of the target gitlab runner.
In step 2022, the storage address of the environment dependent packet is sent to the destination gitlab runner, so that the destination gitlab runner obtains the environment dependent packet according to the storage address of the environment dependent packet, and configures the environment variable of the destination gitlab runner according to the environment dependent packet.
Specifically, the processing device under test may send the storage address of the environment-dependent packet to the target gitlab runner, so that the target gitlab runner obtains the environment-dependent packet according to the storage address of the environment-dependent packet, and configures the environment variable of the target gitlab runner according to the environment-dependent packet.
The specific operation of the destination gitlab runner in configuring the environment variable of the destination gitlab runner according to the environment dependent package is consistent with the above embodiment, and will not be described herein.
Alternatively, the specific parameter corresponding to the environment variable of the gitlab runner may be manually configured when the gitlab runner is installed and configured on the host of the corresponding system.
As another implementation manner, on the basis of the foregoing embodiment, optionally, before step 101, the method may further include:
in step 2031, a registration request is received for the target gitlab runner, the registration request including a type of operating system for the target gitlab runner.
In step 2032, identification information of the target gitlab runner is generated and fed back to the target gitlab runner.
In step 2033, the identification information of the target gitlab runner and the type of operating system are recorded.
Specifically, for each gitlab runner, after installation, registration needs to be registered with the gitlab ci server, and the subsequent gitlab ci can call the gitlab runner to execute test codes as required.
The gitlab runner (for example, the target gitlab runner) may send a registration request to the gitlab ci server, where the registration request may include a type of an operating system where the target gitlab runner is located, and of course, may also include other related information of the target gitlab runner, and after receiving the registration request sent by the gitlab runner, the server generates identification information of the target gitlab runner, feeds back the identification information of the target gitlab runner to the target gitlab runner, and records the identification information of the target gitlab runner and the type of the operating system.
The identification information of the target gitlab runner generated here may include a category tag of the target gitlab runner, such as linux-tag, windows-tag, mac-tag, and may further include a token of the target gitlab runner, through which the gitlab runner may communicate with the gitlab ci. The manner in which the token is generated is known in the art and is further described herein. The generation of the category label may be to obtain a label corresponding to the type according to the type of the operating system where the target gitlab runner is located, and return the label to the target gitlab runner.
As another implementation manner, on the basis of the foregoing embodiment, optionally, the task information further includes a preset trigger condition of the task;
according to the task type identifier, calling a target gitlab runner under a corresponding operating system to execute task content, wherein the task content comprises:
judging whether a preset trigger condition of a task is met currently for each task;
when a preset trigger condition of a task is met, calling a target gitlab runner under a corresponding operating system to execute the task corresponding to the task type identifier according to the task type identifier;
and skipping the task when the preset trigger condition of the task is not met.
Optionally, when a preset trigger condition of a task of the windows system is release of a target item;
and when the preset trigger condition of the tasks of the macos system is the release of the target item.
Specifically, when the tasks corresponding to the systems are set, the triggering conditions of the tasks can be set to control the triggering of the tasks. For example, three tasks are configured separately in the persistent integrated script, one task is a linux system task, one task is a windows system task, one task is a macos system task, and the last two tasks only have specific branches, and specific machines (the windows system and the machines with the built-up gilab runner under the macos system) can execute and cannot be triggered automatically. In this way, when the developer develops at ordinary times, only the first task is used to verify stability, and the testing of the basic function is completely sufficient. When a version of an item is to be published, the correctness of tasks at the windows and the macos system must be verified before the release because the version must be published at a specific branch (the windows system branch and the macos system branch). At this point, the two tasks would be assigned to a particular windows system machine and a macos system machine to execute. The machine may be a host or a server.
The number of online times can be converged by the front end. The project for deploying the end-to-end test can be provided with a version online mechanism, and the online times are controlled through the version, so that the end-to-end test verification of the windows system and the macos system is only required to be carried out before the version is transmitted, and the resource consumption of the machine is reduced.
Alternatively, in front-end project installation, the directory of project dependent files may be linked to a specific directory (such as a desktop) in the global by setting a soft link (ln-s) for the linux system and the macos system. However, there is no ln command on the windows system, and the corresponding substitute command mklink of the windows system is removed by the gitlab runner when a new task is created. To solve this problem, the soft chain may be first removed after the script is executed. Avoiding the erroneous deletion by the window's gitlab runner, and reducing the repeated installation of the dependent file.
It should be noted that, each of the embodiments of the present disclosure may be implemented separately, or may be implemented in any combination without conflict, which is not limited to the embodiments of the present disclosure.
According to the test processing method provided by the embodiment of the disclosure, the continuous integrated script comprises at least one task information, each task corresponds to one type of the gitlab runner of the operating system, so that the target gitlab runner under the corresponding operating system can be called according to the task type identifier to execute task content during test, automatic test on the project under the environments of the windows system and the macos system is realized, and the online performance of the project issued under the environments of the windows system and the macos system is effectively ensured. And by extracting common variables under a plurality of platform environments, the flexibility and the expansibility of cross-system platform testing based on the automatic test of the gitlab are improved. The number of online times is converged through the front end. The project for deploying the end-to-end test can be provided with a version online mechanism, and the online times are controlled through the version, so that the end-to-end test verification of the windows system and the macos system is only required to be carried out before the version is transmitted, and the resource consumption of the machine is reduced.
Yet another embodiment of the present disclosure provides a test handler for performing the method of the above embodiment. The processing device for the test may be located in a server, in particular in a server where the gitlab ci is located.
Fig. 3 is a schematic structural diagram of a test processing device according to an embodiment of the disclosure. The processing means 30 of the test comprise an acquisition module 31 and a calling module 32.
The system comprises an acquisition module, a task type identification module and a task type identification module, wherein the acquisition module is used for acquiring a continuous integrated script corresponding to a target item, the continuous integrated script comprises at least one task information, the task information comprises task type identifications and task contents corresponding to the task type identifications, and each task type identification corresponds to a type of gitlab runner of an operating system; and the calling module is used for calling the target gitlab runner under the corresponding operating system to execute the task content according to the task type identifier.
The specific manner in which the various modules perform the operations in connection with the apparatus of the embodiments of the present disclosure have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.
According to the test processing device provided by the embodiment of the disclosure, at least one task information is included through the continuous integrated script, each task corresponds to a type of the gitlab runner of the operating system, so that the target gitlab runner under the corresponding operating system can be called according to the task type identifier to execute task content during test, automatic test on the project under the environments of the windows system and the macos system is realized, and the performance of the project on line released under the environments of the windows system and the macos system is effectively ensured.
A further embodiment of the present disclosure further provides a device provided by the foregoing embodiment, so as to perform the method provided by the foregoing embodiment.
As an implementation manner, on the basis of the foregoing embodiment, optionally, the obtaining module is further configured to obtain, according to the task type identifier, an environment dependent package of the target gitlab runner, where the environment dependent package includes parameters corresponding to environment variables of the target gitlab runner; and the calling module is also used for sending the environment dependency package to the target gitlab runner so that the target gitlab runner configures environment variables of the target gitlab runner according to the environment dependency package.
As another implementation manner, based on the foregoing embodiment, optionally, the obtaining module is further configured to obtain, according to the task type identifier, a storage address of an environment-dependent packet of the target gitlab runner, where the environment-dependent packet includes a parameter corresponding to an environment variable of the target gitlab runner; and the calling module is also used for sending the storage address of the environment dependent packet to the target gitlab runner so that the target gitlab runner obtains the environment dependent packet according to the storage address of the environment dependent packet and configures the environment variable of the target gitlab runner according to the environment dependent packet.
As another implementation manner, on the basis of the foregoing embodiment, optionally, the obtaining module is further configured to receive a registration request of the target gitlab runner, where the registration request includes a type of an operating system of the target gitlab runner; the acquisition module is also used for generating the identification information of the target gillab runner and feeding back the identification information to the target gillab runner; and the calling module is also used for recording the identification information of the target gitlab runner and the type of the operating system.
As another implementation manner, on the basis of the foregoing embodiment, optionally, the task information further includes a preset trigger condition of the task, and the calling module is specifically configured to:
judging whether a preset trigger condition of a task is met currently for each task;
when a preset trigger condition of a task is met, calling a target gitlab runner under a corresponding operating system to execute the task corresponding to the task type identifier according to the task type identifier;
and skipping the task when the preset trigger condition of the task is not met.
Optionally, when a preset trigger condition of a task of the windows system is release of a target item;
and when the preset trigger condition of the tasks of the macos system is the release of the target item.
As another implementation manner, the types of the operating systems may optionally include windows systems, macos systems and linux systems based on the above embodiments.
The specific manner in which the various modules perform the operations in connection with the apparatus of the embodiments of the present disclosure have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.
It should be noted that, each of the embodiments of the present disclosure may be implemented separately, or may be implemented in any combination without conflict, without limiting the disclosure.
According to the processing device for testing, the continuous integrated script comprises at least one task information, each task corresponds to one type of the gitlab runner of the operating system, so that the target gitlab runner under the corresponding operating system can be called according to the task type identification to execute task content during testing, automatic testing of the project under the environments of the windows system and the macos system is achieved, and the performance of the project on line released under the environments of the windows system and the macos system is effectively guaranteed. And by extracting common variables under a plurality of platform environments, the flexibility and the expansibility of cross-system platform testing based on the automatic test of the gitlab are improved. The number of online times is converged through the front end. The project for deploying the end-to-end test can be provided with a version online mechanism, and the online times are controlled through the version, so that the end-to-end test verification of the windows system and the macos system is only required to be carried out before the version is transmitted, and the resource consumption of the machine is reduced.
Still another embodiment of the present disclosure provides an electronic device configured to perform the method provided in the foregoing embodiment. The electronic device may be a server, such as a gitlab ci server.
Fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the disclosure. The electronic device 50 includes: at least one processor 51 and a memory 52;
the memory stores a computer program; at least one processor executes the computer program stored in the memory to implement the methods provided by the above embodiments.
According to the electronic device disclosed by the embodiment of the invention, through continuously integrating the script to include at least one task information, each task corresponds to the gitlab runner of one type of operating system, so that the target gitlab runner under the corresponding operating system can be called according to the task type identifier to execute the task content during testing, the automatic testing of the project under the environments of the windows system and the macos system is realized, and the online performance of the project issued under the environments of the windows system and the macos system is effectively ensured. And by extracting common variables under a plurality of platform environments, the flexibility and the expansibility of cross-system platform testing based on the automatic test of the gitlab are improved. The number of online times is converged through the front end. The project for deploying the end-to-end test can be provided with a version online mechanism, and the online times are controlled through the version, so that the end-to-end test verification of the windows system and the macos system is only required to be carried out before the version is transmitted, and the resource consumption of the machine is reduced.
As an exemplary embodiment, optionally, as shown in fig. 5, an exemplary structural schematic diagram of an electronic device is provided in an embodiment of the disclosure. The electronic device 800 may include a processing means (e.g., a central processor, a graphics processor, etc.) 801 that may perform various appropriate actions and processes in accordance with programs stored in a Read Only Memory (ROM) 802 or loaded from a storage 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the electronic device 800 are also stored. The processing device 801, the ROM 802, and the RAM 803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to the bus 804.
In general, the following devices may be connected to the I/O interface 805: input devices 806 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 807 including, for example, a Liquid Crystal Display (LCD), speakers, vibrators, etc.; storage 808 including, for example, magnetic tape, hard disk, etc.; communication means 809. The communication means 809 may allow the electronic device 800 to communicate wirelessly or by wire with other devices to exchange data. While fig. 5 shows an electronic device 800 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via communication device 809, or installed from storage device 808, or installed from ROM 802. The above-described functions defined in the methods of the embodiments of the present disclosure are performed when the computer program is executed by the processing device 801.
It should be noted that the computer readable medium described in the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this disclosure, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present disclosure, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.
Yet another embodiment of the present disclosure provides a computer readable storage medium having a computer program stored therein, which when executed implements the method provided by any of the above embodiments.
According to the computer readable storage medium, at least one task information is included through the continuous integrated script, each task corresponds to a type of the gitlab runner of the operating system, so that the target gitlab runner under the corresponding operating system can be called according to the task type identifier to execute task content during testing, automatic testing of the project under the environments of the windows system and the macos system is achieved, and the performance of the project on line released under the environments of the windows system and the macos system is effectively guaranteed. And by extracting common variables under a plurality of platform environments, the flexibility and the expansibility of cross-system platform testing based on the automatic test of the gitlab are improved. The number of online times is converged through the front end. The project for deploying the end-to-end test can be provided with a version online mechanism, and the online times are controlled through the version, so that the end-to-end test verification of the windows system and the macos system is only required to be carried out before the version is transmitted, and the resource consumption of the machine is reduced.
In the several embodiments provided in the present disclosure, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purposes of the embodiments of the present disclosure.
In addition, each functional unit in each embodiment of the present disclosure may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in hardware plus software functional units.
The integrated units implemented in the form of software functional units described above may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium, and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform part of the steps of the methods described in the embodiments of the disclosure. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above. The specific working process of the above-described device may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present disclosure, and not for limiting the same; although the present disclosure has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present disclosure.

Claims (7)

1. A method of processing a test, comprising:
acquiring a continuous integrated script corresponding to a target item, wherein the continuous integrated script comprises at least one task information, the task information comprises task type identifiers and task contents corresponding to the task type identifiers, and each task type identifier corresponds to a script executor of an operating system of one type; the script executor comprises a gitlab runner, and the types of the operating systems comprise windows systems, macos systems and linux systems;
according to the task type identifier, calling a target script executor under a corresponding operating system to execute the task content;
before the target script executor under the corresponding operating system is called to execute the task content according to the task type identifier, the method further comprises the following steps:
acquiring an environment dependency package of the target script executor according to the task type identifier, wherein the environment dependency package comprises parameters corresponding to environment variables of the target script executor;
sending the environment dependent package to the target script executor so that the target script executor configures environment variables of the target script executor according to the environment dependent package;
or alternatively, the process may be performed,
before the target script executor under the corresponding operating system is called to execute the task content according to the task type identifier, the method further comprises the following steps:
acquiring a storage address of an environment dependent package of the target script executor according to the task type identifier, wherein the environment dependent package comprises parameters corresponding to environment variables of the target script executor;
and sending the storage address of the environment-dependent package to the target script executor so that the target script executor obtains the environment-dependent package according to the storage address of the environment-dependent package, and configuring the environment variable of the target script executor according to the environment-dependent package.
2. The method of claim 1, wherein before invoking the target script executor under the corresponding operating system to execute the task content based on the task type identification, the method further comprises:
receiving a registration request of the target script executor, wherein the registration request comprises the type of an operating system of the target script executor;
generating identification information of the target script executor and feeding back the identification information to the target script executor;
and recording the identification information of the target script executor and the type of the operating system.
3. The method of claim 1, wherein the task information further comprises a preset trigger condition of a task;
and calling a target script executor under a corresponding operating system to execute the task content according to the task type identifier, wherein the method comprises the following steps:
judging whether a preset trigger condition of each task is met currently for each task;
when the preset trigger condition of the task is met, according to the task type identifier, a target script executor under a corresponding operating system is called to execute the task corresponding to the task type identifier;
and skipping the task when the preset trigger condition of the task is not met.
4. A method according to claim 3, wherein the predetermined trigger condition for the task of the microsoft operating system is when the target item is published;
and when the target item is released, the preset trigger condition of the task of the apple operating system is the release of the target item.
5. A test handler, comprising:
the system comprises an acquisition module, a script execution module and a script execution module, wherein the acquisition module is used for acquiring a continuous integrated script corresponding to a target item, the continuous integrated script comprises at least one task information, the task information comprises task type identifiers and task contents corresponding to the task type identifiers, and each task type identifier corresponds to a script executor of one type of operating system; the script executor comprises a gitlab runner, and the types of the operating systems comprise windows systems, macos systems and linux systems;
the calling module is used for calling a target script executor under a corresponding operating system to execute the task content according to the task type identifier;
the acquisition module is further used for acquiring an environment dependent package of the target script executor according to the task type identifier, wherein the environment dependent package comprises parameters corresponding to environment variables of the target script executor; the calling module is further used for sending the environment dependent package to the target script executor so that the target script executor configures environment variables of the target script executor according to the environment dependent package;
or alternatively, the process may be performed,
the acquisition module is further used for acquiring a storage address of an environment dependent package of the target script executor according to the task type identifier, wherein the environment dependent package comprises parameters corresponding to environment variables of the target script executor; the calling module is also used for sending the storage address of the environment-dependent package to the target script executor so that the target script executor can acquire the environment-dependent package according to the storage address of the environment-dependent package and can configure the environment variable of the target script executor according to the environment-dependent package.
6. An electronic device, comprising: at least one processor and memory;
the memory stores a computer program; the at least one processor executes the computer program stored by the memory to implement the method of any one of claims 1-4.
7. A computer readable storage medium, characterized in that it has stored therein a computer program which, when executed, implements the method of any of claims 1-4.
CN201910396921.7A 2019-05-14 2019-05-14 Test processing method and device, electronic equipment and storage medium Active CN110096424B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910396921.7A CN110096424B (en) 2019-05-14 2019-05-14 Test processing method and device, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910396921.7A CN110096424B (en) 2019-05-14 2019-05-14 Test processing method and device, electronic equipment and storage medium

Publications (2)

Publication Number Publication Date
CN110096424A CN110096424A (en) 2019-08-06
CN110096424B true CN110096424B (en) 2023-08-22

Family

ID=67447907

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910396921.7A Active CN110096424B (en) 2019-05-14 2019-05-14 Test processing method and device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN110096424B (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111144839B (en) * 2019-12-17 2024-02-02 深圳市优必选科技股份有限公司 Project construction method, continuous integration system and terminal equipment
CN111488136A (en) * 2020-04-07 2020-08-04 携程旅游网络技术(上海)有限公司 Continuous integration and continuous delivery method, system, device and storage medium
CN111782186A (en) * 2020-07-03 2020-10-16 携程旅游网络技术(上海)有限公司 Workflow management method, system, device and storage medium
CN111913884A (en) * 2020-07-30 2020-11-10 百度在线网络技术(北京)有限公司 Distributed test method, device, equipment, system and readable storage medium
CN113515707B (en) * 2020-09-21 2024-02-09 腾讯科技(深圳)有限公司 Data processing method, intelligent device, intelligent equipment and storage medium
CN112181816B (en) * 2020-09-22 2023-06-02 建信金融科技有限责任公司 Scene-based interface testing method and device, computer equipment and medium
CN112115056A (en) * 2020-09-23 2020-12-22 北京达佳互联信息技术有限公司 Project deployment method and device, server and storage medium
CN113872811A (en) * 2021-09-29 2021-12-31 中国建设银行股份有限公司 Operation change method, wide area network control system, electronic device, and storage medium

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103577907A (en) * 2012-07-24 2014-02-12 阿里巴巴集团控股有限公司 Continuous integration testing method and system
CN104298588A (en) * 2013-07-16 2015-01-21 阿里巴巴集团控股有限公司 Continuous integration implementation method and device
CN108733553A (en) * 2017-04-18 2018-11-02 北京嘀嘀无限科技发展有限公司 Configuration method, the device and system of test device based on docker
CN109408382A (en) * 2018-10-11 2019-03-01 网宿科技股份有限公司 A kind of continuous integrating method and continuous integration system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10162735B2 (en) * 2015-09-30 2018-12-25 Red Hat, Inc. Distributed system test automation framework

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103577907A (en) * 2012-07-24 2014-02-12 阿里巴巴集团控股有限公司 Continuous integration testing method and system
CN104298588A (en) * 2013-07-16 2015-01-21 阿里巴巴集团控股有限公司 Continuous integration implementation method and device
CN108733553A (en) * 2017-04-18 2018-11-02 北京嘀嘀无限科技发展有限公司 Configuration method, the device and system of test device based on docker
CN109408382A (en) * 2018-10-11 2019-03-01 网宿科技股份有限公司 A kind of continuous integrating method and continuous integration system

Also Published As

Publication number Publication date
CN110096424A (en) 2019-08-06

Similar Documents

Publication Publication Date Title
CN110096424B (en) Test processing method and device, electronic equipment and storage medium
US10127057B2 (en) Method and apparatus for dynamically implementing application function
US9386079B2 (en) Method and system of virtual desktop infrastructure deployment studio
US9582261B2 (en) Methods and apparatus to update application deployments in cloud computing environments
US10592312B2 (en) Message oriented middleware with integrated rules engine
EP3014435A1 (en) Hook framework
CN110673923A (en) XWIKI system configuration method, system and computer equipment
CN112015654A (en) Method and apparatus for testing
CN109828830B (en) Method and apparatus for managing containers
CN110727575B (en) Information processing method, system, device and storage medium
CN114546588A (en) Task deployment method and device, storage medium and electronic device
US20230239212A1 (en) Stable References for Network Function Life Cycle Management Automation
US11243868B2 (en) Application containerization based on trace information
CN112685040A (en) Method, device, equipment and storage medium for generating interface file in android system
CN113760306A (en) Method and device for installing software, electronic equipment and storage medium
CN104111862A (en) Method and system for obtaining IP (Internet Protocol) address of virtual machine in cloud computing platform
US10073689B2 (en) Managing application lifecycles within a federation of distributed software applications
CN109933355B (en) Application program upgrading method and device
CN116049000A (en) Environment parameter configuration method, device, equipment, storage medium and product
US11425203B2 (en) Commissioning a virtualized network function
WO2023084345A1 (en) Automated deployment of enterprise archive with dependency on application server via script
CN115237441A (en) Upgrade test method, device and medium based on cloud platform
CN114936152A (en) Application testing method and device
CN117112122A (en) Cluster deployment method and device
US9787552B2 (en) Operation process creation program, operation process creation method, and information processing device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant