staf

浅谈自动化测试实践经验和教训

隐身守侯 提交于 2020-05-08 16:28:55
做自动化有好一段时间了,经历了自动化从无到有,然后到框架,到现在的平台,以及持续集成,回顾发现由于自己之前经验太浅,走过的弯路太多,现在也还在谨慎的前进着,之前发现早前很多懵懂的经验,现在稍稍清晰,于是想着结合自己的历程精简出一些经验吧。现在经验还是尚浅,如果有更深认识的朋友,互相讨论,谢谢。 一、所谓自动化是为了软件发布服务的,并不只是为了测试服务   以前一直怀疑自动化测试的用处,我们之前花费大力气开发了大量的基于关键字方式的脚本,用来提高测试的覆盖率,每次测试耗费大量时间,但是发现的问题少之又少,虽然说,自动化测试不是用来发现问题的,是用来验证软件没有问题,但是有一个矛盾在于我如果不做自动化测试,问题还是那么少,那么做自动化测试我们难道只是为了追求一个心理感受吗?这个概率问题怎么平衡 后来,这个经验是在与开发一起合作冒烟测试建设,到现在的持续集成建设,开始明白,自动化测试的好处是为了增强开发的灵活性和保证软件开发流程的有序性 1)快速检测新版本的不稳定变更,即冒烟测试,能够快速验证当前build版本是否可以继续下一步或者提测,此处冒烟测试可以是单元测试、集成测试和基本功能覆盖测试,常用的框架和工具:Junit、TestNG和接口测试框架(soapui、httpClient等)、界面测试框架用于基本的界面测试(QTP、RFT、selenium)。 2)尽可能的暴露回归程序的错误

浅谈自动化测试实践经验和教训

為{幸葍}努か 提交于 2020-05-08 16:19:20
做自动化有好一段时间了,经历了自动化从无到有,然后到框架,到现在的平台,以及持续集成,回顾发现由于自己之前经验太浅,走过的弯路太多,现在也还在谨慎的前进着,之前发现早前很多懵懂的经验,现在稍稍清晰,于是想着结合自己的历程精简出一些经验吧。现在经验还是尚浅,如果有更深认识的朋友,互相讨论,谢谢。 一、所谓自动化是为了软件发布服务的,并不只是为了测试服务   以前一直怀疑自动化测试的用处,我们之前花费大力气开发了大量的基于关键字方式的脚本,用来提高测试的覆盖率,每次测试耗费大量时间,但是发现的问题少之又少,虽然说,自动化测试不是用来发现问题的,是用来验证软件没有问题,但是有一个矛盾在于我如果不做自动化测试,问题还是那么少,那么做自动化测试我们难道只是为了追求一个心理感受吗?这个概率问题怎么平衡 后来,这个经验是在与开发一起合作冒烟测试建设,到现在的持续集成建设,开始明白,自动化测试的好处是为了增强开发的灵活性和保证软件开发流程的有序性 1)快速检测新版本的不稳定变更,即冒烟测试,能够快速验证当前build版本是否可以继续下一步或者提测,此处冒烟测试可以是单元测试、集成测试和基本功能覆盖测试,常用的框架和工具:Junit、TestNG和接口测试框架(soapui、httpClient等)、界面测试框架用于基本的界面测试(QTP、RFT、selenium)。 2)尽可能的暴露回归程序的错误