BY林子

本文首发于「BY林子」，转载请参考版权声明。 “没有专职的测试人员？ 代码提交就直接发布到生产环境？ 而且，一天还可以发布多次？” 对于很多团队来说，这是完全不可能的事情！他们都是怎么做到的？ 01 两个案例相信很多人都对前面这些问题很好奇，在解开谜团之前，我们先来看两个案例。 案例1 随着互联网业务业务的发展，某行业核心系统为了面对互联网的挑战，需要对系统进行改造。可是，真想改起来却寸步难行…… 该系统已经有十多年的历史，业务规则复杂，业务逻辑代码全部都在数据库脚本层；缺乏有效的业务文档，需求分析文档是以系统页面流转和操作步骤为主的形式，开发和测试人员对业务没有清晰的概念，只是知道系统有哪些操作，某个操作对应的真实业务并不清楚。 面对几百万行代码的改造，没有业务上下文的支撑，其难度可想而知。 案例2 某团队开发半年的一个网站在上线前一个多月发现根本没法正常运行，被迫延期半年后才上线…… 原来，该网站是基于一个第三方平台开发，由于业务的特殊性需要支持2TB的数据量。但是，该第三方平台并没有验证过可以支持这么大的数据量，在上线前一个多月UAT环境准备就绪，系统在UAT运行的...

近期北京疫情又开始有病例出现，为了元旦顺利出行，预约好时间、请好了假、就等着孩子放学一起去做核酸检测。但是，上午刚刚通报的最新确诊病例有两例网约车司机，看来这次疫情可能比较麻烦…我们开始纠结还要不要按原计划出行，一直纠结…直到把孩子接回家，最终决定改变计划，不做核酸检测元旦也不出行了。 在做出放弃出行决定那一刻，突然变得很平静，再也不用担心各种可能的麻烦情况。虽然白请假了，利用这个时间好好的给家人做顿美味晚餐、好好的跟家人相处也是很好的！ 回顾过去的2020年，这其实是生活的常态。正是这特殊的2020年，让我学会了以平常心面对一切不确定性。 01我的2020，从焦虑开始。 一月，因为回乡从武汉转车，虽然只是凌晨在候车室待了几十分钟，但足足让我在家焦虑了半个月，甚至头疼感冒都不敢跟家人说…每天起床第一件事情就是跟孩子学校汇报健康情况，以及查看最新疫情发展状况… 随后是考虑上班上学什么时候回京的问题，没有口罩没有消毒液怎么办？回京的高铁票改机票，又由于乡镇封城，机票进行多次改签…内心的焦虑随着疫情加剧有增无减…这是对未来不确定性的担忧。 直到二月顺利回到京城自己家中完成半个月居家隔离...

本文首发于「BY林子」，转载请参考版权声明。 我在敏捷测试系列直播课程里讲到了《测试右移》，也就是收集生产环境的数据信息，分析和利用这些信息优化软件开发和测试环节，以进一步提高质量。生产环境的数据信息中最为重要的就是日志信息，因此，收集日志信息并利用日志信息进行监控也是测试右移最重要的内容。 测试右移直播课 本文将从日志收集的必要性、日志收集方案、日志监控机制和高效日志管理实践几个方面跟大家一起探讨测试右移之日志收集与监控。 日志收集的必要性随着科技的发展，业务形态、业务类型、业务复杂度都发生了很大的变化，相应地，业务数据量和复杂度也增加了不少。为了支撑复杂的业务和大的数据量，技术架构和基础设施也在演进变化。所有这些因素，导致软件系统生态变得日益复杂和不确定。而在处于不确定状态的软件系统，传统的软件测试方法显然行不通，于是利用生产环境信息，尤其是其中的日志信息，成为了新时代软件质量保障的必要条件。 日志信息的价值那么，日志信息这么重要，它的价值到底体现在哪里呢？我认为至少有以下四个方面的价值： 1. 定位功能问题 当我们的软件系统出现bug的时候，最常用的诊断方式就是尝试重...

“林子，咱们上次讨论的高效Desk check清单，用起来还挺好的，最近我们组每次Desk check变得顺利多了，Dev也是越来越熟练。”玥玥跟我说。 “真好！我们组感觉也是这样！” “不过，我听小慧说他们组有人对QA review UT提出了一些concern（质疑），觉得QA review的价值不大，基本都是Dev给讲一遍，QA也提不出来什么反馈…”玥玥补充说道。 “哦！那你们组感觉review的怎么样？”我问玥玥。 “我们组感觉还挺好的，可能是因为我已经review很长时间了，对Dev写的测试也比较了解了，每次过一遍不会太费劲，也能发现一些问题。” “嗯，QA review测试肯定是有价值的，但是能否体现出价值，取决于是否做的好，这不仅对QA有要求，对Dev也是有要求的。” 关于底层测试及其评审看到前面的对话，可能有朋友会问什么是底层测试，以及底层测试又是如何评审的。因此，我先来介绍这两个内容。 底层测试测试分层理论根据测试所覆盖范围的大小，将测试分成不同的层：端到端功能测试、API集成测试、单元测试等，常见的测试分层实例有测试金字塔。 位于金字塔下面的API测试...

“先来更新一下各个team近一周发生的事情吧。”又到了每周的QA catch up时间，今天是轮到玥玥主持会议。 “我先说吧，我们这一周刚完成一件大事！”我忍不住抢先说。 “什么大事？”大家都很好奇。 “就是上次说过的新增一种工单类型的feature，昨天刚刚完成了story的desk check（用户故事验收）。” “听说那个影响到了整个企业系统？” “差不多吧。desk check就做了两个小时。”我说。 “是看到你们做了好久！上次我们有个story做了快一个小时，我都快要崩溃了！你们竟然更久……”小慧之前就给我们说过她那次痛苦的Desk Check经历。 “我们这次时间虽久，但是感觉做的挺好的，已经很高效了。时间长是因为实在是太复杂了。这次Dev很给力，准备工作做的很好，整个desk check过程也很有条理，非常顺畅。”我解释道。 “这种情况可能比较少见。正好今天没有特别的分享话题，咱们先更新完各个组的情况，林子你再给我们详细分享一下昨天的Desk check，咱们还可以可以讨论一下如何能让Desk check做的更好。”玥玥说。 “这个主意不错！”大家都表示同意。于...

本文首发于「BY林子」，转载请参考版权声明。 这一份软件质量保障实践合集是我们团队所采用的实践，全部来源于真实项目经历，将它们整合浓缩到了几页PPT里边，并且对每个部分有详细的解释。 浓缩的都是精华，这篇合集将带给你更全面的视角去理解软件质量保障，帮助你更好的在软件测试职业发展道路上拓宽视野，值得拥有！ 01. 一页纸测试策略 “会当凌绝顶，一览众山小”，只有站的高，才能看的远。要采取合适的测试实践来做好质量保障，对全面的测试策略的掌握是必不可少的。只有掌握了测试策略技能，才能跳出具体的实践细节，从更系统的角度去思考。 测试策略文档通常是篇幅较长、文字为主的形式，编写成本较高，并且写完了很少有人去看，形存实亡。一页纸测试策略以可视化的方式，将测试策略用图来表达，并且在一页纸上搞定，这样的策略图非常清晰，关键信息一目了然，并且提供更大的讨论空间，防止僵化，真正能够发挥策略的作用。 一页纸测试策略图包括三个部分： 指导性原则：团队为质量负责。这是起码的要求，团队是一个整体，要求每个成员要一起为所交付软件的质量负责。 测什么，通常有功能、性能、安全等。这是测试策略非常关键的部分，只...

写在前面 测试金字塔曾经神一样的存在，很多人认为制定测试策略知道测试金字塔就够了。 真的是这样吗？今天，利用这篇短文跟大家聊聊测试金字塔。 如果你恰好知道测试金字塔，也把它奉为测试策略的指导方针，那么这篇文章正好适合你。 如果你还不了解测试金字塔，但是很关注质量和测试，那么不管你是什么角色，这篇文章也适合你。 Most people know about the the Test Pyramid due to Mike Cohn, when he described it in his 2009 book Succeeding with Agile. In the book he refers to it as the “Test Automation Pyramid”, but in use it\‘s generally referred to as just the “test pyramid”. He originally drew it in conversation with Lisa Crispin in 2003-4 and described it at a...

本文首发于个人网站「BY林子」，转载请参考版权声明。 艾森.拉塞尔在《麦肯锡方法》一书中两次提到著名的“蘑菇种植法”：在黑暗的环境下，不断地施肥，然后看看出现了什么。他强调信息需要在团队内流动起来，以提高团队士气，而蘑菇法是阻止这样做的反例。 在团队里，尤其是规模较大的团队，有意无意的蘑菇法总是会出现，下面一起看几个案例。 案例1：未知的高优先级 “张哥，咱们的技术改进这周可以实施了吧？” “啊？老王给了我优先级更高的事情在做，你们那个先不做了，没人跟你说吗？” “什么？为什么优先级变动没有人提前告诉我？！”小李不能理解，非常沮丧。 某资深员工小李，正在推动一个技术改进。这个技术改进从开始提出，就有不同的反对声音，他一个个解释澄清，获得了大家的认可，PM老王也是点头同意了的。小李组织几个同事把该准备的内容都按部就班的准备起来了，等到最后时刻去找Ops同事张哥实施的时候，才知道自己一直在推动的事情被默默的停掉了。 此事让小李感觉非常不爽，从此他对项目上的事情不再那么热情。 有更高优先级这件事情是可以理解的，项目团队的优先级列表一定是不断变化的，而项目的优先级变动有必要分享给团...

本文首发于个人网站「BY林子」，转载请参考版权声明。 你们的测试开发比是多少？测试全阶段参与，怎么可能忙的过来？ 全阶段都在测，那么都需要哪些测试才能保证质量呢？ 自动化测试覆盖率要求达到99%，包括功能、性能，甚至还有易用性…… 前面的第一个和第二个问题经常被人问到，是大家比较关心的问题，而第三个是某项目的真实要求。分别是关于测试人员如何测试、测试活动如何开展、测试覆盖率该是多少的问题，都跟接下来要讲的精益测试有关。 01. 精益生产在介绍精益测试之前，我们先了解精益生产的概念。 精益生产从维基百科可以看到对于“精益生产”的解释：精益生产主要来源于丰田生产方式(TPS)的生产哲学，因此也称为丰田主义 (Toyotism)，一直到1990年间才称为精益生产。精益生产的目标是控制库存量，减少生产过程中的浪费，其核心是“Just in time”，旨在需要的时候，按需要的量，生产所需的产品，也就是用最少工作，创造价值。 02. 精益测试敏捷测试要求的测试左移、全程测试，其目的也是为了快速反馈、降低成本，以交付高质量的软件。如果把精益的概念引入敏捷测试，将有助于减少测试过程中的...

本文首发于「BY林子」，转载请参考版权声明。 【中文版Chinese Version】NOTE： The English version of Agile Testing Manifesto can be found after this Chinese version. 根据多年在Thoughtworks敏捷团队的敏捷测试相关经验，我们几位资深QA同事一起讨论出敏捷测试宣言和原则，本文与大家详细解读。 敏捷测试宣言 解读敏捷测试宣言表达的是我们对于敏捷测试的信仰和价值观，分别包括流程、团队合作、自动化和核心价值观四个维度。 在以往软件发布周期较长、需求变化频率较低、不同角色间的合作壁垒较高的环境下，传统的开发模式所采用的孤立的测试阶段、测试人员独立把关质量、回归式的全量自动化测试和质量检测，是有其价值的。但是，在敏捷开发模式下，敏捷测试则更强调左侧的价值观。 全程的测试介入敏捷测试提倡测试左移和右移，从软件生命周期的早期（左侧）一直到产品发布上线后的生产环境，都需要有测试的介入和测试活动的开展。 左移是为了更好的理解和澄清需求，以减少需求理解不一致导致的浪费；而右移是充分利用...