需求

需求的概念：满足用户期望或正式规定文档(合同、标准、规范)所具有的条件和权能，包含用户需求和软件需求
用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需要一般比较简略
软件需求(功能需求)：该需求会详细描述开发人员必须实现的软件功能
大多数公司在进行软件开发时会将用户需求转化为软件需求，开发人员和测试人员的直接依据就是软件需求，用户需求就是一句话，软件需求是一个文档(详细描述用户需求如何实现)，日常工作我们通常是软件需求进行开发测试

软件测试人员角度的需求
需求是测试人员展开软件测试工作的依据
在具体设计测试用例时，首先要搞清楚每一个业务需求对应的多个软件功能测试点，然后分析每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例：
业务需求 -> 软件功能需求点 -> 测试需求点 -> 测试用例
用户登录测试过程：
在这里插入图片描述
为什么需求对软件测试人员如此重要?
1.从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
2.对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来设计测试用例

如何才可以深入理解被测试软件的需求？
测试工程师猜需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件原始业务需求的最好时机，只有真正理解原始业务需求之后，才有可能从业务需求点角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集

测试用例

测试用例(Test Case)：是为了实施测试而向被测试的系统提供的一组集合，包含：测试环境，操作步骤，测试数据，预期结果等

比如我们我们再刷leetcode
测试环境：Java、C++
测试操作：写代码，提交
测试数据：后台一系列的样例
预期结果： AC，100%

在这里插入图片描述
我们就可以对我们之前写的一个博客系统登录页进行测试
测试环境：windows系统 + chrome浏览器
测试步骤：输入账号，密码，点击提交
测试数据：对账号密码进行比对
预期结果：登录成功

为什么有测试用例？
1.提高测试人员的工作效率/降低测试人员工作的重复性问题
2.测试用例是自动化测试的基础

BUG

软件错误的一般定义：程序与规格说明不匹配

以上的说法是片面的，准确的来说：当且仅当规格说明(软件需求，规格说明书)是存在的并且正确，程序与规格说明之间不匹配才是错误，当规格说明书没有提到的功能，判断标准以最终的用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

软件生命周期

在这里插入图片描述
软件的生命周期只从软件产品的设想开始到软件不再使用而结束的事件。软件的生命周期可以分为6个阶段：需求分析、计划、设计、编码、测试、运行维护
需求分析：分析需求是否合理，需求是否完整
计划：谁开发，谁测试，开发多久，测试多久
编码：写代码
测试：进行测试，写测试报告
运行维护：如果项目有问题，测试人员需要协助开发定位问题 + 解决问题

开发模型

1.瀑布模型
在这里插入图片描述

特点：线性进行的
优点：每个阶段做什么得到什么十分清晰
缺点：风险往往会推迟到后期的测试阶段才显现出来，因此会失去尽早纠正的机会
适用的项目：小型的项目适用于这种模型

2.螺旋模型
在这里插入图片描述
优点：每个阶段都会进行风险分析，尽早的发现问题
缺点：风险分析可能会分析错，需要人力财力的投入
适用项目：适用于比较大的项目，风险较多的

3.增量、迭代
增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。
比如我们之前开发的博客系统，有以下几个板块：登录页，博客列表页，博客编辑页。
增量模型就是：登录功能开发完成 -> 博客列表页开发完成 -> 博客编辑页开发完成
迭代模型：登录开发一部分 -> 列表页开发一部份 ->编辑页开发一部分

区别：
1.核心思想不同：增量模型是将软件系统划分为多个增量模块，逐步实现软件系统，每个增量模块可以在原有软件系统基础上添加新的功能或优化已有功能。而迭代模型则是将整个软件项目分解成多个迭代周期，每个周期包含需求、设计、实现和测试等工作流程。
2.交付物不同：增量模型每个增量模块在完成后即可交付和部署，每个增量模块都是可执行的子系统，可以独立运行。迭代模型则是每个迭代周期都会有一个可交付的软件产品，每个产品版本是最终产品的一个子集。
3.开发方式不同：增量模型采用垂直式的开发方式，即将软件系统按功能分解为若干子系统，每个子系统由一个小团队专门负责。迭代模型采用水平式的开发方式，即所有开发工作都在同一时间进行，每个迭代周期涉及到整个软件系统各个方面的开发工作。
4.需求变更处理方式不同：增量模型能够快速响应用户需求变更，每个增量模块可独立地进行需求变更处理。而迭代模型需要在每个迭代周期的开始前和结束后确定和评估所有的需求变更。

总的来说，增量模型适用于长期、大规模软件系统开发，特别是对于需求变化频繁的软件项目；迭代模型适用于较小规模且需求相对稳定的软件项目。并且在实践中，各种过程模型可以根据自身的情况做出一些自定义调整，以适应具体的软件开发项目。
4.敏捷
敏捷开发是一种以人为本、迭代、循序渐进的软件开发方法，强调在整个软件开发过程中与客户进行频繁的沟通和协作。敏捷开发的核心在于不断地快速迭代、交付、反馈和改进，以适应需求变化和市场竞争的挑战。敏捷模型的流程通常有以下价值观：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者

敏捷模型的灵活性和可适应性较强，在敏捷开发过程中可以根据项目的实际情况进行相应的调整和优化，以更好地满足需求变化和市场挑战。

scrum

scrum：product owner(产品经理)、scrum master(项目经理)、team(研发团队，后端开发、前端开发、UI设计师、测试等)组成
product owner：负责整理用户需求，定义商业价值，对其排序，制定发布计划，对产品负责
scrum master：负责召开各种会议，协调项目，为研发团队服务
team：不同技能的成员组成，通过紧密协调，完成每一次迭代的目标，交付产品
在这里插入图片描述

测试模型

1.V模型
目的是未来改进软件开发的效率和结果是瀑布模型的变种
在这里插入图片描述
特点：左边是开发，右边是测试，类似于瀑布模型
优点：测试划分为了许多类型
缺点：测试人员介入太晚，发现问题的时机太晚
2.W模型

特点：开发一个V测试一个V
优点：测试人员尽早的介入了需求
缺点：测试人员和开发人员一定程度还是串行的，不能拥抱变化，不适用于敏捷