IDEAL Garden

冗杂繁复的数据初始化代码会影响单元测试本身的代码质量，造成单元测试编写成本高、易读性差、易维护性低等问题。

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

###软件质量是什么？业界通常将软件质量定义为如下两部分：Functional Quality - How well software complies with or conforms to customer specifications.Structural Quality - How software meets non-functional requirements that support the delivery of the functional requirements, such a

摘要：本文总结几类项目中跟时区相关的问题，给大家分享一些基本的时区知识，以及如何在软件开发和测试中注意考虑时区因素，以避免因时区而导致系统功能的问题。场景一“小D，我发现调整不同的timezone（时区），咱们的KPI计算结果可能会有一天的误差…”“啊！我看看什么原因。”“嗯啦，KPI务必是准确的，可不能有误差…”“小Q，我知道啦！咱们的工单任务完成时间记录的是UTC时间，是考虑了timezone转换的，但是缺失信息的记录并没有考虑… ”“为什么缺失信息不记录UTC时间呢？”“因为缺失信息只

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

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

QA设计的测试用例大部分都是面向业务的端到端测试，怎么能保证从DB来的数据通过层层service能顺利的到达前端并被正确的展示出来呢？我们可以尝试以UI和DB作为data flow的两端串起所有的测试。场景想象一个典型的场景，一次sign off接近尾声：QA：这个些case都有测试吗？DEV：打开各种IDE，UT cover了case A，JT cover了case B，API test cover了case CSign off结束了，但是代码里的测试真的覆盖了QA预期的全部用例吗？假.

既然无法完全阻止缺陷的出现，那如何确保已发生的缺陷得到有效的处理，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的，也就是缺陷管理的内容。敏捷测试原则中有一条是：预防缺陷，而不是关注缺陷的数量。在敏捷开发中，虽然我们采取了各种措施预防缺陷的发生，例如精准的自动化测试、代码检视、故事卡验收等等，但是并不能保证没有缺陷发生，一个零缺陷的产品也不现实。既然无法完全阻止缺陷的出现，那如何确保已发生的缺陷得到有效的处理，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的，也就是缺陷管理的内容。本文以某实际.

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

机器学习平台是一款集数据集、特征工程、模型训练、评估、预测、发布于一体的全流程开发和部署的工作平台。其数据量大、数据多样性、支持算法种类多，加上算法模型结果不确定、集成复杂等等特点；这会给QA的工作带来怎样挑战、以及如何克服，本文一一揭晓。在谈测试机器学习平台带给QA的挑战之前，先了解一下机器学习平台是什么？机器学习平台是一款集数据集、特征工程、模型训练、评估、预测、发布于一体的全流程开发和部署的工作平台，为数据科学家提供端到端的一站式的服务，帮助他们脱离繁琐的工程化开发，从而帮助他们提高工作效率。.

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

BDD是什么BDD，Behavior Driven Development，行为驱动开发。如果你不是很了解BDD，可以参考我四年前的一篇文章说起BDD，你会想到什么，其中介绍过BDD的理论和应用。我们可以这样来概括BDD：BDD采用统一的领域特定语言（DSL）来描述业务场景和用户行为，让团队各个不同角色对业务需求有一致认识，从而做到更有效的沟通和更高效的协作；BDD的目的不是自动化测试，但是BDD可以有效指导自动化测试，基于BDD的自动化测试相当于维护了一份需求活文档，对项目需求的维护和管理非常

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

我们来一起看一下两个程序员之间的故事。以下示例代码是用Scala写的，不过本文所讲的话题并不仅限于Scala，任何有Future/Promise支持的语言都是适用的。下面这个wiki页面罗列了各个有Future/Promise支持的语言，已经涵盖了大多数的常用语言。Future与promise实现列表我是异步函数的编写者我写了两个异步函数,来提供给其他程序员同事使用。type Call...

起因我的同事肖然在 《ThoughtWorks的敏捷开发》一文中介绍了ThoughtWorks敏捷开发的全貌，并在其中简单介绍了ThoughtWorks是怎么做质量内建和敏捷测试的。我作为一名加入ThoughtWorks已经7年的QA，想更为详细的介绍一下这些内容，希望能帮助业界中仍对于敏捷测试有疑虑和困惑的团队建立起自己的敏捷测试体系和实践，从而帮助团队更好的实施敏捷软件开发。在目前的软件开...

最近十到二十年，软件业迎来了一个超高速发展期，其中软件测试相对于软件开发进展稍微缓慢一点，不过也出现了不少新的思想、技术以及趋势。基于现阶段在客户现场、业界大会、与专家的讨论以及从网上看到的相关内容，我尝试在本篇文章中总结出几个测试新趋势：AI+测试利用AI（深度学习等）系统来辅助测试工作绝对是最近几年最为热门的一个测试趋势，其中包括测试用例，测试数据和测试代码的自动生成、大规模测试结果分析、...

单元测试是现代软件开发最基本，也普遍落地不力的实践。市面关于React单元测试的文章，普遍停留在“可以如何写”和介绍工具的层面，既未回答“为何必须做单元测试”，也未回答“单元测试的最佳实践”两个关键问题。本文正是要对这两个问题作出回答。本文所用技术栈为前端React栈，测试框架与断言工具是jest。文章将略过对测试框架本身的语法介绍，着眼于“为何做”与“最佳实践”的部分。阅读第二部分的代码，需...

“我们公司的测试好多都转业务或开发了，还有的转管理了，测试做不长久…”“现在好多公司已经不招测试人员了，感觉测试没有什么前途…”“ThoughtWorks技术雷达上都是开发相关的内容，测试相关的内容越来越少…”软件测试总是被看做没有技术含量、没有前途的工作，很多做软件测试的朋友也比较迷茫，表示发展受限。在这个技术飞速发展的时代，各行各业都在实行数字化转型，各种高新技术似乎离测试人员越来越...

在经历了“七年之痒”后，蓝鲸项目进入第八个年头，项目的一切趋于稳定。团队倡导持续改进，这时大家的感觉是已经尽力做到最好，似乎没有什么可以改进的了。为了突破这个局面，项目重新聚焦测试，从质量和测试的角度对现状进行了一次评估。评估采用的是基于软件测试原则的模型，本文就是跟大家分享一下这个模型。测试原则在2012年澳大利亚敏捷大会（Agile Australia）上，ThoughtW...

性能测试对于大部分测试人员都是一个神秘地带，因为在很多公司，性能测试都是由一个性能测试团队来做，所以普通测试人员没有机会接触到真实的性能测试，因而很难学习到很多新的测试实践知识。市面上现在有非常多关于性能测试的书籍，其中不少书籍都能够系统地介绍性能测试。今天我想通过另一种方式来介绍性能测试，那就是通过提出一些关于性能测试的问题，然后针对问题进行思考。希望通过不一样的方式让读者以另外一种视角来思...

什么是契约如果从契约产生的阶段来说，现有资料表明最早要追溯到西周时期的《周恭王三年裘卫典田契》，将契约文字刻写在器皿上，就是为了使契文中规定的内容得到多方承认、信守，“万年永宝用”。所以订立契约的本身，就是为了要信守，就是对诚信关系的一种确立。诚信，是我国所固有的一种优良传统，也是延续了几千年的一种民族美德，在中国儒家的思想体系里，是伦理道德内容中的一部分。《现藏于台北故宫博物院》...

背景移动技术发展到现阶段，原生、混合式技术发展的足够成熟，可以无缝融合。而随着移动技术的发展和革新，移动领域的测试技术和实践也有了一定发展：工具不再像早期一样几家独大，选择性越来越多；从浅尝辄止的实验阶段到真实项目中的自动化测试落地。这些实践在一定程度上提升了测试反馈效率，在迭代交付的过程中出色的完成了质量保证的工作，但在相对漫长的实践过程中，我们依然可以总结一些痛点：1、移动自动化测...

数字经济高速推动着一个无情的市场，所有利益相关者通过设备和应用网络进行交互，一个微观时刻足以让市场领导者摆脱优雅。 这种对速度的痴迷能否淡化质量定性方法？《World Quality Report 2017-1028》带你来一探究竟。现代QA和测试部门重点关注的领域敏捷和DevOps已经成为数字化转型的重要工具，同时，质量保障和测试工作也随之发生变化：中央治理和控制减少，团队...

在过去的几个月，我做了一些实践，通过整理、讨论和分析项目上的Defects情况，来探索质量管理中的待改进点。最终发现，Defects实际上给质量管理带来了很多的启示。当然，要讨论Defects，首先要使团队对Defects有一致的理解。我查了很多资料，也没有找到对”Defects”一词的明确定义，大部分人将”Defects”等同于“Bug”。1947年9月9日，Grace Hopper发现了...

“测试金字塔”是一个比喻，它告诉我们要把软件测试按照不同粒度来分组。它也告诉我们每个组应该有多少测试。虽然测试金字塔的概念已经存在了一段时间，但一些团队仍然很难正确将它投入实践。本文重新审视“测试金字塔”最初的概念，并展示如何将其付诸实践。本文将告诉你应该在金字塔的不同层次上寻找何种类型的测试，如何实现这些测试。2018 年 2 月 26 日作者：Ham VockeHam 是德国 Thou...

最近几年，微服务架构越来越火爆，逐渐被企业所采用。随着软件架构的变化，对应的软件测试策略需要作何调整呢？本文将介绍微服务架构下的测试策略，并结合分享在业务和架构演变过程中，一个历经九年的项目测试策略的演进。关于微服务微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级通信机制互相沟通（通常是基于HTTP协议的RESTful API）。...

随着持续集成，持续交付等理念的传播，很多软件开发团队都搭建了自己的staging、UAT等类生产环境。这些环境的软硬件及网络配置会尽量贴近真实的生产环境，起到沙盘演练的作用。类生产环境毕竟前面还有一个类字，沙盘毕竟不是真实的战场，尽量贴近毕竟还不是完全吻合。类生产环境与真实生产环境的一个重要差异就是访问量。稍具规模的互联网应用每天几百万访问量是很正常的，而类生产环境的访问量一般都会相形见绌。...

引子传统的软件测试大多是在测试环境下进行的。人们普遍认为生产环境是服务于最终用户的，只有在测试环境下进行充分测试后才会发布给用户。基于非生产环境的测试-单元测试、集成测试、功能测试等，很多都是基于预期结果的测试，测试人员一般是带着这样的思路来工作 “如果这样做会发生什么呢” -属于known-unknowns。而生产环境往往充满了惊喜-属于unknown-unknowns。我们不知道最终用户怎...

调查分析生产环境缺陷，到最后定位是数据问题的时候，总是让人浑身轻松... 于是，“脏数据”就跟测试的“随机挂”一样，成为了光荣的“背锅侠”！脏数据 ≠ 代码问题，真的是这样吗？先来深入了解一下脏数据。

C4不能帮你做好架构设计，但是它能暴露出你设计中的问题，以便于被自己或其他人纠正。可视化的威力就在这里，但根据我的经验，即便你用上了C4也不见得就能表达清楚，不过好消息是，我们终于可以聊一些高级的表达问题了。

一个短信登录API背后，还能牵扯出这么多事儿。

在2017年第17期和2018年19期技术雷达中，分别出现了两个新的工具——cypress,testcafe，之前只接触过webdriver框架的同学可能会有些陌生。而cypress已经在最新一期的技术雷达中进入了评估阶段，并在多个项目得到了应用，总体反馈利大于弊。先来详细的介绍下cypress以及我所在项目使用中踩过的坑，关于testcafe会在另外一篇文章中介绍,testcafe主要是用来做...

嗯，如何才算的上一份好的测试计划？纵然教科书上讲的天花乱坠，专家理论的头头是道， 面对自己的项目时仍然是难以下手，结果很自然的会拿着一个自以为最全面的模板去硬套。生硬晦涩，最后束之高阁还算是小事，要是拿着它去引领下面的工作，就不知道会发生什么了。测试计划如同一份普通的计划一样，只不过是针对软件测试这个特殊的过程，做了特别的定制。确立测试目标，搞清楚测试范围，分别指定测试策略