看了忍无可忍!
看到这里就忍无可忍?最近听到一些对测试人员的评价，大致列一下：
1，测试人员测试效率低。开发5分钟改完的问题，他测1周，真不知道在测什么。
2，测试人员都稀里糊涂的，解释问题原因都听不懂，那怎么测啊？
3，测试人员懒。不去琢磨问题，不去想测试方法。
4，测试人员程式化，往坏里说是走形式。就知道做一些花里胡哨表面文章，真正要的东西做不出来。
5，测试人员没压力，发生任何问题都跟他们无关。一点责任都不担。
其实，本人也是做测试出身的，可以说没写过1行程序，典型的黑盒测试作了6年。
最近由于工作需要，由测试转向用户支持。
在现在的工作中，经常跟开发、测试和用户之间打交道，产生了很多新体会。
上面的评价是从别人那里听到的，但我本人也感到确实有这些问题存在。
出自对测试的关心，也非常想知道如何改善这个状态，提出这个问题。
希望大家能经验共享。谢谢！
以上是本人在另一个论坛看到的,不过是真是假,还不知道,但看了内心点郁闷!
欢迎大家再说一下!
难道做测试就这么差吗?
如果说程序员好,那我做测试也差不到哪里去! 切肤之痛，深有同感，切身体会。
项目组接一个项目，项目叫什么？不知道，
项目需求所要求的功能？ 不知道，项目进展程度？不知道。
那个模块谁负责？不知道。
只知道：“这个你尽快测试！”
这些是我们经常遇到的问题! 很同意上面那位仁兄的看法!
现在在小弟已经换环境,
公司也很重视测试,
如果做领导的能力不错,
做小的很想跟着他干,
如果看真起来比自己还要差的,那..........
现在很多大型的公司都在增强测试部,
这么中国的测试前途是一片光明的!
在此大家都一起努力!
为中国的软件事业更进一步而努力! 是呀是呀，看来到处都有这个问题呀，做测试的就是被人看扁了，很郁闷，我们公司测试和前台一个档次：（ 难怪,他现在不是测试人员了.情有可原!........TMD 一个测试部负责人给总经理的一封信
**总：
本来很想面对面地与您聊一下测试部成立以来遇到的一些问题、现状、还有未来的发展，我怕一谈到我们的测试部，我可能就会有情绪。因为我对测试部投入了一腔热血，也付出了我全部的精力，但目前的测试部将要走的走，离
的离，如果全部走了，留下来“服役”最长的也超过不了一年，我面对现状，倍感凄楚！
不仅仅是一个***的离职让我有此感慨，是这种现象逼得我不得不去反思。测试部为什么留不住人？我为测试部做了些什么？测试部要不要留住人？为什么要？如果需要留住人，我们该如何去做？与其他公司比我们的测试哪些
做得好，而哪些又有不足，是什么原因导致的？今后的测试部该走向何方？
A：测试部为什么留不住人？
1、 对测试了解的人较少。目前国内相关人士有95％以上的人对测试这个行业还处理不了解的状态（包括当初我自已），这种不了解表现在“测试人员技术素质低、测试比开发要低一个档次、测试只是东点点、西碰碰的活…
…”，但现实又何尝不是如此？！我不得不承认目前国内的情况与此相差无几。网上的BBS还有一些热血青年在高喊“我们要翻身做主人，我们要与开发平起平座！”的论调，我看过心想：要实现这种想法，还必须要有漫长的
路要走。首先是观念的改变，公司全体都要有充分的认识。从人员的任用标准，开发、测试的投入比例开始考虑；再者就是测试从业人员自身专业素养，必须要掌握世界先进的测试管理工具及自动化测试工具。只有这样，才能与
之平起平座。
2、 测试部工作负荷较重。现在我们公司存在***123、***Pro、***Net等版本，还区分简繁体、中英文，***Pro一直以来都在不断地加新功能，不断地反复测试，加上还要写手册，支援一些培训任务
、制作演示数据。
3、 薪资待遇问题。目前的薪资制度很难找到或留住优秀人才，一般从没经验到测试部，一年学成后不管调到那一个部门，或者另找工作，待遇可能都比呆在测试部要好，这种情况大多数人都愿意离开。
4、 学习机会。当初进来对BKD可能有新鲜感，但一年后，对大部分功能都会比较熟悉，对个人而言就没有更多的激情。
5、 大环境因素。远在北仑，想学点东西还真有点困难。
B：测试部要不要留住人？为什么要？
1、 我们的软件发布之后存在一些无法预知的BUG，不能说全是测试部的责任，但有的责任却不可以推辞。有时看到客户反映的一些问题，很想冲着测试负责人指责一顿，但静下来想，他才来几个月这种深层次的问题叫他如
何能找出来。心想，如果是老员工去负责可能就不会存在此问题了。
2、 老员工的存在能够凭着自已的经验去带领新人成长，并能抽出身来研究新的测试方法及技术，对测试部的实力的提高有帮助，实际上就是产品质量保证的重要条件。
3、 一个部门都是新秀，无法建立起组织层次，让谁去做小组负责人，其他人都不会服。
C：如果需要留住人，我们该如何去做？
1、 我自已要加强新知识的吸纳、传授，人员的管理；
2、 减少工作负荷。
3、 力所能及的提供一些培训机会。
4、 在薪资制度，或者人员异动制度有所改善。
D：我为测试部做了些什么？
1、 说句心里话做测试也是我当初无奈地一种选择（当初的无奈也是我对测试不了解的一中表现），但我负责了测试之后，在各个方面存在很多不足，但一心一意、尽心尽力地想把他做好。不断地从网上、书本学习软件测试方
法，与网友交流，也了解了许多自动化测试工具。现在测试部所有的成员都能够对测试有个很清楚的认识。
2、 培训了多名实施顾问及服务人员。
3、 2000年是我起步的一年，2001年是我技术成长的一年，2002年是我管理进步的一年。
E：与其他公司比我们的测试哪些做得好，而哪些又有不足，是什么原因导致的？
1、 黑盒测试做得较好，对商业逻辑的理解能力强。
2、 人员的凝聚力强，都敢于担当重任。
3、 对白盒测试未曾涉及。
4、 对自动化测试只停留在探索阶段。
5、 测试用例做得不太好。
6、 没有全面掌握、使用各种测试方法。
7、 对微软提供功能，而我们软件又会使用到该功能的知识了解的少。
F：今后的测试部该走向何方？
1、 测试部为纯技术部门，所有的商业逻辑等知识只要能看懂文档即可，商业逻辑是否正确应该在需求阶段就应该定义下来，而不是靠测试部来发现，因为改需求的成本极高。
2、 从黑盒向黑盒加白盒，再转向白盒方向，这就要求所有的测试人员必须掌据源代码读写的能力。
3、 一部分人必须掌握自动化测试的技术，以便提高工作效率。
可能占用了您的很多时间，但事关到测试部的未来，我不想看一个架构完善的开发部旁边是一个弱不禁风的测试部，这样的开发处的效能也会大打折扣，我们产品的质量也会受影响，我不认为产品质量是测试部测出来的，但测试
也是保证质量的手段之一。
唠叨至此！ 软件测试的现实和理想
来 源： 中国计算机报
“从我在微软工作的经历来看，软件测试绝对不是开发活动完成后的收尾工作，很多大型的开发项目，测试会占据项目周期一半以上的时间。以IE4.0为例，代码开发时间为6个月，而稳定程序花去了8个月的时间。”前微软亚洲研究院博士、软件测试专家陈宏刚谈道。从投入的资金和人力物力来看，测试、使产品稳定和修改花去的时间可能占到80%。
还处在婴儿期
软件测试之所以发展相对缓慢，一个原因是做研究和做开发的人交流的机会相对少。只有做大型系统工程的人才会对测试提出较高的要求，重要性才能显现出来，而做研究和教学的人没有大型系统工程案例，所以造成了测试理论研究的发展缺乏充实的基础材料。真正做大型系统开发的工程师，又没有时间将第一手的测试经验变成系统的理论。
“在美国，佛罗里达州和华盛顿州分别有一所大学开设软件测试课程，其他有正规课程的学校不是很多。软件测试正停留在没有学科系统、没有系统教育的阶段。虽然已经有学校开设了这门课程，但是使用的教学案例，多半是单机软件，还谈不上系统的理论。”陈宏刚博士介绍说。
高素质的“杂牌军”
由于企业对测试人才有着迫切的需要，因此，只好自己培养测试人才队伍。例如微软公司，对不同的产品制定测试规范，开设一些课程，通过讲座的形式对测试技术人员进行培训，但是也还未形成系统的理论。
即使在微软，测试队伍是典型的“杂牌军”，没有科班，没有统一的专业，更多的是具有丰富的经验和不同行业背景的员工，例如具有语言学、数学、物理学、计算机、工程、管理等学科等背景的员工。但是，这不是说随便什么人都可以做测试工作，陈宏刚工作过的那个试验室，20个人中有7个博士。可见，虽然测试不是一个专门的学科，但是，这个部门对于一个成熟的软件企业又是至关重要的部门。
认识需再提高
IBM和微软公司属于领先的大公司，对测试的认识也经历了一个过程。开始的时候，也是开发人员兼职做测试，就像今天国内一些较小规模的软件企业。但是，后来的结果表明，花在软件修补上面的费用太高，以至于远远超出了所能够允许的范围。这个时候，增加测试队伍的规模，提高测试队伍的素质，提高测试队伍的待遇和受重视的程度是更加划算的。
还有一个问题是，很多工程师不愿意做测试，认为是一种打下手的工作，没有前途，这也是国内比较大软件企业面临的问题。所以，企业从上到下普遍自觉和不自觉地只重视技术，不重视质量，后果是产品在市场上竞争力不高，产品售后维护和服务费用偏高。
巨大反差
微软的开发工程师与测试工程师的比例是1∶2，国内一般公司是6∶1。而且，致命的问题是没有哪个机构专门培养测试工程师。这个矛盾提示我们，在中国不能等到实际的需求和人力资源矛盾十分尖锐的时候，再谈培养问题；也不能等到产品质量成为产业阻碍的时候再来提高软件业的测试水平。测试工作不能靠手工劳动来完成，更多的情况是要使用工具软件和编写测试程序来完成，培养全面的测试专业人才是项任重道远的工作。 同感！一个软件n多bug，上头催着集成个系统出来，说是“我要给客户”，今天搞不定，别想回去，我晕。bug多得差不多不能正常使用，这难道是测试的错…… 支持一下，这些都应该是以后改进测试工作流程和测试人员工作环境的启示 1，开发和数据有任何变更都应该第一时间通知测试，便于及时检查出问题和留底
2，测试接手一个完整的项目时，应该立即划分出项目的最主要的功能（对用户而言最重要的功能）做出列表，如果在列表中的功能在客户机器上出现程序，数据的错误，责任由测试承担。
3，对测试必须承担的责任设定奖金。
4，定义各种功能测试的最短时间，做出企业内部标准。 以上各位网友都说得有道理,我非常赞同!
以下是别人发表的,说得不错,
其中里面有一些是我想说的!
我贴出来给大家看!
以前自己做测试的时候，还没有太多这样的体会。
现在转到做支持，由于平时不断要跟开发和测试要东西，就比较出来了：
跟开发要进度、计划；或者问题的说明，能够很快响应和反馈；
跟测试要，可以说，一般没什么反馈。
此外，有不少问题，据说是解决了，但反过来问测试是如何解决的、怎样测试的，往往说不清楚。
所以，从这些方面，直观上的感觉是测试跟开发之间沟通极差。
这方面觉得开发和测试两方都有问题，当然也跟公司的大环境有关。
但是，单从测试这方面，我从支持的角度感到：
1，不能主动去跟开发沟通，了解问题本质和解决方法，导致测试再走弯路。
这就是说，为什么开发很简单的改了一个问题，一到测试就要测好久。
理论上来讲，测试时间越长就测得越彻底。但关键是市场不允许。用户等着呢！眼看用户无法正常工作造成了损失，叫着要退货。而测试却总是“没有两周测不出来”的回答给拖着，能不让人上火么？
我个人认为测试的弹性应该很大。如果从开发修改的关键点入手测试的话，不应该总是花很长的时间。
2，为了有效的验证修改的结果，希望用户提供有效数据。
本来，这是一个好办法。让用户提供有效数据，能大大减少测试的盲目性。 但是，用户能提供的，只是他们日常工作中的数据。这些数据是否针对某个问题，用户是无法作这个判断的。所有的分析和有效数据的抽取，还应该是测试与开发的任务。
我每次收到来自测试这方面的要求都头疼。按说这个有效数据抽取的工作我也不是不能做，而是实在不应该我来做。
3，感到测试对测试中的软件产品的行业应用情况不了解。
我支持的虽然是个项目，但实际上这套东西属于公司的产品之一，公司在此行业已经有多年的经验。但是，感到测试对这个行业的应用情况不了解，至少不熟练。导致问题出现之后无法很快的制作有效的测试用例。
这方面我觉得跟公司的制度有极大关系。
4，测试很少仔细阅读需求
很多需求中很清楚地要求，问起来测试，都不够肯定。
这个项目的前期版本的需求，好像很散乱，没有给过测试。这个就暂时不提了。
我开始作这个项目的支持后，所有的后续的需求，我都整理过给了开发和测试两方。但是，对于这些需求的具体要求是什么，问起测试，往往还是不能肯定。
这方面是我觉得很头痛的地方。为什么有了文档也不好好去看和去理解？
等等，还有一些琐碎的体会。
muse21问我做支持的感受，
我这个支持相对是比较特殊的，因为我所支持的项目，它的开发团队并不是我自己的公司，而是另一家公司。所以我最大的感受是后方的开发管理（当然要包括测试）不合理的时候，种种弊端就在用户的前方体现出来了。
如果用户属于那种有软件开发经验的话，他们会提出很多尖刻的问题。而并不是有了问题就能使后方的开发管理得以改进的。原因很简单，现在开发团队还是处于盈利（至少是不亏）的状态，他们还没有被逼到非要改革才能生存的状态。
还有，大家提到不少关于对测试的偏见，测试的待遇方面的问题。
目前在国内的软件企业，这方面的偏见，和待遇的差别，我觉得这个短期内无法改变，能有些改善就很不错了。虽然大环境如此，小环境下，应该如何提高测试的积极性？如何带他们认识问题的解决方式？等等……思考中，头痛！
[ Last edited by QA_BAY on 2004-11-18 at 20:50 ] >1,不能主动去跟开发沟通，了解问题本质和解决方法，导致测试再走弯路。
我们都快磨破嘴皮子了，文档翻个稀烂也找不到，只好去看例子、分析。有些问题属于中间地带，几不管的更是被推来推去，最终只能找领导仲裁了。
>2，为了有效的验证修改的结果，希望用户提供有效数据。
我们项目组一般数据都是提供给开发组或是前期调研的人员，测试组要的时候竟然说客户要求保密，呵呵。
>3，感到测试对测试中的软件产品的行业应用情况不了解。
这一点的确是这样的，其实开发组有很多机会和行业部门打交道，但是他们从来都不把信息反馈给测试组。想知道的东西没人告诉你，没人会想到要告诉你。领导说：问啊！问的时候，得到的是：做出来你们就知道了。可恶！
>4，测试很少仔细阅读需求
我们的需求要是你来整理就好了，我们组的人往往都是对照最终产品以及开发人员写的只言片语再加上一遍遍的问而得来的信息重新整理。
大多数开发人员写的东西就是操作说明“点击什么，删除什么”，根本不是用户手册也不是什么需求文档，让人无法从中得到很有用的东西，写出来的，都是显而易见的，其实这种文档没有也罢。
总而言之，缺少一个规范且信息透明的流程，缺少一个能让项目组所有成员获取到应该获取到的信息的一种机制。
曾经，正在做的这个项目开始的时候没有测试组介入，那叫一个乱哪，各组负责人极力让测试组接管，接管之初大家对bug的修改热情还是很高涨的，可是现在n多bug提出来了，却又无人过问，虱子多了不咬人？和Moly的疑问不同的，我想知道：开发人员怎么了？
--------------------------------------------------------------------------------
有同感!
在我上班前,我一个在一家比较有名气的软件公司做测试的朋友,早就听她"唠叨",说他们公司根本不重视测试,很瞧不起她们.晕~我们公司还好吧,总共做测试的就我和另外一个女生,我们俩和开发人员还算相处融洽.说不上看不起什么的. 测试和开发之间是有区别的。从劳动强度上说，正规测试过程的劳动强度不一定比开发人员来得低。在国内开发人员受重视是因为他们是生产者，产出软件产品，而软件测试人员的工作很大程度上依赖固有的软件产品，并且工作的效果不一定是可见的－－一些项目经理可能认为：开发人员在前期设计和编码时，只要足够小心就可以避免大多数的BUG。所以从成本来看，有没有测试人员或者只是交付用户进行测试就足够应付了。但是无形中，又产生了其他的成本，并且该成本的量值可能比先期测试来得更高。
这个涉及到测试管理的一些学问
我可以先说一下 国内的情况1.合格的测试经理不多
2.能够在较差的环境中树立合适的测试团队的人不多
对大家来说很多公司都在重视测试，开始组建测试部门，但是合适的负责人是很难选择的，对于公司来说也没有能力直接找一个高端的，所以这个是大家一个很好的突破口！
对于自己的发展来说，如果能够进一个流程还不算清晰，但是很有前途的公司，应该是很好的选择
1.自己有能力可以管理所有的测试
2.按照自己的想法去做
3.做出的成绩是自己的，如果公司成功，必然自己成功
3.就算做不好，自己也能得到非常多的失败经验！
像楼主的帖子我很认可这种看法，现阶段其实很多公司就是这样，没有什么好气愤地，如果你不是这样，其他部门肯定会尊重你的工作，如果他们不尊重，你多考虑一下自己的问题吧。 版主们的评说,真是透澈啊,我刚来这个网站不久,觉得很好,
我做测试一年了,公司成立测试部才两年,所以很不成熟, 正像几位说的,有很多问题.
1.测试的技术水平很低,用户级测试,发现不了什么实质性的bug
2.可能因此,不受重视.技术水平,也一直上不去,形成恶性循环.
3.测试部门像后勤一样,有什么事,都找我们帮忙,觉得我们没工作一样.
4.工资少,留不住人,一般一年或两年,就跳了,程序员也一样,都去好的地方发展了
5.测试人员都学编程 ,然后做程序员,使得测试总是缺人,再新招,又要重新熟悉.
6.还有就是,我们的负责人,就是个经理助理, 他自己什么都不测,天天也不知道忙
什么,都是一些杂物..像楼上说的一样. 组里就是一片沉浸.没什么生机.也看不出
有什么发展.
总之问题,一大堆了,我也想要跳了
但要跳也得有资本,我会学好之后再走的,呵呵,
其实说了一大堆.解决的办法只有一个, , 提高技术水平了.
那样也会受到重视,一切也不好起来了. 说的好.up 不要总是怪被看扁，自己先做出成绩来再要求被重新看待。贴主转的5条，还是很普遍的。
55555
我现在才刚进测试部不久准确来说 我进来之前公司没测试部主要是做黑盒测试哎。。。。
总这样我估计以后连JAVA或。NET中有那些基本数据类型我都
忘记了。。。（自学。。。开发语言和其他测试方法）
而且抗议 。。。为什么测试人员的薪水，福利和开发人员差那么多。。 其实公司不重视测试不单单是我们测试员的损失，更大的损失是公司在承担。但是对于那些不重视我们的公司，我们也没有必要去为他们惋惜什么，如果还没有找到更好的公司，就在现有的公司里努力提高自己的水平，然后慢慢寻找重视测试，重视我们的地方发展
