要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？ 5.3 登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面？ Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。 5.4 日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗? 5.5 脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。 6 接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。 6.1服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中 6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。 这种情况在远程抄表中可能会体现到 6.3 错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
26
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。
7 结论
无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。
16. 理解web性能测试术语
在软件系统日益复杂的今天，性能已经成为软件质量的重要衡量标准之一，这一点尤其体现在和WEB相关的系统上。接下来介绍一些WEB性能测试中的术语，这些术语都是WEB性能测试中出现频繁的比较高的词汇，只有掌握这些基础的性能知识才可以进一步开展测试工作。这些术语主要有并发用户，并发用户数量，请求响应时间，事务响应时间，吞吐量，吞吐率，TPS，点击率，资源利用率等。
并发用户：并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。
另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。 可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
用户并发数量：关于用户并发的数量，有2种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，但是，在线用户数量是计算并发用户数量的主要依据之一。
请求响应时间：指的是客户端发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被成为\，即\to last byte\意思是从发起一个请求开始，到客户端接收到最后一个字节的响应时间所耗费的时间。请求响应时间过程的单位一般为\秒\或者\毫秒\
事务响应时间:事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数. 吞吐量:指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.
TPS:每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标. 点击率:每秒钟用户向WEB服务器提交的HTTP请求数.这个指标是WEB应用特有的一
27
个指标:WEB应用是\请求-响应\模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求.
资源利用率:指的是对不同的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,因此是WEB性能测试工作的重点.
资源利用率主要针对WEB服务器,操作系统,数据库服务器,网络等,是测试和分析瓶颈的主要参考.在WEB性能测试中,更根据需要采集相应的参数进行分析.
17. Web安全测试入门
18. 测试工作总结
19. Web应用系统易出问题的原因和测试要点
web应用系统是目前最常见的应用系统之一，例如电子商务网站，就是一种典型的web应用系统，关于测试要点，我认为可以有以下几点：
当我们在进行web应用系统的测试时，我们可以做这样一个假设：如果我们是某个电子商务网站的用户，我们会对这个网站有哪些期望呢？
1,有足够的性能，不要在并发用户很多的时候响应速度很慢；
2,有足够好的兼容性，当我们使用IE以外的浏览器的时候，网站仍旧能够正常使用； 3,有足够的安全性。至少我们不希望自己的用户名和密码被别人轻易获得；
4,链接的正确性。当我们点击购买一本图书时，我们不希望出现的是是张CD的页面； 于是总结起来无外乎，性能，兼容性，安全性，正确性，我认为这是我们测试人员应该关注的要点。
这几方面容易出问题的原因，我想可能跟以下几点有关吧。
1,网站用户的数量可能在某个时间段迅速增加，其增加的速度和用户的总数可能会超过当初设计的极限；
2,用户使用环境的复杂性，系统就有WINDOWS,LINUX和其他系统，浏览器又有IE ,FIREFOX ,NETSCAPE,OPERA等等；而有的用户显示器可能还仅仅支持800*600等等状况的复杂性；
3,网络的人为攻击，病毒泛滥等
4,在一个web页面存在大量的连接，且这些链接是在不断更新，难免会出现错误； 由于这些问题的存在，在编写测试计划和测试用例，搭建测试环境和执行测试时，我认为，应该基于web应用系统的测试时的特征，有针对性地进行测试工作。
另外，对于web应用系统来说，还可以分为服务器端测试和客户端测试两部分，毕竟web是由服务器端和客户端组成的。
我想，在服务器端，重点进行的应该是性能测试，负载测试和安全测试吧？！ 在客户端，则要在兼容性测试上做好工夫。
其实对于web，最普遍的性能测试应该是负载测试，通过负载测试，测试人员就可以知道系统如何完成预期的或者超过预期的行为。例如：某个电子商务网站设计时，考虑能同时在线的用户为5000人。那测试员就需要知道当同时在线5000人时，系统的响应状况，也要知道，如果在某个时间段同时在线用户超过系统设计值，假设达到了10000人，系统的响应情况。如果同时在线5000人时，系统响应速度很慢，以至于很少有用户有足够的耐心来等
28
待完成，那么我想这个web系统将不会被用户接受。
对web的性能测试，主要还是借助于测试工具，LoadRunner，我想，最好也是要系统学习一下的。
20. 使用JMeter测试web的应用 2.1 测试环境
作者使用了Tomcat作为Web服务器进行测试，被测试的内容是一个jsp文件和一个servlet，jsp文件调用JavaBean、打印相关信息，servlet接受用户参数、调用javabean、输出相关信息。详细的内容请参考作者提供的JMeter.war的内容。 2.2 安装启动JMeter 大家可以到通过http://apache.linuxforum.net/dist/jakarta/jmeter/binaries/jakarta-jmeter-1.9.1.zip下载JMeter的release版本，然后将下载的.zip文件解压缩到C:/JMeter（后面的文章中将使用%JMeter%来引用这个目录）目录下。
现在，请使用%JMeter%/bin下面的jmeter.bat批处理文件来启动JMeter的可视化界面，下面的工作都将在这个可视化界面界面上进行操作。下面的图片是JMeter的可视化界面的屏幕截图。
图一： JMeter打开时的屏幕截图
2.3 建立测试计划（Test Plan）
测试计划描述了执行测试过程中JMeter的执行过程和步骤，一个完整的测试计划包括一个或者多个线程组(Thread Groups)、逻辑控制（Logic Controller）、实例产生控制器（Sample Generating Controllers）、侦听器(Listener)、定时器（Timer）、比较（Assertions）、配置元素（Config Elements）。打开JMeter时，它已经建立一个默认的测试计划,一个JMeter应用的实例只能建立或者打开一个测试计划。
现在我们开始填充一个测试计划的内容，这个测试计划向一个jsp文件和一个servlet发出请求，我们需要JMeter模拟五个请求者（也就是五个线程），每个请求者连续请求两次，
29
下面的章节介绍了详细的操作步骤。 2.4 增加负载信息设置
这一步，我们将向测试计划中增加相关负载设置,是Jmeter知道我们需要模拟五个请求者，每个请求者在测试过程中连续请求两次。详细步骤如下：
1. 选中可视化界面中左边树的Test Plan节点，单击右键，选择Add'Thread Group，界面右边将会出现他的设置信息框。
2. Thread Group有三个和负载信息相关的参数： Number of Threads： 设置发送请求的用户数目
Ramp-up period： 每个请求发生的总时间间隔，单位是秒。比如你的请求数目是5，而这个参数是10，那么每个请求之间的间隔就是10／5，也就是2秒
Loop Count： 请求发生的重复次数，如果选择后面的forever（默认），那么 请求将一直继续，如果不选择forever，而在输入框中输入数字，那么请求将重复 指定的次数，如果输入0，那么请求将执行一次。
根据我们演示例子的设计，我们应该将Number of Threads设置为5，Ramp-up period设置为0（也就是同时并发请求），不选中forever，在Loop Count后面的输入框中输入2，设置后的屏幕截图如下：
图二：设置好参数的Thread Group。
2.5 增加默认Http属性（可选）
实际的测试工作往往是针对同一个服务器上Web应用展开的,所以Jmeter提供了这样一种设置, 在默认Http属性设置需要被测试服务器的相关属性，以后的http请求设置中就可以忽略这些相同参数的设置,减少设置参数录入的时间。
我们这里将采用这种属性。你可以通过下面的步骤来设置默认http属性：
1. 选中可视化界面中左边树的Test Plan节点，单击右键，选择Add'config element'http request defaults，界面右边将会出现他的设置信息框。 2. 默认http属性的主要参数说明如下： protocal：发送测试请求时使用的协议
server name or ip：被测试服务器的ip地址或者名字
path： 默认的起始位置。比如将path设置为／jmeter，那么所有的http请求的url中都将增加／jmeter路径。
port number： 服务器提供服务的端口号
我们的测试计划将针对本机的Web服务器上的Web应用进行测试，所以protocal应该是http，ip使用localhost，因为这个web应用发布的context路径是／jmeter，所以这里的
30