测试之路:向左走还是向右走

2012-07-18  熊志男 

                  [如需转载,请在转载时注明出处,并保证本文的完整性] 

714参加的中国软件测试大会的北京测试沙龙上,根据演讲嘉宾段念和柴阿峰的分享,我总结了两个不同的观点:软件测试之路向左走还是向右走?

    回想下自己的测试经历和从同行那里听到的,现在有一大部分的测试工程师的工作主要工作内容是集中在功能测试、黑盒测试上。无论是段念所提倡的代码审查、单元测试、高度自动化,还是阿峰所分享的社会化测试、业务测试、用户体验测试等,现在都还做得很不够。       

前一种观点就是“测试工程师要程序员化”。

这也是为什么目前各个公司对于测试工程师的要求越来越高的缘故。过度的依赖于功能测试阶段来发现缺陷,就好象一个没有稳固根基的大厦,要从外部加固一样。常常付出高成本、高风险的代价。我们做功能测试的同行,常常为是否遗漏bug而心惊胆战。解决这个问题就需要从内部开始控制软件质量。也印证了我们测试的准则“缺陷越早发现越好”。

    测试工作在项目中处于下游,我们很多人都这样抱怨过“代码写这么烂,这功能是给人用的吗?”。这都是由于上游没有很好的把控质量,导致缺陷一级级遗漏下来,甚至放大。

测试自动化的好处众所周知,可是实现起来不易。

有些在自动测试过程中遇到的问题是无法通过外部工具来解决的,正如段念所举的例子“一个无法测试的报表程序的左侧树形结构控件,是通过任何自动测试工具都无法从外部来定位的,原因是开发程序的时候没有考虑到可测试性,没有留测试接口”。

    还有就是UI自动测试,尤其是互联网行业,维护自动测试脚本的速度总跟不上总在变动的界面。如果换一种思路,把系统剥离开来,实现分层的自动测试,通过底层的高度自动测试覆盖率来弥补UI层的适度自动测试。通过Google的测试例子也可知道,即使是UI界面,也可以通过调用接口来测试,而不是通过触发表面的元素来执行动作。

     Google所做的就是尽力把一切自动化,自动持续集成、部署、自动测试

    那么从上面这些可以看出,为了提高软件质量,我们测试工程师应该参与的有单元测试、代码审查、自动测试、持续集成。

后一种观点是“程序员是反社会的,测试工程师要更加社会化”。

“二进制”是由于计算机的发明而产生的,同样程序员的思维并不一定适合大众的思维。一个生动的例子“如果我们的老板是程序员,开发和设计者是程序员,测试者也是程序员,那么软件的最终用户也就是一种-----那些该死的程序员!”。

    为什么我们苦心设计的种种功能,也许在一个普通人眼里会一文不值,而大众用户们真正关心的东西却总是很难满足。如果每个用户都要去学习程序员的思维才能够正常使用软件,那将是多么为难他们。往往现在很多人使用软件的时候,连说明书都不看。举个例子“一个从来没用过电脑的老人,给他个PC,然后给他个iPad,那么肯定会在很短时间内学会使用iPad并抛弃另一个”。

而我们测试工程师每天都在做什么呢?我们习惯了文档,对着需求文档、功能说明书或者代码来进行设计并执行测试。那么有很多东西是文档上没有写的,比如时间因素‘千年、闰年、闰月、闰秒、美国的夏时制等’,还有用户的操作喜好。我们过多的时间来研究文档,研究代码,将会漏测掉更宝贵的东西。

自动化测试正是要替代人去做反社会的事情,而测试工程师要做更加符合社会性的测试,黑盒测试和手工测试者需要了解更多的社会化知识,并成长为社会化专家。

两种看似对立的观点,正好代表了测试工程师未来的两个发展方向。


[内容包含对段念老师和柴阿峰老师的部分 PPT内容引用] 

 

564°/5607 人阅读/4 条评论 发表评论

付民  2012-07-19

两个方向,两个概念....但责任是相同的....呵呵


熊志男  2012-07-19

付民: 两个方向,两个概念....但责任是相同的....呵呵


王艺  2012-07-25

我可不可以理解为 测试人员到底是要更重视技术知识还是更重视业务知识


熊志男  2012-07-25

王艺: 我可不可以理解为 测试人员到底是要更重视技术知识还是更重视业务知识
应该是广义上的“业务”,不只是需求文档和功能说明书里写的。


登录 后发表评论