目录
软件测试生命周期
软件测试贯穿于软件的整个生命周期。
具体流程：
- 测试人员不仅要具备开发能力，测试能力，最好具备一定的产品分析能力。
- 测试执行结束后，不能认为项目100%的问题都被发现了。问题是不可能完全被发现。
学习中，本地写的代码提交到码云上/部署到服务器上，可以称为一个上线流程。
实际工作中，上线也分成多个步骤：沙盒，小流量，全流量，全线上。
BUG篇
什么是BUG
- 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
- 当需求规格说明书没有提到的功能，判断标准以最终⽤⼾为准：当程序没有实现其最终⽤⼾合理 预期的功能要求时，就是软件错误。
规格说明/需求规格说明书等都指的是需求文档。
一切要以需求出发；验证软件产品的特性是否符合用户的需求。
描述BUG的要素
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
但是，bug的基本要素包括但不限于以上，还有如 bug级别 等等。
案例：两个浏览器登陆同一个网址，发现展示出的效果不一样。（谷歌浏览器二维码被登录窗口遮挡住了
BUG的级别
bug级别一般分为：崩溃，严重，一般，次要（基础的定义）。
定义bug级别的意义：①评估程序猿的开发能力；②给bug修复顺序排序；③ 看出问题的严重程度，同时会影响程序员的年终奖~
BUG的生命周期
在工作中，测试人员创建的bug不一定是有效的，也可能是因为误操作导致的无效bug。因此bug也有属于自己的生命周期。
简单来说，
所以，bug的级别和bug的数量都会影响到程序猿的年终奖，就难免测试人员与开发人员因bug而产生争论。
❓与开发者发生争执怎么解决❓
- 先检查自身，是否bug描述不清楚
反省自己：是不是在测试时出现了误操作，bug描述是不是没有写清楚
- 站在用户的角度考虑并抛出问题
功能正常只是测试的一部分，还需要考虑用户的使用感受。“如果你是用户，你能接受这样的界面/功能/使用吗？”
- BUG定级要有理有据
bug定级描述文档拿出来，然后将bug的表现和bug定级描述文档进行匹配，说服程序猿
- 提升自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案
测试小白更多的是提出问题，测试大佬除了提问题也能够定位到问题给出解决方案。（但是一定不要以命令式的口吻要求开发人员按照自己的逻辑来修改）
如果开发人员比较犟，怎么都不听的情况下，就需要进行bug评审~bug评审主要有三个代表：测试代表，开发代表，产品代表。
bug评审主要解决两个问题：
- 决定如何处理bug
- 分析缺陷产生的原因，找出预防的对策（不能犯相同的错误）
3485
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
