前言
本篇学习，测试相关基础概念、常见的开发模型测和测试模型，搞懂4个问题：
- 什么是需求
- 什么是 bug
- 什么是测试用例
- 开发模型和测试模型
目录
1. 什么是需求
1.1 为什么要有需求
1.2 测试人员眼里的需求
1.3 如何深入了解需求
2. 测试用例
2.1 什么是测试用例
2.2 为什么要有测试用例
2.3 练习
3. 认识 BUG
4. 软件生命周期
5. 开发模型
5.1 瀑布模型
5.2 螺旋模型
5.3 增量模型与迭代模型
5.3.1 增量模型
5.3.2 迭代模型
5.4 敏捷模型
6. 测试模型
6.1 V 模型
6.2 W 模型(双 V 模型)
1. 什么是需求
1.1 为什么要有需求
当程序猿开发一产品或者测试一个产品时，需要拿着软件需求来进行开发和测试。
1.2 测试人员眼里的需求
对一个大的需求进行子拆分为一些小需求以解决原需求。如一个登录功能：
1.3 如何深入了解需求
开一个需求评审会议，内容大概有：为什么做这样一个需求、这个需求能带来多少收益、软件需要做成什么样子。或查询文档(需求文档、技术文档)，亦或者找产品经理了解软件功能、找开发了解软件的实现。因此，如何深入了解需求有三点:
- 参加需求评审会议
- 查询文档
- 沟通
2. 测试用例
2.1 什么是测试用例
测试用例是一组集合，如：测试环境、测试数据、预期结果、操作步骤等。粗犷的理解为:
- 测试环境：力扣刷题时会给我们提供一个测试平台
- 测试数据：字节输入测试数据 70%
- 操作步骤：写代码然后提交
- 预期结果：100% 通过
例如，一个登录功能，此时：
- 测试环境：windows 系统 + chrome 浏览器 + idea 编译器
- 测试数据：账号 + 密码
- 测试步骤：输入账号密码点击登录
- 测试结果：登录成功
2.2 为什么要有测试用例
测试用例能够提高测试人员的工作效率，降低测试人员工作的重复性。如一个测试登录功能，同一个功能多个人去测，当有了测试用例后，假设有 100 个用例，几个人分别测试这 100 个用例。这样即可以提高工作效率。
测试用例是建立自动化的基础，自动化就是使用代码来实现测试人员解放双手，用代码来代替测试人员执行用例。
2.3 练习
一个练习题：设计手机打电话这个功能的测试用例。
此时，大家脑海里肯定有许多想法如：手机号是否为正确格式，测试网络是否畅通，手机是否有充足话费等等。这样盲目列出让人有一种没有条例毫无思路的感觉，因此可以列出一个集合，如下图所示：
3. 认识 BUG
史上的第一只 Bug ，真的是因为一只飞蛾意外走入一电脑而引致故障，因此 Bug 从原意为臭虫引申为程序错误。在软件测试概念中：
- 当规格说明书存在且正确时，程序与规则之间不匹配则认为是一个错误(bug)
- 当规格说明书没有提到某些功能，程序没有实现最终用户心里需求时则认为是一个软件错误。
以上 bug 容易理解，软件错误可理解为：假设规格说明书中没有明确密码隐藏显示(日常中会默认隐藏显示)，用户在登录时发现自己密码容易被旁人看到，因此向甲方提出诉求，而这就是一个软件错误。
4. 软件生命周期
简单理解为：需求分析、计划、设计、编码、测试、运行维护。详细理解：
- 需求分析：分析需求是否合理，需求是否完整。例如，一个登陆页面，光有登录没有注册，这就是一个不合理、不完整。
- 计划：谁开发、谁测试、开发和测试的周期。
- 编码：前后端程序员根据需求开始编写代码。
- 测试：测试人员根据开发者编写的代码进行测试，会制定一个测试报告，把测试报告则给上级，上级觉得合适则上线。
- 运行维护：如果线上有问题，测试人员需要协助开发定位问题、解决问题。
测试报告大致为：
5. 开发模型
5.1 瀑布模型
瀑布模型（Waterfall Model）是一种经典的软件开发模型，将项目划分为若干个严格按顺序执行的阶段，每个阶段完成后才能进入下一个阶段，形如瀑布流水，故得名“瀑布模型”。常见流程为下图：
- 需求分析：需求文档，分析需求是否合理，需求是否完整。
- 计划：什么时候开始，什么时候结束
- 设计：技术文档(数据库、实现功能等)、UI视觉稿(简单理解为精美的页面)
- 编码：前后端程序员编写代码
- 测试：执行测试用例，提交 bug，验收等。
特点：它是一种线性的路程。
优点：阶段清晰，易于管理；文档驱动，便于沟通；适合需求稳定的项目。
缺点：缺乏灵活性(进入下个阶段，很难回头修改)；风险后置；用户参与度低；不适合需求频繁改变的项目。
5.2 螺旋模型
螺旋模型（Spiral Model）是一种结合了瀑布模型和快速原型模型特点的软件开发模型，核心在于通过迭代式开发和风险驱动的方式，逐步推进项目，降低开发风险，特别适用于大型、复杂且高风险的系统开发项目。常见流程如下：
- 制定计划：确定项目目标、约束条件、备选方案；制定迭代计划，明确资源需求和时间安排。
- 风险分析：识别潜在风险（如技术风险、需求风险、管理风险等）；评估风险影响，制定应对策略。
- 实施工程：根据计划进行系统设计、编码、测试等开发活动；构建原型或增量版本，验证关键功能。
- 客户评估：向客户展示迭代成果，收集反馈；根据反馈调整后续迭代计划。
优点：降低风险，每个阶段都会进行风险分析，避免一些线上问题发生
缺点：管理复杂度高、成本较高、依赖客户参与。
适用项目：大型项目、风险较高项目、需求不明确或需求易变项目。
5.3 增量模型与迭代模型
5.3.1 增量模型
定义：
- 逐步交付：将系统划分为多个独立的“增量”（模块或功能），每个增量独立开发、测试并交付用户。
- 线性扩展：每个增量在上一版本基础上扩展功能，逐步完善系统。
特点：
- 阶段性交互：用户可以提前获得某些功能
- 并行开发：不同的增量可以由不同的程序猿开发
- 需求变化灵活：后增量的需求可在开发前调整，适应变化。
5.3.2 迭代模型
定义：
- 重复开发周期：将开发过程划分为多个“迭代”，每个迭代包含需求分析、设计、编码、测试等完整阶段。
- 逐渐细化：通过多次迭代逐步完善系统，需求和设计在迭代中不断调整。
特点：
- 循环迭代：每个迭代产出可运行的软件版本，但功能可能不完整。
- 分线驱动：早期迭代优先解决高风险问题（如技术验证）。
- 用户反馈驱动：基于用户反馈调整后续迭代内容。
假设有一个网站，包含注册、登录、修改个人信息等功能，增量和迭代模型分别对应如下操作：
增量：注册功能完成 -> 登录功能完成 -> 修改个人信息
迭代：注册功能开发一部分 -> 登录功能开发一部分 -> 修改个人信息开发一部分
5.4 敏捷模型
个体与交互重于过程和工具可用的软件重于完备的文档客户协作重于合同谈判响应变化重于遵循计划在每对比对中，后者并非全无价值，但我们更看重前者
- 以人为核心：
强调团队成员的协作、沟通和创造力，而非过度依赖流程和工具。 - 迭代与增量开发：
将项目分解为多个短周期的迭代（通常为2-4周），每个迭代产生可用的软件增量。 - 快速响应变化：
通过频繁的迭代和反馈，快速适应需求变化，减少项目风险。 - 客户协作：
客户作为团队的一部分，参与需求定义、验收测试和反馈，确保产品符合实际需求。 - 持续交付价值：
每个迭代结束时交付可用的软件，使客户尽早获得价值
常见的敏捷测试有 Scrum ，它用于管理复杂产品的开发、交付和持续支持。它通过短周期的迭代（称为 Sprint）和持续反馈，帮助团队高效协作、快速响应变化，并持续改进产品。
- 特点：基于短周期的迭代（Sprint），强调团队自组织和持续改进。
- 角色：产品负责人（Product Owner）、Scrum Master、开发团队。
- 适用场景：需求不明确或频繁变化的项目，如互联网产品开发。
大概流程为：
（1）项目经理收集用户需求，对需求进行优先级的划分、计划项目开始与结束时间。
（2）每日站会，汇报昨日工作完成状况、遇到问题，今日计划等。
（3）演示，给不同的人进行演示。
（4）总结，总结上述过程中发生的问题，避免今后遇到。
6. 测试模型
6.1 V 模型
- 用户需求：PM(产品经理)将用户需求进行收集形成软件需求
- 需求分析和系统设计：验证需求是否正确，确定语言，确定框架
- 概要设计：项目的一个结构
- 详细设计：每个结构对应的表名、接口等
- 编码：编写代码
- 单元测试：测试每个方法/函数功能是否正确实现
- 集成测试：将众多方法/函数集中在一起进行测试
- 系统测试：测试模块与模块之间没有影响
- 验收测试：产品经理，运营进行验收
特点：左边是开发，右边是测试，分工明确类似于瀑布模式。
优点：测试被划分为许多类型。
缺点：测试人员介入太晚，导致问题发现较晚。
6.2 W 模型(双 V 模型)
特点：开发一个 V，测试一个 V。
优点：测试人员尽早的进入了测试。
缺点：测试人员和开发人员一定程度上还是串行的，不能拥抱变化，不适于敏捷模型。
