目录
一.软件测试的生命周期


软件测试人员不仅要具备开发能力、测试能力,最好具有一定的产品分析能力
**需求分析:**测试人员进行技术可行性的分析,业务是否会出现逻辑冲突导致用户的流失(例如购物车本来最多能存放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评审了
至少要有测试代表、开发代表以及产品代表三方面参加
主要解决如何处理问题、分析缺陷产生的原因并找出预防对策