文章目录
软件测试的生命周期
软件开发的生命周期
需求分析—计划—设计—编码—测试—运行维护
软件测试的生命周期(软件测试的流程)
需求分析—测试计划—测试设计/测试开发—测试执行—测试评估
每个阶段需要做什么
1. 需求分析:验证需求的正确性,合理性,细化需求,找出测试项,写测试用例
2. 测试计划: 确定测试人数,测试环境,测试时间,测试设备
3. 测试设计/测试开发:根据需求写测试用例
4. 测试执行:开发已经完成,执行测试用例,验证功能,如果有BUG,提交BUG,验证BUG
5. 写了多少测试用例,执行了多少,剩余了多少测试用例,BUG数量以及解决的BUG数量,遗留的BUG以及解决方案
如何描述一个BUG
一个合格的BUG描述应该包括以下几个部分:
- 测试版本号:开发人员需要知道出现问题的版本,才能够获取到对应版本的代码来重现故障,并且版本的标识也有利于统计和分析每个版本的质量
- 测试环境:环境分为硬件环境和软件环境,如果是web项目,需要描述浏览器版本(哪一款浏览器,浏览器版本号…),客户机操作系统等,如果是app项目,需要描述机型,分辨率,操作系统版本等。详细的环境描述有利于故障的定位
- 测试数据
- 测试步骤
- 测试实际结果
- 测试预期结果
- 附件,错误日志,错误截图等等
BUG的级别
注意:没个公司都不一样,这里只是普遍的情况
- 崩溃:系统无法正常运行,出现崩溃,操作死锁,死循环,黑屏,阻碍测试人员的工作
注意:这里有一个实际情况,如果线上出现了崩溃情况我们该如何去办?怎么补救?————》回退到上一个稳定的版本 - 严重:系统运行,但是不稳定,继续运行下去会造成严重的损失,重要的功能没有实现,或者功能和需求不符合,数据库中用户数据存储错误,威胁到用户的安全(信息,财产)
- 一般:次要的功能没有实现,或者有错误,系统可以稳定运行
- 建议:功能全都实现,但会影响用户的体验,如:排版,颜色不符合大众审美,信息没有换行,或者提前换行
BUG的生命周期
因为BUG和开发人员冲突该怎么办?
- 检测BUG是否描述清楚
- 从用户的角度去说服开发人员修改
- BUG定级要有理有据(根据公司的规范)
- 作为测试人员要不断提升自己的业务水平和技术水平,不但能够发现BUG,并且能够定位,还能提出解决方案
- 不要争吵,找产品经理讨论:三方会议,测试人员,开发人员,产品经理会讨论这个BUG的最终解决方案