自动化测试最佳实践(一)

自动化测试的误区

自动化测试 != 写脚本

写脚本只是测试工程师的副业,顺手就搞定

自动化测试范围

自动化测试的范围:包括自动化测试的重点和难点、测试深度和广度:

自动化测试的重点:根据被测对象的价值,设计合理的UT/IT/ST自动化分层策略,明确整体测试重点及每一层测试重点

自动化测试难点:从测试技术角度来说,根据产品的类型及团队的能力,分析自动化品测试实施的难易程度,选择合适的自动化测试技术及工具

自动化测试深度从测试方法(场景,边界值,错误输入,单运行,多运行等)角度描述自动化测试的目标

自动化测试的广度从覆盖的角度描述测试,包括功能,性能,安全,兼容性等测试的自动化

按照优先级实施自动化测试

自动化实施时间较长,实施自动化时可区分优先顺序:

对稳定的功能优先做自动化

对已经通过的测试用例做自动化

对冒烟测试用例优先做自动化

高价值高风险对象优先做自动化

对流程类似,数据驱动的组合类测试(接口测试,压力测试,安全测试)优先实施自动化测试

兼容性测试(跨浏览器,跨设备)优先使用自动化

对自动化测试的难点要事先准备

被测对象涉及多种技术: 随着移动互联网时代到来,前端用户接口日益融合,后端架构微服务化,接口/安全/兼容性等测试越来越重要,软件系统日趋复杂,对自动化测试带来的挑战也越来越多。在选择自动化测试技术及工具时,必考虑所选技术路线对未来是否有影响,能否满足未来的自动化测试需求

动态内容的处理:软件中常见的动态内容有id、验证码等

测试环境的影响:在自动化测试执行时,由于测试环境的不稳定(比如数据库,网络,服务器性能)造成的执行失败的问题非常常见,自动化测试脚本中需要对这些问题提供必要的等待策略

复杂流程的处理:在一些比较复杂的流程中,涉及的步骤比较多,步骤间会有顺序,参数可能比较多,不同的参数可能会产生有细微不同的流程,对于这种测试场景,采用组合测试,以及模块化/数据驱动的方式较好

有些测试用例无需自动化

自动化实施成本很高,实施自动化测试必须考虑ROI,某些场景的测试用例可以不实施、或者暂缓实施自动化:

只使用1次的测试用例

性价比不高的测试用例

某些异常场景的测试用例

结果不可知的测试用例

不稳定的测试用例

提高自动化测试的可维护性

自动化测试的成本主要由两部分组成:脚本的开发成本及脚本的维护成本,提高脚本的可维护性,可以降低自动化测试的维护成本,可以采用的策略包括:

自动化测试框架必须支持模块化/数据驱动,支持测试环境分层管理,制定并完善测试脚本的编码规范

测试用例按照测试环境分组

测试脚本要尽可能简单,步骤保持在10~20步之间,流程控制要尽量少

使用测试用例的ID作为自动化测试脚本的ID,避免拿title做脚本或case的名字,ID应有意义,比如ST_ORDER_FUNC_0010

测试用例中的步骤要尽量直观,尽可能使用望而知义的locator

不要使用绝对路径的xpath,减少UI变化对脚本稳定性的影响

测试脚本需要不断的模块化/关键字化/数据驱动工作,应该建立相应的流程和制度,并由专人负责,以提高测试脚本的重用性

脚本的结构可以模板化,采用自动化工具生成大致框架

脚本的变更需要和测试用例同步,并使用自动化工具完成,将测试用例作为脚本的文档,对脚本、用例以及测试数据做变更管理

自动化测试元数据的管理:自动化测试的元数据包括测试时间、测试结果等,都需要妥善管理,为测试框架的优化提供数据支撑

推行组合测试

与研发工具链集成

源代码控制:包括SVN,GIT等变更管理工具

持续集成:如Jenkins,Bamboo等工具

缺陷管理平台:比如JIRA等

提高自动化测试的执行效率

减少不必要的等待,禁止使用强制等待:

使用Selenium Grid或者Jenkins,将测试用例拆分到多个环境上做分布式执行

考虑能否用集成测试或者单元测试代替耗时的系统测试用例

使用分布式或者增量式编译减少build时间

控制测试套的大小,可以将测试用例分级分类,不用每次都执行所有的测试脚本

定期检视从没有失败过的脚本,考虑其功能是否已经被别的脚本覆盖,精简冗余的脚本

自动化测试的基本原则

越早执行越好

执行的越快越快

执行的越多越好

越容易执行越好

自动化所有能自动化的

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180913G0KAAZ00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券