按是否⼿⼯执⾏测试的⾓度划分：⼿⼯测试、⾃动化测试1.⼿⼯测试（Manual testing）
⼿⼯测试是由⼈⼀个⼀个的输⼊⽤例，然后观察结果，和机器测试相对应，属于⽐较原始但是必须的⼀个步骤。
由专门的测试⼈员从⽤户视⾓来验证软件是否满⾜设计要求的⾏为。
更适⽤针对深度的测试和强调主观判断的测试
⽐如：众包测试和探索式测试
优点：⾃动化测试⽆法代替探索性测试、发散思维类⽆既定结果的测试。
缺点：执⾏效率慢，量⼤易错。
2.⾃动化测试（Automation Testing）
定义
所谓⾃动化测试，就是在预设条件下运⾏系统或应⽤程序，评估运⾏结果。（预先条件包括：正常条件和异常条件）。简单来说，⾃动化测试就是是把⼈为驱动的测试⾏为，转化为机器执⾏的⼀种过程。通
常，在设计了测试⽤例并通过评审之后，由测试⼈员根据测试⽤例中描述的规程⼀步步执⾏测试，得到实际结果与期望结果的⽐较。在此过程中，为了节省⼈⼒、时间或硬件资源，提⾼测试效率，便引⼊了⾃动化测试的概念。
分类
⾃动化测试有：功能测试⾃动化、性能测试⾃动化、安全测试⾃动化。（⼀般情况下，我们说的⾃动化是指功能测试的⾃动化）
⾃动化测试按照测试对象来分，还可以分为接⼝测试、UI测试等。接⼝测试的ROI（产出投⼊⽐）要⽐UI测试⾼。
优点
缺点
适⽤范围
⾃动化测试可以涉及和试⽤的范围主要在以下⽅⾯：
基于Web UI的浏览器应⽤的界⾯测试
基于WebService或者WebAPI的服务契约测试
基于WCF、 remoting、Spring等框架的服务的集成测试
基于APP UI的移动应⽤界⾯测试
基于Java、C#等编程⽂件进⾏的单元测试
前提条件
实施⾃动化测试之前需要对软件开发过程进⾏分析，以观察其是否适合使⽤⾃动化测试。通常需要同时满⾜以下条件：
1) 需求变动不频繁；
测试脚本的稳定性决定了⾃动化测试的维护成本。如果软件需求变动过于频繁，测试⼈员需要根据变动的需求来更新测试⽤例以及相关的测试脚本，⽽脚本的维护本⾝就是⼀个代码开发的过程，需要修改、调试，必要的时候还要修改⾃动化测试的框架，如果所花费的成本不低于利⽤其节省的测试成本，那么⾃动化测试便是失败的。项⽬中的某些模块相对稳定，⽽某些模块需求变动性很⼤。我们便可对相对稳定的模块进⾏⾃动化测试，⽽变动较⼤的仍是⽤⼿⼯测试。
2) 项⽬周期⾜够长；
⾃动化测试需求的确定、⾃动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本⾝就是⼀个测试软件的开发过程，需要较长的时间来完成。如果项⽬的周期⽐较短，没有⾜够的时间去⽀持这样⼀个过程，那么⾃动化测试便成为笑谈。
3) ⾃动化测试脚本可重复使⽤
如果费尽⼼思开发了⼀套近乎完美的⾃动化测试脚本，但是脚本的重复使⽤率很低，致使其间所耗费的成本⼤于所创造的经济价值，⾃动化测试便成为了测试⼈员的练⼿之作，⽽并⾮是真正可产⽣效益的测试⼿段了。
另外，在⼿⼯测试⽆法完成，需要投⼊⼤量时间与⼈⼒时也需要考虑引⼊⾃动化测试。⽐如性能测试、配置测试、⼤数据量输⼊测试等。适合场景
通常适合于软件测试⾃动化的场合：
(1)回归测试，重复单⼀的数据录⼊或是击键等测试操作造成了不必要的时间浪费和⼈⼒浪费；
(2)此外测试⼈员对程序的理解和对设计⽂档的验证通常也要借助于测试⾃动化⼯具；
(3)采⽤⾃动化测试⼯具有利于测试报告⽂档的⽣成和版本的连贯性；
(4)⾃动化⼯具能够确定测试⽤例的覆盖路径，确定测试⽤例集对程序逻辑流程和控制流程的覆盖。
注：⾃动化测试更适合⽤于回归测试，⽽不是⽤来发现新bug。
⾃动化测试的流程
测试计划：划定⾃动化测试的范围包含哪些需求，涉及到哪些测试过程
测试策略：确定⾃动化测试的⼯具、编程⽅案、代码管理、测试重点
测试设计：使⽤测试设计⽅法对被测试的需求进⾏设计，得出测试的测试点、⽤例思维导图等
测试实施：根据测试设计进⾏⽤例编写，并且将测试⽤例⽤编程的⽅式实现测试脚本
测试执⾏：执⾏测试⽤例，运⾏测试脚本，⽣成测试结果
⾃动化实施的步骤
（1）完成功能测试，版本基本稳定
（2）根据项⽬特性，选择适合项⽬的⾃动化⼯具，并搭建环境
（3）提取⼿⼯测试的测试⽤例转换为⾃动化测试的⽤例
（4）通过⼯具、代码实现⾃动化的构造输⼊、⾃动检测输出结果是否符合预期
（5）⽣成⾃动测试报告
（6）持续改进、脚本优化
⾃动化测试模型
可以分为线性测试、模块化与类库、数据驱动测试和关键字驱动测试。
线性测试通过录制或编写对应程序的操作步骤会产⽣相应的线性脚本，即单纯地模拟⽤户完整的操作场景。
模块化与类库式把重复的操作单独封装成公共模块，在测试⽤例执⾏过程中，当需要⽤到模块封装时对其进⾏调⽤，这样就最⼤限度地消除了重复，从⽽提⾼测试⽤例的可维护性。
数据驱动测试的定义：数据的改变驱动⾃动化测试的执⾏，最终引起测试结果的改变。就是把数据驱
动所需要的测试数据参数化，我们可以⽤多种⽅式来存储和管理这些参数化的数据。
关键字驱动测试⼜被称为表驱动测试或基于动作字测试。这类框架会把⾃动化操作封装为“关键字”，避免测试⼈员直接接触代码，多以“填表格”的形式降低脚本的编写难度。
⾃动化测试框架
⾃动化测试架构思想做⼀个对⽐：
1）数据驱动测试：
其思想是将我们的⾃动化测试脚本和测试数据放在共同的测试架构中，提供可重⽤的测试逻辑。这样做的⽬的是减少测试维护的⼯作量以及便于改善测试⽤例的覆盖率。测试⽤例需要输⼊的测试数据和测试完成后的测试结果数据都会被存储在同⼀个数据库或者数据源中，并且将测试的数据和测试逻辑分开。这样测试数据发⽣了变化时不会影响到我们的测试逻辑，并且同⼀套测试逻辑可以针对多种数据来进⾏测试，尽量提⾼测试逻辑的使⽤效率和复⽤效率。
2）模块驱动测试：
其思想是使⽤独⽴的脚本或者代码来对应每⼀个待测试的模块单元和功能。模块驱动测试引⼊的是编
程语⾔中的⾯向对象编程中的抽象和模块独⽴封装的思想，即将测试代码和每⼀个测试模块进⾏解耦，减低⾃动化测试脚本或者⾃动化测试代码的维护成本，同时增加可扩展性。
3）关键字驱动测试：
Robot Framework和RedwoodHQ就是⼀种典型的关键字驱动测试的框架模式。关键字驱动测试通常也被认为是表格驱动测试，通过在表格中调⽤关键字来实现⾃动化测试。这种设计思想⼀般会将⾃动化测试拆分为设计和实现两个不同的阶段。
4)⾏为驱动开发测试(BDD)：
是⼀种敏捷开发的思想，使⽤简单的、特定于领域的脚本语⾔(DSL)将结构化⾃然语⾔语句转换为通俗易懂的可执⾏测试。⾏为驱动开发的根基是⼀种“通⽤语⾔”，通俗易懂，同时被客户和开发者⽤来定义系统的⾏为。Cucumber就是⼀种⾏为驱动开发的⾃动化测试⼯具。
⾃动化测试架构设计
注：ant也可以换成maven，看项⽬代码是不是⽤maven
分层⾃动化测试
上图更多关注产品的UI层⾃动化测试，⽽分层⾃动化测试倡导产品不同阶段（层次）都需要⾃动化测试：
unit ：单元⾃动化测试，是对软件中最⼩的可测试单元进⾏检查与验证，如：C语⾔的最⼩的单元是⼀个元素，Java中最⼩的单元是⼀个类，图形化软件中的最⼩单元是⼀个窗⼝、按钮、菜单等。规范单元测试需要借助于单元测试框架（⼯具）
单元测试（Code Review ：中译代码评审、代码审查）：查系统缺陷、保证软件真题质量，提⾼开发者⾃⾝⽔平。
Service：接⼝⾃动化测试分为：模块接⼝测试、web接⼝测试
模块接⼝测试：测试模块间的调⽤与返回。如：类⽅法、函数调⽤并对返回结果进⾏验证
Web接⼝测试：分为服务器接⼝测试、外部接⼝测试
服务器接⼝测试：浏览器与服务器之间的接⼝，通过HTTP协议进⾏调⽤
外部接⼝测试：调⽤接⼝，由第三⽅调⽤，如：调⽤、QQ、微博登陆接⼝
UI层：是⽤户使⽤该产品的⼊⼝，所有功能都通过这⼀层提供并展⽰给⽤户，所以测试⼯作⼤多集中在这⼀层进⾏。为了减轻这⼀层的测试⼈⼒和时间成本，早期的⾃动化测试⼯具主要针对该层设计。
除了UI层所展⽰的功能外，前端代码同样需要进⾏测试。在前端开发中最主要的是javascript脚本语⾔，⽽QUnit就是针对Javascript的⼀个强⼤的单元测试框架。
分层⾃动化测试投⼊⽐例
软件测试appUI层⾃动化测试：投⼊⽐例⼩，原因：很难保证产品的质量，浪费⼈⼒、物⼒，因为越接近⽤户越容易变化
什么样的项⽬适合⾃动化测试
-任务测试明确，不会频繁变动。
-每⽇构建后的测试验证。
-⽐较频繁的回归测试。
-软件系统界⾯稳定，变动少。
-
需要在多平台上运⾏的相同测试案例、组合遍历型的测试，⼤量的重复任务。
-软件维护周期长。
-项⽬进度压⼒不太⼤。
-被测软件系统开发较为规范，能够保证系统的可测试性。
-具备⼤量的⾃动化测试平台。
-测试⼈员具备较强的编程能⼒。
正常情况下满⾜三个：
1、软件需求变动不频繁：⾃动化脚本变化的⼤⼩、频率决定⾃动化维护成本，变化⼤，测试⼈员要进⾏扩展、修改、调试
2、项⽬周期较长：需求确定，框架有好的设计，脚本开发调试时间较长
3、⾃动化测试脚本可重复使⽤：测试项⽬之间是否存在很强的差异性，如：c/s、b/s之间的架构所展⽰的功能差不多，对脚本可重复使⽤，选⽤的技术、⼯具是否适应这种差异，测试⼈员是否有能⼒设
计出满⾜条件的差异
⾃动化测试及⼯具简述
⾃动化测试的概念有⼴义和狭义之分：⼴义上讲：所有借助⼯具来辅助进⾏软件测试的⽅式都可以称为⾃动化测试；狭义上讲：主要是指基于UI层的功能⾃动化测试。
1）UFT：（QTP：企业级⾃动化测试⼯具，提供强⼤、易⽤的录制回放功能，同时兼容对象和图像两种识别模式，⽀持B/S和C/S两种架构的软件测试）
2）Robot Framework：基于Python语⾔编写的⾃动化测试框架，具备良好的可扩展性，⽀持关键字驱动，同时可测试多种类型的客户端或接⼝，可进⾏移动端测试
3）Watir：基于WEB测试，使⽤Roby语⾔开发
4）Selenium：⽤于web应⽤程序测试⼯具，⽀持多平台，多浏览器，多语⾔去实现⾃动化测试
下来我们探讨⼀下主流的⾃动化测试⽅案，⽆⼀例外，都有⼈机沟通的编程语⾔，加上机器操作的⼯具来组成。
功能⾃动化测试
VBScript + QTP(HP UFT)，商⽤功能⾃动化测试⽅案
Python/PHP/Java/C#/JavaScprit/Ruby + Selenium/Appium + 单元测试框架，开源功能⾃动化测试⽅案
这⾥我们多介绍⼀点，Selenium/Appium 本⾝不能算是测试⼯具，⽽只是机器⽤来操作浏览器的⼯具，并且这个⼯具能听懂多种语⾔：
Java，C# 这两个重 (zhòng) 语⾔
Python，Ruby 这两个脚本轻语⾔
PHP，JavaScript 这两个专门处理 Web 的语⾔
⼯具外加指定的语⾔，可以让机器来操作浏览器，但是到此时还⽆法做到测试，于是才需要每个语⾔⾃⼰的单元测试框架，来⼀起完成这个功能⾃动化测试⽅案的构建。
此外，业界还⼀种暂时临时的⽅案，就是 Python 2 + Robot Framework + Selenium Library 插件 + 单元测试框架构成的⼀种测试⽅案，这个⽅案笔者不是⾮常推荐，主要基于两点：
理念：这是⼀种基于关键字的⽅案，那么关键字是 QTP（HP UFT）的特长，并不是Selenium的本意
技术：Python 2 终究是要退出历史舞台的，如果从零开始做⾃动化测试，还是直接⼊⼿ Python 3 吧，然⽽ Robot Framework 不⽀持Python 3……
Python/Java/C#/JavaScprit/Ruby + Gauge，⼜⼀款开源的功能⾃动化测试⽅案
Thoughtworks 的基于BDD理念的⾃动化测试⼯具
Gauge 本⾝就是完整的测试⽅案
Gauge 是从需求分析师（BA）到测试⼯程师（QA）都覆盖的测试⽅案
Java/Python + Macaca，阿⾥巴巴的功能⾃动化测试⽅案，缺点是⽂档少
JavaScript + TestCafe，DevExpress 的开源功能⾃动化测试⽅案
pure node.js - TestCafe不使⽤Selenium，并且不需要插件来在实际浏览器中运⾏测试。它建⽴在node.js的顶部，因此它与现代开发⼯具集成和⼯作良好
⽆需额外的设置或配置- TestCafe是所有设置后⽴即运⾏测试npm install
完整的测试⼯具 - 使⽤单个启动命令，TestCafe启动浏览器，运⾏测试，收集结果并⽣成报告
JavaScript + Postman，免费的Web接⼝功能⾃动化测试⽅案
Groovy + SoapUI，开源的Web接⼝功能⾃动化测试⽅案
性能⾃动化测试
Java/C + HP LoadRunner，商业版性能测试⽅案
Java + JMeter，开源版性能测试⽅案
Python + locust，开源版性能测试⽅案
学习⾃动化测试技术⼼得
⼀、⾃动化测试的学习步骤
1. 做好⼿⼯测试（了解各种测试的知识）->
2. 学习编程语⾔->
3. 学习Web基础->
4. 学习⾃动化测试⼯具 ->
5. 学习⾃动化测试框架 ->
6. 实现⾃动化测试⽤例 ->
7. 开发⾃动化测试⼯具 ->
8. 开发⾃动化测试框架
按照这个步骤来说，基本上到第7步，难度就⽐较⼤了，这个时候也可以称呼⾃⼰为“测试开发”。
⼆、⾃动化测试需要掌握的技术能⼒
⼀、⾸先要学会⼀门语⾔，java或者Python，这⾥针对Python去说。如果要能够满⾜⾃动化测试的需求，不要求Python的能⼒上来就达到精通的⽔平，但是最起码的使⽤是要有的，然后在后期在逐步根据测试⼯具进⾏进阶。
⼆、需要掌握前端的⼀些知识，⽆论学习语⾔还是前端知识，都是为了接下来的脚本和框架做铺垫。
三、数据库的重要性不⾔⽽喻，MySQL必须掌握
四、web端⾃动化测试⼯具selenium
五、接⼝测试⾃动化⼯具jmeter、postman等
六、移动端⾃动化测试appium
在这⾥主要就是把⾃动化划分为了web⾃动化测试、接⼝⾃动化和移动端⾃动化。
三、⾃动化测试的认识误区
1、⾃动化的软件测试与⼿⼯的软件测试过程⼀样
⾃动化测试所需要的技巧与⼿⼯测试所需要的技巧是不⼀样的。
通常，你的项⽬经理会被那些测试⼯具销售们迷惑，认为⾃动化的软件测试就是简单地按⼀个录制的按钮，产⽣测试脚本。⽽事实上并没有那么简单。
区分⾃动化测试所需要的技巧与⼿⼯测试所需要的技巧是⾮常重要的。最重要的是，⾃动化测试⼯程师需要掌握软件开发技巧，没有接受任何培训的⼿⼯测试⼈员，或者没有编程背景的⼿⼯测试⼈员，在实施⾃动化测试时会碰到很多困难。
2、⾃动化测试⼀定会马上⼤量减少测试⼈员数量
⾃动化测试不会马上⼤量减少测试⼈员数量。因为开展⾃动化测试初期需要投⼊⼀定的⼈⼒进⾏⾃动化测试脚本开发，并逐渐将⾃动化测试脚本⽤于⽇常的测试中，逐步减少⼿⼯测试⼈员从事重复劳动的时间和⼈数。为了缩短⾃动化测试脚本的开发时间，可以考虑将⾃动化测试脚本的开发⼯作借助外包的⼒量来早⽇实现⼤规模的⾃动化测试。
3、测试⾃动化就是录制和回放

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