1. 什么是软件测试
软件测试就是验证软件功能是否满足用户需求
在具体业务中表现为，最终交付的产品是否和用户的需求一致，如果不一致，则需要找出不一致的点
2. 软件测试和软件开发的区别
- 难易程度方面
开发对于知识的广度小，专业度高，测试的广度大，专业度低 - 技能要求方面
测试比开发要求更广泛，测试人员需要具备一定的业务能力、沟通能力、对测试工具的收敛使用，是需要有一定的编程能力
3. 软件测试和软件调试的区别
目的
软件测试的目的是验证软件是否满足用户的需求
软件调试的目的是验证软件是否实现了开发人员想让它实现的功能
角色
软件测试是由开发人员和测试人员共同完成的
软件调试是由开发人员完成的
阶段
软件测试贯穿了整个软件开发的生命周期
软件调试只是在开发阶段
软件开发的生命周期
需求分析 -> 计划 -> 设计 -> 开发 -> 测试 -> 运维
4. 什么是需求
需求就是实现用户的期望或者满足文档（合同、标准、规范）所需要的条件或者权限
需求包括软件需求和用户需求
用户需求就是用户想要软件实现的功能，用户需求比较粗略直接实现比较困难
软件需求是从用户需求转化而来的，是对用户需求的细化和具体实现
软件需求是测试人员进行测试工作的基本依据
1）以需求为依据设计测试用例
首先验证需求，保证需求正确可实现，然后细化需求，从需求中提炼出一个个测试项
以 “ 用户登录 ” 为例，具体过程如下：
5. 测试用例是什么
测试用例是为了实施测试向被测试系统提供的一组集合，包含：测试环境、测试步骤、测试数据、预期结果等因素
测试用例告诉我们该测什么，怎么测
设计一条网易邮箱登录的测试用例：
测试环境： Chrome PC端 Windows操作系统
测试数据： 用户名：123456 密码：h123456789
测试步骤：
在 Chrome 浏览器打开网易邮箱 URL
输入用户名和密码
点击登录
预期结果： （操作完测试步骤后的结果）登陆成功
6. 什么是 BUG（软件错误）
当且仅当规格说明书（软件需求）存在且合理，程序和软件需求之间不匹配的情况就是 BUG
当软件需求不存在，用户需求存在且合理，软件功能和用户需求不符合，就说明是软件错误
软件测试在需求分析阶段时需要验证需求的合理性和正确性
7. 五个开发模型
软件开发的生命周期
需求分析 -> 计划 -> 设计 -> 开发 -> 测试 -> 运维
1）瀑布模型
瀑布模型是严格按照软件开发的生命周期进行的分阶段的开发模型
优点： 强调开发的阶段性，强调早期的需求分析和后期的测试
缺点： 测试在编码后才开始介入，导致前期的问题后期才发现，可能会失去错误补救的机会
2）螺旋模型
一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模型，螺旋模型就是典型的 渐进式开发模型，螺旋模型适用于 规模庞大、复杂度高、风险大 的项目
优点： 强调严格的风险管理，强调各开发阶段的质量
缺点： 引入严格的风险管理，需要更多人员、时间和金钱的投入
3）迭代模型、增量模型
将一个系统分为四个模块，A、B、C、D，在两周内将四个模块开发完成
迭代模型：
第一周先开发 A、B、C、D四个模块的基础功能
第二周再在第一周的基础之上完成其他的功能
增量模型：
第一周开发 A、B 两个模块的功能
第二周开发 C、D 两个模块的功能
增量模型和迭代模型抗风险能力都很强，迭代模型相比较增量模型还要更强些
4）敏捷开发模型
敏捷开发是一种可以应对快速变化的用户需求的一种软件开发模式
特点：
轻文档、轻流程、重目标、重产出
拥抱变化，客户可以在整个流程中对需求进行更改
周期短，团队人员少但精干
敏捷宣言：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
Scrum 中的角色
PO（product owner）产品经理，负责整理用户需求，形成 userstory
SM（scrum master）项目经理，管理整个团队，负责敏捷流程的顺利实施，以及各种会议的顺利召开
ST（scrum team）研发团队，负责整个项目的研发，由各种技能的工程师组成
Scrum 流程
发布计划会议： 产品经理收集需求相乘 userstory，讲解 userstory，决定本次迭代需要开发的 userstory 形成 sprint backlog
迭代计划会议： 分析 userstory，把 userstory 分解成一个个的任务，分配给开发人员，制定开发计划
每日会议： 讲解昨天干了什么，遇到的问题、今天的计划
产品演示会议： 给客户演示研发的成果，产品经理整理和手机演示后客户的意见形成新的 userstory，放到下一次迭代中
回顾计划会议： 回顾整个迭代过程，把不足的地方找出，在下一次迭代过程中改进，优化迭代流程
8. 测试模型
1）V 模型
特点： 明确标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程各阶段的对应关系
缺点： 测试在编码之后才被引入，会失去对错误及时纠正的机会
2）W 模型
特点：
- 测试贯穿整个软件开发的生命周期，对需求、代码等都会进行测试测试
- 测试更早的介入，可以尽早发现错误并解决
- 测试与开发独立并行
缺点：
- 测试和开发保持一种线性的前后关系，上一阶段完全结束才可开始下一阶段工作
- 无法支持敏捷开发模型
9. 软件测试的生命周期（软件测试的流程）
生命周期： 需求分析 -> 测试计划 -> 测试设计、测试开发 -> 测试执行 -> 测试报告
需求分析
测试人员对需求进行分析，验证需求的合理性和正确性，细化需求，根据需求提炼测试点
测试计划
确定测试的范围、目的、人员名单、测试工具以及测试环境
测试设计、测试开发
测试人员根据提炼的测试点编写测试用例
测试执行
在开发人员提交代码之后，测试人员根据测试用例和计划执行测试，记录测试过程中发现的 BUG 并提交
测试报告
对本次测试进行分析和总结，记录在本次测试中使用了哪些测试用例，发现了哪些 BUG，修改了多少，剩余的 BUG 有哪些比较好的解决方案
10. 如何描述一个 BUG
一个合格的 BUG 描述包括以下几部分：
发现 BUG 的版本
开发人员提交代码时代码的版本号
测试环境
在不同的测试环境下问题出现的情况可能不一样
测试步骤
告诉开发人员测试数据和执行测试时的具体步骤，以便于开发人员复现 BUG
实际结果
预期结果
BUG 产生时的日志、错误截图等
11. BUG 的级别
1）崩溃
系统崩溃、死机、死循环，黑屏、闪退等导致系统不能运行的问题
如果系统已经发布，用户在使用过程中出现崩溃级别 BUG 怎么办？
可以采用停服维修的方式来对 BUG 进行维护，但是这样会影响用户的体验和产品的利润
最高效且损失最低的方法是，回到上一个稳定可用的历史版本
2）严重
系统可以用，但是不稳定，继续使用会产生严重的错误，如数据库插入用户数据时出错，用户数据的安全性问题等
3）一般
系统可以正常使用，但是一些次要的功能没有实现，如系统的提示语不完善，删除时没有确认弹窗等
4）建议（次要）
一些建议性的问题或者可以对系统进一步优化的方案，比如界面排版不符合用户习惯等
12. BUG 的状态转移图
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取