我个人对测试的理解就是，软件测试就是验证软件产品特性是否满足用户的需求。
需求
用户需求
用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略，通常是一句话。比如实现一个登录功能
软件需求
该需求会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据。
软件生命周期
需求分析 ------ 计划 ------ 设计 ------ 编码 ------ 测试 ------ 运行维护
对于软件的生命周期中，每个阶段都在做什么呢
| 阶段 | 具体内容 | 产出 |
|---|---|---|
| 需求分析 | 分析用户需求是否合理，分别从市场需求、技术等方面进行分析。 | 需求文档 |
| 计划 | 对确认的需求执行计划制定，确定在多长时间内完成该需求，每段时间具体完成哪些功能。 | 计划文档 |
| 设计 | 将需求细化成一个个任务，团队成员各司其职领取任务并进行技术设计（如何进行架构设计，设计哪些接口、采用什么技术）。 | 技术文档 |
| 编码 | 开发人员参考需求文档、设计文档、交互图等文件进行代码的编写。 | 代码文件 |
| 测试 | 测试人员需要介入到软件的测试中来，参考测试用例对软件进行测试。 | 测试用例、测试设计与计划、测试报告 |
| 运行维护 | 项目测试结束后，项目需要进行上线，并对产品进行线上的维护。线上的维护主要分为三个方面：修复性维护、完善性维护和预防性维护。 | 修复性维护：对项目中未发现的问题进行修复。 完善性维护：对功能进行完善。 预防性维护：为了避免产品在线上出现一些其他不可预料的问题，进行一些防护手段。 |
软件测试生命周期
| 需求分析 | 测试计划 | 测试设计与开发 | 测试执行 | 测试评估 | 上线 | 运行维护 |
|---|---|---|---|---|---|---|
| 用户角度：软件需求是否合理 技术角度：技术上是否可行，是否还有优化空间 测试角度：是否存在业务逻辑错误、冗余、冲突等问题 | 制定测试计划：什么时候开始测试，什么时候结束测试 | 参考需求文档、技术文档等编写测试用例 写测试文档，明确标注使用到的测试方法、测试工具、测试形式等 | 充分利用测试用例和测试工具对项目尽可能做到全方位的测试覆盖 | 测试是否通过，本次测试是否有遗留的BUG，最终测试人员需要产出一个测试报告 | 项目测试结束后，将项目发布到线上环境，测试人员需跟踪上线并测试线上环境下软件的运行是否正确 | 测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人 |
常见开发模型
瀑布模型
瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。
瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工。尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。
在瀑布模型中，测试阶段处于软件实现之后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。
瀑布模型优缺点总结：
| 优点/特点 | 缺点 |
|---|---|
| 强调开发的阶段性； 线性结构，每个阶段只执行一次 是其他模型的基础框架 | 测试后置 ○ 前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会 ○ 必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给用户（产品质量差） 周期太长，产品很迟才能被看到和使用，可能会导致需求/功能过时 |
瀑布模型的适用场景：需求固定的小项目
螺旋模型
一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。
优点
- 强调严格的全过程风险管理。
- 强调各开发阶段的质量。
- 增加风险分析和原型。
缺点
- 项目中可能存在的风险性与风险管理人员的技能水平有直接关系。
- 需求人员、资金、时间的增加和投入，可能会导致项目的成本太高。
适用场景：规模庞大、复杂度高、风险大的项目。
增量模型和迭代模型
增量模型
优点:
- 可以早期交付部分功能(因为把大功能拆分成一个个小增量独立开发)
- 灵活性高(每个增量都是独立的,可以根据用户的需求进行调整适应变化)
- 资源优化(逐步交付可以让资源更好的得到分配)
缺点:
- 系统集成问题(不同增量之间可能存在集成问题)
- 可能导致重复性工作(不同增量之间可能会有部分重复工作)
适用场景:
- 时间紧迫,功能可以独立开发和交付的项目
迭代模型
先做一个基础版本,再上线优化版本1,优化版本2(一版一般的迭代上线)
优点:
- 灵活性适应性强(每次迭代可以根据用户的需求完善产品)
- 逐步优化(每个版本都更加接近于最终的理想产品)
缺点:
- 资源消耗大
- 管理复杂(版本进行迭代,项目的协调难度大)
适用场景:
- 需求不明确,敏捷环境(适合敏捷开发框架)
增量开发和迭代开发往往容易被人混淆，但其实两者是有区别的：增量是逐块建造的概念，迭代是反复求精的概念。
敏捷模型
在敏捷模型中，需求被分解成许多可以增量开发的小部分。敏捷模型采⽤迭代开发。每个增量部分都是在迭代中开发的(敏捷模型是一种迭代和增量为一体的模型)这样帮助项目快速适应变更要求.
特点:
- 轻文档,轻流程,重目标,重产出.
优点:
- 强调高效的沟通
- 轻文档,轻流程
- 主动及时了解当下的需求
- 能够主动迎接变化
缺点:
- 依赖高效的团队合作
- 资源需求高
- 不适合大型项目
- 客户不参与时效果差
适用场景:
- 需求变动频繁、开发复杂、团队合作紧密、客户参与度高的场景
测试模型
V模型
优点：
- 结构清晰(开发和测试一一对应便于管理)
V模型指出：
- 单元和集成测试应检测程序的执行是否满足软件设计的要求；
- 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
- 验收测试确定软件的实现是否满足用户需要或合同的要求。
缺点：
- 仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试。缺点同瀑布模型。
W模型
w模型(也叫做双v模型)把测试贯穿了整个软件的生命周期.测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
优点:
- 有利于尽早全面的发现问题
缺点:
- 需求,设计,编码等活动还是串行的(每一条V还是线性进行,哪个阶段出现问题就得大规模反工)
- 测试和开发活动也保持着⼀种线性的前后关系，上⼀阶段完全结束，才可正式开始下⼀个阶段⼯作。
- 重流程,无法支持敏捷开发模型(敏捷开发模型轻文档,轻流程,而双V必须要一个阶段执行完之后才能进行下一阶段)
适用场景:
- 需求不稳定、需要快速反馈和高质量控制的项目，适应性较强，但管理较为复杂，资源消耗较高。
BUG
定义一个bug：
- 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
- 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
描述一个bug
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
BUG的生命周期
- New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。
- Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
- Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
- Rejected：如果认为不是Bug，则拒绝修改。
- Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。
- Closed：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。
- Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。