需求
需求的定义
用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
软件需求：产品经理会把用户需求转化为软件需求（写成一个文档），开发人员和测试人员工作的直接依据就是软件需求，软件需求是测试人员进行测试工作的基本依据。
为什么会有需求
因为这将直接关系到用例的 测试覆盖率，同时对于识别出的每个测试需求点，要采用 具体的设计测试用例的方法 来实现测试用例的设计。
测试角度中的需求
把每一块需求进行拆分，划分成一个个子需求。
深入了解需求
测试工程师在需求分析和设计阶段就开始介入，（就是参加需求评审会议）因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
测试用例（CASE）
什么是测试用例
测试用例是一组集合，包含测试环境、测试数据、预期结果、操作步骤......
| 测试用例 : 用户注册 | |
| 操作步骤 | 期望结果 |
| 进入注册页面，选择注册 | 系统展现注册页面 |
| 输入符合要求的单位名称、单位邮箱、密码、确认密 码、组织机构代码、验证码，并确认同意《用户注册 协议》，提交注册信息 | 系统进行注册操作，发送激活邮件。注册 成功后，跳转到注册成功页面，并提示用 户进行激活操作。 |
| 进入注册用的邮箱，进行激活操作 | 激活成功 |
| 用注册的邮箱和密码，进行登录操作 | 登录成功，系统展示欢迎页面 |
| 测试方式 | 手动 |
| 重要性 | 重要 |
| 测试环境 | Chrome 浏览器 |
| 测试前提 | 系统运行正常，邮件服务器已开启 |
| 功能模块 | 注册登录 |
为什么会有测试用例
1、可以提高测试人员的工作效率 / 降低工作重复性
2、测试用例是建立自动化的基础
软件错误（BUG）
开发模型和测试模型
软件的生命周期
开发模型
瀑布模型（小型项目）
优点：每个阶段需要做什么都非常清晰
缺点：测试人员介入太晚，导致发现问题的时机也太晚
螺旋模型（较大项目、风险较多）
优点：每个阶段都会进行风险分析，在一定程度上避免在上线后发生
缺点：可能风险分析错误，需要大量人力财力投入
增量、迭代
增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，增量先画人的头部，再画身体，再画手脚。
而迭代是反复求精的概念，同样是画人物画，迭代采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
敏捷
scrum 开发方式
scrum里面的角色
迭代开发
scrum的基本流程
产品负责人负责整理user story，形成左侧的product backlog。
发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。
测试模型
测试 V 模型
特点：左边是开发，右边是测试。类似于 瀑布模型
优点：测试被划分成许多类型
缺点：测试人员介入太晚，导致发现问题的时机也就太晚
测试 W 模型（双 V 模型）
特点：开发一个 V，测试一个 V
优点：测试人员早早就介入了
缺点：测试和开发一定程度上还是串行的、不能拥抱变化也就不适用于敏捷
