- 软件测试的基本概念
- 关于软件测试
目录
- 一.软件测试的生命周期
- 二.如何描述一个BUG
- 三.BUG的级别
- 四.BUG的生命周期
- 五.因为BUG和开发人员产生冲突,怎么办
一.软件测试的生命周期
首先我来回顾一下前面讲述过的软件开发的生命周期:软件开发是贯穿在(需求分析–计划–设计–编码–测试–运行维护)整个过程的,而软件测试的生命周期(其实就是软件测试的流程) :需求分析 – 测试计划 – 测试设计/测试开发 – 测试执行 – 测试评估;
而对于软件测试人员,每个阶段都做了什么:
- 需求分析:需要测试需求的合理性和正确性,并且细化需求,找出测试想,然后写出测试用例;
- 测试计划:需要确定测试人数,测试环境,测试时间,测试设备;>
- 测试设计/测试开发:此时就可以根据需求来写测试用例了;
- 测试执行:此时软件人员的开发就已经结束了,测试人员就需要根据测试用例,来验证功能,是否已经完成,如果发现有未完成的测试用例,也就是BUG,那么测试人员就需要编写测试报告,来提交BUG,等待开发人员进行修改,修改完成之后,测试人员就需要验证BUG;
- 测试评估:这个阶段就需要写出在整个测试过程中,写了多少测试用例,执行了多少测试用例,剩余了多少测试用例数,为什么不完成所有的测试用例,以及测试出的BUG数量,解决掉的BUG数量,还有遗留的BUG数量以及解决方案,甚至是测试范围和测试功能…一系列都需要说明清楚!
二.如何描述一个BUG
一般会使用一些BUG管理工具,以文字的形式来进行描述,例如禅道,jira,tapd都是一些BUG管理工具,那描述一个BUG应该从哪些方面描述呢?
- 测试版本号(代码版本信息):在正式测试的时候是需要一些测试版本号的,不能直接在正式版本上进行测试,而如果测试人员在测试的时候发现了BUG就需要说明测试版本号来方便修改BUG的开发人员及时修改;
- 测试环境:如果是web系统,就需要说明硬件设备信息(电脑的品牌以及型号),软件设备(什么操作系统),如果使用的是浏览器的话也是需要说明什么浏览器,以及其的版本号;而如果是APP的话也是需要说明软件设备信息(其系统(安卓,IOS…)以及其版本号),硬件设备(品牌信息及版本);
- 测试数据:有了测试数据开发人员可以快速的复现问题;
- 测试步骤:测试的全部步骤;
- 测试的实际结果和测试的预期结果:方便开发人员进行对比;
- 附件信息:包括错误日志,错误截图等等;
三.BUG的级别
另外这里补充一下关于BUG的级别,这个级别每个公司的都不一样,这里只是介绍普遍情况:
- 崩溃:导致系统无法正常运行,出现了崩溃,操作死锁,死循环,或者黑屏,已经很明显的影响到了测试人员的工作,这就属于非常严重的BUG了,需要及时补救,而要如果是线上出现了这样的情况,应该怎么去进行补救呢?此时就需要及时回溯到一个稳定的版本上,然后再去修改这个严重的BUG,这样可以把损失降低到最小;
- 严重:系统可以运行,但是不稳定,继续运行下去会在成严重的损失,重要的功能并没有实现,或者功能和需求并不符合,或者数据库中用户数据的存储出现错误,已经威胁到了用户的安全(财产,信息);
- 一般:次要的功能没有实现,或者有错误,但是系统可以正常稳定的运行;
- 建议:无关紧要的一些BUG,但是可能会影响到用户的体验,排版可能局促,或者颜色不符合大众的审美,或者信息没有换行,或者换行太多;
四.BUG的生命周期
其实就是BUG的各种生存状态:
五.因为BUG和开发人员产生冲突,怎么办
在工作中,难免会与开发人员产生冲突,因此可以从下几个点出发完美的解决这个问题:
- 先从自身出发,看自己的BUG是否描述清楚;
- 从用户的角度出发,看是否可以说服开发人员进行修改;
- BUG的定级要有理有据(根据公司规范);
- 不断提升自己的业务水平和技术水平,不但能够发现BUG,并且能够定位,然后自己提出BUG的解决方案;
- 以上方案就无法解决的话,一定不要和开发人员进行争吵,可以找产品经理进行讨论,然后开一个三方会议(测试人员,开发人员,以及产品经理)共同讨论这个BUG的最终解决方案!
