Hello 大家好，第一次在 TesterHome 发帖，这个帖子主要是从 DevOps 对测试所带来的变化层面的思考，希望能抛砖引玉，一起探讨下未来测试究竟有什么样的可能。

测试同学在 DevOps 里如何定位？

有人说 DevOps 其实是 DevTestOps 的缩写，那么测试同学在 DevOps 里如何定位呢？实施 DevOps，需要极小的交付颗粒度，极快的交付速度。为什么要这样做，首先小颗粒度的上线，能最大程度的保证线上系统的稳定性。有研究表明，线上的故障 70% 以上都是变更引起的，越小的交付颗粒度，变更的程度就越小。

变更小带来的优点就是容易测试、容易定位问题、容易回滚、影响范围小、牵涉开发人员的精力小。这么一来，DevOps 里可能没有传统意义上的专职测试人员了，作为测试人员不要悲观，其实也没有传统意义上的专职开发人员和专职运维人员了，所有人都是为了从开发到上线整个过程而负责，甚至要对更为前置的需求假设以及更为后置的价值验证的过程负责，所有人的角色不在是固守一亩三分地，而是在更广阔的的空间进行耕耘协同。

每个人都要让自己的工作变得有价值、有效率、有质量

开发人员不仅仅再只是实现需求，将代码交付给测试同学进行部署和测试，而是要保证自己实现的代码是有价值的、有效率的、有质量的。开发人员不仅要高效率的代码实现，保证代码是高质量可交付给用户的，更要让自己实现的代码在产品层面有价值。无论我们的开发效率多快，质量有多高，实现很多没有价值的代码是没有任何意义的。

那么测试同学呢？我们设想一下，在成功实践 DevOps 后，交付颗粒度很小，交付速度很快，基本上每次就是几行代码或者一两个数据库字段的变更。但是这样的变更频率很快，有的时候甚至是连续发布。我们很容易感觉到，要达到这样的模式，不仅需要完备的生产环境交付系统、监控系统，业务系统也要针对基础架构体系进行调整。但是还有一些必须的工具，我们试想一下，整个研发体系需不需要工具平台进行支持？研发效率和质量需不需度量？研发过程需不需持续改进？我们千万不要觉得，研发体系的工具平台应该是运维或者其他角色来提供，度量和持续改进应该是领导来推动的。这些工作在 DevOps 其实也属于测试同学的本职工作一部分。做好这些工作，足以使测试人员在 DevOps 体系下面有成绩斐然的职业生涯和影响力。在 DevOps 体系里，所有人都为了让交付有高价值、高质量、高效率而努力。

任何模式都需要进行迭代和改进

当前的现状不一定是最优的，任何模式都需要进行迭代和改进，DevOps 体系本身就是持续改进的结果，即使当前已经开展了 DevOps，仍然需要分析现状，找到待改进点，制定目标和方向，推动团队实施改进，我们甚至要思考 DevOps 的下一代是什么。

极小的交付颗粒度，极快的交付速度，是手段，不是最终目的，我们的最终目的是要让交付有高价值、高质量、高效率。所有能有助于到达我们目的得工具或者方法都是研发体系的工具平台的范畴。为了使交付颗粒度和交付颗粒度达到一定的程度，需求、变更、版本、分支、测试用例、测试环境、部署的产生速度和颗粒度也会变化，所有的过程和产物都应该进行精细的管理，因此，首先应当对这些部分的管理进行系统化的设计和开发。

举个简单的例子，随着业务的开展，应用和域名的数量越来越多，如果没有一个系统统一的管理，那么一段时间后这些应用和域名是做什么的，负责人是谁，都分属于哪些部门，调用数以及流量数都是多少都无从得知，有些业务甚至已经停止了，域名和应用还在线上跑着，当然这些可能适合偏运维角色的开发人员来做这个系统。

同样的道理，我们发掘一下研发测试过程中的工具，比如测试用例的管理，DevOps 体系会怎么影响我们的测试呢，我们的测试用例应该如何变化呢，我们肯定不希望每次迭代都维护一个庞大的用例结构，因为如果这样的话牵扯的精力太多，根本无法做到快速交付，但是如果我们不考虑用例的结构化，我们又不希望写的测试用例是一次性的，写完就放到用例库里吃灰了，一段时间后都自己都不认识自己的测试用例了，我们希望的是测试用例是高价值、高质量、高效率的，能够尽最大可能的复用、回顾和重构。为了达到这样的状态我们就要修改我们的用例管理体系和用例管理工具，例如用例的形式是什么，由谁写，由谁审，由谁执行，如何管理都需要进行思考和改进。

以上是很简单结合对 DevOps 认知，对于测试未来进行发散思维式的一些思考，只是写了个开头，希望抛砖引玉，未来究竟有什么样的可能。