介绍随着AI的飞速发展，AI已经使用到许多软件系统中，也逐步的应用到软件测试的工作中，并且利用各种AI相关的技术来辅助测试工作也是未来一个测试趋势。当前AI的主要几个应用方向包括，视觉系统，语音系统，决策系统，自然语言处理系统和大数据系统，因此在测试辅助工作中其最主要的方面包括：基于业务流程、被测系统内容、测试用例和测试数据的学习，测试用例和测试数据的生成，自动化测试代码的生成，测试中的视觉识别和NLP，自动化探索性测试，大规模测试日志和结果分析，缺陷定位等等。其中视觉测试，测试日志和结果学习，以及缺陷定位都已经有比较成熟的商业产品，但是相应的成熟的开源系统还暂时没有。而通过相应的学习，...

介绍随着 Web 应用的空前发展，前端业务逐渐复杂，为了处理这些复杂业务，前后端分离，出现了专门应对这种分离架构的应用开发框架，比如 Angular，React，Vue 等，从而也导致 Web 应用的复杂度大大增加，并出现了 SPA（Single Page web Application）。同时随着越来越多的用户使用移动设备访问 Web 应用，使得 Web 应用需要支持一些性能并不是很好的移动设备。为了度量和测试 Web 应用是不是在高复杂度的情况下，页面性能能满足用户的需求。前端页面性能测试本质上和本地应用性能测试类似，其性能和运行应用的设备的性能强相关，即运行被测系统的硬件性能越强，...

介绍随着自动化测试方法和技术的快速发展，自动化测试的的直接开发难度越来越小，但是由于其规模越来越大，测试类型和测试基础设施也越来越多，导致整体开发和实施自动化测试的复杂度是在逐渐增加的。对于大型项目，相对大量不同类型的测试和测试基础设施，专注于测试分析和测试设计，并根据测试策略和计划实施测试工作，包括测试分层，测试赋能，测试前移，开发自动化测试等，这些才是主要也更为重要的工作。由于很多公司的测试资源都是相对较少的，所以让有限的测试资源能尽可能全部的投入到这些重要的工作里面，则可以得到更多更有效的测试用例和测试结果，更好的体现测试的价值。比如TDD这样的技术，就可以使用更多更有效的测试用例...

历史与简介早在 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模型和...

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