2.安全渗透测试
该项工作需要阅读源代码找到潜在的安全漏洞，同时需要及时同步社区中已经发现的cve漏洞，并进行版本升级。cvedetails网站收集了各开源社区的cve信息，在对cve进行排查时，不仅需要排查容器引擎的社区，还需要排查和其有交互的开源组件、编程语言库、编译器等，如golang语言。
性能测试
适合场景：
性能测试适用于对性能要求较高、需要进行性能调优的容器引擎使用场景。
通常做法：
分别在宿主机和容器中执行常用的性能测试套（如lmbench），将测试结果进行对比。不足之处在于其无法覆盖到容器特有的性能参数，如启动时间、占用内存值等。
优秀实践：
通过对不同容器引擎以及容器与物理机虚拟机进行各关键指标的对比，可以找到项目的性能优化点。
容器引擎涉及到的性能指标主要有：
· 容器启动时间
测试方法:
$time${container_engine}run${image}echo0
· 容器占用内存值
测试方法：
$smem${container_pid}
smem工具会获取三个主要的内存指标，在此选取PSS值，这是为了便于测试多个容器使用的内存总量。
· 主机最大容器承载量
测试方法：不断创建新的空载容器，同时使用如下命令获取当前容器数量，直至主机资源耗尽。
$${container_engine}info
· 容器CPU性能
测试方法：测试计算素数直到某个最大值所需要的时间。
$sysbench--test=cpu--cpu-max-prime=${max_prime_value}run
· 容器内存性能
测试方法：每次读写8KB，直到10GB读取完成。
$sysbench--test=memory--memory-block-size=8K--memory-total-size=10Grun
· 容器磁盘IO性能
测试方法：使用sysbench--test=fileio或dd命令进行验证。
· 容器网络性能
测试方法：利用netperf测试套验证。
开源测试
适合场景：
适用于基于开源容器引擎二次开发的容器使用场景。
通常做法：
继承开源社区的测试用例，同时针对自研特性设计测试用例。不足之处在于无法有效利用社区资源进行容器引擎的质量保障。
优秀实践：
可以借助开源社区进一步完善质量保障，具体体现为：
· 上报缺陷
当软件在自己开发环境中发现缺陷时，可以查看社区中是否有其他人报过相同的缺陷。如果没有，可以在github中提交一个issue来跟踪，引导社区来解决缺陷，从而减少自身团队的投入。
· 提交测试用例
对于和自身平台有强相关性的用例可以贡献给社区，可以使社区在发布版本时预先验证某项功能，从而达到测试前移并减少自身项目工作量的目的。
· 排除社区已知缺陷
社区代码缺陷通常存放在issue中，很多高版本发现的缺陷在低版本中同样存在，需要进行人工排查，将issue中高版本的缺陷对应的patch合入到低版本的商用容器引擎中。
内核测试
适合场景：
容器引擎的运维系统往往包含着不同内核版本的宿主机，需要针对不同内核版本验证容器依赖的内核特性。
通常做法：
验证某个单一的内核版本中容器依赖的内核特性后，通过灰色发布的方式进行快速试错。不足之处在于快速试错采用的是线上的环境，如遇到问题可能会导致大面积服务中断。
优秀实践：
容器引擎通常需要运行在3.10或以上版本的内核中，这类内核中包含着cgroup、namespace、capability、seccomp、unionfs等容器依赖的内核特性，需要对这些底层的内核特性进行充分的验证才能保证容器引擎的质量。
Ltp是一款内核开源测试套。里面包含很多内核特性的测试用例，如cgroup测试用例、namespace测试用例。需要在验证容器引擎的同时，运行ltp中容器相关的内核特性测试用例。
故障注入测试
适合场景：
该项测试适用于对容错能力要求较高的场景。故障注入测试可以验证容器引擎的容错能力，从而减少故障对业务的影响。
通常做法：
执行一段时间的长稳测试，将所有已遇到的故障记录下来，录入故障模式库。这种方法较为被动，需要在故障出现时才能梳理出来，无法在故障发生前消除故障带来的影响。
优秀实践：
根据每一个容器引擎命令梳理出程序的控制流，在控制流中的每一个节点中增加典型的故障注入方式，确保不遗漏可能的故障点，从而保证容器引擎的容错能力。常用的故障类型包括但不限于CPU、内存、磁盘、网络等。
下面列举了部分故障供读者参考：
· CPU故障：将容器绑定到某CPU核后强制将该CPU核下线；主机CPU高负载时尝试启动容器；容器内部运行高负载程序时主机不会卡死。
· 内存故障：试图在容器中耗尽主机内存；使用---restart=always选项启动容器后在容器内部不断执行outofmemory的操作；操作系统可用内存低时仍然可以启动容器。
· 磁盘故障：磁盘占满时尝试启动docker容器；容器运行中时umountgraph所在的磁盘分区。
· 网络故障：容器网桥意外下线；ip资源耗尽；加大网络延迟，提高网络丢包率；分配给容器一个已被占用的ip地址。
· 其他故障：宿主机异常断电；随机杀掉系统进程；cgroup文件夹被umount；系统进程数量达到最大值时启动容器。
结尾
本文展示了多种容器引擎的专项测试方法，但测试只是验证其质量的方式。好的软件是设计出来的，而不是测试出来的。在加强容器测试的同时也需要企业去关注开发流程的质量和规范性。只有开发和测试共同努力才能有效的把控容器软件的质量。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
