Web应用自动化失败缘由汇总

时间 2019-11-06

标签 web 应用自动化失败缘由汇总栏目 HTML 繁體版

原文原文链接

多位从业多年的测试工程师经验汇总，提及来都是一部血泪史。前端

不切实际的指望– 100％自动化

最初的测试自动化失败是从不切实际的指望中得到的。在个人职业生涯中，我已经屡次观察到它，一旦您得到了自动化的质量保证或工做人员，管理层就指望他们对全部内容进行自动化测试。尽管听起来很使人愉悦，但这是不可能的。您不能进行100％的自动化测试，由于在少数几个领域必须进行人工检查。这些领域之一可能与您的Web应用程序的可访问性有关。面试

例如，若是您正在执行自动跨浏览器测试，则用于Selenium测试的自动化脚本将在不一样的浏览器或操做系统上呈现网页的显示。可是，要肯定网站是否按照设计进行渲染，版式是否合适，文字是否合适，最好手动评估数据库

自动化什么以及自动化多少？

许多组织确实意识到指望进行100％自动化测试的问题陈述，但一般会遇到如下问题。咱们能够实现什么自动化，若是不是100％，那么咱们能够为Web产品实际实现多少自动化？编程

没有适用于每一个企业的自动化测试覆盖率的完美百分比或近似值。这彻底取决于您所提供的Web应用程序，而且因为不一样的企业正在知足不一样的需求。天然而然地，人们会对围绕自动化测试实际能实现的自动化测试百分比抱有独特的指望？自动化测试的范围将从电子商务Web应用程序到静态，动态或动画Web应用程序有所不一样。所以，若是您想知道为何自动化测试对您的组织失败？而后，我建议您根据所提供的Web应用程序的类型来评估所需的自动化测试量。后端

管理不当致使测试自动化缺少可见性

在我做为自动化测试员开始IT生涯时，我就一直是管理不当的受害者。我当时在一家基于Service的公司工做，他们为我分配了个人第一个项目。这个项目已经运行了两年，当我加入后，我被交给了一系列测试自动化脚本。项目的高层将要离开组织，管理层对即将到来的冲刺太忙了，没法考虑将要离开的高级自动化测试人员进行的全面知识转移课程。他们离开后发生的景象不佳？个人经理在听证会的结尾说，咱们因停电而大吃一惊，而我刚起步，对各类出站和入站流程如何受到众多自动化脚本的影响的了解最少。然而，我见过一些由少数成员负责实现自动化的团队，而其余成员则对正在发生的事情一无所知。浏览器

您是否定为当一半的团队缺少可见性时，从自动化测试中得到魔术效果是不现实的吗？因为自动化必须是一个协做的工做，所以对每一个团队成员进行相关工具和流程的教育很是重要，尤为是对新手而言。您能够经过举行团队会议和会议来讨论与自动化有关的工具，趋势和实践，从而实现这一目标。缓存

对手动测试或探索性测试不了解

这可能会让您有些惊讶，测试自动化失败的另外一个缘由多是缺乏手动测试技能或探索性测试技能。自动化测试脚本并不意味着团队成员能够减小一些懈怠。到目前为止，咱们已经知道，自动化方法不能涵盖全部内容，而这正是挑战所在。由于如今您必须更深刻地研究Web应用程序，并找到队友还没有发现的关键测试方案。网络

自动化是节省测试工做的一种方式。软件公司应该使用它来最大程度地减小重复，并仅使那些不易更改的元素自动化。一旦完成，公司应该分配他们的资源来执行普遍的手动测试或探索性测试，以找到独特的测试用例。并发

不仔细考虑并编写脚本

自动化彷佛是减小工做量的一站式目标。可是在开发测试自动化脚本以前，必须考虑周全。此外，这可能会花费大量的自动化测试执行时间。框架和测试自动化工具的灵活性在开发脚本场景所需的时间中起着相当重要的做用。框架

因为每种状况都不一样，所以必须编写脚本。即便您仔细考虑，若是不编写脚本脚本，这都是浪费。确保测试工程师的编码技能与测试的复杂性保持一致。复杂的测试须要大量时间才能实现自动化。所以，随着全新功能的发展，他们一般没有机会发现回归错误。在写下测试方案以前，请确保牢记这些注意事项。

对什么时候使用自动化以及什么时候不使用自动化缺少理解！

“ 为何测试自动化对您的公司失败？ ”背后的最多见缘由？”是人们不知道何时应该自动化，何时不知道。例如，能够自动化不一样的网页功能。可是经过测试自动化评估填充，图像等渲染问题不是一个好主意。若是使用坐标来肯定元素位置，则在以不一样的屏幕分辨率和大小运行时，可能会致使差别。

在测试易于进行大量更改的项目时，使用自动化是不可行的。若是您要测试稳定的实体，那么自动化是必经之路。基本上，须要重复执行某些操做的普通任务最适合自动化测试。所以，测试自动化能够简化您的回归测试过程。

人员和资源计划选择不当

我看到IT行业广泛存在错误观念。人们认为任何开发人员或测试人员均可以执行测试自动化。测试自动化的设计，配置和实施须要特定的技能。执行自动化的测试人员应该知道如何在经理，开发人员和客户之间阐明想法。他/她还应该对开发趋势有清晰的了解，而且应该知道开发团队要去的方向。

自动化测试工程师是最困难但重要的一些人。为了启动各类自动化项目，聘请具备普遍技术知识的测试人员相当重要。整个团队应该知道发生了什么，而不是由一个或几我的进行自动化测试。即便在雇用技术精湛的员工方面投入很高，但回报仍是值得的。

没有足够注意测试报告

因为自动化测试是一个相对较新的现象，所以失败的可能性很高。测试团队进行的新实验太多，所以准确分析结果变得很重要。进行测试后，测试人员必须作出详尽的测试报告。可是，这就是测试自动化对您而言失败的缘由！您的团队没有对测试报告分析给予足够的重视。若是执行不当，分析可能会致使无人看管的故障，并浪费时间，资源和精力。

在自动测试中，有些测试成功，有些失败。所以，必须检查测试报告是否有故障并分析某些测试失败的缘由。最好手动进行分析，以发现真正的故障。揭露隐藏的问题并确保它们不会被其余问题掩盖而被忽略是相当重要的。

自下而上的方法来定义您的自动化目标

设置过高而不能成为自动化的真正目标，在纸面上彷佛很完美。可是，在执行步骤时，团队成员之间严重缺少清晰度。最大的问题是目标不明确。他们缺少从自动化中得到真正价值的准确性和准确性。大多数公司所作的是，他们开始将很是复杂的事情自动化，并最终重构整个框架。结果，团队最终会浪费大量时间，金钱和精力。

您能够经过从小处着手并逐步提升复杂性来消除不肯定性。选择稳定的功能，并从其自动化开始。以后，收集反馈以肯定出了什么问题。一旦您的测试达到一致性，就能够继续使用其余功能。对于不一样的项目环境，需求可能会有所不一样，所以请使用自定义方法进行测试自动化。

选择合适的工具进行高效有效的测试

在拥有大量自动化工具的状况下，有时候选择最佳工具变得充满挑战。最终目标是改善总体测试程序并知足实际要求。可是大多数团队都没法从头再来，也没有挑选出最适合其测试需求的工具。毫无疑问，自动化测试高度依赖于您决定继续使用的工具。每一个工具都有特定的功能。可是，团队缺少充分利用这些功能所需的专业知识水平。

此外，公司陷入了对特定工具的炒做。可是在选择它以后，他们意识到它并无提供他们但愿得到的一切。另外，每一个团队都有预算，有时该工具的成本超出了预算。在继续选择炒做工具以前，请仔细列出要求。以后，肯定您对该工具的指望。在设定目标时要很是具体，并检查与产品用户接受标准的对应关系。您也能够咨询有使用这些工具经验的专家。

忽略假阴性和假阳性

几乎每一个组织都常常观察到这一点。一旦自动化测试套件准备就绪而且工做正常，管理就开始放松。他们开始放宽对测试执行的深刻分析，由于他们认为只有经过/失败检查才足够。可是，这就是测试自动化对他们失败的缘由！

有时，系统从根本上能够正常运行。可是，自动化脚本不能反映出相同的状况。他们以其余方式陈述并致使假阳性方案。所以，这形成了混乱的局面，浪费了时间，精力和资源。我已经看到测试团队试图找到不存在的东西是多么使人沮丧！

另外一种状况是，自动化脚本发出绿色信号时，出现了问题。系统没法正常运行，但脚本另有声明。网络问题可能会致使测试环境设置出现差别。这是因为数据库开始阶段缺少准确性而致使的。从长远来看，让系统处于受损状态可能会致使灾难性后果。

具备未定义ID的Web元素

每一个Web元素都必须有一个ID才能执行有效的测试。可是有时，开发人员没法将ID分配给全部Web元素，这就是测试自动化失败的缘由。在这种状况下，自动脚本必须查找这些Web元素，这会花费大量时间。此外，若是脚本没法在规定的时间内找到这些元素，则测试将失败。所以，为了确保脚本的正确同步，团队必须为全部Web元素分配惟一的ID。

不利用并行执行

所以，您最终使全部想要自动化的东西都自动化了。您最终得到了庞大的测试套件，直到如今，您才开始碰壁。这些复杂的测试套件执行时间比您预期的要长。这开始与您各自的IDE测试自动化框架中的测试队列质量相抵触。结果，因为队列超时问题，测试用例忽然中止，这都是由于您要按顺序执行它们。测试用例的顺序执行是Web应用程序测试自动化失败的另外一个缘由。

与顺序运行测试不一样，并行执行使您能够在不一样的环境中同时执行多个测试。可是自动化测试可能会致使意外的代码交互。调试失败缘由很是困难，所以您须要透彻的报告机制，提供有关测试执行的详细看法。

经过测试自动化对ROI的错误估计

不管您在线经营什么业务，ROI都将成为每次董事会会议的议程。股东要求更高的回报。并且，不管您准备测试自动化套件花费了多少时间和精力，若是它们产生的ROI均达不到预期，那么它们的重要性将比您预期的要轻得多。

在计算测试自动化的投资回报率时，可能须要考虑许多指标，例如测试维护，购买必要的测试自动化工具所涉及的成本，板载资源等等。计划不切实际的ROI对于许多组织而言多是成问题的，而且多是测试自动化失败的缘由。

没法评估涟漪效应

许多组织给人以自动化测试容易的印象。您所须要作的只是编写几行代码以自动化您的Web应用程序的测试工做流程。就是这样！您彻底没必要担忧测试自动化脚本的计划和输入。但这不是！

您须要评估波纹效应。您的Web应用程序将包含许多旨在测试不一样模块和流程的测试自动化脚本。若是一个测试脚本没法正确执行，则其余脚本也可能触发测试自动化失败。不只如此，在计划资源时还应该计算出连锁反应。

假设您有一个高级资源，他曾经写过脚本，如今已经离开了公司。您可能没有想到辞职可能会在自动化项目的将来时间表中产生连锁反应。这就是为何须要记录有关系统中每一个自动化测试脚本的每一个细节的缘由。该文档应做为萌芽的自动化测试人员以及经验丰富的自动化测试人员的标准。

测试套件不是一成不变的东西–它应该随着平台的发展而发展/变化/不适应的测试套件

测试自动化对您的组织失败的另外一个缘由多是不合适的测试套件。许多自动化测试人员会建立静态测试套件，这些套件在您扩展业务时并不那么灵活。每当平台发展时，它们最终都会从新编写整个自动化测试脚本。这是一个坏习惯，由于您在浪费时间，资源带宽和金钱。另外，这是一个错误的过程。确保您编写随平台扩展而发展和适应的测试套件。

自动化一个过程并跳到另外一个过程而无需回头

避免测试自动化失败的另外一种方法是即兴测试套件。如今，这听起来彷佛很明显，可是在许多组织中却没有实践。缘由是，一旦他们设计了测试套件，并发现它能够正常工做，便开始着手自动化新领域。我没有批评沉迷或探索新领域以实现自动化的努力。可是，管理一个时间窗口并让您和您的团队回顾现有的代码段，以找出进一步优化它的方法并无什么坏处。始终尝试使用您的测试套件，以使事情变得更好。

没法合做

随着敏捷软件，看板软件等现代SDLC（软件开发生命周期）方法在全球范围内的采用，协做已成为将Web应用程序更快部署到市场中的关键组成部分。

这是一个多维软件开发过程，全部团队都在同时开发Web应用程序。您有一组开发人员设计前端，另外一个负责后端，还有一个负责中间件活动的团队。做为测试人员，您须要了解哪一个团队负责哪一个模块。您必须及时了解不一样团队所作的产品加强功能，并对自动化脚本进行相关更改，以确保测试自动化不会失败。

执行每一个测试自动化套件以前，手动设置测试环境

自动化测试的主要目的是最大程度地减小重复手动测试所涉及的压力，以节省时间。从抽象的角度看，这听起来不错，但对于那些执行测试自动化的人来讲，要意识到为执行内部测试自动化而配置正确的基础结构的艰辛。我常常观察到测试人员在执行新脚本以前会刷新整个测试自动化套件，以免与脚本产生任何歧义。但这不能使自动化测试的整个过程都失败，不是吗？

例如，若是您正在使用内部Selenium Grid执行自动跨浏览器测试，以测试适用于Google Chrome和Safari浏览器的macOS和Windows操做系统的网站。如今，您可能每次都要运行Selenium脚本以前就不得不面对设置新操做系统的麻烦。

在静态测试环境中重复运行多个测试套件，而无需进行清理

这是组织自动化测试失败的很是广泛的缘由。特别是在临近最后期限时。您的测试部门将继续在同一测试环境上运行大量测试套件，而不会清除先前执行的测试自动化脚本的缓存。这可能会致使错误的测试评估，当您遇到更多的假阴性和假阳性时，您的测试报告可能会受到影响。

例如，假设您须要针对不一样的地理位置测试您的Web应用程序。在静态测试环境中执行地理位置定位时。您的脚本可能会遭到Google的测试，要求您证实本身不是机器人。这将致使测试自动化脚本失败。

这就是须要使用清除的缓存的新虚拟机的缘由，所以您能够得到自动化跨浏览器测试脚本的准确结果。

测试环境自己很麻烦

为了使自动化可以在不一样的测试环境中工做，须要进行大量的计划。您须要在暂存环境上进行测试，以确保将代码移入生产管道时，它们能够完美地工做。可是，常常会发生这样的状况：在舞台环境中进行测试时，用于代码更改的测试自动化脚本能够无缝运行，可是当移至生产环境时，它就会崩溃。此类问题背后可能有许多缘由，例如缺少持续的监控，登台环境没法使生产环境成对增加，缺乏实时流量等等。

测试代码自己有错误

最后但并不是最不重要的。若是到目前为止咱们已经讲完全部要点，而且您的测试自动化仍然失败，那么您惟一须要反思的地方就是您本身的测试自动化脚本。确保您没有为整个项目中涉及的任何测试脚本提交任何编译时以及运行时错误。

总结一下

若是您的组织须要提升生产力，那么自动化测试就是必经之路。这是提升最终产品质量所需的最有效的过程之一。测试自动化还提升了软件的健壮性。可是要谨慎执行和拖延。您不能在没有障碍的状况下匆匆忙忙，由于没有一家公司能够承受损失巨额资金的麻烦。另外一方面，过多的恐惧会阻止您得到自动化测试所提供的显着优点。