敏捷开发中常见的几种软件测试方法

参考文章：http://www.51testing.net/study/basis/69945.html

回归测试

回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

回归测试主要应用在代码变更的场景，我们需要测试修改后的代码是否影响软件应用程序的其他功能。 此外，当将新功能添加到软件应用程序中并用于缺陷修复和性能问题修复时，同样需要进行回归测试。 为了执行回归测试过程，我们需要首先调试代码以识别错误。一旦发现错误，就进行必要的更改以修复它，然后通过从涵盖代码的修改部分和受影响部分的测试套件中选择相关的测试用例来完成回归测试。

自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

冒烟测试

每个测开的大佬，都会经历过：

• 修复了1个缺陷，引入10个缺陷；

• 开发大佬提供的版本，不是闪退，就是无法运行，计划中的特性测试根本没办法开展。

每次出现这种情况，都需要PM出面，否则…（可能会休长假…）

而解决这些问题，最好的方法就是，给开发提交测试版本设置的一道防线，即冒烟测试。

如果说回归测试是追求大而全，那么冒烟测试追求的就是小而精。

冒烟用例/测试环境/执行入口 由测开人员提供，覆盖本次提交版本的核心功能，涉及主流程。

冒烟测试通过，可以说明开发的代码改动没有很大问题，软件也有了基本的质量保证，后续的测试阶段也可以陆续展开。

冒烟测试作为开发提测的一道防线，可以减少浪费，提交效率。

冒烟[测试用例](javascript:;)比较少，因为开发和维护成本就低很多。

主要的成本是冒烟用例失败的定位分析成本，这是一件持续的事情

冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。

如果不通过，则打回开发那边重新开发；

如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。

简化：门槛测试，一个开关而不是一个阶段。

**目的：**版本验证测试BVT（Build Verification Testing）。

**时间：**开发转测试，历时半至一个小时，很短。

**对象：**需求覆盖，主功能路径。

**优点：**节省测试时间，防止build失败。

**缺点：**覆盖率还是比较低。

**操作：**对着需求文档把新功能过一遍；把所有流程功能走一遍；用monkey跑个一两个小时；如果有历史用例的话，可以把用例分级，冒烟级、详细级、回归级等等

**用例：**冒烟测试基本上不需要什么用例，如果有的话，就用详细用例里，覆盖需求文档级别的用例就可以了

冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，冒烟测试最大的优点在于节约测试的时间成本，减少测试轮数。

灰度测试

软件测试中，有一个根深蒂固，也是很普遍存在的问题：预发环境都OK的功能，上线后，就出现各种问题，在大厂的人，应该是很有感触的。

我们都知道，软件是运行在特定环境中的，软件的的实际行为与其所处的环境具有高度依赖性。

软件运行的终极环境是生产环境，只有在生产环境测试通过，我们才能说软件有风险的几率非常低。但是在生产环境做测试，风险是很大的，对用户的影响也很大，这个时候，就需要引入灰度测试。

引入灰度环境

在灰度测试中，通常将待发版的软件部署到部分生产环境(即灰度环境)上，然后将测试流量或者部分用户流量引入到灰度环境。

如果你是某软件非常活跃的用户，你会收到某新功能的体验邀请。例如：支某宝邀请你参加体验xx新功能、某信邀请你体验xx新功能…

灰度测试实现了在生产环境对软件的终极验证，是软件发布前的最后一道防线。它的投入(环境配置/引流/自动化用例)等是一次性的，但是其产出是显著的(提前于用户发现问题)，并且可以持续产出(每一次软件升级都受益)。

单元测试

软件的问题，90% 都是编码的问题

在编码阶段发现问题，不会对任何人有影响，并且可以随手改掉。这也是成本最低，效率最高的。

那么，单元测试，如何执行呢？

一句话，就是 一行一行执行代码。

只要让代码跑起来，才能发现代码的问题。

单元测试带来的收益，还有很多，例如：更好的模块设计，更放心的代码重构等等。

当然，任何事情都有两面性，单元测试也不例外，这需要持续的编写测试代码。

这也就是出现了两极分化的情况，支持派与反对派。

一般的大厂，都会做单元测试，因为这是减少缺陷，提高效率的方式；

而一些小厂，可能就不会考了这么多，毕竟人员，资源都有限…

一些追踪问题平台

Jira、禅道等