IDEAL Garden

引子先来玩个视觉小游戏，请在下图中找到隐藏的五角星。没找到的朋友，答案在文末。请看完答案再回到这里。现在我们回看上图，是不是很容易就找到五角星，甚至第一眼就看到它了？知识诅咒“有些事知道了，就再也回不去了。”知识诅咒，指的就是一旦我们自己知道某样东西，就会发现我们很难想象不知道它的时候会是什么样子。 我们的知识“诅咒”了我们。 对于我们自己来说，同别人分享我们的知识变得很困难，因为我们不易重造听众的心境。那这件事和测试有什么关系呢？我们看一个典型的测试用例是什么样的：按照用例执行，假设执

测试用例存在一些真相与事实，有些广为人知，有些却很隐蔽。正是基于这些真相与事实，可以对我们的手工测试、自动化测试、甚至规模化的自动化测试（数以万计的用例）带来不同的启发。真相1：不能提前确定所需要的所有测试用例测试领域有一个几乎是共识的结论，我们不能完全测试（Complete Test）。除了这个结论本身，其原因也有很大的参考价值：软件系统本质也是一系统，是由一层层依赖组成的，当我们想测某一点时，总会有假设，但是这个假设本身有时也需要另外的用例来覆盖。而哪一层的假设是可靠、不需要再测试的判断往往是凭

泡水膨胀球（图片来自网络）这是一种小玩具，干燥时拿在手里，小巧紧致。泡在水里一段时间之后，浑圆饱满，一只手都未必能捧的住。放在干燥通风的地方晾晒，一段时间过后，又可以恢复原本的大小。软件需求软件需求与泡水膨胀球也有类似之处。一开始时看似简单明了且完备正交，后来发现越做越大，越做越多。原本一只手能抓好几个的小球，后来变成两只手都抓不住一个。然后的结果要么是超预算多花钱做完，要么是转嫁成本给乙方要求对方做完，要么是延期，要么是痛苦地去压缩需求。无论哪种，都是不健康的。膨胀系数小球泡在水

虽然SOLID原则不能时刻有效指导编码落地，理解这些原则背后的设计理念，让你迈出了第一步，接下来，你需要做的是在前进的路上，不断地进行编码实践、思考总结，将其内化。做了这么多年的面向对象编程还是写出违背SOLID原则的代码，一看都懂、一做就被怼，敏感度不够，如何是好？难道SOLID原则本身就有错？难道我不应该涉水OOD？……请先屏住呼吸，我们来看看SOLID叫什么：Single Responsibility Principle，单一职责原则Open Close Principle，开.

除了感性的工作体验外，我们还需要指标来度量改进措施是否对提升软件交付效能有帮助。过多的指标会对团队造成不必要的管理成本，也容易让团队失去关注焦点。从吞吐量和稳定性两个维度考量的四个关键指标是简单但有效的指标，建议优先度量。为了提升软件交付效能，你的团队或组织可能已经开始采取行动，引入敏捷方法、DevOps实践甚至还有架构重构。但你如何知道这些改进措施起了作用呢，或者它们压根就水土不服呢？简单来说，除了感性的工作体验外，你需要一些指标来度量交付效能。唯快不破提升交付效能的最重要的目标之一就是能"快.

Bug Report一般有两种说法：一是“微观Bug Report”，是指深入分析单个bug产生的影响、产生的根因、后续如何避免等；二是“宏观Bug Report”，是指在一个项目开发周期中，对bug原因、修复周期、bug趋势等维度进行总结分析。说起Bug Report，QA同学都不陌生。本文我们主要聊一聊Bug Report该怎么做。Bug Report一般有两种说法：一是“微观Bug Report”，是指深入分析单个bug产生的影响、产生的根因、后续如何避免等；二是“宏观Bug Report”，.

在证书验证、基于JWT(Json Web Token)的身份认证、IDP(身份提供商)、SP(服务提供商)等技术中，都有一个可信的第三方，可明明是用户对资源或者服务的访问，为啥还要个第三方？这篇文章整理了一些相关技术的案例，并尝试分析其这样设计的原因。经典案例01 证书 —— 整个互联网中的信任传递目的： 解决两个节点之间的安全通信，常用的是用户访问某个具体的网站背景：基于现有的网络协议（如http），在其基础上对信道进行加密，保证安全。这就需要两个节点之间至少持有一个对方的公钥( 用这个秘.

敏捷交付价值，敏捷测试要以业务价值驱动，要以优化业务价值为目标。业务价值可以简单理解为：帮助企业盈利，满足企业业务发展要求，能够带来业务价值的产品需要满足用户需求、让用户使用方便。我们知道，敏捷交付价值，敏捷测试要以业务价值驱动，要以优化业务价值为目标。“TA主要关注系统的操作上，对业务价值关注太少。”“要多关注业务价值，多从业务价值的角度去思考。”这是我们最常见的给敏捷QA的反馈和建议。可是，业务价值到底是什么？业务价值可以简单理解为：帮助企业盈利满足企业业务发展要求能够带.

在一次敏捷课程上，有一些大量有意思的问题，例如 “通过敏捷会让项目开发进度更快吗？”。其中一些也是几年前我想问的，并带着这些问题加入 ThoughtWorks。终于经过各种海内外敏捷项目，在一线开发有了对敏捷更为深刻的认识，现在回过头来聊一聊这些问题。为什么要敏捷？敏捷作为一种软件开发方法，或者项目管理方法，很容易被说的玄乎。软件开发一定要敏捷才行吗？实际上很多项目是可以不采用敏捷开发方法的。在很多年前的电信、银行领域，银行的软件主要是给行内内部使用的。那个时候的软件开发采用瀑布模型，把软件开发过程划

在一次敏捷课程上，有一些大量有意思的问题，例如 “通过敏捷会让项目开发进度更快吗？”。其中一些也是几年前我想问的，并带着这些问题加入 ThoughtWorks。终于经过各种海内外敏捷项目，在一线开发有了对敏捷更为深刻的认识，现在回过头来聊一聊这些问题。为什么要敏捷？敏捷作为一种软件开发方法，或者项目管理方法，很容易被说的玄乎。软件开发一定要敏捷才行吗？实际上很多项目是可以不采用敏捷开发方法的。在很多年前的电信、银行领域，银行的软件主要是给行内内部使用的。那个时候的软件开发采用瀑布模型，把软件开发过程划

摘要：技术是由一万个细节组成的，哪怕一个这么简单的题目，也有如此多的点。我也不敢说自己是什么高手，起码写了许多年代码，也就把自己写代码的思维展示给大家，希望对有心人有所帮助。非初学者向，虽然题是个简单的题，但要求读者有一定的敏捷工程实践及DDD相关经验。FizzBuzz是一个经典的TDD入门题目，麻雀虽小，五脏……勉强算全吧。Stack Overflow创始人曾经在他的一本书里写到，“不要假设程序员都会写程序，招一个程序员来先写个FizzBuzz看看，结果可能会令你吃惊。”我当时不信，于是在一个.

摘要：Cypress和TestCafe这两个工具相比于Selenium都更加的轻量级，且在不同的方面有了改进，比如安装更简单，增加了内置等待机制，调试更加方便等。Cypress、TestCafe、Puppeteer在技术雷达中被誉为后Selenium时代Web UI测试的三驾马车。一、初步印象谈起Web UI自动化测试，首先想到的肯定是Selenium了，毕竟Selenium是名噪一时的Web UI自动化测试工具。在一次QA Community的Catch Up上，大家聊起了最近火起来的Cypre.

我摊牌了，其实我是一名黑客，这是我的自白书。我将坦白当我准备入侵一个目标时，我是如何收集信息并入侵的。最重要的是，我会给你们一些有用的忠告。我是如何收集信息的当我有了一个目标，我就需要开始对目标进行信息收集。信息收集阶段很重要，因为目标一般对我来说都是黑盒子，我需要进行大量的信息收集才能知道这个系统的运行原理，以及哪里有漏洞可以利用。收集信息一般分为以下几种类别，咳咳，划重点了，必考的，...

我们很熟悉以REST实现的API，可以用任何能够发出http 请求的库或者工具来测试REST API。去年随着GraphQL在全球风靡，它也出现在了最近两期的ThoughtWorks技术雷达中，当我们面对新的GraphQL APi时，QA应如何应对？ 知彼知己，方能百战百胜，下面让我们首先来看看什么是GraphQL，它和传统的REST API又有什么不同？什么是GraphQL ？Graph ...

精益敏捷转型听起来很容易，但做起来很难，很多组织在数字化转型的过程的早期，一到两个团队作为试点团队进行敏捷转型，都能获得不错的转型效果。随着转型的持续推进，涉及到越来越多的团队转型，这时就会暴露出早期没有发现的一些问题。我们经常说量变引起质变，如何保证组织转型过程中，大团队从传统的瀑布式开发转变到精益敏捷模式的开发呢？今天我们不谈理论，不谈框架（SAFe，LeSS），我想从一个实操的方面来剖析一些...

ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代，为了让外界理解ThoughtWorks全球团队怎么做敏捷，我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发既不是Scrum，也不是XP。造成这个状态的原因，一方面是行业特点 —— 软件开发还是一个充满不确定性的手工业，方法套路当然不可避免因人而异；...

敏捷从2001年被首次提出到现在已经历经了17个年头，作为一种新的思潮和软件开发方法早已跨越了鸿沟（如图1所示），并团结了大部分实用主义者，陆续掀起了不可逆的全行业敏捷精益转型。如果你的公司或者组织正在进行或者已经经历了敏捷转型，那么作为组织变革者的你，一定在转型初期，组建了类似于“变革委员会”（或者“敏捷工作组”、“敏捷小组”、“变革小组”、“敏捷组委会”等）的团队。而在这个行业中应运而生的关...

你或许从不同渠道看到过来自“ThoughtWorks洞见”的内容，主题横跨ThoughtWorks的业务能力、技术专业能力、文化、职业。自第一篇文章发出至今，已有五年时间，累计641篇文章，不能说这是一个多么大的成绩，但我们在背后的坚持，乃至产生的持续影响，还是会让我自己觉得意外，毕竟我们是一家技术厂商，而不是媒体。

在ThoughWorks有一句流传甚广的话 —— “在ThoughtWorks需要有拥抱随时变化的心态“，因为我们践行敏捷、我们有各种各样的客户，而商机稍纵即逝。作为普通的dev，最明显的感受是不会像其他互联网公司一样长期待在一个固定的项目，有足够的时间了解项目的上下文和背景。我们的项目周期足够短，甚至有时候几周都算很正常，项目的频繁切换对dev的要求就是需要快速了解一个新的项目。这是我在Tho...

团队大了，总有各种会议和讨论，沟通成本上升不少。但是我们不能只是抱怨，如何提高开会的效率才是关键。

7991 年，随着极限编程（Extreme programming）方法论的提出，持续集成（Continuous integration）也随之成为一项标准化的敏捷实践，被逐步应用于各类软件的开发流程中。9102 年的今天，持续集成的概念已经在软件开发领域生根发芽，广泛应用于不同平台及设备的项目开发，极大提升了项目迭代速度，降低了维护成本。不过，作为“敏捷”的固有属性，持续集成也并不仅限于特定...

几年之前我还是个野生程序员的时候，对“敏捷”这个词是有些抗拒的。那时候，要么是没有想法、懒得去理会，要么就是主观上拒绝： 肯定又是些无所事事的人弄出来的无聊概念，帮他们自己刷存在感的东西！ 敏捷，就是那些咨询公司弄出来给别人洗脑的嘛，那些理念太空，根本无法落地！ 那些一大堆概念都是些什么鬼？条条框框太多了，运作起来太麻烦了！ 不用敏捷，我们现在不也挺好的吗？敏...