1. 衡量软件测试的结果——需求

用户需求：甲方提出的要求，终端使用的产品必须要完成的任务。该需求一般比较简略
软件需求：也叫做功能需求，会详细描述开发人员必须实现的软件功能

客户需求会被转化为软件需求，开发人员和测试人员工作的直接一句就是软件需求
软件需求是测试人员进行测试工作的基本依据

2. 测试用例

2.1 概念

测试用例是向被测试系统发起的一组基和，这个集合包含测试环境，测试数据，测试步骤，预期结果，标题，重要性，功能模块，优先级，是否手工

2.2 测试用例举例

正确的用户名：admin
正确的密码：root
用以上正确的用户名和密码可以成功登陆邮箱
测试环境：win11 Edge 105.0.1343.33
测试数据：admin root
测试步骤：

1. 打开Egde浏览器，输入URL

2. 输入用户名和密码

3. 点击登录按钮（Enter），触发登录

预期结果：登陆成功或者页面跳转

3. 什么是BUG

当且仅当软件需求说明书存在且合理，软件的功能不符合需求规格说明书，就是软件错误（BUG）【软件需求规格说明书也就是软件需求文档】

如果软件需求规格说明书不存在，那么用户的需求存在并且合理。软件的功能和用户需求不相符合就是软件错误（BUG）

4. 软件开发的五大模型和软件测试的两大模型

4.1 软件开发的生命周期

需求分析——计划——设计——编码——测试——运行维护【软件从产品的设想开始到软件不再使用而结束的时间】

4.2 开发五大模型

4.2.1 瀑布模型（Waterfall Model）

特点：每一个阶段比较独立，串行，注重前期需求分析，后期系统测试
缺点：测试介入晚，导致软件前期的问题，后期测试阶段才发现，失去了错误及时修正的机会，不响应需求的变化

4.2.2 螺旋模型

适合项目庞大复杂，风险性较高的项目
特点：注重质量管理，每一次迭代都会进行风险评估
缺点：风险分析投入人力，资源，管理成本，成本比较高

4.2.3 增量模型

抗风险能力比较强

4.2.4 迭代模型

抗风险能力比较强

4.2.5 敏捷模型

thought works

特点：轻文档，请流程，重目标，重产出，响应变化

经典的敏捷流程：scrum 流程

角色

PO【Product Owner】产品经理，负责收集需求，转化成 User Story

SM【Scrum Master】项目经理负责保证这个敏捷流程的实施

ST：各种技能的研发人员组成，测试，研发，UI…

发布计划会议：PO把整理好的 User Story 进行讲解，排优先级，找出优先级高的组成本次的迭代内容，形成 Sprint Backlog

迭代计划会议：SM 和 ST 人员一起把本期要迭代的需求进行分析，任务分配和时间估算

每日站会：昨天做了什么，遇到的问题，今天的计划

产品演示：给客户演示产品，讲解，把不足的地方和客户提出的修改意见整理成 User Story 放到下一期迭代
回顾会议：回顾本次的敏捷流程，把不好的地方找出来，下次迭代改进，优化敏捷流程

4.3 测试两大模型

4.3.1 V 模型

特点：左边每一个阶段和右边的阶段一一对应，左边的每个阶段是右边测试的每一个阶段的依据，串行【瀑布模型的变种】
缺点：测试在编码之后进行，测试介入晚，前期的问题后期才发现，导致前期问题不能及时解决

4.3.2 W模型（双V模型）

特点：开发一个V，测试一个V。软件开的过程和软件测试同步进行，保证项目前期的问题能够及时被发现，串行
缺点：不支持需求的变化所以不支持敏捷开发的