为此，我们已经开始从这些第三方购买用于回归软件包的测试脚本。我有一定的编程经验，我担心购买脚本将使我们无法获得以下知识：a）有效评估这些脚本的知识，以及b）充分利用自动化的好处。
通过自动化的全部好处，我的意思是具有以下能力：当场了解某个流程是否是自动化的潜在候选者，自动化与手动执行之间需要多长时间，如何有效地重用现有功能库（测试合作伙伴和（为他们工作的个人定期更换）等。这种知识可以使我们超越为长期维护目的而简单地使回归包自动化的方法，而转向更复杂的自动化方法。
但是，由于组织内部不存在这种能力目前，创建和维护所需的技能基础会产生成本。
作为新来测试的人，我想知道-我的担忧是否合理，还是与购买相关的成本节省？测试脚本是否足以证明缺乏内部专业知识？
#1 楼
为此，您将获得很多“取决于”答案。最好还是主要保留第三方自动化，这将取决于第三方自动化提供商的质量，业务应用程序的性质，内部基础结构，第三方使用的方法以及更多其他条件而改变。要考虑的一些因素是：
您的企业是构建小型，独立的应用程序还是维护大型，复杂的应用程序套件，从而获得新增功能了吗？在前一种情况下，第三方可能是更好的选择，在这种情况下，需要大量领域知识的不断变化的复杂应用是内部开发和维护的自动化的更好选择。
什么是自动化/编码您的内部测试团队的技能基础？如果您有许多具有良好的形式逻辑技能和良好的编程知识的测试人员，则您有足够的能力来构建良好的，可维护的内部自动化。如果您的测试团队基本上是手工的，而没有形式逻辑的限制，那么这样做会变得更加困难，并且您可能会受到测试团队的抵制。
您是什么人组织的预算重点？通常，第三方自动化解决方案将使现有的手动测试用例自动化，这可以使用第三方预先存在的结构和框架相当快地完成。从头开始构建自己的（因为第三方自动化中可能有很多专有代码）在资源，时间和金钱方面非常昂贵。第三方自动化可能会使用超出预算的工具，从而使您无法重用其材料。
您的组织的长期计划是什么？您的测试策略-包括自动化的方法和方法-需要支持组织的长期目标。与构建自己的自动化系统相比，使用第三方构建和维护自动化系统可能更符合长期目标。
构建自己的自动化系统的一些优势包括：
自动化是由具有专业知识的人员构建的。
如果操作正确，则向现有自动化中添加新测试要容易得多。
您的组织保留对自动化的完全控制。 >您的团队更加熟悉自动化，可以更轻松地确保任何测试失败都是软件的真正问题。
其中一些缺点是：
建立稳定，可靠的自动化套件可能要花费很长时间。
根据所需的应用技术，自动化工具可能非常昂贵。
您需要测试人员，他们至少可以编写代码中级开发人员级别。理想情况下，您需要能够担任软件开发人员的测试角色的人，但这些人并非一帆风顺（良好的测试技能和良好的编码技能的结合并不普遍）。
您将需要说服管理层的需求，然后让他们确信。
从管理的角度来看，与某人签定建造自动化的合同更为容易，尤其是当事情已经完成并且第三方对建筑自动化有经验时。它可能也更便宜。
很难量化内部自动化转移带来的潜在成本节省，尤其是当管理人员唯一可能看到的是增加的费用时。
#2 楼
这很大程度上取决于您是否将从第三方测试人员和测试脚本中获得良好的投资回报。如果最终结果是一个好的回归套件，并且能够以合理的价格改变输入和条件，则没有必要将内部自动化完全投入使用。即使第三方测试脚本提供了良好的投资回报可能会受到限制。如果测试脚本损坏，则必须等待第三方对其进行修复，如果要更改生产的软件的行为，则必须将这些更改传达给第三方，这可能是一个挑战。您提到的问题是：可以自动化的每个测试是否实际上是自动化的？我们知道什么值得自动化，什么不自动化？自动化测试是否设计合理并有效利用了现有库？这些是您可以控制测试自动化可以解决的问题和局限性。
您提到“企业中几乎没有测试自动化的历史”，而您只是“开始”购买测试脚本”，听起来好像您是从头开始的，并且以前没有自动测试设置。对我来说，这是在内部进行测试自动化的最佳时机。我的建议是花些时间并建立自己的测试自动化脚本，同时仍要使用第三方脚本，一旦您自己的脚本足够好，您就可以结束第三方脚本的订购。
#3 楼
所有出色的答案。我会再想一想。几年前，我负责一个在中国的团队，该团队对IBM Tivoli部门的产品进行了许多软件国际化测试。这些产品非常庞大且复杂，并且由于团队实际上必须或多或少地行使每个菜单选项并验证显示的结果是否合理，因此这些测试相当于相当广泛的系统测试。无论如何，该团队有很多非常聪明的工程师，他们进行了许多自动化实验。他们的结论是，最佳的投资回报率不是来自尝试自动化测试本身（复杂的交互，不断变化的功能，上述所有问题），而是在于自动化测试实验室的设置。也就是说，当他们查看努力的方向时，设置测试环境（空白的硬盘，重新安装OS等……可能要安装100台机器）是一项非常令人惊讶的工作，并且对于自动化来说相当容易。他们继续进行，并做到了这一点，自动化了许多繁琐的工作，只是手动进行了测试。
当然，结果非常特定于他们所使用的产品类型和测试类型在做。但是，在您首先涉足自动化领域（尤其是购买外部产品和服务）之前，您可能需要先进行一些仔细的时间和精力跟踪，以了解真正消耗掉了什么时间。您可能会感到惊讶。
评论
有趣的答案。没错，仔细分析在整个过程中实际投入的时间/精力可以为自动化提供其他目标。再者，技能基础是一个问题-您需要“聪明的工程师”，他们需要根据自己的声音自动化技能来分析总体目标，然后能够将这些知识指导用于创建较不常规的解决方案。
–user3100456
2014年4月30日在18:16
如果可以的话，omg +1 +1000。这是我最后一个雇主工作18个月以来的真正问题。 “抱歉，我有配置问题”一词变得令人恐惧，但经常听到。最后，我开始编写许多Shell脚本来自动化构建和设置过程。在当前需要启动多个存储库和服务的多服务体系结构的趋势中，这有很大的不同
–迈克尔·杜兰特（Michael Durrant）
15年6月18日在10:29
#4 楼
荒地和凯特·保尔克都给出了很好的答案。我只想补充一下，对于像贵公司这样的复杂应用程序/体系结构，内部测试自动化具有很多好处，而这些好处是您无法从现成的测试脚本中获得的。以我的经验，就是当我坐下来思考“如何测试（或自动化）此功能（或测试）？”时，我发现了体系结构问题，甚至是彻底的错误。换句话说，有时不仅重要的测试，而且还包括如何准确，可重复和有效地测试某些事物的分析。当您将其外包时，您不会被迫进行相同的分析，即“为什么该测试会永远花费大量资源并使用大量资源？”除此之外，一个合适的选择-所有测试脚本/套件只能深入其中。它无法满足那些充满了反模式，非固态，非DRY垃圾的可怕的旧代码，但是您的组织“还没有解决”，因为这需要等待20,000行噩梦发生。另一方面，一旦您和您的团队充分了解它以进行全面测试并自动化您的测试，您就会充分了解它以进行快速重构（准确地说，这要归功于随着代码的逐步改进而进行的自动测试）。 />
简而言之，开发内部测试和自动化技能基础将带来巨大的收益，并使您能够更快地改善应用程序和体系结构。
评论
谢谢，这确实弄清了利弊。实际上，该业务的寿命很长，并且具有您所描述的庞大，复杂的混合体系结构（具有许多自定义应用程序接口），并且该业务已经发展了很长时间。没有计划改变这一点。但是，对于开发编程能力（我们目前缺乏）所涉及的成本的需求可能难以建立。我认为这里的两个答案都为进一步研究提供了良好的基础，所以谢谢。
–user3100456
2014年4月26日上午8:31
@ user3100456-我很明白。在我最后的职位上，核心应用程序已经发展了25年（仍然有一些原始代码）。自动化已经存在了十年，并且已经足够成熟，可以很容易地添加新测试。客户报告的大多数错误都是极端情况或自动化方面的缺陷，但要让管理人员投入自动化工作仍是一个长期的难题。
–凯特·保罗（Kate Paulk）
2014年4月30日在10:58