目录

一.软件测试的生命周期

二.bug是什么？

三.如何描述一个bug？

四.bug的级别

五.bug的生命周期

六.测试与开发产生争执怎么办？（重要！！！）

---

一.软件测试的生命周期

软件测试人员不仅要具备开发能力、测试能力，最好具有一定的产品分析能力

需求分析：测试人员进行技术可行性的分析，业务是否会出现逻辑冲突导致用户的流失（例如购物车本来最多能存放50件商品，现在改成最能只能存放10件），再根据产品分析分析出购物车允许存放数量应该增加而不是减少

测试计划：顾名思义，计划时间内容

测试设计与开发：根据需求、技术文档等编写测试用例（方法+工具+形式）

测试执行：开始测试

测试评估：测试执行结束后，不能认为项目100%的问题都被发现了。评估一下当前项目测试是否通过，测试了项目的哪些方面，是否会有遗留的bug

运行维护：产品上线以后，及时发现问题，也正因此软件测试人员一般也是最了解产品的人员，一般演示会议也是由软测人员来进行

---

上线（本地写的代码提交到码云上/部署到服务器上，称为上线流程）：

实际工作中，分为4个流程 “ 沙盒->小流量->全流量->全线上 ”

因为上线过程中可能存在问题，线下测试没有问题线上可能会出现问题（例如模块、单元的冲突）

1. 沙盒：企业内部的线上环境测试，可以供内部人员进行测试
2. 小流量：部分线上真实用户可以使用到，测试人员要在线上手动测试，还要观察有没有错误日志（游戏内测）
3. 全流量：所有的真实用户都可以用到（游戏demo，未完全优化好的产品）
4. 全线上：上线前的所有测试流程全部完毕，可以上架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评审了

至少要有测试代表、开发代表以及产品代表三方面参加

主要解决如何处理问题、分析缺陷产生的原因并找出预防对策