测试：BUG篇
软件测试生命周期
-
需求分析
用户角度:软件需求是否合理
技术角度:技术上是否可行，是否还有优化空间
测试角度:是否存在业务逻辑错误、冗余、冲突等问题 -
测试计划
制定测试计划:什么时候开始测试，什么时候结束测试，耗时多久 -
测试设计与开发
参考需求文档、技术文档等编写测试用例
写测试文档，明确标注使用到的测试方法，测试工具，测试形式等 -
测试执行
充分利用测试用例和测试工具对项目尽可能做到全方面的测试覆盖 -
测试评估
测试是否通过，本次测试是否有遗留的BUG,最终测试人员需要产出一个评估报告 -
上线
项目测试结束后，将项目发布到线上环境，测试人员需求跟踪上线并测试线上环境下软件的运行是否正确 -
运行维护
测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人
补充：上线过程
上线分为：沙盒、小流量、全流量、全线上
从内部人员测试->部分真是用户体验，测试人员手动测试->所有用户使用->上线
bug
- 当规格说明存在且正确时，程序与规格说明之间是不匹配的时候，是错误
- 无说明时，以最终用户的语气需求为判断标准
bug的描述
bug的描述应该包含以下内容
- 问题出现的版本
- 问题出现的环境
- 问题出现的步骤
- 预期结果
- 实际结果
bug级别
- 崩溃
阻碍开发或测试工作的问题;
造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现，一旦出现应立即中止当前版本测试) - 严重
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他 功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用 冲突，安全问题、稳定性等。如:软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试 - 一般
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多) - 次要
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如:错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等(此类问题在测试初期较多，优先程度较低;在测 试后期出现较少，应及时处理)
手册中有更详细的区分
与开发的沟通
检查自身是否bug描述不清楚
会不会是误操作了，会不会是bug没有描述清楚
在用户角度提出问题
“如果你是用户你可以接受这样的页面/功能吗”
合理给bug定级
根据定级描述文档来匹配
提升自身水平
bug评审
都不行就bug评审（测试、开发、产品代表）
主要解决：
- 如何处理bug
- 找出原因，以后如何预防