历史与简介早在 1984 年，Cem Kaner 就提出了探索式测试（Exploratory Testing），并首次定义它是“一种测试风格，主要是强调个人的自由与责任，让独立的测试人员可以持续的并行的通过相关的学习，测试设计，测试执行等活动来改善测试工作的质量”。然后到了上个世纪 90 年代，Cem Kaner 又在他的书《Testing Computer Software》中第一次正式发布了探索式测试这个方法论，从此它正式进入测试领域，并且引起了业界的关注，很多测试人员也开始实践这种测试方法。从 Cem Kaner 给出的这个定义可以看出，探索式测试的提出主要是为了解决当时测试成本高...

随着Web系统的大规模发展，Web API已经成为了一种广泛使用的技术，再加上微服务和云系统的普及，Web API的数量呈几何增长。比如在一个大型Web系统中，各个子系统或者依赖系统之间一般都使用Web API来集成，从而导致开发不同子系统或者依赖服务的团队之间也存在不少问题。其中最大的四个问题是：团队之间业务和技术集成沟通困难难以快速响应外部需求变化开发流程责任链混乱Web API部署到测试环境后才发现集成问题这四个问题都属于集成和变更管理的问题，首先团队之间业务和技术集成沟通困难主要是指没有明确的集成沟通流程，那么团队之间在沟通集成业务和技术的时候则容易混乱不清，遇到各种困难。所以需...

摘要随着软件系统规模的持续增大，业务复杂度的持续增加，软件测试的复杂度也随之越来越大。而软件测试工作复杂度的直接体现就是测试用例编写、维护、执行和管理，所以编写易读、易维护和易管理的测试用例可以有效的降低测试工作的复杂度。本文主要系统的介绍了测试用例的几种经典编写和管理方法，包括每种的特点，适用场景以及实例。帮助不同的项目和团队，根据自己的情况选择适合的测试用例编写和管理方法，从而降低测试工作的复杂度，提高测试工作的效率。1、前言在软件测试工作中，测试用例是其最为重要的基础。一个良好的测试用例可以帮助测试人员更容易阅读，理解，修改并管理它，从而提高测试工作的质量和效率。要编写一个好的测试...

问题最近几年虽然微服务十分火热，但是仍然有不少人不喜欢微服务，甚至抵制它。其中最主要的原因就是其成本高，难度大。就困难而言，主要是遇到了一些不易解决的问题，其中包括以下三个与测试数据和测试环境有关的问题：问题一：测试环境被多个团队共同使用在大规模的微服务系统中，某些核心服务很多时候都是会被多个团队在共同调用，并且它可能也有多个依赖服务。而当一个服务的某个测试环境被多个团队（服务）共同使用的时候，主要会存在以下两个困难点。1、同一测试数据可能会被不同的团队修改。有些团队通过创建多套测试环境来解决这个问题，但是这样的成本很高。对于很多技术强大的互联网公司，可以通过 Docker 等技术手段来...

概述很多测试人员对于性能测试实践的机会不多，所以很难获得相关的实践经验，也很难系统的总结出性能测试相关的知识。为了方便大家能快速的系统的从整体上了解性能测试，我总结了性能测试洞见101系列文章，今天就让我们来聊聊服务器端系统性能测试。特点首先，总体上来讲，服务器端系统性能测试具有以下三个特点：需求比较困难技术相对简单 过程十分繁琐性能需求的获取一般都是十分困难的，因为很少有人能明确地提出性能需求，要么是新系统，不知道生产环境的性能需求是多少；要么就是不懂技术，无法提出正确合理的性能需求等。对于无法获得性能需求的项目，通常只能通过压力测试后并找到系统的性能极限，反过来把实际的性能指标给客户...

性能测试之并发模型对比（JMeter，Locust和Gatling篇）起因最近不少公众号和在线课程都在讨论性能测试和性能工程，但是鲜有涉及开源性能测试工具的比较与选择。几年前我就写过一篇介绍Gatling的文章《一代服务器性能测试工具Gatling》，里面简单的比较了JMeter和Gatling自身性能和开发形式。现在最为常用的三款开源免费性能测试工具/框架就是JMeter，Locust和Gatling。为了帮助大家更好地理解和选择它们，我将从并发模型角度来介绍并比较它们。并发说到并发，我们首先想到的就是服务端系统的并发模型，现在常见的并发模型有多线程模型，事件循环模型，Actor模型和...

最近随着敏捷测试在中国测试届风起云涌，其中包括不少公开课以及各种文章和在线分享，越来越多的人开始关注敏捷测试和敏捷开发。不过仍然有不少人对敏捷测试和敏捷开发提出了质疑，其中最典型的就是：敏捷测试和敏捷开发只适合小型项目玩一下，不适合大项目，因为一般大型项目质量要求非常高，敏捷做不到高质量敏捷开发没有完备的文档，难以维护，质量难以维系敏捷测试没有完整的测试用例，很难进行全回归测试，无法保证质量理论上同样的团队在单位时间内获得的质量，瀑布要比敏捷高。但是这里有几个前提常常被人忽略，那就是软件需求必须一开始就能确定并且能分析和设计得十分清楚，其次开发过程中不能有大的变动，最后不需要频繁发布。如...

起因在前两篇《TDD之让我们再聊聊TDD》 和《 TDD之让我们再聊聊TDD(续)》 中我们聊了很多TDD理论和实践相关的疑惑，其中包括TDD的分类，选择以及其实施步骤。最近TDD相关的培训和讨论也越来越多，还提出了很多独特的观点，比如：软件没有做好就是因为TDD没有做好TDD没有做好所以软件也做不好学好TDD靠多多练习就可以了，不用学习其理论知识开发应该自己理解业务，并提炼测试（需求）点来实施TDD开发只要做好TDD，就不需要其他人测试了等等对于这些观点我有不同的看法，比如我在第一篇讨论中就提到，TDD不是银弹，所以软件没有做好的原因是很多的，也不是靠TDD做好了就一定能做好。其次学习...

我的同事肖然在 《ThoughtWorks的敏捷开发》一文中介绍了ThoughtWorks敏捷开发的全貌，并在其中简单介绍了ThoughtWorks是怎么做质量内建和敏捷测试的。我作为一名加入ThoughtWorks已经7年的QA，想更为详细的介绍一下这些内容，希望能帮助业界中仍对于敏捷测试有疑虑和困惑的团队建立起自己的敏捷测试体系和实践，从而帮助团队更好的实施敏捷软件开发。在目前的软件开发领域，敏捷依然没有被广为采用，很多人诟病其：开发速度其实并不比传统的开发方式快软件质量得不到保证无法应用于大规模软件开发文档少导致开发出来的软件难以维护……其实大多都是在不了解敏捷开发中质量内建与敏捷...

前言软件安全一直被视为一项神秘而又高级的领域，其中的软件安全开发和安全测试更是很多普通的开发者和测试人员难以企及的工作。但是对于常规的安全开发和安全测试，普通的开发人员和测试人员是可以担任的。而且通过这些常规的安全开发和安全测试，可以预防绝大部分中低级安全漏洞。为什么要做威胁建模软件的安全漏洞主要来自业务需求，业务流程，软件架构，代码开发和第三方依赖包等，并不是仅仅来自某一个单一方面。并且由于某一类角色基本上很难对于业务需求，软件架构，代码细节以及各种基础设施等都很熟悉，因此对于软件系统的全方位的安全漏洞，如果仅仅希望由某几个安全测试人员通过安全测试去发现是非常困难的。所以需要有一种体系...