一.相关概念
1. 软件测试
软件测试就是检测软件是否满足用户的需求。测试就是以评价一个程序或者系统属性为目标的一种活动，是对软件质量的度量。
2. 软件测试和研发的区别
（1）软件测试和调试区别
目的不同：
测试是发现软件中存在的问题；
调试是定位并解决软件中存在的问题。
角色不同：
测试可以是开发人员，也可以是测试人员；
调试只能是开发人员。
阶段不同：
测试贯穿于整个软件开发的生命周期；
调试只能在开发阶段。
（2）开发要求技能少，专业度高；测试要求技能广，深度低。
3. 软件开发的生命周期
4. 需求
满足用户的期望或者合同规定的文档所需的条件和权能。
软件开发的过程：
软件需求是用户需求转化而来的，经过对用户需求的验证和分析之后，具体功能实现的细节说明。
5. 什么是 BUG ？
当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
6. 什么是测试用例？
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
二. 开发模型
软件开的发的生命周期：
1. 瀑布模型
流程：
定义：
瀑布模型是一个项目开发架构，将软件生命周期的各项活动规定按固定顺序连接成若干阶段的工作，形如瀑布流水，因此是线性顺序进行的软件开发模式，是所有其他模型的基础框架。
优点：
- 强调开发的阶段性；
- 强调早期计划及需求调查；
- 强调产品测试。
缺点：
- 依赖于早期进行的唯一一次需求调查，不能适应需求的变化；
- 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
- 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。
2. 螺旋模型
定义：
螺旋模型采用一种周期性的方法来进行系统开发，这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段。由这4个阶段进行迭代，软件开发过程每迭代一次，软件开发又前进一个层次。
一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
优点：
- 强调严格的全过程风险管理；
- 强调各开发阶段的质量；
- 提供机会检讨项目是否有价值继续下去。
-
缺点：
- 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。
3. 增量模型
增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求，下一个版本纳入更多的需求，依此类推，直到系统完成。
4. 迭代模型
把整个软件开发过程细化为一系列不同功能的小项目，在一次次的迭代过程中，不断有新的功能被创造出来，每一次的迭代都包含了对项目的需求分析、设计、实现与测试。当迭代到了一定程度后，可以通过客户的反馈来进一步细化需求，开始新一轮的迭代。
优点：
- 降低了项目的开支风险；
- 可以在较为靠前的时间就发现风险
- 加快了整个开发工作的进度
- 可以适应需求的变化。
增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
5. 敏捷开发
小结： 轻文档、轻流程、重目标、重产出
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，相对于传统软件开发方法的“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
scrum里面的角色
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
- 产品经理负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
- 项目经理负责召开各种会议，协调项目，为研发团队服务。
- 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
scrum的基本流程：
- 产品负责人负责整理user story，形成左侧的product backlog。
- 发布计划会议：产品经理负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的任务列表sprint backlog。
- 迭代计划会议：项目团队对每一个任务分解，分解的标准是完成所有任务，每个任务都有明确的负责人，并完成工时的初估计。
- 每日例会：每天项目经理召集站立会议，团队成员回答昨天的进度和问题。
- 演示会议：迭代结束之后，召开演示会议，相关人员都应参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由产品经理整理，形成新的任务。
- 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。
三．测试模型
测试工作的核心内容就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主
1. 软件测试v模型
- V模型最早是由Paul Rook在20世纪80年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种，明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系
- V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求
- 局限性：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试。
2. 软件测试W模型
- W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
- W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
- W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
- 局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
四．其它知识
1. 软件测试的生命周期
2. 配置管理
配置管理是通过对在软件生命周期不同的时间点上的软件配置进行标识，并对这些被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。
3. 如何描述一个 BUG ？
- 测试版本
- 测试环境(web系统、电脑系统、浏览器的版本号)
- 测试数据
- 实际结果
- 预期结果
- 其它附件(截图错误、错误日志等)
4. BUG 的级别
- Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
- Critical（严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
- Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
- Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
5. BUG 的生命周期
● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
6. 执行测试的步骤
- 打开待测试的系统
- 打开测试管理工具用例模块，开始执行用例
- 发现bug！进行复现并确认bug的复现步骤
- 记录bug
- 沟通bug
- 验证以前提交的bug
- 确认本次测试完成
- 编写测试报告
五． 总结
本篇我们介绍了有关测试部分的基础概念，包括测试的模型和开发的模型。作为测试人员，需要清楚的去描述一个 BUG，尽可能的锻炼自己的沟通能力，在最短的时间内能够把问题讲述清楚，同时应该不断提升自身的业务能力，具有一定的原则性，对于可能出现的问题，一点也不能放过，做到——胆大、心细！
