软件测试的概念
目录
1.认识测试
2.软件测试的工作内容
3.什么是需求
4.开发模型
5.常见的开发模型
5.1.瀑布模型
5.2.螺旋模型
5.3.增量模型
5.4.迭代模型
5.5.敏捷模型
5.5.1.敏捷模型的常见方法
6.测试模型
6.1.v模型
6.2.W模型(双V模型）
7.软件测试的生命周期
软件测试在生命周期各阶段的应用
8.BUG
8.1.BUG分类（按严重性）
8.2.BUG的生命周期
1.认识测试
软件测试是软件开发过程中的关键环节，通过执行软件的过程来验证软件是否符合预期需求其目的就是为了发现软件特性有与用户需求不相符的地方。
举个例子：在鞋店买鞋对鞋进行外观测试：挑选个人喜欢的鞋子，然后就行试穿测试：试穿这双鞋的舒适度以及这双鞋适不适合自己，最后进行价格测试：测试这双鞋满足自己的预期价格。
2.软件测试的工作内容
1.验证软件是否满足需求。
2.尽早发现和修复bug，防止软件上线造成不可挽回对损失。
3.某些软件测试人员还需要开发测试效率工具一提高软件测试的质量。
3.什么是需求
用户需求是从用户的角度描述的问题，而用户的需求不可以直接转化为软件需求，因为难免会出现不可能完成、不合理等需求，所以需要产品经理对用户对需求转变为软件需求，用技术性的语言详细解说如何实现用户的需求，以便提供给开发人员和测试人员。
4.开发模型
开发实际上就是开发一个软件的过程（需求分析-计划-设计-编码-测试-运行和维护）
需求分析：分析用户的需求是否合理，并生成需求文档。
计划：指定一个时间表，描述什么时候开发，需要多久的时间完成每个功能，并生成文档。
设计：将需求设计细化为一个个任务，团队成员各负责各自的任务，并生成文档。
编码：开发人员根据需求文档，设计文档进行代码编写，并生成文档。
测试：测试人员介入当测试当中，并生成文档。
运行和维护：软性上线进行线上的维护（完善性维护、适应性维护和预防性的维护）
5.常见的开发模型
5.1.瀑布模型
瀑布模型是一种线性顺序的开发模型，分为需求分析、设计、实现、测试、部署和维护几个阶段。每个阶段完成后才能进入下一阶段，适合需求明确且变更较少的项目。
优点：是所有开发模型的基础框架，且是线性进行的开发模型。
缺点：测试后置，导致前面的遗留的问题到测试阶段才被发现，导致bug发现过晚，修复的代价就会越高。且时间周期比较长，可能不满足用户的需求。由此瀑布模型适用小型项目。
5.2.螺旋模型
螺旋模型结合了瀑布模型的系统性和敏捷开发的迭代性，强调风险分析。每个迭代周期包括需求分析、风险分析、开发和客户评估，适合高风险或复杂的大型项目。
优点：引用了风险分析和原型，避免了各个阶段产生的遗留。
缺点：浪费大量的人力以及资源。导致项目的成本过高。
5.3.增量模型
增量模型将软件划分为多个独立的增量模块，每个增量模块依次开发并交付。用户可以在早期阶段使用部分功能，适合需求优先级明确的项目。
将软件分为多个独立的模板，独立开发上线，能显著的降低项目风险。
5.4.迭代模型
迭代模型将开发过程分为多个迭代周期，每个周期完成部分功能并逐步完善。与增量开发类似，但迭代周期可能更长，适合大型项目。
迭代模型就是在项目的基础上多次迭代逐步完善项目。
5.5.敏捷模型
敏捷模型主要旨在帮助项⽬快速适应变更请求。因此，敏捷模型的主要⽬的是促进项⽬的快速完成。 要完成这项任务，需要敏捷。敏捷性是通过使过程适应项⽬，删除对特定项⽬可能不是必需的活动来 实现的。此外，避免任何浪费时间和精⼒的事情。
在敏捷模型中，需求被分解成许多可以增量开发的⼩部分。敏捷模型采⽤迭代开发。每个增量部分都 是在迭代中开发的。每次迭代都旨在⼩⽽易于管理，并且只能在⼏周内完成。⼀次为客⼾计划、开发 和部署⼀个迭代。没有制定⻓期计划。
敏捷模型的四个特点：轻⽂档，轻流程，重⽬标，重产出。
5.5.1.敏捷模型的常见方法
Scrum：通过固定长度的迭代（Sprint，通常2-4周）交付增量产品，角色包括产品负责人（PO）、Scrum Master和开发团队。
Kanban：可视化工作流（看板），限制在制品（WIP）数量，强调持续交付和流程优化。
极限编程（XP）：注重工程实践如测试驱动开发（TDD）、持续集成和结对编程。
精益开发（Lean）：聚焦消除浪费、优化价值流，源自丰田生产体系。
Scrum是敏捷模型中的⼀种，⼜称为迭代式增量软件开发模型。 在scrum模型中，主要有三个⻆⾊和五个重要会议。
三个角色：
scrum由productowner(产品经理)、scrummaster(项⽬经理)和team(研发团队)组成。
- 其中产品经理负责整理用户需求，定义其商业价值，对其进⾏排序，制定发布 计划，对产品负责。
- 项目经理负责召开各种会议，协调项⽬，为研发团队服务。
- 研发团队则由不同技能的成员组成，通过紧密协同，完成每⼀次迭代的⽬标，交付产品。
五个会议：
- 需求发布会议：产品经理讲解用户需求，制定需要完成的需求有哪些。
- 计划发布会议：项目团队对项目需求进行分析，由项目成员负责每个任务，并在规定的时间内完成。
- 每日会议：总结昨天做了些什么，以及今天准备完成那些任务。
- 演示会议：展示本次迭代的成果，大家记录下来并反馈。
- 回顾会议：项⽬团队对本期迭代进⾏总结，发现不⾜，制定改进计划，下⼀次迭代继续改进，以达 到持续改进的效果。
6.测试模型
测试模型中有两个⾮常重要且具有标志性的测试模型：V模型和W模型
6.1.v模型
V模型是软件开发中的一种生命周期模型，强调测试与开发阶段的对应关系。其核心思想是将验证和确认活动（如测试）与开发阶段（如需求分析、设计）并行规划，形成“V”字形结构。左侧代表开发阶段，右侧代表测试阶段，两者严格对应。
但该模型有和增量模型一样的问题测试后置，测试都在编码后阶段进行。
6.2.W模型(双V模型）
W模型增加了软件各开发阶段中应同步进⾏的验证和确认活动。W模型由两个V字型模型组成，分别代 表测试与开发过程，图中明确表⽰出了测试与开发的并⾏关系。
特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进⾏的。
缺点： 需求、设计、编码等活动被视为串⾏的；
测试和开发活动也保持着⼀种线性的前后关系，上⼀阶段完全结束，才可正式开始下⼀个阶段⼯ 作。
重流程，⽆法⽀持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理 ⾯临着困惑
7.软件测试的生命周期
软件测试贯穿于软件的整个⽣命周期。
软件测试在生命周期各阶段的应用
需求分析阶段
测试团队参与需求评审，验证需求的完整性、一致性和可测试性。编写初步测试计划，明确测试范围和策略。识别潜在风险并制定应对措施。
设计阶段
根据架构设计制定集成测试方案，验证模块间交互。针对详细设计编写单元测试用例，确保代码实现符合设计预期。设计评审中提出可测试性改进建议。
编码阶段
开发人员执行单元测试，使用工具如JUnit、PyTest等。测试人员准备测试环境，完善自动化测试脚本。持续集成系统运行自动化测试，及时反馈构建质量。
测试阶段
执行系统测试验证功能和非功能需求。进行回归测试确保修改未引入新缺陷。用户验收测试确认系统满足业务需求。缺陷管理跟踪问题修复进度。
维护阶段
监控生产环境问题，分析缺陷根本原因。针对用户反馈进行验证测试。版本升级前执行回归测试。持续优化测试用例库和自动化脚本。
8.BUG
⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障 (fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错 误。
8.1.BUG分类（按严重性）
| 等级 | 影响范围 | 示例 |
|---|---|---|
| S级 | 系统崩溃 | 内存泄漏导致服务宕机 |
| A级 | 核心功能失效 | 支付流程金额计算错误 |
| B级 | 次要功能异常 | UI元素错位 |
| C级 | 体验缺陷 | 拼写错误 |
8.2.BUG的生命周期
测试⼈员在执⾏测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug⽣命起 源），创建好的bug需要被开发⼈员修复，以及测试⼈员的持续跟踪和测试。
●New:新发现的Bug，未经评审决定是否指派给开发⼈员进⾏修改。
●Open：确认是Bug，并且认为需要进⾏修改，指派给相应的开发⼈员。
●Fixed:开发⼈员进⾏修改后标识成修改状态，有待测试⼈员的回归测试验证。
●Rejected：如果认为不是Bug，则拒绝修改。
●Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
●Closed：修改状态的Bug经测试⼈员的回归测斌验证通过，则关闭Bug。
●Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发⼈员重新修改。