目录
定义：软件测试就是一系列活动，这些活动是为了评估一个程序或者软件系统的特性或能力，并确定是否达到了预期的效果。
可以将软件测试理解为一个过程，就是进行一个比较，拿着预期结果和程序执行结果作比较。
软件测试只是一个样本试验，具有不可穷尽性。
一、需求
需求就是满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。
用户需求比较简答，软件需求需要越详细越好。
1.1用户需求
可以简单理解为是甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务，该需求一般比较简略。
1.2软件需求
也可以叫做功能需求，该需求会详细描述开发人员必须实现的软件功能。
1.3需求的重要性
从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。
二、测试用例
什么是测试用例：测试用例是为了实施测试而被测试的系统提供的一组集合，这组集合包含：测试环境，操作步骤，测试数据，预期结果等要素。
执行测试的时候绝大部分测试点都是参考测试用例的。
为什么有测试用例：（1）测试用例解决测试人员工作重复性的问题。（2）测试用例可以提高测试人员工作效率。（3）测试用例是自动化的基础。
三、BUG
3.1什么是BUG
当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能和要求时，就是软件错误；
3.2如何描述一个BUG
（1）发现BUG的版本
（2）问题出现的环境：PC电脑，手机，浏览器型号、版本。
（3）错误重现步骤：通过什么样的操作可以出现这个问题。
（4）预期行为的描述：预期结果的描述。
（5）错误行为的描述：执行结果的描述。
（6）其他：bug标题，bug优先级。
4.3BUG优先级
1、BUG为什么要分优先级
例如一共找到了10个BUG，1-3非常严重，今天必须修复完成。4-7这几个问题明天或者后天修复也行。8-10这几个问题影响不大，如果没有时间修复，也可以等下一个版本开发的时候再修复。
2、BUG有哪些优先级
（1）Blocker（崩溃）：
四、软件开发模型
4.1软件生命周期
软件从诞生到软件不能使用就是软件生命周期。即需求分析，计划，设计，编码，测试，运行维护。
1、需求分析
PM（产品经理）
QA（测试）产出需求文档（软件规格说明书）。
RD（前端和后端开发）判断需求是够合理，需求是否完整。
2、计划
软件开发由谁去做，软件什么时候开发，什么时候结束开发。
3、设计
UI设计师产出一个UI设计稿。
开发人员产出一个技术文档（接口，库表，缓存，mq……）。
4、编码
写代码实现需求。
5、测试
执行测试，提BUG，验收BUG，发送测试报告。
6、运行维护
上线、维护线上软件质量（当发现线上BUG，测试人员需要复现BUG，开发人员需要修复问题）
4.2开发模型
1、瀑布模型
特点：每个阶段时间的关系是线性的。
优点：每一个阶段要做的工作非常的清楚。
缺点：产品效果出现的较晚，如果测试人员介入的太晚，以至于如果测试阶段发现问题，需要不断地向前回溯，如果需求出现问题，那么之前的工作付诸东流，需求需要重新设计。
往往适用于需求非常稳定的项目。
2、螺旋模型
特点：每一次实施的时候都要进行风险分析。
优点：风险分析可以避免一些未知的问题。
缺点：风险分析错误，会导致一系列的损失。风险分析需要一定的成本。
大型项目，具有一些风险一般适用于螺旋模型。
3、迭代、增量
例如淘宝：登录、注册、搜索、查看商品信息、支付……
迭代：先开发淘宝-登录大概框架，先开发淘宝-注册大概框架，先开发淘宝-大概大概框架，查看，支付……
增量：先开发登录直到登录开发结束再去开发注册，注册开发结束在进行下一步……
迭代适用于模块和模块之间没有任何关系。
增量：项目先看到雏形，然后再仔细开发最终实现项目。
4、敏捷开发模型
（1）敏捷宣言：个体与交互重于过程工具。可用的软件重于完备的文档。客户协作重于合同谈判。相应变化重于遵循计划。在每对比对中，后者并非全无价值，但我们更看重前者。
特点：重沟通，轻流程。重交付，轻文档。重交付，轻文档。重协作，轻谈判。拥抱变化。
（2）Scrume角色
PO：产品经理：收集用户需求。
SM：项目经理：对项目进行计划、对需求进行优先级排序。
Team：研发团队（开发、测试、设计师），分别作用是实现需求，负责项目测试，产出交互设计稿。
5、测试模型
（1）V模型
特点：线性的，左边是开发，右边是测试。
优点：将测试分为了好多种类，每个阶段要做的工作非常明确。
缺点：测试接入的太晚，测试和开发是串行的。
（2）W模型
特点：开发一个V，测试一个V
优点：测试人员尽早介入了需求，开发人员和测试人员并行的。
缺点：测试和开发相应来说也是串行的，不能拥抱变化，不能那个适用于敏捷。
转载：https://blog.csdn.net/m0_50987960/article/details/128356466