年前加班转移各项目组的TD库到一台机器上做统一管理之用，折腾了好几天。因为有些项目组是从TD7.0就开始建的project，之后升级为TD8.0，这次又要转到新的机器上所以出现了不少问题。下面简单说一下我遇到的情况和解决办法。（下文介绍的方法均以文字为准，图为辅助说明）

首先是正常的操作：
一般我们从不同机器上迁移TD库project的步骤如下（原主机为hostA，目的主机为IT-DIONYSUS，hostA中已经有TD和project，我们在IT-DIONYSUS上安装一个TD）
1. 进入IT-DIONYSUS TD库的Site Administrator，在projects页面中选择restore project，浏览选中hostA共享的TD库DBID.ini文件

这时点击恢复会报告DB Server没有找到，这是因为IT-DIONYSUS的TD库中没有hostA中的DB Server，我们需要进入DB Server页面把hostA的数据库添加进来，设置验证方式为SQL Auth认证，最后ping一下确认可以正常连通

回到project页面恢复，成功后可以看到hostA中TD库的project已经出现在当前TD中了（但此时project的DB server还是指向hostA上的数据库）。
2. 选择Create Project新建一个项目，数据库类型选择MS-SQL

下一步选择数据库的时候Server Name选择为IT-DIONYSUS机器上的数据库（即，这个project的数据库要建立在IT-DIONYSUS上）

下一步选择Copy

 

注意选择对要复制的project

一切顺利的话这个project就从hostA上完全复制到IT-DIONYSUS上了，并且数据库也指向本机了。
如果上述操作过程中没有报错的话则迁移过来的project是最完整且正常的，所有用户自己添加的字段等信息完全保留。

实际过程中遇到的问题和解决方法：
1. 首先是部分project的DB Server与TD Server不一致。当我们安装TD的时候有一步让你选择输入MS SQL Alias，很多人就是用的默认名称“TDSQLSERVER”
    
当从IT-DIONYSUS上恢复远程project时必须要在DB Server中新建一个名为TDSQLSERVER的服务器，但这个DB SERVER是无法ping通的（后面会讲到如何让其可以使用TDSQLSERVER），因为网络中没有一个叫TDSQLSERVER的SQL服务器，所以从恢复这一步就无法走通。
 方法1：在原主机（还是以hostA为例）TD库的DB Server中新建一个服务器，名字就是本机SQL服务器的名字hostA，Create Project，选择数据库为hostA，Copy那个DB与TD不一致的project。这样再从IT-DIONYSUS上恢复我们新建的这个project即可，这个project的DB Server是可以在网络中找到且连通的。
 方法2：打开IT-DIONYSUS机器上的SQL Server 客户端网络实用工具，点击“别名”，设置TDSQLSERVER的真实服务器名hostA

再在TD的DB Server中新建一个叫TDSQLSERVER的服务器，输入hostA上的用户和密码，ping一下是可以通的

 这样我们就可以从IT-DIONYSUS这一端设置，正常复制hostA上的project了。
2. 本身原数据库就已经存在问题，hostA上已经不能正确新建或激活project，那我们只有从SQL Server强行复制表了，注意这样的复制是有问题的，复制过来的project将丢失部分信息。
方法：以前有网友已经总结过的，这里我再说一下吧。打开IT-DIONYSUS上的Site Administrator，直接Create project，不复制。打开IT-DIONYSUS上的SQL企业管理器，建立(local)和hostA的注册连接。在(local)的数据库中找到新建完成的数据库－名称为：Domain名＋project名。右键菜单里选择“所有任务”－>“导入数据”

数据源选择服务器hostA上的project库，用户为sa
服务器选择本机，数据库即为新建的那个库，这里的用户一定要选择td，密码为tdtdtd！
之后就是导入所有表。过程中会出现部分复制错误。
数据库复制完成后还需要将project的附件等文件夹复制过来：将hostA project文件夹下的attach文件夹所有内容拷贝到IT-DIONYSUS的对应project下，之后根据情况复制其他文件夹的内容（有的文件夹里没内容，可以不复制），注意不要复制DBid.ini文件！！

这样强行转移project后用户和组等信息会丢失，只得自己添加。而且还有很多奇怪的问题，例如添加bug时bug号有错误，以前test plan中的测试用例都跑到一个文件夹下了。于是我打开SQL的事件探查器跟踪了一把，查到TD中部分表和字段对应的信息。这里仅作简单介绍，如果有朋友遇到和我同样的问题，也许可以通过直接操作SQL数据库做补救，但不到万不得已不要这样做。

我们在TD库中作提交bug等操作的TD总会首先查询其数据库中的SEQUENCES表，表里数据如下：
 

其中BUG字段后面的值表示当前库中最大的bug号，当我们再提交bug的时候TD会首先查询这里，并将我们提交的bug号在此基础上加1。TEST字段后面的值表示TD库中Test Plan页面下测试用例的最大ID号。我们new test时这里会加1。
知道这些信息了，当我们的TD库bug号增加不对时可以直接从这里修改。这个数据库中还有一个BUG表，里面存储的都是bug具体信息
 

新增测试用例如果出现问题也极有可能是因为SEQUENCES的test id有问题，比如id莫名其妙的变小了，致使增加的id号会和已有的id重复。数据库中有一个TEST表，里面存储的都是测试用例的信息，但测试用例还是挂靠在一个文件夹下的，这个文件夹id可以从ALL_LISTS表中查看

 
 
我们可以进入TD查看一下测试用例与文件夹的所属关系：

Bug OPEN & CLOSE趋势图

 

众所周知，对于测试过程中发现的缺陷进行收集、分析和统计，是一项很重要的工作。

通过分析，我们可以及时了解产品的质量情况，判断测试过程中存在一些什么问题。

在此推荐一种Open & Close 趋势图，它绘制简单，容易看出一些问题，适合测试经理和高层领导及时了解某一产品的测试情况。

一、初始OPEN & CLOSE 趋势图

解析：

——X轴：由若干个自定义的均匀的时间点组成；

――Y轴：缺陷的数量；

――ALLOPEN：所有被发现（打开）的缺陷数量。（这是一个按时间点的累计值）

――ALLCLOSE：所有被关闭的缺陷数量。（这是一个按时间点的累计值）

――此外，可以添加DaillyOpen和DailyClose曲线，但是否添加，对我们的影响不大；

  

二、此时可以同意产品发布吗？

当ALLOPEN和ALLCLOSE两条曲线刚好汇集在一起时，应该是把把所有OPEN的问题都已经CLOSE了。但此时仍然存在风险，因为对于最新的这个版本，我们只完成了回归，还需要一些时间再进行最后一轮（甚至几轮）系统测试；

 

三、无休止了？

解析：

出现以上曲线时，可以有几种判断：

――1、激战正酣，研发和测试的效率都比较高；（两条线都呈上升趋势）

――2、产品代码质量不高，所以存在大量问题？（导致ALLOPEN一直走高）

――3、大量已关闭的问题又被打开了？（导致ALLOPEN一直走高）

――4、测试经理把关不严，导致重复提单？（所以ALLCLOSE一直走高）

此时，需要测试负责人介入，找出问题所在；

 

四、好像有些难改的问题？

 

解析：

出现以上曲线时，我们可以判断：

――1、发现（打开）和关闭的问题都比较少了，是不是研发和测试的效率有问题？（两条线没有汇集，区间还比较大，但是都很平）

――2、效率受到影响，是不是因为有很严重的技术难题？（导致了研发改错的进度受到影响，ALLCLOSE曲线很平）

――3、而且这个技术难题影响了测试进度？（导致测试发现问题的进度受到影响，ALLOPEN曲线很平）

此时需要测试负责人介入，找出问题所在；

 

  

 

 

五、理想情况

解析：

出现以上曲线，我们可以判断：

――ALLOPEN和ALLCLOSE曲线已经汇集，并且持续了一段时间，此时的产品质量比较稳定，可以批准正式对外发布了；

 

这就是ALLOPEN和ALLCLOSE趋势图的几种典型状况解析，它有利于我们在测试过程中及时观察现象，做出判断，发现并解决问题。通过对过程的监控来降低产品质量风险。

软件测试专业网站:51Testing软件测试网m,dlKX;U7QG)CD
上次在OOW了解到一个压力测试工具Swingbench，这是Oracle UK的一个员工在一个被抛弃的项目的基础上开发的。目前稳定版本2.2，最新版本2.3，基于JDK1.5。该工具是免费的，可以在作者的网站(国内无法访问，需要使用代理，推荐Torpack，最新版已经改名叫XeroBank Browser)上自由下载，并且拥有详细的使用文档。除了Swingbench，作者还开发了两个相关工具：测试数据生成工具DataGenerator和跟踪文件分析工具Trace Analyzer。

Swingbench可以执行4种不同的标准测试(benchmark)，拥有三种前端展示方式 Swingbench/Charbench/Minibench，其中Charbench是字符模式的，另外两种是GUI模式的。另外还可以通过 ClusterOverview可以聚合显示所有的结果。Swingbench的开发目的主要是用来展示RAC的负载和测试，但也可用于单实例环境。最新的2.3版本开始支持TimesTen内存数据库。

简单架构(单实例)

高级架构(RAC)软件测试专业网站:51Testing软件测试网D:DwH*P q%t m+C X

Swingbench支持的4种标准测试
`
V%W&g(j)Z19544
f+sh
]!?3wNJG%^19544 其中OrderEntry和Sales History采用的测试数据基于Oracle自带的两个Sample Schema：OE和SH。Calling Circle则每次运行都需要重新生成schema。Stress Test是最简单的测试，可以用于测试TimesTen。其中OrderEntry和Calling Circle还提供了向导程序。

配置和使用Swingbench

下载后解压缩，然后修改配置文件中的JAVAHOME和SWINGHOME。Unix/Linux平台配置文件为swingbench.env，执行文件路径为bin；Windows下则为swingbenchenv.bat和winbin。在windows平台上注意一定要配置ORACLE_HOME，好像不认注册表。

Swingbench的配置文件为swingconfig.xml，但是通过命令行参数可以覆盖配置文件中的设置。其他各种工具也都有自己相应的xml配置文件。

使用Swingbench相当简单，直接调用相应的向导或者展示程序即可图形化操作。例如我们要执行OrderEntry测试，首先执行oewizard创建schema SOE并生成测试数据软件测试专业网站:51Testing软件测试网;nq$^'zsW8O_

然后执行swingbench开始测试
Js@DD\E#h19544

Minibench的结果
;M%\k,n,ZQ,t19544

Charbench的结果软件测试专业网站:51Testing软件测试网FC?j9B[2Pt

ClusterOverview运行前必须先运行coordinator，由于没有RAC环境，这里就不截图演示了。

 

 

来源：http://www.51testing.com/?145083/action_viewspace_itemid_72343.html