功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：
1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。
4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

。。。

 OLTP(联机事务处理)是指利用计算机网络，将分布于不同地理位置的业务处理计算机设备或网络与业务管理中心网络连接，以便于在任何一个网络节点上都可以进行统一、实时的业务处理活动或客户服务。

     通常在数据库系统中，事务是工作的离散单位。例如，一个数据库事务可以是修改一个用户的帐户平衡或库存项的写操作。联机事务处理系统(OLTP)实时地采集处理与事务相连的数据以及共享数据库和其它文件的地位的变化。在联机事务处理中，事务是被立即执行的，这与批处理相反，一批事务被存储一段时间，然后再被执行。大多数批处理(例如帐目交换)是在夜间进行的。

网络时间是从发出第一个http请求到收到ACK的时间。
服务器时间是从收到ACK到第一个字节返回的时间。

名词解释：

ACK是TCP首部中的确认标志，对已接受到的TCP报文进行确认。
英文缩写: ACK (ACKnowledge Character）
中文译名: 确认字符
分　　类: 传输与接入
解　　释: 在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。

为了使数据库减小和缩短在大方案中的处理时间，必须进行数据聚合。
在自定义中要减小数据库大小可以增加粒度，最小值为1秒。

在测试web应用程序时，配置测试环境是unix下的，如何查看应用的日志，以下介绍几个方式：

1． 应用日志存放的路径一般为： /home/{unix_user}/output/logs/sys/webx.log

2． 一般有很多个webx.log的文件，一个webx.log主文件，其他都加日期的，譬如webx.log.200x-xx-xx 结束的。这些都是之前的log。当日的应用日志应该是webx.log

3． 建议删除所有日志  rm –rf *  然后再重启应用，这时，你的日志文件会变得很清晰，一目了然。

4． 也可以不重启应用，直接清log 比如： > webx.log  这样你的日志文件就被清空了。

5． 查看日志方式： vi webx.log   

                   more webx.log  

                   cat webx.log    

                   tail –f webx.log (查看后面10条log)都可以。

6． 查看日志并查找某关键字：

a. vi webx.log   然后 /ERROR  就是查找有含有ERROR的日志，按键盘n 为 查找下一个

b. cat webx.log |grep ERROR  列出webx.log 中所有 ERROR的行

c. ERROR的个数:   cat webx.log |grep ERROR | wc –l  计算出webx.log 中所有 ERROR的个数

  d. 查找除了ERROR 以外关键字的日志: cat webx.log |grep -v ERROR

     e. 在某个文件夹下,查找该文件夹下,所有文件含有某个关键字:  grep -e ERROR -r *

     ……

     要适当用 管道符 来缩小查找的范围.

7. 对于webx.log 中,存在 ERROR 或者 Exception ,我们都是要关注和跟进的.

8. Log信息问几种级别：OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL；但是平时一般只用四种：DEBUG、INFO、WARN、ERROR；前三个级别的信息一般是在程序员用来调试的信息，而第四种（error）级别是日志信息里级别最高的，ERROR级别信息的产生分两种；一种是程序出错，一种只是程序员用来调试输出；一般在日志文件中，ERROR级别的信息是需要特别关注的

9. 一般我们都把log 的级别调成 error . 在unix测试环境的home下面的antx.properties 中的  应用.loggingLevel     = error  比如: exodus2.loggingLevel     = error

 

1，培训问题

　　好多测试人员没有经过正规的测试培训，致使对测试技术和业务大量的误解和误用，所以要重视测试人员的培训，包括业务培训和测试技术培训。

　　2， 开发人员和测试人员意见对立面问题

　　3，测试工具

　　尽管测试需要的不仅是工具，但是没有工具却想试图有效地进行测试就好比用勺子挖壕沟。

　　4，管理高层缺乏对测试的支持和理解 ：需要沟通、说服、成绩

　　5，用户和客户的介入参与

　　以用户和客户的视角测试发现的问题更典型

　　6，测试时间的把握

　　充分、充分不浪费、不充分

　　7，过分依赖测试

　　8，需求变更、修改频繁

　　9，测试报告缺陷太多，被责备耽误时间；缺陷太少，被质备工作质量差

　　10，测试人员要敢于说“不”的问题，如：“缺陷太多，不能发布”“质量太差，不予测试”等。

如果Disk Time和Avg.Disk Queue Length的值很高，而page Reads/sec 页面读取操作速率很低，则可能存在磁盘瓶径。

如果Process\Private Bytes计数器和Process\Working Set计数器的值持续升高
同时Memory\Available bytes计数器的值缺却持续降低的话
说明很有可能是存在内存泄漏

RTE:基于字符的应用程序，类似我们接触的DOS

在协议的winsock中，我们会经常使用到lrs_save_param函数

lrs_save_param("socket0", LRS_LAST_RECEIVED, "RecvData", 200,100);
从最后一次接受的buffer中取第200个字节之后的100个字节的数据，保存在参数RecvData中。
之后对该参数怎么处理就是你的事了。
要找到数据在buffer中的位置，在data.ws中选中那个buffer，按F7，找到你想要的数据和它的位置。 

lrs_receive("socket2", "buf47", LrsLastArg);
lrs_save_param("socket2", NULL, "param1", 67, 5);
lr_output_message ("param1: %s", lr_eval_string("<param1>")); 
lr_think_time(10);
lrs_send("socket2", "buf48", LrsLastArg); 

我们使用LR在录制了web脚本后，发现会一些会是乱码，使得我们无法判断内容是什么，这样我们往往先检查下是否是字符的原因。

若是字符原因，在recording options中的advanced里的support charset(utf_8)选定即可解决

若不是也可以在word文档中自己先编写后，复制到LR中去调试

 

 

 

 

WEB性能测试的部分概念一般来说，一个web请求的处理包括以下步骤：

（1）客户发送请求；

（2）web server接受到请求，进行处理；

（3）web server向DB获取数据；

（4）web server生成用户请求的object（页面），返回给用户。从客户发送请求开始到客户接收到最后一个字节的时间成为响应时间（第三步不包括在每次请求处理中）。

 1.事务（Transaction）

在web性能测试中，一个事务表示一个“从用户－》web Server－》DB－》web server－》用户”的过程，一般的响应时间都是针对事务而言的。

2.响应时间

响应时间指的是从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间。在某些工具中，响应时间通常会称为“TTLB”，即“time to last byte”，意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间= 网络响应时间 + 应用程序响应时间

3.并发数

并发数是指同时进行请求的客户的数量，并发数用于模拟用户的真实负载情况（并发情况是对系统最大的考验），并发数≠同时使用系统的用户数。

4.吞吐量

吞吐量指的是单位时间内处理的客户端请求数量。通常情况下，吞吐量用请求数/秒或者页面数/秒来衡量。从业务角度看，吞吐量也可以用访问人数/天 或者页面访问量/天 来衡量。

5.资源利用率

资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU（s），内存，网络带宽等。资源利用率通常以占用最大值的百分比 n %来衡量。

性能测试基本概念释疑

似乎许多人都对性能测试有或多或少的不清楚，这里就我的理解提供一些解释： 1、负载测试（Load Test）、压力测试（Stress Test）、容量测试（Capability Test）与性能测试（Performance Test）是什么关系？

可以说性能测试是一个较大的范畴，包括负载测试、压力测试和容量测试。其中负载测试是为了检验系统在给定负载下是否能达到预期性能指标；压力测试是通过不断向被测系统施加“压力”，测试系统在压力情况下的性能表现；容量测试针对数据库而言，是在数据库中有较大数量的数据记录情况下对系统进行的测试。

2、性能测试过程中如何需要记录什么数据？性能测试过程中，根据性能测试的不同类型和不同目标，记录的数据也不同。例如，对于一个以调优为目的的性能测试，可能需要重点关注测试过程中各可能的性能制约点（例如磁盘IO、网络拥塞状况、服务器内存使用情况、数据库使用情况等），通过对参数调整后的系统进行反复测试来找到制约性能的因素；而一个以验证为目的的性能测试可能会重点关注是否能达到性能指标要求，重点集中在用户体验上。

3、性能测试是否一定需要性能测试工具？一般来说，性能测试由于需要模拟并发等操作，需要工具的支持才能进行较好的性能测试。但提到性能测试工具，不见得就是MI的LR或是Rational的LT，还有诸多的开源测试工具或是自己开发的工具都可以运用在性能测试中，只要工具能满足你的要求，就不必追求所谓最好最新的工具。

部署在Internet上的WEB应用毫无疑问每时每刻都在遭受着各种考验，有些是出自恶意的破坏者（Cracker），有些是来自无心的攻击者（中了病毒或是木马的菜鸟），还有一些是来自系统内部的出于好奇或是有目的的恶意访问。下面是计算机安全学会CSI(www.gocsi.com)协同旧金山联邦调查局开展的2002计算机犯罪和安全调查提供的数字：

90%的被调查者在过去12月中探测到有计算机漏洞
74%的被调查者称其Internet连接遭受频繁攻击，而40%的被调查者探测到有来自外部的系统渗透；
75%的被调查者估计他们在过去所受的攻击的一部分可能来自心怀不满的雇员。
而根据CERT的统计(www.cert.org)，2002年度收到的与安全相关的报告事件的数目是43136个，2001年是51658个，2000年是21756个。毫无疑问，安全问题正在成为计算机领域的关键问题，作为具有最多访问方式和最大的网络基础的WEB应用，其面临的安全考验更是严峻。

据知，国内的公司很少会专门为自己的WEB项目进行安全性测试，而且，大部分公司也不知道着手进行安全性测试。

一般来说，一个WEB应用包括WEB服务器运行的操作系统、WEB服务器、WEB应用逻辑、数据库几个部分，其中任何一个部分出现安全漏洞，都会导致整个系统的安全性问题。

对操作系统来说，最关键的操作系统的漏洞，例如Unix上的缓冲区溢出漏洞、Windows上的RPC漏洞、缓冲区溢出漏洞、安全机制漏洞等等；
对WEB服务器来说，WEB服务器从早期仅提供对静态HTML和图片进行访问发展到现在对动态请求的支持，早已是非常庞大的系统，即使发展多年的Apache也难逃经常被发现安全漏洞的缺陷，更不要说千疮百孔的IIS了；
对应用逻辑来说，根据其实现的语言不同、机制不同、由于编码、框架本身的漏洞或是业务设计时的不完善，都可能导致安全上的问题；
对数据库来说，数据库注入攻击一直是数据库厂商和网站开发者的噩梦。

除此之外，安全问题还存在于管理等各个方面，不完善的管理制度、缺乏安全意识的员工都会是内部的突破口，同样，一些开发工具生成的备份文件和注释也会成为Cracker发送攻击的参考资料。

对WEB的安全性测试是一个很大的题目，首先取决于要达到怎样的安全程度。不要期望网站可以达到100%的安全，须知，即使是美国国防部，也不能保证自己的网站100%安全。对于一般的用于实现业务的网站，达到这样的期望是比较合理的：
1、能够对密码试探工具进行防范；
2、能够防范对cookie攻击等常用攻击手段；
3、敏感数据保证不用明文传输；
4、能防范通过文件名猜测和查看HTML文件内容获取重要信息；
5、能保证在网站收到工具后在给定时间内恢复，重要数据丢失不超过1个小时；

最后补充一点，浏览器的漏洞也可能会导致网站的不安全。

LR在选项中设置了选择中文，可以看到  web_add_auto_header("Accept-Language", "zh-cn");

Process：
%Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%
Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。  

Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：
Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：
Physical Disk\ % Disk Time
Physical Disk\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。
Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process(process_name)\ Pool Nonpaged Bytes。
Pages per second :每秒钟检索的页数。该数字应少于每秒一页。

监视IIS需要的一些计数器

Internet Information Services Global:
File Cache Hits %、File CacheFlushes、File Cache Hits
File Cache Hits %是全部缓存请求中缓存命中次数所占的比例，反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值，File CacheFlushes 是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值，可以得到一个适当的刷新值（参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize）
Web Service:
Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
Connection Refused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404） 

ramp down有助于检测内存泄露和系统恢复

具体配置如下：
配置LoadRunner监控Apache,LoadRunner监控Apache服务器是调用的Apache自身的模块进行监控的，所以需要配置Apache和LoadRunner

一.配置LoadRunner
1.在图树中单击 Apache 图，并将该图拖进“运行”视图的右窗格中。
2.右键单击该图，然后选择“添加度量”，或选择“监视器”>“添加联机度量”。
3.在“Apache”对话框的“监视的服务器计算机”部分，单击“添加”输入要监
视计算机的服务器名或 IP 地址。选择计算机运行的平台，单击“确定”。
4.在“Apache”对话框的“资源度量”部分中，单击“添加”选择要监视的度量。
将打开“Apache - 添加度量”对话框，显示可用的度量和服务器属性。
5.在“服务器属性”部分，输入端口号和不带服务器名的 URL，并单击“确定”。
默认的 URL 是 /server-status?auto。
6.在“Apache”对话框中单击“确定”，激活监视器。
二.配置Apache
1.修改Apache中Httpd.conf文件，添加如下代码（该文件中都有，只要取消注释就好了）
<Location /server-status>
    SetHandler server-status
    Order deny,allow
#    Deny from all
    Allow from .localhost
</Location>
2.添加 ExtendedStatus
  设置  ExtendedStatus On
3.取消注释LoadModule status_module modules/mod_status.so
   加载该模块。
4.重新启动Apache 
备注：因为51testing网站也是用apache，这里正好借着解决51testing学员的问题而在这里发布， 转自学员专版 连接 http://bbs.51testing.com/forumdisplay.php?fid=118&page=1