工作效率不够高?也许不是不努力,而是缺少测试思维

前言:软件测试人员的工作主要是检测软件系统中的存在的BUG,但并不是毫无逻辑的盲目抓瞎。学会运用测试思维去完成测试工作,会使你的工作事半功倍。

软件测试的前提假设

测试人员进行软件测试的基本假设是“有罪推断”。即:认为被测程序一定是有bug的,而且每个功能点的实现都存在bug,而且一定存在严重的bug。请牢记这个假设。

在实际工作中,一旦在日后的工作过程中产生了这样的认识:“这个功能很简单,肯定不会出现问题,就不再测试了。”或者“这个功能上一轮刚测试过,当时就没有问题,这一轮应该也不会有问题,就不用测试了。”等等诸如此类的意识,那么你就有90%的概率导致漏测,造成线上问题。

其原因也正是这个测试工作的基本前提假设。一旦被违背,就从开端导致了测试工作存在问题,所以真正出现问题的可能性也就很大了。

正因为软件测试的这个前提假设,在导致了如果我们同开发人员看待程序的角度和出发点完全不同。

因为,通常情况下一个有自信心的开发人员不会认为自己写的代码全部都有问题,他一定是认为自己的代码没有问题了才交付测试的。

因此,如果要从事软件测试工作,那么就必须牢记并运用该假设。这个前提假设要求我们在实施测试的过程中不能放过任何一个细小问题。

比如,某个程序运行时在控制台打印了一些错误信息,但是实际上该程序的运行和功能都没有问题,如果我们摒弃有罪推断的假设,从合理实现的角度去分析,那么就可以认为这是开发人员对于日志打印的输出控制没有做好导致的,属于微不足道的小问题,不需提出即可。

于是,这就使你有90%的可能性错过了发现其编码上的异常分支判断错误导致的重大问题。

相信诸如此类的教训在每一个测试人员那里都不是少数。所以,请转变思维,牢记这个假设。

测试工作的开展思路

01 从需求出发

无论什么样的软件产品,其设计开发的目的必然是为了满足一定的需求,这种需求或者是用户提出的,或者是某个关联系统提出的。因此,软件产品最终是为了交付给用户使用的,也因此可以满足需求是对于软件产品质量的基本保证,其它如扩展性、维护性等等其实也算是更为广义的需求。所以,我们开展软件测试工作必须从需求出发。

02 测试依据是测试设计?

我们进行测试设计的依据是对于软件产品需求的全面和深入分析,但是需求决不全是软件测试的依据。

因为我们不仅要验证需求,而且要验证设计。比如,程序实现的异常(指针越界、字符串copy越界等等)判断,是保证软件产品可以正常运行的必要实现,但是我们在需求中是无法描述和分析出来的。那么进行测试的依据是软件产品的设计或者是代码吗?

当然也不是。因为如果依据开发人员的设计或代码来进行测试的话,设计或代码正确,但是不符合需求逻辑的错误就无法发现。而且,如果依据设计或代码进行测试的话,那么也就违背了我们进行软件测试的基本假设——有罪推断。

所以,我们进行软件测试的依据应该是:我们根据对需求的全面深入分析和对设计实现的了解,两相综合产生的测试设计。正因为如此,测试是否充分和有效的根源也是测试设计。所以,我们的工作重点也是测试用例设计。

 03 测试人员只是验证质量?

首先要明确的是,测试人员无法保证软件产品的质量,软件产品的质量是通过参与软件过程的各方联合共同保证的。有两个原因:

①   由于软件测试人员不是产品设计人员和开发人员,所以无法做到比他们更了解产品需求和产品设计,如果他们都无法保证需求和设计没有问题,那么测试人员就更无法保证了;

②   软件测试位于软件开发生命周期的末端,如果依靠测试人员来发现所有的bug来保证质量的话,那么风险就会后置,导致问题修复的成本增加,同时也增加了修复问题带来新问题的风险,因为在项目末端是不可能投入过多的成本来进行那怕接近全面覆盖的测试的。

也正因为如此,我们是无法决定一个软件产品质量的好坏的,只有PM设计出产品需求,RD编码完成,我们才能够通过我们的工作,促进PM、RD改进他们的产品、系统,从而达到产品、系统的高质量。所以,我们才要参与需求评审和设计评审,大家一起努力,各个阶段由专业化的人员来保证阶段的质量,将问题尽量在前期发现。

04 测试的内容一定是确定的

软件测试只能验证质量,那么所要验证的内容必然是确定的,或者说是概率确定的,否则也就无从验证了。因此,模糊不确定的需求我们无法验证,输出结果没有任何规律的程序设计我们也无法验证,这就是软件产品的可测性判断。也因此,我们进行需求评审和设计评审时是一定要保证这个基本点的。

05 测试的目标不是没有bug

综上所述,进行软件测试的目标不是通过测试使得软件产品不存在bug(这是不可能达成的),而是我们根据确定的需求、确定的设计和确定的测试用例验证出的结果不存在bug。

同样的,测试人员的目标也不是在测试执行过程中去找bug,而是运用测试思维,使用一定的测试方法,尽可能早地在需求阶段、设计阶段将所有的bug找出来,真正测试执行阶段只是验证不存在用例所描述的那样的bug,而不是通过用例去发现bug。

测试人员的工作方法

通过前文的分析,我们可以总结出测试人员的工作方法是:

首先,对需求进行全面深入地分析,接着去分析评审程序设计,假定每个需求的功能点开发人员的实现都是存在问题的;

同时,也假定每一个程序设计的编码实现(无论是方式还是代码写作)都是存在问题的,

然后,根据这些假定设计测试用例,最后执行这些测试用例,验证程序存在那些问题。

因此,测试人员的工作可以重点描述成:是一个运用测试的思维和各种测试理论及方法,将所测试的软件产品的每一个功能都改变成一组特定的输入和一组特定的输出一一确定对应的形式,形成测试用例,然后待开发人员提交测试后,在测试环境部署被测程序,根据测试用例进行主动测试的过程。

 

总结:

感谢每一个认真阅读我文章的人!!!

作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。

  • 25
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值