我又回来了，好久不见，朋友们。

1.       验收测试是一项非常复杂和费力的被用来确保软件质量的环节。它的目的就是使软件能得到充分运行并且能使其符合原始需求。

2.       测试的目的无非就是满足了两个结果：测试通过或测试不通过。为了能实现每个测试结果，必须要明确每个测试用例。并且对于整个系统而言在合同中必须定义测试用例的失败标准，而且这个失败标准数必须是可接受的。

3.       测试用例的通过条件必须有一个清晰的标准，标准可以被定义为一个测试值或一个测试值集，并且将他们显示或保存到数据库中。一些测试结果比较容易形象的看到(例如：网站上的图片是否被有效的加载)，而另一些测试结果却需要通过脚本将测试结果输出(例如：对数据库中的数据进行测试)。

4.       为了能使所有的测试用例能被精确的执行，一般都建立一些基础测试数据。也许这些测试数据可以从计算机中转换得到。无论测试数据被保存在什么地方，都必须被操作系统能熟练控制。这些测试能更方便的被系统使用。事实上就是要确定每个测试步骤要成为整个测试过程的一部分。

5.       在整个测试序列中，为了确保正确的测试步骤被执行，说明测试过程是非常重要的。例如：如何描述测试”动作次序”.

6.       测试脚本的运行必须能被系统运行执行，输出结果必须能被系统识别。通常情况下，输出结果都以文本形式或者以图表的形式输出。有些时间也可以以各种报表的形式打印输出。

 

 

规范的脚本需要注意的几个问题：

*测试数据应该预先存在，并且测试脚本应该依赖与这些测试数据。-这些测试数据可以依赖以某一测试步骤或整个测试过程。测试结果数据也可以保存在计算机的内存、文件或数据集的形式保存在数据库中。

*每一个测试步骤都能够被独立运行.

*有必要的话，在运行每个测试用例之前，先检查测试数据的正确性。在实际案例中，这步是放在每步测试过程之前，另外也可以通过一些软件检查工具进行检查。

*测试用例的通过标准要是合适的。

*对于测试脚本最重要的标准就是它能够重复使用的。如果建立了正确的测试环境，测试脚本在每次执行后都应该产生相同的结果。但请记住，脚本对测试环境依赖很大，所以测试脚本被另外的一些潜在因素所制约，如计算机系统或网络环境。

*测试脚本还会产生”假错误”的危险性。当执行完测试脚本后，测试脚本会报一些错误，但这些错误却不是Bug。举个例子，测试脚本产生了错误，但在用例中却无法找到(数据类型错误或无法找到数据，这些错误虽然简单但是确是很明显的)。应该将测试脚本本身的通过标准加入到测试用例中来。

*一定要查明测试脚本在执行过程中失败的原因。由于测试脚本的复杂性，也难免会有许多假错误。所以一定要找出根本原因，是测试脚本能被正确的回放执行。但有时候同样的两段测试脚本执行会产生不同的结果，一段能测试通过，而另一段却测试失败。同时也有可能会产生不同的测试结果。我想这有可能是有测试环境的错误而引起的。如果项目时间不允许的话，应该将这部分自动化测试脚本删除，改而人工测试执行。

看到几段文字，我贴上来。

国内企业好像还没有PM 这个角色，而测
试人员又往往成为开发人员的附庸，一个Bug 是否要被解决全由开发人员说了算，这很糟
糕，就像政治上一个权力没有被有效的制衡一样，一定会产生各种问题。

做完一个版本后，还会让所有员工匿名投票，找出这次研发过程中出
现的各种问题以便在下个版本中解决(此过程称为Postmortem，挺吓人的一个词)。

微软的Bug 处理过程，非常类似于“击鼓传花”的游戏。鼓点响起，你的任务
就是尽快把自己手中的“花”（Bug）传给下一个人，不要让它在自己手里耽误很长时间。
从表面上看，在微软工作从不打卡、上班时间也很自由、上午很晚到办公室也没人管你，但
是有Email 跟着、有Bug 催着，你永远不可能偷懒。没有人盯着你，只是事情如影随形，
而且所有和你相关的事情都是公开的，相关的人都知道，就像处于非常开放的舆论监督之中，
除了把事情办漂亮你还能有别的选择吗？

想办法，把对某个人的依赖尽量降低，并使产品可持续发展。

但是测试这一块大家还是不够重视，对测试人员的素质要求也不是很高、人员比例也较
低，测试人员往往依附于开发人员的直接管理，人微言轻.

我可以参数化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中。

1.确定问题
可以从几个方面入手：

应用程序代码：通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。

数据库配置：数据库配置经常会引起整个系统运行缓慢，一些诸如Oracle的大型数据库都是需要DBA进行正确的参数调整才能投产的。

操作系统配置：操作系统配置不合理也可能会引起系统瓶颈。

硬件设置：磁盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。

网络：网络负载过重会导致网络冲突和网络延迟。

系统性能问题不是显而易见的，要进行仔细的查找才能够进行正确的定位。

2.确定原因(主要取决于你的经验)

问题的影响是什么：响应时间还是吞吐量，或者其他问题？

是大多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其他用户的操作有什么不同？

系统资源监控的结果是否正常：cpu的使用是否到了极限？I/O情况如何？

3.确定调整目标和解决方案

确定调整目标的主要作用是明确何时停止调整系统，否则工作将永无止尽。

提高系统吞吐量

缩短响应时间

更好的支持并发

设计解决方案的主要依据就是这些调整目标，有了明确的方案和目标，就可以进行后面的工作。

4.测试解决方案

5.分析调整结果

主要考虑以下的问题：

系统调整是否达到或者超出了预定的目标？
系统是整体性能得到了改善，还是以牺牲某部分性能来解决问题的？
调整是否可以结束了？

1.掌握常见自动化测试工具的使用

2.具备一定的编程能力

3.掌握基础的数据库知识

4.掌握常见的操作系统知识

5.掌握一些web应用服务器例如Weblogic和Websphere等的使用

6.具有综合分析问题的能力，例如通过综合分析测试结果来确定系统瓶颈。

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

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

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

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

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

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

1.测试需求分析

2.测试计划制定与评审

3.测试用例设计与开发

4.测试执行与监控

5.分析测试结果

6.编写性能测试报告

7.测试经验总结

最重要的应该是1、4、5

测试需求分析是整个性能测试的基础，在这一阶段，测试负责人要和项目干系人要进行沟通，同时收集各种项目资料，尤其要搞清楚用户对待性能测试的态度。

测试需求分析阶段的主要任务是确定测试策略和测试范围。策略主要根据软件类型以及用户对待性能测试的态度来确定，测试范围则根据测试策略和需求分析的结果来确定！

测试执行与监控。本阶段主要包含性能测试实施与过程监控。测试实施主要指通过测试工具或者真实的用户来执行测试用例，具体工作主要有创建测试场景、执行测试场景、监视测试场景等。监控测试项目是测试经理的主要职责，在执行过程中，通常会根据项目具体情况进行测试内容的调整，例如修改测试用例、调整测试反问等。

分析测试结果。本阶段主要根据前面的测试数据来分析测试结果，为优化和调整系统提供依据。测试分析的对象是应用程序、web服务器、数据库服务器、操作系统、硬件资源等。通过对测试结构的综合分析，准确定位系统的性能问题。

何时实施这种攻击？

首先需要对应用程序的页面进行映射，以便理解它的连接方式。Web crawlers一类的工具(或者wget或BlackWidow)能够帮助你实现这一点。但是如果应用程序是由上千个统一的页面组成，最好还是手工完成这个任务，以便了解web页面框架的更多第一手资料。

映射的过程很简单。从应用程序的第一个页面开始，点击每个链接进入到子页面，归纳所访问到的页面，直到访问了所有的页面为止。

当网页之间传递的数据和参数加上了注解时，页面映射是一个很好的方法，而源代码在获取这些信息方面的作用则很有限。在问题的标号用"&"符号分隔开以后，可以很容易地在URL中找出"变量名==结束"的配对。但这只对于Get参数有效，因为窗口之间传递的参数常常不同。

web代理程序可以解决这个问题。

如果应用程序实现了基于等级的访问，或者根据用户进行限制，则最好从最低等级的用户开始"淘金"，然后逐步处理更高的特权等级的用户，直到最高等级。

在映射了应用程序之后，返回到页面去阅读源代码，并搜索HTML注释(比如通常用两个破折号括起来，比如:<!--...-->)来检查其中的内容。大部分Web设计者都用注释来标记页面中的引导部分，有时这里会包含一些对攻击者很有价值的线索。

未完待续。。。

这种攻击方式主要用于以下四个主要方面：

1.HTML代码中嵌入的注释
2.HTML代码中的敏感信息
3.服务器端的出错信息和HTTP响应
4.应用程序的出错信息

前两个方面需要阅读应用程序的源代码以寻找对于攻击者有用的信息，后两个方面需要提交错误的输入并仔细分析所产生的错误消息以获得有用的信息。

源代码和错误信息对于攻击者而言都是很有价值的，它们能够帮助攻击者确定，哪个web页面包含了"黄金"，而哪些只有沙石。

我将详细介绍这种攻击技术，尽情期待！

 

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

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  
  废弃文件:   未作指定  

      每天大家都很忙，有永远处理不完的事情。如何安排好的你的时间顺序来安排你的生活呢？有些人使用的是Outlook Calendar,Google Calendar,但我总觉得这些工具不是很方便(虽然Outlook有email，Google Calendar可以共享你的日历，也提供源码可以象plugin那样使用)。
      我现在用的是Wallpaper Calendar，它吸引我的地方就是它的桌面日历，你可以直接在桌面上编辑你的日历行程。很是方便。
 
      http://www.zepsoft.com/