1.什么是bug？
- 漏洞缺陷+改进建议+不符合需求
不符合要求：实现的方法与需求文档不一样
2.Bug的等级
2.1 致命错误
- 常规操作引起的系统崩溃、死机、死循环、闪退
- 造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
- 涉及金钱计算
- 阻断性测试，所有测试工作进行不下去（冒烟测试）—正确的密码登录不进去，并且核心功能需要登录
2.2 严重错误：critical
1、重要功能不能实现；
2、错误的波及面广，影响到其它重要功能正常实现；
3、非常规操作导致的程序崩溃、死机、死循环、闪退
4、外观(界面)难以接受的缺陷；
5、密码明文显示；(界面+数据库)
6、偶现的致命性bug
复现率：出现次数/测试次数
2.3 一般错误 major最多
不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
1、次要功能不能正常实现；
2、操作界面错误（包括数据窗口内列名定义、含义不一致）；
3、查询错误，数据错误显示；
4、简单的输入限制未放在前端进行控制；
5、删除操作未给出提示；
6、偶现的严重性bug
2.4 细微错误 minro
- 界面方面的问题：描述性错误、错别字
2.5 改进建议
3.bug的描述
3.1 基本信息
- Bug 编号：为每个 Bug 分配唯一标识符，方便跟踪和管理。如 JIRA 系统自动生成的编号。
- 所属项目与版本：明确 Bug 出现的项目名称及具体版本号，便于确定问题范围。
- 发现日期与报告人：记录发现 Bug 的时间和报告人，有助于后续沟通和追溯。
3.2 重现步骤
- 环境信息：包括操作系统、浏览器及其版本、设备型号等。例如“Windows 10 系统，Chrome 浏览器版本 115.0.5790.102”。
- 详细步骤：按操作顺序准确描述，每一步都要清晰、简洁且可操作。比如“1. 打开登录页面；2. 输入用户名 'testuser'；3. 输入密码 '123456'；4. 点击登录按钮”。
- 前置条件：说明执行重现步骤前系统应满足的条件。如“用户已注册并处于激活状态”。
3.3 实际结果与预期结果
- 实际结果：描述执行重现步骤后系统实际呈现的状态或行为。如“点击登录按钮后，页面无响应”。
- 预期结果：说明按照正常逻辑，执行操作后期望系统出现的结果。如“点击登录按钮后，成功登录并跳转到用户主页”。
3.4 Bug 严重程度与优先级
- 严重程度：反映 Bug 对软件功能、性能等方面的影响程度。常见分类有：
- 致命
- 严重
- 一般
- 轻微
- 优先级：表示修复 Bug 的紧急程度，通常根据严重程度和业务需求确定。如高优先级的 Bug 需立即修复，低优先级的可在后续版本处理。
附件
- 截图：直观展示 Bug 发生时的界面情况，帮助开发人员快速理解问题。
- 日志文件：包含系统运行时的详细信息，有助于开发人员分析问题根源。
- 视频：对于一些难以用文字描述的操作过程或动态问题，可通过录制视频提供更清晰的展示。
其他补充信息
- 复现频率：说明 Bug 出现的概率，如“每次都出现”“偶尔出现（约 10% 概率）”等。
- 可能原因：根据测试人员的经验和对系统的了解，推测 Bug 产生的可能原因，但需注明是猜测，最终以开发人员排查结果为准。
4.Bug周期
Bug 周期指从发现到最终解决所经历的流程，一般包含以下阶段：
- 发现阶段：测试人员、用户或开发人员在软件使用过程中发现与预期不符的情况，记录 Bug 详细信息，如出现环境、操作步骤、预期结果和实际结果等。
- 报告阶段：测试人员整理 Bug 信息，通过缺陷管理工具（如 JIRA、禅道）提交报告，详细描述问题并分配给对应开发人员。
- 确认阶段：开发人员接收 Bug 报告后，对 Bug 进行初步分析，判断是否为有效 Bug。若无效则关闭；若有效则评估影响范围和修复优先级。
- 修复阶段：开发人员针对有效 Bug 编写代码进行修复，完成后在开发环境进行自测，确保问题解决且未引入新问题。
- 验证阶段：测试人员对开发人员声称已修复的 Bug 进行验证。若验证通过，则关闭该 Bug；若未通过，重新将 Bug 打回给开发人员。
- 关闭阶段：经测试人员验证通过的 Bug 会被正式关闭，意味着该问题在当前版本中得到解决。
不同项目、团队和软件类型，Bug 周期会有差异。小型项目可能几天完成一个 Bug 周期，大型复杂项目则可能需数周甚至数月。
