十年茫茫软件路

sunshinelius

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

happy82bluesky

受教了,写的非常好,期待后续的文章.

阳光下的夜

mark,期待下文

yongyongbushi

，感谢

痴迷海军

写得太好了，受教了！

Tiffany0107

回复 4# 千里

Oh No

saramin

写得太好了，有点收获

千里

这个竟然被码出来了

愚人

又一个十年，可以参加征文的呀

tudouniubi

重点是握好手上的牌，好好打牌，有些人就只想着等到好牌才去伸出手，结果很容易什么都错过了，是吗？

sophie2805

Mark.且行且思！

deadstorm

LZ是测cloud.oracle.com的吗？在chris team？

omg

结果是这么转为开发的啊，呵呵，你们开发测试的界线越来越模糊了吧，你们现在开发团队需要专职的测试吗？

sunshinelius

后来的事情呢，我的团队在自动化测试方向做得还好，有过一个比较关键的突破，受到高层管理团队的肯定，用大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，可以观察到对象的数量和创建频率。

sunshinelius

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

溪筅笙

老前辈啊，坐等更新，一个软件测试路上的小猫。。。

girl04

受教了，句句到血！

sunshinelius

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

sunshinelius

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

omg

个人觉得易用性的BUG，很容易发现，但就是开发的接受程度有限。

lc20011003

等更新