软件测试 | 基础篇

※ 软件测试的生命周期（软件测试的流程）

• 需求分析：分析需求，细化需求，验证需求的正确性和合理性
• 测试计划：规划测试人员（数量）、时间、范围、目的
• 测试设计/开发：分析需求，从细化的需求中提炼功能点（测试点），设计测试用例
• 测试执行：执行测试用例，记录BUG
• 测试报告/评估：测试的范围、有多少测试用例，执行了多少测试用例，余留了多少测试用例，发现了多少BUG，修改了多少BUG（验证），遗留的BUG以及解决方案

※ 如何描述一个bug

1. 版本号（代码版本号）
2. 测试环境（平台）
   不同的浏览器对同一个系统的同一个页面解析是不一样的
   Windows/MAC
   Firefox/Chrome/edge/360/搜狗/QQ（具体到浏览器对应的版本号）
   手机APP：Android/iOS（具体到不同的机型）
3. 测试步骤和测试数据
4. 实际结果
5. 预期结果
6. 附件：错误截图、错误日志等

例：

操作：邮箱输入了19个字符，输入正确的密码和手机号，勾选同意，点击立即注册，注册成功。
BUG描述
标题：注册邮箱，邮箱地址输入19个字符，注册成功
测试版本号：version12
测试环境：Windows10 Microsoft Edge 版本 92.0.902.84
测试步骤：
1.进入网易邮箱注册页面
2.邮箱地址输入19个字符：bulabulabiubiubiuha
3.输入符合要求的正确的密码：Z1asdfg456
4.输入符合要求的正确的手机号：15296482356
5.勾选同意条款
6.点击立即注册
实际结果：注册成功
预期结果：注册失败

BUG级别的定义

1. 崩溃：系统运行阻断，严重影响了开发人员和测试人员的工作，需要立马修复；
   线上出现崩溃级别的BUG怎么办？回退到一个稳定的版本
2. 严重：系统还可以运行，但是已经不稳定了，如果再运行下去，可能会产生严重的后果（直播画面失真，密码明文显示等）；
3. 一般：系统可以稳定的运行，但是一些次要功能没有实现，可能会影响用户的体验；
4. 次要（建议性）：影响用户的视觉体验，界面的文字提示内容，展示，图片的排版。（没有严格体现在需求当中，要不要改需要和产品经理商量）

BUG的生命周期

BUG状态转移图

测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。

问题：
测试人员提了一个BUG，开发人员已经修改了，但是测试人员测试的时候，发现这个BUG依然存在，有哪些原因？

• 开发人员没修改好
• 开发人员没有把代码更新到测试环境（没有提交代码）
• 测试人员忘记拉取最新的代码到测试环境进行发布

※ 产生争执怎么办

面试常见问题：
如果碰到一个BUG，和开发人员产生冲突怎么办？
1、先检查自身，是否bug描述不清楚
2、检查BUG的定级是否按照公司的标准判定（BUG定级要有理有据）
3、站在用户的角度说服开发人员
4、提高自身的业务水平和技术水平，不光要提出问题, 最好也能提出解决方案
5、开发人员不接受时，不要争吵，和开发人员、产品经理开会商量BUG的解决方案