数字化时代的软件测试

数字经济高速推动着一个无情的市场,所有利益相关者通过设备和应用网络进行交互,一个微观时刻足以让市场领导者摆脱优雅。 这种对速度的痴迷能否淡化质量定性方法?《World Quality Report 2017-1028》带你来一探究竟。

Quality Report

现代QA和测试部门重点关注的领域

敏捷和DevOps已经成为数字化转型的重要工具,同时,质量保障和测试工作也随之发生变化:

  • 中央治理和控制减少,团队选择方法和技术的自由度增大;
  • 部署速度提高和应用程序日益复杂化,软件错误和故障的风险增加;
  • 软件质量对品牌的影响巨大,但这已经不是最高优先级的目标,日趋成熟的尽早质量保障实践可以帮助纠正品牌和形象方面的缺陷;
  • 最终用户的满意度和安全性是最重要的两个方面,要确保应用程序的功能和非功能质量,同时需要找到成本和风险的平衡点。

调查结果表明,现代QA和测试部门需要重点关注的领域是以下三个方面:

1. 智能测试自动化和智能分析

智能测试自动化和智能分析将成为支持测试的关键,因为它们可以实现智能决策,快速验证和自动调整测试套件。测试自动化的范围从简单地将测试活动(计划、设计和执行)自动化发展到自动化测试环境和测试数据配置。

然而,调查结果显示目前自动化还处于不足的状态,尽管从自动化中获益的组织数量在增加,但产生的价值没有根本变化,测试自动化水平仍然很低(低于20%)。

速度将推动更智能的自动化需求,需要找到提高自动化水平的方法。

2. 智能测试平台

智能测试平台需要应对测试环境、数据和虚拟化日益增长的挑战。真正的智能测试平台的远景超越了生命周期自动化,需要实现自动配置的完全自我感知和自适应环境,以及支持自动化测试数据生成和测试数据管理。

测试环境、测试数据和虚拟化是三大挑战,同时也为自动化提供了巨大的机会。结合智能生命周期的自动化,将使QA和测试进入下一个演进阶段,称之为智能QA,这已经成为行业重要的关键成功因素。

3. 适应敏捷开发流程的QA和测试部门

组织需要关注的第三个领域是适应敏捷开发流程的QA和测试部门。在敏捷和DevOps模型中,测试从中心部门转移到分散的团队。未来的测试组织需要将灵活性与效率和重用性相结合,提供测试环境、测试数据、测试专业知识和技能的测试中心将分散到各种业务线的IT团队。

FIGURE 1

QA和测试的现状与挑战

从调查结果,总结出以下关于质量和测试现状的发现:

1. 回归对应用程序质量的关注,表明在敏捷环境的新上下文里,测试已经成熟

面对开发和测试环境的复杂性以及数字化转型的速度,关注点正在回归到整体产品质量上来,这是一个进步的迹象:

  • 参与这次调查的受访者中QA和测试人员明显多于其他角色,由2016年的37%上升到2017年的41%;
  • 2016年被引用最多的目标是在上线前发现缺陷,这个数字从40%下降到2017年的28%;
  • 最终用户满意度从39%下降到34%。

客户体验和增强的安全性处于IT战略的前两位。从2016年到2017年,增强安全性需求从65%大幅下降到35%。 IT成本优化进入今年IT战略的前三位,证明QA和测试能够应对过去几年的快速变化。

其他一些对IT战略意义重大的领域包括对业务需求的响应、实施软件即服务以及实施敏捷和DevOps。敏捷和DevOps实施需求的减少幅度超过一半,从38%的受访者减少到17%,这表明这些开发方法正变得越来越主流。

2. 测试自动化正在通向智慧、智能和认知QA之路

自动化尚处于待开发阶段,测试活动的平均自动化水平约为16%。自动化产生的价值在很大程度上没有变化。测试自动化不仅应该复制现有的手动测试过程,38%至42%的组织将认知自动化、机器学习、自我修复和预测分析视为测试自动化未来的有前途的新兴技术。

智能解决方案是DevOps、移动和物联网中的新趋势。通过增加智能自动化,企业适应快速变化的业务环境能力将得到增强。

Test Automation

3. 敏捷开发中测试的挑战不断增加

  • 99%的受访者在敏捷开发测试中面临某种挑战
  • 46%的受访者认为缺乏数据和环境是最严峻的挑战,这比2016年的43%有所提高
  • 在敏捷迭代中重复使用或重复测试的难度排在第二位,由2016年的40%增加到了45%
  • 挑战数量下降的唯一领域是:难以确定测试的重点以及测试团队在计划或初始阶段的早期参与。

测试和测试环境的自动化将帮助组织解决敏捷和DevOps开发模式给测试所带来的大部分挑战。 这些智能测试解决方案使得质量保障的速度能够适应日益复杂的集成IT环境。

4. QA组织不断演进以满足双峰要求

2017年,集中式的测试组织和分散式模型之间的分配更加均衡。在许多组织中,以前的卓越测试中心(TCoE,Test Center of Excellence)已经过渡到更加灵活的测试卓越中心(TEC,Test Excellence Center),其重点在于支持和赋能,而不是实际执行测试活动。

瀑布式开发仍将在未来很长时间内实施,形成与敏捷和DevOps混合的局面。例如,组织选择定位软件开发测试工程师(SDET)的位置时,其中敏捷Scrum和TCoE分别是36%和47%。

5. 环境和数据仍然是QA和测试的难点

调查结果显示有73%的组织采用云环境、15%的组织采用容器化来执行测试,使得测试的生命周期缩短。然而,仍有50%上下的受访者分别表示在测试环境管理、测试环境利用率、适用于敏捷开发的开发和测试环境,以及早期进行集成的环境方面存在挑战。

在测试数据管理方面,分别有超过50%的受访者存在以下挑战:管理测试数据集的规模、创建和维护合成测试数据、遵守与测试数据相关规定。

Test Environment Management

6. 测试预算下降,但预计会再次上升

专门用于质量保证和测试的IT总支出的比例为26%,它已经从2016年的31%和2015年的35%下降。

但是,随着组织采用敏捷和DevOps来支持数字化转型,未来两年质量保证和测试预算将会增加,企业必须确保IT应用程序的数量和复杂性,以及随之而来的QA平台解决方案的质量。

推荐的应对策略

1. 提高智能测试自动化水平

自动化是满足日益增长的数字化转型测试需求的关键,建议组织制定一个中心战略,确定企业首选的测试工具,确定自动化计划的战略业务目标,并确定衡量结果的指标。

同时,引入基于分析的自动化解决方案,向智能化QA和智能化测试自动化转变,以确保能跟上数字化转型的速度,做到持续的发展。

2. QA和测试部门转型以支持敏捷开发和DevOps团队

首先是组织结构方面的转变,QA需要与Dev和Ops团队一起,构建集成的DevTest平台,以实现持续的测试自动化。

测试人员专业技能也需要有所改变,要加强开发、分析和业务流程方面的技术专长,以适应敏捷和DevOps模式。

3. 投资智能测试和质量保障平台

在日益复杂的IT环境下,智能测试平台有助于企业做好质量保障工作。

  • 将智能分析和机器人解决方案引入测试流程和平台;
  • 提高容器化和虚拟化解决方案的水平和使用;
  • 投资于测试数据生成解决方案,以提供更多更好的符合所有法规的合成测试数据;
  • 将容器化环境,虚拟化服务和自动化测试数据集成到一个共同的可访问流程和平台中,组织可以围绕所有测试活动制定一致的方法;
  • 采用持续监测,预测分析和机器学习工具,利用生产环境数据,提供基于业务风险和实际问题定义测试策略。

平台战略

4. 定义企业级测试平台战略

开源和服务化解决方案给质量保障和测试工具的选择带来了灵活性,但是,跨多个存储库数据连接和交换导致企业级质量状态缺乏透明度。

企业可以实施单一平台战略,指定一些技术为主要选择工具,或者创建最佳工具策略,可以涉及来自不同供应商的多种工具解决方案。

5. 定义企业级QA分析战略

前面提到过智能分析是重点关注的领域之一。为了从智能QA(智能测试自动化和智能测试平台)的投资中获得最佳回报,建议组织确定企业范围的QA分析策略。

这种质量保证分析策略决定了应该部署分析和认知解决方案的目标和领域,定义了跨QA操作的智能技术路线图。质量保证分析战略应与整体组织战略相联系,并应描述其如何实现整个组织目标。

:以上内容和图片均摘自《World Quality Report 2017-1028》,更多详细内容请参考原文。


更多精彩洞见,请关注微信公众号思特沃克

Share

聚焦测试,驱动卓越

在经历了“七年之痒”后,蓝鲸项目进入第八个年头,项目的一切趋于稳定。团队倡导持续改进,这时大家的感觉是已经尽力做到最好,似乎没有什么可以改进的了。为了突破这个局面,项目重新聚焦测试,从质量和测试的角度对现状进行了一次评估。

评估采用的是基于软件测试原则的模型,本文就是跟大家分享一下这个模型。

测试原则

在2012年澳大利亚敏捷大会(Agile Australia)上,ThoughtWorks非常资深的测试实践带头人Kristan Vingrys分享了如上测试原则,这些原则是ThoughtWorkers在多年软件测试实践基础上总结出来的。

1. 质量内建(Build quality in)

You cannot inspect quality into the product; it is already there. — W.Edwards Deming

著名的质量管理专家戴明指出:产品质量不是检测出来的,从产品生产出来后质量就已经在那了。这同样适用于软件产品。

缺陷发现的越晚,修复的成本就越高。质量内建要求我们做好软件开发每个环节,尽早预防,以降低缺陷出现后的修复成本,要减少对创可贴式的补丁(hotfix)的依赖。

推荐实践: TDD、ATDD等。

2. 快速反馈(Fast feedback)

每个环节的任何变化都能最快的反馈给需要的人,从而能够基于当下最新信息做出明智的决定,降低风险。这要求我们对系统进行频繁的测试,缩短回归测试的周期。

推荐实践:

  • 符合测试金字塔结构的自动化测试,让每一层的测试都能发挥尽可能大的价值,给出最快速的反馈;
  • 持续集成,尽早排查集成引起的问题,降低集成所带来的风险。

3. 全员参与(Involve everyone)

这次上线好多bug,QA是怎么测的?!

那个xxx组在上线前发现了很多的bug,他们的QA真给力!

成也QA,败也QA…如果还是这样的认识,那是极为片面的。测试不仅仅是QA的事情,团队成员要一起为质量负责,软件开发生命周期的测试相关活动需要全员的参与。

全员参与的好处是利用不同角色的不同领域知识和不同的思维模式,不仅可以使得测试的质量更高,同时还能最优化利用测试资源,做到价值最大化。

推荐实践:

  • 自动化测试:QA和BA结对用DSL编写测试用例,QA和Dev结对编码实现测试,生成业务人员可读的测试报告;
  • Bug bash(bug大扫除):团队不同角色一起参与的一个找bug的测试活动。

4. 测试作为资产(Tests as asset)

自动化测试帮助我们验证系统功能的正确性,好的自动化测试还有文档的功能,是宝贵的资产。如果每个项目都构建自己独立的自动化测试,没有跨项目共享,其浪费显而易见。

这个原则要求把自动化测试的代码跟产品开发的代码一起,当做资产管理起来,在不同项目间做到尽可能的复用。这笔宝贵的资产能帮助我们更好的统计跨项目的测试覆盖率,更好的优化测试。

推荐实践:利用版本控制管理工具把测试代码和产品构建代码一起管理,都作为产品的一部分。

5. 更快的交付(Faster delivery into production)

任何一个idea越快做成软件产品交付给用户,给企业带来的价值越大。

该原则要求我们把测试活动融入软件开发生命周期的每个环节,不要在后期进行长时间的集中测试;同时测试人员的关注点不再是发现更多的bug以阻止不符合质量要求的产品上线,而是把目标放在如何能够帮助团队尽快的让产品上线,让企业投资回报更早,也就是更快的赚钱。

推荐实践:自动化构建流水线、关注平均恢复时间、发布与部署解耦等。

6. 清晰一致的测试视图(Clear and consistent view of testing)

用可视化的报告给客户和内部团队展示测试的状态和产品内外部的质量,对项目的质量和风险把控是非常有帮助的。不同项目各自采用五花八门的图表样式,将不利于项目间的信息共享和比较,无端增加复杂性,带来浪费。

因此,我们需要把状态报告做的尽可能简单、清晰,并且保持跨项目的指标一致性;同时,我们不应该为了让某个指标变得好看而改变我们的行为,整个报告要诚实开放,这样才能真实反映出项目的状况。

7. 优化业务价值(Optimize business value)

开发软件无疑是要给客户的业务带来价值,软件测试也需要为这个目标服务,测试要跟业务价值保持一致,帮助客户优化业务价值。要求做到:

  • 测试不仅是保险,不仅是保证软件质量的;
  • 要有目的的关注变化的特性,不要盲目的散弹枪式的对任何特性进行测试,要有优先级;
  • 要能帮助企业驱动新的特性和功能;
  • 帮助客户创造安全的尝试新点子的环境,提供快速的反馈。

推荐实践:

  • 基于风险的测试,根据业务优先级需要调整测试策略,在测试过程中尽可能规避给业务带来的风险;
  • 生产环境下的QA,通过收集生产环境的真实用户行为和应用使用数据,对业务的优化做出贡献。

评估模型以及在项目中的应用

评估模型就是将上述七条原则的每一条细化,列出该原则对应的实践和行为,并给每个实践或行为设定0-5分的不同评分标准,最后统计各个原则的总分,形成类似下图的结果报告:

在项目中的应用

以Cristan分享的模型为基础,由Tech Lead和几个DEV、QA成立一个评估小组。

第一步:分别根据各自的理解给项目打分,结果是很有意思的,请看下图:

根据这些结果,可以看出大家的认识是不太一致的。

第二步:评估小组对模型中的每条细节进行review,做适当修改以更符合项目情况,并且在评估小组内达成共识。其中,所做的修改包括修改原有的实践评分指标、增加新的更适合项目和当前技术趋势的实践、删除过时的或者不符合项目特点的实践。

第三步:根据更新过后的模型指标对项目上的一个team做评估试点,详细分析该team对应到测试原则各个维度的well和less well部分,由评估小组成员一起打分,得到该team的评估结果图。

第四步:根据评估结果并结合项目目标排定需要改进的优先级,制定出改进action,并更新给试点team执行。

后续:试点一个周期后再次评估,并重新review评估模型,再推行到整个项目。同时,周期性的进行新的评估和制定新的action,以做到持续的改进和优化。

总结

应用程序的质量、测试的快速性、以及上线后轻松自信的更新服务的能力,是帮助企业实现业务价值最大化的关键因素之一,一直是我们所追求的。

基于测试原则的评估模型,可以帮助我们在追求这个目标的道路上少走弯路,帮助我们持续的改进,以驱动出更加卓越的软件。


更多精彩洞见,请关注微信公众号:思特沃克

Share

物联网测试地图

物联网的出现,给测试带来了很多有意思的挑战,使得众多QA开始重新思考传统的测试过程。

例如,我最近测试了一个产品,在这个产品中的移动APP会跟连接的机器产生会话。这两个设备各种各样的状态给测试场景的设计带来了特别大的挑战。下面给大家介绍一个很有用的物联网产品测试框架——物联网测试地图,它可以帮助我们管理物联网设备多种排列的复杂状态。

物联网测试因素

当我们测试简单的web应用时,通常要考虑的状态有:

  • 服务器宕机
  • HTTP请求超时
  • 网速慢
  • 授权和认证错误

测试任何互联网应用的时候,需要警惕这四种状态。对于移动应用,操作的是移动环境,需要关注额外的几种情况:

  • 离线模式
  • 在线模式
  • 杀掉Activity
  • 后台行为
  • 语言
  • 地理位置

我们再看“连接的机器”所带来的状态多样性,通常还有:

  • 机器WiFi断开
  • 机器WiFi连接
  • 机器繁忙
  • 机器休眠

这意味着即使只有上述给定的状态集,整个系统在任何时间点上可能会有96(4x6x4)种状态。

由于系统中状态转换会引入附加的约束,这些状态都不能当做独立的实体。例如,状态从“离线”变成“在线”很可能触发一系列的事件。

上述因素还仅仅是冰山一角。随着对规范的深入了解,把不同的状态跟逻辑场景结合起来将会更加的复杂。

对于静态系统的可变数据集,已有的web测试技术可以很好的用来抽取测试场景,比如all pairs(开源的配对测试工具)、等价类划分、边界值分析法等。这些技术通过淘汰的逻辑来优化测试数据集。

例如,all pairs技术会淘汰重复的数据配对组合。但是,对系统的可变状态设计测试场景时,这些技术是不可靠的,废弃的系统状态会使得系统通讯不畅。当然,这些技术对于物联网系统中的单个单元还是很适用的。

因此,非常有必要搞一个物联网测试地图。

可视化地图

大家肯定都在地理课上看过地图。但我这里所说的地图是针对测试场景的,它列出所有潜在的系统因素,在测试某个特性时可以从中抽取必要的测试场景。

产品的每个系统的n种状态在同一个可转动的圆环中列出,逻辑上相邻的状态在环中相互挨着。非功能需求(NFR)在测试复杂集成的时候很容易被忽略掉,于是把它们在一个环中单独列出。

下图就是我所说的物联网测试地图:

下面以一个例子介绍地图的使用场景,该例子仅涉及移动设备和机器交互部分,需要关注的环是设备、机器和网络。

把移动设备和机器固定在WiFi连接的状态,转动网络环,可以得到下面这些场景:

  • 未授权用户尝试访问机器会在App上触发“访问被拒绝”的错误消息
  • 服务器宕机和服务器错误会触发相应的业务错误消息——“程序出错,请稍后重试”
  • 响应超时可能有两种情形:重发同一个请求并显示“正在加载”图示,或者显示上面那样相似的错误消息
  • 非法请求会触发消息“请更新你的App”

继续保持移动设备的WiFi为连接状态,转动机器环:

  • 当机器是离线模式的时候,App应该显示“请检查机器的网络连接”
  • 当机器繁忙的时候,弹出警告“机器繁忙,无法完成请求”
  • 当机器休眠或者在另一个网络上的时候,应该显示“没找到机器”等类似的消息
  • 然后,机器调到正确的网络,应该恢复移动设备和机器的连接

切换机器环为WiFi连接,转动移动设备环:

  • 当移动设备离线时,应该弹出对应的消息或者禁掉操作按钮
  • 当移动设备恢复在线模式时,App应该发送相应的请求去连接机器
  • 当移动设备的网络从WiFi切换到3G,应该有什么样的行为?
  • 当用户正在试图连接物联网设备的时候突然接到电话,将App置于后台运行,这时候还能收到完整的请求还是需要从头开始发送请求?
  • 安卓设备杀掉一个在后台运行了一段时间的App,用户的最后屏幕状态还会保存吗?
  • 有本地化需求的App要在每个场景层面进行验证

就这样,多次旋转地图可以扩展产生多个场景。尽管有些场景可能不适合当前的特性,有些甚至跟业务需求无关,这个测试地图还是非常详尽的。

在实践层面,对于有多个QA在测试同一个物联网产品的团队,地图可以作为大家共同参考的手册。这个地图把工具、设备、场景和协议的排列以易于理解的方式呈现出来,覆盖了测试场景设计这个独特的需求,是一种非常高效的合作方式。


更多精彩洞见,请关注微信公众号:思特沃克

Share

系统级集成测试的断舍离

食之无味,弃之可惜

在企业级应用的“季度或月度发布”被认为是领域最佳实践的时候,在应用部署到生产环境之前维护一个完整的环境来进行集成测试是非常必要的。但是,集成测试环境和集成测试本身有着如下的问题:

  • 环境本身脆弱,而且通常存在手动配置部分,环境维护成本很高;
  • 环境因素导致集成测试不稳定、不可靠、反馈慢,测试失败不易定位问题,同时还会重复测试隔离组件已经测过的功能。

集成测试成为了持续交付的瓶颈,犹如鸡肋。因此,最新一期(2017年第16期)ThoughtWorks技术雷达建议企业暂缓搭建企业级集成测试环境,而是采用增量的方式发布关键组件到生产环境。增量发布涉及到一些重要的技术包括契约测试、将发布与部署解耦、专注于平均恢复时间和生产环境下的QA 。

断舍离之技术可行性

下面分别介绍技术雷达建议的这四项技术,以及在没有集成测试的情况下如何保证应用的质量、如何帮助企业做到独立增量发布。

消费端驱动的契约测试

消费端驱动的契约测试是微服务测试的重要组成部分,主要用来覆盖两两服务之间的契约关系,下面举个例子来说明什么是契约测试以及契约测试与API测试的区别。

家里有个插座,买电器的时候需要考虑插头跟插座是能配对的,也就是说插座和插头之间需要有契约。

这里的契约测试就是插座跟插头的配套性测试,包括

  • 三相/三头还是两相/两头的;
  • 电压是220V还是110V;
  • 插孔的形状:英式 or 中式?
  • 等等

API测试:对于插座本身功能的测试,需要覆盖

  • 插座能够正常通电;
  • 电压是预期的220v;
  • 接地的插孔真的能够接地
  • 等等

也就是说API测试需要测试API本身功能的各个方面,而契约测试重点在覆盖API调用的格式、参数数量、参数类型等,不一定需要涉及API本身的功能和具体的数据。

更多关于消费端驱动的契约测试,请参看文章《Consumer-Driven Contracts: A Service Evolution Patter》

发布与部署解耦

部署,就是把组件或者基础设施部署到生产环境,不对用户可见,不会影响业务和用户的使用。发布,则是将部署的组件让用户可见,对业务会产生影响。可以通过采用Feature toggle的方式实现部署与发布的解耦,做到持续部署和可控制的发布,减少组件改变带来的风险。这样,产品经理可以根据业务需求灵活控制发布给最终用户的功能组件,帮助企业业务价值最大化。

关注平均恢复时间

先看这样两种情况,思考哪种更好:

  • 系统宕机次数很少,可能每年也就一到两次,但是恢复能力很弱,一旦宕机,得花至少24个小时恢复正常;
  • 系统宕机频率较高,不过每次宕机都能快速恢复,用户甚至感觉不到。

对于第一种,平均失败间隔很长,但是一旦失败对用户的影响不言而喻;第二种虽然会频繁的失败,但是平均恢复时间很短,用户体验不受影响,当然是第二种更好。

传统的Ops团队比较关注失败发生的频率,随着持续交付和监控技术的发展,“快速恢复”成为可能。不用担心错误、失败的发生,而是利用对这些错误和失败的监控和分析,让系统做到快速恢复,可以省掉一些复杂的集成测试,也可以减少无处不在的安全攻击的影响。

生产环境下的QA

生产环境是真实用户使用的环境,通常都不能跟测试环境一样可以在上面直接测试产品的功能,不能简单的把测试环境所用的QA技术直接后延到生产环境,而其中一项在生产环境使用的技术就是监控。采用监控技术来获取生产环境的信息,对其进行分析,然后优化开发、测试过程,同时优化企业业务。更多关于生产环境下QA的内容,请参看文章《产品环境下的QA》

对上面四种技术的解释,我们可以看到:契约测试是对持续独立部署有帮助的,监控技术则是缩短平均恢复时间和做好生产环境下的QA共同的关键技术之一。接下来主要分享项目在围绕契约测试和日志监控这两块所做的实践,一起来看系统级集成测试的断舍离该如何实现。

断舍离之项目实践

项目是一个开发了七八年的老项目,团队对集成测试也是进行了多次的调整,经历了“七年之痒”后依然觉得是鸡肋:

  • Pipeline上执行非常不稳定,总是“随机挂”,不能真实反映问题;
  • 系统复杂,集成测试自然也不简单,每次顺利执行的时间都需要半个小时以上,何况还有很不稳定的情况,最严重的时候导致QA超过一周拿不到包部署;
  • 通过集成测试发现的应用程序的缺陷半年也难得出现一个;
  • 随着系统逐渐变得复杂,集成测试维护的成本也不断增加。

可以看出,集成测试已经严重阻碍了项目持续交付的进行,不得不对其断舍离了。

(一)测试策略调整

断舍离的第一个部分是从集成测试本身入手,调整测试策略。步骤如下:

  • 不再添加新的功能层面的自动化测试,原有的集成测试部分能用底层的UT、API测试覆盖的尽量下移;
  • UT和API测试不能cover的服务间的契约关系通过增加契约测试来保证;
  • 从CI上摘掉原来的集成测试,加速pipeline出包,然后添加Smoke测试到QA环境执行;
  • 不管是在测试环境还是生产环境发现缺陷,都添加对应的测试。

整体策略调整思路是根据测试金字塔的结构进行调整,把测试尽量往下层移,但并没有全部去掉集成测试,只是缩减到非常关键的路径覆盖,最终测试结构调整如下图所示:

(二)日志监控、分析和优化

没有了Pipeline上的集成测试,直接上到QA或者prod环境,那么加强日志监控变得尤其重要。因此,断舍离的第二个部分是日志的监控、分析和优化。

日志数据采集

项目使用的日志分析工具是Splunk,使用该工具从下面几个方面来着手采集日志数据:

  • 在Splunk上设置日志监控的Dashboard,主要用来监控API的请求失败、错误的日志,还有API执行时间等性能相关内容。如下图所示:
  • 设置预警邮件提醒:对于一些存在严重性能问题的API请求,通过邮件的方式进行预警提醒,如下图:
  • 主动查找错误日志:对于一些生产环境中用户反馈回来的问题,通过主动查找错误日志的方式去定位。
  • 前面的几个机制同样应用于QA和Staging等测试环境,以通过日志分析尽量提前发现问题。

日志数据利用

利用前面几种方式采集到的日志数据,从下面几个方面进行分析和优化:

  • 发现和定位系统功能问题,分析系统用户的行为习惯,优化业务;
  • 发现和定位安全、性能等非功能问题,进行修复和优化;
  • 发现和分析日志记录本身的不足,规范日志记录,从而进一步增强日志给问题诊断带来的帮助,形成良性循环。规范日志记录主要涉及这些点:统一日志输出路径、统一日志记录格式、清晰定义日志级别,并且把添加必要日志作为story开发流程的一部分,QA会参与日志评审。下图是Splunk里看到的项目最新优化的日志记录格式:

项目对集成测试断舍离才刚刚开始,正在不断摸索着前进,目前能看到的最直接的影响是pipeline出包明显加快,由以前的好几天出不来一个包变成一天能出好几个包。最振奋人心的是本周刚刚发生的事情:前一天下班前报的bug,第二天上午就已经修复出包可以测试了。

写在最后

系统级集成测试虽然有各种问题,不一定会因为集成测试挂掉而发现很多问题,前面也讨论了断舍离的可行性,分析了项目断舍离的实践,但集成测试并不是用来发现问题的,而是一道对质量把关的屏障,关键路径的必要测试是不可替代的。因此,我们提倡减少集成测试的数量,合理调整各层测试的比例。

系统级集成测试的断舍离需要团队有持续、递进、稳定的交付能力,需要保证用户不会受此影响,企业业务能够正常运转。系统级集成测试的断舍离过程不是一蹴而就的,凝结在集成测试上的心血也不是那么容易放弃的,需要很多的平衡和取舍,并在整个过程中要不断的关注系统的质量和风险,及时作出相应的调整。


更多精彩洞见,请关注微信公众号:思特沃克

Share

为什么不能每周发布一次?

“看,车来了!不过貌似咱赶不上这趟车了吧?”

“啊!那快点跑,错过这趟就得再等半个小时!”

……

好无奈,可是真的赶不上也没有办法,这个场景很多人都经历过。

“这个release又是一定包就开始上hotfix,四天跟了四个,我根本没时间做回归测试!” QA小静同学抱怨道。

“每次都是定包后就开始无休止的上hotfix,咱们还不如改成每周发布一次!”Dev大鹏同学也被hotfix折磨苦了。

这是发生在蓝鲸项目中一次真实而平常的对话,跟前面赶公交车的场景有什么关系呢?

发车间隔与发布周期

发车间隔的不同带给乘客的感受会完全不同。

有些公交车很少,每半个小时一趟,有时候眼看着一辆车来了又走了,没赶上会无比懊恼,下一趟还得等上半个小时,实在着急的可能会考虑叫一辆快车赶紧走。

而有些公交车发车间隔非常短,几分钟一趟,就算错过一趟也无需等待太久,只要不是着急去救火,乘客一般不会太在乎。

项目的不同发布周期带给客户的感受也是类似的。

蓝鲸项目的发布周期跟第一种公交车发车间隔非常类似,是四周发布一次。如果功能没能在这次上线,或者有导致功能无法正常工作的缺陷,得再等一个月才能再次上线。一个月,那是多少白花花的银子啊!对于那些特别重要的功能,客户着急就会要求上hotfix,于是就出现了前面小静和大鹏的对话场景。

Hotfix是否真的能解决软件交付过程中的问题呢?其实不然。

Hotfix的引入带来很多额外的工作,影响新功能的按时交付,会打乱交付节奏,有形成恶性循环的趋势。既然这样,大家一定希望能把问题解决,而且通过公交车的例子很容易想到前面大鹏说的那个方案。

如果发布周期缩短,比如说缩短为一周甚至更短,这次没上的功能也不用那么着急的通过hotfix来上线,就能解决问题。那么蓝鲸项目为什么不一周发布一次呢?

如何才能缩短发布周期?

1. 合适的迭代计划和合理的需求切分

半个小时一趟的公交车,就算车子足够大、能够承载半个小时到达的乘客数,也会导致乘客等待时间过长,造成很多不便。要解决这种情况,可以把大型公交车换成多辆小型车,增加发车次数,缩短发车间隔。发车间隔缩短到多少,车子换成多大都是需要仔细分析和考虑的问题。

映射到蓝鲸项目,要缩短发布周期,就得有相应的小规模需求正好能够乘坐小发布周期那样的小车,因此要做好发布计划和需求切分。

这样对需求源的要求很高,需要客户那头的紧密配合。要想缩短发布周期,首先必须得有足够的、粒度合适的功能需求,能够正好安排到较短的发布周期上线。如果需求范围不能提前确定好,就没法提前做好短周期发布计划,不可能把发布周期缩短。

2. 强大的开发能力

在把乘客的需求分析清楚之后,缩短发车间隔非常关键的一点就是要有足够的安全的车和靠谱的司机。如果这一点满足不了,其他都免谈。

对应到蓝鲸项目,安全的车子和靠谱的司机组成了拥有强大开发能力的团队,包括架构支撑和人员技能。

车子就是对持续交付友好的技术架构,需要减少模块间的依赖,比如采用微服务。蓝鲸项目是一个七年之久的老项目,很多陈年依赖已经形成,要拆分不是一时半会的事情,团队正在朝着这个方向努力。

司机就是我们的开发团队,除了要有必要的开发技能外,要做到靠谱就得透彻理解持续交付的精髓,需要团队中人人都有质量意识,人人都有发布周期的紧迫感,并且能够做到高效合作,从需求划分、代码质量、测试保障等做好各个环节的工作,做好缺陷的预防和监控,不让严重缺陷流入后面阶段。

蓝鲸项目由于新人较多、人员流动大等原因,质量意识和紧迫感都有待提高。不过,在各位QA的影响下,这些问题都在改善,新人的技能也在不断的学习和实践中得到提高,但仍然不能放松警惕,需要时刻保持向前的精神面貌。

3. 充分必要的测试支撑

有了足够的安全的车和足够靠谱的司机,还得保证路况够好,这样才能做到不管到达哪个站,间隔都是相同的。

要想蓝鲸项目的持续交付能够顺利前行、一路畅通,需要严格做好质量内建工作,各层都有充分必要的自动化测试保护,减少新功能开发过程中对老功能的破坏;同时持续集成流水线也要健全,不能耽误代码提交和出包,以防影响开发和测试的进度。

蓝鲸项目开发年限已久,复杂度很高,在持续交付的路上行走的有些坎坷。目前团队正在这些方面努力采取改进措施,取得了不少进展,但确实还有不少提高的空间。

前景堪忧?

过去七年,蓝鲸的持续交付之路有些坎坷,但不应因此而失去信心。

通过跟公交系统进行对比,我们可以看到蓝鲸项目要缩短发布周期、杜绝hotfix,需要从需求切分、迭代规划、技术架构、团队能力建设和测试策略调整等多方面进行优化,才能保证持续、快速的发布节奏,这是一个系统的问题。

七年之痒已经平安度过,蓝鲸团队正在采取相应的改进措施,一旦做好了上述各方面的优化,在下一个七年,一周发布一次或者更短的发布周期都将不是梦!


更多精彩洞见,请关注微信公众号:思特沃克

Share