符合架构的测试

架构会对测试带来重要的影响。测试单体系统的方式与测试松耦合系统的方式是不同的。我们以微服务作为松耦合系统的典型示例。下面将会看到,它们挑战了我们之前对于测试的定义。

康威定律

Melvin Conway观察到组织的结构会对它们所创造的产品带来显著的影响:“任何组织在设计一套系统时[……],所交付的设计方案在结构上都与该组织的沟通结构保持一致。”

康威定律说明公司的软件架构通常会反应组织的结构。另一方面,我们如何组织团队会对架构和测试方法带来巨大的影响。

架构和组织结构之间的互相依赖也会反映到BAPO模型中,该模型假设在软件工程中,需要解决四个关注点:业务(Business)、架构(Architecture)、过程(Process)和组织(Organization)。从根本上来说,这个理念是基于业务需求来定义架构。但是,正如Jan Bosch(2017)所言,大多数的公司并不符合BAPO,而是遵循OPAB,也就是以组织结构作为基础来定义架构。

如果组织想要改变软件产品的架构的话,那么它的组织结构(包括测试如何组织)可能是一个推动者,也可能是一个障碍。让我们看一下不同类型的组织结构:

  1. 面向功能的组织能够优化成本。这些组织一般会有层级的结构,结构中包含专家团队,他们负责其功能领域。
  2. 面向市场的组织能够优化速度。这些组织一般会比较扁平化,具备跨功能和自治的团队,他们负责实现和交付产品,不过这样有可能会导致在整个组织范围内产生冗余。
  3. 面向矩阵的组织试图将面向功能和面向市场的理念结合起来。

关于这方面的更多信息,参见:Gene Kim(2016)。

测试微服务

像微服务这样的松耦合架构该如何进行测试呢?

松耦合的系统遵循服务自治的原则,因为它的架构就是基于各个自治的组成部分分解而成的。

越来越多的组织在采用微服务,以便于提升团队的自治性并加快应变的速度。微服务应用由小型、版本独立且可扩展的服务组成,这些服务以客户为中心,它们彼此之间以定义良好的接口通过标准协议进行通信。

微服务

  • 是自治的并且真正松耦合,因为每个微服务都是与其他的微服务物理分离的。
  • 只负责一项功能(功能分解)。
  • 可以独立部署和发布。
  • 应该嵌入依赖,以确保集成点的数量是可管理的。
  • 应该能够通过自治性实现弹性和故障隔离。

这对测试意味着什么呢?

如果我们面向领域并且针对每个业务功能进行垂直切分,那么依然可以有分层的架构,但是层是次要的组织机制。自治的产品开发团队负责实现、测试和交付业务功能:

微服务通常会伴随着DevOps:在敏捷和DevOps中,在开发阶段开始之前,并没有架构师定义整体架构的单独设计阶段。相反,架构会以更加联合的方式来定义,跨越多个项目,并且被整个团队所拥有。

那么这些系统的测试方式又会发生什么样的变化呢?同样,测试不会在一个单独的测试阶段来完成。与之相反,每个人都要为质量负责。

没有独立的测试阶段:

DevOps和持续集成&持续交付(Continuous Integration & Continuous Delivery,CI & CD)解决了快速且高质量为客户交付功能的需求。这意味着测试必须要提供快速和有意义的反馈。为了快速且有自信地发布版本,需要从持续测试(Continuous Testing)中得到立即的反馈:

  • 所有的测试几乎都要是自动化的。对于CI & CD来说,启用持续测试是至关重要的,因为它提供了关于质量的及时反馈。同时,它能够让团队快速掌握和应对。
  • 但是,这并不意味着持续测试只与自动化测试相关。我们接下来将会看到,它是一个全面的方法,目的是得到质量的及时反馈:

测试并不是一个隔离的活动,而是集成到一组综合的实践中,以便于提升质量:“依然有很多的公司在努力改变流程以提升质量,从‘测试或检查质量’转变到一开始就保证高质量,这要通过文化、设计、工艺以及领导力才能实现”(Ben Linders 2017)。

开发人员在确保高质量方面扮演了重要的角色,另外,软件工艺原则也能促进质量的提升。软件工艺指的是软件开发过程中专业性:“工艺精湛的软件意味着,不管应用多么古老,开发人员都能很容易地理解。它的副作用众所周知并且能够得到控制。具备很高很可靠的测试覆盖率,设计清晰简洁,代码能够很好地表达业务语言”(Sandro Mancuso,2015)。

持续测试(通常)意味着向左转和向右转:

向左转和向右转是什么意思呢?

测试通常是按照特定的顺序执行的,从(左侧的)单元测试开始,因为它们能够提供快速的反馈,后续的测试则需要更长的时间来执行,但是它们能够增加我们对候选释放版本的自信心:

这里,有一种左转的趋势,那就是自动化单元和组件级别的测试,在持续集成&持续交付(CI & CD)管道中执行,这个管道是由产品开发团队所拥有的。但是,这是有其成本的:考虑到集成场景的复杂性和动态性,集成测试会变得更加具有挑战性。

如果我们要对比讨论隔离状态以及基于协作的测试,那么很重要的一点就是要区分独立性的(solitary)和社会性的(sociable)测试方式:

  • 在独立性的测试活动中,被测试的软件单元是隔离的,要将协作者(上游依赖)替换为测试替代品(test doubles),比如mocks或stubs。
  • 在社会性的测试活动中,被测试的软件单元要与协作者一起进行测试。

按照测试金字塔的理念,微服务测试的关注点在于要有很多的单元测试以及一组全面的组件测试。微服务首先会彼此隔离地进行测试,然后进行少量的集成,最后是端到端测试。很多端到端测试通常被视为一种问题,因为它们的执行比单元和组件测试要耗费更长的时间,并且也会更加脆弱。但是,很有意思的一点在于,有一种关于测试金字塔理论对微服务测试的价值的争议,以及如果关注单元和组件测试,并使用它们来替代集成测试是否依然是合理的(参见样例:Cindy Sridharan 2017和André Schaffer 2018)。这是一个合法性的问题,因为如果微服务的集成是最具挑战性的,那我们是否可以不要更多关注集成测试,而是更多的依赖社会化的测试?我认为,答案可以说是也可以说不是:如果微服务的嵌入式依赖没有提供独立的业务功能,那么将微服务与这些依赖一起进行测试是非常有意义的。在微服务中,这种类型的社会化测试应该在与其他微服务的集成测试展开之前完成,其他的微服务会封装别的业务功能。如果没有足够的单元和组件级别的测试,分析集成测试的故障会更加复杂。同时,除了传统的集成测试以外,API以及契约集成测试也是非常重要的,因为它们有助于保证微服务协作管道之间能够互相独立。因此,在合适的测试等级进行测试是非常重要的。

另外一个方面也很重要:对于微服务来说,集成场景是复杂和动态的,要有多少集成测试才够用呢?将更多的精力投入到测试中以及在生产环境中快速探查问题之间要有一个权衡。除了左转之外,还有一个趋势,那就是将测试与生产环境的部署和监控更加紧密地连接在一起。生产环境的核对实验(controlled experiment)有助于快速识别问题并得到真实用户的快速反馈。

不同类型的生产环境流量测试有何差异?

这意味着在测试方面还有向右转的趋势。

如前文所述,面向市场的组织针对速度进行了优化,在测试领域的右转有助于完成他们的目标。作为持续实验的一部分,可以进行探索和学习。借助核对实验,在现实中使用应用程序的时候,我们能够得到客户的反馈。

核对实验也能支持弹性架构。正如我们在前面所讨论的,微服务应该通过自治实现可靠性和故障隔离。但是什么是弹性呢?“我们通常认为脆弱系统的对立面就是健壮的系统,因为脆弱的系统通常不会过多(换句话说,说不上喜欢或不喜欢)关注压力。实际上,健壮的系统仅仅脆弱程度有所降低而已。脆弱系统真正的对立面是能够从压力中受益的系统。Nassim Taleb将这样的系统称为反脆弱(antifragile)的”(Dave Zwieback 2014, p. 3)。传统的测试方式是在版本发布之前对系统进行测试,以确保稳定性。但是,这些测试能够支撑健壮性,但是无法支撑系统的“反脆弱性”。有种不同的测试方式就是在生产环境中引入故障,运行主动可控的混乱(chaos)实验。这种精心设计的混乱能够指导产品开发团队思考故障的容忍度和隔离故障的可能性。

总结

对于微服务这样的松耦合系统,测试不应该在一个单独的测试阶段由专门的测试团队来进行,而应该由跨职能的产品开发团队来完成。在测试中,有一种向左的转变,确保团队能够保持自治,同时还有一种向右的转变,这种转变强调的是探索性和实验性。

持续测试(Continuous Testing),既包括CI & CD中的自动化测试,还包括实验性和探索性的文化,它能够保证快速且稳定地发布松耦合的服务。

参考文献

  • Ashby, Dan (10/2016): Continuous Testing in DevOps.
  • Bosch, Jan (11/26/2017): Structure Eats Strategy.
  • Conway, Melvin E. (1968): How do Committees Invent?
  • Kim, Gene (11/16/2016): How to Design With Conway’s Law in Mind.
  • Linders, Ben (2017): What Drives Quality: A Deep Dive into Software Quality with Practical Solutions for Delivering High-Quality Products. Ben Linders Publishing.
  • Mancuso, Sandro (2015): The Software Craftsman. Professionalism, Pragmatism, Pride. Pearson Education.
  • Schaffer, André (01/11/2018): Testing of Microservices.
  • Sridharan, Cindy (12/30/2017): Testing Microservices, the sane way.
  • Zwieback, Dave (2014): Antifragile Systems and Teams. O’Reilly Media.

关于作者

Stefan Friese 是HERE的测试与研发主管,目前在柏林工作。在当前的职位中,他带领团队为一些实时位置的Web服务来构建持续集成&交付的测试功能,这些服务托管在HERE云平台上。Stefan有着14年的工作经验,曾经担任过测试主管、性能测试人员、软件工程师以及质量工程师。你可以通过@y3key在twitter上关注Stefan的动态。

原文发布于微信公众号 - 程序你好(codinghello)

原文发表时间:2018-06-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏熊二哥

项目管理深入理解04--时间管理

进入比较重要的时间管理一章,重点是对WBS,工作单元,活动,资源,时间这一条线索的理解,熬夜加班到4点,继续俺的学习了,正好等等联调数据的状态,加油,熊二。 ...

2366
来自专栏哲学驱动设计

框架模块设计经验总结

    三个月没写日志了,比较懒散……下半年准备做OEA 的 B/S 版本,比较复杂,需要从架构设计开始认真入手。正好今天到了部门反思的时间,今天先把原来的一些...

20910
来自专栏WeTest质量开放平台团队的专栏

鲜科技!内部云游戏沙龙分享

云游戏,也叫订制游戏,是在线游戏的一种不只是网页游戏或者是微端游戏,是一种游戏输入,运算,和画面显示分离的技术。目前有2种主要的云游戏形式:基于视频串流的云游戏...

4957
来自专栏奇点大数据

资源!吴恩达视频文字版及笔记整理

不过,这种视频在线课程也有其弊端,就跟很多人不喜欢微信语音一样,想要在视频中查找和回顾相关的知识点并不方便。

1451
来自专栏编程坑太多

『高级篇』docker容器来说微服务优势和不足(四)

1853
来自专栏Alan的UX笔记

交互设计|设计方案记分对比法

1436
来自专栏SEO

「研究」分析语音搜索排名因素

4498
来自专栏SDNLAB

现代数据中心标准COTS服务器的演进

数据中心内的x86商用成品(COTS)服务器的标准化已经经过了很长时间,因为该架构提供了多功能、低成本、易于集成、更有效地维护和管理配置文件,总而言之,其成本低...

3434
来自专栏Java架构

高并发风控技术解密(上)

风控在任何一个公司都是比较神秘的存在,不仅线上很少分享,从安全角度讲也很少对外披露它的架构及设计。本人将就参与的风控建设谈谈风控的技术。(本文来源于本人内部分享...

2726
来自专栏鹅厂网事

大数据在服务器运营中的应用

前言 腾讯公司从2012年开始,通过对服务器运营流程、工具系统的建设,服务器从一线到三线的运营基本转入线上自动化。在服务器静态配置、动态的运行状态和生命周期各个...

2887

扫码关注云+社区

领取腾讯云代金券