虽然从自己的错误中学习也不错,但从别人的错误中学习总是更好的。
作为一个自动化测试人员,分享常见的容易犯的10个错误,可以从中吸取教训,引以为鉴。
新人小王接到为Web应用程序自动化测试脚本的任务时,既高兴又紧张,因为这是他进入团队的第一个任务。第一印象至关重要,他也希望给团队留下完美的第一印象。小王被要求自动化Web应用程序其中的一个模块,但他想表现得更好、做更多的自动化,于是选择了另外的模块。然而结果是他撞进了死胡同,没有完成。其实小王想做些新尝试并没有错,错在没有咨询前辈就试图自动化该模块。事实证明,这个模块用不着自动化,因为集成的系统可能会导致多重误报。
我在新的自动化测试人员身上看到过很多次这种情况。毕竟,好奇心可以引领前进。当学习自动化测试时,会想尝试在每个项目中引入自动化,但这是不必要的。可能有足够的能力自动化某件事,但这件事是否足够可行?虽然众所周知自动化可以节省时间和精力,但回答以下问题非常重要:“为什么要将此项目自动化?”得到了确切务实的答案后,再为自动化开绿灯。
定义将要执行的测试的范围是非常必要的。作为新手自动化测试人员时,总是试图测试所有的东西,并使每个测试都自动化。问题是尽管可以成功地自动化所有测试,但这既不实用也不可行。
首先,代码中有很多部分并不需要频繁的测试,但可能需要占用大量时间为其开发框架或脚本。比如当测试一个网站时,自动化网站的每个元素并在其上运行脚本是没有用的,这不值得花时间和精力。
其次,自动化所有的东西会增加测试自动化百分比,这会提供书面上很好的数据,让自己觉得完成了一项出色的工作,然而实际上并非如此。
定义测试的范围,只考虑能够及时提供实际价值的自动化测试的可行代码,做出明智选择。
自动化测试人员最常见的另一个错误是没有选择正确的自动化测试工具。一个项目包含许多专注于不同测试目标的组件。这些目标应分为不同的工具,以帮助更有效地实现这一目标。
例如,如果想测试一个网站的API,最好使用Postman;但如果你想确保Web应用程序在不同浏览器间的完美呈现,那么在线Selenium Grid将是自动化跨浏览器测试的最佳选择。
测试团队中有很多人,大家具备不同的技能。例如,有人可能擅长业务测试,而其他人可能擅长功能测试。然而,这不是不与他们讨论任务进展的理由。协调是加速产品交付的关键。了解谁在做什么、使用什么工具、对测试自动化的编程语言是否满意。
这有助于帮助排除自动化测试脚本的故障,万一事情不顺利,就会知道该寻求谁的帮助,了解团队也可以帮助自己在需要的时候进行协调。正如在最后一点中所讨论的,一个项目可能需要不同的工具来实现组合的目标,可以让擅长不同工具的测试人员发挥自己的作用。
仅仅将测试人员的工资作为与整个测试过程相关的成本考虑进去是一个非常新手级的错误。显然,情况并非如此。
例如希望对网站执行跨浏览器测试,测试人员的工资当然是成本的一部分。但如果团队不知道这种类型的测试或与之相关的任何工具,那么还需要通过培训来提升他们的技能,这会产生额外成本。此外,还需要有合适的自动化测试工具或者框架来执行自动化浏览器测试。当然,也可以考虑开源框架。
这只是一个例子。同样,在对Web应用程序执行自动化测试的过程中,您还会遇到其他投资。但是,他们肯定会出现。因此,应仔细考虑测试成本,并牢记您将获得的这些投资回报。如果回报率较低,则需要更改策略并再次计算。但最终,您需要在整个测试过程中获得良好的投资回报率。
虽然无代码自动化测试工具的学习曲线很短,很容易入门,但它们不会帮助构建自动化测试人员配置文件所需的相关技能集。作为初学者,它们很好地帮助新手起步,但随着自身技能的发展,就会意识到它们并不像期望的那样有用。如果决定用无代码自动化工具的智慧参加自动化测试人员的面试,或者一直单独用无代码自动化来自动化复杂的web应用程序,那么将经历一段艰难的时光。
可靠性是这类工具的另一个大问题。在一天结束的时候,需要了解代码,以便调试自己的自动化测试套件执行出错的地方。此外,如果面对一个复杂的网站,那么就不会发现无代码自动化测试工具可以像你想的那样灵活。建议不要逃避代码,而是要熟练地学习它。最重要的是,这将是个人简历上的一大魅力。因此,作为自动化测试人员,请确保避免这种常见的错误。
测试设计是将一般测试目标转换为有形测试用例和条件的过程。作为开发人员,我们倾向于认为既然测试需要编码,为什么开发人员不能完成这项工作?如果是这样的话,那么测试这个岗位也就不存在了。
作为初学者,不理解测试设计的重要性可能是作为自动化测试人员最大的错误。任何时候测试任何东西都是荒谬的想法。为了有效地进行测试,测试人员需要设计测试,然后对其进行编码。设计测试有助于创建有意义的测试,并使整个测试过程非常高效。
测试用例对它所应用的代码并不是唯一的。在一个项目中,会出现许多类似的组件,它们需要类似的测试设计和测试套件。比如,在使用Selenium进行跨浏览器测试时,我们发现Web页面的四个元素都是输入字段,并且需要类似的测试用例。在这里,可以通过仅为第一个元素编写测试来复制粘贴代码。虽然这将给出预期的结果,但问题是将来开发人员可能会以某种方式更改元素。现在,要更改测试用例,就需要更改所编写的每个测试套件中的代码。所有的时间都将浪费在寻找和修改这些测试代码上。
为了避免这种情况,应该始终关注代码的可重用性。与其一次又一次地粘贴代码,不如用适当的参数构造一个函数,并在每个元素上调用该函数。这样,如果将来有任何更改,只需要修改函数,就可以开始了。
跟计算机领域经典的“人月神话”一样,这里的“神话”同样指不可能达到的天方夜谭。
不要相信这种神话,因为作为一个自动化测试人员,这将是一个严重的错误。作为自动化测试领域的新手,对于将自动化引入到项目中都会很兴奋。但这会让人犯错误,认为自动化测试可以完全取代手动测试过程。随着时间的推移,我们将知道这是不可能的。百分之百用自动化测试取代手动测试是一个神话,它永远不可能实现。
作为这方面的初学者,不要试图实现这样的目标。又回到第一条,只有在必要时才进行自动化,并且只对那些需要自动化的项目进行自动化。
在测试时,会遇到不同类型的问题。需要设定目标并对这些问题进行分类。一种基础方法是用较小的模块而不是大模块开始自动化测试。
作为自动化测试人员,最大的错误之一是开始自动化时使用更大、更复杂的模块。可能缺乏对每个用户交互中涉及的入站和出站流程的认识;甚至可能缺乏处理棘手的测试用例的熟练程度;可能最终会浪费大量的时间,但却一无所获。所以从小处开始,从基础的方法中增加自动化测试的覆盖率。
第一次踏入自动化测试领域,难免犯一些错误,这些错误会造成时间、金钱、精力的浪费。希望这篇文章能对自动化测试新人有所帮助,帮大家避免踩这些不必要的坑。