178 lines
12 KiB
Markdown
178 lines
12 KiB
Markdown
|
||
|
||
|
||
|
||
## 1.引入自动化测试的条件及原因
|
||
|
||
### 1.条件
|
||
|
||
● 项目需求变动不频繁
|
||
● 项目周期足够长
|
||
● 自动化测试脚本可重复使用
|
||
|
||
### 2.原因
|
||
|
||
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。
|
||
|
||
自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便无意义。
|
||
|
||
## 2.自动化测试的基本流程
|
||
|
||
|
||
|
||
### 1.制定测试计划
|
||
|
||
明确测试对象、测试目的、测试的项目内容、测试的方法。此外，要合理分配好测试人员的安排以及测试所需要的硬件、数据等资源。制定测试计划后可使用禅道等管理工具监管测试进度。
|
||
|
||
### 2.分析测试需求
|
||
|
||
测试需求其实就是测试目标，也可以看做是自动化测试的功能点。自动化测试是做不到100%覆盖率的，只有尽可能提高测试覆盖率。一条测试需求需要设计多个自动化测试用例，通过测试需求分析判定软件自动化测试要做到什么程度。
|
||
|
||
### 3.设计测试用例
|
||
|
||
在设计测试用例时，要考虑到软件的真实使用环境，例如对于性能测试、安全测试，需要设计场景模拟真实环境以确保测试真实有效。
|
||
|
||
### 4.搭建测试环境
|
||
|
||
自动化测试人员在用户设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件、添加对象。测试环境的搭建，包括被测系统的部署，测试硬件的调用、测试工具的安装和设置、网络环境的布置等。
|
||
|
||
### 5.编写测试脚本
|
||
|
||
根据自动化测试计划和测试用例编写自动化测试脚本。编写测试脚本要求测试人员掌握基本编程知识，并且需要和开发人员沟通交流，以便于对软件内部结构了解从而设计编写出有效的测试脚本。测试脚本编写完成之后需要对测试脚本进行反复测试，确保测试脚本的正确性。
|
||
|
||
### 6.分析测试结果、记录测试问题
|
||
|
||
建议测试人员每天抽出一定时间，对自动化测试结果进行分析，以便更早发现缺陷。如果软件缺陷真实存在，则要记录问题并提交给开发人员修复，如果不是系统缺陷，就检查自动化测试脚本或者测试环境。
|
||
|
||
### 7.跟踪测试Bug
|
||
|
||
测试发现的Bug要记录到缺陷管理工具中去，以便定期跟踪处理。开发人员修复后，需要对问题执行回归测试，如果问题的修改方案与客户达成一致，但与原来的需求有偏离，那么在回归测试前，还需要对脚本进行必要的修改和调试。
|
||
|
||
## 3.自动化测试的实时策略
|
||
|
||
自动化测试采用金字塔策略
|
||
|
||
|
||
|
||
金字塔要求自动化测试从三个不同级别进行，最底部的单元测试占据了自动化测试的最大百分比，其次是接口测试和UI测试。将自动化测试重点工作放在单元测试和接口测试阶段有助于加快项目整体开发进度，减少后期开发和测试的成本。
|
||
|
||
#### 1.单元测试
|
||
|
||
单元测试要求在开发中对每个功能模块（函数、类方法）进行测试，如检测其中某一项功能是否按预期要求正常运行，单元测试中通常采用白盒测试，主要对代码内部逻辑结构进行测试。
|
||
|
||
#### 2.接口测试
|
||
|
||
接口测试要求对数据传输、数据库性能等进行测试，从而保证数据传输以及处理的完整性。接口功能的完整运作对整个项目功能扩展、升级与维护有着重要的作用，接口测试通常使用黑盒测试和白盒测试相结合的方式进行。
|
||
|
||
#### 3.UI测试
|
||
|
||
UI测试以用户体验为主，软件的所有功能都是通过这一层展示给用户，因此UI测试的工作也很重要。由于UI界面以最终的用户体验为主，因此在UI测试中并不是100%的使用自动化测试，其中需要人工操作来确定UI界面的易用程度。
|
||
|
||
## 4.自动化测试的优势和劣势
|
||
|
||
### 优势：
|
||
|
||
● 自动化测试具有一致性和重复性特点，而且测试更客观，提高了软件测试的准确度、精确度和可信任度。
|
||
● 自动化测试可以将任务自动化，能够解放人力去做更重要的工作。
|
||
● 自动化测试只需要部署好相应的场景，如高度复杂使用场景、海量数据交互、动态响应请求等要求，测试就可以在无人值守的状态下自动进行，并对测试结果进行分析反馈，手工测试很难实现复杂的测试。
|
||
● 自动化测试可以模拟复杂的测试场景完成人工无法完成的测试，如负载测试、压力测试等。
|
||
● 软件版本更新迭代后需要进行回归测试，自动化测试有助于创建持续集成环境，使用新构建的测试环境快速进行自动化测试。
|
||
|
||
### 劣势：
|
||
|
||
● 相对手工测试，自动化测试对测试团队的技术有更高的要求。
|
||
● 自动化测试无法完全替代人工测试找到Bug，也不能实现100%覆盖
|
||
● 自动化测试脚本的开发需要花费较大的时间成本，错误的测试用例会导致资源的浪费和时间投入。
|
||
● 产品的快速迭代，自动化测试脚本将不断迭代，时间成本很高。
|
||
● 自动化测试能提高测试效率，却不能保证测试的有效性。
|
||
|
||
## 5.常见的自动化测试技术
|
||
|
||
### 1.录制与回放
|
||
|
||
录制是指使用自动化测试工具对桌面应用程序或者是Web页面的某一项功能进行测试并记录操作过程。
|
||
录制过程会生成对应的脚本。
|
||
|
||
录制是指使用自动化测试工具对桌面应用程序或者是Web页面的某一项功能进行测试并记录操作过程。
|
||
录制过程会生成对应的脚本。
|
||
|
||
回放是指执行脚本还原录制到的操作过程，回放可以查看录制过程中存在的错误和不足，如图片刷新缓慢、URL地址无法打开等。
|
||
|
||
### 2.脚本测试
|
||
|
||
测试脚本是测试计算机程序执行的指令集合，脚本可以使用录制过程中生成的脚本，这些脚本一般由JavaScript、Python、Perl等语言生成。
|
||
|
||
#### 1.线性脚本
|
||
|
||
线性脚本是指通过手动执行测试用例得到的脚本，包括基本的鼠标点击事件、页面选择、数据输入等操作，线性脚本可以完整的进行回放。
|
||
|
||
#### 2.结构化脚本
|
||
|
||
结构化测试脚本在测试过程中具有逻辑顺序以及函数调用功能，如顺序执行、分支语句执行、循环等。结构化测试脚本可以灵活的测试各种复杂功能。
|
||
|
||
#### 3.共享脚本
|
||
|
||
在测试中，一个脚本可以调用其他脚本进行测试，这些被调用的脚本就是共享脚本，共享脚本可以使脚本被多个测试用例共享。
|
||
|
||
### 3.数据驱动测试
|
||
|
||
数据驱动模式实现了数据和脚本分离，相对于录制回放测试方法，数据驱动测试极大的提高了脚本利用率和可维护性，但是对于界面变化较大的情景不适合数据驱动测试。
|
||
|
||
数据驱动指的是从数据文件中读取输入数据并将数据以参数的形式输入脚本测试，不同的测试用例使用不同类型的数据文件。
|
||
|
||
#### 1.关键字驱动测试
|
||
|
||
关键字驱动是对数据驱动的改进，它将数据域与脚本分离、界面元素与内部对象分离、测试过程与实现细节分离。关键字驱动的测试逻辑为按照关键字进行分解得到数据文件，常用的关键字主要包括了被操作对象、操作和值。
|
||
|
||
#### 2.行为驱动测试
|
||
|
||
行为驱动测试指的是根据不同的测试场景设计不同的测试用例，需要开发人员、测试人员、产品业务分析等协作完成。行为驱动测试是基于当前项目的业务需求、数据处理、中间层进行的协作测试，它注重的是测试软件的内部运作变化，从而解决单元测试中实现的细节问题。
|
||
|
||
## 6.自动化测试的常用工具
|
||
|
||
### 1.selenium
|
||
|
||
Selenium是当前针对Web系统的最受欢迎的开源免费的自动化工具，它提供了一系列函数支持Web自动化测试，这些函数非常灵活，它们能够通过多种方式定位UI元素，并将预期结果和实际表现进行比较。
|
||
|
||
selenium主要特点：
|
||
● 开源、免费
|
||
● 支持多平台：Window、Mac、Linux
|
||
● 支持多语言：java、Python、C#、PHP等
|
||
● API使用简单，开发语言驱动灵活
|
||
● 支持分布式测试用例执行
|
||
|
||
### 2.Katalon
|
||
|
||
Katalon Studio是一个非常有魅力的自动化测试解决方案，它其实是构建在Selenium和Appium框架上的，可以同时测试Web系统及手机APP应用。Katalon Studio工具支持不同编程水平的工程师使用。即使不会编程的也可以使用它轻松的开始一个项目的自动化，会编程的和高级自动化测试工程师可以通过Katalon工具快速创建新库以及维护代码，从而节省很多时间。
|
||
|
||
### 3.UFT（Unified Functional Testing）
|
||
|
||
UFT是商业的软件自动化测试和回归测试工具，其前身是QTP（QuickTest Professional）。QTP在更新至11.5版本时将HP QuickTest Professional与HP Service Test整合为一个测试工具，并命名为UFT。
|
||
|
||
## 7.持续集成测试主要思想是什么
|
||
|
||
与传统集成不同，在持续集成中，开发人员会频繁地向主干提交代码，这些新提交的代码首先经过编译和自动化测试验证，然后合并到主干。
|
||
|
||
|
||
|
||
## 8.持续集成过程
|
||
|
||
CI是在源代码变更后自动检测、拉取、构建以及进行单元测试的过程。持续集成的目标是快速确保开发人员新提交的代码是合格的，并且适合在代码库中进一步使用。CI的流程执行和理论实践可以确定新代码和原有代码能否正确地集成在一起并通过测试。
|
||
|
||
## 9.持续集成测试框架
|
||
|
||
### 1.传统持续集成框架测试
|
||
|
||
|
||
|
||
在传统持续集成框架中，最核心的部分是通过集成工具实现自动化测试的调度管理。在启动测试之前，测试所需要的数据、测试用例、测试框架已经搭建完毕，并且项目通过编译，若测试项目使用服务器和数据库，这些资源也需要配备完成。
|
||
|
||
### 2.持续集成容器化框架设计
|
||
|
||
基于容器的持续集成平台在环境搭建上耗时少于传统的持续集成系统搭建，可以在秒级内启动一个镜像生成一个持续集成环境。容器占用资源少并且保证了开发环境和测试环境的统一，降低了测试重复率，极大的提高了测试效率。
|
||
|
||
使用Docker容器搭建持续集成测试环境框架。
|
||
|
||
|
||
|
||
使用容器技术进行测试方便应用的部署以及不同场景下的测试，即一次构建随处运行。此外，容器技术在提高测试效率的同时降低了企业项目花费的成本、加快了开发速度。 |