BY林子

本文首发于「BY林子」，转载请参考版权声明。 去年，我们在《数字化时代的软件测试》中看到了2017年软件质量方面的趋势和给测试人员的建议。又一年过去了，大家对软件质量保障和测试的关注有哪些变化呢？我们一起来看看这份质量报告《World Quality Report 2018-19》有些什么新的内容。 01 关键趋势质量保障和测试的职责已从单纯的缺陷发现转变为客户满意度和业务成果的推动者了，这是个根本性的转变，它所带来的影响可以从今年这份质量报告的多个部分体现出来，而最能体现这个转变的是质量保障和测试的目标，受访者认为目前质量保障和测试策略的最高目标是“确保终端用户的满意度”。不断增长的以客户为中心推动的IT趋势也正在改变质量保障的目标和期望，比如业务数字化和敏捷、DevOps、云服务的采用。 以客户为中心要求我们的IT系统能够在速度、安全和便利性方面增加用户满意度，对应的关键IT趋势有以下几个方面。 1. AI在质量保障和测试中的作用AI的发展对于质量保障和测试主要有两个方面的影响：一方面，AI会促使企业将测试转变成完全自生成、自执行和自适应的活动，也就是用AI技术来优化测...

本文首发于「BY林子」，转载请参考版权声明。 摘要：本文总结几类项目中跟时区相关的问题，给大家分享一些基本的时区知识，以及如何在软件开发和测试中注意考虑时区因素，以避免因时区而导致系统功能的问题。 场景一 “小D，我发现调整不同的timezone（时区），咱们的KPI计算结果可能会有一天的误差…” “啊！我看看什么原因。” “嗯啦，KPI务必是准确的，可不能有误差…” “小Q，我知道啦！咱们的工单任务完成时间记录的是UTC时间，是考虑了timezone转换的，但是缺失信息的记录并没有考虑… ” “为什么缺失信息不记录UTC时间呢？” “因为缺失信息只记录日期，并没有时间。” 蓝鲸项目的小Q和小D说的是啥呢？下面先来借助维基百科的解释来介绍时区和UTC的概念： 时区（timezone） 时区是地球上的区域使用同一个时间的定义。以前，人们通过观察太阳的位置决定时间，这就使得不同的地方的时间有所不同（地方时）。1863年，首次使用时区的概念，通过设立一个区域的标准时间部分地解决了这个问题。 UTC 协调世界时（英语：Coordinated Universal Time，法语：Te...

本文首发于「BY林子」，转载请参考版权声明。 01 引子一年前，在一次客户(老外)的演讲中，晕晕乎乎的在一大段英文中听到了RPA这个词，当时大概查了一下，了解到RPA是机器人流程自动化（Robotic Process Automation)的简称，跟自动化有些关系，但是当时也没搞太明白。 半年前，听说客户的IT部门开始培训大家用RPA工具UiPath来做自动化测试，但是遇到了一些麻烦，问我们这边是否有相关经验。还真不好意思，没有接触过，于是决定研究一下RPA到底是个什么玩意。 02 RPA初印象首先看到的是埃森哲的《Getting Robots Right》文章，介绍了RPA的常见误区、案例分享，以及RPA的关键成功因素等，都是高大上的介绍，对于我这个没有接触过的人来讲还是有些云里雾里，只是对RPA有了大概的认识。 文章提到RPA是使用软件来完成重复的、结构化的、基于规则的任务，从而大规模地自动化业务流程，最终实现企业级智能自动化，它是基于办公室的等效生产线机器人，基础技术是机器学习和人工智能。 简而言之，RPA就是用机器人（软件）来取代人完成工作任务。 文章还介绍了RPA可...

本文首发于「BY林子」，转载请参考版权声明。 01 质量内建的关键是缺陷预防近几年，软件开发过程中的质量内建正在逐渐被大家所重视。越早发现的软件缺陷，修复成本越低。质量内建要求在软件开发生命周期的每个阶段做好质量保障工作，预防缺陷的产生。 缺陷预防说到缺陷预防，通常能够想到的就是测试前移（QA从需求阶段开始介入、TDD/ATDD等）、Code Review等实践，正向的来预防缺陷的产生。 但是，软件系统的生态环境越来越复杂，不确定性增加，缺陷预防的难度也在增加。如果缺陷已经产生，是否还能被利用来帮助质量内建呢？ 在《软件缺陷的有效管理》一文中介绍了基本的缺陷分析方法，接下来我们一起探讨一下如何利用缺陷分析来帮助质量内建。 02 缺陷分析与质量内建缺陷分析最为关键的是根因分析，找到根因，能够减少缺陷重复出现的可能性，在后续阶段做到缺陷预防，帮助质量内建。 1. 分析根因引起缺陷的原因主要有下面这几个方面： 需求缺失或者需求不清晰 设计问题 编码错误 测试不够 环境相关（硬件、软件、配置等） 利用5 Why分析法[1]根据缺陷的表象，多问几个为什么，找出根因。下面...

本文首发于「BY林子」，转载请参考版权声明。 01 软件系统的脆弱性伴随着不断演进的软件技术和架构，日趋复杂的软件系统基础设施，以及大量增加的业务和数据，开发和运行环境中不稳定的因素也在增加，系统行为变得不可预测，同时软件系统的不确定性日益严重。 人们无法通过预先设定的测试场景和测试脚本去测试软件，预生产环境已经不够用，软件系统的质量保障工作受到挑战，软件系统变得脆弱。 软件系统的脆弱性面对复杂的环境和脆弱的软件系统，该如何保障软件的质量呢？借用反脆弱[1]的概念，我们可以把软件的质量保障工作延伸到生产环境，利用这些不确定因素，从中受益，构建反脆弱的软件系统。 生产环境下的QA就是利用系统在生产环境的不可预测性，通过监控预警等方式收集生产环境的信息，总结分析以指导软件开发和测试过程，从而提高软件系统的健壮性、优化业务价值。其中，日志处理是最为关键的一个部分。 02 日志处理的常见误区与改进思考提到日志处理，通常都会想到Ops（可能有Ops和开发人员组成，下面简称Ops）团队，认为日志处理是Ops该做的事情，往往关注的都是利用什么工具、什么技术来监控和分析，很少听到有对仅仅Op...

本文首发于「BY林子」，转载请参考版权声明。 “小光，今天那个诡异的生产环境问题找到原因了吗？” “还是数据问题！之前做的一个功能有一部分数据迁移工作没有做好，导致生产环境有脏数据，委托人的联系人已经不为该委托人服务了，应该移除掉的…=-#~)@/-$*…” “又是脏数据…@=@” “嗯，好在不是代码问题。” 这是在蓝鲸项目发生的真实对话。其中提到的脏数据（Dirty data），也叫坏数据（Bad data），通常是指跟期待的数据不一样、会影响系统正常行为的数据。 蓝鲸项目的QA会定期分析生产环境的缺陷，当定位某个缺陷为脏数据引起之后，往往就到此为止了。生产环境下的缺陷分析流程是这样的： 生产环境缺陷分析流程调查分析生产环境缺陷，到最后定位是数据问题的时候，总是让人浑身轻松… 于是，“脏数据”就跟测试的“随机挂”一样，成为了光荣的“背锅侠”！ 脏数据 ≠ 代码问题，真的是这样吗？先来深入了解一下脏数据。 01 脏数据是怎么回事？脏数据产生的原因多种多样，有的甚至很难解释清楚到底发生了什么… 通常，以下原因可能造成脏数据： 脏读：读了事务处...

本文首发于「BY林子」，转载请参考版权声明。 数字经济高速推动着一个无情的市场，所有利益相关者通过设备和应用网络进行交互，一个微观时刻足以让市场领导者摆脱优雅。 这种对速度的痴迷能否淡化质量定性方法？这份《World Quality Report 2017-2018》带你来一探究竟。 01 现代QA和测试部门重点关注的领域敏捷和DevOps已经成为数字化转型的重要工具，同时，质量保障和测试工作也随之发生变化： 中央治理和控制减少，团队选择方法和技术的自由度增大； 部署速度提高和应用程序日益复杂化，软件错误和故障的风险增加； 软件质量对品牌的影响巨大，但这已经不是最高优先级的目标，日趋成熟的尽早质量保障实践可以帮助纠正品牌和形象方面的缺陷； 最终用户的满意度和安全性是最重要的两个方面，要确保应用程序的功能和非功能质量，同时需要找到成本和风险的平衡点。 调查结果表明，现代QA和测试部门需要重点关注的领域是以下三个方面： 1. 智能测试自动化和智能分析智能测试自动化和智能分析将成为支持测试的关键，因为它们可以实现智能决策，快速验证和自动调整测试套件。测试自动化的范围从简单地将测...

本文首发于「BY林子」，转载请参考版权声明。 曾经在《敏捷中的QA》一文里介绍了敏捷开发模式下，QA如何参与从需求到测试的每个阶段，在每个实践中如何跟不同角色的合作，以及敏捷QA跟传统开发模式下的测试人员的区别等。 这些内容在今天依然适用，但在真实项目中往往情况比较复杂，总会听到一些困惑或者是质疑的声音。 在敏捷项目团队摸爬滚打多年以后，我想跟大家一起再来聊聊这个话题，下面逐个来分析我所见（听）到的质疑或困惑。 01 敏捷QA流程必须严格遵守 “如果QA没有参加Kick-off，我们拒绝做Desk Check；如果没有QA参与Desk Check，我们拒绝测试。” 从需求分析到生产环境，推荐QA参与每一个环节，跟多个角色进行充分的沟通和合作。 有人把这个当做圣旨，觉得不管怎样都不能漏掉某个环节，但难免有特殊情况。比如，由于QA请假或者开会等，错过了某一次Desk Check，一定要求等有时间了（甚至第二天或第三天）再补上，没准那个时候代码都已经上到测试环境，完全可以直接测试没必要在折腾大家来做一次全面的Desk Check了。 QA参与每个环节的目的是尽可能早期发现需求或者设...

本文首发于「BY林子」，转载请参考版权声明。 最近几年，微服务架构越来越火爆，逐渐被企业所采用。随着软件架构的变化，对应的软件测试策略需要作何调整呢？本文将介绍微服务架构下的测试策略，并结合分享在业务和架构演变过程中，一个历经超十年的项目测试策略的演进。 01 关于微服务微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体的业务进行构建，并且能够被独立部署到生产环境、预生产环境。 从微服务的概念可以看出它有如下好处： 每个服务可以独立开发 处理的单元粒度更细 单个服务支持独立部署和发布 更有利于业务的扩展 同时，独立开发导致技术上的分离，HTTP通信加上Queue的机制增加了问题诊断的复杂度，对系统的功能、性能和安全方面的质量保障带来了很大的挑战。另外，服务间的复杂依赖关系带来了很多的不确定性，要实现独立部署，对运维也提出了更高的要求。微服务架构的系统要特别关注这几个方面： 服务间的依赖、连通性 服务的容错、可用性 数据的最终...

本文首发于「BY林子」，转载请参考版权声明。 在经历了“七年之痒”后，蓝鲸项目进入第八个年头，项目的一切趋于稳定。团队倡导持续改进，可大家的感觉是已经尽力做到最好，这个时候似乎没有什么可以改进的了。为了突破这个局面，项目重新聚焦测试，从质量和测试的角度对现状进行了一次评估。 评估采用的是基于软件测试原则的模型，本文就是跟大家分享一下这个模型。 测试原则 2012年澳大利亚敏捷大会（Agile Australia）上ThoughtWorks的非常资深的测试实践带头人Kristan Vingrys分享了如上测试原则，这些原则是ThoughtWorks的同事们在多年软件测试经验基础上总结出来的。 1. 质量内建（Build quality in） You cannot inspect quality into the product; it is already there. – W.Edwards Deming 著名的质量管理专家戴明指出：产品质量不是检测出来的，从产品生产出来后质量就已经在那了。这同样适用于软件产品。 缺陷发现的越晚，修复的成本就越高。质量内建要求我们做好软件开...