【笔记整理】测试方法与理论笔记

软件开发流程

1.软件:程序、文件、文档、数据

2.软件开发流程演变:传统瀑布模型→敏捷开发模型→DevOps模型

3.瀑布模型

瀑布模型流程:需求分析→设计→编码→实现→软件测试→完成→维护

瀑布模型特点:线性

瀑布模型优点:阶段清晰、强调早期计划和需求调查、适合需求稳定产品

瀑布模型缺点:增加开发风险、错误发现晚

4.敏捷开发模型

敏捷开发模型:XP、SCRUM

极限编程-XP:分多个周期

编程方法:简单设计、结对编程、测试驱动开发、重构

小组实践:代码集体所有、编码标准、稳定高速的步伐、持续集成、隐喻

交付和管理:小规模发布、计划游戏、完整的团队、现场客户

SCRUM:产品backlog、sprint计划会议、sprint backlog→2-4周sprint、潜在交付产品增量

敏捷模型特点:增量迭代、小步快跑

5.Devops

DevOps:开发、测试、运维

DevOps生命周期:持续开发、持续测试、持续集成、持续部署、持续监控

DevOps特点:减少变更范围、加强发布协调、自动化

持续集成(CI) 持续交付(CD)

软件测试概念

1.软件测试原则:测试显示缺陷的存在、穷尽测试是不可能的、测试尽早介入、缺陷集群性(2/8原则)、杀虫剂悖论、测试活动依赖于测试内容、没有错误是好是谬论

2.软件测试模型:V模型、W模型

3.V模型

V模型:需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试

V模型优点:既有底层测试又有高层测试、开发阶段清晰

V模型缺点:误解为测试是在开发后进行的阶段

4.W模型

W模型:测试开发并行、测试伴随整个软件开发周期(包括需求、设计)

用户需求→需求分析→概要设计→详细设计→编码→集成→实施→交付

验收测试设计→确认与系统测试设计→集成测试设计→单元测试设计→单元测试→集成测试→确认测试系统测试→验收测试

W模型优点:测试贯穿整个项目周期、更早介入早发现问题、测试开发并行

W模型缺点:无法支持迭代的开发模型、有些项目无文档产出、对需求和设计的测试技术要求高

5.H模型

H模型:把测试活动完全独立出来

测试准备→测试就绪点→测试执行→测试流程

H模型优点:完全独立并发进行、今早准备执行灵活

H模型缺点:测试就绪点分析困难、对人员要求高

测试流程体系(软件项目管理)

1.需求分析→测试计划(计划评审)→测试用例(用例评审)→集成测试(准备测试数据、准备自动化测试用例)→搭建测试环境(补充测试数据、功能测试、自动化测试)→系统测试报告(缺陷报告)

2.开发→单元测试→集成测试→持续集成→冒烟测试→系统测试→验收测试→发布→持续监控

3.软件测试流程:传统测试流程、测试左移(开发)和测试右移(运维)

4.传统测试流程:

单元测试→集成测试→冒烟测试→系统测试→回归测试→验收测试

系统测试流程:需求分析→测试计划→测试设计(用例)→用例评审→测试执行→bug管理→发布维护

Bug管理流程:提交缺陷→指派缺陷→确认缺陷(是)→推迟处理(是)→遗留缺陷(后续版本处理)→处理缺陷→回归缺陷(通过)→关闭缺陷

确认缺陷(是)→推迟处理(否)→处理缺陷→回归缺陷(通过)→关闭缺陷

确认缺陷(否)→回归缺陷(通过)→关闭缺陷

回归缺陷(未通过)→重新打开→确认缺陷

5.测试左移(开发)和测试右移(运维):

测试左移:开发早期介入、代码测试、预防bug

质量保障手段:代码评审、代码审计、单元测试、自动化冒烟测试、研发自测

测试右移:发布之后、线上监控

质量保障手段:闭环的线上问题反馈检查解决更新流程、查看日志、log快速定位

需求分析

查看需求文档-模拟宣讲-需求评审

1.需求评审

业务场景角度:

用户故事(站在用户使用角度)

业务流程图(业务整体流程逻辑)

功能点角度:

数据约束是否全面、合理

存在分支的逻辑、描述是否覆盖所有路径

多状态流程,状态流转描述是否合理且完整

权限描述是否明确

2.需求分析

明确测试范围

明确功能点

明确业务流程

明确输出结果

分析异常流程

预估测试需要的时间和资源

测试技术体系

1.软件测试分类:

按开发阶段分类:单元测试、集成测试、系统测试(功能测试、兼容性测试、性能测试、安全测试)、验收测试(α测试、β测试)

按是否查看代码分类:黑盒测试、白盒测试、灰盒测试

按测试执行方式分类:静态测试(查看代码文档)、动态测试(运行程序)

按是否手工执行分类:手工测试、自动化测试

其他分类:冒烟测试、回归测试、随机测试、探索性测试

2.分层测试体系:

70%单元测试、20%服务测试(接口)、10%用户界面测试(UI)

单元测试方法:java(JUnit、TestNG)python(unittest、pytest)

接口测试(API):接口输入输出的测试→Charles、Fiddler、postman、Jmeter、loadRunner、python(Requests、HttpRunner)、java(HttpClient、RestAssured)

用户界面测试(UI):手工方式(人工)、自动化方式(web:selenium、app:appium)

常用测试平台

测试用例管理与bug管理平台:jira、redmine、testlink、tapd、云效、禅道、gitlab

代码管理平台:gitlab、subversion、github、bitbucket

持续集成管理平台:jenkins、gitlab runner、github action、自建devops平台

1.JIRA

JIRA基本功能模块

Project 项目(产品、用例管理、bug管理)

Issue 问题(任务)

Field 字段(任务的属性)

Workflow 工作流(任务状态)

Screen 视图(字段的合集)

测试用例设计

测试用例概念:测什么?怎么测?

测试用例组成:用例编号、测试模块、测试点、前提条件、测试步骤预期结果、实际结果

测试用例等级:P0(核心-冒烟)、P1(高优先级-基本功能)、P2(中优先级-异常、边界、中断、网络、容错、UI)、P3(低优先级-性能、压力、兼容性、安全性、可用性)

测试用例设计工具:思维导图、excel

测试用例设计方法

白盒测试方法论

1.根据待测产品的内部实现细节来设计测试用例

2.白盒测试手段:涵盖单元测试、集成测试

3.白盒测试度量:代码覆盖率

4.代码覆盖率常见概念

语句覆盖:每行代码都要覆盖至少一次

判定覆盖:判定表达式的真假至少覆盖一次

判定/条件覆盖:判定覆盖与条件覆盖都必须覆盖

条件组合覆盖:判定表达式中的所有条件组合都需要覆盖

分支覆盖:控制流中的每条边都要被覆盖一次

路径覆盖:所有的路径都要尽量覆盖

指令覆盖:一行代码会被编译为多条指令,尽可能的覆盖所有指令

方法覆盖:每个方法至少被覆盖一次

类覆盖:每个类至少被覆盖一次

文件覆盖、模块覆盖等等扩展覆盖

5.覆盖率统计工具:emma、cobertura、jacoco

6.流程覆盖

利用代码执行流代表流程

流程覆盖用路径覆盖率表达

对流程进行裁剪获得一个适合业务的小规模的业务子集

流程覆盖率=测试经过的路径/业务子集路径

7.精准化测试(控制流延申)

代码调用链与黑盒测试用例的关联

根据代码变更自动分析影响范围

黑盒测试过程中借助代码流程覆盖数据指导探索式测试

利用线上数据推导有效测试用例

代码流程分析与覆盖率统计

黑盒测试方法论

1.常用测试方法:等价类划分、边界值分析、因果图与判定表(决策树-流程图)、场景法

2.等价类划分法:集合划分(有效等价类、无效等价类)

等价类划分设计步骤:先划分等价类、有效等价类、无效等价类、挑选测试用例数据

可能数据:整数、小数、字母、汉字、符号、空格、回车、不输入

等价类表

需求:[1,100]加法
--- ---
1. 1-100整数
2. 两个输入框
输入条件 
1-100整数
有效等价类 
 [1,100]整数 
无效等价类
<1整数  >100整数  小数  字母  汉字  特殊符号   空
边界值: 0、1、2、99、100、101

3.边界值分析法:等价类划分的补充方法,通常同时使用

编号 所属等价类 输入框1 输入框2 预期结果
1 有效 1 100 101
2 有效 2 99 101
3 有效 99 2 101
4 有效 100 100 101
5 无效 0 40 给出错误提示
6 无效 40 0 给出错误提示
7 无效 101 50 给出错误提示
8 无效 50 101 给出错误提示
9 无效 3.23 45 给出错误提示
10 无效 45 3.23 给出错误提示
11 无效 ab 11 给出错误提示
12 无效 11 ab 给出错误提示
13 无效 34 给出错误提示
14 无效 34 给出错误提示
15 无效 % 56 给出错误提示
16 无效 56 % 给出错误提示
17 无效 78 给出错误提示
18 无效 78 给出错误提示

4.因果图:利用图解法分析输入的各种组合情况,从而设计测试用例的方法,适合检查程序输入条件的各种组合情况。因-输入条件,果-输出结果。

基本符号:c1-e1恒等 c1~e1非 c1/c2/c3ve1或 c1/c2^e1与

约束条件:E互斥(至多1个)、I包含(至少1个)、O唯一(有且只有1个)、M屏蔽(有a无b)、R要求(有a必有b)

因果图设计步骤:找出所有输入条件(因)、找出所有输出条件(果)、输入条件之间的制约和组合关系、输出条件之间的制约和组合关系、输入条件组合产生的输出结果、因果图转化为判定表、设计测试用例

充值软件:投币50/100,充值50/100
输入条件 输出条件
1投币50 a完成充值退卡
2投币100 b提示充值成功
3充值50 c找零(退钱)
4充值100 d提示错误

输入条件:1和2互斥、3和4互斥,1、2、3、4、13、14、23、24(8)

输出条件:a和d互斥、b和d互斥,ab、abc、cd、d

1、2→cd 3、4→d 13、24→ab 14→cd 23→abc

编号 1 2 3 4 5 6 7 8
输入
1.投币50元 1 1 1
2.投币100元 1 1 1
3.充值50元 1 1 1
4.充值100元 1 1 1
输出
a.完成充值退卡 1 1 1
b.提示充值成功 1 1 1
c.找零(退钱) 1 1 1 1
d.提示错误 1 1 1 1 1

5.判定表组成:条件桩-问题的所有条件、动作桩-问题的所有输出、条件项-针对条件桩的取值、动作项-条件项的各种取值情况下的输出结果

判定表设计步骤:列出所有的条件桩和动作桩、确定规则数-每个条件桩的取值个数^条件桩个数、填入条件项、填入动作项得到初始判定表、简化判定表

判断三角形:三条边a、b、c,判断是否构成三角形、三角形的类型
条件桩 条件项2^4
C1:a、b、c是否构成三角形 1、0
C2:a=b? 1、0
C3:a=c? 1、0
C4:b=c? 1、0

动作桩 动作项
A1:不是三角形 1
A2:普通三角形 1
A3:等腰三角形 1
A4:等边三角形 1
A5:不可能出现 1

条件桩
C1:a、b、c是否构成三角形 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
C2:a=b? 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
C3:a=c? 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1
C4:b=c? 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
动作桩
A1:不是三角形 1 1 1 1 1 1 1 1
A2:普通三角形 1
A3:等腰三角形 1 1 1
A4:等边三角形 1
A5:不可能出现 1 1 1
条件桩
C1:a、b、c是否构成三角形 0 1 1 1 1 1
C2:a=b? - 0 0 1 1 1
C3:a=c? - 0 1 0 1 1
C4:b=c? - 0 1 1 0 1
动作桩
A1:不是三角形 1
A2:普通三角形 1
A3:等腰三角形
A4:等边三角形 1
A5:不可能出现 1 1 1

6.场景法:模拟用户操作软件时的场景,主要用于测试系统的业务流程。

用例场景定义:基本流-按照正确的业务流程来实现的一条操作路径、备选流-导致程序出现错误的操作流程

场景法用例设计步骤:根据需求规格说明画出功能模块流程图、根据流程图描述程序的基本流和备选流、根据基本流备选流生成不同场景构造场景列表、每个场景生成测试用例、生成的测试用例复审去掉多余用例、为测试用例确定测试数值

淘宝网购物流程:流程图
图片

确定基本流和备选流
基本流:进入淘宝网、不注册、浏览物品、选择物品购买、直接购买、是会员、填写验证码、付款到支付宝、等待收货、确认收货
备选流

注册,填写注册信息,验证通过

注册,填写注册信息,验证未通过

加入购物车,直接购买

加入购物车,继续选购

不是会员,填写注册信息,验证通过

不是会员,填写注册信息,未通过验证

测试方法的选择

需要输入数据的地方,考虑使用等价类划分法,将无限测试变成有限测试

任何情况下都必须采用边界值分析法

关注程序的主要功能、业务流程和业务逻辑是否正确实现,考虑使用场景法

如果含有输入条件的组合情况,考虑因果图判定表

采用错误推断法再追加测试用例

测试用例的粒度

掌握好用例复杂和简单的程度。

过于简单失去测试用例意义,过于复杂效率和维护成本的问题。

测试用例的作用

指导测试的实施、规划测试数据的准备、编写测试脚本的“设计规格说明书”、测试结果的度量基准、分析缺陷的标准

测试用例编写步骤

1.步骤:划分功能模块→正向功能验证→单个功能项验证→功能之间交互验证→隐形需求

2.数据约束:数据长度验证、数据类型验证、是否必填验证、限制约束验证

3.面试测试用例设计思路

需求分析、界面、功能、易用性、兼容性、性能、安全性

测试策略概念

在特定环境约束下,描述软件开发周期中关于测试原则、方法、方式的纲要,并阐述了它们之间如何配合,以高效地减少缺陷、提升质量

1.测试策略关注重点

测试的目的

测试可能存在的风险

测试对象和范围

如何安排测试活动

如何评价测试效果

BUG定位方法

1.常见BUG分类

功能:业务流程是否正确

性能:业务流程是否顺畅

安全:是否符合安全标准与规范

专项质量:用户体验 UX 兼容性 稳定性 可靠性

2.BUG定位能力

明确bug问题的现象与复现步骤

分层分析关键过程的数据与问题特征

积累bug特征与问题根源特性,丰富测试经验,提高发现bug能力

测试环境搭建

被测系统AUT

1.常见被测系统类型:UI、service、code

2.部署方法

打包部署:apk、app、ipa、jar、war

脚本部署:自动化脚本与自动化平台

容器部署:基于容器镜像 docker k8s(自动化构建-bash 容器构建-docker 容器编排-k8s 持续集成-jenkins)

系统架构与数据流

理解公司产品的整体架构-测试架构思维

1.业务架构

商业模式

业务流程:角色、资源、数据

系统架构:角色、行为、数据集成关系

2.系统架构

架构角色与技术栈

部署架构

3.使用统一建模语言UML(梳理业务逻辑关系)

用例图-梳理业务流程:商业模式、业务角色

时序图-分析数据流:业务流程、调用关系

部署图:系统架构与集成关系

活动图-分析测试用例:业务逻辑分析

思维导图(活动图)-分析功能点(流程、分类)

时序图

@startuml
Alice -> Bob: Hi
Alice <-- Bob: Hello
Alice -> Bob: How are you?
Alice <-- Bob: Fine
@enduml

图片

声明对象:actor、database
消息数字序号:autonumber
消息分组:alt-else-end

@startuml
autonumber
actor Kim
database db
Kim -> db: 发送请求
alt 第一种情况
Kim <-- db: 第一种结果
else 第二种情况
Kim <-- db: 第二种结果
else 第三种情况
Kim <-- db: 第三种结果
end
@enduml

图片

用例图

@startuml
left to right direction
:kim: as a
actor clerk as b
package actor {
actor anna
}
rectangle checkout {
usecase (checkout) as A
a -- A
A .> (payment) : include
(help) -> A : extends
A -- b
}
b - anna
@enduml

图片

活动图

@startuml
start
:进入登录界面; 
:输入账号;
repeat:输入密码;
:点击登录按钮;
if (校验?) then (正确)
	:登陆成功;
    stop
	else (错误)
	:登录失败,给出错误提示;    
    endif
:清空密码;
repeat while
stop
@enduml

图片

思维导图

@startmindmap
* 根节点
* 节点一
* 节点二
* 节点二
* 节点三
* 节点一
* 节点二
@endmindmap

图片

3 Likes

总结的很好呀,赞一个。

2 Likes