Shulou(Shulou.com)06/01 Report--

Docker and automated testing and its testing practice process is what, many novices are not very clear about this, in order to help you solve this problem, the following small series will explain in detail for everyone, there are people who need this can learn, I hope you can gain something.

Docker and automated testing

For repetitive, boring manual testing tasks, consider automating them. The cost of automation lies in the writing and maintenance of automated programs, while the benefit lies in the time saved in manually executing use cases. In short, if the benefits outweigh the costs, there is value in automating the test task; otherwise, the benefit is simply that the tester's automation skills are improved. Docker's rapid deployment, environment sharing and other features can greatly reduce the cost of automation, so that many of the original value-free test tasks become valuable automation tasks, greatly improving project efficiency.

So if automated tests are already running in virtual machines, is it necessary to retrofit them with Docker technology? this requires a concrete analysis of specific issues. The author does not agree with the containerization of all test tasks. If your current VM already meets your testing requirements, you need to estimate the cost of introducing Docker for the retrofit, including the time cost of learning Docker technology. On the other hand, if the virtual machine cannot meet the current testing needs, you can consider introducing Docker as soon as possible.

Docker constraints

Build, Ship, and Run Any App, Anywhere. This is Docker's high-profile slogan that any application can be built, deployed, and run on any platform. However, due to Docker's own characteristics, its use scenarios have some constraints:

(1)Because the container shares the kernel with the host, if the application in the container requires a different kernel version, the host kernel will have to be replaced. However, if the host kernel changes, it will affect the operation of other containers. A workaround is to decouple application code writing from kernel features.

(2)Docker requires kernel version 3.10 or above to use, which is the minimum limit. If you need to use more advanced Docker features, such as user namespace, you'll also need a higher version of the kernel.

(3)The "--privileged" option allows kernel modules to be loaded or unloaded from containers, but this affects the host and other containers.

(4)It is not possible to simulate the operating environment of different platforms, for example, the container of arm64 cannot be started in x86 system.

(5)Because Docker uses namespace scheme to achieve isolation, and this isolation belongs to software isolation, security is not high. Not suitable for high security testing tasks.

(6)Because there is no time namespace technology, changing the time of a container has to affect the host and other containers.

Test scenarios for Docker

Since the container and the host share the kernel, all test tasks that are not strongly related to the kernel are suitable for introducing Docker for transformation, such as source code compilation test, software installation test, Internet application test, database test, etc. The test tasks that are strongly related to the kernel are not suitable for transformation using Docker, such as kernel network module test, kernel namespace feature test, etc.

Docker Testing Practice

containerized compilation system testing

Early on we installed linux distributions on physical machines for testing. The test environment had to be manually restored when it was necessary to redo the full test. After that, virtual machines were used. Although environment restoration could be realized in an automated way, the consumption of virtual machines was large and the efficiency was low.

If software testing, interface testing, automation testing, performance testing, LR script development, interview experience exchange. Interested can 175317069, there will be irregular distribution of free information links in the group, these materials are collected from various technical websites, sorted out, if you have good learning materials can privately chat with me, I will indicate the source after sharing to everyone.

We then tried to make the environment a Docker image and made the following improvements:

(1)Through Docker's "-v" option, the host directory is mapped to the container, so that multiple containers can share the test code. Test code deployment time reduced from 2 minutes to 10 seconds.

(2)Break large-grained use cases that take longer to execute into smaller use cases.

(3)Perform tests concurrently with containers.

(4)Use Dockerfile to comb product dependency packages and build software installations.

Compiled system tests are user-mode tests, which are ideal for acceleration with Docker. If you need to test a linux distribution, you can use Docker's rapid deployment features to quickly utilize all resources to accelerate test execution.

Linux peripheral package testing

Peripheral packages contain dynamic link library files and commonly used command-line tools. They belong to the middle layer of linux operating system, on which application programs run and supported by linux kernel. At first, the peripheral package test was executed serially, which was inefficient. At the same time, it is affected by environmental pollution, which is easy to produce false positives of software defects. In terms of improvements, we first make a Docker image based on rootfs through Dockerfile, and then implement concurrent execution of test cases through Docker-compose tool.

Below is a comparison before and after the improvement.

How Docker accelerates testing

Docker itself does not directly speed up test execution. Executing tests in containers instead results in performance degradation of about 5% when performing tests serially. But we can take full advantage of Docker's rapid deployment, environment sharing, and other features, while working with container clouds to quickly provide the required test resources to cope with peak test tasks. Ignoring environment deployment time, the time required for test execution is infinitesimal when the granularity of each test case is infinitesimal and the number of test resources provided is infinitesimal.

Did reading the above help you? If you still want to have further understanding of related knowledge or read more related articles, please pay attention to the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.