Detailed Description
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present description. This description may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein, as those skilled in the art will be able to make and use the present disclosure without departing from the spirit and scope of the present disclosure.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used in one or more embodiments of the present specification refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It will be understood that, although the terms first, second, etc. may be used herein in one or more embodiments to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, a first can also be referred to as a second and, similarly, a second can also be referred to as a first without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
First, the noun terms to which one or more embodiments of the present specification relate are explained.
A container: a container is a standardized unit that packages software for development, delivery, and deployment.
The life cycle of the container is as follows: the container is the whole process from creation to deletion.
The container project model: the combination of all operations within a single container lifecycle.
Project scene: a long-time hybrid run of a plurality of randomly varying container item models and their configuration data combined.
And (3) stability testing: the ability of a test system (e.g., a test platform) to operate stably in varying degrees of environment. Generally including stability of repeated operation of the function over time, and stability of operation of the function under concurrent stress.
Chaotic engineering: is a complex technical means for improving the elastic capability of the technical architecture. Chaos engineering (i.e., chaotic engineering) has been experimented to ensure system availability. Chaos engineering aims at throttling faults into swaddling, i.e. identifying them before they cause a break. By actively manufacturing faults, the behavior of the system under various pressures is tested, the fault problem is identified and repaired, and serious consequences are avoided.
And (3) fuzzy testing: fuzz testing is a software testing technique, usually automatic or semi-automatic, that involves providing invalid, unexpected, or random data to the input of a computer program. The program is then monitored for exceptions, such as crashes, built-in code assertion failures, or looking for potential memory leaks.
A cpu: generally referred to as a central processing unit. A central processing unit (cpu) is a final execution unit for information processing and program operation, and serves as an operation and control core of a computer system.
memory: a memory (memory) is one of important parts of a computer, and is also called an internal memory and a main memory for temporarily storing operation data in a cpu and data exchanged with an external memory such as a hard disk.
virtiofsd: also in the qemu warehouse: a scheme for sharing a file system between guests. The main usage scenarios include: 9p was replaced in the kata-container scene as a container rootfs.
overlayfs: is a stacked file system which is dependent on and built on other file systems (such as ext4fs and xfs, etc.), does not directly participate in the division of the disk space structure, and only "merges" different directories in the original underlying file system and then presents them to the user, which is a joint mount technology.
devmapper: the mapping mechanism from the logic device to the physical device is provided, and under the mapping mechanism, a user can conveniently manage the storage resources according to the requirement of the user.
ip vlan: the network card virtualization technology provided by the linux kernel can virtualize a plurality of virtual network cards from a physical network card. Multiple virtual network cards have the same mac address but independent IP.
eni tripping: it is a normal elastic network card, and plays a role of a communication channel in the scheme.
Internet: the Internet (Internet) is a collection of global information resources.
And (3) vpc: virtual Private Cloud, abbreviated VPC, full chinese: a private network.
The testing tool for improving the software stability comprises chaotic engineering and fuzzy testing, wherein the chaotic engineering is a common tool for verifying the stability and the usability of the system, and can cause faults at random positions (including containers) in the whole system, check whether the service has anti-failure capability and help to maintain the healthy operation of the system. For example, Kube-monkey can quickly verify whether the constructed k8s service is robust, whether flexible expansion is possible, whether unplanned faults can be handled, and the like. The fuzzy test, also called fuzzy test, is a test for digging software security loophole and detecting software robustness, which is realized by inputting a large number of random and illegal fields into software and observing whether the tested software is abnormal or not. The method can solve the problems that test input cannot be listed and exhausted, manual test consideration is not comprehensive and the like, and a test input combination is generated based on feedback mechanism variation, so that the test coverage rate is improved. The method is one of the most effective means in the fields of software testing and vulnerability mining.
However, the objective of the Kube-monkey test is not a container. It can promote the stability of k8s service cluster under various pressures through the active manufacturing trouble. The method mainly aims at the stability and the availability of the k8s service cluster, tests the fault handling and recovery capability of the service cluster, and does not focus on improving the stability of the container. Moreover, the traditional fuzz test is tightly coupled with the test product code, and the test coverage is increased through a large amount of random and invalid inputs, so that the quality of software is improved. It also introduces a large number of invalid tests while increasing coverage and even test data that are too voluminous to result in test explosion. In addition, the method tests the source code and the binary program, the generation of the test data is strongly bound with the software programming language, and the method is mainly used for automatically generating a functional test case and rarely used for constructing a complex project scene test.
Therefore, the stability test scheme related to the container technology is relatively deficient, and no commercial mechanism provides a stable container product for a production environment, so that it is urgently needed to construct an efficient container stability test scheme to improve the technical stability of the container for the production environment.
In this specification, a method of testing a container is provided. One or more embodiments of the present disclosure are also directed to a container testing device, a computing apparatus, and a computer-readable storage medium, each of which is described in detail in the following embodiments.
Referring to fig. 1, fig. 1 illustrates an architectural diagram of a container testing system according to an embodiment of the present disclosure.
As shown in fig. 1, the container testing system includes a project model library 102, a container configuration library 104, and a thread pool 106, wherein,
the project model library 102 configured to build a plurality of container project models including at least one operation based on project information, and build the project model library 102 based on the plurality of container project models;
the container configuration library 104 is configured to configure a corresponding configuration parameter set for each operation of each container project model in the project model library according to a preset configuration rule, and construct the container configuration library 104 based on the configuration parameter set;
the thread pool 106 is configured to determine a test thread, and select a to-be-run container item model and a configuration parameter corresponding to each operation in the to-be-run container item model from the item model library and the container configuration library based on the test thread; and acquiring an operation result of the test thread which creates and operates the container based on the container item model to be operated and the configuration parameters corresponding to each operation of the container item model to be operated, and testing the container based on the operation result.
The items include, but are not limited to, data processing items (e.g., data query items, data add items, etc.), resource processing items (e.g., payment items, payment collection items), and the like. Specifically, the items may be set according to practical applications, and the present specification does not limit the items.
And operations include, but are not limited to, create operations, start operations, delete operations, pause operations, resume operations, stop operations, and the like. A container item model is then understood to be a container item model formed by one, two or more operations.
For example, the container item model 1 is: create- > start- > stop- > rm (create operation-start operation-stop operation-delete operation).
The container item model 2 is: run- > exec- > restart- > states- > pause- > update- > stop- > rm (run operation-execute operation-restart operation-view container operation-pause operation-resume operation-update operation-delete operation).
The configuration parameters corresponding to each operation of each container item model can be understood as cpu, memory, and the like of the container.
In specific implementation, a project model library and a container configuration library are first constructed according to rules, where the rules may be understood as rules defined according to characteristics of a project, for example, if a container used by a certain container project model corresponding to the project is smaller, fewer operations in the container project model may be defined; if a container used by a certain container item model corresponding to the item is large, more operations in the container item model can be defined. Specifically, the starting point of the rule is to test a real project scene as much as possible, ensure the effectiveness of the test and reduce a large number of invalid tests introduced by the fuzzy test. Based on the principle, the online project can directly extract the corresponding container project model and the configuration parameter set of each operation in each container project model through project monitoring and log so as to construct a project model library and a container configuration library; if the project is a new project, the rule is defined by combining the requirement of the product and the interface document with the actual requirement of the project (different project side emphasis points are different, such as the ratio of the container cpu to the memory is 2:1, the maximum specification does not exceed 16 cores, and the storage scheme adopts virtiofsd and other similar project limits).
Secondly, based on the project model library and the container configuration library constructed in the above manner, the test system dynamically determines the size of a concurrent test thread pool according to hardware resources (such as cpu and memory), each test thread in the test thread pool randomly selects configuration parameters of each operation in the container project model and each container project model from the project model library and the container configuration library to create and operate a container, a real project scene in which a plurality of containers concurrently operate is simulated, the container configuration continuously and randomly changes in the test operation process, the test thread randomly operates a single container or a plurality of containers, and the test thread randomly creates and operates different types of containers along with the end of a life cycle, so that the stability test of the container is realized.
The container testing system provided by the embodiment of the specification creatively uses the fuzzy testing idea for system stability testing and provides a universal container stability testing scheme. On one hand, the container item which changes continuously is simulated through the combination of a container item model and configuration parameters which are generated dynamically and randomly, on the basis, a large number of complex item scenes of container concurrent operation which are configured in a differentiated mode are built through a thread pool, and test coverage is increased, so that the product stability is improved; on the other hand, the reasonable combination of the container project scene and the configuration data is limited by the test definition rule, so that the test is close to the real project scene, a large amount of invalid tests generated by the conventional fuzzy test are avoided, and more importantly, test explosion caused by the inexhaustible test combination is prevented; and finally, the test object is converted into a higher-level project scene from a bottom-level software source code or binary system, so that the test is realized only by a universal container function interface, a container product of any programming language is supported, the method is suitable for open-source and closed-source software, and the technical problems that the conventional fuzzy test strongly depends on the code of the tested object and the programming language, part of the fuzzy test only supports the open-source software and the like are solved.
Referring to fig. 2, fig. 2 is a flowchart illustrating a container testing method applied to a testing platform according to an embodiment of the present disclosure, which includes the following steps.
Step 202: a plurality of container project models including at least one operation are constructed based on the project information.
For detailed explanation of the item, operation and container item model, reference may be made to the above embodiments, which are not described herein again.
Specifically, the project information includes, but is not limited to, information such as project requests, project monitoring and logs of online projects, and information such as product requirement documents and interface documents of offline projects.
Thus, for the construction of the container item model, a specific implementation of a method is as follows:
the building of a plurality of container project models including at least one operation based on project information includes:
determining a project state of a project, constructing a plurality of initial container project models based on the running information of the project under the condition that the project state is a running state, and determining the operation included by each initial container project model;
aggregating the operationally identical initial container item models to obtain a container item model comprising at least one operation.
The running state may be understood as an on-line state, that is, the project may start running, and project operation may be performed based on the received project processing request.
In this case, the operation information of the project may be understood as information of a project request, a project monitoring, a project log generated during the operation of the project, and the like.
Specifically, in the case that the project state is the running state, a plurality of initial container project models may be constructed based on the running information of the project, for example, if the running information of the project is a data query request, the initial container project models may be: create-query-delete.
After determining a plurality of initial container item models, obtaining operations each initial container item model comprises, aggregating the initial container item models with the same operations to obtain a final container item model comprising at least one operation.
For example, the initial container item model 1 is: create-query-delete, the initial container item model 2 is: create-query-update-delete, the initial container item model 3 is: creating, querying and deleting, wherein it may be determined that the operations of the initial container item model 1 and the initial container item model 3 are the same, the initial container item model 1 and the initial container item model 3 are aggregated (for example, the initial container item model 3 is deleted), and a final container item model including at least one operation is obtained: an initial container item model 1 and an initial container item model 2.
In the embodiment of the present specification, in order to consider the problem of testing efficiency, container item models which operate the same may be merged, and only the simplest valid and near-real container item model is reserved. In addition, in order to enrich subsequent project scenes, the initial container project model can be reasonably expanded based on the product requirements of the project, so that a plurality of subsequent project scenes can be randomly generated, and the container testing accuracy is improved.
Another specific implementation of the method is as follows:
the building of a plurality of container project models including at least one operation based on project information includes:
determining a project state of a project, and constructing a plurality of container project models including at least one operation through a preset construction rule based on project document information of the project under the condition that the project state is a to-be-run state.
The to-be-operated state can be understood as a non-online state, that is, the project only does not start to be operated online except for a product requirement document or a design document.
At this time, the project document information of the project can be understood as a product requirement document, an interface document, and the like when the project is designed.
Specifically, under the condition that the project state is the to-be-run state, a plurality of project models including at least one operation initial container can be constructed through a preset construction rule based on project document information of the project; the preset construction rules may be set according to actual applications, which is not limited in this specification, for example, function settings may be implemented according to items in a product requirement document and an interface document.
In the embodiment of the present specification, when a project is in an offline state, and no ready-made project flow is used as a reference, a custom rule is provided to construct a container project model based on a product requirement document and an interface document of the project, so that a project scene can be subsequently constructed based on the container project model and configuration data, and a stability test on the container is realized.
Referring to fig. 3, fig. 3 is a schematic diagram illustrating construction of a container item model in a container testing method according to an embodiment of the present disclosure.
As shown in fig. 3, states of mirroring, created, running, deleted, suspended, exited, etc. are specifically included, where before creating a container, a common mirroring warehouse or a user mirroring warehouse pulls a required mirroring, and then the container can be created and run through different container project models and configuration parameters of each operation in each container project model, so as to implement a test on the container.
The operations of creating, running, starting, deleting, forced deleting, suspending, resuming, stopping/killing, container process exiting/service hanging, viewing process, viewing container, executing, restarting, updating, renaming, etc. in fig. 3 can all be understood as the container. In practical applications, a container item model may be constructed by a plurality of operations, for example, the container item model is: create-start-stop-delete, etc. Specifically, each operation in each container item model corresponds to an operation state.
The complete process from creation to deletion of the container is the life cycle of the container, in the process, different container operations can change the state of the container, meanwhile, the containers in different states can only do specified container operations, and the set of all the container operations in the whole life cycle of the container is the path of the life of the container (namely, a container project model), and is the embodiment of the container in a real project scene. Based on fig. 3 and rules defined according to the product demand test (for example, the container running at long time, the containers in different states can only operate normally, the cpu resource allocation does not exceed the rules of 32 cores, etc.), and a path of the container life cycle is randomly generated, so as to test and simulate the performance of a single container in a real project scene.
Step 204: and configuring a corresponding configuration parameter set for each operation in each container project model according to a preset configuration rule.
The preset configuration rule may be set according to actual application, and this is not limited in this description embodiment. For example, in the case where the project status is a running status, a corresponding set of configuration parameters may be configured for each operation in each container project model according to the historical running parameters of the project.
Specifically, the configuring, according to a preset configuration rule, a corresponding configuration parameter set for each operation in each container item model includes:
and configuring multiple groups of corresponding configuration parameters for each operation in each container project model according to the historical operating parameters of the project in an equivalent class division and function point orthogonal mode, and forming a configuration parameter set based on the multiple groups of configuration parameters.
The historical operating parameters include, but are not limited to, cpu and memory usage parameters consumed by processing any one item function (such as a data query function or a data update function).
Specifically, multiple sets of configuration parameters corresponding to each operation in each container project model can be configured according to historical operating parameters of the project in an equivalent class division and functional point orthogonal manner, and the multiple sets of configuration parameters corresponding to each operation form a configuration parameter set corresponding to the operation. That is, each operation in each container project model may correspond to multiple sets of configuration parameters, and in practical applications, when a project scene is constructed, the configuration parameters of each operation in each container project model are different, and a different project scene may be constructed.
In the embodiment of the specification, through the manner of equivalence class division and function point orthogonality, test coverage can be ensured, and the test can be controlled within an effective test range.
And performing orthogonality on the resource configuration and the function points divided according to the equivalence classes, and finally generating parameter combinations of each operation in container project models with different types and different configurations for subsequent container creation. The resource configuration comprises an effective value, a boundary value and an invalid value; the functional points include: storage scheme, network scheme, boot type, network access. See table 1 for details.
TABLE 1
Resource allocation
|
Storage scheme
|
Network scheme
|
Type of start-up
|
Network access
|
Effective value
|
overlayfs
|
Network card straight-through
|
Cold start
|
internet
|
Boundary value
|
devmapper
|
ipvlan
|
Warm start
|
vpc
|
Invalid value
|
virtiofs
|
enitrunking
|
Hot start
|
Internet+vpc |
In the embodiment of the description, multiple sets of configuration parameters suitable for each operation in each container project model can be configured in an equivalent class division and function point orthogonal mode according to historical operating parameters of the project, so that the effectiveness of subsequent project scenes is improved.
In another case, when the project state is the to-be-run state, and there is no historical run parameter for the project, a corresponding configuration parameter set may be configured for each operation in each container project model based on the configuration parameters of the test platform. The specific implementation mode is as follows:
the configuring, according to preset configuration rules, a corresponding configuration parameter set for each operation in each container item model includes:
and configuring multiple groups of corresponding configuration parameters for each operation in each container project model based on the configuration parameters of the test platform in an equivalent class division and functional point orthogonal mode, and forming a configuration parameter set based on the multiple groups of configuration parameters.
The test platform can be understood as a test machine, and the configuration parameters of the test platform can be understood as cpu and memory space of the test machine.
In practical application, when the test platform performs container testing, the resources of the containers operated by all the test threads of the test platform cannot exceed the resources of the test platform, so when configuring parameters for each operation in each container project model, the configuration parameters of the test platform need to be considered, so as to avoid test explosion caused by the test threads of the subsequent test platform when operating the containers.
Specifically, under the condition that no historical operating parameters exist in the project, a plurality of sets of configuration parameters corresponding to each operation in each container project model can be configured through equivalence class division and function point orthogonality on the basis of the configuration parameters of the test platform, so that the stability of the test thread of the subsequent test platform on the container test is ensured.
Step 206: and determining a configuration parameter corresponding to each operation in the container item model to be operated and the container item model to be operated, which are selected by the test thread from the plurality of container item models and the configuration parameter set.
In practical application, the test thread may be determined based on the configuration parameters of the test platform, or may be manually preset; the specific implementation manner of the method is described as follows:
the determining of the configuration parameter corresponding to each operation in the container item model to be run and the selected container item model to be run from the plurality of container item models and the configuration parameter set by the test thread includes:
determining at least one test thread based on configuration parameters of the test platform;
and determining a configuration parameter corresponding to each operation in the container item model to be operated and the container item model to be operated, which are selected by each testing thread from the plurality of container item models and the configuration parameter set.
For the configuration parameters of the test platform, reference may be made to the description of the above embodiments, which are not described herein again.
Specifically, the number of the test threads may be dynamically determined according to hardware resources (such as cpu and memory) of the test platform, and then the determined test threads are placed in the constructed thread pool, which is convenient for subsequent application.
After the testing threads are determined, each testing thread randomly selects a container item model to be operated and a configuration parameter corresponding to each operation in the container item model to be operated from a plurality of container item models and the configuration parameter set, and simulates a real item scene of a plurality of containers in parallel to realize the testing of the containers.
In the embodiment of the present specification, during a specific test, the number of test threads may be reasonably determined according to hardware resources of a test platform, so as to ensure that the stability of a container may be subsequently tested based on the test threads.
In another case, the determining, by the test thread, a configuration parameter corresponding to each operation in the container item model to be run and the selected container item model to be run from the multiple container item models and the configuration parameter set includes:
determining at least one testing thread based on a preset configuration rule;
and determining a configuration parameter corresponding to each operation in the container item model to be operated and the container item model to be operated, which are selected by each testing thread from the plurality of container item models and the configuration parameter set.
The preset configuration rule may be set according to an actual application, which is not limited in this specification, for example, the preset configuration rule is to determine a test thread or the like according to the number of container item models or a real operation scene of an item.
Taking a preset configuration rule as an actual operation scene of a project as an example, if 30 containers generally operate simultaneously in the actual operation scene of the project, 30 test threads may be set, but resources of the containers corresponding to the 30 test threads are set based on hardware resources of a test platform, and total consumed resources of the 30 containers in a test operation process cannot exceed the hardware resources of the test platform. Each user can set the number of the test threads according to the actual situation of the user, which may be 10 or 200, and specifically, the concurrent number of the containers is set according to the project situation, so that the resource of a single container is definitely small, and if a large container runs, one container can be executed concurrently through a plurality of test threads.
In specific implementation, each test thread only operates one container, which is the most basic scenario, and another scenario is that 30 containers are created first, and then each test thread operates any container in the 30 containers, and a scenario that multiple test threads operate the same container or a single thread operates multiple containers is simulated.
In the embodiment of the specification, a test thread in a thread pool can simulate a project scenario in which a plurality of containers run on the same machine, and the concurrent combination of a random container project model and configuration parameters can automatically generate as many project scenarios as possible, even some conflicts and extreme situations which are not easy to construct, so that more problems can be found in the test process, and more comprehensive container tests can be realized.
Step 208: and acquiring an operation result of creating and operating a container by the test thread based on the container item model to be operated and the configuration parameters corresponding to each operation of the container item model to be operated, and testing the container based on the operation result.
Specifically, each test thread creates and runs a container after selecting a to-be-run container item model and a configuration parameter corresponding to each operation of the to-be-run container item model. The test platform may test the containers based on the results of the operation of each container.
The testing the container based on the operation result comprises:
determining the end state of the container based on the operation result, and acquiring the target operation of a container item model corresponding to the container;
and testing the container based on the corresponding relation between the end state and the target operation.
The ending state of a container may be understood as a state returned after the container performs an operation in the corresponding container item model, such as a pause state or a delete state.
The target operation of the container item model corresponding to the container may be understood as the last operation of the container item model, for example, the container item model is: create-update-pause, then the target operation is a pause operation.
In practical applications, if the running state of the container is consistent with the expected state (for example, after the container is paused, the ending state of the container is in a paused state), the container can be determined to pass the test.
In one implementation, the container may also be tested according to configuration parameters after the container is operated, for example:
the testing the container based on the operation result comprises:
determining operation parameters of the container based on the operation result, and acquiring configuration parameters corresponding to each operation in the to-be-operated container project model corresponding to the container;
and comparing the operating parameters with the configuration parameters, and testing the container based on the comparison result.
Wherein the operation parameters may be understood as parameters obtained after the container is operated based on the container item model and the corresponding configuration parameters.
Specifically, if the configuration parameters of the container are consistent with the operation parameters, the state of the container is stable. If the configuration parameters of the container are inconsistent with the operation parameters, which indicates that some problems occur in the operation process of the container, the performance of the container can be determined to be unstable.
In the embodiment of the specification, whether the state of the container is normal can be quickly determined by judging whether the operation parameters of the container are consistent with the configuration parameters.
During specific implementation, the test threads are operated all the time according to preset loop times, and each test thread selects a container project model and configuration parameters of each operation in each container project model from a project model library and a container configuration library in each loop, and creates and operates a container. Specifically, if the first operation of the container item model is creation, a container is created at this time, and then other operations of the container (such as restarting, pausing, executing a command, checking the state of the container, and the like) are executed according to the selected container item model, and finally the container is deleted, and the next round of circulation is entered until the circulation number is finished. The specific cycle test mode is as follows:
after determining the configuration parameters corresponding to each operation in the selected to-be-run container item model and the to-be-run container item model from the multiple container item models and the configuration parameter set by the test thread, the method further includes:
determining the selection times of the test thread from the item model library and the configuration parameter set, wherein the selection times of the test thread are selected from the selected to-be-operated container item model and the configuration parameter corresponding to each operation in the to-be-operated container item model;
judging whether the selection times are larger than a preset time threshold value or not,
if so, comparing the configuration parameters before the test platform operates with the configuration parameters after the test platform operates, testing the container based on the comparison result,
if not, acquiring an operation result of the testing thread which is created and operated by the testing thread based on the selected container item model and the configuration parameters corresponding to each operation of the container item model, and testing the container based on the operation result.
The number of selections may be set according to the actual application, for example, 10 times or 20 times.
In practical application, the test threads are operated all the time according to preset loop times, and each test thread selects a container project model and configuration parameters of each operation in each container project model from a project model library and a container configuration library in each loop, and creates and operates a container. Specifically, if the first operation of the container item model is creation, a container is created at this time, and then other operations of the container (such as restarting, pausing, executing a command, checking the state of the container, and the like) are executed according to the selected container item model, and finally the container is deleted, and the next round of circulation is entered until the circulation number is finished. And each step in the cycle checks whether the container operation is expected (e.g., after the container is paused, whether the container is paused) to determine whether the container is in a normal state. After the whole circulation is finished, whether the resources (cpu, memory and the like) of the whole test platform are correctly recycled is checked, whether the resources (such as container processes, control groups and the like) are remained or not is checked, if the resources are normal, no error is generated in the test process, and the test is passed.
The container testing method provided by the embodiment of the specification simulates continuously changing container items through the combination of the container item model and the configuration parameters which are randomly generated, and a large number of complex item scenes of container concurrent operation which are configured in a differentiated mode are constructed by using the testing thread, so that the testing coverage is increased, and the container stability is improved.
In addition, the container testing method decouples the fuzzy test and the test product code, is applied to project scene testing, inherits the capability of the fuzzy test to effectively discover problems to improve the stability of container products on one hand, and improves the universality of the fuzzy test on the other hand, and supports various types (different languages, open sources and closed sources) of container products. And the project model library and the container configuration library can be defined based on rules, so that the test is close to a real project scene, a large number of invalid tests are avoided, and the test effectiveness is improved.
Corresponding to the above method embodiment, the present specification further provides an embodiment of a container testing apparatus, and fig. 4 shows a schematic structural diagram of a container testing apparatus provided in an embodiment of the present specification. As shown in fig. 4, the apparatus includes:
a model building module 402 configured to build a plurality of container project models including at least one operation based on the project information;
a parameter building module 404 configured to configure a corresponding configuration parameter set for each operation in each container item model according to a preset configuration rule;
a scenario building module 406 configured to determine a test thread from the multiple container item models and the configuration parameter set, a selected container item model to be run and a configuration parameter corresponding to each operation in the selected container item model to be run;
the testing module 408 is configured to obtain an operation result of creating and operating a container by the testing thread based on the selected container item model and the configuration parameters corresponding to each operation of the container item model, and test the container based on the operation result.
Optionally, the model building module 402 is further configured to:
determining a project state of a project, constructing a plurality of initial container project models based on the running information of the project under the condition that the project state is a running state, and determining the operation included by each initial container project model;
aggregating the operationally identical initial container item models to obtain a container item model comprising at least one operation.
Optionally, the model building module 402 is further configured to:
determining a project state of a project, and constructing a plurality of container project models including at least one operation through a preset construction rule based on project document information of the project under the condition that the project state is a to-be-run state.
Optionally, the parameter construction module 404 is further configured to:
and configuring multiple groups of corresponding configuration parameters for each operation in each container project model according to the historical operating parameters of the project in an equivalent class division and function point orthogonal mode, and forming a configuration parameter set based on the multiple groups of configuration parameters.
Optionally, the parameter construction module 404 is further configured to:
and configuring multiple groups of corresponding configuration parameters for each operation in each container project model based on the configuration parameters of the test platform in an equivalent class division and functional point orthogonal mode, and forming a configuration parameter set based on the multiple groups of configuration parameters.
Optionally, the scene building module 406 is further configured to:
determining at least one test thread based on configuration parameters of the test platform;
and determining a configuration parameter corresponding to each operation in the container item model to be operated and the container item model to be operated, which are selected by each testing thread from the plurality of container item models and the configuration parameter set.
Optionally, the scene building module 406 is further configured to:
determining at least one testing thread based on a preset configuration rule;
and determining a configuration parameter corresponding to each operation in the container item model to be operated and the container item model to be operated, which are selected by each testing thread from the plurality of container item models and the configuration parameter set.
Optionally, the test module 408 is further configured to:
determining the end state of the container based on the operation result, and acquiring the target operation of a container item model corresponding to the container;
and testing the container based on the corresponding relation between the end state and the target operation.
Optionally, the apparatus further comprises:
a loop module configured to:
determining the selection times of the test thread from the item model library and the configuration parameter set, wherein the selection times of the test thread are selected from the selected to-be-operated container item model and the configuration parameter corresponding to each operation in the to-be-operated container item model;
judging whether the selection times are larger than a preset time threshold value or not,
if so, comparing the configuration parameters before the test platform operates with the configuration parameters after the test platform operates, testing the container based on the comparison result,
if not, acquiring an operation result of the testing thread which is created and operated by the testing thread based on the selected container item model and the configuration parameters corresponding to each operation of the container item model, and testing the container based on the operation result.
The container testing device provided in the embodiment of the present specification simulates continuously changing container items through a combination of randomly generated container item models and configuration parameters, and constructs a large number of complex item scenes in which containers configured differently run concurrently by using a testing thread, so as to increase testing coverage and improve container stability.
The above is a schematic solution of a container testing apparatus of the present embodiment. It should be noted that the technical solution of the container testing apparatus is the same concept as the technical solution of the container testing method, and the detailed contents of the technical solution of the container testing apparatus, which are not described in detail, can be referred to the description of the technical solution of the container testing method.
FIG. 5 illustrates a block diagram of a computing device 500 provided in accordance with one embodiment of the present description. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. Processor 520 is coupled to memory 510 via bus 530, and database 550 is used to store data.
Computing device 500 also includes access device 540, access device 540 enabling computing device 500 to communicate via one or more networks 560. Examples of such networks include the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the internet. The access device 540 may include one or more of any type of network interface, e.g., a Network Interface Card (NIC), wired or wireless, such as an IEEE802.11 Wireless Local Area Network (WLAN) wireless interface, a worldwide interoperability for microwave access (Wi-MAX) interface, an ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a bluetooth interface, a Near Field Communication (NFC) interface, and so forth.
In one embodiment of the present description, the above-described components of computing device 500, as well as other components not shown in FIG. 5, may also be connected to each other, such as by a bus. It should be understood that the block diagram of the computing device architecture shown in FIG. 5 is for purposes of example only and is not limiting as to the scope of the present description. Those skilled in the art may add or replace other components as desired.
Computing device 500 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., tablet, personal digital assistant, laptop, notebook, netbook, etc.), mobile phone (e.g., smartphone), wearable computing device (e.g., smartwatch, smartglasses, etc.), or other type of mobile device, or a stationary computing device such as a desktop computer or PC. Computing device 500 may also be a mobile or stationary server.
Wherein the processor 520 is configured to execute computer-executable instructions that, when executed by the processor, implement the steps of the container testing method described above.
The above is an illustrative scheme of a computing device of the present embodiment. It should be noted that the technical solution of the computing device and the technical solution of the container testing method described above belong to the same concept, and details that are not described in detail in the technical solution of the computing device can be referred to the description of the technical solution of the container testing method described above.
An embodiment of the present specification further provides a computer-readable storage medium storing computer instructions, which when executed by a processor, implement the steps of the container testing method described above.
The above is an illustrative scheme of a computer-readable storage medium of the present embodiment. It should be noted that the technical solution of the storage medium belongs to the same concept as the technical solution of the container testing method, and details that are not described in detail in the technical solution of the storage medium can be referred to the description of the technical solution of the container testing method.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The computer instructions comprise computer program code which may be in the form of source code, object code, an executable file or some intermediate form, or the like. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer memory, Read-Only memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, etc. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.
It should be noted that, for the sake of simplicity, the foregoing method embodiments are described as a series of acts, but those skilled in the art should understand that the present embodiment is not limited by the described acts, because some steps may be performed in other sequences or simultaneously according to the present embodiment. Further, those skilled in the art should also appreciate that the embodiments described in this specification are preferred embodiments and that acts and modules referred to are not necessarily required for an embodiment of the specification.
In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.
The preferred embodiments of the present specification disclosed above are intended only to aid in the description of the specification. Alternative embodiments are not exhaustive and do not limit the invention to the precise embodiments described. Obviously, many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the embodiments and the practical application, to thereby enable others skilled in the art to best understand and utilize the embodiments. The specification is limited only by the claims and their full scope and equivalents.