不幸的事件组合使团队有了一个对产品一无所知的经理，而我是自动化专家。一位在相对静态的数据输入自动化方面具有丰富经验的新员工和经理相信，自动化框架“太复杂”，以及自动化运行需要太长时间的原因。
如何我是否可以说服他们，尽管框架很复杂，但它是一个健壮，可靠的工具，而他们偏爱的解决方案（由于系统的事务性，具有大量重复功能的标准化记录和回放）正在成为维护的噩梦？ （我维护着这些东西。我知道哪些东西更容易调试和维护。）
这里的任何建议都值得欢迎-我的团队很快就过载了，没有任何缓解的迹象，所以我真的很想避免使情况变得更糟的任何事情。
#1 楼
Bret Pettichord在今年的Selenium会议上的主题演讲中有很多精彩的内容，这些都是直接的。他详细讨论了为什么他对大型商用工具供应商发出的“回放和记录”销售信息感到越来越沮丧。要在YouTube上观看他的演示文稿，请单击此处。跳到9:48。在这里，他开始谈论他和其他领先的测试自动化专家思想家在1990年代中期相互分享的见解。他还讨论了如何将“记录和回放”功能添加到SilkTest的预光标中。在Bret看来，添加记录和回放功能几乎完全是因为这是销售工具的好方法（相对于实际可用的功能）。
在10:40，他讲述了导致他决定创建一个演示文稿的故事，该演示文稿的标题为“ Capture / Replay is for Fools。”
#2 楼
我认为交流和协作将是最好的选择。 GUI自动化非常脆弱，并且当您的AUT不断变化时，需要不断维护。 Record'n Play甚至更糟，将使可维护性成为一场噩梦。自动化也是它自己的开发工作，应该将其包括在任何其他工作的时间估算中。尽管不建议使用录音与演奏，但也许还有其他方法可以构架您的框架，从而允许其他人快速入门。如果开发人员投资于自动化测试，那么该框架势必会得到改进。您还可以尝试在新的框架/环境中管理层建议的内容，以便您现有的框架/环境可以保持不变。试用期可以证明您的观点，或者最终可以很好地发挥作用。
#3 楼
在您的辩护中，如果更改了要测试的应用程序的主要部分，是否需要重新记录并重新调试所有记录的脚本？新的质量检查人员/测试人员几天之内无法进入并开始使用/修改它？像其他任何东西一样，可维护性是关键功能。取决于应用程序和自动化套件的类型，记录和回放是否可以不费吹灰之力使用现有自动化套件的某些复杂功能？ ？
评论
如果更改了主要部分，则可以，所有记录的脚本都需要重做。假设熟悉我们的软件产品（需要3到6个月），我会说可以在几天内使用面向对象的框架创建基本测试。我们正在使用TestComplete，并且一些复杂的功能应该可以作为测试项访问，尽管到目前为止，事实证明，将代码框架和TestComplete关键字测试框架进行混合比发布广告要难得多。
–凯特·保罗克♦
2011年5月12日13:42
#4 楼
首先，您已经与您的经理谈过了吗？如果没有，那么作为自动化专家，以及作为产品新手比新员工有更多经验的人，您的经理可能会信任您，足以选择首选的解决方案。其次，您自己承认，您的框架可能比必要的更为复杂。如果您希望框架与更简单（尽管不那么复杂）的技术竞争，则可能需要找到使更简单的测试更易于创建的方法。如果您还没有这样做，我建议与新员工坐下来，了解为什么难以使用您的框架。员工是否可以使用您的框架？是否有任何文档？最后，在经过一段时间的测试之后，维护成本就会显示出来，这意味着需要花费一些时间来证明这些缺陷在新员工的方法。也许您应该建议您的经理，您的团队在试用期内会同时使用这两种技术，并记录测试的工作以及维护这些技术所需的工作量。试用期过后，您应该拥有一些数据来帮助经理做出明智的决定。
评论
@ user246，团队多年来遇到的最大问题是要执行的测试多于执行时间。试图获得或窃取时间重构和清理框架是一个失败的选择。
–凯特·保罗克♦
2011年5月12日13:47
对于已经存在一段时间的任何软件来说，这都是一个普遍的问题。您没有说经理是只负责质量检查还是负责质量检查和开发人员。如果只是QA，您的经理是否具有管理测试自动化项目的经验？如果不是这样，他们可能不愿意在重构方面投入大量资源。
–user246
2011年5月12日19:55
不幸的是，经理负责这两个工作，并且我不了解与质量检查相关的经验。
–凯特·保罗克♦
2011年5月15日19:22
#5 楼
在许多情况下，即使在我现在的位置上，问题仍然在于，总是有新的开发，新的功能，正在开发的新产品，以便任何测试框架，甚至记录和回放（某种框架）都将要求1）维护，以确保现有的自动化可以继续运行并提供对现有功能的保证，以及2）新的测试开发（甚至记录和回放），以构建新功能所需的新测试。问题总是试图在快速有效地建立新测试功能之间建立平衡（解决方案2），但要确保最容易维护这些新测试功能（解决方案1）。那么，您如何说服经理们？确实，您将需要花费时间和精力来收集使用旧框架和新方法创建新测试所花费时间的度量。这是一个度量标准，不幸的是，这将表明记录和回放将在那里很好地显示。但是，您需要的是其他度量标准，用于衡量维护一套记录和回放测试与维护自由代码单元和数据驱动/表驱动框架所需的时间。当功能更改时，更新该功能的所有这些记录和回放测试需要多长时间，而在功能更改时，修改该功能的框架需要多长时间？
最终，这是经理为做某事而花费的金额与所完成工作的价值的底线。记录和回放自动化以及框架自动化在大多数情况下都具有相同的价值...确保现有产品功能的回归。因此，您最大的“实惠”是衡量和评估支出。
现在，与此同时，不要试图保留现有框架，而是要切实可行。如您所说，现有框架还有改进的空间。他们为记录和回放实现的某些内容也许可以进行修改以改进框架。是否正在创建一些记录和回放测试以供合并到框架中？框架的某些部分是否可以增强以简化维护和使用？管理层不能很好地倾听“这是对的，是错误的，也是不好的”，而没有通过“这是一种更好的方法”来支持它的方法。和知识渊博的论文。我发现真正对我有很大帮助的是这篇文章，它详细描述了什么是框架测试，为什么如此重要，甚至记录和回放的具体问题还有做与不做清单。该文章的末尾还提供了详尽的参考资料集，可以对其进行交叉引用，研究等等。
祝你好运！
评论
仅供参考，我无法获得工作链接。
– Ethel Evans
2011年5月12日18:40
立即尝试...我在URl中遇到了问题。
– TristaanOgre
2011年5月12日18:41
#6 楼
听起来您的经理确实有合理的顾虑，我认为真正的解决方案在两者之间。我认为您需要解决两点：记录和回放
记录和回放本质上是作为自动化工具销售的工具提供的。记录和回放方法将在多个测试用例中创建很多相同的代码。
我根据记录和回放构造业务案例的方式非常简单，我将记录并呈现有关如何与仅使用代码的方法相比，在编写应用程序时需要花费大量时间来重新创建测试用例。
您可以通过快速的并行技术演示直观地说明这一点。 。
框架的复杂性
如果您的经理认为启动和运行自动化所需的时间太长，则可能是正确的。您应该准确确定它们要遵循的结果，并找出可以对框架进行建议的地方，以便可以更快地创建新的测试用例。在我的堆栈（testing-stax.org）中，我们构建了一些生成器来为我们创建很多该代码，从而尽管进行了编码，也使我们可以非常快速地进行操作。
#7 楼
尽管这个问题已经有了很多不错的答案，但我认为时代已经改变了。在大多数情况下，捕获和重放确实是一种维护恐怖，长期来看，组织良好的页面对象结构与手工制作的测试脚本相结合会更容易处理。存在利用机器学习（ML）和其他技术来克服捕获和重放的维护问题的方法。例如，Testim结合了历史数据来分别对每个元素的定位器进行排名，从而使测试随时间稳定。也就是说，ML算法不使用单个手工选择的定位器，而是使用所有定位器并自动“修复”脚本。另一种方法是通过重新测试完成的（免责声明：我是重新测试的软件工程师）。它捕获了被测系统（SUT）的整个（可见）状态，其中a）不需要声明，b）留下大量数据用于组件识别（具有“令人困惑的优势”）。 >不幸的是，我不知道类似的开源解决方案，但是我认为社区为Selenium之类的工具开发它只是时间问题。最重要的是，如今，机器学习和其他技术实际上可以使捕获和重放变得可靠。尽管如此，这是例外而不是规则。因此，我将尝试（单独）捕获和重放工具并比较两种解决方案。如果它是传统的捕获和重放工具，则测试阶段可能会很快表明您的OO解决方案是卓越的，尤其是在维护方面。
#8 楼
如果记录的脚本可以正确播放，则很难说服质量保证经理使用测试自动化框架。很多时候，它们
记录的脚本数量很少
记录的脚本不需要任何自定义更改
应用程序相当稳定
对于管理员来说，记录脚本的时间是最重要的，尤其是在那些脚本不会中断的情况下。测试自动化框架的用处很明显。
我最近和一位提出相同问题的同事进行了讨论。
我在本文中详细介绍了我们的对话。
#9 楼
这是一个古老的问题，但答案在过去2-3年中确实发生了很大变化。古老的录音机是一场灾难。它们存在于硒之前，甚至还有一个硒录音机被扔掉了。硒使记录员摆脱了自己。但是那是15年前。最近2-3年出现了新一代的记录技术。不是开源的，而是来自知名公司的。 testim，Tricentis，Provance，功能化。可能还有一些其他的我忘记了。因此，使用AUT可以快速生成端到端测试。
某些系统具有自我修复功能（至少具有Appvance和testim），可以随着访问者的更改而减少维护。
我们使用Appvance Test Designer测量了与Selenium相比，团队的生产率提高了3倍到10倍（不包括AI测试生成，仅记录器）。我希望其他工具也能看到类似的改进。
由于测试团队必须更快地赶上DevOps的时间表，因此现在是重新审视现代录音技术的好时机，尤其是使用ML自我修复。录音有个坏名字。但是今天由于时间和预算的限制，是时候重新考虑它了。
免责声明我为appvance.ai工作，以上是我自己的经验
评论
布雷特是正确的。
–user246
2011年5月13日在22:58
该答案非常值得50代表赏金……我想出什么更好的答案方法，就是请这样的专家来为记录和回放的设计提供良好，实用的内部了解。谢谢@Justin
– TristaanOgre
2011年5月16日下午14:26
我将该视频标记为该视频的公认答案-我将把视频链接发送给整个团队进行审核。感谢所有回答的人-所有建议都是好的建议，我可能最终会混合使用各种答复来尝试改善我所面临的情况。
–凯特·保罗克♦
2011年5月16日16:14
正如我在其他地方提到的那样，可能有时记录和回放是创建自动化测试的理想方法。但是，如果目标是创建一种可移植，可重用，灵活且可适应不同条件的测试，则记录和回放仅作为研究其他测试的研究工具而受益。
– TristaanOgre
2011年5月18日在15:33
真的很不幸我的梦想之一就是创建一个健壮的记录和回放，它足够聪明，可以以一种智能思考的模式存储所记录的内容，在这种模式下，它不会重复数据，不会重复使用现有的基础架构，并以抽象的方式输出代码可维护的方式我敢肯定它永远不会是100％，但是它可能比大多数记录/播放功能生成的the脚脚本好得多，并且实际上可能有用。
–山姆·伍兹（Sam Woods）
2012年2月16日在16:52