请选择行业
请选择职位
请选择省份
请选择城市

软件测试人员的修炼——测试思想成熟度模型

时间: 2013-05-02 14:24   作者: lantuzty   点击次数: 
 

  上周在一次小组会议上,我问到大家做测试的目的是什么?刚才的实习生小姑娘回答说,是为了发现BUG。继续问,测试之后发现了什么?回答说,发现我们产品的BUG满天飞。然后再问测试的目的是什么呢?她说,是为了发现关键的BUG。非常好,能够发现影响到产品质量的关键BUG,就初步具备了软件测试人的素质。在我的测试思想成熟度模型中,定义为”测试一段“。

  从测试目的出发,总结了测试人员的思想成熟度模型。从一段到七段,由初级到高级。

  ● 测试一段:发现BUG,发现有价值的关键的BUG。

  ● 测试二段:定位BUG,积极主动的定位BUG。

  ● 测试三段:解决BUG或提出解决方案。

  ● 测试四段:总结和分享

  ● 测试五段:思考和预防

  ● 测试六段:规范流程

  ● 测试七段:成本意识

  (以后要画个图)

  这是一个真实的例子,我们在一次迭代中的例行回归测试时,场景准备(略),数据准备(略),执行(略)。重点说验收测试结果,首先观察系统页面展示,程序运行正常无告警。其次查看日志,无各级erro报告。然后查看数据库中相关业务表,结果也是对的,没有发现异常。以上各项指标已符合预期输出,有些测试人员到这里,就认为这个CASE通过了。如果真是这样的话,我们就错失机会了。还好实际上,我们的测试人员是足够优秀的,在写测试报告的过程中,从程序输出的日志里发现了异常,刚刚测试的程序,走了另外一个分支(国外的业务逻辑,国内是不使用的),而我们的业务逻辑完全没有被覆盖到。所以之前的测试是无效的,需重新验证。事后想想,如果走错版本分支这件事不被及时发现的话,版本直接发布到现场,后果是不堪设想的。我们知道,我们发现了一个严重的BUG,如果不修复,接下来的一系列测试CASE将无法展开(都是基于国内分支的)。所以说测试不但是一个正明的过程,更是一个正伪的过程。正伪过程中,通过逆向思维能够发现更重要的问题。至此,我们完成了测试人员的第一级修炼,到达“测试一段”。

  可是程序为什么会走错分支呢?查看了DB中相于流程分支的配置,正常的。程序的版本,正常的。咨询了相应的开发,国内逻辑没有变,与国外是完全不同的,日志里会打印版本信息。同时,又是一个棘手的BUG,如何定位是一个挑战。

  谁来定位问题,对此存在很多争论,有些测试人员认为定位BUG是开发的事,测试只管发现并提交BUG。那些执相反意见的人,比如开发人员或对自己有较高要求的测试人员,认为这样说是不负责的,等等,然后争论。其实没必要,从思维的角度观察,如果一个测试人员认为定位BUG完全是开发人员的负责的话,我们可以发现客观的原因是,这名测试人员的思想成熟度不够高,还停留在测试一段的水平。世界观决定方法论。

  有了主动定位BUG的思想,就具有了向上的阶梯。定位问题的能力涉及非常广泛和深奥远超软件工程的范围,单说软件产品,定位问题涉及到软件运行的平台环境(主机、数据库、中间件、网络等),程序(业务程序、框架程序、外围接口),业务数据,配置等。上面的这个事例中,我们最终发现是DB中一个基础配置项(决定业务分支)的确被修改过,之后又被改回正确的值,当我们查看的时候,DB中的配置是OK的。而程序在运行时直接使用的配置是加载在专门的共享内存容器中的(从DB加载到共享内存中),被改掉之后做了刷新,恢复之后,没有做刷新的动作。所以,导致了业务流程全部走到一个无效的分支。问题终于定位了,测试人员主动探寻并定准BUG所在的修炼,使我们成为测试二段。

  问题终于定位了。有人说,这下好了,可以松一口气了。解决问题的分工,我们公司通常由开发解决程序问题,QA解决配置和数据问题。例子中,这个BUG是由配置引起的,所以QA改一下配置然后刷新就解决了。事实上我们也是这么做的。在接下来的测试过程中,陆续测出了很多BUG,并及时提交给开发修复了代码,最终发布了一个比较稳定的版本。

  可是,问题真的解决了么?

  事情没有这么简单。两周后,下一个的迭代中,我们再次发现了类似的BUG,同样的配置又被修改了。于是问题有了新的引申,需要重新定位和更全面的解决方案。

  一翻努力之后,问题浮出水面了。另外一个产品线,在这个环境中部署了一套自动化的CASE,在准备场景的时候对基础配置重新做了初始化,这个配置对他们产品线没有影响,只是为了方便把配置表做了全表替换。到此,真正的问题找到了。之后,双方做在一起共同梳理了基础配置。使得双方的测试都可以正常执行,不再相互影响。

  找到问题真正所在,并从根源上解决,做到了这一点,那么恭喜你,可以晋升为测试三段了。

  接下来的修炼历程,从认知理论出发,解决了一个问题,并不带表我们真正懂了,掌握一门知识离不开总结和分享。写个邮件,将以上对问题的分析和处理过程分享给团队其他成员或其他团队,让大家共勉,避免类似问题再次发生。再回到解决问题的角度来思考,总结和分享的过程,实现了从解决单点问题,发展到了解决多点问题,甚至继续扩展到一个面。这是一个很大进步。

  今天先写到这里,后面还有很多在酝酿,将慢慢呈现给各位朋友。

版权声明:本文出自 lantuzty 的51Testing软件测试博客:http://www.51testing.com/?262983

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

打印本页 | 加入收藏

上一篇:一个软件测试工程师的成长日记(连载一)     下一篇:我的软件测试成长之路

关闭  
主要城市: 北京 上海 杭州 广州 南京 武汉 长沙
全部城市: