测试基础 在 DevOps 蓬勃发展的时代,软件测试还有没有价值?

肖哥shelwin · 2019年06月27日 · 最后由 肖哥shelwin 回复于 2019年07月04日 · 2330 次阅读

敏捷还没远去,DevOps 就已到来。

关于 DevOps,存在多样化的定义。从字面理解,Dev 是软件开发 (Software Development),Ops 是软件运维 (Software Operation)。DevOps 就是通过软件开发和软件运维紧密、高效地协作,以更好、更快、更频繁地交付软件,从而满足市场需求、收获商业成功。

DevOps 引起了软件行业的普遍重视,各种各样关于 DevOps 的方法论和工具链如雨后春笋般层出不穷。

这是属于 DevOps 的时代。

身为软件测试从业人员,不禁要问,在 DevOps 的时代,软件测试何去何从?软件测试会不会失去存在的价值?

答案当然是否定的。

在 DevOps 中,以及在可预见的未来,软件测试不仅不会消失,反而会继续保持旺盛的生命力。具体来说,在 DevOps 中,软件测试的价值至少体现在以下几个方面。

1. 在 DevOps 中,交付软件之前仍然需要进行测试。

虽然在 DevOps 中,软件交付的速度越来越快,软件交付的频率越来越高,但是这并不意味着可以牺牲软件的质量。无论何时交付,软件必须是满足用户需求和设计目标的。检验软件是否满足用户需求和设计目的,需要使用软件测试的理论和方法。没有经过严格测试和具有质量保证的软件,用户不会买单。失去用户所导致的商业上的失败,是我们承受不起的。

那么,如何持续地在短时间内完成软件测试呢?传统的手工测试方法当然很难做到。这时就需要自动化测试。实际上,DevOps 的核心要义之一就是自动化,即把软件开发之后的诸多过程以自动化的形式去实现,包括自动化构建、自动化集成、自动化运维等。测试作为其中的重要一环,同样也需要自动化,否则测试将成为项目推进的瓶颈,DevOps 也就无法顺利实施。

2. 在 DevOps 中,软件开发的计划和执行过程需要测试介入。

如果实现了自动化测试,测试是否就一定不会在 DevOps 中成为瓶颈呢?答案是否定的,测试仍然可能成为瓶颈。如果输入给自动化测试的软件质量不够高,在自动化测试中发现许多软件问题,定位和解决这些问题必然耗费大量的资源,从而导致测试无法及时输出。测试仍然将成为瓶颈。

如果测试仅仅作为软件开发后续的一个阶段,将很难避免这种情况的出现。要想避免这种情况,需要优化软件开发的过程,让软件测试提前介入,并对软件开发产生积极影响。具体来说,在制定软件开发的计划 (Planning) 时,需要考虑软件的测试策略 (Testing Strategy)。测试策略是一个宏大的命题,我们不准备在这里详细阐述,只是简要说明两点。

一是在制定开发计划时,要考虑在软件的开发周期内,是否每个时间点 (段),都有可以测试的软件。这里的测试通常指的是端到端的测试或者与外部模块之间的集成测试。我们称此时的测试为持续测试。持续测试使得软件代码在产生的同时能够迅速得到验证,从而把尽量多的软件问题发现和解决在软件生产阶段。持续测试是 DevOps 持续交付的基础之一。

二是通过分析和识别软件功能与用户需求,将有限的测试资源基于优先级重点投入到对实现核心需求、承担关键功能、变化频繁的代码模块上,从而在有限的时间窗口内最大化测试的收益。

这种 “范围上有侧重,时间上全覆盖” 的测试策略需要在软件开发开始之前制定,并在软件开发过程中持续实施,从而保证软件始终可工作、可交付,实现 DevOps 的预期目标。

3. 在 DevOps 中,软件运行环境的改动也需要经过测试验证。

用户需要的是服务,而提供这种服务的除了产品软件,还有产品软件运行所依赖的基础设施。这种基础设施的范畴越来越宽泛,其复杂度通常远远超过产品软件本身。通过执行自动化测试,不仅能够发现软件问题,而且能够发现运行环境的问题。这意味着,不仅软件的改动需要经过测试验证,系统和环境配置之类的改动同样需要经过测试验证,从而尽力避免因错误配置而引起的服务断供问题。

4. 在 DevOps 中,开发人员需要更好地掌握测试理念和测试技能。

做好高质量的软件产品,根本还是要依靠每一个软件开发人员写出高质量代码的能力。在关于如何写好代码的各种建议中,总是能够看到 “重视单元测试” 这一条。为什么强调单元测试?这是源于一条最基本的测试理念,那就是没有经过测试验证的代码是不能信赖的。

具备了测试理念的开发人员,通常会在动手写代码之前就写好测试用例,然后通过编写代码让测试用例通过,并在不破坏用例结果的情况下,持续重构和优化代码。这就是测试驱动开发 (TDD) 的方法。无论在敏捷时代还是在 DevOps 时代,TDD 都是写好代码的重要保证。TDD 方法要求软件开发人员为自己的代码编写单元测试用例,而要设计好的单元测试用例,需要掌握测试技能。

由此可见,做好软件开发,既需要测试理念,又需要测试技能。在 DevOps 中,快速、高频的软件交付必然对开发人员掌握好测试理念与技能提出了更高的要求。

5. 在 DevOps 中,特定形态的测试仍然存在。

无论软件开发的方法论和流程如何演进,有些特定形态的测试是不可避免的,例如负载测试、性能测试、稳定性测试、安全测试等。这些测试在 DevOps 中同样存在,做好这些测试所需要的专门知识与技能不会褪色。

综上我们可以看到,在 DevOps 时代,软件测试依然具有存在价值。并且,相比瀑布时代和敏捷时代,由于软件测试的影响力贯穿了软件生命周期的多个阶段,因此软件测试的价值不仅没有降低,反而增加了。

当然,测试所具有的这种影响力绝非轻而易举可以得到。这既需要测试理论和方法的变革,也需要软件工程组织和流程的变革。在 DevOps 中,如何做好软件测试?这是另一个重要的话题,我们在后续的文章中讨论。

实际上,窃以为,无论软件工程的方法论如何演进,只要以下两个基本事实不变,软件测试就永远不会失去价值:

  • 没有开发人员/团代能够写出没有问题的代码

  • 用户不会为低质量的软件买单

你怎么看?

最后,欢迎关注我的个人微信公众号《测试不将就》,我们一起探讨高质量软件养成之道。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 6 条回复 时间 点赞

讨论价值没意义 有意义的是讨论价值多少

好像 Devops 都是测试这块在研究。

上游的人没必要研究,软件流程上游做的事情越来越少,越来越细化,能固化、系统化的都做了,他们也不需要关心什么,只有苦逼的下游岗位才在关注这个

simonpatrick 回复

有道理,说有价值容易,能算出价值多大就难了

徐汪成 回复

好吧😂

kuroky 回复

苦逼啊,说多了都是泪😂

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册