一、软件测试的生命周期
二、缺陷管理
1.如何描述一个缺陷
2.如何定义缺陷的级别
3.缺陷状态及状态转换。
4.缺陷的生命周期
三、如何开始第一次测试
四、如何发现更多的缺陷
五、提交一个缺陷，研发人员不认可，产生争执怎么办
一、软件测试的生命周期（5个）
需求分析—测试计划—测试设计—测试执行—测试评估
二、缺陷管理
1.缺陷描述
要素：环境、数据、步骤、版本、预期结果实际结果、附件、级别
实际结果于预期结果进行对比：如果一致说明功能实现，如果不一致，就生成的缺陷
附件：当缺陷用语言描述不太清楚时可以去服务器里抓取相关日志，可以把这些截个图或者存在文档里，然后给研发人员附到他的缺陷里边，研发人员会打开附件去看就能很清楚的知道是什么原因造成了缺陷（报错日志）
级别（缺陷要分级别）：表示缺陷的严重程度。
优先级：修改缺陷的优先级。
原则上来说缺陷的级别越高，修改的优先级就越高，但是不排除个别的，例如：崩溃的严重的缺陷优先级低，比如你发现一个崩溃的严重的缺陷，它是偶然性的找不到它的规律浮现不出来，而且这个缺陷一周或者半个月才出现一次查不到它的原因，这个时候，他的优先级可能就放低了，因为核心是先要抓住规律找到他能浮现的步骤，而他浮现不了，没法进行修改，找不到如何去浮现这个缺陷，无法进行定位，就不能调试。一定要是能浮现出步骤的才可以，所以说有个别的严重级别高的缺陷，他的优先级不一定是高的（正常情况下是严重级别越高，优先级就越高）
2.缺陷级别：崩溃、严重、一般、次要、建议
建议型的缺陷（非bug）：大部分公司会出一个建议型的缺陷，建议型的缺陷就是这个功能是没有缺陷的，如果按另外一种方法实现就可以这样举例：设计了一个界面，建议把这个界面的颜色调的更漂亮美观这就是一个建议型的缺陷
有些企业会把这5个缺陷级别换成简称：A B C D E或者1 2 3 4 5
3.缺陷的状态及状态转换
缺陷的状态：NEW OPEN FIXED DELAY REJECTED CLOSED REOPEN
缺陷的状态转换图：（⚠️注意：以后画流程图时，标准规范的流程图是以start开始，end结束）
- New:（是测试人员操作）是由测试人员测试的时候发现了一个缺陷后，把它提交到缺陷管理平台，提交完之后他的默认状态就是new
- Open:（测试人员操作）测试人员把相应的缺陷分配给研发人员之后，状态就有new变为open
- 缺陷：（研发人员操作）研发人员要验证，他到底是不是一个缺陷，验证结果是缺陷就修改，不是缺陷就拒绝。
- 研发人员对于缺陷有三种处理方式，以下就是三种处理方式：
- Rejected:（研发人员操作）如果研发人员认为不是Bug，则拒绝修改。
- Delay（延迟）:（研发人员操作）研发人员验证后确定是缺陷。但是这个缺陷影响不大。而且研发人员手头上有重要的工作。没有时间去修改这个缺陷。暂时不影响其它的核心功能。可以放在下一个版本，再去修改。（如果认为暂时不需要修改或暂时不能修改，则延后修改）
- Fixed:（研发人员操作）研发人员验证后发现确实是一个缺陷而且需要修改。这个时候他就会把这个缺陷进行修改。修改完之后，他会把缺陷的状态状态置为Fixed
- 通过：修改完的缺陷，测试人员是不可以直接进行关闭的，需要再进行一下验证。验证修改完的这个缺陷是否可以通过？
- Closed（测试人员）:验证通过的话就置为Closed
- Reopen（测试人员）:如果验证失败了，就需要让测试人员来重新打开这个bug，研发人员重新定位问题，进行修改
- 以下是两个无效的bug:（什么是无效的bug：提交的缺陷分配给研发人员，根据你的步骤，研发人员浮现不了，说明这就是一个无效的缺陷，或者自己提交完缺陷之后，还没有给研发人员分配，自己去验证的时候也浮现不出来了）
- New→open→closed
- New→open→rejected→closed
- 其中reject和delay这两个状态要进行评审：
当提出的缺陷研发人员和测试人员意见不一致时就可以找产品经理、项目经理大家一起来评审（会议或者非会议都可以），并不是每发现一个reject和delay就要评审，一般会在本轮测试结束之前组织一次会议，把所有的缺陷所有的reject和delay缺陷一起过一遍，确定好要不要修改（统一一次性评审）
bug的生命周期：
每个公司、每一个工具（bug管理系统）对bug生命周期的定义都是不一致的，下面仅是一个常见的例子： 测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。
三、如何开展第一次测试（了解内容）
- 学习项目相关的所有文档（测试文档、研发文档用户的使用说明文档全部都要学习）
- 项目中所有的会议要参加（大大小小的会议都要参加，除非不用测试人员参加的会议）
- 获取项目相关的管理、使用的地址（项目的访问地址，、项目的服务器的地址）、用户名、密码（测试用例管理缺陷的平台的用户名和密码）
- 学习相关规范（编写测试用例、提交缺陷、使用工具）
- 积极主动（要积极主动的和项目组的成员、测试组负责人、师傅进行沟通）
四、如何发现更多的缺陷
1.二八原则（模块、人员）
模块：80%的缺陷，由20%的模块引入的。
人员：80%的缺陷出自于20%的研发人员。
注意：测试的时候要加强重点，哪个模块出现的bug多，我们就对这个模块加强重点测试，某一个研发人员的代码能力暂时提升的空间很大的时候，他写的代码的缺陷就会比较多，这时我们就要加强对这个人员的代码重点测试
2.不要依赖测试用例和需求（我们还要注意看研发人员的设计等等）
3.逆向思维、发散思维、扩展思维
4.尽早介入（越早介入越好，比如说需求阶段介入你发现需求的bug，这是修改bug的成本就会特别低，也就是说，缺陷发现的越早修改的成本就越低，越晚成本就越高。再往后代码越难改）
五、提交一个缺陷研发人员不认可（面试题！！！）
1.自查（查自己对需求理解的对不对，查自己提出的bug有没有问题，写的清不清楚，步骤对不对，缺陷可不可以复现？）
2.站在用户的角度考虑（给出的缺陷，要站在用户的角度考虑。让开发人员了解到缺陷对用户可能造成的困扰，可以问开发人员一句，如果你是用户你可以接受吗？）
3.缺陷级别定位要准确。
4.提高自身的业务能力和技术水平（自己的业务水平能力提高了之后，发现了bug就能给出研发人员相关的解决方案还能告诉他这个bug是因为什么原因而产生的怎么去修改？）
5.寻求第三方帮助（评审、沟通：找项目经理研发经理进行评审bug，确定到底是不是一个bug，以及原因）