|
小子目前工作月于,接触软件测试也有2年多乐,现在在某公司实习中
今日初来51TEST 留点东西记录下也分享下我对软件测试的看法
在写东西之前看了很多关于软件测试的帖子,不免有些感慨,
现在已经将软件测试的某些步骤分化初来比如按照测试种类就有黑盒白盒
近年已经有灰盒测试的说法了,按照测试方法又有很多其他的分类
然而看了许多始终没有看见我个人觉得最关键的一个测试,业务流程测试
不知道为什么,这个步骤的测试在网上接触到得人心里处于很尴尬的地位,
勉强挂在功能测试的门下。
然而,其实不然,最近在做一个保险平台的测试,举一个简单的列子把
对于一个退保了的人员是否还能再次退保呢,在系统中确实可以实现这个操作,
而这部算是功能缺陷,因为客户自己也没有明确要求,但是如果不去考虑相关业务的流程,
那么我们做出来的软件就有很大的通用性,和潜在危险性
目前参与的项目类似于外包项目,我相信在软件业务流程中将该款软件定义的更为有针对性
在测试时多在用户的角度去考虑该有的流程,画出业务流程图,理清自己的思路
测试的时候从业务流程出发,这点与场景分析法有点相像,以一条基线为主,引发多条备选流
而在发现缺陷时,不能简单的给缺陷定义,目前很多中小型公司没有一个完整的开发体系,
在估算时间时只计算了开发时间和测试时间有的甚至只计算了开发时间并没有将测试时间算进去
而一旦业务测试中出现了Bug对于整个软件系统需要变更的地方就很多,在测试后做修复的时候
就已经相当于需要重新设计了,这时我们作为测试人员就不得不考虑下开发人员的时间和项目所剩余的时间
有些缺陷我们可以自己判断其威胁程度,在提交测试缺陷时应该将严重紧急的放在最前,如果有的缺陷不是那么重要
在走业务流程基线时能走通,而其备选流又多是用户的错误操作,这时我们就应该考虑下这个缺陷需不需要修改
如果要改那么能不能放在后期维护或者优化时再来修改了
以上是个人对测试的一点看法,心里觉得我们做测试不能单纯的将自己当做一个技术人员
对于软件必然有管理员和用户的区别,而我们在思考时应多站在使用者的角度也就是不能单纯的依赖技术
更重要的是思维模式。
如果开发人员是杀敌的刀,那么我们测试人员就是刀舞过得痕迹,相对于实际的技术,抽象的概念性更为重要 |
|