如何提升个人专业测试能力

今日看到一段李开复老师的介绍,很有共鸣,与大家分享:

【李开复：如何提升个人专业能力】1.写文章，多发表个人见解，增加个人思考机会；2.大量看书，自学，但一定要选好书；3.多和圈里高手交流，听君一席话，胜读十年书；4.建立个人文件管理系统，不断整理自己的原创；5.参加系统学习，找到短板，快速学习；6.实践，大量实践！

 

1. 几个月写一次blog文章和每半年写一次测试技术总结的习惯，让我及时记录下自己最新的测试创新想法，并进行了系统化的梳理，在梳理过程中找到下一步的专业提升方向。

2. 时至今日每年都会购买几本测试书和计算机基础知识的书，几乎不买工具操作书（互联网上有文章）。因为操作书属于短平快没有收藏价值，我所购买的书都是通用性和能反复阅读5遍以上，每次都有收获的书籍。

3. 博客和微博是好东东，有条件参加一些测试大会和活动也能开拓视野。但还会紧盯和关注欧洲和美国一些测试大师 ，测试咨询公司的互联网资源，来拓展自己的思想。

4. 即使我自己回顾看自己写的blog和微博，有时都会有种疑问，这是我写的吗。所以及时写下自己的灵感非常有价值。

5. 通过阅读某一知识领域系统性的书籍，学习系统性的ppt，多看老外系统性的文章和国内专家们系统性的分享，作为镜子诚实的对比自己，就能找到短板。

6. 做1万小时一线的测试用例开发和执行，亲自发现1000以上bug，学习和分析它人发现的5000个bug，思考测试改进时间超过1000小时，项目中运用新测试方法超过1000小时，这些大量的实践，会加深你对专业领域的认知，会让你量变引起质变。

软件测试管理需要重视的几个问题

测试执行与跟踪阶段的管理重点是保证测试按照计划的顺利和有效实施。通过规范测试流程，加强测试的有效性的检查，及时报告测试进度，促进测试团队的交流，成为决定这一阶段工作成败的关键。

　　1、确保测试数据信息流通畅

　　管理国际化测试流程应该保证测试数据内容的有效传递，例如被测试软件的Build如何在编译工程师和测试团队之间及时传递，发现问题如何反馈，谁负责解答。

　　如果设计需求发生了改变，测试用例需要相应的更新。在测试过程中发现的测试用例无法执行的问题，需要通过有效的渠道，将这些信息及时地传送给合适的人员。

　　当测试的范围或测试时间发生改变时，测试管理人员应该及时将这些信息进行处理，调整测试人员的数量和工作内容，并且通知测试团队成员。

　　为了保证测试过程的数据信息有效传递，在项目的准备阶段需要确定传递的数据的类型（Build，文档，进度报告等），数据传递的方式（电子邮件，FTP等），数据传递的频率（每天或每周），数据的发送方的负责人和联系方式，数据接收方的负责人和联系方式。

　　2、Build验证测试与常规测试无缝集成

　　由于国际化测试和本地化测试同时测试数十种测试平台和语言，因此，按照先执行Build接受测试（或者成为Build验证测试），通过后再按照测试用例执行常规测试，可以快速确认当前版本是否存在重大的不适和大规模常规测试的缺陷。

　　常规测试即根据测试计划的要求，运行测试用例测试，在项目的缺陷管理库中报告和修正缺陷。为了保证每一个缺陷都是有效的缺陷，测试团队中需要安排对软件熟悉的高级测试工程师首先验证缺陷，关闭那些由于测试人员错误操作或者理解错误而报告的缺陷。

　　另外，在多个测试组同时测试时，可能会重复报告缺陷，也需要专人负责关闭缺陷。这样做可以有效节省开发人员修正缺陷的时间。

　　在进行多语言本地化测试过程中，某些缺陷是属于过重本地化版本共同存在的缺陷，因此，可以参考其他语言报告的缺陷，避免漏报。

　　为了尽早修正缺陷，测试人员应该每天跟踪缺陷的修正情况，并且对缺陷修正人员的任何反馈及时答复。例如，如果因为缺少了关键步骤，缺陷修正人员无法复现缺陷，则他们会在缺陷报告中要求测试人员补充所需要的详细内容，并且把缺陷的状态修改成"Need More Info"状态。测试人员尽量及时补充遗漏的缺陷信息。

　　测试任务紧张，测试时间不足，赶不上测试的进度要求，是测试人员经常遇到的问题。需要根据具体的情况正确处理，例如，如果在计划内，编译人员没有成功地编译出被测试的Build，而测试的时间不能落后于计划时，可以与测试管理人员讨论是否可以先选择在典型平台测试，优先执行高优先级的测试案例。

3、收集项目测试数据，跟踪和控制测试进度

　　由于国际化测试团队可能分布于不同的国家和地区，分别执行不同本地化版本或不同的测试类型的测试，因此，对于这些团队的进度和质量跟踪更有挑战性。

　　毫无疑问电子邮件是最常用的交流方式，除此之外，即时通信工具（例如，MSN）和电话也经常采用。为了便于跟踪，最好在使用及时通信工具和打完电话后，将交谈内容以电子邮件的形式发送给对方和相关人员。

　　对于外包测试而言，项目进展的信息交流显得尤为重要。最常用的是定期（例如，每周一次）进行项目电话会议，实现拟定会议主题，软件开发公司的测试项目管理人员和来自外包测试服务公司的测试管理人员，就测试的进度和问题进行系统交流。

　　对于被测试项目而言，典型的测试管理应该包括一个全球项目经理（GPM）和多个本地项目经理（LPM）。GPM负责整个项目全部的测试管理，通过收集LPM的测试项目信息，集中向产品经理报告。

　　项目测试进度报告是对项目进度跟踪的主要文档。对于比较严格的测试项目，LPM需要每天向GPM报告测试的进展，包括当天运行的测试用例，报告的缺陷，需要解决的测试问题等。

　　通常，可以每周一次或每两周一次由各个参与测试的团队向GPM报告测试的进展情况。GPM汇总测试信息，作为下次项目电话会议的讨论内容。对于需要软件开发人员和文档创作人员回复的问题，GPM及时与他们联系，将他们的反馈及时告知各个测试团队的测试经理。

　　除了测试进度外，测试质量的有效性和测试耗费的时间也是需要跟踪和控制的内容。测试的有效性可以由专门的质量保证人员负责，测试花费的时间与人力资源影响着测试的项目预算和成本。如果由于测试需求的变更，引起测试工作量和测试内容的增加，应该要求软件开发公司的项目负责人增加测试预算。

　　4、测试过程的风险管理

　　处理项目测试风险是测试执行阶段无法回避的问题，虽然在测试计划中已经分析了可能的项目风险，但是，"计划没有变化快"。实际测试项目过程中，总会出现这样或那样的事先没有料到的意外情况。这时候的处理原则是在不影响测试进的和质量的情况下，如何优化现有资源，保证测试的覆盖率。

　　由于测试人员的变动引起的资源紧张，可能是测试过程中遇到的较大问题，尤其是那些与语言相关的测试问题，如果没有备用的测试人员，则将影响测试的进度。因此，关键岗位的测试人员应该有备用替补人员。

　　对于测试数据丢失，例如网络病毒引发的网络瘫痪，关键测试文件无法得到引起的问题，属于不可抗拒的客观因素。因此，需要加强数据的安全备份。

　　对于那些可能会引起测试进度滞后，或测试质量降低的风险，测试方首先要积极寻求内部解决，例如，增加测试人员，通过加班赶上进度。另外，要及时将这方面的信息告知GPM，以便及时调整整个项目的测试进度和内容。

Session对性能测试的影响

　　Session介绍

　　Cookie是Web产品测试过程中不可缺少的一部分，我们需要通过Cookie信息辨别用户，得到属于自己的结果数据，例如DWR接口测试过程中，需要在请求头信息中传入测试用户的cookie信息，才可以得到该用户学习的课程，发表的博客，或者关注的用户等。Cookie信息通过模拟登陆操作就可以获得。但是，你有没有注意到你获得的Cookie是由什么组成的？是否包含NTES_SESS信息，是否包含SessionID信息？

　　NTES_SESS是URS返回的Cookie信息，NTESSTUDYSI是云课堂返回的Session信息，NTESSTUDYSI存储SessionID信息，不同的产品会配置不同的变量名。这个信息对于接口测试来说并不是必须的，但是却会在性能测试过程中起到很关键的作用。Cookie和Session有什么区别，为什么性能测试过程中必须需要Session信息？下面，我们一一阐述：

　　Cookie是什么：

　　cookie是小甜饼、小型文本文件，因为HTTP协议是无状态的，浏览器无法区分这次请求来自于哪个浏览器，因此产生了随着HTTP请求一起被传递给服务器的Cookie信息。Cookie是保存在客户端的，存在内存中的cookie，浏览器关闭后就消失了，存在时间是短暂的；存在硬盘中的Cookie，但存储时间长度超过过期时间或者用户手动清除时，cookie信息会消失。

　　Session是什么：

　　Session是会话，当用户第一次对网站服务器发生请求时，服务器会创建Session信息，生成SessionID用来唯一标识用户，并会把该SessionID返回给客户端浏览器（只存在内存，并不存在硬盘中），在会话结束之前的每次请求，浏览器会自动将该SessionID附加在请求头信息中，服务端接受请求时，检测是否存在SessionID（不存在或者Session过期都会重新生成Session），并通过该SessionID以键值对的方式查询用户信息。服务端的Session使用类似散列表的结构存储用户信息。

　　Session的常见实现形式是会话Cookie（Session Cookie），即未设置过期时间的Cookie，这个Cookie的默认生命周期为浏览器会话期间，只要关闭浏览器窗口，Cookie就消失了，这种形式的Session是和Cookie绑定在一起的。而平常所说的Cookie主要指的是另一类Cookie——持久Cookie（Persistent Cookies）。持久Cookie是指存放于客户端硬盘中的Cookie信息（设置了一定的有效期限）。持久Cookie一般会保存用户的用户ID，该信息在用户注册或第一次登录的时候由服务器生成包含域名及相关信息的Cookie发送并存放到客户端的硬盘文件上，并设置Cookie的过期时间，以便于实现用户的自动登录和网站内容自定义。

　　我们在执行接口测试之前，首先会通过URS得到用户Cookie信息，这份Cookie信息中至少会得到NTES_SESS字段对应的Values值，如果在获取Cookie时，我们同时跳转到产品页面，向该产品服务器发送请求（例如云课堂），那么在我们得到的Cookie信息中同样存在NTESSTUDYSI字段，该字段就是该产品的Tomcat服务器产生的32位的SessionID +jvmRoute设置的后缀名。在做接口测试时，如果请求头中没有传入SessionID信息，那么每次执行时，Tomcat都会重新生成一份Session；即便你传入该SessionID信息，如果SessionID过了超时时间设置，Tomcat还是会重新生成一份，Tomcat默认的Session过期时间为30Min。

　　性能影响

　　虽然只是一个小小的SessionID，却会对性能测试的产生很大的影响：

　　1、Session缺失：

　　在做Lofter产品的性能测试时，测试getHomePage接口，发现响应时间比较慢，JVM内存在测试过程中一直增长，Young GC收集不过来，Old区内存不断增长，最终会导致频繁Full GC，使用Jmap定位到堆内存中java.util.concurrent.ConcurrentHashMap$Segment对象不断增加，但是并不知道这个对象时谁在什么时候产生的。我们Dump出来此时的堆内存，使用MAT (Memory Analyzer Tool)工具进一步分析，到底是什么操作产生了大量的ConcurrentHashMap$Segment。

　　由上图可以看到这个对象是由org.apache.catalina.session.StandardManager产生的，session.StandardManager就是存储Session的容器。

　通过了解Session的原理得知，我们在测试过程中，只是传入了Cookie信息，在Cookie中没有包含SessionID信息，所以每次请求时，Tomcat都会检查是否存在该标识信息，如果没有则会创建。如果我们测试过程中有几十万次请求，那么Tomcat会创建几十万个Session信息，假设一条Session需要2K的数据，那几十万的Session可能会使得Session容器占用上百兆的空间。同时需要注意，因为我们每个请求都会创建Session，这个Session是创建了以后不会被使用的(下次请求中依然没有携带SessionID)，即垃圾Session，但是垃圾Session在过期之前是会一直存在内存中的，默认的Session保存时间是30Min，这样的垃圾Session会在内存中保存至少30Min，如果在这30Min中内我们不停的发送请求，Session容器占用的内容空间会 不断扩大，最终会影响我们的测试结果。

　　2、Session过期

　　即便我们在请求中加入了SessionID，但是还可能会产生不停的创建Session问题，这是为什么？因为Session是存在过期时间的，默认的Tomcat中web.xml中设置的session过期时间为30Min，如果我们得到的SessionID在30Min后使用，依据Tomcat的Session机制，首先会检查是否存在SessionID，如果有的话，检测是否过期，如果传入的SessionID已经过期，Tomcat还是会每次都自动生成Session信息。

　　Mark，Session的过期时间有三种设置方式：一种是Tomcat的配置文件web.xml中设置，一种是webroot项目代码中的配置文件web.xml中设置，一种是代码中设置session.setMaxInactiveInterval(15*60)，所以我们在测试中要记得检测和确认这三个地方。

　　3、SessionID后缀不匹配

　　在测试云课堂项目中，我明明已经修改了每个地方的Session过期时间，请求中传入了没有过期的SessionID，可是为什么还是会不停的创建Session？

　　一般我们的产品架构是Nginx+Tomcat方式，静态请求走Nginx，动态请求通过Nginx访问到Tomcat。Nginx处理Session采用了session sticky方案，需用到第三方模块jvm_route，需要在Nginx的配置文件中upstream.conf中设置：

upstream study { server 10.120.36.68:8010 srun_id=qa18-8010; server 10.120.36.97:8010 srun_id=qa19-8010; jvm_route $cookie_NTESSTUDYSI reverse; keepalive 100; }

　　该配置文件中配置了一个Nginx连接两个Tomcat，当请求过来时，会依据SessionID中的后缀来查找请求发送到哪个Tomcat，例如NTESSTUDYSI=1816E5ECBC052F6ABA420FEE7B06DA86.qa18-8010;就会把带这个SessionID的请求发送到 10.120.36.68(qa18)这台机器上去。

　　在qa18这台机器的Tomcat配置文件server.xml中，会设置jvmRoute="qa18-8010"，这样保证生成的SessionID的后缀是qa18-8010，如果这个两个后缀不一致的话，同样会出现问题。

　　例如如果Nginx配置文件中upstream.conf中设置的srun_id=qa18-8010，而tomcat配置文件中设置的jvmRoute="qatest18-8010"，那么获取Cookie得到的SessionID后缀则为qatest18-8010，当发送请求到Nginx时，检测到SessionID的后缀和设置的server服务器无法匹配，则会丢失session，使得发送到Tomcat的动态请求依旧是没有Session信息的请求，造成session丢失，测试过程中还会有session不断的创建。

测试用例说明书对客户和开发人员的重要性

测试用例说明书，通常定义为对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。在软件产品开发中用的非常多，但在项目开发中，重要性进行经常被忽视，很多项目组都是不做的，或者是为了敷衍编写的。敷衍是有很多原因的，各方不重视测试，需求多变导致测试层本大幅增加、项目时间节点紧，因此很多测试过程会被简化。很多项目组最后只会有下1-2个左右的测试人员，或者是开发人员做兼职测试，在编码结束后，就上系统点点，然后提交客户了；客户验收也是同样，验收平台搭建好后，走走流程，可能脑袋里面会想，怎么走流程可以把所有的流程都过一遍么，缺乏系统和专业的考虑。

　　软件开发，肯定比不上产品开发了，项目的成本、项目结点都是摆在那里的，要说服客户或者领导重视测试不是一朝一夕就能解决的。测试阶段肯定要简化的，但是测试用例说明书还是建议保留的，他的作用不是仅仅停留在测试的。

　　测试，第一要求的尽可能是测试覆盖业务的所有流程，逻辑分支；第二是测试的依据，不管是覆盖流程、分支还是覆盖页面，都归集为预期输入和预期结果，输入后的结果不是预期的，就是有问题的。

　　做需求有两个产物：需求规格说明书和页面DEMO，这都是需求静态的描述，你会发现很多客户在项目编码结束测试阶段后会提出很多新增需求和需求变更，有些程序员会抱怨客户，其实这很大原因就是，静态的需求描述和DEMO很难让客户的思维有所发挥，业务是动态的，做业务的客户的逻辑性和构思不比专业做软件的，只有等软件动态后才会想到真正的需求，谁都不希望最后一大堆改动，一堆人加班，一大堆风险。测试用例说明书能很好的弥补这个静态的问题，测试用例的业务流程覆盖测试，动态的描述的业务操作步骤，而且在需求做完确认后就能编写了，因此在需求阶段就做完测试用例说明书，可以有效的改善提高需求设计的质量，降低后期的需求变更。

　　上面的作用，是对客户而言，对做需求而言的；而第二个作用是做开发人员而言的。编写好的基本设计交给开发人员开发，经常会出现最后完成的代码不符合要求，问题可以归咎为开发人员理解有问题或者沟通有问题；也会出现开发人员不负责任，提交的代码问题未经自己测试，测试的任务推卸给测试人员。问题出在哪里，能不能沟通更加准确，能不能让开发人员更加负责？基本设计有颗粒度到页面级别的，也有到API级别的，但是不管怎么样，都可以分成预期输入和预期输出，在做完基本设计后，根据基本设计的颗粒度，设计页面或者API预期的输入和预期的输出后，就基本给开发人员定性，编写完成的代码应该是怎么样的了，这个预期都是测试用例，明确告知开发人员，编写的代码只有达到这个预期后才算完成，可以提交给测试人员测试。通常，开发人员在明白了预期的输入和输出后，对要编写的代码理解就更加深刻了。

　　至于测试用例说明书如何写，到底是怎么样的颗粒度，这个我以后在整理，这篇只是说要它的价值所在和重要性。

　　软件工程中明确写过，测试用例说明书编写在需求阶段和设计阶段，是经过无数项目的总结出来的，只是没体会到而已，这只能说自身功力的问题。

2012年我国承接国际服务外包439亿美元

　在2月20日上午召开的商务部例行新闻发布会上，商务部发言人沈丹阳表示，去年我国共承接国际服务外包合同金额438.5亿美元，同比增长34.4%，执行金额336.4亿美元，同比增长41.1%。具体承接服务外包情况如下：

　　(一)服务外包业务规模稳步增长。据服贸司业务统计，2012年我国共签订服务外包合同144636份，合同金额612.8亿美元，同比增长37%，执行金额465.7亿美元，同比增长43.8%。其中，承接国际服务外包合同金额438.5亿美元，同比增长34.4%，执行金额336.4亿美元，同比增长41.1%。

　　(二)服务外包业务仍以信息技术外包为主。2012年，信息技术外包(ITO)、业务流程外包(BPO)和知识流程外包(KPO)占比分别为56.1%、15.5%和28.4%。

　　(三)服务外包业务以美欧日为主要市场。2012年我国承接美国、欧盟和日本的外包执行额依次为89.4亿美元、54.6亿美元和48.3亿美元，占总执行额的26.6%、16.2%和14.4%。

　　(四)服务外包业务就业规模进一步扩大。截至2012年底，我国共有服务外包企业21159家，从业人员428.9万人，其中大学(含大专)以上学历291万人，占总数的67.8%。

观美剧《外包服务》 看美国人的外包实验

外包不只提供产品和服务，它还会产生工作转移、财富转移，让贫富更替。不管认同与否，外包是社会大趋势。

　　"外包"这个词最早出现在《地球是平的》一书中，不用弗里德曼费力解释，从字面就大致可以理解它的含义——把一些工作打包扔给外人。外人的含义很广，简而言之，他是愿意用低价格出售好服务和好产品的人，他一般出现在中国、印度、越南或者非洲。

　　经济学家和跨国公司的老板是外包服务的推动者，他们把外包描绘得极具诱惑力，它为劳动力过剩的国家解决就业问题，把人口红利提升一个档次，为需要消费的国家送去廉价产品，拉动内需。外包公司就是一个生活代理服务机构，它消化了过程，把结果直接送到你面前。

　　外包的故事有其残忍的一面，世界杯的比赛用球在印度生产，阿迪达斯雇佣的童工时薪不足1美元，同样是在印度，外包又展现出光鲜的一面，数以万计的理科生投入到软件外包的行业中，他们中的一部分成为中产，不只为美国人工作，也为中国人工作。美剧《外包服务》的故事也发生在印度，它聚焦的是美国公司设在印度的呼叫中心。不错，《贫民窟的百万富翁》中的杰玛在赢取百万大奖之前，也是在一个外包呼叫中心上班。

　　为什么是呼叫中心?它可能是现代企业中最容易被外包出去的一个部门，它不具备任何技术含量，公司拨给的预算极低，自然首当其冲被包给更廉价的人群。一切只在乎成本，会说英语的印度人比会说英语的美国人便宜很多，如果他口音严重，外包价格还能更低一些。

　　《外包服务》的主创显然对"地球是平的"这一说法有意见，在产业链和贸易层面，地球可能是平的，但在文化层面，地球到处都是沟壑。剧中的主人公美国人托德刚从大学毕业就进入白领阶层，是美国文化的代言人，但他跨越太平洋(601099,股吧)远赴印度管理自己的新员工时，却发现四处碰壁，他不喜欢印度的交通，觉得周遭的气味像是"大便在燃烧"，他播放录像向印度下属解释什么叫性骚扰，但这一行为本身又被视作骚扰，他再也吃不到猪肉，只能每天吃糊状物体裹腹，常春藤大学的毕业生在印度文化面前一败涂地。

　　看到这儿，你就该知道《外包服务》其实和外包没有太大关联，它基本就是一个美国人的印度游记，是《老友记》的印度版。故事的结局当然是美国人和印度人的融合，彼此发现对方身上的闪光之处，外包是美好的。

　　观众都在享受外包的成果，但不是每个人都有耐心欣赏一间外包公司的日常运作。

　　观众不一定这样认为，《波士顿环球报》刊登过一名观众在NBC网站上的留言："我的妻子——两个孩子的母亲因为印度的外包而丢掉了她长达10年的工作，从那时开始我就必须同时兼两份工，只是为了填补收入空缺，认为这部电视剧好笑的想法只会让我想吐。"一部展现文化冲突之美的电视剧瞬间又被拉回到了讨论外包服务是否合理的话题场中，不过它再也没有发散的机会了，《外包服务》只熬过了一季就被NBC电视台无情砍掉。观众都在享受外包的成果，但不是每个人都有耐心欣赏一间外包公司的日常运作，当文化冲突产生的笑料被审美疲劳后，剧中的印度人和美国人的命运就不那么重要了。

　　有一些工作是可以外包的，比如呼叫中心，比如iPhone的组装，比如Intel在成都的芯片封装工厂。它们的共同点是，流水线高强度作业、技术含量低、需要大量劳动力，这些现象都导致一个结果——外包公司处在产业链的下游。微软中国研究院不是外包公司，谷歌在全世界的分部也不是外包公司，你可以让人帮你送快递，但不会让他帮你去银行存款，被外包的总是不可或缺的边角废料。

　　为期一个月的外包生活被雅各布斯点滴记录了下来，完整地发表在《君子》杂志上，他感慨无所不能的印度人可以随时建立或者夺去一个美国人的生活。

　　凡事都有例外，《君子》杂志的首席编辑雅各布斯曾经做过一个实验，把自己的生活事无巨细全盘外包给一间印度公司，事实证明，被外包的生活也可以过得很顺畅。

　　雅各布斯雇佣了两间印度公司，分别负责他的工作事务和日常生活。他每月付给YMII公司400美元，有专人全权参与他的生活，为他结账，预定度假行程，网购。曾在《地球是平的》一书中出现的Brickwork公司则介入他的工作，当雅各布斯想做一篇人物采访时，Brickwork公司为他搜集所有信息，他们调查到了这个人物的身材数据、食物喜好，把谷歌上所有关于他的消息都分门别类写进了一个文档之中，比专业记者更加专业。类似的服务，雅各布斯只需要每月付出1000美元，在美国，这份薪水不够支付给一个记者。当雅各布斯想拒绝一个采访邀请，Brickwork公司会代笔写一封言辞恳切有礼的回绝信，雅各布斯把这封回绝信全文登载在了《君子》杂志上，称它为"新闻史上最好的回绝信"。当然，1000美元在美国也聘请不到一个如此优秀的秘书，雅各布斯甚至还因为想熬夜看电视而让Brickwork公司帮他完成过一篇文章的写作。

　　为期一个月的外包生活被雅各布斯点滴记录了下来，完整地发表在《君子》杂志上，他感慨无所不能的印度人可以随时建立或者夺去一个美国人的生活，他可怜"那些要大学毕业的美国人，他们要和渴求的、礼貌的、精通Excel的印度大军竞争"。

　　这差不多就是关于外包的现状，外包不只提供产品和服务，它还会产生工作转移、财富转移，让贫富更替。不管认同与否，外包是社会大趋势。问题是，雅各布斯的外包实验还是会遇到和《外包服务》相似的疑问，当工作和生活被外包，财富被转移，总有人要承受这种阵痛。那个在NBC官网上留言的观众不觉得《外包服务》是一部喜剧，自然也不会认为雅各布斯的外包实验多么有趣。

系统管理员常备十大开源工具

据说，网上充斥着超过50000种系统管理工具——而且所有你需要的工具都有开源版本。比如，Sourceforge，目前列出了超过405,000个项目，有超过25000个系统管理员工具——Linux系统下有超过21000个，Windows下将近15000个。我们选出了一些你经常需要用到的和一些能让你的工作更加轻松的工具。

　　1. Wireshark

　　Wireshark，2006年之前叫做Ethereal，它是当今最强大的网络工具之一。该软件捕捉和分析 Ethernet, IEEE 802.11, PPP, raw USB和本地连接的数据包，对于网络故障排除尤为有用。你可以通过显示过滤器自定义显示，创建插件来支持新协议，捕获的文件可通过命令行输入进行编辑或转换。

　　支持的操作系统：BSD, Linux,Mac OS X, Windows, UNIX

　　许可证：GPLv2

　　2. Virtuawin

　　VirtuaWin是一个Windows下的虚拟桌面管理器，可使用户显示多达20个虚拟桌面。该软件在后台运行，使用快捷方式对虚拟桌面进行访问。最重要的是，该程序还有一个移动版，可以让你在U盘里带着你的桌面。VirtuaWin支持双显示器，并具有可定制的系统托盘图标。

　　支持的操作系统：Windows 95以上

　　许可证：GPL

　　3. phpMyAdmin

　　phpMyAdmin可以用网络浏览器界面管理MySQL数据库。该软件使用PHP开发，可以使用全局数据库或使用自定义查询进行子集搜索，自定义查询可由Query-by-example(QBE)创建。phpMyAdmin可创建和删除数据库;创建，删除和变更表;删除，编辑和添加域;执行SQL语句。数据导入格式包括CSV和SQL，数据可以导出为CSV, SQL, XML, PDF, OpenDoc以及DOC, Excel和LATEX格式。还有一个把数据库布局存为一个PDF文件的功能。

　　支持的操作系统：跨平台，在浏览器中运行。

　　许可证：GPLv2

　　4. Pandora FMS

　　Pandora FMS(灵活监控系统)是一种小型和大型系统环境(一个服务器2000节点)的可用性和性能监视系统。对于本地系统，该软件使用代理来监视Linux, Solaris, FreeBSD, MAC OS X, Windows和AIX平台上的数值参数，布尔状态或字符串。使用者可以用Shellscript, WSH, Perl 或 C创建代理。 可通过SNMP v3, TCP检查和远程WMI探测来进行远程网络监视。 数据报告基于Pandora自己的SQL后台，且可在配置的屏幕上显示。

　　支持的操作系统：Linux

　　许可证：GPLv2

　　5. Process Hacker

　　Process Hacker是Windows下综合的进程查看器，功能不仅有结束进程，还有内存查看和编辑。这个工具特别有用的一点在于它可以绕过安全软件和系统防御，还有一些给力的可视化的功能，比如，一个线程等待的事件，重启进程的能力，创建进程dump，查看进程堆，注入DLL，内存转储为一个文件，编辑服务属性。

　　支持的操作系统：Windows 32位, 64位

　　许可证：GPLv2, GPLv3

　　6. Notepad++

　　Notepad++是一个方便的开源代码编辑器，可以替代Windows自带的记事本。不同于基本的Windows工具，该软件具有所见即所得的打印，书签，支持制表位，宏，启动开关，自动完成，语法高亮，放大和多文档支持等功能。该程序有一长串的功能，所有的编码工具都显示在工具栏上，它保持了多数Windows软件独有的那种轻量级的编辑器的外观和感觉。

　　支持的操作系统：Windows 95以上

　　许可证：GPL

　　7. Swiss File Knife

　　SFK在一个命令行功能里包括了96个功能。该工具包括任务类别文件系统命令(管理目录和目录树)，文件转换(如将十六进制数据转成二进制)，文本处理，文本/文件的搜索与比较(如在二进制文件中查找字段)，网络，脚本(比如运行HTTP和FTP服务器)，软件开发(包括二进制数据到源代码的转换)。

　　支持的操作系统：Windows XP以上，Linux (Ubuntu, DSL), Mac OS X

　　许可证：BSD

　　8. LDAP Admin

　　LDAP服务器上用来浏览，查询，修改，创建和删除对象的最好的目录管理工具之一，最近刚加入Unicode支持，一个增强的图片查看器，内容高亮，以及AD支持。作为LDAP Admin Tool 或 LDAP Administrator这种昂贵程序的免费替代品，功能设置还不是很广泛，但你仍能运行复杂的任务，比如在远程服务器间复制目录，修改数据集的操作，利用密码管理，管理Posix组和账户。

　　支持的操作系统：Windows

　　许可证：GPLv2

　　9. RackTables

　　如果电子表格已经不再是跟踪数据中心设备的理想方案，那么RackTables这样的资产管理程序也许是更有益的解决方案。使用该软件，你可以列举数据中心里的所有组件，包括硬件资产，网络地址，机架空间和网络配置。仍处于初期开发阶段，缺少一些功能，如有限的交换机支持，但是软件涵盖了IPv4/IPv6地址管理，802.1Q VLAN管理，CWDM与DWDM通道网格，以及通过CDP和LLDP的邻节点发现。

　　支持的操作系统：Windows, Mac OS X, Linux

　　许可证：GPLv2

　　10. Areca Backup

　　Areca Backup是一个简单，但非常有效的备份解决方案，让你选择一个一组文件或目录进行备份并配置自定义备份后行为。备份程序支持ZIP和ZIP64格式，AES128/256加密，本地或网络驱动器上的备份存储，文件过滤器增量备份，档案合并，数据恢复，备份报告。用户可以创建脚本，在备份完成时运行。软件有图形界面和命令行。

　　支持的操作系统：Windows 32位, Mac OS X, Linux

　　许可证：GPL

调查显示：大型机外包存在诸多隐患

　　Compuware对全球的首席信息官调查发现，多个隐藏的大型机外包交易费用给71%的首席信息官造成困扰。

　　该公司调查了全球范围内的520名首席信息官，发现其中67%的受访者对于他们外购商所提供的新的应用和服务不满，大致归为不断加大的内部技能差距，知识转移的难度以及外包商组织内部的人员变动。

　　Compuware大型机解决方案总监Neil Richards表示，他不相信外包商会故意隐藏成本，但是，"这些交易会变得异常复杂，结果很难预测。每笔合同都不尽相同。"

　　Richards称，大型机基础设施外包交易不如那些设计外包应用的交易复杂。他认为，一旦外包，外包商就没有太大的热情来调整大型机的最佳性能，这就是为什么57%的受访者认为外包商并不关心他们写的应用的执行效率，还有88%的受访者，他们的交易以CPU消耗为基础，他们相信自己的外包商可以把CPU成本控制的更好。

　　Richards表示，这类交易的问题包括缺少全面的文档，缺少内部大型机技能，有限的技术转让，以及把应用知识转交给外包商的难度。

　　受访者还表示，大型机的使用正在增加，MIPS的成本平均每年增加21%，40%的受访者声称，消费已经变得失去控制。然而Richards表示，一些公司正试图摆脱大型机的束缚："企业知道这些是关键人物系统，但是还需要提高外包交易的透明度，企业和外包公司需要共同合作来让双方的交易成功。"

App被App Store拒之门外的9个意外理由

　　要保证应用商店的健康生态环境、避免用户被一些低质量或恶意APP所扰，苹果App Store的审查制度就是为此而生。如果你的APP质量不低且不是恶意软件却仍被App Store拒之门外，可能是因为下边这几个原因。

　　1. APP描述中带"Beta"字样，或是其他表明APP还未开发完成的信息

　　苹果坚决杜绝那些未完成的应用进入App Store，包含"Beta"、"Preview"甚至"Version 0.9"都无法通过审核。

　　2. APP加载时间过长

　　iOS、Android以及Windows的操作系统对APP的启动时间都有一个上限要求，其中iOS APP的最长启动时间不得超过15秒。另外，在进行测试的时候，别只是依赖iOS模拟器，真机测试或是找一些型号较老的设备来测试，这样才能确保万无一失。

　　3. 给出外部购买链接

　　苹果规定App Store中所有数字内容只能通过iTunes购买，如果你的APP支持其他购买渠道，那肯定是没法通过审核的。值得注意的是，这条规定甚至延伸到你的应用的web页面，Dropbox就曾因为其web登录页面上包含其他用以购买空间的链接而被App Store拒绝。

　　非数字服务或商品是例外，比如通过APP在酒店订房间。

　　4. APP描述中提到了iOS之外的其他支持平台

　　谁都不希望在自己的地盘出现竞争对手的名字，这无异于打脸。所以，如果你的APP还适用于其他平台比如Android或是Windows，在你自己的网页上宣传就好，别写进APP描述里。不然苹果很生气，后果很严重…

　　5. 本地化问题没解决

　　即便不会遍及全球，你的APP也不会只限于一个地区使用。即便没有内置多种语言选择，涉及货币、日期时间等细节的问题你也需要考虑到，在提交审核之前就需要针对不同地区的体验进行测试。

　　6. 存储和文件系统使用不当

　　iOS 5.1发布之后，苹果曾拒绝了一个应用进行更新，因为该开发者将2MB的数据库压缩到文件系统中，违反了iCloud只备份用户生成内容的原则。

　　7. 未取得用户授权就崩溃

　　iOS 6操作系统中，APP需要获得用户授权才能访问地址簿、图库、地理位置、日历等等多个功能，即便用户拒绝其中任意一项，你的APP必须仍能继续正常运行。

　　有些用户可能最初拒绝后面又允许访问，你的APP也不能因为数据变更而无法工作。总之，在提交审核之前就必须进行全面测试，考虑到各种情况。

　　8. 图标和按钮使用不当

　　很多APP被拒通常不是因为产品功能本身有问题，而是因为一些UI细节。去熟读《苹果人机交互指南》，确保你的APP图标和按钮外观风格一致。

　　9. 误用商标和Logo

　　确保你的APP及任何相关图片中不要出现其他已注册的商标以及苹果的标志，甚至有因为关键字中含有其他商标的APP也被拒绝过。

　　如果你的APP被拒了也别太惊慌，按照苹果的反馈进行修改就是了;另外，苹果也有加急审核机制，适用于那些只是简单修复Bug或是安全问题的APP。不过，也别用太多次，不然就有可能永远被挡在App Store门外的。

中国服务外包向“内”转

中国服务外包研究中心副主任金世和透露，在今年2月国务院发布的《关于进一步促进服务外包产业发展的复函》中，已经将离岸服务外包的占比降至35%。这意味着，中国服务外包向"内"转已成为趋势。

日前，在天津举行的第二届中国服务外包领军者年会上，北京服务外包企业协会理事长曲玲年向国际商报记者表示："希望10年之后，中国服务外包行业在岸业务份额能达到90%。"

据国家服务外包产业发展中心主任王瑞介绍："目前，我国与印度相比，离岸外包的数量仅为印度的1/5，在岸业务数量则为印度的8倍。"这说明，我国国内市场潜力巨大，蕴含着无限商机。

转向有原因

服务外包向"内"转有部分原因是国际市场竞争力下降。曲玲年对记者说："近几年，国内部分企业的利润率已经由原来的15%～20%下降到5%～10%。其主要原因是人力成本上升。企业不可能通过降低人力成本来提高利润率。如果企业营收不能2倍于人力成本，行业不太可能保持前几年快速增长的态势。"

汇率风险也加大了企业离岸业务的压力。"印度卢比贬值，人民币持续升值，这也是拉开中印两国外包企业利润差距的原因之一。"曲玲年说。

当然，一些国内知名企业的日子相对来讲会好过一些，它们有更广阔的国际客户，也具有更强的承担风险的能力，这些风险包括汇率风险。"我们在与客户签订合同时会比较谨慎，要求双方对汇率风险共同承担，对于在中国设有分部的外企有些会进行人民币结算。"东软信息技术服务有限公司副总裁王凤对国际商报记者表示。

对于大多数外包企业，尤其是中小企业而言，离岸市场不容乐观。

国内市场如何释放

新一届政府提出，中国将刺激内需，使经济较少依赖于对外出口，坚持市场化的改革方向。

对此，曲玲年的理解是，对于服务外包产业，政府将进一步放手，以释放国内市场的需求。这种放开首先要从政府的外包业务开始。"只有政府的外包业务放开了，国企、央企的业务才会跟着放开，进而将全社会的需求释放出来。"

释放国内市场潜力的前提是，外包企业能够为包括政府在内的客户提供"双赢"的解决方案，创造新的商业模式。

曲玲年给记者举了个例子：华为通过对天津市电信局交换机冗余容量的研究，向电信方面提出了一个在天津市部分重点大学免费安装长途电话的解决方案，华为的利润从话费分成中获得。这个听起来很像LED照明领域的"合同能源管理"的方案，就是一个很好的"双赢"案例。

除此之外，商务部国际贸易经济合作研究院国际服务贸易研究所所长李钢还提出了几条在"政府放权"方面的政策建议，包括加大财政支持、扩大税收优惠、引导差异化人才培养、建立全国性服务外包机构等。

东软副总裁王凤同时提醒中小外包企业，应主动创新，避免在那些国内竞争已经非常激烈、利润空间不大的领域进行投入，否则将对扩大在岸业务起到反效果。

2013年外包行业值得企业捕捉的几大机遇

　　2013年，伴随世界经济的缓慢复苏、在岸市场的进一步开发，中国服务外包产业规模将继续呈现稳定上升的发展势头，合同签约金额及离岸合同执行金额有望分别突破900亿美元和460亿美元，同时产业聚焦点将更多地由"规模增长"转向"效益提升"。国家或将以提升发展水平为方向酝酿出台新一轮产业政策。除延续现有税收优惠等政策外，有望在推动产业规范化、促进在岸市场发展、提升产业价值、开拓海外市场、鼓励特色发展、加强培训资源管理等方面加大支持力度，以推动我国服务外包继续健康、快速发展。

　　2013年，服务外包企业将加速步入转型升级快车道。那么，2013年，究竟哪些机遇值得企业捕捉?

　　新兴市场继续升温

　　2013年，随着新兴市场经济发展和社会环境的改善，预计服务外包企业对这些地区的关注将继续升温，从而使来自东南亚、拉美等市场的服务外包业务有所增加。

　　金融危机爆发后，欧美等发达国家经济不景气，促使服务外包企业越来越注重新兴市场开拓，而低成本制造业向新兴、欠发达地区的大量转移，恰恰为服务外包企业开拓新的业务市场提供了契机，上海、杭州、厦门、深圳等许多城市的服务外包企业都陆续开始向东南亚、拉丁美洲等新兴市场拓展业务。

　　大数据服务将获大幅增长

　　2013年，将有越来越多的行业用户尝试大数据平台及其服务。

　　信息技术的发展带动了数据源种类和数据量的持续快速增加，前所未有的庞大数据集给传统的数据库和信息基础架构带来难题。随着大数据价值不断被认识发掘，在金融风险管控、智能控制、社交营销等各方面所带来的思维方式转变和商业模式变革，将成为改变企业竞争力的重要因素，从而触发数据存储、数据分析、数据处理等外包服务业务的新一轮增长。

　　制造业服务化将成重要增长点

　　报告称，外部经济不景气、产品出口需求减缩、市场供过于求，许多制造企业已步入微利时代，如何寻求产业突围路径、找到新的利润增长点和发展方向，正成为越来越多制造企业关注的焦点。其中，服务外包无疑成为一个重要的突破口，不少大型制造类企业正逐步向服务型企业转型，向微笑曲线两端发展。随着这些企业的加盟，2013年，制造业服务化很可能成为中国服务外包的一个重要增长点。

　　"智慧城市"建设将成外包新动力

　　报告称，2012年12月5日，住建部正式发布《关于开展国家智慧城市试点工作的通知》，并印发了《国家智慧城市试点暂行管理办法》和《国家智慧城市(区、镇)试点指标体系(试行)》，我国"智慧城市"建设将进一步加快，相关投资规模或有大幅增长。由此，与平安城市、电子政务、数字医疗、智能交通、智能建筑等相关的系统和平台开发、IT运营维护、信息化规划咨询、数据处理分析等服务外包领域，也将在2013年逐渐获得新的发展动力，有望迎来新一轮快速增长。

　　电子商务继续拉动外包商机

　　报告预测，2013年，随着规模扩大和竞争加剧，电子商务人才紧缺、平台建设成本投入大等问题日益突出，将为电子商务平台建设、运营维护、数据分析处理、客户服务、物流规划等相关外包服务带来巨大的商机。相关服务外包企业在助力传统企业涉水电子商务的过程中，将更加专注修炼专业服务的扎实功底，开发和形成整体解决方案的服务模式。

IT外包：CIO关注的3个核心问题

　　69%的受访企业2012年度外包业务投资总额不少于100万元。其中，25%为100～200万元，16%为500～1000万元。

　　2013年1月8日，在ITValue联合IBM举办的"探寻IT轻资产高端CIO研讨会"上，50余位与会CIO共同就IT轻资产与IT外包的话题展开激烈讨论。

　　会议前期，ITValue曾联合ValueResearch展开一项相关调研。数据显示，88%的受访企业的外包主要类型为信息技术外包(ITO)、业务流程外包(BPO)和知识流程外包(KPO)所占比例则非常低。

　　结合会议现场讨论、此项调研结果以及ITValue社区内的相关在线讨论，ITValue梳理出了CIO对IT外包最为关注的3大核心话题。

　　国内外包有何变化趋势?

　　IBM全球业务咨询业务规划和解决方案经理林波：在变化不定的环境中，全球化、人口转移、社交网络与移动技术、数据激增，这4大趋势正在影响企业在信息科技应用发展和投入。基于这样的内外部环境，企业CIO需要通过领先的技术优势与跨部门的无缝协同，支持CEO的议程，抓住"复杂性"的机会，推动企业持续增长。合理有效的IT外包可以协助企业改造与集成业务流程和业务设计、把固定成本转化为可变成本、优化信息化资源的利用、灵活应变、防患于未然、保障业务连续性。

　　IBM资深解决方案架构师刘登科：从外部环境来看，CIO面临很多的外部挑战和业务需求。针对国内的企业客户，IBM提出来一个下一代IT服务的战略伙伴关系，体现在4个方面，就是协作、前瞻、整合和灵活。当然，服务交付模式也在变化，自建自管、自建共管模式和云端交付模式。这种转变能够帮助企业降低费用，支撑业务转型，带来更大的价值。

　　金融街控股股份有限公司IT经理董勤林：毋庸置疑，外包是大多数企业信息化发展过程中不可或缺的一支力量。但是，不能简单地以资产规模来衡量所需的IT人员数量，这与行业特点、发展阶段、外包精细化程度、需求更新速度等都有密切关系。

　　不同企业阶段和信息化阶段，选择外包的策略有何不同?

　　IBM资深解决方案架构师刘登科：从我们的角度讲，任何企业在任何阶段都是可以有东西拿得出来外包的，但是外包与否，或者是外包什么内容，是有很多制约因素的。

　　福州总医院计算机应用与管理科主任/高工陈金雄：在目前国内企业管理尚不够规范、提供IT服务的企业自身能力还不够强大的情况下，盲目提倡外包风险巨大，值得深思。

　　上海相宜本草化妆品股份有限公司副总裁于筱静：IT外包的前提是公司管理体系已经十分稳定和成熟。内部员工也比较适应和接受这样的应用环境。做到这一步，不只是IT部门的努力就足够的，公司领导层的管理意图是否清晰，业务目标是否明确，对IT的定位是否合理，都是至关重要的。

　　CIO如何与第三方公司一起合作共赢?

　　IBM全球业务咨询业务规划和解决方案经理林波：确认IT的应用组合，确认IT的基础架构，确认IT的项目组合，确认IT的服务水平要求。

　　均瑶集团行政总经理、信息总监吴大为：能买的绝不自己开发，避免对开发人员的依赖;要开发就找好企业来开发，保证售后服务水平;广借外脑，与各大高校和企业的专家合作;要擅长联合各部门，培养下属并充分授权，与业务部门和下属共同发展;由业务需求驱动系统发展……

　　无锡世成晶电柔性线路板有限公司IT Manager方迅：IT外包从来就不缺技术，缺的是规范、响应速度、成本和企业内部对IT要求不断提升的一种平衡。但是，是否外包与企业背景有关系，对IT资源需求不平衡的企业，外包也是一个非常好的解决方案。项目经理甲方把控，这样能很好的控制项目以保证质量和成本。"

软件项目管理中的10个误区

　　随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。计算机软件开发从"个人英雄"时代向团队时代迈进，计算机软件项目的管理也从"作坊式"管理向"软件工厂式"管理迈进。这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法，完成思想观念上的转变。以下列举了10个在现代项目管理中思想观念上容易陷入的误区，希望能够抛砖引玉，引发大家更多的思索和讨论。

　　误区1：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明"软件项目的需求可以持续不断的改变 ，而且这些改变可很容易地被实现"。实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶 段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在软 件版本发布以后，甚至可能要花费60-100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少，容易被实现。

　　误区2：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。分析：软件程序测试可以分为"白盒法"和"黑盒法"两种方式。由于使用"白盒法"对测试人员各方面素质的种种要求，在进行程序测试时 测试人员总是最优先使用"黑盒法"。他们的工作方式往往是先对程序进行"黑盒法"测试；如果测试没有通过，不得已这才考虑对程序代码 进行"白盒法"测试。显然，这种对"白盒法"有意无意的"逃避"，对软件的可靠性和稳定性构成了威胁。如何解决这个问题？一方面需要 提高对测试人员的要求，另一方面也需要程序员完成部分的"白盒法"测试（实际上，程序员往往也是进行"白盒法"测试的最佳人选）。

　　误区3：软件项目管理只是相关技术部门的事情，与公司其他部门无关。在竞争日益激烈的今天，软件项目规模大、复杂度高而且时间要求紧迫。要想提高公司的软件项目管理水平，这就需要提高公司的整体参与意识，需要公司各个部门协同作战。例如需要会计部门协助进行项目预算，财务管理和费用控制；需要研究部门（技术委员会）指派专家 协助进行各种风险评估，提供技术指导；需要后勤部门提供各种保障。

　　误区4：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。分析：在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业 有一定了解，并且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围；那么"新人"的加入是有益的。否则，可能会"好心好意做坏事"。因为尽管其个人能力很高，但是为了使其与大家一起协同工作，开发团队不得不分出人手对其进行与项目有关的技术/业务培训，更重要的（也是难度最大的）是还要引导其融入团队。这可能需要花费开发团队许多时间和精力，很有可能使项目进度更慢。

　　误区5：技术骨干应该成为项目的项目经理，项目经理一定是所有项目成员中薪水最高的。分析：在"软件作坊"时代，这是一种普遍使用而且效果不错的方法；而在"软件工厂"时代，这种方法却带来各种问题，有时甚至直接导致 项目失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发生了根本的改变--最注重的不是其对某项专业技术 的掌握程度，而是其组织、领导、协调开发团队的能力（当然，可以两者均突出最好）。至于项目经理的薪水问题，这和定薪制度有很大关系。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的，但不一定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。

　　误区6：只有项目经理以及部门主管才会关心项目整体进度，程序员只关心自己的开发进度。其实这是一种"官僚"的想法。实际上程序员作为团队中的一员，他不仅仅是在打一份工，更重要的是在参与一件"作品"的创作。在体味工作的辛苦的同时，程序员更重要的是要享受创作的快感。项目经理不应该漠视程序员对"成就感"的追求，应该向每一个人详细描述最终"作品"将会如何美妙和令人兴奋，并且在到达最终目标的路上设立一系列的里程碑。每当项目整体推进到一个里程碑的时候，项目经理应该把 这个消息告诉每一位项目成员，这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作效率。

　　误区7：更大的压力可以带来工作效率的提高。软件公司的员工加班情况是时常发生的，对员工增加工作压力、要求加班赶进度，这种方式在初期可以略微提高生产力，因为员工喜欢压力，并且集中精力于项目任务，全力投入。中等压力或许可以将生产力提高25％，甚至使总的交付时间缩短25％。但是只有在压力处在适当的范围时，情况才是这样。压力再大点，增加的压力将不会产生作用，毕竟人的能力是有限的，当员工面对巨大的压力而习以为常时，会将普通的工作量占满整个工作时间，导致实际的生产力下降。如果压力再大一些，员工开始疲惫，直到筋疲力尽，甚至灰心丧气，他们对项目不抱有什么积极的态度，此时的项目结局可想而知。

　　误区8：使用高级语言可以大大提高项目进度，缩短交付期。高级语言相对于他们的前辈确实效率大大提高，程序员使用之可以提升编码速度，从而使整个项目的开发周期缩短；但是在完整的软件生命周期中，编码活动一般仅占总时间的20％左右，而需求搜集和分析、高层设计、测试等活动却无法从高级语言的使用中获益，所以不要认为运用了高级语言就可以制定一个"激进而且安全"的项目进度计划。

　　误区9：小型项目不需要严格的流程控制。小型项目由于涉及的人员较少，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别；开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。往往觉得"把这些事情（流程管理、项目文档）都做完的话，项目就永远做不完了！"事实是如果项目中不做这些事，就得花更久时间才完成得了。

　　误区10：软件产品的质量完全取决于过程。事实上产品的质量受到人员、技术和过程三个要素制约，片面强调过程决定质量就好像认为只有明星程序员才能开发出合格的软件一样片面。而且低劣设计和良好设计之间的区别可能在于设计方法中的完善性，而良好设计和卓越设计之间的区别肯定不是如此。卓越设计来自卓越的设计人员。软件开发是一个创造性的过程。完备的方法学可以培养和释放创造性的思维，但它无法孕育或激发创造性的过程。

如何处理开发和软件测试工程师之间的关系

　　在整个项目中，其实开发和测试是一个团队，团队的目标是一致的，提高软

　　件的质量。但是工作当中因为职责的不一样，往往可能会造成分歧。为了更好的

　　配合开发，测试人员要把握好以下几点：

　　1）报告问题时，要尽量描述清楚，语句简洁明了，尽量找出问题出现的关键，以帮助开发尽快找出解决问题的办法

　　2）对于不容易复现的问题，要尽量提供全面的信息，如当时手机的电量，后台程序，自己之前做了什么操作（提供的越多越好），出现问题后又做了什么操作有什么结果。根据这些条件尽量帮助开发复现。

　　3） 严重问题且不容易复现的，可以保留现场让开发过来现场研究，这样有两个好处，一是开发可能根据目前状态查到一些原因，二是如果今后不复现开发也不能抵赖，因为他见过此问题的出现。

　　4）如果开发和测试对于一些问题是否要解产生了争议，那就从用户的角度出发看看这个问题对于用户是否可以接受，会不会造成退机或者用户很讨厌的问题之一，如果是，就写成强有力的原因说服开发去解或者让他们推迟解决（最终是解了），也可以求助自己的领导或者专家来和开发工程师及开发经理来协商解决方案。对于严重影响用户使用或感受的问题一定要提出来，这样今后一旦出现什么用户投诉自己可以免责

　　5）多做换位思考，遇到问题与开发打交道时多从他们的角度看问题，遇到有可能伤害其利益的问题可以事先和开发商量一下如何处理。如原本fixed的问题又复现了是要repen还是要重新报一个呢，很多人直接reopen了，这样做其实会影响开发的绩效，可以和他们协商一下是不是重新报一个对他们比较好，因为开发有很多绩效考核的算法。

　　6）多与开发沟通，如他们怎样看待我们提出的问题，他们是否理解我们的工作，我们提出的问题他们又是怎样的流程和制度来fix，了解了他们的工作对于我们今后的工作安排也会有很大的好处。

如何提高php代码的质量

　　1、- DRY： Don't repeat yourself

　　DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

　　DRY 这一法则可能是编程届中最通用的法则了，目前为止，应该没有哪个程序员对这一法则存有异议。但是，我们却能发现，一些程序在编写单元测试（unit testing）时忘记了这一法则：让我们相像一下，当你改变一个类的若干接口，如果你没有使用DRY，那么，那些通过调用一系例类的接口的unit test的程序，都需要被手动的更改。比如：如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法，而是每个test case自己去构造类的实例，那么，当类的构造函数被改变时，你需要修改多少个test cases啊。这就是不使用DRY法则所带来的恶果。

　　2、- 短小的方法

　　至少，我们有下面三个不错的理由要求程序员们写下短小的方法。

　　代码会变得更容易阅读。

　　代码会变得更容易重用（短方法可以减少代码间的耦合程度）

　　代码会变得更容易测试。

　　批注：我们一般要求每个函数不超过一屏幕，for循环不超过三层，主要是为了阅读方便，但是刻意去为了短小而简化函数最后代码的可维护性也不是很强，所以根据具体业务去处理，函数的职责是做什么，这个函数里面哪些可以公用出来独立为方法的，哪些写法可以简化，这些方面需要去思考。

　　3、- 良好的命名规范

　　使用不错的统一的命名规范可以让你的程序变得更容易阅读和维护，当一个类，一个函数，一个变量的名字达到了那种可以"望文生义"的境界话，我们就可以少一些文档，少一些沟通。文章《编程中的命名设计那点事 》可以给你一些提示。

　　批注：命名不规范 相当于整个项目会看起来很乱，命名要求通俗易懂，不要太长。

　　4、- 赋予每个类正确的职责

　　一个类，一个职责，这类规则可以参考一下类的SOLID 法则。但我们这里强调的不是一种单一的职责，而是一个正确的职责。如果你有一个类叫Customer，我们就不应该让这个类有sales 的方法，我们只能让这个类有和Customer有最直接关系的方法。

　　5、- 把代码组织起来

　　把代码组织起来有两具层次。

　　物理层组织：无论你使用什么样的目录，包（package）或名字空间（namespace）等的结构，你需要把你的类用一种标准的方法组织起来，这样可以方便查找。这是一种物理性质的代码组织。

　　逻辑层组织： 所谓逻辑层，主要是说，我们如果把两个不同功能的类或方法通过某种规范联系和组织起来。这里主要关注的是程序模块间的接口。这就是我们经常见到的程序模块的架构。

　　6、- 创建大量的单元测试

　　单元测试是最接近BUG的地方，也是修改BUG成本最低的地方，同样也是决定整个软件质量好坏的成败的地方。所以，只要有可能，你就应该写更多的，更好的单元测试案例，这样当你未来有相应代码改变的时候，你可以很简单知道你代码的改变是否影响了其它单元。

　7、- 经常重构你的代码

　　软件开发是一种持续的发现的过程，从而让你的代码可以跟上最新的实际需求的变化。所以，我们要经常重构自己的代码来跟上这样的变化。当然，重构是有风险的，并不是所有的重构都是成功的，也不是我们随时都可以重构代码。下面是两个重构代码的先要条件，以避免让你引入更多的BUG，或是把本来就烂的代码变得更烂。

　　有大量的单元测试来测试。正如前面所说，重构需要用大量的单元测试来做保障和测试。

　　每次重构都不要大，用点点滴滴的小的重构来代替那种大型的重构。有太多的时候，当我们一开始计划重构2000行代码，而在3个小时后，我们就放弃这个计划并把代码恢复到原始的版本。所以，我们推荐的是，重构最好是从点点滴滴积累起来的。

　　8、- 程序注释是邪恶的

　　这一条一定是充满争议的，大多数程序员都认为程序注释是非常好的，是的，没错，程序注释在理论上是非常不错的。但是，在实际过程序当中，程序员们写出来的注释却是很糟糕的（程序员的表达能力很有问题），从而导致了程序注释成为了一切邪恶的化身，也导致了我们在阅读程序的时，大多数时候，我们都不读注释而直接读代码。所以，在这里，我们并不是鼓励不写注释，而是——如果你的注释写得不够好的话，那么，你还不如把更重要的时间花在重构一下你的代码，让你的代码更加易读，更加清楚，这比会比注释更好。

　　批注：个人认为，注释是必须的，但是注释表达一定要清晰，没有注释的代码是邪恶的。

　　9、- 注重接口，而不是实现

　　这是一个最经典的规则了。接口注重的是——"What"是抽象，实现注重的是——"How"是细节。接口相当于一种合同契约，而实际的细节相当于对这种合同契约的一种运作和实现。运作是可以很灵活的，而合同契约则需要是相对需要稳定和不变的。如果，一个接口没有设计好而需要经常性的变化的话，那我们可以试想一下，这代来的后果，这绝对会是一件成本很大的事情。所以，在软件开发和调设中，接口是重中之重，而不是实现。然而我们的程序员总是注重于实现细节，所以他们局部的代码写的非常不错，但软件整体却设计得相对较差。这点需要我们多多注意。

　　批注：接口相当重要，现在的项目做过很多接口方面开发，接口的变动是致命的。

　　10、- 代码审查机制

　　所有人都会出错，一个人出错的概率是很大的，两个人出错的概率就会小一些，人多一些，出错的概率就会越来越小。因为，人多了，就能够从不同的角度看待一个事情，虽然这样可能导致无效率的争论，但比起软件产品release后出现问题的维护成本，这点成本算是相当值得的。所以，这就是我们需要让不同的人来reivew代码，代码审查机制不但是一种发现问题的最有效的机制，同时也是一种可以知识共享的机制。当然，对于Code Review来说，下面有几个基本原则：

　　审查者的能力一定要大于或等于代码作者的能力，不然，代码审查就成了一种对新手的training。

　　而且，为了让审查者真正负责起来，而不是在敷衍审查工作，我们需要让审查者对审查过的代码负主要责任，而不是代码的作者。

　　另外，好的代码审查应该不是当代码完成的时候，而是在代码编写的过程中，不断地迭代代码审查。好的实践的，无论代码是否完成，代码审核需要几天一次地不断地进行。

　　批注：代码Review可以提供代码水平和质量，是一个非常好的控制代码。

传统软件测试中存在的问题及解决方法

　　传统的软件测试流程：一般是在软件开发过程中进行少量的单元测试。然后在整个软件开发结束阶段，集中进行大量的测试，包括功能和性能的集成测试和系统测试。随着软件开发的越来越复杂，传统的软件测试流程不可避免的给我们带来以下问题：

　　问题一：项目进度难以控制，项目管理难度加大。

　　大量的软件错误往往只有到了项目后期系统测试阶段才被发现，解决问题花费的时间很难预料， 经常导致项目进度无法控制，同时在整个软件开发过程中，项目管理人员缺乏对项目质量的了解和控制，加大了项目管理难度。

　　问题二：对项目风险的控制能力较弱项目风险在项目开发较晚的时候才能够真正降低。往往是经过系统测试之后，才真正确定该设计是否能真正满足系统功能、性能和可靠性方面的需求。

　　问题三：软件项目开发费用超过预算。在整个软件开发周期中，错误发现的越晚，单位错误修复成本越高，错误的延迟解决必然导致整个项目成本的急剧增加。

　　IBM Rational 软件自动化测试最佳成功经验解决传统测试问题。

　　核心的三个最佳成功经验是：尽早测试、连续测试，自动化测试，并在此基础上提供了完整的软件测试流程和一整套的软件自动化工具，使我们最终能够做到：一个测试团队，基于一套完整的软件测试流程，使用一套完整的自动化软件测试工具，完成全方位的软件质量验证。

　　成功经验一：尽早测试

　　所谓尽早测试是指在整个软件开发周期中通过各种软件工程技术尽量早的完成各种软件测试任务的一种思想。IBM Rational 主要在以下三个方面为我们提供的尽早测试的软件工程技术：

　　首先，软件的整个测试生命周期是与软件的开发生命周期基本平齐的过程。即当需求分析基本明确后我们就应该基于需求分析的结果和整个项目计划来进行软件的测试计划；伴随着分析设计过程同时应该完成测试用例的设计；当软件的第一个发布出来后，测试人员要马上基于它进行测试脚本的实现，并基于测试计划中的测试目的执行测试用例，对测试结果进行评估报告。这样，我们可以通过各项测试指标实时监控项目质量状况，提高整个项目的控制和管理。

　　项目计划、需求管理―――测试计划

　　测试计划、分析设计―――测试设计

　　测试设计―――测试实现

　　测试实现―――测试结果评估

　　其次，通过迭代是软件开发把原来的整个软件开发生命周期分成多个迭代周期，在每个迭代周期都进行测试，这样在很大程度上提前了系统测试发生的时间，这在很大程度上降低了项目风险和项目开发成本。

　　最后，IBM Rational的尽早测试成功经验还体现在它扩展了传统测试阶段从单元测试，集成测试到系统测试、验收测试的划分，将整个软件的测试按阶段划分成开发员测试和系统测试两个阶段。它把软件的测试责无旁贷的扩展到了整个开发开发人员的工作过程。通过提前测试发生的时间来尽早的提高软件测试的质量、降低软件测试成本。

　　成功经验二：连续测试

　　测试成功经验连续测试是从迭代式软件开发模式得来的。在迭代化的方法中，我们将整个软件的开发目标划分为一系列更易于实现和达到的小目标，这些小目标都有定义明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而从事的一系列开发活动，在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划，而且每个迭代过程中都包括需求，设计，编码，集成，测试等一系列的开发活动，都会增量式集成一些新的系统功能。通过每次迭代都产生一个可运行的系统。通过对这个可运行系统的测试来评估该次迭代有没有达到预定的迭代目标，并以此为依据来制定下一次迭代目标。由此可见，在迭代式软件开发的每个迭代周期，我们都会进行软件测试活动，整个软件测试的完成是通过每个迭代周期不断增量测试和回归测试实现的。

　　成功经验三：自动化测试

　　在整个软件测试的过程中都要尽早测试，连续测试，可以说完善的测试流程是前提，自动化测试工具是保证。IBM Rational的自动化测试成功经验主要是指利用软件测试工具提供完整的软件测试流程的支持和各种测试的自动化实现。

　　为了使软件测试团队更好的进行测试，IBM Rational在提供了测试成功经验之外，还为我们提供了一整套的软件测试流程和自动化测试工具，使软件测试团队可以从容不迫地完成测试任务。

对于敏捷的五大误解

　　误解一：敏捷对人的要求很高

　　很多人在尝试实施敏捷时说：敏捷对人的要求太高了，我们没有这样的条件，我们没有这样的人，因此我们没法敏捷。可是，敏捷对人的要求真的那么高么？

　　软件归根到底还是一种创造性活动，开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用，各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作，从而产生更高的生产力。不管用什么方法，开发人员的水平永远都是一个主要的因素。

　　从另一个角度来看：过程和方法究竟能帮开发人员多大忙？对于技术水平较低的开发人员，敏捷方法和传统方法对他的帮助是差不多的，因此看不到显著的效果，甚至有些时候还有反效果；而随着开发人员技术水平的提高，敏捷方法能够解开对人的束缚，鼓励创新，效果也会越来越显著。

　　敏捷对人的要求并不高，而且会帮助你培养各种所需的能力，当然前提是你处在真正敏捷的环境中。

　　误解二：敏捷没有文档，也不做设计

　　这个误解从XP开始就没有停止过，XP鼓励"在非到必要且意义重大时不写文档"。这里面提到的"必要且意义重大"是一个判断标准，并不是所有的文档都不写。例如，用户手册是不是"必要且意义重大"？这取决于客户的要求，如果客户不需要，那就不用写，如果客户需要，就一定要写；再如，架构设计文档要不要写？复杂要写，不复杂不用写。通常架构设计只需要比较简单的文档，对于有些项目，一幅简单的UML图就够了。因此，写不写，怎么写，都要根据这个文档到底有多大意义，产出和投入的比例，以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定，尽量避免由某一个人（比如lead）来决定。

　　至于设计，XP奉行的是持续设计，并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中，不断的设计、改善（重构），使得设计一直保持灵活可靠。至于编码前的预先设计，Kent Beck等人确实实行着不做任何预先设计的开发方式，但是对于我们这些"非大师"级开发人员，必要的预先设计还是需要的，只是不要太多，不要太细，要有将来会彻底颠覆的准备。

　　误解三：敏捷好，其他方法不好

　　有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好，而提到CMMI等方法就大呼不好，不管是什么只要沾上边就哪里都不好，似乎敏捷和其他方法是完全对立的。牛顿说过，我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点，也是站在了巨人的肩膀上，敏捷依然保持了很多历史悠久的实践和原则，只是表现方式不同罢了。

　　从另一个方面来看，方法本没有好环，好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境，在需求稳定、软件复杂度相对不高的时代，瀑布模型也可以工作的很好，而敏捷恰好适用于变化快风险高的项目 － 这恰恰是现在很多项目的共性。

　　因此选择一个方法或过程，并不是根据它是否敏捷，而应根据它是否适合。而要了解一个东西是否适合，还是要尝试之后才知道，任何没有经过实践检验的东西都不可信。

　　误解四：敏捷就是XP，就是Scrum

　　XP和Scrum只是众多敏捷方法中的两种，还有很多其他的敏捷方法。龙生九子各个不同，敏捷的这些方法看起来差别也是很大的，可是他们之所以被称为敏捷方法，就是因为他们背后的理念和原则都是相同的，这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践，还要理解实践后的原则，不仅要理解怎么做，还要理解为什么这么做，以及什么时候不要这么做。

　　即使将XP或Scrum完全的应用的你的项目中，也未见得就能成功，适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点，但绝对不是终点，最适合你的方式还要由你自己在实际工作中探索和寻找。

　　误解五：敏捷很好，因此我要制定标准，所有项目都要遵循着个标准

　　没有哪两个项目是一样的，客户是不一样的，人员是不一样的，需求是不一样的，甚至没有什么可能是一样的。不一样的环境和问题，用同样的方法解决，是不可能解决的好的。方法是为人服务的，应该为项目团队找到最适合他们的方法，而不是先确定方法，再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

　　同时，对于同一个团队，随着项目的进行，对需求理解的深入，对技术理解的深入，一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整，保证项目的质量和效率。敏捷是动态的，而非静止不变的，因为这个世界本身就是变化的，在变化的世界使用不变的方法，是不现实的。银弹从来就没有过，在有限的将来也不会存在。