1. 什么是需求

需求主要分为两种： 用户需求 和 软件需求

用户需求：可以理解为就是甲方提出需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。这种需求一般是比较简略的，并且用户需求是五花八门的

软件需求：也就是功能需求，详细描述了开发人员必须实现的软件功能

开发人员和测试人员的直接工作依据就是软件需求

用户的需求能否作为测试和开发的直接工作依据？

肯定是不能的，因为大多数的公司在进行软件开发时，是把用户需求转化为软件需求，这个过程依据，

比如技术是否可行，市场是否可行，成本投入和受益占比等多方面分析的

2. 测试用例是什么

假如要测试一个输入框，应该怎么设计测试用例

空字符串？特殊字符？超长字符串还是中英文符号

测试用例的存在就是要解决两个问题，测什么，怎么测

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

3. Bug 是描述

1. 当前仅当规格说明（需求文档 / 产品规格说明书）是存在的并且正确，程序与规格说明之间的不匹配才是错误**
2. 当需求规格说明没有提到的功能，判断标准最终以用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误

4. 产品的生命周期

开发流程/软件的生命周期

产品的生命周期：需求分析—— 计划 —— 设计 —— 编码 —— 测试 —— 运行维护

1. 需求分析：市场分析、技术上是否可行、成本和收益占比

2. 计划：什么时候开始、什么时候结束、耗时多久

3. 设计：将大的需求转变为一个个可具体执行的任务。进行开发设计（开发哪些接口、使用什么开发框架、使用什么技术）

4. 编码：开发人员参考需求文档和技术文档等等来进行代码开发

5. 测试：测试人员参考测试用例来设计

6. 运行维护：

   完善性维护：对功能进行完善

   修复性维护：对项目中没有发现的问题要及时进行修复

   预防性维护：为了避免产品在线上运行期间出现意想不到的问题，需要进行一些预防性的手段

5. 软件测试贯穿于软件的整个生命，如何贯穿？

软件测试的生命周期：需求分析 —— 测试计划 —— 测试设计与开发 —— 测试执行 —— 测试评估

1. 需求分析：

   用户角度思考问题：软件需求是否合理

   技术角度思考问题：技术上是否可行，还是否有优化空间

   测试角度思考问题：是否存在业务逻辑冗余/冲突

2. 测试计划：什么时候开始测试、什么时候测试结束、耗时多久

3. 测试设计与开发：写测试文档，明确标注使用到的测试方法，测试工具，测试形式，参考需求文档，技术文档等等编写测试用例

4. 测试执行：充分利用测试用例和其他工具对项目尽可能做到全方面的覆盖测试

5. 测试评估：评估产品是否存在其他的质量问题，功能演示

面试题：如果线上出现问题，测试人员应该怎么做？

项目测试完成之后，需要进行项目上线。产品在线上运行期间我们测试人员也需要及时关注产品线上运行情况，是否出现了产品质量问题，如果出现了问题：

1. 尝试复现（普遍都存在的问题还是个别问题）复现成功后通知项目组内所有成员进行问题的定位
2. 尝试定位问题出现的原因，帮助开发人员尽快定位问题并解决问题
3. 反思问题（为什么出现，如何解决，后续如何避免）如果问题较严重或者比较典型的问题，通常要写文档

6. 开发模型（瀑布模型、螺旋模型、增量模型和迭代模型、敏捷模型）

（1）瀑布模型

使用场景：需求固定的小项目

特点：

1. 线性结构，每个阶段只执行一次（如果需求分析不充分，有风险遗漏，那么所有的风险都会在测试阶段暴露出来）
2. 是其他模型的基础框架

缺点：

1. 测试后置

   1）前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会

   2）必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷暴露给用户（产品质量差）

2. 周期太长，产品很迟才能被看到和使用（可能会导致需求/功能过时）

（2）螺旋模型

使用场景：规模庞大、复杂度高、风险大的项目

特点：螺旋模型中增加了风险分析和原型

缺点：

1. 项目中可能存在的风险性与风险管理人员的技能水平有直接关系
2. 需要人员、资金、时间的增加和投入，可能会导致项目的成本太高

（3）增量模型和迭代模型

增量模型里把大的需求划分成一个个可以独立开发上线的功能

假如有一个软件，共有A B C D E 五个功能

增量模型：可以先开发 A B 功能，再开发 C D E

迭代模型：先开发 A B C D E 的基础版本，然后在基础版本上不断的进行功能的完善

增量和迭代两者是有区别的，增量是逐块建造的概念，迭代是反复求精的概念

（4）敏捷模型

《敏捷宣言》中的价值观：

个体与交互重于过程和工具

可用的软件重于完备的文档

客户协作重于合同谈判

响应变化重于遵循计划

在每对比对中，后者并非全无价值，但我们更看重前者。

敏捷模型中考核标准：可交付的软件

特点：轻流程、轻文档、重目标、重产出

敏捷模型拥抱变化

敏捷开发有很多方式，其中 scrum 是比较流行的一种

scrum模型

三个角色和五个重要会议

三个角色：产品经理、项目经理、研发团队组成

五个重要会议：

7. 测试模型（V模型、W模型）

（1）V模型

特点：

1. 测试过程中存在的不同类型的测试
2. 测试阶段的参考标准以前面对应阶段为准

缺点：测试后置

（2）W模型（双V模型）

特点：W模型重流程、不能够迎接变化、W模型不适用于敏捷模型