开发敏捷了，测试也想敏捷，结果有了“敏捷测试”。但测试真能敏捷吗？

我一直认为敏捷是以开发为中心的，如果敏捷宣言尚且是对传统软件开发模式原则上颠覆的话，那么敏捷所带来的N多佳实践更是以开发过程改进为目标的，信手拈来的是TDD、CI、XP、PP等诸多实践方式，是跟测试拉上一点关系的UT和Acceptance Testing也是多由开发者自己来完成，那对专业测试工程师来说，当团队进入到Agile的环境后，会有怎样的不同遭遇呢？在Agile中如何到测试更有效呢？

测试在敏捷前后的不同

在敏捷环境中，测试可以早介入，从确认客户需求开始，到测试计划、测试案例、测试执行、缺陷跟踪、回归测试，一直到后软件系统发布，测试会贯穿在整个流程中，这是明显区别于传统的瀑布型模式的。这样的优点毋庸置疑，让测试专家从客户的角度尽早的使用软件，及早发现与需求相悖的问题，尽量减小因设计实现所带来的缺陷问道所招致的维护成本。

这样的描述会在所有“敏捷测试”相关的国内外资料中都能看到的，也是为大家所承认的。但具体问题具体分析，在不同的团队构成、不同的软件系统等条件下，所谓“敏捷测试”总不得不去面对一些棘手的问题。

测试在敏捷中的困境及对策

虽然测试工作的内容无非包括计划、执行、回馈等几个环节，这在进入敏捷环境后也不会有怎样的变化，但面对采用了诸多开发佳实践的开发者以及会产生快速迭代出新功能的软件系统，测试人员如何保持快速的响应，并实时地调整测试过程，是每个测试团队不得不面临的问题。即使是“敏捷测试”的推广者们，在宣扬了测试早介入之后，也鲜有值得推介的测试实践拿出手来。这对各个测试团队无疑是个考验，即使是采用了相同敏捷实践的开发者也不会表现出一样的生产力，只有测试工程师根据整个团队的特点，总结出一套适合团队的测试模式，才是理想的。

系统测试

不得不说的是，算是“敏捷测试 ”也没有考虑到系统测试在敏捷环境中怎样做。这对一般不会太看重软件性能和集成性的系统来说不算个大问题，但对具有大大小小系统性能测试需求的测试团队来说，是不可想象的。测试早介入，在系统测试团队看来似乎是场噩梦，对尚未稳定的架构施加系统性能测试，多半会引起系统测试工程师们徒劳无功，因为开发人员这时不会太介意性能上的问题，他们有更重要的功能还没实现，但schedule如此紧张。如果中途需求变化甚至架构变化，开发者几乎可能把设计实现全部推到重来（这也是拜敏捷所赐了）。那之前系统测试工程师花费大量精力和时间，发现的问题很可能此不可重现不再有效。相对白白付出的工作量，如果这段时间用来做技术调研准备和自动化测试开发，效益不可同日而语。这里需要开发团队和系统测试工程师相互配合，开发为测试定义一些系统测试的进入点，并及时对系统测试的defect作出响应，才是理想的行为。