一、什么是需求
概念：满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含 用户需求和软件需求通俗来讲，就是把用户的需求转化为可以指导研发人员进行设计写代码，并且指导测试人员写测试用例的文档
用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
软件需求是测试人员进行测试工作的基本依据
一般都有软件需求规格说明书，按照说明书完成对应的功能即可
二、什么是BUG（缺陷)
包括代码的缺陷和功能的缺陷
软件错误
当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误
- 当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误
- 通俗来讲，就是与用户需求或者是和需求规格说明书要求不一致的就是缺陷
三、什么是测试用例
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素
- 测试用例是一个集合
- 用例编号是唯一的，比如学生的学号
- 把你进行测试的过程记录下来，测试的步骤，要素，结果等
四、什么是软件的生命周期
软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。如果把软件看成是有生命的事物，那么软件的生命周期可分为6个阶段：需求分析、计划、设计、编码、测试、运行维护
五、开发模型和测试模型
1、开发模型（5种）
瀑布模型（Waterfall Model）
瀑布模型是其他模型的基础框架，是线性顺序的软件开发模式
优点：
- 强调开发的阶段性
- 强调早期计划及需求调查
- 强调产品测试
缺点：
- 依赖早期进行的唯一一次的需求调查，不能适应需求变化
- 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程
- 风险往往在后期的测试阶段才显露，因而失去及早纠正的机会
螺旋模型（Spiral Model）
当需求不明确时，采用渐进式的开发模式，螺旋模型就是渐进开发模式的一种
优点：
- 强调严格的全过程风险管理
- 强调各开发阶段的质量
- 对后期留有时间对项目进行评估
- 适合项目比较庞大，风险比较高的项目
缺点：
- 耗时间、人力、物力
- 风险大
增量、迭代
- 目的：降低项目的风险
- 增量：部分描述
- 迭代：精益求精
敏捷
敏捷开发模型和传统开发模型的区别是敏捷开发模型有12宣言，下面是其中最重要的4个宣言：
- 个体与交互重于过程和工具（人与人之间的沟通）
- 可用的软件重于完备的文档（轻文档）
- 客户协作重于合同谈判（客户参与）
- 响应变化重于遵循计划（拥抱变化）
特点：
- 周期比较短（最快一星期左右，最多一个月）
- 对团队的人数有要求，一般不超过10个人
- 每天都要开晨会（时间不超过15分钟，只三句话，昨天干了什么，今天打算做什么，工作中遇到的问题
- 敏捷开发模式在于如何激发工作人员的热情
scrum是一种敏捷开发模式：
scrum里面的角色
scrum由product owner（产品经理）、scrum master（项目经理）、team（研发团队）组成
- 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责
- scrum master 负责召开各种会议，协调项目，为研发团队服务
- 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品
scrum的基本流程：
- （整理user story）产品负责人负责整理user story，形成左侧的product backlog
- （确定我们要发布的）发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog
- （安排任务）迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计
- （开发）每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题
- 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story
- （测试发布）回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果
敏捷中的测试
挑战1：轻文档
挑战2：快速迭代 （自动化）
- 测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主
- 测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试
- 敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug出现的原因
2、测试模型（2种）
软件测试v模型
- 用户需求：产品经理和用户沟通，测试人员此时只需要了解做什么
- 需求分析与系统：测试参与，了解确定需求的范围、测试功能、制定测试计划
- 概要设计、详细设计：测试人员不参与
- 编码：黄金分割线，左边是研发线，右边是测试线，每一个研发对应相应的测试，研发人员工作完成，测试人员编写测试用例
- 单元测试：白盒测试方法，测试人员写代码测研发人员的代码，传统测试人员不参与，白盒测试工程师或研发人员做
- 集成测试：是代码和功能的测试
- 系统测试：测试人员工作最多、时间最长的阶段，核心， 个阶段，主要做五项工作：测试环境搭建、数据准备、测试执行、缺陷管理、测试报告输出
- 验收测试：测试人员不参与，用户参与
- V模型的优点：（和瀑布模型一样）把测试和研发的每个阶段划分的很明确
- V模型的缺点： 测试阶段比较晚，让人误以为测试不重要，其实很重要。
仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试。发现bug比较晚，修改成本 - V模型的目的：是改进软件开发的效率和效果，是瀑布模型的变种
软件测试W模型（双V模型）
- W模型是为了解决V模型的缺点而引入的，也叫双V模型，图中明确表示了开发和测试的并行关系，测试人员所有阶段参与，不适合敏捷开发模型
- W模型的特点：测试的对象不仅是程序，需求、设计等同样要测试
- W模型的优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度
- W模型的缺点：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式
