当前位置：文档之家› 负载测试与性能测试

负载测试与性能测试

1.什么是负载测试？什么是性能测试？

性能测试（或称多用户并发性能测试）、负载测试、强度测试、容量测试是性能测试领域里的几个方面，但是概念很容易混淆。下面将几个概念进行介绍。

性能测试（Performance Test）：通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。

关注点：how much和how fast

负载测试（Load Test）：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。

关注点：how much

强度测试（Stress Test）：强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括

Spike testing：短时间的极端负载测试

Extreme testing：在过量用户下的负载测试

Hammer testing：连续执行所有能做的操作

容量测试(Volume Test)：确定系统可处理同时在线的最大用户数

关注点：how much（而不是how fast）

容量测试，通常和数据库有关，容量和负载的区别在于：容量关注的是大容量，而不需要表现实际的使用。

其中，容量测试、负载测试、强度测试的英文解释为：

Volume Testing = Large amounts of data

Load Testing = Large amount of users

Stress Testing = Too many users, too much data, too little time and too little room

2.性能测试包含了哪些测试（至少举出3种）

包含以下测试类型：

基准测试- 比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。

争用测试：- 核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。

性能配置- 核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。

负载测试（Load Test）-是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。

核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。

强度测试Stress Testing -核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。

3.简述性能测试的步骤

性能测试的过程应该为六个阶段，分别是[b]发现、探究、提案、执行、复查、收尾[/b]。原文如下：

1，Discover the problem：发现问题。

这个步骤最重要的就是发现(Discover)问题，详述问题(Discribe),并且正确而详细地记录(Document)下来。在进入下一步骤前，我们测试人员应该问问自已以下这些问题：

[b] ·对于问题是否已经有简明的描述

·用户的基线与期待在哪[/b]

2，Explore the conditions：探究原因，为问题提供明确的定义与定位。

这个步骤的主要任务：是广泛搜集相关数据，尽量了解系统的每一个方面，避免深入分析时，漏了某个关键的现象而误入歧途；重点：是探索(Explore)，寻找证据(Evidence),建立(Establish)整个问题的来龙去脉的假设。

有的时候在这个阶段就可以发现重大问题，一眼就看出关键点，例如硬件毁损，某个硬盘区块或内存块不稳，或某个其他程序吃掉所有的内存，让SQL Server无内存可用，或是该程序常常死当，拖垮CPU等等。

3，Track down possible approaches：提供可能的解决方案。

这个步骤的主要任务：深入分析数据间的关联性，并对整个问题的前因后果提出假设，最后拟定出相应的策略(计划)。如果前一个步骤做得不够详实，在这个步骤我们可能就会误判，导致努力的半天，但就是找不到瓶颈点。

这个步骤的最重要的动作：是拟定计划。一个好的计划，你才能知道方向与步骤。

4，Execute the most likely approach：执行最有可能的解决方案。

这是DETECT方法中最简单的一步，因为只要执行上一步中所拟定的计划就行了。但是在执行计划时，仍然要注意系统的反应（随时都可能会要放弃当前的计划，因为新的证据可能证明你先前的判断错误，因而要修正计划，甚至是退回到上一步以重新拟定计划。这时切勿躁，因为整个性能测试的过程就是在考验团队的细心与耐力、知识的广度与深度！），同时还要小心观察会不会有新的问题出现并严重影响当前系统的执行，不要原来系统迟缓，而你的测试却成为压垮骆驼的最后一根稻草。

5，Check for success(如果需要的话，重复之前的步骤)：确认解决方案成功与否。

这一步骤主要任务是：重新收集数据，以验证该计划的成功与否。如果证实假设是对的，则继续搜集相关数据，以确立接下来的步骤；如果到这一步发现执行的结果不如预期，证明我们的假设错误。这会非常让人气tuo,进而放弃这个性能测试的方法，因为无法忍受整个时间的流失。其实，定错性能的目标是常有的事，这个方法论就是要你在错误的当前，停下来好好思考，重新理出头绪，最重要的是要清楚知道这一回是错在哪，如此新的步骤就能更逼近目标。有系统的犯错，是整个计划的一部分，踩着错误走向成功是性能测试的常态。

6，Tie up loose ends：完成收尾工作。

重复前五个步骤直到达到目标。

但当我们完成目标后，依然要注意以下的问题：

[b] ·解决的方式是否有边际效应，造成其他的问题[/b] 例如：为了某类的查询工作建立了大量的索引，

事后原本正常的新建、修改、删除都出现了性能问题。

[b] ·是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚[/b]建立问题的假设时，很容易将问题特殊化，仅局部地解决该现象。例如：加了某个索引或稍稍改变查询语法，舒缓了当前的瓶颈，但当用户稍微增加，或是采用了不同的查询方式，就老问题复发。

[b] ·是否要建立持续跟踪的计划[/b]

4.简述使用Loadrunner的步骤

1、用户确定需要进行性能测试的业务或交易，通过用户操作和Vuser Generator的录制功能来记录并生成虚拟用户脚本。

2、手工修改虚拟用户脚本，确定脚本能够回放成功。

3、在Controller中对场景进行培植后，就可以启动测试了。在测试过程中，Controller控制Load Gernerator 对被测系统的加压方式和行为。

4、Controller同时负责搜集被测系统各个环节的性能数据。各个Load Generatro会记录最终用户响应时间和脚本执行的日志。

5、压力运行结束以后，Load Generator将数据传到Controller中，由Controller对测试结果进行汇总。

6、测试人员借助数据分析工具Analysis对性能测试数据进行分析，进而确定瓶颈和调优方法。

7、针对性地对系统进行调优，重复进行压力测试，确定性能是否有所提高。

5.什么时候可以开始执行性能测试？

6.LoadRunner由哪些部件组成？

Virtual User Generator：捕捉终端用户事务处理过程，自动生成可以被Virtual user识别的性能测试脚本；

Controller：组织、驱动、管理和监视负载测试；

Load Generators：执行virtual user 创建附负载；

Analysis：帮助用户观看、剖析比较性能测试结果；

Launcher：提供访问LoadRunner所有部件的唯一接口。

7.你使用LoadRunner的哪个部件来录制脚本？

8.LoadRunner的哪个部件可以模拟多用户并发下回放脚本？

9.什么是集合点？设置集合点有什么意义?Loadrunner中设置集合点的函数是

哪个?

插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中，可能会要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据，从而达到测试计划中的需求。

说明：在脚本中设置了“集合点”后，当运行场景时可以对集合点进行设置，可以设置当百分之多少用户到达时，系统开始执行操作

设置集合点的函数：lr_think_time

10.什么是场景？场景的重要性有哪些?如何设置场景?

运行场景描述在测试活动中发生的各种事件，一个运行场景包括一个运行虚拟用户活动的Load Generator 机器列表，一个测试脚本的列表以及大量的虚拟用户和虚拟用户组

创建场景使用Controller-New Scenario

场景重要性？？？？？

11.请解释一下如何录制web脚本？

这需要你自己总结

12.为什么要创建参数?如何创建参数?

参数可以让你在建立试脚本后，利用几套不同的实际发生数据来测试应用程序，从而反映出系统的负载能力。以一个订单输入过程为例，参数化操作可将记录中的固定数据，如订单号和客户名称，由可变值来代替。（绿色部分是举例说明）

LoadRunner通过Data Wizard来自动实现其测试数据的参数化

13.什么是关联？请解释一下自动关联和手动关联的不同。

如何在LoadRunner 脚本中做关联(Correlation)

当录制脚本时，VuGen会拦截client端（浏览器）与server端（网站服务器）之间的对话，并且通通记录下来，产生脚本。在VuGen的Recording Log中，您可以找到浏览器与服务器之间所有的对话，包含通讯内容、日期、时间、浏览器的请求、服务器的响应内容等等。脚本和Recording Log最大的差别在于，脚本只记录了client端要对server端所说的话，而Recording Log则是完整纪录二者的对话。

当执行脚本时，您可以把VuGen想象成是一个演员，它伪装成浏览器，然后根据脚本，把当初真的浏览器所说过的话，再对网站伺服器重新说一遍，VuGen企图骗过服务器，让服务器以为它就是当初的浏览器，然后把网站内容传送给VuGen。

所以纪录在脚本中要跟服务器所说的话，完全与当初录制时所说的一样，是写死的（hard-coded）。这样的作法在遇到有些比较聪明的服务器时，还是会失效。这时就需要透过「关联（correlation）」的做法来让VuGen 可以再次成功地骗过服务器。

何谓关联（correlation）？

所谓的关联（correlation）就是把脚本中某些写死的（hard-coded）数据，转变成是撷取自服务器所送的、动态的、每次都不一样的数据。

举一个常见的例子，刚刚提到有些比较聪明的服务器，这些服务器在每个浏览器第一次跟它要数据时，都会在数据中夹带一个唯一的辨识码，接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器。一般称这个辨识码为Session ID。对于每个新的交易，服务器都会产生新的Session ID给浏览器。这也就是为什么执行脚本会失败的原因，因为VuGen还是用旧的Session ID向服务器要数据，服务器会发现这个Session ID是失效的或是它根本不认识这个Session ID，当然就不会传送正确的网页数据给VuGen了。下面的图示说明了这样的情形：

当录制脚本时，浏览器送出网页A的请求，服务器将网页A的内容传送给浏览器，并且夹带了一个ID=123的数据，当浏览器再送出网页B的情求时，这时就要用到ID=123的数据，服务器才会认为这是合法的请求，并且把网页B的内容送回给浏览器。

在执行脚本时会发生什么状况？浏览器再送出网页B的请求时，用的还是当初录制的ID=123的数据，而不是用服务器新给的ID=456，整个脚本的执行就会失败。

要对付这种服务器，我们必须想办法找出这个Session ID到底是什么、位于何处，然后把它撷取下来，放到某个参数中，并且取代掉脚本中有用到Session ID的部份，这样就可以成功骗过服务器，正确地完成整个交易了。

哪些错误代表着我应该做关联（correlation）？

假如脚本需要关联（correlation），在还没做之前是不会执行通过的，也就是说会有错误讯息发生。不过，很不幸地，并没有任何特定的错误讯息是和关联（correlation）有关系的。会出现什么错误讯息，与系统实做的错误处理机制有关。错误讯息有可能会提醒您要重新登入，但是也有可能直接就显示HTTP 404的错误讯息。

要如何做关联（correlation）？

关联（correlation）函数

关联（correlation）会用到下列的函数：

? web_reg_save_param：这是最新版，也是最常用来做关联（correlation）的函数。

语法：

web_reg_save_param ( “Parameter Name” , < list of Attributes >, LAST );

? web_create_html_param、web_create_html_param_ex：这二个函数主要是保留作为向前兼容的目的的。建议使用web_reg_save_param 函数。

详细用法请参考使用手册。在VuGen中点选【Help】>【Function reference】>【Contexts】>【Web and Wireless Vuser Functions】>【Correlation Functions】。

如何找出要关联（correlation）数据

简单的说，每一次执行时都会变动的值，就有可能需要做关联（correlation）。

VuGen提供二种方式帮助您找出需要做关联（correlation）的值：

1. 自动关联

2. 手动关联

自动关联

VuGen内建自动关联引擎（auto-correlation engine），可以自动找出需要关联的值，并且自动使用关联函数建立关联。

自动关联提供下列二种机制：

? Rules Correlation：在录制过程中VuGen会根据订定的规则，实时自动找出要关联的值。规则来源有两种：

o 内建（Built-in Correlation）：

VuGen已经针对常用的一些应用系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，内建关联规则，这些应用系统可能会有

一种以上的关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】中启用关联规则，则当录制这些应用系统的脚本时，VuGen会在脚本中自动建立关联。

您也可以在【Recording Options】>【Internet Protocol】>【Correlation】检视每个关联规则的定义。

o 使用者自订（User-defined Rules Correlation）：

除了内建的关联规则之外，使用者也可以自订关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】建立新的关联规则。

? Correlation Studio：有别于Rules Correlation，Correlation Studio则是在执行脚本后才会建立关联，也就是说当录制完脚本后，脚本至少须被执行过一次，Correlation Studio才会作用。Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。

Rule Correlation

请依照以下步骤使用Rule Correlation：

1. 启用auto-correlation

1. 点选VuGen的【Tools】>【Recording Options】，开启【Recording Options】对话窗口，选取【Internet Protocol】>【Correlation】，勾选【Enable correlation during recording】，以启用自动关联。

2. 假如录制的应用系统属于内建关联规则的系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，请勾选相对应的应用系统。

3. 或者也可以针对录制的应用系统加入新的关联规则，此即为使用者自订的关联规则。

4. 设定当VuGen侦测到符合关联规则的数据时，要如何处理：

【Issue a pop-up message and let me decide online】：跳出一个讯息对话窗口，询问您是否要建立关联。?

【Perform correlation in sceipt】：直接自动建立关联?

2. 录制脚本

开始录制脚本，在录制过程中，当VuGen侦测到符合关联规则的数据时，会依照设定建立关联，您会在脚本中看到类似以下的脚本，此为BroadVision应用系统建立关联的例子，在脚本批注部分可以看到关联前的数据为何。

3. 执行脚本验证关联是OK的。

Correlation Studio

当录制的应用系统不属于VuGen预设支持的应用系统时，Rule Correlation可能既无法发挥作用，这时可以利用Correlation Studio来做关联。

Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。

使用Correlation Studio的步骤如下：

1. 录制脚本并执行

2. 执行完毕后，VuGen会跳出下面的【Scan Action for Correlation】窗口，询问您是否要扫描脚本并建立关联，按下【Yes】按钮。

3. 扫描完后，可以在脚本下方的【Correlation Results】中看到扫描的结果。

4. 检查一下扫瞄的结果后，选择要做关联的数据，然后按下【Correlate】按钮，一笔一笔做，或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。

注意：由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【Correlate All】。

5. 一般来说，您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。因为有时前面的关联还

没做好之前，将无法执行到后面需要做关联的部份。

有可能有些需要做关联的动态数据，连Correlation Studio都无法侦测出来，这时您就需要自行做手动关联了。

手动关联

手动关联的执行过程大致如下：

1. 使用相同的业务流程与数据，录制二份脚本

2. 使用WinDiff工具协助找出需要关联的数据

3. 使用web_reg_save_param函数手动建立关联

4. 将脚本中有用到关联的数据，以参数取代

接下来将详细的说明如何执行每个步骤

使用相同的业务流程与数据，录制二份脚本

1. 先录制一份脚本并存档。

2. 依照相同的操作步骤与数据录制第二份脚本并存盘。注意，所有的步骤和输入的数据一定都要一样，这样才能找出由服务器端产生的动态数据。

有时候会遇到真的无法使用相同的输入数据，那您也要记住您使用的输入数据，到时才能判断是您输入的数据，还是变动的数据。

使用WinDiff工具协助找出需要关联的数据

1. 在第二份脚本中，点选VuGen的【Tools】>【Compare with Vuser…】，并选择第一份脚本。

2. 接着WinDiff会开启，同时显示二份脚本，并显示有差异的地方。WinDiff会以一整行黄色标示有差异的脚本，并且以红色的字体显示真正差异的文字。（假如没看到红色字体，请点选【Options】>【View】>【Show Inline Differences】）。

3. 逐一检视二份脚本中差异的部份，每一个差异都可能是需要做关联的地方。选取差异的脚本，然后复制。在复制时，有时并不需要取整行脚本，可能只会选取脚本中的一部分。

注意：请忽略lr_thik_time的差异部份，因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间。

4. 接着要在Recording Log（单一protocol）或是Generation Log（多重protocol）中找这个值。将鼠标光标点到Recording Log的第一行开头，按下Ctrl+F，开启【Find】窗口，贴上刚刚复制的脚本，找出在Recording Log第一次出现的位置。

结果会有二种：

o 在Recording Log中找不到要找的数据，这时请先确认您找对了脚本，毕竟现在开启了二个几乎一样的脚本，很容易弄错。

o 在Recording Log中找到了要找的数据，这时要确认数据是从服务器端传送过来的。首先可以先检查数据的标头，从标头的Receiving response可以知道数据是从服务器端传送到client端的。假如此数据第一次出现是在Sending request中，则表示此数据是由client端产生，不需要做关联，但是有可能需要做参数化（parameterized）。

您要找的标头格式如下：

*** [tid=b9 Action1 2] Receiving response from host https://www.doczj.com/doc/d49525845.html,:80 ( 25/11/2002 12:04:00 )

5. 现在您已经找到录制二次都不一样，而且是由服务器所产生的动态数据了，而此数据极有可能需要做关联。

使用web_reg_save_param函数手动建立关联

在找到是由服务器所产生的动态数据之后，接下来要做的就是找出适当的位置，使用web_reg_save_param 函数，将这个动态数据撷取到某个参数中。

1. 要在哪里使用web_reg_save_param函数？

在之前的步骤，我们已经在Execution Log找到可能需要关联的动态数据。在Execution Log中选取动态数据前的文字然后复制，我们将会利用这段文字，来帮助我们找出要关联的动态数据。

不过在这之前我们要先找出使用web_reg_save_param函数的正确位置，所以我们要再重新执行一遍脚本，而且这次会开启所有的Log。

1. 在VuGen中点选【Vuser】>【Run-Time Settings】。

2. 点选【General】>【Log】。

3. 勾选【Enable logging】、【Always sends messages】、【Extended log】，以及【Extended log】下的所有选项。

4. 按下【OK】就可以执行脚本了。

执行完脚本之后，在Execution Log中搜寻刚刚复制的字符串。找到字符串后，在字符串前面会有

A.tion1.c(7)，这个7就是到时候要插入web_reg_save_param函数的位置，也就是要插入到脚本的第7行。

在脚本的第7行前插入一行空白行，然后输入

web_reg_save_param(“UserSession”,

“UserSession” 这个“UserSession” 就是到时要使用的参数名称，建议给个有意义的名字。

注意：到这里整个web_reg_save_param函数还没完成。

2. 找出web_reg_save_param中要用到的边界

web_reg_save_param函数主要是透过动态数据的前面和后面的固定字符串，来辨识要撷取的动态数据的，所以我们还需要找出动态数据的边界字符串。

找出左边界字符串

再回到Execution Log中，选取动态数据前的字符串并且复制它。

这时会有个问题，到底要选取多少字符串才足以唯一识别要找的动态数据呢？建议是越多越好，但是尽量不要包含到特殊字符。

在这边我们选取「input type=hidden name=userSession value=」字符串。选好之后，还要再确认一次这段字符串真的是可以唯一识别的，所以我们在Execution Log中透过Ctrl+F的搜寻，找找看这段字符串是否可以找到要找的动态数据。假如找不到，web_reg_save_param函数还有个ORD参数可以使用，ORD 参数可以设定出现在第几次的字符串才是要找的字符串。

将这个边界字符串加到未完成的web_reg_save_param函数中：

web_reg_save_pa ram(“UserSession”, “LB= input type=hidden name=userSession value=”,

找出右边界字符串

接下来要找出动态数据的右边界字符串，这个字符串就比较好找了，从动态数据的最后一个字符开始，通常就是我们要找的右边界字符串了。

以这个例子来看，就是「>」，所以再把右边界字符串加入，web_reg_save_param函数中，这时

web_reg_save_param函数已经快完成了。最后再加上「LAST);」就完成整个web_reg_save_param函数了。

web_reg_save_param(“UserSession”, “LB= input type=hidden name=userSession value=”, “RB=>”, LAST);

将脚本中有用到关联的数据，以参数取代

当使用web_reg_save_param建立参数后，接下来就是用“UserSession”参数去取代脚本中写死的

（hard-coded）资料。

范例：

将

“Name=userSession”, “Value=75893.0884568651DQADHfApHDHfcDtccpfAttcf”, ENDITEM,

换成

“Name=userSession”, “Value={UserSession}”, ENDITEM,

到这里您已经完成了一个关联了，接下来就是执行脚本，是否能成功运行，假如还是有问题，就要检查看看是否还需要再做另一个关联。

关于web_reg_save_param 函数

对于关联(correlation)来说，web_reg_save_param是最重要的一个函数，其功能是在下载的网页内容中，透过设定的边界字符串，找出特定的数据并将其储存在一个参数中，以供后续脚本使用。

接下来将针对web_reg_save_param做比较详细的说明。

Service and registration type function

web_reg_save_param是一个Service function。service function主要是用来完成一些特殊的工作的，如关联、设定proxy、提供认证信息等，当其作用时，不会对网页的内容做任何的修改。

web_reg_save_param同时也是一个registration type function (只要函数名称中包含_reg_的字眼，表示其为registration type function)。registration type function意味着其真正作用的时机是在下一个action function完成时执行的。举例来说，当某个web_url执行时所接收到的网页内容中包含了要做关联的动态数据，则必须将web_reg_save_param放在此web_url之前，则web_reg_save_param会在web_url执行完毕后，也就是网页内容都下载完后，再执行web_reg_save_param找寻要做关联的动态数据并建立参数。

所以要记住一点，要使用registration type function时，要注意其放置的位置必须在要作用的action function 之前。

语法

int web_reg_save_param(const char *ParamName, , LAST);

参数说明

ParamName:存放动态数据的参数名称

list of Attributes:其它属性，包含Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, 以及SaveLen。属性值不分大小写，例如Search=all。以下将详细说明每个属性值的意义:

? Notfound:指定当找不到要找的动态数据时该怎么处置。

o Notfound=error:当找不到动态数据时，发出一个错误讯息。假如没设定此属性，此为LoadRunner的默认值。

o Notfound=warning:当找不到动态数据时，不发出错误讯息，只发出警告，脚本也会继续执行下去不会中断。在对角本除错时，可以使用此属性值。

? LB:动态数据的左边界字符串。此属性质是必须要有的，而且区分大小写。

? RB:动态数据的右边界字符串。此属性质是必须要有的，而且区分大小写。

? RelFrameID:相对于URL而言，欲搜寻的网页的Frame。此属性质可以是All或是数字，而且可有可无。? Search:搜寻的范围。可以是Headers(只搜寻headers)、Body(只搜寻body部分，不搜寻header)、Noresource(只搜寻body部分，不搜寻header与resource)或是All(搜寻全部范围，此为默认值)。此属性质可有可无。

? ORD:指明从第几次出现的左边界开始才是要撷取的数据。此属性质可有可无，默认值是1。假如值为All，则所有找到符合的数据会储存在数组中。

? SaveOffset:当找到符合的动态数据时，从第几个字符开始才开始储存到参数中。此属性质不可为负数，其默认值为0。

? Convert:可能的值有二种:

o HTML_TO_URL: 将HTML-encoded数据转成URL-encoded数据格式

o HTML_TO_TEXT:将HTML-encoded数据转成纯文字数据格式

? SaveLen:从offect开始算起，到指定的长度内的字符串，才储存到参数中。此参数可有可无，默认值是-1，表示储存到结尾整个字符串。

范例

web_reg_save_param("A", "LB/ic=

a[1]++;

else if(ch[i]>='a' && ch[i]<='z') //如果是小写字符

a[2]++;

else if(ch[i]>='0' && ch[i]<='9') //如果是数字