1. 软件测试的生命周期
软件测试贯穿于软件的整个⽣命周期，针对这句话我们⼀起来看⼀下软件测试是如何贯穿软件的整个生命周期。
软件测试的生命周期是指测试流程，这个流程是按照⼀定顺序执⾏的⼀系列特定的步骤，去保证产品 质量符合需求。在软件测试⽣命周期流程中，每个活动都按照计划的系统的执⾏。每个阶段有不同的目标和交付产物
各阶段具体内容：
测试人员不仅要具备开发能力、测试能力，最好具备一定的产品分析能力
测试执行结束后，不能认为项目100%的问题被发现了。问题是不可能被完全发现
学习中，本地写的代码提交到码云上、部署到服务器上，可以称为一个线上流程，实际在工作中，上线要分成很多个步骤：沙盒、小流量、全流量、全线上 因为上线的过程中也可能会存在问题，线下测试没有问题。如果直接推到线上可能会发现问题
沙盒：企业内部的线上环境可以供内部人员进行测试
小流量：部分线上真实的用户可以使用到测试人员要在线上测试，还要观察有没有错误日志，真实用户在使用过程中是否发现了问题
全流量：所有用户都可以使用到
线上环境和线下环境并不是完全一样的，因此每一步都需要跟进测试
2. BUG
2.1 bug的概念
定义：⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障 (fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误。
准确的来说：
- 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
- 当需求规格说明书没有提到的功能，判断标准以最终⽤⼾为准：当程序没有实现其最终⽤⼾合理
预期的功能要求时，就是软件错误。
一切要以需求出发，验证软件产品的特性是否符合用户的需求
2.2 描述bug的要素
为什么描述bug还有要素要求？
在⼼理学上说，⼈们在编写⽂档的时候，经常会出现自己想表达的和写出来的内容往往南辕北辙
bug描述：浏览器打开链接失败
该描述下，没有明确说明哪个浏览器，失败的具体表现是什么，对于开发人员来说无法捕捉到更多有效的信息，会造成沟通效率低下，⼯作质量低下等问题。
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
案例：https://www.101eduyun.com/
问题出现的版本：谷歌浏览器版本 123.0.6312.123（正式版本） （64 位）
问题出现的环境：Windows家庭版
问题出现的步骤：
1、打开谷歌浏览器，输入网址https://www.101eduyun.com/
2、等待首页面渲染完成
预期结果：二维码与登陆模块不会出现遮挡，二维码可以正常扫描
实际结果：二维码被登陆模块遮挡，二维码扫描失败
版本和环境没有强区分，就算把浏览器版本写在环境里也是可以的，只要能够给上关键信息供开发人员去复现就可以的
2.3 bug级别
通过定义bug的级别，能够明确看出问题的严重程度。⼯作中开发⼈员通常需要按照bug的级别来分配 优先级来处理bug，除此之外，通过bug级别也能够体现出开发⼈员的开发质量。
案例：
bug级别⼀般分为：崩溃、严重、⼀般、次要
2.4 bug的生命周期
测试⼈员在执⾏测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug⽣命起
源），创建好的bug需要被开发⼈员修复，以及测试⼈员的持续跟踪和测试。
在工作中，测试人员创建的bug不一定是有效的，也可能是因为误操作导致的无效bug
● New:新发现的Bug，未经评审决定是否指派给开发⼈员进⾏修改。
● Open：确认是Bug，并且认为需要进⾏修改，指派给相应的开发⼈员。
● Fixed:开发⼈员进⾏修改后标识成修改状态，有待测试⼈员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试⼈员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发⼈员重新修改。
⽆效的bug：open->closed open-rejected-closed
2.5 与开发产生争执怎么办（高频考题）
在测试工作中，最常遇到的是和开发⼈员的PK，作为测试经理还会和项目经理、产品经理的PK进度、 质量。作为⼀名测试人员，⼀般会遇到以下几种情况：
遇到争执不要怕，要理性的分析和反馈问题。
2.5.1 先检查自身，是否bug描述不清楚
反省自己：是不是在测试的时候出现了误操作、bug描述是不是没有写清楚，主动找开发沟通说明，确保开发理解问题，避免被动等待开发询问。
2.5.2 站在用户角度考虑并抛出问题
站在用户⻆度考虑问题 应该让开发⼈员了解到Bug对用户可能造成的困扰，这样才能促使开发⼈员
更加积极地、高质量地修改Bug。在争执时，可以问⼀句：如果你是用户，你可以接受么？
2.5.3 BUG定级要有理有据
BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们 的是有区别的，需站在用户的⻆度定考虑定位级别。
2.5.4 提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决⽅案
提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。 在工作中，你会发现同⼀个bug，资深测试⼯程师提出和初级测试⼯程师提出，两者的结果完全不同，两者最⼤的差别是资深测试工程师往往会提出解决⽅案。而长此以往，权威性逐渐的建立起来，那么开 发⼈员看到bug的第⼀反应，就是这是⼀个bug，而不是这是⼀个bug吗？
注意：可以给出解决⽅案，但是不能喧宾夺主，命令式让开发⼈员按照自己的想法来修改。
2.5.5 bug评审
如果确实是bug，友好沟通不能解决问题，那么就召开bug评审。
bug评审主要解决两个问题：
1）决定如何处理bug
2）分析缺陷产⽣的原因，找出预防的对策
bug评审⾄少需要项⽬组各个⽅⾯的代表参加：
1）测试代表
测试代表主要从Bug的具体表现、严重程度等⽅⾯提供信息，并提出⾃⼰对Bug的处理意⻅。需要注 意的是，测试⼈员不应该⼀味地要求对Bug进⾏修改，因为修改可能带来回归的⻛险，同时带来的是 回归测试的⼯作量，如果时间⽐较紧迫，修改后剩余的时间若不⾜以做⼀次有效的回归测试，可能不 修改是个明智的选择。
2）开发代表
开发代表主要从修改缺陷的难度和⻛险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、 可能引发的⻛险等，如果决定要修改，还要讨论出修改的初步⽅案。
3）产品代表
产品代表主要从产品的整体计划、用户的要求等⽅⾯对缺陷的修改必要性、缺陷修改的时间和版本提 出自己的意见