bug详述

1.bug的概念：

当且仅当规格说明书（软件需求说明书）存在并且正确，程序和规格说明书之间不符合，称之为错误
当用户的需求存在并且合理，程序没有满足用户的需求，称之为BUG

2.如何描述一个BUG

2.1描述BUG的要素：
测试版本，测试环境，操作步骤，预期结果，实际结果

2.2BUG级别：
崩溃：系统无法正常运行，阻断

严重：系统可以运行，但是不稳点，如果可以继续运行，会发生严重的后果。表现：数据泄露，直播画面失真，密码明文显示

一般：系统可以稳定运行，但是缺少部分功能，影响用户体验。表现：微信聊天记录无法删除，数据库查询错误

次要：系统稳定运行，属于建议性的BUG

3.BUG的生命周期（从BUG创建到BUG关闭，bug所经历的一些状态）：

New:新建
open：确认
fixed：已解决
reopen：重新打开
closed：关闭
reject：丢弃
delay；延期

4.如果因为一个BUG和开发人员产生冲突，测试人员如何恰当处理？

1.先检查自身，描述BUG是否清楚
2.站在用户的角度去说服开发人员
3.BUG定级要有理有据
4.作为测试人员，不断提升自己的技能水平
5.评审BUG

5.如何开始第一次测试

作为一个菜鸟在进入测试团队开始第一次测试的时候，我们需要做很多的准备：
1、阅读所有项目有关的文档，包括：需求文档、设计文档、用户手册
2、尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务专业性较强
的项目，例如银行业务，需要了解各种业务知识，如高低柜、一二三类账户等、存款、贷款等。
3、熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式
4、阅读已有的测试方案和测试案例
5、阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则
6、了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规范等
在进行了以上的准备工作之后，第一次测试工作到来了，我们需要与测试组长确认具体的工作内容：
1、测试的计划是什么？
2、测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？
3、我要测试的内容开发人员是谁？需求人员是谁？
4、分配给我的测试内容是否需要特殊的测试资源？资源是否满足需要？
在我们确认了以上内容之后，就可以开始测试的执行了

6.测试的执行和BUG管理

现在我们开始进行测试了：

1. 打开待测试的系统
2. 打开测试管理工具用例模块，开始执行用例
3. 发现bug！进行复现并确认bug的复现步骤
4. 记录bug
5. 沟通bug
6. 验证以前提交的bug
7. 确认本次测试完成
8. 编写测试报告
   执行测试时处理要做到测试用例和需求的覆盖外，还要有临时发挥的能力。根据自己的经验、对测试的感悟以及随
   机测试可以发现很多根据测试用例无法发现的缺陷。
   不能拘泥于测试用例或者已经有的测试方法，在测试执行过程中要不断总结测试方法和测试故障模型。真正优秀的
   测试人员在执行测试时是想着做，做着想，这样的测试效果才好，尤其是在测试过程中，对程序的处理相当了解的
   情况下，测试的思路会更加清晰和全面。