当前位置:首页 > 教育资讯

清华大学教授: 软件测试已经走入一个误区——“非代码不可”!

有没有发现现在招聘测试工程师的JD,基本都涉及开发内容了?比如:

是不是感觉不会写代码?就干不了测试了?

事实上,“面试要求造火箭,日常工作拧螺丝”之类的事情比比皆是。

即使日常工作只是“点点点”的验证工作,面试时候也得笔试,在纸上写个排序算法什么的。

软件测试已经走入一个误区——“非代码不可”

换言之,软件测试目前一个趋势,测试工程师什么角色都必须写代码。

写代码,增强自动化程度,让计算机完成重复动作,本身无可厚非。但是一旦过了,变成“必须写代码”,就是当前软件行业的一个误区。

“非代码不可”的误区形成,有几个原因:

测试不受重视

这个话题相信会引起众多测试人的共鸣

请回答几个问题:

“公司里研发和测试人员的配比是多少?”

“软件研发周期是多久?多少时间留给测试?”

“软件上线后出现问题,第一个被责问的是哪个团队?”

几个问题,基本就可以男默女泪了。

测试团队必须体现出自己的技术性、专业性?还要量化地表现出来。

全面学习研发,跟着写代码,就是一个很直接的想法。

于是,很多测试人放下业务研究,拿起了IDE开始写代码…

测试团队负责人不懂测试

这也是一个现实问题,不少的测试团队实际负责人是R&D的领导,或者测试经理向R&D负责人汇报。

R&D的领导,99%是纯研发出身,也是不争的事实。

IT技术发展,分工越来越细化,研发和测试,本来就是两个不同的方向。

这就难免出现外行管内行的问题。

如果从纯研发人员眼光来看,代码量是衡量工作的一个标准,但是用这个标准要求、衡量测试的工作,则以偏概全了。

多数人,只能理解自己懂得东西,否则就套用到自己理解的范围内。

过分强调自动化

自动化测试,是一个好的方向,替代了很多人工劳动,尤其在回归测试方面,尤为重要!

但是,如果觉得“自动化测试”能解决一切问题,那么就言过其实了

全面推广自动化测试,意味着相关的测试人员必须写代码。

- 怎么判断测试的业务覆盖率?

- 怎么判断异常用例的范围足够?

- 多少缺陷是自动化测试用例发现的?多少是人工测试发现的?

几个问题的答案,不言自明。

如果没有好的软件架构,自动化测试,尤其是UI自动化测试,绝对是疲于应付各种修改

铺开自动化测试前提是,有个好的测试架构师规划。

综上所述

走出“非代码不可”的误区,软件测试应该回归本质:保证质量。

在测试这个角度,软件测试的本质是质量保证,一切能够提高质量的工作都是测试人员应该涉猎的,代码仅仅是其中一部分

误区的存在,导致很多测试人员在为了代码而学习代码,并没有解决质量问题,甚至不懂业务。

更可怕的是不少测试人员既不关心业务,也不关心技术,而是整天琢磨着下一步转型成什么角色的工作。

就软件测试领域而言,接口测试、安全测试、性能分析……,很多工作真的不需要具体写代码。

人的精力是有限的,全面开花,往往意味着“十八般武艺样样稀松”。最终会面临35岁问题。

随着敏捷跟DevTestOps体系的流行,测试行业也开始慢慢发展,各种概念开始流行,测试人员对于未来的发展可能会迷茫,这个是可以理解的,但还是要有独立思考的能力,不要总是人云亦云,相信什么名人效应。

迷惘的时候,不妨思考一下事情的本质是什么,找到本质,也就有了方向。

本文来自网络,不代表教育资讯立场,转载请注明出处。