彩票走势图

视野的缺乏

毫无疑问，测试自动化最有危险的隐患是缺乏视野。一个连贯的视野产生一幅详细的地图---某种脆弱的你的团队可以开始剖析和理解的东西。没有那幅共享的理解，团队们经常在一个项目的生命周期里表现出漫无目的的情。尽管他们可能坐得很近，但是一个团队可能跟下一个团队的策略不同。其他团队可能在做重复工作。另外一个可能完全在往错误的方向发展。更糟糕的是，团队们可能在建造一些最终会被忽略或放弃的不可维护的东西。洞察力应当是简单的并且清晰地阐述它的目标。主要的目标是去创建一个回归套给予你的团队信心当他们在重构程序的时候能够发现缺陷。

重构旧的代码没有一个自动化安全网会是很危险的。它可能会有不可预见的质量后果，尤其是当处理那种过于复杂的不愿用手“摸”的代码时。开发团队和他们的产品拥有者需要有平静的大脑让他们无所顾忌地不用负面影响顾客体验地重构程序。另外一个重要的目标是你的自动化测试套应当将你的测试人员从重复手工执行回归用例中解放出来。这种解放会允许你的团队将精力集中在更有深度的探索性测试中。如果你曾经多次手动跑过回归测试，你就知道这最终是一个重复性的会麻木你的知觉和大脑的活动。

自由的测试人员是开心的测试人员，而开心的测试者会发现更好的缺陷。一个稳固的自动化策略应当将你对单元，功能（或服务）和UI测试的预期细节化。因为每一种类型都有其自己的成本和投资回报，对你团队应当对每个类型贡献多少时间具体化。马克.科恩的自动化三角形象地呈现了每个测试类型的合理比率。不要低估一个有粘聚性的可实现的策略的价值。

它会成为你在专业，奉献和团队合作之旅中的技术指导。

整合聚集

我曾见过三家机构的团队测试自动化配置。第一和最有毁坏性的是孤狼方式。创建和维护测试的责任降落在一个单一的个人，通常是团队里最有技术能力的QA工程师。这个人跟其他每个人一样对手动测试有额外的责任。孤狼方式中使用的自动化工具很可能是由管理层购买的。第三方工具产生录制-回放自动化用例，且能快速地创建，但是那些测试通常本质脆弱。他们无法摆脱地将用户界面元素绑定到测试逻辑上，因此保证任何在用户界面上的小的变动意味着级联的测试失败。对这种等级的测试破坏意味着很多测试将不得不重新录制，而没有足够的时间来解决这些问题因为有其他的测试责任。所以，用户界面回放测试停留在一个失败的状态。

因为对结果缺乏信心，回归测试套最终将会被暂停使用。该机构将会把用户界面测试自动化与失败关联在一起。在不同方面让团队信服将会是一场费劲的战争。下一个方式是有一个小的，分离的自动化测试团队与其他团队分开的方式。简单的团队不会将他们最好的做法与组织剩下的人员社交分享。这些团队也会发现随着他们的测试数增加，维护工作变得不可持续。不是去开发新的自动化用例，他们去修复测试问题并且给框架打补丁。他们没有这种网络带宽来创新或者将他们的知识和专业与其他团队共享。甚至更危险的是，他们的分离可能导致在所有测试自动化工作上的一种域拥有感和微妙的不愿分享的情绪。给测试自动化支持的最有效率的方式是让每个人都负起责任来。

在敏捷中，有一种成熟度标准来定义工作是否被认为是完成的。整个团队同意而且为这个完成情况负责。一个例子是，团队需要手工测试他们开发的功能。测试人员给精心安排所有的测试成员测试活动，包括开发人员。将测试自动化编织近你的完成度标准中是一种让所有人对产品质量负责的好方式。非技术测试人员可以帮忙编写前段测试用例，而开发人员或者测试“自动化人员”编写实际的自动化代码。目标是让整个团队感受到所有权。每个人分享开发，维护和修复测试的责任增加了测试的效率，移除了职员的平静。它鼓励合作和共享最好的做事方法。对自动化策略有一个统一的洞察和普遍存在的理解是使用这种团队为基础的方式的前提。

银弹

测试自动化对非技术的管理经理们是一个黑盒子。他们对它的理解是有限的，而他们对调查解决方法的时间几乎是不存在的。市场上有产品生成可以提供最终测试自动化解决方案—银弹。它的设想是非技术测试人员可以从理解使用该产品开始，然后快速不费力气地建造一个健壮的自动化套。管理者们可能有一种感觉是因为没有必要的特殊的培训，软件的成本是合理化的。营销这类产品的网站生成要移除测试自动化的复杂性换之以一种直观的用户界面。别弄错，测试自动化是复杂的。当心提防那些声称可以戏剧化简化创建自动化测试的产品。

随着专利测试数目的增加，团队们变得跟自动化工具更加紧密地连接起来。如果你已经创建了成千上百个测试用例却发现这个工具不能实现他承诺的功能怎么办？对对成本有要求的机构，围绕是撕还是替换的变动的讨论会很困难因为已经投入的沉没成本。关心设想的经理们不可能去承认失败，而团队被留在一遍无所选择只能继续讲他们自己推往墙角。这需要有勇气的领导力来承认在工具选择流程上的错误。从一个技术角度来看，选择一个第三方测试工具需要完全采用他们的架构。你想要一个增强吗？提交一个功能请求，然后跟用户库的其他人排在一条线上。同时，你在非法访问计算机测试系统
来让他们工作。增加的技术债务将会导致广泛的测试脆弱性。当脆弱测试越来越多时，维护他们的成本变得不可持续。如果你决定转用另一个测试工具，没有一个良好的退出策略。这不会像将你的测试用例从一个工具中到处然后导入到另一个中那么简单。

数字游戏

那些对测试自动化直观价值不熟悉的人尝试从一些度量中收集获取这种信息。他们将注意力放在数个编写好的测试用例且注意自动化测试发现的缺陷数。而那些度量可能很有意思，他们只阐述了故事的一小部分。没用自动化的测试团队每次回归测试用例手工运行时都会支付一轮循环成本。随着代码库的增大，回归测试集也会随之增加。结果，那个循环成本继续增加。一个有意义的度量是“我们使用自动化工具每周节约了多少人-时？”。随着团队可以执行更多探索性测试用例，他们可能发现更多测试缺陷。有多少缺陷是在使用探索性测试发现而使用手工运行回归测试用例不可能发现的？这是个有趣的问题，但是不可能有答案。更困难的是分配一美元可以展示投资回报的价值。自动化带来价值，但是据我的经验很难衡量。

一个有着可靠的安全网的团队很大胆。产品所有者可能不止会冒险还会允许团队去对重构的代码做更多冒险的活动。这种重构导致的结果可以增加产品质量，甚至它还能改善该程序的用户体验，然后可能增加登录和转变。更多的用户就会带来更多收入。而用这种假设的情形来决定投资回报率是不可能的。它强调了一个观点---不是所有有价值的东西都容易去衡量。关注于错误的度量的领导者会激励错误的事情。如果一个团队将关键表现指数作为总测试数的话，队员将会更可能会写更多测试用例。总体测试数只代表自从引进测试自动化所走的距离；它并不告诉你离目的地有多近。而高测试总数并不等同于更好的覆盖率；它只意味着团队已经找到一种方式去游戏/测试系统。有意义的测试自动化度量的一个例子是手工回归测试集被自动化的百分比。那给团队成员一个对进度的理解。它也回答了那个还需要多少工夫才能完全自动化手工回归测试的问题。

不能快速传送价值

没有一个合理合适的架构的框架的自动化是毫无价值的。框架这个词包括所有支持性的帮助你的测试有价值的代码。开发一个合适的框架构架需要时间。它是一个与你团队的需求不断演变的一个适应性的过程。总是有要加强的代码，有要更新的组件和要执行的重构工作要去做。由于软件开发的节奏的原因，编写测试自动化的团队迫切需要尽可能快地传送价值。如果你的公司有冲刺评审，展示你所取得的进展。不要等到你的测试框架成熟到开始编写测试用例；你可以使用现有的框架骨架来跑测试用例。

从价值的角度，你能做的最差的事是花费数轴来开发一个没有任何测试进行的框架。一个没有测试的框架-不管架构多么优雅，提供的价值微乎其微。结果，投资商可能
开始怀疑他们的投资。从一开始，你的焦点应当放在自动化手工冒烟测试上。使用如Jenkins这样的工具，将这些测试用例的运行绑到一块部署代码上然后部署到你的测试环境上。你的下一个目标应当是自动化整个手工回归测试集，从高价值的组件开始。类似于注册，转变，登录，下单和支付的功能是高价值目标，需要被透彻测试。采用一种自动化策略后，至少在首次冲刺末尾承诺发送一小部分测试结果。通过展示你的测试结果在团队附近某处的信息发射器（如挂在墙上的电视）最大化透明度。然后定期间隔地，反思你的进展然后做过程改正来增加测试程序集的价值。

遗漏价值提议

任何团队的自动化努力目标都是去创建有价值的测试用例。有价值的测试用例是稳定的，快速的，恰当关注的和易于维护的。这些测试类型是由已经长期自动化测试的团队编写的。随着时间的推移，队员们对什么该自动化，什么不该自动化有了理解。有经验的测试团队视自动化为一把扳手，而不是锤子。由于增加的维护成本和扩展的整体执行时间他们很小心地添加测试用例到程序中。当评价新功能是否能自动化，成功的团队问自己，“这个果汁值得挤榨吗？”这个测试被自动化更好还是留作手工测试更好？这个自动化太复杂、在我们的一个冲刺里给定的有限的时间里耗费时间编写吗？正在开发的功能做自动化已经饱和了吗？自动化的执行依赖与某些我们无法控制的外部变动的代码块吗？

如果对这些问题的任一个回答是是的话，找其他的去自动化吧。成功的团队会快速删掉不提供价值的测试。他们甚至更快速递删除那些没有明显原因就随机失败的测试。那些测试需要高维护成本。信息展示台的观察者可能视这些停留在失败状态的测试为不成比例的时间量。最终你的机构会成长为不再相信你的自动化测试，然后对其提供的任何价值打折扣。

测试自动化

一个成功的测试自动化，就像软件开发，并不简单。有很多重要的成本涉及到。有很多潜在的错误的转变和错误的开始。要知道每个你编写的有价值的自动化测试用例，
你的团队变得更加解放。更重要的是，不要忘记授权成员做事。允许他们围绕一个视野，提供给他们一个明晰的策略让他们自我组织。给他们自由去探索新的技术，然后决
 定他们想要拥抱的自动化工具。成为决定过程的一部分意味着他们会更多投资在他们自己的成功上。你的团队可能刚刚发现了一个如果隐藏不被发现就会导致上百万损失的缺陷。这种投资回报率怎样？

原文转载自：