自动化测试的发展趋势.doc_第1页
自动化测试的发展趋势.doc_第2页
自动化测试的发展趋势.doc_第3页
自动化测试的发展趋势.doc_第4页
自动化测试的发展趋势.doc_第5页
免费预览已结束,剩余1页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

自动化测试的发展趋势 提及自动化测试,如果单纯这么说,那么范围非常广泛。单元测试的自动化,功能测试自动化,性能测试自动化都属于自动化测试的范畴。而我们常说的自动化测试往往指的是UI功能自动化测试。 其实,在自动化测试领域,较为成熟的应用集中在单元功能自动化测试和性能自动化测试。在单元自动化测试阶段,现在产生了很多成熟的理论和方法,指导着工作的开展与展开。 在我个人的编码过程中,也尝试过测试驱动开发,在功能编写之前先进行测试代码的编写,当然,我使用的语言往往是Python,用的是Python的白盒自动化测试框架:unittest。然后,这种模式是和语言无关的,包括各种*unit。 在后续的代码开发和重构中,之前构建的白盒测试用例也都有效的节约了测试的劳动力,大大提高了测试的覆盖度。 性能自动化测试工具的应用比较多。像我的工作中往往关注进程本身的CUP,内存,发展到后续的I/O,子进程数量,线程数等等。这些也都有成熟的工具可以应用。对于典型的协议层面的性能自动化测试,LR是比较成熟的工具。 曾经和一个自认为测试技术不错的人探讨过,他尊称LR为性能测试之王,对此我深表遗憾。还有很多非常好的性能自动化测试工具。我们的产品特性让我有机会接触到业界的思博伦,BPS等等厂商的性能测试设备,进行二三层的测试工作。 在这些测试工具中,开放了良好的二次开发接口,可以进行自动化测试工具。 当然,包括LR,包括思博伦或者BPS等厂商的测试设备,价值不菲。还有一种比较极端的请款就是自我开发。自我开发的工作难度比较过,因为要模拟并发很难,不过在一些要求并非十分严格的情况下,也是一种实现方式。 说了这么多,只是想说明,当我们在探讨自动化测试这个话题时,要明确其范围,这个领域非常的广,如果范围不清,探讨就不再有其意义。4. 关于自动化测试发展的思考: 上面谈及了自动化测试的诸多领域。而我也一直在思考如果在我们实际的工作中应用自动化测试辅助我们的功能进行。 当前的UI功能自动化层面从业人员比较多,多也有回归测试阶段节约资源的观点。但我想,现在我们是否可以打破自己的视野,将自动化测试提前到前端去,而不是简单的后端被动应用。 首先说说UI的功能测试自动化。现在的技术发展据说有:应用为王的口号,在产品开发技术的逐渐成熟下,技术壁垒越来越低,而客户的感知往往决定着产品的成败。所以对于UI方面的测试重视逐步提高。 由此衍生了诸多的UI自动化测试方法的工具,QTP,Selenium,TC等等,太多了。 然后,抛开这些工具,让我们来思考UI功能自动化测试本身,它自身的投入产出比,我们当前是否做的足够好? 先说听到的两个案例吧: 1. 看到微软的测试人员写的一篇论文,在浏览器兼容性测试之前,通过编码实现HTTP协议的GET,POST等函数,进行与后端web服务器的功能交互,验证功能的有效性。 从这个测试模式可以看出,至少在此测试阶段,弱化了UI的测试,而主要进行接口层面的功能验证。这也体现了模块化,解耦合的思想。后续当然也会进行UI的测试工作,但也许后续的会种感受,轻功能,当然是有相应的策略了,在此不作揣测。 2. Baidu的技术交流会,陈景卫(如果名字打错请见谅)先生介绍百度当前的自动化测试分工,有7-2-1的划分,貌似的意义在于七成在后台,二成在功能,一成谈UI,也不约而同的对UI的功能自动化进行了一定程度的弱化。 其实在我们绿盟,虽然我们的自动化测试投入人力有限,也一直在进行领域的探索。跟随他们的脚步吧或者说也有同样的认知,我们在推广UI功能自动化的同时就进行了后台功能测试重点推广。争取将自动化测试逐步推向前,而不是只在简单的最终段。 所以,我在此想强调的是,随着自动化测试从业人员的技术积累,所谓的在回归测试应用自动化测试等等的观念可以做写改进了,我们理论上已经有能力将自动化测试应用到产品开发流程的前端。5. 我们该如何做: 既然有这样的想法,具体如何实现才是关键。 回归到底一段描述的内容,我的面试题,我们是否可以直观的看出,这样的测试题和所谓研发的测试题目是否还有本质的质的区别?包括我们公司现在的招聘工作,研发测试都是同样的笔试题,也在深刻的体现一个问题: 研发测试工作界线的弱化。 首先,现在的要求是研发、测试都要有强烈的质量意识。这点其实很多研发职位的人员是有非常强烈的质量意识的。他们对于产品质量的要求甚至要比所谓的测试工作者更强。二者本应是相辅相成的互助模式,而非所谓的敌对。 便如三权分立的思想,在合作的同时,彼此制衡,来保证产品的质量。 随着这个行业的发展,竞争逐渐激烈,门槛也会逐步提高。 在这种情况下,我们的测试人员还有理由没有编码能力吗?所以,编码能力必将成为测试从业者的基础技能之一。 另外就是,要坚定的认识到,自动化测试的推进不再是产品测试人员的工作,需要研发测试的合力。 在产品的设计阶段,留出良好的测试接口,当然,可以包含在发布代码中,也可以调试模式或者其他方式,现在也有成熟的理论支撑,在后续的发布版本中去掉。有了良好的测试代码接口,我们的自动化测试人员可以大幅提高开发效率,进而提高投入产品比,让自动化测试不只停留在一个理论的阶段。 同时,也要推进研发人员的白盒测试工作,当然,具体谁来执行白盒测试各公司分工不同。至少要有认识,如果他们不愿意或者排斥白盒测试的工作,你是否有能力承担起白盒测试的工作? 相比UI的功能自动化测试工作,我一直认为白盒测试自动化和性能测试自动化相对要容易些。 对于想实现最终的自动化测试,可以逐步推进,从白盒测试自动化,到功能测试自动化,UI功能自动化到性能测试自动化。在设计层面加入一些思考,让彼此解耦合,能够

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论