软件测试基本概念

软件测试：
软件测试目的：软件测试就是验证软件功能是否满足用户的需求。（）实际就是找bug，以及验证软件功能的正确）
软件测试原则：以客户为中心，遵循软件测试的规范、流程、标准和要求

需求：
需求：满足用户期望或正式规定文档（合同、标准、规范）所具有条件或权能（暂且理解为权限），包含用户需求、软件需求
用户需求：甲方提出的需求，没有甲方就是终端用户使用产品时必须要完成的任务，该需求一般比较简略
软件需求：功能需求，详细描述开发人员必须实现的软件功能

bug：
当且仅当规格说明是存在的并且是正确的（一定要有一个标准），程序与规格说明之间不匹配才是错误（缺陷）。

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

开发模型与测试模型：

首先要了解软件的生命周期：
需求分析—计划—设计—编码—测试—运行维护
瀑布模型：Start—需求分析—计划—设计—编码—测试—end
优点：强调开发的阶段性、早期计划及需求调查。产品测试
缺点：依赖早期进行的唯一依次需求调查，不能适应需求的变化，开发中的经验教训不能反馈给本次产品，风险（尤其是集成风险）往往在后期的测试阶段才显露，失去及早纠正的机会

螺旋模型： 渐进式开发模型，适用于规模庞大、复杂度高、风险大的项目
特点：不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代
优点：严格的全过程风险管理（每次都有风险分析），强调各开发阶段的质量，提供机会检讨项目是否有价值继续下去
缺点：对风险管理的技能水平提出很高的要求

敏捷：
价值观：沟通、轻文档、客户参与、拥抱变化
敏捷开发的方式：scrum
scrum中角色：
product owner（产品经理） ：负责user story 定义其商业价值，对其进行排序、制定发布计划、对产品负责
scrum master（项目经理） ：召开各种会议、协调项目、为研发团队为服务
team(研发团队)：由不同技能的成员组成，交付产品
scrum基本流程：6步
产品负责人整理user story，形成product backlog
发布计划会议：po讲解user story，对其进行评估、排序，以及产生spring backlog
迭代计划会议：任务认领，工时初估计
每日例会：scrum master召开站立会，团队成员提出计划，反馈问题
演示会议：团队负责人展示本次迭代取得成果，po记录反馈，形成新的story
回顾会议：团队对本期迭代进行总结，发现不足，制定改进计划
敏捷中的测试： 注重灵活 沟通
核心还是信号bug、不能依赖文档，更注重探索性测试，自动化测试、讲求合作，测试应主动与开发沟通

V模型：

特点：活动串行，是瀑布模型的变种
优点：既有底层的设计（单元测试），又有高层的设计（系统测试）
缺点：仅仅把测试作为编码之后的一个阶段，发现问题晚，修改成本高、忽视了对需求的分析

W模型：

特点：测试开发同时进行（并行）测试对象不仅是程序，需求、设计也要测试
优点：有利于尽早的全面发现问题，对需求的测试有利于及时了解项目难度和测试风险，
缺点：需求、设计、编码等活动仍然是串行的，仍然不支持迭代

配置管理和软件测试
配置管理：通过对软件生命周期不同时间点上的软件配置进行标识，并对这些被标识的软件配置得更改进行系统控制，从而达到保证软件产品的额完整性和可塑性的过程。
测试人员应该从配置库取源代码编译后进行测试