深入研究可持续性的测试自动化

发表于:2019-7-18 10:09

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Alice 译    来源:51Testing软件测试网原创

  概述:当说到实现可持续的测试自动化时,拥有一个合适、恰当的测试自动化团队结构是应当采取的最重要的首要步骤。这篇文章有一些已经证实的适合一些不同的测试自动化场景的惯例--由自动化团队领导或回归测试团队带领,加上敏捷的适应性--已经帮助很多机构享受到了长期的测试自动化成功的成果。
  启动新型测试自动化措施的公司--任何参与其中售卖给他们相关的工具的销售人员---倾向于认为他们的成功依赖于一次毫无瑕疵的发布。作为一名测试自动化顾问,我想提供一个基于在这个领域里看到的真实检查。初期的发布可能是一条崎岖的道路如果你没做准备的话,但是长期来看,那并不是将要促成或打破你的测试自动化的发布的第一步。
  我最近目睹了几个开始不用或用很少准备在公司内部推动测试自动化的几个公司。采用这种“策略”的风险是测试人员可能基于以下原因抵制测试自动化:
  他们感到没有自动化也挺好
  他们不想或没有时间去学习新的工具
  他们担心自动化太复杂,去追赶所花的时间和精力会超出预期的收益
  很差劲的计划或者不做计划的推动显然不是启动测试自动化准备工作第一步的最好的方式。但是,我已经发现从困难重重的现有推动中复原比从不做恰当、合适的测试自动化团队结构来获取可持续的测试自动化总是更容易。
  我这里分享些适用于好多不同的测试自动化采用场景很好用的做法,它们已经帮助很多机构享有长期的成功---甚至当初始推动并不理想。
  自动化团队以项目为单位推出测试自动化
  我能给出的最好的建议是从小事开始做起,然后再大做事。被证实好用的首个做法是从组建一个自动化团队开始。
  这个队伍将在不同的项目上迭代,并从最重要的测试用例开始自动化。这让你能展示项目的进展,并给你一些程序变更如何影响关键的程序功能上有价值的见解。
  我推荐从最有影响力的测试用例开始:那些覆盖了头条商业风险的用例。这为创建一个强大的回归模型创造了基础,好让其提供快速的对程序变更时候破坏了之前正常运行的功能的反馈。
  自动化团队应当包括至少一名测试设计专家,做评审需求工作,和使用测试用例设计方法来选出应当进行自动化的测试用例。然后,测试设计专家或其中两三个自动化专家可以评估是否需要测试数据管理,然后他们可以合作来共同定义测试用例。同时,测试设计专家将着手下个项目。
  取决于你希望测试的软件和希望多大程度的个性化,可能会需要一个自动化工程师。他们会确保个性化控制的创建以及后续的维护。
  队伍的大小将随着时间推移而增加,取决于此队伍必须处理的项目和其中的测试用例个数的多少。这些建议只适用于起步阶段的启动。一旦项目推动开始启动,你会希望尽快招募更多的人加入队伍。
  当测试用例自动化后,他们可以在夜间运行在测试虚拟机器上,接着以天为基础汇报执行结果。将自动化测试程序启动和运行最重要的事就是实际去跑测试用例。如果你没在跑测试用例,你就不会从他们那儿接收到任何有价值的东西,不管你的测试集准备设计得多好,也不管它们如何充分地覆盖了首要的商业风险。
  取决于你公司的结构(敏捷与否,有测试队伍还是独立的测试人员),自动化队伍或许要带头教会每个人怎样应用自动化最佳做法以及当他们开始自己的测试自动化时应当考虑的项目变量。
  在测试人员开始运用测试自动化之前,必须做个决定:谁为这些测试用例负责任?这很关键。如果自动化团队或者也许是后期的回归团队来负责,那么他们必须与测试人员和业务方的增多沟通。如果是测试人员的责任,他们需要时间确保所有的测试用例正在运行并且符合业务预期结果。每个机构需要决定什么是最好的,取决于他们的结构和工作风格。
  不管你选哪个方向,一定保存足够的沟通时间。一方面,新的测试用例需要由回归团队评审然后启动来执行。另一方面,回归测试结果尤其是失败的测试用例需要分享出去以便负责的团队成员或测试人员可以评审他们并依据需要进行更新。至少,确保测试人员独立检查回归测试结果,并做出合适的调整这样回归团队能够推送从共享文件夹推送新的测试用例然后独自评审这些用例。
  每个项目的回归团队领导和带教测试人员
  我见到的最有效率的启动方法是建立一个初期自动化团队,将回归测试团队引入进来,当测试自动基础建立好以后其他人就准备好去向前执行即可。
  此回归团队仍然对在项目初期创建测试用例负责,维护已有测试用例,跑测试用例,护卫测试基础设施和忽略更广的测试自动化准备活动和项目负责。你可以称这样的团队是出色测试中心。
  有这样的准备工作,就有可能让项目和大的变更通过严格的测试设计专家的评审,他们将着手用正确的格式和提供一个项目应当看起来是什么样子的轮廓。他们像软件架构师或者在我们这里是测试架构师。
  这个回归测试团队即为“吸纳组”如果你有相关问题或者你想驱动新的创新的话。所有权和责任应当是回归测试团队因为他们对整个测试模式有最好的概览。
  从资源的角度来看,你需要回归测试团队里有高级技能人员,但是你也可以不让不太有经验的成员去做测试。如果测试人员需要比培训所能提供的知识更多的知识时,他们总可以询问回归测试团队,他们可以分享他们已经构建起来的知识技能来帮助他们。
  适应敏捷环境
  对于敏捷环境来说,测试自动化是在团队内由敏捷测试人员所驱动的。这个人应当比自动化专家还要技能高级--他们需要理解测试用例设计,需求,测试用例创建和执行及核心测试最佳惯例,并且他们需要对测什么和怎样有效地测试有较好的理解。
  我推荐开发和测试的持续启动,从一个冲刺到另一个冲刺:
  当开发工作在冲刺n-1的功能点完成,测试工作开始。同时,开发工作可以继续在冲刺的功能点2上继续进行,等等。只要确定留出时间来修复缺陷和做进一步的改进完善即可。

        ......
查看更多精彩内容,请点击下载:

版权声明:本文出自《51测试天地》第五十四期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号