如何描述一个bug?

作为一名测试人员，提bug是最基础的工作，那我们如何才能把bug提的清晰易懂呢?

发现问题的版本开发人员获取对应版本的代码来重现故障。版本标识也能统计和分析版本的质量

问题出现的环境环境分为硬件环境和软件环境，web项目 (描述浏览器版本) 、app项目 (描述app版本) ，详细的环境描述有利于故障的定位

错误重现的步骤描述问题重现的最短步骤

预期结果以用户的角度来描述程序正确预期。依据需求提出的故障，最好写出需求的来源

错误结果描述错误的现象。crash等可以上传log，UI问题可以有截图

其他某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等

不要把多个bug放到一起在无法确认是同一段代码造成的故障时，不要将bug放在一起提交

bug的等级

不同公司的bug等级定义可能不一样，但基本都是下面四类

Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

Critical （严重）：

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

Major （一般）：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(实际测试中存在最多）

Minor （次要）：

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

bug的生命周期

New :测试创建一个bug。

Open ：开发确认是不是bug，是的话就状态改为open。

Fixed :开发进行修改后修改状态为Fixed，有待测试人员的回归测试验证。

Rejected ：如果认为不是Bug，则拒绝修改。

Delay :如果认为暂时不需要修改或暂时不能修改，则延后修改。

Closed ：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。

Reopen ：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

无效的bug：open->closed open-rejected-closed

基本的流程图：

测试的执行：

执行测试时处理要做到测试用例和需求的覆盖外，还要有临时发挥的能力。根据自己的经验、对测试的
感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷。
不能拘泥于测试用例或者已经有的测试方法，在测试执行过程中要不断总结测试方法和测试故障模型。
真正优秀的测试人员在执行测试时是想着做，做着想，这样的测试效果才好，尤其是在测试过程中，对
程序的处理相当了解的情况下，测试的思路会更加清晰和全面。

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