测试专栏

🍟 🍟

🍍 一.软件测试的生命周期

首先我来回顾一下前面讲述过的软件开发的生命周期:软件开发是贯穿在(需求分析–计划–设计–编码–测试–运行维护)整个过程的,而软件测试的生命周期(其实就是软件测试的流程) :需求分析 – 测试计划 – 测试设计/测试开发 – 测试执行 – 测试评估; 而对于软件测试人员,每个阶段都做了什么:

需求分析:需要测试需求的合理性和正确性,并且细化需求,找出测试想,然后写出测试用例; 测试计划:需要确定测试人数,测试环境,测试时间,测试设备;> 测试设计/测试开发:此时就可以根据需求来写测试用例了; 测试执行:此时软件人员的开发就已经结束了,测试人员就需要根据测试用例,来验证功能,是否已经完成,如果发现有未完成的测试用例,也就是BUG,那么测试人员就需要编写测试报告,来提交BUG,等待开发人员进行修改,修改完成之后,测试人员就需要验证BUG; 测试评估:这个阶段就需要写出在整个测试过程中,写了多少测试用例,执行了多少测试用例,剩余了多少测试用例数,为什么不完成所有的测试用例,以及测试出的BUG数量,解决掉的BUG数量,还有遗留的BUG数量以及解决方案,甚至是测试范围和测试功能…一系列都需要说明清楚!

🍍 二.如何描述一个BUG

一般会使用一些BUG管理工具,以文字的形式来进行描述,例如禅道,jira,tapd都是一些BUG管理工具,那描述一个BUG应该从哪些方面描述呢?

🍍 三.BUG的级别

另外这里补充一下关于BUG的级别,这个级别每个公司的都不一样,这里只是介绍普遍情况:

崩溃:导致系统无法正常运行,出现了崩溃,操作死锁,死循环,或者黑屏,已经很明显的影响到了测试人员的工作,这就属于非常严重的BUG了,需要及时补救,而要如果是线上出现了这样的情况,应该怎么去进行补救呢?此时就需要及时回溯到一个稳定的版本上,然后再去修改这个严重的BUG,这样可以把损失降低到最小; 严重:系统可以运行,但是不稳定,继续运行下去会在成严重的损失,重要的功能并没有实现,或者功能和需求并不符合,或者数据库中用户数据的存储出现错误,已经威胁到了用户的安全(财产,信息); 一般:次要的功能没有实现,或者有错误,但是系统可以正常稳定的运行; 建议:无关紧要的一些BUG,但是可能会影响到用户的体验,排版可能局促,或者颜色不符合大众的审美,或者信息没有换行,或者换行太多;

🍍 四.BUG的生命周期

其实就是BUG的各种生存状态:

🍍 五.因为BUG和开发人员产生冲突,怎么办

在工作中,难免会与开发人员产生冲突,因此可以从下几个点出发完美的解决这个问题:

1. 先从自身出发,看自己的BUG是否描述清楚;
2. 从用户的角度出发,看是否可以说服开发人员进行修改;
3. BUG的定级要有理有据(根据公司规范);
4. 不断提升自己的业务水平和技术水平,不但能够发现BUG,并且能够定位,然后自己提出BUG的解决方案;
5. 以上方案就无法解决的话,一定不要和开发人员进行争吵,可以找产品经理进行讨论,然后开一个三方会议(测试人员,开发人员,以及产品经理)共同讨论这个BUG的最终解决方案!