1. 软件
1.1 软件的定义
软件是运行在硬件上，一段指令的集合
1.2 软件的分类
系统软件：系统自带的软件
应用软件：
- 移动端（APP）软件
- 电脑端（PC）软件
- 平板电脑端（pad）软件
前端
C/S
PC exe --- 指Windows操作系统下的可执行文件
APP IPA --- 指iOS应用程序包文件，扩展名为.ipa，包含了iOS应用程序的所有资源和代码。
B/S
URL --- 统一资源定位符，指向互联网上资源的地址，通常用于访问网页或下载文件。
后端
IP地址 --- 互联网协议地址，用于唯一标识网络中的设备，分为IPv4和IPv6两种类型，便于设备之间进行通信。
1.3 软件是如何产生的
1.4 软件生命周期
1.4.1 研发类项目
产品类型：
- 自研自用
- 自研他用（商品化）
- 外包 1.项目 2.人力
1.4.2 更新迭代项目
迭代
根据功能大小定义： 大迭代 小迭代
根据软件版本号定义（大版本更新1.1.1-2.1.1，小版本更新1.1.1-1.1.2 1.1.1-1.2.1）
小版本迭代一般一周一次或两次，大版本迭代一般两周一次或者一个月一次
1.5 测试环境
什么是环境：项目运行所需要的所有的软件和硬件组合
| 开发环境 --- DEV环境 | 是开发进行软件开发的工作环境 |
| 测试环境 --- SIT环境（大型公司/金融公司 使用） | 是模拟生产环境在公司内网建立的一套专用于软件测试的环境。 |
| 验收环境 --- UAT环境 （在大型商业公司或者银行项目居多） | 用户为主的测试 是客户或者甲方产品人员对测试完成的软件进行验收测试，主要测试功能和设计是否符合用户和甲方的预期 |
| 准生产环境 | 与生产环境高度相似的环境。 一般用来在生产上线前在准生产环境进行主功能和代码版本的验证 |
| 生产环境 | 真实用户环境 |
1.6 软件开发/测试模型
1.6.1 瀑布模型
优点：
严格规定每一阶段必须提交的文档，项目的推进必须按照一定顺序来做
缺点：
- 各个阶段的划分完全固定，阶段之间产生大量文档，极大的增加工作量
- 用户等到项目末期才能看到开发结果
- 测试工程师后期才能参与到项目中，测试介入较晚，人员闲置严重，后续工作跟不上
速记：
阶段（阶段划分----结果） ---- 用户 ---- 测试工程师
1.6.2 V模型
是一种软件开发流程模型，强调了开发和测试的并行性。它在传统的瀑布模型基础上进行了扩展，形状类似字母“V”
优点：
包含了从底层（单元测试）到顶层的测试（验收测试） 更清楚的标识了开发和测试的各个阶段 自上而下逐步求精，每个阶段分工明确，便于整体 项目的把控。
缺点：
自上而下的顺序导致测试工作在编码后，不能及时的进行修改 实际工作中，需求经常变化，导致V模型步骤反复执行 ，返工量很大，灵活度较低。
1.6.3 W模型（双V模型）
两个V字型模型组成，分别代表测试 与开发过程，测试的活动与软件开发同步进行，相对与V模型可尽早发现软件缺陷可降低软件开发的成本
优点：
- 修复成本低（提高效率）
- 分阶段工作，方便项目的整体管理
缺点：
开发和测试依然是线性的关系，需求的变更和调整，依然不方便。
1.6.4 敏捷模型 （一般适用于更新迭代类项目）
软件项目在构建初期被拆分为多个相互联系而又独立运行的子项目,开发过程中,各个子项目都要经过开发测试。当客户有需求变更时,敏捷模型能够迅速地对某个子项目做出修改以满足客户的需求。
敏捷模型是为了对应敏捷开发才提出的概念，
敏捷开发最大的特点是高度迭代，周期性强，能够及时的、持续的响应需求的频繁变更反馈；
敏捷测试即是不断修正被测对象的质量指标，正确建立测试策略，确认客户的有效需求得以圆满的实现和确保整个生产过程安全、及时地发布最终产品
2. 软件测试基础知识
2.1 软件测试的定义
利用一定的技术手段，检测被测软件是否满足需求
2.2 软件测试的目的
通常有以下方面：
1、发现被测对象与用户需求的差异，即缺陷；
2、通过测试活动发现并解决缺陷；
3、通过测试活动了解被测对象的质量状况；
4、通过测试活动积累经验，预防缺陷的出现，降低产品失败风险；
通俗说就是找bug，
修复bug 提升质量
累积经验 预防缺陷 降低风险
2.3 缺陷的定义
bug：存在于程序代码或硬件系统中的错误
可以是静态形式存在，也可以在特定诱因下存在（偶现bug）
2.4 缺陷产生的原因（重点）
一般由以下原因：
①因为需求表述、理解、编写引起的错误； 不符合需求
②系统架构引起的错误；
③开发过程中缺乏有效沟通及监督
④程序员编程产生的错误 编程
⑤软件开发工具本身隐藏的问题
⑥软件复杂度越来越高
⑦于用户需求不符 不符合用户需求
⑧外界环境原因造成
2.5 软件缺陷报告
2.5.1 缺陷的要素
缺陷ID、概要描述（简单描述缺陷的存在形式及表现）、发现人、发现时间、修复时间、所属版本（发现缺陷时，缺陷所在的版本）、所属模块（缺陷所在的功能或业务模块 ）、缺陷状态、缺陷严重程度、指派人（缺陷下一步处理的人员，一般是开发人员）、详细描述（操作步骤、预期结果、实际结果，执行操作时的用户数据或者系统流水号）、附件（执行操作时候的截图）
2.5.2 缺陷的状态--- 缺陷的生命周期
| 新建状态 | new | 刚提出的缺陷 |
| 打开状态 | open | 经过开发/测试经理确认有效后 |
| 修复中 | fix | 开发人员确认缺陷后就要进入到修复过程 |
| 已修复 | 开发人员修复完毕 | |
| 待验证 | 此缺陷可以进行验证 | |
| 关闭 | close | 确认缺陷被成功修复 |
| 重新打开 | reopen | 验证后，缺陷未修复好 |
| 拒绝 | reject | 开发不认可测试提出的缺陷 |
2.5.3 缺陷的严重程度
| 致命 | 引发大面积的功能错误，甚至系统崩溃 |
| 严重 | 主功能 主流程序错误 |
| 一般 | 当前功能无法正常使用 |
| 轻微 | 图片显示，字体显示，错别字，子功能实现错误 |
| 建议 | 后果不严重，用户使用不便 |
2.5.4 缺陷管理流程
2.5.5 缺陷管理工具
| 禅道 | 国产项目管理平台，包含了缺陷管理功能 |
| QC / ALM | 是惠普公司开发的一款测试管理平台，包含了缺陷管理功能； 中大型公司使用的比较多，银行项目大部分都使用qc |
| JIRA | 国外一款项目管理平台，包含缺陷管理功能； |
| 除以上之外有些公司会有自己的缺陷管理系统，流程操作与上述系统大同小异； | |
2.6 软件测试的级别 ---测试阶段
| 1. 需求测试 | 检查需求规格说明书中是否存在描述不准确、定义模糊、需求用例不正确、语言存在二义性等问题 检查规格说明书的需求是否准确 |
| 2. 单元/组件测试 --- 一般是以白盒测试的方法进行 | 针对被测软件基本组成的单元来进行正确性检验的测试工作，发现其可能存在的内存泄漏、算法冗余、分支覆盖率低、循环调用效率低等问题； 实际工作中，一般由开发完成。 |
| 3. 集成测试 --- 一般是以灰盒测试的方法进行 | 集成测试是对单元组件之间及单元组件与第三方接口之间进行测试 一般由开发去测，或者有专门的接口测试小组去测 |
| 4. 系统测试 --- 一般是以黑盒测试的方式进行 | 系统测试是通过集成测试的软件，部署到测试环境进行测试，目的在于通过与系统的需求定义做比较，发现软件与系统的需求定义不符或矛盾的地方； 主要检查功能是否符合需求 |
| 5. 验收测试 | 验收测试是以用户为主的测试，根据合同、需求规格说明书、验收测试计划等对成品进行验收， 此阶段发现缺陷不是目的，主要是通过验收测试使用户建立对即将交付应用的软件的信心 保证软件符合客户的期望 |
| 6. Alpha测试 --- 内测 | 由用户在开发环境下进行的测试，也可以是在开发机构内部的用户模拟实际操作环境中进行测试； |
| 7. Beta测试 --- 公测 | 多个用户在一个实际使用的环境下进行测试； |
内存泄漏
内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问，而系统也不能再次将它分配给需要的程序。
2.7 软件测试的类型
1. 功能测试 --- 手工测试
功能测试是指在指定情况下，软件功能满足需求（显性需求，隐性需求）
功能测试主要检查被测对象是否存在以下几种错误：
1）是否有不正确、遗漏或多余的功能；
2）是否满足用户需求和系统设计的隐藏需求；
3）是否对输入做出正确的响应，输出结果能否正常展示；
2. 性能测试
性能测试关注被测对象的响应速度、并发数、业务成功率及资源占用情况，
常用的监控指标有：并发数、响应时间、吞吐量、TPS、硬件资源耗用等
评估系统在特定负载下的表现和响应能力
3. 负载测试
是指在超过被对象标准性能负荷下，验证被测系统的负载承受能力，并要求在超负荷时，被测对象依然能够正常实现业务
4. 压力测试
在超过性能指标的饱和状态下，系统处理业务的能力情况，以及系统是否出现错误
5. 安全测试
验证被测对象的安全保护机制能否在实际的应用中保护系统不受非法入侵，用来保证系统本身的数据完整性和保密性；
一般由专门的安全测试工程师进行，我们在测试中只对简单的业务功能下的安全进行测试，比如密码的复杂程度，密码的密文显示、接口报文的加密等；
6. 兼容性测试
指软件在不同的平台或者不同的应用环境下兼容情况，一般在工作中分为，web系统（B/S结构）兼容和APP兼容
web兼容：①不同浏览器的兼容，使用不同内核的浏览器对web系统进行测试，查看页面显示是否正常；一般使用的浏览器有：chrome浏览器、firefox浏览器、欧鹏浏览器、遨游浏览器；
②不同操作系统的兼容，使用不同的操作系统查看web系统功能显示是否正常；一般考虑：windows系统、macOS系，以及不同系统的不同版本，比如win10、win11；
APP兼容：
①不同系统：安卓系统、IOS系统、鸿蒙系统
②不同厂商：OPPO、vivo、小米、华为
③不同系统版本：安卓5-安卓12 IOS15-IOS17
④不同尺寸：
⑤不同分辨率
⑥不同刷新率
7. 冒烟测试
指在开展系统测试前，先对被测系统的主要功能和主要流程进行验证的测试活动；
冒烟测试一般只需要拉取系统测试用例中的主功能和主流程相关的测试用例，占比大概到全部测试用例的百分之十左右；
8. 回归测试
对被测对象在修复缺陷后进行的重复测试，目的是验证修复缺陷没有引发新的缺陷和问题；
回归测试一般拉取上一轮中与缺陷相关的测试用例，以及主流程和主功能相关的测试用例
2.8 软件测试的方法
| 黑盒测试 | 测试人员对内部实现一无所知，关注输入和输出，基于需求进行功能验证，适合系统测试。 |
| 灰盒测试 | 测试人员对内部结构有部分了解，关注功能和性能，适合集成测试 |
| 白盒测试 | 测试人员了解内部代码，关注逻辑和路径，适合单元测试，能够发现隐藏的逻辑错误。 |
3. 软件测试设计
软件质量的关键点是满足需求；
需求又分为两个层次，一个是用户显性需求，一个是隐性需求
| 1. 了解需求 | 首先需要对已经定版的需求规格说明书进行充分的了解，明白其实现了哪些功能，有哪些业务 |
| 2. 拆分/提取功能点 | 如何提取测试点：功能模块 -> 子模块 -> 功能点 -> 功能点的描述/业务要求（业务逻辑、业务规则、数据约束等） -> 提取测试点（注意隐性需求） |
| 3. 测试用例设计 | 为什么？盲目测试、漏测风险大大增加 降低软件的质量风险，提高测试活动质量 |
3.1 测试用例的格式/要素
①用例编号：用来唯一识别测试用例，要求有易识别性和易维护性；
②测试标题/测试目的/测试概述：概括性的描述用例设计的目标，建议写法：某种角色的用户操作了何种交易，引起了什么结果，此结果是否正确、
③用例属性：一般为：功能用例、性能用例、接口用例、安全性用例、兼容性用例；④前置条件：是执行这条测试用例的前提，如果此条件不满足，则无法执行该用例；
⑤操作步骤：设计用例时执行的详细步骤，编写操作步骤时，需明确给出每一个步骤的详细描述；
⑥预期结果：预期结果来源于需求规格说明书，做为测试最重要的一个部分，需明确定义；
⑦实际结果：用例设计时，此项空白，在执行测试用例时，根据执行的实际情况填写；一般为：Passed--成功通过 ，Failed---失败，N\A----不适用 （在测试时无法执行这条测试用例或者这条测试用例不适用于本次测试，所以不用执行）
⑧优先级：指测试用例在执行的先后顺序，
级别一般有：高，覆盖系统主功能、主流程的测试用例标为高级别，在执行时优先执行；
中：覆盖系统子功能，二级功能或者辅助功能的测试用例标为中级别；
低：覆盖系统的界面检查，界面要素功能检查标为低界别；
⑨用例性质：一般为正用例、反用例；正用例表示这条测试用例的输出结果为成功；反用例表示这条测试用例的输出结果为失败；⑩用例设计人；
3.2 测试用例设计方法
3.2.1 等价类
等价类一般分为有效等价类和无效等价类；
有效等价类：针对被测对象需求规格说明书而言：有意义、有效的测试输入集合；
无效等价类：针对被测对象需求规格说明书而言：无意义、无效的测试输入集合；
3.2.2 边界值
边界值属于等价类方法的输入域，包含在有效的等价类或无效等价类中，在使用边界值方法选择测试数据时，通常选择输入域的边界值；
在用边界值方法构造数据是需要考虑三个点的选择：
上点：是输入域边界上的点
离点：是离上点最近的一个点
内点：是输入域范围内任意的一点
3.2.3 场景分析法
针对业务场景流程，一般分为：基本流、备选流和异常流3种业务流向；
基本流表示输入经过每一个正确的流程运转最终达到预期的结果；
备选流/分支流表示输入经过每一个流程运转时可能产生异常情况，但经过纠正后仍能达到预期结果；
异常流表示输入经过每一个流程运转时，产生异常终止的现象；
基本流和备选流通常作为业务流程测试过程中优先级最高的测试分支，应详细设计定义，异常流作为可靠性健壮性用例亦需同步考虑