如果你对软件测试、面试经验交流感兴趣欢迎加入软件测试技术群:695458161,群里发放的免费资料都是笔者十多年测试生涯的精华。还有同行大神一起交流技术哦。

一入测试深似海,从此月薪过两万--自动化测试如何产生价值?

上一篇 / 下一篇  2020-04-28 17:53:35 / 个人分类:软件测试

一、前言

如何让自动化测试产生价值?这是一个恒古不变的话题!只有将自动化切入日常测试中,才能将飘于空中的技术产生实际的价值,无论是DevOps、CICD等其他的一些融合开发的概念,质量的自动化保障都是基础设施。本次主要讲一下现有团队在自动化方面的一些探索和落地。


二、自动化优先

        自动化优先,既在QA人员介入测试时,就需要考虑需求自动化测试动作。需求中需要哪种程度的自动化介入,需要哪些自动化测试动作的介入,自动化测试需要哪些前置资源,自动化测试所花费成本,自动化测试在本次需求中的收益点;了解清楚了这些内容,就能够确定自动化是否要做,怎么做。

根据实际的项目经验,自动化优先具有以下优点:

节约自动化编写时间(项目熟悉成本)、在测试过程中自动化的用例能够支持测试、加快定版回归效率、外部联调测试中支持测试。

材料:外部接口文档、web接口契约

三、执行过程

如果你觉得此文对你有帮助,如果你对软件测试、面试经验感兴趣欢迎加入:
软件测试技术群:695458161,群里发放的免费资料都是笔者十多年测试生涯的精华。还有同行大神一起交流技术哦。
笔者来自公众号:软测之家

在实际的自动化测试过程中,主要涉及以下的流程&动作:

1.需求分析:软件测试技术群:695458161

前面有提到,我们的自动化手段有很多,在实际项目中,无论是基于UI、WEB场景、SRV服务代码逻辑覆盖;针对需求的大小、涉及面、复杂度、类型(UI、接口),都有使用场景,不同工具方法使用在不同的场景发挥恰到好处的价值。

具体来讲:

接口请求返回调整的需求,仅需要针对历史脚本文档进行维护即可。

新增完整小模块的需求,针对模块功能,上线模块功能自动化覆盖。

调整/重构核心系统的需求,具体分析本次需求对核心系统影响,了解变更设计的历史脚本维护,了解需要对哪些历史脚本进行维护,并了解需要新增的逻辑/接口。

全新系统开发类的需求,了解本次需求涉及测试类型,针对UI、WEB接口、srv服务等类型,考虑需要采用的合适测试类型。 

2.脚本设计

根据需求分析中得到的需求类型和涉及的测试类型,涉及对应的测试用例,此处只讨论接口测试相关内容。

一个接口测试用例应包含以下几个模块:初始化(数据初始化、配置初始化)、业务逻辑模块(内包含基础的接口)、工具类(conditionSleep、**加签、解密等)、数据校验、数据输出。

很多时候完整自动化用例并不适用小版本迭代,在进行小版本功能迭代时,更多是进行部分接口或逻辑的变更。针对小的逻辑变更时,可以参考开发代码进行代码行逻辑覆盖,结合jacoco工具,做到对开发有效代码的逻辑覆盖。通过这种方式的测试,无需上层复杂场景高成本覆盖,仅通过底层接口的自动化测试,来保证底层提供功能的符合性。

以下示例为一个完整的场景测试用例。

3.基础配置

在开始编写脚本之前,需要准备好所需要的资料(如:外部接口文档、WEB接口文档、相关规约说明)。

在进行基础配置准备中需要遵循一些基本原则,即可维护性,通用性,原子性。通常这类配置都是能够被不同业务场景,甚至业务线共用的,保持其通用性将会对后续的脚本开发、维护有极大的便利性。

根据实际系统的需求,针对外部接口文档配置所需要的MOCK(通常情况下为保证自动化的通过率,外部系统的接口采用MOCK方式支持);依据WEB接口文档,配置基础的WEB接口参数等。

PS:MOCK系统的支持需要基础设施的支持,这个不在本次讨论范围内,后续有机会讨论。

MOCK配置:MOCK开关初始化、MOCK路由配置、 MOCK请求数据准备、MOCK返回数据准备。

WEB接口配置:服务、公共路径(功能模块)、方法配置(请求参数、返回参数)。

MicService接口配置:服务、服务组标识(ServiceGroup)、接口(InterfaceInfo)、方法(Method)

不过在没有经验的情况下,这些可能无法一次就做的比较好,那么就一步一步迭代即可,初步保持基本原则,在遇到具体的多元化引用时进行优化。

4.脚本编写

在开始脚本编写的时候,要根据脚本设计实施,针对不同的模块类型有具体差异性。

常见的模块类型有:公共工具模块、数据初始化、数据校验模块、脚本场景支撑模块。

公共工具类模块主要提供一些工具属的支撑,如:条件等待(有些场景异步返回结果或返回结果是非实时,需要根据某一个条件(通常是数据库数据)判断是否进行下一步操作)、加签**(某些外部接口请求需要对请求参数进行**加签处理,通常这类操作是通用的)、解密(有些外部请求的返回已被**,在进行后续操作是需要进行解密;有些数据检查需要进行解密后才能校验)。

数据初始化模块包含场景用例运行所需的初始数据,这类数据来源有:数据库现有数据(现有可进行场景执行的账户)、根据规则实时生成的数据(如:身份证、手机号、订单号)、由其他用例执行后输出的数据(如开通脚本输出的开通用户数据、借款脚本生成的借款单数据)

数据校验模块用来对数据落地进行逻辑符合性校验,通过对场景运行中涉及到的数据落地表数据进行逻辑符合性校验,保证自动化用例的有效性。数据校验也可以分层分级进行配置,针对不同用途的脚本(冒烟、回归、功能测试),选择覆盖不同的表、字段检查项。

脚本场景支撑模块是场景用例组装的基础,脚本设计中包含此模块详细设计。具体来讲,通过对需求业务、接口各个功能分析,划分出场景中相对固定的一些模块(此处划分有以下原则可以遵循:接口上下文在场景多元化时无需增减调整、无参数变化、无异步调用出,则可以划分为一个模块。在模块划分清楚后,依据已经实现的原则层用例,将各个子用例打包成一些固化的模块,组织好各个原子接口的参数输入和输出以及一些基本的校验。

自动化测试中很大一部分的工作都在此时完成,脚本的效率、合理性、鲁棒性都是在此时通过具体实施来落地。脚本的优化性都有一个相对度,不必过于追求对脚本进行优化,如同开发代码一样,优化是没有极限的,只要满足当前使用要求,遵循一些必要原则即可。

5.场景组装

自动化想要实现的覆盖都会通过场景组装来实现,需要覆盖多少场景是根据每个团队业务需要来确定,有些需要做尽可能多场景覆盖,有些仅需要做核心逻辑覆盖即可。

场景组装需要控制覆盖场景的粒度,一旦过于追求场景覆盖度,维护成本就会失控。

在进行场景组装时,会发现有些前置的实现存在不合理,此时及时优化不合理的地方并做记录,方面后续脚本优化时有的放矢。

场景组装示例

6.调试优化

脚本编写完成后,通过不断的运行,会发现脚本中一些不合理的地方。这些不合理的地方主要有:耗时较久、不稳定(偶尔失败)、脚本间互斥(配置初始化不合理)、通过率较低等一些问题。

针对这些问题,其实上面已经讲过方法,在脚本编写的阶段未严格遵循一些原则或没有意识到这些问题,此时对应做优化即可。

耗时较久的问题,需要做下取舍或通过技术手段来弥补脚本的等待时间,针对某些需要等待过久的脚本,单独拆出做自动化。

用例执行耗时

不稳定的问题,一般都是检查点不合理导致的,某些检查点未做好,会出现偶尔失败的场景。有些检查点不必做过于强的校验,抓住自动化的目的。

脚本间互斥的问题,此类问题就是脚本设计问题了,在考虑好脚本场景要求后,对每个脚本都要做一些配置校验或初始化,保证脚本运行期间业务、系统配置是预期的。另,在不同脚本运行期间由于运行顺序不合理业务有此类问题,此时可以调整用例的线性运行顺序。

通过率较低的问题,在脚本初步调试完成后,运行一段时间发现通过率较低,这个在自动化初期阶段较常见,一般都是外部系统不稳定导致的问题。此时需要针对不稳定的外部系统,做些MOCK,必要时,可以要求研发提供必要的接口支持业务数据顺利流转。


TAG:

引用 删除 wjh973447344   /   2020-05-07 17:38:54
5
ganyu_甘雨的个人空间 引用 删除 ganyu_甘雨   /   2020-05-06 14:41:31
5
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

诸葛_

诸葛_

如果你对软件测试、面试经验交流感兴趣欢迎加入软件测试技术群:695458161,群里发放的免费资料都是笔者十多年测试生涯的精华。还有同行大神一起交流技术哦。

日历

« 2021-03-01  
 123456
78910111213
14151617181920
21222324252627
28293031   

数据统计

  • 访问量: 10925
  • 日志数: 38
  • 建立时间: 2020-04-01
  • 更新时间: 2020-06-29

RSS订阅

Open Toolbar