目录
一、软件测试的生命周期(5个步骤)
①需求分析(两个角度)
用户角度：
开发人员的角度：
②测试计划
③测试设计、测试开发
④执行测试
⑤测试评估
二、软件测试贯穿项目的整个生命周期的体现
需求分析阶段
计划阶段
设计阶段
编码阶段
测试阶段
运行维护阶段
三、关于bug
如何描述一个bug(5个内容)
标题
发现bug的版本
发现bug的环境
发现bug的具体步骤
期望结果&实际结果
bug的级别是什么
NO.1崩溃(非常严重，并且比较少见)
NO.2严重(主要的功能与预期存在严重不符)
NO.3一般(很常见)
NO.4次要(很常见)
bug的生命周期
发现bug
收到bug
修复bug
bug回归验证
如果测试人员认为是bug，开发人员不认为是Bug，怎么处理
一、反思自己
二、提bug一定要有理有据
三、合理友好地沟通
四、提出问题，最好可以提出解决方法(优秀)
五、提出评审(一定是最后的最后才作出这样的决定)
一、软件测试的生命周期(5个步骤)
①需求分析(两个角度)
需求分析需要站在两个角度进行分析：
用户角度：
检查需求的逻辑是否正确，是否符合用户的需求和习惯等；
开发人员的角度：
思考需求是否可以实现/实现的难度大小。
②测试计划
针对一个项目具体的测试计划（例如测试的工时、人力的安排等等）
③测试设计、测试开发
测试设计阶段：设计测试用例。
测试用例就是测试人员向待测试的软件提供的一组测试数据，包括以下的内容：
测试环境、
测试数据、
测试步骤、
预期结果
每一个步骤是干什么的，已经在这一篇文章当中提到了。 【测试开发篇2】软件测试常用概念_革凡成圣211的博客-CSDN博客
https://blog.csdn.net/weixin_56738054/article/details/129493584?spm=1001.2014.3001.5502
在这两个阶段，经验丰富的白盒测试人员就可以开始进行单元测试了（关于什么是白盒测试、什么是黑盒测试，已经在这一篇文章当中提到了）
④执行测试
参考测试用例来执行测试。计划好了测试的计划，那么在这一个步骤就需要来具体地执行测试了。
⑤测试评估
测试人员需要记录测试、做好缺陷管理（例如记录bug、评估风险）
二、软件测试贯穿项目的整个生命周期的体现
之前我们提到了，软件测试是贯穿整个软件的生命周期的。那么，下面我们来回顾一下软件的生命周期是什么。
需求阶段：产品经历根据用户需求转化为软件需求；
计划阶段：进行软件开发的计划，包括项目的开发工时、人力等，产出计划文档；
设计阶段：设计具体的开发步骤；产出设计文档；
编码阶段：开发人员根据需求文档和设计文档来进行软件开发；
测试阶段：测试人员对于软件进行测试；
运行维护阶段：发现项目当中旧的问题、对于当前项目的维护、以及预防可能发生的问题。
下面，我们具体来聊一下，在每一个阶段，软件测试人员需要做什么事情。
需求分析阶段
在这个阶段，测试人员也需要了解用户的需求、软件的需求等等。分析需求是否合理，站在开发人员的角度思考技术如何实现，针对技术难度来合理调整需求。
计划阶段
在测试人员了解到具体的需求之后，就需要进入到计划阶段了。根据需求来编写测试计划、测试方案。
设计阶段
根据项目的设计细节，搭建测试框架，并且根据项目的计划编写一部分的测试用例。
编码阶段
测试人员一般不需要编码的。
在这个阶段，白盒测试人员就可以参与进来进行测试了。同时，在这个阶段也需要完善、细化测试用例以及调整测试计划和方案
测试阶段
测试人员根据测试用例来进行测试，在执行的过程当中记录并且管理缺陷。
并且还需要在这一个阶段进行
总结：
运行维护阶段
在这一个阶段：
①测试人员可以参与用户使用软件的培训；
②收集运行时候项目的问题并且反馈给相关的负责人。
三、关于bug
关于什么是bug,也已经在前面的文章当中提到了：
当软件需求正确的时候，软件的实际运行效果和软件需求不一致的时候，那么这就是bug。
如何描述一个bug(5个内容)
标题
对于一个bug的简单描述：一般是bug的现象是什么。
发现bug的版本
对于用户使用的版本，我们称之为"线上包"或者"正式包"。
那么测试使用的版本就是"测试包"。因此，需要描述好是哪一个测试的版本发现的bug。
发现bug的环境
例如是在什么操作系统下面发现的bug，是移动端还是微信端还是pc端等等。
发现bug的具体步骤
指的是测试人员具体操作了哪些步骤，才发现了bug。
例如是：
用户登录之后，退出到首页的情况发现了bug
还是打开浏览器，进入首页的情况发现了bug
期望结果&实际结果
例如：期望的结果是什么，但是实际的结果又是什么，以及具体的描述。
bug类型：前端问题,bug等级...
(最好配有截图)
bug的级别是什么
关于bug的级别，不同的公司有不同的规定，在定义级别之前首先需要查看公司的规范。一般分为以下几个级别：
NO.1崩溃(非常严重，并且比较少见)
这种bug，可以说是会直接导致系统崩溃的。例如：
死循环、死机、数据库内容丢失等等，在测试的环节非常少遇见
NO.2严重(主要的功能与预期存在严重不符)
例如在一个博客系统当中，用户点击了保存草稿，但是还是没办法保存成功一样。
或者用户点击了登录，账号密码都输入正确了，但是还是没办法正常登录。
NO.3一般(很常见)
功能没有完全实现，但是不影响使用。
主要功能存在缺陷，但是不影响系统的稳定性。
NO.4次要(很常见)
一些建议优化的措施。(例如调整前端页面的字段大小等等)
bug的生命周期
发现bug
测试人员发现了新的Bug，同时测试人员要新建一个bug，这个bug的状态就是new。
收到bug
开发人员收到了bug，查看测试人员提出的bug是否是bug。如果是bug，就把这个bug的状态设置为open。
如果开发人员认为这不是一个bug，那么开发人员就把这个bug修改为rejected(拒绝)，然后就直接进入closed状态。
修复bug
开发人员认定了bug之后，就需要采取修复的工作。
但是，就算是修复，也有两种措施：
delay：现在暂时不需要修复，于是采取的措施是：延迟修复。
fixed：立刻进行bug修复。
bug回归验证
把这一个bug的状态修改为reopen，重新交给开发人员。
画个图总结一下bug的生命周期流程图(圆圈为bug的状态)：
如果测试人员认为是bug，开发人员不认为是Bug，怎么处理
一、反思自己
具备批判性的思维，先考虑一下：自己是不是对于bug描述地不清楚。
这个bug是不是无效的bug
二、提bug一定要有理有据
不单止对于bug的描述，还需要有明确的依据（包括是在什么样的环境下面发现的bug，测试的版本、运行的截图等等）
并且要严格规定bug的等级，不可以过低或者过高。
三、合理友好地沟通
如果开发人员并不太认可，可以站在用户的角度进行沟通。如果你是用户，那么可以接收这样处理嘛？
四、提出问题，最好可以提出解决方法(优秀)
如果bug太多的话，最好可以提出解决方案，帮助开发人员快速进行修正。
五、提出评审(一定是最后的最后才作出这样的决定)
邀请产品代表、开发代表、测试代表一起对这个bug进行评估。
包括以下的内容：
(1)如何解决bug；
(2)如何预防类似的bug。
