简介：
TestMore 是一个 UI 测试自动化工具，基于 Microsoft 公司的 NET 框架 和 动态语言运行时(DLR)基础之上，支持多种脚本语言，目标计划支持四种标准的脚本语言:
* Python http://www.python.org
* Ruby http://www.ruby-lang.org
* Javascrīpt http://www.ecmascrīpt.org/
* Visual Basic 10(VBx) http://msdn2.microsoft.com/zh-cn/vbasic/default.aspx
下载地址：
http://code.google.com/p/testmore/
TestMore当前最新的版本是0.6，主要feature如下
TestMore 当前版本实现的特性集合如下：
TestMore 0.6D101
* 集成正则表达式插件
* 集成帮助菜单和在线网站
* 重构并完善自动化对象模型(1.0 Beta)
* 重新实现 IE 驱动程序
* 更新帮助文档并打包发布
TestMore 0.5D601
* 集成工程管理模型
* 集成工程管理面板
* 支持用户自定义用例模板功能
TestMore 0.3D201
* 实现源代码编辑功能：创建、打开、保存、另存为……
* 语法高亮度显示功能：支持Python、Javascrīpt、Ruby、VisualBasic、……，可以根据需要添加其它语言；
* 源代码折叠显示功能：提供了更好的编辑视图，目前仅提供 Python/Javascrīpt/Ruby 折叠支持；
* 动态脚本语言的支持：安装包中集成了 IronPython 实现，可以实现Python脚本语言的编辑调试；
* 支持插件功能，目前没有开放插件SDK
* 支持多语言

这是一个非常新的测试需求分析和测试用例设计技术，特别适用于测试需求不明确、文档不全的情况，而且把测试用例的重用性发挥到了极致，如果设计得当，基本可以做到design once, apply all的地步。不仅仅可以适应于跨项目，跨产品，甚至跨行业，跨公司都可以重用测试用例。
Q-Pattern中的Q是Question的意思，这是一个由一系列的问题组成的一个问题集的设计方法，针对不同颗粒的需求，小到一个下拉框，大到C/S级别的应用，都可以由一个包含许多问题集组成，针对不同的被测对象，回答这些问题就可以生成一系列的完成对产品覆盖的测试用例集。

 

利用LoadRunner测试一个应用的时候，需要验证域用户，所以即使录制成功，每次回放的时候都提示错误，用户名和密码不对，对此耿耿于怀了很久。今天居然解决了。解决方法就是一个简单的函数调用： web_set_user，此函数的解释和用法如下：
The web_set_user function is a Service function that specifies a login string and password for a Web server or proxy server. It can be called more than once if several proxy servers require authentication. web_set_user overrides the run-time proxy authentication settings for user name and password.
When you log onto a server that requires user and password validation, VuGen records a web_set_user statement containing the login details. However, there are some more stringent, authentication methods for which VuGen is unable to insert web_set_user statements. See User Authentication for more detail. In such cases, you can add web_set_user into your scrīpt manually.
When you run the scrīpt, LoadRunner automatically submits the user authorization along with every subsequent request to that server. At the end of the scrīpt, LoadRunner resets the authorization.
This function is supported for all Web Vusers, and for WAP Vusers running in HTTP mode only. It is not supported for WAP Vusers running in Wireless Session Protocol (WSP) replay mode.
Example 3
The following example was inserted manually by the user into the scrīpt as the Web server “mansfield” uses NTLM authentication. VuGen cannot record NTLM or Digest authentication. Note that for NTLM authentication the domain name “mansfield” followed by a double backslash must be prepended to the user name:
web_set_user(”mansfield\\freddy”, “XYZ”, “mansfield:80″);
原来一直没有想到域的设置，结果一直不行，现在可以了。
另外一个问题跟之前这个有关系，那就是验证码的问题，之前曾经看过段念（关河大侠）的关于验证码的是三个解决方案，这里是第四种解决方案。对于一些比较简单有规律的验证码可以搞定。对于复杂的比如有干扰的，或者没有规律的则参考关大侠的其他解决方案。
这个应用经过源代码分析，发现每次客户端请求过来的验证码都可以取到，格式如下固定，是四个数字的组合。经过多次尝试发现如下规律：
验证码如下： 52|52|52|51|46|47|49|55|
对应界面的验证码是： 6039
规律是第2，5，8，9位的值减去46对应的即是验证码。
有了这个规律，就可以通过关联提前取得服务器的验证码，然后通过简单的计算，得到结果。详细代码如下：

#include “web_api.h”
Action()
{
// char* str = “52|52|52|51|46|47|49|55|”;
char result[64];
int num1;
int num2;
int num3;
int num4;
int temp1;
int temp2;
int temp3;
int temp4;
web_set_user(”XXXXDomain\\szXXXX”,
lr_decrypt(”46246a2633f042c67758b9ddc2b863038aa063c03d7e”),
“XXXX.XXXX.com.cn:8080″);
web_reg_save_param(”check”, “LB=Image=”, “RB=\\”, LAST);
web_url(”Register”,
“URL=http://XXXX.XXXX.com.cn:8080/xx/main/Register”,
“Resource=0″,
“RecContentType=text/html”,
“Referer=”,
“Snapshot=t1.inf”,
“Mode=HTML”,
LAST);
lr_think_time( 6 );
sscanf(lr_eval_string(”{check}”), “%d|%d|%d|%d|%d|%d|%d|%d”, &temp1, &num1, &temp2, &temp3, &num2, &temp4, &num3, &num4);
num1 -= 46;
num2 -= 46;
num3 -= 46;
num4 -= 46;
sprintf(result, “%d%d%d%d”, num1, num2, num3, num4);
lr_log_message(”getvalue : %s”, result);
web_submit_form(”Register;jsessionid=6726009A7D21963602B166D91C883413″,
“Snapshot=t2.inf”,
ITEMDATA,
“Name=Register.reason”, “Value= “, ENDITEM,
“Name=set_attach”, “Value=result”, ENDITEM,
LAST);
return 0;
}
本文来源于天行健，君子以自强不息 http://www.rickyzhu.com , 原文地址： http://www.rickyzhu.com/173_case-three-of-loadrunner.html

 

可以利用LR的内置函数web_get_int_property判断HTTP服务器的返回状态, 如下是一个简单的例子:
#include "web_api.h"

Action()
{
int HttpRetCode;
web_url("my_home","URL=http://myhomeurl","TargetFrame=_TOP", LAST);
HttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE);

if (HttpRetCode == 200)
 lr_log_message("The scrīpt successfully accessed the My_home home page");
else
 lr_log_message("The scrīpt failed to access the My_home home page ");

 return 0;
}

看到xingcyx兄博客上一篇关于LoadRunner Pacing的设置文章,完全是根据他自己的经验写的,并且参考了Kirk的一些观点,后面引发了多位高手的激烈讨论,其实讨论本身比文章更有吸引力. 所以就转了过来. 原贴的位置: http://www.blogjava.net/xingcyx/archive/2006/12/28/90498.html
在 LoadRunner 的运行场景中，有一个不大起眼的设置，可能经常会被很多人忽略，它就是 Pacing 。具体设置方式为： Run-Time settings à General à Pacing ，这个设置的功能从字面上就很容易理解，即在场景的两次迭代 (iteration) 之间，加入一个时间间隔（步进）。设置方法也很简单，这里就不赘述了，我在这里想说明的是，这个设置到底有什么作用？为什么要进行这个设置？说实话，虽然我在以前做过的一些性能测试中，偶尔会对这个步进值进行一些设置，但其实对它的真正含义和作用，我还并不十分清楚。
前段时间，我在对X银行招聘信息系统进行性能测试的时候，发现这个值的设置对于测试的结果有着很大的影响，很遗憾当时没有深入研究这个问题，而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章，读完之后，再用之前我的测试经历加以印证，真有种豁然开朗的感觉。以下就将我的一些体会与大家分享：
通常我们在谈到一个软件的“性能”的时候，首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的：
“要求系统支持 100 个并发用户”
看到这样的性能需求，我们往往会不假思索地就在测试场景中设置 100 个用户，让它们同时执行某一个测试脚本，然后观察其操作的响应时间，我们都是这样做的，不是吗？我在实际实施性能测试的过程中，也往往都是这样做的。可惜的是，我们中的大多数人很少去更深入地思考一下其中的奥妙，包括我自己。
事实上，评价一个软件系统的性能，可以从两个不同的视角去看待：客户端视角和服务器视角（也有人把它叫做用户视角和系统视角），与此相对应的，又可以引出两个让初学者很容易混淆的两个概念：“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的，而“每秒请求数”则是从服务器视角去定义的。
因此，上面所描述的做法的局限性就是，它反映的仅仅是客户端的视角。
对于这个世界上的很多事情，变换不同的角度去看它，往往可以有助于我们得到更正确的结论。现在，我们就转换一下角度，以服务器的视角来看看性能需求应该怎么样定义：
“要求系统的事务处理能力达到 100 个 / 秒” ( 这里为了理解的方便，假定在测试脚本中的一个事务仅仅包含一次请求 )
面对以这样方式提出的性能需求，在 LoadRunner 中，我们又该如何去设置它的并发用户数呢？千万不要想当然地以为设置了 100 个并发用户数，它就会每秒向服务器提交 100 个请求，这是两个不同的概念，因为 LoadRunner 模 拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间 的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们 想要在测试过程中维持一个稳定的每秒请求数（ RPS ），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（即多次迭代），通过多个事务 (transaction) 的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道， LoadRunner 是以客户端的角度来定义“响应时间”的 ，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载， 但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试 结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其 实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。
因此，为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。这就是我在文章开头所提到的 Pacing 这个值的作用。
最后再补充一句话：虽然性能测试通常都是从客户端活动的角度定义的，但是它们应该以服务器为中心的视角来看待。请注意这句话，理解它很重要，只有真正理解了这句话，你才会明白为什么我们一直强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络，因为我们希望评价的是软件系统真正的性能，所以必须排除其它一切因素对系统性能造成的影响。
花了几天的时间才完成这篇文章，如果它能够帮助大家对性能测试多一些理解或者多一些思考，那就是我的荣幸了。 ^_^
参考资料：
Kirk Pepperdine 《 Tuning your stress test harness 》
http://www.theserverside.com/tt/articles/article.tss?l=StressTest
 
 
下面就是回复了:
 
e: 谈谈LoadRunner中Pacing的设置 2006-12-28 23:15 | Jackei
其 实这篇文章最早是在 2006 年初看到的，过去几个月，发现对里面的内容已经有点遗忘了。所以看到你在我 blog 留言后，就又翻出来看了几遍。这次再看，发现有不少地方同 Kirk 的看法有分歧。本来想专门写篇文章来讨论一下，不过看到兄台已经打了个基础，不妨咱们就依照这个基础来讨论下去 ^_^
由于晚上时间也有限，所以我想今天我先说说我对 Tuning your stress test harness 这篇文章的一些不同看法，改天咱们可以继续讨论，搞个连载 ^_^
Kirk 在 Tuning your stress test harness 一文中提出的一个重要的观点就是“放慢速度，做得越多”。这其实是一种场景设计的思路，Kirk 提出这个的原因是他认为那些“不增加服务器负载的线程看起来会降低服务器的性能”，于是，Kirk 通过人为的方法来限制了 RPS（Request per Second）的值——这里我们要注意到的是，实际上 Kirk 是将 RPS 控制为小于 The Number of Concurrent Users 的值。以文中的例子来说，Kirk 是在 50 个并发用户的情况下，将 RPS 控制在了 9 个左右。这样的结果是什么？不知道你有没有注意到，在这篇文章中，Kirk 是以 RPS 作为指标衡量系统负载的，这种做法就算是所谓的“服务器视角”了吗？
我们知道对于一个给定的系统来说，在某个特定的环境和场景中，它的“最佳并发用户数(The Optimum Number of Concurrent Users)”是客观存在的——关于“最佳并发用户数”的概念可以参见我的《LoadRunner没有告诉你的之三——理发店模型》一文（http://www.cnblogs.com/jackei/archive/2006/11/20/565527.html ）。当并发用户数大于这个“最佳”时，就会出现排队的情况。如果这个并发量一直持续，那么随着时间的流逝，队列也会越来越长，而越往后的请求在队列中等待 的时间也越长，从性能测试工具中看到的响应时间也会越来越长。而这就是 Kirk 认为不合理的地方。但实际上是这样吗？当我们使用 LR 或者 JMeter 这类性能测试工具测试时，队列真的会越来越长吗？响应时间也会越来越长吗？
今天先写这么多，如果有了不同的看法，我们明天继续 ^_^
e: 谈谈LoadRunner中Pacing的设置 2006-12-29 10:06 | xingcyx[匿名]
谢谢Jackie的回复！
按照我的理解，Kirk所说的RPS，是以服务器为视角来看的每秒请求数，也就是每秒钟到达服务器端的请求，而不是从客户端发出请求的频率，我们 知道这二者是会有差别的，否则的话，我们也用不着一直强调说做性能测试的时候一定要排除网络等因素的影响。同时这也是我看这篇文章获得最大的一个收获，因 为他教我们用一个不同角度去看待问题。不过说实话，我也没有弄明白他把RPS设成9的原因，从他的描述和图中，我看不出这其中的对应关系。这个问题其实也 让我想了好久，但他所说的RPS代表服务器视角，这一点我还是比较认同的，不知道你的意见如何，欢迎继续讨论。
当我们使用LR等工具的时候，队列确实不会越来越长，这个问题Kirk在文中也提到过了，他想告诉我们的是，由于我们所使用的工具的限制，导致了 看似服务器在应付一种稳定状态的负载，其实却是个发散的队列（因为工具会在收到服务器响应后才会发出第二个请求），这也是他所指出的问题关键所在。但响应 时间的确会越来越长的，因为当客户端收到服务器请求以后，如果我们没有设置延时，那么客户端会立即发出下一个请求，同时启动计时器，而此时如果服务器的资 源已经满负荷，这个请求并不会进入排队队列，那么这个时间其实是多计算的，因此后面的这些请求的平均时间将越来越长，导致整个平均值不准确。
另外这里我再提一个没有在我上面的文章中提到的一个问题，就是这个以“服务器视角”提出的性能需求应该是什么样子的，以前从来没有考虑过这个问题。
e: 谈谈LoadRunner中Pacing的设置 2006-12-29 12:25 | wufeiwufei
我也看过这篇文章，但我当时就发现这篇文章其实并不是写给测试工程师看的，我认为kirk想象中的读者应该是那些性能优化工程师（虽然国内这两个职业常常放到一块，因为国内对性能优化所能做的事情最多的大概就是添加硬件呢）。为什么这么说呢？因为角度不一样。
1、测试工程师站在客户角度，对客户来说请求的响应时间就是请求的排队时间加上请求的处理时间再加上网络传输的时间。测试工程师需要做的是按照需求，设置 场景，然后验证排队时间加上处理时间加上传输时间是符合客户的忍耐标准的。在这个标准下，找到最优并发数，最大并发数。
2、而对性能优化工程师来说，他们的目标是系统，设计的系统有没有问题，只和系统的本身有关，而不应该考虑那些客观存在的条件，传输的时间太长是网络问题 和系统无关，传输时间不应该考虑进去，排队的时间是操作系统的问题，如果已经排除呢系统设置的线程池（例如数据库连接池）的问题，那么也不应该考虑进去。 性能优化工程师要考虑的是，系统处理那些连续的请求，处理时间是否有线性上升，大概在什么样的请求数量下已经不符合系统设计时候的处理时限要求。
最后再举两个例子：A客户需求上要求100个并发用户下，数据库查询响应时间不能大于5秒。B系统设计书上设计系统处理单个查询请求不能时间不能大于2 秒。对A的测试脚本很好写，对B的测试场景设计起来要相对复杂，因为你要找到那个持续点，也就是kirk指的收敛点，并设计出pacing值。
e: 谈谈LoadRunner中Pacing的设置 2006-12-29 12:53 | xingcyx[匿名]
同样谢谢wufeiwufei的回复！我的BLOG是新开张，留言的人还不多，没想到一出手的就全是行家！^_^
你说的不错，kirk这篇文章的确更适合给性能优化工程师看，我不知道国外对于性能测试工程师和性能优化工程师是否有明确的定义和分工，但至少在 国内，这二者的区别是不大的。到目前为止，我所接手过的性能测试工作，大部分也是同时承担这二者的角色的，因为客户或者项目经理，请你来做性能测试工作， 不仅仅是要你指出系统存在什么性能问题，并且往往还希望你能告诉他们如何去解决。而且我也是这样来要求自己的，作为性能测试工程师，我认为我们也只有能够 做到这一步，才更有成就感！:)
e: 谈谈LoadRunner中Pacing的设置 2006-12-29 20:39 | Jackei
嗯，我现在来扮演反方吧，指出 Kirk 在文中的一些前后矛盾的地方，也是我对他的思路存在质疑的地方。
Kirk 在文中提到：我们将看到服务器正在处理稳定的请求流，而处理请求的时间似乎越来越长（“只做力所能及的”的那一节）。后面有提到：不增加服务器负载的线程 看起来会降低服务器的性能。并且“因为线程一离开就进入系统，就造成了这样的情况：线程必须等待其他每个线程完成后才能被服务。在这种场景下，线程越多就 会造成队列和响应时间越长。”——（“三思而后行”那一节）
如果大家对性能测试工具的工作原理比较熟悉，那么不难发现 Kirk 的理解的确存在一些偏差。首先，当某个系统在一个给定的环境和场景中时，它的“最佳并发用户数”是客观存在的，也就是说系统的响应能力的限度是客观存在 的。当每秒的请求数量大于这个限度时，必然会导致某些请求需要排队。但是这个排队并不会像 Kirk 说的那样——线程越多就会造成队列和响应时间越长。
我们举个例子来看：
- 假如系统的最佳并发用户数是 10，那么当并发用户数为 20 时（假定是 R1-R20），如果系统依旧平稳的每秒完成 10 个请求的响应，那么我们可以看到。第一秒的时候，R1-R10 完成了响应，而 R11-R20 在排队。第二秒时，R11-R20 被响应，而 R1-R10 又重新进入队列等待处理；第三秒，R1-R10 被处理，R11-R20 在排队…… 周而复始下去。Kirk 的看法，说到根本上就是认为这个队列会越来越长，所以他要控制一下。但是就如上面我们所说的，当并发用户数大于最佳并发用户数后，出现排队是正常的。而 Kirk 的方法最终的结果是让工具模拟了 100 个用户，但是系统在任意时刻却只有 50 个负载。认为的将负载控制在最佳并发用户数的范围内有意义吗？
所谓的“放慢速度，做得更多”，那么什么时候做得最多？当并发用户数等于系统的最佳并发用户数时系统做得最多，因为这时系统的整体效率最高。
Kirk 在文章最后的部分的论述，说明他明白性能测试工具工作的原理，所谓的稳定的请求流，而处理请求的时间似乎越来越长的情况是不会出现的——恰恰相反的是，请 求流是稳定的，响应时间也是稳定的。而他用大用户量模拟小并发量的做法我更是不赞同。因为在我的观点看来，RPS 并不是很适合用来度量负载的大小，因为在实际的测试中，这个值只与系统的响应能力有关。理论上来说，RPS 其实是等于 TPS 的，而 TPS 是用来度量系统的响应能力的。
另外，Kirk 在文中的观点认为，响应时间的延长是因为队列造成的，“不增加服务器负载的线程看起来会降低服务器的性能”。但是事实上并不是这样的。因为那些线程并非“不增加服务器负载”，而响应时间的延长也不单单是因为后面的线程的响应时间中包含了排队时间。
个人观点：最佳并发用户数是衡量系统性能的一个很关键的指标，而 Kirk 在整篇文章中关注的其实是当并发用户数大于最佳并发用户数以后的情况。他通过人为的方法将系统的负载控制在最佳并发用户数上下。所以，我认为他提出的以 RPS 来衡量系统负载的方法并不是合适，因为真正应该关心的其实应该是系统在任意时刻的负载。
说实话，我现在觉得 Kirk 这篇文章的思路并不是很清晰，或许是因为他没有提供更多的背景信息吧。
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 10:05 | wufeiwufei
Jackei兄还是没有理解kirk的意思啊，kirk并不是一个测试工程师，他主要是从事java性能优化的，所以注定他必定是站在开发人员的角度去理解系统性能，直接的说他是为了发现程序中的性能问题而尽量避免因为硬件或是操作系统带来的影响。
我把你举的例子进一步假设：这是一个基于80端口的web项目（我们暂且叫做A程序），采用的windows nt操作系统，该操作系统对于80端口的连接限制为6个，A程序在运行过程中最多向cpu申请到4个线程。每个用户每次只发一个请求。
让我来按照我理解的kirk的思想分析你举的例子的：
1、让我们先来看看10个最佳并发用户数都在干些什么。按照单cpu来看，系统在一个时间片上只处理一个请求，也就是说只有1个用户被系统处理，那么其他 的9个在干什么呢？按照假设，3个请求已经申请到线程，在等待cpu处理。6个请求在操作系统端，已经建立了连接，等待分配线程。
2、当20个并发数产生时，他们又在干什么呢？还是只有一个请求在被cpu处理，还是只有3个请求申请到线程，在等待cpu处理，仍然只有6个请求在操作系统端，已经建立了连接，等待分配线程，但是我们发现却多了10个请求在等待进入80端口，还没有建立连接。
3、那么kirk作为java程序优化工程师，什么是他关心的呢？有两点是他最关心的。a、每个请求的A程序处理时限；b、A程序对资源的占用和释放，对 cpu线程申请是否合理。前一个很好理解，后一个我再做进一步解释，程序写的好坏，有很大一部分在于对资源的占用和释放，假设有个死循环在系统里，那么一 旦申请到资源（cpu时间片），它始终不释放，必然导致cpu占用率一直是100％。再假设如果按照cpu的处理能力，A程序其实可以申请到4个时间片进 行处理，但是实际上由于某个线程没有及时释放资源，或者对于一个需要长时间的请求没有sleep，导致只能申请到2个时间片，那就需要优化程序了。
通过上面的解释我们就可以发现其实只有4个请求的处理时间是kirk关心的。而其他的，那并不是程序优化应该关心的事情，你可以转交给系统工程师进行进一步的优化。
4、那么如何才能让这4个请求的处理时间更加准确了？很显然，由于loadrunner只能从发出请求就开始计算时间，因此如果前面的等待端口和等待分配 线程的时间越长，那么得到的数据就越不准确。最合理的是根本就不要等待端口，最好每个请求都能直接建立并得到线程，进入cpu处理队列，当然因为我们并不 知道cpu实际的队列长度，所以很难进行控制。
5、那么我们应该怎么作呢？首先我们找到最佳请求数，因为我们知道最佳请求数其实就是已经建立连接的6个请求加上分配到线程的3个请求，再加上1个正在处 理的请求。然后我们逐步减少最佳请求数，其实也就是减少建立连接等待分配线程的请求数，随着逐步的减少，等待分配线程的时间也就减少，最终当我们减少到4 个时，我们发现响应时间不再提高，我们也就找到了我们最关心的响应时间的最准确值。这个过程就是kirk说的从发散到平稳到收敛的过程。
6、我们还应该注意什么呢？因为我们无法把握cpu的处理时间，所以我们也不可能算好，第5个请求正好在第一个请求处理完成后发起，因此我们不可能准确的 找到这个值。所以我在上个回复中说了，我们只有尽可能的接近收敛点，反复设置pacing值，好达到第5个请求到达时间接近第一个请求的释放时间，或是第 6个请求到达时间不超过太多第一个请求释放时间。
7、什么是系统真正的性能，什么是程序A的最佳并发数？系统真正的性能并不等同于用户需求定义的性能，在kirk理解上，系统真正的性能是系统处理他应该 去处理的事所得到的性能。如果请求建立连接的数量越多，那么必然耗损cpu时间，从而降低去处理A程序的效率，因此kirk认为我们应该减少并发数量，去 测试真正的系统性能。而从这个角度理解，4个用户才是kirk认为的最佳并发数。
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 10:17 | wufeiwufei
@xingcyx
一个性能优化工程师所要积累的知识并不是看看书，编编程就能达到的，我觉得一个优秀的性能优化工程师大概要有3年的操作系统级编程经验，2年的web经验，3年的数据库经验，再加2年的测试经验。
而国内根本不具备这个条件，对测试的轻视，对技术的追逐，导致有几个资深的开发人员会进入这个行业，导致有几个项目能给你时间，成本去积累这些知识。这真是可悲啊。
所以我觉得，我们这批测试工程师只能更多的发现问题，更多的去揭示问题，让中国的软件行业快点意识到其实还有一片更大的天空。
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 13:33 | Jackei
想到一个问题：如果我们以单位时间 1 秒来衡量系统的处理能力，发现每秒可以响应的请求数量是 10，也就是说每秒“流出”的是 10，那么是否可以认为最佳的请求数 RPS 也是 10 ？
也就是说，我们知道通常一个请求并不是只用一个 CPU 时间片就可以处理完的，而且单个 CPU 时间片是很短的。那么我们对于最佳请求数的评估是否要有一个时间单位做为基准？例如 1 秒。那么如果以 1 秒做为基准，是否最佳请求数同我之前提到的最佳并发用户数是同一个概念？
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 14:00 | xingcyx[匿名]
还是那句话，这应该是同一个问题，从两个不同的方面去理解。
我看过你写的《LoadRunner没有告诉你的》，里面对于“最佳并发用户数”的解释，我是赞同的，但“最佳请求数”这个概念，我相信很少有性 能需求会这样去提的。所以我觉得还是像wufeiwufei所提到的那样，国内把测试工程师和性能优化工程师两个角色混在一起了，因此这二者之间的界限很 模糊，在我做过的性能测试工作中，很多都是混在一起的，而偏偏客户和测试者都没有意识到这一点。
因此我是这样来理解的：如果是以用户的角度去测试，那之前谈到的最佳并发用户数的概念是没有错的，而一旦是涉及到性能瓶颈的定位、调优等，那还 是需要从服务器的角度去测试。系统是否存在一个“最佳请求数”，并不是很重要，我们只需要保证在测试的过程中，能够使系统维持一个稳定的负载，保证测试结 果准确、可信，不会有偏差就够了，也就是kirk说的，让服务器的队列处于稳定的而不是发散的状态。
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 14:48 | wufeiwufei
@Jackei
我觉得可以这么理解，但是最佳并不是非常合适，虽然从大的方面讲增加请求数会在一定程度上增加cpu的负载，因而导致rps在某个阶段是有个最大的值，但 实际上这和性能测试工程师理解的最佳有一定的差别的，性能测试工程师得到最佳并发用户数是更多的为了验证用户要求的性能目标或是为了以后的扩容有个量的了 解，而从测试中得到这个rps更多的是为了发现问题进行优化，而不是为了达到某个目标，从这个角度来讲，rps没有最佳。
我一直认为rps对我们现在来说没有太大的意义，为什么这么说呢？
这是由于现在的性能测试过程决定的。现在的测试过程一般是：根据业务需求，设置目标，进行性能测试，获得基础数据－>根据数据对比业务需求，分解 transcation，设置关注点－>再次测试 这样一个循环的过程。我们之所以认为有问题，是因为我们站在用户角度去进行测试，对于客户来说是不管是设备的问题还是软件的问题都是我们的问题，因此对于 我们来说并不需要按照kirk的方式去追求rps，因为在这个过程中，我们可以把等待连接和分配进程的时间看成一个常量，而这个常量在所有的 transcation中都是存在的。我们更多是去确定是那个trancation有问题，然后针对这个transcation进行优化。
而kirk是这样测试的（仅仅是我自己的看法），分别对软硬件进行性能测试－>软件寻找rps－>根据经验，判断是否合理－>然后进行优化。
看出这两个差别了吗？举个例子更好理解，项目A要求100个并发数下动态页面的响应时间不大于5秒，静态页面的响应时间不大于2秒。举出三种测试情况：
1、动态页面是6秒，静态页面是1秒。
2、动态页面是6秒，静态页面是3秒。
3、动态页面是4秒，静态页面是1秒。
只有在第二种情况下，我们才会去寻找是否是硬件的问题。而通常在这种情况下，其实我们已经要求更换硬件了。
而对kirk来说，三种情况并没什么区别，他一样要找到rps，然后根据技术标准来看是否需要对程序进行优化。
为什么会造成这种差别呢？我认为最重要的原因，国内没有积累，企业缺少规范，非常缺少性能优化工程师这类专业人才，只有用业务需求的标准来衡量，而没有真正的技术标准，没有技术标准，即使我们得到rps，你又如何分析出是否合理，是否需要优化呢？
以上只是我一家之言，而且我对操作系统层面的东西也不是很清楚，毕竟我只作过1年不到的开发。
很高兴能和你们一起交流。
我的联系方式:wufei@133sh.com
msn:wufeisuliang@hotmail.com
re: 谈谈LoadRunner中Pacing的设置 2007-01-08 18:03 | 关河
呵呵，好容易看完了这么长的文章和评论，感觉这是精彩绝伦，赞一个先：）
严重同意wufeiwufei的观点，Kirk提出的问题，其实关键点在于他是从 “代码优化” 的角度来考虑问题的，他要的结果是“没有任何疑义的完全由于代码执行消耗的时间”，而不应该包括“队列等待时间”。
但对测试工程师来说，我们的任务是准确地知道真正的用户在使用这个系统时的性能感受，也就是完全的用户视角的“响应时间”，那当然应该包括全部的时间范围在内，Kirk提出的方法并不适用——所谓目的不同。
另外， 提出一点我的个人意见，上文所提到的RPS（或是TPS），我认为可以作为一个衡量系统压力的主要指标，在我看来，并发用户数和TPS都是在进行性能压力测试，或是衡量响应时间的依据，只有说“在XX用户数下，在XXTPS水平下”，响应时间才是有意义的。
re: 谈谈LoadRunner中Pacing的设置 2007-01-09 09:36 | xingcyx[匿名]
连关河老师都来参与讨论了啊，呵呵！
Kirk确实是从“代码优化”的角度来考虑问题的。我不知道国外对于测试工程师和性能优化工程师这两个角色是否有严格的划分，但至少我自己在实际 工作中，是没有分的，很多时候我都要身兼这两个角色，所以我觉得学会从两个角度来看待性能，是很有必要的，这也是我看Kirk文章的收获。另外，在我所做 过的性能测试中，通常都会要求将后台服务器的一些无关进程、服务停掉，并且尽量使网络独立、或者保证带宽足够，这样的做法，本质上也是在确保使测试出来的 性能结果尽量接近“实际的代码执行时间”。不知道各位在实际的工作中是怎样做的，这个问题也希望大家踊跃讨论。
关于关河老师最后提到的将RPS（TPS）作为衡量系统压力的指标，我也非常认同。
re: 谈谈LoadRunner中Pacing的设置 2007-01-09 15:00 | wufeiwufei
@关河
“在XX用户数下，在XXTPS水平下”，响应时间才是有意义的。 ”
我觉得准确得应该说 在xx用户数下，响应时间是多少，并单独加上tps值，和响应时间作为并列的性能指标。tps提交给开发组，响应时间记录进性能测试报告中。
我有几点问题，想请教关老师，jackei，xingxing等各位前辈同仁
1、我们都知道现在的性能测试，几乎都是根据预定的系统目标来衡量，而对代码的执行效率几乎没有任何评估，在这种情况下tps这个值到底还有多大意义。
2、如果我们真的关注代码的执行效率，那么通过loadrunner等性能测试工具得出tps值既烦琐而且得出的数值对定位问题几乎无多大的帮助，而据我 所知行业中有针对java和.net的应用级的监控工具（例如：wily公司的introscope），从这个工具可以很轻松的观察到各个程序块的相对运 行时间，随着并发用户数增加的，处理时间，占用资源的情况。那么kirk这篇文章又有多大的作用呢？
re: 谈谈LoadRunner中Pacing的设置 2007-01-10 09:25 | xingcyx[匿名]
@wufeiwufei
说说我的想法。
问题1：以我的实际经验来看，tps这个值通常是客户方关注得比较多，这是他们衡量一个应用系统性能好坏的一个重要标准。而对于项目组（程序代码的直接开发者）的性能定位、调优则几乎没有什么帮助。换句话说，这个值更多的用于“性能评测”，而不是“性能调优”。
问题2：你提到的wily公司的introscope主要是帮助我们来定位应用系统的性能问题，而kirk这篇文章则启发了我们，根据不同的测试目的应该有不同的测试策略。如果你的性能测试是为了定位程序中的性能问题，就应当尽可能地排除其它因素的干扰。
另：introscope这个工具我曾经看过wily公司的演示，感觉还可以，但我自己试用的时候却没配置成功。不知道你有是否对它有研究？
re: 谈谈LoadRunner中Pacing的设置 2007-01-10 09:41 | wufeiwufei
@xingcyx[匿名]
不好意思，写错了，不是tps，我的意思是rps，你可能没有明白我的意思，我是说我们现在的测试立足点基本就是站在客户方，而调优仅仅是在达不到客户方 要求的情况下才进行的，因此我觉得过分追捧kirk的理论对我们现实的测试工作没有任何帮助，因为即使我们利用这个理论去找到最接近系统处理能力的 rps，但是实际上也无助于我们进行性能调优（因为我们几乎无法对这个值进行评测）。
至于introscope的设置不好搞，我个人认为也因而导致他的推广的不力，我自己并没有单独成功配置过，基本上都需要他们的支持人员帮助才能搞定（通常还要花很长时间）
re: 谈谈LoadRunner中Pacing的设置 2007-01-31 17:40 | 槛外人
看了上面各位大侠的评论，收获颇多。
非常同意wufeiwufei的观点，我们现在的性能测试相当于验收测试，在功能差不多稳定的情况下，验证系统是否满足需求方提出的各个性能指标。而Kirk跟我们进行的不是一个层面的工作。他不管用户需求，只考虑自己的程序是否还有调优的空间。
有关于RPS说几句。在我们公司的测试中，性能指标不是由需求方提出来的，而是我们测试人员根据线上的日志分析出出来的。一般关键的指标是2点：TPS和 响应时间。而并发用户数我们是不关注的。跟我们系统本身的特点有关。我们做的是网络支付行业，一般来说，如果用户不提交请求，只浏览页面，对于系统造成的 压力我们是忽略的。
TPS是测试工程师分析线上的日志情况，计算出每天的高峰请求数。响应时间则是按照行业内的2/5/8原则。
按照这样的情况设计的测试场景[测试工具是LoadRunner]，是基于目标的场景，即设置系统每秒要达到的TPS，至于并发用户数是工具根据响应时间自动计算出来的。
在这种情况下，我在想Pacing的设置可能没有太多的关系。因为我们的测试本身就是以服务器的角度来考虑的。不知道这样的想法是否正确，还请各位高手指点。
终于贴完了,精彩吧.希望以后类似的讨论会越来越多.

时间管理可分为以年为单位的时间管理，以天为单位的时间管理和以小时为单位的时间管理三个层次。
以年为单位的时间管理
每年一月份，我都会制定新的一年的行动计划，以及审视去年的实施情况（参见：2002 - 2003 - 2004）。这个计划的逻辑是：1）职业/生活目标，2）我的强项/弱项，3）具体的支持活动。只有制定了一年的计划，我才知道有朋友叫我去唱歌的时候是不是该拒绝，我才知道晚上是不是放弃看《康熙来了》而研读逻辑，我才知道要定期在当当上买书、做卓越的终生VIP。以年为单位的“有目标的”时间管理，帮我省下来的是若干月的时间。
以天为单位的时间管理

上帝给了每个人公平的每天三个八小时。第一个八小时大家都在工作，第二个八小时大家都在睡觉。人与人的区别都是第三个八小时创造出来的。如果你每天花3个小时上下班，2个小时吃早中晚饭，1个小时看电视，那你自由支配的时间就只剩2个小时了。你可能会非常节省的用它来陪女朋友看电影，健身或者唱歌，打打游戏。但是如果你从交通、睡觉、吃饭里分别省出一些时间花在学习上，你的学习进步将是惊人的。如果你把这些时间花在拓展交际、锻炼身体、参加公益，你的人脉增长将是同样惊人的。
以小时为单位的时间管理
我们和CPU一样都是分时系统，只不过芯片每秒分成上亿份，人类一小时分成四、五份。每一个时刻我们只能做一件事情，如果被打断再转回来的时候会有一定的时间浪费在回忆刚刚在做什么、做到哪里。我们需要锻炼在不同事务之间迅速切换的本领，这样就会更加有效的利用每一个小时的时间，在每一个时间片里 100%的专注。这要借助工具，所以我一直在非常大的依赖于微软的Outlook和我的智能手机来管理我的每一个小时。把事情分为“轻重缓急”，按照规律去顺序处理。
如果你不能以年的方式来管理时间，那么这样白白浪费掉的时间让以小时为单位的时间管理显得毫无意义。如果不能在每一个小时上有所节省，那么每年的时间也无法真正管理。这三种层次是缺一不可的。
本文来源于天行健，君子以自强不息 http://www.rickyzhu.com , 原文地址： http://www.rickyzhu.com/331_manage-your-time.html

        测试人员,对公司产品进行测试时,对原有业务逻辑掌握越清楚,越容易做好该业务的升级和改造任务的测试工作，那么怎么衡量测试人员对现有业务的掌握程度，并进行客观的评价呢？
       思虑已久，通过测试分析小组的讨论，我们产出了下面这份业务能力掌握程度考核评定方法。

 

 

一、              建立review题库

1.         每个业务产品至少给出10个考核题目，题目要分的细一些，每个题目确定好权值；

2.         所处的题目覆盖该产品的主要功能，题目之间难度系数序列化递增；

3.         针对每个考核题目，题目根据难度的不同分为四个等级：

A：难度很高，涉及到不同产品、不同系统之间的交互关系或者数据模型；

B：难度较高，涉及业务细节以及数据库主要字段及相关日志的变化

C：难度较低，涉及业务流程的操作

D：难度很低，相关的一些概念性的理解

4.         针对每个等级设置不同的权值

A：1.0

B：0.8

C：0.5

D：0.2

5.         题库的题目需要列出对应的产品，给出的答案可以不用很详细，但必须给出关键点。

二、              review过程

1.         每个月都选择1-2个同学进行业务review，可以先选择试用期结束的同学，再选择新来的同学以及其他已经过了试用期的同学，主要目的是督促大家学习；

2.         选择review的问题可以根据该同学来的时间以及所负责的业务模块去选择对应的题目，如果不是很熟悉的，可以从低难度的问起，逐步提高难度；

3.         Review时间控制在每人半小时以内，review题目在10个左右；

4.         根据被review同学的掌握程度适当的调整题目的难度与提问个数；

5.         提问者可以选择性的提一些问题，也可以根据上一个问题回答的情况进行追问，以达到了解相关业务熟悉的程度；

三、              review评价

1.         根据回答的问题的答案分为5个等级的分数：

a：5分，回答得很全面

b：4分， 回答得较全面，漏掉某些信息，但是在提问者的引导下给出全面的答案；

c：3分，回答的一般，遗漏不重要的信息，在引导下也未给出正确答案；

d：2分，回答得较残缺，遗漏比较重要的信息，在引导下也未给出正确答案；

e：1分，回答得很残缺，只知道大概的东西或者听说过相关概念；

f：0分，完全不知道问题是什么

2.         review结束以后根据提出的问题以及回答的满意度评定一个分数；

3.         最后评定的分数邮件抄送给主管以及STA；

4.         STA根据被review的同学在review过程中回答的业务问题给出整体评价，指出掌握的好的业务以及不足需要改进之处，让该同学可以有针对性的学习提升；

 

四、              分数评定说明

1.         每一题最高得5分，按照权值乘以题数相加之后再除以题目数目；

2.  假设一个同学A类1个题得4分，B类3个题得5分，C类4个题得3分，D类2个题得2分，则最后得分为（1.0x1x4+0.8x3x5+0.5x4x3+0.1x2x2）/10=2.24

3.         最后评定等级

5：Perfect

[3.5-5)：优秀

[2.5-3.5)：良

[1.8-2.5)：合格

[0-1.8)：有待提高

4.         分数段划分原则

1)         1.8：期望每个同学在B、C、D类问题起码可以达到3分，大致分配为：B（4题）+C（5题）+D（1题）

2)         2.5：期望每个同学在B、C、D类问题可以达到4分，大致分配B（4题）+C（5题）+D（1题）

3)         3.5：期望每个同学在A、B、C、D类问题可以达到4分以上，其中有几题需要5分，大致分配A（1题）+B（4题）+C（4题）+D（1题）

更新方式：

.      Each Occurrence

每次遇到参数就进行更新。

多次使用同一参数，而且没有什么关联，例如随机数。

Each Iteration

每次迭代时发生更新。 如果参数出现几次，虚拟用户用同一个数值。

适用同一个关联的参数。

Once

所有的地方都用同一个数值，包括所以的迭代。

文件类型参数分派方法

Sequential

按照顺序访问。

 

	更新方式	Sequential	例子
1.	Each Iteration	所有用户每次迭代同时取下一个数值。	All the Vusers use Kim in the first iteration, David in the second iteration, Michael inthe third iteration, etc.
2.	Each Occurrence	所有用户每次遇到同时取下一个数值，即使在同一个迭代。	All the Vusers use Kim in the first occurrence, David in the second occurrence,Michael in the third occurrence, etc.
3.	Once	所有用户第一次迭代时同时取第一个值，该用户所有的子迭代值不变。	If you specified Once, all Vusers take Kim for all iterations.

 

例子：

First Name

Kim

David

Michael

Jane

Ron

Alice

Ken

Julie

 

没有足够的值，从第一行开始重新取值。

 

 

 

 

 

Random：每个虚拟用户开始运行时安排随机的数值。

 

	更新方式	Random
1.	Each Iteration	每次迭代时，随机从数据表中取数。
2.	Each Occurrence	每次遇到随机取一个数值，即使在同一个迭代。
3.	Once	第一次迭代时随机取值，改用户所有的子迭代值不变。

 

 

数据必须足够，例如20个虚拟用户，5次迭代，至少要有100个数据。

http://www.rayfile.com/zh-cn/files/24552c9c-1b5a-11dd-b1d1-0014221f4662/

软件质量是指软件的功能和性能满足用户需求和期望的程度。随着IT技术在各个行业的广泛深入地应用，软件质量成为普遍重视的因素。如何有效地提高软件质量，增强软件产品的竞争力，是软件企业管理和技术人员共同面对的问题。

软件质量重于泰山

软件质量重于泰山，软件质量是核心竞争力之一。现在和未来软件企业的竞争力不仅体现在产品类型的多样性，产品功能的先进性，更多的体现在产品质量的稳定性和可靠性。软件应用的领域不断深入，设计的复杂程度逐步扩大，开发的周期不断缩短，质量的要求水涨船高，软件企业面临着巨大挑战。

用户对软件产品质量的要求不断提高，促使软件企业把提高软件质量作为增强竞争力的策略。提高软件质量要素在哪里？可以通过采用软件设计技术，加强软件过程管理，实施软件测试等方法。从提高软件质量的显著程度、投资回报率和可实施性等方面比较，实施有效的软件测试，提高软件测试的效率，是保证软件质量的最显著方法。

软件测试是通过技术、流程、工具、人员以及管理手段，检测软件文档、软件中间产品和最终产品，查找和报告软件缺陷、错误以及隐患的专业技术。通过跟踪缺陷、错误及隐患的修正过程，确保软件产品、中间产品和文档符合软件工程过程需求和用户的最终需求。

软件测试创新之道

软件测试在国内仍处于起步阶段，各种软件测试的方法、技术和标准都还在探索阶段。国内软件行业普遍规模偏小，缺乏大型软件产品经验，开发过程不够规范，这决定了国内软件质量和测试行业，必须根据国内行业现状，确定软件质量目标和测试策略方法，而不是照搬照抄国外成熟软件企业的测试方法。

1.观念创新

提高软件质量的决定因素不是软件测试技术，而是对软件质量和测试的思想观念。只有把提高软件质量上升到企业战略发展的高度，才能从根本上解决问题。长期以来，国内软件行业对软件质量重视程度不足，对于软件测试的作用认识不够，造成项目因质量问题造成进度推迟甚至失败。

为了彻底改变这种被动现象，企业高层管理人员必须从管理思想、资源支持等方面为软件质量和测试部门提供全力支持。软件项目经理必须坚持软件开发和软件测试并行处理并且互相协调。软件开发人员重视和配合软件测试人员。
观念创新不要仅停留在口头上，而要落实在具体行动上，通过软件质量和测试的有效流程进行推动，通过过程改进进行提高。通过有效组织管理，形成以重视软件质量为荣，以轻视软件质量为耻的工作氛围。

2.流程创新

测试流程决定软件质量。软件测试如同软件开发一样，需要经过收集测试需求、确定测试策略、设计测试、执行测试、分析测试等流程。软件测试不是软件开发的最后阶段，而是贯穿于软件项目的整个生命周期。决定软件测试成败的关键是软件测试需求是否完整、准确，测试策略是否有效和实用，测试设计是否覆盖了测试需求。

软件测试流程既不是僵化的生搬硬套，也不是随机的增添取舍。软件企业的质量管理部门和项目开发团队需要根据公司技术、资源现状，针对项目的特点和客户需求，从保证软件质量、项目进度和测试成本等方面，进行优化设计并且不断改进流程管理。对于项目周期长、应用领域广、对质量要求高的软件，必须制定和遵守严格的测试流程。

测试流程创新的目标是在公司内部制定和执行完善的项目质量管理体系。优化项目生产方式，跟踪和度量生产过程和产品，使得生产过程和各阶段产品处于可控制和可度量状态，保证产品符合客户的功能和进度需求。

3.技术创新

软件测试是一项软件工程领域的专业技术，而不是简单的把软件测试认为随便找个人运行几次软件，就可以发现全部的软件问题。前文已经提到，软件测试需求和测试设计是决定软件测试效果的关键因素，因此，加强测试技术创新的重点是在测试需求和设计设计的创新。

在软件测试技术创新方面，要避免陷入过渡追求自动化测试技术的误区。自动化测试确实可以在某些方面显著提高测试效率和准确性，但是自动化测试只适合测试软件的某些方面的质量（例如性能测试，回归测试等），80%左右的软件缺陷是靠测试人员手工测试发现的。

对于某些特别需要自动化测试的软件特性，需要加强开发软件测试工具，而不是全部依赖市场上的现有测试工具。这是因为商业工具功能繁多，价格昂贵，培训和学习周期很长，选择不当就会造成巨大浪费。

4.管理创新

软件测试管理的目标是实现软件质量、进度、成本之间的最佳平衡。有效的测试管理需要企业管理层、软件开发团队、质量保证与测试团队通力合作，采用计划、组织、领导、控制等手段，组建高效团队，制定完善的测试流程，做好测试设计，有效执行测试，加强过程跟踪，从而顺利完成质量保证和测试任务。

测试管理创新的核心是软件质量和测试的团队建设，软件质量和测试是技术密集型活动，团队的知识结构、创造力和凝聚力是保证测试流程、测试技术充分实施的基础。质量和测试团队建设的重点是设置和培养各类技术和管理人才，进行有效交流，形成良好的评估和促进机制。

测试管理创新的另一个重点是测试管理平台建设。包括构建测试项目管理的集成系统，实现公司产品和项目数据信息的有效管理和顺序控制，使项目数据透明化，技术知识有效传承，项目质量和进度数据化、图形化。可以根据公司的现状，购买软件测试管理的商业工具，也可以内部开发软件测试管理工具。

软件测试技术路线图

如果把软件测试之道称为测试战略，要发挥测试战略的现实意义，需要把测试战略转化为测试战术。测试的“道”与“术”的无缝集成，才能显著地、持续地、逐步地提高软件产品质量。实施软件测试的战术是一系列过程的组合，涉及测试团队建设、流程设计、测试平台、测试管理等多个方面。

1.测试团队建设

测试团队可以是测试部，也可以是测试组。公司规模决定了测试团队的大小和组织形式。测试团队建设需要执行两个原则：第一，测试团队必须独立于开发团队，而不是附属于开发团队，实现测试的独立性和公正性；第二，测试团队必须具有明确的工作目标，即发现和报告软件缺陷，推动和确认缺陷修正，协助软件开发的过程改进，提高软件整体质量。

软件测试团队根据规模可以设置多个职位，每个职位具有明确的岗位职责，例如，测试部门经理、测试项目经理、测试组长、测试架构师、高级测试工程师、测试工程师等。对于刚刚成立的测试团队，可以一个人兼任多个职位，完成多项测试任务。测试人员的总数应该与开发人员相适应，最好在1：1到1：2之间。

2.流程设计

测试流程设计必须与软件设计流程相对应，基本测试流程包括测试需求分析，测试计划设计、测试用例设计、测试执行、测试评价、测试总结等。

根据软件需求和软件设计规格说明进行测试需求分析，测试需求分析的目的是明确需要测试的对象、特征、范围和方法，从而制定测试计划，确定测试策略。

测试计划设计是为了有效配置测试过程、人员和工具，充分利用现有的资源，按照项目计划进度，组织有效的测试。测试计划设计的输出结果是测试计划文档，它是指导软件测试活动的纲领性文档。

测试用例设计是指导具体测试内容和方法的关键内容，如果需要执行自动化测试，还需要依靠测试用例设计生成对应的测试脚本。测试用例设计的输出结果是不同类型的测试用例，这些测试用例必须以标准的、一致的形式设计、评审、存储、更新。

测试执行是发新和报告软件缺陷的阶段，根据软件计划的进度，分配测试内容，构建测试环境，依靠测试用例运行测试程序和程序文档。测试执行的输出结果是缺陷报告，测试进度报告等。

测试评价是度量软件测试执行效率和有效性的过程。测试评价的输入是测试用例的执行情况，软件缺陷的报告数据。测试评价的输出包括测试用例的有效性分析，软件缺陷的类型和有效性分析等，测试进度和有效性分析等。

测试总结包括测试过程每天或者每周的过程总结，也包括测试项目结束后的测试项目总结。测试总结的输出是测试总结报告，总体评价软件质量，指出测试存在的问题，提出改进的方法和进程，总计测试的有效经验。

3.测试平台设计

测试平台设计包括测试技术平台设计和测试管理平台设计。测试技术平台包括设计测试环境，设计或设置测试工具等。测试管理平台设计包括测试文档系统设计、测试版本配置管理、缺陷数据库设计、测试进度和质量分析系统设计。

测试技术平台设计需要根据测试计划的测试内容和测试环境要求，组织软件、硬件、数据库和网络等，这经常是一项较为耗时的工作，同时它影响着测试的正确性，必须尽快在测试开始阶段完成，最好采用有效的方法把搭建的测试环境进行备份保存，以便今后可以快速恢复，重复利用。

测试管理平台设计，影响测试管理的复杂度，好的测试管理平台可以使测试管理人员，方便的跟踪、查询、分析测试进度，评估测试人员的工作绩效，评价测试的总体质量。对于测试技术人员而言，可以方便的寻找测试对象和测试文档，报告和输出测试结果，共享测试数据，提高测试效率。

4.测试管理

测试管理关注人员、过程、产品三要素的互动与变化，测试管理包含项目计划和组织结构管理，测试阶段管理，时间、资源和质量管理，文档管理和团队管理等。测试部门经理、测试项目经理和测试组长是测试管理的主要执行者，需要与测试团队成员、开发人员、公司管理人员密切配合。

为了加强测试管理，需要确保测试数据信息流通畅，使测试团队、开发团队、质量保证团队之间有效交流。测试管理的其他内容包括团队成员参与各种培训，客观积极的绩效评估，识别项目测试风险，实现人尽其才，信息共享，进度可控，规避风险，降低成本，提高质量。

结论

提高软件质量是提高产品竞争力的重要因素，加强软件测试创新是显著改善软件质量的实用方法。软件测试创新是循序渐进的过程，从建立完整的质量管理体系入手，通过团队建设、优化流程、技术创新，加强管理，实现人员、流程和技术的和谐统一，提高软件质量的可预测试性和可控制性。

选自《Web性能测试实战》

      

        配套性能测试课程：

        1、LoadRunner性能测试入门与虚拟用户开发基础（点击进入）

        2、LoadRunner Controller使用基础（点击进入）

      

        请看下面一个性能测试小案例：

某公司OA产品的新版本即将发布。为了看看系统的性能，决定安排测试工程师A君执行性能测试任务。A君做法如下：

1.       找到一台PC机，CPU主频1G，内存512M，……；

2.       在找到的PC机上搭建了测试环境：安装了Oracle9i、Weblogic等系统软件；

3.       在自己的工作机上安装了LoadRunner7.8;

4.       然后录制了登陆、发布公告等功能；

5.       开始设置30、50、100、500不同的并发用户数目进行并发；

6.       最后得出结论：系统只能运行80个左右的并发用户……。

无疑上面的做法存在很多不合理的地方，例如测试内容太少、测试服务器配置太低等。现实工作中，尽管性能测试以其在测试中独特的地位越来越为软件测试人员、开发人员和用户所重视，但是不管是测试人员还是开发人员，仍然在认识上存在这样或者那样的误区。

误区1：提高一下硬件配置就可以提高性能了，因此性能测试不重要。

这是以前系统规模不大时期留下来的认识。DOS时代以及后来Windows操作系统流行的初期，软件规模一般较小，而硬件的更新却是日新月异，软件性能一般不是突出问题，因为只要升级一下硬件，很容易就解决了性能问题。

现在随着软件规模的扩大，提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题，再多的资源可能也不够用，例如内存泄漏问题，随着时间的增加，内存终究会被耗尽，最后导致系统崩溃。

因此，如果用户对软件的性能要求较高，这将意味着不但要从硬件方面来提供性能，还要从数据库、WebServer、操作系统配置等方面入手来提高性能，同时开发的软件系统本身也要进行优化，以便全面提高性能。

误区2：性能测试在所有其它测试完成后，测试一下看看就可以了。

这是目前特别普遍的一种现象，例如前面的A君，这种现象主要是没有意识到性能测试的重要性。这种做法最严重的后果是如果性能问题是由软件系统本身产生的，可能会无法根治性能问题。例如架构设计方面的失误，可能意味着软件系统将被废掉。

当然这并不意味所有的性能测试都要尽早进行，性能测试的启动时间要由软件特点来决定。性能测试策略的制定问题可以参考《程序员》2005第10、11期的《治疗软件亚健康》。

误区3：性能测试独立于功能测试。

功能测试可以发现性能问题，性能测试也能发现功能问题。性能测试和功能测试是紧密联系在一起的，原因之一是由于很多性能问题是由软件自身功能缺陷引起的。如果应用系统功能不完善或者代码运行效率低下，通常会带来一些性能问题。功能测试通常要先于性能测试执行或者同步进行，软件功能完善可以保证性能测试进行得更加顺利。

误区4：性能测试就是用户并发测试。

仍然有很多人（尤其是开发人员和部分项目实施人员）一提到性能测试，就会联想到并发用户测试，进而认为性能测试就是“测试一下多用户的并发情况”。严格地讲，性能测试是以用户并发测试为主的测试。实际性能测试还包含强度测试、大数据量测试等许多内容。

误区5：在开发环境下进行一下性能测试就可以了。

很多时候，在软件开发完成后会进行性能测试，看一看软件的性能。实际上大多数的开发环境因为硬件条件比较差，所以反映不了过多的性能问题。

因此性能测试要尽量在高配置的用户投产环境下进行。但是有两种可以例外的情况：一种是为了发现某些功能方面的问题，例如为了发现并发算法的一些缺陷；另外一种就是有非常好的硬件资源或者实验室作为开发环境。

误区6：系统存在瓶颈，不可以使用。

系统发现了瓶颈，的确是很让人担心的一件事情。不过不要紧，很多的瓶颈可以不必去理会。发现瓶颈的目的主要是为了掌握系统特性，为改善和扩展系统提供依据。因此在性能方面给系统留有30％左右的扩展空间就可以了。

例如，1000个用户并发时发现了系统瓶颈，而客户的最大并发用户数量在500左右，这样的性能问题完全没有必要处理，要是550或者600个并发用户出现性能问题就应该认真地调整系统性能了。

误区7：不切实际的性能指标。

这种现象主要归结于对软件应用需求的不了解。很多时候，尤其是用户会提出很多不切实际的性能指标，例如，针对500个用户使用的OA系统，可能有的用户负责人会提出要满足100个甚至500个用户并发的性能目标，而实际并发数量不会高于50。这种情况只有和用户进行沟通才可以解决。

上面列举的都是日常性能测试工作中相关人员常犯的错误，这些观点只在极其特殊的情况下才正确。希望读者了解这些常见的性能测试误区后，能在以后的工作中避免类似的情况。

 

选自《Web性能测试实战》

      

        图书配套性能测试课程：

        1、LoadRunner性能测试入门与虚拟用户开发基础（点击进入）

        2、LoadRunner Controller使用基础（点击进入）

 

注：转载请注明出处与原文地址。 

在各类软件测试工作中，性能测试往往不被重视，而项目中由于系统性能不合格带来损失的例子却非常多。造成这种现象的原因之一就是各个公司习惯压缩测试成本，而在性能测试方面的投入则更少。

本文重点介绍如何基于场景来设计性能测试。选择典型的用户场景来进行测试，不但可以大大降低执行成本，更能提高性能测试执行效率。

在以前的《治疗软件亚健康》中，笔者重点讨论了运用“全面性能测试模型”来组织各类性能测试的方法。“全面性能测试模型”提出了设计性能测试用例的框架，在实际项目中通过它可以确定性能测试用例的范围和类别。而在测试用例内容确定后，接下来就要设计各类性能测试用例中的具体内容。

性能测试按照场景不同一般可以分为两大类，一类是为了测试目的而进行的场景测试，另外一类是基于用户实际情况而进行的场景测试。因此，性能测试用例的设计应该面向性能测试场景来进行。

实际上，由于开发环境硬件配置不高，基于用户的测试多在用户现场进行，而为了测试目的而进行的测试多在开发环境即开发团队内部进行，不过两者进行的场所没有严格的界限，例如也可以在开发团队内部模拟用户的环境进行性能测试。

“为了测试目的而设计的测试用例场景”主要根据测试设计人员的经验来进行，但是仍然要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据。例如一些业务系统，虽然备份历史数据的周期为一年，但是设计大数据量测试用例时仍然包含了系统运行一个月、半年等的数据量模拟测试，因为这些均属于用户的典型场景。

综合上面可以看出，性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。下面详细介绍一下常见的三类用户场景：

一天内不同时间段的使用场景。在同一天内，大多数系统的使用情况都会随着时间发生变化。例如对于新浪、网易等门户网站，在周一到周五早上刚一上班时，可能邮件系统用户比较多，而上班前或者中午休息时间则浏览新闻的用户较多；而对于一般的OA系统则早上阅读公告的较多，其他时间可能很多人没有使用系统或者仅有少量的秘书或领导在起草和审批公文。这类场景分析的任务是找出对系统产生压力较大的场景进行测试。

系统运行不同时期的场景。系统运行不同时期的场景是大数据量性能测试用例设计的依据。随着时间的推移，系统历史数据将会不断增加，这将对系统响应速度产生很大的影响。大数据量性能测试通常会模拟一个月、一季度、半年、一年、……的数据量进行测试，其中数据量的上限是系统历史记录转移前可能产生的最大数据量，模拟的时间点是系统预计转移数据的某一时间。

不同业务模式下的场景。同一系统可能会处于不同的业务模式，例如很多电子商务系统在早上8点到10点以浏览模式为主，10点到下午3点以定购模式为主，而在下午3点以后可能以混合模式为主。因此需要分析哪些模式是典型的即压力较大的模式，进而对这些模式单独进行测试，这样做可以有效的对系统瓶颈进行隔离定位。与“一天内不同时间段的场景测试”不同，“不同业务模式下的场景测试”更专注于某一种模式的测试，而“一天内不同时间段的场景测试”则多数是不同模式的混合场景，更接近用户的实际使用情况。

上面只介绍了三种典型的场景，实际项目中分析场景一般不会孤立的分析某一特定类型场景，而是把两种或者几种类型场景结合起来进行分析设计，这样做主要是为了选择更典型的场景和节省一些测试成本。

有了上面的基础知识，下面开始逐一讨论各类测试用例设计的细节。在下面的讨论中，将以图2所示的某视频点播网站做为示例，图2显示了该视频点播网站的主要业务以及各个时间段使用场景。

 

图2网上视频点播系统使用情况图

1、 确定用户使用系统情况的方法

确定用户对系统的使用情况是设计用例具体数据的基础，后面并发用户数据设计、疲劳强度设计、以及各种场景设计都要依赖对用户使用系统情况的分析结果。分析用户使用情况经常采用现场调查和分析系统日志两种方法。

l  用户现场调查

用户现场调查实际就是通过和用户进行沟通，进而确定用户的人员组成情况。这类方法适用于用户群体固定且目标测试系统没有投产前的情况。

l  分析系统日志

很多时候，通过和用户沟通不能掌握其使用系统的详细情况，尤其是诸如图2的网站业务系统，因为目标用户使用系统的情况是不确定的。当用户比较分散、现场调查比较困难时，可以采用对系统日志进行分析的方法，以此作为对用户现场调查信息的补充。

大多数的系统都会对用户使用系统的情况进行日志管理，因此可以对日志进行分析，日志分析方法适用于已经投产或者试运行的系统。如果没有系统日志功能，可以和开发人员进行沟通，在测试过程中增加日志管理功能。通常分析系统日志可能要开发一些程序来对其进行统计分析。

在具体设计过程中，一般是两种方法结合使用。图2的网上视频点播系统就是通过两种方法得到的测试数据：通过和用户进行沟通得到全国各地维护人员使用系统的大概情况，然后通过对系统一个月的日志进行分析得出其它用户使用系统的情况，最后综合在一起就得到了系统的使用情况图。

也许有人会问：为什么不通过日志分析得出全部的用户使用情况？主要原因有两个：一是日志分析不一定能得出全部的使用情况，可能产生偏差，例如用户反复登陆系统、注册多个帐号都会影响统计结果；二是日志分析往往较用户调研成本大，因为多会涉及开发工作。

2、 并发用户数量设计

并发用户尤其是最大并发用户数量的设计一直是网上很多测试论坛津津乐道的话题。在前面文章中，已经介绍了并发用户和并发用户数量两个概念，下面将在其基础上讨论一下如何在性能测试用例中设计并发用户数量。

在设计并发用户数量前，首先要了解确定系统最大并发用户数量的方法。下面介绍根据系统的最大使用人数或者最大在线数量来评估最大并发用户数量的方法（注：这里的最大并发用户数量不是指系统支持的最大并发用户数量，而是指系统在生存周期内可能达到的最大并发用户数量）。

l  极限法。取最大在线用户数作为最大并发数，这种方法适用于系统已经投产或者目标用户群体不确定的门户网站，可以通过分析日志来得出结果；也可以使用系统已经注册的用户数量做为系统的用户数量，然后按照经验公式来估算最大并发用户数量。

l  用户趋势分析。对软件生存周期内的用户未来走势进行分析，预测系统可能达到的最大使用用户数目，从而估计系统的最大并发用户数目，这种方法多用于系统用户数目逐渐增加的情况。

l  经验评估法。按照经验来评估系统可能的最大并发用户数，这种方法多用于系统的使用用户数目相对稳定且比较明确的系统。

完成最大并发用户数量的评估后，接下来就可以设计每个用例要模拟的用户数量。表1是上面OA系统的一个性能测试用例。

功能		系统支持多个用户同时进行登录邮件系统的操作。
目的		测试多用户访问邮件模块时系统的处理能力。
方法		模拟多个用户在不同客户端登录邮件，然后进行并发进入邮件系统的操作
并发用户数与事务执行情况
并发用户数	事务平均响应时间		事务最大响应时间	事务成功率	平均流量（字节/秒）
30
60
90
110

表1 性能测试用例并发用户设计示例

通过表1可以看出并发用户数量的设计很简单，基本是按照最大并发用户数量的百分比来设计，例如可以按照最大用户的20％不断增加来设计并发用户数量，直到达到最大并发用户数量。对于某一特定的用例，设计用户数量需要注意下面三点：

（1）              按照各类用户同时递增的方式来设计用户数量。按照递增的顺序设计测试用例是为了按照由浅入深的方法来发现系统的瓶颈，因此系统的各类用户应该同时增加。

（2）              并发用户数的最大值一般不会超过前面计算的最大并发用户数量的20％，除非是为了测试系统能支持的最大并发用户数量。

（3）              设计用户数量时要考虑成本，因为每组用户数都意味着至少执行一次测试。

综合上面的内容，可以看出用户并发数量设计是很灵活的，不用拘泥于公式和形式，只要充分考虑到用户现在和未来的增长趋势就可以了。

3、 系统不同时间段场景的设计

不同时间段的场景更接近用户使用情况，也是设计核心模块和组合模块并发性能测试用例的基础。例如图2的网上电影点播系统，每两个小时使用系统的情况都是不同的，因此需要设计一些典型的场景。

不同时间段场景分析的数据来源主要是前面的需求分析和日志分析结果。通过图2，很容易看出各个时间段不同模块的用户是如何并发的。有了上面的资料，就可以设计各个时间段的组合模块测试用例。下面是图2所示的网上电影点播系统“0~2点” 场景的一个测试用例：

模块名称	并发人数	运行时间
扣费批处理	20	1小时
帐号维护	60
系统备份	11

上面场景的并发人数只是一个实际例子，如何设计最大并发用户可以参考本节“并发用户数量设计”和“业务模式设计”的相关内容。

查看(289) 评论(0) 收藏 分享 管理