概述
最近，当我想利用四种资源开始一个新的自动化测试项目时，我首先想到的是使用敏捷方法中的任何一个，但是往往不能继续，因为一连串的问题浮现在了我的脑海里。这些问题类似"在自动化测试中使用敏捷方法是否可能？""我能否使用传统工具？""我是否应该使用开源工具？""如果我在敏捷环境中使用了自动化测试，那么我面临的挑战都有哪些？"。在这篇文章中，让我们一起分析，在自动化测试中使用了敏捷方法所遇到的一些挑战。在敏捷环境中的自动化测试处在一个变得混乱、无结构化、无法控制的风险之中。
敏捷项目团队向自动化团队提出了他们所面临的挑战：不明确的项目范围、多次迭代、极少的说明文档、早期频繁的自动化需求以及来自自动化团队的利益相关者积极参与产生的大量需求的挑战。这些挑战包含：
挑战一：需求阶段
自动化测试开发者从"用户描述"中获取需求，这是客户需求功能的简要概述。
每个需求按照如下优先顺序排列：
高：必须在第一次发布就完全实现得关键任务需求。
中：可以逐步实现的重要需求。
低：这些需求为最好有但是对于软件本身操作并不是关键的。
一旦建立了规则，"迭代"的发布计划就开始了。一般来说，每一个敏捷迭代的发布需要一到三个月。
客户/软件人员太过随意导致了需求变化的挑战，有时，这些需求是如此易变使得迭代无法进行。这些挑战是在实施敏捷自动化测试的过程中最大的挑战。
挑战二：选择合适的工具
使用传统的或最新包含记录和回滚功能的工具问题，迫使大家必须等到软件完成才能开始工作。再者，传统的自动化测试工具在敏捷环境中是无法工作的，这是因为他们解决的是传统的难题，这和敏捷自动化团队所面临的挑战是不同的。
自动化在敏捷项目的早期阶段，通常是非常难做的，但是随着系统的发展和演变，一些方面的解决自动化就有了用武之地，因此，自动化工具的选择变成了提高效率和质量的关键。
挑战三：脚本开发阶段
自动化测试人员、开发人员、业务分析员以及项目的相关利益人员都能启动有关如何选择下一个冲刺目标的"用户描述"会议。一旦一个"用户描述"被选中为冲刺目标，他们将会成为一系列测试的基础。
每一次扩展新的功能，必须进行回归测试，以确保现有的功能没有被在每个迭代周期引入新的功能的影响。每次项目冲刺导致回归测试的规模增长，测试团队使用自动化测试回归套件以确保这仍旧是一个可管理的任务。
挑战四：资源管理
敏捷方法要求一种复合测试技能，这就是说，测试资源需要定义不清晰的场景和测试用例，甚至在开发人员身旁实施人工测试，编写自动化回归测试程序并执行自动化回归包。随着项目的进展，专业技能将也需要掌握，包含覆盖更多测试领域，也许将包括集成和性能测试。这部分工作应该由一位合适的多领域专家来计划和收集要求。在资源管理方面具有挑战性的部分，是找出复合技能的测试资源并合理分配。
挑战五：沟通
良好的沟通必须存在于自动化测试团队、开发人员、业务分析师和利益相关方之间。这就要求客户和沟通团队之间有高度的协作。更多的客户参与意味着更多的建议或客户方的变更，这意味着沟通需要更多的宽度。关键的挑战是，所有过程应该能够获取和有效地执行，并且所有的变化和数据的完整性需要保留。在传统的测试中，开发人员和测试人员如油和水，但在敏捷的环境中，具有挑战性的任务是他们必须共同努力实现的目标。
挑战六：每日例会
每日例会是在敏捷过程中的关键活动。团队进行15分钟的会议，这些会议的效果是什么？如何做到到目前为止，这些会议是有助于自动化实践开发者？
挑战七：发布阶段
敏捷项目的目的是尽可能快地提供一个基本的工作产品，然后经过一个持续改进的过程。这意味着没有一个单独的产品发布阶段，最具挑战性的是产品的集成测试和验收测试。
如果我们能找到一个很好的优化方式，这就为质量保证人员在敏捷环境中的自动化回归测试提供了一个管理敏捷过程的绝好的机会，也可以更好的在用户和开发者之间架起桥梁，了解什么是两者之间必需的，它是如何实现的以及它是如何在开发之前就部署的。自动化实践应该在方式和结果之间取得利益的平衡。此外，应该继续保持在整个系统发展阶段满足业务目标和达到目的的要求。
关于作者：
J.B. Rajkumar在学术界和软件测试领域拥有超过15年的经验。他曾作为企业培训师，测试经理，质量保证经理和质量控制经理。他也是一个频繁在国际会议，学院，大学和软件领域发表演讲的人。目前他在一个顶尖的跨国企业做自动化实践。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
