51Testing软件测试论坛

标题: 十年茫茫软件路 [打印本页]

作者: sunshinelius 时间: 2013-7-21 23:49
标题: 十年茫茫软件路
前不久在北京的大学同学聚会，毕业13年了，在家庭里，工作上，社会中摸爬滚打十几年，都有了不少感悟和话题，席间大家不约而同地谈到一个话题，自己行业这碗饭吃得怎么样，还能吃多久。
奔四的年龄恰处在人生的一个拐点时刻，青春理想的惯性动力已经慢慢消失，对社会环境职场生存的人事开始形成一些自己的观点和判断，能接受残酷和无奈，也能观察机会和希望。如果说二三十岁是一个靠机会凭直觉的青春型成功时期，那么四十岁就是靠理性主动寻找人生价值来获取个人成功的阶段。
如今社会有不少极端案例，自焚，流血甚至危害公共安全，我有观察过，事主有不少是在45岁左右，这看起来有点奇怪，既不是热血青春的冲动青年，也不是已近暮年的老人，45岁大概是“看破”的年龄，是成功者最得意风发的人生阶段，也是失意者最没落绝望的时期。古往今来很少有人能够在四五十岁之后还能大幅度改变人生轨迹的人，除非时势造英雄，如八十岁的姜太公，当然时势也能打造狗熊，“时来天地皆同力，运去英雄不自由”。
“菩萨畏因，凡人畏果”，我是一凡夫俗子，当然担心40岁之后如何讨生活的问题，要想好好地谋划未来，就得狠狠地总结过去，这也是为什么我想写这篇文章的原因。
2002年我计算机应用小硕毕业，毕业课题有关软件性能测试，这给当时毕业的我出了一个“测试还是开发”的哈姆雷特问题，不过当时的IT行业正在高潮期，实际也是中国走向全球化的快速发展时期，到处都是新想法和机会，我不是哈姆雷特，却如阿Q一样，眼看周围同学纷纷走向外企和民企，便高喊着“同去！同去！”，就这样稀里糊涂地踏入了软件测试行业。
现在想想，人生最重要的决定往往是最不经意做出的。可能是因为小时叛逆想远远离开父母而选择到另外一个城市奋斗，这里后来成就了你的所有人脉；可能是因为网上偶遇认识了你的另一半，而从此你们在余生互相消耗折磨对方直到70岁才宽慰“我终于可以忍受他上床不洗脚了”。古人有句话“很好的姻缘都是天成的”，我再加上一句“很坏的姻缘也是天成的”，你只能在现有的条件下，努力打好手上的牌。

作者: 夕阳西下° 时间: 2013-7-22 09:20
写的很好，每个人在不同境遇之下都会有不一样的选择，而我们需要做的就是选好一条正确的路，然后坚定不移地走下去！

作者: forstkksk 时间: 2013-7-22 23:46
只知道自己还在路上，虽然不清楚下面该怎么走~

作者: 千里 时间: 2013-7-23 20:15
45岁的人还有做测试的，说明测试这个行业可以做到中年。

作者: omg 时间: 2013-7-23 23:26
前辈，能不能说下具体做了几年测试？目前做了哪些事情？下个5年准备怎么发展？

作者: sunshinelius 时间: 2013-7-25 07:51
这是个开贴，打算持续更新。51的审核机制太严格了，现在。发多点文字就要管理员审核。
可以看我的博客，那里更多文字
http://www.cesoo.com/bbs/viewtopic.php?f=3&t=539

作者: omg 时间: 2013-7-25 20:57
怕广告吧，他审就审，不是广告，肯定过。

作者: 夕阳西下° 时间: 2013-7-26 09:55
我们是实时审核的，一般工作时间5分钟左右就会审一次！

作者: sunshinelius 时间: 2013-7-27 10:32
第一份工作就这样开始了。负责一个功能模块的UI手工测试，还兼做公司几个产品上线前的性能测试。工具就是loadrunner，录脚本，设场景，看报告，三板斧下来，总会发现一些性能问题，这项工作是给测试团队加分的，因为人对自己不了解的领域会有本能的敬畏和尊重，在十年前，谈到“”高并发”“大负载”，连开发人员也会觉得新奇。后来测试业界又出现了更多的性能概念名词，如“伸缩性”，“压力测试”，“容量测试”等等。我一直有个不善良的猜测，业界一些利益相关者出于某种目的，将能够说简单的事情复杂化，有意给读者设置理解障碍，就像社会某专家一样，大谈“幸福指数”，“等离子”，想跟我对话辩论，先明白些名词吧，不过名词的解释权可在我手里哦，一些中国所谓专家就是这么练成的，信息和术语的垄断太可怕了。
于是，2004年，我在论坛写了《让loadrunner走下神坛》，在2006年出了第一本关于loadrunner的入门书，这促使了我对性能测试做一些思考，loadrunner能证明系统存在瓶颈，能找出瓶颈在哪里么，再前进一步，我们能够消除甚至提前避免瓶颈出现么？这些问号，使我最后回到一个简单的问题上来，到底什么是“瓶颈”，它到底在软件系统的哪个地方出生，身材相貌，成长背景，我竟然对它一无所知，这太荒谬了，就像社会都说“有关部门”，但谁也没看过“有关部门”的住址门牌。
手工测试里重复工作多，不知什么时候开发出来一个build，就要开测，忙得一塌糊涂。测得不顺要加班，测得顺利又没bug可提。这种日子一天连着一天，一直在想能不能把测试工作做得像开发一样，理性有序。于是抽点时间就搞了几个想法，测试案例管理，执行自动化，报告生成。这几个工作大大地提高了测试效率，获得了领导的肯定，单独找我谈话：“小liu同学，我要提拔你，以后你可以与开发平起平坐，共商软件质量大计”，打住，醒醒，哥们，你是在炖测试版的心灵鸡汤呢吧？

作者: zz45509 时间: 2013-7-27 20:24
然后呢

作者: forstkksk 时间: 2013-7-27 21:08
最后来了一个神转折...求一天三更

作者: 赵佳乐SMILE 时间: 2013-7-29 09:32
楼主文采飞扬啊

作者: sunshinelius 时间: 2013-7-29 12:03
改善手工测试的种种努力，在项目实践中收效甚微，不是无果而终，就是半道中卒。那些在教科书中写着的知识，在国外已经成熟的经验，为什么在我们自己的项目里就应用不起来呢。比如测试流程管理，目的将测试中的工作规范化，测试自动化是为了提高执行效率，这些看起来都是很好的愿景，没有错啊，那是什么地方出了问题呢。
我有几年一直在努力从测试技术上寻找答案，后来终于有了一点想法。
当我们把过多的关注焦点放在在如做好软件测试的时候，下意识里有一个隐含的前提，就是测试是独立于开发的，我们可以不用太关心软件开发，就可以经营好自己的测试领域，从而反推开发提升软件质量。这种逻辑对不对，可以从实践中求证，有没有哪个软件企业开发做得混乱无序，而测试做得井井有条呢？
当我们在低头苦苦寻找答案时，不妨得闲抬头望望星空。有过人生阅历的人会有体会，最棘手的问题往往最后是两难共存的，而不是简单的一方消灭另一方。
开发和测试这对冤家是整个软件生产过程的一部分，矛盾有对立也有统一，离开了开发模式谈测试流程是空谈误国，离开了开发技术谈测试技术也是纸上谈兵。一个需求频繁变化的软件项目，连开发都忙得焦头烂额，你能指望测试工作整齐有序么？一个用户界面“一周小变样，一月大变样”的系统，你能设立UI自动化测试目标达到50%的覆盖率么？
软件开发和测试本是人为设定的两个概念，你把它当成一个软件工作更容易想明白一些问题。
当前有一个趋势，开发和测试越来越向对方融合，开发也要做自己的测试，测试也要做自己的开发，开发思维和测试思维并存，才能做出好软件。
到了2005年，无论做性能测试，还是手工测试，遇到的问题和事情让我有了一个内心冲动，去做开发！我要去看看开发工作到底在做什么，为什么会有bug产生。

我像一个大山里的孩子，每天对着大山，山那边到底是什么对我来说是新奇的，我渴望想翻过那座高山，看看山那边到底是那么样子。

作者: omg 时间: 2013-7-29 19:21

继续

作者: 愚人 时间: 2013-7-29 21:59
拜读了

作者: gj518889 时间: 2013-7-29 23:26
本帖最后由 gj518889 于 2013-7-30 21:35 编辑

楼主我现在是很迷茫啊，干了5年测试，干了5年配置+测试，部门整合，结果被整合下来了，说什么配置开发的人自己干，测试开发的都能干，活活的让我离开这个行业！！

作者: sunshinelius 时间: 2013-7-29 23:48
从软件测试转开发，是很有难度的。第一，从自身看，开发比测试的技术和经验要求更高，有人说，我们做测试的也会写代码啊，其实写代码是开发人员的一个基本条件，开发人员的经验不光是写代码，还有技术架构的选型和设计，对开发流程的熟悉等等，这些都是测试转开发的困难。第二，从用人单位看，大多数企业给开发定的工资比测试高，他们不太愿意用能给开发的工资雇佣一个只有测试背景的人。
所以，做测试要转开发，时间上就要计划一个提前量，用心学习和准备。要在面试官前展现出来至少不逊于一般开发人员的技术素质，才有可能被录取。
我当时准备了半年，在这段时间里把c语言和数据结构的书又看了一遍，然后研究一些网上的面试题，主要是算法问题。
面试了公司很多，其中曲折历程不多讲，电话面试就失败，运气好进入现场面试，最佳战绩也是只到了第二轮没了下文。后来放弃开发，测试职位竟然也屡试不中，从刚开始自信满满到后来斗志涣散，开始怀疑自己的能力。
在几乎放弃希望的时候，收到了一个M公司的开发职位offer，还是高级开发工程师的抬头。以M公司的名气和这个开发岗位，我都感觉像做梦，不真实。
好吧，来吧，一切未知的已知的，困难的容易的，都来吧，我要开始新的航程。

作者: wason21cn 时间: 2013-7-30 05:52
拜读

作者: sunshinelius 时间: 2013-7-30 11:09
回复 16# gj518889

这就是我写这篇文章的原因。一来自勉，二来示人。到底职业生涯里什么最重要

作者: omg 时间: 2013-7-30 18:20
那前辈后来知道为什么M选你了吗？

有些好奇

作者: gj518889 时间: 2013-7-30 21:32
回复 19# sunshinelius
最近面试了3家，感觉都是觉得10多年的经验人家用不起，不敢用，虽然降低身价，人家还是觉得你干不长，一有机会就会跳，接近40就成破衣服了么？

作者: sunshinelius 时间: 2013-7-31 10:02
尽管在转开发之前，我做了一些知识的准备，但进入M公司之后，发现那些知识混弄面试还凑合，但应对工作却远远不够，尤其是一个高级软件开发工程师的岗位。
这给我带来了巨大的压力，人最危险的状态是“名不副实”，往前一步是泡沫，往后一步是原形，深深太平洋的深深伤心啊。
M公司主要开发语言是C和C++，而且大多产品已经发布，处在维护阶段，而我的任务就是负责一个产品上的新功能开发，实际上也可叫做补丁。要改代码，就要先读懂老代码，几万行的代码，一份功能文档，要在一两个月内看懂，压力很大。毕竟我大多的开发经验只是在研究生阶段做过一些小规模的原型开发，还从来还没有接触过大系统的开发工作。
有人说，正规的公司应该有入职培训，安排工作导师啊，这些在M公司不是没有，大多是常规的笼统的，所谓“师傅领进门，修行在个人”，具体到工作上的细节，大多还是靠自己来琢磨。向工作导师求教是一个不错的途径，但工作导师不是学校的老师专门负责答疑解惑，他也有自己的工作任务。所以，对于一个新员工，如何能够从有经验的同事那里快速学习到知识是很一件重要的本领。
我们十几年所受的教育模式是，好多年轻人听一个长者讲，然后要精准无误，丝毫不差地将这些知识通过考试再反馈给长者，尤其文科类科目，政治语文历史等等，考试像是复印机性能竞赛，谁复印得越清楚，谁得分就越高。在这个教育过程中，年轻人只用到耳朵和手，没用到嘴巴，而倾听和表达是人际交流中最关键的两个信息交流方向，人们通过倾听收集信息，在大脑里分析这些信息，然后又通过讲话校验和表达这些信息，再倾听，再反馈，进而通过交流获得自身能力的提高。
在软件过程中，有一个活动叫代码审查，由代码开发者走读自己的代码，很多时候，开发者在复述自己代码的过程中，就发现了其中的问题，可见在组织语言的过程中，大脑同时也在进行思考和校验。语言能力提高到一定水平后，运用简单的逻辑和质朴的词汇，就能说清楚一件复杂的事，这是一种巨大的人格魅力。

作者: 蹇自勤 时间: 2013-7-31 10:13
期待LZ转开发后对测试的新视野

作者: girl04 时间: 2013-7-31 11:49
原来是《让loadrunner走下神坛》的作者呀，敬佩敬佩！前辈。

这是多年来看到且印像非常深刻的文章。

作者: omg 时间: 2013-7-31 19:00
如何快速学习，融入新项目和新公司，真的是个难题，看到不少人，速度真的比较慢。

作者: 夕阳西下° 时间: 2013-8-1 10:00
楼主测试转写作吧，文采飞扬，不当作家可惜了，太厉害了！

作者: sunshinelius 时间: 2013-8-1 10:45
回复 20# omg
谢谢关注，后面会提到

作者: sunshinelius 时间: 2013-8-1 10:48
张嘴说话，至少有两个好处，别人能了解你的想法，你能获得有效的反馈。
和同事的交流最好从一个问题开始，因为做技术的人很少愿意做无目的的谈话，而且，交流过程中也会发现更多的问题，得到的答案越多，进步就会越快。可以说，提出一个好的问题就是成功了一半。
从哪里搜集问题呢？工作环境中有很多挺好的渠道，比如大公司内部的文档库，邮件列表， bug数据库等等。拿出测试工程师的耐心和细心，总会找到一些线索。我有一次在程序里发现某个网络会话对象构建得非常大，达400多Ｋ，而且在网络交互中，客户端没做cache, 一次登陆会发生多次数据包往返，测试的职业敏感让我想到了这里可能存在的性能问题，于是通过计算，证明在百兆局域网里只要有12个用户以上同时登陆，就会导致网络瓶颈。做出这个结论，我没有做任何真实的loadrunner并发，只是在脑子里模拟了一下场景。当时我把这个问题反映给负责的同事，他惊讶得下巴都快掉下来了。
转型压力依然非常大，汤师爷说过“步子迈大了，容易扯着蛋”，我的这次转型有两个跨越，第一，测试转开发，缺少上手开发的经验。第二，大系统的开发工作，没有丰富代码经验的人也很难摸到门路。
就是因为扯了蛋，我面对新工作就经常蛋疼。
在这里，给那些想从测试转开发的朋友建议，如果你想做开发，可以多看自己项目里开发人员写的代码，没吃上猪肉，至少也能见过猪跑，看多了，自然会有理解，再吃猪肉，就不那么发怵了。

作者: sunshinelius 时间: 2013-8-5 10:28
日子一天天过，我就那么一点点啃代码，虽然进度慢点，但按照这个思路下去，也应该至少是一个笨鸟先飞，新警察入道的传统故事，毕竟古人说过“世上无难事，只怕有心人“嘛，但别忘了，古人还说过”人算不如天算“。在我进入开发工作几个月后的一天，公司突然传来消息，由于种种原因，项目要发生变动，人员也要调整。原来，这个项目在我进入之前就已经不稳定了，这也是当时我为什么会如此”幸运“的一个重要原因。
经历这件事之后，在我梦里，经常出现两艘大船，一个是泰坦尼克号，一个是诺亚方舟，应该上哪艘船呢。
天上掉馅饼，也掉秤砣。我收到了O公司的offer，就又回到测试行业里来了（不要问我为什么）。当今电视选秀中一群坐在高高龙椅上的导师嘉宾经常问选手的问题“你有什么梦想啊”，“你为什么选择这个行业”。我想，对这种问题的回答大多不可能是真实的。就像王石不会告诉你，他的前岳父是广东省委副书记；马化腾不会告诉你，他父亲是盐田港上市公司董事；刘志军不会告诉你，他当年是因为娶了武汉铁路局局长的侄女后平步青云。
进了O公司，负责一个产品的模块测试。应该说，O公司相比其他公司测试人员地位还是有点分量的，给我印象深刻的是测试人员居然参与代码单元测试，在业界还在争论单元测试应该是由开发还是测试来做的时候，O公司的策略很简单也很务实，无论开发和测试谁一方做单元测试，最后都要经过对方的review。没有一个强大的测试技术团队是不可能争取到这个地位的。

作者: sunshinelius 时间: 2013-8-5 11:02
回复 23# 蹇自勤
我喜欢你用视野这个词，确实看得宽了，有挺多纠结的问题都能找到答案，这就是成长。

作者: sunshinelius 时间: 2013-8-5 11:23
回复 21# gj518889
特别理解软测人员的职业瓶颈，在国内环境下，35岁可以算是一个分水岭。用人单位担心35后的可能不是跳槽，而是安排不了一个合适的岗位。在国外，我见到五六十岁还在做软测的人。我在后续的帖子里讨论这个差别，谢谢关注。

作者: wason21cn 时间: 2013-8-5 22:16
O公司 Oracle ?

作者: omg 时间: 2013-8-5 22:39
看样子，这O公司，的确不错。

作者: sunshinelius 时间: 2013-8-6 12:44
回复 33# omg
大公司内部各个产品部门都会有差别的。

作者: sunshinelius 时间: 2013-8-6 12:44
首先说说单元测试，任何工作都要遵循投入产出比最大化，单元测试是一项距离开发最近的测试工作，开发人员做单元测试无疑效率最高，因为设计单元测试案例要理解代码的功能，单元模块之间的调用，继承关系，把这些搞清楚，相当于重新开发一次代码。但这也不绝对，如果是一些标准规范化的功能，测试人员也可以介入单元测试的，比如涉及到编码，解码，文档MIME规范等等，这些功能input和output都比较简单和固定，测试人员如果有一定代码水平，做起来完全没有问题。但无论哪一种实现，都需要人工投入。有的小公司小项目，测试就几个人，忙手工测试还手忙脚乱，谈单元测试那无疑是纸上画饼。从我个人来看，我倾向于将来单元测试会成为开发必做的工作，当然也可以指导测试人员去做这项工作，最关键的是需要一个透明的流程机制来定时运行，维护，更新这些单元测试案例，hudson是一个比较不错的框架，就是太偏重开发。
UI自动化测试就像一个梦中情人，听说过，但从来没真正地享受过。UI自动化测试的关键之处不在工具，也不在技术，而在于产品的管理，流程给UI自动化测试添加了非常多的干扰因子。比如吧，花了一周开发的测试脚本，可能在产品版本的升级后，就跑不起来了，花了半天才定位出是因为页面上的某个labe属性变化了，好吧，修改脚本，再运行，下个版本又出错，再修改，最后算算，自动化上花费的时间可能比手工测试还要多。要避免这种风险，需要谨慎考虑自动化测试介入的时机，和自动化测试案例的功能范围。凭个人经验，介入不宜过早，可以选择在稳定的回归测试开始之后；自动化覆盖率不宜过高，能达到20%就是一个不错的比率了。如果各项条件都不成熟，可以暂时不做，把自动化测试计划得更远一些。至于QTP，Winrunner，Selenium等等工具，不比做太多的伯仲之争，我一向的观点是，工具就是工具，用的爽了就用，用的不爽就换，自动化测试人员随着经验增长，应该把更多的精力转移到自动化的整体方案上来，能不能用，用什么，怎么用，怎么和开发流程整合，怎么生成报告的问题上来。而对于测试经理来说，UI自动化测试可能是一个毒丸，需要根据实际对自动化测试实施做恰当的决策，软件产品周期长功能稳定，自动化测试必须考虑在测试计划里，软件项目周期短变化快，自动化测试可以考虑适时而为，虚虚实实结合，对上既有政绩，对下又有业绩。
性能测试呢，是一个技术性较强的工作，开发能做，之所以是测试人员来做，因为它是性能测试。但尴尬的是对于测试人员来说，性能测试的要求又太高了，几乎要囊括了体系设计，系统平台，中间件，数据库等各方面的知识专家，当然可以说这些知识测试人员应该有，但是到了那个层次后，他恐怕就不叫测试人员了，可以叫DBA，叫System administrator。所以，性能测试人员的最大作用是将性能测试推动起来，能够将这些不同的知识专家们集结到一个性能问题上，当然，如果能够对性能问题做一些定量的分析，判断问题范围，那就更完美了。在性能测试里，沟通也是一个重要的本领，谦虚是必须的，因为你面对的是专家，随意下结论很显然是自取其辱的最快捷方式。
在测试过程里，不少产品都有一个安装测试，负责部署环境。安装包括server端的安装和客户端安装，安装测试是典型的简单高重复工作，因此也是自动化测试实施的重点领域。如果是web页面，需要和不同的浏览器不同的版本进行兼容，如果是桌面客户端就更麻烦了，windows，linux，还有mac，现在智能终端的兴起又有iphone, ipad, android。另外，插件也是客户端的一种方式，插在浏览器上，outlook上，这又牵出一堆的版本矩阵。安装测试工作的关键点在于测试场景的整理，优先级的规划，测试计划安排。首先可以整理出一个测试场景矩阵，估算工作量，测试机器资源等等，然后进行计划安排，自动化测试的规划等等。如果自动化测试做得不错，安装测试会是一个比较稳定有序的工作。

作者: omg 时间: 2013-8-6 21:03
前辈在O公司做多久？经历上面的事项吗？

作者: sunshinelius 时间: 2013-8-7 10:31
回复 36# omg
既然问到这了，我就说一下大概我的个人职业历程，从测试到开发，到自动化测试，到测试经理，逆袭开发经理，目前任云计算方向的高级开发经理。我在本贴的观点皆出于本人经历和观察，之所以写本贴，是个人测试到开发的一个总结，权当向51testing论坛朋友的致敬和告别，另外，就是看到测试业界自负和自卑，热情和迷茫并存，希望能提供一个视角让大家平和看待开发和测试。

作者: omg 时间: 2013-8-8 00:25
厉害。做到开发经理，又是扯上云计算的。

作者: 夕阳西下° 时间: 2013-8-8 10:58
回复 37# sunshinelius

为什么要告别呢？

作者: flyinglus 时间: 2013-8-10 12:20
mark,期待下文

作者: sunshinelius 时间: 2013-8-12 09:18
再谈谈按照行业划分的测试
全球化测试(Globalization)，是一个固定的知识集合，包括数据层上的字符转化，应用层上的时间，日程，货币格式，BIDI等等各种不同locale。虽然Global feature相比base feature级别要低一些，但是Globalization的特点是知识独成一体，贯穿到开发的设计，实现，到测试的设计与实现。比如你的产品要支持全球化，那在产品设计初期就要规划好支持多少种locale，资源文件采用什么格式，翻译的process等等，在实现的时候，时间处理，字符长度计算，人名显示等等，要调用正确的globalization API, 避免默认英文的hard code，最后交给测试人员来验证。全球化的测试人员上手并不困难，遇上好的导师，一个新人上手全球化测试也就两三个月的时间，但是要做深入，还是要研究不少知识的，至少MIME规范，RFC，Unicode等等。如果做得好，可以进入Globalization的开发甚至设计，而不会受到业务的限制。个人的看法全球化测试工作稳定，可以做很长时间，但挑战性较小，毕竟unicode一统天下的时代开始了。
业务性很强的测试（比如金融，电信）。产品带有两个很强的属性，业务属性和软件属性，懂软件，同时也要对业务有理解，比如银行，证券等，无法通过常识来判断软件是否运行正确，需要一定的行业知识积累，这里的软件测试人员更像一个行业用户。同时，金融行业对于软件质量有着自己的要求，主要是功能正确，交易安全，至于其他的易用性什么的，不是考虑重点，所以在这个行业的测试人员我看到的都比较辛苦，经常做回归测试，而且对遗漏bug的追查也非常严格，再加上行业特点太强，职业生涯和行业前景密切相关。
相比之下，云计算是软件属性非常强，按业界流行划分为IAAS, PAAS和SAAS三个层次，IAAS上对计算资源，存储资源，网络资源的虚拟化，PAAS上提供管理，计费，通知等公共服务平台，SAAS上则向用户提供最终服务。云计算的革命性是它提供了一种与以往传统软件不同的生长模式，从安装，部署，升级到扩容，都有统一的策略，这给软件界带来的影响是深远的。云计算不是突然产生的，其实像GoDaddy之类的网站空间运营商已经可以算的上是PAAS提供商了，下一步IT厂商将会在云计算领域进行更加剧烈的竞争，而大的IT公司（如电商，金融，通信）会向私有云靠拢，中小企业则会向公有云转移。云计算的兴起带来的是对软件开发人员的开发模式，流程工具都会有改变，而对测试人员的要求有更多的技能，甚至有可能将开发人员转做测试人员，总之，开发和测试的界限会越来越模糊。

作者: 夕阳西下° 时间: 2013-8-12 09:45
版主的观点很有前瞻性，非常赞同楼主的观点！

作者: omg 时间: 2013-8-12 22:52
mark

作者: sunshinelius 时间: 2013-8-13 11:12
用户体验(User Experience)是一个热点，如何能让软件的界面有更直观易用的风格，让用户喜欢，这是很多互联网公司正在做的事情，比如facebook的招聘计划里，user experience工程师名列薪水榜首，可见多么吃香紧俏。
软件测试工程师可以推动用户体验，反过来，用户体验又可以加强软件测试。可以想想，让你实现一个操作订单的功能（包括增加，查询，修改，删除在同一个页面里），这个功能很容易实现，但是怎样能够在不影响性能的前提下，让用户感觉更方便易用呢。这需要有两个基本条件，第一，对业务功能有深刻的理解，知道订单的上下文，工作流，操作权限等等。第二，对用户使用习惯有经验理论，如人体工学，人机交互学，信息结构等等。在UI测试中，如果测试人员能够留心UI的功能布局，页面风格，图标设计，响应输出，就能积累UE经验，甚至提出UE的bug。在不少互联网公司的bug数据库里有一个叫做“易用性”的bug类型，测试人员也可以提易用性的bug。

作者: liu_jiayou 时间: 2013-8-13 15:52
期待更新

作者: 徐如果 时间: 2013-8-14 13:43

作者: lc20011003 时间: 2013-8-14 17:14

等更新

作者: omg 时间: 2013-8-14 20:44
个人觉得易用性的BUG，很容易发现，但就是开发的接受程度有限。

作者: sunshinelius 时间: 2013-8-15 09:27
在软件测试的这几年，先后做单元测试，测试设计，自动化测试，后来获得了一个晋升的机会，就成为了test manager。多了一些管理的工作，团队的规划，培养，分工。
  招人，是团队搭建的一个重要工作。任何团队，不管是技术型还是业务型，找到合适的人是关键第一步。有凝聚的团队，管理集中在怎样做事；而众口不一的团队，管理就要花费精力在管人上。这倒不是孰优孰劣，因为在不同时期，不同背景下，所要求的团队类型也会不一样。比如，战争时代会涌现一大批有个性有想法能做事的人才，有名的是湘军，桂军等，都以个性刚直勇猛为名；而到了和平时期，社会成功者大多是一些能够协调好关系，处理好矛盾的全面人才，尤以江浙一代的师爷文化为代表。所谓“飞鸟尽，良弓藏；狡兔死，走狗烹”，其实也有一定的客观的社会事实基础。
  在流行的管理学里，一般会用态度和能力两个维度来描述一个职员的职场表现，于是排列组合下来，就有了态度好能力强，态度好能力弱，态度差能力强，态度差能力弱四种类型。毋庸置疑，态度和能力俱佳的人，应该是骨干人才，要留住并提拔的；态度差能力差的人，是要被职场淘汰的。态度差能力强和态度好能力差这两种类型是要谨慎对待的。在现实里，情况可能还要更复杂多，对于软件测试人员来说，至少还要有一个重要的能力，就是交流，如果细分的话，还可以有文档交流，邮件交流和对话交流。在外企的话，涉及不同的文化差异，交流能力更加重要，直接影响晋升，甚至职业前程。在比较小的项目里，开发和测试团队如果能安排坐在同一个办公室里，会能提高工作效率，因为交流成本很小。但如果一些大的项目，工作合作要跨部门甚至跨国，需要沟通和协作，如何通过交流清楚地表达自己和理解对方，这就是一个重要的本领了。有的人喜欢写长邮件，有的人则喜欢写短邮件，这可能会起到完全不同的的效果。另外，对于测试人员容易犯的交流错误是表达问题不准确，而又盲目对问题做结论性的描述，比如“这个bug非常严重”，“开发人员谁谁开发的质量不好”等等。这些都不是很好的交流方式，应该尽量做到客观，理性，明确bug的重现场景，搜集bug的准确信息，这样表现了专业能力，又能跟开发人员是“我们在一条船上”的态度。
  再次强调，理解开发工作是做好测试的一个必要条件。

作者: sunshinelius 时间: 2013-8-16 12:03
经常有人问我，创建一个新的测试团队，或者开始一个新的测试项目，应该从哪里开始入手，测试里有很多工作，包括测试计划，测试自动化，测试流程等等，总不能在刚开始时就眉毛胡子一把抓啊。要搞清楚这个问题，就要先想想我们测试工作的关键价值在哪里，毫无疑问，测试的最根本工作还是发现并提交bug。一个多么简单的道理！没有人会说软件质量是“测”出来的，也没有哪个测试团队不花大力气去找bug，换句话说，如果长时间不提bug，测试团队就会心里发慌；如果软件里没有bug，软件测试也就失去了存在的意义。
IT行业发展成熟，会使软件市场充分竞争，提高软件质量要求，软件测试得到重视，这是软件行业的一般规律。而中国有自己的国情特色，GDP大半部分是靠政府花纳税人的钱投资拉动，花别人的钱都不会太理性的，不会追求效益最大化，也不尊重行业的一般规律，于是我们看到一些匪夷所思的事情，明知测试不充分存在安全隐患，但为了sb大献礼，高铁也要准时上线；army的软件系统提出最严格的需求，但软件项目竣工时专家都不到场就合格验收。在这种形势下，连软件开发本身可能都不是整个项目的关键，何谈重视软件测试呢？这种“中国特色”能够解释很多现象
1. 国外的软件技术人员职业寿命可以到60岁退休，而中国，做到35岁就纷纷考虑转管理
2. 软件行业里很多都是“娃娃兵”
3. 来自客户需求每天都在变，今天某个客户领导A有了新想法，明天领导B又有了新想法。
等等。不一胜数。

作者: girl04 时间: 2013-8-20 18:27
受教了，句句到血！

作者: 溪筅笙 时间: 2013-8-28 08:54
老前辈啊，坐等更新，一个软件测试路上的小猫。。。

作者: sunshinelius 时间: 2013-9-2 10:23
我们每个工作在第一线的技术人员都是一颗渺小的种子，能不能顺利发芽长大，大多靠自己的基因，能长成一株小草，还是一棵参天大树，更多取决于这个森林规则。前不久，马云，柳传志企业家不约而同地在公开场合主张“莫谈国事”，这真让人怀疑他们面对公众的立场和诚意，企业家代表不代表企业，人大代表不代表人民，每个人可以只关心自己一亩三分田的今天长势，但没有权利批评别人收听天气预报，未雨绸缪，就像那个HH代表文艺界表态不闹事一样，在一间漏雨的屋子里，怂蛋看到的是漏雨，勇士却看到的是屋外横挂天空的彩虹。

作者: sunshinelius 时间: 2013-9-2 13:47
后来的事情呢，我的团队在自动化测试方向做得还好，有过一个比较关键的突破，受到高层管理团队的肯定，用大boss的话来说“这个方案解决了公司自xx领域产生20年以来的空白”。实际上，为此我们也付出了相当的努力，持续几年的投入，将近10万行代码的开发量，终于在最后一刻灿烂了，那种感觉真的很棒。

再后来，一个机会，我的测试团队直接转为开发团队，负责云平台上的服务开发，经过测试转型和新聘开发人员，磨合碰撞中，终于上了正轨，花了一年多的时间，团队内建立了敏捷开发的流程，开发规范，还有一套自动化测试验证框架，使bug尽量在最早的开发阶段被发现。因为做过测试，所以我对测试更加重视。

下面从开发的角度来看看ｂｕｇ是怎样产生的

1）性能bug

软件性能在本质上是一个空间和时间转换的问题。

1. cache的使用

应该考虑为重复使用的数据设计cache机制。cache中常规的有配置数据，用户信息，resourcebundle等等，这些读概率非常高的数据一般都在app启动时就加载到内存的cache里。我还遇到一个有趣的现象，发现java的反射机制是十分消耗时间的，在10ms级别。因此，在第一次反射后就将annotation放在cache中会大大提高效率。实际上， cache里什么都可以放，对象，甚至interface和class的定义也可以放进cache。cache在提高效率的同时，也会带来新的问题，比较头疼的就是cache同步。在多节点的环境里，测试人员可以设计多节点同步，restart app server，shutdown db等测试案例，发现可能的cache的问题。

2. log的级别

之所以把它放在第二位，是因为它不起眼，但是却能制造大麻烦。在一般情况下，log可以设置error级别，但开发人员在开发过程中，容易把一些不重要的信息都塞进log里以便调试，如果不注意调整，log就成为潜伏最深的性能问题，我遇到过访问一个页面，后台写了45次error log, 每次log都要占用20多ms, 对性能影响非常大。

3. DB server的问题

对于Oracle ＤＢ, 最好用的性能监控报告是awr了。awr最初级的指标就是top sql。可以发现哪些sql耗费时间，能够发现不合理的table设计，索引问题。对ｄｂ性能有杀伤力的是trigger，trigger可以方便解决一些场景，但性能上比较耗时间，慎用，有的公司ＤＢ设计规范就不建议用trigger。我看过一个大型的电信系统数据库竟然使用了几百个trigger，真是开了眼界。

4. java 线程同步

在java里，经常使用synchronized关键字定义同步的代码块。但对于synchronized的高昂代价java开发者一直非常谨慎。在stackoverflow里有讨论。

http://stackoverflow.com/questions/1671... ve-in-java

多个线程并发情况下，synchronized只会允许一个线程进入代码块。

5. java对象复用

在javadoc里，有一些object是建议复用的。比如simpleJdbcCall，httpclient等，因为它们在初始化的时候，要使用非常多的资源，为了提高效率，需要复用。采用单点实例是一个不错的办法。性能测试中，通过监控java的heap，可以观察到对象的数量和创建频率。

作者: omg 时间: 2013-9-3 20:31
结果是这么转为开发的啊，呵呵，你们开发测试的界线越来越模糊了吧，你们现在开发团队需要专职的测试吗？

作者: deadstorm 时间: 2014-3-11 01:00
LZ是测cloud.oracle.com的吗？在chris team？

作者: sophie2805 时间: 2014-5-22 16:07
Mark.且行且思！

作者: tudouniubi 时间: 2014-5-30 12:20
重点是握好手上的牌，好好打牌，有些人就只想着等到好牌才去伸出手，结果很容易什么都错过了，是吗？

作者: 愚人 时间: 2014-5-30 12:23
又一个十年，可以参加征文的呀

作者: 千里 时间: 2014-5-30 12:27
这个竟然被码出来了

作者: saramin 时间: 2014-7-3 15:05
写得太好了，有点收获

作者: Tiffany0107 时间: 2014-7-17 10:52
回复 4# 千里

Oh No

作者: 痴迷海军 时间: 2014-7-19 14:00
写得太好了，受教了！

作者: yongyongbushi 时间: 2014-8-8 14:48

，感谢

作者: 阳光下的夜 时间: 2015-12-23 00:05
mark,期待下文

作者: happy82bluesky 时间: 2015-12-30 15:18
受教了,写的非常好,期待后续的文章.

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)