⾃动化测试简介
1. 基础概念
1.1. 百度百科的概念
⾸先我们来了解⼀下“⾃动化”的概念,来源于百度百科:
⾃动化(Automation)是指机器设备、系统或过程(⽣产、管理过程)在没有⼈或较少⼈的直接参与下,按照⼈的要求,经过⾃动检测、信息处理、分析判断、操纵控制,实现预期的⽬标的过程。⾃动化技术⼴泛⽤于⼯业、农业、军事、科学研究、交通运输、商业、医疗、服务和家庭等⽅⾯。采⽤⾃动化技术不仅可以把⼈从繁重的体⼒劳动、部分脑⼒劳动以及恶劣、危险的⼯作环境中解放出来,⽽且能扩展⼈的器官功能,极⼤地提⾼劳动⽣产率,增强⼈类认识世界和改造世界的能⼒。因此,⾃动化是⼯业、农业、国防和科学技术现代化的重要条件和显著标志。
再来了解⼀下“⾃动化测试”的概念,来源于百度百科:
⾃动化测试是把以⼈为驱动的测试⾏为转化为机器执⾏的⼀种过程。通常,在设计了测试⽤例并通过评审之后,由测试⼈员根据测试⽤例中描述的规程⼀步步执⾏测试,得到实际结果与期望结果的⽐较。在此过程中,为了节省⼈⼒、时间或硬件资源,提⾼测试效率,便引⼊了⾃动化测试的概念。
1.2. 个⼈的理解
从百度百科得来的关于“⾃动化”和“⾃动化测试”的概念,以及结合我⽇常⼯作的性质,个⼈认为⾃动化测试应该从⼴义和狭义两⽅⾯去区分⼀下。
⾃动化测试(Automated Testing):这个层⾯属于⼴义的理解,就是说测试⼯作或者流程整体是都是⾃动化完成,机器不仅代替测试⼈员的体⼒劳动,也负责整体测试⼯作的协调、管理、控制和优化,⾃动化涉及测试⼯作的⽣命周期全过程。(如⽬前流⾏的devops,整个过程定义好就可以完成测试代码更新、编译、打包、发布、执⾏测试、⽣成测试报告并发送邮件等,这个过程完全不需要⼈为介⼊,可以算作是⾃动化测试)。java技术介绍百度百科
测试⾃动化(Test Automation ):这个层⾯属于狭义的理解,范围相对要狭⼩⼀些,指使⽤特定的软件⼯具(测试⼯具)来控制测试的执⾏以及将实际结果与预测结果进⾏⽐较,能够⾃动执⾏⼀些重复但必要的任务,其实就是⽤机器代替测试⼈员的⼿⼯操作步骤的过程。通常⼤家说的⾃动化测试应该都是指“测试⾃动化”。关于“Test automation”可以参考⼀下的词条连接:
当然上⾯都是对⽂字意义上的理解,实际上为了完成测试⾃动化,还需要完成其他协同的相关⼯作内容,包括⾃动化团队的建设、⼯具的选择与使⽤等等。
2. 分层的⾃动化测试
测试⾦字塔(Test Pyramid):其实分层的⾃动化测试就是指测试⾦字塔。
迈克科恩在2009年《 Succeeding with Agile 》中对此进⾏了描述,并称为“测试⾃动化⾦字塔”。最早是⼀个包含UI/Service/Unit三层的⾦字塔,后来Lisa Cripin在《agile testing》中给塔加了⼀个⼿⼯测试的帽⼦,后来随着敏捷测试的推进,帽⼦部分转变为探索式测试。马丁福乐在2012年也在他的博客中对测试⾦字塔进⾏了描述,主要是增加了对成本和速度箭头的想法。还有 Alister Scott提出的测试⾦字塔。
Lisa Cripin的测试⾃⾦字塔:
Alister Scott的测试⾦字塔:
这些形形⾊⾊的测试⾦字塔,都是传统的⾃动化测试⾦字塔模型,都是很棒的视觉隐喻,可以让⼈思考不同层次的测试,还会告诉我们在每个测试层要做多少测试。⼤体上这些测试层分为UI Tests(e2e Tests)、Serveice Tests(API/Integration/Component Tests)、Unit Tests、Exploratory Testing。
注:下⾯部分内容借鉴齐涛道长
分层⾃动化测试倡导的是从⿊盒(UI)单层到⿊⽩盒多层的⾃动化测试体系,从全⾯⿊盒⾃动化测试到对系统的不同层次进⾏⾃动化测试,也揭⽰了我们对于⾃动化测试在每个层⾯的应该投⼊的情况,如下图:
Unit层(单元⾃动化测试),测试⾦字塔最底层,投⼊与产出都是最⼤的层级,主要有单元测试、代码审查等可以实现⾃动化。这个层级的东西应该是开发⼈员做的事情。
单元测试是指对软件中的最⼩可测试单元进⾏检查和验证。对于单元测试中单元的含义,⼀般来说,要根据实际情况去判定其具体含义,如C语⾔中单元指⼀个函数、Java中单元指⼀个类、图形化的软件中单元可以指⼀个窗⼝或⼀个菜单等。总的来说,单元就是⼈为规定的最⼩的被测功能模块单元。规范的进⾏单元测试就需要借助单元测试框架,如Java语⾔的Junit、TestNG,C#语⾔的Nunit。
Code Review 中⽂翻译为代码评审或代码审查,是指在软件开发过程中,通过对源代码进⾏系统性检查的过程。通常的⽬的是查系统缺陷,保证软件总体质量和提⾼开发者⾃⾝⽔平。与Code Review相关的插件与⼯具有很多,例如Java语⾔中基于Eclipse的Review Clipse和Jupiter、findbugs等。
Service层(可以叫做集成测试也有叫接⼝⾃动化测试的),测试⾦字塔居中的位置,投⼊与产出居中的价值位置。由于所有的应⽤程序都存在于其他部件(与其他应⽤程序的⽹络调⽤、数据库、⽂件系统)集成在⼀起,集成测试就是测试应⽤程序与应⽤程序内外的所有部分的集成内容。也可以理解为接⼝测试,对于接⼝测试分为:
模块接⼝测试,主要测试模块之间的调⽤与返回。也可以将其看作是单元测试的基础。它主要强调对⼀个类⽅法或函数的调⽤,并对返回结果的验证,所⽤到的测试⼯具与单元测试相同。
Web接⼝测试⼜可分为两类:服务器接⼝测试和外部接⼝测试。
服务器接⼝测试:指测试浏览器与服务器的接⼝。Web开发⼀般分前端和后端,前端开发⼈员⽤HTML/CSS/JavaScript等技术,后端开发⼈员⽤PHP/Java/C#/Python/Ruby等各种语⾔。⽤户的操作是在前端页⾯上,需要后端提供服务器接⼝,把前端通过调⽤这些接⼝来获得需要的数据,通过HTTP协议来实现前后端的数据传递。
外部接⼝测试:指调⽤的接⼝由第三⽅系统提供。典型的例⼦就是第三⽅登录,例如新上线的产品为了免于新⽤户注册账号的⿇烦会提供第三⽅登录,那么⽤户在登录的时候调⽤的就是第三⽅登录的接⼝,⽤户登录信息的验证由第三⽅完成,并返回给当前系统是否验证通过。
UI层(E2E Tests),处于测试⾦字塔的塔尖,相对来说投⼊产出⽐最⼩。
UI层是⽤户使⽤该产品的⼊⼝,所有功能都通过这⼀层提供并展⽰给⽤户,所以⼤多测试⼯作都集中在这⼀层进⾏。为了减轻这⼀层的测试⼈⼒和时间成本,早期的⾃动化测试⼯具主要针对该层设计。
除了UI层所展⽰的功能外,前端代码同样需要进⾏测试。在前端开发中最主要的莫过于JavaScript脚本语⾔。测试⾦字塔映射了不同测试阶段所投⼊的⾃动化测试的⽐例,UI层被放到了塔尖,这也说明UI层应该投⼊较少的⾃动化⽐例。如果系统只关注UI层的⾃动化测试并不是⼀种明智的做法,因为其很
难从本质上保证产品的质量。如果妄图实现全⾯的UI层的⾃动化测试,那么需要投⼊⼤量的⼈⼒和时间,然⽽,最终获得的收益可能远低于所投⼊的成本。因为对于⼀个系统来讲,越接近⽤户其越容易变化,为了不断适应这种变化就必然需要投⼊更多的成本。既然UI层的⾃动化测试这么劳民伤财,那么我们是不是只做单元测试与接⼝测试就可以了呢?答案是否定的,因为不管什么样的产品,最终呈现给⽤户的是UI层的功能,所以产品才需要招聘⼤量的测试⼈员进⾏UI层的功能测试。
在《Google 测试之道》⼀书中提到,Google对产品测试类型划分为:⼩测试、中测试和⼤测试,采⽤
70%(⼩)/20%(中)/10%(⼤)的⽐例,⼤体对应测试⾦⼦塔中的Unit、Service和UI层。在进⾏⾃动化测试中最担⼼的是变化,因为变化会直接导致测试⽤例的运⾏失败,所以需要对⾃动化脚本进⾏不断调整。如何控制失败,降低维护成本是对⾃动化测试⼯具及⼈员能⼒的挑战。反过来讲,⼀份永远都运⾏通过的⾃动化测试⽤例已经失去了它存在的价值。
对于测试⾦字塔,还有⼀个帽⼦是探索性测试。
探索性测试是⼀种⼿动测试⽅法,强调测试⼈员的⾃由和创造⼒,使⽤破坏性的思维⽅式,想出办法在被测对象中引发问题和错误,以便在测试对象中发现质量问题。
就算对于测试⾦字塔UI、service、unit所有层的⾃动化都做的极致,由于⾃动化⽤例设计或可⽤性等也不能保证所有某些边缘情景都考虑,发现所有问题也是不可能的事情。所以依然需要有经验的⼿⼯测试去补充。让机器做最擅长的重复性⼯作,让测试⼈员做⼀些有挑战的有意义的探索性测试。
分析测试⾦字塔,讲的都是理论上的内容,实际的⾃动化测试实践,⼤多数情况都变成了倒着的测试⾦字塔,UI层成了我们投⼊最多的地⽅,依次是service层和unit层。

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。