An acceptance method, device and equipment based on configuration coding

Abstract

This specification discloses an acceptance method, apparatus, and device based on configuration code. It involves obtaining a configuration code file from an isolated environment; compiling the configuration code file based on a predefined acceptance model to generate a management configuration file; performing tests according to the management configuration file and generating test results; obtaining acceptance rules; and performing product acceptance based on the test results according to the acceptance rules. This achieves configuration code-based product processing and transmission within an isolated environment, enabling automatic acceptance in an isolated environment by requiring only user configuration of the corresponding product's configuration code.

Description

Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to an acceptance method, apparatus, and device based on configuration coding. Background Technology

[0002] With the development of private cloud technology, more and more workloads are migrating from on-premises data centers to the private cloud, and more and more products need to be deployed in the isolated environment of the private cloud. As a result, the product delivery and acceptance process requires on-site product acceptance for several weeks or even months. This is not only time-consuming and labor-intensive, but also carries various stability risks caused by human error during acceptance. Furthermore, this acceptance process is repeated when delivery and deployment need to be carried out in a new isolated environment.

[0003] Therefore, a more convenient product acceptance method is needed. Summary of the Invention

[0004] This specification provides an acceptance method, apparatus, device, and storage medium based on configuration coding to address the following technical problem: the need for a more convenient product acceptance scheme.

[0005] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows:

[0006] In a first aspect, embodiments of this specification provide an acceptance method based on configuration code, comprising: obtaining a configuration code file from an isolated environment; compiling the configuration code file based on a predefined acceptance model to generate a management configuration file; performing tests according to the management configuration file and generating test results; obtaining acceptance rules, and performing product acceptance on the test results according to the acceptance rules.

[0007] In a second aspect, embodiments of this specification provide an acceptance device based on configuration code, comprising: an acquisition module for acquiring configuration code files from an isolated environment; a compilation module for compiling the configuration code files based on a predefined acceptance model to generate a management configuration file; an execution module for performing tests according to the management configuration file and generating test results; and an acceptance module for acquiring acceptance rules and performing product acceptance on the test results according to the acceptance rules.

[0008] In a third aspect, embodiments of this specification provide an electronic device, including:

[0009] At least one processor; and,

[0010] A memory communicatively connected to the at least one processor; wherein,

[0011] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in the first aspect.

[0012] In a fourth aspect, embodiments of this specification provide a non-volatile computer storage medium storing computer-executable instructions, which, when read by a computer from the storage medium, cause one or more processors to perform the method described in the first aspect.

[0013] The above-described at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: by obtaining configuration code files from an isolated environment; compiling the configuration code files based on a predefined acceptance model to generate a management configuration file; performing tests according to the management configuration file and generating test results; obtaining acceptance rules; and performing product acceptance on the test results according to the acceptance rules, thereby realizing the coding of product configuration and transmission in an isolated environment. Thus, users only need to configure the configuration code files of the corresponding products to achieve automatic acceptance in an isolated environment, which is more convenient. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This specification provides a schematic diagram of a configuration-based coding process for an embodiment of the invention.

[0016] Figure 2 This is a schematic diagram illustrating a product acceptance framework provided in an embodiment of this specification.

[0017] Figure 3 A timing diagram illustrating a batch acceptance process provided in an embodiment of this specification;

[0018] Figure 4 A schematic diagram of an acceptance device based on configuration coding is provided for an embodiment of this specification;

[0019] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. Detailed Implementation

[0020] This specification provides an acceptance method, apparatus, device, and storage medium based on configuration coding.

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0022] An isolated environment refers to an environment where network access is isolated and information can only be transmitted through physical storage media. This network access isolation can be bidirectional, that is, network access isolation between the service provider and the product provider, or network access isolation between the product provider and the service provider.

[0023] Network access isolation between the service provider and the product provider means that the product cannot directly access the environment provided by the service provider. For example, the service provider offers a private cloud environment to the product provider. In this private cloud environment, the service provider isolates its hardware and software resources to serve the product provider. However, during product development, the product provider may be aware of the relevant environment information of the private cloud, but may not be able to directly access the private cloud environment. Network access isolation between the product provider and the service provider may also include situations where the product provider itself is developing its product in a network-isolated environment. For example, in some confidential scenarios, the product provider's access to the outside network is physically isolated.

[0024] In the aforementioned isolated environment, the product provider can know the execution environment involved in the product's actual operation. However, during development, a good simulation environment may not be available, and the execution environment may change (for example, the resource environment provided by a private cloud may change). Therefore, using conventional product acceptance methods becomes very inconvenient. Based on this, this specification provides an acceptance scheme based on configuration coding.

[0025] like Figure 1 As shown, Figure 1 This specification provides a schematic diagram of a configuration-based code-based process in an embodiment. Figure 1 The process may include the following steps:

[0026] S101, retrieves configuration code files from the isolated environment.

[0027] Configuration code files can be generated by the product provider based on a predefined code configuration model, according to information such as software, hardware, network, and database involved in the product's runtime.

[0028] Specifically, the service provider can pre-deploy a configuration code repository containing code corresponding to various resource configurations (including the aforementioned software, hardware, network, and database configurations) for different products and environments. A front-end model can also be pre-developed, allowing users to select the various software and hardware configurations relevant to their product. Based on the user's configured environment information and the corresponding code in the configuration code repository, a configuration code file is then generated.

[0029] In other words, the configuration code file represents the execution environment information involved in the product's runtime. This execution environment information includes software information (e.g., operating system type), hardware information (e.g., server model, server hardware performance, etc.), network information, and database type, etc., that may be involved in the product's runtime. Furthermore, the configuration code file can also represent some custom dynamic parameters, such as the image address of the use case, environment variables, machine specifications, and startup commands, etc.

[0030] This process can be achieved using common configuration code tools, such as the open-source configuration code tool Kusion. For example, a front-end model can be developed using Kusion, and the product team can configure the execution environment information and dynamic parameters involved in the product based on the front-end model. The front-end model can then generate configuration code files based on the execution environment information and dynamic parameters configured by the product team.

[0031] S103, Compile the configuration code file based on the predefined acceptance model to generate a management configuration file.

[0032] The acceptance model is also based on the configuration code repository pre-developed by the service provider. Its function is to compile the configuration code file to obtain the execution environment information and dynamic information corresponding to the configuration code file, and write this information into the management configuration file. That is, the management configuration file contains the execution environment information of the product to be accepted.

[0033] For example, the service provider can develop an acceptance model (e.g., a Kubernetes Job) using a code-based approach based on the aforementioned configuration code repository, serving as the backend model corresponding to the aforementioned frontend model. They can also create an acceptance service application (provider). Upon receiving the configuration code file, the acceptance model (or backend model) can compile and generate a corresponding Job YAML management configuration file. This Job YAML management configuration file contains the execution environment information corresponding to the configuration code file and the amount of resources used when executing the test task.

[0034] In one implementation, in addition to configuring the execution environment for the product to generate configuration code files, the product vendor also needs to migrate the test cases involved in the product to an isolated environment. For example, this involves migrating the test cases to a mirror repository and generating the corresponding test case addresses.

[0035] Test cases correspond to specific functional modules in a product. For example, a product may have functions A and B during runtime. During development, test case A corresponding to function A and test case B corresponding to function B can be developed. These test cases can run in different execution environments (i.e., different software and hardware environments), thus producing different execution results.

[0036] Furthermore, before compiling and generating the management configuration file, a result receiving address can be obtained. For example, the domain name of the acceptance platform can be obtained from the acceptance platform, and this domain name can be used as the result receiving address. This address is used to receive the test results generated by executing test tasks. Both the aforementioned test case address and the result receiving address can be written into the management configuration file along with the execution environment information during the compilation process.

[0037] S105, Perform tests according to the management configuration file and generate test results.

[0038] As mentioned earlier, the management configuration file contains the execution environment information corresponding to the configuration code file and the amount of resources used when executing the test task. In essence, it defines the resources used when executing the test task. At this point, the management configuration file can be deployed to the cluster of test equipment to create corresponding test tasks and generate test results.

[0039] When the cluster of test equipment creates a corresponding task, it will generate a corresponding number of execution resource pools according to the official configuration file. After the task is completed, it will exit but will not be deleted. You can check the relevant logs to understand the completion status of the task.

[0040] For example, the cluster of testing equipment can use a Kubernetes (K8S) cluster. In a K8S cluster, the execution resource pool is the Pod. A Pod is the smallest unit that can be created, scheduled, and managed, and each Pod has an independent IP address. A Pod can run one or more containers (Docker). Any two Pods can communicate with each other, and containers within the same Pod share the Pod's file system and network.

[0041] The file system and network environment contained in the execution resource pool (Pod) can be created based on execution information. Pods can request the corresponding amount of resources from the cluster based on the execution environment information given in the management configuration file to ensure that the execution environment information of the created Pod is the same as the execution environment information corresponding to the configuration code file.

[0042] For example, a management configuration file may include the following information: the maximum number of resources that can be allocated to the execution resource pool, including the maximum amount of computing resources, storage resources, and memory resources that can be allocated; and the execution environment information requested by the execution resource pool, including the computing resources, storage resources, and memory resources requested by the execution resource pool, etc. Obviously, in general, the execution information requested by the execution resource pool will not exceed the maximum number of allocable resources to avoid execution errors.

[0043] Then, the test cases can be executed in the execution resource pool (Pod). Specifically, the execution environment information is obtained from the management configuration file, and a corresponding execution resource pool is created based on the execution environment information; the test cases are pulled from the test case address to the execution resource pool for execution, and test results are generated.

[0044] In practical applications, after the cluster obtains the management configuration file Job Yaml, it creates a corresponding test task. In the test task, multiple execution resource pools (Pods) are created based on the configuration. The file system and execution environment information of the execution resource pools have been given by the Job Yaml. In addition, whether the multiple Pods run in parallel or serial mode can also be given in the Job Yaml through pre-configuration.

[0045] For each execution resource pool, there is a certain execution time (e.g., 2 minutes). When the time expires or the execution is completed, the execution resource pool will terminate.

[0046] There are usually multiple test cases, and an execution resource pool can pull these multiple test cases into the execution resource pool for sequential execution. For example, the cluster device creates multiple parallel execution resource pools based on the configuration of the management configuration file, and pulls multiple test cases into the parallel execution resource pools for parallel execution. Alternatively, the cluster device creates multiple serial execution resource pools, and pulls multiple test cases into the serial execution resource pools for sequential execution.

[0047] After the test task is completed in the cluster device, the execution resource pool is terminated, and the corresponding test results can be obtained from the relevant logs.

[0048] In addition, when the management configuration file contains a result receiving address (usually the domain name of the acceptance platform), the test results generated by the cluster device executing the test task can also be directly sent to the result receiving address, so that the acceptance party can directly obtain the test results and carry out subsequent acceptance.

[0049] S107, Obtain the acceptance rules, and perform product acceptance based on the test results according to the acceptance rules.

[0050] Acceptance rules can be pre-defined by the service provider or pre-configured by the product provider. For example, pre-configured acceptance rules by the product provider might include: the execution time of test tasks does not exceed the preset total time; the average execution time of test cases does not exceed the preset average time; and the pass rate of test cases is not lower than the preset pass rate. Acceptance rules pre-defined by the service provider might include: the number of test cases is not lower than a preset value; and the individual file size of a test case is not lower than a preset file size.

[0051] The acceptance rules configured by the service provider or product provider can be pre-published in the acceptance platform or the corresponding database. The test results generated by the cluster devices executing test tasks can be called back to the acceptance platform, so that the product can be accepted based on the test results in the acceptance platform according to the acceptance rules.

[0052] like Figure 2 As shown, Figure 2 This is a schematic diagram illustrating a product acceptance framework provided in an embodiment of this specification. The product provider migrates the configuration code files corresponding to the product to be accepted to an isolated acceptance platform, and simultaneously migrates the test cases to an image repository. The caller retrieves the configuration code files from the platform and starts a predefined acceptance service (provider) based on the configuration code repository (konfig). This service compiles and generates a management configuration file (Job Yaml) containing execution environment information. The cluster then creates an execution resource pool (Pod) containing the corresponding execution environment based on the Job Yaml, pulls the test cases contained in the image repository, executes them in the Pod to generate test results, and sends the test results back to the acceptance platform. The acceptance platform performs product acceptance based on preset acceptance rules and generates acceptance results.

[0053] The generated acceptance results can be further subdivided based on the granularity of the acceptance process. For example, the acceptance result can be "pass" or "fail," or it can specify at a finer granularity which parts passed and which parts failed, such as a low pass rate for test cases or a test case exceeding its total duration. The generated acceptance results can be stored locally on the acceptance platform or persistently in a database for later retrieval.

[0054] By obtaining configuration code files from an isolated environment; compiling the configuration code files based on a predefined acceptance model to generate a management configuration file; performing tests according to the management configuration file and generating test results; obtaining acceptance rules; and performing product acceptance based on the test results according to the acceptance rules, the product configuration is coded and transmitted in an isolated environment. This allows users to configure the corresponding product configuration code, enabling automatic acceptance in an isolated environment, which is more convenient.

[0055] In one implementation, when obtaining execution environment information from the management configuration file and creating a corresponding execution resource pool based on the execution environment information, the number of execution resource pools created can be determined based on the number of test cases. That is, when writing the test case address into the management configuration file, the number of test cases is also included. In this way, the cluster device can determine the number of test cases corresponding to the test case address when creating an execution resource pool; obtain the execution environment information from the management configuration file; and create an execution resource pool containing the execution environment information, with the same number of test cases as the specified number of pools.

[0056] Therefore, when executing test tasks, test cases can be matched one-to-one with execution resource pools. That is, each execution resource pool executes one test case. In this way, regardless of the number of test cases contained in a test task, the cluster devices can always guarantee that the test cases will be completed within one duration period (usually 2 minutes) of the execution resource pool, thus improving testing efficiency when there are many test tasks.

[0057] In one implementation, when there are many products to be accepted, the service provider can make regular calls and batch process multiple products to be accepted.

[0058] In this implementation, the acceptance platform typically receives multiple configuration code files. The service provider can then initiate regular calls to the acceptance platform, using the identifier of the product to be accepted (usually AppName or AppId, etc.) as a trace identifier (similar to a traceid) to represent the corresponding configuration code file, subsequent test tasks, and test results. During compilation to generate the management configuration file, management configuration files corresponding to multiple test tasks can be generated (for example, multiple test tasks can be controlled by a single JobYaml file), where each test task corresponds one-to-one with the configuration code file.

[0059] Furthermore, when testing according to the management configuration file and generating test results, multiple independent execution resource pools can be created based on the management configuration file. Tests are then executed on the multiple test tasks within these multiple independent execution resource pools, generating multiple test results. That is, there is a one-to-one correspondence between execution resource pools and test tasks; each independent execution resource pool executes one corresponding test task, thereby generating multiple test results, which are then returned to the acceptance platform. The service provider can initiate a polling process with the acceptance platform, polling for the acceptance results corresponding to the multiple configuration code files based on the identifiers of the products to be accepted, and storing the acceptance results. This method allows for routine batch processing of multiple uploaded products to be accepted, achieving fully automated batch processing of a large number of configuration code files to be accepted, thus improving efficiency.

[0060] like Figure 3 As shown, Figure 3 This diagram illustrates a timing sequence for batch acceptance testing as provided in an embodiment of this specification. In this diagram, the acceptance caller starts the acceptance service provider using the configuration code tool Kusion. The acceptance service provider then initiates a call to the configuration code repository based on the obtained configuration code file, obtains the platform domain name from the acceptance platform as the result collection address, and compiles a JobYaml management configuration file based on the configuration code file and the pre-configured configuration in the configuration code repository, which is then deployed to the K8S cluster.

[0061] The Kubernetes cluster generates corresponding execution resource pools and performs test tasks according to the management configuration file, generates test results, and uploads them to the acceptance platform. The acceptance platform verifies the test results based on pre-configured acceptance rules, generates acceptance results, and stores them in the database. The acceptance caller continuously polls the acceptance platform for the acceptance results, thus automatically achieving batch acceptance of configuration code files for multiple products awaiting acceptance.

[0062] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 4 , Figure 5 As shown.

[0063] In the second aspect, such as Figure 4 As shown, Figure 4 This specification provides a schematic diagram of an acceptance device based on configuration coding, which includes:

[0064] Module 401 retrieves the configuration code file from the isolated environment;

[0065] Compilation module 403 compiles the configuration code file based on the predefined acceptance model to generate a management configuration file;

[0066] Execution module 405 performs tests according to the management configuration file and generates test results;

[0067] Acceptance module 407 obtains acceptance rules and performs product acceptance based on the test results according to the acceptance rules.

[0068] Optionally, the device further includes a migration module 409, which generates a configuration code file based on a preset front-end model and according to the execution environment information; migrates the configuration code file to the isolation environment using an isolation medium; and the acquisition module 402 acquires the migrated configuration code file from the isolation environment.

[0069] Optionally, the compilation module 403 obtains the test case address and the result receiving address; compiles the configuration code file based on the predefined acceptance model, determines the execution environment information corresponding to the configuration code file, and generates a management configuration file containing the execution environment information, the test case address, and the result receiving address.

[0070] Optionally, the execution module 405 obtains execution environment information from the management configuration file, creates a corresponding execution resource pool based on the execution environment information, pulls test cases from the test case address to the execution resource pool for execution, and generates test results.

[0071] Optionally, the execution module 405 determines the number of test cases corresponding to the test case address; obtains execution environment information from the management configuration file, and creates an execution resource pool containing the execution environment information that is the same as the number of test cases.

[0072] Optionally, the device further includes a sending module 411 for sending the test results to the result receiving address.

[0073] Optionally, when there are multiple configuration code files, the compilation module 403 generates management configuration files corresponding to multiple test tasks, wherein each test task corresponds one-to-one with a configuration code file; correspondingly, the execution module 405 creates multiple independent execution resource pools according to the management configuration files, performs tests on the multiple test tasks in the multiple independent execution resource pools, and generates multiple test results; correspondingly, the device further includes a polling module 413, which polls the acceptance results corresponding to the multiple configuration code files.

[0074] In the third aspect, such as Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. The device includes:

[0075] At least one processor; and,

[0076] A memory communicatively connected to the at least one processor; wherein,

[0077] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in the first aspect.

[0078] In a fourth aspect, based on the same idea, embodiments of this specification also provide a non-volatile computer storage medium corresponding to the above method, storing computer-executable instructions, which, when read by a computer from the storage medium, cause one or more processors to execute the method described in the first aspect.

[0079] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0080] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0081] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0082] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0083] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0084] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0085] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0086] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0087] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0088] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0089] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0090] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0091] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0092] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0093] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0094] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. An acceptance method based on configuration coding, applied to an isolated environment where network access is isolated and information can only be transmitted through physical storage media, the method comprising: Obtaining configuration code files from an isolated environment includes: generating configuration code files based on a preset front-end model and execution environment information; migrating the configuration code files to the isolated environment using an isolation medium; and obtaining the migrated configuration code files from the isolated environment. The configuration code file is compiled based on a predefined acceptance model to generate a management configuration file; Perform tests based on the management configuration file and generate test results; Obtain the acceptance rules and conduct product acceptance based on the test results according to the acceptance rules.

2. The method as described in claim 1, wherein, The configuration code file is compiled based on a predefined acceptance model to generate the managed configuration file, including: Obtain the test case address and result receiving address; The configuration code file is compiled based on the predefined acceptance model to determine the execution environment information corresponding to the configuration code file; Generate a management configuration file containing the execution environment information, test case addresses, and result collection addresses.

3. The method as described in claim 2, wherein, Tests are performed based on the management configuration file, and test results are generated, including: Obtain execution environment information from the management configuration file, and create a corresponding execution resource pool based on the execution environment information; The test cases are retrieved from the test case address and executed in the execution resource pool to generate test results.

4. The method of claim 3, wherein, Obtain execution environment information from the management configuration file, and create a corresponding execution resource pool based on the execution environment information, including: Determine the number of test cases corresponding to the test case address; Obtain execution environment information from the management configuration file, and create an execution resource pool containing the execution environment information, with the same number of test cases as the number of test cases.

5. The method of claim 3, wherein, The method further includes: Send the test results to the result receiving address.

6. The method of claim 1, wherein, When there are multiple configuration code files, a management configuration file is generated, including: Generate management configuration files corresponding to multiple test tasks, wherein each test task corresponds one-to-one with the configuration code file; Accordingly, testing and generating test results according to the management configuration file includes: creating multiple independent execution resource pools according to the management configuration file, executing tests on the multiple test tasks in the multiple independent execution resource pools, and generating multiple test results; Accordingly, the method further includes: polling the acceptance results corresponding to the plurality of configuration code files.

7. An acceptance device based on configuration coding, applied to an isolated environment where network access is isolated and information can only be transmitted through physical storage media, the device comprising: The acquisition module acquires configuration code files from the isolated environment, including: generating configuration code files based on a preset front-end model and execution environment information, migrating the configuration code files to the isolated environment using an isolation medium, and acquiring the migrated configuration code files from the isolated environment; The compilation module compiles the configuration code file based on the predefined acceptance model to generate a management configuration file; The execution module performs tests based on the management configuration file and generates test results. The acceptance module obtains the acceptance rules and performs product acceptance based on the test results according to the acceptance rules.

8. An electronic device, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, such that the at least one processor can perform the method as described in any one of claims 1 to 6.

Images