-
性能测试指标的基本概念 (网络摘抄)
2008-12-31 16:25:34
性能测试指标的基本概念 (摘抄)
吞吐量/处理能力
处理能力又叫吞吐量，指的是单位时间内处理的客户端请求数量。通常情况下，吞吐量用请求数/秒 Or 页面数/秒来衡量。从业务角度看，吞吐量也可以用访问人数/天Or页面访问量/天来衡量。负载
负载分为客户端负载和服务器端负载客户端负载的通俗解释就是有多少个用户在同时使用软件服务器端负载的通俗解释就是有多少个请求同时到达了服务器端，要求服务器进行处理。例如，某个网站当前有10000个人在线访问，从他们的客户端层面看过去，这个负载就是客户端负载，为10000。若某个网站当前有10000个人在线访问，某一时刻，从他们的客户端同时发出了1000个页面的请求到服务器，从服务器端层面看过去，这个负载就是服务器端负载，为1000。响应时间
响应时间是可以判断一个被测应用系统是否存在性能瓶颈的最直观的要素。例如，在执行完性能测试后，发现某个交易的“平均响应时间”为8秒，超过了预先确定下来的性能指标“该交易的性能指标为平均响应时间要小于等于3秒”。此时，就可以认为被测应用系统存在性能瓶颈了，要利用一定的手段去探查被测应用系统中哪个地方引起了系统的处理效率低以及低的原因了。响应时间一般包括最大响应时间和平均响应时间，响应时间包括网络上的传输时间，WEB服务器上处理时间、APP服务器上的处理时间、DB服务器上的处理时间，响应时间不包括浏览器上的内容显示时间。同时在线用户
对于一个网站来讲，当一个用户登录到该网站的首页后，开始在该网站上进行各种操作，包括浏览网页、检索内容、提交表单等，这个过程中的用户称为在线用户。若同一时间点或同一个时间段内，有很多这样的用户在访问该网站，这些用户统称为该网站的同时在线用户。同时在线用户的另一层理解是，将应用系统整体看作是一个黑盒子，从用户的客户端层面看向系统，总共有多少个人在使用它。当进行性能测试时，如果你使用的是同时在线用户，则可以称之为同时在线负载。超级并发用户
对于一个网站来讲,可能存在WEB服务器、应用服务器、数据库服务器三个层次，而用户所使用的浏览器是在最外面的客户端层面。如果某个时间点或时间段内，共有1000个用户同时在线，他们进行着各种各样的操作，而某个时间点上可能存在10个左右的用户同时进行了一个或多个操作，导致WEB服务器同时接收到了10个左右的交易请求，我们称这个10个左右的用户为超级并发用户。当进行性能测试时，如果你使用的是超级并发用户，则可以称之为超级并发负载。性能测试脚本
脚本是用负载模拟工具开发出来的。脚本是一些代码的组合体，它用代码来实现用户对应用系统的操作。例如,你在一个网站上访问首页、输入用户名和密码后点击登录按钮进行登录，这是用户对应用系统的两步操作内容，在脚本中则包含了实现这两个操作步骤的代码。如果你要模拟10000个用户的负载，这10000个用户中50%进行首页的访问、20%进行注册、20%进行查询、10%进行某个页面的浏览，则你需要制作5个脚本，分别是首页访问脚本、注册脚本、查询脚本、页面浏览脚本。事务
事务是脚本的一个特性，每个事务都包含开始事务和结束事务。事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。你可以将开始事务放置在脚本中某行代码的前面，将结束事务放置在该行代码的后面，在该脚本的虚拟用户运行时，这个事务将衡量该行代码的执行花费了多长时间。交易
交易分为业务层面和技术层面两种定义。业务层面交易是指完成一次完整的业务操作，例如进行一次取款、查询操作。技术层面的交易是指进行一次应用程序至应用程序、或者应用程序至数据库的系统操作。一般的一笔业务交易由多笔技术交易组成，根据业务交易的复杂度和系统应用架构的不同，其比例大致为1：2-1：10。TPS与HPS
TPS (Transactions Per Second)是估算应用系统性能的重要依据。其意义是应用系统每秒钟处理完成的交易数量，尤其是交易类系统。一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。依据经验，应用系统的处理能力一般要求在10-100左右。不同应用系统的TPS有着十分大的差别，一般需要通过性能测试进行准确估算。当系统没有达到性能瓶颈时，TPS随着负载的增加呈近似线性增长，当接近性能瓶颈时出现拐点；如果系统健壮性较好，在到达性能瓶颈后，TPS基本保持水平，不会再随着负载的增加而有显著增长；而如果系统存在比较严重的性能问题，当到达性能瓶颈后，TPS会出现明显的下降趋势。HPS：(Hits per Second)每秒点击次数，是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和它一般和TPS成正比关系，是B/S系统中非常重要的性能指标之一。
TPS可以有多种衡量单位，在进行性能测试的业务模型分析时使用，例如：
（1）在税务系统中，可以用“系统每个月要处理10万用户的业务操作”，这里的TPS用企业数/月来衡量；（2）在税务系统中，也可以用“系统在第七天的8个小时内要处理4万用户的业务操作”，这里的TPS用企业数/天来衡量；（3）在税务系统中，也可以用“系统在第七天的10点到11点之间要处理1.2万用户的3种缴税交易操作，即3.6万次缴税交易操作”，这里的TPS用交易数/小时来衡量；（4）在税务系统中，也可以用“系统在第七天的10点到11点之间要处理1.2万用户的3种缴税交易操作，即3.6万次缴税交易操作，每次缴税交易要从客户端向服务器发送平均10次HTTP请求，即36万次HTTP请求操作”，这里的TPS用请求数/小时来衡量。
HPS是用来衡量很多用户使用客户端进行操作，向服务器发送请求的效率。我们认为HPS表现的是最终用户的整体行为，是衡量在线负载程度的一个指标。而TPS表现的是服务器端的程序行为，是衡量服务器处理能力高低的一个主要指标。
例如：HPS＝“点击次数/秒”；TPS＝“处理事务数/秒”，HPS与TPS没有绝对的关系。性能测试实现的准确性
在进行了正确的性能测试分析后，获得了正确的性能测试需求，从而使用性能测试工具开发相应的性能测试脚本、开发相应的性能测试场景、在性能测试脚本中利用性能测试数据、在性能测试脚本中设置相应的思考时间、在性能测试场景中设置运行的参数等，以期能利用自动化的性能测试工具模拟现实中大量用户同时访问被测系统的情形。即，如果性能测试工具操作不当，将会导致无法准确的实现“模拟实际情况”的目标。例如，某些性能测试工程师在使用性能测试工具时不懂得利用“检查点”这个功能，从而无法发现在性能测试执行过程中大量虚拟用户甚至没有登陆到系统中的严重问题，仍然认为性能测试执行效果良好，被测系统性能没有问题。Web服务器和APP服务器
通俗的讲，Web服务器传送(serves)页面使浏览器可以浏览，然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点，你可以说：Web服务器专门处理HTTP请求(request)，但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。Web服务器(Web Server)Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request)，会返回一个HTTP响应(response)，例如送回一个HTML页面。为了处理一个请求(request)，Web服务器可以响应(response)一个静态页面或图片，进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本，JSP(JavaServer Pages)脚本，servlets，ASP(Active Server Pages)脚本，服务器端(server-side)Javascrīpt，或者一些其它的服务器端(server-side)技术。无论它们(译者注：脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。要知道，Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时，它只单纯的把请求(request)传递给可以很好的处理请求(request)的程序(译者注：服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境，而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing)，数据库连接(database connectivity)和消息(messaging)等功能。虽然Web服务器不支持事务处理或数据库连接池，但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability)，例如负载平衡(load balancing)，缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。
应用程序服务器(The Application Server)根据我们的定义，作为应用程序服务器，它通过各种协议，可以包括HTTP，把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向浏览器发送HTML以供浏览，而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法(或过程语言中的一个函数)一样。应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑(program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML，所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。在大多数情形下，应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序)的，例如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作(gate-keeping duties)包括安全(security)，事务处理(transaction processing)，资源池(resource pooling)，和消息(messaging)。就象Web服务器一样，应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。 例如，设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询(query)后，网站会进行查找(lookup)并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。
情景1：不带应用程序服务器的Web服务器在此种情景下，一个Web服务器独立提供在线商店的功能。Web服务器获得你的请求(request)，然后发送给服务器端(server-side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file，译者注：flat file是指没有特殊格式的非二进制的文件，如properties和XML文件等)中查找定价信息。一旦找到，服务器端(server-side)程序把结果信息表示成(formulate)HTML形式，最后Web服务器把会它发送到你的Web浏览器。简而言之，Web服务器只是简单的通过响应(response)HTML页面来处理HTTP请求(request)。
情景2：带应用程序服务器的Web服务器情景2和情景1相同的是Web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注：服务器端(server-side)程序)。然而，你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化，此脚本只是简单的调用应用程序服务器的查找服务(lookup service)，而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生HTML响应(response)时就可以使用该服务的返回结果了。在此情景中，应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节，相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时，此服务只是简单的查找并返回结果给客户端。通过从响应产生(response-generating)HTML的代码中分离出来，在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端，例如收款机，也可以调用同样的服务(service)来作为一个店员给客户结帐。相反，在情景1中的定价查找服务是不可重用的因为信息内嵌在HTML页中了。总而言之，在情景2的模型中，在Web服务器通过回应HTML页面来处理HTTP请求(request)，而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。
警告(Caveats) 现在，XML Web Services已经使应用程序服务器和Web服务器的界线混淆了。通过传送一个XML有效载荷(payload)给服务器，Web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。另外，现在大多数应用程序服务器也包含了Web服务器，这就意味着可以把Web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了Web服务器的功能，但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注：这种功能是指既有应用程序服务器的功能又有Web服务器的功能)。相反，如果需要，他们通常会把Web服务器独立配置，和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的Web请求(request)就不会影响应用程序服务器了)，分开配置(专门的Web服务器，集群(clustering)等等)，而且给最佳产品的选取留有余地。性能瓶颈
性能瓶颈实际上就是一个软件的性能缺陷，最通俗的理解“性能瓶颈”。
（1）硬件上的性能瓶颈主要指的是CPU、RAM方面的问题。例如，在进行软件需求分析、概要设计时，确定了在数据库服务器上需要6个CPU、12G内存，但是在测试时，发现CPU的持续利用率超过95%，这时可以认为在硬件上出现了性能瓶颈。
（2）应用软件上的性能瓶颈一般指的是应用服务器、WEB服务器等应用软件，还包括数据库系统。例如，在WEBLogic平台上配置了JDBC连接池的参数，最大连接数为50，最小连接数为5，增加量为10。在测试时发现，当负载增加时，现有的连接数不足，系统会动态生成10个新的连接数，这样导致了交易处理的响应时间大大的增加。这时可以认为在应用软件上出现了性能瓶颈。
（3）应用程序上的性能瓶颈，一般指的是开发人员新开发出来的应用程序。例如，用Java或者C开发出来的部署在应用服务器上用于用户交易请求处理的应用程序。例如，某个开发员开发了一个缴费处理程序，在测试时发现，这个缴费处理程序在处理用户发过来的并发缴费请求时，只能串行处理，无法并行处理，导致缴费交易的处理响应时间非常长，这时可以认为在应用程序上出现了性能瓶颈。
（4）操作系统上的性能瓶颈，一般指的是Windows、Unix、Linux这些操作系统。例如，在windows系统中，虚拟内存设置的不合理，都指定为C驱提供虚拟内存，在测试时发现当出现物理内存不足时，虚拟内存的交换效果非常不理想，导致交易的响应时间大大增加。这时可以认为在操作系统上出现了性能瓶颈。
（5）网络设备上的性能瓶颈，一般指的是防火墙、动态负载均衡器、交换机等设备。例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其它负载较轻的应用服务器上。在测试时发现，动态负载均衡机制没有起到相应的作用，这时可以认为在网络设备上出现了性能瓶颈。 -
性能测试用例(网站)转载
2008-12-29 10:25:00
某网站提供会员模板下载、上传、购买、支付等功能，目前进入性能测试阶段，通过性能需求可以了解到主要有以下几个性能指标需要进行测试：
产品页面刷新性能
产品上传性能
产品下载性能
目前给出的指标为：
延迟：
测试项 响应时间 抖动 备注
产品页面刷新 <5秒 <2秒
产品下载相应时间 <4秒 <2秒
吞吐量：
编号 项 吞吐量
Perf.T.1 所有登录用户在线状态更改频率 每10分钟1次
Perf.T.2 每日页面平均访问量 60000次
Perf.T.3 每日下载量 50000
Perf.T.4 平均每日新增会员数量 500
Perf.T.5 高峰同一模板下载量 100用户并发下载
Perf.T.6 高峰不同模板下载量 150用户并发下载
容量：
编号 项 容量
Perf.C.1 用户数 <=100万
Perf.C.2 活动用户数 10000
Perf.C.3 模板中心总用户数 <=25万
根据如上性能需求及数据我们该如何设计性能测试用例及场景呢？（可以说给出的性能需求很垃圾，没有丝毫价值，但没办法还是点做啊）
首先，我不去在乎它要求的性能是什么，我只需要去做在一定的测试环境下对系统进行压力测试，找到各个性能指标的临界点就好了，至于是否达到性能指标，在和性能需求对照编写测试报告即可。所以，针对这几个需要进行性能测试的页面，我们做一下分析，如何设计场景才能尽可能准确地体现出系统的性能：
先说一下搜索页面
搜索页面根据对项目的了解，搜索后，将所有符合条件的结果遍历出来，显示在前台，每页的显示数量是一定的，超出的部分分页显示。根据上面的描述我们可以看出搜索结果是在将符合条件的所有结果集均发送到前台页面，对于页面显示对性能的消耗我们可以忽略不计，主要的压力来自数据的传输、sql的执行及应用服务器的处理过程，所以我可以从两个方面设计场景：a、虚拟用户一定，不同数据库数量级的情况下，搜索的性能
如何确定虚拟用户的数量成为一个关键，我们可以让客户提供一个常规情况下每天访问用户数（如果没有实际数据可参考，可以根据产品方案中期望的用户数来代替），我们就用这个用户数来进行测试；再来分析一下不同的数据库数量级，如果系统运营1年的产品数据量是5万条，那么我们就根据这个值分别取1W条、3W条、5W条、10W条、20W条数据量来进行测试（具体的分法可以根据实际情况而定），所以对于这个测试目标，我们可以设计5个场景进行：
虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间
100 10000 搜索页面 随机产生 30分钟 加入思考时间
100 30000 搜索页面 随机产生 30分钟 加入思考时间
100 50000 搜索页面 随机产生 30分钟 加入思考时间
100 100000 搜索页面 随机产生 30分钟 加入思考时间
100 200000 搜索页面 随机产生 30分钟 加入思考时间
b、一定数据库数量级，不同量虚拟用户的情况下，搜索的性能
我们定下来一个常规的数据库数据量，在数据量不变的情况下逐步增加虚拟用户数，测试一下不同虚拟用户压力下系统的性能
虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间
50 50000 搜索页面 随机产生 30分钟 加入思考时间
80 50000 搜索页面 随机产生 30分钟 加入思考时间
100 50000 搜索页面 随机产生 30分钟 加入思考时间
120 50000 搜索页面 随机产生 30分钟 加入思考时间
150 50000 搜索页面 随机产生 30分钟 加入思考时间产品上传
影响上传性能的主要因素有上传文件的大小和上传的请求数，所以我们就从这两个方面设计用例。
a、虚拟用户数一定，上传不同大小的文件
虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间
50 100k 上传页面 随机产生 30分钟 取消思考时间
50 300k 上传页面 随机产生 30分钟 取消思考时间
50 500k 上传页面 随机产生 30分钟 取消思考时间
50 800k 上传页面 随机产生 30分钟 取消思考时间
50 1M 上传页面 随机产生 30分钟 取消思考时间b、上传文件大小一定，不同量的虚拟用户
虚拟用户数 上传文件大小 录制页面 并发用户数执行时间思考时间
20 300k 上传页面 随机产生 30分钟 取消思考时间
50 300k 上传页面 随机产生 30分钟 取消思考时间
80 300k 上传页面 随机产生 30分钟 取消思考时间
100 300k 上传页面 随机产生 30分钟 取消思考时间产品下载
影响下载性能的主要因素有下载文件的大小和下载的请求数，所以我们就从这两个方面设计用例
a、虚拟用户数一定，下载不同大小的文件
虚拟用户数 下载文件大小 录制页面 并发用户数执行时间思考时间
50 100k 下载页面 随机产生 30分钟取消思考时间
50 300k 下载页面 随机产生 30分钟取消思考时间
50 500k 下载页面 随机产生 30分钟取消思考时间
50 800k 下载页面 随机产生 30分钟取消思考时间
50 1M 下载页面 随机产生 30分钟 取消思考时间b、下载文件大小一定，不同量的虚拟用户
虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间
20 300k 下载页面 随机产生 30分钟 取消思考时间
50 300k 下载页面 随机产生 30分钟 取消思考时间
80 300k 下载页面 随机产生 30分钟 取消思考时间
100 300k 下载页面 随机产生 30分钟 取消思考时间 -
Oracle数据库的锁
2008-12-27 17:05:04
Oracle数据库的锁数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。
加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。
在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。
Oracle数据库的锁类型
根据保护的对象不同，Oracle数据库锁可以分为以下几大类：DML锁（data locks，数据锁），用于保护数据的完整性；DDL锁（dictionary locks，字典锁），用于保护数据库对象的结构，如表、索引等的结构定义；内部锁和闩（internal locks and latches），保护数据库的内部结构。
DML锁的目的在于保证并发情况下的数据完整性，。在Oracle数据库中，DML锁主要包括TM锁和TX锁，其中TM锁称为表级锁，TX锁称为事务锁或行级锁。
当Oracle 执行DML语句时，系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志，而只需检查TM锁模式的相容性即可，大大提高了系统的效率。TM锁包括了SS、SX、S、X 等多种模式，在数据库中用0－6来表示。不同的SQL操作产生不同类型的TM锁。
在数据行上只有X锁（排他锁）。在 Oracle数据库中，当一个事务首次发起一个DML语句时就获得一个TX锁，该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行 DML语句时，第一个会话在该条记录上加锁，其他的会话处于等待状态。当第一个会话提交后，TX锁被释放，其他会话才可以加锁。
当Oracle数据库发生TX锁等待时，如果不及时处理常常会引起Oracle数据库挂起，或导致死锁的发生，产生ORA-60的错误。这些现象都会对实际应用产生极大的危害，如长时间未响应，大量事务失败等。
悲观封锁和乐观封锁
一、悲观封锁
锁在用户修改之前就发挥作用：
Select ..for update（nowait)
Select * from tab1 for update
用户发出这条命令之后，oracle将会对返回集中的数据建立行级封锁，以防止其他用户的修改。
如果此时其他用户对上面返回结果集的数据进行dml或ddl操作都会返回一个错误信息或发生阻塞。
1：对返回结果集进行update或delete操作会发生阻塞。
2：对该表进行ddl操作将会报：Ora-00054:resource busy and acquire with nowait specified.原因分析
此时Oracle已经对返回的结果集上加了排它的行级锁，所有其他对这些数据进行的修改或删除操作都必须等待这个锁的释放，产生的外在现象就是其他的操作将发生阻塞，这个这个操作commit或rollback.
同样这个查询的事务将会对该表加表级锁，不允许对该表的任何ddl操作，否则将会报出ora-00054错误：:resource busy and acquire with nowait specified.二、乐观封锁
乐观的认为数据在select出来到update进取并提交的这段时间数据不会被更改。这里面有一种潜在的危险就是由于被选出的结果集并没有被锁定，是存在一种可能被其他用户更改的可能。因此Oracle仍然建议是用悲观封锁，因为这样会更安全。阻塞
定义：
当一个会话保持另一个会话正在请求的资源上的锁定时，就会发生阻塞。被阻塞的会话将一直挂起，直到持有锁的会话放弃锁定的资源为止。4个常见的dml语句会产生阻塞
INSERT
UPDATE
DELETE
SELECT…FOR UPDATE
INSERTInsert发生阻塞的唯一情况就是用户拥有一个建有主键约束的表。当2个的会话同时试图向表中插入相同的数据时，其中的一个会话将被阻塞，直到另外一个会话提交或会滚。一个会话提交时，另一个会话将收到主键重复的错误。回滚时，被阻塞的会话将继续执行。
UPDATE 和DELETE当执行Update和delete操作的数据行已经被另外的会话锁定时，将会发生阻塞，直到另一个会话提交或会滚。
Select …for update
当一个用户发出select..for update的错作准备对返回的结果集进行修改时，如果结果集已经被另一个会话锁定，就是发生阻塞。需要等另一个会话结束之后才可继续执行。可以通过发出 select… for update nowait的语句来避免发生阻塞，如果资源已经被另一个会话锁定，则会返回以下错误：Ora-00054:resource busy and acquire with nowait specified.
死锁-deadlock
定义:当两个用户希望持有对方的资源时就会发生死锁.
即两个用户互相等待对方释放资源时,oracle认定为产生了死锁,在这种情况下,将以牺牲一个用户作为代价,另一个用户继续执行,牺牲的用户的事务将回滚.
例子：
1：用户1对A表进行Update，没有提交。
2：用户2对B表进行Update，没有提交。
此时双反不存在资源共享的问题。
3：如果用户2此时对A表作update,则会发生阻塞，需要等到用户一的事物结束。
4：如果此时用户1又对B表作update，则产生死锁。此时Oracle会选择其中一个用户进行会滚，使另一个用户继续执行操作。
起因:
Oracle的死锁问题实际上很少见，如果发生，基本上都是不正确的程序设计造成的，经过调整后，基本上都会避免死锁的发生。DML锁分类表
表1 Oracle的TM锁类型 锁模式 锁描述 解释 SQL操作 0 none 1 NULL 空 Select 2 SS(Row-S) 行级共享锁，其他对象只能查询这些数据行 Select for update、Lock for update、Lock row share
3 SX(Row-X) 行级排它锁，在提交前不允许做DML操作 Insert、Update、Delete、Lock row share
4 S(Share) 共享锁 Create index、Lock share 5 SSX(S/Row-X) 共享行级排它锁 Lock share row exclusive 6 X(Exclusive) 排它锁 Alter table、Drop able、Drop index、Truncate table 、Lock exclusive
1.关于V$lock表和相关视图的说明ColumnDatatypeDescrīptionADDRRAW(4 | 8)Address of lock state objectKADDRRAW(4 | 8)Address of lockSIDNUMBERIdentifier for session holding or acquiring the lockTYPEVARCHAR2(2)Type of user or system lockThe locks on the user types are obtained by user applications. Any process that is blocking others is likely to be holding one of these locks. The user type locks are:TM - DML enqueueTX - Transaction enqueueUL - User supplied--我们主要关注TX和TM两种类型的锁--UL锁用户自己定义的，一般很少会定义，基本不用关注--其它均为系统锁，会很快自动释放，不用关注ID1NUMBERLock identifier #1 (depends on type)ID2NUMBERLock identifier #2 (depends on type)---当lock type 为TM时，id1为DML-locked object的object_id---当lock type 为TX时，id1为usn+slot，而id2为seq。--当lock type为其它时，不用关注LMODENUMBERLock mode in which the session holds the lock:- 0 - none
- 1 - null (NULL)
- 2 - row-S (SS)
- 3 - row-X (SX)
- 4 - share (S)
- 5 - S/Row-X (SSX)
- 6 - exclusive (X)
--大于0时表示当前会话以某种模式占有该锁，等于0时表示当前会话正在等待该锁资源，即表示该会话被阻塞。--往往在发生TX锁时，伴随着TM锁，比如一个sid=9会话拥有一个TM锁，一般会拥有一个或几个TX锁，但他们的id1和id2是不同的，请注意REQUESTNUMBERLock mode in which the process requests the lock:- 0 - none
- 1 - null (NULL)
- 2 - row-S (SS)
- 3 - row-X (SX)
- 4 - share (S)
- 5 - S/Row-X (SSX)
- 6 - exclusive (X)
--大于0时，表示当前会话被阻塞，其它会话占有改锁的模式CTIMENUMBERTime since current mode was grantedBLOCKNUMBERThe lock is blocking another lock0, 'Not Blocking', /* Not blocking any other processes */
1, 'Blocking', /* This lock blocks other processes */
2, 'Global', /* This lock is global, so we can't tell */
--该锁是否阻塞了另外一个锁
2.其它相关视图说明
视图名 描述 主要字段说明 v$session 查询会话的信息和锁的信息。 sid,serial#：表示会话信息。program：表示会话的应用程序信息。row_wait_obj#：表示等待的对象,和dba_objects中的object_id相对应。lockwait :该会话等待的锁的地址,与v$lock的kaddr对应.v$session_wait 查询等待的会话信息。 sid：表示持有锁的会话信息。Seconds_in_wait：表示等待持续的时间信息Event：表示会话等待的事件，锁等于enqueuedba_locks 对v$lock的格式化视图。 Session_id：和v$lock中的Sid对应。Lock_type：和v$lock中的type对应。Lock_ID1： 和v$lock中的ID1对应。Mode_held,mode_requested：和v$lock中的lmode,request相对应。v$locked_object 只包含DML的锁信息，包括回滚段和会话信息。 Xidusn,xidslot,xidsqn：表示回滚段信息。和v$transaction相关联。Object_id：表示被锁对象标识。Session_id：表示持有锁的会话信息。Locked_mode：表示会话等待的锁模式的信息，和v$lock中的lmode一致。1.查询数据库中的锁
select * from v$lock;
select * from v$lock where block=1;
2.查询被锁的对象
select * from v$locked_object;
3.查询阻塞
查被阻塞的会话
select * from v$lock where lmode=0 and type in ('TM','TX');
查阻塞别的会话锁
select * from v$lock where lmode>0 and type in ('TM','TX');
4.查询数据库正在等待锁的进程
select * from v$session where lockwait is not null;
5.查询会话之间锁等待的关系select a.sid holdsid,b.sid waitsid,a.type,a.id1,a.id2,a.ctime from v$lock a,v$lock b
where a.id1=b.id1 and a.id2=b.id2 and a.block=1 and b.block=0;6.查询锁等待事件
select * from v$session_wait where event='enqueue';解决方案：SELECT sid, serial#, username, osuser FROM v$session;
ALTER SYSTEM KILL SESSION 'sid,serial';
example:
ALTER SYSTEM KILL SESSION '13, 8'; -
高性能网页开发新20条规则详解 (有用的转载)
2008-12-27 16:57:42
高性能网页开发新20条规则详解
上个月，Yahoo!优异性能（Yahoo!'s Exceptional Performance）开发团队成员 Stoyan Stefanov 出席了蒙特利尔的2008魁北克PHP会议演讲。他提供了他们团队最新的研究成果和提高网页性能规则20条。在早先的高性能网页开发14条军规已经让大家耳熟能详，此次新增的20条更加全面，覆盖了服务器端、cookies、页面内容、Javascrīpt、CSS、图片、移动手机应用这七大类别。以下内容就是根据这二十条结合个人在实际开发中的理解所做的全面解读。希望对大家开发有所助益。阅读指导：
1. 每条规则后会指明是针对上述所说的七大类别中哪个类别的优化。
2. 文中提到的一些工具在文后附注中会提供简要说明。
3. 文中经常提到“组件”这个词，这个词不同于我们程序开发中常提到的组件概念。本文中提到的“组件”特指嵌在HTML页面中图片、Javascrīpt脚本、CSS等静态文件。
一、尽早清除缓冲区［服务器端］
假如用户请求一个页面，而这个页面在后端服务器需要花200至500毫秒乃至更长时间才能生成最终HTML页面，这时候用户浏览器处于较长时间的、等待页面数据返回的空闲状态，用户体验不会很好。此时可以根据页面内容长短做适当分隔，将先生成的页面局部HTML缓冲内容提前发送到客户端，不必让服务器消耗内存缓冲完整个庞大的页面内容后再行输出。这种方法有益于处理后端负荷大而前端负荷轻的页面。
在HTML页面的head标签位置后是清除缓冲的好位置，因为HTML的head标签可以包括 CSS 和 Javascrīpt 文件，对于浏览器而言获取页面显示与后端服务器处理并行的效果较好。在PHP中有一个函数 flush()，它可以发送请求页面的局部HTML代码给浏览器，以便浏览器能先取得页面已经生成的部分HTML，同时后端服务器继续忙于处理生成页面余下的HTML。以下以此函数做个示例：
... <!-- css, js -->
</head>
<!-- 注意此处flush()是放在了head标签位置后面 -->
<?php flush(); ?>
<body>
... <!-- content -->
其他语言也有类似语法，如ASP.NET和ASP中的 Response.Flush()。
注意：在实际Web开发中，尽量减少HTTP请求次数是优化的重要方面，这条基本原则是早先14条和新增20条中很多规则的制订基础，实际上它也是14条规则中第一条也是非常重要的一条规则，但是使用尽早清除缓冲语句会增加一个页面的HTTP请求次数，这无疑是一个矛盾，因此请注意本条规则的适用范围，不要滥用它。
二、使用GET方法的AJAX请求［服务器端］
这个容易理解一些。AJAX经常要用XMLHttpRequest，但是它的POST方法在浏览器中完成需要执行两步：首先发送信息头，然后才是发送数据；而GET方法只用一个TCP数据包传递（cookies信息例外）即可，减少了一个步骤，速度会快些。
另外根据HTTP规范，GET方法就是为获取信息而生的。因此仅在请求数据而不是发送数据给服务器端存储时，使用GET方法很有意义。
要注意的是，IE中URL允许最大允许长度是2K，用GET方法发送数据时注意2K的这个限制。
三、后加载组件［页面内容］
使用该方法的意义在于：如果某个页面内容丰富多彩的话，在浏览器加载显示它时速度就不会很快。使用后加载组件的方法可以通过延迟加载一些隐藏内容来保证浏览器优先显示初始页面。
要做到这一点必须仔细观察自己的页面并且问自己：“解释生成一个完整页面，什么部分内容是开始加载时绝对必须显示的？”清楚了这个问题，那么那些余下内容和组件就可以采用后加载方法延迟生成。这样会大大加快页面显示速度。
这个技巧通常是Javascrīpt通过处理页面加载时的onload事件完成。例如，使用Javascrīpt代码和库去执行拖放动态效果操作时，这些操作可以延迟，因为拖动页面上元素的操作只能等初始页面生成完后才能发生。页面中的隐藏内容也适合用后加载方式，因为只有页面加载完毕用户才能操作决定是否显示该内容。
Yahoo!网站的首页内容繁多，观察处于隐藏状态下的内容，这些内容通常在一些选项卡一样的标签页当中，只有点击后才会加载。
只要明白该规则的优化要点后相信大家可以通过Javascrīpt做出自己的具体实现。Yahoo!提供了两个用于实现后加载方法的工具：
◆ YUI Image Loader：可以延迟图片显示
◆ YUI Get utility：它可以在页面加载完成后把Javascrīpt和CSS资源绑定到DOM上去。
以上的工具是Yahoo!的YUI库提供。
四、预加载组件［页面内容］
从文字上看预加载组件与后加载组件似乎作用相反，但实际上二者目标是完全不同的。通过预先加载组件可以充分利用浏览器的空闲时间，并且可以请求未来页面需要的组件。在这种情况下，当用户访问下一个页面时，你已经提前让大多数组件保存在缓存中，用户加载这个页面就会非常快。
预加载类型有下列三种：
1. 无条件预加载
onload事件一触发，就要马上取回一些指定的组件。可以检查google.com首页中onload事件中请求Sprite图片的例子（注：什么是Sprite图片，请参看第十六条规则）。在这个例子可以看出这个sprite图片www.google.com/images/nav_logo3.png在google.com首页本身并不需要, 但它会在随后用户搜索生成的结果页面中需要。
2. 条件预加载
根据用户操作预测用户下一步操作的方向，并据此做预加载。例如，search.yahoo.com中，在输入框中刚键入几个字符后，就会看到页面对你键入的词做出合理推测，推出几个可能要搜索的实际关键词。此方法目前谷歌（google.cn）也在使用。
3. 提前预加载
在将重新设计的网站页面发布前用此法较好。页面重新设计后常会有这样的反馈：“新站点太酷了，就是比以前慢”。原因在于用户访问旧站点是全缓存的，但新站点还没有缓存过。这时可以在发布新设计前就预加载一些新站点组件，这可以减少没有缓存的副作用。可以利用用户访问旧站点时浏览器空闲的时间请求新站点要使用的图片、脚本等。
五、减少 DOM 元素数量［页面内容］
一个复杂的页面意味着要请求下载的字节数更多，也意味着用Javascrīpt访问DOM速度更慢。
如何尽量减少已有页面的 DOM 元素数量呢？一个重要的思路就是不要滥用表格table和div 。很多人习惯用一些网页编辑软件去设计页面，这样会导致大量嵌套的表格或在使用语义不合法的标记。使用div要仅当它在语义上有意义时才使用它，有些开发者使用它仅仅是因为它可以被浏览器解释生成一个新行。
Yahoo! 提供了一个避免这些问题的方法——使用YUI CSS工具。grids.css 有助于整体布局设计，fonts.css 和 reset.css 有且于清除浏览器的默认格式设置。这些工具可以在Yahoo!的YUI页面中去找。
DOM元素的数量可在Firebug的Console上键入 document.getElementsByTagName('*').length 得到。
DOM 元素不超过多少才适当呢？这可以通过检查一些有良好设计的页面来感觉比较。如Yahoo! 主页访问量相当大，它的数量在700个元素（HTML标签）以下。
六、分隔组件到多个域中［页面内容］
对终端用户响应时间影响最大的就是所请求页面所含组件数量。只要浏览器缓存为空，下载每个组件需要占用额外的HTTP请求，只有缓存满时才可能不占用。
HTTP/1.1规范中建议浏览器对每一个主机名允许并发下载两个组件。默认状态下，Internet Explorer和Firefox都符合这个规范。注意：IE8.0默认允许6个并发请求。
许多网页中所有组件都从同一主机名中下载，这时不仅响应时间受并发线程数限制，同时也受该服务器CPU和带宽限制。把页面组件分布在两个主机名中，整体响应时间就会快2倍，CPU和带宽消耗也会得以分担。
七、尽量减少 HTML 标签 iframe 的使用数［页面内容］
iframe允许在父文档内插入一个HTML文档。要想高效使用iframes，理解它的工作方式很重要。
使用iframe有如下好处：
◆ 有助于减慢显示第三方标记和广告内容。
◆ 是个安全的 Sandbox。
◆ 能并发下载脚本。
但同时也有弊端：
◆ 即使iframe 内的 HTML 文档内容为空，消耗也比较高。
◆ 会阻止页面的onload事件
◆ 非语义的
八、避免404页面［页面内容］
如果做了一个HTTP请求然后得到一个无用的响应页面，不仅完全不必要而且会降低用户体验。404页面就是在没有发现指定资源时返回的页面。
一些站点提供了有益的404提示，对用户体验有好处，但这毕竟浪费了服务器资源。当链接一个外部Javascrīpt文件，而它又出了404错误，这尤其糟糕。首先，因为这个下载有问题会阻止并发下载；其次，即使有错浏览器仍然会尽力解析404返回的内容，看看有无Javascrīpt代码，尽力查找里面可用代码。
-
数据库测试方法介绍(转贴)
2008-12-26 11:06:08
数据库测试包括测试实际数据(内容)以及数据完整性,已经确保数据没有被误用以及规划的正确性,同时也对数据库应用(例如,Sql处理组件)进行功能性测试.通常会用到SqL脚本进行数据库测试.尽管不是所有的数据库都是适合Sql的,但是通过Sql数据库可以支持绝大部分数据操作,大多数的Web应用程序也是如此。通常有两类由数据库错误引发的问题，它们是数据完整性错误以及输出错误。输出错误是在数据提取和操作数据指令过程中发生的错误引起的，这时源数据是正确的。
通常，数据操作包含了以下一些活动：
首次活动（例如安装过程）
1.连邮菘夥衿?2.创建新数据库 3.创建表格、默认值和规则；填入默认数据。 4.编译存储过程和触发器
在成功安装过程完成之后，对数据库的使用由以下活动组成：
1.连接数据库 2.执行Sql语句、存储过程以及触发器 3.释放与数据库的连接
在数据库活动中所包含的错误主要有以下几种常见类型：
1.连接数据库失败，引起该类失败的许多潜在问题包括：
a.非法的用户名、密码或两者皆非法 b.对于某些数据活动，如创建表和存储过程，用户拥有不适当的权限。
c.非法或错误的DSN d.与拥有必要的DSN文件的服务器连接失败
指令（存储过程、触发器等）中常见错误包括：
1.数据库被配置为区分大小写的，但是代码却没有
2.在Sql语句中使用了保留关键字，例如 Select user from mytable。user为保留关键字
3.NULL被传递给不接受NULL的记录字段
4.在字符串字段中对单引号（‘）的错误处理。
5.在整型字段中对逗号（，）的错误处理。
6.数值对于字段大小来说过大，字符串对于字段的长度来说过长。
7.超时---数据库执行完某个过程所用时间长于脚本中所设定的超时值。
8.非法或错误拼写的字段、列、表或者视图的名称，未定义的字段、表或视图的名称，非法或错误拼写的存储过程名称
9.调用错误的存储过程。
10.缺少关键字。
下面为实际例子介绍：
1.缺少关键字的： create view student_view select * from student_tbl。其中语句缺少as关键字
（注：剩下部分以后再慢慢补上，请大家多支持。）
-
[转载]基于实际测试的功能测试点总结
2008-12-19 15:17:30
1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。可以使用一些工具，如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码；HTML Link Validater只能测试以Html或者htm结尾的网页链接；Xenu无需安装，支持asp、do、jsp等结尾的网页，xenu测试链接包括内部链接和外部链接，在使用的时候应该注意，同时能够生成html格式的测试报告。如果系统用QTP进行自动化测试，也可以使用QTP的页面检查点检查链接。2. 相关性检查：
Ø 功能相关性：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确，常见的情况是，增加某个数据记录以后，如果该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形。
Ø 数据相关性：下来列表默认值检查，下来列表值检查，如果某个列表的数据项依赖于其他模块中的数据，同样需要检查，比如，某个数据如果被禁用了，可能在引用该数据项的列表中不可见。
3. 检查按钮的功能是否正确：如新建、编辑、删除、关闭、返回、保存、导入，上一页，下一页，页面跳转，重置等功能是否正确。常见的错误会出现在重置按钮上，表现为功能失效。
4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。还要检查需求规定的字符串长度是否是正确的，有时候会出现，需求规定的字符串长度太短而无法输入业务数据。
5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。
6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格当作一个字符，而在查询的时候空格被屏蔽，导致无法查询到添加的内容。
7．特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。常见的错误是出现在% ‘ \ 这几个特殊字符
8. 中文字符处理: 在可以输入中、英文的系统输入中文,看会否出现乱码或出错。
9. 检查信息的完整性: 在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。要注意检查的时候每个字段都应该检查，有时候，会出现部分字段更新了而个别字段没有更新的情况。
10. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。
11. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。如果有多页，翻页选，看系统是否都正确删除，并且要注意，删除的时候是否有提示，让用户能够更正错误，不误删除。
12. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
13. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
14. 重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否做了处理。对于Web系统来说，可以通过浏览器返回键或者系统提供的返回功能。
15. 检查多次使用返回键的情况: 在有返回键的地方,返回到原来页面,重复多次，看会否出错。
16. 搜索检查: 有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确，搜索的时候同样要注意特殊字符，某些系统会在输入特殊字符的时候，将系统中所有的信息都搜索到。
17. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。
18. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。下载文件能否打开或者保存，下载的文件是否有格式要求，如需要特殊工具才可以打开等。上传文件测试同时应该测试，如果将不能上传的文件后缀名修改为可以上传文件的后缀名，看是否能够上传成功，并且，上传文件后，重新修改，看上传的文件是否存在。
19. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加“*”；对必填项提示返回后，焦点是否会自动定位到必填项。
20. 快捷键检查：是否支持常用快捷键，如Ctrl+C、 Ctrl+V、 Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
21. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。这个地方很有可能会出现错误。
22．刷新键检查：在Web系统中，使用浏览器的刷新键，看系统处理如何，会否报错。
23．回退键检查：在Web系统中，使用浏览器的回退键，看系统处理如何，会否报错。对于需要用户验证的系统，在退出登录后，使用回退键，看系统处理如何；多次使用回退键，多次使用前进键，看系统如何处理。
24．直接URL链接检查：在Web系统中，直接输入各功能页面的URL地址，看系统如何处理，对于需要用户验证的系统更为重要。如果系统安全性设计的不好，直接输入各功能页面的URL地址，很有可能会正常打开页面。
25．空格检查：在输入信息项中，输入一个或连串空格，查看系统如何处理。如对于要求输入整型、符点型变量的项中，输入空格，既不是空值，又不是标准输入。
26．输入法半角全角检查：在输入信息项中，输入半角或全角的信息，查看系统如何处理。如对于要求输入符点型数据的项中，输入全角的小数点（“。”或“．”，如４．５）；输入全角的空格等。
27．密码检查：一些系统的加密方法采用对字符Ascii码移位的方式，处理密码加密相对较为简单，且安全性较高，对于局域网系统来说，此种方式完全可以起到加密的作用，但同时，会造成一些问题，即大于128的Ascii对应的字符在解密时无法解析，尝试使用“uvwxyz”等一些码值较大的字符作为密码，同时，密码尽可能的长，如17位密码等，造成加密后的密码出现无法解析的字符。
28．用户检查：任何一个系统，都有各类不同的用户，同样具有一个或多个管理员用户，检查各个管理员之间是否可以相互管理，编辑、删除管理员用户。同时，对于一般用户，尝试删除，并重建同名的用户，检查该用户其它信息是否重现。同样，提供注销功能的系统，此用户再次注册时，是否作为一个新的用户。而且还要检查该用户的有效日期，过了有效日期的用户是不能登录系统的。容易出现错误的情况是，可能有用户管理权限的非超级管理员，能够修改超级管理员的权限。
29．系统数据检查：这是功能测试最重要的，如果系统数据计算不正确，那么功能测试肯定是通不过的。数据检查根据不同的系统，方法不同。对于业务管理平台，数据随业务过程、状态的变化保持正确，不能因为某个过程出现垃圾数据，也不能因为某个过程而丢失数据。
30．系统可恢复性检查：以各种方式把系统搞瘫，测试系统是否可正常迅速恢复。
31．确认提示检查：系统中的更新、删除操作，是否提示用户确认更新或删除，操作是否可以回退（即是否可以选择取消操作），提示信息是否准确。事前或事后提示，对于Update或Delete操作，要求进行事前提示。
32．数据注入检查：数据注入主要是对数据库的注入，通过输入一些特殊的字符，如“’”，“/”，“-”等或字符组合，完成对SQL语句的破坏，造成系统查询、插入、删除操作的SQL因为这些字符而改变原来的意图。如select * from table where id = ‘ ’ and name = ‘ ’，通过在id输入框中输入“
33．刷新检查：web系统中的WebForm控件实时刷新功能，在系统应用中有利有弊，给系统的性能带来较大的影响。测试过程中检测刷新功能对系统或应用造成的影响（白屏），检查控件是否回归默认初始值，检查是否对系统的性能产生较大影响（如每次刷新都连接数据库查询等）。
34．事务检查：对于事务性操作，断开网络或关闭程序来中断操作，事务是否回滚。
35．时间日期检查：时间、日期验证是每个系统都必须的，如2006-2-29、2006-6-31等错误日期，同时，对于管理、财务类系统，每年的1月与前一年的12月（同理，每年的第1季度与前一年的第4季度）。另外，对于日期、时间格式的验证，如
36．多浏览器验证：越来越多的各类浏览器的出现，用户访问Web程序不再单单依赖于Microsoft Internet Explorer，而是有了更多的选择：Maxthon、Firefox、Tencent Traveler等，考虑使用多种浏览器访问系统，验证效果。
37．安装测试：对于C/S架构的系统，安装程序的测试是一个重要方面，安装程序自动化程度、安装选项和设置（验证各种方案是否都能正常安装）、安装过程中断测试、安装顺序测试（分布式系统）、修复安装及卸载测试。
38．文档测试：主要是对用户使用手册、产品手册进行测试，校验是否描述正确、完整，是否与当前系统版本对照，是否易理解，是否二义性等。
39．测试数据检查：事实告诉我们，测试数据比代码更有可能是错的，因此，当测试结果显示有错误发生的时候，怀疑代码错误前要先对测试数据检查一遍。
40．请让我的机器来运行：在某些项目中，出现一个病态的问题：系统没有问题呀，它在我的机器上是能够通过的。这就说明了其中存在着和环境相关的BUG。“是否所有的一切都受到了版本控制工具的管理？”、“本机的开发环境和服务器的环境是否一样？”、“这里是否存在一个真正的BUG，只不过是在其他的机器里偶然出现？”。所有的测试必须在所有系统要求的机器上运行通过，否则的话，代码就可能存在问题。
41．Ajax技术的应用：Ajax有很多优点，但也有很多缺点，如果利用优点、避免缺点，是我们对新的Web2.0应用的一个挑战。而Ajax的应用最直接的问题就是用户体验，用户体验的效果直接关系到是否使用Ajax技术。“会做，并不意味着应该做、必须做”，这就是对Ajax技术的很重要的注解。
42．Ajax技术的应用：Ajax采用异步调用的机制实现页面的部分刷新功能，异步调用存在异常中断的可能，尝试各种方法异常中断异步的数据调用，查看是否出现问题。在这里遇到的一个问题就是对日期控件的操作，已经如果页面数据较多的时候的刷新。
43．脚本错误：随着Ajax、IFrame等异步调用技术的发展，Javascrīpt技术也越来越受到开发人员的重视，但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题，因此在Web系统中，可能会出现脚本错误。同时，脚本错误造成的后果可大、可小，不能忽视。
-
搜索引擎测试点(转载)
2008-12-19 15:14:29
包括关键字搜索.完全匹配.有效字符.无效字符等1,空内容点击搜索，看其有没有LINK
2,输入过长查询数据，看其有没判断，报错
3,输入各种符号，特别是空格，看其能否正确判断
4,输入各种字符，譬如输入范围是0~9，A~Z的看输入中文是什么效果
5,输入正确数据，看其的查询后数据的完整性
6,注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方
7,在输入结束后直接按回车键,看系统处理如何,会否报错
8,反复输入相同的数据（5次以上）看是否报错
9,各国文字/字符的输入/粘贴能正确显示 退格键等操作显示正常 超过支持的最大长度有相应的提示 混合的多种语言也能正确显示
10,显示&接收；能进行下一步处理
11,其他的 包括能删除 能剪切等（我也不确定要不要包括 有点奇怪 显示语言是字符库支持的问题 而且如果是面向对象程序设计语言做的文本框 删除什么的功能也不用测 -
配置Jprofile及注册码分享(网络收集)
2008-12-16 17:15:47
配置Jprofile
配置本地监控步骤
第一步，在安装被监控程序的机器上安装windows版的jprofiler5.第二步，New Session，选择New server Integration。
选择服务类型，本次配置使用的是TOMCAT5.5，可以选择Apache Tomcat 5.x第三步，选择本地机器。
第四步，选择本地机器选择服务启动文件，如：D:\dhcc\soft\DhccOA\bin\appserver\apache-tomcat-5.5.20\bin\startup.bat，点击NEXT
第五步，选择JVM类型及版本
第六步，设置端口号，使用默认的端口号。
第七步，使用默认选择，不立即连接。
第八步，显示配置信息。
第七步，完成配置，并启动。OK
配置远程监控步骤：
第一步，在监控端安装windows版的jprofiler5，由于服务也是windows操作系统，在服务器端安装windows版的jprofiler5。第二步，在监控端配置，点击NEW SESSION，选择New Remote Integration，如下图：
选择On a remote computer,选择Platform. if the remote computer（一般为被监控机器的类型），点击NEXT。
第三步，输入被监控机器的IP，如下图，点击NEXT。
第四步，输入被监控机器中，jprofiler的安装位置(如：D:\Program Files\jprofiler5)，点击NEXT。
第五步，选择JVM的类型和版本，其他默认，点击NEXT。
第六步，JProfiler监听的端口，使用默认值即可，点击NEXT。
第七步，选择启动模式，选择第一个，点击NEXT。
第八步，显示待修改的信息，将此信息copy出来，待配置被监控的机器时用。
第九步，完成配置，选择第二项，不立即连接。
第十步，在被监控的服务器端，修改服务启动文件，如果服务为TOMCAT，将startup.bat文件中的JAVA_OPTS的后面添加第八步中copy出来的内容：-agentlib:jprofilerti=port=8849 "-Xbootclasspath/a:D:\Program Files\jprofiler5\bin\agent.jar"
保存此文件。
第十一步，在环境变量PATH中添加第八步中copy出来的内容：
D:\Program Files\jprofiler5\bin\windows（注意前面加分号）。
第十二步，在被监控端，启动startup.bat，提示等待连接的信息，在监控端，选择要连接的SESSION，点击START，在下一出现的页面，点击OK，连接成功，被监控端的服务启动，待启动完成后，监控端能显示对方服务的内存、CPU等占用情况。
监控资源的配置
另外特别注意的是，在SESSION配置页面，要添加被监控的资源或CLASS这样才有实际意义，
常出现的问题
1. JVM出了bug报告，开始不知道怎么回事，耽误了很多时间，其实就是参数冲突）。还有一个个性配置信息就是要有一个叫LD_LIBRARY_PATH的环境变量，那我就修改了catalina.sh，在里面加入export LD_LIBRARY_PATH=D:\Program Files\jprofiler5\bin\windows。 (转)2. 有时也要将Jprofiler安装目录下bin下的jprofiler.vmoptions文件中的虚拟内存适量的改小。
JProfiler连接Weblogic (转)
http://www.ej-technologies.com/
1.本地连接1.1环境说明
本地安装JProfiler，Weblogic相关工具,相关破解可以在网上找到.
1.2步骤说明
1.打开工具JProfiler后,在Session菜单下选择New windows,弹出Quickstart窗口界面,在该界面选择第三项An application server, locally or remotely,然后点击Next.
2.进入Integration wizard界面,选择应用服务的类型和版本.此处,我们选择BEA Weblogic 8.1,然后点击Next.
3.选择连接的类型,是本地还是远程,这里我们选择本地(on this computer),然后点击Next.
4.选择Weblogic的启动文件Startweblogic.cmd,然后点击Next.
5.选择JDK的提供厂商和其版本.这里我们选择了Sun Microsystems的1.4版,然后点击Next.
6.选择两种处理模式,这里选择第一种,符合应用服务(JIT/hotspot complation enabled)
7.选择JProfiler的使用端口,对于本地连接来说,此处作用不大,用默认即可
8.选择第一个,启动weblogic时,试图去连接本次建立的连接,一直会等待到成功连接,而选择第二个,若是发现weblogic没有启动,将不做等待这里我们选择第一项.
9.对前面设置的内容统一展现,若是检查没有问题,则点击Next,进行下一步操作.
10.点击Finish,完成了本次连接的配置,若是选择了马上连接,则下一步开始连接.
11.这里对配置好的连接进行设置,根据需要可以进行过虑等设置,完成后点击OK.
12.开始连接本地的weblogic应用,连接成功后,可以得到相关的信息
附:
JProfiler.v4.2.2+注册机JProfiler是一个全功能的Java剖析工具（profiler），专用於分析J2SE和J2EE应用程式。它把CPU、线程和记忆体的剖析组合在一个强大的应用中。JProfiler可提供许多IDE整合和应用服务器整合功能。JProfiler直觉式的GUI让你可以找到性能瓶颈、抓住内存泄漏(memory leaks)、并解决多线程的问题。它让你得以对heap walker作资源回收器的root analysis，可以轻易找出内存泄漏；heap快照（snapshot）模式让未被引用（reference）的对象, 稍微被引用的对象、或在终结（finalization）序列的对象都会被移除；整合精灵以便剖析瀏览器的Java外掛功能。
下载地址:
http://download.ej-technologies.com/jprofiler/jprofiler_windows_4_2_2.exe
解密过程:
将EJ[1].Technologies.JProfiler.v4.2.2.Incl.Keymaker-AGAiN压缩包中的jkgone.jar解压到
根目录或其它目录下运行如下命令.
java -jar jkgone.jar附其它版本的注册码
http://download.ej-technologies.com/jprofiler/jprofiler_windows_3_3_1.exe
JProfiler 4.0
Name and Company: anything s/n: A-G666#76114F-1olm9mv1i5uuly#0126JProfiler 3.3.1
s/n: A-XiV7#20128F-1nf9r2z1qepp2e#7120EJ Technologies JProfiler 2.2.1
S/N: A-DWP#OWNZ#YOU-212hyrJProfiler 3.3
S/N: A-XiV6#62267F-1tfbcghardqqd#16312<br>JProfiler 3.2.0
S/N: A-GAiN#91584F-vd0mmz13mkf00#181013<br>or<br>A-GAiN#22031F-1giul8u16x7p65#121218<br>or<br>A-GAiN#98900F-1j62dw18rpusn#111117<br>JProfiler 3.2
S/N: A-GAiN#70503F-l7qte9gtq77c#81111<br>or<br>A-GAiN#19132F-y2fnayai9yu8#141420<br>
目前最新版为4.3,大家可以申请试用10天,如果大家还需要其它版本的注册码回复Jprofiler 5.1.2
下载地址:http://www.ej-technologies.com/download/jprofiler/files.php
官方试用版下载:
http://www.ej-technologies.com/download/jprofiler/trial.php .
-
常用的性能测试方法和测试要点
2008-12-16 13:58:04
常用的性能测试方法和测试要点
1、明确用户的性能需求（显示的和隐式的），性能测试点，找出瓶颈
1）用户直接需求的和使用过程中（行业经验）可能遇到的性能瓶颈点必须测试和分析到。当然，客户不需要的，也没有必要去花时间和精力。
2）从中获取相应的性能测试参数，峰值和平均值。
3）客户的性能容忍度和系统所能承受的容忍度同样重要。
4）确认系统运行的最低硬件环境要求（虽然硬件便宜的多了，但客户能不能改造自己的环境还得客户说了算）
5）如果可以的话，将系统的容错性做为性能测试的一部分进行测试
2、测试对象和性能负载分布
1）基本的3个对对像：C/S、B/S中的客户端和服务器，其中还有网络进行连接或中间件。
2）服务端可能分为数据端、业务端和服务容器。
3）跟据实际的测试结果合理的进行相应的性能负载分布。
3、负载、容量和压力测试逐一进行（如果需要）
1）更多的情况下，性能测试中出现的问题是最初的设计时应存在的问题。如果可能，建议对相应的性能提前做测试和优化。
2）够用就好，不是所有的系统都要进行性能测试，一切以客户需求和实际需要为准。
4、测试点
1）CPU和内存使用（系统自身的原因）。是否可以正常的使用和释放，是否存在内存溢出。
2）访问的速度（客户需求或是实际的应用要求说了算）
3）网络。网络传输速度，网络传输丢包率。（找些工具，有免费的）
4）服务器。指令、服务应答响应时间，服务器对信息处理的时效性，服务器对峰值的处理（建议进行服务器优化或是进行服务负载均衡，有大量的文档对此进行描述）
5）中间件。中间件在信息传递中的处理性能及信息处理的正确性。
5、测试和监控数据
1）均值下的持续运行（通过分析对整体的性能进行预测和评估）
2）短时间的峰值运行（分析系统的处理能力）
3）最低配置和最佳配置下的性能对比
4）多用户。同时访问，同时提交。
5）对 4 中的数据进行记录和监控
6、选择测试工具
现有的测试工具太多了，不在一一列举。
适用就好，推荐开源的工具。
-
测试用例的有效维护
2008-12-15 11:11:30
开发一个软件产品，会发布多个版本，伴随着测试用例（Test case）的不断维护, 使测试用例不断完善并与产品功能、特性(features)的变化保持一致，所以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品，多个版本常常共存，为客户提供服务，这时多个版本的测试用例也是并存的，所以在新建、修改、删除测试用例时要十分小心，并有相应的规则。根据产品特性和test case一致性，分下面几种情况分别处理：
1. 产品特性没变，只是根据Late Discovery Bug 或 Remedy Ticket 来完善 test case，只有这时候可以修改Test case, 也就意味着当前修改的test case，对目前和以前的版本都有效。
2. 原有产品特性发生了变化，不是new feature, 而是enhanced features（功能增强）, 这时候原有的 test case 只对先前版本（如version 1.0、2.0) 有效，而对新的版本（如 version 3.0)无效，这时绝不能修改 test case ，只能增加新的 test case，这一点很重要。原有的 test case 依然对原有版本有效（如version 1.0、2.0)。
3. 原有功能取消了，这时只要在新版本上使之对应的test case置为inactive（无效）。
4. 完全新增加的特性，大家比较清楚，增加对应的、新的测试用例。
这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几、十几倍的增加，可以真正保证 test case 的完整性、有效性！
-
性能测试（并发负载压力）测试分析－简要篇 (摘取)
2008-12-12 11:03:35
性能测试（并发负载压力）测试分析－简要篇
在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。分析原则：
• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
• 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
• 分段排除法 很有效
分析的信息来源：
•1 根据场景运行过程中的错误提示信息
•2 根据测试结果收集到的监控指标数据
一．错误提示分析
分析实例：
1 •Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection
•Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely
分析：
•A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题）
•B、应用服务没有死
（应用服务参数设置问题）
例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
•C、数据库的连接
(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)
2 Error: Page download timeout (120 seconds) has expired
分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多
二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(out of memory errors)
处理器：
1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
合理使用的范围在60%至70%。
2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU)
过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time)
磁盘I/O：
1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(large disk queue length)
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)
4．数据库服务器：
SQL Server数据库：
1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
Oracle数据库：
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率：
select(sum(pins-reloads))/sum(pins) from v$librarycache;
select(sum(gets-getmisses))/sum(gets) from v$rowcache;
自由内存： select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
缓冲区高速缓存命中率：
select name,value from v$sysstat where name in (’db block gets’,
‘consistent gets’,'physical reads’) ;
Hit Ratio = 1-(physical reads / ( db block gets consistent gets))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况 ：
select name,value from v$sysstat where name = ‘redo log space requests’ ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
内存排序命中率 ：
select round((100*b.value)/decode((a.value b.value), 0, 1, (a.value b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’
注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。
-
软件测试计划(转贴)
2008-12-06 14:10:07
测试计划
1引言
1.1编写目的
本测试计划的具体编写目的，指出预期的读者范围。1.2背景
说明：a． 测试计划所从属的软件系统的名称；
b． 该开发项目的历史，列出用户和执行此项目测试的计算中心，说明在开始执行本测试计划之前必须完成的各项工作。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。1.4参考资料
列出要用到的参考资料，如：a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2计划
2.1软件说明
提供一份图表，并逐项说明被测软件的功能、输入和输出等质量指标，作为叙述测试计划的提纲。2.2测试内容
列出组装测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的，例如模块功能测试、接口正确性测试、数据文卷存取的测试、运行时间的测试、设计约束和极限的测试等。2.3测试1（标识符）
给出这项测试内容的参与单位及被测试的部位。2.3.1进度安排
给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境。培训、准备输入数据等）。2.3.2条件
陈述本项测试工作对资源的要求，包括：a． 设备所用到的设备类型、数量和预定使用时间；
b． 软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件，如测试驱动程序、测试监控程序、仿真程序、桩模块等等；
c． 人员列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数。技术水平及有关的预备知识，包括一些特殊要求，如倒班操作和数据键入人员。
2.3.3测试资料
列出本项测试所需的资料，如：a． 有关本项任务的文件；
b． 被测试程序及其所在的媒体；
c． 测试的输入和输出举例；
d． 有关控制此项测试的方法、过程的图表。
2.3.4测试培训
说明或引用资料说明为被测软件的使用提供培训的计划。规定培训的内容、受训的人员及从事培训的工作人员。2.4测试2（标识符）
用与本测试计划2.3条相类似的方式说明用于另一项及其后各项测试内容的测试工作计划。3测试设计说明
3.1测试1（标识符）
说明对第一项测试内容的测试设计考虑。3.1.1控制
说明本测试的控制方式，如输入是人工、半自动或自动引入、控制操作的顺序以及结果的记录方法。3.1.2输入
说明本项测试中所使用的输入数据及选择这些输入数据的策略。3.1.3输出
说明预期的输出数据，如测试结果及可能产生的中间结果或运行信息。3.1.4过程
说明完成此项测试的一个个步骤和控制命令，包括测试的准备、初始化、中间步聚和运行结束方式。3.2测试2（标识符）
用与本测试计划3.l条相类似的方式说明第2项及其后各项测试工作的设计考虑。4评价准则
4.1范围
说明所选择的测试用例能够接查的范围及其局限性。4.2数据整理
陈述为了把测试数据加工成便于评价的适当形式，使得测试结果可以同，已知结果进行比较而要用到的转换处理技术，如手工方式或自动方式；如果是用自动方式整理数据，还要说明为进行处理而要用到的硬件、软件资源。4.3尺度
说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。 -
测试用例设计应该具备的描述信息(转贴)
2008-12-06 12:04:39
测试用例设计应该具备的描述信息
Test Case ID:
用来标记测试用例的编号，这个编号必须是唯一的
测试描述:
用来描述你将要进行的测试是怎样实施的
修订历史:
为了明确测试用例由谁创建或者修改，所以每个测试用例都应该有其修订历史
功能模块:
测试功能模块的名字
测试环境:
用来描述你的测试环境，当然包括硬件环境和软件环境
测试准备:
测试之前除了你所测试的程序之外还应该准备的东西，如打印机，网络等等
测试执行:
用来详细描述你的测试步骤
期望结果:
The descrīption of what you expect the function to do.描述该功能所要实现怎样的结果
实际结果:
通过/失败
如果成功——纪录实际运行的过程
如果失败——描述你观察到的现象，这将有利于发现Bug的起源
一个很好的测试所应具有的特征:
发现Bug的几率很大
没有多余
不是太简单也不会太复杂
Ps.当你的期望结果有很多的时候，测试用例就会变得很复杂
-
测试报告文档
2008-12-06 11:59:00
1.引言
本文档为**的系统测试活动给出一个总结报告，该报告用于评估系统测试活动的质量和产品的质量，并且决定是否把产品发布给最终用户。
2.测试时间，地点和人员
测试时间：
地点：
测试人员：
3.测试环境描述
（测试系统的软硬件配置）
4.测试数据度量
4.1测试用例执行度量
测试对象 用例总数 执行总数 OK项 POK项 NG项 NT项 发现缺陷数 系统功能 系统性能 系统GUI规范 系统可安装姓 合计 4.2 测试进度和工作量度量
1.进度度量
进度度量参考表22.3
表22.3进度度量
任务 计划开始时间 计划结束时间 实际开始时间 实际结束时间 环境准备 系统测试执行及 回归 系统测试报告 系统测试报告评审 2.工作量度量
工作量度量参考表22.4
表22.4工作量度量
执行任务 开始时间 结束时间 工作量/时 4.3 缺陷数据度量
缺陷数据度量参考表22.5
表22.5 缺陷数据度量
（饼图显示缺陷的比例情况）被测对象 总数 致命 严重 一般 提示 设计错误 赋值错误 算法错误 接口错误 功能错误 其他 系统功能 系统性能 系统GUI规范 合计 -
这一年,我们不裁员,不减薪!
2008-12-02 16:06:49
这一年,我们不裁员,不减薪!
面对金融危机,企业要有社会责任,员工要顾全大局,为企业渡过难关;
我们不需要得到什么,我们只想把社会的资金最大化,
我们要懂得节约,我们时刻准备着..
我们都需要感恩..没有任何人是没有任何困难..但我们能做到的有几多?
我们不要做无知者.我们需要知道更多的真相..
其实..危机早就为我们埋下伏笔...
只是我们不愿意接受事实...
当危机最大化的时候...
我们解决问题更加有难度..
其实...只要我们齐心协力...
没有什么办不到...
更应该唤醒我们的团结..
没有社会的稳定...拥有世间最大的财富..又有何意义?
经济危机的来临...我们都要共同面对和解决.... -
从编码方面提高网站性能的手段
2008-11-27 16:27:57
从编码方面提高网站性能的手段
一、缓存
缓存是ASP.NET中提高性能的重要手段，缓存一般遵循以下原则：
1） 在页面中将静态内容与动态内容分割开来
考虑将动态内容作成用户控件
2） 缓存合理的数据
一般应当缓存应用程序集的数据、多个用户共同使用的数据、静态数据、生成数据需要很大开销的动态数据、DataSet以及自定义对象等。不要缓存数据库连接对象、DataReader。
3） 选择适当的方式
如可以使用页面缓存指令，API等。
二、视图状态
视图状态放在页面中名为_VIEWSTATE的表单隐藏域里面，随页面一起被发送到客户端，在用户提交页面时，又被提交到服务器。
1） 如果不需要视图状态，则禁用
视图状态默认是允许的，如果页面不进行PostBack，如果不处理服务器控件的事件，如果服务器控件的数据每次都需要重新计算等
2） 尽量减少视图状态中存放的对象
三、 关于页面处理（减少页面生成的时间和过程）
1） 应尽量减少页面文件的大小
2） 通过检测Page.IsPostBack减少代码执行的数量
3） 禁止使用Debug=“true”，减少页面生成过程中生成额外的调试信息
4） 使用Server.Transfer而不使用Response.Redirect，减少服务器和客户端间的往返
5） 尽量使用客户端验证，减少服务器和客户端间的往返
6） 在适当的场合使用服务器控件
7） 尽量避免嵌套的服务器控件
四、 避免使用Page.DataBind和DataBinder.Eval
五、 关于Application对象和Session对象
1） 使用静态属性存储数据而不使用Application对象，在Application对象里存储只读类型的数据都将回提高性能
2） 尽量使用InProc模式的Session，这个模式是最快的
3） 在Session里存储基本类型的数据减少序列化的所消耗的资源
4） 如果不用Session变量，使用EnvableViewState=“false”禁用
5） 如果不修改Session变量的值，尽量使用ReadOnly属性设置
六、 关于字符串操作
1） 尽量使用Response.Write将结果输出到浏览器，这种方法是最快的。不要将字符串连接在一起一次输出。
2） 在字符串短并且少的情况下可以使用String.Concat方法，而在字符串长度未知，并且字符串大的情况下，使用StringBuilder对象
3） 不要使用strVar==“”来判断字符串是否为“”，这样它会创建额外的字符串，请使用strVar==String.Empty代替或者使用strVar.Length==0来判断
4） 请使用String.Compare方法进行字符串的比较
七、 关于数据访问
1） 尽量使用存储过程返回数据，不要直接在代码中进行查询
2） 在数据库中只返回有用的数据结果，不要选择不使用的数据字段
3） 进行使用DataReader进行数据绑定，DataReader是单向只读的
4） 尽量一次返回多个数据集而不是每个记录集分别打开一次数据库连接进行查询
5） 尽量晚的打开数据库，尽量早的关闭数据库
6） 使用连接池提高性能
7） 使用ExecuteNonQuery方法执行不返回数据的操作，使用ExecuteScalar方法返回单个结果的操作，使用Commandbehavīor.Sequentialaccess返回二进制数据或者大数据
8） 如果多次相同的查询，请使用Command.Prepare方法
9） 使用GetOrdinal方法预先得到索引值，使用索引值比使用字符串的列名查询数据效率更高
八、 关于代码优化
1） 在解析基本数据类型时，使用Try方法如果解析失败，会抛出异常，使用TryParse方法则只执行Else下的语句。
2） 使用AppendAllText、WriteAllBytes等方法读写文件内容可以优化性能
3） 将循环判定条件放在for语句外
4） 避免在循环里创建对象
5） 尽量减少装箱的次数
6） 不要使用例外控制程序的流程
7） 在循环中不要使用不变的对象属性或者字段
8） 使用for循环代替foreach循环遍历结合内容
9） 数组是所有集合中最快的，如果没有特殊需要，尽量使用数组代替集合
10） 了解各个集合类型的特性，选择合适的类型
11） 使用泛型避免减少装箱、拆箱
-
如何写性能测试用例
2008-11-27 16:20:36
如何写性能测试用例
由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。
性能测试的目的：
为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。性能测试指标的来源：
用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）主要的性能指标：
服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。BUG观点：
1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）；
2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）；
3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）。HTTP观点：
1、 负载测试是正常情况下持续的加压；
2、 压力测试是直接加压达到一个极限值。大家统一的观点：
性能测试、压力测试、负载测试密不可分，可统称为性能测试。性能测试要点：
1、 性能测试是在功能测试完成之后进行。
2、 性能测试计划、方案一般与测试用例统一在一个文档里。
3、 测试环境应尽量与用户环境保持一致。
4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。
5、 性能测试的重点在于前期数据的设计与后期数据的分析。
6、 性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。） -
LoadRunner参数化
2008-11-22 08:49:48
LoadRunner参数化
一、关于参数的定义
函数中参数的值就是在录制过程中输入的实际值。
例如，你录制了一个 Web 应用程序的脚本。脚本生成器生成了一个声明，该声明搜索名称为 “软件测试” 的图书的数据库。当你用多个虚拟用户和迭代回放脚本时，也许你不想重复使用相同的值“ 软件测试”，还需要其他的值如“项目管理” 。例如平常经常用到的，登陆界
面输入用户名和密码，那么，你就可以用参数来取代这个常量。结果就是你可以用指定的数据源的数值来取代参数值。数据源可以是一个文
件，也可以是内部产生的变量。
用参数表示用户的脚本有两个优点：① 可以使脚本的长度变短。② 可以使用不同的数值来测试你的脚本。例如，如果你企图搜索不同名称的图书，你仅仅需要写提交函数一次。在回放的过程中，你可以使用不同的参数值，而不只搜索一个特定名称的值。
参数化包含以下两项任务：① 在脚本中用参数取代常量值。② 设置参数的属性以及数据源。
参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。另外，不是所有的函数都可以参数化的
二、参数的创建
可以指定名称和类型来创建参数。不存在对脚本中参数个数的限制。在 Web 程序的用户脚本中，你可以使用如下过程在基于文本的脚本视图中创建参数。或者，也可以在基于图标的树形视图中创建参数。
在基于文本的脚本视图中创建一个参数：
1 、 将光标定位在要参数化的字符上，点击右键。打开弹出菜单。
2 、 在弹出菜单中，选择 “Replace with a Parameter” 。选择或者创建参数的对话框弹出。
3 、 在 “Parameter name” 中输入参数的名称，或者选择一个在参数列表中已经存在的参数。
4 、 在 “Parameter type” 下拉列表中选择参数类型
1）、 Date/Time Date/Time 用当前的日期 / 时间替换参数。要指定一个 Date/Time 格式，你可以从菜单列表中选择格式，或者指定你自己的格式。这个格式应该和你脚本中录制的 Date/Time 格式保持一致。你可以设置一个时间参数的偏移量，如果你打算测试下个月的日
期，你就可以选择偏移量为30。你也可以设置前偏移量和后偏移量，默认的是前偏移量。另外你可以命令vguen在工作日使用date值，不包括
周六和周日（没有明白这个的具体用处，明白的请告知）。
2 ）、 Group Name Group Name 用虚拟用户组名称替换参数。在创建 scenario 的时候，你可以指定虚拟用户组的名称。当从用户脚
本生成器运行脚本的时候，虚拟用户组名称总是 None 。
char *c =" {NewParam}"; //%05s
char *d="{NewParam_1}";//%07s
lr_log_message("group(5s) is %s,group(7s)is %s",lr_eval_string (c),lr_eval_string (d));
显示的结果为：group(5s)is 0None,group(7s)is 000None
3）. Iteration Number Iteration Number 用当前的迭代数目替换参数
设置迭代次数为3
char *c =" {NewParam}"; //%05s
char *d="{NewParam_1}";//%07s
lr_log_message("Iteration(5s) is %s,Iteration(7s)is %s",lr_eval_string (c),lr_eval_string (d));
结果为：Iteration(5s) is 00001,Iteration(7s)is 0000001
Iteration(5s) is 00002,Iteration(7s)is 0000002
Iteration(5s) is 00003,Iteration(7s)is 0000003
4）、 Load Generator Name Load Generator Name 用脚本负载生成器的名称替换参数。负载生成器是虚拟用户在运行的计算机。
5） 、 Random Number Random Number 用一个随机数替换参数。通过指定最大值和最小值来设置随机数的范围。
6）、 Unique Number Unique Number 用一个唯一的数字来替换参数。你可以指定一个起始数字和一个块的大小。
7 、 Vuser ID Vuser ID 用分配给虚拟用户的 ID 替换参数， ID 是由 Loadrunner 的控制器在 scenario 运行时生成的。如果你从脚本生成器运行脚本的话，虚拟用户的 ID 总是 -1
8、User-Defined Functions ―― 调用外部 DLL 函数生成的数据 ，函数必须是如下格式：
__declspec(dllexport) char *<functionName>(char *, char *) 例如：__declspec(dllexport) char *UF_GetVersion(char *x1, char*x2) {return "Ver2.0";}
9、table或file 从已存在的数据库中导入文件
可以使用下列两种方式之一：
1. 使用 Microsoft Query （要求在系统上先安装 MS Query ）。
2. 指定数据库连接字符串和 SQL 语句。
用户脚本生成器在从数据库中导入数据的过程中提供了一个向导。在向导中，你指明如何导入数据－通过 MS Query 创建查询语句或者直接书写 SQL 语句。在导入数据以后，以 .dat 为后缀并作为正规的参数文件保存。
要开始导入数据库中数据的过程，在参数属性对话框中点击“ Data Wizard ”，则，数据库查询向导弹出。
要创建新的查询
1. 选择“ Create new query ”。如果需要 MS Query 的帮助，选择“ Show me how to use Microsoft Query ”，然后点击“ Finish ”。
如果你还没有安装 Microsoft Query ， Loadrunner 会提示你这个功能不可用。在进行之前，从 Microsoft Office 中安装 MS Query 。
2. 在 Microsoft Query 中遵循以下步骤，导入期望的表和列。
3. 在完成数据的导入后，选择“ Exit and return to Virtual User Generator ”，然后点击“ Finish ”。在参数属性对话框中数据库记录以 data 文件的形式显示出来。
要在 MS Query 中编辑并查看数据，选择“ View data or edit in Microsoft Query ”。若要结束，则选择“ File>Exit and return toVirtual User Generator ”返回到脚本生成器。
4. 在“ Select Column ”部分，指定包含当前参数数据的列可以指定列号或者列名。注意：列标题默认为第 0 行（ row 0 ）。
5. 从“ Select next row ”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是： Sequential、 Random 、 Unique 或者 Same Line As 。
6. 如果选择“ Advance row each iteration ”，虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。
要指定数据库连接或者 SQL 语句
1. 选择“ Specify SQL Statement ”，然后点击“ Next ”。
2. 点击“ Create ”指定一个新的连接字符串。选择数据源的窗口弹出。
3. 选择已有的数据源，或者点击“ New ”创建一个新的数据源。向导将提示你穿过创建 ODBC 数据源的过程。在完成后，连接字符串就会在连接字符串框中显示出来。
4. 在 SQL 框中，输入或者粘贴 SQL 语句。
5. 点击“ Finish ”继续 SQL 语句并导入数据。数据库记录将以 data 文件的形式显示在参数属性框中。
6. 在“ Select Column ”部分中，指定包含当前参数数据的列。你可以指定列号或者列名。
7. 从“ Select next row ”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是： Sequential、 Random 、 Unique 或者 Same Line As 。
8. 如果选择“ Advance row each iteration ”，虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。
数据文件 数据文件包含着脚本执行过程中虚拟用户访问的数据。局部和全局文件中都可以存储数据。可以指定现有的 ASCII 文 件、用脚本生成器创建一个新的文件或者引入一个数据库。在参数有很多已知值的时候数据文件非常有用。数据文件中的数据是以表的形式存储的
。一个文件中可以包含很多参数值。每一列包含一个参数的数据。列之间用分隔符隔开，比如说，用逗号。 对数据文件设置参数属性
如果使用文件作为参数的数据源，必须指 定以下内容：文件的名称和位置、包含数据的列、文件格式，包括列的分隔符、更新方法。
如果参数的类型是“ File” ，打开参数属性（ Parameter Properties ）对话框，设置文件属性如下：
1 、 在 “File path” 中输入文件的位置，或者点击 “Browse” 指定一个已有文件的位置。缺省情况下，所有新的数据文件名都是“parameter_name.dat” ，注意，已有的数据文件的后缀必须是 .dat 。
2 、 点击 “Edit” 。记事本打开，里面第一行是参数的名称，第二行是参数的初始值。使用诸如逗号之类的分隔符将列隔开。对于每一新的表行开始一行新的数据。 注意：在没有启动记事本的情况下如果想添加列，就在参数属性对话框中点击“ Add Col” ，那么 “Add
new column” 对话框就会弹出。输入新列的名称，点击 “OK” 。脚本生成器就会添加该列到表中，并显示该列的初始值。
3 、 在 “Select Column” 部分，指明包含当前参数数据的列。你可以指定列名或者列号。列号是包含你所需要数据的列的索引。列名显示在每列的第一行（ row 0 ）。
4 、 在 “Column delimiter” 中输入列分隔符，你可以指定逗号、空格符等等。
5 、 在 “First data line” 中，在脚本执行的时候选择第一行数据使用。列标题是第 0 行。若从列标题后面的第一行开始的话，那就在“First data line” 中输入 1 。如果没有列标题，就输入 0 。
6 、 在 “Select next row” 中输入更新方法，以说明虚拟用户在脚本执行的过程中如何选择表中的数据。方法可以是：连续的、随机的、唯一的、或者与其它参数表的相同行。
6.1 、 顺序（ Sequential ）：该方法顺序地给虚拟用户分配参数值。如果正在运行的虚拟用户访问数据表的时候，它会取到下一行中可用的数据。
6.2 、 随机（ Random ）：该方法在每次迭代的时候会从数据表中取随机数
6.3 、 使用种子取随机顺序（ Use Random Sequence with Seed ）：如果从 Loadrunner 的控制器来运行 scenario ，你可以指定一个种子数值用于随机顺序。每一个种子数值在测试执行的时候代表了一个随机数的顺序。无论你何时使用这个种子数值，在 scenario 中同样的
数据顺序就被分配给虚拟用户。如果在测试执行的时候发现了一个问题并且企图使用同样的随机数序列来重复测试，那么，你就可以启动这
个功能（可选项）。
6.4 、 唯一（ Unique ）： Unique 方法分配一个唯一的有顺序的值给每个虚拟用户的参数。
6.5 、与以前定义的参数取同一行（ Same Line As ）：该方法从和以前定义过的参数中的同样的一行分配数据。你必须指定包含有该数据的列。在下拉列表中会出现定义过的所有参数列表。注意：至少其中的一个参数必须是 Sequential 、 Random 或者 Unique 。
如果数据表中有三列，三个参数定义在列表中： id1 ， name1 和 title1 ，如下：。
ID Name Title
132 Kim Manager
187 Cassie Engineer
189 Jane VP
对于参数 id1 ，你可以指示虚拟用户使用 Random 方法，而为参数 name1 和 title1 就可以指定方法 “Same Line as id1” 。所以，一旦 ID“132” 被使用，那么，姓名（ Name ） “Kim” 和职位（ Title ） “Manager” 同时被使用。
7 、 Updta value on 数据的更新方法
7.1 、 Each iteration ――每次反复都要取新值。
7.2 、 Each occurrence ――只要发现该参数就要重新取值。
7.3 、 Once ――在所有的反复中都使用同一个值
8 、 When out of values 超出范围：（选择数据为 unique 时才可用到）
8.1 、 Abort Vuser ――中止
8.2 、 Continue in a cyclic manner ――继续循环取值
8.3 、 Continue with last value ――取最后一个值
9 、 Allocate Vuser values in the Controller 在控制器中分配值：（选择数据为 unique 时才可用到） -
如何写软件性能测试用例
2008-11-22 08:39:59
由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。 性能测试的目的： 为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。 性能测试指标的来源： 用户对各项指标提出的明确需求;如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。(需求+经验) 主要的性能指标： 服务器的各项指标(CPU、内存占用率等)、后台数据库的各项指标、网络流量、响应时间。 BUG观点： 1、性能测试就象人在无风情况下跑步(正常情况下的性能指标); 2、压力测试就象人在微风中跑步(在正常的基础上加大多少百分比压力的性能指标); 3、负载测试就象人在强风中跑步(不断加压，直到系统崩溃)。 HTTP观点： 1、 负载测试是正常情况下持续的加压; 2、 压力测试是直接加压达到一个极限值。 大家统一的观点： 性能测试、压力测试、负载测试密不可分，可统称为性能测试。 性能测试要点： 1、 性能测试是在功能测试完成之后进行。 2、 性能测试计划、方案一般与测试用例统一在一个文档里。 3、 测试环境应尽量与用户环境保持一致。 4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。 5、 性能测试的重点在于前期数据的设计与后期数据的分析。 6、性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。(说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。)
-
怎样解决Java内存泄漏
2008-11-14 14:09:12
解决Java内存泄漏Java内存泄漏是每个Java程序员都会遇到的问题,程序在本地运行一切正常,可是布署到远端就会出现内存无限制的增长,最后系统瘫痪,那么如何最快最好的检测程序的稳定性,防止系统崩盘,作者用自已的亲身经历与各位分享解决这些问题的办法.
作为Internet最流行的编程语言之一,Java现正非常流行.我们的网络应用程序就主要采用Java语言开发,大体上分为客户端、服务器和数据库三个层次.在进入测试过程中,我们发现有一个程序模块系统内存和CPU资源消耗急剧增加,持续增长到出现java.lang.OutOfMemoryError为止.经过分析Java内存泄漏是破坏系统的主要因素.这里与大家分享我们在开发过程中遇到的Java内存泄漏的检测和处理解决过程.一. Java是如何管理内存
为了判断Java中是否有内存泄露,我们首先必须了解Java是如何管理内存的.Java的内存管理就是对象的分配和释放问题.在Java中,内存的分配是由程序完成的,而内存的释放是由垃圾收集器(Garbage Collection,GC)完成的,程序员不需要通过调用函数来释放内存,但它只能回收无用并且不再被其它对象引用的那些对象所占用的空间.
Java的内存垃圾回收机制是从程序的主要运行对象开始检查引用链,当遍历一遍后发现没有被引用的孤立对象就作为垃圾回收.GC为了能够正确释放对象,必须监控每一个对象的运行状态,包括对象的申请、引用、被引用、赋值等,GC都需要进行监控.监视对象状态是为了更加准确地、及时地释放对象,而释放对象的根本原则就是该对象不再被引用.
在Java中,这些无用的对象都由GC负责回收,因此程序员不需要考虑这部分的内存泄露.虽然,我们有几个函数可以访问GC,例如运行GC的函数System.gc(),但是根据Java语言规范定义,该函数不保证JVM的垃圾收集器一定会执行.因为不同的JVM实现者可能使用不同的算法管理GC.通常GC的线程的优先级别较低.JVM调用GC的策略也有很多种,有的是内存使用到达一定程度时,GC才开始工作,也有定时执行的,有的是平缓执行GC,有的是中断式执行GC.但通常来说,我们不需要关心这些.
二. 什么是Java中的内存泄露
导致内存泄漏主要的原因是,先前申请了内存空间而忘记了释放.如果程序中存在对无用对象的引用,那么这些对象就会驻留内存,消耗内存,因为无法让垃圾回收器GC验证这些对象是否不再需要.如果存在对象的引用,这个对象就被定义为"有效的活动",同时不会被释放.要确定对象所占内存将被回收,我们就要务必确认该对象不再会被使用.典型的做法就是把对象数据成员设为null或者从集合中移除该对象.但当局部变量不需要时,不需明显的设为null,因为一个方法执行完毕时,这些引用会自动被清理.
在Java中,内存泄漏就是存在一些被分配的对象,这些对象有下面两个特点,首先,这些对象是有被引用的,即在有向树形图中,存在树枝通路可以与其相连；其次,这些对象是无用的,即程序以后不会再使用这些对象.如果对象满足这两个条件,这些对象就可以判定为Java中的内存泄漏,这些对象不会被GC所回收,然而它却占用内存.
这里引用一个常看到的例子,在下面的代码中,循环申请Object对象,并将所申请的对象放入一个Vector中,如果仅仅释放对象本身,但因为Vector仍然引用该对象,所以这个对象对GC来说是不可回收的.因此,如果对象加入到Vector后,还必须从Vector中删除,最简单的方法就是将Vector对象设置为null.实际上这些对象已经是无用的,但还被引用,GC就无能为力了(事实上GC认为它还有用),这一点是导致内存泄漏最重要的原因. 再引用另一个例子来说明Java的内存泄漏.假设有一个日志类Logger,其提供一个静态的log(String msg),任何其它类都可以调用Logger.Log(message)来将message的内容记录到系统的日志文件中.
Logger类有一个类型为HashMap的静态变量temp,每次在执行log(message)的时候,都首先将message的值写入temp中(以当前线程+当前时间为键),在退出之前再从temp中将以当前线程和当前时间为键的条目删除.注意,这里当前时间是不断变化的,所以log在退出之前执行删除条目的操作并不能删除执行之初写入的条目.这样,任何一个作为参数传给log的字符串最终由于被Logger的静态变量temp引用,而无法得到回收,这种对象保持就是我们所说的Java内存泄漏. 总的来说,内存管理中的内存泄漏产生的主要原因：保留下来却永远不再使用的对象引用.
三. 几种典型的内存泄漏
我们知道了在Java中确实会存在内存泄漏,那么就让我们看一看几种典型的泄漏,并找出他们发生的原因和解决方法.
3.1 全局集合
在大型应用程序中存在各种各样的全局数据仓库是很普遍的,比如一个JNDI-tree或者一个session table.在这些情况下,必须注意管理储存库的大小.必须有某种机制从储存库中移除不再需要的数据.
通常有很多不同的解决形式,其中最常用的是一种周期运行的清除作业.这个作业会验证仓库中的数据然后清除一切不需要的数据.另一种管理储存库的方法是使用反向链接(referrer)计数.然后集合负责统计集合中每个入口的反向链接的数目.这要求反向链接告诉集合何时会退出入口.当反向链接数目为零时,该元素就可以从集合中移除了.
3.2 缓存
缓存一种用来快速查找已经执行过的操作结果的数据结构.因此,如果一个操作执行需要比较多的资源并会多次被使用,通常做法是把常用的输入数据的操作结果进行缓存,以便在下次调用该操作时使用缓存的数据.缓存通常都是以动态方式实现的,如果缓存设置不正确而大量使用缓存的话则会出现内存溢出的后果,因此需要将所使用的内存容量与检索数据的速度加以平衡.常用的解决途径是使用java.lang.ref.SoftReference类坚持将对象放入缓存.这个方法可以保证当虚拟机用完内存或者需要更多堆的时候,可以释放这些对象的引用.
3.3 类装载器
Java类装载器的使用为内存泄漏提供了许多可乘之机.一般来说类装载器都具有复杂结构,因为类装载器不仅仅是只与"常规"对象引用有关,同时也和对象内部的引用有关.比如数据变量,方法和各种类.这意味着只要存在对数据变量,方法,各种类和对象的类装载器,那么类装载器将驻留在JVM中.既然类装载器可以同很多的类关联,同时也可以和静态数据变量关联,那么相当多的内存就可能发生泄漏.四. 如何检测和处理内存泄漏
如何查找引起内存泄漏的原因一般有两个步骤:第一是安排有经验的编程人员对代码进行走查和分析,找出内存泄漏发生的位置;第二是使用专门的内存泄漏测试工具进行测试.
第一个步骤:在代码走查的工作中,可以安排对系统业务和开发语言工具比较熟悉的开发人员对应用的代码进行了交叉走查,尽量找出代码中存在的数据库连接声明和结果集未关闭、代码冗余等故障代码.
第二个步骤:就是检测Java的内存泄漏.在这里我们通常使用一些工具来检查Java程序的内存泄漏问题.市场上已有几种专业检查Java内存泄漏的工具,它们的基本工作原理大同小异,都是通过监测Java程序运行时,所有对象的申请、释放等动作,将内存管理的所有信息进行统计、分析、可视化.开发人员将根据这些信息判断程序是否有内存泄漏问题.这些工具包括Optimizeit Profiler,JProbe Profiler,JinSight , Rational 公司的Purify等.
4.1检测内存泄漏的存在
这里我们将简单介绍我们在使用Optimizeit检查的过程.通常在知道发生内存泄漏之后,第一步是要弄清楚泄漏了什么数据和哪个类的对象引起了泄漏.一般说来,一个正常的系统在其运行稳定后其内存的占用量是基本稳定的,不应该是无限制的增长的.同样,对任何一个类的对象的使用个数也有一个相对稳定的上限,不应该是持续增长的.根据这样的基本假设,我们持续地观察系统运行时使用的内存的大小和各实例的个数,如果内存的大小持续地增长,则说明系统存在内存泄漏,如果特定类的实例对象个数随时间而增长(就是所谓的“增长率”),则说明这个类的实例可能存在泄漏情况.
另一方面通常发生内存泄漏的第一个迹象是：在应用程序中出现了OutOfMemoryError.在这种情况下,需要使用一些开销较低的工具来监控和查找内存泄漏.虽然OutOfMemoryError也有可能应用程序确实正在使用这么多的内存；对于这种情况则可以增加JVM可用的堆的数量,或者对应用程序进行某种更改,使它使用较少的内存.
但是,在许多情况下,OutOfMemoryError都是内存泄漏的信号.一种查明方法是不间断地监控GC的活动,确定内存使用量是否随着时间增加.如果确实如此,就可能发生了内存泄漏.
4.2处理内存泄漏的方法
一旦知道确实发生了内存泄漏,就需要更专业的工具来查明为什么会发生泄漏.JVM自己是不会告诉您的.这些专业工具从JVM获得内存系统信息的方法基本上有两种：JVMTI和字节码技术(byte code instrumentation).Java虚拟机工具接口(Java Virtual Machine Tools Interface,JVMTI)及其前身Java虚拟机监视程序接口(Java Virtual Machine Profiling Interface,JVMPI)是外部工具与JVM通信并从JVM收集信息的标准化接口.字节码技术是指使用探测器处理字节码以获得工具所需的信息的技术.Optimizeit是Borland公司的产品,主要用于协助对软件系统进行代码优化和故障诊断,其中的Optimizeit Profiler主要用于内存泄漏的分析.Profiler的堆视图就是用来观察系统运行使用的内存大小和各个类的实例分配的个数的.
首先,Profiler会进行趋势分析,找出是哪个类的对象在泄漏.系统运行长时间后可以得到四个内存快照.对这四个内存快照进行综合分析,如果每一次快照的内存使用都比上一次有增长,可以认定系统存在内存泄漏,找出在四个快照中实例个数都保持增长的类,这些类可以初步被认定为存在泄漏.通过数据收集和初步分析,可以得出初步结论:系统是否存在内存泄漏和哪些对象存在泄漏(被泄漏).
接下来,看看有哪些其他的类与泄漏的类的对象相关联.前面已经谈到Java中的内存泄漏就是无用的对象保持,简单地说就是因为编码的错误导致了一条本来不应该存在的引用链的存在(从而导致了被引用的对象无法释放),因此内存泄漏分析的任务就是找出这条多余的引用链,并找到其形成的原因.查看对象分配到哪里是很有用的.同时只知道它们如何与其他对象相关联(即哪些对象引用了它们)是不够的,关于它们在何处创建的信息也很有用.
最后,进一步研究单个对象,看看它们是如何互相关联的.借助于Profiler工具,应用程序中的代码可以在分配时进行动态添加,以创建堆栈跟踪.也有可以对系统中所有对象分配进行动态的堆栈跟踪.这些堆栈跟踪可以在工具中进行累积和分析.对每个被泄漏的实例对象,必然存在一条从某个牵引对象出发到达该对象的引用链.处于堆栈空间的牵引对象在被从栈中弹出后就失去其牵引的能力,变为非牵引对象.因此,在长时间的运行后,被泄露的对象基本上都是被作为类的静态变量的牵引对象牵引.总而言之, Java虽然有自动回收管理内存的功能,但内存泄漏也是不容忽视,它往往是破坏系统稳定性的重要因素.
标题搜索
我的存档
数据统计
- 访问量: 198739
- 日志数: 282
- 图片数: 5
- 建立时间: 2008-01-30
- 更新时间: 2012-02-06
