灿烂的阳光,苦涩的生活,认真做,你能行!

发布新日志

  • Tomcat性能调整[转载]

    2009-01-04 17:38:22

    一、引言
    性能测试与分析是软件开发过程中介于架构和调整的一个广泛并比较不容易理解的领域,更是一项
    较为复杂的活动。就像下棋游戏一样,有效的性能测试和分析只能在一个良好的计划策略和具备了
    对不可预料事件的处理能力的条件下顺利地完成。一个下棋高手赢得比赛靠的不仅仅是对游戏规则
    的认识,更是靠他的自己的能力和不断地专注于分析自己对手的实力来更加有效地利用和发挥规则
    的作用。同样一个优秀的性能测试和分析人员将要面对的是来自一个全新的应用程序和环境下带来
    的整个项目的挑战。本文中作者结合自己的使用经验和参考文档,对Tomcat性能方面的调整做一简
    要的介绍,并给出Tomcat性能的测试、分析和调整优化的一些方法。
    二、测量Web服务器的性能
    测量web服务器的性能是一项让人感到畏缩的任务,但是我们在这里将给出一些需要注意的地方并且
    指点你了解其中更多的细节性的内容。它不像一些简单的任务,如测量CPU的速率或者是测量程序占
    用CPU的比例,web服务器的性能优化中包括许调整许多变量来达到目标。许多的测量策略中都包含
    了一个看似简单的浏览实际上是在向服务器发送大量的请求,我们称之为客户端的程序,来测量响
    应时间。客户端和服务器端是在同一台机器上吗?服务器在测试的时候还运行着其它的什么程序吗
    ?客户端和服务器端的通讯是通过局域网,100baseT,10baseT还是使用调制解调器?客户端是否一
    直重复请求相同的页面,还是随机地访问不同的页面?(这些影响到了服务缓存的性能)客户端发
    送请求的有规律的还是突发的?你是在最终的配置环境下运行服务的还是在调试的配置环境下运行
    服务的?客户端请求中包含图片还是只有HTML页面?是否有请求是通过servlets和JSP的,CGI程序
    ,服务端包含(Server-Side Includes ,SSI是一个可以让你使用动态HTML文件的技术)?所有这
    些都将是我们要关心的,并且几乎我们不可能精确地把所有的问题都清楚地列出来。

    1.压力测试工具
    “工欲善其事,必先利其器”,压力测试只有借助于一些工具才可得以实施。
    大多数web压力测试工具的实现原理都是通过重复的大量的页面请求来模拟多用户对被测系统的并发
    访问,以此达到产生压力的目的。产生压力的手段都是通过录制或者是编写压力脚本,这些脚本以
    多个进程或者线程的形式在客户端运行,这样通过人为制造各种类型的压力,我们可以观察被测系
    统在各种压力状况下的表现,从而定位系统瓶颈,作为系统调优的基础。目前已经存在的性能测试
    工具林林总总,数量不下一百种,从单一的开放源码的免费小工具如 Aapache 自带的 web 性能测
    试工具 Apache Benchmark、开源的Jmeter 到大而全的商业性能测试软件如 Mercury 的
    LoadRunner 等等。任何性能测试工具都有其优缺点,我们可以根据实际情况挑选用最合适的工具。

    您可以在这里找到一些web压力测试工具http://www.softwareqatest.com/qatweb1.html#LOAD
    这里我们所使用的工具要支持web应用服务认证才可以,要支持接收发送cookies,不仅如此Tomcat
    支持多种认证方式,比如基本认证、基于表单的认证、相互认证和客户端认证,而一些工具仅仅支
    持HTTP基本认证。真实地模拟用户认证是性能测试工具的一个重要的部分,因为认证机制将对一个
    web站点的性能特征产生重要的影响。基于你在产品中使用的不同的认证方式,你需要从上面的工具
    列表中选择使用这种特性的测试工具。
    Apache Benchmark和http_load是命令行形式的工具,非常易于使用。Apache Benchmark可以模仿单
    独的URL请求并且重复地执行,可以使用不同的命令行参数来控制执行迭代的次数,并发用户数等等
    。它的一个特点是可以周期性地打印出处理过程的信息,而其它工具只能给出一个全局的报告。
    三、外部环境的调整
      在Tomcat和应用程序进行了压力测试后,如果您对应用程序的性能结果不太满意,就可以采取
    一些性能调整措施了,当然了前提是应用程序没有问题,我们这里只讲Tomcat的调整。由于Tomcat
    的运行依赖于JVM,所以在这里我们把Tomcat的调整可以分为两类来详细描述:
      外部环境调整
      调整非Tomcat组件,例如Tomcat运行的操作系统和运行Tomcat的java虚拟机。
      自身调整
      修改Tomcat自身的参数,调整Tomcat配置文件中的参数。
      下面我们将详细讲解外部环境调整的有关内容,Tomcat自身调整的内容将在第2部分中阐述。
      1.JAVA虚拟机性能优化
      Tomcat本身不能直接在计算机上运行,需要依赖于硬件基础之上的操作系统和一个java虚拟机
    。您可以选择自己的需要选择不同的操作系统和对应的JDK的版本(只要是符合Sun发布的Java规范
    的),但我们推荐您使用Sun公司发布的JDK。确保您所使用的版本是最新的,因为Sun公司和其它一
    些公司一直在为提高性能而对java虚拟机做一些升级改进。一些报告显示JDK1.4在性能上比JDK1.3
    提高了将近10%到20%。
      可以给Java虚拟机设置使用的内存,但是如果你的选择不对的话,虚拟机不会补偿。可通过命
    令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。
    参数描述
    -Xms<size>
    JVM初始化堆的大小
    -Xmx<size>
    JVM堆的最大值
      这两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的
    内存的大小。一般而言,这个参数不重要。但是有的应用程序在大负载的情况下会急剧地占用更多
    的内存,此时这个参数就是显得非常重要,如果虚拟机启动时设置使用的内存比较小而在这种情况
    下有许多对象进行初始化,虚拟机就必须重复地增加内存来满足使用。由于这种原因,我们一般把
    -Xms和-Xmx设为一样大,而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程
    序会使用持久对象,内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机
    就会提示内存溢出,并且导致应用服务崩溃。因此一般建议堆的最大值设置为可用内存的最大值的
    80%。
      Tomcat默认可以使用的内存为128MB,在较大型的应用项目中,这点内存是不够的,需要调大。
      Windows下,在文件/bin/catalina.bat,Unix下,在文件/bin/catalina.sh的前面,在文件
    里/bin/run.conf增加如下设置:
      JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'
      需要把这个两个参数值调大。例如:
      JAVA_OPTS='-Xms256m -Xmx512m'
      表示初始化内存为256MB,可以使用的最大内存为512MB。
      另外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上
    的时间和频度。收集垃圾可以接受的速度与应用有关,应该通过分析实际的垃圾收集的时间和频率
    来调整。如果堆的大小很大,那么完全垃圾收集就会很慢,但是频度会降低。如果你把堆的大小和
    内存的需要一致,完全收集就很快,但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时
    间,以在特定的时间内最大化处理客户的请求。在基准测试的时候,为保证最好的性能,要把堆的
    大小设大,保证垃圾收集不在整个基准测试的过程中出现。
      如果系统花费很多的时间收集垃圾,请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。
    如果垃圾收集成为瓶颈,那么需要指定代的大小,检查垃圾收集的详细输出,研究 垃圾收集参数对
    性能的影响。一般说来,你应该使用物理内存的 80% 作为堆大小。当增加处理器时,记得增加内存
    ,因为分配可以并行进行,而垃圾收集不是并行的。

    四、简单介绍操作系统性能优化和TOMCAT和WEB服务器的整合以及负载均衡功能
    1.操作系统性能优化
      这里说的操作系统是指运行web服务器的系统软件,当然,不同的操作系统是为不同的目的而设
    计的。比如OpenBSD是面向安全的,因此在它的内核中有许多的限制来防止不同形式的服务攻击
    (OpenBSD的一句座右铭是“默认是最安全的”)。这些限制或许更多地用来运行活跃的web服务器

      而我们常用的Linux操作系统的目标是易用使用,因此它有着更高的限制。使用BSD内核的系统
    都带有一个名为“Generic”的内核,表明所有的驱动器都静态地与之相连。这样就使系统易于使用
    ,但是如果你要创建一个自定义的内核来加强其中某些限制,那就需要排除不需要的设备。Linux内
    核中的许多驱动都是动态地加载的。但是换而言之,内存现在变得越来越便宜,所以因为加载额外
    的设备驱动就显得不是很重要的。重要的是要有更多的内存,并且在服务器上腾出更多的可用内存

      小提示:虽然现在内存已经相当的便宜,但还是尽量不要购买便宜的内存。那些有牌子的内存
    虽然是贵一点,但是从可靠性上来说,性价比会更高一些。
      如果是在Windows操作系统上使用Tomcat,那么最好选择服务器版本。因为在非服务器版本上,
    最终用户授权数或者操作系统本身所能承受的用户数、可用的网络连接数或其它方面的一些方面都
    是有限制的。并且基于安全性的考虑,必须经常给操作系统打上最新的补丁。
    2.Tomcat与其它web服务器整合使用
      虽然tomcat也可以作web服务器,但其处理静态html的速度比不上apache,且其作为web服务器的
    功能远不如apache,因此我们想把apache和tomcat集成起来,将html与jsp的功能部分进行明确分工
    ,让tomcat只处理jsp部分,其它的由apache,IIS等这些web服务器处理,由此大大节省了tomcat有
    限的工作“线程”。
    3.负载均衡
      在负载均衡的思路下,多台服务器为对称方式,每台服务器都具有同等的地位,可以单独对外
    提供服务而无须其他服务器的辅助。通过负载分担技术,将外部发送来的请求按一定规则分配到对
    称结构中的某一台服务器上,而接收到请求的服务器都独立回应客户机的请求。
      提供服务的一组服务器组成了一个应用服务器集群(cluster),并对外提供一个统一的地址。当
    一个服务请求被发至该集群时,根据一定规则选择一台服务器,并将服务转定向给该服务器承担,
    即将负载进行均衡分摊。
      通过应用负载均衡技术,使应用服务超过了一台服务器只能为有限用户提供服务的限制,可以
    利用多台服务器同时为大量用户提供服务。当某台服务器出现故障时,负载均衡服务器会自动进行
    检测并停止将服务请求分发至该服务器,而由其他工作正常的服务器继续提供服务,从而保证了服
    务的可靠性。
      负载均衡实现的方式大概有四种:第一是通过DNS,但只能实现简单的轮流分配,不能处理故障
    ,第二如果是基于MS IIS,Windows 2003 server本身就带了负载均衡服务,第三是硬件方式,通过
    交换机的功能或专门的负载均衡设备可以实现,第四种是软件方式,通过一台负载均衡服务器进行
    ,上面安装软件。使用Apache Httpd Server做负载平衡器,Tomcat集群节点使用Tomcat就可以做到
    以上第四种方式。这种方式比较灵活,成本相对也较低。另外一个很大的优点就是可以根据应用的
    情况和服务器的情况采取一些策略。

    五、对tomcat自身性能的调整,根据自己的情况自行调整;
      本节将向您详细介绍一些加速可使Tomcat实例加速运行的技巧和方法,无论是在什么操作系统
    或者何种Java虚拟机上。在有些情况下,您可能没有控制部署环境上的操作系统或者Java虚拟机。
    在这种情况下,您就需要逐行了解以下的的一些建议,然而你应该在修改后使之生效。我认为以下
    方法是Tomcat性能自身调整的最佳方式。
    1.禁用DNS查询
      当web应用程序向要记录客户端的信息时,它也会记录客户端的IP地址或者通过域名服务器查找
    机器名转换为IP地址。DNS查询需要占用网络,并且包括可能从很多很远的服务器或者不起作用的服
    务器上去获取对应的IP的过程,这样会消耗一定的时间。为了消除DNS查询对性能的影响我们可以关
    闭DNS查询,方式是修改server.xml文件中的enableLookups参数值:
    在/jboss/server/default/deploy/jbossweb-tomcat55.sar/server.xml

    Tomcat4
    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="80"
    minProcessors="5" maxProcessors="75" enableLookups="false" redirectPort="8443"
    acceptCount="100" debug="0" connectionTimeout="20000" useURIValidationHack="false"
    disableUploadTimeout="true" />
    Tomcat5
    <Connector port="80" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
    enableLookups="false" redirectPort="8443" acceptCount="100" debug="0"
    connectionTimeout="20000" disableUploadTimeout="true"/>

      除非你需要连接到站点的每个HTTP客户端的机器名,否则我们建议在生产环境上关闭DNS查询功
    能。可以通过Tomcat以外的方式来获取机器名。这样不仅节省了网络带宽、查询时间和内存,而且
    更小的流量会使日志数据也会变得更少,显而易见也节省了硬盘空间。对流量较小的站点来说禁用
    DNS查询可能没有大流量站点的效果明显,但是此举仍不失为一良策。谁又见到一个低流量的网站一
    夜之间就流量大增呢?
    2.调整线程数
      另外一个可通过应用程序的连接器(Connector)进行性能控制的的参数是创建的处理请求的线
    程数。Tomcat使用线程池加速响应速度来处理请求。在Java中线程是程序运行时的路径,是在一个
    程序中与其它控制线程无关的、能够独立运行的代码段。它们共享相同的地址空间。多线程帮助程
    序员写出CPU最大利用率的高效程序,使空闲时间保持最低,从而接受更多的请求。
      Tomcat4中可以通过修改minProcessors和maxProcessors的值来控制线程数。这些值在安装后就
    已经设定为默认值并且是足够使用的,但是随着站点的扩容而改大这些值。minProcessors服务器启
    动时创建的处理请求的线程数应该足够处理一个小量的负载。也就是说,如果一天内每秒仅发生5次
    单击事件,并且每个请求任务处理需要1秒钟,那么预先设置线程数为5就足够了。但在你的站点访
    问量较大时就需要设置更大的线程数,指定为参数maxProcessors的值。maxProcessors的值也是有
    上限的,应防止流量不可控制(或者恶意的服务攻击),从而导致超出了虚拟机使用内存的大小。
    如果要加大并发连接数,应同时加大这两个参数。web server允许的最大连接数还受制于操作系统
    的内核参数设置,通常Windows是2000个左右,Linux是1000个左右。
      在Tomcat5对这些参数进行了调整,请看下表:
    属性名
    描述
    maxThreads
    Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。
    acceptCount
    指定当所有可以使用的处理请求的线程数都被使用时,可以放到处理队列中的请求数,超过这个数
    的请求将不予处理。
    connnectionTimeout
    网络连接超时,单位:毫秒。设置为0表示永不超时,这样设置有隐患的。通常可设置为30000毫秒

    minSpareThreads
    Tomcat初始化时创建的线程数。
    maxSpareThreads
    一旦创建的线程超过这个值,Tomcat就会关闭不再需要的socket线程。
      最好的方式是多设置几次并且进行测试,观察响应时间和内存使用情况。在不同的机器、操作
    系统或虚拟机组合的情况下可能会不同,而且并不是所有人的web站点的流量都是一样的,因此没有
    一刀切的方案来确定线程数的值。
    加速JSP编译速度
    3.加速JSP编译速度
    4. 其它
      前面我们提到过操作系统通过一些限制手段来防止恶意的服务攻击,同样Tomcat也提供了防止
    恶意攻击或禁止某些机器访问的设置。
      Tomcat提供了两个参数供你配置:RemoteHostValve 和RemoteAddrValve。
      通过配置这两个参数,可以让你过滤来自请求的主机或IP地址,并允许或拒绝哪些主机/IP。与
    之类似的,在Apache的httpd文件里有对每个目录的允许/拒绝指定。
      例如你可以把Admin Web application设置成只允许本地访问,设置如下:
    allow="127.0.0.1" deny=""/>
         如果没有给出允许主机的指定,那么与拒绝主机匹配的主机就会被拒绝,除此之外的都是允许的
    。与之类似,如果没有给出拒绝主机的指定,那么与允许主机匹配的主机就会被允许,除此之外的
    都是拒绝的。

    六. 容量计划
      容量计划是在生产环境中使用Tomcat不得不提的提高性能的另一个重要的话题。如果你没有对
    预期的网络流量下的硬件和带宽做考虑的话那么无论你如何做配置修改和测试都无济于事。
      这里先对提及的容量计划作一个简要的定义:容量计划是指评估硬件、操作系统和网络带宽,
    确定应用服务的服务范围,寻求适合需求和软件特性的软硬件的一项活动。因此这里所说的软件不
    仅包括Tomcat,也包括与Tomcat结合使用的任何第三方web服务器软件。
      如果在购买软硬件或部署系统前你对容量计划一无所知,不知道现有的软硬件环境能够支撑多
    少的访问量,甚至更糟直到你已经交付并且在生产环境上部署产品后才意识到配置有问题时再进行
    变更可能为时已晚。此时只能增加硬件投入,增加硬盘容量甚至购买更好的服务器。如果事先做了
    容量计划那么就不会搞的如此焦头烂额了。
      我们这里只介绍与Tomcat相关的内容。
      首先为了确定Tomcat使用机器的容量计划,你应该从一下列表项目种着手研究和计划:
      1. 硬件
      采用什么样的硬件体系?需要多少台计算机?使用一个大型的,还是使用多台小型机?每个计
    算机上使用几个CPU?使用多少内存?使用什么样的存储设备,I/O的处理速度有什么要求?怎样维
    护这些计算机?不同的JVM在这些硬件上运行的效果如何(比如IBM AIX系统只能在其设计的硬件系
    统上运行)?
      2. 网络带宽
      带宽的使用极限是多少?web应用程序如何处理过多的请求?
      3. 服务端操作系统
      采用哪种操作系统作为站点服务器最好?在确定的操作系统上使用哪个JVM最好?例如,JVM在
    这种系统上是否支持本地多线程,对称多处理?哪种系统可使web服务器更快、更稳定,并且更便宜
    。是否支持多CPU?

         4. Tomcat容量计划
      以下介绍针对Tomcat做容量计划的步骤:
      1) 量化负载。如果站点已经建立并运行,可以使用前面介绍的工具模仿用户访问,确定资源
    的需求量。
      2) 针对测试结果或测试过程中进行分析。需要知道那些请求造成了负载过重或者使用过多的
    资源,并与其它请求做比较,这样就确定了系统的瓶颈所在。例如:如果servlet在查询数据库的步
    骤上耗用较长的时间,那么就需要考虑使用缓冲池来降低响应时间。
      3) 确定性能最低标准。例如,你不想让用户花20秒来等待结果页面的返回,也就是说甚至在
    达到访问量的极限时,用户等待的时间也不能超过20秒种(从点击链接到看到返第一条返回数据)
    。这个时间中包含了数据库查询时间和文件访问时间。同类产品性能在不同的公司可能有不同的标
    准,一般最好采取同行中的最低标准或对这个标准做出评估。
      4) 确定如何合理使用底层资源,并逐一进行测试。底层资源包括CPU、内存、存储器、带宽、
    操作系统、JVM等等。在各种生产环境上都按顺序进行部署和测试,观察是否符合需求。在测试
    Tomcat时尽量多采用几种JVM,并且调整JVM使用内存和Tomcat线程池的大小进行测试。同时为了达
    到资源充分合理稳定地使用的效果,还需针对测试过程中出现的硬件系统瓶颈进行处理确定合理的
    资源配置。这个过程最为复杂,而且一般由于没有可参考的值所以只能靠理论推断和经验总结。
      5) 如果通过第4步的反复测试如果达到了最优的组合,就可以在相同的生产环境上部署产品了

      此外应牢记一定要文档化你的测试过程和结果,因为此后可能还会进行测试,这样就可以拿以
    前的测试结果做为参考。另外测试过程要反复多次进行,每次的条件可能都不一样,因此只有记录
    下来才能进行结果比较和最佳条件的选择。
      这样我们通过测试找到了最好的组合方式,各种资源得到了合理的配置,系统的性能得到了极
    大的提升。
    七. 附加资料
      很显然本文也很难全面而详尽地阐述性能优化过程。如果你进行更多研究的话可能会把性能调
    优做的更好,比如Java程序的性能调整、操作系统的调整、各种复杂环境与应用系统和其它所有与
    应用程序相关的东西。在这里提供一些文中提到的一些资源、文中提到的相关内容的链接以及本文
    的一些参考资料。
      1. Web性能测试资料及工具
      1) Jmeter Wiki首页,Jmeter为一个开源的100%Java开发的性能测试工具
      http://wiki.apache.org/jakarta-jmeter/
      2) Apache Benchmark使用说明
      http://httpd.apache.org/docs-2.0/programs/ab.html
      3) 一些Java相关测试工具的介绍,包含可以与Tomcat集成进行测试的工具
      http://blog.csdn.net/wyingquan/
      4) LoadRunner® 是一种预测系统行为和性能的工业标准级负载测试工具。它通过模拟数据以
    千万计用户来实施并发负载来对整个企业架构进行测试,来帮助您更快的查找和发现问题。
      http://www.mercury.com/us/products/performance-center/loadrunner/

      2. 文中介绍的相关内容的介绍
      1) Apache 2.x + Tomcat 4.x做负载均衡,描述了如何利用jk配置集群的负载均衡。
      http://raibledesigns.com/tomcat/index.html
      2) 容量计划的制定,收集了许多有关制定web站点容量计划的例子:
      http://www.capacityplanning.com/
      3) 评测Tomcat5负载平衡与集群,
      http://www.javaresearch.org/article/showarticle.jsp?column=556&thread=19777
      
          4) Apache与Tomcat的安装与整合之整合篇
      http://www.javaresearch.org/article/showarticle.jsp?column=23&thread=18139
      5) 性能测试工具之研究,介绍了性能测试工具的原理与思路
      http://www.51testing.com/emagzine/No2_2.htm
      6) Java的内存泄漏
      http://www.matrix.org.cn/resource/article/409.html
      7) Web服务器和应用程序服务器有什么区别?
      http://www.matrix.org.cn/resource/article/1429.html
      8) 详细讲解性能中数据库集群的问题
      http://www.theserverside.com/articles/article.tss?l=DB_Break

  • 什么是CGI

    2008-12-30 13:36:45

    CGI是CommonGatewayInterface 的简称。是一个用于定Web服务器与外部程序之间通信方式的标准,使得外部程序能生成HTML、图像或者其他内容,而服务器处理的方式与那些非外部程序生成的HTML、图像或其他内容的处理方式是相同的。因此,CGI程序册仅使你能生成表态内容而能生动态内容。使用CGI的原因在于它是一个定义良好并被广泛支持的标准,没有CGI就不可能实现动态的Web页面,除非使用一些服务器中提供的特殊方法(如今,也有除CGI之外的其他技术逐渐在成为标准)。

    CGI主要的功能是在WWW环境下,藉由从客户端传递一些讯息给WWWServer,再由WWWServer去启动所指定的程式码来完成特定的工作。所以更明确的说,CGI仅是在WWWServer上可执行的程式码,而她的工作就是控制讯息要求而且产生并传回所需的文件。使用CGI,你的Server可以读取并显示在客户端无法读取的格式(像是SQLDataBase)。而且可以像闸道(Gateway)一样,在伺服端和客户端之间,产生客户端所需要的讯息。基本上,在此种主从式(Client/Server)的环境之下,其IPC(InterProcess Communication)的协定是利用讯息传递及记忆体分享(环境变数)的方式来完成。CGI有其特定的写法及规格,必须遵守其原则,方可达到主从端资讯交流的目的。

  • 页面攻击检测软件

    2008-12-30 09:19:37

  • 测试工作步骤

    2008-12-25 13:50:37

    1 得到需求、功能设计、内部设计说书和其他必要的文档

    2 得到预算和进度要求

    3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )

    4 确定应用软件的高风险范围,建立优先级、确定测试所涉及的范围和限制

    5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试

    6 确定对测试环境的要求 ( 硬件、软件、通信等 )

    7 确定所需的测试用具 (testware) ,包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等

    8 确定对测试的输入数据的要求

    9 分配任务和任务负责人,以及所需的劳动力

    10 设立大致的时间表、期限、和里程碑

    11 确定输入环境的类别、边界值分析、错误类别

    12 准备测试计划文件和对计划进行必要的回顾

    13 准备白盒测试案例

    14 对测试案例进行必要的回顾 / 调查 / 计划

    15 准备测试环境和测试用具,得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南,建立测试跟踪过程,建立日志和档案、建立或得到测试输入数据

    16 得到并安装软件版本

    17 进行测试

    18 评估和报告结果

    19 跟踪问题 / 错误,并解决它

    20 如果有必要,重新进行测试

    21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
  • Java性能

    2008-12-23 23:25:03

    "本附录由Joe Sharp投稿,并获得他的同意在这儿转载。请联系SharpJoe@aol.com"

    Java语言特别强调准确性,但可靠的行为要以性能作为代价。这一特点反映在自动收集垃圾、严格的运行期检查、完整的字节码检查以及保守的运行期同步等等方面。对一个解释型的虚拟机来说,由于目前有大量平台可供挑选,所以进一步阻碍了性能的发挥。

    "先做完它,再逐步完善。幸好需要改进的地方通常不会太多。"Steve McConnell的《About performance[16]

    本附录的宗旨就是指导大家寻找和优化"需要完善的那一部分"

     

    1       基本方法

    只有正确和完整地检测了程序后,再可着手解决性能方面的问题:

    (1)   在现实环境中检测程序的性能。若符合要求,则目标达到。若不符合,则转到下一步。

    (2)   寻找最致命的性能瓶颈。这也许要求一定的技巧,但所有努力都不会白费。如简单地猜测瓶颈所在,并试图进行优化,那么可能是白花时间。

    (3)   运用本附录介绍的提速技术,然后返回步骤1

    为使努力不至白费,瓶颈的定位是至关重要的一环。Donald Knuth[9]曾改进过一个程序,那个程序把50%的时间都花在约4%的代码量上。在仅一个工作小时里,他修改了几行代码,使程序的执行速度倍增。此时,若将时间继续投入到剩余代码的修改上,那么只会得不偿失。

    Knuth在编程界有一句名言:"过早的优化是一切麻烦的根源"Premature optimization is the root of all evil)。最明智的做法是抑制过早优化的冲动,因为那样做可能遗漏多种有用的编程技术,造成代码更难理解和操控,并需更大的精力进行维护。

    2       寻找瓶颈

    为找出最影响程序性能的瓶颈,可采取下述几种方法:

     

    1)     安插自己的测试代码

    插入下述"显式"计时代码,对程序进行评测:

    long start = System.currentTimeMillis();

    // 要计时的运算代码放在这儿

    long time = System.currentTimeMillis() - start;

    利用System.out.println(),让一种不常用到的方法将累积时间打印到控制台窗口。由于一旦出错,编译器会将其忽略,所以可用一个"静态最终布尔值"Static final boolean)打开或关闭计时,使代码能放心留在最终发行的程序里,这样任何时候都可以拿来应急。尽管还可以选用更复杂的评测手段,但若仅仅为了量度一个特定任务的执行时间,这无疑是最简便的方法。

    System.currentTimeMillis()返回的时间以千分之一秒(1毫秒)为单位。然而,有些系统的时间精度低于1毫秒(如Windows PC),所以需要重复n次,再将总时间除以n,获得准确的时间。

     

    2)     JDK性能评测[2]

    JDK配套提供了一个内建的评测程序,能跟踪花在每个例程上的时间,并将评测结果写入一个文件。不幸的是,JDK评测器并不稳定。它在JDK 1.1.1中能正常工作,但在后续版本中却非常不稳定。

    为运行评测程序,请在调用Java解释器的未优化版本时加上-prof选项。例如:

    java_g -prof myClass

    或加上一个程序片(Applet):

    java_g -prof sun.applet.AppletViewer applet.html

    理解评测程序的输出信息并不容易。事实上,在JDK 1.0中,它居然将方法名称截短为30字符。所以可能无法区分出某些方法。然而,若您用的平台确实能支持-prof选项,那么可试试Vladimir Bulatov"HyperPorf"[3]或者Greg White"ProfileViewer"来解释一下结果。

     

    3)     特殊工具

    如果想随时跟上性能优化工具的潮流,最好的方法就是作一些Web站点的常客。比如由Jonathan Hardwick制作的"Tools for Optimizing Java"Java优化工具)网站:

    http://www.cs.cmu.edu/~jch/java/tools.html

     

    4)     性能评测的技巧

    ■由于评测时要用到系统时钟,所以当时不要运行其他任何进程或应用程序,以免影响测试结果。

    ■如对自己的程序进行了修改,并试图(至少在开发平台上)改善它的性能,那么在修改前后应分别测试一下代码的执行时间。

    ■尽量在完全一致的环境中进行每一次时间测试。

    ■如果可能,应设计一个不依赖任何用户输入的测试,避免用户的不同反应导致结果出现误差。

     

    3       提速方法

    现在,关键的性能瓶颈应已隔离出来。接下来,可对其应用两种类型的优化:常规手段以及依赖Java语言。

     

    1)     常规手段

    通常,一个有效的提速方法是用更现实的方式重新定义程序。例如,在《Programming Pearls》(编程拾贝)一书中[14]Bentley利用了一段小说数据描写,它可以生成速度非常快、而且非常精简的拼写检查器,从而介绍了Doug McIlroy对英语语言的表述。除此以外,与其他方法相比,更好的算法也许能带来更大的性能提升--特别是在数据集的尺寸越来越大的时候。欲了解这些常规手段的详情,请参考本附录末尾的"一般书籍"清单。

     

    2)     依赖语言的方法

    为进行客观的分析,最好明确掌握各种运算的执行时间。这样一来,得到的结果可独立于当前使用的计算机--通过除以花在本地赋值上的时间,最后得到的就是"标准时间"

     

    运算 示例 标准时间

     

    本地赋值 i=n; 1.0

    实例赋值 this.i=n; 1.2

    int增值 i++; 1.5

    byte增值 b++; 2.0

    short增值 s++; 2.0

    float增值 f++; 2.0

    double增值 d++; 2.0

    空循环 while(true) n++; 2.0

    三元表达式 (x<0) ?-x : x 2.2

    算术调用 Math.abs(x); 2.5

    数组赋值 a[0] = n; 2.7

    long增值 l++; 3.5

    方法调用 funct(); 5.9

    throwcatch异常 try{ throw e; }catch(e){} 320

    同步方法调用 synchMehod(); 570

    新建对象 new Object(); 980

    新建数组 new int[10]; 3100

     

    通过自己的系统(如我的Pentium 200 ProNetscape 3JDK 1.1.5),这些相对时间向大家揭示出:新建对象和数组会造成最沉重的开销,同步会造成比较沉重的开销,而一次不同步的方法调用会造成适度的开销。参考资源[5][6]为大家总结了测量用程序片的Web地址,可到自己的机器上运行它们。

     

    1. 常规修改

    下面是加快Java程序关键部分执行速度的一些常规操作建议(注意对比修改前后的测试结果)。

     

    ... 修改成... 理由

     

    接口 抽象类(只需一个父时) 接口的多个继承会妨碍性能的优化

    非本地或数组循环变量 本地循环变量 根据前表的耗时比较,一次实例整数赋值的时间是本地整数赋值时间的1.2倍,但数组赋值的时间是本地整数赋值的2.7

    链接列表(固定尺寸) 保存丢弃的链接项目,或将列表替换成一个循环数组(大致知道尺寸) 每新建一个对象,都相当于本地赋值980次。参考"重复利用对象"(下一节)、Van Wyk[12] p.87以及Bentley[15] p.81

    x/2(或2的任意次幂) X>>2(或2的任意次幂) 使用更快的硬件指令

     

    3)     特殊情况

    ■字串的开销:字串连接运算符+看似简单,但实际需要消耗大量系统资源。编译器可高效地连接字串,但变量字串却要求可观的处理器时间。例如,假设st是字串变量:

    System.out.println("heading" + s + "trailer" + t);

    上述语句要求新建一个StringBuffer(字串缓冲),追加自变量,然后用toString()将结果转换回一个字串。因此,无论磁盘空间还是处理器时间,都会受到严重消耗。若准备追加多个字串,则可考虑直接使用一个字串缓冲--特别是能在一个循环里重复利用它的时候。通过在每次循环里禁止新建一个字串缓冲,可节省980单位的对象创建时间(如前所述)。利用substring()以及其他字串方法,可进一步地改善性能。如果可行,字符数组的速度甚至能够更快。也要注意由于同步的关系,所以StringTokenizer会造成较大的开销。

    ■同步:在JDK解释器中,调用同步方法通常会比调用不同步方法慢10倍。经JIT编译器处理后,这一性能上的差距提升到50100倍(注意前表总结的时间显示出要慢97倍)。所以要尽可能避免使用同步方法--若不能避免,方法的同步也要比代码块的同步稍快一些。

    ■重复利用对象:要花很长的时间来新建一个对象(根据前表总结的时间,对象的新建时间是赋值时间的980倍,而新建一个小数组的时间是赋值时间的3100倍)。因此,最明智的做法是保存和更新老对象的字段,而不是创建一个新对象。例如,不要在自己的paint()方法中新建一个Font对象。相反,应将其声明成实例对象,再初始化一次。在这以后,可在paint()里需要的时候随时进行更新。参见Bentley编著的《编程拾贝》,p.81[15]

    ■异常:只有在不正常的情况下,才应放弃异常处理模块。什么才叫"不正常"呢?这通常是指程序遇到了问题,而这一般是不愿见到的,所以性能不再成为优先考虑的目标。进行优化时,将小的"try-catch"块合并到一起。由于这些块将代码分割成小的、各自独立的片断,所以会妨碍编译器进行优化。另一方面,若过份热衷于删除异常处理模块,也可能造成代码健壮程度的下降。

    散列处理:首先,Java 1.01.1的标准"散列表"Hashtable)类需要造型以及特别消耗系统资源的同步处理(570单位的赋值时间)。其次,早期的JDK库不能自动决定最佳的表格尺寸。最后,散列函数应针对实际使用项(Key)的特征设计。考虑到所有这些原因,我们可特别设计一个散列类,令其与特定的应用程序配合,从而改善常规散列表的性能。注意Java 1.2集合库的散列映射(HashMap)具有更大的灵活性,而且不会自动同步。

    方法内嵌:只有在方法属于final(最终)、private(专用)或static(静态)的情况下,Java编译器才能内嵌这个方法。而且某些情况下,还要求它绝对不可以有局部变量。若代码花大量时间调用一个不含上述任何属性的方法,那么请考虑为其编写一个"final"版本。

    I/O:应尽可能使用缓冲。否则,最终也许就是一次仅输入/输出一个字节的恶果。注意JDK 1.0I/O类采用了大量同步措施,所以若使用象readFully()这样的一个"大批量"调用,然后由自己解释数据,就可获得更佳的性能。也要注意Java 1.1"reader""writer"类已针对性能进行了优化。

    造型和实例:造型会耗去2200个单位的赋值时间。开销更大的甚至要求上溯继承(遗传)结构。其他高代价的操作会损失和恢复更低层结构的能力。

    图形:利用剪切技术,减少在repaint()中的工作量;倍增缓冲区,提高接收速度;同时利用图形压缩技术,缩短下载时间。来自JavaWorld"Java Applets"以及来自Sun"Performing Animation"是两个很好的教程。请记着使用最贴切的命令。例如,为根据一系列点画一个多边形,和drawLine()相比,drawPolygon()的速度要快得多。如必须画一条单像素粗细的直线,drawLine(x,y,x,y)的速度比fillRect(x,y,1,1)快。

    使用API类:尽量使用来自Java API的类,因为它们本身已针对机器的性能进行了优化。这是用Java难于达到的。比如在复制任意长度的一个数组时,arraryCopy()比使用循环的速度快得多。

    替换API类:有些时候,API类提供了比我们希望更多的功能,相应的执行时间也会增加。因此,可定做特别的版本,让它做更少的事情,但可更快地运行。例如,假定一个应用程序需要一个容器来保存大量数组。为加快执行速度,可将原来的Vector(矢量)替换成更快的动态对象数组。

     

    1. 其他建议

    将重复的常数计算移至关键循环之外--比如计算固定长度缓冲区的buffer.length

    static final(静态最终)常数有助于编译器优化程序。

    实现固定长度的循环。

    使用javac的优化选项:-O。它通过内嵌staticfinal以及private方法,从而优化编译过的代码。注意类的长度可能会增加(只对JDK 1.1而言--更早的版本也许不能执行字节查证)。新型的"Just-in-time"JIT)编译器会动态加速代码。

    尽可能地将计数减至0--这使用了一个特殊的JVM字节码。

     

    4       参考资源

     

    1)     性能工具

    [1] 运行于Pentium Pro 200Netscape 3.0JDK 1.1.4MicroBenchmark(参见下面的参考资源[5]

    [2] SunJava文档页--JDK Java解释器主题:

    http://java.sun.com/products/JDK/tools/win32/java.html

    [3] Vladimir BulatovHyperProf

    http://www.physics.orst.edu/~bulatov/HyperProf

    [4] Greg WhiteProfileViewer

    http://www.inetmi.com/~gwhi/ProfileViewer/ProfileViewer.html

     

    2)     Web站点

    [5] 对于Java代码的优化主题,最出色的在线参考资源是Jonathan Hardwick"Java Optimization"网站:

    http://www.cs.cmu.edu/~jch/java/optimization.html

    "Java优化工具"主页:

    http://www.cs.cmu.edu/~jch/java/tools.html

    以及"Java Microbenchmarks"(有一个45秒钟的评测过程):

    http://www.cs.cmu.edu/~jch/java/benchmarks.html

     

    3)     文章

  • 脚本下载说明

    2008-12-23 17:25:28

    浏览器对于scrīpt的下载是避免并行进行的。HTTP/1.1协议中规定浏览器和同一host之间只建立最多两个连接,也就是说允许的最大并行度为2(当然,对IE和Firefox来说,你都可以通过修改浏览器的设置来扩大这个并行度)。但对于scrīpt的下载来说,浏览器在开始下载scrīpt之后,是不会并行的下载其他element的。不会并行下载scrīpt这一点是一个事实,但浏览器为什么要采用这种策略,以及浏览器我们提到的“将scrīpt放到HTML文件中尽量靠近尾部”到底能起到多大的作用,需要注意哪些事项,我希望在这篇文章中进一步的进行讨论。

    将scrīpt放到HTML文件中尽量靠近尾部”的方法来提高用户感觉上的响应时间

     

  • Tomcat5中的部署方式

    2008-12-17 16:08:27

    Tomcat4中的部署方式:

    1 部署Web应用程序的方法:
    1.1 WAR方式
    将应用程序包含的jsp、servlet等文件包装成一个单个的、自包含的WAR文件。WAR文件是一个JAR文件,其中包含了特殊的目录和位于他的/Web-INF目录中的web.xml文件。其结构举例如下:
    hello.jsp
    META-INF/
          MANIFEST.MF
    Web-INF/
          web.xml
          classes/
                example/helloWorld.class
          lib/
                xxx.jar
    创建WAR文件的最容易的方法就是,首先在开发环境中创建相应于WAR结构的目录结构。然后,创建WAR所要做的工作就是在WAR的根目录中执行下面的命令。注意,其中排除了.java源文件,它是WAR文件中不必要的内容,并且在试图部署WAR时可能会带来问题:
    Jar ?cvf hello.war META-INF/MANIFEST.MF Web-INF/classes/example/*.class Web-INF/web.xml *.jsp
    将WAR文件拷贝到$CATALINA_HOME/webapps目录中。当Tomcat启动时,它
    就会自动对WAR文件进行解包,并且创建这个应用程序,应用程序的名字(和上下文路径Context Path)为WAR文件的名称。在这里不需要对系统或者服务器路径做任何的改动。

    注意:如果在Tomcat已经启动好以后,放置WAR文件到webapps目录,则Tomcat无法动态
    部署这个Web应用程序,需要重启Tomcat。 如果虚拟主机的liveDeploy属性为true就不用了。

    1.2扩展目录方式
    此种部署方式的优点是,当对jsp进行了修改时不必重启Tomcat,并且不必在每次修改时都要去重新建立归档文件,而且在准备好进行软件分发时也很容易地创建WAR文件。
      在server.xml文件中加入如下代码,该文件位于$CATALINA_HOME/conf目录中。
      <Context path=”/hello” docBase=”<path to root of war>” debug=”0”
            reloadable="true" crossContext="true" />
      <path to root of war>是一个按照使用的操作系统的目录惯例的绝对路径,并且不必是位于Tomcat的目录树下面。作者把这个WAR部署到Windows中,使用的是docBase=”d: lymacy”,而在Unix中,所使用的docBase=”/export/home/macy”。

    注意,Tomcat要求对Windows的路径使用单个反斜杠。

    ______________________________________________________________________________________________
    答6:
    Tomcat5中的部署方式:


    1 应用程序部署器(Deployer)
    程序员朋友不要以为这是什么全新的东西,其实以前的版本就已经有了,只不过在Tomcat4中没有提出这个概念,且它的功能被分散在各个组件中,给人的感觉是比较支离破碎的。于是乎,在Tomcat5中对其进行了包装和增强,提出了Deployer这个逻辑概念,用于集中表示应用程序部署和发布功能。Tomcat5对其的主要改进就是进行了一些优化,增强了动态部署的功能,减少了重启Tomcat的次数,增强了服务器的健壮性和可靠性。
    Deployer提供的主要功能就是静态(在tomcat启动之前)或者动态(在Tomcat运行以后)进行Web应用程序的部署和删除,在某些情况下Deployer需要和Manager管理工具联合使用。
    1.1 Context descrīptors
    这个也不是新东西了,Tomcat4中的Manager和Admin管理工具其实就是利用它来部署的。在Tomcat5中提出了Context descrīptor这个概念,且为其配置了一个专有目录,而不像Tomcat4那样大杂烩一般地放置在$appBase目录下。既然了有了名分,当然要为其单独配置一个目录才能显其身份:)
    Context descrīptor是一个只包含Context元素的xml格式的部署文件,其中Context元素与server.xml中的Context元素配置相同。对于一个给定的主机,Context descrīptor放置在$CATALINA_HOME/conf/[enginename]/[hostname]/目录下面。Tomcat5默认安装时,在$CATALINA_HOMEconfCatalinalocalhost目录中有admin.xml和manager.xml,是两个管理工具的部署描述符文件。而这两个文件在Tomcat4中是放置在$CATALINA_HOME/webapps目录下面的。呵呵。。。果然是换汤不换药啊:)

    注意事项:context descrīptor的文件名可以与Web应用程序名无关,但是Tomcat在部署这个应用程序的时候所创建的程序运行上下文(Context)的名称是与Web应用程序名称匹配的。
     
    1.2 静态部署
    静态部署是指在Tomcat运行之前就把相关的Web应用程序放置到合适的目录,在Tomcat启动的时候自动来部署这些应用程序。
    如果"deployOnStartup"属性值为true,那么在Tomcat启动时,在$appBase目录下的web应用程序将被自动部署。部署的过程如下:
    ? Context元素声明的Web应用程序将被首先部署,这包括server.xml和context descrīptor文件中的Context元素所指的应用程序;
    ? 部署扩展目录形式的Web应用程序;
    ? 部署WAR形式的Web应用程序;
    Tomcat5对于静态方式的部署的增强主要就是:
    1、对于context descrīptor方式的应用程序的部署。
    2、如果扩展目录方式的应用程序对应有一个WAR文件,且WAR是更新过的,扩展目录将被自动删除,Web应用程序将被从WAR文件中重新部署。而在Tomcat4中,即使WAR文件已更新也无法被重新部署,仍然会使用旧的扩展目录方式的Web应用程序,除非你自己手动删除目录,记得还要重启Tomcat哦。这么麻烦?(#@($)#*$),看来还是Tomcat5好啊:)

    1.3 动态部署
    动态部署是指在Tomcat已经运行以后在不重启服务器的情况下部署应用程序的方式。
    如果虚拟主机的"autoDeploy"属性值为true,则主机会在需要的时候试图去部署和更新应用程序。这是由虚拟主机在后台运行的一个负责自动加载的处理线程来完成的,它的工作流程如下:
    1、部署新放入$appBase目录的War方式的应用程序。
    2、部署新放入$appBase目录的扩展目录方式的应用程序。
    3、如果一个扩展目录方式的应用程序对应的War文件更新了,则删除此目录,从War文件中重新解开并部署。如果”unpackWARs”属性值为false,则不解开,从War文件中直接运行。(记住:不用自己删除扩展目录,也不用重启服务器)
    4、如果应用程序的/WEB-INF/web.xml文件被改变,则重新部署这个应用。
    5、如果应用程序对应的Context元素配置发生了改变,则重新部署这个应用。这包括server.xml或者上下文描述符文件中的Context元素。
    6、如果$CATALINA_HOME/conf/[enginename]/[hostname]/目录下增加了上下文描述符文件,则重新部署这个应用。
    看来Tomcat5在动态部署上花费了不少功夫,其中的亮点主要就是如果我们修改了web.xml、server.xml配置文件,增加了上下文描述符文件,动态更新了War文件时都可以实现应用程序的自动部署和更新,而不用重新启动Tomcat服务器,在Tomcat4中都是必须重新启动服务器的,这是一个非常喜人的变化。毕竟在对服务器的健壮性和可靠性要求越来越高的今天,重启服务器都是一件令我们非常头疼的一件事情。以后终于可以挺直腰杆对客户说“这回坚决不用重启服务器!”嘿嘿。。。幸福啊!

    1.4 用Client Deployer工具包部署
      这个才是Tomcat5中名副其实的创新,它是一个全新的部署器。
    client deployer是一个集验证、编译、部署功能与一体的工具包。它使用Ant来实现应用程序的自动化验证和编译,使用Manager管理工具来实现应用程序的自动化部署。
    这个工具包包含:Catalina Ant工具、Jasper编译器(用于将jsp编译为servlet)、应用程序验证工具(validator task)。默认的验证工具的实现类是org.apache.catalina.ant.ValidatorTask,它只允许以扩展目录的文件路径作为唯一的参数。
    此部署工具包使用一个事先写好的Ant脚本,包含如下一些目标(target):
    ? compile (默认):用于验证和编译Web应用程序。它可以在不启动Tomcat的情况下被单独使用。由于使用的是新的Jasper编译器的缘故,编译后的应用程序将只能在Tomcat 5.X版本上使用。需要提醒的是,不光是jsp文件被编译为servlet, 应用程序的/WEB-INF/classes目录下的Java源文件也将被同时编译为class文件。
    ? deploy:将Web应用程序部署到Tomcat服务器中。
    ? undeploy:从服务器中解除部署已经部署的某个应用程序。
    ? start:启动Web应用程序
    ? reload:重新加载Web应用程序
    ? stop:停止Web应用程序

    以下是Ant脚本中的一些重要属性:
    ? build:编译以后的文件默认放置在${build}/webappapp/web。编译目标执行完以后,生成了应用程序的War —— ${build}/webappapp/web.war.
    ? webapp:放置需要被验证和编译的Web应用程序(扩展目录方式)的文件路径。默认值为”myapp”。
    ? path:Web应用程序部署后对应的运行上下文的路径默认是”/myapp“。
    ? url:放置Manager管理工具的绝对路径,它被部署工具包用来部署和解除部署应用程序。默认情况下,部署器将试图使用
    http://localhost:8080/manager访问本机的Manager管理工具。
    ? username:可以使用Manager管理工具的超级用户的用户名。
    ? Password:超级用户的密码。

    至此,Tomcat5中神秘的部署器就讲完了,大家是不是已经对它发生了浓厚的兴趣呢?那就动手去试一下吧!尽管朝$appBase目录下扔你心爱的程序吧,Tomcat5会马上让他们欢快地跑起来。速度真的比Tomcat4快多了,一种冲浪的感觉:)
  • tomcat配置方法 共有0条回复

    2008-12-17 15:12:22

    一、tomcat 的 context元素 配置

    如果将做好的web程序再tomcat总发布,那我们必须要了解Tomcat 体系结构中的六个主要概念:Server Service Engine Host Connector Context ,其中我认为context是使用最频繁的元素我们初学者首先要了解的。

    Context表示在虚拟主机中运行的web应用程序。一个虚拟主机中能够运行多个Context,它们通过各自的Context Path进行相互区分。如果Context Path为"",那么该web应用为该虚拟主机的默认的web应用。实际上context作用和在iis中配置的虚拟目录一样,只不过微软东西做的有界面,而我们需要手工配置,但是如果将manager应用启动后我们也可以在界面下配置。

    context怎么配置呢,目前可以通过四种方式将Context加入Host:

    1、$CATALINA_HOME/conf/context.xml,其中Context元素中的信息会被所有web应用程序加载

    2、$CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default,其中Context元素中的信息会被hostname主机下的所有web应用程序加载

    3、$CATALINA_HOME/conf/[enginename]/[hostname]/目录中所有以.xml为扩展名的文件,其中Context元素中的信息会被hostname主机下的所有web应用程序加载

    4、如果通过上面的步骤没有找到,那么最后要从web应用程序的/meta-INF/context.xml目录中查找

    tomcat 与 java Web 开发技术详解》中讲到配置context元素的方法(第16页),但是这个方法目前在tomcat6中是不推荐使用的,甚至在tomcat6的使用说明中都不这么写了,所以大家不要按照书上的方法设置了。

    tomcat6 具有 Automatic Application Deployment 功能,所以一般情况下你只要设置正确 那么在浏览器中敲入:

    http://127.0.0.1:8080/examples/ 就可以看到tomcat自带的例子程序,如果你有新开发的web应用并且是按照tomcat的标准的目录结构,

    那么不需要任何配置,只要把发布的文件夹考到webapp下就可以了。打开“Automatic Application Deployment 功能”的参数为

    使用Host的标准实现,同时deployonstartup属性值为true(这是默认值)。

    自动部署功能已经够用了,后面会详细降到自动部署的细节。

    现在对上述的前三种方法做一个说明,第四种没什么可说的:

    1、第一种方法,《tomcat 与 java Web 开发技术详解》(第16页)中讲到配置context元素,可以在/conf/server.xml 中的 元素中 加入 这种方法现在已经不推荐使用了,同时这个方法演变为在$CATALINA_HOME/conf/context.xml 文件中加入context 配置

    2。第二、三种方法 区别不大,但是用的人不多,最典型的就是Netbeans6 绑定的tomcat 就是用这种方式部署应用的,如果安装了Netbeans的网友可以到C:\Documents and Settings\用户名\.netbeans\6.0\apache-tomcat-6.0.14_base\conf\Catalina\localhost 看到manager.xml 及root.xml 这些xml中的context元素的 path 参数 指定的是实际的web应用的程序所在的目录,netbeans都用的是绝对路径。

    二 、自动部署 (Automatic Application Deployment)的细节。

    如果使用Host的标准实现,同时deployonstartup属性值为true(这是默认值),那么Catalina在首次启动时会自动完成下面的工作:

    $CATALINA_HOME/conf/[engine_name]/[host_name]目录下的所有xml文件都被假定含有元素。

    appbase目录下的所有没有展开的war文件(没有展开的意思是没有和war文件名不包括.war扩展名对应的目录存在)会被自动展开,除非unpackWARs属性值为false。如果重新部署更新的war文件,在重起Tomcat之前要删除先前展开的目录(如果autoDeploy属性值为true那么只要删除先前展开的目录更新后的war文件就会自动展开)。

    对于appbase中含有/WEB-INF/web.xml文件的任何子目录都会自动产生一个Context,不管该子目录是否在conf/server.xml文件中出现过。这个新产生的Context将会根据DefaultContext的属性值进行设置,其context path为“/目录名”。

    如果目录名为ROOT,那么context path为“”。

    因此要使用上面的规则需要将xml设置文件拷贝到$CATALINA_HOME/conf/[engine_name]/[host_name]目录下或将war文件和含有web应用的目录拷贝到appbase目录下。

    自动部署(Auto Deployer)也会跟踪如下web应用程序的变化:

    更新WEB-INF/web.xml文件将会使web应用程序重新加载

    更新已展开的war文件会使web应用程序卸载(undeploy)(同时移除先前展开的目录)并重新部署(deployment)

    更新xml设置文件会使web应用程序卸载(undeploy)(不移除任何展开的目录)并重新部署(deployment)

    在使用自动部署的时候xml设置文件中的docbase要指向appbase目录之外。否则部署将很困难或应用程序会被部署两次。

    如果要显示的定义context,那么需要关闭自动部署。否则相应的context将会部署两次,这可能会有问题。

  • JAVA基础-Tomcat的配置技巧精华详解

    2008-12-17 15:10:45

    1、配置系统管理(Admin Web Application)
      
      大多数商业化的J2EE服务器都提供一个功能强大的管理界面,且大都采用易于理解的Web应用界面。Tomcat按照自己的方式,同样提供一个成熟的管理工具,并且丝毫不逊于那些商业化的竞争对手。Tomcat的Admin Web Application最初在4.1版本时出现,当时的功能包括管理context、data source、user和group等。当然也可以管理像初始化参数,user、group、role的多种数据库管理等。在后续的版本中,这些功能将得到很大的扩展,但现有的功能已经非常实用了。Admin Web Application被定义在自动部署文件:CATALINA_BASE/webapps/admin.xml 。(译者注:CATALINA_BASE即tomcat安装目录下的server目录)
      
      你必须编辑这个文件,以确定Context中的docBase参数是绝对路径。也就是说,CATALINA
      
      _BASE/webapps/admin.xml的路径是绝对路径。作为另外一种选择,你也可以删除这个自动部署文件,而在server.xml文件中建立一个Admin Web Application的context,效果是一样的。你不能管理Admin Web Application这个应用,换而言之,除了删除CATALINA_BASE/webapps/admin.xml ,你可能什么都做不了。
      
      如果你使用UserDatabaseRealm(默认),你将需要添加一个user以及一个role到CATALINA_BASE/conf/tomcat-users.xml文件中。你编辑这个文件,添加一个名叫“admin”的role 到该文件中,如下:
      
      <role name="admin"/>
      
      你同样需要有一个用户,并且这个用户的角色是“admin”。象存在的用户那样,添加一个用户(改变密码使其更加安全):
      
      <user name="admin"
      password="deep_dark_secret"
      roles="admin"/>
      
      当你完成这些步骤后,请重新启动Tomcat,访问http://localhost:8080/admin,你将看到一个登录界面。Admin Web Application采用基于容器管理的安全机制,并采用了Jakarta Struts框架。一旦你作为“admin”角色的用户登录管理界面,你将能够使用这个管理界面配置Tomcat。
      
      2、配置应用管理(Manager Web Application)
      
      Manager Web Application让你通过一个比Admin Web Application更为简单的用户界面,执行一些简单的Web应用任务。Manager Web Application被被定义在一个自动部署文件中:
      
      CATALINA_BASE/webapps/manager.xml
      
      你必须编辑这个文件,以确保context的docBase参数是绝对路径,也就是说CATALINA_HOME/server/webapps/manager的绝对路径。(译者注:CATALINA_HOME即tomcat安装目录)
      
      如果你使用的是UserDatabaseRealm,那么你需要添加一个角色和一个用户到CATALINA_BASE/conf/tomcat-users.xml文件中。接下来,编辑这个文件,添加一个名为“manager”的角色到该文件中:
      
      <role name=”manager”>
      
      你同样需要有一个角色为“manager”的用户。像已经存在的用户那样,添加一个新用户(改变密码使其更加安全):
      
      <user name="manager"
      password="deep_dark_secret"
      roles="manager"/>
      
      然后重新启动Tomcat,访问http://localhost/manager/list,将看到一个很朴素的文本型管理界面,或者访问http: //localhost/manager/html/list,将看到一个HMTL的管理界面。不管是哪种方式都说明你的Manager Web Application现在已经启动了。
      
      Manager application让你可以在没有系统管理特权的基础上,安装新的Web应用,以用于测试。如果我们有一个新的web应用位于/home/user /hello下在,并且想把它安装到/hello下,为了测试这个应用,我们可以这么做,在第一个文件框中输入“/hello”(作为访问时的 path),在第二个文本框中输入“file:/home/user/hello”(作为Config URL)。
      
       Manager application还允许你停止、重新启动、移除以及重新部署一个web应用。停止一个应用使其无法被访问,当有用户尝试访问这个被停止的应用时,将看到一个503的错误??“503 - This application is not currently available”。
      
      移除一个web应用,只是指从Tomcat的运行拷贝中删除了该应用,如果你重新启动Tomcat,被删除的应用将再次出现(也就是说,移除并不是指从硬盘上删除)。
      
      3、部署一个web应用
      
      有两个办法可以在系统中部署web服务。
      
      1. 拷贝你的WAR文件或者你的web应用文件夹(包括该web的所有内容)到$CATALINA_BASE/webapps目录下。
      
      2. 为你的web服务建立一个只包括context内容的XML片断文件,并把该文件放到$CATALINA_BASE/webapps目录下。这个web应用本身可以存储在硬盘上的任何地方。
      
      如果你有一个WAR文件,你若想部署它,则只需要把该文件简单的拷贝到CATALINA_BASE/webapps目录下即可,文件必须以“.war” 作为扩展名。一旦Tomcat监听到这个文件,它将(缺省的)解开该文件包作为一个子目录,并以WAR文件的文件名作为子目录的名字。
      
      接下来,Tomcat将在内存中建立一个context,就好象你在server.xml文件里建立一样。当然,其他必需的内容,将从server.xml中的DefaultContext获得。
      
      部署web应用的另一种方式是写一个Context XML片断文件,然后把该文件拷贝到CATALINA_BASE/webapps目录下。一个Context片断并非一个完整的XML文件,而只是一个context元素,以及对该应用的相应描述。
      
      这种片断文件就像是从server.xml中切取出来的context元素一样,所以这种片断被命名为“context片断”。
      
      举个例子,如果我们想部署一个名叫MyWebApp.war的应用,该应用使用realm作为访问控制方式,我们可以使用下面这个片断:
      
      <!--
      Context fragment for deploying MyWebApp.war
      -->
      <Context path="/demo"
      docBase="webapps/MyWebApp.war"
      debug="0" privileged="true">
      <Realm className=
      "org.apache.catalina.realm.UserDatabaseRealm”

    resourceName="UserDatabase"/>
      </Context>
      
      把该片断命名为“MyWebApp.xml”,然后拷贝到CATALINA_BASE/webapps目录下。
      
      这种context片断提供了一种便利的方法来部署web应用,你不需要编辑server.xml,除非你想改变缺省的部署特性,安装一个新的web应用时不需要重启动Tomcat。
      
      4、配置虚拟主机(Virtual Hosts)
      
      关于server.xml中“Host”这个元素,只有在你设置虚拟主机的才需要修改。虚拟主机是一种在一个web服务器上服务多个域名的机制,对每个域名而言,都好象独享了整个主机。实际上,大多数的小型商务网站都是采用虚拟主机实现的,这主要是因为虚拟主机能直接连接到Internet并提供相应的带宽,以保障合理的访问响应速度,另外虚拟主机还能提供一个稳定的固定IP。
      
      基于名字的虚拟主机可以被建立在任何web服务器上,建立的方法就是通过在域名服务器(DNS)上建立IP地址的别名,并且告诉web服务器把去往不同域名的请求分发到相应的网页目录。因为这篇文章主要是讲Tomcat,我们不准备介绍在各种操作系统上设置DNS的方法,如果你在这方面需要帮助,请参考《DNS and Bind》一书,作者是Paul Albitz and Cricket Liu (O'Reilly)。为了示范方便,我将使用一个静态的主机文件,因为这是测试别名最简单的方法。
      
      在Tomcat中使用虚拟主机,你需要设置DNS或主机数据。为了测试,为本地IP设置一个IP别名就足够了,接下来,你需要在server.xml中添加几行内容,如下:
      
      <Server port="8005"
      shutdown="SHUTDOWN" debug="0">
      <Service name="Tomcat-Standalone">
      <Connector className=
      "org.apache.coyote.tomcat4.CoyoteConnector"
      port="8080"
      minProcessors="5" maxProcessors="75"
      enableLookups="true"
      redirectPort="8443"/>
      <Connector className=
      "org.apache.coyote.tomcat4.CoyoteConnector"
      port="8443" minProcessors="5"
      maxProcessors="75"
      acceptCount="10" debug="0"
      scheme="https" secure="true"/>
      <Factory className="org.apache.coyote.
      tomcat4.CoyoteServerSocketFactory"
      clientAuth="false" protocol="TLS" />
      </Connector>
      <Engine name="Standalone"
      defaultHost="localhost" debug="0">
      <!-- This Host is the default Host -->
      <Host name="localhost"
      debug="0" appBase="webapps"
      unpackWARs="true" autoDeploy="true">
      <Context path="" docBase="ROOT" debug="0"/>
      <Context path="/orders"
      docBase="/home/ian/orders" debug="0"
      reloadable="true" crossContext="true">
      </Context>
      </Host>
      
      <!-- This Host is the first
      "Virtual Host": http://www.example.com/ -->
      <Host name="www.example.com"
      appBase="/home/example/webapp">
      <Context path="" docBase="."/>
      </Host>
      
      </Engine>
      </Service>
      </Server>
      
      Tomcat的server.xml文件,在初始状态下,只包括一个虚拟主机,但是它容易被扩充到支持多个虚拟主机。在前面的例子中展示的是一个简单的server.xml版本,其中粗体部分就是用于添加一个虚拟主机。每一个Host元素必须包括一个或多个context元素,所包含的context元素中必须有一个是默认的context,这个默认的context的显示路径应该为空(例如,path=””)。
      
      5、配置基础验证(Basic Authentication)
      
      容器管理验证方法控制着当用户访问受保护的web应用资源时,如何进行用户的身份鉴别。当一个web应用使用了Basic Authentication(BASIC参数在web.xml文件中auto-method元素中设置),而有用户访问受保护的web应用时,Tomcat将通过HTTP Basic Authentication方式,弹出一个对话框,要求用户输入用户名和密码。在这种验证方法中,所有密码将被以64位的编码方式在网络上传输。
      
      注意:使用Basic Authentication通过被认为是不安全的,因为它没有强健的加密方法,除非在客户端和服务器端都使用HTTPS或者其他密码加密码方式(比如,在一个虚拟私人网络中)。若没有额外的加密方法,网络管理员将能够截获(或滥用)用户的密码。
      
      但是,如果你是刚开始使用 Tomcat,或者你想在你的web应用中测试一下基于容器的安全管理,Basic Authentication还是非常易于设置和使用的。只需要添加<security-constraint>和<login-config>两个元素到你的web应用的web.xml文件中,并且在CATALINA_BASE/conf/tomcat-users.xml文件中添加适当的<role>和<user>即可,然后重新启动Tomcat。
      
      下面例子中的web.xml摘自一个俱乐部会员网站系统,该系统中只有member目录被保护起来,并使用Basic Authentication进行身份验证。请注意,这种方式将有效的代替Apache web服务器中的.htaccess文件。
      
      <!--
      Define the
      Members-only area,
      by defining
      a "Security Constraint"
      on this Application, and
      mapping it to the
      subdirectory (URL) that we want

    to restrict.
      -->
      <security-constraint>
      <web-resource-collection>
      <web-resource-name>
      Entire Application
      </web-resource-name>
      <url-pattern>/members/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
      <role-name>member</role-name>
      </auth-constraint>
      </security-constraint>
      <!-- Define the Login
      Configuration for
      this Application -->
      <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>My Club
      Members-only Area</realm-name>
      </login-config>
      
      6、配置单点登录(Single Sign-On)
      
      一旦你设置了realm和验证的方法,你就需要进行实际的用户登录处理。一般说来,对用户而言登录系统是一件很麻烦的事情,你必须尽量减少用户登录验证的次数。作为缺省的情况,当用户第一次请求受保护的资源时,每一个web应用都会要求用户登录。
      
      如果你运行了多个web应用,并且每个应用都需要进行单独的用户验证,那这看起来就有点像你在与你的用户搏斗。用户们不知道怎样才能把多个分离的应用整合成一个单独的系统,所有他们也就不知道他们需要访问多少个不同的应用,只是很迷惑,为什么总要不停的登录。
      
      Tomcat 4的“single sign-on”特性允许用户在访问同一虚拟主机下所有web应用时,只需登录一次。为了使用这个功能,你只需要在Host上添加一个SingleSignOn Valve元素即可,如下所示:
      
      <Valve className=
      "org.apache.catalina.
      authenticator.SingleSignOn"
      debug="0"/>
      
      在Tomcat初始安装后,server.xml的注释里面包括SingleSignOn Valve配置的例子,你只需要去掉注释,即可使用。那么,任何用户只要登录过一个应用,则对于同一虚拟主机下的所有应用同样有效。使用single sign-on valve有一些重要的限制:
      
      1> value必须被配置和嵌套在相同的Host元素里,并且所有需要进行单点验证的web应用(必须通过context元素定义)都位于该Host下。
      
      2> 包括共享用户信息的realm必须被设置在同一级Host中或者嵌套之外。
      
      3> 不能被context中的realm覆盖。
      
      4> 使用单点登录的web应用最好使用一个Tomcat的内置的验证方式(被定义在web.xml中的<auth-method>中),这比自定义的验证方式强,Tomcat内置的的验证方式包括basic、digest、form和client-cert。
      
      5> 如果你使用单点登录,还希望集成一个第三方的web应用到你的网站中来,并且这个新的web应用使用它自己的验证方式,而不使用容器管理安全,那你基本上就没招了。你的用户每次登录原来所有应用时需要登录一次,并且在请求新的第三方应用时还得再登录一次。
      
      当然,如果你拥有这个第三方web应用的源码,而你又是一个程序员,你可以修改它,但那恐怕也不容易做。
      
      6> 单点登录需要使用cookies。
      
      7、配置用户定制目录(Customized User Directores)
      
      一些站点允许个别用户在服务器上发布网页。例如,一所大学的学院可能想给每一位学生一个公共区域,或者是一个ISP希望给一些web空间给他的客户,但这又不是虚拟主机。在这种情况下,一个典型的方法就是在用户名前面加一个特殊字符(~),作为每位用户的网站,比如:
      
      http://www.cs.myuniversity.edu/~username
      http://members.mybigisp.com/~username
      
      Tomcat提供两种方法在主机上映射这些个人网站,主要使用一对特殊的Listener元素。Listener的className属性应该是 org.apache.catalina.startup.UserConfig,userClass属性应该是几个映射类之一。
      
      如果你的系统是Unix,它将有一个标准的/etc/passwd文件,该文件中的帐号能够被运行中的Tomcat很容易的读取,该文件指定了用户的主目录,使用PasswdUserDatabase 映射类。
      
      <Listener className=
      "org.apache.catalina.startup.UserConfig"
      directoryName="public_html"
      userClass="org.apache.catalina.
      startup.PasswdUserDatabase"/>
      
      web文件需要放置在像/home/users/ian/public_html或者/users/jbrittain/public_html一样的目录下面。当然你也可以改变public_html 到其他任何子目录下。
      
      实际上,这个用户目录根本不一定需要位于用户主目录下里面。如果你没有一个密码文件,但你又想把一个用户名映射到公共的像/home一样目录的子目录里面,则可以使用HomesUserDatabase类。
      
      <Listener className=
      "org.apache.catalina.startup.UserConfig"
      directoryName="public_html"
      homeBase="/home"
      userClass="org.apache.catalina.
      startup.HomesUserDatabase"/>
      
      这样一来,web文件就可以位于像/home/ian/public_html或者/home/jasonb/public_html一样的目录下。这种形式对Windows而言更加有利,你可以使用一个像c:home这样的目录。
      
      这些Listener元素,如果出现,则必须在Host元素里面,而不能在context元素里面,因为它们都用应用于Host本身。
      
      8、在Tomcat中使用CGI脚本
      
      Tomcat主要是作为Servlet/JSP容器,但它也有许多传统web服务器的性能。支持通用网关接口(Common Gateway Interface,即CGI)就是其中之一,CGI提供一组方法在响应浏览器请求时运行一些扩展程序。
      
      CGI之所以被称为通用,是因为它能在大多数程序或脚本中被调用,包括:Perl,Python,awk,Unix shell scrīpting等,甚至包括Java。

    当然,你大概不会把一个Java应用程序当作CGI来运行,毕竟这样太过原始。一般而言,开发Servlet总要比CGI具有更好的效率,因为当用户点击一个链接或一个按钮时,你不需要从操作系统层开始进行处理。
      
      Tomcat包括一个可选的CGI Servlet,允许你运行遗留下来的CGI脚本。
      
      为了使Tomcat能够运行CGI,你必须做如下几件事:
      
      1. 把servlets-cgi.renametojar (在CATALINA_HOME/server/lib/目录下)改名为servlets-cgi.jar。处理CGI的servlet应该位于Tomcat的CLASSPATH下。
      
      2. 在Tomcat的CATALINA_BASE/conf/web.xml 文件中,把关于<servlet-name> CGI的那段的注释去掉(默认情况下,该段位于第241行)。
      
      3. 同样,在Tomcat的CATALINA_BASE/conf/web.xml文件中,把关于对CGI进行映射的那段的注释去掉(默认情况下,该段位于第299行)。注意,这段内容指定了HTML链接到CGI脚本的访问方式。
      
      4. 你可以把CGI脚本放置在WEB-INF/cgi 目录下(注意,WEB-INF是一个安全的地方,你可以把一些不想被用户看见或基于安全考虑不想暴露的文件放在此处),或者你也可以把CGI脚本放置在 context下的其他目录下,并为CGI Servlet调整cgiPathPrefix初始化参数。这就指定的CGI Servlet的实际位置,且不能与上一步指定的URL重名。
      
      5. 重新启动Tomcat,你的CGI就可以运行了。
      
      在Tomcat中,CGI程序缺省放置在WEB-INF/cgi目录下,正如前面所提示的那样,WEB-INF目录受保护的,通过客户端的浏览器无法窥探到其中内容,所以对于放置含有密码或其他敏感信息的CGI脚本而言,这是一个非常好的地方。
      
      为了兼容其他服务器,尽管你也可以把CGI脚本保存在传统的/cgi-bin目录,但要知道,在这些目录中的文件有可能被网上好奇的冲浪者看到。另外,在Unix中,请确定运行Tomcat的用户有执行CGI脚本的权限。
      
      9、改变Tomcat中的JSP编译器(JSP Compiler)
      
      在Tomcat 4.1(或更高版本,大概),JSP的编译由包含在Tomcat里面的Ant程序控制器直接执行。这听起来有一点点奇怪,但这正是Ant有意为之的一部分,有一个API文档指导开发者在没有启动一个新的JVM的情况下,使用Ant。
      
      这是使用Ant进行Java开发的一大优势。另外,这也意味着你现在能够在Ant中使用任何javac支持的编译方式,这里有一个关于Apache Ant使用手册的javac page列表。
      
      使用起来是容易的,因为你只需要在<init-param> 元素中定义一个名字叫“compiler”,并且在value中有一个支持编译的编译器名字,示例如下:
      
      <servlet>
      <servlet-name>jsp</servlet-name>
      <servlet-class>
      org.apache.jasper.servlet.JspServlet
      </servlet-class>
      <init-param>
      <param-name>logVerbosityLevel
      </param-name>
      <param-value>WARNING</param-value>
      </init-param>
      <init-param>
      <param-name>compiler</param-name>
      <param-value>jikes</param-value>
      </init-param>
      <load-on-startup>3</load-on-startup>
      </servlet>
      
      当然,给出的编译器必须已经安装在你的系统中,并且CLASSPATH可能需要设置,那处决于你选择的是何种编译器。
      
      10、限制特定主机访问(Restricting Access to Specific Hosts)
      
      有时,你可能想限制对Tomcat web应用的访问,比如,你希望只有你指定的主机或IP地址可以访问你的应用。这样一来,就只有那些指定的的客户端可以访问服务的内容了。为了实现这种效果,Tomcat提供了两个参数供你配置:RemoteHostValve 和RemoteAddrValve。
      
      通过配置这两个参数,可以让你过滤来自请求的主机或IP地址,并允许或拒绝哪些主机/IP。与之类似的,在Apache的httpd文件里有对每个目录的允许/拒绝指定。例如你可以把Admin Web application设置成只允许本地访问,设置如下:
      
      <Context path=
      "/path/to/secret_files" ...>
      <Valve className="org.apache.
      catalina.valves.RemoteAddrValve"
      allow="127.0.0.1" deny=""/>
      </Context>
      
      如果没有给出允许主机的指定,那么与拒绝主机匹配的主机就会被拒绝,除此之外的都是允许的。与之类似,如果没有给出拒绝主机的指定,那么与允许主机匹配的主机就会被允许,除此之外的都是拒绝的。

  • svn记录版本

    2008-12-17 09:20:52

    1 右键-repo-brower

    2trunk

    3tag-create folder 命名一个版本名称

    4再将trunk/deployment copy to  3的文件夹中/deployment   /source

    5出版本时候加上trunk下的版本号,这是公司的要求

  • 连接数据库报错

    2008-12-16 16:26:00

    连接数据库报错
    java.sql.SQLException:   The   Network   Adapter   could   not   establish   the   connection

    用sqlplus   连接数据库可以连上
    java连接时报错。
    用ip地址作连接,防火墙以关/

    管理工具--> 服务   中启动OracleOraDb10g_home1TNSListener服务后再刷新看该服务是否还显示为“已启动”。

    9i2我把C:\oracle\ora92\network\admin目录下的listener.ora和tnsnames.ora文件中的HOST全部改为:HOST   =   127.0.0.1   就好了,我以前遇见过这种情况。


    #   LISTENER.ORA   Network   Configuration   File:   C:\oracle\ora92\network\admin\listener.ora
    #   Generated   by   Oracle   configuration   tools.

    LISTENER   =
        (DEscrīptION_LIST   =
            (DEscrīptION   =
                (ADDRESS_LIST   =
                    (ADDRESS   =   (PROTOCOL   =   IPC)(KEY   =   EXTPROC0))
                )
                (ADDRESS_LIST   =
                    (ADDRESS   =   (PROTOCOL   =   TCP)(HOST   =   127.0.0.1)(PORT   =   1521))
                )
            )
        )

    SID_LIST_LISTENER   =
        (SID_LIST   =
            (SID_DESC   =
                (SID_NAME   =   PLSExtProc)
                (ORACLE_HOME   =   C:\oracle\ora92)
                (PROGRAM   =   extproc)
            )
            (SID_DESC   =
                (GLOBAL_DBNAME   =   tfpc)
                (ORACLE_HOME   =   C:\oracle\ora92)
                (SID_NAME   =   tfpc)
            )
        )

    **********************

    #   TNSNAMES.ORA   Network   Configuration   File:   C:\oracle\ora92\network\admin\tnsnames.ora
    #   Generated   by   Oracle   configuration   tools.

    TFPC   =
        (DEscrīptION   =
            (ADDRESS_LIST   =
                (ADDRESS   =   (PROTOCOL   =   TCP)(HOST   =   127.0.0.1)(PORT   =   1521))
            )
            (CONNECT_DATA   =
                (SERVER   =   DEDICATED)
                (SERVICE_NAME   =   tfpc)
            )
        )

    INST1_HTTP   =
        (DEscrīptION   =
            (ADDRESS_LIST   =
                (ADDRESS   =   (PROTOCOL   =   TCP)(HOST   =   127.0.0.1)(PORT   =   1521))
            )
            (CONNECT_DATA   =
                (SERVER   =   SHARED)
                (SERVICE_NAME   =   MODOSE)
                (PRESENTATION   =   http://HRService)
            )
        )

    EXTPROC_CONNECTION_DATA   =
        (DEscrīptION   =
            (ADDRESS_LIST   =
                (ADDRESS   =   (PROTOCOL   =   IPC)(KEY   =   EXTPROC0))
            )
            (CONNECT_DATA   =
                (SID   =   PLSExtProc)
                (PRESENTATION   =   RO)
            )
        )

    telnet   localhost   1521
    然后什么都不显示

    lz这样:开始--> 运行--> cmd--> netstat   -na
    找找里面有没有如下一行:
    TCP         127.0.0.1:1521                   0.0.0.0:0                             LISTENING

    嗯,不错,换成ip地址就没错了!
    真不明白是自己的ip地址和localhost或127.0.0.1有什么区别?

  • HTTP常见错误 400/401/403/404/500及更多

    2008-12-11 14:54:35

    HTTP 错误 400
    400 请求出错
    由于语法格式有误,服务器无法理解此请求。不作修改,客户程序就无法重复此请求。

    HTTP 错误 401
    401.1 未授权:登录失败
    此错误表明传输给服务器的证书与登录服务器所需的证书不匹配。
    请与 Web 服务器的管理员联系,以确认您是否具有访问所请求资源的权限。
    401.2 未授权:服务器的配置导致登录失败
    此错误表明传输给服务器的证书与登录服务器所需的证书不匹配。此错误通常由未发送正确的 WWW 验证表头字段所致。
    请与 Web 服务器的管理员联系,以确认您是否具有访问所请求资源的权限。
    401.3 未授权:由于资源中的 ACL 而未授权
    此错误表明客户所传输的证书没有对服务器中特定资源的访问权限。此资源可能是客户机中的地址行所列出的网页或文件,也可能是处理客户机中的地址行所列出的文件所需服务器上的其他文件。
    请记录试图访问的完整地址,并与 Web 服务器的管理员联系以确认您是否具有访问所请求资源的权限。
    401.4 未授权:授权服务被筛选程序拒绝
    此错误表明 Web 服务器已经安装了筛选程序,用以验证连接到服务器的用户。此筛选程序拒绝连接到此服务器的真品证书的访问。
    请记录试图访问的完整地址,并与 Web 服务器的管理员联系以确认您是否具有访问所请求资源的权限。
    401.5 未授权:ISAPI/CGI 应用程序的授权失败
    此错误表明试图使用的 Web服务器中的地址已经安装了 ISAPI 或 CGI程序,在继续之前用以验证用户的证书。此程序拒绝用来连接到服务器的真品证书的访问。
    请记录试图访问的完整地址,并与 Web服务器的管理员联系以确认您是否具有访问所请求资源的权限

    HTTP 错误 403
    403.1 禁止:禁止执行访问
    如果从并不允许执行程序的目录中执行 CGI、ISAPI或其他执行程序就可能引起此错误。
    如果问题依然存在,请与 Web 服务器的管理员联系。
    403.2 禁止:禁止读取访问
    如果没有可用的默认网页或未启用此目录的目录浏览,或者试图显示驻留在只标记为执行或脚本权限的目录中的HTML 页时就会导致此错误。
    如果问题依然存在,请与 Web 服务器的管理员联系。
    403.3 禁止:禁止写访问
    如果试图上载或修改不允许写访问的目录中的文件,就会导致此问题。
    如果问题依然存在,请与 Web服务器的管理员联系。
    403.4 禁止:需要 SSL
    此错误表明试图访问的网页受安全套接字层(SSL)的保护。要查看,必须在试图访问的地址前输入https:// 以启用 SSL。
    如果问题依然存在,请与 Web服务器的管理员联系。
    403.5 禁止:需要 SSL 128
    此错误消息表明您试图访问的资源受 128位的安全套接字层(SSL)保护。要查看此资源,需要有支持此SSL 层的浏览器。
    请确认浏览器是否支持 128 位 SSL安全性。如果支持,就与 Web服务器的管理员联系,并报告问题。
    403.6 禁止:拒绝 IP 地址
    如果服务器含有不允许访问此站点的 IP地址列表,并且您正使用的 IP地址在此列表中,就会导致此问题。
    如果问题依然存在,请与 Web服务器的管理员联系。
    403.7 禁止:需要用户证书
    当试图访问的资源要求浏览器具有服务器可识别的用户安全套接字层(SSL)证书时就会导致此问题。可用来验证您是否为此资源的合法用户。
    请与 Web服务器的管理员联系以获取有效的用户证书。
    403.8 禁止:禁止站点访问
    如果 Web服务器不为请求提供服务,或您没有连接到此站点的权限时,就会导致此问题。
    请与 Web 服务器的管理员联系。
    403.9 禁止访问:所连接的用户太多
    如果 Web太忙并且由于流量过大而无法处理您的请求时就会导致此问题。请稍后再次连接。
    如果问题依然存在,请与 Web 服务器的管理员联系。
    403.10 禁止访问:配置无效
    此时 Web 服务器的配置存在问题。
    如果问题依然存在,请与 Web服务器的管理员联系。
    403.11 禁止访问:密码已更改
    在身份验证的过程中如果用户输入错误的密码,就会导致此错误。请刷新网页并重试。
    如果问题依然存在,请与 Web服务器的管理员联系。
    403.12 禁止访问:映射程序拒绝访问
    拒绝用户证书试图访问此 Web 站点。
    请与站点管理员联系以建立用户证书权限。如果必要,也可以更改用户证书并重试。

    HTTP 错误 404
    404 找不到
    Web 服务器找不到您所请求的文件或脚本。请检查URL 以确保路径正确。
    如果问题依然存在,请与服务器的管理员联系。

    HTTP 错误 405
    405 不允许此方法
    对于请求所标识的资源,不允许使用请求行中所指定的方法。请确保为所请求的资源设置了正确的 MIME 类型。
    如果问题依然存在,请与服务器的管理员联系。

    HTTP 错误 406
    406 不可接受
    根据此请求中所发送的“接受”标题,此请求所标识的资源只能生成内容特征为“不可接受”的响应实体。
    如果问题依然存在,请与服务器的管理员联系。

    HTTP 错误 407
    407 需要代理身份验证
    在可为此请求提供服务之前,您必须验证此代理服务器。请登录到代理服务器,然后重试。
    如果问题依然存在,请与 Web 服务器的管理员联系。

    HTTP 错误 412
    412 前提条件失败
    在服务器上测试前提条件时,部分请求标题字段中所给定的前提条件估计为FALSE。客户机将前提条件放置在当前资源 metainformation(标题字段数据)中,以防止所请求的方法被误用到其他资源。
    如果问题依然存在,请与 Web 服务器的管理员联系。

    HTTP 错误 414
    414 Request-URI 太长
    Request-URL太长,服务器拒绝服务此请求。仅在下列条件下才有可能发生此条件:
    客户机错误地将 POST 请求转换为具有较长的查询信息的 GET 请求。
    客户机遇到了重定向问题(例如,指向自身的后缀的重定向前缀)。
    服务器正遭受试图利用某些服务器(将固定长度的缓冲区用于读取或执行 Request-URI)中的安全性漏洞的客户干扰。
    如果问题依然存在,请与 Web 服务器的管理员联系。

    HTTP 错误 500
    500 服务器的内部错误
    Web 服务器不能执行此请求。请稍后重试此请求。
    如果问题依然存在,请与 Web服务器的管理员联系。

    HTTP 错误 501
    501 未实现
    Web 服务器不支持实现此请求所需的功能。请检查URL 中的错误,如果问题依然存在,请与 Web服务器的管理员联系。

    HTTP 错误 502
    502 网关出错
    当用作网关或代理时,服务器将从试图实现此请求时所访问的upstream 服务器中接收无效的响应。
    如果问题依然存在,请与 Web服务器的管理员联系。

    转载:http://www.xiazaichina.com/bbs/viewthread.php?tid=1502

  • TD发送邮件一定要用UTF-8的码码格式打开

    2008-11-20 23:37:16

    客户端由到TD发送邮件一定要用UTF-8的码码格式打开,否则中文显示为乱码,原因是因为TD发送到邮件服务器是使用的UTF-16的字符集方式(通过抓包工具发现的),所以只需要修改TD服务器的
    c:\Program Files\Common Files\Mercury Interactive\DomsInfo\StyleSheets
    目录下的BUG_HTML.xsl文件(假如你设置的邮件发送为html而不是text的话).文件即可,将文件中的
    <xsl:attribute name="CONTENT">        <xsl:value-of select="//@td_lang"/></xsl:attribute>
    修改为
    <xsl:attribute name="CONTENT">text/html;CHARSET=UTF-8</xsl:attribute>
    即可,这样以后客户端在收邮件时打开的为UTF-8格式的文件,中文就不会是乱码了。

  • windows 2003“超出最大允许连接数"解决方法

    2008-11-18 16:11:53

    通常情况下,企业中有多个管理员,他们都有权限可以登录到终端服务器。默认情况下,administrator的远程桌面连接数2个。如果此时正好有两个管理员远程桌面连接到终端服务器,那么第三个管理员就不能登陆,会提示“终端服务器超出了最大允许连接数”,无法进行登录。(图4)

     

     


        
        另外,某些管理员远程登录结束后不是按照常规做法从终端服务器中注销用户,而是直接端口连接。这样的话,虽然远程用户已经断开了与终端服务器的远程桌面连接,但是session(会话)还停留在服务器端,也会有上面的提示造成无法登录。

      对于这一问题就笔者所知有四种解决办法:

      (1).本地登录(控制台登录)到终端服务器,远程登录的用户会自动被注销。如果还有用户没有注销,可以在打开“任务管理器”,点击“用户”标签然后选择远程登的用户点击右键选择“注销”即可。(图5)

     

        (2).如果终端服务器开启了telnet服务,我们可以telnet到终端服务器,然后通过命令注销(踢出)用户。首先输入命令“query user”查看当前的登录,然后选择相应的用户通过命令logoff ID来注销该用户。其中ID是系统分配给用户的标识,它是唯一的。比如我们输入logoff 2,就注销了ID为2的用户的远程登录,那么其他用户就可以登录了。(图6)

     

       


        
        (3).限制已经断开连接的session存在的时间,当超过时间后会自动进行注销,其原理是修改终端服务器配置来实现的。操作步骤是:

      第一步:点击“开始”,依次定位到“控制面板→管理工具→终端服务配置”,在“终端服务配置”

      窗口,点击左侧的“连接”然后双击窗格右侧的“RDP-Tcp”打开其属性设置对话框。(图7)

     

     

        第二步:点击“会话”标签,勾选“替代用户设置”激活下面的选项,然后在“结束已断开的会话”后面的下拉列表中选择一个时间,比如我们选择30分钟。这样当断开连接30分钟内没有再次连接的话,系统就会技术这个session(会话)。(图8)

     

       


        
        第三步:点击“网卡”标签,修改“最多连接数”,默认是2,大家可以根据自己的需要进行修改。不过,数字不宜过大,否则会占用终端服务器的系统资源。

      (4).上面的三个方法可以解决问题,但笔者认为最彻底的解决方案是增加终端服务器的连接数,我们通过组策略来实现,操作步骤是:

      第一步:点击“开始→运行”,输入gpedit.msc打开组策略编辑器,依次展开“计算机配置→管理模板→Windows 组件→终端服务”,双击右边的“限制连接数量”,点选“已启用”,在“TS 允许的最大连接数”后面根据自己的需要输入一个连接数。

      第二步:点击左侧的“会话”,然后双击右侧的“为断开的会话设置时间限制”,点选“已启用”,在“结束断开连接的会话”后的下拉列表中选择一个时间,比如我们选择“30分钟”。(图9)

     

       

  • 解决cisvc.exe进程占用大量内存空间

    2008-11-13 13:51:42

    cisvc.exe
    cisvc - cisvc.exe - 进程信息
    进程文件: cisvc 或者 cisvc.exe
    进程名称: Microsoft Index Service Helper
    描述:
    cisvc.exe是微软Windows操作系统自带的程序。它用于监测CIDAEMON.exe内存使用状态,防止可用内存过低问题,如果cidaemon.exe内存使用超过了40M,则自动重新启动该进程。这是一个系统进程,不要进行删除。

    解决cisvc.exe进程占用大量内存空间:

    解决方法:CIDAEMON.EXE和CISVC.EXE不是木马程序,可以用如下方法停用,停用后,就不会浪费大量内存了.在桌面上的 我的电脑 图标上右键单击,选取 ”管理”,打开 ”服务” ,右键单击 ”Indexing Service” ,选取 ”禁用”.这样就可以了

  • 屏蔽或关闭网通的域名纠错系统

    2008-11-11 14:57:42

    用网通的客户在上网过程中,某些原本可以正常打开的正规网站,实然之间在打开时总是转到网通的“域名纠错系统”,给大家的正常上网带来很多不便。打电话至网通的客服(10060),他们的技术顾问也会向你说些无法解决的废话。
    且不论网通的这种服务是好是坏(个人认为此服务纯属多余、不务正业),大家最关注的是怎样去解决这个问题。
    首先谈一下为什么会出现这种问题。我们知道在网络上访问网站,要首先通过DNS服务器把要访问的网络域名(XXXX.com)解析成XXX.XXX.XXX.XXX的IP地址后,计算机才能对这个网络域名进行访问;当然,也可以事先在本地电脑的Hosts文件中建立域名和IP的映射关系来达到访问网络域名时通过本地域名解析直达IP地址的目的。根据Windows系统规定,在进行DNS请求以前,Windows系统会先检查自己的Hosts文件中是否有这个网络域名映射关系。如果有,则调用这个IP地址映射,如果没有,再向已知的DNS服务器提出域名解析。也就是说hosts文件实际上可以看成是一个本机的DNS系统,它可以负责把域名解释成IP地址,它的优先权比DNS服务器要高,它的具体实现是TCP/IP协议中的一部分,实现了域名解析的本地化。有关Hosts的知识可以查看Hosts的百度百科http://baike.baidu.com/view/597330.htm
    根据上面所说的我们就可以明白,那些在我们访问时被强制转到网通的“域名纠错系统”的网站,就是在被访问的网络域名通过网通的DNS进行解析时,被网通强制作了“网站错误、无法访问”的处理,进而页面被转到网通的“域名纠错系统”。由此看来,要解决这一问题,就需要在DNS服务器上下手,一种是更换网通提供的DNS(网上较为流行,旦不实用),一种是访问网站时通过设置Hosts让被阻的网站绕过网通的DNS解析(被网通强制转换的网站太多时,此法显得太麻烦),还有最后一种是通过设置Hosts屏蔽网通的“域名纠错系统”网站(此法以不变应万变)。
    那么怎样实现最后一种方法的设置呢?
    首先,找到电脑上的Hosts文件,并打开。
    在Windows 98系统下该文件在Windows文件夹。在Windows 2000/XP/Vista系统中位于\%Systemroot%\System32\Drivers\Etc 文件夹中,其中,%Systemroot%指系统安装路径。例如,Windows XP 安装在C:\WINDOWS,那么Hosts文件就在C:\WINDOWS\system32\drivers\etc中。你也可以用windows自带的查找功能搜索找到hosts文件。该文件其实是一个纯文本的文件,用普通的文本编辑软件如记事本等都能打开和编辑。
    其次,在打开的Hosts文件中输入:“127.0.0.1 *.cncmax.cn”(引号内的内容),并保存。
    通过观查我们可以发现,每次页面转到“域名纠错系统”网站时,“域名纠错系统”网址都不太一样,但有一点没变,那就是都以cncmax.cn收尾,这样我们在其前面加一个通配符“*”,则可实现屏蔽所有以cncmax.cn结尾的“域名纠错系统”网址。
    通过上面的设置即可屏蔽网通的“域名纠错系统”,此法对于解决电信用户的114错误一样有效。只要把cncmax.cn换成电信的114错误网址即可。同样,由于各地网通“域名纠错系统”网址的不相同,把cncmax
  • 常用的网站功能测试方法(已更新)和GUI基本测试内容

    2008-11-06 13:27:56

    1、页面链接检查: 每一个链接是否都有对应的页面,并且页面之间切换工具,如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文,中文字符显示为乱码;HTML Link Validater只能测试以Html或者htm结尾的网页链接;Xenu无需安装,支持asp、do、jsp等结尾的网页,同时能够生成html格式的测试报告。

    2、相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确检查按钮的功能是否正确 如新建、编辑、删除、关闭、返回、保存、导入等功能是否正确。

    3、字符类型检查:在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。

    1)标点符号检查:输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。

    2)特殊字符检查:输入特殊符号,如@、#、$、%、!等,看系统处理是否正确。

    3)字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。

    4、中文字符处理:在可以输入中、英文的系统输入中文,看会否出现乱码或出错。

    检查信息的完整性 在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。

    5、信息重复:在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。

    6、检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。

    7、检查添加和修改是否一致:检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型

    8、检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错

    9、重复提交表单:一条已经成功提交的纪录,返回后再提交,看看系统是否做了处理。对于Web系统检查多次使用返回键的情况   在有返回键的地方,返回到原来页面,重复多次,看会否出错

    10、搜索检查:有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确。

    11、输入信息位置:注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。

    12、上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。下载文件能否打开或者保存,下载的文件是否有格式要求,如需要特殊工具才可以打开等。

    13、必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加“*”;对必填项提示返回后,焦点是否会自动定位到必填项。

    14、快捷键检查:是否支持常用快捷键,如Ctrl+C、 Ctrl+V、 Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。

    15、回车键检查:在输入结束后直接按回车键,看系统处理如何,会否报错。

    16、刷新键检查:在Web系统中,使用浏览器的刷新键,看系统处理如何,会否报错。   

    17、回退键检查:在Web系统中,使用浏览器的回退键,看系统处理如何,会否报错。对于需要用户验证的系统,在退出登录后,使用回退键,看系统处理如何;多次使用回退键,多次使用前进键,看系统如何处理。

    18、直接URL链接检查:在Web系统中,直接输入各功能页面的URL地址,看系统如何处理,对于需要用户验证的系统更为重要。

    19、空格检查:在输入信息项中,输入一个或连串空格,查看系统如何处理。如对于要求输入整型、符点型变量的项中,输入空格,既不是空值,又不是标准输入。

    20、输入法半角全角检查:在输入信息项中,输入半角或全角的信息,查看系统如何处理。如对于要求输入符点型数据的项中,输入全角的小数点(“。”或“.”,如4.5);输入全角的空格等。

    21、密码检查:一些系统的加密方法采用对字符Ascii码移位的方式,处理密码加密相对较为简单,且安全性较高,对于局域网系统来说,此种方式完全可以起到加密的作用,但同时,会造成一些问题,即大于128的Ascii对应的字符在解密时无法解析,尝试使用“uvwxyz”等一些码值较大的字符作为密码,同时,密码尽可能的长,如17位密码等,造成加密后的密码出现无法解析的字符。

    22、用户检查:任何一个系统,都有各类不同的用户,同样具有一个或多个管理员用户,检查各个管理员之间是否可以相互管理,编辑、删除管理员用户。同时,对于一般用户,尝试删除,并重建同名的用户,检查该用户其它信息是否重现。同样,提供注销功能的系统,此用户再次注册时,是否作为一个新的用户。

    23、系统数据检查:这是功能测试最重要的,如果系统数据计算不正确,那么功能测试肯定是通不过的。数据检查根据不同的系统,方法不同。对于业务管理平台,数据随业务过程、状态的变化保持正确,不能因为某个过程出现垃圾数据,也不能因为某个过程而丢失数据。

    24、系统可恢复性检查:以各种方式把系统搞瘫,测试系统是否可正常迅速恢复。



                                                                      GUI基本测试内容

    图形用户界面( GUI )对软件测试提出了有趣的挑战,因为 GUI 开发环境有可复用的构件,开发用户界面更加省时而且更加精确。同时, GUI 的复杂性也增加了,从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似,所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南:

    窗口:
    · 窗口是否基于相关的输入和菜单命令适当地打开?
    · 窗口能否改变大小、移动和滚动?
    · 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问?
    · 当被覆盖并重新调用后,窗口能否正确地再生?
    · 需要时能否使用所有窗口相关的功能?
    · 所有窗口相关的功能是可操作的吗?
    · 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用,并适当地显示?
    · 显示多个窗口时,窗口的名称是否被适当地表示?
    · 活动窗口是否被适当地加亮?
    · 如果使用多任务,是否所有的窗口被实时更新?
    · 多次或不正确按鼠标是否会导致无法预料的副作用?
    · 窗口的声音和颜色提示和窗口的操作顺序是否符合需求?
    · 窗口是否正确地被关闭?

    下拉式菜单和鼠标操作:
    · 菜单条是否显示在合适的语境中?
    · 应用程序的菜单条是否显示系统相关的特性(如时钟显示)?
    · 下拉式操作能正确工作吗?
    · 菜单、调色板和工具条是否工作正确?
    · 是否适当地列出了所有的菜单功能和下拉式子功能?
    · 是否可以通过鼠标访问所有的菜单功能?
    · 文本字体、大小和格式是否正确?
    · 是否能够用其他的文本命令激活每个菜单功能?
    · 菜单功能是否随当前的窗口操作加亮或变灰?
    · 菜单功能是否正确执行?
    · 菜单功能的名字是否具有自解释性?
    · 菜单项是否有帮助,是否语境相关?
    · 在整个交互式语境中,是否可以识别鼠标操作?
    · 如果要求多次点击鼠标,是否能够在语境中正确识别?
    · 光标、处理指示器和识别指针是否随操作恰当地改变?

    数据项:
    · 字母数字数据项是否能够正确回显,并输入到系统中?
    · 图形模式的数据项(如滚动条)是否正常工作?
    · 是否能够识别非法数据?
    · 数据输入消息是否可理解?

    鼠标右键是否可用。
    页面是否支持鼠标托拽。
    页面是否能拷贝。
    tab,shift+tab顺检查。
    输入框输入法检查,光标移到文本框时,默认输入法是否正确。
    输入框转换功能检查,按照要求,是不是一律转换为小写,或者大写,是不是转换为全角或者半角。
    输入框trim功能检查,输入带空格的字符串,是否都trim了。
    检索结果表示检查,所有结果的font是否统一,包括表头,表内容。检索后,条件是否保留或者清除,检索后,光标停留位置。

  • PLSQL导入导出数据库

    2008-11-04 16:20:16

    导出数据库

    建议使用plsql6.0,这样可以在导出sql文件的时候不记录原有表空间的名字

    步骤:

    1 tools --export user object:去除 include storage 选项,点击"export"按钮

    这里不要用export tables 这样就没法导出存储过程,只有表结构

    2 tools --export tables 导出dmp文件

    导入数据库

    步骤:

    1 tools--import tables 导入sql文件,然后再导入dmp文件

  • 监控Tomcat服务器性能

    2008-10-28 23:21:46

    在进行性能测试时,一般都需要对应用服务器进行监控,监控的指标包括应用服务器的JVM使用状况、可用连接数、队列长度等信息。商业的应用服务器如WebLogic、WebSphere等都提供了Console对这些指标进行监控,在性能测试时可以很容易观察这些指标的情况。

      Tomcat作为在国内得到广泛应用的J2EE服务器,在不少项目中都得到了使用。Tomcat小巧灵活、配置简单,非常适合小的WEB应用使用。但在对使用Tomcat的应用系统进行性能测试时,最头疼的问题就是不能获得应用服务器的相关性能指标数据

      其实,从Tomcat 5.0开始,Tomcat就已经为自己提供了一个用于监控应用服务器性能指标的servelet —— status servelet。安装完Tomcat 5之后,通过访问http://yourhost:port/manager/status就可以获得当时的应用服务器监控数据。

      当然,为了安全起见,Tomcat 5在缺省安装时是不允许用户直接访问http://yourhost:port/manager/status的,访问的时候会给出一个403(forbidden)的错误信息。在Tomcat的Manual里说明了允许用户访问的方法:

       1. 转到Tomcat的安装目录下;
       2. 修改conf/tomcat-users.xml文件,在其中加入一行  <user username="servermon" password="passwd" roles="manager"/>

      这样就可以在访问http://yourhost:port/manager/status时给出 servermon 的用户名与口令,查看到应用服务器的相关性能指标数据。

  • IIS服务器的配置,及在其中发布网站

    2008-10-23 10:57:47

    一、IIS服务器的配置

    在控制面板中选择添加删除程序;在弹出的页面中,选择“添加删除组建”,然后选择相应的IIS服务组建进行安装;

    二、IIS下发布网站

    一种不建虚拟目录的方法:(已经使用过,成功)
    1)依次展开本地计算机--网站--默认网站;
    右击默认网站的属性。
    在[网站]标签页中,[IP地址]中分配该服务器的IP,[TCP端口]中输入端口号(默认80)。
    在[主目录]标签页中,[本地路径]中选择你要发布站点的文件夹,然后勾选脚本资源访问、读取,[执行权限]中选择脚本和可执行文件。
    在[文档]标签页中,添加默认文档。
    将网站发布到该文件夹中,之后可通过域名直接访问。

    2)首先到控制面板--管理工具中打开IIS;
    依次展开本地计算机--网站--默认网站;
    右击默认网站,选择新建--虚拟目录:在[别名]中输入虚拟目录名称(如test),在[目录]中选择你要发布站点的文件夹,在[允许下列权限]中勾选读取、运行脚本,完成。
    将网站生成后发布到上述文件夹中。然后就可以通过http://localhost/test/访问。

1095/6<123456>
Open Toolbar