软件架构师 vs 资深测试工程师

发表于:2011-1-19 11:51  作者:董杰   来源:51Testing软件测试网原创

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试 测试职业发展 测试工程师 架构师

  也许你是一个头衔为资深测试工程师,高级测试工程师,测试工程师的测试从业人员,但在本文中什么头衔并不重要,重要的是你是否希望在自动化测试以外的领域不断提升自己的测试功力,有一天能与软件架构师一起畅谈产品架构设计,模块设计,甚至能辅导年轻的软件架构师如何设计一个有高可靠性的高质量架构。本文起这个标题不只是“吸引眼球”,同时也是告诉大家测试是从需求阶段就已开始,资深测试工程师从需求阶段开始就已与软件架构师一起合作,一起PK。

  软件架构师与我们测试有啥关联吗?我的观点是:软件架构师与资深测试工程师大部分的IT知识是相通的,从其中一个微观角度看:当软件的架构被设计出来后,程序员需要用编程语言来实现设计逻辑,而测试员需要用测试语言(testcase等)来不断验证实现的质量和驱动软件进行设计改进,当然我们tester也会用到一些自动化测试的编程语言。而在软件架构被设计出来前,测试人员与软件架构师是可以一起合作分工的,测试人员一样可以在需求澄清中与开发人员一起工作,在架构设计阶段一起讨论最终选择的技术框架,讨论如何让架构可支撑起多种需求,特别是如何设计才能满足可靠性和性能等质量强相关的需求。如果测试人员经验比软件架构师经验更丰富,你甚至可以影响和指导软件架构师对架构的某些设计做出很大的重构,给软件架构师提供某些设计方案也是可以的。

  可为什么国内很少有测试人员参与产品的架构设计?有人会说:“测试人员能力和经验少呗”。我的观点与你一样:“说的对”。的确是这个原因,导致这个现状的主要原因有4个:

  1、工作经验少了:产品架构设计人员往往有3-5年以上的工程化项目经验,而测试人员呢--可能才毕业,或只工作了一年,或是做测试管理很久了,或是主要精力放在了自动化和工具实现上,对商业产品的架构设计关注投入时间不够,对产品设计没有和软件架构师一样吃透。结果在架构设计阶段,明显测试人员的工程化经验比开发架构人员少,那么你又怎么能与开发一起完全平起平坐,甚至自己都觉得在需求和架构设计阶段,自己可发挥的作用太少了,还是想早点回去搞自动化脚本,心里来着实在些。但反过来如果一个项目组在需求和架构阶段,是这样一个组织结构:软件架构师只做软件开发5年,且第一次独立承担商业化的整产品设计;资深测试工程师是一个一直在技术一线工作了8年,且经历了多个不同架构的产品工程化的全过程(见多识广)。那么资深测试工程师不但能与这个年轻的软件架构师一起在需求和架构阶段工作,保障产品的可靠性设计及架构的质量属性,更能辅导软件架构师做正确的事,牵引他把架构设计从质量角度考虑的更全面些,更长久些,减少他架构推翻重来的风险。

  ……………………

  查看全文请点击下载:http://www.51testing.com/html/02/n-227802.html

  遗憾的是很多测试朋友,包括计算机科班出生的测试人员也都止步于毕业前计算机基础知识的认知,在从事测试后就不再继续深入学习计算机基础知识,认为那是开发人员的事。可恰好相反,我认为:“测试人员反而比开发人员更需要补充全面的计算机基础知识(含理论知识)”。因为我们做测试工作,特别是做测试分析设计工作就是一个把产品架构疱丁解牛的过程,你没有足够的基础知识框架,用什么工具来分解“这头牛身上的不同器官呢?”开发人员把一部分精力放在了编程实现的工具及语言熟悉上,这时测试人员正好可以利用这段时间来不断补充计算机基础知识。只有有了众多的计算机基础知识你才能知道如何来评估和验证被测产品的质量,建立起系统地产品质量评估体系,以及在需求和架构阶段(不需要精通编程语法)才能与软件架构师用计算机基础知识PK。对于不同行业的测试人员(科班和非科班),我可以给大家一些学习建议,针对不同的被测产品不断补充自己的计算机基础知识。如果被测产品是JAVA开发出来的,至少再好好把面向对象编程、TCP/IP知识、操作系统知识、数据库知识温习温习;如果被测产品是C++语言开发的,除了学习JAVA同学的课程外,数据结构也是要再温习的并了解C语言开发常犯的错误。 无论是什么项目的测试,操作系统知识都是一切的核心,因为它几乎融入了计算机的主要基础知识,任何软件架构的设计都会围绕和使用着操作系统的知识及其中的设计思想来开展的。如果一个来应聘测试的毕业生,他能对操作系统的基础知识有着全面深刻的理解,难道学一门脚本语言,掌握2-3种测试工具会对他是个难题吗?我相信未来他在日常测试中对bug的根因认识深度,以及对开发设计文档理解的效率上都会是不错的,能有机会成长为系统级的测试工程师。

  3、缺少一个好的平台,缺少大型复杂项目经历:这个是机遇问题,但却是一个非常重要的客观因素。 如果你有机会参与2个代码几百万级,开发人员超过百人的项目,并且有机会学习产品的架构设计文档,那你是幸运的,因为你有了量变到质变的原始积累了,但有运气不代表你就一定会获得质的提升,还需要自己努力把实现业务流程的设计全搞明白,最佳检验你把设计流程搞明白的方法就是--灰盒测试分析与设计,你基于模块的设计流程开发出了原来纯从用户场景分析没有开发出的用例,那说明你真理解了该模块的软件设计了(通常在这个活动过程中,你会发现原来的软件设计居然还有这么多的问题,我还可以发现软件设计的问题啊)。

  ……

  查看全文请点击下载:http://www.51testing.com/html/02/n-227802.html

  版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。


评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2020, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道