前置知识
- 软件测试：验证软件产品特性是否满足用户的需求。
- 软件生命周期：软件有一个孕育、诞生、成长、成熟和衰亡的生存过程。一般有以下几个阶段：
问题定义-可行性研究-需求分析-设计（概要设计-详细设计）-编码-测试-运行和维护
1.软件开发模型
这里主要把握软件开发模型的特点和优缺点
1.1 瀑布模型
- 特点：1）遵循软件生命周期的划分。2)有严格的顺序要求，上一个阶段任务结束才能到下一个阶段任务。3)具有依赖性，前一个阶段正确输出，后一阶段才有正确的结果。
- 优点：文档驱动
- 缺点：交付周期长、测试延后、不能很好应对变化的需求
1.2螺旋模型
- 特点：风险驱动
- 优点：适合复杂的大规模项目，能较好保证软件产品的质量
- 缺点：风险评估好坏依赖风险评估人员的专业能力，成本高
1.3 增量和迭代模型
二者区别：
- 增量模型：把软件产品作为一系列的增量构建来设计、编码、集成和测试。
- 迭代模型：一开始产品较为粗糙，经过逐渐迭代优化后，产品更加完备。
- 优点：交付快、易于应对需求变化。
一般二者结合使用。
1.4 敏捷模型（重点）
- 特点：敏捷模型主要旨在帮助项目快速适应变更请求，主要目的是促进项目的快速完成。轻文档，轻流程，重目标，重产出。
- 优点：快速交付、适应需求变，现在的企业一般都是使用敏捷模型。
《敏捷宣言》中四句话概括敏捷模型的特点：
scrum模型
scrum是敏捷开发中比较流行的一种，scrum 又称为迭代式增量软件开发模型。在scrum模型中，主要有三个角色和五个重要会议。
- 三个角色：product owner（产品经理）、scrum master（项目经理） 、team(研发团队)
- 五个会议：发布计划会议、迭代计划会议、每日例会、演示会议、回顾会议
角色职责
- 产品经理:负责收集用户需求，将需求排序，去掉不合理需求
- 项目经理:把用户需求转化为软件需求，写需求规格说明书，负责资源和人员的协作和调配
- 研发团队：包含开发人员、测试人员、设计人员等负责项目正式实施
关系图（流程图）
2.bug
这里主要把握bug的定义、bug的定级,掌握如何正确详细的描述bug、处理bug的流程
2.1bug定义
当且仅当规格说明（软件需求 / 规格说明书）是存在的并且正确，程序与规格说明之间的不匹配才是错误。
当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
2.2bug等级
具体看公司给bug定级的名称。
一般分为：崩溃、严重、一般、次要
- 崩溃：阻碍开发或测试工作的问题。崩溃等级是加班加点也要处理好的。
- 严重：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
- 一般：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性
- 次要：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
2.3bug描述
bug描述主要包含以下几要素：
- 问题出现的环境（版本）
- 问题出现的步骤（分1、2、3...简洁凝练描述清楚）
- 问题结果（预期结果）
Bug 的处理流程（重点）
推迟修复的bug最后也是一定要修复的
- New：测试人员新发现的 Bug，未经评审决定是否指派给开发人员进行修改。
- Open：确认是否为有效 Bug，并且认为是否需要进行修改，无效的 Bug 则状态流转为 Rejected（拒绝），否则指派给相应的开发人员。
- Fixed：优先级高、时间充裕，开发人员进行修改后标识成修改状态（将 Bug 修复结束了），有待测试人员的回归测试验证。
- Rejected：如果认为不是 Bug，则拒绝修改。
- Delay：如果认为暂时不需要修改或暂时不能修改（优先级低），则延后修改。
- Closed：修改状态的 Bug 经测试人员的回归测试验证通过，确认 Bug 已修复，则关闭 Bug。
- Reopen：如果经验证 Bug 仍然存在，则需要重新打开 Bug（打回），开发人员重新修改。
最后bug处理的更详细的部分，推荐看博客：https://elena.blog.csdn.net/article/details/138033547
