敏捷宣言或其12条准则中没有提到任何要团队必须平衡测试自动化的工作以达到成功的说法。但是，如果你曾经做过任何形式的敏捷或适配性开发工作的话，你肯定知道他有多重要。敏捷促进了反馈循环更快进行。测试自动化，当有技能地去做，恰恰提供了这一点。重复地跑自动化测试用例给你的程序的质量提供了心脏的跳动，告知每个人当你从代码库向程序中添加或移除功能点时你程序的稳定性。对自动化的极乐世界是有一条路通往那里的。它将你导向你的团队去建设有价值和可靠的自动化。不幸的是，它是设置在双方中，其中的问题可能会将勇敢的努力变成一堆沮丧和白费力气。学习怎样避免将会在你实现测试自动化过程中挡路的几个障碍的发生和出现。
视野的缺乏
毫无疑问，测试自动化最有危险的隐患是缺乏视野。一个连贯的视野产生一幅详细的地图---某种脆弱的你的团队可以开始剖析和理解的东西。没有那幅共享的理解，团队们经常在一个项目的生命周期里表现出漫无目的的情形。尽管他们可能坐得很近，但是一个团队可能跟下一个团队的策略不同。其他团队可能在做重复工作。另外一个可能完全在往错误的方向发展。更糟糕的是，团队们可能在建造一些最终会被忽略或放弃的不可维护的东西。洞察力应当是简单的并且清晰地阐述它的目标。主要的目标是去创建一个回归套给予你的团队信心当他们在重构程序的时候能够发现缺陷。
重构旧的代码没有一个自动化安全网会是很危险的。它可能会有不可预见的质量后果，尤其是当处理那种过于复杂的不愿用手"摸"的代码时。开发团队和他们的产品拥有者需要有平静的大脑让他们无所顾忌地不用负面影响顾客体验地重构程序。另外一个重要的目标是你的自动化测试套应当将你的测试人员从重复手工执行回归用例中解放出来。这种解放会允许你的团队将精力集中在更有深度的探索性测试中。如果你曾经多次手动跑过回归测试，你就知道这最终是一个重复性的会麻木你的知觉和大脑的活动。
自由的测试人员是开心的测试人员，而开心的测试者会发现更好的缺陷。一个稳固的自动化策略应当将你对单元，功能（或服务）和UI测试的预期细节化。因为每一种类型都有其自己的成本和投资回报，对你团队应当对每个类型贡献多少时间具体化。马克.科恩的自动化三角形象地呈现了每个测试类型的合理比率。不要低估一个有粘聚性的可实现的策略的价值。
它会成为你在专业，奉献和团队合作之旅中的技术指导。
整合聚集
我曾见过三家机构的团队测试自动化配置。第一和最有毁坏性的是孤狼方式。创建和维护测试的责任降落在一个单一的个人，通常是团队里最有技术能力的QA工程师。这个人跟其他每个人一样对手动测试有额外的责任。孤狼方式中使用的自动化工具很可能是由管理层购买的。第三方工具产生录制-回放自动化用例，且能快速地创建，但是那些测试通常本质脆弱。他们无法摆脱地将用户界面元素绑定到测试逻辑上，因此保证任何在用户界面上的小的变动意味着级联的测试失败。对这种等级的测试破坏意味着很多测试将不得不重新录制，而没有足够的时间来解决这些问题因为有其他的测试责任。所以，用户界面回放测试停留在一个失败的状态。
因为对结果缺乏信心，回归测试套最终将会被暂停使用。该机构将会把用户界面测试自动化与失败关联在一起。在不同方面让团队信服将会是一场费劲的战争。下一个方式是有一个小的，分离的自动化测试团队与其他团队分开的方式。简单的团队不会将他们最好的做法与组织剩下的人员社交分享。这些团队也会发现随着他们的测试数增加，维护工作变得不可持续。不是去开发新的自动化用例，他们去修复测试问题并且给框架打补丁。他们没有这种网络带宽来创新或者将他们的知识和专业与其他团队共享。甚至更危险的是，他们的分离可能导致在所有测试自动化工作上的一种域拥有感和微妙的不愿分享的情绪。给测试自动化支持的最有效率的方式是让每个人都负起责任来。
在敏捷中，有一种成熟度标准来定义工作是否被认为是完成的。整个团队同意而且为这个完成情况负责。一个例子是，团队需要手工测试他们开发的功能。测试人员给精心安排所有的测试成员测试活动，包括开发人员。将测试自动化编织近你的完成度标准中是一种让所有人对产品质量负责的好方式。非技术测试人员可以帮忙编写前段测试用例，而开发人员或者测试"自动化人员"编写实际的自动化代码。目标是让整个团队感受到所有权。每个人分享开发，维护和修复测试的责任增加了测试的效率，移除了职员的平静。它鼓励合作和共享最好的做事方法。对自动化策略有一个统一的洞察和普遍存在的理解是使用这种团队为基础的方式的前提。
银弹
测试自动化对非技术的管理经理们是一个黑盒子。他们对它的理解是有限的，而他们对调查解决方法的时间几乎是不存在的。市场上有产品生成可以提供最终测试自动化解决方案-银弹。它的设想是非技术测试人员可以从理解使用该产品开始，然后快速不费力气地建造一个健壮的自动化套。管理者们可能有一种感觉是因为没有必要的特殊的培训，软件的成本是合理化的。营销这类产品的网站生成要移除测试自动化的复杂性换之以一种直观的用户界面。别弄错，测试自动化是复杂的。当心提防那些声称可以戏剧化简化创建自动化测试的产品。
随着专利测试数目的增加，团队们变得跟自动化工具更加紧密地连接起来。如果你已经创建了成千上百个测试用例却发现这个工具不能实现他承诺的功能怎么办？对对成本有要求的机构，围绕是撕还是替换的变动的讨论会很困难因为已经投入的沉没成本。关心设想的经理们不可能去承认失败，而团队被留在一遍无所选择只能继续讲他们自己推往墙角。这需要有勇气的领导力来承认在工具选择流程上的错误。从一个技术角度来看，选择一个第三方测试工具需要完全采用他们的架构。你想要一个增强吗？提交一个功能请求，然后跟用户库的其他人排在一条线上。同时，你在非法访问计算机测试系统来让他们工作。增加的技术债务将会导致广泛的测试脆弱性。当脆弱测试越来越多时，维护他们的成本变得不可持续。如果你决定转用另一个测试工具，没有一个良好的退出策略。这不会像将你的测试用例从一个工具中到处然后导入到另一个中那么简单。
... ...
查看全文内容，请点击下载：http://www.51testing.com/html/18/n-3708418.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
