你的应用就绪了吗？

你的应用就绪了吗？2014-03-29 infoq Gil Zilberfeld问题很简单，却很难回答。

我们通常会按时间交付软件，在截止时间之前努力完成所有开发和测试工作。我们会优先完成那些自己觉得重要的部分，当应用达到确定的质量标准后，就准备上线了。因为发布的内容可能不会尽善尽美，所以我们总是假设将来还有一些版本。甚至我们交付软件时，都不能辨别应用的就绪状态。我们总是依赖于测试人员给我们答复，但为了产品的收益和质量，我们应该让所有人都参到这个过程中。

在本文中，我们将会围绕发布一个工作应用程序讨论当前流行的几种不同测试方法。然而，这些不是你“常规”的测试工作！我们强调质量不能变成最后打补丁。我们的目标是在整个编程过程中打造并保证质量。

测试简史

现在我们的开发项目中有作为职能小组的测试人员，在那之前软件的用法都很简单，所以只让开发人员确保软件可以工作就够了。但是随着项目越来越大，应用变得更加复杂，发布截止日期也更紧了。因为程序员永远都不够用，而且会越来越紧张，所以就要求他们在很短的时间内开发更多的特性。在巨大的“质量洼地”里长满了虫子。我们急需杀虫剂。

测试人员将成为那些杀虫剂。随着职责流转，测试人员将成为守护者，捕捉从构建中遗留下来的虫子。很不幸地是，这个主意没有成功。应用太复杂了，有太多场景需要测试人员充分覆盖。即使引入了自动化，测试花费的时间也不可能低于原型开发的时间。而虫子仍然在那儿，满地都是。

在最近几年里，特别是随着敏捷方法的发展，测试已经在生态系统中有了彻底转变，自始至终我们都不可能离开测试了。另外，从安装版软件，到客户端/服务器端，再到云和移动应用的转变，已经决定了应用是否“做好市场准备”会面临更多的挑战。

如今的测试非常复杂

通常，我们认为测试是达成可交付软件的重要环节。但是你仔细想想看，在开发过程中测试无处不在，它肯定不是一个“周期”或者一项“任务”，而是散布在整个产品研发组的一套技能。

一个简单的例子可以很好地解释为什么测试不仅仅像最初定义的那样只是检查工件。假设你确定了如下需求：记录应用中的3处错误将锁定用户。这看上去非常直白，但当你开始认真研究时，你会发现很多问题：什么是错误？锁定后会触发什么？这些“隐性”的需求可能并不明确，而需要我们理解上下文中的要素。

我们来进一步说明：如果我们捕获的所有需求都是一成不变的，那么我们如何完成所有测试？你不能在生产环境中测试，所以要在一些预生产环境的服务器中做功能测试。你需要运行集成测试用例，运行场景脚本，验证实际的运行情况，然后它自己再完成清理工作。我们也可以在单元测试层面测试这些用例，但需要模拟数据库和环境调用。

那只是一个简单的需求，在测试人员实际操作之前就已经都完成了。

反馈回路

在敏捷时代V模型已经过时了,但即使在今天仍用它来表述一些基本的概念，说明过程中的每个步骤有哪些验证操作的测试点。