十年茫茫软件路

sunshinelius

再谈谈按照行业划分的测试
   全球化测试(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公司（如电商，金融，通信）会向私有云靠拢，中小企业则会向公有云转移。云计算的兴起带来的是对软件开发人员的开发模式，流程工具都会有改变，而对测试人员的要求有更多的技能，甚至有可能将开发人员转做测试人员，总之，开发和测试的界限会越来越模糊。

夕阳西下°

版主的观点很有前瞻性，非常赞同楼主的观点！

omg

mark

sunshinelius

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

liu_jiayou

期待更新

徐如果

lc20011003

等更新

omg

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

sunshinelius

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

sunshinelius

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

girl04

受教了，句句到血！

溪筅笙

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

sunshinelius

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

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，可以观察到对象的数量和创建频率。

omg

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

deadstorm

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

sophie2805

Mark.且行且思！

tudouniubi

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

愚人

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

千里

这个竟然被码出来了