认识软件测试
今天小编来分享下什么是测试。
这个里的测试是指软件测试
软件测试：是通过执行程序、系统、组件，以验证其是否满足规定的需求、发现其中存在的bug并评估其质量过程
与其类似还有一个，软件测试开发工程师
软件测试开发工程师:是介于传统测试工程师与开发工程师直接的角色，不仅负责测试策略与用例设计、还具有较强的编码能力、开发自动化测试框架、工具、脚本，以提升测试效率和质量保障能力。
那么值得注意的是，有些公司它招人是测试，但它也有可能会让你干测开的活。
接下来，小编再来分享一下关于测试的相关知识
在多数的软件公司中，需要分为两种，一种是软件需求，一种是用户需求。
以最终用户或客户角度出发，描述他们希望系统“能做什么”或“解决什么问题”的高层次、业务导向的诉求。通常以自然语言、用例或用户故事的形式表达
示例：
“用户希望能够通过手机号一键登录，无需记住密码。”
是将用户需求转化为技术团队可理解、可验证、可实现的详细规范，明确系统“必须具备哪些功能”和应满足哪些约束条件“。它是开发和测试工作的直接依据
这里还分为功能性需求、非功能性需求
描述系统应提供的具体功能或行为
示例：
”系统应在用户输入错误密码5次后锁定账户30分钟“
描述系统运行时的质量属性或约束条件，如性能、安全性、可用性、兼容性等
示例：
”系统应支持1000万并发用户同时登录，响应时间不超过2秒“
对比如下：
分享这个开发模型之前，不能不提一句软件开发的生命周期。
需求分析——>计划——>设计——>编码——>测试——>运行维护。
| 阶段 | 主要工作内容 | 关键产出物 | 测试角色关注点 |
| 1. 需求分析 | 与用户/业务方沟通，收集、分析、确认系统需要实现的功能和约束；明确“做什么”。 | - 用户需求文档（URD） - 软件需求规格说明书（SRS） - 用户故事/用例 | - 参与需求评审 - 评估需求的可测试性 - 识别测试范围和风险 - 初步定义验收标准 |
| 2. 计划 | 制定项目整体计划，包括时间、资源、技术方案、风险管理等；测试团队制定测试策略。 | - 项目计划书 - 测试计划（Test Plan） - 质量保证计划 | - 编写测试计划（范围、方法、资源、进度、风险） - 确定测试类型（功能、性能、安全等） - 规划自动化策略 |
| 3. 设计 | 系统架构设计、模块划分、数据库设计、接口定义等；将需求转化为技术方案。 | - 系统架构图 - 详细设计文档（DDD） - 接口文档（API Spec） | - 参与设计评审 - 设计测试方案与测试用例 - 准备测试数据和环境 - 设计自动化测试框架（如适用） |
| 4. 编码 | 开发人员根据设计文档编写代码，实现功能。 | - 源代码 - 单元测试代码 - 构建产物（如 jar、apk、exe） | - 编写/维护自动化测试脚本 - 执行冒烟测试/每日构建验证 - 与开发协作进行缺陷修复验证 - 推动单元测试覆盖率 |
| 5. 测试 | 执行各类测试，验证系统是否满足需求，发现并跟踪缺陷。 | - 测试用例 - 测试报告 - 缺陷报告（Bug List） - 质量评估报告 | - 执行功能、回归、集成、系统等测试 - 提交并跟踪缺陷 - 验证修复结果 - 输出发布质量建议 |
| 6. 运行维护 | 项目测试结束之后，项目需要进行上线，并对产品进行 线上的维护。线上的维护主要分为三个方面。分别为修 复性维护、完善性维护和预防性维护。 修复性维护：对项目中未发现的问题进行修复。 完善性维护：对功能进行完善。 预防性维护：居安思危，为了避免产品在线上出现一 些其他不可预料的问题，进行一些防护的手段 | - 运维日志 - 用户反馈记录 - 热修复/补丁版本 | - 监控线上质量（如错误率、性能） - 支持线上问题复现与定位 - 回归测试补丁版本 - 收集生产问题用于改进测试覆盖 |
开始——>需求分析——>计划——>设计——>编码——>测试——>结束
可以看到和软件的生命周期还是有点类似的
优缺点如下：
优点 | 缺点 |
1.强调开发的阶段性 2.线性结构，每个阶段只执行一次 3.是其他模型的基础框架 | 1.测试后置 前面各阶段遗留下来的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会 必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给用户 2.周期长，产品或许很迟才能被看到和使用，可能会导致需求/功能过时 |
综上来说，瀑布模型适用场景：需求固定的小项目
图片来源：https://www.itcast.cn/news/20201008/15522827061.shtml
在有些场景中，软件开发的初期需求不是很明确时，会采用渐进式的开发模型。而螺旋模型是渐进式开发模型代表之一。
优缺点如下：
优点 | 缺点 |
强调严格的全过程风险管理 强调各开发阶段的质量 增加风险分析和原型 | 项目中存在发风险性与风险管理人员的技能水平有直接关系 需求人员、资金、时间的增加和投入，可能导致项目成本过高 |
增量模型：
将系统划分为多个功能增量，每个增量都是一个可交付的完整子系统，逐步叠加直至完成全部功能。
可以理解为：先做一部分功能、做完再做下一部分
迭代模型：
通过多次循环开发、每次迭代都包含需求、设计、编码、测试等完整流程，逐步完善系统
可以理解为：每次做全功能、但越来越完善
优缺点对比如下：
对比维度 | 增量模型（Incremental Model） | 迭代模型（Iterative Model） |
优点 | - 用户可早期使用部分功能 | - 快速响应变化 |
缺点 | - 增量间接口需提前规划，否则集成困难 | - 管理复杂度高 |
敏捷模型是一种以人本、协作、响应变化和可工作软件为核心的软件开发方法论，强调小步快跑、持续交付、快速反馈，它不是单一的模型，而是一类方法的统称。
它存在着一个重要的《敏捷宣言》内容如下：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
由此可以总结出四个特点：轻文档、轻流程、重目标、重产出
敏捷开发有很多方式，其中较为流行的是：scrum方式
scrum：又称为迭代式增量软件开发模型
其中三个角色和五个重要会议是比较重要的
1.product owner（产品经理） ：负责整理user story（用户故事） 定义商业价值，对其进行排序，制定发布计划，对产品负责
2.scrum master（项目经理）：负责召开各种会议，协调项目，为研发团队服务。
3.team（研发团队）：研发团队由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品
1.发布计划会议：
产品经理负责讲解用户故事，对其进行估算和排序，发布计划会议的产出：就是制定这一期迭代要完成的story列表，sprint backlog
2.迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初步预估
3.每日例会：项目经理召集站立会议，团队成员回答昨天做了什么、今天计划做什么、有什么问题
4.演示会议：迭代结束后，召开演示会议，相关人员都受邀参加，团队负责人向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由产品经理整理，形成新的story
5.回顾会议：项目团队对本期迭代进行总结、发现不足、制定改进计划，下一次迭代继续改进，以达到持续改进的结果
那么对于这个开发模型分享到这里，接下来分享下测试模型
在测试中，有两个非常重要且具有标记性的测试模型：V模型和W模型
V模型是瀑布模型在测试领域的延伸，强调开发阶段与测试阶段的一一对应关系，左侧是开发活动，右侧是测试活动，形成V字形结构
优点：
明确标注了测试过程中存在的不同类型的测试，并且清除的描述了这些测试阶段和开发过程期间各阶段的对应关系，有效提升测试的质量和效率
缺点：仅仅把测试作为编码之后的一个阶段，未在需求阶段就介入测试，缺点就类似于瀑布模型
是对v模型进行改进，它强调：测试不仅针对程序本身，也针对开发过程中所有工作产物（如需求文档，设计文档），且测试活动与开发活动并行开展。
图片来源：https://blog.csdn.net/weixin_51059284/article/details/123208765
W模型的核心特点：
有两个V字叠加，形成W形
左侧V：开发过程+对应的测试设计
右侧V：验证与确认并行
测试对象扩展：不仅测代码、还测需求、设计等文档（即静态测试）
测试尽早介入：从需求阶段就开始测试活动（如评审、检查）；
对比如下：
