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