在之前的《Hello Docker》中，简单介绍过Docker，但仅限于在测试开发团队内部使用，或者说更多的是我个人在使用Orz，等了好久终于公司的研发团队开始正式使用Docker了。这次来西安分公司学习下公司基于Docker和K8S开发的容器云平台，深入了解了下Docker的底层原理，简单学习了下K8S的基本概念和操作，感觉对于研发团队来说，容器化的迁移还是有一定成本的。
Docker带来了什么？改变了什么？
一、传统软件开发流程有几大痛点：
开发、测试、发布环境不统一
配置测试环境过程冗长又复杂
自动化测试环境不稳定，容易受到污染，隔离不足
无法准确获得客户的软件环境
开发团队无法复现测试团队报出的软件缺陷，导致两个团队出现相互推诿的现象
二、当前测试技术面临的几大挑战：
- 配置一致的测试环境
- 快速部署软件
- 并行执行测试，在并行的同时还要保证测试任务各自的环境不被污染
- 成功的复现软件缺陷
- 创建干净的可信的测试环境
- 快速部署多个测试主机
- 快速导入测试数据
- 快速清理测试环境
- 快速保留、复制、恢复测试环境
- 正确配置测试工具。快速将测试环境在不同操作系统（类Unix）
三、Docker对测试技术的革命性影响
软件开发交付速度上不去，很大一个问题是软件运行环境这个环节存在瓶颈，Docker解决了这个瓶颈，促进了软件开发的DevOps模式推广，这对所有的软件行业从业者都是巨大利好。
软件测试的几个重要方面：测试策略、测试设计、测试方法、测试数据、测试环境，前三个是方法论思想层面的，后两个是需要技术突破的。测试数据因具体细分行业不同，各有各的痛点也各有各的解决方案，但是对于测试环境来说，Docker是个近乎接近“银弹”的技术解决方案。
通过Docker的软件环境快速部署能力，促进了测试时间的再分配
一个小小的Dockerfile明确声明了软件部署的所有细节和流程，从此忘记冗长的安装部署文档吧！无论是从研发自测、功能测试、集成测试等哪个环节来讲，测试环境的部署时间成倍缩短，能给工程师更多的时间做更多有意义的事情，开发工程师可以有更多时间完善优化设计，修复缺陷，测试工程师可以有跟多时间拓宽测试的广度和提高测试的深度，运维工程师有更多的时间专注于改进软件监控分析系统，这和有效的自动化测试的价值可以相提并论。
通过Docker的软件环境一致性能力，有效降低了偶然复杂度
Docker的镜像发布，容器编排运行等设计实现，保证了开发环境、测试环境、生产发布环境以及不同操作系统发行版的高度一致可信，几乎避免了测试团队发现的缺陷在开发环境无法复现、线上生产环境的缺陷在线下无法复现且不便线上调试等问题带来的一些列人力成本、时间成本、心智成本的无谓消耗。
通过Docker的环境隔离管理能力，提高了测试资源的自由度
以往虽然有各种虚拟化技术，可以一台服务器虚拟化为多台虚拟机，可以对虚拟机进行快照，随时恢复软件环境，但是终究太笨重，资源损耗太高，利用率太低，无法实现测试资源自由。现在有了Docker的资源隔离管理能力，我们可以按照测试需求，启动多个不同版本的服务，随时创建，随时销毁；我们甚至可以在一台服务器给每个测试人员启动一套独立的测试环境，大家并行测试，互不干扰，避免了互相踩踏。同时这种环境资源的自由度，对于自动化测试的执行过程是有很大帮助的，大大提高了自动化测试的成功率，进而提高自动化测试的ROI。
测试团队如何顺势而为？
上一小节总结的三点革命性影响，对于整个开发流程来说，已经为CI/CD提供了道路基石，势必将进一步缩短迭代周期，提高交付速度（虽然还是有需求变更，开发延期等软件开发管理上不可避免的问题和人的不可靠性等因素等debuff）
效率提高了，交付速度提高了，迭代速度更快了，单纯的手工测试已经跟不上DevOps的软件开发模式了（其实在很多年前就跟不上现代软件开发节奏了），对测试的要求更高了，应当思考下省下来的时间如何更好的利用，如何跟上研发提测的速度。对于我现在所在的这种相对传统的行业软件服务企业来说，测试团队必须尽快适应这种DevOps开发模式了，不然就会被历史的车轮碾死在尘埃里。
测试团队的核心职责是质量保障，围绕质量保障，我们可以将测试能力向前向后输出，输出的最好形式就是自动化。
- 自动化测试环境资源不再是自动化实施的绊脚石，接下来需要考验的是我们的自动化框架、自动化工具是否真的可靠、可用。
- 测试驱动开发的模式虽然很好，但是推广落地却不是那么容易的😊。测试团队还可以将测试用例封装为自动化测试服务，提供给研发自测，而不是等研发一次次快速提测再被打回，冲击消耗测试工程师的激情和精力。更近一步可以考虑通过感知镜像仓库中镜像的变化，动态触发自动化测试。当然长远看来还是要与开发团队共同实现CI/CD，需要各个研发部门通力合作。
- 软件运行环境的高度一致性，理论上线上发现的缺陷可以等价于测试团队漏测，这对测试团队的可信度和口碑是一个挑战，需要进一步提高测试质量和标准
- 上线后的软件运行状态检测，虽然按照传统分工应当是运维团队来做的，但是测试团队在这方面也有自己得天独厚的优势，对产品的深刻理解，测试角度，可以将内测测试用例调整转为适配线上数据环境的在线自动化测试用例，实现线上测试，在第一时间发现由于线上环境测试数据的多样性和量级带来的问题，及时收集触发线上自动化用例失败的测试数据来完善测试用例库，提高测试覆盖度。
总而言之，核心就是进一步提高自动化测试技术的深度和广度。
暂时想到这些，有新的想法再补充。
Reference
https://www.infoq.cn/article/docker-lead-test-innovation