1. 什么是软件测试
软件测试就是验证软件产品特性是否满足用户的需求
2. 调试与测试的区别
- 目的不同
- 调试：发现并解决软件中的缺陷
- 测试：发现软件中的缺陷
- 参与角色不同
- 调试：开发人员
- 测试：测试人员，开发人员等（单元测试，集成测试主要由开发人员来测试）
- 执行阶段不同
- 调试：编码阶段
- 测试：不是在编码之后！测试贯穿软件的整个生命周期
什么是需求
软件测试的目的和原则：
● 目的：验证软件有或没有问题。
● 原则：以客户为中心，遵循软件测试的规范、流程、标准和要求。
用户需求与软件需求：
● 用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
● 软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。 软件需求是测试人员进行测试工作的基本依据。 （一般为产品经理设计）
软件需求部分案例：
● 用户需求：比较简略，需要进行需求分析转变为供开发和测试参考的软件需求
● 软件需求：具体描述开发人员必须要实现的功能，要讲用户需求转变为软件需求需要进行技术可行性分析和市场可行性分析等待（可行性分析）
什么是bug
bug的缘由：马克一号计算机上面发现的让计算机出错的一只小虫子
● 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
● 当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
软件开发的生命周期
软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软 件的生命周期可以分成6个阶段，即需求分析、计划、设计、编码、测试、运行维护。
- 需求分析：分析用户的需求是否是合理的（市场分析，技术分析…），产出软件需求稳定
- 计划：指定需求执行计划，
- 设计：将需求细化成一个个任务，进行技术设计（设计哪些接口，采用哪些技术），产出设计文档
- 编码：开发人员按照需求文档和设计文档进行编码
- 测试：测试人员参考测试用例来执行测试
- 运行维护：项目上线后对产品进行线上的维护
● 修复性维护：对项目中未发现的问题进行修复
● 完善性维护：对功能进行完善
● 预防性维护：（居安思危）为了避免产品在线上出现一些其他的问题，进行一些预防的手段
案例：实现一个教务系统（用户需求）
7. 需求分析：要实现的功能是什么，具体要求是什么，产出一个需求文档
8. 计划：这样一个需求需要多长时间去推进上线，消耗多长的时间，安排多少的人力，产出计划文档
9. 设计：将功能拆解成一个个任务，产出设计文档
10. 编码：开发人员进行编码
11. 测试：测试人员进行相应测试（贯穿整个软件的生命周期）
12. 运行维护：（居安思危）
测试用例
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步 骤、测试数据、预期结果等要素。
● 测试环境：软件/硬件+版本
● 操作步骤：
● 测试数据：
● 预期结果：
原则：测试用例避免用后即弃，避免了重复测试问题！！！
为什么要设计测试用例？
围绕着软件需求来设计测试用例
解决了重复测试的问题（原则：测试用例避免用后即弃）
提bug -> 开发人员对bug修复完成之后 —> 对bug进行回归验证
版本迭代：对新版本的历史功能也需要进行测试（自动化测试）
开发模型
瀑布模型
瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是 线性顺序进行的软件开发模式。 （元老级别）
● 特点：线性的开发流程（需求完成之后才能开始计划，计划完成之后才可以开始设计…）
● 缺陷：测试被后置，风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。测试可能因为时间不充分导致测试不充分，从而把缺陷直接遗留给用户
● 瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到
● 特点：不能够应对需求的变化
适用场景：需求固定的小项目
瀑布模型是其他模型的基础框架
螺旋模型
螺旋模型引入全流程的风险分析，每次分析完成之后都会生成一个新的原型
适用场景：规模庞大、复杂度高、风险大的项目
缺点：时间拉长，人力资金成本较高（风险分析能力和产品遗留的风险是成反比的）
增量模型和迭代模型
增量模型：假如用户有一个需求，功能包含 A+B+C
运行增量模型开发就是：
● 开发完A就直接上线供给用户去使用
● 开发完B就直接上线供给用户去使用
● 开发完C就直接上线供给用户去使用
大大缩短了开发周期
迭代模型：先开发一个基础版本，包含功能A,B,C，但是功能比较简陋，接来下会继续在基础版本上对ABC功能进行迭代优化
列子：
画人物画时候：
● 增量模型：（逐块建造）先画头，再画身体…
● 迭代模型：（精益求精）先画大致轮廓，再补色，细化…
敏捷模型（互联网主流模型）
敏捷宣言：
- 轻流程，强调人与人之间面对面的高效沟通
- 轻文档，重产出
- 与客户之间的协作比合同谈判的形式更重要
- 需求变化很灵敏
4句宣言想表达敏捷模型的一个特点：轻流程，轻文档，重目标，重产出
度量标准：可交付的软件
scrum ：三个角色，五个会议
三个角色：
- 产品经理：收集用户的需求，编写需求文档，对产品负责的人
- 项目经理：负责召开各种会议，协调项目，为研发团队服务（催作业的人）
- 研发团队：开发人员，测试人员，UI设计人员等待
五个会议： - 发布会议：产品经理派活
- 迭代计划会议：计划，需求拆分成一个一个任务，划分任务给不同负责人，初步确定工时
- 每日列会：总结一天问题，汇报每日工作，规避风险
- 演示会议：2-4周结束之后，产出可以使用展示的软件，进行演示使用
- 回顾会议：回顾总结，新产出的需求再次放回需求池进行下一个周期
敏捷模型可以及时接收需求的变化
scrum的基本流程如上图所示：
● 产品负责人负责整理user story，形成左侧的product backlog
● 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出
这一期迭代要完成的story列表，sprint backlog。（产品经理从需求池里选取几个需求，开展发布计划会议，产出 sprint backlog）
● 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有
明确的负责人，并完成工时的初估计。
● 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。（站会，快速过一下几个问题，意义：及时了解项目进度，预制风险，规避风险；产出物：可交付的软件）
● 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成
果。期间大家的反馈记录下来，由po整理，形成新的story。（产出物：新的 user story（用户需求））
● 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改
进的效果。
