摘要: 记 得几年前如果你需要添加一些互动元素到你的网站中用来改善用户体验？ 是不是立刻就想到了flash实现？这彷佛年代久远的事了。使用现在最流行的web技术 HTML5，CSS3和jQuery，同样也可以实现类似的用户体验。而且使用这些特性将会比使用flash更加有效。也许你可能刚知道Adobe停止开 发移动版flash的消息，虽然在桌面中我们还拥有大量的flash的应用，但是随着HTML标准的完善，...
阅读全文
摘要: http://www.oschina.net/news/23206/25-useful-html5-cheat-sheets-and-tutorials-for-web-developerweb开发者必须尽快熟悉并使用起HTML5，因为它在web端开发的发展趋势已经明朗，可以用来创建丰富多彩的效果。使用HTML5还是有一些复杂的，所以本文介绍了25个优秀的HTML教程及小手册，欢迎大家使用。Mak...
阅读全文
小C所在公司目前现状：
开发人员30人左右，项目型团队。
测试人员：小C、本科学历、测试工作经历1年；
职责范围：编写测试用例，测试执行，编写帮助文档、产品对外沟通和培训等；
抱怨理由：工作量大，经常加班，无加班费，工作压力大，薪水不见长；产品出了问题首先责问测试人员；在这个公司没学到什么知识，目前所做的也都是一些苦力活；不
知道做这些有没有什么发展，现在很迷茫，想辞职，又怕错过这个发展机会。。。
小C的问题很普遍，虽然以前的答复都类似，但还得重新组合一下回复的思路：
首先，小C是否明确了自己在测试行业里的发展规划，如果已定位测试职业规划，那么就不考虑该跳槽，换行业的思考；
1、工作量大，经常加班，无加班费；
偶认为是第一个问题是最主要的，为什么工作量大，先分析清楚这个，然后再找对策；
着手点在小C的岗位职责是否明确，小C是否知道哪些工作是自己份内的事，哪些是份外的事情；如果是份内的事情，工作量大是经常还是偶然，换个角度去思考问题，从自己本身问题找起，如果有公司流程和管理混乱或其他原因导致，那么就可以跟领导说个1、2、3来，这点是小C自己要能分析和总结出来的，别人帮不了；如果是份外的事情导致自己工作量大，那么就需要沟通和协调；
总的来说，小C应该把自己的工作量化出来，哪些事该做？工作计划和时间安排，一一罗列出来，即便变化很大，也不能失去工作计划这个主线；事情清楚了，给领导也能有一目了然的交代和认知，
偶想小C加班的事情领导肯定也看在眼里，如果你能把这些信息反馈给上级并能让自己的作用在这个岗位上发挥到重要的作用上，那么薪水报酬自然是领导应该去考虑的问题，小C也就不会在抱怨了，动力有了工作也就不会那么压抑了；
2、工作压力大
一方面说明小C责任心强，也许还有点不自信都在里面，偶想小C要明确的告诉领导，产品出了质量问题，最主要的原因不能落在测试人员身上，这是测试行业里最明白和浅显的道理，不再详细讨论，小C应该做的是总结原因，修改用例，避免下次再出现这样的问题遗漏现场；小C也不要太在意这个信息的反馈给自己心理带上枷锁，因为测试行业本身就在夹缝中生存和发展，心态要平和一些；
3、没学到什么知识
老话说：平凡的岗位上也能出人才。就看什么样的人、用什么样的态度和方法去面对这个平凡的岗位，从小C反馈的信息来看，能力还是比较全面，领导也安排了很多资料的编写这样的工作，说明小C在这个团队里还是有事可做的，事情虽然看上去比较简单但如果要做好这些事情，还真不是那么容易，对小C来说也是一个很好的锻炼机会，先跳槽之前，先问问自己，我真的满足了这个岗位需求？我真的把工作做得很好了？我在这个团队里没有发展空间了？每个公司都会有这样或那样的问题，但首先我们先考虑自身的问题，先想好，然后再做。
4、目前的待遇和付出不成比例
80%的人或许都有这样的想法，首先还是要综合分析一下原因，横向、纵向有个比较，个人的发展和公司的发展是紧密相联的，你是否是以主人翁的态度去面对这份工作，你的领导认为你还有哪方面的不足和需要提高的地方？你是否跟领导有很高的沟通？每个公司都有涨薪水的要求和规则，你是否符合条件？
抛开以上问题外，如果问题真出在公司环境上，在工作中无法寻找到兴趣和乐趣的话，那就把工作当成一个纯粹的工作。在这个岗位上暗自努力，积累经验，做好下次跳槽的准备！
解决这个问题还有一个办法就是小C在工作之外去求职，经过求职和面试的过程，会让你获得一些感悟，即保住了目前的工作，也帮助自己认识到自身的优点和不足，然后再在工作和学习中去改进自己的缺点和不足，此意见仅供参考~！呵呵，如果被公司领导发现你在另谋出路，也许他对你的信任度又将降低了~！
总之，遇到问题的时候办法，先从自身问题开始反省，然后再分析外部原因，换位思考，做个有心的人~！
大多数数据库都自带了同步方案，但通常是同步到同一类型的数据库。在一些特定的情况下，我们可能希望把数据从一种数据库，同步到另一种数据库，以便进行数据分析、统计、挖掘等，或是完成实时监控、实时搜索等服务。
本文介绍的就是这样一个方案，把数据从NoSQL数据库ttserver同步到MySQL上。
数据的同步过程基本上可以分解成：获取、解析、识别、处理。
获取同步（replicating）过程基本上就是处理高性能网络交互、各层通信协议、基于安全考虑的身份验证等问题的过程。解析（parsing）过程主要处理具体数据结构，由分派器（dispatcher）分派给具体的识别器（recognizer）进行识别。最终由处理器调用数据访问层完成整个过程。基本过程可见下方草图：
以上只是一个简化的草图，实际完成的时候，还有很多细节需要处理，如，
1）快照点的选择，以及生成快照点的方案。不稳定的数据是没用的；
2）协议、数据结构的可配置化。不同的场景下只需要简单配置，就能满足具体业务；
3）对前后端数据服务的抽象。只有抽象化，才能让它成为一个有生命力的方案；
4）高处理能力。异步、非阻塞、多worker、操作合并；
5）考虑对协议升级的兼容方案；
6）可支持前后端数据迁移、数据分片；
7）前后端多实例同时使用；
8）全局同步与增量同步方案同时支持，新同步点支持；
9）各种可能的出错：网络、数据、服务等处理、监控、告警；
10）稳定性、可用性；
11）完备的统计数据。方案做得怎么样，总要有数据才好说话吧：）
顺带把部分初期概念设计图放出来。后来已经有一些演变，但只是少数环节上。在大部分的环节上，基本思路没有太大的变化。
经过一段时间的奋战把方案实现出来，功能验证也比较顺利通过了，实战又将跑得怎么样？具体业务及性能数字未经同意不准备在此公布，但可说侧面说一下。目前，该方案上线应该已经将近一年，除了少数几次前端迁移以外，未停过服。性能方面，一年后，在业务已经有量级发展的情况下，该方案仍能满足需求。
另外，虽然命名为tt2mysql，我从未把该方案当成是数据库之前的同步方案。以前说过会把东西总结出来，一直太懒，翻到了就写一下。
大家讨论使用Gearman做分布式处理时，各机需要注册一个独立的job作为信息反馈，但是为了方便，Gearman::Worker脚本register_function代码又要通用，于是想到了使用各自的ip地址作为job命名~
那么怎么在worker脚本里获取本机ip作为func呢？
第一种办法，最简单的，调用shell：
| $ip = `ifconfig eth0|grep -oE '([0-9]{1,3}\.?){4}'|head -n 1`; |
注：这里输入是固定的，所以简单的[0-9]{1,3}了，如果是在web程序等地方验证ip，需要更严谨！
或者
| $ip = `ifconfig eth0|awk -F: '/inet addr/{split($2,a," ");print a[1];exit}'`; |
好吧，这样显得太不perl了，而且频繁的调用外部shell不太好，第二种：
open FH,"ifconfig eth0|";
while(<FH>){
last unless /inet addr:((\d{1,3}\.?){4})/;
print $1;
} |
看起来稍微perl了一些，虽然实质跟上面的调用shell和grep法是一样的。
第三种，更perl一点，纯粹读文件：
open FH,'<','/etc/sysconfig/network-scripts/ifcfg-eth0';
while(<FH>){
next unless /IPADDR\s*=\s*(\S+)/;
print $1;
} |
进一步的，如果不一定rh系，还要去读/etc/issue，确定网络配置文件到底是/etc/sysconfig/network-script/ifcfg-eth0还是/etc/network/interfaces还是其他，然后根据不同发行版写不同的处理方法……额，这是打算自己写模块么？
好吧，大家来充分体会CPAN的魅力，去search一下，找到一把Sys::HostIP、Sys::HostAddr、Net::Inetface等模块。第四种：
use Sys::HostAddr;
my $interface = Sys::HostAddr->new(ipv => '4', interface => 'eth0');
print $interface->main_ip; |
不过进去看看pm文件，汗，这几个模块都是调用ifconfig命令，不过是根据发行版的不同进行封装而已。
还有办法么？还有，看第五种：
| perl -MPOSIX -MSocket -e 'my $host = (uname)[1];print inet_ntoa(scalar gethostbyname($host))'; |
不过有童鞋说了，这个可能因为hostname的原因，导致获取的都是127.0.0.1……
那么最后还有一招。通过strace ifconfig命令可以看到，linux实质是通过ioctl命令完成的网络接口ip获取。那么，我们也用ioctl就是了！
如下：
#!/usr/bin/perl
use strict;
use warnings;
use Socket;
require 'sys/ioctl.ph';
sub get_ip_address($) {
my $pack = pack("a*", shift);
my $socket;
socket($socket, AF_INET, SOCK_DGRAM, 0);
ioctl($socket, SIOCGIFADDR(), $pack);
return inet_ntoa(substr($pack,20,4));
};
print get_ip_address("eth0"); |
这样的好处，就是只调用了核心模块，在分发脚本时，不用连带安装其他模块。
注：这个其实是根据网上有的一个py的脚本修改的，py版如下：
#!/usr/bin/python
import socket
import fcntl
import struct
def get_ip_address(ifname):
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
return socket.inet_ntoa(fcntl.ioctl(
s.fileno(),
0x8915, # SIOCGIFADDR
struct.pack('256s', ifname[:15])
)[20:24])
print get_ip_address('eth0') |
现在先来总结一下到底上面说的模型存在着哪些问题：
1、客户生气地说：这个产品好像不是我们想要的吧！早知你们给我这样子的产品，我才不会下单了，你们也早点跟我说这个产品是这样子，到现在才给我看，浪费我时间，精力，我不买了！（客户到交付后来发现产品与当初他们提的需求不一致，所以很生气，后果很严重）
2、设计团队激动地说：都开发了这么长时间了，你们还要改功能加功能啊，这样子会影响到很多其他功能的，会影响最后发布时间的，而且最后的质量如何，我不能保证。（老兄，我出钱买你们产品的好吧，我想加什么功能改什么功能当然得给我弄好，不然我不付钱了！）
3、开发人员暴跳如雷地说：你们这帮测试，早不提晚不提，总是在最后要发布前给我们提这么多Bug，是不是存心给我们找茬啊！要是不能准时发布，你们负责啊！（测试人员委屈地说：我们也想能早点发现这个Bug，早点修好这个Bug啊，但是之前你们也没我Build测啊！）
就这样，不断地出现相互的抱怨，也就是所谓的矛盾，哲学上说，矛盾是事物发展的动力，所以这些矛盾的出现，也就是预示着，我们需要有解决这些矛盾的方法，很庆幸，我们的很多前辈已经帮我们解决了这方面的问题，准确地说是从理论上解决了这种问题，且听我慢慢道来。
首先，对于客户能否得到自己想要的产品这个问题，以前得不到的原因无非就是两点：
第一个就是我们一开始设计的需求点其实跟客户所想要的需求不一致。这一点，我们可以通过需求设计完成后马上跟客户确认就可以解决。
第二点就是客户只能等到最后时刻才能看到这个产品，也就意味着，即使他们发现自己以前的想法是不对的，想要改一下自己的想法却来不及了，因为产品已经出来了，再去改可能又要等很长时间了，这个谁也拖不起。这一点，我们可以通过经常给客户交付一个可用的Build，让客户去看已经实现的功能，来研究是否还需要更改。
而对于我们的设计团队来说，上面的第二点也正好可以解决他们的问题，由于有可用的Build，所以我们设计好的功能一做完就可以马上让客户看到，一旦要修改些什么，就不会再像以前那样由于所有功能点都做完了，改一个就牵一发而动全身了，这点也类似之前说的，一个Bug发现的越早修得成本越低。
而对于咱们的开发人员和测试人员而言，为了帮助客户得到自己想要的产品，也需要做些改变，不过也很简单，几句话而已，开发完成一个功能以后，测试人员就要测试这个功能，然后开发人员需要把发现的Bug马上修掉，最后测试需要把修复的Bug确认修复。这样子的话，就可以解决以前最后阶段才能开展测试，才能发现大量Bug，导致发布成本增加、延期等不确定因素的发生。
当然，这里还有一点必须说一下，即使采用了新方法，成本增加，时间延期这种事情还是有可能发生，但是新的方法可以让你预测到可能发生的成本与时间问题，不会像以前那样到最后时刻才会发现，这样子对于领导层做决策还是会有很大帮助的。
讲到这里，大家应该发现，测试流程已经完全与开发流程并行了，之前说的W模型虽然也会有并行，但是只是属于“伪并行”，因为它需要一个阶段结束才能进行下个阶段，比如开发完所有的功能以后才能开始测试，而对于这个模型，测试自始至终一直在参与着测试，不会去管哪个阶段是否完成，只在乎哪个功能已经设计好，已经开发好。对于设计好的功能，测试里也有专门的设计测试工程师（Design QA）去专门检查这个设计是否符合客户的要求，甚至会去和客户做沟通；对于开发好的功能，一方面代码完成后开发需要马上进行单元测试，然后专职测试人员拿到Daily Build以后就要马上常规测试，看看是否工作，发现严重Bug马上提上去让开发修；最后所有功能都已经确认和测试完毕后，测试人员还要再继续进行集成测试、系统测试和压力测试等等；甚至到了后来的维护阶段还需要测试人员继续参与，因为很多技术支持人员对产品没有测试人员了解地多，所以碰到难的问题，还需要测试人员的帮忙。
所以从一开始的设计到最后的发布，测试人员一直全程参与着，这个跟以前的模式已经有了非常大的改变了，对测试人员的要求和压力已经是不可同日而语了。这个新的模式也就是敏捷测试模式的雏形了，当然还并非完全的敏捷测试模式，所以我暂时先把它称之为准敏捷模式。
既然有了准敏捷模式，那什么才是真正的敏捷测试模式呢？呵呵，还是听下回分解吧。
（未完待续）
一、负载压力测试概述
系统的负载压力是指系统在某种指定软件、硬件以及网络环境下承受的流量，包括并发用户数、持续运行时间、数据流量等等，其中并发用户数是负载压力中比较重要的指标。
负载压力测试基础概念
负载压力测试是指在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的最大负载压力。例如当一个系统在少量用户同时使用时，系统能够正常运行，但当有大量用户同时使用，可能会出现功能失效、性能衰退，甚至系统崩溃的现象。
负载压力测试是性能测试的重要组成部分，它包括并发性能测试、疲劳强度测试、大数据量测试等内容。
二、负载压力测试监理工作重点
负载压力测试实施主要包括：测试计划，测试需求分析，测试案例制定，测试环境、工具及数据准备，测试脚本录制、编写与调试，场景制定、测试执行、获取测试结果、结果评估与测试报告等步骤。下面将按照测试实施的步骤详细论述各步骤监理的工作重点。
● 测试计划
制定一个全面的测试计划是负载测试成功的关键，一个明确、清晰的测试计划将确保制定的方案能够完成负载压力测试的预定目标。监理工程师在审查测试计划时，需要注意以下几点；
1）测试计划中所制定的目标是否具有可度量性
测试计划中除了确定负载压力测试的一般性目标，还应以可度量指标制定更加具体的测试目标，并明确的区分可接受和不可接受的测试结果的标准。例如，一个明确的测试目标可以是最终用户的响应时间等指标。
2）测试计划中的指标是否符合合同、初步设计或其他相关文件的要求
监理工程师在审查测试计划时，不仅要考虑测试目标的可度量性，还要考虑测试计划中提到的指标是否符合合同、初步设计或其他相关文件的要求。如果承建单位提交的指标与其不符，则需要监督其整改，直至符合要求。
● 测试需求分析
监理工程师在审查测试计划时，应依据前期在项目实施过程中了解到的相关资料，判断承建单位提交的测试需求是否合理。在判断过程中，监理工程师在了解80-20等原理的基础上，判断承建单位制定的指标是否符合项目的实际情况，是否能够满足项目的实际需要。
● 测试案例制定
监理工程师在审查测试案例时，应关注测试案例的各项内容，包括案例名称、案例描述、并发用户数、网络环境、场景、测试指标等。
1）案例描述中应明确在本案例测试过程中，必须的操作步骤；
2）并发用户数应清晰描述初始用户数、用户增长模式、运行时间、停止模式、考虑思考时间等内容；
3）测试指标中应为可度量的指标。例如：事务平均响应时间小于5秒，事务通过率大于95％，CPU使用率低于60％，内存使用率低于70％等。
● 测试环境、工具、数据准备
监理工程师在本环节，需要注意承建单位搭建的测试环境与真实使用环境的区别，注意承建单位初始测试数据的准备情况。此外，某些特殊系统还需要考虑其在真实环境中的表现。例如，在测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的结果才具有实际意义。
● 测试脚本
目前，很多软件开发项目都是一个比较庞大的系统工程，它由多个子系统构成。一般来说，各子系统分别由不同的承建单位开发，在测试过程中可能需要与其它系统发生交互，所以，监理工程师需要提醒、监督承建单位，测试脚本的录制、编写及调试工作，不仅仅要考虑到自身系统，还要考虑到相关的其他系统。例如，很多应用系统的负载压力测试的测试步骤就需要通过身份认证，这就需要承建单位及时与身份认证系统开发商沟通，共同做好脚本。
● 测试执行
测试执行时，监理工程师应在现场旁站，及时记录测试中发现的问题，并与已经通过审核的测试计划、测试用例进行比较，确定系统是否实现预计的测试目标。
● 结果评估与测试报告
测试完成后，监理工程师针对发现的问题，督促承建单位进行整改，并适时开展二次测试，直至其通过负载压力测试并出具测试报告。然后，监理工程师、业主单位代表、承建单位项目经理将在测试报告上签字确认，并作为系统开展单项验收工作的一个必备的前提条件整理、归档。
三、结束语
负载压力测试作为系统性能测试的一个重要组成部分，有着十分重要的意义。它有助于确认被测系统是否能够支持性能需求，以及预期的负载增长等。监理工程师通过审查测试计划、测试案例、测试环境及脚本，旁站测试执行，对系统的性能进行质量把关，确保系统的建设能够符合预期的建设目标，为最终的竣工验收打下坚实的基础。
前言：前一篇分享了Oracle环境下的环境搭建和恢复，这一篇分享下DB2数据库的环境搭建，欢迎拍砖。
一、搭建测试环境：
（1）新建数据库，DB2安装完成之后，在开始菜单中查看对应的信息，步骤是“开始”-->“程序”-->“IBM DB2”-->“DB2COPY”-->“一般管理工具”-->“控制中心”，如下图所示：
图1，DB2启动页面
（2）打开控制中心页面，对象视图默认显示的是高级对象视图，即能够看到所有系统和所有数据库，如果看不到，点击“工具”--“定制控制中心”，即可根据自己的要求显示特定的控件（个人一般只用所有系统和所有数据库这两个，看各自的习惯了。）。
（3）在“所有数据库”的菜单中选择“创建新的数据库”，系统默认情况下会创建带有自动维护功能的数据库，如果不需要，即可右键“所有数据库”，创建标准的DB2数据库。输入数据库名称，按照提示一步步创建即可。注：DB2的数据库名称最长为8个字符。
（4）创建数据库大约需要一分钟，创建成功后可以在所有数据库中查看。（选择该数据库，右键“启动”，新建的数据库一般不需要，如果是系统关机后，打开控制中心后要启动该DB，否则该DB的其他功能不能使用。SQL命令是db2start）为了测试数据库是否正常，可以用db2admin尝试链接，链接方法前一篇已经介绍，这里不罗嗦了。
（5）新建数据库时，系统会默认创建常规、用户的表空间，如果觉得这不够，选择表空间创建新的表空间即可，方法同数据库类似，图形操作一步步走下去就行了（在“类型”中选择表空间类型）。
（6）接下来是创建用户，使用DB2记住一点，DB2的用户即系统用户，这一点和Oracle是有区别的。所以在创建DB2用户前先创建对应的系统用户（“我的电脑”--“管理”），删除时只需删掉系统用户即可。创建系统用户成功后，右键某个数据库，选择“权限”，添加用户，从系统用户中选择某个用户，授予其权限，所有的权限都罗列在下面的显示框中，授予完成了确定即可。
图2、添加用户和授权页面
（7）DB2默认的端口号是50000，如果端口号冲突了，可以选择修改，修改的地方如下图所示：
图3、端口修改1
图4、端口修改2
至此需要准备的环境工作（数据库名称、端口、用户名和密码）均已准备完成。
二、小提示：
在日常测试中我们经常会碰到SQL异常，又没有足够的信息帮助我们定位到底数据库出了什么问题，去检索IBM的文档有点繁琐，教一个小方法：
在拥有已经启动好DB2服务的机器上点击“开始”选择“运行”，输入“db2cmd”，确定后在cmd的窗口中输入db2，看到db2=>时输入？ SQLSTATE（这个值是SQL异常中SQLSTATE的那个值），即可快速查看是什么问题了。
三、DB2完全卸载方式：
如果我们想卸载某一款DB2产品，又怕会有残留，影响后续安装，那我们可以找到DB2的安装程序，cmd下运行与setup.exe同级的db2unins.bat，加参数-f（所有DB2产品） -y（忽略确认）即可。其他参数可以通过帮助查看。
先提一个小学时候语文老师问过的一个问题：战争、战役、战斗三个词语之间是什么关系？
之前我写过刻苦学习之颠倒黑白和刻苦学习之自虐，表明关于什么时候学习如何学习，在5W1H（where when what why who how）的概念中其实我只说出了when和how并没有说出其他的东西，当然该学习的人是你自己，那就是who，今天最后的一部分我们就来说说where what和why。
1、把所有的凭什么都变成为什么
很多人在工作上十分爱说凭什么，“凭什么他比我的工资高”“凭什么我要忙死了他还在那里闲着”“凭什么我要比他承担更多的责任”“凭什么升职是他不是我”。是啊，大家想一想凭什么，当我们真的静下心来想凭什么的时候，其实我们已经是在想为什么了。搞计算机的我们都要明白，有因才有果，所以我们只要追查出来原因，不久可以解决了吗。当然有些情况是“他”是某某领导的“某某”，那么我们就不要再眼气了，他是领导的“某某”，那即是领导让他不上班在家还给他钱也是领导高兴，现在领导给他钱他还来上班了，领导也就更满足了，我们还有什么可挑剔的呢？另外还有一种情况，就是他什么都不会，领导就什么都不让他干，而采用看起来没问题实际问题大大的方式“能者多劳”。不要生气，至少你在劳动就说明你是能者，如果你还是不满意，把那些不劳动的也培养成能者吧。什么？你说这样会加大竞争？那就没有办法了，如果你有这种想法，那你就只能做那个孤独而多劳的能者了。
而实际上，在公司里最多的一种情况是你并不是能者，而他是能者，他可以随意的做一件事情得到领导的满意，他可以随意的说一句话提一个意见让领导给你多加若干的工作。那么我们还要说凭什么吗？不要再说了，赶紧行动起来让自己变成一个能者吧。当有一天你的能力和他一样高的时候，你就可以随意的去做了。当然这里涉及到的第一件事就是如何快速的追赶上他，其实很简单，你无法变成一个全能的高手，但你至少变成一个学习的高手。如果以上所有的你都做不到，或者不符合你的要求，那只能说你选错了where，赶紧换个地方吧。你说你换地方没人会要你？那就对不起了，你一定是传说中的“怨妇”，无能而把所有的问题归咎于苍天。
2、审时度势 适应环境
任何人，无论有多高，都不可能在新进入一个环境的时候就成为高手，那么我们如何做呢？就像我刚才说的，至少你要表现出你的学习能力，换句话说就是思考能力。如果在接受一个新事物的时候你比其他人都快，那么你就会成为众新手中的佼佼者，可能会享受到和老同志们相同的待遇，甚至有些更有挑战性的东西会交给你而不是交给一些老顽固的。如果想接受新事物比别人快，就要在新事物来的时候更多的去学习更多的去思考，即使这件事物在你的人生中可能是唯一的一次，那也不要说我以后用不到我不学，因为这是给你的一次崭露头角的机会。说两个我曾经做过的事情：
我刚刚进入测试行业测试的第一个软件是一个累死飞鸽一样的局域网即时通信类的软件，功能点有几十个，有十几页的测试用例，每周出两个版本，我们几个人的任务就是在新版本出来的时候重新执行一下所有的用例。因为多次重复，大家都不再看测试用例而是直接执行，这样做虽然很快，但往往是会露掉几个没有测试。在几次重复之后，我找一个空闲时间写了一个功能点列表，只有一页纸，然后发给大家，从这开始，大家不在看测试用例，而在测试过程中直接看这个测试点列表来检查自己是否有漏掉测试用例。也是从那一天开始，那个项目的负责人把统计和整理大家测试结果的任务交给我，于是我有幸可以纵观所有人的测试bug列表，从中吸取别人的长处补充自己的测试遗漏。也成为项目结束前测试人员中最重要的一位。
我曾经做过一次扫描枪的选型测试（通过测试对比若干产品的优劣选择其中更好的），就是那个在超市扫描标签在屏幕上显示一串串让你心惊肉跳的数字的东西。接触这个项目的时候，包括项目经理在内任何人都没有接触过这个东西，更别说在几十个样品中通过测试和得到的数据有力的说明哪一个更好。几个同时进入项目的人在相关厂家的介绍下开始制定测试标准，但是厂家往往会在告诉我们一些东西的时候回避他们产品的不利部分，所以我们收集了很多厂家的意见合并在一起，但仍然感觉少了些什么。就在这个时候，我拿出过去看杂志中对笔记本的评测文章，自习的分析，说出除了扫描的性能外还有很说使用舒适性上的区别，并且列出超过十条这方面的对比条件。另外，在条码扫描纠错一项上，大家对有问题条码一直无法定位，我便在生活中观察到底条码会受到什么方面的破坏，在若干超市的观察之后，我总结出半透明覆盖、磨损、划痕、撕裂、不平整等几种并且更新到测试规范中。自此，项目经理看到了我在这方面的开拓精神，把制定此次测试规范的任务交给我，我也在测试过程中不停的改进测试的过程，最终成为这次测试的规范制定者和技术顾问，而众多同时参与测试的人都只能遵循我所制定的测试方法进行每天不停的扫描和数据记录。评良心说，我这辈子不太可能再接触这方面的测试了，我自己也不想再做。不过我在这次测试中显出了我的能力，领导从这开始尽量把有挑战性的任务交给我来做，我也有更多的时间来研究和学习新的东西，而这大多是我本专业的东西，学完了可以受用一生。
不知道大家看到上面两个例子是什么感觉，虽然在一开始的时候看起来比别人要累一些，但是逐渐的越来越轻松。更有效果的是，如果这样的事情进行几次，领导自然会在有领导职位空缺的时候把你考虑进去（虽然现在我还没有成为领导，呵呵）。
3、选择道路适应未来
无论工作有多忙，在你工作经验逐渐增多的过程中都会慢慢的有所感觉，知道自己未来的大致方向，至少知道自己的职业生涯是属于哪一个行业。那么，我们是否应该在知道这些事情之后把它明确，做好各种准备，在机会到来的时候大展身手一展宏图呢？我们经常听到有人说机会是留给有准备的人的，事实也是这样。其实很多机会在你面前，你未必看不到，就是抓不住，原因很简单，就是你没有做好足够的准备。不要说你没有看到机会，任何公司的任何一次招聘对你来说都是一次机会，你没有去成，就是因为你的能力还不够，不要说什么经验之类的，如果你能力非常高，经验的门槛就一定会降低的，同样的能力，如果是你你是否会选择更年轻一点的呢。那么我们在选择好道路的时候，就要提前开始走这条路了，虽然你的工作和这些不相干，你也要开始学习，积累这方面的知识，等有一天机会来的时候，你至少比别人懂得多一点点，就是这一点点决定了你得到了这个机会，而别人没有得到。也许你还不知道你的未来是什么，也许你还不知道你所选择的道路到底应该学什么，其实这很简单，只要一小段时间，你广博的学一下各个学科的基础，你就会知道你适合干什么，喜欢干什么。就好比一桌丰盛的菜肴，你不知道哪一个适合你的口味，最好的办法就是都吃一口，你就知道你喜欢吃哪一个了。到这个时候你知道了你想走的路，首先要做的一件事就是把这条路的路障搞清楚。假设我们搞测试的人选择的性能测试，首先要知道最广泛的工具是LR，也是入门基础，那就要开始学习，而这个学科更重要的是执行和分析，所以你要懂些代码和架构的知识，这些代码和架构又建立在一个硬件和软件的环境上，所以你还要懂些硬件和操作系统的知识，性能通常是网络软件，所以你还要知道些网络的东西。好了，到此你的知识结构已经确定。至于这些知识应该哪个轻哪个重，学到什么程度，就留给你们自己去想吧。
4、深挖洞广积粮（书海战术）
很多人即使知道自己的路在哪里，却不知道自己应该怎么走，我学习一段时间最大的感受就是大家通常在说我要学某某的时候却不知道从何下手。具体来说，就是不知道先学什么后学什么，需要看什么书。其实问题很简单，要么去问这行业的高手，要么就行动起来，去想是一定不会想出来的。行动的方法就是把网上或者书店了解到的这个行业的书多买几本回来，从自己认为写的比较简单的那一本开始（我通常认为是否写的比较简单的办法就是看薄厚和是否多图），迅速的去读，不需要精，你现在要做的是了解这个行业，等这基本书读完的时候，你应该就知道自己应该做些什么了。所谓深挖洞，就是把这些知识的储存做好，越多越好，广积粮就是要把所有的储存的知识都快速吸收，不论效果先浏览一遍再说。开始可能会很迷茫，一段时间之后这些看似散乱的东西就是逐渐在你心里结成一张知识网，虽然这张网不是那么鲜明，不是那么清晰，但是你一定会找到属于你的那个脉络。有人说这样很浪费时间，可能学到了很多我们一辈子都用不到的东西，那好吧，你还可以赌一下，试试专注。
5、专注
所谓专注，其实十分简单，就是想尽办法得到各方的支持，包括身边的高手（公司的厚着脸皮去问），网络上的高手（去查），专业书的作者（找到他们的邮箱给他们发信），得到一个最集中的判断哪本书最好，然后拼尽全力去钻研那唯一的一本书，一遍一遍的读，不厌其烦的读，读上十遍，想不成为专家就难。其实很多东西很好问道的，比如像学Java，问他们你得到的答案一定是《Java编程思想》问学MFC的一定回答《深入浅出MFC》问搞软件项目管理的当然要看《人月神话》。其实就是这样简单，不要费那么多脑子去选择，不用自己去梳理知识脉络，只要你按照别人告诉你的答案，按照书中的步骤一步一步去走就可以了。不过提醒大家，这种方式有至少两个缺点。第一就是学习的东西比较单一，无论你看哪本技术的书，如果它写的深，必然涉及到的面不够广，任何一个行业就职的人也不可能就靠一个方面的知识就能够打拼出来，更何况现在企业大多需要多面手，逐渐成长之后还是要把面铺的广些。另一个就是，开始就去研究这些书因为基础不牢，书写的又很深，所以可能会很困难，要吃很多苦头，甚至有些时候会有些迷茫，容易放弃，需要大家有很强的毅力去坚持。也许大家也感觉到了，专注和书海战术的区别就是由点到面和由面到点，如何选择就你自己来考虑吧。
回到开始的问题，战争、战斗、战役到底是什么关系，这个简单的语文问题大家其实都知道答案。但是我们到底是应该研究战争，还是应该研究战役，或者战斗，研究哪场战役，哪场战斗呢？没有确定的答案，要在具体的时间，具体的情景下具体的人根据自己的个性去判断。
最后声明一下，我写的东西未必我自己全部做到，但是至少我做到了70%，即使这样我也认为我在我的环境中做的还是很优秀的，至少我没有奋斗上的遗憾。希望大家也不要给自己最应该辉煌最应该奔跑的时刻留下什么遗憾。
DevSuite系统中的文档管理工具叫做KnowledgeWise，在以“知识为核心” 的理念中属于核心地位，因为软件开发过程中其实每个阶段都需要接触文档的，从需求文档到设计文档到开发文档到测试文档再到发布文档维护文档，文档自始至终一直是需要的，而且同一个文档在整个过程可能是不断发生更改的，所以通过KnowledgeWise跟踪到每个更改对于开发过程来说或是及其重要的。
在KnowledgeWise中，文档通过条目（Item）的方式来记录的，也就是一个文档对应一个条目，每个条目首先会有标题，描述，负责人，附件等字段组成，这些字段是自定义，可以根据你的需要而添加，这是所谓的基本属性。然后条目还有一些高级属性，比如权限控制，流程控制，版本控制，历史跟踪记录等等，下面我就结合我们公司的实际流程来介绍一下这个系统。
1、首先对于那些制度类的，合同类的文档，还有培训类的文档，我就不详细介绍了，因为这些文档不需要所有人都需要看到的，甚至有些需要保密的，更加不能让很多人看到了。通过KnowledgeWise可以保存到只有相关人员才能看到的地方。KnowledgeWise可以为每个人针对每个文件，每个文件夹设置不同的权限，比如只读，可以编辑，可删除，可创建，当然还有不可见。所以你想设置如何复杂的权限组合都是没问题的。（权限管理）
下面的两个图中，可以看到，我们可以为文件夹与文件设置不同的权限，而且是可以为不同的人设置不同的权限的，也就意味着，就是两个人都是经理，我也可以让一个文件只让其中一个人看到。
2、然后就是一些设计文档、开发文档或者是FAQ之类的，这些文档在实际过程中总是会经过很多流程最终产生一个成品，拿设计文档来说吧，一个设计文档从最初有意向，到最后成型，可能分为以下几个部分：草稿—>初级审核—>继续修改—>再次审核—>最后修改—>最后审核—>同意，这么几个过程，而且每个过程中，负责处理的人也不一定是一样的，草稿可能是有普通设计人员处理的，初级审核应该是设计组长处理，最后审核可能是设计主管处理，所以我们就需要设置严格的工作流程和相应的权限，流程刚才已经说过了，权限的话，意思是说，比如这个文档在“初级审核”阶段，必须设计组长才有权限去把这个文档改变到继续修改状态，其他人没有这个权限，甚至其他根本就没法看到这个状态下的那个文档，这样就确保是设计组长审核过才去继续修改的，杜绝了有些人想尽快通过这个文档而直接跳过流程改状态了（当然，在KnowledgeWise中经过自定义设置是可以跳过流程改状态的，当然正常情况下，这个必须是有一定权限的人才能做的，比如主管，经理等）（流程管理）
下面两个图是一个典型的文档的流程的，第一个图是在系统中自定义设置一个流程，第二个图是系统客户端的实际使用情况，可以看到，一个文档从新建到最终成型在正常情况必须通过每个状态的负责人的处理后，走完这个流程，这样子基本上能够保证一个文档的质量。在系统中，每个能进入的系统的人，只要一进系统就可以看到自己需要处理的不同状态的文档任务，包括写文档、修改文档和审核文档。
3、软件公司的做设计的人应该知道，对于一个设计文档而言，会不断地经过修改，即使是最后定稿了以后，可能一个新的改动过来，又得改，但是经常地我们也碰到了一种问题，就是我改完了，但是发现改错了，想看看原来是怎么样了，或者客户不满意想改回一个礼拜之前那个设计，总之就是我想还能看到这个文档每次改动时内容，然后进行一些回滚操作，或者有时候需要对两个不同版本的内容进行比较，看看到底做了哪些改动，改动前是什么，改动后是什么。（变更管理，版本管理）
在KnowledgeWise中，对一个文档条目，每一次操作都能用快照方式记录一个版本，所谓快照方式，就是类似一个拍照功能，把该版本文档的相关内容拍下来，以后只能看，不能改。当然，你可以设置不让每次修改都保存版本，只修改一些关键地方的地方才去保存一个版本，不然版本太多，以后比照起来也挺累人的。
对于保存下来的版本，主要有三个用处，
第一个当然是去看唠，可以看看在过去某个时段，这个文档是啥内容；
第二个内容就是回滚作用，就是说如果一旦我这个文档修改了一下，觉得不对，想恢复到修改前的样子，就可以回滚一下，当然你是可以回滚到任何已经保存下来的版本里的，那么那个版本里的内容将会覆盖当前内容，所以一般情况下如果想回滚的话，你可以先手动做个版本保存，这个在KnowledgeWise中是允许的，而且即使做了回滚，所有的已经保存的版本还是不会受影响的。
第三个作用就是两个版本间的相互对比，有时候我们作了修改后，想对比一下两个版本之间到底有什么不一致，究竟改了多少地方，一旦我们用了对比功能以后，就可以把这个文档的所有字段在不同版本间进行一一对比，有修改的地方会被自动标记，例如这个版本比那个版本就是删除了一段话，这样子的话，对比的时候，被删除的这段话就会自动加上颜色，并且会加上一个删除的线，一目了然。（关于对比这个功能，有些版本控制管理软件其实做得更好，类似Subversion，所以KnowledgeWise也提供了跟Subversion集成的效果，有任何文件作为附件放到一个文档里去的时候，可以同时被自动提交到Subversion中，这样子，就可以对附件也进行对比了）
下面的图就是版本保存的地方。
4、类似FAQ这些文档，其实最终我们做完后是给我们的客户用的，也就是给他们看的，作为帮助文档的方式，所以放在系统中的话，就不太适合他们去看，可看性不好，所以KnowledgeWise提供了一种Wiki功能，可以将指定的文档用Wiki方式给用户看，下面就是一个典型的FAQ在线帮助的截图。
5、另外的话，KnowledgeWise还支持直接由Word或者PDF文档中直接把内容导入到系统中作为一个条目，甚至可以把Word/PDF中分段的内容导成几个相关联的条目，当然也支持导出功能和报表功能了。
6、KnowledgeWise的文档管理支持服务器-浏览器形式的访问，所以只要你能访问你们公司的网页，你就能访问到你想要的文档，局域网与广域网访问起来没有任何区别。
总的来说，KnowledgeWise是一个非常棒的文档管理系统，完全满足了我们公司的要求，甚至超出了不少期待，因为它能跟我们买的其他TechExcel产品做无缝的集成，也就是说一个文档我可以在不同产品中都能看到，如果有更新我也能一下子看到，对于我们公司的软件开发过程是相当有帮助的。