将BUGZILLA繁体中文语言包转换为简体中文的方法

使用软件“GB/BIG5/UTF-8 文件编码批量转换程序”进行转换。
  软件版本：1.3
  编译日期：2006/06/15
  程序作者：阿勇(fxy_2002@163.com)
  作者主页：WWW.PC-SOFT.CN

UTF-8 -> BIG5 -> GB -> UTF-8

从事软件测试快1年了，各方面的书籍和知识也看了不少，实践却不是很多，虽然学了不少非测试的知识，对软件工程也算有了比较清晰的认识，但对于把测试作为主要学习对象的我来说。测试上的技术还远远不够，测试工具的使用有待进一步的加强。所以，这里也把一些知识总结一下，方便自己以后查询和复习。

1.介绍

软件性能：是一种指标，是参考一定标准的表现，表明软件系统或构件对于其及时性要求的符合程度，即在相应的硬件和软件环境下，该软件系统应该达到的一个水平。另外，性能是一种特性，可以用时间和空间来进行度量。

3种角度看性能：（1）用户角度：直观印象，主要是从响应时间来看；（2）管理员角度：建立在响应时间基础上，要考虑系统状态如系统资源的利用率，系统的扩展性和系统的稳定性；（3）开发人员：主要从系统架构，数据库设计，代码的优化来看待。

2.主要关键词

响应时间：对请求作出响应所需要的时间。web的普遍标准是2/5/10秒，即2秒以内的客户响应被认为是“非常好非常吸引人”的，5秒内是“比较不错”的，10秒是能接受的上限。但是响应时间具有相对性，如：一个月才进行一次的操作，20分钟是一个可以接受的等待时间。即：具体环境具体判断。

用户并发数：主要取决于服务端和客户端的性能。对服务端来说，每个用户和服务断都是离散的，用比较形象的话来说，就是一群小孩对着一堵墙踢球，每个小孩都有一个球，具体多少个小孩，每个小孩每次对着墙踢球的时间是不确定的或有一定规律的。而墙能承受多少小孩踢球而不跨掉，便是一个用户并发数的问题。而对客户端来说，每个小孩踢球的时间都是根据自己的实际情况来决定的，即根据用户实际的业务场景来决定的。所以，系统的服务端能承受的最大并发访问数主要取决于并发用户数和业务场景，一般可以通过对服务器日志的分析可以得到。 并发数确定的理论公式：C=nL/T （C是平均的并发用户数，n是login session“用户从登陆系统到退出系统的时间段”，T是考察的时间段即用户可能使用系统的总时间段）C^＝C＋3根号C。

例如：一OA系统，该系统有200用户，每天大约100人访问系统，一天内用户从登陆系统到退出系统的平均时间是4小时，一天内，用户最多使用8小时。

那么可以得到C＝200*4/8＝100 （并发用户数）

C^=100＋3*根号100 （最大用户数）

吞吐量：单位时间内系统处理的客户请求的数量，主要体现软件系统的性能承载能力。

吞吐量的单位不定，可以是：请求数/秒，人数/天，业务数/小时……对于web系统来说，常用的是请求数（点击数）/秒或字节数/秒来体现

计算公式：F=N*R/T

F代表吞吐量，N代表Virtuae User的个数，R代表每个用户的请求数，T代表性能测试的时间

可以看到上列公式在图表里显示理论上是一根平滑的斜线，理论上随着用户数的请求数增加，时间也跟着增加，如果实际测试中。系统的性能出问题时，即用户数增加到一定数量，系统不能及时处理，此时，图表表现出来就会发生变化。

一般来说，2个不同的系统可能具有不同的用户数和用户使用模式，但如果具有基本一致的吞吐量，则可以说，他们具有基本相同的平均处理能力。

性能计数器（Counter）是描述服务器或操作系统性能的一些数据指标。例如，对windows操作系统来说，使用内存数，进程时间等都是常见的计数器。

思考时间：指用户在进行操作时，每个请求之间的间隔时间。

吞吐量/处理能力
处理能力又叫吞吐量，指的是单位时间内处理的客户端请求数量。通常情况下，吞吐量用请求数/秒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）网络设备上的性能瓶颈，一般指的是防火墙、动态负载均衡器、交换机等设备。例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其它负载较轻的应用服务器上。在测试时发现，动态负载均衡机制没有起到相应的作用，这时可以认为在网络设备上出现了性能瓶颈。

系统：       windows xp
所需软件： 1.openbravoERP-2.35-windows-installer
                2.oracleXE
                3.apache-tomcat-6.0.14
                4.jdk-6u2-windows-i586-p
                5.apache-ant-1.7.0-bin
安装步骤：
               1.先安装jdk-6u2-windows-i586-p（默认路径）
               2.安装apache-tomcat-6.0.14（默认路径）端口设置为8081
               3.安装oracleXE 端口8080
               4.安装apache-ant-1.7.0-bin直接以文件夹存放
               5.系统设置：
                      我的电脑——属性——高级——环境变量——用户变量（JAVA_HOME=java中jdk文件夹的路径；ANT_HOME=ant文件夹的路 径；CATALINA_HOME=tomcat文件夹的路径；CATALINA_OPTS=-server -Xms=512M -Xms=512M)——系统变量（classpath=.;java中jdk文件夹中lib文件夹中tools.jar;java中jdk文件夹中 lib文件夹中dt.jar）（path=java中jdk文件夹中的bin目录；ant中的bin目录）
              6.设置完毕后重启电脑
注：以上安装时使用默认路径是为了便于安装，路径可以更改。
              7.双击openbravoERP-2.35-windows-installer安装
              8.安装时编译时间有点长需要等待安装完毕后初始用户名：Openbravo  初始密码：openbravo

今天遇到了ant在编译java时候出现乱码问题，解决方法如下

1中文版本的 editplus 下操作的菜单结构如下: 文档->参数设置->文件->UTF-8签名->总是移除签名->确定
注意：要统一eclipse的编码。

在每种不同的系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。我们不可能对每种技术都详细解说，这里只是介绍一种方法提供给你如何选择测试策略，从而帮助分析软件不同部分的性能指标，进而分析出整体架构的性能指标和性能瓶颈。

     由于工程和项目的不同，所选用的度量,评估方法也有不同之处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。步骤如下

1．    制定目标和分析系统
2． 选择测试度量的方法
3． 学习的相关技术和工具
4． 制定评估标准
5． 测试环境建立

6． 设计测试用例

7． 运行测试用例

8． 分析测试结果

·制定目标和分析系统

   每一个性能测试计划中第一步都会制定目标和分析系统构成。只有明确目标和了解系统构成才会澄清测试范围，知道在测试中要掌握什么样的技术。   

目标：

1． 确定客户需求和期望

2． 实际业务需求

3． 系统需求

系统组成

   系统组成这里包含几方面含义：系统类别，系统构成，系统功能等。了解这些内容的本质其实是帮助我们明确测试的范围，选者适当的测试方法来进行测试。

   系统类别：分清系统类别是我们掌握什么样的技术的前提，掌握相应技术做性能测试才可能成功。例如：系统类别是bs结构,需要掌握http协议，java，html等技术。或者是cs结构，可能要了解操作系统，winsock，com等。所以甄别系统类别对于我们来说很重要。

   系统构成：硬件设置，操作系统设置是性能测试的制约条件，一般性能测试都是利用测试工具模仿大量的实际用户操作，系统在超负荷情形下运作。不同的系统构成性能测试就会得到不同的结果。

   系统功能：系统功能指系统提供的不同子系统，办公管理系统中的公文子系统，会议子系统等，系统工能是性能测试中要模拟的环节，了解这些是必要的。

·选择测试度量的方法

经过第一步，将会对系统有清醒的认识。接下来我们将把精力放在软件度量上，收集系统相关的数据。

度量的相关方面：

*制定规范

*制定相关流程,角色，职责

*制定改进策略

*制定结果对比标准

·学习的相关技术和工具

     性能测试是通过工具，模拟大量用户操作，对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过winsock,http等协议纪录用户操作。而协议选择是基于软件的系统架构实现（web一般选择http协议,cs选择winsock协议），不同的性能测试工具，脚本语言也不同，比如rational robot中vu脚本用类c语言实现。

     开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软件架构的性能测试工具。确定测试工具后，需要组织测试人员进行工具的学习，培训相关技术。

·制定评估标准

        任何测试的目的都是确保软件符合预先规定的目标和要求。性能测试也不例外。所以必须制定一套标准。

     通常性能测试有四种模型技术可用于评估：

         *线性投射：用大量的过去的，扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况对比。

         *分析模型：用排队论公式和算法预测响应时间，利用描述工作量的数据和系统本质关联起来

         *模仿：模仿实际用户的使用方法测试你的系统

         *基准：定义测试和你最初的测试作为标准，利用它和所有后来进行的测试结果进行对比

 测试环境建立

1） 整个测试环境系统的安装；

2） Web层系统的部署；

3） App层服务的安装；

4） DB层数据库的备份和还原；

5） 整个系统部署安装完成后，需要对系统功能进行测试检查（可以围绕着测试范围来进行）

 设计测试用例

   设计测试用例是在了解软件业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可能发现软件的性能瓶颈。

   1．测试数据生成

对于数据生成的方法，我主要是编写SQL语句来完成，另外还可以使用一些辅助工具，例如：DataFactory。

大数据量的生成，要注意SQL语句的有效性，尽量减少数据生成时所需要的时间；另外在数据生成过程中，可以进行脚本的准备。

注意：在数据生成之前，要考虑数据库文件的数量，因为数据文件均匀分布对整个性能测试结果很有影响，这是我们的血泪经验。

 2．测试脚本准备

根据不同的测试工具，编写脚本的方式不一样，但是其流程大致是一样的：

录制—〉回放—〉一些数据的参数化、添加一些验证条件—〉回放

注意：参数化数据的随机性会影响性能测试结果；

 运行测试用例

  1．预测试

测试相关工作准备完成后，我们可以开始预测试了；

预测试的目的主要是优化和调整系统；它是一个反复迭代的过程；

2．性能优化和调整

性能优化和调整是整个性能测试工作的核心和关键；

主要根据测试过程中所得到的系统计数器值来判断系统瓶颈所在，这里需要一些经验；我对性能优化和调整的认识主要如下：

1） Web层，主要在于对IIS的优化；对于基于.NET Framewoek的Web站点，还可以修改相关的参数来进行优化；

2） App层，目前我们的系统都是在功能完成后才对系统进行性能测试的；所以我们对代码的优化工作机会为零，这是一个遗憾，但也是整个性能优化和调整的一大部分工作所在。

3） DB层，数据库层的性能优化是我们整个性能优化的核心，我们主要围绕着索引和存储过程来展开；这是一个相当漫长的一个过程，需要我们有耐心和毅力。

  3．正式测试

当预测试结果达到测试需求后，我们可以进行正式测试了；如果时间允许，我们可以进行进一步的性能优化和调整工作；但是实际上很多时候，我们没有这样的机会。

 通过性能测试工具运行测试用例。同一环境下作的性能测试得到的测试结果是不准确的，所以在运行这些测试用例的时候，需要用不同的测试环境，不同的机器配置上运行。

   ·分析测试结果

     运行测试用例后，收集相关信息，进行数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网络带宽，流量对用户操作响应的影响，而cs结构我们可能更关心会系统整体配置对用户操作的影响。

• 　　软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等
• 　　软件未达到产品说明书标明的功能。
• 　　软件出现了产品说明书指明不会出现的错误。
• 　　软件功能超出产品说明书指明范围。
• 　　软件未达到产品说明书虽未指出但应达到的目标。
• 　　软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

　　测试的主要方面：

　　一、功能测试

　　对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》，对于应用程序模块需要设计者提供基本路径测试法的测试用例。

　　1、链接测试

　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面：

　　1)测试所有链接是否按指示的那样确实链接到了该链接的页面;

　　2)测试所链接的页面是否存在;

　　3)保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

　　Xenu------主要测试链接的正确性的工具

　　可惜的是对于动态生成的页面的测试会出现一些错误。

　　2、表单测试

　　当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

　　要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

　　B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。

　　我们对UM子系统中各个功能模块中的各项功能进行逐一的测试，主要测试方法为：边界值测试、等价类测试，以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入，以确保测试输入的全面性。

　　3、Cookies测试

　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作而且对这些信息已经加密。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

　　4、设计语言测试

　　Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

　　5、数据库测试

　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

　　在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

二、性能测试

　　网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做的不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。

　　网站的性能测试主要从三个方面进行：连接速度测试、负荷测试(Load)和压力测试(Stress),

　　连接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃。

　　1、连接速度测试

　　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟)，用户就会因没有耐心等待而离开。

　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

　　2、负载测试

　　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线?如果超过了这个数量，会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

　　3、压力测试

　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

　　压力测试的区域包括表单、登陆和其他信息传输页面等。

　　采用的测试工具：

　　性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具

　　ab -----Apache 的测试工具

　　OpenSTA—开发系统测试架构

　　在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、

　　验证数据或提交订单。

　　1、 服务器接口

　　第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器

　　记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

　　2、 外部接口

　　有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行

　　为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

　　3、错误处理

　　最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错

　　误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况?

　　订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服

　　务器的连接。在这些情况下，系统能否正确处理这些错误?是否已对信用卡进行收费?如果

　　用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致

　　电用户进行订单确认。

四、可用性测试

　　可用性/易用性方面目前我们只能采用手工测试的方法进行评判，而且缺乏一个很好的评判基准进行，此一方面需要大家共同讨论。

　　1、导航测试

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。

　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。

　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

　　2、图形测试

　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

　　(1)要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

　　(2)验证所有页面字体的风格是否一致。

　　(3)背景颜色应该与字体颜色和前景颜色相搭配。

　　(4)图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

　　3、内容测试

　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

　　4、整体界面测试

　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

　　对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　对所有的可用性测试来说，都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与，最好是最终用户的参与。

五、兼容性测试

　　需要验证应用程序可以在用户使用的机器上运行。如果您用户是全球范围的，需要测试各种操作系统、浏览器、视频设置和 modem 速度。最后，还要尝试各种设置的组合。

　　1、平台测试

　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

　　2、浏览器测试

　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，Javascrīpt是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

　　采用测试工具：

　　通过白盒测试或者黑盒测试导出的测试用例，采用相应的工具进行测试，可以采用OpenSTA进行测试，此测试工具可以采用不同的浏览器进行测试。

　　3.视频测试

　　页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

　　4.Modem/连接速率测试

　　是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测

　　试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，

　　但却不会耐心等待首页的出现。最后，需要确认图片不会太大。

　　5、打印机测试

　　用户可能会将网页打印下来。因此网页在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

　　6、组合测试

　　最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容

　　机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。

　　如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，

　　那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。

　　(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能

　　在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，

　　系统能在所有机器上运行，这样就不会限制将来的发展和变动。

六、安全测试

　　Web应用系统的安全性测试区域主要有：

　　1、 目录设置

　　Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页

　　面，这样就不会显示该目录下的所有内容。如果没有执行这条规则。那么选中一幅图片，单击鼠标右键，找到该图片所在的路径"… com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。但是进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中有些都是已过期页面。如果该公司每个月都要更改产品价格信息，并且保存过期页面。那么只要翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。

　　2.登录

　　现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

　　3.Session

　　Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内(例如15分钟)没有点击任何页面，是否需要重新登陆才能正常使用。

　　4.日志文件

　　为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

　　5.加密

　　当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

　　6.安全漏洞

　　服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

　　目前网络安全问题日益重要，特别对于有交互信息的网站及进行电子商务活动的网站尤其重要。目前我们的测试没有涵盖网站的安全性的测试，我们拟定采用工具来测定，

　　工具如下

　　SAINT------- Security Administrator’s Integrated Network Tool

　　此工具能够测出网站系统的相应的安全问题，并且能够给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。

七、代码合法性测试

　　代码合法性测试主要包括2个部分：程序代码合法性检查与显示代码合法性检查。

　　1、程序代码合法性检查

　　程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，未来期望能够有相应的工具进行测试。

　　2、显示代码合法性检查

　　显示代码的合法性检查，主要分为Html、Javascrīpt、Css代码检查，目前采用

　　HTML代码检查------采用CSE HTML Validator进行测试

　　Javascrīpt、Css也可以在网上下载相应的测试工具。

　　八、 文档测试

　　l、产品说明书属性检查清单

　　1)完整.是否有遗漏和丢失，完全吗? 单独使用是否包含全部内容

　　2)准确.既定解决方案正确吗? 目标明确吗? 有没有错误?

　　3)精确、不含糊、清晰.描述是否一清二楚? 还是自说自话?容易看懂和理解吗?

　　4)一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突

　　5)贴切.描述功能的陈述是否必要?有没有多余信息? 功能是否原来的客户要求?

　　6)合理.在特定的预算和进度下,以现有人力,物力和资源能否实现?

　　7)代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码

　　8)可测试性.特性能否测试? 测试员建立验证操作的测试程序是否提供足够的信息?

　　2、 产品说明书用语检查清单

　　1)说明。 对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.

　　2)总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.

　　3)当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.

　　4)某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.

　　5)等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.

　　6)良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.

　　7)已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.

　　8)如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.

　　相关的测试工具

　　OpenSTA

　　主要做性能测试的负荷及压力测试，使用比较方便，可以编写测试脚本，也可以先行自动生成测试脚本，而后对于应用测试脚本进行测试。

　　SAINT

　　网站安全性测试，能够对于指定网站进行安全性测试，并可以提供安全问题的解决方案。

　　CSE HTML Validator

　　一个有用的对于HTML代码进行合法性检查的工具

　　Ab(Apache Bench)

　　Apache自带的对于性能测试方面的工具，功能不是很多，但是非常实用。

　　Crash-me

　　Mysql自带的测试数据库性能的工具，能够测试多种数据库的性能。

10万人主要集中在5个月的时间访问系统，再按2/8原则，计算系统访问量，

7款网站开发测试实用工具

通常在发布新的网站、添加新功能或者升级系统之前，都需要进行测试。对程序员、设计人员和生意人来说，最糟糕的一件事情就是登陆到一个无法使用的网站，这会赶走客户，损害公司的声誉，并会导致更多的工作、更多的头痛事以及更多的利润损失。

　　幸运的是，目前有很多用于网络开发测试的强大工具。这些工具可以测试所有你所需要的，从CSS确认到网站速度。所有网站的共同目标都是：确保用户和客户顺利地使用网站服务。使用下面这些工具可以作为网站开发过程的最后步骤。

　　1. WebSitePulse测试工具

　　网址：http：//www.websitepulse.com/

　　想要快速测试响应时间、文件尺寸以及链接数量吗？WebSitePulse测试工具提供了一系列快速易用的测试方法，可以给出从网站速度到链接错误等所有的情况。还提供文件大小、转移速度以及DNS的数目。

　　2. 多浏览器测试工具Xenocode Browser Sandbox

　　网址：http：//www.xenocode.com/browsers/

　　浏览器测试是网站开发中最乏味和令人沮丧的部分。设计人员和程序员在测试网站在IE6平台效果的时候经常会大呼小叫。浏览器测试中另一个困难的部分就是没有任何的开发人员能够在同一台计算机中拥有所有的浏览器来进行测试。

　　进入XenoCode Brower Sandbox，它可以同时虚拟所有的常用浏览器，而不需要安装软件。遗憾的是，XenoCode Browser Sandbox在某些浏览器中运行速度很慢，并且目前还没有Mac版本。

　　3. Firebug Firefox 扩展插件

　　网址：http：//getfirebug.com/

　　这是所有的程序员最喜欢的扩展软件，Firebug是测试前端代码和CSS的最好的调试软件。如果出现任何不符合格式的图像或类型，最好的解决办法就是用Firebug检查出来。甚至可以在里面改变样式来检查网站是如何在浏览器中的渲染效果。

　　4. Load Impact负载测试软件

　　网址：http：//loadimpact.com/

　　如果一个网站正在运行病毒、Digg、Twitter和StubleUpon，一次汇聚了多种应用程序，它能够承受这种负载吗？Load Impact可以帮助回答这个问题。它在网络服务器上模拟大量的用户下载，来决定该网站是否能够承受高流量负荷。该软件拥有一个免费版本和几个付费版本。

5. Safari Web Inspector

　　网址：http：//www.apple.com/safari/

　　苹果公司的Safari网络浏览器的其中一个亮点就是网络监测功能。Web Inspector，仅在打开开发面板之后才可使用，它能显示类型表单、图像、网页上的脚本。虽然如此，Web Inspector最实用的部分就是它的Network功能，该功能实时地显示文件和脚本从服务器转换到浏览器的命令和速度。可以使用这款软件找出哪个脚本、文件或图像在浏览器中占用最大的空间，然后进行调整。

　　6. Web Developer Firefox Extension

　　网址：https：//addons.mozilla.org/en-US/firefox/addon/60

　　Web Developer是一款健壮的Firebox 插件，当测试一个网站的时候，所有开发人员都要参与其中。它提供了广泛的测试，包括测试受损的图片，测试多重屏幕尺寸的布局，查看cookie信息以及验证标记。对Firefox用户来说它是最终的测试工具。

　　7. W3C 验证服务

　　W3C是所有网站验证的标准。W3C Validator以工业标准为基础，查看网站的标记并显示错误信息。它有多种语言和种类。 下面是一些重要的验证工具：

　　-W3C Markup Validation 网址： http：//validator.w3.org/

　　-W3C CSS Validation 网址：http：//jigsaw.w3.org/css-validator/

　　-W3C mobileOK Checker 网址：http：//validator.w3.org/mobile/

　　-W3C Link Checker 网址：http：//validator.w3.org/checklink

　　-W3C Feed Validation Service 网址：http：//validator.w3.org/feed/

　　这些工具都可以用来尽早地检测出Bug来保证网站稳定高速运行的。至少可以让开发人员意识到，除了对着IE6显示的糟糕页面大呼小叫之外，他们还有很多选择。

浮躁的国内测试界－2006年测试人员招聘感悟

作者：陈大卫 来源：希赛网软件测试频道

我面试的测试应聘人员大多是有一定从业经验的测试人员，其中不乏优秀者，但是也有相当多的应聘人员反映出这样那样的问题，概括说来就是“浮躁”，具体拆解来看主要表现在以下几点。

一、根基不牢

问题：利用等价类划分的方法，对某问题设计测试用例。

分析：98%以上的应聘者只知道按照有效等价类和无效等价类进行划分，殊不知此种分类方法只是等价类划分的一个典型应用而已，等价类划分远非只能划分为有效和无效两类。根据种种划分依据，还可以进一步划分很多其他类别。

问题：根据事件描述，画出对应的因果图。

分析：标准答案中只画了“两条恒等，两条非，一个与，一个或”。如此简单的问题，上百名应聘者中竟然无一人答对，痛心啊。黑盒测试方法就那么几种，既然你已知这个名，怎么就不知道多看几眼。

★ 小结：

上面提到的是软件测试的最基本的方法，作为从业测试实际工作已经有1-2年的应聘人员，未能真正领悟，实属不应该，心浮气躁，忽视了你身边最简单，也是最厉害的技能。根基不牢，怎么可能把测试做深。

二、专业不精

问题：音视频文件都有哪些格式，这些格式之间有什么差别？

分析：此问题是问那些做过多媒体方面测试的，但是我们的应聘者向来都是拿来主义，别人给我什么媒体文件我就用什么做测试，而根本不管不问。“为什么MIDI文件比WAV文件小那么多？我们如何知道扩展名是.Mpeg的文件是Mpeg1格式的还是Mpeg2格式

1 如何用junit写测试？

1、创建一个TestCase的子类: 

1 ant中发送邮件

  <mail password="123" user="aaa" messagemimetype="text/html"  subject="Test sendmail" mailport="80" mailhost="mail.fulong.com.cn">
      <from address="aaa@fulong.com.cn"/>
   <to address="aaa@fulong.com.cn"/>
   <message>aaaaaaaaaaaaaaaa</message> 
   </mail>

注意：Ant发送邮件需要的相关支持包有：mail.jar和activation.jar
如果有错误，请确认这两个包是否已经存在于ant目录的lib中。

2 邮件服务器主机链接不上

nested   exception   is:   class   javax.mail.MessagingException:   Could   not   connect   to   SMTP   host:

原因，邮件服务器的端口号不对，邮件服务器的默认端口号是25.

3 判断资源文件是否存在

<?xml version="1.0" encoding="UTF-8"?>
<project name="testCondition">
    <path id="all.test.classes">        
         <pathelement location="bin"/>
     </path>
  <target name="mail">
 <mail   mailhost="pop.126.com "   mailport="25"   subject="Test   build">  
    <from   address="luojing_happy@126.com"/>  
    <to   address="luojing_happy@126.com"/>  
     <message>The   nightly   build   has   completed</message>  
 
  </mail> 
</target>
    <target name="test">
        <condition property="scondition">
            <available resource="TestTest.class">
                <classpath refid="all.test.classes" />       
            </available>
        </condition>
        <antcall target="isTrue"></antcall>
        <antcall target="isFalse"></antcall>       
    </target>
    <target name="isTrue" if="scondition">
     <antcall target="mail"/>

        <echo>is ture</echo>
    </target>
    <target name="isFalse" unless="scondition">
        <echo>is false</echo>
    </target>
</project>

持续集成 Java手册

一、概念

Martin Fowler的文章：Continuous Integration  中文翻译：持续集成

二、工具

传统工具：VisualStudio.Net，VisualSourceSafe，Rational ClearCase

自动编译工具：Ant

回归测试工具：JUnit

代码检查工具：CheckStyle

持续集成工具：CruiseControl

三、步骤

• CruiseControl监控远程版本控制系统的变化

• 变化发生时CruiseControl调用编译工具进行编译（Ant等）

• 编译成功后调用JUnit进行回归测试

• 编译成功后调用CheckStyle进行代码检查

• 完毕后将编译结果、测试结果、代码检查结果发送至开发人员、主管经理，并发布至网站，甚至报警器

    所有这一切都是按照编制好的脚本自动进行的

四、实施示例

目前我们使用的是ClearCase，主控软件为CruiseControl，其脚本文件为cccc.xml

• 配置远程版本控制系统

• 配置编译工具

• 配置测试用例（在ant的配置文件中）

• 配置报告形式

• 其中CruiseControl暂时没有提供代码检查工具的支持，建议使用Ant来调用CheckStyle，示例如下（没有真正运行过）：

五、几点提示

• CruiseControl会自动根据本地ClearCase的View监控远程VOB
• 其实除了监控远程版本控制系统外其它的任务都可以由Ant来完成，CC只负责监控变化并调用Ant即可
• 可以为cruisecontrol.bat加入启动参数“-port 8055”，这样可以用JMX（http://localhost:8055）来控制cc
• 最好避免中文路径，否则就需要手工为几个Xml格式的文件，如cc的report Servlet的Web.xml等加入编码方式“<?xml version="1.0" encoding="UTF-8" ?> ”，或者将中文路径映射为虚拟硬盘：“subst Y: "D:/cc_view/chelsea/Platform/开发/Nucleus2.0/Source"”
• 中文log无法正常显示时，需要设置CruiseControl配置文件中<log>元素的“encoding”属性，如：
  <log dir="D:/Tomcat 4.1/webapps/cruisecontrol/samplelogs" encoding="utf-8">

    <merge dir="D:/cc_view/chelseafc/Nucleus2.0/Port/test-results" />

  </log>
• 编译失败后，在下次checkin之前，一般不需要重新编译，这时可设置<project >的“buildafterfailed”属性为false来避免重新编译
• <htmlemail>的几个属性好像没有缺省设置，虽然文档里说从2.1.7开始有缺省设置，包括xsldir，css，logdir
• 各种工具的安装、使用，在各自的文档里都非常详细，网上亦有无数资源

六、参考资料

• DailyBuild全攻略
• Draco.Net
• 持续集成.Net手册

<?xml version="1.0" encoding="UTF-8"?>
<project name="MultiLogin" default="compile" basedir=".">
 <property name="webapp.name" value="MultiLogin" />
 <!-- tomcat的安装路径-->
 <property name="catalina.home" value="D:\MySoft\Tomcat 6.0" />
 <!--src.dir  :原文件路径 -->
 <property name="src.dir" value="src" />
 <!-- 编译所需要的jar包的存放目录-->
 <property name="lib.dir" value="${basedir}/WEB-INF/lib" />
 <!--build.classes:class 文件 存放目录 -->
 <property name="class.dir" value="${basedir}/WEB-INF/classes" />
 <!-- tomcat 的应用发布路径-->
 <property name="webapps.dir" value="${catalina.home}/webapps" />
 <!-- jsp 页面文件-->
 <property name="ui.dir" value="admin" />
 <!-- **********************************set classpath********************************** -->
 <!-- 设置环境变量，把编译所需要的jar包引入-->
 <path id="compile.classpath">
  <fileset dir="${catalina.home}/lib">
   <include name="*.jar" />
  </fileset>
  <fileset dir="${lib.dir}">
   <include name="*.jar" />
  </fileset>
 </path>
 <!-- **********************************init********************************** -->
 <!-- 初始化，创建各种目录 -->
 <target name="init">
  <mkdir dir="${src.dir}" />
  <mkdir dir="${lib.dir}" />
  <mkdir dir="${ui.dir}" />
 </target>

 <!-- **********************************clean class********************************** -->
 <!-- 清除 编译的文件 -->
 <target name="clean" description="Delete old build and dist directories">
  <delete dir="${class.dir}" includes="**/*.class" />
 </target>

 <!-- **********************************compile java********************************** -->
 <!-- 编译java文件 -->
 <target name="compile" description="Compile Java sources" depends="clean">
  <mkdir dir="${class.dir}" />
  <javac srcdir="${src.dir}" destdir="${class.dir}">
   <classpath refid="compile.classpath" />
  </javac>

  <copy todir="${class.dir}">
   <fileset dir="${src.dir}" excludes="**/*.java" />
  </copy>
 </target>

 <!-- 打成jar包 -->
 <target name="jar" depends="compile">
  <jar jarfile="${src.dir}/test.jar" basedir="${class.dir}" excludes="**/*Test.class" />
 </target>

 <!-- **********************************deploy   webapp********************************** -->
 <!-- 部署到tomcat-->
 <target name="deploy" description="Install application to servlet container" depends="compile">
  <delete dir="${webapps.dir}/${webapp.name}" />
  <war destfile="${webapps.dir}/${webapp.name}.war" webxml="${basedir}/WEB-INF/web.xml">
   <fileset dir="${ui.dir}" />
   <lib dir="${lib.dir}" />
   <classes dir="${class.dir}" />
  </war>
 </target>

 <!-- **********************************start  web server********************************** -->
 <!-- 启动tomcat -->
 <target name="startserver" description="Start  web server">
  <exec dir="${catalina.home}/bin" executable="cmd.exe">
   <env key="CATALINA_HOME" path="${catalina.home}" />
   <arg value="/c startup.bat" />
  </exec>
 </target>

 <!-- **********************************stop  web server********************************** -->
 <!-- 停止tomcat-->
 <target name="stopserver" description="Stop  web server">
  <exec dir="${catalina.home}/bin" executable="cmd.exe">
   <env key="CATALINA_HOME" path="${catalina.home}" />
   <arg value="/c shutdown.bat" />
  </exec>
 </target>

 <!-- **********************************start work**********************************  -->
 <target name="start" description="Clean build and dist directories, then compile">
  <ant target="deploy" />
  <ant target="startserver" />
 </target>

 <!-- **********************************reload  web server********************************** -->
 <!-- 重启tomcat -->
 <target name="reload" description="reload  web server">
  <ant target="stopserver">
  </ant>
  <sleep seconds="2">
  </sleep>
  <ant target="start">
  </ant>
 </target>
</project>

本文所用cruisecontrol版本是2.8。

1. 日构建配置

日构建是指在每天指定的时间进行构建。

1.1. <Project>

requireModification 设为 false，含义是无论有没有变化，都要进行构建。

1.2. <Listener>

    <listeners>

      <currentbuildstatuslistener file="logs/${project.name}/status.txt"/>

</listeners>

如果没有设置, 那么dashboard上的status将是空，但并不影响大局，一般就如上配置。

1.3. <bootstrappers>

Bootstrappers配置了检查变更前的任务，也在Schedule中的任务之前。这里要完成schedule中任务所依赖的文件的更新。

比如

<bootstrappers>

  <tfsbootstrapper itemSpec=“[vstsworkspace]\[setuppath]\build.xml />

</bootstrappers>

而cruisecontol给出的connectfour例子：

<bootstrappers>

            <antbootstrapper anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml" target="clean" />

</bootstrappers>

实际上没有必要，大可放到 schedule中的任务中。

1.4. <modificationset>

对于日构建，这其实是不需要的，但由于cc必须要1个mondification，可以配一个无效。两个建议：

1，配成检查本机某个目录,这个目录不需要变化； 

    <modificationset >

      <filesystem folder="D:\WWS\JJJ"/>

    </modificationset>

2，配成timebuild

    <modificationset >

      <timebuild time="1200" />

</modificationset>

这与schedule中的time配置有所冲突，shedule中任务的time设置后，此设置无效。

1.5. <schedule >

属性interval 是设置检查更新的间隔秒数。如果下面的任务配置了 time，这个属性会变得无效。

对于日构建任务，建议只设置一个，首选ant任务，全部要完成的动作在ant的build.xml中。

例：

   <schedule interval="300">

      <ant anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml" time="2112" />

</schedule>

Build.xml中处理了获取代码、编译、测试、打包、发布等等任务。

1.6. <log>

如果采用了ant中junit任务，可以用下面语句合并日志。

    <log>

      <merge dir="projects/${project.name}/target/test-results"/>

    </log>

1.7. <publishers>

主要配置email通知。配置简单，按说明即可。要注意的是，在force build时，缺省地存在名为"User"的用户，在发送列表中，但"User"不是一个有效的email，因此加入"User"的别名来解决这个问题。示例如下：

    <publishers>

      <htmlemail buildresultsurl="http://xx" mailhost="smtphost" username="xxx" password="xxx" returnaddress="xxx@yyy.com">

        <map alias="User" address="xxxuser@gmail.com" />

         <always address="xxxxx@hotmail.com" />

      </htmlemail>

    </publishers>

对于项目群汇总报告，建议采用 <http>

也可以将build.xml中最后的发布任务放到这里。比如

<publishers>

<onsuccess>

    <antpublisher antscrīpt="C:\Java\apache-ant-1.6.1\bin\ant.bat"

         antworkingdir="D:\workspace\MyProject"

         buildfile="build.xml"

         target="publish">

     </antpublisher>

</onsuccess>

</publishers>

一、什么是持续集成（Continuous Integration）？

　　这个名词已经在软件开发领域持续了N年，一个比较简单的定义如下：
　　持续集成（CI）是一种实践，可以让团队在持续的基础 上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。通俗一点儿说，就是指对于开发人员的每一次代码提交，都自动地把Repository中所有代码Check out到一个空目录，并且自动运行所有Test Case。如果成功则接受这次提交，否则告诉所有人，这是一个失败的Revision。更具体的解释可以参考Martin fowler的Continuous Integration  。

二、持续集成的价值与成本

　　有句时髦的话，叫做“存在即为合理”。既然持续集成已经存在了这么长的时间，而且没有消失的迹象，那就是有价值的东西。那么它的价值何在？有人概括如下：(1) 减小风险；(2) 减少手动过程；(3) 生成构建结果；(4) 安全感。
　　而持续集成的成本在于对持续集成代码的维护成本和集成的时间成本。因为随着项目进行，软硬件环境会越来越复杂，成品代码也会不断膨胀。此时，需要团队而修改或增加原有的测试代码，以适应这些变化，同时，每次集成所需时间也会变长，这就是持续集成的成本。某个blog中提道：“这种集成是如此的频繁，多少次的代码Commit就有多少次持续集成。前提是集成的成本很低，或者说是完全自动化的。”

三、持续集成应该自动化什么呢？

　　我们要以尽可能少的成本来获得尽可能多的价值。这就要考虑哪些自动化是必要的啦。Jez Humble提到至少有六点要做到自动化，它们分别是(1)自动化的运行测试；(2) 自动产生可部署的二进制成品；(3) 自动将成品自动部署到近似生产环境；(4) 自动为CodeBase打上标签；(5) 自动运行回归测试；(6)自动生成度量报告。

四、持续集成服务器的选择

　　在进行持续集成实践前，应当正确的选择并配置持续集成服务器。比较成熟的持续集成服务器包括：CruiseControl, Anthill, Bamboo, TeamCity, Continuum 等。CruiseControl作为开源产品，以其对于各种SCM以及构建工具的广泛支持而被许多开发团队所接受。而开发自动化专家 Duvall 采用一致的评估标准和很多说明性示例，介绍了一些开源 CI 服务器，包括 Continuum、CruiseControl 和 Luntbuild。并指出“要根据 自己的 具体技术和政策需求对工具进行分析”。并用以下五个指标来评估CI工具，它们分别是：(1)  特性；(2)  可靠性；(3)  寿命；(4) 目标环境；(5) 易用性。结果如下表：
　　　　　　　　　　　

　　而CruiseControl是我唯一真正用过的持续集成工具，它现在灵活而又强大功能也让我瞠目，而且配置与管理也较两年前容易得多啦。为什么说它强大呢？因为你只要想得到的问题，它也都会有所考虑。朋友的Blog上有些CruiseControl的最佳实践足以证明这一点，只要你肯去实践。

五、只有持续集成服务器是远远不够的

　　正如Jez Humble所说，CruiseControl和其它的CI工具本质上只不过是一个定时器，时间一到，做你让它做的事情。所以，必然要有其它工具与其结合，方显持续集成的本色。这些工具又是什么呢？想测试的话，你就要用一些测试工具，如JUnit，JWebUnit，Selenium等等；想检查代码标准的话，你就要用checkstyle等代码规范检查工具；想要了解测试覆盖率的话，你可能就要用到JCoverage啦。当然，想得到二进制文件，就要用到Ant，Make之类的工具啦。

六、最重要的事：实践与反思

　　也许这些东西大家都知道，而且有些人可能已经实践过啦。无论这些实践的结果是怎样的，一定不要忘记总结和反思。如果这些实践成功了，不要把它归功于这个工具，而是要总结一下为什么会成功，如果你愿意的话，还可以和大家分享一下。如果这些实践失败了，也不要把它归功于这个工具，而是要反思一下，是否正确地使用了这个工具，团队成员是否都喜欢这个工具，为什么？