软件测试概念
1.什么是软件测试？
软件测试就是软件测试人员验证软件是否满足用户的需求。
2.软件测试和软件开发的区别
(1)本身
开发：广度小，专业度高
测试：所需技能广泛，专业度低
(2)软件测试和软件测试
**目的：**软件开发人员要确保程序做了他想让程序实现的功能
软件测试是测试人员确保程序实现了他应该实现的功能（用户需求）
角色：
测试：开发人员和测试人员共同完成
开发：开发人员
**阶段：**软件测试贯穿到了整个软件开发的生命周期
软件开发在开发阶段
3.你为什么选择软件测试
综合能力：沟通能力、学习能力、开发能力
自动化测试技术
编写测试用例的能力
探索性思维
有兴趣，有责任感
4.什么是需求
用户的期望和满足合同（文档、规则、标准）的规定所需要的条件和权限
用户需求和软件需求
软件需求是用户需求转化来的，他是用户需求的细化，是用户需求的具体实现细节和规范。
用户需求比较粗略，直接实现有困难，所以需要软件需求把用户需求细节实现和规范，把用户需求变成一个具体的可实现的过程文档。
需求是软件测试的依据
验证需求，确保需求正确可实现，细化需求，从需求中提炼出一个个测试项
测试人员如何深入了解需求？
从需求分析阶段就开始介入了解需求
站在用户需求的的角度
测试用例：
测试用例就是向被测试系统发起的一组集合，包含测试环境、测试数据、测试步骤、预期结果（重要性、优先级、操作方式、标题等）
测试用例
测试用例感受我们测什么，怎么测
优点：衡量需求的覆盖率；复用性，借鉴意义；用于回归测试；防止遗漏测试需求
5.什么是BUG？
当且仅当，程序规格说明书（软件需求）存在并且合理，如果软件功能和软件规格说明书不相符合，就认为是软件错误；
当软件需求不存在，用户需求存在且合理，软件功能和用户功能不相符合，就说明软件错误；
软件测试贯穿到了整个软件开发的生命周期，验证需求的合理性和正确性
6.开发模型（5个模型）
软件开发的生命周期
软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码（开发）、测试、运行维护。
6.1 瀑布模型
特点：阶段性强，每一个阶段比较独立；比较看重前期的需求分析和后期的测试
缺点：测试在编码后才介入，导致前期问题后期才发现，失去了错误补救的机会
6.2螺旋模型
适合于项目庞大，前期风险大，不是很明确的项目
特点：强调每一个迭代的测试质量和风险分析
缺点：风险管控人力物力投入多，成本投入大
6.3增量模型，迭代模型
同一个系统的四个模块A,B,C,D
增量模型：
第一周开发A,B功能模块
第二周开发C,D功能模块
迭代模型：
第一周先开发A,B,C,D的基础功能，第二周再在第一周的基础上完成其他功能
特点：抗风险能力强，
6.4敏捷模型
敏捷宣言：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
特点：轻文档，轻流程，重目标，重产多
scrum流程
角色：（5~7人）
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
PO product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。（产品经理）
SM scrum master 负责召开各种会议，协调项目，为研发团队服务。（项目经理）
研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
ST scrum team 各种技能的人组成，开发、测试UI等
流程：
发布计划会议：产品经理手机需求形成user story，讲解，排出本迭代需要进行开发的user story形成spring backlog
迭代计划会议：分析用户故事，把user story分解成一个个任务，分配开发人员，制定开发计划
每日站会：昨天做了什么，遇到的问题，今天的计划
产品演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
回顾计划会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。
7.测试模型
7.1软件测试V模型
特点：每一个阶段独立性比较强；
左边的每一个阶段是右边测试阶段的依据，和右边每一个测试阶段一一对应
是瀑布模型的变种缺点和瀑布模型一样（编码后才能测试，前期问题后期才发现，失去了错误补救的机会）
7.2 W模型（双V模型）
特点：每一个阶段独立性比较强，测试和开发一同介入，可以保证前期的问题及时发现和纠正，测试与开发是同步进行的
局限性：每一个阶段都是串行的过程，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式（拥抱变化）。
需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑
