当一台主机上安装多个浏览器时，LoadRunner录制脚本经常遇到不能打开浏览器的情况，可以用下面的方法来解决。

　　启动浏览器，打开Internet选项对话框，切换到高级标签，去掉“启用第三方浏览器扩展（需要重启动）”的勾选，然后再次运行VuGen即可解决问题

　　提示：通常安装Firefox等浏览器后，都会勾选上面得选项，导致不能正常录制。因此建议运行LoadRunner得主机上保持一个干净的测试环境。

　　2.录制Web脚本时，生成的脚本中存在乱码该如何解决？

　　录制脚本前，打开录制选项配置对话框Record-Options，进入到Advanced标签，先勾选“Support charset”，然后选择中支持UTF-8。再次录制，就不会出现中文乱码问题了。

　　3.HTML-based script与URL-based script的脚本有什么区别？

　　使用“HTML-based script”的模式录制脚本，VuGen为用户的每个HTML操作生成单独的步骤，这种脚本看上去比较直观；使用“URL-based script”模式录制脚本时，VuGen可以捕获所有作为用户操作结果而发送到服务器的HTTP请求，然后为用户的每个请求分别生成对应方法。

　　通常，基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本；而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用了HTTPS安全协议，这时使用“URL-based script”模式进行录制。

　　4.为什么脚本中添加了检查方法Web-find，但是脚本回放时却没有执行？

　　由于检查点功能会耗费一定的资源，因此LoadRunner默认关闭了对文本及图像的检查。要想开启检查功能，必须修改运行时的配置Run-time Setting。

　　进入“Run-time Setting”对话框，依次进入“Internet Protocol→Preferences”，勾选Checks下的“Enable Image and text check”选项即可。

　　检查执行结果时推荐使用web_reg_find方法。

　　5.运行时的Pacing设置主要影响什么？

　　Pacing主要用来设置重复迭代脚本的间隔时间。共有三种方法：上次迭代结束后立刻开始、上次迭代结束后等待固定时间、按固定或随机的时间间隔开始执行新的迭代。

　　根据实际需要设置迭代即可。通常，没有时间间隔会产生更大的压力。

　　6.运行时设置Log标签中，如果没有勾选“Enable logging”，则手工消息可以发送吗？

　　Enable logging选项仅影响自动日志记录和通过lr_log_message发送的消息。即使没有勾选，虚拟用户脚本中如果使用lr_message、lr_output_message、lr_error_message,仍然会记录其发出的消息。

　　7.LoadRunner 8.0版本的VuGen在录制Web Services协议的脚本时一切正常，而回放时报出错误提示“Error：server returned an incorrectly formatted SOAP response”。这时说明原因引起的？

　　造成这种情况的主要原因是LoadRunner 8.0的VuGen在录制Web Service协议的脚本时存在一个缺陷：如果服务器的操作系统是中文的，VuGen会自动将WSDL文件的头改为<?xml version=”1.0” encoding=”zh_cn”?>，因此会有上面的错误提示。

　　解决方法：把“LR80WebservicesFPI_setup.exe”和“lrunner_web_sevices_path_1.exe”两个补丁打上即可解决。

实验环境：Weblogic Server/Express 8.1 、Window professional 2000、Ant2.0

阅读对象：刚接触Weblogic而对怎么布署Web（暂不含J2EE）不甚熟悉的初学者

前提：webapp在Tomcat下能够正常工作，具有正常的webapp目录结构，包含所需的web.xml；Weblogic Server/Express 8.1正常安装并能正常启动，设置了域和Server，这里以域default和Server KEZC为例加以说明。

Weblogic_Home : D:＼bea

WeblogicServer_Home: D:＼bea＼user_projects＼domains＼default

Weblogic Server/Express 8.1支持三种布署方式：自动布署、命令行布署(可和Ant结合)、控制台（console）布署。下面简要说明三种布署方式。

1、 自动布署：

这里的自动布署特指在WeblogicServer_Home＼applications目录。如果服务器启动期间启用了自动部署特性,则服务器会经常扫描applications目录,看是否增加了新的web布署,或是否修改了web布署的程式.如果有新的布署,则服务器将试图以web根名(目录布署以目录名称为根名,war布署以war名称为根名)作为布署应用的初始化名称和根环境开始自动布署.所以,如果要采用自动布署功能,请将webapp目录或war包拷贝到applications目录下，WeblogicServer会定时检测自动布署。

   怎么允许服务器自动布署呢?只要确保启动服务器的startWeblogic命令(windows下为startWebLogic.cmd,Unix/Linux下为startWebLogic.sh)的PRODUCTION_MODE值为false或不设置即可,这个也是默认值.上述两个文件在D:＼bea＼user_projects＼domains＼default目录下.在此情况下,如果web程式文件被修改,Weblogic Server将会自动加载.这个原则适用于applications目录下的全部三种布署方式.

    另外,虽然应用程式能放置在applications目录下的所有位置,不过自动布署只适用于applications根目录.

2、 命令行布署：

在默认安装条件下,Weblogic Server会包含一个weblogic.Deployer的实用程式,提供基于命令行的布署和管理技术,能方便的和Ant结合进行自动化布署(使用wldeploy任务).

在使用命令行布署之前,要先进行环境变量的初始化,否则系统将识别不了weblogic.Deploy命令:

D:＼bea＼weblogic81＼server＼bin>setWLSEnv.cmd

设置成功,系统返回信息:

CLASSPATH=d: bea JDK141~1 lib tools.jar;d: bea WEBLOG~1 server lib weblogic_sp.jar;d: bea WEBLOG~1 server lib weblogic.jar;d: bea WEBLOG~1 server lib ojdbc14.jar;D: tool java mysql mysql-connector-java-3.0.12-production-bin.jar

PATH=d: bea WEBLOG~1 server bin;d: bea JDK141~1 jre bin;d: bea JDK141~1 bin;C: WINDOWS system32;C: WINDOWS;C: WINDOWS System32 Wbem;D: Borland JBuilder2005 thirdparty ant bin;d: bea WEBLOG~1 server bin oci920_8

Your environment has been set.

周详的参数请参考weblogic.Deployer的帮助信息.

周详的能参考sdj21的<<使用Ant管理设置Weblogic>>

浏览地址为: http://dev2dev.bea.com.cn/bbs/jishudata/ArticleShow.jsp?Id=7

3、 控制台（console）布署：

这里的控制台布署方式是指基于web-UI的布署方式.

启动先前设置好的server,输入:http://localhost:7001/console登录进入管理控制台.

按顺序点击DeploymentsàWeb Application Modules,然后在右框架中点击链接Deploy a new Web Application Module,选择想要布署的web程式所在的目录.

如果web程式可布署的话,在列表中的文件之前会出现一个单选框.

选中要布署的web程式,点击Target Module按钮,输入布署的web程式名称(如果有多个服务器和集群,则还要选择目标服务器和集群),点击Deploy按钮,等待web布署启动.

4、 Weblogic Server/Express8.1编译临时目录：

Weblogic Server/Express 8.1 将JSP/Servlet文件编译为class,存储在D:＼bea＼user_projects＼domains＼default＼KEZC＼.wlnotdelete＼extract目录下相应的子目录中.

5、 Weblogic.xml解析：

Weblogic.xml描述符文件用来对web.xml文件的基本设置和布署特性进行扩展,主要包含针对weblogic server特有的属性,比如安全代理角色控制、缺省web设置等.值得注意的是, 只要web.xml够用weblgic.xml并不是必须的.

Weblogic.xml以weblogic-web-app为根节点,包括以下属性:

description, weblogic-version, security-role-assignment, run-as-role-assignment,

reference-descriptor, session-descriptor, jsp-descriptor, auth-filter,

container-descriptor, charset-params, virtual-directory-mapping, url-match-map,

preprocessor, preprocessor-mapping,security-permission, context-root,

wl-dispatch-policy, servlet-descriptor,init-as, destroy-as

以前一直使用免费简单的Tomcat，近来因为项目需要改用WebLogic，安装配置过程中走了不少弯路。下面就简单介绍一下WebLogic 8安装，并配置一个DefaultWebApp目录。
　　
　　安装过程就不多说了，执行platform812_zh_CN_win32.exe文件，开始安装。安装目录我选在d:\bea，选择完全安装，其他按默认值就行。
　　
　　下面主要看看配置过程，以下步骤按照WebLogic配置出现界面，就不每步抓图了：）
　　1．“开始->程序->Bea WebLogic Platform. 8.1-> Configuration Wizard”，启动Configuration Wizard工具。
　　2．选择“新建WebLogic配置”，单击“下一步”。
　　3．选择“Basic WebLogic Server Domain”，单击“下一步”。
　　4．选择“自定义”，单击“下一步”。
　　5．更改Name，我这儿改为hgknight，单击“下一步”。
　　6．选择“否”，单击“下一步”。
　　7．选择“否”，单击“下一步”。
　　8．选择“否”，单击“下一步”。
　　9．输入“User name”和“password”，单击“下一步”，需要8位，简单一点我就都输入hgknight。
　　10．选择作为Window服务，单击“下一步”。
　　11．默认设置，单击“下一步”。

例子:

create user yuansilai
identified by yuansilai
default tablespace users
temporary tablespace temp;

当使用create user语句创建用户时,该用户权限域为空.可以使用该用户登录到oracle ,但使用该用户不能进行任何操作.给用户授予权限可以使用grant语句来实现.

语法格式:

GRANT system_priv | role TO user

[WITH ADMIN OPTIN]

system_priv:要授予的系统权限

role:要授予的系统角色

with admin option:把向其他用户授权的能力传递给被授予者

例子:

grant dba to yuansilai //授予yuansilai以dba角色

grant create any table,create any view to yuansilai
with admin option //授予用户yuansilai一些系统权限,并且该用户可以向其他用户授权

删除用户:

drop user yuansilai;

drop user yuansilai;
create user yuansilai
identified by yuansilai
default tablespace users
temporary tablespace temp
password expire;

ORACLE中，表空间是数据管理的基本方法，所有用户的对象要存放在表空间中，也就是用户有空间的使用权，才能创建用户对象．否则是不充许创建对象，因为就是想创建对象,如表,索引等，也没有地方存放,Oracle会提示:没有存储配额．

建立数据连接池
1． 启动WebLogic7
2． 打开IE6，在地址栏中输入：http://localhost:7001/console
3． 输入用户名和密码
4． 在左边的目录树中选中Services->JDBC->Connection Pools，单击右侧的Configure a new JDBC Connection Pool.，输入以下信息：
Configuration->General页：
Name = SQL Server Connection Pool
URL = jdbc:weblogic:mssqlserver4:northwind@localhost
Driver classname = weblogic.jdbc.mssqlserver4.Driver
Properties : user = sa
Password =<- sa的密码
单击Create建立连接池。
Targets->Server页：
将myserver(服务器名称)移至右侧的列表中，但击单击Apply

建立数据源
Services->JDBC->Data Sources->Configure a new JDBC Connection Pool
Configuration->General页：
Name ＝ SQLServer Tx Data Source
JNDI Name ＝ SQLServer
Pool Name = SQL Server Connection Pool
选中Emulate Two-Phase Commit for non-XA Driver和Row Prefetch Enabled
单击Create建立数据源。

　　抗纹涂抹法

　　早晚涂上合适的眼部产品是护理的基本步骤，但涂抹眼霜时，并不是胡乱地擦上或以最快的速度扫开便可，要配合独特的涂抹方法，效果才会事半功倍。

抗纹涂抹法步骤一

1.先用指腹之力将上下眼皮撑开，再轻柔地以轻弹的手法将眼霜涂在肌肤上，加快渗透力。

抗纹涂抹法步骤二

　　2.再运用手腕的热力，轻压眼眶位置，维持1分钟，利用热力加强眼霜的渗透。

SOS按摩法 浮肿、眼纹快快消失！

　　每天花数分钟时间，为眼部进行深层按摩，不单可加强眼部循环，更可达到消肿去纹的效用。

点击图片，进入下一页

深层按摩步骤一

　　1 先以无名指于眉头对下位置按压。

深层按摩步骤二

2 再轻按瞳孔位，但不要用力。

深层按摩步骤三 3 将重心移向眼头对下位置。

深层按摩步骤四

4 运用拇指轻压鼻梁两旁位置，有助舒缓压力。

深层按摩步骤五 5 再轻按太阳穴，为整套按摩法作结。

眼部产品加分用法

　　眼部产品加分用法

眼部产品加分用法

　　眼膜：敷眼膜前，应先以精华素打底，并透过密封式原理，让当中的养分能渗入肌肤底层。而敷眼膜后，可将余下的精华素打圈按摩，加强吸收。

　　眼霜：当遇上极端的外在天气时，如极干的气候，可先涂上眼部�ㄠ�，再涂上眼霜，进一步锁紧水分和养分。

　　眼部精华：眼部浮肿时，可涂上精华液，再用冷冻的铁汤匙轻按眼部周边，可达到消肿去水功效。

　　对于软件测试人员而言，在测试中不能正确表示缺陷的严重程度和优先级，这将会影响到软件缺陷管理的质量，不仅不利于有效的处理软件缺陷，还可能影响到软件缺陷的处理时机。特别在软件测试的后期，将影响软件是否能够按期发布与否。近期我在一个测试项目中，由于对缺陷严重程度和优先级缺乏有效处理，最终导致软件验收发布被迫延后。

　　什么是缺陷严重程度和优先级？

　　（1）什么是缺陷的严重程度和优先级

　　软件缺陷是指在软件系统中会导致系统不能实现其功能的缺陷（包括Defect或Bug）。一般来说，软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷来源、缺陷原因等。

　　其中缺陷严重程度是指软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将会对软件的功能和性能产生怎样的影响。优先级是指表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

　　（2）正确评估严重程度和优先级的作用

　　缺陷管理的目标在于：当在软件测试过程中发现缺陷后，能正确评估缺陷并执行及修正系统质量，以创造一个合乎需求的软件产品。因此，软件产品质量很大程度上取决于在测试中发现的缺陷的管理能力。其中软件缺陷严重程度和优先级的正确评估和描述是软件缺陷管理的基础部分，也是测试人员与开发小组交流的基础。一个好的严重程度和优先级评估会用简单的、准确的、专业的语言来反映缺陷的本质。否则，如果评估和描述信息含糊不清，就可能会误导开发人员。因为清晰准确的软件缺陷评估可以提高软件缺陷修复的速度，也可以加强开发人员、测试人员和管理人员的协同工作。

　　因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。为了保证正确评估缺陷的严重程度和优先级，质量保证人员需要经常检查测试人员和开发人员对于这两个指标的评估和处理情况，一发现有问题及时反馈给项目负责人解决。

　　（3）缺陷的严重程度和优先级的级别划分

　　缺陷的严重程度和优先级通常可按级别划分，各个公司对不同项目的具体表示方式有所不同，具体的级别划分需要软件测试前达成一致。常用的缺陷严重程度可分为：致命、严重、一般、较小。致命是指系统任何一个主要功能完全丧失，或用户数据受到破坏，造成系统崩溃、悬挂、死机或者危机人身安全；严重是指系统的主要功能部分丧失，或数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；一般是指系统的次要功能没有完全实现，但不影响用户的正常使用；较小是指使操作者不方便或遇到麻烦，但它不影响功能的操作和执行的一些小问题。

　　常用的缺陷的优先级表示方法可分为：立即解决、高优先级、正常排队、低优先级。立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需要优先考虑；正常排队是指缺陷需要正常排队等待修复；而低优先级是指缺陷可以在开发人员有时间的时候再被纠正。

　　（4）缺陷严重程度和优先级的关系

　　严重程度高说明缺陷对软件造成的质量危害性大，是需要优先处理，而严重程度低的缺陷可能只是软件不太尽善尽美，可以稍后处理。因此，缺陷的严重程度和优先级是含义不同但相互联系密切的两个概念，它们是从不同的侧面描述了软件缺陷对软件质量的影响程度和处理方式。

　　一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。

　　如何评估缺陷严重程度和优先级？

　　（1）明确用户需求，设定软件质量标准

　　我们常常听到许多自称测试专家的人在大谈特谈缺陷严重程度和优先级的标准，例如什么系统死机就一定是高级别，界面错误则是低级别之类。但事情上，对于不同的软件因为应用场合的不一样，即使是同一类型的缺陷但也可能其严重程度和优先级是不一样的。

　　一般来说，软件程序并不需要十全十美，因为尽善尽美意味着成本巨大，但软件产品必须迎合和满足目标用户的需求和期望。因此，对于一个软件产品,应该从客户角度来建立缺陷严重程度和解决优先级。了解对用户来说什么是最重要的，而不只是根据经验和常识来制定缺陷的严重程度和优先级。

（2）实事求是的确定缺陷严重程度和优先级

　　通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。但实际上，优先级和严重程度是有联系也有区别。严重程度高的，必然优先级也要高，但优先级高的，严重程度却并非也一定高。

　　那么，怎么样才能使得一个包含缺陷的软件产品却看起来性能优良呢?具体说很大程度上是根据公司和客户需求来决定的。简单说，就是缺陷对客户影响严重程度（主要、次要、不严重），就是对软件产品的影响严重程度；缺陷客户的优先级（紧急、普通、不急）就是项目的优先级。所以，并非所有的缺陷都是一样的重要，也并非根据以往的项目经验就能确定软件缺陷的严重程度和优先级。判断的依据应该是从软件最终用户的观点来做出判断，即判断缺陷的严重程度是先考虑用户的利益，例如此类缺陷是否会对用户使用造成恶劣后果的严重程度。因此，根据用户需求和期望，是分析和评估缺陷严重程度至关重要的一步。

　　但缺陷优先级却不只是依据客户需求来判断的，缺陷优先级还必须要根据开发角度和资源投入来进行划分和评估优先次序。一般来说，测试比较规范的团队，会由测试经理、项目经理等部门根据技术角度和公司资源来制订一份优先级的标准文档。因为缺陷的修正顺序是个复杂的过程，不单是纯粹技术问题，除了要站在开发的角度去考虑问题外，更多的还要考虑抢占市场先机和公司资源分配的情况。

　　另外，为了确保软件缺陷的有效管理，在一定环境和条件下缺陷应该可以改变优先次序，如升级和降级。就是说随着项目进度，可能会重新划分严重程度和优先级别。因此，确定和评估缺陷严重程度和优先级要全面了解和深刻体会缺陷的特征，要从用户需求、开发角度以及市场的因素综合考虑。

　　（3）避免两种常见的误区

　　正确评估缺陷的严重程度和优先级不是件容易的事情，对于经验不是很丰富的测试人员而言，经常犯的错误有两种情形：一是将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，不但影响到对软件质量的正确评估，而且也耗费了开发人员辨别和处理缺陷的时间。二是将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。结果到项目后期才发现还有很多由于不正确评估优先级造成的严重缺陷，将会需要投入更多人力和时间进行修正，影响软件的正常发布；或者这些严重的缺陷成了漏网之鱼，随软件一起发布出去可能会造成软件质量事故。

　　巧用评估技术工具，分清轻重缓急

　　因此，正确评估和区分缺陷的严重性和优先级，是测试人员和开发人员以及全体项目组人员的一件大事。这既是确保测试顺利进行的要求，也是保证软件质量的重要环节，应该要引起足够的重视。这里介绍三种常用的技术工具供大家参考。

　　（1）20/80原则

　　管理学大师彼得杜拉克说过：做事情必须分清轻重缓急。最糟糕的是什么事都做，这必将一事无成。而意大利经济学家柏拉图则更明确提出：重要的少数与琐碎的多数或称20/80的定律。就是80%的有效工作往往是在20%的时间内完成的，而20%的工作是在80%的时间内完成的。因此，为了提高测试质量，必须清晰的认识到哪些缺陷是最重要的，哪些缺陷是最关键的。不要拣了芝麻，却丢了西瓜。所以，只有抓住了重要的关键缺陷，测试效果才能产生最大的效益，这也是第一个原则---分清轻重缓急，把测试活动用在最有生产力的事情上。

　　（2）ABC法则

　　古人云：事有先后，用有缓急。测试工作其实也是如此，分清缺陷的轻重缓急，不但做处理缺陷来井井有条，完成后的效果也是不同凡响。因此，我们在测试工作中要时时记住一点，手边的缺陷并不一定就具有第一优先处理的重要性。只有正确的判断，才可将测试活动效率增加数倍。

　　ABC法则是设定缺陷优先顺序重要工具之一。这ABC工具的关键点在于根据缺陷的重要程度决定优先顺序，按需求目标进行量化规划。把A类缺陷作为测试最重要的最有价值的最关键的缺陷，并保证首先把A类缺陷先处理。其次是B类，然后是C类，然后是其它的，还有一些不紧急不重要的缺陷根本没有必要去做。因此，应用ABC方法可更明确地确定各项测试目标，当然也能更明确把要处理的缺陷和它们的优先次序确定。

　　（3）四象限原则，把缺陷进行分类

　　在处理测试缺陷中，常会遇到千头万绪、问题繁多的情况，有些测试人员会被测试出来众多的缺陷所压垮，有些人则是悠然自得、高效完成。到底是什么原因造成这种区别呢？原因在于对缺陷分类是否合理。

　　那么，我们该如何对缺陷进行合理的分类呢？其实很简单，在一张坐标纸上，先划分好四个象限，然后只需记住四个字就行，那就是"轻重缓急"。"轻"，指的是相对重要但不紧急的缺陷；"重"，是指最重要也是最紧急的缺陷；"缓"，指的是不重要也不紧急的缺陷；"急"，则是指不是最重要但却最为紧急的缺陷。理清这种关系之后，就算同时测试许多不同类型的缺陷，也会很快清楚哪些缺陷是必须马上完成，哪些缺陷是可以暂时缓一缓，这样也就不会被堆积如山的缺陷所压垮，测试效率自然也会得到很大的提高。

作者: 潘少红    来源: IT168

　　2、如果是作随机测试时，把测试步骤的点进行速记;

　　3、偶发BUG一般都是严重的，保留现场，让开发人员一起分析留下的现场(如数据的变化，界面窗口的变化等，找出问题的引子，那怕是千丝万缕，只要有一线希望，都要与开发人员一起分析，千万别关机(关机后再重启很多现场已破坏，不少数据是保存在闪存中的)。

　　4、最好的做法：要求开发打开trace，测试版本在执行时能自动把测试的路径，或触发的消息等输出到文件，相当于软件的执行log，这个log对解决偶发问题将大有裨益。

　　5、即使一时没有重现，一定也要录入故障库，并标明发生的概率。在日后不同的迭代版本中进行跟踪验证，并把验证的路径写上。

　　6、事上没有那么侥幸的事，在公司内部出现过的BUG，在用户端一定也会发生，只是时间与频率的问题，所以要视其影响度，是否需考虑由专人处理这类问题。

本文出自aux0的51Testing软件测试博客：http://www.51testing.com/?26026

列表页面显示：

　　● 产品页面刷新性能

　　● 产品上传性能

　　● 产品下载性能

　　目前给出的指标为：

　　延迟：

　　测试项         响应时间  抖动   备注

　　产品页面刷新     <5秒    <2秒

　　产品下载相应时间  <4秒    <2秒

　　吞吐量：

　　编号                项                 吞吐量

　　Perf.T.1 所有登录用户在线状态更改频率  每10分钟1次

　　Perf.T.2 每日页面平均访问量           60000次

　　Perf.T.3 每日下载量                  50000

　　Perf.T.4 平均每日新增会员数量          500

　　Perf.T.5 高峰同一模板下载量           100用户并发下载

　　Perf.T.6 高峰不同模板下载量           150用户并发下载

　　容量：

　　编号       项            容量

　　Perf.C.1 用户数          <=100万

　　Perf.C.2 活动用户数       10000

　　Perf.C.3 模板中心总用户数  <=25万

　　根据如上性能需求及数据我们该如何设计性能测试用例及场景呢？（可以说给出的性能需求很垃圾，没有丝毫价值，但没办法还是点做啊）

　　首先，我不去在乎它要求的性能是什么，我只需要去做在一定的测试环境下对系统进行压力测试，找到各个性能指标的临界点就好了，至于是否达到性能指标，在和性能需求对照编写测试报告即可。

　　所以，针对这几个需要进行性能测试的页面，我们做一下分析，如何设计场景才能尽可能准确地体现出系统的性能：

　　先说一下搜索页面

　　搜索页面根据对项目的了解，搜索后，将所有符合条件的结果遍历出来，显示在前台，每页的显示数量是一定的，超出的部分分页显示。根据上面的描述我们可以看出搜索结果是在将符合条件的所有结果集均发送到前台页面，对于页面显示对性能的消耗我们可以忽略不计，主要的压力来自数据的传输、sql的执行及应用服务器的处理过程，所以我可以从两个方面设计场景：

　　a、虚拟用户一定，不同数据库数量级的情况下，搜索的性能

　　如何确定虚拟用户的数量成为一个关键，我们可以让客户提供一个常规情况下每天访问用户数（如果没有实际数据可参考，可以根据产品方案中期望的用户数来代替），我们就用这个用户数来进行测试；再来分析一下不同的数据库数量级，如果系统运营1年的产品数据量是5万条，那么我们就根据这个值分别取1W条、3W 条、5W条、10W条、20W条数据量来进行测试（具体的分法可以根据实际情况而定），所以对于这个测试目标，我们可以设计5个场景进行：

　　虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间

　　100 10000  搜索页面 随机产生 30分钟 加入思考时间

　　100 30000  搜索页面 随机产生 30分钟 加入思考时间

　　100 50000  搜索页面 随机产生 30分钟 加入思考时间

　　100 100000 搜索页面 随机产生 30分钟 加入思考时间

　　100 200000 搜索页面 随机产生 30分钟 加入思考时间

　　b、一定数据库数量级，不同量虚拟用户的情况下，搜索的性能

　　我们定下来一个常规的数据库数据量，在数据量不变的情况下逐步增加虚拟用户数，测试一下不同虚拟用户压力下系统的性能

　　虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间

　　50  50000 搜索页面 随机产生 30分钟 加入思考时间

　　80  50000 搜索页面 随机产生 30分钟 加入思考时间

　　100 50000 搜索页面 随机产生 30分钟 加入思考时间

　　120 50000 搜索页面 随机产生 30分钟 加入思考时间

　　150 50000 搜索页面 随机产生 30分钟 加入思考时间

　　产品上传

　　影响上传性能的主要因素有上传文件的大小和上传的请求数，所以我们就从这两个方面设计用例。

　　a、虚拟用户数一定，上传不同大小的文件

　　虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间

　　50 100k 上传页面 随机产生 30分钟 取消思考时间

　　50 300k 上传页面 随机产生 30分钟 取消思考时间

　　50 500k 上传页面 随机产生 30分钟 取消思考时间

　　50 800k 上传页面 随机产生 30分钟 取消思考时间

　　50 1M   上传页面 随机产生 30分钟 取消思考时间

　　b、上传文件大小一定，不同量的虚拟用户

　　虚拟用户数 上传文件大小 录制页面 并发用户数执行时间思考时间

　　20  300k 上传页面 随机产生 30分钟 取消思考时间

　　50  300k 上传页面 随机产生 30分钟 取消思考时间

　　80  300k 上传页面 随机产生 30分钟 取消思考时间

　　100 300k 上传页面 随机产生 30分钟 取消思考时间

　　产品下载

　　影响下载性能的主要因素有下载文件的大小和下载的请求数，所以我们就从这两个方面设计用例

　　a、虚拟用户数一定，下载不同大小的文件

　　虚拟用户数 下载文件大小 录制页面 并发用户数执行时间思考时间

　　50 100k 下载页面 随机产生 30分钟 取消思考时间

　　50 300k 下载页面 随机产生 30分钟 取消思考时间

　　50 500k 下载页面 随机产生 30分钟 取消思考时间

　　50 800k 下载页面 随机产生 30分钟 取消思考时间

　　50 1M   下载页面 随机产生 30分钟 取消思考时间

　　b、下载文件大小一定，不同量的虚拟用户

　　虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间

　　20 300k 下载页面 随机产生 30分钟 取消思考时间

　　50 300k 下载页面 随机产生 30分钟 取消思考时间

　　80 300k 下载页面 随机产生 30分钟 取消思考时间

　　100 300k 下载页面 随机产生 30分钟 取消思考时间

　　● 单元测试（Unit Testing）

　　定义：针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的工作；

　　测试目的：检测软件模块对《详细设计说明书》的符合程度。

　　● 集成测试（Integration Testing）

　　定义：在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作；

　　测试目的：检测软件模块对《概要设计说明书》的符合程度。

　　● 系统测试（System Testing）

　　定义：将已经集成好的的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他元素组合在一起，在实际运行（使用）环境下，对计算机系统进行的一系列的测试工作。

　　测试目的：与《需求规格说明书》做比较，发现软件与系统需求定义不符合或与之矛盾的地方。

　　● 回归测试（Regression Testing）

　　定义：软件在测试或其他活动中发现的缺陷经过修改后，进行的测试；

　　测试目的：验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能；

　　特点：回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试；

　　策略：

　　①、完全重复测试：重新执行前期建立的所有测试用例，并确认确认缺陷解决和修改的扩散影响性；

　　②、选择性重复测试：

　　——覆盖修改法：选择直接影响的用例；

　　——周边影响法：选择间接影响的用例；

　　——指标达成方法：达到指标的覆盖率等。

　　流程：

　　1）制定回归测试策略

　　2）确定测试的版本

　　3）按照回归测试策略执行回归测试

　　4）回归测试通过，关闭缺陷跟踪单（问题单）

　　5）回归测试不通过，缺陷跟踪单返回开发人员，经开发人员修改后再次进行回归测试

　　回归测试自动化：（需考虑的问题如下）

　　1）回归测试是一个重复的以前测试的测试，所以自动化是回归测试的追求；

　　2）自动化法包括：程序的自动运行、自动配置，用例的管理、自动输入，测试自动执行，测试结果自动采集、比较及结论的自动输出；

　　3）对比较稳定的可采用QTP、Robot、SilkTest等工具的“捕捉回放”工具；

　　4）为了能实现自动化需要用到脚本语言，如：TCL、Python、Perl等；

　　5）对比较复杂的过程，无法借助工具的需要自己开发专用工具；

　　6）尽早考虑回归测试的自动化，形成工具化、可继承和推广的。

　　●　　其他测试阶段

　　○　　α测试：用户在开发环境下进行的测试，评价软件FLURPS

　　○　　β测试：多用户在实际使用环境下进行的测试

　　○　　验收测试：用户根据合同、《需求规格说明书》或《验收测试计划》对产品进行的验收测试

　　注：FLURPS即：功能、局域化、可用性、可靠性、性能、技术支持

　　首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：

　　* 程序做了它应该做的事情

　　* 程序没有做它不该做的事情

　　因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

　　2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试;

　　不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护(别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化)上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

　　在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。

　　除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。

　　在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30 - 40左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

　　3、测试用例设计是一劳永逸的事情;

　　这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。

　　这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

　　4、测试用例不应该包含实际的数据;

　　测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

　　5、测试用例中不需要明显的验证手段;

　　我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢?是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢?显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

对于刚进入软件测试工作岗位的新人，如何快速、健康的在职业道路上成长，作者谈了几点自己看法：

1、兴趣是最好的老师
　　对于软件测试工作，通常是比较枯燥的，如果没有兴趣很难做到持久。我最近参与了一个软件测试项目，在测试团队中，有三位是在校学生，他们以兼职的身份到公司上班，他们都是软件相关专业的本科生和研究生，基础都不错。但是，只有其中一位表现最突出，因为他很珍惜这份社会实践的工作机会，做事认真，找出了很多高优先级的Bug。
　　另两位同学，在参加项目不到1个月后就以各种理由退出了。在我与他们的交流中，其中一位说测试工作太枯燥了，没有挑战性，他更希望做软件开发的工作。这位同学由于不喜欢做软件测试，实际上他对软件测试技术缺乏基本的了解。所以他在7天的测试工作中，只找到了3个Bug（正常情况下，其他测试人员每天能找到5个缺陷）。因此，从绩效评比中他的成效最低。
　　另一位同学虽然愿意做软件测试，但是他觉得现在的黑盒测试太简单，学习不到测试技术的高级技巧，他更愿意学习白盒测试，能够自己测试软件源代码。而现在的项目没有这部分的内容，所以尽管他工作成绩也不错，但是积极性不高。
　　因此，建议同学们在寻找工作中，首先需要了解，你是否愿意做软件测试，愿意做白盒测试还是功能的黑盒测试，不要盲目的参与到工作中，否则对于用人单位，对于个人的成长都是浪费。

2、测试人员要学会思考
　　测试是个技术工作，需要学会主动思考。如果你遇到一个好的测试主管（组长），他会主动的解决你的测试实际技术难点，这是你的幸运。但是测试问题错综复杂，测试主管工作很忙，他没有时间解决你遇到的任何技术问题，需要你自己分析问题的性质，尝试各种解决方法，搜索网络上的文章，最好如果仍然解决不了才向主管求助。
　　我们反对遇到问题表现得很茫然失措，不要问一些很“弱智”的问题，否则主管认为你解决问题的能力不做，学习能力欠缺，这样对于今后的发展不利。
　　测试人员如何思考？根据问题的现象思考。问题是属于测试专业知识不足引起的，还是测试用例等测试文档模糊、错误引起的，是个别现象还是测试项目的其他内容都存在的普遍现象。测试要从模拟用户使用的角度展看，因此要用最终用的角度，分析问题的严重程度。
　　在询问最终的解决方法前，确保你根据自己的经验尝试了各种解决方法，并且尽量把你发现的问题和猜测，告诉测试主管，证明你已经主动思考了，但是没有找到好的解决方法，或者不能确定是否方法可行。

3、选择适合的测试学习材料
　　软件测试的技术博大精深，对于初学者该从何入手呢？可以从以下几个方面学习：
　　第一是公司提供的培训材料。测试新员工到公司后一般都要经过短暂的培训，这是学习的最好的第一手材料。针对性特别强，都是公司今后用到的测试知识的总结，针对性和实用性都很强。如果有不懂得问题，可以随时提出来，因为你是测试新人，不懂要问，任何人都不会对你的能力表示怀疑。
　　第二是借助测试项目的测试文档学习，包括测试计划、测试用例，测试缺陷数据库，可以先看看以前发现了哪些bug，这些bug是怎么发现的，有什么规律和特征，学习别人怎么写测试缺陷报告。
　　第三是阅读测试书籍和测试网站和论坛。这些内容很多，建议利用工作之后的时间，根据自己的知识有选择的选择测试书籍，先从基础知识阅读。正式出版的书的内容质量都比较高，而测试网站和论坛的文章良莠不齐，有些只是只言片语，很多还存在错误。因此，需要有一定的鉴别能力，否则会误导，浪费时间。

4、巩固测试知识基础
　　练武术需要先练“蹲马步”，否则直接学习刀枪棍棒等十八般武器，只能学到几招皮毛，甚至伤及自己，武林高手都是基础很牢固的，内功很深厚的。
　　做软件测试也是这个道理。很多出入测试行业的新人，希望走捷径，往往听信各种测试培训机构的宣传，认为参加几天的能力提高班，就可以步入测试高手的殿堂，这是错误的，也是要吃大亏的。
　　另一个错误就是还没有学会测试的基本概念，就盲目地学习各种大型商业自动化测试软件，结果花了很多时间和金钱，只是学会了工具的具体操作。到了实际测试项目中，无法有效利用工具解决实际测试问题。
　　实际上，作为测试新手，大部分都是从手工功能测试开始起步的，大型自动化测试只有成为测试高手，才有机会使用。另外测试工具的操作是很简单的技术问题，关键是如何发挥测试工具的作用，这需要测试策略。
　　所以，初学者要老老实实的学习测试基础知识，学习各种测试术语、测试概念、测试分类、测试的流程、测试项目的执行过程等。如果这些都不懂，今后的职业发展会成为限制。
　　学习是痛苦的过程，但是学习是增强技能的必然之路。学习测试知识没有捷径，需要日积月累，需要勤奋，需要思考，需要总结，从一点一滴学起。

5、不断学习行业知识
　　测试人员除了学习和掌握测试技术外，还需要不断学习行业知识，这是区别普通测试技术人员和测试行业专家的最好方法。
　　学习什么行业知识呢？根据你测试的软件的应用领域决定。例如，你正在测试的是电信行业的应用软件，那么你需要学习电信行业知识，包括术语、业务和行业技术。怎么学习呢？可以与客户交流，与开发人员交流，看专业书和文章。
　　学习行业知识是个不断进步的过程，每个行业都有很系统的知识架构，首先学习工作中最需要的理论和技术。然后有机会和兴趣的时候，不断细化和深入。
　　高级的测试人员需要精通测试技术，掌握行业知识，可以提供行业软件的测试和质量保证方案。对于初学者，要认识到经过不断努力，可以成为测试行业专家。千里之行，始于足下，目前最重要的是从测试入门知识开始。