自动化测试项目为何失败

自动化的端到端测试旨在替代手动测试人员部分工作，通过前端以及后端API的程序化测试和性能测试以自动化方式执行的内容。并非手动测试所做的一切都可以自动化，手动测试存在的重要原因。例如，很难自动化UX和可用性测试的各个方面，但是大多数重复的测试都可以自动化。根据我的经验，大多数测试可以自动化，包括与复杂功能相关的测试，但是自动化成本就差异万千。

自动化的好处很多，比如：自动化测试可以节省时间，并可以完成更多的测试。候选发布之间的时间间隔可以短于可行地全面手动测试构建所需的时间。希望实现自动化的原因是可以理解的，但是看到实施和维护此类项目的尝试未能兑现最初的愿景的情况很常见。

前文Web端自动化测试失败原因汇总， 下面列举一些导致自动化实施失败的原因。

错误的人来工作

自动化测试主要是是大量的程序和脚本。测试自动化涉及编写软件，这需要具有一定开发技能的软件测试人员，参与开发自动化测试不是软件开发人员的场合。

有一些管理者有这样一个观点：优秀的手动测试工程师只要稍加培训，比如测试工具，测试脚本一类，可以很顺利晋升为自动化测试工程师。并且他们以此为行动准则，带来的影响可能是灾难性的。

发生这种情况的另一个原因是：他们相信可以通过简单的测试工具、开源软件或使用机器学习来生成自动测试用例。到目前为止，其效果仅限于各类Demo和简单的测试用例。要拥有完善的测试套件，需要手写代码，您需要足够开发技能。

缺乏代码质量观念

自动化测试会测量正确性和软件质量，为此，测试代码本身也应该是高质量，可维护和可扩展的，以确保持久有效。

通常大多数情况并非如此。原因之一是由于上述工作问题的人员没有对自身代码质量有很清楚的认识。计算机科学以及特定算法和数据结构的坚实基础，以及丰富的经验可以帮助软件开发人员意识到确保所编写的软件满足这些要求的重要性。

质量可能很低的另一个原因是由于缺乏时间，或在没有意识到自动测试前期将会花费更多时间和资源。这是一个管理问题。应将足够的时间纳入工作计划中。

未认识到自动化是长期项目

自动化的端到端测试将需要对其进行测试的产品或服务进行更新和维护。如果被测试的应用程序是公司销售的产品或对支持和使业务运行至关重要的服务，则这可能意味着自动化将伴随公司的整个生命周期。

但是有时会招募短期承包商来实现自动化。他们离开时会发生什么？谁将维护测试，谁将在端点更改时更新测试，或者在每次重新设计UI或更改流程或添加新功能时就UI测试进行更新。可以将其视为一个长期项目，它将与被测产品并存。

误解自动化构成

如果团队是由具有技术背景的人领导的，则希望此规则不适用。有时领导层不熟悉自动化测试开发所涉及的内容。他们知道构建软件产品需要一组软件开发人员，测试，设计等人员，但是对于开发自动化的含义存在误解。

明确说明自动化测试是软件，应将其视为软件开发项目，这不是可以立即使用的东西。测试的开发应尽早开始，并与功能和产品开发并行进行。突然提供自动化测试是不正确的，这是对所涉及内容的根本误解。

太快地放弃可以自动化的东西

所有这一切都可以自动化，只不过有的容易有的困难，有的超出了自己的能力范围。但请不要太快放弃，不要屈服于无法自动化或不值得“自动化”的观念。

有时，以正确的态度实现自动化可能比实施自动化要简单得多。只要它是某种程序性任务，就可以自动化。通过确保将这些案例自动化，自动化测试程序所带来的价值将大大增加。

测试范围有限

成功的自动化测试项目包括几个部分。有测试执行者和程序执行者，有时也称为测试工具，这常常是自动化测试项目范围的限制。尽管测试工具是测试自动化项目的核心，但如果仅此而已，自动化测试的投资回报率的有效性就会受到限制。

一些测试作业应与构建系统和持续集成系统集成。端到端测试通常是长期运行的，因此在每次提交或在大型团队中构建它们都可能并不总是可行的，但是应将它们设置为按计划运行，例如每天进行一次。临时运行的功能始终很有用，但是在此之上的计划工作可确保测试正常运行而无需干预。

在开发测试工具时，通常会在开发机器上运行测试。否则，在运行时请考虑添加工具以辅助此操作。对于在Web和移动设备上进行的前端测试，您可能需要一个设备矩阵，或者是您的团队自行构建的本地设备储备，或者是基于云真机。对于后端API测试，尤其是性能测试，可以将测试工具部署在不同区域的云实例中。

缺乏可见性，可追踪性和报告

一旦自动测试按常规时间表运行，或者由事件触发甚至临时运行，测试结果和相关输出数据就会开始生成。应该考虑如何收集，报告和分析这些数据。如果数据难以访问，例如，需要检查远程服务器上的日志，或者缺乏测试结果和测试数据的可见性，那么就不可能有效地了解自动化测试的状况。

如果不及时纠正，此错误可能会危害整个自动化项目，因为如果不报告捕获的质量测量结果，自动化测试也可能不存在。正确完成后，出色的报告不仅可以作为结果的枢纽，还可以查看测试用例的详细信息，查看它们的运行频率，查看失败的原因，然后处理测试的结果以分配失败的测试用例并链接错误以采取措施。

• 郑重声明：文章首发于公众号“FunTester”，禁止第三方（腾讯云除外）转载、发表。