首页  思维导图  详情

软件测试

2021-06-16 08:57:03   197  举报





AI智能生成

为你推荐

查看更多



软考-系统架构（分析）-软件工程-测试分类

软件测试流程图

软件测试

软件开发测试全流程

软件测试是软件开发过程中不可或缺的一环，其目的是发现并修复软件中的错误和缺陷，提高软件的质量和可靠性。软件测试包括功能测试、性能测试、安全测试等多个方面，通过模拟各种场景和使用情况来验证软件的正确性和稳定性。在软件测试过程中，测试人员需要制定详细的测试计划和测试用例，并进行测试执行和结果分析。只有经过充分的测试，才能确保软件能够满足用户的需求和期望，避免因软件问题而造成的损失和影响。因此，软件测试是保障软件开发成功的重要环节，也是提高用户体验和企业竞争力的关键因素之一。

作者其他创作

大纲/内容

软件测试

25 代码测试基础理念和方法

代码级测试是一套方法的集合

一种方法解决一部分问题

综合运用多种方法解决全部问题

常见错误类型

有特征错误

语法特征错误

边界行为特征错误

特定边界值错误

经验特征错误

与常规做法有明显差异

无特征错误

算法错误

与预想结果不一致

部分算法错误

代码测试中比例最大

部分情况下与预期不符

代码级测试方法

静态方法

人工静态

方法

代码跑查

相互review

理论上可以发现所有错误，但实际效果不理想

缺点

过度依赖评审人员能力，同样流程发现问题悬殊

自己跑查，容易陷入思维惯性

完全人工，效率较低

自动静态

定义

不运行代码，通过词法、语法、控制流分析等实现的代码分析技术

可以发现有特征错误

动态方法

人工动态

设计输入和预计输出，执行代码判断结果

善于发现无特征错误

一般是单元测试

自动动态

自动生成边界测试用例

26 静态测试方法

通过PR方式进行同行评审的方式最常用

特点

比编译器更加严格

不检验代码逻辑，基于规则去发现问题

不实际执行代码，可能存在误报率

java检测工具sonar的使用效果

27 动态测试方法

单元测试的难点

输入参数复杂性

预期输出复杂性

依赖代码不可用

通过桩代码模拟

定义各种数据类型的典型值和边界值

根据被测函数的原形，生成测试用例代码模板

28 不同视角的软件性能与性能指标

不同类型系统，性能关注点不同

web和手机应用，关注端对端响应时间

非交互式的应用，关注事件处理速率，单位时间吞吐量

四类不同对象群体

终端用户

系统响应时间

系统处理

数据库处理

网络传输

前端展现时间

运维人员

并发访问时的负载

高负载下的系统健康情况

长期运行稳定性

可能的瓶颈

数据库调优

系统配置调优

软件设计人员

算法设计

内存泄漏

线程安全

资源竞争

架构设计

应用集群

缓存集群

数据库集群

性能最佳实践

数据压缩

加密

代发语言最佳实践

数据库相关

必要的索引

sql语句性能

读写分离

数据库承载压力

可测试性

为性能分析提供接口

高并发性能打点

全链路性能分析

性能测试人员

性能需求抽象

性能测试场景设计

性能脚本开发

性能报告分析

性能测试数据设计

软件性能常见指标

并发数

业务层面并发用户数

接口层面的并发请求

响应时间

吞吐量

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 各个阶段有有哪些自动化测试技术

各个阶段都有自动化测试

单元测试的自动化

除了用例执行自动化还包含

用例框架代码自动生成

部分输入数据自动生成

自动桩代码生成

能支持“抽桩”

自动化静态分析

测试覆盖率自动统计与分析

代码级集成测试

不使用桩代码

界面工具

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

页面对象自动生成

GUI 测试数据自动生成

自动生成测试输入数据

自动完成多个测试数据的笛卡尔积组合，再以人工的方式剔除掉非法

无头浏览器

拥有完整的浏览器内核，包括 JavaScript 解析引擎、渲染引擎等

测试执行速度更快

减少对测试执行的其他界面干扰（系统意外弹出等）

简化测试执行环境的搭建

在单机环境实现测试的并发执行

不能完全模拟真实的用户行为

17 测试稳定性的关键技术

要提高GUI稳定性，先找出因数，再给出对应的解决方案

不稳定因数

非预计的弹出对话框

进入异常场景恢复

页面属性细微变化

模糊识别

引入规则引擎

A/B测试

测试脚本做分支处理

随机页面延时

加入重试

测试数据问题

18 GUI自动化的测试报告

早期基于视频

主要问题

体积比较大

没有相关的日志

理想的测试报告

一系列时间顺序的屏幕截图

高亮所操作元素

开源框架可以通过hook实现高亮