核心提示：21世纪是高度依赖计算机系统的信息时代，软件产品日益多元化、多样化的同时，软件开发也将面临着新的更为艰巨的挑战：一方面是软件开发上需求的多样性、个性化，需要不断的与时俱进，另一方面则是来自同行激烈的市场竞争。
摘要：随着计算机系统的信息时代激烈的市场竞争的同时，敏捷测试方法也开始受到更多的关注。同时，软件测试用例的选择和生成也是软件测试中的一个重要研究领域，测试用例的质量将直接决定软件测试的科学性和有效性。
敏捷开发模式自2001年《敏捷宣言》（“agile manifesto”）的创生，经过多年的打磨已经成为现今系统开发上非常流行和成功的开发模式，传统的东西就是用来打破的，敏捷开发模式以人为本和其开发上的种种优势，渐渐地取代了传统的瀑布式开发模式，敏捷测试也在新环境里产生出来的打破传统的测试模式，并且渐渐地也取代了传统的测试模式。甚至于敏捷测试将会在将来，转化成更适合现代化软件开发、测试团队的方法和实践。
其实敏捷测试实质不只是去测试软件本身的功能和质量，还包括软件测试的过程和模式，进一步的完善软件本身的功能和质量，速度，解决其中发生的或者是可能发生的问题。如果产品发布后才发现很多问题，很可能是软件开发过程出了问题。因此测试除了需要确保软件的质量问题，即软件做了正确的事情，以及软件做了应该做的事情以外，敏捷的测试团队还要保证整个软件开发过程是正确的完善的。即是从使用软件的用户的这个角度来测试软件，以确保被测软件的完整性和正确性。敏捷测试重点是关注软件持续迭代的测试新开发的功能，而不再强调传统测试过程中严格规定的所谓的测试阶段，因此相对于强调传统测试方式更加的灵活多变，可以节约软件测试过程中浪费的不必要的时间。建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
其次敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈。敏捷测试即是不断完善开发产品的质量指标，提高质量以及运行速度，正确的确立开发产品的测试策略，确认客户的需求得以确保整个生产的过程安全的、及时的发布最终产品。敏捷测试人员因此更需要在活动中关注产品的市场需求，了解产品设计，解读源代码；在独立完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论，团队决策，这样才能更加了解开发产品，从而更好的调试产品的不足，及时反馈。
敏捷测试还需要高度迭代工作、需要频繁的得到stakeholder、客户的反馈，需要动态的调整测试计划和测试的执行。并且，敏捷测试人员需要参与到了更多的敏捷生产活动中，影响着团队所做出的决定和计划。
在敏捷测试中“人”才是重心，方法、策略则是辅。敏捷测试是以人为本的，也就是说敏捷型方法是“面向人”的，而非“面向过程”的，“敏捷”的一切都围绕着人展开，如敏捷需要直接、平行的沟通；敏捷需要持续直接的了解客户需求以及敏捷活动的设计，方案和决策需要团队协同制定等等，敏捷测试需要一支非同寻常的团队，不同于以往传统开发模式下的团队结构。为了去适应不同的团队结构和不同的项目环境，敏捷项目和敏捷活动的实践行动也将因“人”而异，但是，并不是说可以“为所欲为”。其次工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法则认为没有任何过程能代替开发组的技能，过程起的作用是对开发组的工作提供支持。一旦脱离了正确的敏捷方法和敏捷原则的指导，我们的敏捷测试活动就好雾里看花，只会越看越花。
敏捷开发以测试为驱动的开发方式——测试驱动开发，递增型的迭代测试，它首先是对敏捷测试过程活动和生命周期模型的介绍，通过学习经典的敏捷增量测试模型，我们将敏捷测试的各类活动有机的组合到了一起。在此之上，对定制后的独特敏捷增量测试模型的分析和理解，帮助我们理解测试活动的规划和管理；递增型的迭代测试，它首先是对敏捷测试过程活动和生命周期模型的介绍，通过学习经典的敏捷增量测试模型，我们将敏捷测试的各类活动有机的组合到了一起。在此之上，对定制后的增量测试模型进行分析，继而理解，从而更好的帮助测试人员理解测试活动的规划和管理；以及需要特别关注的递增型迭代测试的关键活动之一——“静态测试”；这也是迄今为止最高难度、最具影响力的敏捷测试活动。它将敏捷测试最早的引入产品开发过程中，测试人员必须以产品以后的角度去判断设计的有效性和可能性，此活动暴露了较早的产品设计过程中的一些缺陷、避免了团队人员对目标的不一致理解等，是测试活动中最有创造性价值的部分；然而，敏捷测试不是一蹴而就的，要做到真正的敏捷，无论是从传统测试模式到敏捷测试的过渡上，还是组建全新的团队都是需要循序渐进的，同时也需要团队成员的通力合作和不断的实践来完善敏捷测试的实践原则和方法。
综上所述：敏捷开发项目中软件测试方法的研究是以人为本的，围绕着人而展开的实践活动，是一种与传统的瀑布模型开发和cmm（capability maturity model，软件开发的能力成熟度模型）所追求的严谨的文档制度截然相反的开发过程。这一开发过程注重开发团队和成员之间的关系而不是以开发的进程和使用的工具为重点，注重所开发的软件产品而不是追求广泛的文档编制，注重开发过程中与客户的协同工作而不是以签订合同的谈判为工作的核心，注重在开发过程中随时调整计划而不是同意完全遵循某一开发计划，以实现所谓开发过程的敏捷。
