自动化测试策略?如何开展自动化测试?

测试基础知识学习笔记 专栏收录该内容
3 篇文章 0 订阅

功能测试自动化要点

 

1 什么时候开始使用自动化测试?

开始之前,要考虑5点

 

1.1 功能测试自动化类似软件开发过程

录制,回放是不能满足自动化测试的需求的,所以要测试人员掌握开发知识,和编程技巧。

 

1.2 功能自动化测试是个长期的过程

首先我们不能再短时间内有很多的测试成果,找到测试的BUG,自动化测试只有在长期的多次运行后才能体现出他的价值和作用。

其次开发出来的东西也不意味着可以取代所有的测试工作,要考虑自动化测试脚本的设计和维护,被测试的应用修改之后,测试脚本也需要去维护,测试是个长期的过程。

 

1.3 确保自动化测试的资源,包括人员和技能

准备好电脑,服务器,手机,等等一切自动化测试需要的资源,有专职的人员负责设计框架和开发脚本,解决开发过程中遇到的问题,确保自动化计划顺利进行。

 

1.4 循序渐进的开展自动化测试

不要一开始就把自动化测试弄的很大,这很难实现,自动化测试应该从最小的开始,熟悉自动化测试和基本的技能,开始整合资源,实现一些基本用例,例如冒烟的用例,然后在逐步的扩展和补充。

 

1.5 确保功能测试过程的成熟度

开展自动化测试之前,考虑一下企业各方面的管理,例如考虑测试是否要独立执行,有无配置管理,进展控制能力如何?这些不成熟,不具备,开展自动化测试有点困难。

 

2 如何开展自动化测试?

 

2.1 选取合适的项目进行自动化测试

关键字:长期,稳定的项目

       自动化测试只有在长期的多次运行后才能体现出他的价值和作用,不断的进行自动化测试才能预防缺陷,减轻测试人员的工作量,如果一个项目是短期的,或者UI频繁的在变,这是不适合做自动化测试的。

      其次,不要在紧急的项目中开展,自动化需要脚本的开发以及维护,这其中又要花费很多时间,这个时候开展自动化测试,最后会起到相反的效果

 

2.2 选择合适的自动化开始时间

过早的开始自动化测试带来的维护成本太高了,早期的需求不确定,频繁的变动,这个时候不能进行

 

2.3 选择合适的自动化测试工程师,构建测试团队

编写脚本的人,要有一定的代码知识,需要了解各种测试脚本的编写和设计方法,知道什么时候选择什么样的测试脚本开发方式,如何有效维护等,需要具备一定的编程技巧,以及需要测试的基本知识,能够理解测试业务,只有理解了才能准确的转化为自动化测试用例。

 

自动化测试体系:

a. 测试自动化的类型和接口类型:接口自动化,单元测试自动化,回归自动化,性能自动化等。

b. 自动化测试的工具:POSTMAN,Jmeter,LR,QTP等等

c. 测试自动化测试框架设计

d. 自动化脚本思想,包括用例选择,自动化测试设计和开发,自动化测试的执行,分析和报告。

e. 自动功能化测试脚本质量优化。考虑到脚本维护性,移植性,灵活性,健壮性,稳定性,可靠性,效率等问题。

f. 编程思想。掌握对应编程语言的基础语法,比如Java,Python

g. 自动化对象。包括识别应用对象,对象映射,对象模型,动态对象行为等

h. 调试技巧。脚本报错了,会去调试

i. 错误处理。了解常用的错误处理手段,诊断错误,定义错误捕获机制,建立出错日志,创建错误处理函数

j 自动化测试报告。比如HTMLTestRunner  这种的,生成一个漂亮的报告,给领导展示以及自动好记录工作成果。

 

2.4 控制成本

考虑人员,测试设备以及测试工作成本问题。

  • 抽取专职人员做自动化测试,不影响测试业务进行
  • 准备额外的设备:机器,文件服务器,数据库等
  • 引入自动化测试工具或者开发工具成本预算,测试工具培训等等

 

3. 自动化测试项目流程

遵循软件开发的基本规则,按照软件开发生命周期来弄:

a. 需求概述   

制定自动化测试需求分析说明书

b. 制定自动化测试计划

c. 制定自动化测试方案

d. 自动化测试用例设计或从功能测试用例中挑选适合的用例

e. 自动化脚本的开发

f. 自动化测试执行,生成报告

根据自动化测试计划中指导,按照时间的要求执行所有自动化测试内容,并生成自动化测试结果,分析自动化测试需求覆盖率,自动化测试效果,生成报告。

 

4. 自动化测试方案制定

选择自动化测试方案要考虑以下几点:

a 项目的影响:自动化测试是否能对项目进度,覆盖率,风险有积极的作用,或者让开发更敏捷

b 复杂度:自动化测试是否容易实现,包括数据和其他环境的影响

c 时间:需要多少时间

d 早期的需求和代码的稳定性:

e 维护工作量:代码是否能保持长期相对的稳定,功能特性是否会变化

f 覆盖率:是否覆盖到了关键的特性和功能

g 资源:测试组是否有足够的人力资源,硬件资源和数据资源

h 自动化测试的执行:拥有足够的时间去运行代码

 

5. 自动功化测试执行的策略?

自动化测试用例的执行策略是要看自动化测试的目的,通常有如下几种策略:

要确信你的自动化case是有价值的,可以代替你的手动测试

        自动化测试,尤其是功能性,也就是说代替手动case的。所以说我们必须确信我们的case是有价值的,可以代替我们去执行相应的手动case。至于什么是有价值的自动化case,我们相信应该是这样的:在一定的环境中执行过了自动化case,我们就相信,在这个环境中,我们没必要再进行同样的手动操作。

        至于如何写出有价值的case,当然也有其策略和方法,这里不再提及。

在测试环境中的执行才更有价值的

        上条说道,在一定的环境中去执行case,那这个一定的环境是什么样的环境呢?这里我的观点可能比较极端,我认为写case的环境,是我们的开发环境,并不是我们理想中的测试环境。

        那什么才是测试环境呢?答案就是,我们自己定义的,并且专门用于测试的环境。这个环境的所有情形都是Expected,或者是可枚举的。比如说装什么系统,装什么相关软件,如何跑我们的case,这都应该是定义好的。这样的环境才是测试环境。

        也许有人会对我这里定义的测试环境持反对意见,认为这样的环境并不是用户真实使用的环境,我们应该在更复杂的环境中去执行自动化测试,以期找到更多的bug。但是我认为自动化测试的目的就是做Regression Testing,以期有效的功能测试和版本控制。自动化测试并不能代替手动case,它应该是一个增量式的过程,我们不要期望让自动化发现更多的bug,而应该不断的添加,丰富各种自动化case,以及Bug Verification,以解放测试人员,让其更关注于测试本身。

能持续集成的运行了,才算我们的自动化测试跑起来了

      持续集成是业界非常好的经验总结,不光适用于我们测试,实际上她应该是适用于整个项目的。要想做到持续集成我们有很多的开源工具可以选择,这里的持续集成包括了:自动化执行。发现了BUG,自动的报BUG等,真正做到了全自动化。

我们要拥抱任何有意义的变化

这一点非常重要,这个是观念上的转变。我们要拥抱任何有意义的变化,这是观念上的转变。为了做出更好的产品,需求在变,代码也跟着变,我们的case在变,自动化case又有何理由不变呢?如果因为需求的变动导致我们自动化case挂了,我们应该高兴才是,因为我们的case成功的侦测到了这个变动,它是有价值的。换句话说,如果需求都变了,而我们的case还跑的好好的,那我可就要怀疑你的case到底有没有价值喽?!拥抱任何有意义的变动,不是说创建稳定性好的自动化case就没有意义了。

至于如何做自动化,Just Coding!

当DEV的开发水平会更高一些,但是对于我们QA,尤其是做开源领域比如Android的测试,做自动化的终极解决方案其实就是阅读产品代码,当我们读懂了开发代码,那写测试case就不是问题了。所以我最终的的建议就是:Just Coding, Just Do It!只有真正去做了,你才会发现问题,才会想到去解决问题,才会想到要总结一些方法,然后让我们的Case在测试环境中自由的跑起来!

自动化测试用例是用来监控的

在此目的下,我们就把自动化测试用例设置成定时执行的,如果每五分钟或是一个小时执行一次,在jenkins上创建一个定时任务即可。

必须回归的用例

有些儿测试用例,如BVT测试用例,我们在公司产品任何变动上线之前都需要回归执行。那我们就把测试用例设置成触发式执行,在jenkins上将我们的自动化测试任务绑定到开发的build任务上。当开发人员在仿真环境上部代码的时候,我们的自动化测试用例就会被触发执行。

不需要经常执行的测试用例

像全量测试用例,我们没有必要一直回归执行,必竟还是有时间消耗的,有些非主要业务线也不需要时时回归。这类测试用例我们就采用人工执行,在jenkins创建一个任务,需要执行的时候人工去构建即可

广撒网 

广撒网是指,加测试的时候A,B,C,D四个模块雨露均沾,没有什么特别的规则,你只要能报证覆盖率是增加的就行了。

集中某个业务流程 

这种策略优先关注于A,B,C,D中的某一个,完成其中某一个之后,再去实现别的模块。

集中某个业务的策略收益更早一些,对于广撒网这种策略,因为某个业务模块的金字塔没有完全实现,所以我们是不敢用它代替人工的,只能等所有的都完成了,我们才敢使用它代替人工测试。但是,集中某个业务是先完成某个业务流程,当这个业务流程完成了,我们就可以使用它代替人工测试,因为不是广撒网,所以我们收益的更早一些。

自动化测试中的测试数据管理策略

 

 

 

  • 5
    点赞
  • 1
    评论
  • 39
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 创作都市 设计师:CSDN官方博客 返回首页

打赏作者

Ricky_Frog

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值