一、软件测试的基础概念
1.1 需求
在企业中，需求 主要分为 用户需求 和 软件需求~
用户需求：
可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务；用户需求 一般是比较简略的，没有一定限制的（五花八门）~
举个例子：假如现在有一个声控灯的话，那么就可以有多个用户需求：声控灯是熊猫形状的、声控灯是黄金制作的、声控灯的声控范围就是在楼梯这一段距离......
由此可见,用户需求是五花八门的,不可以做为实现参考的依据（技术上、投入成本、收益......），需要进行用户需求的提取和分析才可以~
软件需求：
也叫做功能需求，该需求会详细描述 开发人员必须实现的软件功能~
软件需求 是测试人员进行测试工作的依据~
举个例子，解释用户需求和软件需求的不同点：
npy提出了一个需求：就想要喝奶茶（这个是用户需求）~
于是自己就可以取跑去买了，但是需要去和npy去反复的确认：是哪个门店的？是哪款奶茶啊？是热的还是冰的啊？要不要加一些料啊？（这个就是软件需求）~
1.2 测试用例
测试用例 是测试人员执行测试的一组依据，测试人员在执行测试之前 需要编写测试用例，测试用例的好坏 与产品测试质量 具有很大的关联关系~
测试用例 要尽可能的广~
之后，就可以根据测试用例，一个一个的进行测试了~
如果没有测试用例，那么 测试的时候仅仅只能靠着头脑去测、去记，到最后 到底测试过哪些东西，自己也会搞混了~
所以说，测试用例的存在，可以引导进行有条不紊的测试，提高测试的覆盖率，防止出现 "漏测" 的风险~
当然，虽然说 在测试中有一句话叫做 "不可能做到完全的测试"，但是 测试人员要尽可能的去避免 "漏测"，保证线上不会出现明显的问题~
测试用例的出现主要解决了两个问题：测什么、怎么测~
测试用例 是为了实施测试 而向 被测试的系统 提供的一组集合，这组集合包括：测试环境、操作步骤、测试数据、预期结果 等要素~
比如说，上面的第一个测试用例，就可以这样写：
可是，如果是针对某一个功能，需要去设计几十个甚至上百个测试用例，岂不是非常的麻烦~
实际上，现在的互联网企业，主要使用的是 "思维导图" 的方式去编写测试用例，如：
1.3 BUG
当且仅当规格说明 是存在的并且正确，程序与规格之间的 不匹配才是错误，即BUG~
当需求规格说明书 没有提到的功能，判断标准以最终用户为准：当程序没有实现 最终用户合理预期的功能要求时，就是BUG~
BUG实例：
比如说，在实现用户登录功能的时候，需求规格说明书 上面明确规定：密码最短输入为6位，最长为15位；但是，实际上如果输入5位，也可以通过的话，那么这就是一个BUG~
比如说，向其他人分享资料，有的时候显示的是一个 默认组件的样式，有的时候显示的具有图片；此时，分享的功能是正常的，但是发给其他人的时候 展示的不好看，此时也可以提BUG的（但是在需求文档中可能不会提到）~
二、开发模型和测试模型
2.1 开发模型
开发模型，可以理解为 开发流程/项目推进流程~
常见的开发模型有：瀑布模型、螺旋模型、增量模型、迭代模型、敏捷模型 等等~
当然，也可以理解为 软件的生命周期（软件从开始 到结束的这一段时间），软件的生命周期可以分为六个阶段：需求分析、计划、设计、编码、测试、运行维护~
下面，来举一个例子更好地理解这六个阶段：
假如现在需要建造一个房子，那么 房子的生命周期是什么？
需求分析阶段：
首先需要明确，为什么要建造房子~
房子是用于商用的还是民用的~
假如需要建造商用房，需要在哪里建造，建造多少层~
建造的投入与收入比例是否过大~
......
计划阶段：
什么时候开始建造房子~
房子什么时候动工，房子什么时候竣工~
大概需要一年的时候来建造，2023年1月1日开始动工，2024年竣工并投入使用~
......
设计阶段：
先出设计图，对房子有一个明确的布局，
如：谁来负责打地基，谁来负责建筑框架，谁来负责砌墙，谁来负责粉刷~
......
编码阶段：
脚踏实地的按照需求和计划一步一步的建造房子~
......
测试阶段：
等到房子交付的日期了，就要进行房子的验收测试，
如：房子有没有漏水，房子有没有偷工减料，房子是否按照规定的样子来建造~
......
运行维护阶段：
房子交房之后，用户也已经住进去了，后期也许会出现一些异常的情况，
如：房子漏水，墙皮掉落~
需要用户自己来进行维护~
通过上述建造房子的例子，就可以更好地理解软件的各个生命周期~
软件生命周期 各阶段需要进行的 部分内容 如下：
如上，软件开发有它自己的整个生命周期，
其实 软件测试也有着它自己的生命周期：它诠释了 测试人员在软件 整个生命周期里面，在各个阶段需要做的事情~
软件测试的生命周期 5个阶段：
需求分析 -> 测试计划 -> 测试设计与开发 -> 执行测试 -> 测试评估
ps：
需求分析：软件测试人员往往是最了解需求的人~
测试计划：测试人员也需要编写 测试计划文档，明确标注了：有多少个测试人员，什么时候开始测试~
测试设计与开发：测试人员需要借助 需求文档 + 技术文档 来编写测试用例~
2.1.1 瀑布模型
瀑布模型
需要注意的是，瀑布模型 不重视测试的，即：在编码及之前的几个阶段，都不涉及到测试的动作（当然，也是包含前面的测试 5个阶段）~
这就意味着，瀑布模型 更看重于前面的几个阶段~
瀑布模型 很容易的可以看出，它是一个线性结构：这就意味着 前一个阶段结束之后，后一个阶段才会开始~
这就意味着，在最终测试的时候，发现的错误 可能不仅仅是 编码阶段的错误，前面阶段 也可能会出现错误~
这就埋下了一个隐患：风险 往往会 延迟 到后期的 测试阶段 才会显露，因而 失去 及早纠正 的机会~
特别是，测试被后置， 就说明需要把足够的时间留给测试，如果最后留给测试的时间有限，那么 测试就可能不充分，最终就可能会把一些问题暴露给用户~
当然，瀑布模型的最大缺陷就在于：
由于瀑布模型是一个线性模型，所以项目需要实现的所有功能 必须要在一个周期里面完成~
而如果是一个大型项目的话，每一个阶段都要经历很久，到最后 用户在很晚之后才可以看到~
但是，我们不可能保证，在这一段时间内，用户的需求会不会发生变化（某一段时间很急需某个需求A，当时没有上线；等已经不需要需求A了，才上线）~
当然，瀑布模型 在软件工程中占有着重要的地位，它是所有其他模型的基础框架，后面的其他模型都是在瀑布模型的基础上不断优化的~
瀑布模型适用场景：需求固定的小型项目（不能很好的迎接需求的变化）~
2.1.2 螺旋模型
螺旋模型
螺旋模型 是在 瀑布模型 的基础上进行优化的，在每个阶段都增加了 风险分析（把那条曲线拉直）~
发现有风险了，消除风险之后，会生成新的原型~
但是，这种模型一定是耗时耗力的，成本大，需要去找专门的风险分析人才~
螺旋模型适用场景：需求不确定，变化的可能性很大的大型项目~
2.1.3 增量模型、迭代模型
ps：计划之类的阶段就没有画出来了
增量模型：使项目进行模块化，每个模块都可以进行独立的开发和上线~
优势：产品可以在较短的时间内尽快的交付给用户去使用~
迭代模型：假如说一个产品有A、B、C三个功能，迭代模型 会先完成这三个功能的基础版本，之后再经历一期又一期的迭代优化，直到这三个功能非常的优秀~
总之，增量模型 和 迭代模型 是通常混为一谈的，但是其实它们是有区别的~
增量模型一定是逐块建造的，可以先开发功能A，也可以先开发功能B、功能C~
迭代模型一定是在基础的版本上进行 更新优化，是精益求精的过程~
2.1.4 敏捷模型
在敏捷模型中，没有强调类似于其他模型中 重流程 的一些东西~
提出了《敏捷宣言》：通过身体力行和帮助他人来揭示更好的软件开发方式，形成了如下价值观：
敏捷宣言
ps：
敏捷模型 强调了 团队内部人员需要尽可能的进行高效的沟通~
强调了 最终的标准就是：可交付的软件；至于 开发软件过程中 写了多少份文档 并不是特别在乎，而在一个周期结束之后，需要给一个结果：或有一个新的功能，或有一个新的产品 等等~
强调了 须把客户的需求 放在第一位，与客户之间需要有一个高效的协作；如：之前客户有需求A，以合同的形式告诉；后来客户有需求B，那就需要去实现需求B了~
强调了 需要时刻响应变化，而不是和前面几个模型一样，一直不变，否则如果出现问题的话，开发的成本就会越来越高了~
即：敏捷宣言的特点是：轻流程、轻文档、重目标、重产出~
2.1.4.1 scrum模型
敏捷开发有很多种方式，其中 scrum模型 是比较流行的一种~
在 scrum模型 里面，需要了解三个重要的角色 和 五个重要的会议~
三个角色
scrum 由 产品经理、项目经理、研发团队 三个角色组成~
产品经理：收集用户需求，转变成软件需求，推动研发团队去进行功能的开发~
项目经理：很多企业是 没有项目经理 这一角色的，此时由 产品经理 承担，其职责是 在合理的周期内，去推进项目可以如期的进行；如 在计划阶段规定了项目什么时候开始，什么时候结束，项目经理就需要检查到了这段时间 计划的有没有完成，如果遇到项目问题 就需要去协调解决问题，召开会议，为研发团队服务；可以简单的理解——项目经理就是催加班、催进度的~
研发团队：由不同技能的人员组成（如 前端、后端、测试人员 等等），通过紧密协同，完成每一次迭代的目标，交付产品~
基本流程
2.2 测试模型
除了敏捷模型之外，其他几个模型都把测试阶段放到了后期，说明并不重视测试~
而在后续的发展中，测试就被重视起来了~
这里就介绍两种测试模型：V模型、W模型~
2.2.1 V模型
V模型
特点：
明确了测试有不同的类型，而且每个类型和前期的开发工作之间有对应关系~
缺陷：
测试后置~
2.2.2 W模型
W模型
特点：
测试从一开始就介入（软件测试贯穿于软件的整个生命周期），有利于尽早地全面的发现问题~
缺陷：
开发和测试虽然是同步的，但是仍然存在这前后的线性关系~
不支持敏捷模型（太重文档了）~