❶ WEB测试应该注意哪些地方，怎样才能做好WEB
基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。
随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。
Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。
在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。
一、功能测试
1、链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
2、表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、javascript、 ActiveX、VBScript或Perl等也要进行验证。
5、数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用sql对信息进行处理。在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
二、性能测试
1、连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
3、压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。压力测试的区域包括表单、登陆和其他信息传输页面等。
三、可用性测试
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。
4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
四、客户端兼容性测试
1、平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、javascript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，javascript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
五、安全性测试
Web应用系统的安全性测试区域主要有：
（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
六、总结
本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。
❷ 如何利用VS2013 做Web性能测试和负载测试67
定义测试策略 到目前为止，您肯定参加过这样的会议，客户倚靠在宽大的会议桌上，问您：“这个系统能处理上千个用户吗？”传统的负载测试方法要求您编写脚本并执行测试，以试图给出此问题的精确答案。对于这种测试，您需要定义“处理”的含义以及 100...
❸ 如何测试web服务器的网速
电脑进入运行程序，输入CMD，然后键入ping+空格+你的IP地址（+号无需输入），按回车键就可以了。
如果是联通宽带用户，可登陆网上营业厅www.10010.com 后，首页点击“我的联通”-“便民服务”-“宽带测速”，即可根据页面提示信息进行测速。也可以使用宽带号码登录联通手机营业厅客户端——查询——宽带业务查询——立即测试（“宽带测速”业务不支持免流）。
温馨提示：以上路径以网上营业厅实际显示信息为准。
❹ 如何对Web应用程序进行负载测试
定义测试策略 到目前为止，您肯定参加过这样的会议，客户倚靠在宽大的会议桌上，问您：“这个系统能处理上千个用户吗？”传统的负载测试方法要求您编写脚本并执行测试，以试图给出此问题的精确答案。对于这种测试，您需要定义“处理”的含义以及 1000 名典型用户在站点活动时的情形。您需要定义测试用例以代表各种用户活动：例如，购买股票或注册新的帐户。接下来，您必须估计用户在这些测试用例上的分布。对以下数据进行假设，即模拟真实用户与应用程序交互时，需要多长的思考时间（或等待时间）。因此，负载测试期间活动的可从某个方面大致反映出同样数量的真实用户在站点活动时的情形。 这种方法有几个不足之处。首先，其结果不会比您做的假设更好。显然，不正确的假设将使结果出现偏差。 其次，估计真实用户需要大量客户端硬件。如果对每名虚拟用户给定需要的处理能力和内存量，则典型的客户端计算机可以处理大约 200 名虚拟用户。因此，对 2000 名用户并发处理级别的测试需要 10 台客户端计算机 — 这是一笔重大投资。测试使用 HTTPS 的站点将需要多得多的客户端硬件。 最终，此方法难以向您的开发团队提供以操作为导向的信息。当某处出现故障时，常常难以再现该问题。 作为备选方案，我们建议您围绕以下这些关键问题设计测试用例： �6�1 系统瓶颈在哪里？系统能同步处理多少个并发请求？ �6�1 在响应时间变得不可接受之前，一台机器能处理多少名不同步的超级用户？ �6�1 添加额外的硬件时，结果是线形增长的吗？ �6�1 有任何稳定性问题会妨碍站点运行于生产环境中吗？ 此方法将使用开发团队（此开发团队参与可能出现问题的领域）提供的附加信息。请关注这些领域。对于上一个示例，其瓶颈可能出在定单提交领域。从这里您可以派生出更具体的问题，例如“提交流程可以同时处理多少个请求？”攻击这些特定领域是最快且成本最小的方法，用来向开发团队提供以操作为导向的信息，以便他们能改进系统。在使用这种方法的同时，我们推荐您记住遵循以下建议。 关注负载测试正如我们已提到的那样，首先要做的是构建导致潜在瓶颈和稳定性问题的脚本。这种“数据第一，假设第二”的方法使您能够从应用程序收集原始数据，然后根据假设确定更高级别的结果。不用担心为识别低风险站点的脚本编写问题。例如，为站点的帮助领域或只读文档领域编写脚本不大可能出现系统瓶颈。 同步请求使用同步请求攻击瓶颈。此处的这个主意是模拟最坏的情况：即，站点上的用户精确地在同一时间攻击瓶颈。通过使用户同步，您可以重复进行此测试。如果不同步结果，则难以再现故障情况。可以使用同步点做到这一点，同步点是大多数较健壮（成本也较高）的测试工具中提供的一项功能。同步点迫使每名虚拟用户一直等到剩余的用户到达脚本中定义的点后，才能开始下一请求。它允许您精确并重复地确定站点的潜在瓶颈区域能处理的并发用户数。例如，下限可以是 7 名并发同步用户。 创建循环测试用例脚本使测试用例循环。在另一种方法中，每次测试用例迭代前后，站点应处于相同状态。这允许您长时间地重复运行测试用例。 使用超级用户最后，使用我们所称的超级用户。正如前面所提到的，超级用户运行时思考时间设置为零。请记住，思考时间假设是用于常规测试中，以使虚拟用户模拟真实用户。但是，如果将虚拟用户思考时间减半，则服务器的实际负载将加倍。在另一种方法中，服务器真正关心的与负载有关的变量是每秒的请求数。虚拟用户的数量及其思考时间结合起来生成该负载。 让我们进行一些数学运算以使此概念更清晰。下面的公式计算访问站点的真实用户生成的负载（请求数/秒）： 例如，某个站点有 100 名并发用户，假设下载时间为 10 秒，思考时间为 30 秒，则每秒将生成 2.5 页。如果我们假设每页 3 个请求，则在 Web 服务器上将转化为每秒 7.5 个请求。 以超级用户运行测试时，观察每秒请求数，并与刚刚计算的值比较。根据我们的经验，真实用户数与超级用户数的比例通常约为 15:1。对于同一个示例，这意味着 (100/15) 名超级用户将生成与 100 名普通用户相同的负载。再举一个例子，假设在 10 名超级用户之后响应时间变得不可接受。请注意转换回真实用户数的该点每秒请求数。现在您可以进行任何希望的思考时间假设，甚至可以更改它而无需重新运行测试。在几天的测试之后，您将能根据直觉从超级用户数转换成真实用户数。此方法允许您保持用户数可控，减少所需的客户端硬件数量，并包含负载测试软件的成本。 这些超级用户测试用例对于多机测试很有用。要测试站点的可伸缩性，可添加第二台 Web 服务器和一个负载平衡器，并重复超级用户测试。理想情况下，在看见相同的相应次数之前，您将能加倍超级用户数量。 要回答稳定性问题，可运行测试，以在延长的时间段内维持合理数量的并发且未同步超级用户。我们在上一个项目中熬了很多个通宵，甚至 24 小时昼夜不停，但持续时间与应用程序有关。我们称之为“内置”测试。一旦您已采取步骤识别并潜在地解决了找到的瓶颈，则重复同步点测试，看下限是否有所增长。然后用所支持的新的并发用户数重新运行“内置”测试。以努力提高此数字为目标重复该循环，直到达到质量条。 但是有多少用户呢？ 尽管此方法向开发团队提供了有价值的信息，但它使得您更难于回答会议室的问题。不过，您可以近似地估计答案。例如，假设站点的最坏情况瓶颈显示，每台计算机多于 20 名超级用户的情况下，响应时间超过 10 秒。根据您从我们建议的公式计算的结果，近似地估计有 300 名真实用户（20 名超级用户 × 15 名真实用户）。此时，您可以做出与常规用例中相同的假设。通常情况下，有百分之多少的用户正在使用站点的此领域？假设预期 50% 的用户正在使用此领域，而其他领域，例如文档或数据库读取，用户比例则没有这么大。这意味着具有一台 Web 服务器的系统将处理大约 600 名用户。 到目前为止，我们已讨论了在能明确地指向站点的一个瓶颈领域的情况下该如何做，但如果影响性能的领域不止一个时您又应如何做呢？答案是创建单独查看各个领域的测试脚本。首先孤立地运行这些脚本，然后一起运行。再比较结果，看站点的一个领域对另一个领域的影响有多大。
❺ 如何配置Web服务器实现负载均衡
网络的负载均衡是一种动态均衡技术，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理均衡地分配出去。这种技术基于现有网络结构，提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法，加强了网络数据处理能力，提高了网络的灵活性和可用性。
以四台服务器为例实现负载均衡：
安装配置LVS
1. 安装前准备：
(1)首先说明，LVS并不要求集群中的服务器规格划一，相反，可以根据服务器的不同配置和负载状况，调整负载分配策略，充分利用集群环境中的每一台服务器。如下表：
Srv Eth0 Eth0：0 Eth1 Eth1：0
vs1 10.0.0.1 10.0.0.2 192.168.10.1 192.168.10.254
vsbak 10.0.0.3 192.168.10.102
real1 192.168.10.100
real2 192.168.10.101
其中，10.0.0.2是允许用户访问的IP。
(2)这4台服务器中，vs1作为虚拟服务器(即负载平衡服务器)，负责将用户的访问请求转发到集群内部的real1，real2，然后由real1，real2分别处理。
Client为客户端测试机器，可以为任意操作系统。
(3)所有OS为redhat6.2，其中vs1 和vsbak 的核心是2.2.19， 而且patch过ipvs的包， 所有real
server的Subnet mask 都是24位， vs1和vsbak 的10.0.0. 网段是24 位。
2.理解LVS中的相关术语
(1) ipvsadm ：ipvsadm是LVS的一个用户界面。在负载均衡器上编译、安装ipvsadm。
(2) 调度算法： LVS的负载均衡器有以下几种调度规则：Round-robin，简称rr;weighted
Round-robin，简称wrr;每个新的连接被轮流指派到每个物理服务器。Least-connected，简称lc;weighted
Least-connected，简称wlc，每个新的连接被分配到负担最小的服务器。
(3) Persistent client
connection，简称pcc，(持续的客户端连接，内核2.2.10版以后才支持)。所有来自同一个IP的客户端将一直连接到同一个物理服务器。超时时间被设置为360秒。Pcc是为https和cookie服务设置的。在这处调度规则下，第一次连接后，所有以后来自相同客户端的连接(包括来自其它端口)将会发送到相同的物理服务器。但这也会带来一个问题，因为大约有25%的Internet
可能具有相同的IP地址。
(4) Persistent port
connection调度算法：在内核2.2.12版以后，pcc功能已从一个调度算法(你可以选择不同的调度算法：rr、wrr、lc、wlc、pcc)演变成为了一个开关选项(你可以让rr、
wrr、lc、wlc具备pcc的属性)。在设置时，如果你没有选择调度算法时，ipvsadm将默认为wlc算法。 在Persistent port
connection(ppc)算法下，连接的指派是基于端口的，例如，来自相同终端的80端口与443端口的请求，将被分配到不同的物理服务器上。不幸的是，如果你需要在的网站上采用cookies时将出问题，因为http是使用80端口，然而cookies需要使用443端口，这种方法下，很可能会出现cookies不正常的情况。
(5)Load Node Feature of Linux Director：让Load balancer 也可以处理users 请求。
(6)IPVS connection synchronization。
(7)ARP Problem of LVS/TUN and LVS/DR：这个问题只在LVS/DR，LVS/TUN 时存在。
3. 配置实例
(1) 需要的软件包和包的安装：
I. piranha-gui-0.4.12-2*.rpm (GUI接口cluster设定工具);
II. piranha-0.4.12-2*.rpm;
III. ipchains-1.3.9-6lp*.rpm (架设NAT)。
取得套件或mount到光盘，进入RPMS目录进行安装:
# rpm -Uvh piranha*
# rpm -Uvh ipchains*
(2) real server群：
真正提供服务的server(如web
server)，在NAT形式下是以内部虚拟网域的形式，设定如同一般虚拟网域中Client端使用网域：192.168.10.0/24
架设方式同一般使用虚拟IP之局域网络。
a. 设网卡IP
real1 ：192.168.10.100/24
real2 ：192.168.10.101/24
b.每台server均将default gateway指向192.168.10.254。
192.168.10.254为该网域唯一对外之信道，设定在virtual server上，使该网域进出均需通过virtual server 。
c.每台server均开启httpd功能供web server服务，可以在各real server上放置不同内容之网页，可由浏览器观察其对各real
server读取网页的情形。
d.每台server都开启rstatd、sshd、rwalld、ruser、rsh、rsync，并且从Vserver上面拿到相同的lvs.conf文件。
(3) virtual server：
作用在导引封包的对外主机，专职负责封包的转送，不提供服务，但因为在NAT型式下必须对进出封包进行改写，所以负担亦重。
a.IP设置：
对外eth0：IP：10.0.0.1 eth0：0 ：10.0.0.2
对内eth1：192.168.10.1 eth1：0 ：192.168.10.254
NAT形式下仅virtual server有真实IP，real server群则为透过virtual server.
b.设定NAT功能
# echo 1 >; /proc/sys/net/ipv4/ip_forward
# echo 1 >; /proc/sys/net/ipv4/ip_always_defrag
# ipchains -P forward MASQ
c.设定piranha 进入X-window中 (也可以直接编辑/etc/lvs.cf )
a).执行面板系统piranha
b).设定“整体配置”(Global Settings) 主LVS服务器主机IP：10.0.0.2， 选定网络地址翻译(预设) NAT路径名称：
192.168.10.254， NAT 路径装置： eth1：0
c).设定虚拟服务器(Virtual Servers) 添加编辑虚拟服务器部分：(Virtual
Server)名称：(任意取名);应用：http;协议： tcp;连接：80;地址：10.0..0.2;装置：eth0：0; 重入时间：180
(预设);服务延时：10 (预设);加载监控工具：ruptime (预设);调度策略：Weighted least-connections; 持续性：0
(预设); 持续性屏蔽： 255.255.255.255 (预设); 按下激活：实时服务器部分：(Real Servers); 添加编辑：名字：(任意取名);
地址： 192.168.10.100; 权重：1 (预设) 按下激活
另一架real server同上，地址：192.168.10.101。
d). 控制/监控(Controls/Monitoring)
控制：piranha功能的激活与停止，上述内容设定完成后即可按开始键激活piranha.监控器：显示ipvsadm设定之routing table内容
可立即更新或定时更新。
(4)备援主机的设定(HA)
单一virtual server的cluster架构virtual server 负担较大，提供另一主机担任备援，可避免virtual
server的故障而使对外服务工作终止;备份主机随时处于预备状态与virtual server相互侦测
a.备份主机：
eth0： IP 10.0.0.3
eth1： IP 192.168.10.102 同样需安装piranha，ipvsadm，ipchains等套件
b.开启NAT功能(同上面所述)。
c.在virtual server(10.0.0.2)主机上设定。
a).执行piranha冗余度 ;
b).按下“激活冗余度”;
冗余LVS服务器IP： 10.0.0.3;HEARTBEAT间隔(秒数)： 2 (预设)
假定在…秒后进入DEAD状态： 5 (预设);HEARTBEAT连接端口： 539 (预设)
c).按下“套用”;
d).至“控制/监控”页，按下“在当前执行层添加PULSE DEAMON” ，按下“开始”;
e).在监控器按下“自动更新”，这样可由窗口中看到ipvsadm所设定的routing table，并且动态显示real
server联机情形，若real server故障，该主机亦会从监视窗口中消失。
d.激活备份主机之pulse daemon (执行# /etc/rc.d/init.d/pulse start)。
至此，HA功能已经激活，备份主机及virtual server由pulse daemon定时相互探询，一但virtual
server故障，备份主机立刻激活代替;至virtual server 正常上线后随即将工作交还virtual server。
LVS测试
经过了上面的配置步骤，现在可以测试LVS了，步骤如下：
1. 分别在vs1，real1，real2上运行/etc/lvs/rc.lvs_dr。注意，real1，real2上面的/etc/lvs
目录是vs2输出的。如果您的NFS配置没有成功，也可以把vs1上/etc/lvs/rc.lvs_dr复制到real1，real2上，然后分别运行。确保real1，real2上面的apache已经启动并且允许telnet。
2. 测试Telnet：从client运行telnet 10.0.0.2，
如果登录后看到如下输出就说明集群已经开始工作了：(假设以guest用户身份登录)
[guest@real1 guest]$——说明已经登录到服务器real1上。
再开启一个telnet窗口，登录后会发现系统提示变为：
[guest@real2 guest]$——说明已经登录到服务器real2上。
3. 测试http：从client运行iexplore http://10.0.0.2
因为在real1 和real2 上面的测试页不同，所以登录几次之后，显示出的页面也会有所不同，这样说明real server 已经在正常工作了。
❻ Web测试的主要内容和测试方法有哪些
1功能测试 2 1.1链接测试 2 1.2表单测试 2 1.3数据校验 3 1.4 cookies测试 3
1功能测试 2
1.1链接测试 2
1.2表单测试 2
1.3数据校验 3
1.4 cookies测试 3
1.5数据库测试 3
1.6应用程序特定的功能需求 4
1.7设计语言测试 4
2性能测试 4
2.1连接速度测试 4
2.2负载测试 4
2.3压力测试 5
3用户界面测试 6
3.1导航测试 6
3.2图形测试 6
3.3内容测试 7
3.4表格测试 7
3.5整体界面测试 7
4兼容性测试 8
4.1平台测试 8
4.2浏览器测试 8
4.3分辨率测试 8
4.4 Modem/连接速率 9
4.5打印机 9
4.6组合测试 9
5安全测试 9
5.1目录设置 9
5.2登录 10
5.3日志文件 10
5.4脚本语言 10
6接口测试 10
6.1服务器接口 10
6.2外部接口 11
6.3错误处理 11
7结论 11
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术
❼ Web应用的测试内容都包括哪些方面
1、通用指标
指Web应用服务器、数据库服务器必需测试项，包括：处理器时间：指服务器CPU占用率，一般平均达到70%时，服务就接近饱和。可用内存数：如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重。物理磁盘读写时间。
2、Web服务器指标
平均每秒响应次数为总请求时间与秒数之比。平均每秒业务脚本的迭代次数。成功的请求和失败的请求。成功的点击次数和失败的点击次数。每秒点击次数、每秒成功的点击次数和每秒失败的点击次数。尝试连接数。
3、数据库服务器指标
用户连接数，也就是数据库的连接数量。数据库死锁量。数据库缓存的命中情况。
(7)vsweb负载测试扩展阅读
对被测的Web应用程序进行需求分析，即对所做的测试作一个简要的介绍，包括描述测试的目标和范围，所测试的目标要实现一个什么样的功能，总结基本文档、主要活动。
写出测试策略和方法，这里包括测试开始的条件、测试的类型、测试开始的标准以及所测试的功能、测试通过或失败的标准、结束测试的条件、测试过程中遇到什么样的情况终止和怎么处理后恢复等。
一个Web应用程序由完成特定任务的各种Web组件（web components)构成的并通过Web将服务展示给外界。在实际应用中，Web应用程序由多个Servlet、JSP页面、HTML文件以及图像文件等组成。所有这些组件相互协调为用户提供一组完整的服务。
❽ Visual studio2013使用时无法打开负载测试结果数据库，求大神支招
在进行负载测试时，很多同学遇到可能地遇到一个错误“无法打开负载测试结果数据库”，针对这种错误，解决方案大致如下：
1.打开 Visual Studio 命令提示
a.输入"cd.."命名返回上一级目录
b.输入"cd Common7/IDE"命名查找到对应的目录
2.打开服务管理器并启动"SQL Server (SQLEXPRESS)"服务
3.在VS命令提示内键入以下指令：
SQLCMD /S localhost/sqlexpress /i loadtestresultsrepository.sql
警告
参数区分大小写。必须键入大写的 S 和小写的 i。
也可以选择将数据库安装到任何现有的 SQL 服务器上。例如，如果您有一个名为 ContosoServer1 的 SQL 服务器，则可以使用以下命令：
SQLCMD /S ContosoServer1 -i loadtestresultsrepository.sql
可能还需要指定用户名和密码，以便可以连接到 ContosoServer1。在这种情况下，应使用下面的命令：
SQLCMD /S ContosoServer1 -U <用户名> -P <密码> -i loadtestresultsrepository.sql
警告
参数区分大小写。必须键入大写的 S、U 和 P，以及小写的 i。
4.在“测试”菜单上，单击“管理测试控制器”。将显示“管理测试控制器”对话框。
5.在“服务器名称”中，键入 localhost/sqlexpress 或您在第 2 步中使用的服务器的名称（例如 ContosoServer1）。
6.在“登录到服务器”下，选择“使用 Windows 身份验证”。
7.在“连接到数据库”下，选择“选择或输入一个数据库名”。从下拉列表框中选择“LoadTest”。
8.单击“确定”。
9.在“管理测试控制器”对话框中单击“关闭”。
转于：http://blog.csdn.net/279503482/article/details/6007173
❾ 怎样正确做 Web 应用的压力测试
关于工具的选择
其实工具并不是最重要的，那么多的测试工具，HP的是LoadRunner、IBM的是Rational Performance Tester、Apache有Jmeter（免费开源）、还有Borland的SilkPerformer，这些都是可以的。有人提到了Apache的AB，AB不是说不行的，但既然问题是"正确的压力测试"，那么还是选择一个那些容易支撑起复杂业务的性能场景的工具吧。
什么样的工具能够在脚本中让你模拟业务场景中一个用户的行为？什么样的工具能够在场景中让你模拟业务场景中一群用户的行为？什么样的工具能够让你模拟用户所处于的使用环境？什么样的工具能够让你比较方便、快捷的通过它的性能图表了解Web应用的大致性能表现？答案肯定不会是那些对某个URL不断施压的那些工具。
关于场景的设计过程
过半数的性能测试人员并不了解自己执行的性能测试场景代表的是用户生产环境中什么样的场景。事实很难正确的说清楚“性能测试”、“负载测试”、“压力测试”、“可靠性测试”、“配置测试”、“疲劳测试”这些测试的概念。
任何一个场景的设计都必须首先明确一些相关的性能指标，这些指标的阈值一旦被超出，那么场景一般是不必继续执行的。
关于性能指标我们可以几个角度来看：
首先是用户视角的性能指标，一般来说这些指标包括了测试事务的平均响应时间、最大响应时间、90%事务的响应时间、事务响应时间标准差，我们通过着一些指标来判断用户实际获得的性能体验如何。然后是运维视角指标，点击率、吞吐量、处理能力、各种硬件资源占用、运维通过这些指标来了解目前应用的处理能力，通过业务增长了解何时需要进行扩容，还有开发视角的指标，锁竞争。具体要考虑的视角由项目干系人、关键角色定义。
采用的指标确定好以后，再开始为这些指标定义阈值，例如事务的响应时间，也许用户认为请求在2秒以内得到响应是满意的，5秒以内响应是一般，超出8秒则会感觉太慢，超出10秒会超出了可容忍的上限，那么对于这一项指标来说，它的阈值可以是：
<2秒响应，优秀
<5秒响应，良好
<8秒响应，较差
>10秒响应，超出可容忍上线
关于用户性能体验的指标一般会划分为4个级别。硬件指标至少也会划分2个级别。
系统在任何时候都应该为用户提供优秀的响应体验吗？并不总是，在2倍的峰值负载中，我认为良好、甚至较差的响应体验也是可接受的。那是不是说在正常的峰值负载中，各项指标表现不在优秀范围内就是不理想呢？也不一定，要看正常的峰值负载持续时间长短是否合理。
场景的设计不合理最终将可能导致我们面对一堆性能缺陷无法确定处理的优先级。
场景设计中，重点考虑的问题：
脚本测试数据符合典型用户的数据差异（测试帐号差异、操作数据差异、提交表单参数差异等）
脚本操作次序符合典型用户的操作差异（思考时间、业务间间隔等）；
脚本执行符合典型用户的使用环境（浏览器缓存模拟、带宽模拟等）；
测试环境的业务基础数据必须合理（0年到N年的基础数据）；
测试场景所产生的负载必须合理（代表峰值的负载？代表1.5倍峰值的负载？代表促销活动的负载？）。
一般都是使用工具，可以模拟多用户 同时/异步地进行比较好的工具，要钱的有loadrunner ，不要钱的有JMeter 。这2种工具都能自动生成图形报告。这样你就能判断出服务器的瓶颈在哪里。是需要增加内存还是提高处理器性能，或者增加硬盘。
❿ Web测试的主要内容和测试方法有哪些
测试分类：
1、界面测试
1）给用户的整体感：舒适感；凭感觉能找到想要找的信息；设计风格是否一致
2）各控件的功能
2、功能测试
1）删除/增加某一项：是否对其他项造成影响，这些影响是否都正确
2）列表默认值检查
3）检查按钮功能是否正确：新建、编辑、删除、关闭、返回、保存、导入、上一页、下一页、页面跳转、重置（常见错误）
4）字符串长度检查：超出长度
5）字符类型检查
6）标点符号检查：空格、各种引号、Enter键
7）特殊字符：常见%、“、”
8）中文字符：是否乱码
9）检查信息完整：查看信息，查看所填信息是否完整更新；更新信息，更新信息与添加信息是否一致
10）信息重复：需唯一信息处，比如重复的名字或ID、重名是否区分大小写、加空格
11）检查删除功能：不选择任何信息，按Delete，看如何处理；选择一个或多个进行删除；多页选、翻页选删除；删除是否有提示
12）检查添加和修改是否一致：添加必填项，修改也该必填；添加为什么类型，修改也该什么类型
13）检查修改重名：修改时把不能重名的项改为已存在的内容
14）重复提交表单：一条已经成功提交的记录，返回后再提交
15）检查多次使用返回键：返回到原来页面，重复多次
16）搜索检查：存在或不存在内容，看搜索结果是否正确；多个搜索条件，同时输入合理和不合理条件；特殊字符
17）输入信息的位置
18）上传下载文件检查：功能是否实现，
上传：上传文件是否能打开、格式要求、系统是否有解释信息、将不能上传的文件格式修改后缀为可上传的文件格式；
下载：下载是否能打开、保存、格式要求
19）必填项检查：必填项未填写；是否有提示，如加*；对必填项提示返回后，焦点是否自动定位到必填项
20）快捷键检查：是否支持快捷键Ctrl+C、Ctrl+V、backspace；对不允许做输入的字段（如：下拉选项），对快捷方式是否也做了限制
21）Enter键检查：输入结束后按Enter键，系统如何处理
22）刷新键检查：按浏览器刷新键如何处理
23）回退键检查：按浏览器回退键如何处理
24）空格检查：输入项输入一个或多个空格
25）输入法半角全角检查：比如，浮点型，输入全角小数点“。”或“. ”，如4. 5；全角空格
26）密码检查：输入加密方式的极限字符；密码尽可能长
27）用户检查：不同种类管理员用户的不同权限，是否可以互相删除、管理、编辑；一般用户的权限；注销功能，老用户注销再注册，是否为新用户
28）系统数据检查：数据随业务过程、状态的变化保持正确，不能因为某个过程出现垃圾数据，也不能因为某个过程而丢失数据。
29）系统可恢复性检查：以各种方式把系统搞瘫，测试系统是否可以迅速恢复
30）确认提示检查：系统更新、删除操作：是否有提示、取消操作；提示是否准确；事前、事后提示
31）数据注入检查：对数据库注入，特殊字符，对SQL语句进行破坏
32）时间日期检查：时间、日期、时间验证：日期范围是否符合实际业务；对于不符合实际业务的日期是否有限制
33）多浏览器验证
3、性能测试
1）压力测试：实际破坏一个Web应用系统，测试系统的反应，测试系统的限制和故障恢复能力
2）负载测试：在某一负载级别上的性能，包括某个时刻同时访问Web的用户数量、在线数据处理的数量
3）强度测试：测试对象在性能行为异常或极端条件下（如资源减少或用户过多）的可接受性，以此验证系统软硬件水平
4）数据库容量测试：通过存储过程往数据库表中插入一定数量的数据，看是否能及时显示
5）预期指标的性能测试：在需求分析和设计阶段会提出一些性能指标，对于预先确定的性能要求要首先进行测试
6）独立业务性能测试：对核心业务模块做用户并发测试，包括同一时刻进行完全一样的操作、同一时刻使用完全一样的功能
7）组合业务性能测试：模拟多用户的不同操作，最接近实际用户使用情况，按用户实际的实际使用人数比例来模拟各个模块的组合并发情况
8）疲劳强度性能测试：系统稳定运行情况下，以一定负载压力来长时间运行系统的测试
9）网络性能测试：准确展示带宽、延迟、负载、端口的变化是如何影响用户的相应时间的
10）大数据量性能测试：实时大数据量，模拟用户工作时的实时大数据量；极限状态下的测试，系统使用一段时间，积累一段数据量时能否正常运行，以及对前面两种进行结合
11）服务器性能测试：在进行用户并发性能测试、疲劳强度、大数据量性能测试时，完成对服务器性能的监控，并进行评估
12）一些特殊的测试：配置测试、内存泄漏的一些特殊测试
4、可用性测试(接口测试）
1）整体界面测试
2）多媒体测试
3）导航测试
5、客户端兼容性
平台测试：windows；unix；macintosh；linux
浏览器测试：不同厂商的浏览器对Java、Javascript、ActiveX、plug-ins或不同的HTML的规格
不同的支持；框架和层次结构在不同浏览器也不同的显示
6、安全性
安全性测试要求：
1）能够对密码试探工具进行防范
2）能够防范对Cookie攻击的常用手段
3）敏感数据保证不用明文传输
4）能防范通过文件名猜测和查看html文件内容获取重要信息
5）能保证在网站收到工具后在给定时间内恢复，重要数据丢失不超过1小时
web的性能测试工具：
随着Web2.0技术的迅速发展，许多公司都开发了一些基于Web的网站服务，通常在设计开发Web应用系统的时候很难模拟出大量用户同时访问系统的实际情况。
因此，当Web网站遇到访问高峰时，容易发生服务器响应速度变慢甚至服务中断。
为了避免这种情况，需要一种能够真实模拟大量用户访问Web应用系统的性能测试工具进行压力测试，来测试静态HTML页面的响应时间，甚至测试动态网页（包括ASP、PHP、JSP等）的响应时间，为服务器的性能优化和调整提供数据依据。
1、企业级自动化测试工具WinRunner
MercuryInteractive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。
2、工业标准级负载测试工具Loadrunner
LoadRunner是一种预测系统行为和性能的负载测试工具
3、全球测试管理系统testdirector
TestDirector是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。
4、功能测试工具RationalRobot
IBMRationalRobot是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。
它集成在测试人员的桌面IBMRationalTestManager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。
这种测试和管理的双重功能是自动化测试的理想开始。
5、单元测试工具xUnit系列
目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit（Delphi），NUnit（.net），PhpUnit（Php）等等。
该测试框架的第一个和最杰出的应用就是由ErichGamma（《设计模式》的作者）和KentBeck（XP（ExtremeProgramming）的创始人）提供的开放源代码的JUnit.
6、功能测试工具SilkTest
BorlandSilkTest2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。
这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。
7、性能测试工具WAS
是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。
透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。
8、自动化白盒测试工具Jtest
Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。
parasoft同时出品的还有C++test，是一款C/C++白盒测试工具。
9、功能和性能测试的工具JMeter
JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。
10、性能测试和分析工具WEBLOAD
webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能。
(10)vsweb负载测试扩展阅读：
漏洞测试
企业网站做的越来越复杂、功能越来越强。不过这些都不是凭空而来的，是通过代码堆积起来的。如果这个代码只供企业内部使用，那么不会带来多大的安全隐患。
但是如果放在互联网上使用的话，则这些为实现特定功能的代码就有可能成为攻击者的目标。
天眼举一个简单的例子。在网页中可以嵌入SQL代码。而攻击者就可以利用这些SQL代码来发动攻击，来获取管理员的密码等等破坏性的动作。
有时候访问某些网站还需要有某些特定的控件。用户在安装这些控件时，其实就有可能在安装一个木马（这可能访问者与被访问者都没有意识到）。
为此在为网站某个特定功能编写代码时，就要主动出击。从编码的设计到编写、到测试，都需要认识到是否存在着安全的漏洞。
天眼在日常过程中，在这方面对于员工提出了很高的要求。各个员工必须对自己所开发的功能负责。
已知的病毒、木马不能够在所开发的插件中有机可乘。通过这层层把关，就可以提高代码编写的安全性。