前言👀~
上一章我们介绍了什么是软件测试，今天我们讲解测试的一些基础概念
软件测试的生命周期
如何描述一个bug
如何定义bug的级别
bug的生命周期（重要）
和开发产生争执怎么办？
如何开始第一次测试？
如何发现更多的bug？
如果各位对文章的内容感兴趣的话，请点点小赞，关注一手不迷路，讲解的内容我会搭配我的理解用我自己的话去解释如果有什么问题的话，欢迎各位评论纠正 🤞🤞🤞
个人主页：N_0050-CSDN博客
相关专栏：java SE_N_0050的博客-CSDN博客 java数据结构_N_0050的博客-CSDN博客 java EE_N_0050的博客-CSDN博客
软件测试的生命周期
软件测试的生命周期： 需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
1.需求分析就是站在用户的角度看需求是否完整是否正确，站在开发的角度看需求是否能实现或者实现难度大小
2.测试计划就是制定测试计划（确定谁来测试什么时候开始测试什么时候结束测试测试哪些模块）
3.测试设计、测试开发就是写测试用例（手工测试用例、自动化测试用例）、编写测试工具，测试执行就是执行测试用例，测试评估就是测试人员写一个测试报告包含测试的评估等信息
测试报告内容：测试人员、测试时间（开始时间到结束时间）、开发人员、开发时间、测试用例、bug（bug类型、发现问题的版本、发现问题的环境、发现问题的步骤）、文档（需求文档、技术文档）等
如何描述一个bug
一个合格的bug描述应该包含以下部分：
1.发现bug的版本：测试出bug要记录当前出现bug的版本，方便开发人员对照版本进行修复
3、发现bug的步骤：描述问题重现的步骤
4、预期结果：就是预期的效果应该是怎么样的我们要描述出来
5、实际结果：描述出现错误的现象
6、故障优先级：例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高，这这些说的就是bug类型、bug等级
7、不要把多个bug放到一起：在无法确认是同一段代码造成的故障时，不要将bug放在一起提交
如何定义bug的级别
不同公司对bug的定级以及标准不一样。根据bug的影响程度来决定的，影响严重的我们需要优先修复，影响小的可以留到后续版本进行修复
1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题
2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符。（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试），就是主要功能模块出现问题
3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多），例如一个外卖软件商家显示半天影响用户体验
4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理），就是一些细节点
注意：如果发现崩溃级别的bug，立即停止测试，测试写一个测试报告交给领导然后打回，然后给开发进行修复，修复后再仔细测试
bug的生命周期（重要）
New：发现Bug，未经评审决定是否指派给开发人员进行修改
Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员
Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证
Rejected：如果认为不是Bug，则拒绝修改
Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改
Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改
无效的bug：open->closed open-rejected-closed
总结：一个bug的生命周期就是测试人员发现一个问题此时bug就是new状态，然后把bug告诉开发人员，开发人员进行确认如果确认是则进入open状态不是的话开发人员将把状态改为rejected或者是bug但是延后修改则进入delay状态，进入open状态后开发人员进行修复后进行fixed状态，然后我们测试人员再进行测试如果没问题就进入closed状态，如果还是有问题就是reopen再次回到开发人员那里接着修改重复刚才的操作
和开发产生争执怎么办？
1.首先确保自己对需求理解没有问题，反思自己是不是bug描述的不清楚是
2.bug等级一定要有理有据
3，友好的沟通，站在用户的角度进行反问：如果你是用户你能接收吗
4.不仅能发现问题，最好能给出解决方案
5.组织bug评审（评审需要项目组各个方面的代表参加），开会前要明确问题产生原因如何解决，开会之后要明确问题要不要解决，什么时候解决谁去解决
如何开始第一次测试？
1.充分理解需求
通过文档（产品文档+技术文档）或尽可能参加各种项目会议，阅读旧有的bug库，了解系统功能，尤其重要的是和现有的测试团队保持一致的故障定级原则
2.确定测试计划
谁去测试？什么时候开始测试？测试内容是什么？
3.执行测试
打开测试管理工具用例模块，开始执行用例，发现bug！进行复现并确认bug的复现步骤、记录bug、沟通bug、验证以前提交的bug。确认本次测试完成，编写测试报告
4.项目上线+维护
如何发现更多的bug？
1、软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度！
2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度！
3、多进行逆向思维和发散性的思维（多编写测试用例多看测试用例积累测试经验）
4、不要局限于用例和需求文档
5、尽早介入项目, 不要等到开发的差不多了再介入项目（尽早介入需求理解需求）
以上便是本章内容比较基础都是一些测试的概念，下一章我们讲解如何设计一个测试用例💕
