二、BUG的描述

开发人员需要获取对应版本的代码来重现BUG，版本的标识有利于统计和分析每一个版本的质量

Web系统：

硬件设备（电脑品牌，型号）

软件设备（操作系统，浏览器即版本号）

APP：

硬件设备（手机品牌，分辨率）

软件设备（操作系统及版本号）

描述问题重现的最短步骤

以用户的角度描述程序应有的行为是怎样的，可以的话写明需求的来源

三、BUG的级别

以下对BUG级别的描述只是典型情况，实际中的BUG级别的划分需看公司的定义

崩溃

严重阻碍到测试人员的工作，系统无法正常运行，出现崩溃，操作死锁，死循环，黑屏，导致数据库数据丢失，数据库连接错误等（遇到这类情况应立即中止当前版本的测试）

严重

系统能运行，但是不稳定，继续运行下去会造成严重损失，重要的功能没有实现，或者与需求不符合，数据库中的用户数据存储出现了错误，威胁用户的安全

一般

系统可以稳定运行，次要的功能没有实现，或者与需求不符合，比如加载时间过长，格式错误，数据库表中字段过多等

建议

影响用户的体验，界面格式不规范，排版不符合大众审美，描述不清晰，提示语丢失，文字排列不整齐等优先级较低的BUG

四、BUG的生命周期

五、当因为 BUG 和开发人员产生冲突时

检查自身，看对BUG的描述是否清楚

一个描述清晰的BUG信息，使得解决问题的效率大大提高。当BUG的信息无法书面描述清晰时，应当主动找到开发人员进行沟通

从用户的角度去说服开发人员修改

一个项目最后面向的对象的是用户，引导开发人员站在用户的角度思考问题，可以促进开发人员修改BUG

BUG的定级要严格按照公司的规范

不断提升自己的业务技术水平

不仅能发现BUG，还能够对BUG进行定位，甚至提出解决方案，建立权 威，有较高的可信度

拒绝大声争吵，拒绝扯头花

进行三方会议，测试人员、开发人员、产品经理一起讨论BUG的解决方案

六、菜鸟如何开始自己的第一次测试

进行第一次的测试前需要做好充分的准备

拿到一个项目，我们需要阅读所有项目相关的文档，需求文档，设计文档，用户手册。这些是之后写测试用例，进行测试的根本依据所在

多多参加项目相关会议，了解项目的背景，人员组成，进一步了解项目需求和业务，针对专业性较强的项目，要了解各种相关知识

熟悉项目使用的测试管理工具，配置管理工具

阅读已有的测试方案，测试用例以及BUG，和团队保持一致的故障定级原则

编写代码前还需要了解公司的规范要求，比如用例编写的规范，用例执行的规范，BUG 提交的规范，测试工具使用的规范等

在真正进行测试前，还需要向自己的小领导确认具体的工作内容：

测试的计划

测试的内容

任务限制几天完成

我要测试的内容的开发人员、需求人员

测试的内容是否需要其他特殊的测试资源

至此，就可以开始执行测试任务