在前面几章里，笔者所讨论的都是传统的UI层的自动化测试。作为传统的软件开发模型中的典型代表，无论是V模型、W模型，都是将测试人员的工作定格在一个基调上，那就是编码完成了再开始进行测试；虽然UI层的自动化测试也存在超前式的测试开发，但是它所要求的条件无论从客观上（开发设计模式足够先进）还是主观上（自动化测试技术层次）都非常高。而如今，人们不再满足于这种毫无生气的软件开发模式，他们不仅要改变软件开发本身的管理模式，而且提出了“编码未动、测试先行”的概念！
（a）敏捷测试理念的起源
敏捷开发到底是什么样的一种开发形态呢？我从网上摘抄了一些简单易懂的文字，这样就省去了我用自己的语言费力的解释了：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可以运行的特征。敏捷团队依靠变化来获取活力，团队几乎不进行预先设计，因此，不需要依赖一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援，这样保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。
另外一个问题：敏捷开发是否为专职的软件测试敲响了丧钟？我理解，敏捷其实就是开发对测试说：“我受够了这么多年来的一成不变和低效，所以我需要一个改变，我要更加人性化、更加机动灵活的开发方式来实现对用户需求的快速达成（参见敏捷宣言），并以此留住我们的客户和用户。而要做到这些，必须有测试的支持，请测试为我们定制开发、预防缺陷，让我们的软件开发更有效率、更有激情吧！”笔者不曾参与敏捷开发、测试，经验完全谈不上，这里只是以自己的理解来揣度敏捷开发给测试带来的一切。
那么敏捷测试的实质是什么呢？我曾经参加过一次51Testing举办的软件测试沙龙，演讲嘉宾是微软某个产品部门的一位测试技术总监，他从敏捷宣言开始一直讲到敏捷建模和实施，虽然我这个敏捷门外汉基本没有听明白，但是作为一个测试人员，让我映像最深刻的就是这六个字：测试驱动开发！后来通过在网络上不断的学习和咨询，我确定了一点，那就是敏捷测试的核心价值就在于测试驱动开发。什么叫测试驱动开发呢？意思就是说每一处将要实现的功能或者模块，你必须事先写好它的测试代码，否则即便你实现了这功能也是没有必要的。一般的开发人员从观念上很难接受这一点，听起来很残酷，只要没有预先写好测试，所做的将不被认可，这与传统的先编码后测试的观念与做法完全是背道而驰的。即便是这样，还是有很多敏捷开发的拥趸者对这一点坚信不疑，而且他们普遍更加倾向于以代码和测试用例作为知识传承的载体。这些被坚持了好几年的观念和做法想必不会毫无道理，因为我们可以看到，他们的确产出了可以稳定运行的软件，比如微软的Office 2007和Windows Server 2008这种已经被广泛推广的产品。
（b）敏捷测试带来的挑战
1）敏捷开发改变测试传统
上文提到测试驱动开发就意味着每一处将要实现的功能或者模块都必须事先写好它的测试代码，那么这段测试代码到底应该由谁来写呢？由传统的开发人员好像对测试是没有这个意识的，而测试人员是否具备相应的技能又是一个问题，显然我们必须要做出抉择。在面临这种问题的时候大家往往都会选择去改进开发人员的测试意识，因为在管理者来看来，要育成一批与开发人员对编码技术有相同水平的测试人员成本不会很低。这样一来，很多人便开始鼓吹敏捷开发不需要测试这种言论，这究竟是不需要测试了还是在混淆视听呢？很明显，既然测试驱动开发，何来不需要测试这么一说呢？只是说在敏捷开发中的大多数自动化测试编码可以由熟练掌握编码技能的开发人员来完成。如果管理者真的选择让编码人员自己来写测试驱动自己的开发，那么测试人员的传统地位的确是受到了挑战的；当然，精明的领导人也不会轻易丢弃测试人员丰富的测试经验与意识，会更加乐意考虑好好利用一下测试人员缜密的思考能力和对软件质量问题的敏锐洞察力的。那么测试人员该何去何从呢？要么在敏捷中努力提高，要么在敏捷中被淘汰，要么远离敏捷……
敏捷测试崇尚百分之百的自动化，当然在实际操作中还会存在些许手工参与或者干预的情况，尤其是从UI开始往上的层面，比如涉及用户感官体验的内容等。UI往底层延伸，还有服务、业务组件的接口测试和单元测试；在敏捷测试中他们所占的测试代码和测试工作量比例大致是呈一种金字塔的关系。虽然因敏捷的程度或者系统的特征不同而让测试内容分布有所不同，但一般情况下，手动测试内容极少，UI层的自动化测试约占10%左右，接口层的自动化测试约占30%左右，而单元测试占比可能在50%以上。而这仅有的10%左右的UI自动化验证测试却可能是整个构建中的效率瓶颈，因此很多测试人员可能需要增加对自动化测试执行效率问题的关注，以往对测试程序或者脚本本身效率没有很高要求的观念将因此而改变。
