目录
一软件测试的生命周期
软件测试贯穿软件的整个生命周期：对于测试人员来说，不仅要具备开发能力，测试能力，还要有一定的产品分析能力来保证产品的质量；
软件测试的生命周期指按照一个系统的流程去执行，确保软件的质量符合需求；以下是具体内容
| 需求分析 | 测试计划 | 测试设计与开发 | 测试执行 | 测试评估 | 上线 | 运行维护 |
|---|---|---|---|---|---|---|
| 从用户角度：需求是否合理； 从开发角度：技术上是否可行，是否有优化空间； 从测试角度：需求是否符合逻辑 | 测试的时间要计划多久 | 参考需求文档，技术文档编写测试用例； 编写测试文档要明确标注使用到的测试方法，测试手段，测试工具等 | 利用测试用例与测试工具对软件进行全方位的覆盖测试 | 测试是否通过？测试是否有遗留的BUG?测试人员要结合测试实际编写一份测试报告 | 上线分为四步骤：沙盒，小流量，全流量，全线上 | 测试人员参与项目的实施工作，收集用户问题反馈给相关负责人 |
所以说：测试执行完成后不能就说软件100%的问题被解决了，有些问题可能很难被发现，需要用户体验一段时间后才暴露出来；
项目测试完成后要把它推送上线，可不是像我们一样就直接push代码到远程机器上就好了：因为一个项目可能是有多个团队共同开发完成的，一同推上面可能会有冲突；再加上线下环境与线上环境的不同，可能线下环境没问题，一上线就会出现各种报错，所以上线分为四步：
- 沙盒：企业内部的内部的线上环境供测试人员测试；
- 小流量：先让一小部分用户进行体验，测试人员除了要线上测试外，还要看是否有错误日志；
- 全流量：全部用户都能使用到；
- 全线上：项目正式推送上线；
二BUG
1概念
- 当且仅当规格说明（需求）是存在并且正确时，程序与规格说明不匹配时就是Bug；
- 当规格说明没有提到的功能，判断以用户为准：程序没有实现用户合理预期的功能也是Bug；
一切以需求出发：来验证产品的特性是否返回用户的需求！
2描述Bug
当出现了Bug后，测试人员也要能很好地描述清楚：
- 问题出现的版本；
- 问题出现的环境；
- 问题出现的步骤；
- 预期结果；
- 实际结果
案例 ：101智慧课堂-您身边的智慧课堂
之前（现在修复了）登录以上网站的登录页面时：在ie浏览器上正常，在谷歌浏览器上发现登录旁的二维码被遮挡了，此时如果你是测试人员要怎么跟开发人员描述Bug呢？
直接说：在浏览器上出现页面遮挡二维码的Bug，要马上进行修复！
开发人员此时就登上浏览器后发现没有测试人员描述的情况：你是不是想找茬？
所以此时描述Bug时，我们可以应该这样来描述：
- 问题出现的版本：⾕歌浏览器：123.0.6312.123（正式版本）（64位）
- 问题出现的环境：Windows 家庭版
- 问题出现的步骤：1.在搜索框上输入网站；2.等待网站页面渲染完成；
- 预期结果：二维码没有被遮挡，可以使用微信扫一扫二维码进行登录'
- 设计结果：二维码被登录页面遮挡，扫描二维码失败！'
尽可能详细清楚去在线Bug出现的场景，给开发人员去复现Bug后进行能及时进行修复
3Bug级别
通过定义Bug级别来看出Bug的严重程度，根据Bug优先级的顺序俩处理Bug；除此之外，Bug级别也决定着你的年终奖的高低：写出几个严重的Bug可能就要就要跟你的奖金说再见了~
- Bug级别一般分为：次要，一般，严重，崩溃；（但并不绝对，具体看公司的Bug描述文档）
| 次要 | 一般 | 严重 | 崩溃 |
|---|---|---|---|
| 界面，性能缺陷，建议类问题：如：百度页面的百度一下变成了百度两下；优先度较低 | 功能没有完全实现但不影响用户正常使用；菜单功能存在缺陷但不影响系统稳定性；如：百度页面的百度一下按钮点击没反应，但可以通过回车键进行搜索；优先级低 | 系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，一级菜单不能使用但不影响其它功能测试；一般出现较少 | 严重阻碍开发与测试的工作，造成系统崩溃，死机，死循环，导致数据库数据丢失；出现极少 |
4Bug的生命周期
当测试人员发现Bug时，要提交到对应的Bug管理平台，对Bug进行持续追踪与测试，确保Bug能被顺利解决掉：这就是一个Bug的生命周期
三与开发人员发生争执怎么办
因为年终奖的利益关系，测试人员与开发人员通常会在Bug问题上发生争执：开发人员认为这不应该是一个Bug；Bug的级别太高了；你是不是故意找一个无效的Bug来增加自己的奖金...面对各种可能的出现情况，测试人员怎么就决定了争执的走向~
1先自省：是否Bug描述不清晰
- 反省是否对Bug描述不清楚或者是自己误操作；
- 如果发现是自己的原因，在Bug提交后主动去找开发人员解释，而不是等开发人员来找自己
2站在用户角度考虑并抛出问题
- 功能正常只是测试的一部分，还要考虑用户体验感受；
- 如果开发人员不认同，我们可以反问他：如果你是用户，你也接收这样的体验吗？？
3Bug定级有理有据
- Bug定级不仅要参考Bug文档，也要站在用户角度上；
- 开发人员不认可Bug定级时：拿出Bug描述文档与Bug表现进行匹配；
4不仅要提出问题，还要给出解决方案
- 在你的技术能力范围内：可以给开发人员一个解决方案，但不能是以命令的口吻去要求
如果以上措施还得不到解决，接下来就要进行Bug评审
5Bug评审
5.1解决的问题
- 如何处理Bug；
- 分析Bug产生的原因，找出预防对策（不能犯同样的错误）
5.2三种角色
- 测试代表：从Bug的具体表现，严重程度上提供信息，并给出意见；
- 开发代表：从修改缺陷的难度和⻛险等角度分析，给出初步方案；
- 产品代表：从产品计划时间，用户要求等方面，给出意见；
以上便是全部内容，有问题欢迎在评论区指正，感谢观看！