目录
一.软件测试的生命周期
二.bug是什么？
三.如何描述一个bug？
四.bug的级别
五.bug的生命周期
六.测试与开发产生争执怎么办？（重要！！！）
一.软件测试的生命周期
软件测试人员不仅要具备开发能力、测试能力，最好具有一定的产品分析能力
需求分析：测试人员进行技术可行性的分析，业务是否会出现逻辑冲突导致用户的流失（例如购物车本来最多能存放50件商品，现在改成最能只能存放10件），再根据产品分析分析出购物车允许存放数量应该增加而不是减少
测试计划：顾名思义，计划时间内容
测试设计与开发：根据需求、技术文档等编写测试用例（方法+工具+形式）
测试执行：开始测试
测试评估：测试执行结束后，不能认为项目100%的问题都被发现了。评估一下当前项目测试是否通过，测试了项目的哪些方面，是否会有遗留的bug
运行维护：产品上线以后，及时发现问题，也正因此软件测试人员一般也是最了解产品的人员，一般演示会议也是由软测人员来进行
上线（本地写的代码提交到码云上/部署到服务器上，称为上线流程）：
实际工作中，分为4个流程 “ 沙盒->小流量->全流量->全线上 ”
因为上线过程中可能存在问题，线下测试没有问题线上可能会出现问题（例如模块、单元的冲突）
- 沙盒：企业内部的线上环境测试，可以供内部人员进行测试
- 小流量：部分线上真实用户可以使用到，测试人员要在线上手动测试，还要观察有没有错误日志（游戏内测）
- 全流量：所有的真实用户都可以用到（游戏demo，未完全优化好的产品）
- 全线上：上线前的所有测试流程全部完毕，可以上架steam（doge）
二.bug是什么？
定义：⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障 (fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误。
1.当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
一切都要以需求出发，即验证软件产品的特性是否符合用户的需求；根据用户需求创造出的测试用例，如果测试执行后获得的结果与预期不符，那么就能称为一个bug
2.当需求规格说明书没有提到的功能，判断标准以最终⽤⼾为准：当程序没有实现其最终⽤⼾合理预期的功能要求时，就是软件错误。
就比如一个界面做得不好看，字体太小但用户群以老年人为主；这种时候倘若规格说明书中没有明确提到，那么我们还是以用户需求为主
三.如何描述一个bug？
bug描述：浏览器打开链接失败
该描述下，没有明确说明哪个浏览器，失败的具体表现是什么，对于开发⼈员来说⽆法捕捉到更多有效的信息，会造成沟通效率低下，⼯作质量低下等问题。
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
版本和环境没有强区分，就算把浏览器版本写在环境里也是可以的，只要能够给上关键信息供工作人员去复现可以实现，但也不能说把软件版本写在环境里
四.bug的级别
通过定义bug的级别，能够明确看出问题的严重程度。⼯作中开发⼈员通常需要按照bug的级别来分配 优先级来处理bug，除此之外，通过bug级别也能够体现出开发⼈员的开发质量。
bug级别⼀般分为：崩溃、严重、⼀般、次要（有些公司可能会用P0、P1、P2、P3代替）
- 崩溃：阻碍开发或测试的问题，造成闪退、死循环等……
- 严重：主要功能部分丧失（例如一款购物软件，可以打开软件以及添加商品到购物车，但无法下单支付）
- 一般：功能没有完全实现但是不影响使用（例如一款搜索引擎，必须完整打出想要搜索的内容才能搜索出结果，没有搜索关键词）
- 次要：界面、性能缺陷（抢票的时候提示抢票的人太多了，无法进行抢票）
定义bug的级别意义在哪？
1）评估程序员的开发能力
2）年终奖评定
3）bug修复的优先级
五.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同样的处理方式
六.测试与开发产生争执怎么办？（重要！！！）
1.先检查⾃⾝，是否bug描述不清楚
反省自己，是不是测试的时候出现了误操作、bug描述不够清晰
2.站在用户角度考虑问题
功能正常只是测试的一部分，还需要考虑用户的使用感受
但也要三思而后行，如果钻牛角尖提出太多bug容易让开发人员恼火
3.bug定级要有理有据
一个次要bug定级定了严重，包会让开发人员感到难受的（毕竟和开发人员的年终奖有关）
4.提高自身技术，做到不仅能解决问题还能给出解决方案
5.bug评审
如果一个bug是会严重影响到用户体验的，但开发人员拒不修改，这个时候就可以召开bug评审了
至少要有测试代表、开发代表以及产品代表三方面参加
主要解决如何处理问题、分析缺陷产生的原因并找出预防对策
——学习笔记)
