软件测试的生命周期?
(软件测试的流程)
需求分析 —》 测试计划 —》 测试设计/开发 —》 测试执行 —》 测试报告
- 需求分析:分析需求、细化需求、验证需求的正确性和合理性
- 测试计划:规划测试人员数量,规划时间、测试范围、测试目的
- 测试设计/开发:分析需求,从细化的需求中提炼功能点,设计测试用例
- 测试执行:执行测试用例,记录BUG
- 测试报告:测试的范围有多少测试用例,执行了多少,预留了多少测试用例,发现了多少BUG,开发人员修改了多少BUG(验证),遗留的BUG以及解决方案
如何表述一个BUG?
- 版本号(代码版本号)
- 测试环境(平台):不同的浏览器对同一个系统的同一个页面解析是不一样的
Window / Mac 系统
Firefox / Chrome / edge / 360 / 搜狗 / QQ 浏览器对应的版本号
ios / Android 手机系统,手机机型 - 测试步骤和测试数据
- 实际的结果
- 预期的结果
- 附件 (错误截图,错误日志等)
练习
操作:邮箱输入了19个字符,输入正确的密码和手机号,勾选同意,点击立即注册,注册成功
标题:注册邮箱,邮箱地址输入19个字符,注册成功
测试版本号:versionx12
测试环境:Windows10 Chrome 版本 89.0.4389.128
测试步骤:
- 进入网易邮箱注册页面
- 邮箱地址输入19个字符:jkkdasfasdftdswgjgq
- 输入符合要求的正确密码:*******
- 输入符合要求的正确手机号:18735412654
- 勾选同意条款
- 点击立即注册
实际结果:注册成功
预期结果:注册失败
BUG级别的定义
- 崩溃:系统运行阻断,严重影响了开发人员和测试人员的工作,需要立马修复
线上出现崩溃级别的BUG怎么办?回退到一个稳定的版本 - 严重:系统还可以运行,但是已经不稳定了,如果再运行下去,可能会产生严重的后果
- 一般:系统可以稳定的运行,但是一些次要功能没有实现,可能会影响用户的体验
- 次要(建议性):没有严格体现再需求里面的
影响用户的视觉体验,界面的文字提示内容,展示,图片的排版,要不要改和产品经理商量
BUG的生命周期
- New:新发现的Bug,未经评审决定是否指派给开发人员进行修改。
- Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。
- Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证。
- Rejected:如果认为不是Bug,则拒绝修改。
- Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。
- Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug。
- Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。
- 无效的bug:open->closed open-rejected-closed
如果碰到一个BUG,和开发人员产生冲突怎么办?
- 先检查自己的BUG描述是否清除
- 检查BUG的定级是否按照公司的标准来的
- 站在用户的角度去说服开发
- 不断提高自己的业务水平和技术水平
- 和开发人员,产品经理开会商量BUG的解决方案