我可以参数化3组不同权限的用户,进行登陆测试,这样用一个脚本完成了3个不同用户的登陆,方便维护脚本.

QTP调用Action有三种方式：

a）call to new Action，在当前test中创建一个新的Action；
b）call to Copy of Action；以嵌套方式调用
c）call to existing action，调用一个re-usable action，如果这个re-usable action来自另外一个test，将以只读的方式插入到当前test中。

web应用需要底层架构的支持-web服务器硬件/软件、DNS入口、网络设备、负载均衡器等等。

任何好的web安全评估方法，首先都是识别和分析应用程序所位于的底层架构的。

踩点和扫描：定义范围
注册调查、DNS查询、常规的组织结构调查
服务器发现(ping扫描)、网络服务识别(端口扫描)

Banner抓取，通常可以确定目标web服务器软件的类型及版本

高级HTTP指纹：抓取HTTP相关版本的Banner称之为web服务器指纹识别。
例如，一个IIS服务器和一个Apache web服务器可能会对某个非法的HTTP请求返回不同的响应信息。(这是确定web服务器真实类型和版本非常好的方法)

不常见的http请求方法
httpprint工具使用了诸如检查HTTP头顺序等的大部分探测技术。他也带有可定制的web服务器指纹数据库。

中间件架构(负载均衡、虚拟服务器配置、代理和web应用防火墙)

虚拟服务器(一般小公司比较喜欢用，为了节约硬件条件，可以在一台server上模拟多个不同IP)

检测负载均衡器
探测在目标站点上是否运行了负载均衡器的方法：在一个ip范围内做端口扫描

使用SQL时必须考虑的关键因素。依我看来，有五大要素：

1.获得结果集所需访问的数据量

2.定义结果集所需的查询条件

3.结果集的大小

4.获得结果集所涉及的表的数量

5.多少用户会同时修改这些数据

一.数据总量（Total Quantity of Data）

必须访问的数据总量，是要考虑的 最重要因素。没有确定目标容量之前，很难断定查询执行的效率。

二.定义结果集的查询条件(Criteria Defining the Result Set)

多数情况下会涉及where子句条件，应该从几个方面考虑("过滤"、主要SQL语句、以及庞大的数据量对查询的影响等)。这个问题比较复杂。

三.查询所返回的数据量（或是SQL语句改动的数据量）(Size of the Result Set)

取决于表的大小和过滤条件的细节。

个人认为应该从以下几个角度去考虑1.若干个独立使用时效率不高的条件，结合起来使用时会产生极高的效率.

从技术角度来讲，结果集的大小并不重要，而是取决于最终用户的感觉。用户的耐心，在很大的程度上和预期返回的记录条数有关

熟练的开发者应该努力使响应时间与返回的记录数成比例。

四.表的数量(Number of Tables)

一.TamperIE工具
TamperIE 是来自Bayden系统的一种浏览器辅助对象(Browser Helper Object,BHO).它非常简单，只有两个选项-篡改GET和Post.在默认情况下，设置为仅篡改post，所以当你在浏览时遇到post请求时，TamperIE会自动阻断提交并在屏幕上显示出来。

二.IEWatch
IEWatch是简单但功能完整的HTTP监控客户端，它可以作为浏览器栏集成在IE中。它位于浏览器的下方，将HTTP和HTTPS交互的所有方面都暴露出来，包括请求头、表单、cookies等等，都可以进行简单双击输出日志中的对象进行详细的分析。但不能篡改参数

三.IE Headers
基本功能与IEWatch一样，他也不允许篡改数据

以上都是IE插件

Firefox插件(用于HTTP分析和篡改)
一。LiveHTTPHeaders
二。TamperData
三.Modify Headers

1.web平台：web平台软件漏洞,包括Http底层服务软件(比如，IIS或Apache)等底层基础设施，以及应用程序开发框架(如Asp.Net或者PHP).

2.web应用：对授权、认证、站点结构、输入验证、程序逻辑以及管理接口进行攻击。

3.数据库：通过数据库查询进行特权命令，操纵查询以返回额外的数据集，这里最具破坏性的攻击是SQL注入。

4.web客户端：活动内容执行、客户端软件漏洞攻击、跨站脚本错误，以及钓鱼欺骗

5.传输：窃听客户-服务器通信，SSL重定向

6.可用性：如果要你迅速地指出更危险的"黑客"技术，拒绝服务攻击(denial of service,DoS)经常会被遗漏，其实DoS攻击是任何可公开访问的Web应用所面临的最大威胁之一。让任何资源都对公众开放本来就有很大的挑战，在网络世界中更是如此。

其中Open Web Application Security Project(owas)就是流行之一。

如果软件的GUI界面都在不停的变化，确实不太适合做自动化测试。但是我们也可以考虑一些变通的方法，减少脚本维护的工作量。比如我们可以把GUI的属性写到xml文件里，然后QTP从xml读取属性值，并使用setProperty方法将属性赋值给测试对象，最后就是脚本的执行了。在去年的自动化测试过程中，曾小范围的尝试过这种做法，但是效果不理想，主要是学习成本高：
1、要解决XML在TD上的存储和读取问题；
2、要解决QTP对XML的读取和写入问题；
3、要解决XML文件和测试对象属性的对应问题；
4、即使把测试对象的属性都写进xml文件，对XML文件的维护又成了我们头疼的事情。
最后采取的方法是，对于IE标题、页面名称等固定的对象，则建立共享对象库，对于每个功能模块的GUI对象，由于变化次数比较多，采用单独对象库模式。软件即使要变，也不可能把所有的GUI对象都改头换面。这样当开发人员每次发版的时候，我们会去了解哪些模块进行了改动，然后花1-2天对脚本进行调试和修改，完成后就是脚本的整体运行了。

在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。

        假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“ 在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人 数”），那么，系统的并发用户数是多少呢？

        根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系 统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点， 在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用 户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的 20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务 器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

       在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

        （1）  计算平均的并发用户数： C = nL/T      

        （2）  并发用户数峰值： C’ ≈ C+3根号C

         公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。

        公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

实例：

        假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

则根据公式（1）和公式（2），可以得到：

               C = 400*4/8 = 200

               C’≈200+3*根号200 = 242

性能测试按照场景的不同一般可以分为两种：一种是基于用户实际使用情况的场景测试，另外一种是为了特殊测试目的而设计的场景测试。

前者主要是基于验证目的而进行的测试，是为了测试系统是否满足用户的基本使用要求。

后者属于为了测试而进行的测试，主要是为了测试系统的扩展性、稳定性等方面。两种场景测试都要以用户的实际情况为基础来进行设计。

比较常见的用户场景有如下三种：

一天内不同时间段的使用场景
系统运行不同时期的场景
不同业务模式下的用户场景

    测试数据的构造对于软件测试工程师是最基本的技能．
　　系统测试数据来源主要由以下构成：
　　－产品
　　－手工构造
　　－生成
　　－捕获
    －随机

SQL*LOADER是ORACLE的数据加载工具，通常用来将操作系统文件迁移到ORACLE数据库中。SQL*LOADER是大型数据  
  仓库选择使用的加载方法，因为它提供了最快速的途径（DIRECT，PARALLEL）。现在，我们抛开其理论不谈，用实例来使您快速掌握SQL*LOADER的使用方法。

我们知道，SQL*LOADER只能导入纯文本，所以我们现在开始以实例来讲解其用法。  
  　　   一、已存在数据源result.csv，欲倒入ORACLE中SYSTEM用户下。  
  　　　　   result.csv内容：  
  　　   1,默认   Web   站点,192.168.2.254:80:,RUNNING  
  　　   2,other,192.168.2.254:80:test.com,STOPPED  
  　　   3,third,192.168.2.254:81:thirdabc.com,RUNNING  
  　　   从中，我们看出4列，分别以逗号分隔，为变长字符串。  
  　　   二、制定控制文件result.ctl  
  result.ctl内容：  
  load   data  
  infile   'result.csv'  
  into   table   resultxt    
  (resultid   char   terminated   by   ',',  
  website   char   terminated   by   ',',  
  ipport   char   terminated   by   ',',  
  status   char   terminated   by   whitespace)  
  　　   说明：  
  　　   infile　指数据源文件　这里我们省略了默认的　discardfile   result.dsc   badfile   result.bad  
  　　   into   table   resultxt   默认是INSERT，也可以into   table   resultxt   APPEND为追加方式，或REPLACE  
  　　   terminated   by   ','　指用逗号分隔  
  　　   terminated   by   whitespace　结尾以空白分隔  
  　　   三、此时我们执行加载：  
  D:\>sqlldr   userid=system/111111 control=result.ctl   log=resulthis.out  
  SQL*Loader:   Release   8.1.6.0.0   -   Production   on   星期二   1月   8   10:25:42   2002  
  (c)   Copyright   1999   Oracle   Corporation.   All   rights   reserved.  
  SQL*Loader-941:   在描述表RESULTXT时出现错误  
  ORA-04043:   对象   RESULTXT   不存在  
  　　   提示出错，因为数据库没有对应的表。  
  　　   四、在数据库建立表  
  　   create   table   resultxt  
  (resultid   varchar2(500),  
  website   varchar2(500),  
  ipport   varchar2(500),  
  status   varchar2(500))  
  /  
 　　   五、重新执行加载  
  　　   D:\>sqlldr   userid=system/111111   control=result.ctl   log=resulthis.out  
  SQL*Loader:   Release   8.1.6.0.0   -   Production   on   星期二   1月   8   10:31:57   2002  
  (c)   Copyright   1999   Oracle   Corporation.   All   rights   reserved.  
  达到提交点，逻辑记录计数2  
  达到提交点，逻辑记录计数3  
  　　   已经成功！我们可以通过日志文件来分析其过程：resulthis.out内容如下：  
  SQL*Loader:   Release   8.1.6.0.0   -   Production   on   星期二   1月   8   10:31:57   2002  
  (c)   Copyright   1999   Oracle   Corporation.   All   rights   reserved.  
  控制文件:   result.ctl  
  数据文件:   result.csv  
  错误文件:   result.bad  
  废弃文件:   未作指定