今天有个以前的51testing上的测试朋友在MSN上找到我，跟我聊了几句，后来发现我居然还是08年更新过这边的贴子，就一直没有再有更新了（先鄙视一下自己）

近年来（呵呵，感觉有点沧桑），发生的事情太多了，真是一言难尽，但一样没有变化，就是工作，我的工作还是原来的那个，唯一变化的是工作的时间。

唉~~~希望我的工作上的领悟也会象时间一样积累起来！

非常感谢今天让我顿悟的朋友！

一转眼10年的，工作9年了，现在回首看看自己，就像一只蜗牛一样，进步没多少

大学的同学好多都已破茧成蝴蝶了，一片光明

最近看看网上的一些招聘信息，虽然年限是够，但技术方面的信心都是缺缺的

特别是外语，没有进步，反而是退步，现在我不知道怎么办？

在网上看到一则这样的信息，说是做3年测试的，一般都是测试经理了，天啊，我都干5年了，现在也不过是个leader，这难道就是传说中的差距？我不知道，我迷茫了

总结，自己在第一家公司呆在太久了（6年），浪费了自己大好的青春时光，这都怪自己，不思进取！

这就是苦果，只能自己吃了

真希望时间可以回去，我一定不会这么活了

 

现在很多的测试用例都是在规定的模板上堆着以后也不太会有人看的文字，一本接一本的，看得人云里雾里，还是没有搞清楚到底是要测的什么，也没有搞清楚要测的系统到底是要干什么。

个人比较喜欢图形，在上个东家里做的系统都是跟图形打交道，认为图形其实是个很直接的东西。因为我的抽象思维很差，形象思维很好，很多东西要画出来，我一般都能知道是什么（印象派除外），而且人又很懒，不喜欢看全是字的东西。做了这么多年的测试工作，说起写测试用例，其实最多也就是1-2K行吧，不多，就是因为我不喜欢写，而且在写的过程中我也不知道我会写到哪里去，只能是写一些对付了事的，但总是能安全的没有被发现过关，也许也归功能我的测试执行其他跟我的用例并不是一样的，我的执行一定是比我所写的测试用例要多得多的。

测试用例的图形化，在我认为其实也没有什么，就是在堆文字前，使用一些工具（现在在这方面开源的小工具很多）可以做出一些必要的图形，就像在做需求时，要做的需求分析一样，我们测试也可以没有必要一上来就抽出模板，不停的在上面写着自己也没有搞清楚的文字。

那为什么不能直接就用需求分析时做出来的图呢（一般在需求时会做出一些用例图等），这些图太简单，只是一个大致的轮廓，如果按这图去做测试用例的话，真的写不出真正在后期执行中有用的用例，其实就目前我所做的项目中文字化测试用例的问题有这些：

1、文字化测试用例是乏味的，因为全是文字，就象如果是看小说的话，一个人也一天也看不了两本书，更何况是没有情节的文字测试用例

2、文字化测试用例是孤立的，虽然有文字说明他的接口，但并不直观，难以表现过程

3、文字化测试用例是烦多的，一个小功能，就能写上成千上万行的用例，而且当需要修改时，那就更惨了，不是全推掉，就是让你找个半天然后改个一点

4、文字化测试用例无法让不同的人统一理解的，当一个人写完一个测试用例，一段时间后，由其他的人接手做时，理解原来的测试用例不但花一定的时间，而且会对同一功能产生不一样的理解

其实想想在做码case前，为什么我们不加入先把要写的测试用例图形化呢！现在很多人都在使用一种做脑图的工具（freemind），开源的，不错！可以把它应用到在测试用例前，先把整个系统在你脑子里的构造描绘出来，形成一个脑图（也可以叫做是一个系统的流图或是功能图等等），然后把这张图中的各个结点再去讨论，细化出更小的结点，再确认，最后在最小的结点中加入必要的描述注释，在关键的结点中做出标记，可以认为是重点测试，在描述注释中可写出相应的简化的测试用例，这样在测试团队中全体成图也就知道这个系统的功能以及关键是什么了！

接下来做一些文字化的测试用例，对于一些特别重要的的结点可以做文字化的测试用例，以保证在测试覆盖达到最大。

现在这种做图的工具很多，因为我用得多的是freemind，昨天刚看到一个叫keystone的，还没有用，不知道怎么样！但思想是一样的！

先想到这么多了！

项目被无期限的推迟了，所以我被先release出来！这是我第一次在没有做完一个项目时就被弄出来了，有点生气！但也没有办法。

出来后，就没有接到新的任务了，其实没有活干也挺难过的，天天无所事事的，上班也不知道要干嘛，但又不能让我们在家里睡大觉！痛苦

所以想想用这段时间也研究一下测试工具，最主要的是性能测试工具中得出的性能结果的分析，因为一个工具的使用应该是很容易的，不容易的是他的结果的分析。

公司里用的是LR，可是我的机器 不争气，上不了，一上就重启了，内存不够，只能去网上找个轻量级了，而且还要是开源的，找到了很多，选了一个:WebLoad，据说还不错

先来说说这个WebLoad吧（以下的信息均来自网络）

webload是radview公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能，用户创建的是基于javascrīpt的测试脚本，称为议程agenda,用它来模拟客户的行力，通过执行该脚本来衡量web应用程序在真实环境下的性能

完成第二个项目，又接到第三个项目了，这个项目不大，不过还是给多配了一个QA（本来就我一个QA），希望我能带带她，有点觉得受宠若惊了，没有带过毕业生，这是第一次偿试着。

我想我应该会把我的一些对测试方面的理解告诉她的，但不知道她能理解多少！

回头说说这个项目吧，不大，刚开始听说是只要1个多月就可以OK的，昨天又收到通知，说客户要更改需求了，可能更改会有很大，影响也不会小，唉，这段时间coding暂停了，testing完成现有的工作后，也要暂停，等着最新的需求下来，听DM说可能还会涉及到要重新评估呢，又搞大了！

现在也只有等了！

也好，这段时间可以空出来，让我学学关于性能测试的知识，不错，拿现在手头上这个项目做例子，使用webload来测试一下，公司里是用LR的，我想那个东西太大了， 还是搞个轻量型的，先进行学习一下！

就写到这了。

回上去看，有点胡言乱语了！

 

从第一个项目出来还没休息几天，就被直接拉到另一个项目中去做测试了，虽然只是做个小测试，没有做leader，但现在回想起来，还是很辛苦，原因主要有2个，1我从第一个项目里出来，还没有好好的休整好，就投入到另一个项目的工作中去了，（人年纪大了，精力体力都跟不上了）；2就是我进项目前对项目的评估出现错误，以为项目的工作量不大，没有关系，但事实却是项目的计划被一再的提前，导致QA不断的加班，完成任务，很累！

但不管怎么说，总算是熬过来了，总算是做完了，我可以退出来了，虽然这样，但不能说没有什么好总结的，还是有很多东西我学到了（当初就是因为我不想再做leader，我想看看别的leader是怎么带项目的，我可以多学习一些知识，我的目的达到了）：

1、带新人：在开始工作前就应该规范好他们应该要做什么，怎么做，要求出什么，这样新人在工作起来效率很很高，但不能让他们整天做，得定时给一些问题让他们去解决，并定时跟踪；

2、要规范：不管开发做得怎么样，QA都应该做好自己的事情，QA就是为了提高质量而产生的，在全程中不仅是对系统的bugs提意见，对项目的流程如果发现不好的地方，也应该提出来，并且对问题的解决方案提出自己的建议，这样有助于项目越来越规范，努力让自己参与到项目的管理过程中去，为将来成为一名高级管理人员打下基础（我的目标是这样的，但如果是立志成为技术高手的人，我想应该多向测试的方法、技术方面考虑吧）

3、快乐的工作：这是这个项目的PM常说的一句话，我个人认为是很有真理的，虽然在这个项目里，我并不怎么算happy的工作啦，但总的来说，还可以，不会让我太屈气（QA总会遇到这种情况），因为项目经常加班，而且是在年前的时候，天气又不好，我真的不喜欢加班，但我不是leader，只能这样，我发现在加班的时候我找bug的效率很低，我上午的工作效率是最好的，我能发现很多bug，因为我认为如果项目要加班，这个项目就已经不算是一个做的好项目了，好的项目是不加班（虽然这是理想想法，不能实现的），因为一个在经过一天8小时的工作后，还让加班，从人体注意力来说，已经没有那么集中了，如果这样的，还加班，那不是在浪费生命吗？而且效率不高（夜猫子除外了，我不做夜猫子很久了）

4、技术上：学了一点oracle的知识（大侠们不要笑我），我一直都是用SQL SERVER的，好多oracle的东西我是一窍不通的，这次让我见识了，我也长了点知识，值了点！

5、写文档：用户手册要简洁，把系统中如何实现业务的过程写清楚就行了，没有说明要写成什么样！

目前就只有这些，但总体觉得做这个项目有点不值，没有得到什么！希望以后自己不要再犯这种错误了，在接项目前是得好好把项目评估一下了（这方面我得下多点功夫了！）

今天早上听广播里在进行年终总结，说是对07年关键词进行总结：

我也来说说我对于07年的一个关键词的总结：

金猪年OR土猪年，

股票狂涨，

关闭煤矿，

油价涨，

排队加柴油，

猪肉价涨，

黄金周调整，

带薪年假，

17大全国代表大会，

升息，

房价涨，

动车组，

医改药改，

we are ready，

F1红色法拉利队又得第一，

。。。。。。

现在只记得这么多了！

前几天与同事在MSN上聊天时，不知不觉地就聊到了关于探索性测试，这个名词我不熟悉，只能现从网络上google一下啦（有网络就是好，但老是中毒就不好啦），具体解释如下：

摘抄51testing:

探索性软件测试是一种强大和有趣的测试方法。在某些情况下，它比剧本化的测试更高效。其实，每个测试员都在不知不觉地在用到探索性测试方法，但是很少有人学习和重视这种方法。现在是时候认识一下探索性测试方法了：科学的实时的思考。

这几天，项目进入到了尾声了，但是就像是文章或是电影一样，一般高潮也都会在快结束的时候，所以，我们的项目在这段时间也进入到了最忙也最迷茫的阶段

忙的是项目也结束了，但是可测的包却不能按时的提交，可是总体时间却没有变化，搞得我们测试人员急得在热锅上的蚂蚁一样

迷茫就是这个项目完成了，不知道下一个项目将是怎么样了，每个人都有自己的想法，可是这种想法可以得到实现吗，似乎现在看来，在这个项目中没有学到什么东西，迷茫了，其实这并不是我这篇文章想要说的事情。

时间很紧张了，可是客户却在这个时候告诉我们要加入新的测试阶段，因为我们的第三方不再帮我们做这个阶段了，搞死了，用例我都没有安排写过，唉，只有补了，可是用例太多了，好痛苦。

写一点吧，对付一下了，说实话，我一直认为，测试用例对于我来说只是一种辅助记忆的，因为认为能在用例上写出来的，一般是不会发现缺陷的，发现缺陷的部分一般都是在用例以外的，因为在项目的设计过程中，开发人员与测试人员开会沟通，大家都知道在注意什么，要做什么，并且开发人员也不傻，测试人员也不笨，所以来说，测试用例上写全的东西，开发人员在提交可测试版本前均已把他们给处理掉了。对于一些不在用例里的，却是缺陷表中的主力军，因为软件这东西本来就不是实在的，他是虚拟的，谁也不知道这东西会有什么不一样的毛病出来，这个东西只能放在多实践的过程中才能真正现示出他的真面目，这对于开发来说是不可能的，而对于测试来说却是正中下怀的，不是吗？有人说，那就把用例给不停的补充进去，这就得说到现阶段的中国实情了，现在中国的项目能给你那多么的时间让你来加用例吗？本来在中国测试就没有开发来得受重视，这是不争的事实。还能让你有时间去补，再者即便优秀的测试人员真的认真地把用例补上去了，会有几个管理人员真正地看看这个用例，我想大家都很忙的。

其实说到底，测试用例在大多的项目中最多只能说是一种形式罢了，特别是那些写满密密麻麻的文字信息的用例（个人私心，我是个不喜看大段文字的人），对于我来说，那只是增加我的烦恼，我认为在测试的过程中，应该针对不同的阶段的去设计不同的用例形式，没有必要非得用所谓的文字表达，比如用图，用树等表示就可以了，在软件测试过程中各种测试方法什么覆盖什么路径的，这些不是可以用图先做出来的吗，都已经有图了，为什么还得多此一举地去把图转成文字，其实对于外行的客户他们如果要来看我们的测试用例的话，图，树等也是很适合的。

现在发现网上很多测试的模板，个人认为部分内容不适合我，因为用模板写出来的测试用例对于我来说，作用不大！

 

l'll try to write english sentence -----one

I shall lose my weight

1]We have bigger houses and smaller families; more conveniences, but less time; we have more degrees, but less common sense; more knowledge, but less judgement; more experts, but more problems; more medicine, but less wellness.

[2] We spend too recklessly, laugh too little, drive too fast, get to angry too quickly, stay up too late, get up too tired, read too little, watch TV too often, and pray too seldom.

[3] We have multiplied our possessions, but reduced our values. We talk too much, love too little and lie too often. We've learned how to make a living, but not a life; we've added years to life, not life to years.

[4] We have taller buildings, but shorter tempers; wider freeways, but narrower viewpoints. We spend more, but have less; we buy more, but enjoy it less.

[5] We've been all the way to the moon and back, but have trouble crossing the street to meet the new neighbor. We've conquered outer space, but not inner space. We've split the atom, but not our prejudice; we write more, but learn less; plan more, but accomplish less. 

[6] We've learned to rush, but not to wait; we have higher incomes, but lower morals. We build more computers to hold more information, to produce more copies, but have less communication. We are long on quantity, but short on quality.

[7] These are the times of fast foods and slow digestion; tall men and short character; steep profits and shallow relationships. More leisure and less fun; more kinds of food, but less nutrition; two incomes, but more divorce; fancier houses, but broken homes.

 

[1]我们居住的房屋越来越宽敞，家庭却越来越小型化；可以享受的生活便利日益增多，属于自己的时间却日趋减少；我们获得了一张又一张学位证书，却愈加频繁地陷入对常识的茫然中；我们广泛地涉猎各类知识，却越来越缺乏对于外界事物的准确把握和判断；专家越来越多，问题却也日渐增加；药物越吃越多，健康却每况愈下。

[2]我们花钱太疯，笑容太少，开车太快，发怒太急，熬夜太晚，起身太累，文章读得太少，电视看得太勤，祷告做得太少。

 

[3]我们不断聚敛物质财富，却逐渐丢失了自我价值。我们的话语太多，真爱太少，谎言泛滥。我们掌握了谋生手段，却不懂得生活真谛；我们让年华付诸流水，却不曾将生命倾注其中。

 

[4]我们的住房越来越好，脾气却越来越糟；我们行驶的道路越来越宽阔，眼光却越来越狭隘。我们付出很多，可获得的很少；我们购买了很多，可从中得到的乐趣却很少。

 

[5]我们能够往返于地球与月球之间，却不乐于穿过马路向新邻居问好。我们可以征服外部空间，却慑于走进内心世界。我们可以击碎原子，却不能突破思想偏见；我们写得很多，可学到的很少；计划很多，可完成的很少。

[6]我们学会了追赶时间，却没学会耐心等待；我们拥有的财富越来越多，道德品质却日益沦丧。我们生产更多的电脑用于存储更多的信息和制造更多的拷贝，而相互间的交流与沟通却越来越少。我们拥有的是数量，缺乏的是质量。

[7]这是一个快餐食品和消化迟缓相伴的时代；一个体格高大和性格病态并存的时代；一个追名逐利和人情冷漠相生的时代。我们的休闲多了，乐趣却少了；食品种类多了，营养却少了；双薪家庭增加了，离婚率也激升了；居室的装修华丽了，家庭却残缺破碎了。

 

 

    新公司里的项目已经做快做完第一阶段了，进入到最后的系统测试时期，而且在此阶段也都完成了92%了，就在此时，我发觉自己不知不觉到了软件测试疲劳状态了：无论怎么找，无论怎么测试，都无法再发现bug，而且更加难办的是，我已不想再找bug，即使是从以前测试的结果来分析，bug多的地方，所隐藏的问题也就越大，也许发现的bug会更多，也是系统的弱点以及测试的重点所在，可是现在的我却不想再测试的，因为我觉得对于系统来说，它已对我产生的抗体了，怎么办？

    如果再走一遍，会不会有效果？

    如果换个测试人员再测试呢？

    还是先让自己休息吧，不管了？

    。。。。。。

 

从51testing一个个人空间看到英文版的关于测试的概念讲解的文章，顺着这些文章，我找到了这本书，

与大家一起share(我3岁的侄子的口头禅！)

http://www.robdavispe.com

在这里非常感谢：越测越开心

 

 

       

所谓“潜规则”，就是看不见的、又没有明文规定，被某个圈子的人所深谙而遵循的一种规则。这是eweek 公布的IT人员相信的十条潜规则。

　　1.安全领域最大的潜规则

　　黑客跟安全产商是一伙的。任何时候出现一个系统和软件的漏洞，黑客便马上攻入用户的系统。

　　2.SOA是良药

　　我们都知道新的架构应当基于SOA因为它非常优秀的。但是我们没有商业动力去回头，并改变已存在了30年的应用架构。

　　3.应用包装

　　从来没有包装的应用符合用户的需求，也进而可以这样说，从来没有开发者为着用户的需要而工作。

　　4.墨菲定律

　　当网站随着代码和功能的添加而价值日增时，墨菲定律揭示，网络上最重要的功能和应用却会莫名地减少。

　　5.摩尔定律已过时

　　摩尔定律说每18个月，集成电路的密度就会增加一倍。这一定律让用户很是相信性能的不断提高。现在看来，厂商吹嘘可以两倍、三倍甚至四倍的提升性能，然而问题是他们没有能力来真的实现。

　　6.微软是妖怪

　　坦白说，微软并非最大限度的从用户利益出发。但是我们确立微软妖怪的地位是为了让它跟其他妖怪抗衡，比如蓝巨人（IBM）。

　　7.开源是共产主义

　　开源是IT领域的共产主义，与商业化开发这一资本主义背道而驰。

　　8.软件是糟糕的服务

　　由于我们总是使用却不直接拥有软件，所以它是服务，而且是一直很差劲的服务。

　　

　　9.重回电话时代

　　电子邮件起诉案（指由于司法部通过电子邮件而获得某些罪刑的证据）的增加，让IT的人民重新回到电话旁。不论你说什么，都不会莫名其妙地被带到法庭上。

　　10.游说大厅

　　IT有一拨说客，他们手里拿着钞票到处游说，诱使政客和管理者，从而IT部门花更多的钱购买他们的东西。

　　

职场潜规则

据《新闻晨报》人才周刊和前程无忧联合进行的“职场潜规则知多少”的调查显示，所有的人都承认有违背本意顺应公司潜规则的经历，但大部分人对职场的潜规则了解不多。

　　10个在职场中运行的潜规则

　　据调查，受访者普遍认为潜规则主要作用在企业的“内部管理”、“薪酬福利”和“人际关系”三方面。职场潜规则是企业内只可意会不可言传的运行规则，它引导甚至制约企业员工的言行和价值判断。

　　调查发现，75.5%的人表示“企业不会允许夫妻在同一公司工作”，63.1%的人认为“销售是公司最强势的部门，销售的意见和要求最受到重视”。

　　职场中，最主流的潜规则是“老板说了算”，97.3%的人表示“企业里个人的前途首先取决于老板的喜恶而不是业绩”。90.2%的受访者说“公司里只可暗斗，恩怨不能放在台面上”。88.3%的人说“企业里完全不存在人人平等，同等职位男性比女性收入高”，85.1%的人表示“企业里面有派系，站对队伍比做好事情重要得多”……

　　近80%的人对潜规则不够了解

　　在职场中，员工常常感到，有一种无形的力量在左右着自己的方向，却又触摸不着，琢磨不透。调查显示，没有人声称对企业潜规则百分之百地了解，游刃有余地运用，只有20%的人觉得自己比较了解企业的潜规则，能适应企业的潜规则，近80%的人认为自己对潜规则不够了解。其中，45.8%的人认为对潜规则一知半解，27.1%的人对企业潜规则知之甚少，无法猜透，7.6%的人对企业潜规则毫不了解，无从把握。

　　职场潜规则不可回避

　　前程无忧的职业顾问指出，潜规则的客观存在是不可回避的。一些潜规则因企业文化、领导人的不同而大相径庭。比如日韩企业相对偏重员工的合作和忍让，欧美企业鼓励个人能力的发挥和相互竞争。还有一些潜规则是职场中约定俗成的，比如越级汇报的下属在哪里都不会被容忍，员工加班后休假的安排必须以不影响工作任务为前提。

　　潜规则的最大特性是不稳定，它主要伴随着企业高层管理者的管理特性而形成。如果老板对成本控制比较敏感，那么公司就会以“成本优先"作为管理和考核标准；如果老板喜欢独断，那么公司内部就比较崇尚遵从。所以对企业而言，需通过持续有效力的管理制度，使潜规则帮助完善现有的沉稳制度，使之逐步转变为显性规则，而作为员工，需深入了解企业文化及其背景下的潜规则，同时避免那些和社会法律伦理相悖的“灰色规则”，减少职业风险，学会善用潜规则，为自己职业发展创造良好环境。（
职场上不得不知的六个潜规则

与白纸黑字、公众认可的显规则不同，潜规则恰如摆不上桌面的小菜，从不会大鸣大放地写在告示板上，却需要你明心亮眼地默默参透，才能避免接二连三的尴尬糗事。

潜规则1　不要苛求百分百的公平
　　显规则告诉我们要在公平公正的原则下做事，潜规则却说不能苛求上司一碗水端平，尤其是老板更有特权。
　　孙小明刚进公司做计划部主管时，除了工资，就没享受过另类待遇。一个偶然的机会她得知行政主管赵平的手机费竟实报实销，这让她很不服气！想那赵平天天坐在公司里，从没听她用手机联系工作，凭什么就能报通讯费？不行，她也要向老板争取！于是孙小明借汇报工作之机向老板提出申请，老板听了很惊讶，说后勤人员不是都没有通讯费吗？“可是赵平就有呀！她的费用实报实销，据说还不低呢。
”老板听了沉吟道：“是吗？我了解一下再说。”
　　这一了解就是两个月，按说上司不回复也就算了，而且孙小明每月才一百多块钱的话费，争来争去也没啥意思。可是偏偏她就和赵平较上劲了，见老板没动静，她又生气又愤恨，终于忍不住和同事抱怨，却被人家一语道破天机：“你知道赵平的手机费是怎么回事？那是老板小秘的电话，只不过借了一下赵平的名字，免得当半个家的老板娘查问。就你傻，竟然想用这事和老板论高低，不是找死吗？”
　　孙小明吓出一身冷汗，暗暗自责不懂高低深浅！怪不得老板见了自己总皱眉头！从此她再也不敢提手机费的事，看赵平的时候也不眼红了。
　　场外提示：
　　一味追求公平往往不会有好结果，“追求真理”的正义使者也容易讨人嫌，有时候，你所知道的表象，不一定能成为申诉的证据或理由，对此你不必愤愤不平，等你深入了解公司的运作文化，慢慢熟悉老板的行事风格，也就能够见惯不怪了。

潜规则2　莫和同事金钱往
　　显规则告诉我们同事间要互相帮助团结友爱，潜规则却说不是谁都可以当成借钱人。
　　一种叫做“同事”的人际关系，阻碍了职场里的资金往来。
　　客户主任SUNNY就曾当了一次尴尬的杨白劳！那次时值月底，正是她这种月光女神最难捱的痛苦时光，偏偏又赶上交房租，囊中羞涩的SUNNY只好向同事LILY求助，第一次开口借钱，LILY自然不好拒绝，很痛快地帮她解了燃眉之急，可是3000块钱也不是一时就能还清的，拮据的SUNNY只好一次次厚着脸皮请人家宽限，最后一次，LILY回答SUNNY说不着急，前几天给女儿交学琴费倒是用钱，不过我已经想了办法。SUNNY没心没肺地连声道谢，过后就被“好事者”指出其实人家是在暗示你还钱呢，再说了，你满身名牌会还不起这3000块钱？谁信？话里话外都在影射SUNNY的赖账。SUNNY心里别提多么不舒服了，第二天马上找到同学拆墙补洞，才算暂把这一层羞给遮住，至于日后是否留下不良口碑，SUNNY却是想也不敢想了。
　　场外提示：
　　的确，谁让这年头时兴本末倒置，欠账的是爷，赊账的是孙子呢！“同事”是以挣钱和事业为目的走到一起的革命战友，尽管比陌生人多一份暖，但终究不像朋友有着互相帮衬的道义，离开了办公室这一亩三分地，还不是各自散去奔东西。
　　所以如果不想和同事的关系错位或变味，就不要和同事借钱。

潜规则3　闲聊天也要避开上司的软肋
　　显规则告诉我们“言及莫论人非”，
　　潜规则将其深化成“言及莫论人”，因为少了一个“非”字，也就少了失言的机会。
　　总公司的市场经理MONICA初次来办事处指导工作，中午请部门同事一起吃饭，席间谈起一位刚刚离职的副总王琳，入职不久的LINDA说王琳脾气不好，很难相处。MONICA说是吗，是不是她的工作压力太大造成心情不好？LINDA说我看不是，三十多岁的女人嫁不出去，既没结婚也没男朋友，老处女都是这样心理变态。
　　闻听此言，刚才还争相发言的人都闭上了嘴巴。因为，除了LINDA，那些在座的老员工可都知道：MONICA也是待字闺中的老姑娘！好在一位同事及时扭转话题，才抹去MONICA隐隐的难堪，而事后得知真相的LINDA则为这句话悔青了肠子。
　　场外提示：
　　都说言多必失，可言少也不一定没有失误，如果在错误的时间错误的地点和错误的对象说了一句涉及到具体人事的大实话，那后果真的堪比失言。
　　潜规则4　不要得罪平庸的同事
　　显规则告诉我们努力敬业的同事值得尊重和学习，潜规则却拓宽了“努力”与“敬业”的外延，说懒散闲在的同事也不能得罪。
　　原以为外企公司的人各个精明强干，谁知过关斩将的魏莹拿到门票进来一看，哈哈！不过如此：前台秘书整天忙着搞时装秀，销售部的小张天天晚来早走，3个月了也没见他拿回一个单子，还有统计员秀秀，整个一个吃闲饭的，每天的工作只有一件：统计全厂203个员工的午餐成本。
天！魏莹惊叹：没想到进入了E时代，竟还有如此的闲云野鹤。
　　那天去行政部找阿玲领文具，小张陪着秀秀也来领，最后就剩了一个文件夹，魏莹笑着抢过说先来先得。秀秀可不高兴了，她说你刚来哪有那么多的文件要放？魏莹不服气，“你有？每天做一张报表就啥也不干了，你又有什么文件？”一听这话秀秀立即拉长了脸，阿玲连忙打圆场，从魏莹怀里抢过文件夹递给了秀秀。
　　魏莹气哼哼地回到座位上，小张端着一杯茶悠闲地进来：“怎么了MEIMEI，有什么不服气的？我要是告诉你秀秀她小姨每年给咱们公司500万的生意……”然后打着呵欠走了。
　　下午，阿玲给魏莹送来一个新的文件夹，一个劲儿向魏莹道歉，她说她得罪不起秀秀，那是老总眼里的红人，也不敢得罪小张，因为他有广泛的社会关系，不少部门都得请他帮忙呢，况且人家每年都能拿回一两个政府大单。魏莹说那你就得罪我呗，阿玲吓得连连摆手：不敢不敢，在这里我谁也得罪不起呀。
　　魏莹听了，半天说不出话来。
　　场外提示：
　　其实稍动脑筋魏莹就会明白：老板不是傻瓜，绝不会平白无故地让人白领工资，那些看似游手好闲的平庸同事，说不定担当着救火队员的光荣任务，关键时刻，老板还需要他们往前冲呢。所以，千万别和他们过不去，实际上你也得罪不起。

潜规则5　给上司预留指导的空间
　　显规则告诉我们升职加薪需要自己努力工作靠真实才干获得，
　　潜规则却说做事要多请示上司，功劳要想着分给上司一半，莫要埋没领导的支持和指导。
　　人力资源专员袁晓敏入职3年，能干又努力，工作认真做事漂亮，人缘佳，但奇怪的是尽管工作出色，可仍旧原地踏步，难上青云，倒是那些不如她的同事却接二连三地升了职。
　　没错，她袁晓敏是能干，但上司就是不喜欢她。为什么？在小节上从不顾及上司感受：比如每次开会老板都指定袁晓敏做会议记录，袁晓敏整理出来后从来不会让直接主管李虹过目就直接上交老板，因为老板夸她有生花的文案整理功夫呀；她帮其他的部门做事，从不事先请示李虹是否还有更重要的工作分配她做，就自行接下，也不管这事会不会留下什么隐患，所以她是得到了好口碑，李虹倒显得有些小气。部门要买个投影仪，李虹让她询价做性价比，然后准备购买一台，袁晓敏拿到供应商资料后多方比较，自作主张就订了货，还对李虹说出一大串理由，好像她做事是多么的圆满。
　　在看到又一个同事加薪升职后，袁晓敏叹道：唉，上司真是瞎了眼了。
　　场外提示：
　　其实上司一点也不瞎，人家心里亮堂着呢。不管你承认不承认，那些表现出色，从不出事，也不需要老板来指点的人，并不一定能得到重用和认可，甚至上司并不喜欢，因为面对你的完美，上司无法发挥他的指导，无法显示他的才干，而你也就不会和进步或改正什么的词挂钩，这时候，完美就是你的缺点；倒是那些大错不犯小错不断又喜欢和上司接近的人却容易获得更多的机会，因为他给老板预留了发挥的空间，让上司很有成就感，即便日后升了职也会被骄傲地冠名为“我培养出来的”。有时候，满足一下上司的虚荣心也算剑走偏锋的一招。

潜规则6　用脑子听话
　　显规则告诉我们要用耳朵听话，用嘴巴沟通，潜规则却说要用脑子听话，用眼神沟通。
　　刘婷是行政部职员，初来乍到，一身稚气，不知公司两位高层徐副总和王副总是面和心不和，徐副总同意的事，王副总有意见，反之亦然。公司不大，所以行政部有时候也兼做些类似秘书的工作。那次给老板写年终报表分析，王副总让刘婷先按他设计的表格做报告，过两天徐副总问刘婷有没有什么格式，刘婷就把给王副总的那份报告给了他参考，此举让王副总非常不快，嘴上没说什么，却冷冷地把刘婷叫进来让她按自己的思路重新设计表格、重新做报表，还开玩笑般不冷不热地加了一句“这可是有知识产权的，要保密哟”，闹得刘婷一头雾水。后经资深高人点化，才知原来二总相争已非一日，大到争权争利争人缘，小到争外出公车的品牌，都要显出个人的身价。所以身为他们的下属，一定要口风严，都不能得罪，徐副总的话没错，王副总的意见也没错，这时候你不光要用耳朵，还要用脑子。
　　刘婷这才知道自己碰到了只可意会不可言传的事，暗叹公司的运作与生存艺术实在不同凡响，身为下属向左走还是向右走，就看脑子做出的判断对不对了。
　　赵丽丽是王副总的小表妹，那次在给客户做培训时不小心砸坏一个价值8000元的机头，当着徐副总的面，王副总皱着眉头严厉地对刘婷说：要查，要按公司规定罚款，决不能敷衍了事。刘婷这次可学乖了，先是查找能够遵循的公司制度，然后给行政部出了个方案：扣发一个月奖金。奖金嘛，一个月不到1000块，当然比不上8000元的机头钱。刘婷执行的方案是：非故意损坏的要酌情惩罚，情节严重的要照价赔偿。人家赵丽丽把机头弄坏的时候，可是哭得梨花带雨，这谁都看见了，这怎么也不能说是情节严重吧，所以刘婷就建议酌情惩罚了。
　　事后王副总也追问刘婷的解决方案，还打着官腔问惩罚力度是不是不够，刘婷巧妙地述说了上述理由，王副总没再说话，挥挥手让刘婷走了，不过接下来的日子，和刘婷说话的时候总是那么和颜悦色，让她感到特别的舒服。
　　场外提示：
　　潜规则暗示了公司的一种潜在文化和行事规则，往往只有老员工们才能深刻领会。如果对此尚不了解，那么不妨多请教资深同事，同时记住：你既不能把自己的上司不当回事，也不能把他们的话真正当回事，执行起来也得有弹性，有时你的确需要装糊涂。
　　TIPS1　遵守潜规则的必备素质：
　　* 懂得上司的心理和行事习惯；
　　* 熟悉公司文化和运作方式；
　　* 懂得难得糊涂的拿捏尺度。
　　TIPS2　几种心照不宣的潜规则：
　　1. 上司的喜好有时高于制度；
　　2. 别和老板谈公正；
　　3. 不能抢了上司的风头；
　　4. 太露锋芒的人容易没饭吃；
　　5. 给上司预留指导和发挥的空间；
　　6. 适时的巴结也算一种沟通技巧；
　　7. 尽早投靠新上司；
　　8. 把握好潜规则的分寸

（第一次试着用电脑输入日语）

こんにちわ      good morning    你好！早上好！

はじめまして       how do you do; nice to meet you!        初次见面

1. I've got a cold. / I've got a bad cold.

　　我感冒了。/ 我感冒很严重。

2. I've got a runny nose. / My nose is running.

　　我流鼻水。

3. I've got a sore throat.

　　 我喉咙痛。

4. I've been coughing day and night.

　　我早晚都在咳嗽。

5. I can't stop sneezing.

　　我打喷嚏打个不停。

6. I've got a temperature. / I'm running a high fever.

　　我发烧了。/ 我发高烧。

7. I've got a very bad headache. / This headache is killing me.

　　我头很痛。/我头快痛死了。

8. I feel sore and ache all over.

　　我觉得全身酸痛。

9. I feel like I'm dying.

　　我觉得我好象要死了一样。

10. I feel dizzy. / My head is swimming.

　　我头晕。/ 我头昏脑胀的。

写商务邮件往往要比口语简单：你不必担心发音，并且你可以慢慢的修改你的信件内容。但是写的时候却需要记得几项规则。这儿有一些建议可以保证你的邮件给人留下好印象。

1. Know your email terms:英语电子邮件发送程序有很多的缩写，如果你不知道意思的话，你给老板要求加薪水的邮件就可能发给了整个办公室！ 

"Reply to all"表示你的邮件将发送给每一个收到原始邮件的人。在邮件的地址栏内，"cc" (carbon copy)部分是指邮件发给你指定的人，而"bcc"部分你可以悄悄的发送邮件而不让其他的人知道– b的意思是"blind"（掩藏的）。

如果有人要你"forward"一封邮件，他们意思是要你通过转发的功能发送邮件，有时侯简写成"fw." 


2. Use the Right Greeting:尽管用"Hey"作为写给朋友的电子邮件开场白没有任何问题，但是最好不要用这种方式来给一个潜在的商务伙伴这样写信。另一方面，使用非常正式的传统开场白"Dear Sir" 也已经越来越过时了。最好是写"Dear Mr. / Ms." 然后那个人的姓。如果你们一起工作的话，那就写他们的名字也没有关系。（例如"Dear John"）。 

3. Keep it Short and Clear:其他种类的语言可能需要用精美的词汇和复杂的句法来显示你的聪明才智和教育，而写英语邮件你只需用一种清晰且有条理的方式。在邮件的第一段清楚的表明你写信的目的并条理清晰，每一段都有中心句。使用类似"first, second, next, and finally"的词引导读者你将表述一个新的观点。你不需在邮件中包括所有的详细内容。你可以用象"If you have any other questions please feel free to contact me,"这样的短语来结束邮件，这样一来让读者有更多的机会询问更多的信息。

4. Be polite and tactful:在你写邮件时尽量清晰的陈述所写的内容， 到底是邮寄鞋子的费用折扣还是一次工作面试，最好不要用象 "I want."的词表示要求，"I would like"显得更尊重对方，并且"I am interested in"是提出请求建议或寻求意见的好选择。 

5. 电子邮件正确结尾： "I am looking forward to your reply," "Thank you,"或者"Sincerely"都是给收信人留下好印象的结尾方式。

6.BTW：By the way

7.FYI:for your information

8.R.O.I:return of investment (投资回报)

9.ASAP:as soon as posible

 

来新的公司已快两个月了，一进来就被分配到一个新的项目，做QA Leader，第一次看到比较详细的SRS，听说这份还不是详细的，一个老QA给我看了一份她的第一个项目的SRS，外文的，很详细，真的，没有看过这么详细的SRS，有点佩服这个PM，能写得这么细。

说说现在的这个项目吧，国内的，据说是一个小的项目，半年就得搞定的，现在的情况是项目开发总是delay,导致现在测试前期工作量不满，我想在后期可能是得加班了，不然就得加人（我不主张加人）。唉，这样看来，每个软件公司的项目都有这种情况了。

上周学着开始做进度控制，发现按计划本应该进行了30%的工作量的，但现在测试只完成了20%的工作量，少了10%的工作进度，这10%想想只能通过加班才能完成 ，可恶的是，delay的部分都是我要测试的部分，到后期，我一定会被逼疯了，我有这种预感了！可怜~~~~~

    一直想着把公司里的测试效率提高,所以在加强测试人员的专业水平外,就是把测试工具应用到自己的测试中去,现在世面上许多的测试工具,开源的,试用的等等,几乎都看到过,但没有一个是可以应用到公司的产品自动化测试中,虽然我也知道测试工具不是万能的,但是由于公司的产品是别人平台的二次开发,而且开发的语言也不是大众的开发语言,有点无奈.

    最近在研究测试自动化,看着网上许多的教程,搭起环境,学习着应用,发现很难,一是业务方面,二是专业方面,不知道应该从什么地方着手去做,很茫然.

    想起去别的公司,也许会好一点,但是谁又能知道下个东家是个什么样呢!唉,不想了,总归简历发出去了,能成不能成也不是我能决定的,在这家公司一天就好好的干一天,能学习就多学一点,以后一定能用得上的.

    现在学习的东西好乱,QTP,LR,TD,C#,JAVA,脚本语言等等,有点思维混乱了,我得好好的理一下了.