昨天把简历公开了，中英文简历都修改好了，投了八家公司，都是比较期望的公司。刚投过去，下午就接到其中两家公司的面试电话，第一家的民营企业，总部在珠海，不过广州有分公司，安排在上午九点面试。第二家是外企，总部在德国，下午两点面试。收到他们的邮件后，我一一回复，并进行相关证书和简历的准备。

    后来还接到深圳一家外包公司的电话，HR跟我聊了半个多小时，简单的了解了一下我的情况，也介绍了他们公司的情况，需要外派到广州汇丰银行，这个项目组一共有200多个人。并且谈了薪资，她说可能跟我期望的有所差距，但6.5K是没有问题的，其他的福利待遇都有。我对外包公司兴趣不大，所以婉言拒绝了。

    今天上午7点就出门了，一路转车、倒地铁到第一家公司参加面试。

    面试的流程大致是：

    首先，前台让我填了我的基本信息表，然后给了两份试卷给我，一份是EQ测试，另一份是软件测试试卷。EQ测试就不说了，软件测试试题包括五大题，第一道是判断题，对一些软件理论进行判断；第二道是单项选择题，第三道是多项选择题，第四道是简答题，最后是英翻中两段话。难度不算太大，答得还可以。

    后来测试部主管（孕妈妈）给我进行第一面，她很和蔼，她先让我做了自我介绍，然后问了我测试专业知识方面的问题和一些综合性的问题，期间也有比较麻烦的问题，比如说我之前的工作参与了项目的好几个阶段，而现在我专门做测试有什么优势？我们聊得很愉快，她说了好几次，我非常满意你今天的表现，然后我问了几个关于公司测试部门和产品的一些问题。。。。。

    最后，人事给我进行了第二面，其实主要是谈薪资，她把公司的福利待遇都给我介绍了一遍，然后说可能跟我期望的有所差距，我没有直接拒绝，她让我回去等OFFER。上午的面试就这样结束了，出来的时候已经11点半了。

    直接赶到下午面试的公司，今天做了一件明智的事情和一件不明智的事情，明智的是我早上出门买了个起司，不明智的是，我没有吃中饭就去了德国这家公司面试，那里是国际软件开发产业基地，狗不拉屎的地方，我没找到快餐店，连个超市都没看到。通知的是2点面试，我1点半上去的，一进去就被吓到了，好大的办公室，里面至少有好几百个人。前台给了我一份基本信息表和笔试题，这套笔试题比上午的要难度更大。题型有选择题、填空题、简答题和设计题，填空和设计我答得不是很顺利，考了一些技术方面的，但是还是瞎编乱凑的完成了。

    完了人事带了一个男的（后来知道是研发部的技术人员）给我面试，他先让我做自我介绍，然后就开始问技术方面的问题，问得深入了，什么权限，访问点，资源。。。问了一大堆，幸好我还能一一对付，不会的就瞎说，还问我人生中有没有什么缺陷导致我的职业发展停滞不前？一些很奇怪的问题。

    半小时后，他拿着我的简历去找人事，算是一面通过了。第二面由人事部经理给我面试，又让我自我介绍了一遍，然后问了我之前工作的流程还有优势什么的，遇到问题怎么解决啊之类的，差不多了，她突然用英语冒出一句“please introduce to yourself!”,我当时懵了一下，不过马上缓过来了，还好事先有准备，我流利地用英语介绍了自己，然后她继续用英语问了我一些问题，比如说在一次会议上，你的上司犯了一个错误，你会怎么处理？你这两年工作的收获？你怎么处理和同事之间的关系，这些都比较简单，我觉得回答得很顺畅，就是有一个问题，“严重性”我一时想不到英语怎么说，不过漂亮的人事经理提示了我。用英语大概交流了二十多分钟，然后她转中文了，给我介绍了公司的产品，在德国的情况，采用的技术，还很详细的跟我说了公司的福利（五个工作日，8小时/天，五险一金，一年两次提薪，班车免费接送），除此之外，公司还提供两名英语培训讲师，专职培训员工英语，健身计划。。。诸如此类，我比较满意，如果有可能的，我也愿意去降低一些期望的薪资。

    最后一面是由研发部主管给我面试，我发现职位越高的人越和蔼，主管没有问我什么专业性的问题，倒是问了比较多综合性的问题，还问了我一个很苛刻的问题，他说如果公司就只有我和另一个开发人员讨论一个鼠标的标记颜色，双方意见不统一，开发人员故意找茬，就是不同意我的方案。项目经理在出差（期间不能打电话给项目经验），公司就你们两个，没有第三者，你会如何处理？我从立场、如何去跟开发人员沟通方向回答。主管也说这个问题很苛刻，但确实会发生在实际工作中。

    三面结束，HR说一周内会发OFFER，出来的时候已经4点多了。两场面试下来，身心疲惫。回来的路上，接到一家猎头公司的面试公司，明天上午继续。。。

    我把今天笔试遇到的不会答得问题列出来，及时巩固，希望下次可以对答如流。

    1、测试方法有哪些？

    2、设计测试用例的方法有哪些，分别在什么情况下会使用这些设计方法？

    3、面向过程的集成策略包括哪些？

    4、性能测试的步骤和目的。

    5、回归测试要注意哪些问题？

    6、用等价类划分的方法设计三角形计算的测试用例。

    7、用因果图法编写字符*或&输入的用例。

    8、CMM成熟度包括几个等级，分别是？

    9、如何跟踪bug的生命周期？

    10、QTP和Loadrunner的基本原理和操作过程。

今天在51testing看到一篇转载的文章，很有共鸣。为此结合我的经历和体会，对文中的一些观点点评一把，给大家分享：

“最近受邀请要给微软的一个团队讲解我个人的一些测试小秘密和常用的测试技术。其实，测试没有什么太多的秘密可言。如果说如何能发现更多的bug的话，那么我认为最最重要的是passion和experience. 但是，由于他们期望听到的是测试的techniques，我就列了一个我认为最重要的几个方面。现在发出来和大家共享一下吧。

——Jack点评：我也认为激情和经验最重要。同样的测试思想和方法好比不同的武器，给不同经验和心态的工程师绝对效果是不一样的。测试管理者们不要指望用工厂生产管理的方式用机器代替人，所有工作都通过工具把对人的依赖弱化掉。测试工程师怎么说也还是知识工作者，不是富士康的操作工。从未听说过设计工作被自动化，实现工作被自动化倒是可行的。类比现在有工具可以自动生成代码，自动生成自动化测试脚本，测试用例，但是这些工具的输入还是由设计者经过人脑分析设计而产生的。

　　·         Passion, Experience

　　我觉得experience和passion最重要。有一个周六的半夜我突然有种想法应该给我测试的feature去做code review，就去了office一直工作到5:00am, 结果就发现了两个security bug. 之所以能有这个idea就是因为经验的积累造成，而能在周末凌晨工作几个小时则是因为passion. 我现在完全地享受能发现各种各样bug的生活了，已经对开发没有什么兴趣了。破坏软件真的是很有趣。

　　·         Understand features deeply

　　o   Design

　　o   Architecture

　　o   Implementation

　　o   Customer requirements

　　理解这些非常的重要。你理解的越深，你就可能发现更多，更好的bug。

——Jack点评：我所做过的每一个项目都会深入学习和理解该项目的design、Architecture、Customer requirement，这是我这么多年来做测试的习惯。所以说完全黑盒的测试是不存在的，做好系统测试可以不看代码（时间成本很高，老板不高兴），但一定要和开发人员一样了解design、Architecture、Customer requirement。并且只有你能在这3类文档中发现了其中的缺陷，才能说明你真正的看懂了，并可基于这些资料开始测试用例的系统分析和设计。我甚至认为做一个合格的测试分析和设计人员是必须具备快速学习和理解项目design、Architecture、Customer requirement的能力的。

　　·         Tools

　　o   App verifier

　　o   Driver verifier

　　o   Fuzzing tools

　　o   Etc.

　　Some tools are extremely useful. Some tools are very helpful. 很多人不理解我为什么每天都能发现一两个蓝屏的bug，其实90%的应该归功于这些tools。但是，虽然几乎微软每个人都知道这些tools，但真正经常使用的并不多。我发现一个有趣的问题，绝大多数我发现的bug并不需要特别的技术，而决定于态度。是一个你有没有去测的问题，只要去测，细心去测都能发现他们。

——Jack点评：对测试工程师来说用好工具胜过自行开发工具（这是在做开发，而非测试），开发工具是有很大的成本的。当你是一个有丰富测试经验的工程师时，我更希望你能发挥测试的特长，而不是放弃特有的测试经历转向开发重新开始。当然如果你认为你的测试用例集已足够完善和完美，有无事可做那么你可以去写写工具玩，否则的话应将测试工具的开发交由专门的开发人员来实现。

　　·         Code review+Debugging

　　o   Security audit: buffer overflow, memory leak, AV

　　o   Logic review

　　Debugging 的技术非常非常重要，这是开发和测试的一个主要技术交集。就在我做完这个经验介绍以后，其他的feature里发现一个bug，他们怀疑是我们的 feature造成的。我出面跟他们的开发和开发组长进行交涉，最后给他们指出他们的代码里问题的所在。Code review和debugging是相辅相成的，不可分割。我一般进行两种code review。一种叫code audit, 不关心代码的逻辑，功能，只是检查有没有buffer overflow, memory leak, AV 等等。一种是logic review, 专门检查代码的逻辑是否合理。Code review是个bug farm, 熟悉之后你能发现大量的bug在里面。

——Jack点评：非常高兴最近我正在实践的代码检视方法与文中的一样：如果时间资源少，先只做code audit（关注内存泄漏，资源泄漏，错误的指针内存使用，字符串缓冲区溢出，数组应用错误等）；只有时间资源多时，才考虑logic review（一直没有时间来开展。） code review可以在测试设计开始之前做，能帮助你对系统实现了解更多，有更多可编写测试用例的场景输入；也可以在所有用例测试完成后来做，对基于场景的测试分析进行补充，毕竟无人能100％的覆盖所有的可能问题场景，通过code review也是一种补充方法。不过，需要强调的是：code review能发现代码编写的错误，却很难发现设计流程的错误（因为你已陷到细节的纠缠中去了，很难再从全局考虑设计了）

　　·         Tenet tests:

　　o   Reliability: tools, stress

　　o   Security: fuzzing, code audit

　　o   Performance: Xperf

　　大家一般更多的关注与functional test。其实Reliability, Security和Performance测试都非常重要。每一个测试人员都应该具备进行这几方面测试的能力，从而给自己负责的feature经常性的，或者通过Lab进行这些测试，肯定能发现很多bug，这些一般都是非常好的bug。

——Jack点评：压力测试和可靠性测试做的不充分，不精耕细作的项目，绝对质量是不过关的，无论测试报告能多么匹配你公司内部的质量出口标准，只要产品大规模上市应用后，你就会吃到这个苦头的。我甚至认为压力测试和可靠性测试是充分暴露产品bug的重型武器，功能测试用例只是步兵的随身武器。一直以来我每一年都会帮某些项目设计压力测试方案（用例）或可靠性测试用例，每做一个项目，我都能在这些专项测试的测试分析和设计质量上更进一步。

　　·         Integration test

　　大多数人只关心自己的component。其实很多bug发生在集成测试上。你需要学习其他相关的component, 从而能够想象很多cross feature的scenario进行测试，也能发现很多bug。

——Jack点评：通常我在给项目组补充测试用例设计时，很多都是补充的这类用例。因为经验稍少的人难免会对被测系统内部的对象理解的过于孤立，即使有时进行了正交穷举法也未必能考虑齐全。要做好集成测试的设计，需要测试分析设计人员具备快速进行宽度知识学习和深度知识学习的合理平衡。不过于钻牛角尖，又不过泛导致只能搞穷举正交。

　　·         Looking for test holes

　　o   Test cases

　　o   Test tools

　　o   Test owner history

　　o   Old bugs analysis

　　我在有时间的时候我会通过这几方面去寻找更多的bug。看看有没有没有cover的test case， 看看有没有新的test tool可以尝试，跟别人聊天看看自己component以前test owner的情况，以及分析一下最近发生的一些bug。同一个bug有没有可能出现在其他地方。

版权声明：本文出自flysky19的51Testing软件测试博客，欢迎转载……”

通过日期控件选择日期，很多情况无法录入所选择的日期，导致回放失败，可以用下面的方法处理

先把显示日期的文本框添加到对象库，假设是WebEdit类型的文本框sdate，对象整体路径：browser().page()...WebEdit("sdate")可做如下操作
sd = browser().page()...WebEdit("sdate").object
object.value = "2007-01-03"  也可直接赋值 browser().page()...WebEdit("sdate").object.value = "2007-01-03"，输入正确日期格式的日期，再回放时就能正确显示所设置的日期了

这个问题出题很新颖，着重是考察公司的测试Leader应对突发事件的能力？
以前我们公司招测试Leader的面试题目中也有类似的一个题目？我面试了很多人，回答都不是很理想，都只能够回答上几句话，并且都有“需求不明确”等同感，只是工作中太忙缺少总结，给出一个常见的很熟悉的问题，马上作答不知道如何说起。

下面是我的一些看法，恳请各位同行批评指正：
1.根据客户的功能点整理测试需求追朔表：
一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。

2.根据开发人员的Software Specification List整理我们的功能测试点：
一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。

3.开展项目跨部门讨论会：
可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。

4.测试人员整理用例需求疑问递交项目组和客户代表回复：
测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。

5.项目内部用例评审：
测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。

6.邮件和客户代表确认部分争议问题：
测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下最好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。最后编写测试用例的时候，以客户的邮件内容为准。

7.项目Demo和部分已开发系统：
大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。

8.参考同行业和竞争对手的类似产品：
假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

9.交叉模块的测试，最容易被人忽略：
一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。

10.可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：
我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。

作为一名测试新人加入团队，大多数情况下，项目组成员都是一种热情欢迎的态度，并且主动提供力所能及的支持和帮助，如何快速熟悉项目业务和测试环境，尽快投入到实际工作中去，我谈谈个人的经验和一些看法，供同行参考：

1、寻找新公司的团队元老：

  一般来说，一个新人进入新公司，都要指定一个师傅带一段时间，这也就是我们说的测试前辈。很多时候，测试前辈都是经验非常丰富的测试高人，如何您和他相处融洽，关系不错，凭他个人丰富的业务经验，给您指点迷津，也许会比你自己摸索10倍的时间效果还好。很多的测试新手，刚进入新公司时，自高自大，眼高收低，测试前辈都不愿意交，结果到了试用期转正答辩的时候，一问三不知，被迫离开公司，被炒鱿鱼。这样的例子我看到的不下于10例，很可惜丢失了很多工作机会。

2、虚心的学习态度：

刚到一家新公司，保持谦虚的学习态度非常必要。记得我刚毕业那年，公司招聘了一个测试主管，他有4到5年的工作经验，阅历算是不简单，也是我们心目中的牛人吧。但是那个人，除了听总监的话以外，对于我们部门的其它人来说，他简直是自高自大，目中无人，根本不把部门里的其他人放到眼里，觉得部门的人都不如他。他作为一个空降兵，老员工和新员工，对他都很冷漠，碰到什么问题，需要小组成员帮忙的时候，大家都不愿意帮助他，互相推诿，并且经理也找他谈了几次话，效果不明显，结果他呆了不到2个月，估计是自己觉得很不开心，被迫离开了公司。其实，保持低姿态，谦虚的学习态度，必不可少。

3、阅读项目相关的文档：

  一般来说，新人一到公司，就会安排到项目中去。作为测试新手，快速阅读相关的“需求文档”、“详细设计文档”和“用户手册”特别关键。我们能够通过需求规格说明书等文档，快速熟悉系统相关的知识，获取编写测试文档的相关信息。如果项目已经编好了用户手册，您完全可以根据文档的步骤，一步一步傻瓜式的熟悉每项功能。只有掌握的这些文档的精髓，测试才会变得异常轻松呀。

4、快速熟悉项目相关业务知识：

刚到新公司的测试人员，如果你是跳槽到以前做过的相近行业，有丰富的经验了，那么您熟悉业务没什么大的问题。如果您换的新公司是您以前都没有接触到的行业，那你一定得努力一点，买些相关的业务知识看看非常必要。我深有体会，以前从一家“通讯公司”跳槽到做“银行系统”的公司，业务完全两样，很多业务知识都是从零开始。不过有一定的工作经验，学习起来也挺快，关键取决于个人是酷爱学习和坚强的学习毅力。

5、尽快介入了解被测试系统：

   刚跨入一家新公司，如果被测试系统已经开发的差不多了，部分功能已经OK了。你可以部署到测试环境下，尝试从直观测试的角度去尽快了解系统，尽快结合文档熟悉起来。很多的时候，通过页面操作实际的系统比看文档效果好的多，并且印象更深刻，熟悉系统更快。新加入公司的朋友不防试一试。

6、了解公司类似的相关产品：

    大多数的公司，都不可能在每个行业都非常强，基本上都是在某一个较小的领域很强势，公司主要就是研发强势相关业务的产品。所以说，相关的产品一般来说是很多的，如果要你测试的系统没有开发完毕，如果时间和条件允许，不妨先了解一下公司类似的产品，以便尽快熟悉起来。大多数情况下，公司很多的产品都是相通的，大部分的产品是在不同的客户要求下，修改了部分功能和界面而已。个人认为：了解类似的产品，也是测试新手快速熟悉产品的一条捷径。

7、尽量多参加项目的各种会议：

    每个项目，特别是在项目的启动阶段，大会小会不断，很多时候项目组成员抱怨居多，都认为很浪费时间，耽误开发进度。如果作为测试新手的您这个时候加入，那太好了，多参加这样的讨论会。大部分时间都是在讨论项目的重点和关键，如果大家意见不一致，必然要对不一致的东西展开细节讨论，您肯定是收益匪浅。特别是对业务方面的讨论，您参加几次讨论，比您看10篇需求还强，并且理解也很透彻。如果您对需求有所了解，但是部分功能模块还有问题，就可以在讨论会上随时提出来，大家一起讨论，共同解决。如果有这样的机会，切勿放弃哟。

8、阅读类似项目已有的测试用例：

   如果项目已经启动并进入了测试阶段，如果你在这个时候介入，通常情况下负责人都会给你提供整个项目或部分需要你测试的部分模块的测试用例。这些测试用例也是您快速上手测试的重要参考资料。如果还没有编写测试用例，你就介入了，那你就得重头开始，您可以阅读项目类似的测试用例，并结合以前项目的测试经验，根据公司相关的测试用例模板开始编写测试用例。如果在编写测试用例中碰到您不了解和很难处理的问题，您可以记入测试需求疑问表格，等部门开会时，提出来大家讨论。最好不要碰到一个问题就去问，经常打乱人家的思路，弄得别人嫌烦，那就不值了。

9、查看缺陷数据库中旧有的缺陷：

   一般的测试缺陷跟踪系统，都是按模块来分类软件缺陷的。如果老大给你分配了测试任务，你就可以有目的的去熟悉即将测试的模块缺陷。登录系统后，对缺陷进行筛选，尝试按测试前辈的Bug描述步骤进行操作，看看是否能够重新缺陷？这种方法能够借鉴测试同行的经验，尽快发现问题，避免测试的盲目性。一来可以拓宽您的视野，避免递交类似问题的Bug或是重复的Bug，二来还可以为您快速熟悉被测试系统添砖加瓦。

10、必须明白自己领导是谁：

   一般的员工进入公司，公司和部门领导很多，搞不清楚谁管我，碰到问题问谁？谁可以帮忙解决问题？如果真是这样那就麻烦了。部门领导臃肿的情况实在是太多了，有的公司，既有2测试经理，又有几个测试主管，还有多个项目经理和研发总监，不知道工作向谁回报，对哪个领导负责。弄得每个领导都回报，很累呀！！我的做法是：测试项目中负责领导只有一个那就是测试主管，测试主管负责安排和分配每个测试人员的工作和任务，我直接Review测试主管。如果项目中碰到有什么解决不了的问题，组内成员可以直接找我，同时我也定期加入项目参加部分测试，了解测试项目的一些进展情况，必要时还要找一些人谈心。这样，工作汇报比较简单明了，很轻松。

11、熟悉与测试相关的管理软件的使用：

  我说的这个测试相关的软件包括缺测试需求管理软件（如TestDirector或QC）、陷跟踪管理软件（如：TestTrack Pro、TestDirector等等）、版本配置管理工具软件（CVS、VSS，还是SVN等等），具体熟悉到什么程度，那就要看您的职位了。如果您是一般的工程师，那你就只了解一般的使用就够了，如果您是测试经理，您不仅要了解一般的使用，还要更深层次的了解软件的权限和项目的配置，因为您要作为该软件的Admin，碰到问题大部分都由您搞定呀，高工资不是那么好拿的呀，哈哈！！！如果作为新入职的您，连这些都不会，那你就得加把油了，不然到了测试启动阶段，你才开始熟悉管理软件，那么你觉的能够快速展开测试吗？

12、注意沟通技巧，把握请教良机：

  为了尽快熟悉项目，展开测试工作，沟通技巧必不可少。您作为新入职的测试人员，尽量了解每个开发人员开发的模块和每个开发人员的性格特点，寻找一些共同语言，拉近与开发人员的距离，让他们对您产生好感。只有这样，当您碰到问题的时候，他们才会鼎立的帮助您。如果您与开发人员关系不好，看了就觉的很讨厌，那他们肯定不会帮助您的，更不原意和您配合，当您提错Bug的时候，他们就会抓住这些Bug不放，有时候还要说您什么都不懂，这样你就很郁闷，肯定呆不长久的，只有走人的份了，呵呵。特别是开发人员很窝火的时候，您更要多一些理解和宽容，切勿火上浇油，您可以给他一些表扬，给他一些鼓励。他一听准开心死了，总觉得还是您们最了解我，把您当成自己人。这个时候，你再问开发人员问题，他也许态度就不一样了，他准会仔细的给你讲解，并且以后的什么事情，他也会百厌齐烦地帮助您的，因为他觉您最了解他们，无意识的把您当成了好朋友和哥们。还有的时候，开发人员有空过来测试部门逛逛，准备和您交流时，一定要把握机会，和开发人员开开玩笑和一些必要赞赏，也能够调节和开发人员的关系。总之，这一点做起来真的很难，如果做的好，那效果确实就不一样了

缺陷的生存周期？

缺陷汇报、缺陷确认、缺陷修改、缺陷修改确认、不是问题

缺陷级别？

非常低、低、重要、非常重要

缺陷管理过程？

1）提交缺陷 2）分析和定位缺陷 3）提请修改相应软件 4）修改相应软件 5）验证修改

负载测试、可靠性测试、可用性测试的定义，有什么区别

负载测试

负载测试时通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。

可靠性测试

(1)通过在有使用代表性的环境中执行软件,以证实软件需求是否正确实现。
(2)为进行软件可靠性估计采集准确的数据。估计软件可靠性一般可分为四个步骤,即数
据采集、模型选择、模型拟合以及软件可靠性评估。可以认为,数据采集是整个软件可靠性
估计工作的基础,数据的准确与否关系到软件可靠性评估的准确度。
(3)通过软件可靠性测试找出所有对软件可靠性影响较大的错误。

可用性测试：

故名思议是测试设计方案或者产品在一定的环境下的可用性水平。

软件测试的目的和原则

目的：

（1）测试是程序的执行过程，目的在于发现错误；

　　（2）一个好的测试用例在于能发现至今未发现的错误；

　　（3）一个成功的测试是发现了至今未发现的错误的测试。

原则：

（1）应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

（2）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

（3）程序员应避免检查自己的程序。

（4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

（5）充分注意测试中的群集现象。

（6）严格执行测试计划，排除测试的随意性。

（7）应当对每一个测试结果做全面检查。

（8）妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

以下摘录性能测试定位瓶颈的经验分享：

--------------------------------------

性能测试的概念是什么，基本目的是什么，我想大家都基本清楚，不作详述，总之，性能测试只是测试过程中的一种方式，帮助我们的功能更好的运行，如果功能测试是可用，易用，满足需求、用户使用为目的，性能测试无非就是让这些目的更流畅。没有什么专业的概念，无非实现两个字：好用！
    所以，性能测试这种测试方式在发生过程中，其中一个过渡性的工作，就是对执行过程中的问题，进行定位，对功能的定位，对负载的定位，最重要的，当然就是问题中说的“瓶颈”，接触性能测试不深，更非专家，自己的理解，瓶颈产生在以下几方面：
1，网络瓶颈，如带宽，流量等形成的网络环境
2，应用服务瓶颈，如中间件的基本配置，CACHE等
3，系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
4，数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
5，应用程序本身瓶颈，
以上几方面分别唠叨几句
      针对网络瓶颈，现在冒似很少，不过也不是没有，首先想一下如果有网络的阻塞，断网，带宽被其他资源占用，限速等情况，应用程序或系统会是什么情况，针对WEB，无非是超时，HTTP400，500之类的错，针对一些客户端程序，可能也是超时，掉线，服务器下发的，需要服务器返回的信息获取不到还有一种更明显的情况，应该就是事务提交慢，如果封装事务的代码再不完善，一般造成的错误，无非就是数据提交不完整，或者因为网终原因+代码缺陷造成重复性提交。如此综合下来，肯定是考虑网络有瓶颈，然后考虑网络有问题时，怎样去优化，是需要优化交互的一些代码，还是接口之类的。
      应用服务的瓶颈的定位，比较复杂，学习中，不过网上有很多资料可以参考的。一般像tomcat，weblogic之类的，有默认的设置，也有经过架构和维护人员进行试验调试的一些值，这些值一般可以满足程序发布的需要，不必进行太多的设置，可能我们认识的最基本的就是JAVA_OPTS的设置，maxThreads,time_out之类的参数我们做借助LR，Jemeter或webload之类的工具，执行性能测试，尤其是对应用服务造成了压力，如果应用服务有瓶颈，一般我们设置的log4j.properties，日志都会记录下来。然后根据日志，去进一步确定应用服务的问题
      系统瓶颈，这个定位虽说比较复杂，但是有很多前辈的经验值参考，不作说明，相信用LR的同行，也可以从性能记数器中得出一些指标值，加上nagios，cacti，可以很明显的看出系统哪些资源够用，哪些资源明显不够用。不过，一般系统瓶颈的造成，是因为应用程序本身造成的。关于这点儿的分析和定位，就需要归入应用程序本身瓶颈分析和定位了。
      现在基本所有的东东，都离不开数据库这个后台，数据库的瓶颈实在是不知道是什么概念，数据库管理员的工作，数据库管理员日常做的工作，可能就是有瓶颈定位的工作，比如：查询一下V$sys_event,V$sysstat,v$syssql之类的表，比对一下日常正常情况下的监控数据，看一下有没有异常等。其他方面，我也不是太了解。
      应用程序瓶颈，这个是测试过程中最需要去关注的，需要测试人员和开发人员配合执行，然后定位，我这儿做的大都是执行性的，比如会有脚本去运行，开发人员会结合jprofiler之类的工具，去看一下堆遍历，线程剖析的情况确定哪儿有问题。大致是这样，没有实际操作过
------------------------------------

逐步细化分析，先可以监控一些常见衡量CPU，内存，磁盘的性能指标，进行综合分析，然后根据所测系统具体情况，进行初步问题定位，然后确定更详细的监控指标来分析。

怀疑内存不足时：
方法1：
【监控指标】：Memory Available MBytes ，Memory的Pages/sec, page read/sec, Page Faults/sec
【参考值】：
如果 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。
Page/sec 推荐00-20（如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题）。

方法2：根据Physical Disk 值分析性能瓶颈
【监控指标】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length
【参考值】：%Disk Time建议阈值90%
        当内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。

怀疑内存泄漏时
   【监控指标】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time
【说明】：
Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验。


CPU分析
【监控指标】：
System %Processor Time CPU，Processor %Processor Time CPU
Processor%user time 和Processor%Privileged Time
system\Processor Queue Length
Context Switches/sec 和%Privileged Time
【参考值】：
System\%Total processor time不持续超过90%，如果服务器专用于SQL Server,可接受的最大上限是80-85% ，合理使用的范围在60%至70%。
Processor %Processor Time小于75%
system\Processor Queue Length值,小于CPU数量的总数+1

CPU瓶颈问题
1：System\%Total processor time如果该值持续超过90%,且伴随处理器阻塞，则说明整个系统面临着处理器方面的瓶颈.
注: 在某些多CPU系统中,该数据虽然本身并不大,但CPU之间的负载状况极不均衡,此时也应该视作系统产生了处理器方面的瓶颈.
2：排除内存因素，如果Processor %Processor Time计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU 瓶颈。（内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。）

造成高CPU使用率的原因：
频繁执行程序，复杂运算操作，消耗CPU严重
数据库查询语句复杂，大量的 where 子句，order by, group by 排序等，CPU容易出现瓶颈
内存不足，IO磁盘问题使得CPU的开销增加


磁盘I/O分析
【监控指标】：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time,Physical Disk\ Avg.Disk Queue Length， Disk sec/Transfer
【参考值】：%Disk Time建议阈值90%


Windows资源监控中，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

Processor%Privileged Time该参数值一直很高,且如果在 Physical Disk 计数器中,只有%Disk time 比较大,其他值都比较适中,硬盘可能会是瓶颈。若几个值都比较大, 那么硬盘不是瓶颈。若数值持续超过80%,则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。

Disk sec/Transfer 一般来说,该数值小于15ms为最好,介于15-30ms之间为良好,30-60ms之间为可以接受,超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了.

---------------------------------------------

好久了，写完这篇文章，感觉，内容是属于少部分人的，但是，这部分人对中国测试的未来影响却可能会比较大，因为作为招聘人员，他们在选择测试的未来。尽管看到，国内很多差距，但是，还是希望中国的测试行业，会越来越健康，希望这个讨论，能给招聘同仁们一点点不同的想法

================

因为工作关系，自己有机会很早就接触面试过程，招聘新的测试人员，内部提拔管理人员，并且为了这个事情，如何在候选几个人之间做出抉择的时候也有不少的思想斗争，有些感悟，记录下来。

现在想想，自己面试过的人，肯定要超过100人，面试过程，非常能够体现Interviewer的功力，面对不同的interviewee，问同样的一个问题，会有100个不同的答案，即使是相同的答案，回答的人的语气，表情，细节动作也会不同，这些肢体语言同样会隐含很多问题。怎么能从这些细节之中看到interviewee的区别，这就是功力！更深的功力在于，当别人有了不同的答案之后，你怎么继续问不同的问题，因为对于水平不同的人，你当然要问水平不同的问题，否则，怎么能看出他们的水平？如果面试高水平人员，问的好不好，人家会看出来的，他们会怀疑你们公司到底行不行，你到底懂不懂测试？所以，本身面试过程，一方面是考察候选人，另一方面，也在把自己公司的形象传递给候选人。这个过程很重要。因为对于真正的好人，人家能力强到，他在选公司，而不是公司选他，选公司，意味着起码两个条件：1，公司的待遇和知名度，2，公司里面相处的人，他以后的老板，他是否认同这个人，以有利于他以后的发展。如果他觉得你的水平不一定比他高，这个即使他进来了，你也可能没这个本事管理好。

好，下面言归正传，一步一步开始。
第一，招聘目的。一样的，要搞清楚，你们这次招聘，要招聘什么样的人。是哪个项目组招聘，那个项目组的特别需求在什么地方？比如对数据库功底要求比较高，还是业务要求比较多，或者性能测试之类的。但是这些都是特殊需求。一般，公司都是有特殊需求才开始招聘的，当然也有很多公司，会固定的招聘很多应届生，这个不做讨论。然而在特殊需求之上，我们必须定义一个基本需求，这个是组织层面的。我觉得很多公司可能都没考虑到这一点，但是，这个其实是挺重要的，你需要深入的观察你公司的文化氛围，会发现，公司有这么个文化土壤，特别适合孕育某些人，而，你招聘的时候最好招聘符合你的文化土壤的，否则不太适合成长，当然，除非你对你的文化土壤不满意。

第二，组织层面的基本需求：
1)企业文化需求：首先，组织领导需要对自己的文化有清晰的认识，要招聘什么样的人，这里主要从性格和行为方式上面来看的，比如，很多私企喜欢，踏实，能干活，任劳任怨，没有太多抱怨的人，简而言之他们喜欢“服从者”。很多比较好的外企喜欢，认证听取工作，有问题能主动提出，有自己观点，能够在压力下工作，善于沟通的人，简而言之，就我觉得，他们喜欢“聪明的服从者”。很多国企可能喜欢，比较会看到领导意图，眼睛比较活，说话办事比较圆滑的人。这里你就需要看到自己的组织，到底需要什么类型的人。这里也不是说什么类型的人好，什么样的不好，而是不同的组织文化需要不同性格的人。要是搞进来几个很不合文化的，长久留下来的可能行不大，而且会对管理者产生挑战。
但是，是否说，就一定不要招聘这样的人呢？不一定！有时候，为了组织内部的改革，为了文化的更新，你就是需要几个特别有反叛精神的人，制造一个“鲶鱼效应”！所以说，这个因地制宜。但是，你本身想要建立怎样的文化氛围，精神上的工作环境，这个你自己必须清楚。比如，我就是为了找几个好好干活，老老实实挺话的，遵守规章制度的，那没关系，这种人多得是。你一面试就能看出来这个人是不是很活跃了。太活跃的，有思想的你不要就是了。

2)个人素质需求：上面谈的是个性方面的，更重要的，除了个性之外，还有个素质问题。不同个性的人，可能都有差不多的素质，这个素质，是指：学习能力，沟通能力，思考能力，工作能力。也就是说，有的人不爱说话，有的人很活跃，但是这不妨碍他们的学习能力，可能基础都很好，学习新东西都很快。这些东西，我们要有整体考量。当时我招聘的时候，我就首先观察我现有整个团队的人员素质问题，然后，根据平时的绩效考核，还有自己的观察，找出2，3个素质比较平均的人，以这个人作为标准。招聘的时候，我就回想，如果以这个interviewee和我的这2，3个人做比较，如果，光考虑他们的素质，不考虑经验，我是否会选择他们，如果答案是“yes”，这个基本上我就考虑要这个人了。以为他的到来只会让我们整个团队的素质提高，而不是下降，否则，导致我团队平均素质的下降，我要这个人干嘛？

以上两者，个性+素质，作为基础需求，不过，这是个动态变化、渐进明细的过程，因为，首先你对组织文化的认识，还有方向的认识是逐渐深入的，其次，整体团队的素质应该在你的这个文化的影响下是逐渐提高的，如果不是的话，你需要思考你的团队文化了，需要思考是不是自己不称职？是不是要把自己换掉了哦，呵呵。

第三，是项目或者某次招聘的特别需求，这个，基本上是技术方向上的特别需求。招聘的时候特别把握一下就好了，比如英语要求特别高的，或者需要性能测试的。但是，就我觉得，如果可以，尽量把这个人的这些特别需求建立在刚才所说的基础需求之上，最好这个人是适合前面所说的文化土壤的成长的，如果可以最好这样，不行，再求其次，并且考虑让这个人接受公司的文化。

上面两点之所以如此强调文化，我是想说，无论招聘还是应聘，目光都要放长远，不要那么在乎短期利益，把一个人骗进来了，那只是短时间的，没什么意思。有些公司不错，但是，有些人就是不适合这个公司，不喜欢你们这个所谓的好公司的氛围。比如Huawei,我周边，有不少人都不喜欢这个公司，尽管他待遇相当不错，但是，他就是不喜欢，不喜欢他们对事情的看法，不喜欢做事情的风格，不喜欢拼命的那股劲。尽管很多人很赞美这个床垫文化，但是，他不喜欢，你要是不告诉他，看他能力强，硬是把他来进来了，也没太多意义的，反倒是会破坏你文化的凝聚力。当然我不是说华为不好，总体来说，在全球，华为做出来的成绩是中国企业中非常难得的。
另外其实有很多企业，压根也没啥真正的，值得深掘文化内涵在里面的话，其实作为领导的需要仔细琢磨一下了，一个好的领导带出来的团队，是应该在上面有他自身无法磨灭的痕迹的。

第四，招聘面试过程。
1)面试人数比例.首先仔细挑选一下简历，选择出所需人数150%-200%的人来面试。选择面尽量广一点，很多人很有本事，只是简历写的不好，或者只是不够好好表达，这部分人不能漏掉。给他们个机会，并且让他们能表现出他们的能力。当然怎么能让他们表现出他们的能力，这个就看interviewer了。

2）先观察不急于判断。招聘过程有个东西很重要的，一般，如果2个人，或者3个人一起来做interviewer的话，尽管很多人说，一般前3分钟，就能看出来是否要这个人了，但是，如果你可以，请尽量不要在这3分钟之内做出判断，尽量延长到10分钟，因为，前几分钟一个人的表现，波动很大，往往情绪都没稳定。这时候的判断是有偏颇的。另外，尽量，不要在当场做出判断，而是主要记录这个过程，如果按照七顶颜色的帽子的说法，应该是“白色思维”，客观的思维，然后，面完之后，3个人再合计一下，每个人对这个被面试者的观察，然后根据这个客观观察做自己的推理判断。这个非常重要，可以参见《七顶颜色的帽子》这本书。

3）面试过程的判断：首先基于公司文化需求来判断，在基于公司本次招聘需求来判断，如果前期的需求做得好，现在的判断也跟容易。另外作为一个高素质的interviewer，我时常提醒自己，要荣辱不惊，保持一颗平静的心，O(∩_∩)O哈哈~，不过，我说的也是事实。因为有一次，一个很丑的人过来面试，当时，我们3个人在面试，一见面，吓了一跳，那个男的，真的很丑。星爷电影里面有个叫如花的，不过，不是那个胖如花，而是那个做过什么生发水广告的，那个如花，真是，跟他差不多。虽然我当时感觉，我根本就不想看他，但是，当他回答问题的时候，我还是让他看出，我在看着他，并且期待他的回答。不过，很囧的时，这10分钟时间，另外两个面试官，竟然都是低着头，而且基本不说话……我很囧。尽管最后没有录取他，但是，并不是以他的容貌作为判断的。现在想想，幸好，他技术不是很好，我并没有觉得良心上有啥挣扎，否则，又是个tough  question了。 

强调：如何判断一个有争议的，重要角色的人物？这个Jack Welche做过详细的探讨，不过，我想说的是，这个一定要问自己的那颗心，一定要让自己真诚的说服自己，能够录用这个人，而不是要努力说服别人录取他。而且这个非常消耗面试官的功力。我以前自以为自己看人能力还不错，基本上面试一个重要的人，需要30分钟左右，但是后来换公司之后，看见我们老板面试，差的3分钟，好的20分钟，那个真是快啊。可是，尽管很快，但是把人招聘进来之后，能看到基本都还可以，差距不大。但是，我再后来看到另外一个公司，招聘的水平就很有限了，特别是对经理人员的招聘，几乎只看简历，不看人！很多的经理的管理水平相当的差，不少事情安排不合理，很多员工也都不愿意在他手下工作，当然这个判断也是基于，默认我是一个合格的经理人基础之上判断的。招聘一个错误的经理人，绝对可以抹杀前面你大部分的功绩。在好公司，很大部分员工的离开，都是因为自己的boss。

4）面试官的私心。其实这个也不是难得，关键是，当作为男人的你，遇到美女了，你该怎么办？你会不自觉的多面试一会吧？不自觉的，放低标准吧？能让她进来就尽量让她进来吧？而丑女，你就是能不让她进来就不让她进来了吧？O(∩_∩)O哈哈~，如果，小美女进来了，你孤独已久，漂流已远的心，是不是又再一次焕发生机，是不是在想可以再一次停靠港口了呢？ 所以，其实面试别人的过程，也是面试自己的过程，也是面对自己内心的灵魂的另一面的过程。看看你是否为会用自己的权利来交换那点阴暗的私利的过程，如果交换了一次，你是否，会在以后做出更大交换的过程。 当然从候选者的角度看，你完全可以利用面试官的私心来达到你自己的目的，呵呵...

5）面试过程，如何问问题？如何看出这个人的能力？有些人，面试的时候，表现的很好，能说会道，很配合，表现的很积极，也很合作，但是近来之后，发现似乎不是这样，会不懂装懂。这个，其实，有很多，特别是技术能力，在面试阶段就是可以面出来的，可以发现问题的，而不是等到近来之后才发现不行。怎么面试呢？面试问问题，最好一个问题套一个问题，一个问题深入一个问题，直到问出这个人不明白的，不懂得为止，如果没有不懂，而且回答的很清晰，那说明这个人的确很强。而，同时，如果这个人刚开始的几个问题有欺骗的成分在里面，你几个相关的问题一深入，就会暴露出前面的谎言了。问题，本身的设计，最好是开放的，可以深入的。如果是另外一些非技术问题（有些技术问题也可以），可以问些，比较有争议的，比较能仁者见仁，智者见智的问题，而不是答案非常确定的问题。我们的目的透过这些问题，要看到这个人的思维过程是怎样的，逻辑性是不是很强，在我眼里，思路正确要远大于答案正确。透过这个过程也可以看到这个人的世界观，是善良的，是相对自私的还是比较乐于合作的。所以，看人，主要从有争议的问题中看，而不是听他直白的说。

第五，面试之后，进公司之后的进一步判断。当然，这个本不属于招聘过程了，但是他是这个过程的延续，因为，本来招人，是有个考量的，后续的过程也是这个考量的一部分。你对整个团队需要有个布局，不同的人，根据他们自身的特点，有你作为领导人的布局，当然，这个人是否合适，最好的方法就是，就我自己的感觉，就是放给他们权利。看看，权利是否会毁了这个人，是否会成为权利的奴隶。当然，能够好好利用权利，并认真对待职责的人太少了。好好驾驭他们，给他们犯错误的机会，给他们鼓励，也给他们惩罚。最后这个过程反过来应该对前面招聘的需求，和对人的判断有个反馈，需要你仔细反思为何招聘了这样的一个人进来。又是一个PDCA。这个，很多内容，有机会以后再论述吧。

ok, it is over!

======================

这篇文章，很久以前就写了一半。明天，就是我在这个公司的最后一天了，离职之前的这个上午，伴着5年前买的Shania Twain的up专辑音乐，写完这篇文章，不知道，下次更新会在什么时候。也不知道自己的方向，是否能到达我理想的斯坦，就让这篇文章做一个路标吧。

PPT高手的制作思路

制作PPT需要思考的东西很多：思路，架构，版面，色调，详略，图片等等。即便是做了8、9年PPT的高手每次在做新PPT之前，还是会很头痛！

      网络PPT高手根据经验,总结了一些做PPT的流程，非常感谢分享：

1、最开始什么都不要想,不要去查资料,也不要接触电脑,而是用笔在纸上写出提纲,当然,能简单的划出逻辑结构图最好了.越细越好.

2、打开PPT,不要用任何模板,将你的提纲按一个标题一页整出来.(过去我就总是追求完美,首先搞摸板,花掉半个多小时,做的过程中不满意又修改,做完后又修改,甚至最后完全推翻—-伤神费力耗时!!)

3、有了整篇结构性的PPT(底版/内容都是空白的,只是每页有一个标题而已),就可以开始去查资料了,将适合标题表达的内容写出来或从网上拷贝进来,稍 微修整一下文字,每页的内容做成带”项目编号”的要点.当然在查阅资料的过程中,可能会发现新的资料,非常有用,却不在你的提纲范围中,则可以进行调整, 在合适的位置增加新的页面.

4、看看PPT中的内容哪些是可以做成图的,如其中中带有数字、流程、因果关系、障碍、趋势、时间、并列、顺序等等内容的，全都考虑用图画的方式来表现。 如果有时候内容过多或实在是用图无法表现的时候，就用“表格”来表现。实在实在是不行了，才用文字说明。所以，最好的表现顺序是：图–表–字。这个过 程中图是否漂亮不要在意，“糙”点没关系，关键是你用的图是否准确。

5、选用合适的母版，根据你的PPT呈现出的情绪选用不同的色彩搭配，如果觉得office自带的母版不合适，自己在母版视图中进行调整，自己加背景图、 Logo、装饰图等。其实关于母版颜色的选择，这么多年，我也一直没有研究透彻，据说不同的颜色会给人带来不同的感情冲击，专业的书讲的都是些狗屁理论， 不就是情绪吗？我就按自己的情绪来定了。当然，如果是有公司自己的标准模版，就不用费这些工夫了，直接用之。

6、在母版视图中调整标题、文字的大小和自体，以及合适的位置。

7、根据母版的色调，将图进行美化，调整颜色、阴影、立体、线条，美化表格、突出文字等。注意在此过程中，把握整个PPT的颜色不要超过3个色系！否则你的PPT就显得特别乱而且“土”！

8、美化页面，看看哪里应该放个装饰图，图片可以从网上找，建议用GOOGLE的图片搜索（用英文最好），装饰图的使用原则是“符合当页主题，大小、颜色不能喧宾夺主！”

9、最后在放映状态下，自己通读一遍，哪里不合适或不满意就调整一下，修改错别字！

10、你以为这就完了吗？？没有！注意错别字！（上一步你已改过了，但不够！你自己做自己查的正确率并不高），你知道吃饭的时候，饭里有只苍蝇是什么感觉 吗？就是看PPT时看到错别字时的感觉！而且读者一般是老板或客户，会非常怀疑的专业精神和工作态度，前面99%的工作已经做的非常不错了，但你的给读者 印象却可能毁于这1%的失误上！因此，将PPT给你的同事或者朋友检查一下，如果文件很重要，建议给2-3个同事检查。

密技真言：

尽量用1种字体，最好不要超过3种
PPT的灵魂—-“逻辑！”
PPT的恶心—-“错别字等于苍蝇”
3色原则：“不要超过3种色系”
6字解码：“大化小，小化图”—-提纲时，用逻辑树尽量将大问题分解成小问题，小问题用图表现。
12字真言：“能用图，不用表；能用表，不用字”
只要掌握如上原则，PPT肯定不会很“糙”或“土”，而且具有专业精神！

绝招一：文字是用来瞟的，不是读的

      我们时不时听到这样的言论：“PPT很简单，就是把Word里的文字复制、粘贴呗。”这其实是对PPT的一种无知与亵渎。如果直接把文字复制粘贴就能达到演示的效果，PPT根本就没有存在的必要了。
      PPT的本质在于可视化，就是要把原来看不见、摸不着、晦涩难懂的抽象文字转化为由图表、图片、动画及声音所构成的生动场景，以求通俗易懂、栩栩如生。

形象，至少能给你带来三方面的感受：
    一是便于理解。
      文字总是高度抽象的，人们需要默读、需要转换成自己的语言、需要上下联想、需要寻找其中的逻辑关系；但人们看电影就轻松许多，只需要跟着故事的发展顺理成章地享受其情节、体味其寓意就行了。PPT就是要把这些文字变得像电影一样生动。
    二是放松身心。
      如果把一本小说贴在墙上，相信你看半个小时就会腰酸背痛；如果把小说拍成电视剧，也许你看上一天也不觉得疲惫。就是这个道理。
    三是容易记忆。
      传统的PPT，你需要观众记住的是文字，这个难度太大了，即使记住了也很容易忘记；而形象化PPT，可以让观众轻松记住其中的图形、逻辑或结论，也许三五年后，人们仍然能够记忆犹新。
      改变那种“复制、粘贴”的做法吧！把那些无关紧要的内容大胆删除，把长篇大论的文字尽量提炼，也许刚开始你不习惯，也许你做得还很粗糙，别放弃，总有一天你会让观众赞不绝口的。
      有的领导会问：“如果PPT没有文字，你让我讲什么？”的确，演示习惯的改变不是一朝一夕的事情，这依赖于演示者对内容的熟悉程度和演示技巧的掌握程度，但有一点，带着观众读文字是演示的大忌，杜绝这一条，演示效果会逐步得到提升。
所以，提出了两个观点：
1、文字是用来瞟的，凡是瞟一眼看不清的地方，就要放大，放大还看不清的，删！
2、文字是PPT的天敌。能减则减，能少则少，能转图片转图片，能转图表转图表。

绝招二：20分钟是快乐的极限

      传统上，我们总是认为，讲得越多，时间越长，越体现出演示者的重视。这是计划经济时代的标准。现在，无论我们的领导、客户还是普通的受众，时间都极为宝贵，没有人愿意阅读动辄数百页的研究报告，也没有人去听你的长篇大论。浓缩的才是精品！
    演示的核心内容是什么？观点！
      在此基础上把观众容易困惑的地方、你认为重要的地方作一些说明。永远不要担心你的演示过短，如果花费20分钟就能够把一天才能了解的内容讲清楚，你实际上为观众节省了7小时40分，在时间就是金钱的年代，观众当然求之不得。
      简短的另一个好处是意犹未尽。如果你的演示足够精彩，会给观众留下更多的期待和回味，甚至会有人要求把你的PPT拷回去好好研究几遍呢。
      简短，也对PPT提高了要求。你需要了解哪些内容是观众最关心的，哪些内容是非讲不可的，哪些内容是能带来震撼的，据此，该合并的合并，该删减的删减。也许，这是一个反复的过程，但标准只有一个：不要让观众有打哈欠的时间。

绝招三：清晰比什么都重要

PPT有一个致命的弱点——观众容易迷失思路。
为什么？
一、PPT毕竟不是电影，其逻辑结构是抽象的，难以把握；
二、PPT是一页页翻下去的，一次只能看一页内容，前面看过的只能依靠记忆。
解决的办法有两个：
一是事先给每位观众发一份演说纲要；
二是给你的PPT建立清晰的导航系统。
导航系统主要包括：
一、从片头动画、封面、前言、目录，到切换页、正文页、结尾页等一套完整的PPT架构（本书第3章将详细介绍）；
二、每页都有标题栏（除了标明整个PPT的标题，更重要的是标明本章节的标题、本页的主题）；
三、页码，如果方便的话也尽可能加上。

绝招四：没有设计就等于垃圾

      传统上，我们把PPT归结为办公处理之类的工具，认为只要简单排版就可以满足需求。
      随着整个社会审美标准的提升，这一观点正被越来越多的人抛弃。PPT，特别是对外PPT，正成为公司形象识别系统的重要组成部分，代表着一个公司的脸面；设计，正成为PPT的核心技能之一，也是PPT水准高低的基本标准。
      无论是汇报、宣传还是比赛、竞标，一个设计精美的PPT最少可以起到以下作用：
（1）让观众赏心悦目：美女养眼，精美的PPT养神。
（2）让观众产生好感：爱美之心人皆有之，漂亮的PPT自然能让观众多看几眼。
（3）赢得观众的信任：人总是有偏见的，精美的设计给人专业、认真、可靠的感觉，内容的含金量也自然得到提升。
（4）赢得成功的机会：在职场上，美女与帅哥有更多成功的机，PPT演示也是如此。
      内容的好坏难以评价，但形式的优劣却显而易见，喜欢而又信任的方案自然是领导和客户的首选。
设计非一日之功，但我们可以找到捷径：
（1）善用专业素材：专业的PPT模板让你的PPT拥有外在美；专业的PPT图表让你的PPT
具备内在美；专业的PPT图片（包括JPG、PNG、AI等格式）让你的PPT充满生机。
（2）掌握排版的基本原则：每个人的审美标准是不同的，但总有一些规律是相通的，掌握并遵守这些规则，将使你的PPT设计得到大多数人的认可。这些规则包括：一个中心、合理对齐、画面统一、强烈对比、层次分明等，本书第6章将详细讲述。
（3）多看精美案例：PPT诞生以来的十多年里，整个社会的设计水准都在迅速提高，三人行，必有我师，在平面设计、动画领域，处处都有值得我们学习的案例。

绝招五：炫不是动画的根本

自PPT诞生以来，动画就一直是最大的争议。
一 种观点认为，PPT就是幻灯片，就是一页一页翻过的图片加文字，在商务PPT应用领域，根本不需要动画或者最多只需简单的页面切换动画； 相反，有无数的仁人志士对PPT动画矢志不渝，用自己的创意和努力一次次创作动画的传奇，也得到众多PPT爱好者的欢呼雀跃。
近年来，锐普PPT把PPT动画成功应用到商务领域，并得到客户的广泛认同。
动画，不仅仅让PPT变得生动，更能让PPT表现效果数倍提升。
（1）片头动画
让 你的PPT一把抓住观众眼球。电影有片头、游戏有片头、网站有片头，PPT演示也需要片头。演示开始时，观众往往会需要一个适应期，也许 还在想着刚才没有处理完的工作，也许还在跟邻座侃侃而谈，也许还在抱怨着观看演示的辛苦，这时候，你需要立即把观众的视线聚焦到你的演示中来，精美和创意 的片头能立即给观众带来震撼，让观众目不转睛。
（2）逻辑动画
一幅静止的画面，观众会 自上而下全面浏览，缺乏逻辑的引导，观众难以把握重点，看完之后还要思考其中的逻辑关系，实际上浪费了精力和注意 力；如果给这幅画面加上清晰的逻辑动画，就把观众自己找线索变成了帮观众理线索。演示者可以控制对象出现的先后顺序、主次顺序、位置改变、出现和退出等， 引导观众按照自己的思路理解PPT内容。
片头动画让对外宣传的PPT尽显企业的专业与实力。一束光闪过，该公司的logo由轮廓逐渐变得靓丽十足，让人记忆深刻；紧跟的4张动画页面从不同角度展现了上海及该公司的风貌，同时配以连续抽象的文字和动画效果，消除了页面之间的分割感。
（3）强调动画
以 往我们只是用颜色的深浅、形状的大小以及字体的不同来突出某些重要内容，这有一个很大的弊端，就是要强调的内容会一直处于强调地位，当我 们讲述别的内容时，它会分散观众的视线；强调动画，通过对象的放大、缩小、闪烁、变色等动作实现强调效果，并能够让演示者自如控制，强调过后自动回复到初 始状态。
（4）片尾动画
与那些戛然而止的PPT相比，加一个简单的片尾动画将收到意想不到的效果：
一是作为礼貌，提醒大家演示结束，并给人一定的缓冲时间，准备接下来的活动；
二是与片头动画相呼应，做到有始有终，避免给人虎头蛇尾的印象；
三是通过贯穿始终的形式，提醒观众回忆内容，强化记忆。
（5）情景动画
也许你讲述的就是一个故事，故事总是有情节、有过程的，而要用一张静止的画面去表达一个完整的过程，几乎不可能。相反，一套连续的动画，则能把这些过程表现得栩栩如生。以往，我们用Flash、视频来表现这些效果，PPT其实也能够实现。

绝招六：图表是PPT的筋脉

      商业演示的基本内容就是数据，于是图表变得必不可少。最早出现的是柱图、饼图、线图、雷达图等；咨询公司把数据图表转移到对逻辑关系的表达 上，于是出现了并列、包含、扩散、综合、层进等各类关系图表，从此，文字也可以不再抽象、乏味了；以ThemeGallery为代表的韩国公司、以 PresentationLoad为代表的欧美公司以及以锐普PPT为代表的中国公司等设计公司，则进一步把这一趋势发挥到极致——加入了设计的概念，从 此，文字可以变得像图画一样精美、形象、栩栩如生。
      同样，PowerPoint软件就像天生为图表而生的，强大的像Illustrator一样的绘图功能，加上清晰的操作界面、简单的操作模式，让人人都能轻而易举地掌握。很快，PPT图表就风靡全球，与图片配合使用，让演示如虎添翼。
      如果你的PPT还在受大段文字的困扰，还在为逻辑混乱而发愁，那就赶快学习PPT图表吧。

绝招七：没有策划就没有精品

      好的PPT是策划出来的，就像宏伟的建筑是规划出来的。
      所有的PPT设计师者首先是策划师，有的是无意识为之，有的是用心去做的，但没有策划的PPT必定是失败的作品。不同的演示目的、不同的演示风格、不同的受众对象、不同的使用环境，决定了不同的PPT结构、色彩、节奏、动画效果等，PPT的人介于观众、领导、演示者等多重标准的审视。
一个好的PPT作品基于对以上要求的准确把握。
      我们曾经有一些卓越的设计师，出来的作品很美、很耐看，但却一直得不到客户的认可，为什么？就是缺乏准确的策划。美，不是PPT的唯一标准；经验、用心、设身处地为观众着想，即使画面有瑕疵，也往往能赢得演示者的认同和观众的喝彩。

绝招八：PPT可以当主角

      西方有一种观点开始在中国流行：演讲者永远是主角，PPT不过是陪衬。
      其实这完全是站在西方立场上的一种观点，未必适应中国国情。西方人大多喜欢张扬，擅长演说，甚至在很多人看来演说已经是一种享受，当然不愿意被PPT抢了风头；但中国文化更强调内秀，不愿意抛头露面，擅长演说者更是寥寥，甚至连一些领导在众人面前也不愿张扬，何况一般人？所以，我们常常把自 己作为的一员，是我们代表演说，我们不过是一种符号，低调再低调，宁可把PPT作为众人瞩目的焦点。
从另一个角度讲：我们是为了演示而演示吗？是为了表现自我吗？
当然不是！每次我们都是抱着一定的目的进行演示的，或者为了让观众了解我们的工作，
或者为了让观众选择我们的产品，或者为了沟通一些信息，或者纯粹为了博得大伙一乐……能找到必须让我们成为主角的理由吗？
没有！
效果为王，只要能达到目的，不要在乎谁是主角、谁是配角。
如果你是一位表现欲极强的演说大师，如果这是一个需要你展示自我的舞台，那你就勇敢地站出来，做主角吧！
如果你是一位稍微内敛的工作者，为了工作才进行这次演示，或者这是一个需要低调的场合，那就不必拘泥于大师们的说教，即使你是配角，也能得到最热烈的喝彩。

绝招九： PPT不是哑巴

在很多人眼中，PPT是多媒体的代名词。但这个多媒体，却一直因为无声而名不副实。
细分析，无声原因有三：
一是PPT的商务特点限制了声音的应用，毕竟在商务会议场所，人们需要集中精力思考，无论是背景音乐还是动画声音都会给人们带来干扰；
二是PPT软件设计的功能限制了声音的应用，PPT软件生下来就没有为声音的应用做好充分准备，仅仅了这一功能，对声音的编辑、优化等功能，PowerPoint还无心顾及；
三 是PPT人群实在太广，经理、文员、老师、销售代表、老总、领导、甚至一些小学生都成了PPT技术员，大家相关的知识储备远不够，缺乏声 音素材、缺乏声音感觉、缺乏声音编辑的技术，但不知不觉中，有人还是尝试起来，结果声音应用不专业，特别有些动作声音常常引来观众一阵哗然。于是，有人总 结了，PPT勿用声音。
果真这么绝对吗？
形势正在悄悄变化，PPT有声时代正在来临。
（1）PPT早已不再限于汇报演示，企业宣传、婚庆礼仪、休闲娱乐等正成为PPT应用的热点领域，声音是不可或缺的元素。
（2）平面设计、flash、视频等时刻冲击着人们的视觉，人们正经受着最严重的审美疲劳，单纯靠画面给人的刺激已经大大降低，声音是增强画面冲击力的绝佳武器。
（3）PPT设计公司的崛起，让PPT声音的处理专业化，声音素材库搭建起来，各类声音编辑软件应用自如，配音设备逐步完善，PPT中声音运用的规律也已经把握到位。

绝招十：退“三”进“七”

要让PPT高人一等有很多方法，率先使用PowerPoint 2007，无疑是最有效的捷径。
从PPT专业应用角度看，PowerPoint的以下特点都是我们极为推崇的。
（1）操作界面更美观、更人性化
● 全新的vista般操作界面，让人赏心悦目；
● 对文件整体管理的功能集中到左上角的offi ce按钮里，为操作区留出更大空间；
● 操作区域更开阔、归类更合理，操作熟练后一目了然；
● 自定义按钮非常个性化，把常用的功能放在这里调用更快捷；
● 选择窗格与Photoshop 窗格类似，“层出不穷”成为现实，使PPT各项功能全面提升；
● 放大/缩小按钮与视图模式按钮同时放置于右下角，更适应一般人的操作习惯。
（2）绘图和设计功能更强大
（3）丰富而实用的功能集群
这些功能包括：
● SmartArt图表，可以把文字轻松转化为图表。（只是目前所的图表种类较少，质感过于单调，从设计的角度并不主张过多应用。）
● 为PPT文件减肥，2007版的PPTX格式的文件比2003版的PPT格式文件小了很多。
● PPT可以直接转为pdf、xps、jpg等格式，并可把其中的部分PPT页面发布出来，供各类场合使用。
● 有效防止文档崩溃，在2003版里一旦文档出错，没有保存的数据都会丢失；2007版则能够尽力恢复程序关闭前的状态。
但2007版也存在一些明显的遗憾：
其一是对电脑硬件要求较高。不少学员反映，500MHz以下的处理器、256MB以下的内存的电脑用起来都较吃力。
其 二是与2003版的兼容性不够。PPTX文档一般要转化成PPT文档或者安装插件才能在2003版的PowerPoint中读取。用 2007版所作的立体艺术文字、艺术图形在2003版中是无法编辑的，部分颜色渐变效果、阴影效果、文字效果，甚至一些动画在2003版里会发生变形，需 要在2007版里对照编辑。
但这些缺陷改变不了2007版快速普及的趋势，要想实现超人一等的PPT表现效果，PowerPoint 2007无疑是最佳的选择。

文章中观点来源于《PPT演义》一书中的总结，文章内容转载自且行资源

大家天天都在谈管理，如何管理。本人也做管理四年了，本日志就是对这四年得一个总结吧。

做管理者分二种：一技术型管理者、另一种就是权术型管理。

二者的区别，前者是以技术、实力服人；后者是以手段、玩权等方式服人。

但还有一种人是权术型管理者打着技术型管理的牌子来管理。（也就我们常说的装NB的人）这种人我个人觉得应该不能算是管理者，应该算是小人。

做管理者的必备条件

不管是技术型管理者还是权术型管理者都得有几下共同点

一是人格魅力：一定要有自己的人格魅力

二是思路清晰：不管做什么事，计划、方案等要事先想好。思路要清晰明了。

三是协调能力：要有高强的协调能力，沟通技能等

四是执行、下达命令能力：如果你是中高层领导都这一条也是必不可少的。

五是开拓、创新能力：要会总结，在总结的基础上进行开拓、创新。有些人有开拓、创新能力，但就是想出来点子或办法不服实际的工作情况，这开拓、创新能力也是等零。

六是指导能力：给你的团队或组织要能正确指导、引导能力。

其它还有许多，就不一一列出来，此处只列个人感觉比较重要的。

如何开展你的管理工作

一是计划：什么事都应该做计划。不管计划做的怎样，都应该有。计划中应该设定完成的目标、开始结束时间、人员、事件等

二是方案：根据实际的事件给出相应的方案。比如我们常见的方案--测试用例。

三是执行、下达命令：给你的团队、你的下属下达命令；其次是执行计划与方案。在执行的过程中会产生监督工作，其次是指导工作、协调工作。

四是总结：一件事务完后，一定的总结。

五是开拓、创新：根据总结，进行开拓和创新

如何提高你的管理能力

有些人做了8-10年的中层领导或小组长，自己的工作也很卖力，但就是升不上去。今天以我的观念来畅谈一下：

一是没有顾大局能力或思想：这条也80%人都会犯的错误。他只想到自己、不顾其领导、下属的想法，这样的人很难提升。

二是总与直接领导比较，甚至瞧不起直接领导者：如果你的直接领导真不如你，你也不应该去比较；更不要拿领导与其他领导去比较；其次是要尊重你的领导；如果他能当上领导，那他一定有他的长处。

三是没有进取精神：自己到了一定位子，就不进取。很满足。这也是一大忌。

其次是把握机会：当机会一来时，要及时把握。

以上说得也不知对不对。总结上述,如果要提高你的管理能力，要随时有顾全大局；要尊重领导；服从领导；随时“充电”；再加把握机遇。

今天就说到这里，我得开始工作了。下次再述