tomcat-清除缓存

方法一：
 conf/server.xml文件
 Context path中间加上reloadable="true"
 例如：<Context path="" docBase=""  reloadable="true">

方法二：
 删除work目录下的缓存文件
 可以把Catalina目录删除；
 
 注意：不能把work整个目录删除，不然重启tomcat时，会把conf/web.xml删除掉，这样在启动时，日志会提示：No Default web.xml，且访问页面会显示404错误；

关于session机制的一些总结

一、cookie和session的区别与联系。
    “让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：
    1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。
    2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。
    3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。
    由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。 ”

二、session是如何实现。
      session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。既然信息是保存在服务器中，那么现在主要问题是，作为查询关键字的session id如何产生以及如何在服务器和客户端间传递呢？方法有三种：
     1、使用会话cookie。这种cookie不记录在磁盘中，由浏览器记录在内存中。这是session最主要的实现方式。
     2、如果客户端禁用cookie，不能使用第一种方法，则通过改写URL的方式，将session id附加在url中回传给服务器。
     3、使用表单的隐藏字段。这种方法用的比较少。

三、session何时创建
    “ 一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <%@page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。”

四、session何时销毁
     “除非程序通知服务器删除一个session，否则服务器会一直保留，程序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。（因此最好session不用的话就删除它，及时释放资源，而不需要等到超时再由web容器来删除）
     恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间”（Tomcat可在web.xml中配置，也可以调用session的setMaxInactiveInterval方法进行设置）

五、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session？
       “不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。对于保存在内存里的cookie（session就是通过这种方式实现的），不同的浏览器有不同的处理方式。对于IE，在一个打开的窗口上按Ctrl-N（或者从文件菜单）打开的窗口可以与原窗口共享，而使用其他方式新开的IE进程则不能共享已经打开的窗口的内存cookie；对于Mozilla Firefox0.8，所有的进程和标签页都可以共享同样的cookie。一般来说是用javascript的window.open打开的窗口会与原窗口共享内存cookie。”（也就是说，如果你是使用session进行身份验证的话，你使用Maxthon浏览器在一个标签的页面中登陆成功后，在另外一个新开的标签中也就登陆成功了，因为它们共用同一个session）

六、服务器关掉后，当前session会丢掉吗？
      这个取决于你使用什么样的web服务器以及web服务器是如何配置的。tomcat在shutdown前默认会自动将session保存到指定的目录中，重新启动是重新加载，因此tomcat重新启动后，session是可以继续使用的。此外，你还何以将session保存到数据库中，这个要在server.xml中配置。

（此文为转载，出处查不到了）

全文如下：

开头语：

作测试很久了，一直为一些问题所困扰，也一直对微软有一种顶礼膜拜的向往，终于有一天，近距离的接触了微软的测试，感觉不是以前想象中那么遥不可及，却又难以企及。于是把个人觉得微软值得借鉴的地方整理了一下，希望能对大家有所帮助。

1．  测试流程

首先说说测试流程，微软的测试流程也没什么新的东西，和大多数的测试流程一样。

大致是先进行测试准备，然后是Testcase的编写，然后是白盒测试（不一定每个项目都有），然后是功能测试阶段，然后是验收测试，最终release。

如果看流程的话，和一般公司大同小异，没什么新花样。但是我觉得值得借鉴的是两点。

第一，   微软的流程执行的非常认真。

这点非常值得提倡，我们都知道，测试的最终质量决定于测试流程和测试人员素质，要想测试质量有保证，要么是流程很完善，要么你流程不行，但是个人能力超强。如果有一个很好的流程，就算执行的人稍微差点，最终的质量也不会差到哪里去。所以流程是很重要的。

但是，看国内的公司欠缺的就是这个，要么是没有流程，要么流程是个花架子，没认真执行过。我想微软的测试人都是超级牛人，但是人家还是老老实实的忠实按照流程来走，我觉得这点非常好。（在IBM 也是这样，笔者以前在IBM作项目的时候，发现他们的文档写的特认真，流程特认真），所以说忠实的执行一个好的流程是成功的一大半。

第二，   在整个流程中，微软非常强调测试尽早介入。微软在这方面是一致提倡的，按照我们国内IT业的恶习，一般都是软件主体差不多成型了，拉几个测试人员过来点点，其实这是非常不好的。微软的测试人员在项目一开始就和开发人员同步介入，在需求阶段就开始介入，进行需求评审。在开发人员开始编码的时候，测试人员就开始编写Test case，并开发一些测试工具，或者写一些配套的测试代码（不要奇怪，微软的测试人员都能写很好的代码）。微软的理念就是：预防bug比解决bug好，所以非常提倡测试尽早介入，把一部分bug消灭在需求阶段。

2．  自动化流程

说到自动化，大家可能以为我是说微软的自动化测试工具多牛，其实微软内部用到的自动化测试工具倒是不多，就算有也都是内部开发的，非常实用的，他们不会去用MI的工具。

        说微软的自动化程度高，主要是体现在流程方面，譬如说整个自动

    构建流程，在开发人       员代码check in之后，系统自动发邮件，邮

    件内容就是一个change list，包括代码更新list以及一个编译者添加的comment，其内容是该版本功能的变化或者修改掉的bug ID。整个测试过程中能用自动化的地方都尽可能采用自动化，尽可能减少人为失误，并且可

    以使人和机器并行工作。个人觉得，这点很值得我们国内的测试公司借鉴，能自动化的流程都自动化，减少一些不必要的沟通。

3．  质量控制机制

说到质量控制是个大问题，需要整个团队和流程提高素质。那么微软的质量控制可以借鉴的是什么呢？是他们的机制。在微软的测试流程当中，在开发的早期，项目中所有的问题都是Dev leader和PM商量说了算（当然也要参考需求方的意见），但是到后期，具体就是功能测试之后，项目的主动权都在测试这边，某个bug的要不要解决，或者项目进度控制都是测试leader说了算。这和国内的大多数软件公司是不一样的，在微软，测试人员要对最终的软件质量负责任，但是也有相应的权利来约束开发人员。当然，他们也肯定有一些bug是产生争议的，这个时候的仲裁机制就是PM，这个不是我们传统的PM（Project manager），而是一种具有微软特色的PM（全称是Program manager）。这样，测试人员在对一些争议bug的处理上有相当的话语权。

4．  测试用例及管理

微软的测试用例倒没什么特别的，不过看过他们用例之后，还是觉得写的详细，认真，但是又不冗长拖沓，这个需要很高深的水平。另外，微软的测试用例管理用的是微软自己开发的用例管理工具。

另外值得说明的是，微软的每个用例都进行了分级，并且功能所在的模块都标的很清楚。

5．  效率

在效率方面，微软的测试效率非常高！高的让人惊叹，我问一个在微软工作的哥们，“你们那边测试的最大特点是什么”，他说“最大特点是快！”，就是效率很高，具体就是在测试后期过程中测试和开发之间的反馈非常快，开发修改一定量的bug，提交一个新的版本。测试人员往往能在很快的时间内把测试结果反馈出来，一般是在1天之内就能把用例快速run一遍，这样就能减少某些后期才发现bug导致的项目delay。在国内很多项目的通病是，开发解决问题带进一个新问题，测试人员整个遍历一遍用例之后才能发现，这样来回反复就消耗了大量的时间。

但微软是如何才能实现快速反馈呢？

第一，   测试人员对程序的了解，微软的测试人员对程序内部结构都非常熟悉，修改某一个地方，可能引起什么问题，哪些用例需要重新测试，测试人员非常清楚，能快速的执行最可能出错的地方。如果某些模块不熟悉，那么他们会和开发人员在一起沟通这次修改可能引起的问题。

第二，   工具！还是工具，在微软的测试中，测试人员用各种工具帮助测试，提高测试效率是占到很大的比重。

第三，   时间意识。微软的测试人员有强烈的时间意识。

6．  测试工具

测试工具能很大程度上提高测试效率，这个作为测试人员都很清楚。当然测试工具在微软的测试中也应用非常广泛，但是请注意，微软并不是像我们国内的公司一样使用的都是LR或QTP这类的录制回放工具，反而这种工具倒是用的不多，就跟微软不屑CMM一样，可能是不想屈尊自己IT老大的身份吧。

但是微软的测试工具最大的特点是实用。他们用的测试工具都是确实能提高效率，确实能办事情的工具，都不是类似WR和QTP的很大很系统的工具，而是比较小的，很灵活，实用的小工具（譬如：Fiddler、Drip、httpwatch、IE DevToolBar、PaintNotNet、procexp etc.）。甚至有一些测试工具是测试人员在开发人员协助下根据项目需要临时开发的，不过大多数工具都是微软内部已经共享出来的，在微软内部各种各样的小工具特别多。

总体给我的感觉是，不是为了用测试工具而用，而是根据实际的需要，确实能提高效率而用到，在用的过程中确实也很大的提高了效率。

7．  测试人员的专业素质

微软测试给我印象最深刻的还有他们测试人员的专业水准，在测试过程中，测试人员在一些技术上并不逊色于开发人员，在一些bug的处理上，能提出很多合理的很有建设性的建议。

8．  微软的白盒测试

微软的白盒测试怎么执行呢？让我略微有点吃惊的是，微软的一半测试人员基本不做白盒测试，除非有些不能做黑盒的模块，另外也不是所有的产品都作白盒测试。

微软的白盒测试一般还是由专门的白盒测试人员来做，但是开发人员要对测试人员的白盒测试代码进行Review，另外微软对开发人员的代码，效率也都有一套详细的考核机制，所以开发人员对自己的代码也是非常负责任的，都进行很认真的进行测试。

9．  意识（时间，质量）

另外微软的测试还有很好的一点就是意识，时间和质量的意识都是非常强。在控制时间成本上，意识非常强，这点非常值得我们国内同仁学习，另外，风险管理的机制和意识都是非常好。在微软，项目组的每个成员都被明确告知，如果这个项目每delay一天，就会损失多少个million的美元，所以整个项目组都有比较好的时间意识。

另外，在微软，项目组人员的质量意识都是比较强的。怎么样更好服务用户，让用户体验更好，怎么样更好的改进，这种意识比较强。

10． 微软的培训

在微软内部，员工外训的机会比较少，大多都是内部互训，各人培训自己的强项，有比较好的互相分享的习惯。另外微软的内部有非常丰富的各种培训文档。以后我会上传上去和大家分享。

11 ．测试数据记录

微软的测试数据记录是非常全的，也都是系统自动的，每天都是由系统自动统计当天的bug情况，然后发送一个report到每个项目组成员的邮箱里。最后到测试总结的时候，这些测试数据将变得非常有用。

编后感：在深入了解微软的测试之前，对微软这个IT业界巨无霸的测试感觉是顶礼膜拜，高不可攀，总觉得可能很神秘，用很牛的技术或者很高深的手段。深入了解之后，发现微软的测试也是和我们做一样的事情，只不过人家做的更认真，更细，更实用，更有效率。再回过头来看时，微软的测试给我留下印象最多的是，流程，效率，意识，工具，素质！也就是这几项，成为我们国内IT企业亟需跨越的。