文章目录
- [1. 软件测试的生命周期](#1. 软件测试的生命周期)
- [2. BUG](#2. BUG)
-
- [2.1 bug的概念](#2.1 bug的概念)
- [2.2 描述bug的要素](#2.2 描述bug的要素)
- [2.3 bug级别](#2.3 bug级别)
- [2.4 bug的生命周期](#2.4 bug的生命周期)
- [2.5 与开发产生争执怎么办（高频面试题）](#2.5 与开发产生争执怎么办（高频面试题）)
1. 软件测试的生命周期
需求分析--> 测试计划--> 测试设计、测试开发--> 测试执行 --> 测试评估 --> 上线 --> 运行维护
测试贯穿于软件的整个生命周期。
| 需求分析 | 测试计划 | 测试设计与开发 | 测试执行 | 测试评估 | 上线 | 运行维护 |
|---|---|---|---|---|---|---|
| ⽤⼾⻆度：软件需求是否合理技术⻆度：技术上是否可⾏，是否还有优化空间。测试⻆度：是否存在业务逻辑错误、冗余、冲突等问题 | 制定测试计划：什么时候开发测试，什么时候结束测试，耗时多久 | 参考需求⽂档、技术⽂档等编写测试⽤例写测试⽂档，明确标注使⽤到的测试⽅法，测试⼯具，测试形式等等 | 充分利⽤测试⽤例和测试⼯具对项⽬尽可能做到全⽅⾯的测试覆盖 | 测试是否通过，本次测试是否有遗留的BUG，最终测试人员需要出一个测试报告 | 项⽬测试结束后，将项⽬发布到线上环境，测试⼈员需求跟踪上线并测试线上环境下软件的运行是否正确 | 测试⼈员需要参与项⽬的实施⼯作。测试⼈员对项⽬产品的业务和操作⾮常了解，加上测试⼈员的沟通表达能⼒⼀般都⽐较强，所以测试⼈员可以参与⽤⼾使⽤软件的培训，在试运⾏项⽬时收集 问题并及时反馈给相关负责人 |
2. BUG
2.1 bug的概念
-
当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
-
当需求规格说明书没有提到的功能，判断标准以最终⽤⼾为准：当程序没有实现其最终⽤⼾合理预期的功能要求时，就是软件错误。
只要满足上面两条中的任意一条就是一个bug。
2.2 描述bug的要素
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
案例：
谷歌浏览器打开的页面：
火狐浏览器打开的页面：
描述bug:
问题出现的版本（软件版本）： 版本133.0.6943.127（正式版本）(64 位)【这里指的是软件版本，若是web系统，这里的版本就是浏览器的版本；若是APP，这里的版本就是软件的版本。】
问题出现的环境（测试环境）： windows系统版本xxxx.XXX
问题出现的步骤：
- 打开谷歌浏览器
- 输入网址：https://www.101eduyun.com/
- 页面展示第一个背景图上的小程序二维码
预期结果: 小程序二维码不会被登录模块遮挡，二维码可以正确扫描。
实际结果： 序二维码被登录模块遮挡，二维码不可以正确扫描。
注意：
- 要素包含但不限于以上这些，还可以有：序号、标题、bug等级...
- 笔试的时候，如果笔试题中明确要求让同学们提bug，一定要完全按照上面的格式来描述bug笔试的时候bug数量写的越多越好~
2.3 bug级别
通过定义bug的级别，能够明确看出问题的严重程度。⼯作中开发⼈员通常需要按照bug的级别来分配优先级来处理bug，除此之外，通过bug级别也能够体现出开发⼈员的开发质量。
案例：
男朋友多看了几眼美女：次要
男朋友跟美女加微信聊天：一般
男朋友跟美女私下去吃饭：严重！！！
男朋友跟美女去做头发：崩溃！坚决端了！！！！
通过级别，可以评估开发人员开发质量的好坏。在部分企业里，程序员的年终奖可能跟bug数量和质量息息相关；开发人员bug数量和质量又决定着测试人员的测试质量和能力。
bug级别⼀般分为：崩溃、严重、⼀般、次要。对于不同的企业来说，bug等级可能稍有不同，但是万变不离其宗。
入职之后，公司/团队会提供"bug级别描述文档"。
| 崩溃 | 严重 | 一般 | 次要 |
|---|---|---|---|
| 阻碍开发或测试⼯作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发⽣死锁、重要的⼀级菜单功能不能使⽤等（该问题在测试中较少出现，⼀旦出现应⽴即中⽌当前版本测试）。 | 系统主要功能部分丧失、数据库保存调⽤错误、⽤⼾数据丢失，⼀级功能菜单不能使⽤但是不影响其他功能的测试。功能设计与需求严重不符，模块⽆法启动或调⽤，程序重启、⾃动退出，关联程序间调⽤冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显⽰错误，⽤⼾所要求的功能缺失，程序接⼝错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。 | 功能没有完全实现但是不影响使⽤，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间⻓、查询时间⻓、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多） | 界⾯、性能缺陷，建议类问题，不影响操作功能的执⾏，可以优化性能的⽅案等。如：错别字、界⾯格式不规范，⻚⾯显⽰重叠、不该显⽰的要隐藏，描述不清楚，提⽰语丢失，⽂字排列不整⻬，光标位置不正确，⽤⼾体验感受不好，可以优化性能的⽅案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理） |
2.4 bug的生命周期
测试⼈员在执⾏测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug⽣命起源），创建好的bug需要被开发⼈员修复，以及测试⼈员的持续跟踪和测试。
- New:新发现的Bug，未经评审决定是否指派给开发⼈员进⾏修改。
- Open：确认是Bug，并且认为需要进⾏修改，指派给相应的开发⼈员。
- Fixed:开发⼈员进⾏修改后标识成修改状态，有待测试⼈员的回归测试验证。
- Rejected：如果认为不是Bug，则拒绝修改。
- Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
- Closed：修改状态的Bug经测试⼈员的回归测斌验证通过，则关闭Bug。
- Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发⼈员重新修改。
⽆效的bug：open->closedopen-rejected-closed
在工作中，开发人员创建的bug不一定是有效的，也可能是误操作导致的无效bug，无效bug在一定程度上反映了个人的测试能力。
2.5 与开发产生争执怎么办（高频面试题）
在测试⼯作中，最常遇到的是和开发⼈员的PK，作为测试经理还会和项⽬经理、产品经理的PK进度、质量。作为⼀名测试⼈员，⼀般会遇到以下⼏种情况：
遇到争执不要怕，要理性的分析和反馈问题。
1. 先检查⾃⾝，是否bug描述不清楚。
反省自己：是不是测试中出现了误操作、bug描述不清楚。
2. 在用户角度考虑并抛出问题
可以问一句：如果你是用户，你可以接受么？
3. BUG定级要有理有据
bug定级描述文档拿出来，然后将bug的表现和bug定级描述文档进行匹配，说服程序猿。
4. 高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案
测试小白：更多的是提出问题（bug)。
测试大牛：除了提出问题也能够定位到问题，给出解决方案。
一定不要以命令式的口吻要求开发人员按照自己的方案来修改代码，只是建议而已~，不要命令或者认为开发人员必须这样改。
5. BUG评审
bug评审额外还需要有三个代表来参加：测试代表（测试人员的直接上级）、开发代表（开发人员的直接上级）、产品代表（当前需求开发者）。
BUG评审主要解决两个问题：
- 决定如何处理bug.
- 分析缺陷产生的原因，找出预防的对策（防止在以后的工作中，找出预防的对策）。
前面4个解决方案，讲述的顺序不重要，但是bug评审一定是放到最后去说，这是工作中出现问题的终极大招~