BY林子

本文首发于「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 著名的质量管理专家戴明指出：产品质量不是检测出来的，从产品生产出来后质量就已经在那了。这同样适用于软件产品。 缺陷发现的越晚，修复的成本就越高。质量内建要求我们做好软件开...

本文首发于「BY林子」，转载请参考版权声明。 物联网的出现，给测试带来了很多有意思的挑战，使得众多QA开始重新思考传统的测试过程。 例如，我最近测试了一个产品，在这个产品中的移动APP会跟连接的机器产生会话。这两个设备各种各样的状态给测试场景的设计带来了特别大的挑战。下面给大家介绍一个很有用的物联网产品测试框架——物联网测试地图，它可以帮助我们管理物联网设备多种排列的复杂状态。 01 物联网测试因素当我们测试简单的web应用时，通常要考虑的状态有： 服务器宕机 HTTP请求超时 网速慢 授权和认证错误 测试任何互联网应用的时候，需要警惕这四种状态。对于移动应用，操作的是移动环境，需要关注额外的几种情况： 离线模式 在线模式 杀掉Activity 后台行为 语言 地理位置 我们再看“连接的机器”所带来的状态多样性，通常还有： 机器WiFi断开 机器WiFi连接 机器繁忙 机器休眠 这意味着即使只有上述给定的状态集，整个系统在任何时间点上可能会有96（4x6x4）种状态。 由于系统中状态转换会引入附加的约束，这些状态都不能当做独立的实体。例如，状态从“离线”变成“在线”...

本文首发于「BY林子」，转载请参考版权声明。 01 食之无味，弃之可惜在企业级应用的季度或月度发布被认为是领域最佳实践的时候，应用部署到生产环境之前维护一个完整的环境进行集成测试是非常必要的。但是，集成测试环境和集成测试本身有着如下的问题： 环境本身脆弱，而且通常存在手动配置部分，环境维护成本很高； 环境因素导致集成测试不稳定、不可靠、反馈慢，测试失败不易定位问题，同时还会重复测试隔离组件已经测过的功能。 集成测试成为了持续交付的瓶颈，犹如鸡肋。因此，最新一期（2017年第16期）ThoughtWorks技术雷达建议企业暂缓搭建企业级集成测试环境，而是采用增量的方式发布关键组件到生产环境。增量发布涉及到一些重要的技术包括契约测试、将发布与部署解耦、专注于平均恢复时间和生产环境下的QA 。 02 断舍离之技术可行性下面分别介绍技术雷达建议的这四项技术，以及在没有集成测试的情况下如何保证应用的质量、如何帮助企业做到独立增量发布。 1. 消费端驱动的契约测试消费端驱动的契约测试是微服务测试的重要组成部分，主要用来覆盖两两服务之间的契约关系，下面举个例子来说明什么是契约测试以及契...

本文首发于「BY林子」，转载请参考版权声明。 “看，车来了！不过这趟车貌似咱赶不上了吧？！” “啊！那快点跑，错过这趟就得再等半个小时！” …… 好无奈，可是真的赶不上也没有办法，这个场景很多人都经历过。 “这个release又是一定包就开始上hotfix，四天跟了四个，我根本没时间做回归测试！” QA小静同学抱怨道。 “每次都是定包后就开始无休止的上hotfix，咱们还不如改成每周发布一次！”Dev大鹏同学也被hotfix折磨苦了。 这是发生在蓝鲸项目的一次真实而平常的对话，跟前面赶公交车的场景有什么关系呢？ 01 发车间隔与发布周期1. 发车间隔的不同带给乘客的感受会完全不同有些公交车很少，每半个小时一趟，有时候眼看着一辆车来了又走了，没赶上的心情无比懊恼，下一趟还得等上半个小时啊！实在着急的可能考虑叫一辆快车赶紧走… 而有些公交车发车间隔非常短，几分钟一趟，就算错过一趟也无需等待太久，只要不是着急去救火的乘客一般都不会太在乎。 2. 项目的不同发布周期带给客户的感受也是类似的蓝鲸项目的发布周期跟第一种公交车发车间隔非常类似，是四周发布一次，如果这次没能上线的功...

本文首发于「BY林子」，转载请参考版权声明。 “你们团队QA和DEV的人员比例是多少？” “我们团队一般有1个QA和3~4对DEV pair.” 经常会被问到这样的问题，一般的小团队都是这样的人员比例，QA也不会觉得压力有多大。当多个特性团队工作在同一个代码库、分别在开发同一个系统的不同功能的时候，虽然每个特性团队也保持前面所述的比例，对于QA的挑战却要大得多，那是因为： QA不仅要了解自己特性团队的需求，还需要了解其他团队的需求，因为这些功能都在同一个系统上，联系必然是很紧密的； 某个团队发现的软件缺陷的根源、错误日志信息，在其他团队也可能发生，这些信息需要共享； 某个特性团队有任何基础设施、测试环境配置文件的变化都得让所有团队知晓，而QA是其中沟通这个内容最恰当的角色； …… 由此可见，大规模团队的QA不像小团队那么简单，沟通的成本要高很多。如果没有及时沟通，将会造成信息不对称，要补救所花费的额外精力是比较大的。当然，大规模团队不仅QA的沟通成本增加，其他角色也一样，只是因为我是QA嘛，就跟大家聊聊我们QA是如何应对这种大规模团队的挑战的。 01 集体参加story...

本文首发于「BY林子」，转载请参考版权声明。 你有没有过下面的经历： 在谷歌浏览器输入一个网址，出来一个错误提示：“不支持当前浏览器，请用IE访问”… 换成IE，重新打开该网站，输入用户信息注册一个新用户，随后收到一封注册成功邮件，里边直接包含刚刚注册的密码… 用注册的用户名密码登录进去，又不知道所需要的功能入口在哪里… 翻遍了一层又一层的菜单，终于找到了入口，进去打开的是一个列表，足足等了2分钟才加载完成… 从列表中找到自己需要的那个信息，点击“查看详情”，却显示一堆乱码… 一次性碰到上面的各种当然属于极端现象，但我敢说，你一定碰到过其中的问题不止一次，而且碰到了一定很郁闷。这些都是软件缺陷，分别是兼容性、安全性、易用性、性能和功能方面的缺陷，一旦出现将会给企业和用户带来不同严重程度的影响。 这种糟糕的体验有没有使你产生想去优化的冲动？你是否想知道如何帮助软件开发团队开发出缺陷更少的软件产品？如果你的回答是肯定的，那么请跟我一起来做QA吧：） 01 QA是什么？狭义的理解就是软件测试，软件测试工程师常被称为QA；广义上，QA就是在软件开发过程中做好软件质量分析和保证的人...