在这篇文章中，作者J.B. Rajkumar分享了他在敏捷环境中实现自动化回归测试的经验。
摘要
最近，当我想要用四个资源开始我新的自动化测试项目时，我想到了使用敏捷方法中的某一种方式。但是由于我脑海中浮现的一系列问题，我的项目没能继续下去。这些问题诸如："在自动化测试中使用敏捷方法是否可行？"，"我能使用传统的工具吗？"，"我必须使用开源工具吗？"，"如果我试图在敏捷环境中实现自动化测试，那么我将会面临什么样的挑战？"。因为敏捷环境中的自动化测试具有混乱、无组织性、无法控制的风险，于是在本文中，我们将会分析一些使用敏捷方法实现的自动化测试时面临的挑战。
敏捷项目给自动化团队带来的挑战有很多：项目范围的不清晰，多次迭代，文档内容简单，早期频繁的自动化需求，以及所有的项目相关人员都积极的参与到所有的需求中。其中的一些挑战如下：
挑战1：需求阶段
自动化测试开发人员是通过"用户故事"的方式捕捉需求，但这些故事只是用户相关功能的简要描述。
每一个需求都必须按下列方法优先排序：
高：这些都是关键的任务需求，必须在第一个版本中就必须完成。
中：这些需求很重要，但可以在版本实施时完成。
低：这些需求不是软件操作的关键部分，但如果能有这些需求，软件会更好。
一旦优先级被确定下来，"迭代计划"就开始了。通常，每一次敏捷迭代开发都需要1到3个月才能交付。客户/软件人员都可以很自由的对需求进行更改。有时，由于这些修改的需求很不稳定，迭代过程只能将其舍弃掉。这些修改在实现敏捷自动化测试的过程中都是更大的挑战。
挑战2：选择合适的工具
传统意义上的测试，都是直到软件开发完成后，能进行录制和回放的强大的测试团队才开始工作。此外，由于传统的自动化测试工具解决的是传统的问题，但是这些问题和敏捷环境中的自动化团队面临的挑战并不一样，这就导致传统的自动化测试工具并不能适用于敏捷环境。
挑战3：脚本开发阶段
自动化测试人员，开发人员，业务分析师和项目的相关人员都将参加项目的启动会议，并将"用户故事"作为下一个任务目标。一旦这个目标定了下来，"用户故事"就会被看做是接下来一系列测试的基石。
随着每次迭代中功能点的增加，就必须频繁的执行回归测试来确保每一个独立的闭环中已经实现的功能不会被新引进的功能所影响。回归测试的规模随着软件功能点的增加而增大，并且需要确保这些工程可以被测试团队使用自动化测试工具里面的回归套件管理。
挑战4：资源管理
敏捷方法需要混合型的测试技能，也就是说，需要使用测试资源来定义不清晰的场景和测试用例、引导开发人员进行手动测试、编写自动化回归测试用例并执行自动化回归包。随着项目的进行，需要有专业的技能来覆盖更多的包含集成测试盒性能测试的测试领域。这就需要一个具有适当的跨领域专家来计划和整理需求。在资源管理阶段的挑战是要找出多重技能的测试资源并整合它们。
挑战5：沟通
自动化测试人员，开发人员，业务分析人员和项目经理之间必须有良好的沟通。客户和交付团队之间应该有高度默契的互动。更多的客户参与意味着能从客户那里获得更多的建议或者更多来自客户的更改需求。这也意味着沟通的无边界性。这种流程中最关键的挑战是要捕获并有效的实施所有的更改以及要保留的数据的完整性。在传统的测试中，开发人员和测试人员的关系就像是油和水，互不相容。但是在敏捷环境中，挑战点是开发人员和测试人员必须在一起工作来实现目标。
挑战6：每天激烈的会议
每天激烈的会议是敏捷过程关键的驱动点之一。团队每工作15分钟就进行一次会议。这些会议的效率在哪里？对自动化实践开发人员又有多深远的帮助？
挑战7：释放阶段
敏捷项目的目标是为了尽可能快的提供一个具有基本功能的产品，然后再进行一系列连续的过程中进行改进。这就意味着产品没有任何的释放阶段。对于测试人员具有挑战性的部分集中在集成测试和产品的验收测试。
如果我们能以一个最优的方式面对这些挑战，那么QA就能利用敏捷环境中的自动化回归测试来领导整个敏捷过程。自动化回归测试在用户和开发人员之间搭建了一座桥梁来理解双方需要的究竟是什么，这个目标如何在调度部署前就能确保被实现。自动化实践应该在持续确保整个展开的系统能满足业务目标的同时，在方法和结果中都获得一定的利益。
.......
本文出自《51测试天地》原创测试文章系列（四十四）
