突发奇想!自动化测试在测试过程中该怎样提升效率?

突发奇想!自动化测试在测试过程中该怎样提升效率?_第1张图片
测试能力分层的组织架构下,一提到效率提升,可能大多数人,首先想到的是测试开发团队,亦或是成败在于此。假如我们也是这样想,我想我们可以尝试换一个角度,也许会有更多的收获。

两个必要问题

解决效率问题,其本身包含两个必要问题,二者缺一不可:

  • “适不适合”做
  • “能不能够”做

“适不适合做” 衡量的是意义价值,即必要性,引入自动化测试是为了能够切实解决某些问题,而不是单纯为了自动化而做自动化。

“能不能够做”衡量的是能力水平,即可行性,重点关注的是具体开展过程中的自动化设计、开发、维护、使用等问题,如何通过更优雅的方式降低开发、维护成本,比如数据驱动等等。

结合以往经验,在只解决上述问题中的其一或者二者不解决的情况下,可能会出现以下情况:

只解决“适不适合做”的问题,可能会导致:

  • 没有掌握完整的自动化测试技术栈,开发成本高。
  • 没有选择合适的框架或解决方案,无法从整体上降低用例的编写、维护成本,在持续投入下,投入产出比大概率为负。

只解决“能不能够做”的问题,可能会导致:

  • 传统瀑布开发模式下,迭代周期长,次数少。几个版本下来,等同测试覆盖下,自动化测试投入可能大于手动测试投入。
  • 频繁的需求变更,自动化用例维护成本高,自动化测试逐渐废弃。

“适不适合做”、“能不能够做”的问题都不解决,可能会导致:

  • 如果是这样,那这只能是 “闹着玩”,也许昙花一现、也许半途而废。

因此,在我们的自动化开展过程中,引入了自动化需求澄清环节,主要研判的就是上述两个问题。这个过程,业务方作为需求提出方主要研判“适不适合做“的问题,测开方作为需求承接方主要研判“能不能够做的问题”,根据以往经验,前者问题难度更高更复杂。

因此,我们不难发现,要做到有效的提升、这两个问题是绕不过去。在解决这两个问题的前提下,我们才能够正确地明确其目标,才有了目标才能正确制定其具体实施方案。

突发奇想!自动化测试在测试过程中该怎样提升效率?_第2张图片

为何而做(目标度量)

接下来,聊一聊目标,自动化测试度量指标,我们近几年尝试过很多种维度去度量,例如,从自动化用例数量、到覆盖率、再到ROI、效率提升率,我们发现这些度量维度不难计算,通过自动或手动统计的方式都可以统计计算出结果,但度量数据反映的情况与实际情况存在较大的差异性(效率、质量),例如 度量数据呈现出的效率提升率在变高,但实际业务测试周期似乎没有变化,等等。

那么这个问题出在哪里?—— 当我们与真相一步步靠近时,这其中每一步都是有意义的。

问题也许出在 “目标” 本身,目标即导向。那么效率提升的本质是不是“用例数量多“、”覆盖率多”、”ROI高”? 好像也并不是,差一点意思。我认为本质应该是简单的、直接的 :

  • 在定时任务的背景下,快 → 时间缩短
  • 在定量任务的背景下,快 → 人数减少

我们可以尝试以效率提升最本质的目标作为驱动,也许将更有效、更直接。

在具体指标设定时,除了“定性”、不可避免的还要“定量”,“定量”一方面是为了度量其绝对值,另一方面是与其“定性”相互佐证。

  • 定性: 时间缩短 → 例如,平均项目测试周期缩短 X % 。
  • 定量: 累计节省人力投入(或累计节省额外人力投入) → 例如,累计节省额外人力投入X 人月。

如何去做

这是万事俱备,只欠东风的一步,当然这也是最重要的一步。有一些项目可能会有疑问,上述的问题,我们都一定程度解决掉了,但自动化测试仍然没有达到预期的效果。

大概可能是以下原因导致:

  • 缺乏整体测试用例执行设计,用例覆盖目的性弱,具有随机性、随意性,低覆盖,无法真正的缩短执行效率。
  • 只做到了自动执行,但没有做到自动验证,无法真正的在保证质量的提前下,提高执行效率。
  • “自动化孤岛”,缺乏持续性、未引入到流程当中。

“缺乏整体测试用例执行设计”的问题 解决思路

我们在手动执行测试用例时,为了缩短执行时间,避免某些操作的重复执行,通常,我们会先设计执行场景,一个场景下,尽可能根据执行顺序,覆盖更多的测试用例。
突发奇想!自动化测试在测试过程中该怎样提升效率?_第3张图片
比如,结合上述业务流程Demo,我们需要自动化测试覆盖所有功能服务接口,我们的会怎样设计测试用例?从单接口的角度还是场景的角度?

对于这种包含业务流程或是用户使用场景的功能测试分析,建议从场景的角度去覆盖,通过场景的流程分解,逐步拆分,然后对拆分后的流程环节进行测试分析,提取测试点。

最后,根据流程串联各个环节的测试点,最大程度地复用流程,降低测试覆盖过程的重复性操作,以覆盖一个场景为最小有效单位。例如,1-2-4-5-7, 1-3-6-7 。

假如,我们在自动化覆盖的时候,不按照场景的方式,单个接口逐一覆盖,此时若“关注商品”暂时没有进行覆盖,还是采用手动执行的方式验证该功能,单从自动化覆盖率、用例数量等指标看,与场景的方式无异。但在实际手动执行时,会发现在有意或无意地在操作自动化已经覆盖的“查询商品”等功能,那么从提效的角度来看,手动执行自动化已经覆盖的测试点,相当于自动化的提效作用被抵消。

因此,无论我们在冒烟测试、回归测试的用例设计中,尽可能保障覆盖功能点在操作上的闭环,以覆盖一个场景为最小有效单位,这个场景的定义就是连续性操作的闭环,可能是N个功能、也可能是一个功能。

只做到了自动执行,但没有做到自动验证

翻阅平台的自动化用例,不乏只有验证响应状态的用例出现,也许是在手动测试的时候,只是关注了下状态,剩余的一扫而过。

一条严谨有效的测试用例,需要对响应内容全面覆盖,考虑到响应内容可能存在一些非幂等性的属性,比如当前时间,目前提供的关键字中,也灵活的支持过滤掉哪些属性不校验的功能。

避免在提升效率的过程中,忽略了质量的基本要求。这也是今年自动化平台需要延展的功能—— 测试用例设计风险预警。

“自动化孤岛”,缺乏持续性、未引入到流程当中。

这个大家应该都明白,那就是引入到持续集成中,是最直接、有效的解决方法。

同时,在流程中的提测环节、在系统集成前,做好自动化测试通过率、代码覆盖率的卡点。

最后

自动化测试,起初的定义是用于回归测试等操作具备重复性,且对象具备稳定的场景中,主要考虑到功能的稳定性和投入成本的问题,前期项目功能变更的风险较高、同时周期往往紧张,自动化覆盖存在一定的开发、维护成本。

这其中的主要矛盾是“成本问题”,试想自动化覆盖成本在不断降低时,矛盾在逐渐弱化,那么这个局限性就会被打破。自动化测试同样可以用于首轮测试、甚至是在与研发功能设计有良好的契约下,在提测前也可以完成。

上述,我们在探讨自动化测试如何做到有效的效率提升,除此之外,还可以去尝试结合代码覆盖率,不断提高自动化覆盖率;结合代码改动范围,精准运行对应测试用例,从机器逐渐演变成智能…

在这里推荐一个我自己创建的软件测试交流群,642830685,群中会不定期的分享软件测试资源,测试面试题以及测试行业资讯,大家可以在群中积极交流技术,群内大佬也会为你答疑解惑。

推荐阅读

毕业3年…设计行业一事无成,北漂闯荡转行成功

面试10家公司…从刚开始的危机感到绝地求生的自救之路

因为前公司一句话错失offer,背调时如何预防前任的负面评价?

你可能感兴趣的:(软件测试,自动化测试,软件测试工程师)