按是否手工执行测试的角度划分：手工测试、自动化测试_按是否手工执行方式划分,软件测试分为哪些测试方法

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

缺点

适用范围

自动化测试可以涉及和试用的范围主要在以下方面：

基于Web UI的浏览器应用的界面测试

基于WebService或者WebAPI的服务契约测试

基于WCF、.net 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的一个强大的单元测试框架。

分层自动化测试投入比例

UI层自动化测试：投入比例小，原因：很难保证产品的质量，浪费人力、物力，因为越接近用户越容易变化

什么样的项目适合自动化测试

-任务测试明确，不会频繁变动。

-每日构建后的测试验证。

-比较频繁的回归测试。

-软件系统界面稳定，变动少。

-需要在多平台上运行的相同测试案例、组合遍历型的测试，大量的重复任务。

-软件维护周期长。

-项目进度压力不太大。

-被测软件系统开发较为规范，能够保证系统的可测试性。

-具备大量的自动化测试平台。

-测试人员具备较强的编程能力。

正常情况下满足三个：

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的顶部，因此它与现代开发工具集成和工作良好

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

开发工具集成和工作良好

[外链图片转存中…(img-nnanBekh-1715374763804)]
[外链图片转存中…(img-Tve9iNhg-1715374763805)]
[外链图片转存中…(img-LJYz9rwI-1715374763805)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取