大体分为四个步骤：

1）创建soapui脚本并调试成功；</DIV> <DIV>这个就在这里不累述了

2）使用Soapui中的 TestRunner来完成测试脚本通过命令行的方式来执行

Launch TestRunner===>; 选择TestRunner的路径，一般都在安装路径下，配置好信息，选择导出结果，选择结果放置的路径；执行。拷贝运行命令，存到bat文件中。</DIV> <DIV>把bat文件所在路径设置到path中;

3）创建定时任务，运行命令:SCHTASKS /Create /SC HOURLY /MO 5 /TN rtest2 /TR clocktask.bat /ST 11:45:00 /SD 2011/03/04 /ED 2011/03/04

表示每5个小时运行一次该命令；

4）但是结果每次都被覆盖

处理：同事帮忙写了个jar，把生成的文件加上时间戳并保存到指定的文件夹。

上面的任务执行后3分钟，自动保存结果。

SCHTASKS /Create /SC HOURLY /MO 5 /TN rtest2 /TR clocktask.bat /ST 00:03:00 /SD 2011/03/04 /ED 2011/03/04

步骤四 为导航路径或模拟用户识别唯一性的数据

很不幸，光是导航路径不能提供所有的需要贯彻的负载模拟的信息。至于所有的可执行的负载模型，以下信息是需要的，包括：

用户在一个页面上停留多长时间？

每个页面需要什么样的数据？

用户在什么条件下变化导航路径？

下表提供了一个为电子商务应用提供识别唯一数据的例子。

需要考虑的事

在为导航路径或模拟用户识别唯一性的数据时，需要考虑以下关键事项：

• 性能测试一般需要消耗大量的测试数据，需要准备充足的测试数据；
• 重复使用相同的数据可能会导致无效的结果；
• 尤其是在设计和调试性能测试脚本的时候，可能会引起测试数据的过量负载，要提前检查，去掉干扰性能测试结果的一些垃圾数据；
• 在性能测试中要考虑到一些无效的数据。比如说，有的用户第一次输错了密码，第二次才输入了正确的登录了系统；
• 第一次登录的用户在页面上停留的时间要比经常使用该系统的用户停留的时间长；
• 最有可能的测试数据一般来自于真实的生产环境或者日志文件；
• 要考虑到客户端崩溃的情况。第一使用的用户要下载每个控件，而经常使用的用户则不需要多次下载，而且还有可能以前的一些操作结果存在缓存中。要考虑到他们的不同；

为关键场景确定导航路径

人的操作行为是不可预期的，网站一般提供多条路径到达相同的功能或者操作，相对较少数量的用户而言这一定是正确的：真实用户不仅会使用任何你想到的路径来完成他们的任务，他们也会创造出想不到的路径。用户完成某个操作的每条路径，在系统中都会形成不同的路。这些不同有可能是微不足道的也有可能是特别巨大的——除非是你来测试，不然没有办法确定。有很多办法确定你完成一个任务或者一个操作的导航路径，包括：

• Identify user paths within your Web application that are expected to have a significant performance impact and that accomplish one or more of the identified key scenarios.
• 阅读设计文档或者操作手册；
• 从日志文件中提取数据；
• 亲自尝试操作；
• 让别人来操作，看他的操作路径。

系统为用户可接受测试，beta 测试或者产品测试发布版本后，你就能够确定大多数用户是如何在被测系统中到达他要操作的功能。一般这样也是很不错的主意：把你的模型和真实情况相比较然后根据你发现的相似和不同来决定是否运行额外的测试。

需要考虑的事

• 当你为关键场景确定关键路径的时候，要考虑以下事项：
• 有些用户作为一个游客时可能操作了很多功能；
• 有些用户登录一次可能操作了很多次相同的功能；
• 可能有些用户在网站上作为游客没有真正执行任何功能；
• 导航路径一般可以通过页面标题来获得；
• 如果系统中页面标题不是很直观，那么可以系统给定的操作步骤来确定系统的导航路径；
• 和经常访问的用户不同，第一访问的用户一般会走一个不同的路径，在你的模型中应该考虑到这些不同和新老用户的百分比；
• 不同的用户操作习惯也会有很大的不同，有的操作登出，有的直接关闭窗口，也有的不管它让它自己超时，我们在考虑和估计session持续时间的时候一定要确保把这些因素考虑进去。

识别关键的用户场景

想要在性能测试中模拟用户可能的所有的操作，这是绝对不可能的，因此，不管你是从sever的日志中分析出来的，还是通过观察可用性研究的，还是从市场材料中得到的，甚至直接是靠猜的，你都有可能都是在把一些有限的尝试用到行为活动的数量中，或者为性能测试识别关键的场景。你会发现下面的有限尝试是非常有用的：

通过目标的暗示或规定来确定关键场景；

要包括最常用的操作；

要包括比较明显的操作；比如，一个用户可能仅仅在你的网站上注册了一次，因为感受体验不好，就再也没有来过。

要包括关键的业务。比如说，如果你的业务是依赖消费者提供收益，那么如果消费者不能提交订单那一定会出现损失，一定要保证这样的操作完成的很好。

要包括比较集中的操作。即使这些操作用到的很少，他们也会显著地影响性能。比如，有的业务是一个月在后台批处理一次，但这些操作会对前台想性能有很大影响。

要包括写在合同里的对性能有要求的操作，或者有权势的利益相关人的操作。

下面是电子商务系统的关键场景：

1、浏览；

2、创建用户账户

3、查询；

4、登录；

5、提交订单

需要考虑的事

在识别关键场景中要考虑到一下关键点：

• 要把没有人的系统或是后台批量进程考虑成和终端用户一样。比如，当用户正在执行操作的时候，有一个批处理程序正在运行更改订单的状态。在这种情况下，你需要计算这些进程，因为他们也要消耗系统资源。
• 一般来讲，web servers 是对应文本和图片的处理能力是非常有效的。带有平均大小的静态页面一般没有动态页面，表格和多媒体页面那么关键。

步骤一：识别目标

创建负载模型的目的通常重点在于确保测试场景是符合现实情况的，或者是特别设计一个测试以满足特殊的需求、目标或者性能测试的目的（更多的信息，请参看“如何确定最终用户数量的需求”以及“如何定义性能测试目标”--秀霞以后有时间会慢慢翻译）当识别目的的时候，你应该充分考虑到满足商业需求的目标，在模拟你的目标的时候。可以考虑一下关键问题：

• 当前或随着时间推移预期的业务量是多少？比如，在给定时间段内的订单是多少？其他操作时什么？比如查询的数量，浏览的数量，登录次数等等，支持订单顺序吗？

• 随着时间推移，业务量是怎样的期望？你的项目应该应该把将来的需要计算在内，比如，业务的增长，可能出现的企业合并，新产品的引入等等。

• 目前或者期望的负载峰值水平是什么？这个项目应该考虑支持这样的行为活动，这些行为活动支持销售或者其他关键业务流程，比如市场战役（诸如产品促销，搞活动等等-秀霞加），新产品上市，对时间敏感的活动比如证券交易所依赖于永不停歇的市场等等。

• 你期望多快达到峰值负载水平？你的预期应该把不是很常见的业务活动激增考虑在内，当一个事件发生后，对增长的需求组织调整有多快？

• 峰值的负载会持续多长时间？也就是说，在系统疲劳之前的资源的退让会持续多长时间？比如说，一个经济公告就可以引起货币外汇市场持续高负荷两到三天，而不是几个小时。

这些信息可以从web服务器的日志中获得，也可以从市场文档反映出的商业需求中获得，也可以从利益相关者那里获得。下面是一些在这个过程中被识别的目标：

• 确保一个或者多个模型可以代表峰值期望的负载（每小时产生的订单数）

• 确保一个或者多个模型可以表示出 “quarterly close-out” 区间使用模式和“典型营业日”使用模式的区别。（译者理解：有的系统只登录一次，可能查询一下或者操作一个功能就退出了，而有的系统则全天在线，比如柜台业务的操作的系统，早上登录，全天都在不停地执行操作）

• 确保一个或多个模型可以表示出业务或者市场项目可以在未来一年内运行的很好。

如果这些目标在项目的背景下是讲得通的，那么我们就认为是可以接受的。接下来要做的就是为取得的目标填充上必要的详细内容。

要考虑的事

在识别目标的时候要考虑到以下的关键点：

• 创建一个负载模型过程中的吞吐量，记得和团队分享你的假设条件和草稿，索求他们的反馈意见。

• 不要过度地追求完美，不要陷入过度单纯化的诱惑。一般而言，一个好的主意是在你已经有了一个可以用来测试的模型并且已经开始测试的情况下产生的，然后在收集结果的时候再逐渐增强它。

如何为web应用建立负载模型

J. D. Meier, Prashant Bansode, Carlos Farre, Scott Barber编写 秀霞翻译

应用于：

Web 应用

性能测试

摘要

这里要描述如何创建负载模型，这个负载模型可以表示预计web应用如何在实际环境中工作。对于性能测试的结果可以理解为真实环境下的性能特性，测试用的负载模型必须代表真实用户场景。创建一个合理准确的现实表述，你必须理解使用应用的业务前后逻辑关系，不同情况下所期望的事务，期望的用户路径，以及其他可以利用的要素。

目录

目标

概要

步骤的摘要

步骤1：识别目标

步骤2：识别关键场景

步骤3：为关键场景确定导航路径

步骤4：为导航路径或模拟用户识别唯一的数据

步骤5：确定场景的相对分配

步骤6：识别负载水平的目标

步骤7：准备执行模型

目的

学习如何根据期望、文档、观察分析以及以前版本可以得到的数据为web应用组建和实现负载模型。

概述

负载模型是一个识别一个或者多个混合的应用使用情况的过程，一般用在性能测试中。一个负载模型包括和数据相关的项，诸如：

• 关键用户的行为；

• 导航路径的相关的行为；

• 相关的用户分布以及（或者）跨目标负载的行为；

• 唯一的数据和模拟的每个用户中应用相互影响。

然而，模拟不切实际的负载模型可以在执行性能测试的时候为团队提供有价值的信息，这当然是正确的，你可以仅仅加一些准确的前提条件，就可以让现实情况被模拟，并为产品进行性能测试或者实现性能优化。

步骤的总结

步骤的摘要

步骤1：识别目标

步骤2：识别关键场景

步骤3：为关键场景确定导航路径

步骤4：为导航路径或模拟用户识别唯一的数据

步骤5：确定场景的相对分配

步骤6：识别负载水平的目标

步骤7：准备执行模型

最近在整理负责产品的负载模型，见得这个文章还不错，先转过来。

------

一个访问量达到百万级别的门户网站及奥运会订票系统等这中用户数较多的系统，进行性能测试是必须的。要不就和产品演示会上出现的笑话一样，风险投资商提出的问题是这个网站能支持多少用户同时上线，项目经理居然说没有进行这方面的测试。全场哗然。。。。
　　对于性能测试的第一步是怎么去根据业务的实际模型分析出具体的测试场景及性能测试的指标。

　　一、 性能测试业务逻辑理解的一些基本概念

　　1、负载测试和压力测试的区别：负载测试在于确定最终满足系统指标的前提下，系统所能承受的最大负载测试，压力测试的目标则在确定什么条件下系统性能处于失效状态。

　　2、吞吐量（Throughput）：指单位时间内处理的客户段请求数量，直接体现软件系统的性能承载能力。

　　3、并发（Concurrency）：多个同时发生的业务操作。例如100个用户同时点登录21CN邮箱和同时在线人数不一样。比如说21CN通行证用户登录的有1万个可能只有20%的人在看博客，10%的人在看相册，30%的人在查看邮件，10%的人在查看播客，10%的人在看视频点播，10%的人在逛论坛等等

　　但是同时在线人数就是1万，并发用户就是针对每个系统的具体人数。

　　二、几种常见的业务模型设计

　　1、e家广告系统：

　　（1）具体的业务参数要求：

　　系统要达到4000万日均PV，则需要平台可以处理4000并发/秒。根据选中的服务器的性能，处理能力约为2000个HTTP并发/秒或1000个流媒体并发/秒。假设这4000万PV中有图片的PV占3000万，流媒体的PV占1000万，则需要WEB服务器及流媒体服务器各两台。

　　（2）具体的测试设计方法：

　　（a）平台的处理能力与要达到的日均PV的能力的计算关系为：

　　参数说明：

　　X：表示整个系统的日均PV值，单位为：万PV/天

　　m：平台最大有效并发数（即用来服务于广告物料显示的并发数），单位为：并发/秒，每小时是3600秒，即每个小时处理的并发数为3600m并发，即0.36m万并发/小时。

　　y：非高峰时期的平均并发数与平台最大并发数的比例，0<y<1

　　Y：高峰期（平台达到最大并发数的70%，平台负载超过70%以后，将变得不稳定）小时数,0<Y<24,即高峰期并发数为70%*0.36m

　　那么：

　　日均PV＝高峰期并发数＊高峰期小时数＋非高峰期平均并发数＊（24－高峰期小时数）

　　即：

　　X=0.7*0.36mY+y*0.36m*(24-Y)

　　即最后结论：

　　X=(0.252Y+8.64y-0.36yY)*m

　　根据经验值，Y＝3，y=30%时，m/X=0.33。而m是平台最大有效并发数，即用来服务于广告物料显示的并发数，而对于每次广告物料的显示，客户端还有访问其它资源如JS代码等，假设每一次广告物料的访问会有伴随另外2个资源的访问。

　　那么平台支撑的总的并发数与需要达到的日均PV的比大约为0.33*3=1。

上面算的比较乱，我换了一种格式表达如下：

下面的好像不是很正确~~~~

（b）实际测试模型设计中结果：

　　面的并发用户数只需要达到N1=0.33*40000000*0.7/24*0.3*3600=356个

　　对于流媒体服务器并发用户数：N2=10000000*0.7/24*0.3*3600/2=135个

　　对于图片服务器并发用户数：N3=30000000*0.7/24*0.3*3600/2=405个

　　2、集团邮箱：

　　（1）具体的业务参数要求：集团邮箱支持支持2000万用户，对性能有要求的操作有邮箱登录，读信，翻页，发邮件（分别是8秒内，2秒内，2秒内，5秒内）。所有的操作均返回HTTP200的状态代码。其中服务器资源分别是登录5台机器（连接PASSPORT），收发邮件5台（不包括POP收发信），其它邮件处理服务器5台，pop/smtp服务器5台。

　　（2）具体的测试设计方法：具体的设计2000万个用户登录时间大概在会在8点到下午18点前操作，而该类业务模型满足80~20原则，比如80%的业务会在20%的时间内处理。则登录的并发用户数设计成多少好呢？ VUlogin=20000000*80%/(10*20%*3600*5) 其它事物可以以此类推。

　　（3）当然如果业务在要求吞吐量的时候，就要更根据吞吐量来设计性能瓶颈所需要的并发用户数这在我们21CN网站和电子商务网站中经常出现。这里引进一个公式VU=F /R*T(VU并发虚拟用户数,F吞吐量,T性能测试时间,R每个VU的请求数量)举例说明（某网站的吞吐量为90亿KB，每个用户每秒50万kb，运行时间30分钟设计出来的每秒用户数VU=9000000000/(500000*30*30)）

　　（4）如办公系统（业务比较频繁的系统）：每天内的一些典型用户固定可以考虑采用一种更准确的计算并发用户数的的方法。公式引进：C=N*L/T,C1=C+ (C是平均并发用户数，N是login session的数量，L是login session的时长，T是考察的时间长度，C1是最高峰值)（*这里的用户是指明确每天都要使用的系统的大概数量来自需求，而这里的用户都是当做一个典型的用户来分析就是登录后会进行正常的流程操作）如21CNEIP每天有320个典型用户访问，系统平均时间为4小时，在一天内用户使用该系统的时间都在8小时内。得出C=320*4/8,C1=C+3 (5)针对这几种模式做一些归纳无论那种模型都是来源于需求根据需求的实际模型是最真实的也是最有效的性能测试模型，在没有典型用户的前提下选择2-8原则（在测试环境中要考虑到等价这个概念就是测试环境服务器数量没有实际环境哪么多的时候要折算过来），有典型用户的情况下选择最大并发数的计算方法，在要求有吞吐量的情况下用吞吐量的计算方法（但是吞吐量的数据要采用上一次测试或者经验值中没有突破系统瓶颈的部分数据要不结果不准确，其中每秒事物数取的是平均值）

　　三、其它值得注意部分

　　1、设置测试场景中并发用户为每隔一段时间增加X个虚拟用户（预热，RAMP UP设置），与同时加载所有的并发用户的测试结果不同，实际的测试中要根据具体业务情况设计。另外实际的数据库记录数和网络环境等都会影响到测试结果。

　　2、建议在实际的测试过程中能多次测试取平均值。

　　3、性能测试的”拐点论”:产生拐点的情况是性能测试产生某种瓶颈，主要原因是某种资源达到了极限。此时表现为随着压力的增大，系统性能出现急剧下降。

　　4、性能测试的系统能力验证: （a）是系统稳定性的一个基本要求，通常表现为系统在要求的平均并发用户下服务器的CPU平均使用率不高于75%，内存的使用率不高于75%。（b）系统在要求的并发用户数达到峰值情况下服务器的CPU平均使用率不高于95%，内存的使用率不高于90%。（c）系统能在高于实际系统运行压力1倍的情况下，稳定的运行72小时。

　　5、为分清各个不同事物的响应时间请务必在多事物的脚本中添加事物以便区分，请在要用到多个帐户或者多个用户的迭代或者循环操作的时候请务必进行参数化（很多系统都限制了同一帐户在多长时间的操作，或者防止数据冲突）。

SoapUI的性能测试提供几种测试策略，我装的事3.6.1，有下面四种：

1、Simple

“Simple “执行指定精确数量的线程（并发），并且延迟的时间也是精确的,并且可以模拟给服务器喘息的空间。比如，你想要运行10个并发10秒延迟这样的功能测试，你就可以设置Threads 为10，Test Delay 设置为10000，random 设置的值是要根据你想要自由度设定，如果设置成0.5，那么delay 的时间就是在5-10之间，如果设置成0.7，就是在7-10之间。

当创建一个新的负载策略的时候，默认的值分别是5,1000和0.5

Simple 策略对基线测试是完美的。用它可以断言你的服务的基本性能情况和验证不存在多线程和资源被锁的问题。当你想更详细的产生你的系统情况，你就可以逐步增加你的负载，或者你也可以执行长时间运行来发现内存泄露的问题。

由于这并不意味着将你的服务就可以放在膝盖，但这样的设置可用于连续负载测试，以确保您的服务按预期执行在中等负荷;建立一个没有随机的延迟基准测试，新增LoadTest断言，断言可以作为一个意想不到的结果的安全网，同时也可以通过命令行自动运行LoadTest或放到Maven插件中执行。

2、Variable Load Strategies

最近接到性能测试的任务，需要使用SoapUI来进行，以前没用过SoapUI，于是进入学习阶段。

其中最大的疑惑是：我如何知道我要发送的请求？这个问题像个小山一样横在我前进的道路上，我想如果作为开发人员，这个问题基本上不成问题吧，但是对于测试人员，对代码了解很少的情况下，应该是很难的。

最后在开发人员的帮助下，通过查找日志中的记录，来获取发送的请求，单个的脚步问题发送都成功了，这是性能测试执行的基础，这一步要先过关了，但还是很疑惑，以后的项目日志还会保留的这么详细可用吧，暂时不想这个问题，先基于现在的项目，进行性能测试，Let's go！

1、首先把调试好的request 右键选择“add to Testcase "

2、选择要添加的位置，也可用创建新的测试套件或者测试用例。

3、此时创建新的Load TEST就可以看到刚才创建的测试用例了。

4、创建新的Load Test 的内容如下：

内容解释：双击打开后，页面如上显示，设置过程参考如下，场景为5用户并发，
持续运行1 分钟，没有思考时间。相应的SoapUI 可设置Threads=100，
Test Delay=0，Limit=600，后面的下拉框选择Seconds，表示600 秒。设
置完毕后，点击左上方的绿色箭头，程序开始进行负载测试。
6、执行结果如下：

单位是毫秒

但是给出的信息还是太少了，决定更深层次的挖掘，下篇继续。

我在RPT8.1中遇到如下错误：

RPTO0029E 记录不包含已安装测试生成器的任何协议数据

解决过程：

方法一：

解决办法：

录制页面时，访问的URL不要使用localhost或127.0.0.1，改用分配的IP地址，例如：

http://192.168.1.100:1080/webtours

方法二：Tools -> Internet Options -> Connections (tab) -> Lan Settings ->
There is a checkbox which states "Automatically Detect Settings" which was checked(selected). After unchecking this checkbox, the problem got solved. I am able to reproduce the problem by enabling this checkbox again.

但以上方法都解决我了我的问题，最后还是自己解决

分析：产生原因IE6，因为Firefox 没有该问题，于是升级为IE7，问题得到解决。

1.根据原有的测试数据进行估计。

原来的测试是195000在2倍于当前环境下进行的，本次测试可用 195000/2 的模拟用户总数来进行测试；

2、当前用户数、当前的业务数量，以及时间长度来计算 业务的密集程度，从而推算出并发用户数

3、客户公司的总人数，和预计未来的人数，这个是最简单的方法

4、如果实在不好计算用户情况，可进行逐步的增压，根据实际测试结果的支持人数，来给出系统容量。

……后续补充

    为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。

    这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的 ^_^

    系统总容量达到日委托6000万笔，成交9000万笔

    系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔

    实际股东帐号数3000万

    这个例子中已经包括几个明确的需求：

    最佳并发用户数需求：每秒7300笔

    最大并发用户数需求：峰值处理能力达到每秒10000笔

    基础数据容量：实际股东帐号数3000万

    业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型

    什么是“有效的”性能需求？

    要想获得有效的性能需求，就要先了解什么样的需求是“有效的”。有效的性能需求应该符合以下三个条件。

    1. 明确的数字，而不是模糊的语句。

    结合上面的例子来看，相信这个应该不难理解。但是有的时候有了数字未必就不模糊。例如常见的一种需求是“系统需要支持5000用户”，或者“最大在线用户数为8000”。这些有数字的需求仍然不够明确，因为还需要考虑区分系统中不同业务模块的负载，以及区分在线用户和并发用户的区别。关于这方面的内容，在下面两篇文章中的留言内容中有精彩的讨论：

    2. 有凭有据，合理，有实际意义。

    通常来说，性能需求要么由客户提出，要么由开发方提出。对于第一种情况，要保证需求是合理的，有现实意义的，不能由着客户使劲往高处说，要让客户明白性能是有成本的。对于第二种情况，性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜测，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的——本文后面的部分会介绍获得可用的数据和计算公式的方法。

    3. 相关人员达成一致。

    这一点非常关键。如果相关人不能对性能需求达成一致，可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。这里要注意“相关人员”的识别，通常项目型的项目的需要与客户方的项目经理或负责人进行确认，产品型的项目需要与直属领导或者市场部进行确认。如果实在不知道该找谁确认，那就把这个责任交给你的直属领导；如果你就是领导了，那这领导也白当了 ^_^

如何获得有效的性能需求

    上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可行的。这几种方法由易到难排列如下：

    1. 客户方提出

    这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。

    2. 根据历史数据来分析

    根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统，可以根据已有系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不同行业、不同应用、不同的业务是有各自的特点的。例如，购物网站在平时的负载主要集中在晚上，但是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了周末，还有周一到周五的一早一晚上下班时间。

    3. 参考历史项目的数据

    如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。

    4. 参考其他同行类似项目的数据

    如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。

    5. 参考其他类似行业应用的数据

    如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。

    6. 参考新闻或其他资料中的数据

    最后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，通常可以通过各种新闻媒体找到一些可供参考的数据，但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中，可以根据新闻中公布的各省、各市，以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。

"Static Analysis" does not apply to the selected items.

遇到的问题和解决方法

过程：

我的文档图标是：

而别人的是：

通过仔细看E文帮助文件，通过修改MIME Type解决：

introduction

WebKing™, from Parasoft Corporation, is a source code validation tool for HTML. It is used to check HTML documents for proper syntax and standards compliance, including accessibility standards. WebKing can be used to test static web pages served from a web server, and can also be used to test HTML pages created dynamically by web applications and portal web sites.

WebKing is used to validate compliance of the IBM Corporate Instruction 162 Web Accessibility Checklist. Keep in mind that WebKing only covers a subset of the checkpoints in the checklist, and WebKing can only do a technical validation of the HTML syntax. The appropriateness of the text or alternative text and the other checkpoints in the checklist must still be manually validated.

In the development environment, WebKing has a plug-in for WebSphere Studio Application Developer (WSAD), which enables web page debugging during development. That feature is not discussed in this document. See WebKing's on-line plug-ins documentation for details.

This document is intended solely to describe the use of WebKing as a software accessibility testing tool. For a more comprehensive guide to using WebKing, refer to the WebKing on-line documentation. For additional information, go to the ParaSoft Web site.

set up