1、我想问一下关于自动化测试工具Selenium和QTP的区别。假如一个系统现在需要一款自动化测试工具,要求可以重复提交表单进行功能性测试,不用纯手工去做(因为工作量过大),现在有两个工具(Selenium和QTP),哪个比较适合?
这个要看情况:
1、你们公司是不是土豪,可以买qtp,可以买就用qtp。不能买,敢不敢用盗版?敢用,就用qtp。
2、页面元素的识别麻烦不?如果qtp搞不定,就只有努力学习,提升自己的编码能力,使用selenium去操控底层的页面元素来实现。如果页面元素不麻烦,想偷懒,请参考第一条。
2、目前很多项目自动化最多就是跑冒烟测试,所以更大的意义在哪里呢?求解
冒烟测试也是很有意义的,可以在最短的时间内验证程序是否跑得起来,而且因为测试用例少,实施起来门槛低,容易实现。比如我要做的一个windows客户端程序,冒烟测试就只有登录和3个基本功能。如果登录失败,则可以第一时间发现平台环境(包括数据库)是否正常。测试好立即恢复环境,以免影响后续测试工作。
3、毕业一年半一直做功能测试,想转自动化测试,不知道怎么开始第一步?老师有没有什么建议
其实才毕业,任务安排还不能随心所欲,要听老大的。做好老大安排的任务是最基本的。功能测试技术含量听起来不高大上,但是可以深入了解自己公司产品的业务流程。业务流程对测试人员来说才是最重要的。
如果一定想转学自动化测试,可以先自己自学,等待老大给机会。自动化测试对一般公司来说还是比较奢侈的(哈哈),需要等待机会。希望你好运。
4、如果想要把自动化发挥更多更广阔的地方,应该是朝哪个方向呢?
冒烟测试的基础上,下一步就是要实现基本功能的自动化回归测试了。
基本功能测试用例集的确定非常重要,一定是那些最基本最核心最稳定的功能。基本功能用例集实现自动化测试后,这些测试用例会被反复执行(特别是在每日构建流程中),所以性价比是最高的。
下一步就是将更多的功能加入自动化测试。这些非基本功能可能不会每次都自动化回归。但是在一个开发周期中可能会被反复执行。所以也很重要。
5、想请教一下,如果测试场景中,涉及到输入验证码,能实现自动化吗?
基本上这个很难。如果自动化测试能够绕开验证码,那这个验证码得多笨。
这种情况下,一般都需要开发配合,提供去掉验证码的测试版本。
6、自动化测试后是否还要提交给单独的测试部进行系统测试?
这是必须的。千万不要以为自动化测试是万能的。即便微软 谷歌等公司也不是这样。
记住,自动化测试只能用于回归测试,而且要在脚本通过了长期验证,证明没有问题的情况下。
刚刚做自动化测试的同事,常常碰到一个问题,自动化测试脚本其实也是代码,开发写的代码靠自动化测试脚本来保证质量,那自动化测试脚本靠谁来保证质量呢?只能靠脚本编写人员的能力来保证,和长时间的实践来检验了。
7、看了好多jenkins自动化测试的配置,都是说在构建的时候执行测试用例,可是构建的时候,连服务都没有怎么可能测试成功啊?我认为的过程应该是:(1)提交代码;(2)构建编译;(3)自动部署(4)自动化测试,求大神解释一下,jenkins怎么做到我说的过程的?
如果是代码级的单元测试 集成测试,可以在自动部署前,构建的时候运行。不过我还是建议单元测试 集成测试和构建分开为两个步骤。
如果是系统测试,就只能在自动化部署后。你的理解是正确的。
8、我正在学习web开发,哪一个版本的火狐浏览器适合做web开发测试?
用chrome吧,chrome浏览器比较常用一些
9、我在学习QTP,我用的版本是UFT12,为了实现拖动浏览器的滚动条,网上查到的脚本代码是Browser().Page().Object.body.doScroll("scrollbarDown") ,但是我在编写这条代码时,Object的属性和方法里却没有body,是什么原因?
没有实际环境,我也不好回答你。不过这种找不到属性的问题在QTP使用的时候是常事。这也是我喜欢sikuli的原因之一。我建议一个偏方,你试试发送page-down键盘消息看看呢。
10、为何国内的前端对自动化测试好像不是很看重?
自动化测试的重点不是实现自动化测试或者把它加入到开发上线流程中,而是要对用例做收集管理,借助丰富的用例来保证代码质量。而用例的收集管理是否可以成功,取决于业务是否稳定可预测。现阶段国内的IT行业还处于高速增长期,业务善变不稳定。尤其是UI的变化更是频繁。此时收集管理用例成了西西弗斯的惩罚,消耗人力不说,还无法用来保证代码质量。对于与业务无关的底层框架、库来说,自动化测试一直是存在的。但正如他们所处的位置,相对公司范围,只会是小范围小团队对其它有依赖,难以扩大影响,在频繁变更的业务线也无法推广。所以,我想,等高速增长期结束了,业务趋于稳定后,它才有可能被普遍重视吧。
11、APP UI自动化测试框架都包含哪些内容?
所有的自动化测试框架都牵涉到3个阶段:setup, execution, teardown。setup阶段你需要想好你的case执行策略和之间的关联关系如何解决(支持并发执行吗?case需不需要做前后关联?关联的话并发执行如何解决?),数据准备,配置(包括环境如何分隔)。execution阶段需要考虑调用测试代码如何实现,肯定会包括你的执行机制和验证结果机制如何做能让用的人比较方便。teardown阶段就是最麻烦的地方了,牵涉到数据结果收集,展示,异常处理机制。前端的话你只要做到上面3点,再做到UI元素库的封装就行,一般的话都是用的POM。其实一般不要一个人去造这种轮子,累不说,做完了可能还不如开源项目,不如二次开发通用型测试框架。比如Robot Framework和Gauge这种。
版权声明:本文出自51Testing会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。