软件测试
2021-06-16 08:57:03 203 举报AI智能生成
软件测试是软件开发过程中不可或缺的一环，其目的是发现并修复软件中的错误和缺陷，提高软件的质量和可靠性。软件测试包括功能测试、性能测试、安全测试等多个方面，通过模拟各种场景和使用情况来验证软件的正确性和稳定性。在软件测试过程中，测试人员需要制定详细的测试计划和测试用例，并进行测试执行和结果分析。只有经过充分的测试，才能确保软件能够满足用户的需求和期望，避免因软件问题而造成的损失和影响。因此，软件测试是保障软件开发成功的重要环节，也是提高用户体验和企业竞争力的关键因素之一。
作者其他创作
大纲/内容
25 代码测试基础理念和方法
代码级测试是一套方法的集合
一种方法解决一部分问题
综合运用多种方法解决全部问题
常见错误类型
有特征错误
语法特征错误
边界行为特征错误
特定边界值错误
经验特征错误
与常规做法有明显差异
无特征错误
算法错误
与预想结果不一致
部分算法错误
代码测试中比例最大
部分情况下与预期不符
代码级测试方法
静态方法
人工静态
方法
代码跑查
相互review
理论上可以发现所有错误，但实际效果不理想
缺点
过度依赖评审人员能力，同样流程发现问题悬殊
自己跑查，容易陷入思维惯性
完全人工，效率较低
自动静态
定义
不运行代码，通过词法、语法、控制流分析等实现的代码分析技术
可以发现有特征错误
动态方法
人工动态
设计输入和预计输出，执行代码判断结果
善于发现无特征错误
一般是单元测试
自动动态
自动生成边界测试用例
26 静态测试方法
人工静态
通过PR方式进行同行评审的方式最常用
自动静态
特点
比编译器更加严格
不检验代码逻辑，基于规则去发现问题
不实际执行代码，可能存在误报率
java检测工具sonar的使用效果
27 动态测试方法
人工动态
单元测试的难点
输入参数复杂性
预期输出复杂性
依赖代码不可用
通过桩代码模拟
自动动态
定义各种数据类型的典型值和边界值
根据被测函数的原形，生成测试用例代码模板
28 不同视角的软件性能与性能指标
不同类型系统，性能关注点不同
web和手机应用，关注端对端响应时间
非交互式的应用，关注事件处理速率，单位时间吞吐量
四类不同对象群体
终端用户
系统响应时间
系统处理
数据库处理
网络传输
前端展现时间
运维人员
并发访问时的负载
高负载下的系统健康情况
长期运行稳定性
可能的瓶颈
数据库调优
系统配置调优
软件设计人员
算法设计
内存泄漏
线程安全
资源竞争
架构设计
应用集群
缓存集群
数据库集群
性能最佳实践
数据压缩
加密
代发语言最佳实践
数据库相关
必要的索引
sql语句性能
读写分离
数据库承载压力
可测试性
为性能分析提供接口
高并发性能打点
全链路性能分析
性能测试人员
性能需求抽象
性能测试场景设计
性能脚本开发
性能报告分析
性能测试数据设计
软件性能常见指标
并发数
业务层面并发用户数
接口层面的并发请求
响应时间
吞吐量
29
30
31
32
33
34
35 如何准备测试数据
GUI 操作生成
缺点
创建测试数据的效率非常低
不适合封装成测试数据工具
测试数据成功创建的概率不会太高
会引入不必要的测试依赖
API 调用生成
目前是主流
好处
保证创建的测试数据的准确性
执行效率更高
封装成测试数据函数
不足
不是所有数据都有API支持
有时准备一个数据需要调用依次调用多个API
无法批量创建海量数据
数据库操作生成
把SQL 语句封装成一个个准备函数
缺点
往往需要修改多张表，维护成本高
容易出现数据不完整
业务逻辑发生变化，要同步更新准备数据函数
综合运用 API 和数据库的方式
36 测试数据的痛点
不同时机创建数据的痛点
测试过程中创建，耗时较长
测试之前准备好，容易产生脏数据
测试环境本身不稳定
实时创建on the fly
优点
用例自行维护，最大程度避免脏数据
缺点
比较耗时
数据的复杂关联，测试数据本身依赖其他数据
预先准备out of box
缺点
容易产生脏数据
其他用例修改了数据状态
手工测试影响
调试过程修改了数据
综合运用
死水数据
更适合预先准备
活水数据
更适合动态创建
37 统一数据测试平台 上
1.0 时代
测试数据准备封装成函数
默认缺省参数
多个不同的功能的准备函数
38 统一数据测试平台 下
2.0 时代
生成器模式 Build Pattern
指定数据类型
search only
从被测系统查找
create only
从被测系统新建
smart
先查找，没有就新建
out of box
查找out of box中数据
3.0 时代
Restful API 支持数据准备
swagger提供GUI文档
nosql数据表保存预创建数据
39 Selenum Grid
测试基础架构
执行测试过程中用到的所有基础硬件和软件
包括
执行测试的机器
测试用例代码仓库
发起执行的job
统一执行平台
测试依赖的其他服务
配置服务
测试报告服务
...
执行测试的机器
人工维护环境
缺点
需要记录安装的信息
不同机器区分浏览器版本
人工维护机器列表
难以并行操作
小作坊 一般30台机器以内
Selenum Grid
架构图
主从架构
单机搭建
docker搭建
40 测试执行架构 上
测试执行环境
狭义
执行机器集群
广义
还包括集群创建和维护
容量规划
测试发起控制
用例组织等
解决的问题
简化测试执行过程
docker解决
最大化测试执行机器资源利用率
提供大量用例并发执行能力
自动扩容解决
测试用例版本控制
友好的界面
CI CD集成机制
早期架构
架构图
本地调试执行
push到仓库
发起测试执行
经典架构
架构图
固定机器替换成selenum grid
41 测试执行架构 下
docker架构
架构图
主要创新
测试用例版本维护
提供API给CI CD
Jenkins 集群
架构图
负载自适应
架构图
如何选择架构
由需求驱动
用例数量较少，直接使用经典架构
用例数量较少，使用docker架构
42 大型全球电商测试基础架构设计
架构图
测试服务微服务化
统一执行服务
统一数据服务
环境准备服务
被测系统部署服务
测试报告服务
测试配置服务
43 发挥人的潜能 探索式测试
与招聘面试类比
探索式测试不是测试技术，而是测试风格
探索过程
设计最初测试用例
输出与预期输出的差异
根据差异再设计新用例
通过反复探索，发现缺陷
同时开展
测试学习
测试设计
测试执行
测试结果评估
强调测试工程师个人自由和责任，持续优化工作价值
即兴测试
不注重测试计划和设计
两种区别
不停的优化测试模型
如何开展
思维导图理清思路
基于反馈的测试方法
44 测试驱动开发TDD
45 精准测试
46 渗透测试
47 基于模型的测试
测试基础知识
01 - 11
GUI自动化测试
12 - 21
API自动化测试
22 - 24
代码测试
25 - 27
性能测试
28-34
测试数据准备
35-38
测试基础机构
39-42
测试新技术
43-47
互联网核心知识
48-52
01 你真的懂测试吗
设计测试用例
等价类划分
边界值分析方法
兼顾考虑非功能性需求
安全性
性能
兼容性
很难穷尽测试
时间成本、经济成本
基于风险驱动，寻求风险和研发成本的平衡
02 如何设计一个好的测试用例
什么好的的测试用例
误区
发现了缺陷的用例
大概率发现错误的用例
发现隐藏缺陷的用例
整体完备性
覆盖测试需求
等价类划分准确
边界值准确
缺陷像鱼，用例像网
常用用例设计方法
等价类划分法
用少量代表性数据覆盖结果
设计有效等价类，找出无效等价类
边界值分析法
子主题
错误推断法
探索性测试理念
缺点：过度依赖个人经验与能力
建立常见缺陷知识库，帮助优化补充用例
不同生命周期的各个阶段有不同测试类型
单元测试
集成测试
GUI测试
API测试
...
测试类型
黑盒测试
白盒测试
灰盒测试
用例设计其他经验
理解被测软件的架构
软件设计和实现的细节
引入需求覆盖率和代码覆盖率衡量测试完备性
03 如何做好单元测试
案例：组装电视机
最小可测试单元与其他部分相隔离的情况下进行验证
单元测试用例是“输入数据”和预期“输出”的集合
输入数据
函数输入参数
函数内部读取全局变量
函数内部读取的成员变量
函数内部调用子函数获得的数据
子函数改写的数据
...
预计输入
函数返回值
函数输出参数
函数改写的成员变量
函数改写的全部变量
函数进行的文件更新
函数进行的数据库更新
函数中的消息队列更新
...
常见名词
驱动代码
通常步骤
数据准备
调用被测函数
验证结果
桩代码
定义
代替真实代码的临时代码
作用
使被测试函数可以独立运行
控制测试执行路径
mock代码
与桩类似
详细区别查看 https://martinfowler.com/articles/mocksArentStubs.html
关系
常见困难
耦合代码难以隔离
隔离后编译运行困难
可测试性比较差，与代码规模成正比
无法通过桩代码模拟系统底层函数
代码覆盖率越后越难提高
04 为什么要做自动化测试
定义
把人对软件的测试行为转化为由机器执行测试行为的一种实践，可以解放手工操作
成本高
写一段代码去测试另一段代码，属于开发工作，需要投入大量时间与精力
随着被测对象，持续维护，不断更新
双刃剑，如果维护的成本高于节省的测试成本，就失去意义
好处
替代大量的手工机械重复性
大幅提升回归测试的效率
更好地利用无人值守时间，去更频繁地执行测试
可以高效实现某些手工测试无法完成或者代价巨大的测试类型
缺点
不能完全替代手工测试
比手工测试脆弱，无法应对被测系统的变化
开发工作量远大于单次的手工测试，至少执行5次以上才能收回成本
需要业务人员与测试人员紧密配合才能开展
什么项目适用自动化测试
需求稳定，不频繁更改
研发、维护周期长，需要频繁回归测试
手工难以实现，手工成本太高
压力测试
稳定性测试
05 各个阶段有有哪些自动化测试技术
各个阶段都有自动化测试
单元测试的自动化
除了用例执行自动化还包含
用例框架代码自动生成
部分输入数据自动生成
自动桩代码生成
能支持“抽桩”
自动化静态分析
测试覆盖率自动统计与分析
代码级集成测试
不使用桩代码
API测试
界面工具
Postman
SoapUI
测试框架
除了执行自动化，还包含
脚手架代码自动化生成
部分测试输入数据自动生成
response验证自动化
自动比较两次API返回结果，识别差异字段，去除特定动态值
基于SoapUI或Postman的自动化脚本生成
GUI测试自动化技术
分为web浏览器与移动端原生应用
技术实现差异大
但用例设计思路类似
web浏览器自动化测试
开源的selenium
商业方案UFT
移动端自动化测试
Appuim
06 你真的懂测试覆盖率吗
测试覆盖率通常被用来衡量测试的充分性和完整性
需求覆盖率
需求与测试建立映射关系
代码覆盖率
至少被执行了一次的条目数占整个条目数的百分比。
如果“条目数”是语句，对应的就是代码行覆盖率
如果“条目数”是函数，对应的就是函数覆盖率
如果“条目数”是路径，那么对应的就是路径覆盖率
指标
行覆盖率
分支覆盖(判定覆盖)
条件覆盖
统计覆盖率仅仅是手段
测试的成本会随着代码覆盖率的提高以类似指数级
局限性
基于已有代码，无法发现未处理的情况
实现原理
使用代码注入
07 如何高效填写缺陷报告
缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁
缺陷报告质量的影响
缺陷被修复的速度
开发工程师的效率
测试工程师的信用
测试与开发人员协作的有效性
好的缺陷报告
绝对不是大量信息的堆叠
而是以高效的方式提供准确有用的信息
应该包含的内容
缺陷标题
概括性描述，通常采用“在什么情况下发生了什么问题”的模式
尽可能描述问题本质，而避免只停留在问题的表面
只描述表面
商品金额输入框，可以输入英文字母和其他字符
描述本质
商品金额输入框，没有对输入内容做校验
拒绝笼统
搜索功能有问题
登录不正常
提交之前可以查阅是否有人已提，作为索引
不易过长
缺陷概述
提供更多概括性的缺陷本质与现象的描述
缺陷影响
影响范围
优先级
严重程度
要对场景和需求有理解
环境配置
详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息
系统
版本
浏览器种类
特定用户
...
只描述那些重现缺陷的环境敏感信息, 无关的细腻系不用描述
前置条件
减少缺陷重现步骤的描述
合理地使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰，使其更有针对性。
重现步骤
缺陷报告的核心
用简洁的语言向开发工程师展示缺陷重现的具体操作步骤
每个步骤是可操的、连贯的，往往采用步骤列表
避免
笼统的描述，缺乏可操作的具体步骤
出现与缺陷重现不相关的步骤
缺乏对测试数据的相关描述
预期结果和实际结果
预期结果
来自于对需求的理解
说明应该发生什么，而不是什么不应该发生
实际结果
来自于测试执行的结果
你应该说明发生了什么，而不是什么没有发生
严重程度与优先级
看起来有点类似，而本质却完全不同
严重程度是缺陷本身属性，通常确定后不再变动
优先级是工程属性，会随着项目进度、解决缺陷的成本等因素而变动
两者关系
缺陷越严重，优先级就越高
缺陷影响的范围越大，优先级也会越高
不影响用户，但影响测试等，属于典型的严重程度低，但是优先级高
有些虽然严重程度比较高，但考虑到修复成本、技术难度等，也可能优先级低
变通方案
一种临时绕开当前缺陷而不影响产品功能的方式
有无以及实施的难易程度，是决定缺陷优先级和严重程度的重要依据
根原因分析
定位出问题的根本原因，清楚地描述缺陷产生的原因
缺陷的效率就会大幅提升，技术影响力也会被开发认可
附件
截图
日志
视频
对于难以描述
截图并高亮显示应该关注的区域
使用缺陷重现视频
08 如何做好测试计划
没有测试计划会怎么样
很难确切地知道具体的测试范围，以及应该采取的具体测试策略
难以预估工作量
整体进度完全不可控，难以知道测试进度，难以预估完成时间
对潜在风险的抵抗能力很弱，难应对需求的变更以及其他突发事件
测试范围
需要明确“测什么”和“不测什么”
测试策略
先测什么后测什么，如何来测
要求我们明确测试的重点，以及各项测试的先后顺序
功能测试
根据测试需求分析的思维导图来设计测试用例
先实现主干业务流程的测试自动化
兼容性测试
确定设备类型、系统版本呢
如何确定
分析产品使用TOP30%
通过 TalkingData 等网站统计数据
通常系统稳定以后再做
性能测试
明确了性能需求
性能测试报告，是最关键的点
测试资源
明确“谁来测”和“在哪里测”这两个问题
根据不同等级、不同经验的人员，做不同的任务划分
测试进度
开始时间，所需工作量，预计完成时间，确定发布时间
需要几轮回归测试、每一轮回归测试的工作量
很多测试工作会和开发工作同步进行
测试风险预估
测试风险的主要原因
需求变更
开发延期
重大缺陷
人员变动
...
制定应对策略
09 测试人员的核心竞争力
测试人员，必须深入理解业务，但是业务知识不能等同于测试能力
试开发岗位的核心其实是“测试”，“开发”的目的是更好地服务于测试
功能测试工程师
测试策略设计
对于不同的项目，快速理解需求，有限时间和资源下，明确重点，确定测试方法
大量实践上潜移默化的
测试用例设计
能设计出高效地发现缺陷，保证产品质量的优秀测试用例
对常见的缺陷模式、典型的错误类型以及遇到过的缺陷，要不断地总结、归纳，才能逐渐形成体系化的用例设计思维
对于缺陷举一反三
快速学习
不同业务需求和功能的快速学习与理解能力
测试新技术和新方法的学习与应用能力
探索性测试思维
基于错误猜测和逻辑推理, 整理和分析出更多的有针对性的测试关注点
有针对性地对变更点以及变更关联点做测试
缺陷分析
预测或者定位缺陷的发生原因，大幅缩短缺陷的修复周期
推断同类缺陷存在的可能性，找出所有相关的潜在缺陷
对高频缺陷类型提供系统性的发现和预防措施，调整后续的测试策略
自动化测试技术
从大量的重复性手工劳动中解放出来
自动化测试的核心价值还是“测试”本身，“自动化”仅仅是手段
沟通能力
测试开发工程师
代码开发能力是最基本的要求
宽广的技术知识体系
10 测试人员需要掌握的非业务能力
开发工程师通常是“深度遍历”，关注的是“点”
测试工程师通常是“广度遍历”，关注的是“面”
网站架构
容器技术
云计算技术
CI/CD流水线
前端开发技术
11 互联网产品的测试策略如何设计
通常情况下，互联网产品要求全回归测试的执行时间不能超过 4 小时
互联网产品特点是“快”
传统产品
三角形
互联网产品
菱形
全面单元测试只应用在那些稳定和最核心的模块上
12 第一个GUI自动化测试
Selenium 工作原理
Selenium 1.0
JavaScript Remote control
Selenium 2.0
使用浏览器原生的 WebDriver 实现页面操作
13 脚本与数据的解耦 PageObject模型
数据驱动测试
减少大量重复脚本，测试脚本和数据的解耦
不仅可以包含测试输入数据，还可以包含测试验证结果数据
不仅适用于 GUI 测试，还可以用于 API 测试、接口测试等
页面对象模型
以页面为单位来封装页面上的控件以及控件的部分操作
测试用例就是函数操作，基于页面封装对象来完成具体的界面操作
设计进化
1.0
2.0
3.0
14 脚本更好的描述业务
把控操作函数的粒度
抽象出“高内聚低耦合”操作步骤集合
业务流程抽象
基于操作函数的更接近于实际业务的更高层次的抽象方式
15 GUI自动化过程中的测试数据
创建测试数据
技术手段
API 调用
数据库操作
两者结合
创建时机
例执行过程中，实时创建测试数据 on-the-fly
测试用例执行前，事先创建好 out-of-box
16 PageCodeGen DataGen Headless
页面对象自动生成
提供 Web 的 URL,自动帮你生成这个页面上所有控件的定位信息，并自动生成 PageClass
GUI 测试数据自动生成
自动生成测试输入数据
自动完成多个测试数据的笛卡尔积组合，再以人工的方式剔除掉非法
无头浏览器
拥有完整的浏览器内核，包括 JavaScript 解析引擎、渲染引擎等
好处
测试执行速度更快
减少对测试执行的其他界面干扰（系统意外弹出等）
简化测试执行环境的搭建
在单机环境实现测试的并发执行
缺点
不能完全模拟真实的用户行为
17 测试稳定性的关键技术
要提高GUI稳定性，先找出因数，再给出对应的解决方案
不稳定因数
非预计的弹出对话框
进入 异常场景恢复
页面属性细微变化
模糊识别
引入规则引擎
A/B测试
测试脚本做分支处理
随机页面延时
加入重试
测试数据问题
18 GUI自动化的测试报告
早期基于视频
主要问题
体积比较大
没有相关的日志
理想的测试报告
一系列时间顺序的屏幕截图
高亮所操作元素
开源框架可以通过hook实现高亮
相关操作步骤描述
19 大型项目中设计GUI自动化测试策略
自动化测试策略设计
从前端组件的级别来保证质量
自定义开发的组件进行完整全面的测试
每个模块，建立页面对象库，封装业务流程，再组装测试用例
自动化测试脚本管理
20 移动应用测试方法与思路
略
21 带你玩转Appium
略
22 API测试怎么做？常用API测试用户简介
API 测试的基本步骤主要
准备测试数据
通过 API 测试工具，发起对被测 API 的 request
验证返回结果的 response
API测试工具
常见的命令行工具 cURL
图形界面工具 Postman
API 性能测试的 JMeter
Newman 工具直接执行 Postman 的 Collection
23 API自动化测试框架的前世今生
早期的基于 Postman 的 API 测试
界面不利于批量执行
无法与CI CD结合
基于 Postman 和 Newman 的 API 测试
可以使用命令行执行
但无法解决多个接口间的参数依赖
基于配置的API测试
Rest-Assured
httprunner
代码的API测试
基于 Java 的 OkHttP 和 Unirest
基于 Python 的 http.client 和 Request
基于 NodeJS 的 Native 和 Request 等
...
自动生成 API 测试代码
把Postman的Collection换成API 框架的代码模板
Response 结果发生变化时的自动识别
内建数据库，推荐非关系数据库
下次发送相同request时，自动和上次的 response 做差异检测，对差异自动告警
24 微服务模式下API测试要怎么做
单体架构
灵活性差
编译打包都要花费很长
可扩展性差
无法以模块为单位灵活扩展容量
稳定性差
何一个模块有问题时，都可能会造成应用整体的不可用
可维护性差
代码的复杂性也是直线上升
微服务架构
一个大型复杂软件系统不再由一个单体组成，而是由一系列相互独立的微服务组成，不同服务之间通过一些轻量级交互机制进行通信
特点
每个服务运行在其独立的进程中，开发采用的技术栈也是独立的
服务间采用轻量级通信机制进行沟通，RPC、HTTP
每个服务都围绕着具体的业务进行构建，并且能够被独立开发、独立部署
对运维提出了非常高的要求，促进了 CI/CD 的发展与落地
测试挑战
过于庞大的测试用例数量
使用基于消费者契约的 API 测试
微服务之间的耦合关系
0 条评论
下一页
