暂无

1、在服务器上任意共享一文件夹，并且启动启动Network DDE，Remote Registry，Remote Procedure Call(RPC)这三个服务；（Network DDE服务不能启动时，先启动（Network DDE DSDM）。
2、开始---->运行---->输入服务器的IP地址,弹出对话框,输入服务器的帐号:administrator,密码:******;
  a.LR的测试机和服务器不在域里面,在输入服务器帐户是(如:服务器的机器名或IP\administrator),在输入密码,使LR的测试机和服务器建立链接,就可以看见服务器共享的文件夹,这样就链接成功了.
  b.LR的测试机和服务器在域里面,在输入服务器帐户是时直接输入:administrator,在输入密码,使LR的测试机和服务器建立链接,就可以看见服务器共享的文件夹,这样就链接成功了.
3、在LR的测试机上进行Windouws资源计数器的添加.

概述: LoadRunner测试方法手册从测试流程, 测试过程, 测试文档输入输出等各个方面描述, 可以称为性能测试方法手册, 我们目前使用的测试工具LoadRunner满足我们测试的需求, 本文主要结合LoadRunner工具来描述性能测试方法. 

 性能测试需求分析

    性能测试需求是由产品提出,客户沟通,或者依据业界标准来获取, 首先目前测试现状来看, 性能需求都会有,但不会很明确. 通过沟通讨论来逐步将客户(或者开发)性能需求转换为测试性能需求,如上图测试过程中的

<!--[if !supportLists]-->1.       <!--[endif]-->确定测试环境 Identify Test Environment

<!--[if !supportLists]-->2.       <!--[endif]-->确定性能可接收标准 

性能测试设计 Plan and Design Tests

性能测试设计先总体来描述, 编写性能测试方案, 必须包括如下方面:

<!--[if !supportLists]-->1.       <!--[endif]-->测试用机和测试软件LoadRunner的部署

<!--[if !supportLists]-->2.       <!--[endif]-->分析测试用机对本性能测试设计是否存在影响

<!--[if !supportLists]-->3.       <!--[endif]-->被测Web应用服务器的部署

<!--[if !supportLists]-->4.       <!--[endif]-->描述测试和被测服务器的网络TOPO

<!--[if !supportLists]-->5.       <!--[endif]-->分析描述网络TOPO可能对本测试设计存在的影响

<!--[if !supportLists]-->6.       <!--[endif]-->性能测试可接收标准(从性能测试需求分析得到)

<!--[if !supportLists]-->7.       <!--[endif]-->性能测试用例设计

<!--[if !supportLists]-->a)         <!--[endif]-->测试目的

<!--[if !supportLists]-->b)         <!--[endif]-->性能测试输入

<!--[if !supportLists]-->c)         <!--[endif]-->数据及数据流向

<!--[if !supportLists]-->d)         <!--[endif]-->性能测试操作过程

<!--[if !supportLists]-->e)         <!--[endif]-->LoadRunner中的Init Action中初始化功能

<!--[if !supportLists]-->f)          <!--[endif]-->LoadRunner中的集合点处理

<!--[if !supportLists]-->g)         <!--[endif]-->Loadrunner中的虚拟用户并发量

<!--[if !supportLists]-->h)         <!--[endif]-->LoadRunner中的End Action中清理功能

<!--[if !supportLists]-->i)           <!--[endif]-->性能测试输出

<!--[if !supportLists]-->8.       <!--[endif]-->LoadRunner性能测试场景设计

<!--[if !supportLists]-->a)         <!--[endif]-->Manual模式

非Web用户只能使用Manual模式,

场景设计要包括多少虚拟用户, 虚拟用户启动过程,虚拟用户停止过程, 虚拟用户运行时间;是否使用IP地址池等

<!--[if !supportLists]-->b)         <!--[endif]-->Goal模式

Web用户分虚拟用户数目标,Hits/Second目标, Pages目标,Transactions数(TransAction需要指定)

<!--[if !supportLists]-->9.       <!--[endif]-->LoadRunner参数设置

<!--[if !supportLists]-->10.   <!--[endif]-->被测试软件监控和日志分析设计 

性能测试功能实现

<!--[if !supportLists]-->1.       <!--[endif]-->测试环境配置

<!--[if !supportLists]-->2.       <!--[endif]-->LoadRunner测试设计实现

LoadRunner性能测试的文档在公网上非常多,帮助手册也很全面,就不再重点描述

<!--[if !supportLists]-->1.       <!--[endif]-->录制代码需要删除和本次测试无关的任务语句

<!--[if !supportLists]-->2.       <!--[endif]-->调试代码可以编写,但正式执行前必须注销,特别是Output Message类型的命令

<!--[if !supportLists]-->3.       <!--[endif]-->明确Web测试模式Html和Http的区别,按照设计来制定

<!--[if !supportLists]-->4.       <!--[endif]-->对动态捕获的数据进行判断

比如web_reg_add_cookie, web_reg_save_param等函数

需要判断”查询”是否注册成功,判断是否取回了数据,判断取回的数据类型是否满足预期,减少实际运行时出现异常.

 性能测试执行和分析

<!--[if !supportLists]-->1.       <!--[endif]-->按照性能测试Case执行

<!--[if !supportLists]-->2.       <!--[endif]-->保存LoadRunner测试结果

<!--[if !supportLists]-->3.       <!--[endif]-->使用Windows性能监控或者Loadrunner来记录Web站点的各个性能计数器

<!--[if !supportLists]-->4.       <!--[endif]-->记录Windows资源的性能计数器,包括CPU,内存,硬盘,网络

<!--[if !supportLists]-->5.       <!--[endif]-->记录CLR的性能计数器

<!--[if !supportLists]-->6.       <!--[endif]-->记录数据库(MS SQL)的性能计数器等

 性能测试报告

<!--[if !supportLists]-->1.       <!--[endif]-->编写各个测试用例的测试结论

<!--[if !supportLists]-->2.       <!--[endif]-->分析和确认目前产品中的性能瓶颈

<!--[if !supportLists]-->3.       <!--[endif]-->记录显示测试过程和测试原始数据

<!--[if !supportLists]-->4.       <!--[endif]-->性能测试优化建议

 性能测试迭代测试

性能测试应该是一个迭代的过程, 测试发现和定位性能瓶颈, 根据问题原因修改系统配置或者代码, 修改后应用原来的测试环境和手段, 再次测试,验证问题是否解决, 配置是否生效, 对性能值各个方面比较,检测是否真正优化.

性能测试持续迭代测试到满足性能需求为止.

如存在理解错误和问题,欢迎探讨cmmdy@hotmail.com

【摘要】 软件测试从哪里开始到哪里结束？中间要经过哪些环节以及各环节要注意哪些事项。本文就有关问题结合个人实际工作经验进行阐述，鉴于每个环节都可以做为一个专题来进行探讨，所以受篇幅和时间限制，本文对有关问题未做深入剖析，只做一个宏观上的介绍。

【关键词】测试流程、需求分析、测试用例、测试计划、缺陷管理

一、概述

一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：

需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.

在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。

说明：

1．以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。

2． 以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于 一些需求不清楚而重新进行需求分析等。这就和我们国家提出建设有中国特色的社会主义国家一样，只所以有中国特色，那是因为国情不一样。所以在实际测试过程 中也要做到具体问题具体分析，具体解决。

二、测试流程

     

需求分析

需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。

可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要，而且至关重要！

一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。

其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！

既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。

总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

测试计划

   

测试计划（Test Plan）一般由测试负责人来编写。

   测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：

1．  测试背景

a.       软件项目介绍；

b.       项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。

2．  测试依据

a.       软件需求文档；

b.       软件规格书；

c.       软件设计文档；

d.       其他，如参考产品等。

3．  测试资源

a.       测试设备需求；

b.       测试人员需求；

c.       测试环境需求；

d.       其他。

4．  测试策略

a.       采取测试方法；

b.       搭建哪些测试环境；

c.       采取哪些测试工具以测试管理工具；

d.       对测试人员进行培训等。

5．  测试日程

a.       测试需求分析；

b.       测试用例编写；

c.       测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

6．  其他。

测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。

计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是

关于web测试
1页面部分
（1） 页面清单是否完整（是否已经将所需要的页面全部都列出来了）
（2） 页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示）
（3） 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）
（4） 页面特殊效果（如特殊字体效果、动画效果）是否显示
（5） 页面特殊效果显示是否正确

2 页面元素部分
（1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
（2）素是否显示（元素是否存在）
（3）页面元素是否显示正确（主要针对文字、图形、签章）
（4）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
（5） 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
（6） 页面元素的容错性列表（如输入框、时间列表或日历）
（7） 页面元素的容错性是否存在
（8） 页面元素的容错性是否正确

3 功能部分
（1） 数据初始化是否执行
（2） 数据初始化是否正确
（3） 数据处理功能是否执行
（4） 数据处理功能是否正确
（5） 数据保存是否执行
（6） 数据保存是否正确
（7） 是否对其他功能有影响
（8） 如果影响其他功能，系统能否作出正确的反应
（9） 其他错误
（10） 对模块的具体功能进行测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况
如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
单项功能测试（增加、修改、查询、删除）
增加——>增加——>增加 （连续增加测试）
增加——>删除
增加——>删除——>增加 （新增加的内容与删除内容一致）
增加——>修改——>删除
修改——>修改——>修改 （连续修改测试）
修改——>增加 （新增加的内容与修改前内容一致）
修改——>删除
修改——>删除——>增加 （新增加的内容与删除内容一致）
删除——>删除——>删除 （连续删除测试）
（11）查询功能分为两种情况，验证操作结果。
一、打开页面时自动显示结果，则不特别强调；
二、需要手工操作进行查询，则每次在其他功能完成后进行。
4 提示信息
（1） 成功、失败提示
（2） 操作结果提示
（3） 确认提示
（4） 危险操作、重要操作提示
（5） 返回页面 提示后显示的页面
5 容错性
注意以下几种情况
（1） 为空、非空
（2） 唯一性
（3 ）字长、格式
（4） 数字、邮政编码、金额、电话、电子邮件、ID号、密码
（5） 日期、时间
（6） 特殊字符 （对数据库）英文单、双引号，&符号
6 权限部分
功能权限： 指定用户可以使用那些功能，不能使用那些功能
数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可
以合并到功能测试
操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合
并到功能测试
权限变化： 可以合并到功能测试

（1） 功能权限是否存在
（2 ）功能权限是否正确
（3） 数据权限是否存在
（4） 数据权限是否正确
（5）操作权限是否存在
（6） 操作权限是否正确
（7） 引起权限变化的功能列表
（8） 功能权限变化还是数据权限变化，或两者兼有
（9） 权限变化是否正确

7 键盘操作
（1） Tab键的使用
（2） 上下方向键的使用
（3） Enter键的使用
（4） 系统设定快捷键的使用（如果设置有快捷键）

8 测试中还应注意的其他事项
（6） 完整性：是否是一个整体，没有功能缺损
（7） 易用性：使用是否方便
（8） 一致性：类似的问题用类似的方法处理
（9） 提示信息：提示信息是否完整、正确、详细
（10） 帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
（11） 兼容性：包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
（12） 可扩展性：是否由升级的余地，是否保留了接口
（13） 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
（14） 运行速度：运行的快慢，带宽占用情况

有几点：
1.功能点测试：是否满足需求所要求的功能
2.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
3.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
4.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
5.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
6.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
7.界面测试：界面的正确性、一致性、友好性、易用性。

用户界面测试是从最终的使用者用户的角度来看软件，软件难以理解，不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面：
1.易用性检查：确保软件易于理解，方便使用。
2.一致性检查：
a.注意系统页面的风格是否一致，如字的大小、颜色、字体要相同。
b.提示信息的表达方式是否一致。
c.按钮排列顺序是否一致。
d.back, cancel等按钮跳转页面处理是否一致。
e.各字段的名称，位置、长度、类型是否和设计文档要求一致，如Employee No和LoginName不一致。
3.正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
4.友好性检查：
a.提示信息是否友好.
b.系统应该在用户执行错误的操作之前提出警告，提示信息.
c.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
5.合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
6.检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。
7.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理。

安装SQL Server2000的时候，安装程序提示我安装程序被挂起，让我重新启动电脑，但我即便是重新启动了再次安装，SQL Server2000的安装程序依旧提示我这个错误。

1 数据和数据库完整性测试
数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
数据库完整性原即：
主码完整性：主码不能为空；
外码完整性：外码必须等于对应的主码或者为空。
数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持测试的工具和技术。
比如，有两张表：部门和员工。部门中有部门编号，部门名称，部门经理等字段，主码为部门编号；员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。
员工类型如下定义：0：职工，1：职员，2：实习生。但数据类型为Int，我们都知道Int占有4个字节，如果定义成char(1).就比原来节约空间。
2 白盒测试
白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般白盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
2.1 静态白盒测试
利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而白盒测试发现一个函数定义如下：
Function NameGet(){
….
}
这是属于不符合开发规范的错误。
有这样一段代码:
if (i<0) & (i>=0)
…
这段代码交集为整个数轴，IF语句没有必要
I=0;
while(I>100){
J=J+100;
T=J*PI;
}
在循环体内没有I的增加,bug产生。
2.2 动态白盒测试
利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
看一段代码
if(I<0){
P1
}else{
P2
}
在调试中输入I=-1,P1程序段通过， P2程序段未通过，属于动态黑盒测试的缺陷
3.功能测试
功能测试指测试软件各个功能模块是否正确，逻辑是否正确。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。
4.UI测试
UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关
比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。
5.性能测试
性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试
5.1负载测试
负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？
5.2强度测试
强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。
5.3数据库容量测试
数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。
数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。
比如，在电子商务系统中，通过insert customer 往user表中插入10 000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100 000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；如果在规定的时间内显示出来，可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
5.4基准测试
基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。
5.5竞争测试
软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？
6. 安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。
6.1应用程序级别的安全性
可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？
6.2系统级别的安全性
可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？
7.故障转移和恢复测试
故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。
故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？

Transactions（用户事务分析）
用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary（事务综述）
对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）
“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）
“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）
“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
8、Transaction Response Time(Distribution)（事务响应时间(分布)）
“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。

Web Resources（Web资源分析）
Web资源分析是从服务器入手对Web服务器的性能分析。
1、Hits per Second（每秒点击次数）
“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
2、Throughput（吞吐率）
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
“吞吐率”图和“点击率”图的区别：
“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。
3、HTTP Status Code Summary（HTTP状态代码概要）
“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
4、HTTP Responses per Second（每秒HTTP响应数）
“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
5、Pages Downloader per Second（每秒下载页面数）
“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
6、Retries per Second（每秒重试次数）
“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
在下列情况将重试服务器连接：
A、初始连接未经授权
B、要求代理服务器身份验证
C、服务器关闭了初始连接
D、初始连接无法连接到服务器
E、服务器最初无法解析负载生成器的IP地址
7、Retries Summary（重试次数概要）
“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections（连接数）
“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
借助此图，可以知道何时需要添加其他连接。
例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
9、Connections Per Second（每秒连接数）
“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
10、SSLs Per Second（每秒SSL连接数）
“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。

Web Page Breakdown（网页元素细分）
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。
1、Web Page Breakdown（页面分解总图）
“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
“页面分解”图可以按下面四种方式进行进一步细分：
1)、Download Time Breaddown（下载时间细分）
“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。
3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）
“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。
“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。
4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。
2、Page Component Breakdown（页面组件细分）
“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。
3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）
“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。
4、Page Download Time Breakdown（页面下载时间细分）
“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。
“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。
5、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）
“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。
“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。
6、Time to First Buffer Breakdown（第一次缓冲时间细分）
“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。
网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。
服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。
7、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。
8、Downloader Component Size(KB)（已下载组件大小）
“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。

1、出现这样的提示，是因为数据保护引起的，可能数据保护的解除：
    在控制面板里打开“系统”属性，在【高级】选项卡下的“性能：视觉效果、处理器计划、内存使用和虚拟内存”里面点击  【设置】，接着在“性能选项”中选择【数据执行保护】选项卡。
2、我们只要设置为：只为关键的windows程序和服务启动数据保护。

3、或者选择:对所有的程序和服务启动数据保护，把checku.exe钩选去掉。

4、这个方法我已经使用成功，一开始在2003下面安装TD8.0的时候也出现了上面的提示，设置后，就安装成功了。

 

IE7自从Beta到现在正式release英文版已经很长时间了，在IE7下浏览不了estdirector的问题始终困扰着很多同学，MI也似乎对这个问题置之不理？！我觉得是MI在卖关子，好了，废话少说，以下是解决方案：
1、以系统管理员身份登录TD服务器；
2、找到C:\Inetpub\TDBIN目录，用编辑器打开start_a.htm；
3、找到变量fMSIE3456，在后面加一句脚本：(ua.lastIndexOf('MSIE 7.0') != -1)，照猫画虎，别忘了两条竖线和后面的分号；
4、保存，打开IE7访问testdirector，安装ActiveX，大功告成！

 windows2003上可以修改。

破解TD7.6无限制使用方法！

以下是TestDirector 7.6的一些破解方法，希望对大家有帮助！

TestDirector 7.6
7FFFK-A2722-FF7AC-A6KKN
安装之前将日期往后改几年，如2006-04-02，安装完成后使用期限自然是到2006-06-02.
成功后，在将当前日期改回来，2004-04-02，再进去看看License的使用期限，还是2006-06-02。

-----------------------------------------------------------------------

TD 7.6 License Code   日期限制  合作    缺陷    需求   TestPlan-TestLab
-----------------------------------------------------------------------
7DFDM-8EFEE-EA68C-A6KKN  4个月     无限    25      25     25
NPPPF-WGGGG-RPHWS-UH330  无限      无限    32      16     16

-----------------------------------------------------------------------

B343P-44B44-43444-6444S  (无任何限制)

TD 8.0破解序列号：
Maintenance no.：KSQMQSQ-HQSQDQS-Q3QSQ3S-Q2SSQI8

License no.：B343P-44B44-43444-6444S 

备份文件

    后台数据库使用SQLServer2005；

一、数据库备份：从原服务器上备份出所有您要还原的TD系统数据库（在SQLServer2005中操作）；

二、文件备份：

    1、TD_Dir整个文件夹；

    2、备份C:\Program Files\Common Files\Mercury Interactive\DomsInfo 文件夹中的所有文件；

还原数据库

一、将备份出来的DomsInfo文件夹的内容覆盖到C:\Program Files\Common Files\Mercury Interactive\DomsInfo 文件夹中， 这里进行项目配置的还原。

    1、用Access打开DomInfo文件夹下的doms.mdb数据库文件，默认口令为tdtdtd，进行以下修改：

     a)修改Admin数据表,打开该表并修改Admin_pswd 的密码，如果你不想修改以前的Admin用户的密码也可以不进行该步操作。

     b)修改DBServers数据表，打开该表并修改DBServer_Name字段的第二行值为新TD服务器名称。

     c)修改Params数据表，打开该表并修改ACIServer、SiteScopeurl行对应的Param_Value字段值用新TD服务器名称替换旧TD服务器的名称。

     d)修改Projects数据表，打开并修改每个项目的Physical_Directory路径修改为：C:\TD_Dir\Default\项目名称；

      e)修改TDServers数据表，打开并修改TDServer_Name、TD_IP_Address列的值为新TD服务器的服务器名称。

 2、修改old_DomSetup.ini文件中的：

      TDSQLSERVER=TD服务器名称

      Value_1=TD服务器名称:9999

      Value_3=http://TD服务器称称/TDBIN/Redist/SiteScope/SiteScope4TD.htm

　     说明：把TD服务器名称替换为新的服务器名称或IP。

二、还原系统文件

1、将备份出来的TD_Dir文件夹中的内容覆盖到C:\TD_Dir文件夹下（除所要还原的项目系统文件）；

2、说明：（“TEST”，“国家环保总局项目”2个文件夹）就是要还原的项目系统文件，所以覆盖时不能还原，要在TD的Site Administrator页面中重新创建，创建成功后再C：\TD_Dir目录下会生成该文件夹；

三、项目名称的创建及数据库的还原

1、在TD的Site Administrator页面中重新建立所要还原项目的域名和工程名；

2、创建成功以后在SQLServer2005中会创建 数据库，

还原备份的数据库 ，还原后必须在查询分析器中执行以下2条语句：

　   exec sp_change_users_login 'Report'

　   exec sp_change_users_login 'Update_One','td','td'

　   说明：这个脚本必须要执行，要不还原过来的项目不能激活，TD和SQLServer不能建立链接。

四、在右下角的任务栏中停掉TD服务，在启动TD服务；

五、打开TD的Site Administrator页面中的进行数据库连接测试，及对每个项目进行连接测试。

这两天总结下基本步骤
Setp 1:安装必须的插件
     欲自动运行WR需要在本机上装如下插件：
     TD add-ins页面中下载安装：TestDirector Connectivity、TestDirector System Test Remote Agent、TestDirector Client Side Setup
     欲自动运行QTP需要在本机上装如下插件：
     More TD add-ins 页面中下载安装: QuickTest Professional/Astra QuickTest Add-in( 注意版本的匹配性)
接下来以QTP脚本为例，WR、LR的处理类似
Step2: QTP连接TD并将脚本同步至TD
     A:tool中选择Quality center connection
       在server处输入： http://TD服务器IP/tdbin  点connect
       在project connection里填写正确的domain、project、user、password 点connect .
       注意勾选上：reconnect on stratup、save password
     B:本地录制编辑完脚本后，选择file->save as,出现一个保存界面，在左边的category里将脚本同步到TD服务器的相关位置，右边的file system里保存至本地。
     备注：将脚本同步到TD，有很多方法，可以直接在TD中launch QTP来录制脚本，也可以利用一些工具如Import Tests 来同步脚本。
Step3:在配置自动运行的环境：
       A: 在QTP tool->options->run 中够选 allow other mercury products to run tests .
       B: 在TD中已经保存相应脚本的project中进行如下操作：
           Test lab->host->host manager  中配置远端主机。
       C:配置脚本测试集及运行环境
      首先：在test lab->exection flow-> slecct tests 选择待测试的脚本，并配置各脚本的关联关系。         

     其次：设置定时器：右键点击脚本，选择test run schedule,配置定时器      
     最后：点击run test set ,配置运行环境，最后点run或run all，所配置的脚本进入等待运行状态，定时运行。
    注意：如果是控制远端机运行脚本，必须把默认勾选的run all test locally去掉
    PS：以上步骤也可以在test lab的exection grid中完成。
Step4:配置自动邮件：
     A:在TD 的SiteAdmin->td server中配置mail protocol
      B:在TD相应project的testlab->test set properties 中配置notifications项添加邮件接收人，邮件基本内容等。
     C：通过在tool->change user properties可以设置发件人的邮箱名。
完成以上配置后，大功告成，在脚本自动运行完后，就可以接收到运行结果的邮件了

在TestDirector中后台数据库为SQL Server 2000时，在TestDirector中一直创建工程失败，原因是一般在安装SQL Server 2000时选择都是混合模式（空密码）登录，没有sa用户的认证。解决办法：安装SQL Server 2000的SP4补丁，安装补丁时就有sa用户的认证信息。