51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: jackei
打印 上一主题 下一主题

软件测试工程师试题发布版

[复制链接]

该用户从未签到

61#
发表于 2005-4-6 18:44:54 | 只看该作者
好吧,跟你细说细说。

当你学C的时候,应该是先看书,然后写程序,当然,看完一本书都没写过一个程序的人也有。道理地球人都知道,看书,但不能只看书。

但软件工程和编程不一样,一个语言要学习它的语法才能写出程序,要知道编译器是怎么处理这个语言的,所以,看书就很重要,不知道语法是根本写不出来的。软件工程不一样,不知道任何这方面的理论也带得好项目,实践经验是很重要的,不否认理论的正面作用,但只是辅助,像我前面举的例子,不知道重构的理论不知道daily build的理论,在测试环节上不知道冒烟的理论时我也知道该在什么时候做什么事情,这个经验可以让我在其他的团队其他的情况中判断什么出了问题该怎么解决。

为什么不提倡新接触的人一上来就把理论当成圣经,可能是因为理论繁杂,多而空,内容拗口玄虚,又解决不了问题,会误导,花时间精力学这些不如多实践,多观察,多想。(其实我的回帖一直在说我的经验,可似乎大伙没看出来,这里就强调一下,我从在公司观察与我相干或不相干的项目、一定的实践、仔细分析得到的结果中获益很多。)关于这个影子已经说了很多而且很清楚了,多看看他的回帖,很有好处的。(当我第一次发现他的回帖,在一片指责声中我知道以后每天来这有好东西看了,可惜这里的朋友不欢迎他,他的发言不多。我每次登录搜完自己回过的贴后就搜他回过的贴,嘿嘿。)

如果我是想应付老板而对其本身无任何兴趣认为它增加不了我的什么,我也想以最快的速度做成,但如果我是想增加自己的砝码,让自己做有所得,说句大话同时也为行业做自己的贡献,那我不会想着速成,我情愿踏踏实实慢慢学慢慢做。难道这里那么多想速成的测试行业朋友都只是为了应付老板?太辜负jackei等热心斑竹了吧。知识是要学习,我强调的是,速成的心态要不得。

“快速——你的编程也是看书学来的吧?不会是自己发明的吧”
/// 这是在回应“快速”吗?这两个字可强调的都是快、速啊。

卡内基梅隆鼓捣出CMM的时候被捧成圣经,现在却被人遗弃,又有CMMI接替,XP也凑热闹。如果你认为印在书上的权威说的就是实用的可用的,那我还跟你说什么呢?我说的那个问题存不存在自己去想吧。

软件工程的提出似乎是源于美国军方系统研发的需要,对高可靠性的严格要求和高成本的近乎无限的投入(时间、人、财等)使方法保证安全可靠是可行的并且有效的。但对于现在的普遍软件,没有那么多的投入,也没有那么变态的要求,理论是否管用可用实用是需要实践者琢磨,而不是校园里的学生对着课本能体会到的。既然你也知道理论是有适用范围的,那为什么又说理论是不该拒绝的呢?这不矛盾吗?有些时候,理论就要被拒绝。强调这个是因为这里需要“过正”来“矫枉”了。

最后,我没想自己的话上升为什么理论,理论需要“绚”,而我的话很“土”。我一直都在说我的经验,难道没看出来吗?遗憾...
回复 支持 反对

使用道具 举报

该用户从未签到

62#
发表于 2005-4-6 18:55:39 | 只看该作者

上面的细说细说是和Nio兄的交流 :)

rinthesky朋友,缺什么补什么,怎么补,业余时间补。
我看不出从论坛里的那么多堆积概念的帖子里能学到什么,难道堆了一堆的什么标准,什么规范就有帮助吗?这难道不是泛泛吗?看来解毒不容易啊。 如果我比你痴多些个经验的话,其实影子也谈到了他的经验,那些个东西咋一看哇塞宝贝啊,时间长了就知道那玩意没用。
经验这个东西,你能从里面得到的其实是有限的,譬如我有一朋友行业里摸打多年还出过软工方面的书,可我知道除非天天跟着他做项目,否则只从msn的聊天里能借鉴的东西是很有限很有限的,还是要靠自己去体会去琢磨。这个行业,发展的迅速变化的迅速导致了三言两语很难传递什么经验,不可能像武侠小说里的,写一本没几个字的口诀册,就把绝世武功传下去了。
回复 支持 反对

使用道具 举报

该用户从未签到

63#
发表于 2005-4-6 18:57:39 | 只看该作者
为什么我和影子都用了玄虚这个词。
国内的软件行业很浮,喜欢玩弄概念吹嘘,软件、软件工程是需要踏实地去做去总结的。
回复 支持 反对

使用道具 举报

该用户从未签到

64#
发表于 2005-4-6 19:15:39 | 只看该作者
纠改一句话

原:理论是否管用可用实用是需要实践者琢磨,而不是校园里的学生对着课本能体会到的。

现:理论是否管用可用实用或这么运用是需要实践者琢磨,而不是校园里的学生对着课本能体会到的。
回复 支持 反对

使用道具 举报

该用户从未签到

65#
 楼主| 发表于 2005-4-6 22:36:21 | 只看该作者
Originally posted by black_tulip at 2005-4-6 13:43:
我觉得奇怪,如果因为对方说话的方式方法语气让自己觉得不爽而不愿意考虑去接受对方的帮助,反倒要提供帮助的人想想自己的方法而不是等待接受帮助的人反省自己的接受力。开个玩笑,就好象“你要帮我,但是你要好 ...


http://bbs.51testing.com/viewthr ... &highlight=

http://bbs.51testing.com/viewthr ... &highlight=

http://bbs.51testing.com/viewthr ... &highlight=

http://bbs.51testing.com/viewthr ... &highlight=

找了几篇言辞激烈的,倒是想请教一下应该如何培养自己的接受能力。
回复 支持 反对

使用道具 举报

该用户从未签到

66#
 楼主| 发表于 2005-4-6 22:39:48 | 只看该作者
Originally posted by black_tulip at 2005-4-6 15:49:
在俺知道“冒烟测试”这个名词前,曾看过一群高人讨论daily build,很精彩,收获很大。后来公司的配置管理遇到严重问题,也讨论过对策,采取过一些措施,实践中的体会更能增加理解和自己的看法。

自己的看法和 ...


我想如果您在此之前就接触了“冒烟测试”的理论和一些具体方法,然后根据这些方法去尝试,然后再改进,是否会比自己重新摸索,重新发明轮子更有效呢?
回复 支持 反对

使用道具 举报

该用户从未签到

67#
 楼主| 发表于 2005-4-6 22:51:12 | 只看该作者
Originally posted by black_tulip at 2005-4-6 18:44:
好吧,跟你细说细说。

当你学C的时候,应该是先看书,然后写程序,当然,看完一本书都没写过一个程序的人也有。道理地球人都知道,看书,但不能只看书。

但软件工程和编程不一样,一个语言要学习它的语法才 ...


学而不思则罔,思而不学则殆。
实践是检验真理的唯一标准。
理论具有指导实践的作用。
我想上面这些似乎已经不用争论了。理论和实践是不能绝对的进行剥离,然后说哪个重要的。把理论当做圣经固然不对,我也绝对赞同应该一边学习理论,一边在工作中实践,并发展出自己的一些更实际的方法。但是忽视理论,再重新去探索和发明前人的知识不是也很浪费吗?如果一个人连基本的软件开发过程都搞不清楚,找工作会不会成问题呢?不管大学课程中的那本《软件工程》知识是否老旧,但始终说明软件工程的一些基础理论知识还是重要的。站在不同的理论高度看待问题,思路会有很大的不同。我觉得如果有别人现成的经验可以参考的话,我会优先选择使用别人的经验。
回复 支持 反对

使用道具 举报

该用户从未签到

68#
 楼主| 发表于 2005-4-6 22:56:45 | 只看该作者
另外,我觉得进入测试行业也是一步步逐渐成长的,并不是每个人一入行就去测试USB或者IDE驱动的。我觉得black_tulip 说的也可以说明另一个问题,那就是行业知识的学习。如果测试的是行业应用,那么行业背景知识也是很重要的。就像 “做ide驱动测试的搞不清dma”,如果测试ATM连银行卡都没有见过,不是也很可笑吗?
回复 支持 反对

使用道具 举报

该用户从未签到

69#
 楼主| 发表于 2005-4-6 23:04:26 | 只看该作者
Originally posted by black_tulip at 2005-4-6 18:55:
rinthesky朋友,缺什么补什么,怎么补,业余时间补。
我看不出从论坛里的那么多堆积概念的帖子里能学到什么,难道堆了一堆的什么标准,什么规范就有帮助吗?这难道不是泛泛吗?看来解毒不容易啊。 如果我比你 ...


既然说到武侠小说,那就看看武侠小说。小说中不是谁拿到一本秘籍都可以练成的,要讲究修为的。这就好像看软件工程方面的资料,也不是谁都可以一下领会全部的意思的。人的学习是一个渐近的螺旋上升的过程,不同阶段对同一段话都可能产生不同的理解。哪一次是对的?恐怕每次都是依据当时的知识和经验认为是对的。
经验最终还是要上升为理论知识的。不知道black_tulip兄的公司有没有一个规范的开发过程?这个开发过程是否是贵公司的成员自己一点点发明出来的?而没有参考以往的软件工程思想?我相信这些知识就像black_tulip兄说的那样,是要自己去总结和观察、思考的。但是总是在前人留下的理论和经验的基础上进行的吧?

[ Last edited by jackei on 2005-4-6 at 23:05 ]
回复 支持 反对

使用道具 举报

该用户从未签到

70#
 楼主| 发表于 2005-4-6 23:18:11 | 只看该作者
试题中的第一题是要了解应聘者对软件测试工作的认识。
第二和第三题是要了解应聘者是否留意过自己以往工作的企业的具体细节,也要了解一下应聘者以往的工作中是否有更好的方法可以借鉴的。
第四题是要了解应聘者以往的具体工作情况,以及所擅长的部分是否同职位要求相一致。
第五题是要了解应聘者对基础知识的了解情况。
第六题本身就是一个陷阱。

影子杀手,我向你请教,你说我“故作自谦的八股客套话实在让人听着难受”;我不回答,你说我“不正面讨论问题”;我对你的问题做出解释,你说我是“冠冕堂皇”的“为自己开脱”。真不知道这个世界要变成什么样才能如了你的心愿。你一直以来都是这么偏激的看待人和事的吗?总是把别人使劲往坏了想?

争论归争论,我承认从这次争论中我自己也有不小的收获,至少知道了自己同高手们的技术差距,但是我不敢恭维影子杀手对待人和事情的态度。就这么多了。个人感觉说的这么多都应该要比影子杀手给别人回复的那些更容易接受一些,看到的人就不用专门练习接受能力了。

[ Last edited by jackei on 2005-4-6 at 23:27 ]
回复 支持 反对

使用道具 举报

该用户从未签到

71#
发表于 2005-4-7 09:52:15 | 只看该作者
如果我们这儿的每个人都能一直从事测试这一行业,我想要不了多久(五年或者十年),我们都会有将自已的心得写出来,留给后来者参考,不是么?

出现这么多争论不是什么坏事,我个人认为。我们也不必因为言辞的问题,紧抓不放,重要的是我们听到了不同的声音,不是么?

我一直有这么一种想法,历来我们都希望将不同产品的测试行为归为一类,但随着软件产品的多样化,不同产品的测试存在着很大的差异性,甚至于成为完全不同的测试行为。在这样的情况下,以往的测试经验理论有多少可以继续实用?但我们又将如何面对这样的现实呢?以往的经验理论是否适用现今的测试呢?特别是中国目前的测试现状?
另一个问题就是在这样一种大环境下,以往的经验理论是否还有让类似我这样的后来者去学习参考的必要?
我们一直在做无谓的争论,可否解决我心中的疑团先?
回复 支持 反对

使用道具 举报

该用户从未签到

72#
发表于 2005-4-7 10:19:33 | 只看该作者
1)jackei给的几个链接,前三个我都打不开。

2)要说言辞激烈,几个月来我在这里发现的最激烈的发言就数jackei的红红粗粗的一段了。如果随即影子和我也用更红更粗的回答回应,估计要群殴了呵呵。

3)如果jackei要用轮子这个词,虽然我不太明白其意思,但已没有了对jackei的敬意,虽然在红红粗粗之后这敬意已然大减。但我猜你会说你不在意或担当不起之类。

4)我没有说发明,我强调的是在有了实践经验后再去领会拗口的理论会比先强记硬背理论再到实践里去用效果要更好,特指的是测试,和刚入行的朋友。请把对方的发言用心领会而不要断章臆断,这是真正的尊重。

5)这个帖子从3楼到9楼都是如影子所说的一片赞扬,如果不是他的一个回帖,估计到100回帖也都是一样的内容,如同这里的很多精华贴和置顶贴一样。
这里还有很多题目很大很空让人无法回答的问题。为什么新人在这里只敢问一些不清不楚大而空洞的问题?而不敢对别人的问题甚至自己的问题说说自己的看法?大概和一些高手总拿玄虚的理论吓唬人有关。说点解决实际问题的吧。

6)对,背景知识。如影子所说,大家从事的是软件测试,可这里的很多新入行的朋友太缺乏软件知识,计算机知识。不抓紧补这个,却把测试名词解释当做当务之急,当作具体的实在的,把最基本的计算机系统知识当作泛泛的,这是对自己不负责任。

7)我提到武侠小说,是因rinthesky朋友希望能从有经验的人那传递来很多东西让自己少走弯路。还是要说这不同C语言的学习,可以告诉你要怎样怎样不要怎样怎样,这个东西是不可能像锦囊一样写下来碰到问题打开就能用的。所谓的经验就是一种遇到任何问题都能在最短的时间内找到最合适的解决方法的能力。急不得,自己慢慢的学,从实践中学而不是搬着书学。

8)为什么会多次强调这个,几个月在这里看下来,发现这个作为专业的软件测试、软件质量论坛,有些八股,总以一些空洞的理论来回答新人,以书本上看来的不变应对实际情况的万变。所以我说以“过正”来“矫枉”。

9)我没有说理论不对不好不要学,我希望这里更多的讨论软件工程实践中的问题和怎样解决,而不是从书里copy,从gooooogle里copy来一些堆砌来回答问题。
回复 支持 反对

使用道具 举报

该用户从未签到

73#
发表于 2005-4-7 10:25:25 | 只看该作者
用我的浅见回答一下Nio朋友。假设你认识一个大牛,你感觉到他的货真价实,他也乐于把自己的一些想法告诉你,你听了,甚至记了(这种事我就干过),而且你也知道他用这些东西成功地挽救了快死的项目,或成功地完成了难度很大的项目,而你在自己的过程碰到问题时,到自己的记录里去找,找合适的经验,拿来一用,可能会有效,但没那么有效,也很可能根本行不通。
所以我强调这个东西更多的靠自己积累。弯路一定是要做的,还要多走,趁年轻多走。
回复 支持 反对

使用道具 举报

该用户从未签到

74#
发表于 2005-4-7 10:26:56 | 只看该作者
弯路一定是要 走 的...   又错字了,抱歉。
回复 支持 反对

使用道具 举报

该用户从未签到

75#
发表于 2005-4-7 11:00:23 | 只看该作者
Originally posted by black_tulip at 2005-4-6 10:25 AM:
但是你做的那些,对于你成为真正的测试合格者是没太大帮助的,如果你能从计算机系统结构、操作系统、数据结构这三个方面入手好好下点功夫,对做测试是大有帮助的。在我接触的人里面,测试高手都是这方面功底深厚 ...

如何才算功底深厚?
回复 支持 反对

使用道具 举报

该用户从未签到

76#
发表于 2005-4-7 11:08:59 | 只看该作者
Originally posted by 影子杀手 at 2005-3-21 09:31 AM:
看了,满篇都是大道理,玄虚的概念,须知测试的知识是从实践中得来的,不是背书本背出来的。
哪家公司给你出这样的面试题,就可以打定主意不要去了。

你的手下真辛苦啊,一边学东西一边挨骂:|
回复 支持 反对

使用道具 举报

该用户从未签到

77#
发表于 2005-4-7 11:14:25 | 只看该作者
无聊至极,我看了一小部分都没有心情看下去了。大家为了一个共同的目标,但是怎么能这样无聊的急诊争论下去呢。有些人是高手,就请你的知识传授给我们,如果你不原意的话,我们也只能望洋兴吧了;如果是亲手,就不要花太多的时间看这些无聊的争论了。
注:我也是个新手。
回复 支持 反对

使用道具 举报

该用户从未签到

78#
发表于 2005-4-7 12:01:28 | 只看该作者
To:   black_tulip
或许是我得表达能力不够好,没能将我得意思明确得让你理解,这里我就和你细说一下吧:
1.做为一个软件测试工程师本身应该具备什么样得素质?
答:当然有很多方面,其中得重点是必须能掌握软件方面得所有基本知识.
试想一个不懂C语言得人你让他去做一个由c开发得软件得ut测试,这可能吗?
2.说到规范得问题.
为什么要规范,应该有什么样得规范,合理得正确得规范难到不重要吗?这里不需要我和你解释规范得必要性和重要性了吧.
3.经验!
其实我们刚入行得新人就是需要前人得经验.你举到武侠小说得例子,那我们就说武侠小说,试问一本武功秘笈是怎么出来得?难道是凭空想象出来得?天上掉下来得?我想一本武功秘笈得由来也是出自多少前人得苦心钻研,走火入魔,经过许多挫折,困难而来得吧!其实我现在得目的就是想向你们这些有经验得前人讨教这本武功秘笈,难不成你们经过了那么多挫折后还希望后人继续走你们走过得路一步步走上来!难道你们就不能总结出一些捷径!来让我们这些后人乘乘凉?恕我直言,如果你是一个资深得软件测试工程师,相信你一定能总结出一些好得良方,秘笈.如果你不能总结出得话,那是不是说明你还停留在你得前人脚步上并没有任何进步!
回复 支持 反对

使用道具 举报

该用户从未签到

79#
发表于 2005-4-7 12:20:20 | 只看该作者
引用版主一句话"既然说到武侠小说,那就看看武侠小说。小说中不是谁拿到一本秘籍都可以练成的,要讲究修为的。"这句话翻译过来就是做软件测试这一行并不是人人都能做得也是要有点基础得人才能做得!
我现在甚至开始怀疑版主和black_tulip是不是认为那些刚踏入软件测试领域得人就是对软件工程没有一点常识得人!人家说看不起软件测试这个行当觉得没有技术含量,现在似乎是你们这些资深得软件测试专家在贬低你们自己,在贬低软件测试这个行当!请不要摆出一副老者得姿态,请你们务实!
回复 支持 反对

使用道具 举报

该用户从未签到

80#
发表于 2005-4-7 12:56:29 | 只看该作者
同意楼上的 我看这帖子 看的真累。。。。。。。。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-1 21:30 , Processed in 0.075234 second(s), 21 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表