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

Posted 软件测试呀

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了清华大学教授:软件测试已经走入一个误区——“非代码不可”相关的知识,希望对你有一定的参考价值。

有没有发现现在招聘测试工程师的JD,基本都涉及开发内容了?比如:
是不是感觉不会写代码?就干不了测试了?

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

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

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

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

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

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

测试不受重视

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

请回答几个问题:

“公司里研发和测试人员的配比是多少?”
“软件研发周期是多久?多少时间留给测试?”
“软件上线后出现问题,第一个被责问的是哪个团队?”

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

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

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

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

测试团队负责人不懂测试

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

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

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

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

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

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

过分强调自动化

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

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

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

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

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

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

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

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

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

综上所述

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

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

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

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

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

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

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

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

房子要一层一层盖,知识要一点一点学。大家在学习过程中要好基础,多上手实操,话不多说,这里狠狠上一次干货!我熬夜整理好的各阶段(功能、接口、自动化、性能、测开)技能学习资料+实操讲解,非常适合私下里学习,比找资料自学高效多了,分享给你们。

领取关 w/x/g/z/h:软件测试小dao

敲字不易,如果此文章对你有帮助的话,点个赞收个藏来个关注,给作者一个鼓励。也方便你下次能够快速查找。

以上是关于清华大学教授:软件测试已经走入一个误区——“非代码不可”的主要内容,如果未能解决你的问题,请参考以下文章

清华自动化系教授张长水:图像识别有风险

谷歌修改Chrome源码的“黑/白名单”术语;清华教授称要警惕开源软件的“科技侵略”

关于大学中软件工程课程的开设问题——不要把实践性科学当作理论性学科来教授...

关于大学中软件工程课程的开设问题——不要把实践性科学当作理论性学科来教授...

关于大学中软件工程课程的开设问题——不要把实践性科学当作理论性学科来教授...

大学生用 AI 写论文:次次拿 A,还赚 100 美元,大学教授:反作弊软件查不出来怎么办?...