本节概要：
软件测试的生命周期
bug的概念
buh要素
bug等级
bug生命周期
对于bug的定级与开发发生冲突如何解决
一、 软件测试的⽣命周期
软件测试贯穿于软件的整个生命周期，针对这句话我们⼀起来看⼀下软件测试是如何贯穿软件的整个生命周期。
软件测试的⽣命周期是指测试流程，这个流程是按照⼀定顺序执⾏的⼀系列特定的步骤，去保证产品质量符合需求。在软件测试⽣命周期流程中，每个活动都按照计划的系统的执行。每个阶段有不同的⽬标和交付产物。
因为测试人员是要最了解需求的人，在需求分析会上测试人员可以从技术，产品，用户等角度考虑需求是否有问题。后面....
| 需求分析 | 测试计划 | 测试设计与开发 | 测试执⾏ | 测试评估 | 上线 | 运⾏维护 |
| ⽤⼾角度：软件需求是否合理 技术⻆度：技术上是否可⾏，是否还有优化空间 测试⻆度：是否存在业务逻辑错误、冗余、冲突等问题 | 制定测试计划：什么时候开发测试，什么时候结束测试，耗时多久 | 参考需求⽂档、技术⽂档等编写测试⽤例 写测试⽂档，明确标注使⽤到的测试⽅法，测试⼯具，测试形式等 | 充分利⽤测试⽤例和测试⼯具对项⽬尽可能做到全⽅⾯的测试覆盖 | 测试是否通过，本次测试是否有遗留的BUG，最终测试⼈员需要产出一个测试报告 | 项⽬测试结束后，将项⽬发布到线上环境，测试⼈员需求跟踪上线并测试线上环境下软件的运行是否正确 | 测试⼈员需要参与项⽬的实施⼯作。测试⼈员对项⽬产品的业务和操作⾮常了解，加上测试⼈员 的沟通表达能⼒⼀般都⽐较强，所以测试⼈员可以参与⽤⼾使⽤软件的培训，在试运⾏项⽬时收集问题并及时反馈给相关负责人 |
二、 Bug
2.1 bug的概念
测试人员一定是最了解需求的人，最后演示会议是由测试人员来演示产品/软件
测试人员不仅要具备开发能力，测试能力，最好具备一定的分析能力。
测试执行结束后，不能认为项目100%的问题全被发现了。问题是不可能全被发现的
二、Bug
2.1 bug的概念
定义：⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误
1. 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
2. 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理
预期的功能要求时，就是软件错误。
2.2 描述bug的要素
为什么描述bug还有要素要求？
在⼼理学上说，⼈们在编写⽂档的时候，经常会出现⾃⼰想表达的和写出来的内容往往南辕北辙。
Eg：
bug描述：浏览器打开链接后二维码窗口被遮挡。
该描述下，没有明确说明哪个浏览器，失败的具体表现是什么，对于开发⼈员来说⽆法捕捉到更多有效的信息，会造成沟通效率低下，⼯作质量低下等问题。
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
bug级别
通过描述bug的基本要素让开发人员快速定位具体的问题，复现bug。
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，开发⼈员重新修改。
2.5 关于bug和开发人员发生冲突怎么办
在工作中，测试人员创建的bug不一定是有效的，也可能是因为误操作导致的无效bug。
- 先检查自身，是否bug描述不清楚
- 站在用户角度考虑并抛出问题：站在⽤⼾⻆度考虑问题 应该让开发⼈员了解到Bug对⽤⼾可能造成的困扰，这样才能促使开发⼈员 更加积极地、⾼质量地修改Bug
- BUG定级要有理有据：BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往⽤⼾的BUG级别和我们的是有区别的，需站在⽤⼾的⻆度定考虑定位级别
- 提⾼⾃⾝技术和业务⽔平，做到不仅能提出问题，最好也能给出解决⽅案
- bug评审：
1. 决定如何处理bug
2.分析缺陷产⽣的原因，找出预防的对策
bug评审⾄少需要项⽬组各个⽅⾯的代表参加：测试代表，开发代表，产品代表
