软件开发流程
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
