1. 软件测试的生命周期

需求分析——测试计划——测试设计/开发——测试执行——测试报告

1.1 需求分析

分析需求，验证需求合理性，正确性。细化需求，根据需求去提炼测试点

确定测试范围、目标、测试人员、测试工具、时间、测试环境

开发测试用例

开发人员以及提交代码执行测试，提交BUG

本次迭代的测试情况进行分析和总结，写了多少测试用例执行了多少，发现了多少BUG，修改了多少
剩余BUG的解决方案，测试的覆盖率。

（1）测试版本（代码提交的版本号）
在这里插入图片描述
（2）测试环境
因为在不同测试环境出现的问题不一样

（3）测试步骤
测试数据和执行测试的详细步骤——>为了方便开发人员复现问题。
（4）实际结果
（5）预期结果——>需求期望的结果
（6）BUG产生时的log日志，错误截图等附件

（1）崩溃
系统崩溃，不能运行，死循环，数据库死锁，资源分配不均，黑屏，闪退，阻塞。
线上（用户使用的环境）出现崩溃级别的BUG：回到上一个可用稳定的历史版本

（2）严重
服务器可以用，但是不稳定，继续使用会产生严重的错误；一级菜单错误，数据库插入用户数据错误，威胁到用户的安全等。

扫描二维码关注公众号，回复： 13925197 查看本文章

（3）一般
系统可以稳定的运行，次要的功能没有实现，提示语不完善，弹出框没有关闭按钮，不影响用户的使用

（4）建议（次要）
建议性的，提示信息重叠（看不清楚），界面排版不符合用户使用习惯，颜色不符合软件使用场景。

一个BUG 从无到有的各种状态
在这里插入图片描述
如果要丢弃BUG的话，应找产品经理确认，不能影响最终项目的上线。

测试环境不一样
开发人员理解不到位，没有修改成功
开发人员修改后，没有提交代码到远程，测试人员用的旧的（有问题的代码）进行测试。

（1）检查自己的BUG描述，是否描述清楚
（2）可以从用户角度考虑，说服开发人员
（3）BUG定级要有理有据，符合公司的规范
（4）测试人员要不断提升自身的专业技能和业务水平
（5）找产品经理去讨论问题的解决方案