测试BUG篇

一，软件测试的生命周期

首先说一句最重要的：软件测试是贯穿于软件的整个生命周期的

软件测试的生命周期流程为：

每个的内容为：

1.需求分析：用户想着软件是否合理，技术想着技术上面是否可以开发，还能不能优化，测试想着是否有逻辑错误，冗余，冲突的问题。

2.测试计划：也就是什么时候开发测试，什么时候结束测试，要耗时间多久。

3.测试设计与开发：写测试文档，明确需要用到的测试方法，测试工具，测试形式等。

4.测试执行：充分利用测试工具和用例对项目进行尽可能的全方位测试

5.测试评估：测试人员对本次测试的是否有BUG，要做出一个最终的测试报告。

6.上线：测试结束后，对软件在线上线下的运行是否正确一致。

7.运行维护：也就是对用户使用软件做一个培训，然后再试运行的时候收集问题反馈给相关人员。

二，BUG

2.1BUG是什么

也就是存在了一个错误或者疏忽使程序无法正确的运行，这就是BUG，还有就是如果最终实现的项目与用户合理预期功能不一致的时候，就是BUG。

2.2对BUG的描述

对BUG的描述有一个要素要求，也就是要明确这个BUG出现的所有东西。

基本要素为：问题出现的版本，环境，步骤，预期结果，实际结果。

就比如：

问题出现的版本：谷歌浏览器版本126.0.6478.115（正式版本） （32 位）

问题出现的环境：Windows家庭版

问题出现的步骤：打开网站，等待渲染完成

预期结果：什么什么该出现什么

实际结果：什么什么和预期结果完全反着。

2.3BUG级别

分为四点：崩溃，严重，一般，次要

崩溃：代码错误，死循环，数据库发生死锁，一些大功能不能使用，直接运行导致死机等。

严重：系统主要功能部分丧失，用户数据丢失，功能与需求严重不符合，稳定性和安全问题。

一般：功能没有完全实现但不影响使用，或者进入网页时间等待特别长，边界条件错误。

次要：有些性能缺失但不影响使用，有错别字什么的之类。

在开发中主要就是后两种。

2.4BUG的生命周期

new：新发现BUG了，要经过评审决定是否给开发进行修改。

open：确认是BUG，认定要修改，然后分配给指定的开发人员。

Fixed：修改之后将标识修改成修改状态，等待测试人员做回归测试。

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

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

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

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