通信人家园

标题: 【原创】谈谈测试与开发  [查看完整版帖子] [打印本页]

时间:  2012-11-21 10:52
作者: shennjia     标题: 【原创】谈谈测试与开发

大环境不景气,不少朋友也在面临选择或者被迫选择。(仅就软件工程师)
有人也来问我到底是做开发还是做测试?这时一般是有选择的前提下提出来的问题。
有人也来问做测试有前途吗?这时一般是被迫选择的。似乎骨子里觉得测试就是低人一等)

面对这些虔诚的小弟小妹的问题,真的是要认真思考才能给答复啊。不然真的是容易误人子弟。良心不安。
首先我想说虽然测试开发属性上不大相同。但刻意去细化其区别不见得是件好事。
所以每次我都回答为什么不想想都是软件工程师呢?

这几年来,我似乎更觉得 好的测试工程师更有选择空间。可能是更多人更重视开发,导致测试领域高手并不像开发领域那么多。很多人都认为开发转测试是下楼梯,测试转开发是上楼梯。可我并不这么认为。语言和执行层面的东西毕竟几个月后都没啥区别。有没有正确的意识才是决定你能走多远的关键。

首先测试是个很庞大的体系,我也没有学过专门的测试理论。
结合自身经历,我想一般公司里面都有如下的几种吧:

A:单元测试,一般由开发人员自己负责,或者量太大了,才单独成立一个小组来负责。从TDD 开发模式来说,测试难度似乎要高于开发难度,友类啥的。最独立灵活,最不被人看得起,而我认为是个练习程序语言的最佳途径,起码我的编程技能主要都有此得到。如一个函数,一个类。 这个层面,你就是主宰一切,。好的UT 架构体现出一个人的编程基础能力。

B:模块测试,往往注重细致的功能测试,feature角度,或者你认为是大块UT. 很多函数,好几个类,通常是面向一个特定的进程的。规模适中。需要一定的算法能力才成设计出好的case,stub特别多。 中型测试软件支撑。至少是良好架构的,否则越做越乱。这个层面你可能是个主要的player。一些协议层面以下的算法会被很详细的测试到。

C:再往上,可能是基于特定的仿真设备。  往往涉及到多个线程之间的交互,消息层面的东西特别多。可以理解为黑盒测试了。自动化程度很高,往往需要特定的脚本,或者特定的大型测试工具支撑。这个层面一般是个平台的使用者,需要更多专注总体设计层面出发考虑问题,设计case 依赖协议,同时兼顾自家实现算法。依照特定设计模式来实现case。(小公司往往做不到这点)

D:再再往上,可能就是特定的设备了。实验室,介于后面的和前面的中间,典型的黑盒测试。需要懂协议层面的多些,设计出合格的case,需要操作设备,因为很多东西不是软件仿真的,所以自动化是个很郁闷的东西,常常人为介入的东西比较多。大公司和小公司在这点真的是没法比。


E:最后外场:说实话,这个层面跟编程没啥关系,需要做的是对设备使用熟练,参数敏感,算法场景清晰,需要会提取结果,分析结果,发现问题。驱动问题解决。因为最终功能性能ok与否,都是由这层来把关的。


介入人群而言:   能力要求高的,我认为是B,C , 重复性最强的我认为是D ,最不容易受重视的是A。 至于E没做过,不晓得。

ABCDE --> 自下而上
EDCBA --> 自上而下

如果说开发和测试在E完全没关系,那么我想在A应该是同为一体的。  V 型开发模型似乎就是这个道理吧。每个环节都有其特有的需求倾向,都有不断提升的空间。

祝愿即将离开开发岗位走向测试岗位的两位小弟小妹 在新的征程上迎接新的挑战,新的提升领域收获新的美好生活


相关阅读:
谈谈我对于测试岗位的理解

时间:  2012-11-21 11:07
作者: npfc

测试技术上升空间肯定不如开发,尤其IT业。
通信行业还好一些,测试可以成长为系统工程师。
时间:  2012-11-21 11:10
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 11:19
作者: shennjia

npfc 发表于 2012-11-21 11:07
测试技术上升空间肯定不如开发,尤其IT业。
通信行业还好一些,测试可以成长为系统工程师。

最后那句比较认可。
好几个老外系统工程师都是测试路线上成长起来的。考虑问题的时候总是思路非常开阔
时间:  2012-11-21 11:19
作者: shennjia

ALU_Then_HW 发表于 2012-11-21 11:10
越大的公司, 一般FLT越不行吧。NLT好一些吧。

不好意思哈,,FLT 和NLT 啥意思呀。。第一次听这么叫。
时间:  2012-11-21 11:23
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 11:26
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 11:31
作者: shennjia

ALU_Then_HW 发表于 2012-11-21 11:23
呵呵。。, 很多做测试根本就不会coding呀。。 对不?

如果你把手机测试里面的按按钮之类的也算进来的话确实郁闷了。

但好的测试架构,log 系统的自动分析,其编程要求还真的不比写C++ 简单。
而且测试领域所设计的好多软件思想我觉得不是开发领域能触及的。

比如那种面向feature 覆盖,基于随机,和依赖自动化的 高级集成测试,真的让我觉得5年前都盲目低估了测试对人的要求。
时间:  2012-11-21 11:32
作者: calitrean2

作为通信设备厂商来说,UT想做TDD是很难的,那意味着在UT之前就得写一大堆的文档来描述函数的名称、参数、返回值,然后coder按照此文档coding,测试按照此文档写case。事实上,真没几个公司会为UT如此兴师动众,况且开发人员自己都无法确定到底有哪几个函数。。。其次,UT的架构,基本上没有公司会从0开始自主搭建,基本都是用现成的,cpp test,mock之类的。在融入自己的源代码之前,必须把桩函数设计好,哪些桩是公共的,放在哪里;哪些桩是需要各个team自己去打的。。。

至于MT,窃以为不能简单的认为是大块的UT,实际上很多公司的MT除了功能测试之外都已经涉及性能测试。对于这一层,case的设计确实非常重要,而且case的设计也非常有难度,烂的case根本测不出什么东西。在这一层,测试框架也很重要,尤其是对于性能测试。只是对于MT来说业内还没有好用的通用框架,很多公司都是自己做测试框架,有用python的,有用perl的,有用ruby的,还有用java的,实在很无奈。。。

再往上,ST和IT,系统级了,基本是由专门的测试部门来负责(UT和MT一般由开发自己进行)。对于自动化,其实每一层测试的自动化程度都很高。

通信行业的封闭性导致了测试技术无法共享,也内也没有什么通用的测试工具和框架,导致大公司和小公司在测试上的差异相当之大。反观互联网行业,这个问题基本不存在,无论你是淘宝还是几十个人的小公司,都可以用junit,jmeter,loadrunner这些工具搞定,即使是很小的公司也可以做到大公司的测试流程和水准
时间:  2012-11-21 11:35
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 11:38
作者: calitrean2

ALU_Then_HW 发表于 2012-11-21 11:35
要看做什么测试, 还有你的background。。 会不会coding等等。。 我只能说:
80%的测试人员前景不如开发的 ...

如果你是开发转测试的,前途大大的好
时间:  2012-11-21 11:41
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 11:52
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 11:54
作者: shennjia

ALU_Then_HW 发表于 2012-11-21 11:41
现在的问题大部分的测试根本就不会写code。。, 开发转NLT,前途光明, 可以做system engineer。。

我还是觉得 把不会coding 这个看的太严重了。
如果说在学校很多人不会coding 我赞同,如果说很多人测试人员没多少机会拿到coding的任务我赞同,
但我不认为coding这个技能学不会。
参加过一些测试部门的人招人的面试,面下来别人跟我说 其实他们不担心一些coding技能,因为脚本的东西学起来比较快。现在是个人我想学校时候都学过基本编程。不管当初学的有多好多差,最主要是没有发挥的空间导致被灰尘堆满了。。

如果不会coding是基于以上的背景,我想再笨的人如果想学,3个月内应该是可以满足基本需要的。 至于架构那种层面的,我想就算你会coding 也不见得有胆量去揽那个活吧。

所以我的观点:coding不是问题。踏实好学的两,三个月内 可以达到qualified 级别。
时间:  2012-11-21 11:56
作者: shennjia

calitrean2 发表于 2012-11-21 11:32
作为通信设备厂商来说,UT想做TDD是很难的,那意味着在UT之前就得写一大堆的文档来描述函数的名称、参数、返 ...

这个比较赞同。  确实走过好几个公司,MT 层面的设计千差万别。
再往上层,涉及到测试设备的时候又变得类似了。
因为只有那么几家测试工具尝试提供大型测试设备
时间:  2012-11-21 11:56
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 11:57
作者: shennjia

shennjia 发表于 2012-11-21 11:56
这个比较赞同。  确实走过好几个公司,MT 层面的设计千差万别。
再往上层,涉及到测试设备的时候又变得类 ...

哇塞,此贴一出,不经意间从中士升级到上士 哈哈 得瑟一下。
时间:  2012-11-21 11:58
作者: calitrean2

shennjia 发表于 2012-11-21 11:56
这个比较赞同。  确实走过好几个公司,MT 层面的设计千差万别。
再往上层,涉及到测试设备的时候又变得类 ...

N的俩硕士的毕业设计就是一个TDD的自动化测试工具,叫ROBOT,除了N之外用的人不多
时间:  2012-11-21 11:58
作者: bruce_h

各有利弊吧
测试如果肯钻,上到系统工程师,前提是最好写过几年代码,否则下面开发的要跳脚骂娘了
开发的比较容易被局限在自己的一个小方块里面,很多场景并不清楚,扣细节比较多,视野有限。

所以,测试最好是从开发出来的;开发的这个只要肯动手动脑,能坐下来,基本上手没问题的
时间:  2012-11-21 12:05
作者: calitrean2

本帖最后由 calitrean2 于 2012-11-21 12:07 编辑

通信设备商们可以联合整一个MT工具,用perl,python,ruby都可以,或者用java也可以,要不就干脆基于eclipse开发一个,通过TCP/IP连测试环境,如果要在PC上做仿真的话必须支持memory dump,扩展功能通过插件添加,放在开源社区
时间:  2012-11-21 12:09
作者: calitrean2

额,貌似windriver的workbench和TI的CCS都是基于eclipse做的,TI的CCS动不动就crush
时间:  2012-11-21 12:10
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 12:29
作者: shennjia

calitrean2 发表于 2012-11-21 12:05
通信设备商们可以联合整一个MT工具,用perl,python,ruby都可以,或者用java也可以,要不就干脆基于eclipse开 ...

这种我最喜欢。  虽然Visual studio 很好用。但我还是硬着头皮逼自己尽量改成eclipse了。  摆脱商业软件的捆绑。  刹车,跑题了。

只是想感谢开源,让自己看到了很多优秀的东西。 继续讨论。
时间:  2012-11-21 13:28
作者: lazygsc

:)
时间:  2012-11-21 13:35
作者: chendbuaa

工作过3家公司, 这3家公司里面,项目经理,产品经理,系统工程师,架构师,release manager,测试出身的占多数。
时间:  2012-11-21 13:43
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 13:51
作者: kingbao21

谢谢各位的意见
时间:  2012-11-21 13:54
作者: bigliu819

好吧。我做的是测试。讲下我之前做的事情。为黑盒测试搭建平台。 这个估计都得做。但是让开发人员过来搭可能就搭不出来。
举个简单例子, 话单(CDR)
比如 我要测端到端的话单,不是说coding的人直接在后台建个数据文件,然后程序读这个数据文件生成话单这么简单。
对于系统来讲,这个系统我得设置信令接口卡,系统控制卡,业务处理卡(一般ATCA架构), 然后得搭建信令用的link,模拟信令流(不用用直接手机打一个,因为这样子系统得搭建终端到core Network一整套,通常是模拟某一接口),然后检查最后能否生成cdr,有时还得对比特殊字段(一般针对信令中)生成CDR中的字段。 一般做后端CDR coding的人应该是拿不下这个东西的。做CDR CODING的只晓得这些话单应该是其他某个进程送过来,它抓取出来就够了。 但是做协议开发的coding 人员呢,也做不好这个测试,对他来讲,他只需要把信息送给CDR 进程就够了,最后结果正确与否,他并不用关心。

就光这段工作来讲, 这个测试人员所要完成的工作量以及相应的知识面,应该就比一般的coding人要多了。这也是前面有个仁兄讲为什么经理以测试人员出身为多。 因为测试人员才回来评估完成一个任务所需的软硬件资源。
时间:  2012-11-21 14:03
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 14:17
作者: bruce_h

ALU_Then_HW 发表于 2012-11-21 12:10
again, 越是复杂的通讯设备或者solution中的unit testing的role越是尴尬。。 民工而已。。除非是coding p ...

就一砌砖的,没机会看到楼长神马样子,就是有几次跑外场,机会也少
但如果测试也是界面弄弄,报告写写,系统不熟,配置不知,脚本不会,也和Unit码农没神马两样
时间:  2012-11-21 14:20
作者: 秀才文

说说自己看法
我一直纳闷的是,在国内的众多企业中,测试的地位都不高,貌似都低开发一级,这是我一直来想不通的问题。

测试与开发,我一直喜欢用老师和学生来这这对应关系,能批卷子的,肯定比答卷子的,掌握的知识要多。
欧美为啥在现代科技发展历程中,处于领先地位,个人觉得很大的原因是他们测试测量技术远远领先我们。



时间:  2012-11-21 14:24
作者: shennjia

ALU_Then_HW 发表于 2012-11-21 14:03
测试在研发中的地位, 你还还看看公司的高层的态度吧。。

今天中午吃完饭在外面溜达的时候又有了一个新的想法。
前几天看电视说一个印染厂加大技改,投入新设备为的是降低污染,能耗,加大绿色经济的投入。
结果是更多的质量上的回报,总成本的减少。

我想谈到质量问题,有远见的公司肯定是会大力投入的。与其整天三令五声整流程,还不如加大测试方面投入。强大的测试才能客观的保证产品的质量。

如果只是图山寨速度,那我也就无语了。。老板巴不得拼起来就拿去卖钱了。
时间:  2012-11-21 14:29
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 14:30
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 14:31
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 14:32
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 14:33
作者: shennjia

本帖最后由 shennjia 于 2012-11-21 14:36 编辑
ALU_Then_HW 发表于 2012-11-21 14:29
你把概念混淆了。。 一般的测试(大牛除外)不会写code, 只是按照testing case 做具体测试。 测试完了, ...


写test case 已经是很高级的一种工作范畴了。我觉得比coding 价值高。
这就好比能写一段漂亮code的人 很多时候写的word 文档不咋地。甚至你会看到好多if 语句。

反过来,能写出好case,好文档的,我觉得其一旦要写code时候,写出来的反而逻辑不错。

时间:  2012-11-21 14:39
作者: shennjia

ALU_Then_HW 发表于 2012-11-21 14:31
哎。。 现在通讯行业只能是这样了。。 没有钱赚, 只能压缩各种开支, 包括测试成本。。 但是测试的人确实 ...

测试的等开发的发新的补丁包。
开发的等测试抓新补丁包的结果。
测试的往往被老大k,客户k,开发往往被测试骂。
如果测试的配错参数,开发的就会找到爆破口使劲埋怨。

感觉是本是同根生,相煎何太急
时间:  2012-11-21 14:41
作者: shennjia

ALU_Then_HW 发表于 2012-11-21 14:30
另外一点: 大部分测试人员测试的领域很窄的。。窄到你想想不到。。 就是一点。。 所以只是做点的测试, 永 ...

bigliu 的就很宽。

不晓得实际上倒是宽窄的比例大概多少。。至于窄到什么难以想象的地步,还想多听听
时间:  2012-11-21 15:35
作者: kutao-hill

作为一个毕业后半年开发,四年NLT测试的工程师,个人感觉coding不是问题,测试过程中去看开发人员写的代码也不是很难的事。但欠缺的是对架构的了解,比如状态机的应用。遇到一些问题还是不得不去求助于开发人员。
总之就是不是开发的,很多就是不明白,做系统工程师感觉还是得有一定的开发经验。这里的开发经验重点不在coding上,而在于软件的架构设计。
时间:  2012-11-21 15:45
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 15:48
作者: tjhwa

测试这个工作是很重要的,重视测试的公司才能出好产品,但中国公司中重视测试的并不是很多。
时间:  2012-11-21 15:54
作者: savie_lee

硬件开发难度比纯软件要大一些
时间:  2012-11-21 16:12
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 16:28
作者: 物联网—星星

不懂啊!!
时间:  2012-11-21 16:29
作者: shennjia

ALU_Then_HW 发表于 2012-11-21 16:12
研发里面, 测试是最最底层的民工。。 都不重视。。 用的基本上是新兵蛋子。。

帮人家设计一些好的能力上的上升通道嘛,再找些可能的出路方向?哪天被不爽了还可以拍屁股 挺胸走人。
时间:  2012-11-21 16:58
作者: hanangellove

不会coding的 tester拍过
时间:  2012-11-21 17:00
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 17:01
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 17:05
作者: hanangellove

ALU_Then_HW 发表于 2012-11-21 17:00
你说说看像你这样的测试人员的职业前途?

转型中~!
时间:  2012-11-21 17:13
作者: hanangellove

还得继续学习才行~!
时间:  2012-11-21 17:19
作者: bigliu819

做测试的一个比较重要任务是尽可能的在lab中模拟还原现实中的网络环境。coding 这部分东西就算是内部测试通过,你coding 看起来100倍正确,但是跑到现实环境中还是因为会有各种没有预想过的问题crash掉。。
我认为不会coding 的tester 很正常, 他就应该和用户一样,两眼一抹黑的来测试你的各种输入,看各种输出。我还担心看了你coding,做了白盒测试,全跟着你思路走,那还发现什么bug。

tester会coding,但这不是用来发现你coding 有什么问题。比如语句顺寻,死循环什么,这些你coding 人员自己应该在前期Unit Test 就应该发现完了。 而是应该站在系统功能是否能够满足用户需求,系统稳定性的角度来完成自己的工作。基于这个出发点,会不会coding根本不是问题。

另外,在遇到现场问题的时候,有经验的测试人员应该会比R&D 更快的发现问题所在,或者缩小问题的范围,从而帮助R&D去fix 问题。
时间:  2012-11-21 17:25
作者: itoktome

ALU_Then_HW 发表于 2012-11-21 17:00
你说说看像你这样的测试人员的职业前途?

真开发转测试还不太容易,好多公司你开发的去应聘测试的人家还不要呢。
时间:  2012-11-21 17:33
作者: shennjia

bigliu819 发表于 2012-11-21 17:19
做测试的一个比较重要任务是尽可能的在lab中模拟还原现实中的网络环境。coding 这部分东西就算是内部测试通 ...

很高兴有这种丰富测试经验,测试体验的人来分享一下。

希望能够更系统的总结和展示
时间:  2012-11-21 17:49
作者: 740443671

顶一个...
时间:  2012-11-21 17:53
作者: 走四方之行路难

本帖最后由 走四方之行路难 于 2012-11-21 11:54 编辑

System,design 和 I&V是研发铁三角,系统决定干什么,design去干出来,I&V的验证做出来的这个东西是个什么质量,缺了哪一个都不行。而且现在都在推Agile,在Scrum里面哪里还有System,design和I&V的title分别啊,都是SW developer了

E的工资体系目前design和I&V是一样的,system高5%。等到全面Agile以后这个5%也要取消……
时间:  2012-11-21 17:55
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 17:59
作者: key20003

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 18:11
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 18:28
作者: jookrei

不知道对于coding的定义是什么。如果指脚本开发,我认为是要成为优秀测试人员的必须能力。测试不仅要有深刻的协议理解和应用环境仿真能力,还要有大型测试环境下的数据收集和分析能力,从而反推系统实现的逻辑,这些要求一点不比开发低吧。认识的几个principle,都是测试出身或者至少长期做过系统级测试。测试根本没必要去读懂开发写的代码,而应该把重点放在需求实现的验证和总体把握产品上。
时间:  2012-11-21 18:45
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-21 19:56
作者: clementma

正在BC....
时间:  2012-11-21 20:30
作者: rj45rt

有见地
时间:  2012-11-21 20:32
作者: 走四方之行路难

ALU_Then_HW 发表于 2012-11-21 11:55
理论上是一样的。 但是实际上呢。 tester老师背黑锅。

看了你的所有回复,感觉你心里面已经形成了test不如design的结论,你全部的回复只是想让别人帮你说出来而已。呵呵,那这个帖子还有什么继续讨论下去的必要?
时间:  2012-11-21 21:04
作者: shennjia

ALU_Then_HW 发表于 2012-11-21 18:45  做那一部分都有大牛, 我们现在关注的是哪占多少的tester, 甚至这些tester不会写code!大牛没有必要讨论 ...

为什么没有必要呢?这才是讨论的真正意义所在吧。大牛不是天生的,同时我相信测试大牛绝不是开发大牛直接换马甲就行的。再者大牛不见得就没年少的。大牛的足迹与心理路程总是有借鉴价值的。希望测试大牛们能更多的现身说法 改变测试低人一等不正常理念。面对目前的形势能从领域观念上打开一扇门必然对后面可能发生在自身的变化能够多一手应对 。 这样我们讨论的过程才真的是对观者有意义呀 。 希望测试大牛们多多现身吧  bigniu 继续说说你咋个在测试这条道上走到现在呢 :)
时间:  2012-11-21 21:13
作者: shennjia

jookrei 发表于 2012-11-21 18:28  不知道对于coding的定义是什么。如果指脚本开发,我认为是要成为优秀测试人员的必须能力。测试不仅要有深刻 ...

估计是测试主力 想听听咋个成长的
时间:  2012-11-21 21:18
作者: shennjia

走四方之行路难 发表于 2012-11-21 20:32  看了你的所有回复,感觉你心里面已经形成了test不如design的结论,你全部的回复只是想让别人帮你说出来而 ...

呵呵,终于到你帮他说出来了,反正我似乎跟他杠上了。haha 。不过很感谢 alu_then_hw的讨论
时间:  2012-11-21 22:16
作者: 爻..

coder也就这么点见识了

coding这东西嘛....有人说了,找个高中生(职高)写出来的东西未必比你差,人家还主动写注释
就这么一项看看书,再实践几年就OK的技能,你觉得tester不会?笑话

高端工作里,眼界远比技能重要
作为coder,没有算法方面的特长,再没有全局的把握能力,就不要成天把架构挂在嘴边了
对于那些埋了bug,被人家测试一针见血指出问题所在,还要狡辩的coder……唉,不想说这类了

算了,你们讨论需求都没有测试陪着的coder,跟你们聊测试实在是无聊
时间:  2012-11-21 22:52
作者: 湛江陈纯斌

我是学通信的,现在已经大三了,可是对自己以后的就业方向还是很迷茫啊。听师兄师姐们说大三就要分清楚自己的就业方向了,要有所侧重,可是我到现在还不知道自己能做什么啊。
时间:  2012-11-21 22:55
作者: Motone

测试、开发……做好了都是大牛蛙
时间:  2012-11-21 23:30
作者: lewy

干码农两年发现没一个测试会码的,但福利却都一边倒向测试,测试MM依靠不对称优势完全奴役咱码农啊!
时间:  2012-11-22 04:39
作者: CQI2_0

说句实话,我不是很看好开发这个岗位,一般情况下太累,钻的领域也比较窄,而且本人除了刚开始工作的一两年时候,由于读的计院,对代码还有情节,那时候总是遗憾不能够亲自写代码。对产品实现也很困惑,那时候觉得代码或者是唯一通向本质的道路。新手嘛,对可运行的几百万行代码自然会流露出崇敬之情。

现在,鄙人做测试也4年多了,我还是比较庆幸自己进入了测试这个团队。没有写过代码,没有写过DT,UT之类的。只是搞过自动化,用C#这种简单的语言做个测试工具。当然也经常走读过开发的代码,现在觉得代码确实没法带来太大的乐趣,特别是通行领域的代码,没有复杂的数据库,没有有意思的分布式处理,欠缺了很多互联网里面很有乐趣的东西。我眼中真正优秀的开发,也不是在代码领域里面驰骋得最好的,最后还是体现在对需求和代码架构的理解上的。

我见过很多开发搞出来的Bug是对需求的理解偏差导致的,甚至有些需求本身描述得有点模糊,语文稍微好点的也能够发现里面语法的歧义点,但小部分开发会不澄清就盲目的开工完成代码了,虽然代码按照他的想法完美的实现了,但又有什么作用呢。写代码是一个职业活,但做开发还需要更多的职业素养,如果仅局限于Code,也不好出彩。

我认识一个朋友做了10多年的开发了,但代码编程考试却总过不了,在考试的时候习惯性的考虑可维护性、可测试性等等在其他人看来有点旁枝末节的东西。但这并不妨碍他成为部门普通员工(非领导)眼中的专家,能够真正的给新方案提供自己的好的有益的建议,疑难问题能够梳理出各个模块排查思路,协议滚瓜烂熟,只是不太受领导赏识,因为太较真,平时的问题也解决的太顺利,没有形成影响力(扯淡开会攻关等等)。

而作为测试需要的素养,能够快速的理解需求,结合协议能够大致猜测出代码里面可能实现的框架和流程,用例设计就不说了,有经验的测试甚至需要梳理出SE与开发相互理解可能存在的分歧点,在代码实现时可能引入的问题点,提前把这些暴露出来与SE和开发沟通澄清,防患于未然。

测试执行也不仅仅是简单的照着testcase按部就班的操作,通信系统本来就复杂,没有哪个用例是能够保证执行完了之后就没有任何问题的。当然可能是我井底观天,也许有些公司存在这种用例,希望你能够给我介绍一下经验,我也学习学习。测试执行需要培养起侦探一般敏锐的嗅觉和洞察力,每一个现象以及每一个现象之间的联系都需要快速的在脑海中过一遍。另外,如果做测试执行只想着打pass或者fail,那你就悲剧了,不去关注Bug的根因,不去了解人的什么思维过程引入的Bug,你永远也成长不起来。

对于问题定位,我看过两派人的意见,有领导要求需要自己初步定位并走读代码,甚至能够自己定位出来原因,还有些其他的领导要求出现了问题以最快的速度与开发沟通,最好能把问题单走下去,自己就解放出来能够干其他活了。我觉得都没有错,但对于我个人来说,我觉得一个问题出现之后,测试人员能够准确的描述问题现象,能够根据经验推断出具体模块的问题,当然最好在不看代码的前提下就能够大致推测出代码可能存在的问题。把这些快速的梳理清楚之后,反馈给更熟悉代码的开发定位分析,这样可能大家的效率都更高。

所以我觉得测试更轻松一些,但不是说测试就一点技术含量没有,不会Code也不是什么大事,玄乎一点比喻,测试是建立的一种人生观,用它来审视人生中的过往以及所有的琐事,而开发就是亲力亲为的办这些事的人。你是愿意办事呢还是愿意做评判?至于Code,我们组原来就有两个女生进公司不到一年,从来没有接触过代码,刚开始代码走读就能够发现不少功能性的问题,不是所有代码都会有复杂的数据结构让人感到晦涩难懂,相反,大部分公司应该都是要求代码越简洁越好,话说不管是C和Java,能有什么代码是超出我们的世界观的。

我的意见是,做一个扑在某个模块上无法自拔的开发,不如做一个测试,更广泛的接触各种特性和各种系统,测试也具备这个条件,没有哪个公司规定做测试只能发现本领域的问题的,问题驱动你会了解到很多意想不到的东西。
时间:  2012-11-22 04:52
作者: CQI2_0

CQI2_0 发表于 2012-11-22 04:39
说句实话,我不是很看好开发这个岗位,一般情况下太累,钻的领域也比较窄,而且本人除了刚开始工作的一两年 ...

其实开发和测试岗位你如果兴趣浓厚都能够发现很多乐趣,也会学习到比别人更多的知识。只是觉得测试轻松些,付出的代价也会小些,性价比高些,呵呵。
时间:  2012-11-22 08:38
作者: NGN通信人

学习一下  大家点评
时间:  2012-11-22 08:41
作者: shennjia

爻.. 发表于 2012-11-21 22:16  coder也就这么点见识了   coding这东西嘛....有人说了,找个高中生(职高)写出来的东西未必比你差,人家还 ...

有地点很有共鸣:分析需求时测试的意见不被重视,很难在后面验证 然后开发出来的东西就直接出去裸奔了。开发领域其实也是菜鸟云集地。就是因为把握不了大局,反而顶着架构的虚名照着别人的需求文档直译。试问有多少开发是参与需求讨论然后自己设计然后实现再验证呢
时间:  2012-11-22 08:53
作者: shennjia

lewy 发表于 2012-11-21 23:30  干码农两年发现没一个测试会码的,但福利却都一边倒向测试,测试MM依靠不对称优势完全奴役咱码农啊!

其实我最近想这么多测试一个很重要的原因除了之前小弟小妹来问我之外还在想:前些年经济繁荣,泡沫鼓起,那么多公司为了抢市场拼进度 急功近利。重心自然在开发。现如今经济减速,市场疲软。新投资减少,众多企业加强开源节流,开流难自然重心转向节流。在陈货上挖潜力,提高原有质量。所以我的观点是后面这段时间测试驱动更有活力
时间:  2012-11-22 09:04
作者: shennjia

CQI2_0 发表于 2012-11-22 04:52  其实开发和测试岗位你如果兴趣浓厚都能够发现很多乐趣,也会学习到比别人更多的知识。只是觉得测试轻松些 ...

cqi2_0 真给力,直接预示双流的ack 1b都是true :)   要是能和这样的测试组合成敏捷团队真是幸事
时间:  2012-11-22 09:13
作者: mybaby3746

太搞笑了,

一个是杀猪的和一个做豆腐的,讨论谁更有前途????
时间:  2012-11-22 10:07
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-22 10:24
作者: mummywho

作为一个刚毕业就被分到测试部的员工,浅谈测试.
     工作一段时间后,新员工集体培训的时候,当老师讲到测试规程的时候,让大家发言讨论时,新进入的开发和测试就闹开了,有个做开发的,说测试什么都不懂,整天就IM找他问这问那,每次他都要花费大量的时候和测试讨论,难道测试自己就不会看文档吗。有个气盛的测试怒了,说开发写的东西乱,看不懂,做的东西也烂。后来老师也调侃了,说以前开发和测试是死对头,两边互相影响着自己的考核。当时学生们相互之间也调侃,说开发干久了,看什么都是好的,测试干久了,看什么都是毛病。

做测试,优势如下:
      1.与人沟通的能力。因为是测试整个服务器,里面的问题牵涉到许多模块,所以时常要联系相关模块的人,时间久了,认识的开发也就多了。现场有问题,老大们把你叫过去,开会,时间长了,和老大们也混个脸熟。出差支持现场,和办事处和厂家的人多接触,自己的交流能力也有所提高。
        2.对事物的思维判断能力。做测试的,我是指做黑盒测试的,判断有没有故障,是从用户的角度出发,制定全面的测试,这要求测试人员要对服务器有全面的了解,小到各个功能,大到整体服务性能。我工作的时候遇到过一些开发,比如一个功能有引起用户掉线的可能,和他说,他不认可,他说开发文档上就这么要求的,我只要实现这个功能就好了。做测试的看问题会从用户角度出发,看问题发散不局限。
        3.写文档的能力。大家也许会笑了,写文档应该是文员干的活(我以前也这么认为的)。写好文档其实是十分重要的。对己,写好测试文档,记录下相应的数据,今后测试的时候再和先前的测试测试数据相比能发现不少问题。写好文档,别人接收你的任务的时,上手方便了许多。还有测试有时要写开局,升级文档,写好文档现场工程人员也方便许多。
        4.任务安排能力。测试一般干的活较多,较杂。要定期完成任务,必定要有一套时间规划方法。
        5.网络知识和动手能力。做测试的要时常搭环境,服务器的操作系统,版本安装,机房的组网的布线和配置都要自己弄,时间长了,动手能力和相关知识有所提高,如果以后去运营商机房,相关设备的搭建轻车熟路了。
                       
测试的也有许多本身的缺陷
     1.因为开发和测试是分离的,是先开发后测试在修改的过程。测试人员遇到问题只能问开发,自己看不到代码,不知道里面的处理流程。做事的时候比较被动。
     2.工作中不会涉及到代码,写代码的能力没有提高。现在想换个工作都要求开发经验。在一些单位,测试就是按按仪器按钮没技术含量,只有大公司才有专门的测试部,换工作会受到限制。
    3.测试工作有点杂,时间长了比较烦。
    4.测试转开发开始有点痛苦,切身体会。搞自动化测试,也要写代码的,刚开始还是有许多东西要学的。
时间:  2012-11-22 10:31
作者: 最亮的光

研发觉得自己有水平,测试觉得自己有眼界....

要说底子是研发的人好,我毕业那会儿除去去美国的牛人相对成绩好一些的作研发,一般一些的作测试.

但工作会改变一个人,以我的经验.测试工程师的危机感更强.他们常常会努力寻求横向发展..
我们公司测试的现在做什么的都有,各个部门都有他们的人,做人圆滑,而且很抱团,和上层关系较好.

研发的,从经理到工程师,都比较安逸,喜欢偷个懒.和上层的关系也比较糟糕.会为了技术上的一些事情和产品部门冲突.


时间:  2012-11-22 10:33
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-22 10:51
作者: shennjia

mybaby3746 发表于 2012-11-22 09:13
太搞笑了,

一个是杀猪的和一个做豆腐的,讨论谁更有前途????

真的有这么大区别吗?
时间:  2012-11-22 10:56
作者: shennjia

mummywho 发表于 2012-11-22 10:24
作为一个刚毕业就被分到测试部的员工,浅谈测试.
     工作一段时间后,新员工集体培训的时候,当老师讲到 ...

这才是测试人应用的风范?
如果适时转行去做一段时间开发,就更容易成为高级的复合人才了。  你不想成为核心都难啊。

核心成员除了能20%关键时候攻克难点外,70%的时间能够协调人员,把控风险。前者让一些没有深厚积淀的人感到敬畏,但后者更是一些性格孤僻的高手所不可能达到的。因为我觉得后者更多考验一个人的个性。前者似乎更多体现一个时间上的问题
时间:  2012-11-22 11:11
作者: hanangellove

bigliu819 发表于 2012-11-21 17:19
做测试的一个比较重要任务是尽可能的在lab中模拟还原现实中的网络环境。coding 这部分东西就算是内部测试通 ...

测试的时候作为一个用户的角度去使用新的软件版本,我觉得这样测试起来更有感觉。
当然,如果想要深入去挖掘产品的BUG,还需要一定的产品架构知识和懂得各个模块的规范。

时间:  2012-11-22 11:15
作者: key20003

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-22 11:17
作者: hanangellove

爻.. 发表于 2012-11-21 22:16
coder也就这么点见识了

coding这东西嘛....有人说了,找个高中生(职高)写出来的东西未必比你差,人家还 ...

你说的这个问题、还真遇到过。 我们发现了设计不合理的地方(我作为用户的角度),但是开发就说:这个就是这么设计的。OK,好吧~!有时候确实挺无奈的,仅仅有时候。
时间:  2012-11-22 11:25
作者: kutao-hill

ALU_Then_HW 发表于 2012-11-21 18:45
做那一部分都有大牛, 我们现在关注的是哪占多少的tester, 甚至这些tester不会写code!大牛没有必要讨论 ...

我做了四年network level testing,总结下来就是,tester里头做得好的基本上都是四个方面比较优秀,一个是对标准的理解能力,一个是对客户需求的理解能力,还有就是对代码和软件架构的理解能力。

我组里十来个tester,能看懂代码的不超过两个。
时间:  2012-11-22 11:27
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-22 11:29
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-22 11:31
作者: shennjia

key20003 发表于 2012-11-22 11:15
不过北欧公司就是这样,我也在E呆过,这样是有问题的,尽管我认为design和I&V都是混饭吃,但强度和难度肯 ...

还得看地区吧。。。  要不要备注(北京?上海?   )  当然本地比较还是有价值的。
欧洲价格高,也还是要看相对价格的。你要考虑本地生活,那还是很贵的。
好比同是一瓶可乐,那要15rmb,这边可能就是2.5 rmb。 不考虑价格因素,直接数值其实没多大意思。
时间:  2012-11-22 11:33
作者: shennjia

kutao-hill 发表于 2012-11-22 11:25
我做了四年network level testing,总结下来就是,tester里头做得好的基本上都是四个方面比较优秀,一个是 ...

都是能力高端要求。

面试一般开发人员年度要求就是 C、C++ 2~3年。。  
时间:  2012-11-22 11:34
作者: ALU_Then_HW

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2012-11-22 11:40
作者: kutao-hill

ALU_Then_HW 发表于 2012-11-22 11:29
en, tester里面要做的出色, 必须要懂得些code, 或则多code
理解的透彻。。否则的话, 就是民工了。。 ...

其实很多开发人员对code理解力也很一般,都是照着design直接实现,也不做太多整体上的考量。经常在代码里看到几千行的if else。。。
时间:  2012-11-22 12:36
作者: 爱立信_No1

行行出状元,但测试的状元也只能混到design里面做二流货色,tester转design努力5年最多Top20,Design转测试仨月轻松Top3
以上只是技术工种对比,其他比比没有什么意义,比如design,tester,system都有那种动嘴不干活的职位,靠关系,写写文档开开会,这个就没法比了,跟各自老板有关系。
如果算投入产出比的话,只要自己觉得happy就好,工作不分贵贱,只有喜欢和不喜欢,钱的目的也只是叫你暂时快乐一下。
时间:  2012-11-22 12:40
作者: 未知用户

本帖最后由 未知用户 于 2012-11-22 12:57 编辑

NLT  --- Network Level TesterFLT  --- 没有找到,猜是Functional level Tester


请了解的帮忙解释一下。
谢谢。

时间:  2012-11-22 12:43
作者: bigliu819

shennjia 发表于 2012-11-21 21:04
为什么没有必要呢?这才是讨论的真正意义所在吧。大牛不是天生的,同时我相信测试大牛绝不是开发大牛直接 ...

你真是。。不停的再引导话题方向。我觉得在辩论赛里,你肯定是主席的位置。
我这个测试,其实也轮换了很多岗位。 售后,售前,lab都干过。售后,售前的工作和客户交流比较多。在Lab里测试又干了好几年。因此对产品的前期客户需求,前期测试,后期测试,售后都所有理解。。

一个是看客户需求文档(但是可能有些公司这块很缺乏),一个看规范。我认为规范比较重要。因为对于产品来说,各个公司的内部实现都不一样,但是输出接口上都需要与规范保持一致(尤其是通信产品),老实话,这种你看好了,出去找工作已经握了一把底牌。
也会看一些UML 的书籍,帮助自己建模。开始模块化的对待一个系统结构,或者来讲,对自己的撰写的test case 更有顺序性和层次性。

工作中因为厌烦重复的手工操作,自己有意识的开始使用脚本工具。但是这种coding是为了更好的完成测试的工作。
时间:  2012-11-22 12:46
作者: shennjia

ALU_Then_HW 发表于 2012-11-22 11:34
这是同一个城市的工资水平, 不同城市的有可比性吗?! 不要断章取义!

hehe ,,不好意思,见笑了。确实有点吃惊,差异居然这么大。。看来有目标了。
时间:  2012-11-22 12:47
作者: 未知用户

bigliu819 发表于 2012-11-21 13:54
好吧。我做的是测试。讲下我之前做的事情。为黑盒测试搭建平台。 这个估计都得做。但是让开发人员过来搭可能 ...

有道理。
时间:  2012-11-22 12:51
作者: shennjia

bigliu819 发表于 2012-11-22 12:43
你真是。。不停的再引导话题方向。我觉得在辩论赛里,你肯定是主席的位置。
我这个测试,其实也轮换了很 ...

谢谢支持,这也是论坛跟办公室会议室的区别吧。
大家一定都有感受,公开场合谈心得,谈经验,多有少人真的愿意站出来说呢。
又有多少人真的会真心去体会你呢。
人海中遇到个有共同语言的,自然也是一种幸福啦。





通信人家园 (https://www.txrjy.com/) Powered by C114