电商网站建设方案模板下载,公司查询企业查询在线,深圳网站官网建设方案,wordpress添加百度地图什么是自动化测#xff1f; 做测试好几年了#xff0c;真正学习和实践自动化测试一年#xff0c;自我感觉这一个年中收获许多。一直想动笔写一篇文章分享自动化测试实践中的一些经验。终于决定花点时间来做这件事儿。 首先理清自动化测试的概念#xff0c;广义上来讲#…什么是自动化测 做测试好几年了真正学习和实践自动化测试一年自我感觉这一个年中收获许多。一直想动笔写一篇文章分享自动化测试实践中的一些经验。终于决定花点时间来做这件事儿。 首先理清自动化测试的概念广义上来讲自动化包括一切通过工具程序的方式来代替或辅助手工测试的行为都可以看做自动化包括性能测试工具loadrunner、jmeter,或自己所写的一段程序用于生成1到100个测试数据。狭义上来讲通工具记录或编写脚本的方式模拟手工测试的过程通过回放或运行脚本来执行测试用例从而代替人工对系统的功能进行验证。 当然我们更普遍的认识把“自动化测试”看做“ 基于产品或项目UI层的自动化测试”。 分层的自动化测试 这个概念最近曝光度比较高传统的自动化测试更关注的产品UI层的自动化测试而分层的自动化测试倡导产品的不同阶段层次都需要自动化测试。 相信测试同学对上面的金字塔并不陌生这不就是对产品开发不同阶段所对应的测试么我们需要规范的来做单元测试同样需要相应的单元测试框架如java的Junit、testNGC#的NUnit python 的unittest、pytest 等几乎所有的主流语言都会有其对应的单元测试框架。 集成、接口测试对于不少测试新手来说不太容易理解单元测试关注代码的实现逻辑例如一个if 分支或一个for循环的实现那么集成、接口测试关注的一是个函数、类方法所提供的接口是否可靠。例如我定义一个add()函数用于计算两个参数的结果并返回那么我需要调用add()并传参并比较返回值是否两个参数相加。当然接口测试也可以是url的形式进行传递。例如我们通过get方式向服务器发送请求那么我们发送的内容做为URL的一部分传递到服务器端。但比如 Web service 技术对外提供的一个公共接口需要通过soapUI 等工具对其进行测试。 UI层的自动化测试这个大家应该再熟悉不过了大部分测试人员的大部分工作都是对UI层的功能进行测试。UI测试就是最简单的在页面上面的点点点测试也是最简单的黑盒手工测试但是UI自动化就很难了因为在录制的脚本在回放的时候很多都不能用所以必须自己写脚本但是又不能缺少录制脚本因为一开始我们只有通过录制脚本才能熟悉被测产品UI自动化脚本是怎样写的例如我们不断重复的对一个表单提交结果查询等功能进行测试我们可以通过相应的自动化测试工具来模拟这些操作从而解放重复的劳动。UI层的自动化测试工具非常多比较主流的是QTPRobot Framework、watir、selenium 等。 为什么要画成一个金字塔形则不是长方形 或倒三角形呢 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试只做UI层的自动化测试是不科学的从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试那更是一个劳民伤财的举动投入了大量人力时间最终获得的收益可能会远远低于所支付的成本。因为越往上层其维护成本越高。尤其是UI层的元素会时常的发生改变。所以我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。 既然UI层的自动化测试这么劳民伤财那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品最终呈现给用户的是UI层。所以测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力所以我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。 在自动化测试中最怕的是变化因为变化的直接结果就是导致测试用例的运行失败那么就需要对自动化脚本进行维护如何控制失败降低维护成本对自化的成败至关重要。反过来讲一份永远都运行成功的自动化测试用例是没有价值。 至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书对于google产品70%的投入为单元测试20%为集成、接口测试10% 为UI层的自动化测试。 我为什么要做自动化测试 根据51testing的《中国软件测试从业人员调查报告》手工测试占到的89% 相对开发来说测试的门槛底薪资普遍较底所要求的知识面虽然有一定广度但缺乏深度。这是测试的普遍现状。 正因为手功测试人门槛不高使大量的毕业生甚至是非专业人员涌入这个行业。从而增加了这个行业的激烈竞争。对于工作几年扔处于手工测试的人员来说都会有强列的危机感。由于工作的技术含量不高薪资的涨幅遇到瓶颈另一方面受到新进入者的威胁同样的工作公司花5K招来的人就可以做那么就不会花8K 的招。 好吧这个问题不应该出现讨论技术的话题中但他的确是大多测试人员不得不面对的一个问题。所以从测试人员自身的发展来说我其实非常需要通过自动化技术来增加自己有竞争力。当然做到一定年限测试人员会选择转管理或其它岗位这又是另一个话题了。 从测试行业的发展来说国内产品由于产品特点世界级的产品不多技术含量相对不高质量要求相对要求不高外包国外项目测试人力成本低廉所以需要大量的手工测试人员。 所以在不远的未来我认为纯的工手测试人员的需求是递减公司更需要更高技术能力的测试。质量需要测试测试行为永远不会消失但纯的手工测试人员是否消失是有可能的。 好吧你可以说测试多朝阳的行业我纯属在危言耸听。不管未来如何我们都需要提升自身的技能对吧 什么项目适合做自动化测试 假如你已经决定要学习自动化测试了如何学习是要面临的下一个问题这个问题以被测试产品为出发点进行分析假如你所学的技术不能得到应用验证将会使你的学习过程寸步难行。 首先考考虑产品是否适合做自动化测试。这方法比较普遍的共识是从三个方面进行权衡。 软件需求变动不频繁 测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本而脚本的维护本身就是一个代码开发的过程需要修改、调试必要的时候还要修改自动化测试的框架如果所花费的成本不低于利用其节省的测试成本那么自动化测试便是失败的。 项目中的某些模块相对稳定而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试而变动较大的仍是用手工测试。 项目周期较长
由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程需要较长的时间来完成。如果项目的周期比较短没有足够的时间去支持这样一个过程那么自动化测试便成为笑谈。 自动化测试脚本可重复使用 自动化测试脚本的重复使用要从三个方面来考量一方面所测试的项目之间是否很大的差异性如C/S系统和B/S系统的差异所选择的测试工具是否适应这种差异最后测试人员是否有能力开发出适应这种差异的自动化测试框架。 选择什么工具进行自动化测试 假如你已经确认了XX 项目适合做自动化测试那么接下来你要做的就是选测试工具了。 首先要先确认你所测试的产品是桌面程序C/S还是web应用B/S。 桌面程序的工具有QTP、 AutoRunner web应用的工具有QTP、AutoRunner、Robot Framework、watir、selenium 由于B/S架构的诸多优势早几年前大量C/S架构的应用转为B/S结构。从而也推动了web开发与测试技术的发展。假如被测试有产品是C/S架构的那么推荐QTP QTP在UI自动化测试领域占到了一半的试用率。所以足以说明QTP在自动化领域强大易用性等。学习主流的工具也可以使你获得更多的机会。市面上关于QTP的书籍也非常丰富。当然要想学好QTP 你必须要掌握VBS脚本语言。 如果被测产品是B/S 结构那么推荐selenium 为什么不是QTP 或其它工具因为selenium 对B/S应用支持很好更重要的一点它支持多语言的开发真正的试用selenium 你所要掌握的不仅仅是一个工具而已你还需要学习一门语言。我为什么要选择selenium还要学一门语言这无疑增加了我的学习成本。增加成本的同时也增加的你的竞争力而且在这个过程中你不单单只是学会了一个自动化工具而已你完全可以使用所学的语言去做更多的事情。 好吧假如你决定试用selenium 了之后你又面临了一个新的问题选择一门语言。selenium 是支持java、python、ruby、php、C#、JavaScript 。 从语言易学性来讲首选ruby python 从语言应用广度来讲首选java、C#、php、 从语言相关测试技术成度及 资料来讲ruby ,python ,java 或者你可以考虑整个技术团队主流用什么语言然后选择相应的语言。 selenium 用前须知 OK经过上的过程我相信你一定做出的相应的选择如果你选择的是selenium 工具那么接着往下阅读。
首选你在开始selenium之前需要花一到两个月时间去学一门语言这里是根据没有语言基础的同学而定的。我推荐ruby ,python ,java 任意一门语言来进行学习。 当然已经如果有很好的语言基础略过这个环节或者你的丰富的java编程能力那么学习python 可能只需要几天时间或更短。 假如你已经搞定了一门语言的基础接下来你需要先了解selenium selenium 并不是单纯的一个工具他是一组工具的集合而且他还有1.0与2.0之分当然3.0也已经到来。 selenium 也不是简单一个工具而是由几个工具组成每个工具都有其特点和应用场景。 selenium IDE selenium IDE 是嵌入到Firefox浏览器中的一个插件实现简单的浏览器操作的录制与回放功能。那么什么情况下用到它呢 快速的创建bug重现脚本在测试人员的测试过程中发现了bug之后可以通过IDE将重现的步骤录制下来以帮助开发人员更容易的重现bug。 IDE录制的脚本可以可以转换成多种语言从而帮助我们快速的开发脚本关于这个功能后而用到时再详细介绍。 selenium Grid Selenium Grid是一种自动化的测试辅助工具Grid通过利用现有的计算机基础设施能加快Web-app的功能测试。利用Grid可以很方便地同时在多台机器上和异构环境中并行运行多个测试事例。其特点为
· 并行执行
· 通过一个主机统一控制用例在不同环境、不同浏览器下运行。
· 灵活添加变动测试机 selenium RC selenium RC 是selenium 家族的核心工具selenium RC 支持多种不同的语言编写自动化测试脚本通过selenium RC 的服务器作为代理服务器去访问应用从而达到测试的目的。 selenium RC 使用分Client Libraries和selenium ServerClient Libraries库主要主要用于编写测试脚本用来控制selenium Server的库。 Selenium Server负责控制浏览器行为总的来说Selenium Server主要包括3个部分Launcher、Http Proxy、Core。其中Selenium Core是被Selenium Server嵌入到浏览器页面中的。其实Selenium Core就是一堆JS函数的集合就是通过这些JS函数我们才可以实现用程序对浏览器进行操作。Launcher用于启动浏览器把selnium Core加载到浏览器页面当中并把浏览器的代理设置为Selenium Server 的Http Proxy。 selenium 2.0 搞清了selenium 1.0 的家族关系selenium 2.0 是把WebDriver 加入到了这个家族中简单用公式表示为 selenium 2.0 selenium 1.0 WebDriver 需要强调的是在selenium 2.0 中主推的是WebDriver WebDriver 是selenium RC 的替代品因为 selenium 为了向下兼容性所以selenium RC 并没有彻底抛弃如果你使用selenium开发一个新自动化测试项目强列推荐使用WebDriver 。那么selenium RC 与webdriver 主要有什么区别呢 selenium RC 在浏览器中运行JavaScript应用使用浏览器内置的JavaScript 翻译器来翻译和执行selenese命令selenese 是selenium命令集合。 WebDriver通过原生浏览器支持或者浏览器扩展直接控制浏览器。WebDriver针对各个浏览器而开发取代了嵌入到被测Web应用中的JavaScript。与浏览器的紧密集成支持创建更高级的测试避免了JavaScript安全模型导致的限制。除了来自浏览器厂商的支持WebDriver还利用操作系统级的调用模拟用户输入。 如果是新项目直接学习webdriver 就OK了RC是过时技术。 selenium学习路线 配置你的测试环境真对你所学习语言来配置你相应的selenium 测试环境。selenium 好比定义的语义---“问好”假如你使用的是中文为了表术问好你的写法是“你好”假如你使用的是英语你的写法是“hello”。 所以同样有语义在不同的语言下会有不同的写法语法。 接着你需要熟悉webdriver API API就是selenium 所定义一方法用于定位操作页面上的各种元素。 先学习元素的定位selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能强大语法稍微复杂在这其间你可能还需要了解更多的前端知识。xml ,javascript 等。 定位元素的目的是为了操作元素接就要学习各种元素有操作输入框下拉框按钮点击文件上传、下载分页对话框警告框...等等。 经过一段时间的学习你可以游刃有余的模拟手工测试来操作页面上的各种元素了。接着你需要做的就是把这些“用例”组织起来统一来跑。 那么你需要做的就是学习并使用单元测试框架单元测试框架本身就解决了用例的组织与运行。 当你写了一些“测试用例” 之后你会发现用例中有大量重复的操作能不能写到一个单独的文件中需要的时候调用这些操作当然可以运用你的编程能力来实现这一点将非常简单。然后你又发现每个用例中都有一些数据这些数据也是一样的但如果变化了修改起来非常麻烦你也可以把他写到一个单独的文件中进行读取。 接着你又遇到了新的疑问我写的脚本用例都是流水式的我怎么知道用例运行失败还是成功。那么就需要在脚本中加一些验证与断言。 接着你又有了更多的想法单元测试框架的log太简陋了能不能生成一张漂亮的测试报告出来。我能不能定时的来跑这个脚本。能不能把每一次跑脚本的测试结果直接发到我的邮箱。能不能...... 为解决这些问题你不得不学习更多的编程技术然后你的“测试结构”会功能越来越强大越来越灵活。产生了一定的通用性和移植性。一个有模有样的自动化测试框架诞生了。 假如有一天你不再做UI的自动化测试了你会发现你去做单元测试 或接口测试基本没什么难度。开发个测试工具之类的也不在话下感谢selenium 吧顺便也感谢一下我吧
