BY林子

本文首发于「BY林子」，转载请参考版权声明。 01 离奇的数据丢失案件最近生产环境出了一起数据离奇丢失的案件，调查过程很曲折，几度进入死胡同。下面跟大家分享整个事件的来龙去脉。 1.1 数据丢失案件 8月初，用户批量导入了一批（300+）委托人数据，导入后检查过数据都没有问题。最近（10月中），处理那些委托人的时候，发现所有委托人的某几个列表（list）类型的自定义字段的值都没有了…… 用户报过来以上问题，涉及到数据丢失，是高优先级问题，客户为此特别紧张。 团队随即展开调查。 1.2 补充说明为了更好地解释这个问题，补充如下信息： 委托人的信息存在于两个系统中：从A系统导入，存入A系统的数据库，同时会有同步机制把数据同步到B系统的数据库；在B系统也可以修改这些数据，修改完会同时写入A、B两个系统。 丢失数据的“字段”（不是字段的“值”）本身是通过list类型来自定义的，也就是说不同类型的委托人可能看到的字段是不一样的；而丢失的是自定义字段对应的“值”。 1.3 案件排查过程 团队第一反应是怀疑双写和同步之间出了问题，但仔细检查后觉得没法成立。 怀疑B系统的用户操作...

本文首发于「BY林子」，转载请参考版权声明。 “好多QA转PM，因为QA（的地位）始终是要低一些” “我现在做的事情跟几年前没有区别” “资深QA在项目上做的事情新来的毕业生也能做” 上面的话你是不是也有同感？我相信大部分人会这么认为，因为这些表面上看起来的确是这样的！ 那么，软件测试人员或者说QA真的有这么惨淡吗？ 对于开篇引用的几句话，我们一一来分析一下。 01 测试工作的价值不容置疑“好多QA转PM，因为QA（的地位）始终是要低一些”说这话是没有看到QA所做工作带来的价值。相反的，我认为QA之所以可以转PM是QA工作过程中获得的锻炼挺多的，不仅可以转PM，可以转PO，技术型的QA还可以转Dev。 其实，QA和PM并没有地位高低之分，只是分工和职责不一样，QA转其他角色并不是地位的改变，可能只是更加适合自己。积极主动的做好本职工作，都能为团队带来很大价值；做的不好的话，都同样的不能带来价值。况且，做的不好的PM可能影响到整个团队，所带来的价值远不如一个优秀的测试人员带来的价值大。 团队协作才能成功 我们应该以合作的心态看待这个问题，一直强调的团队为质量负责，需要每个人都...

本文首发于「BY林子」，转载请参考版权声明。 每天的会议太多了，我都没有时间写代码了… 最近天天各种讨论，我有好多story都没测了… 在蓝鲸项目经常能够听到这样的声音。这也难怪，团队大了，总有各种会议和讨论，沟通成本上升不少。但是我们不能只是抱怨，如何提高开会的效率才是关键。 前同事李光磊写过一篇《极限会议》就是讲的怎么提高会议效率，写的非常好。但其中的原则要真正实践起来可能还是不那么容易让所有人都能快速理解并实施。 本文通过故事的方式分享日常会议的常见问题，并试图从会前、会中、会后三个阶段来列一些相对比较基础的、比较容易落地执行的规则。 会前场景一：突如其来的会议 一天早上，小青看了看时间，已经是9点半，半个小时后有个面试，这是上周HR就约好了的，他把候选人的简历拿出来看了看，想提前准备一下。 “小青，咱们几个去开个会，头脑风暴一下下周跟客户的catch up XXX的内容！” 突然听到有人叫他，小青回头一看，原来是老王。 “大概要多久？我十点有个面试呢。 ” “看进度吧，估计得一个多小时，我半个小时前给你们几个发了邀请了。” “那我肯定不行！我只有半个小时，你不提前...

本文首发于「BY林子」，转载请参考版权声明。 问：谁应该为质量负责？ 答：QA是负责测试把关，主要负责吧，DEV也要在设计和代码上对质量负责。 问：那其他角色呢？ 答：BA还好吧，跟质量的关系没那么大。 …… 在蓝鲸项目，似乎大家对质量的关注意识有些欠缺，于是在项目上的不同角色、不同工作年限的人之间采样做了一次访谈，上面这个问题就是其中访谈的问题之一。有同事曾提醒我说这种题就是送分题，肯定不会有人回答不出。可是，事实并非如此 … 为什么会这样呢？我猜想可能是大家对质量的理解不一致的缘故，在没有搞清楚什么是质量的前提下，当然也没有可能理解到底谁该为质量负责。 因此，我们来看看质量到底是什么？ 01 质量是什么 产品质量不是检测出来的，从产品生产出来后质量就已经在那了。 ——著名的质量管理专家戴明 在讲什么是质量之前，我们有必要区分两个不同的概念：测试只能检测、发现缺陷，而质量要通过缺陷预防来实现。 测试与质量不可同日而语，以后再也不要说“上线这么多问题，测试是怎么测的”这种话了。 那么，质量到底是什么？对于不同的角色、不同的利益相关者，质量有着不同的含义。总的来说，可以分...

本文首发于「BY林子」，转载请参考版权声明。 “我们公司的测试好多都转业务或开发了，还有的转管理了，测试做不长久…” “现在好多公司已经不招测试人员了，感觉测试没有什么前途…” “ThoughtWorks技术雷达上都是开发相关的内容，测试相关的内容越来越少…” 软件测试总是被看做没有技术含量、没有前途的工作，很多做软件测试的朋友也比较迷茫，表示发展受限。在这个技术飞速发展的时代，各行各业都在实行数字化转型，各种高新技术似乎离测试人员越来越遥远… 那么，测试人员真的是前途渺茫吗？本文将根据ThoughtWorks最新发布的第20期技术雷达来分析当前流行的技术给软件测试人员带来的影响是什么，有哪些机遇与挑战。 技术雷达上的内容涵盖有技术、平台、工具和语言&框架四个维度，我观察到其中跟测试人员关系比较紧密的主要有以下几个方面： 1. 支持快速、持续交付的基础设施与DevOps实践质量和速度是最关键需求，为了适应各行各业对速度的要求，配套的支持快速、持续交付的基础设施与DevOps实践是成功之必备。技术雷达上与之相关的条目有很多，比如：Terraform生态系统和四个关键...

本文首发于「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...