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