需求了解
例：
1) 查看性能是否提升
	=> 建立基线：
   		a) 新旧版本比较
   		b) 不同（程序/站点）设置间比较
2) 并发处理正确性
   	a) 步增实验，确定性能瓶颈下的“Maxinium User Load”
   	b) 不同并发下“Fail Test”
NOTE：

	重要指标
	.  Avg. Response Time： 针对“响应”
	.  Avg. Test Time、Total Tests、Tests/sec：针对“事务”
	.  Total Requests、Requests/sec：针对“请求”
	=> Test:Request=1:N，当Test耗时久时，需分析主力耗时的Request
-------------------------------
方案设计
注意事项：
1) 确定对象是否可测
    例：SilverLight不支持Load Test=>开发可测试版本（目标：实现逻辑一致性）
2) 确定各测试版本、同类功能是否统一部署
    例：多个Team合作下，由于程序/数据库部署不一致导致类比对象偏差
3) 确定被测程序级需要收集的关键变量
    例：项目开关设计，无开关版本、有开关版本开关“开”、有开关版本开关“关”
       . 数据库级开关
       . 配置文件级开关
4) 确定测试报告需要收集的特殊指标
    例：测试缓存是否有效以及缓存的最优配置度量
       . Cache Enties：Cache副本数量
       . Cache Turnover Rate：Cache副本回收率
       . Cache Hit Ratio：Cache副本命中率
NOTE：

	 复杂综合案例
       . 缓存测试，Scenario设计：
	  a) "Web Test" Mix：查看不同页面、不同Domain、不同参数、含Cookie页面在Cache机制下是否存在混淆串联
	  b) "Browser" Mix：测试Cache在多浏览器下的有效性
       . IIS中，将站点配置拆分为多个w3wp
	  原理：通过增加线程数量，提升线程级Memory来提升系统Memory，从而增加Requests数
	  a) 线程级Memory之和应当<=100%，线程级CPU之和应当<=100% 
-------------------------------
数据准备
注意事项：
1) 数据源确认
    a) 数据库环境：当有多个测试环境时，或多个Team合作时，或存在数据源同步/镜像时
    b) 数据库实例：当多个Team合作时，或存在数据源同步/镜像时
    c) 数据库名：当多个Team合作时，或存在数据源同步/镜像时
    d) 表名：当多个Team合作时，或存在数据源同步/镜像时
2) 数据验证，测试被测对象，确认其功能的有效性以及数据源收集的正确性
3) 确定数据驱动文件类型
    a) Database
        优点：通用性佳，功能性强，便于维护与测试执行
        缺点：如数据准备非Database，则导入导出操作复杂
    b) XML
        优点：模板便于创建
        缺点：不便于维护
    c) CVS
        优点：模板便于创建
        缺点：不便于维护
4) 确定数据文件正确性
    例：Excel中xls转换格式为cvs，以Notepad打开查看是否有多余行或乱码存在