1.软件测试的生命周期（软件测试的流程？）
需求分析—>计划阶段（范围，时间，人员，工具）—>测试设计/开发（测试用例）—>测试执行(执行测试用例，补充测试用例)—>测试评估（覆盖范围，测试了哪些功能，没测哪些功能，BUG情况统计）
2.如何描述一个BUG
（1）测试版本：当前测试的系统所在的代码版本
（2）测试环境：系统所在的环境
- web系统 浏览器：Chrome IE edge；浏览器的版本号
- APP iOS Android；系统的版本号；机型
（3）测试步骤：引起BUG的操作步骤
（4）测试数据：引起BUG的输入信息或数据
（5）测试实际结果：预期结果对比
（6）其他，错误截图，错误日志等附件
3.BUG的级别
崩溃：系统已经没法运行，黑屏或死机
可能代码中有死循环，数据库中有死锁，重要的一级菜单没有办法使用
严重：系统还可以使用，但不稳定，如果继续运行会产生严重后果
画面失真，密码或隐私明文显示
一般：系统可以稳定运行，但是有些功能没有实现，或实现有问题，不影响用户使用
无法查询，查询没排序，
次要：建议性的BUG，界面问题
字写错了，图片排版问题
问题：
如果线上出现崩溃你会怎么做？
回退到之前稳定的版本，利用git命令，然后维护
4.BUG的生命周期
- 测试人员发现BUG，新建一个BUG，new
- 开发人员确认是不是BUG，open
- rejected（丢弃）/delay（延期）
- fixed（修改）
- 测试人员检查，验证
- 验证通过，修改BUG结束，closed（关闭）
- 验证不通过，reopen（重新打开，给开发人员确定，重复上述过程）
5.如果测试人员因为BUG和开发人员产生争执怎么办
重要：千万不要争吵，保存镇定
- 检查一下，看BUG描述是否清楚，是不是让对方没有理解
- 站在用户的角度说服开发人员，谁开发的这么不好用，还折磨人
- BUG的定级要合理，按照公司的测试BUG定级规范
- 要让开发人员愿意和我合作，要不断提高自己的业务水平和技术水平，找到BUG，提出原因，找到解决方案
- 和产品经理，开发人员，测试人员，“三方会议”，讨论BUG的严重程度，影响程度，以及最终解决方案
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
