螺旋模型（风险）
2.3.4 敏捷模型
主要困难包括在项目开发期间处理来自客户的变更请求以及合并这些变更所需的高成本和时间
轻文档，轻流程，重目标，重产出
在scrum模型中，主要有三个角色和五个重要会议
三个角色：产品经理、项目经理和研发团队组成
产品经理（产品经理收集需求，产出软件需求文档）
项目经理（负责召开各种会议，协调项目，为研发团队服务。资源，人）
研发团队（由很多角色组成：开发人员(前端、后端)、测试、交互、设计。。。）
迭代开发：
与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。（重目标，重结果）
scrum的基本流程：五个重要会议
产品负责人负责整理(用户需求)user story，形成左侧的product backlog
1.发布计划会议：product owner负责讲解user story（用户需求），对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog.
2.迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
3.每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题
4.演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
5.回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果。
敏捷中的测试：
轻文档和快速迭代
敏捷模型中强调轻文档，所以测试人员不应使用传统的Excel编写测试用类的方法，更多的是使用思维导图、探索性测试（强调自由度，设计和执行同时进行，根据测试结果不断调整测试计划）、自动化测试等
敏捷讲求合作，在敏捷项目组中，测试人员应多主动跟开发人员了解需求、讨论设计、一起研究bug出现的原因
2.4测试模型
测试模型中有两个非常重要且具有标志性的测试模型：V模型和W模型
单元测试参考的是详细设计
集成测试参考的是概要设计
系统测试参考的是需求分析与系统
验收测试参考的是用户需求
V模型的缺点：测试是在编码之后的一个阶段，未在需求阶段就介入测试。缺点和瀑布模型一样
2.4.2 W模型（双V模型）
V模型中未将测试前置的问题在W模型中得以解决（测试前置）
开发V模型并不是单单指编码阶段，而是为产品开发流程而实施的各个阶段
特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
W模型缺点：
1.需求、设计、编码等活动被视为串行的；
2.测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
3.重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。敏捷开发模式（轻文档轻流程）
Bug篇
软件测试贯穿于软件的整个生命周期
| 需求分析 | 测试计划 | 测试设计与开发 | 测试执行 | 测试评估 | 上线 | 运行维护 |
|---|---|---|---|---|---|---|
| 用户角度：软件需求是否合理 技术角度：技术上是否可行，是否还有优化空间 测试角度：是否存在业务逻辑错误、冗余、冲突等问题 | 制定测试计划：什么时候开发测试，什么时候结束测试，耗时多久 | 参考需求文档、技术文档等编写测试用例 写测试文档，明确标注使用到的测试方法，测试工具，测试形式等等 | 充分利用测试用例和测试工具对项目尽可能做到全方面的测试覆盖 | 测试是否通过，本次测试是否有遗留的BUG,最终测试人员需要产生一个测试报告 | 项目测试结束后，将项目发布到线上环境，测试人员需求跟踪上线并测试线上环境下软件的运行是否正确 | 测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人 |
演示会议：由测试人员来演示产品/软件
测试人员一般是最了解需求的人
测试人员不仅要具备开发能力、测试能力，最好具备一等的产品分析能力
bug的概念
准确来说：
1.当且仅当规格说明（需求文档）是存在的并且正确，程序与规格说明之间的不匹配才是错误。
2.当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
一切要以需求出发
验证软件产品的特性是否符合用户的需求
bug描述1：百度一下按钮不好看
按钮是太大了？太小？颜色？形状？。。。。
描述不清晰，不具体，无法通过描述来快速定位问题
提高了沟通成本，降低了工作质量
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
