敏捷世界中的测试

自代码编写完成以来，我们一直在进行测试。这是检验软件质量的古老方法。随着工具的进步，我们能够更快、更好地交付产品，我们的期望也随之提高。在敏捷开发的世界里，我们往往更关注能够创建的功能数量（即开发速度），而不是偶尔出现的错误。

代码质量（在我看来，这很大程度上是主观的）不能仅仅根据 bug 的数量来判断，它还取决于其他几个因素。技术债务（糟糕的代码）如果不加以控制，从长远来看可能会造成非常严重的后果。但本文我们将重点讨论测试。

虽然测试代码的方法有很多种，但我将讨论当今时代普遍采用的几种方法：

最初，大多数软件开发都采用瀑布模型，即先收集、分析并最终确定需求。项目会被划分成若干里程碑，任何对初始需求的更改都需要提交变更请求（通常成本较高）。这使得管理者能够更好地管理工作；他们可以将工作细分并分配给团队成员。

但我们都知道，软件诞生之初就存在漏洞。因此，以下情况应运而生：

手动测试

至于目前大多数代码的测试方式，人工质量保证（QA）在当今时代仍然发挥着至关重要的作用，并将继续如此。我们不可能完全摒弃它。

这种测试方式（也称为传统测试）是由编写代码的人员以外的其他人进行测试。这可以提供不同的视角，因为我们都知道开发人员在查找 bug 方面有多么出色。手动检查对于项目的前端部分（例如 Web 或移动应用）尤为重要，以确保其在不同的浏览器和移动设备上都能正常运行。

因为在这样的过程中，开发人员没有成为规划过程的组成部分，所以他们无法对他们编写的代码承担全部责任。

虽然一开始这并非重大开销，但随着软件变得越来越复杂，测试所需的时间也随之增加。这就需要找到自动化测试流程的方法。我认为，当时人们看到了两种解决方案：自动化测试和测试驱动开发（TDD）。

即使质量保证人员在使用工具跟踪和监控问题方面变得更加高效，每当有重大部署或功能发布时，他们仍然需要进行大量的回归测试（测试所有内容）。

这导致时间效率低下，并让人感觉没有在做有意义的工作（因为工作内容重复）。因此，测试人员开始编写代码来自动化他们通常手动执行的测试——而且他们至今仍在这样做。

但敏捷开发方法的出现改变了人们交付代码的方式。如今，每个人都想采用敏捷开发，因为他们希望以前所未有的速度发布产品。这节省了时间，从而也降低了成本。

TDD（测试驱动开发）是一种开发方法，开发者在编写代码之前先编写自动化测试。您可以将其概括为以下步骤：

采用测试驱动开发（TDD）后，确保代码按预期运行的责任又回到了开发人员身上。质量保证（QA）人员的职责也从单纯测试产品转变为协助编写更多测试用例，而这些用例最终需要由开发人员来完成。

理想情况下，采用测试驱动开发（TDD）后，质量保证（QA）的角色就显得多余了，但却忽略了一个重要因素—— 视角。因为人们很难发现软件中的漏洞，所以我们需要第二双眼睛来确保一切运行顺畅。

编写TDD代码的另一个后果是，为了进行彻底的测试，代码必须采用松散的模块划分方式。这迫使开发人员编写模块划分更清晰的代码——这并非出于习惯，而是出于一种必然。

因此，在敏捷开发中，开发者在测试驱动开发（TDD）的基础上，仍然坚持编写代码，但并没有完全消除人工质量保证（QA），而是降低了对人工QA的依赖。SoluteLabs也遵循同样的原则——TDD与人工QA相结合。

还有许多其他领域需要进行测试。不过，在为初创公司和大型企业开发产品时，我们始终专注于以最快的速度交付产品，同时保证最高的代码质量标准。

我们使用 BDD 的经验是，它耗时太长，而且需求经常变化，因此不值得投入。