mount /dev/cdrom /mnt/cdrom (加载光驱    卸载是 #umount /mnt）
cd /mnt/cdrom （切换到光驱盘符下）
ls （相当于DOS中的DIR）
cp vmware-linux-tools.tar.gz /tmp（复制相当如DOS中的copy）
（桌面方式如下:

点击虚拟机的安装vmwaretools选项,在redhat桌面上生成文件夹,把相关文件copy到tmp中）
cd /tmp

ls    /*查看是否有tools文件
tar zxf vmware-linux-tools.tar.gz （解压缩）
ls
cd vmware-tools-distrib

ls
./vmware－install.pl （正式安装）

参考网址  http://www.qqread.com/sys-soft/a211201.html(谢谢这位大哥出的图示!)

今天浏览一位网友的blog看到的,不敢藏私,拿出来大家共同分享,在此感谢这位仁兄的blog

http://blog.chinaunix.net/u/29321/showart_332194.html

 

declare @count int
declare @i int
declare @username varchar(20)
declare @no varchar(3)          //定义变量

set @count = 20                //设置循环数(也就是添加用户数)
set @i=1

while @i<=@count
begin
   if (@i < 10)
   begin
 set @no = '0' + convert(varchar(20),@i)  
   end                                            //当数目小于10的时候,以0+count显示,否则直                                                    接显示
   else
   begin
 set @no = convert(varchar(20),@i)  
   end 

   set @username = 'user' + @no                   //用户名前缀+@count
  INSERT INTO t_userinfo(username,userpassword,displayname,status,accounts)
                VALUES(@username,'b59c67bf196a4758191e42f76670ceba',@username,'1',@username)  

   set @i=@i+1
end

   最近试用TD中,网上找到的一篇对bug的详尽描述,看了深有体会!

Bug的处理

开发组长/经理
每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进行代码审查

开发人员
分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度3-High类以上（包含）bug5个或5个以上，停止新功能的开发。

需求人员
解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划

测试人员
不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解决

测试组长/经理
审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见

产品人员
可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺

　

Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed及Rejected等

New	为测试人员新问题提交所标志的状态。
Open	为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug解决中的状态，由任务分配人改变。对没有进入此状态的Bug，程序员不用管。
Reopen	为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由测试人员改变。
Fixed	为开发人员修改问题后所标志的状态，修改后还未测试。
Closed	为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。
Rejected	开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由Bug分配人或者开发人员来设置。

Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。

A-Crash	错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作；
B-Major	功能未实现或导致一个特性不能运行并且不可能有替代方案；
C-Minor	错误导致了一个特性不能运行但可有一个替代方案；
D-Trivial	错误是表面化或微小的（提示信息不太准确友好、错别字、UI布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；
E-Nice to Have（建议）	建设性的意见或建议。

Bug优先级(Priority)：指缺陷必须被修复的紧急程度。由Bug分配者（开发组长/经理）指定。

5-Urgent	阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试
4-Very High	必须修改，发版前必须修正
3-High	必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正
2-Medium	如果时间允许应该修改
1-Low	允许不修改

功能模块(Subject)：TD中需在Test Plan页中定义好Subject，才能在Defects页中使用。

问题描述、附件附图 请参见后面第四部分‘Bug描述要求’的有关内容。

处理意见:开发组长/经理(或具体Bug分配人员) 在审核新Bug时、将Bug分配给开发人员解决前，需要给出该Bug的处理意见。

Fixable	可修改。表示Bug可以被修复或更正
Duplicated	重复。表示该Bug已经被其它测试人员找出来了（‘纯粹’重复），或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）
Postponed	延后。由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。 （注：因‘Bug状态’字段中也有该值，根据各组各自使用情况，可以只保留一个，或者开发/测试各有侧重地使用这两个Postponed）
By Design	因设计结构问题无法修改。测试人员认为是Bug，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改代价太大
Can’t Reproduce	不可复现。不能重现（如因Bug出现的环境重现不了了），或以前出现的某个Bug自动消失了（可能是在处理其他Bug的时候把这个Bug 一并修复掉了）。 （注：因TD本身亦带有‘是否复现(Reproducible)’字段，根据各组各自使用情况，可以用它来标识，或者不用它而在‘处理意见’字段中用该值标识出）
Disagree With Suggestion	不同意所提意见或建议，不采纳
Not Error	不是问题。测试人员提错了
Won’t Fix	这个Bug是一个错误，但还没有重要到非要更正不可的地步，可以忽略不计

说明：
1. 定为Duplicated的Bug，必须注明和XXXbug重复
2. 测试人员对标明为Duplicated的Bug复测，需要XXXBug修改后方可进行
3. 定期回顾Can't Reproduce,Postponed
4. 定期整理By Design

其它一些字段（及所定义的枚举值）的定义解释，供有需要用到的组参考：

测试状态（TestState）：新提交的Bug定位标准。由测试人员指定。一般有8个（提交Bug时给出）

1－New Defects（或写成Defect）	新Bug
2－Second Defects（或写成SB）	复测时新出现的Bug
3－Faculative	偶发性
4－Reappear	原来修改过的问题又重新出现
5－By Requirement	需求要求但没有做的功能
6－Suggestion	需求需要完善
7－Differ With Requirement	与需求不一致
8－By Design	设计要求但没有做的功能

复测状态(ReTestState)：复测时给出的状态，测试人员对于经过验证的Bug应按以下几种标准进行定位。由测试人员指定。一般有1－OK、2－PD、3－DV、4－NB、5－NR、6－AR。

OK	正确
PD	此问题悬而不决
DV	有错误可以暂时不考虑
NB	不是错误
NR	不能复现的错误
AR	需求不明确

问题定位：

Calculate_error	计算错误，指计算过程中、计算结果错误。
Data_error	数据错误，指非计算结果类的数据错误。
Graphics_error	图形错误，指绘图、图形显示、图形编辑时发生的错误。
Interface_error	界面错误
Requirement_error	需求错误
Function_error	功能错误
Unknown_error	未知错误

缺陷来源(Source)：指引起缺陷的起因。

Requirement	由于需求的问题引起的缺陷
Architecture	由于构架的问题引起的缺陷
Design	由于设计的问题引起的缺陷
Code	由于编码的问题引起的缺陷
Test	由于测试的问题引起的缺陷
Integration	由于集成的问题引起的缺陷

类型(Type)：是根据缺陷的自然属性划分的缺陷种类。

F- Function	影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷
A- Assignment	需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷
I- Interface	与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
C- Checking	提示的错误信息，不适当的数据验证等缺陷。
B- Build/package/merge	由于配置库、变更管理或版本控制引起的错误
D- Documentation	影响发布和维护，包括注释。
G- Algorithm	算法错误。
U- User Interface	人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷
P- Performance	不满足系统可测量的属性值，如：执行时间，事务处理速率等。
N- Norms	不符合各种标准的要求，如编码标准、设计符号等。

（以上依各组实际情况可以作适当调整）

项目组各角色在Bug库中的权限

管理员：全部权限

测试组长/经理：全部权限

测试人员：可添加Bug、不能删除Bug、可添加注释评论(R&D Comments)、不可修改他人所提Bug、可调整：Bug概要(题目，Summary)、问题描述、附件附图(Attachments)、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&D Comments)、复测人、复测日期、修改人

开发人员/需求人员：不能删除Bug、可添加注释评论(R&D Comments)、可调整：注释评论(R&D Comments)、是否复现、Bug状态（不过无法直接标为closed）、问题描述、处理意见、待测版本、修改人、修改日期。可添加Bug。

开发组长/经理/需求经理：除了开发人员的权限，还可调整：优先级别、责任人、Bug概要(题目，Summary) 、附件附图(Attachments)

项目经理：可添加Bug、可添加注释评论(R&D Comments)、可修改字段：Bug概要(题目，Summary) 、问题描述、附件附图(Attachments) 、Bug状态（不过无法直接标为closed）、修改人、优先级别、问题定位、处理意见、注释评论(R&D Comments) 、是否复现、责任人、待测版本。也可删除Bug，但要与测试组长/经理协商。

不属于项目组成员的其他人如研发中心经理组成员等，有必要查看TD库的话，可分配给其帐号及查看的权限。

Bug描述要求

Bug描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。测试组长/经理把关，以开发人员的角度来审查Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截图作为附件提交。具体要求为：

• 问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整；
• 单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。在主报告之后应注明不同的条件；
• 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；
• 再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；
• 复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；抓图可用TestDirector自带的功能，亦可用HyperSnap之类的专用抓图工具。
• 报告中不允许使用抽象词句：比如“有错误”之类；
• 有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在Bug报告中标识；
• Bug描述示例：

例一 河北98土建标准换算 操作： 1.输入9-24 2.F8 3.在F8输入10 期望结果：进行换算 实际结果：提示“输入的厚度应大于20”

例二（模块或功能点也可在‘功能模块’字段中规定，则Bug描述中就不必写了） 操作： 1.打开新建向导； 2.在“新建”中的“项目名称”中输入>80个字符； 3.点击“下一步” 期望结果：“项目名称”应<=80个字符，输入大于80个字符，点击“下一步”应有错误提示 实际结果：进入“比重调整”界面

例三（程序员知道期望结果的情况下） 云南98土建 操作： 1.输入13-170 2.F5 3.在F5中修改3240008的名称, 处于编辑状态 4.到人材机,再回来 实际结果： F5中变白板 注：若3不处于编辑态切换则正常

例四（建议、需求类） 功能：预算页，子目排序后可恢复原顺序 用途：用户误操作后可复原

注：所有项目采用TestDirector进行Bug管理，该工具能从测试步骤自动生成Bug报告，因此对于Bug描述要求在测试方案用例设计（在Test Plan页中）阶段就可以进行控制。

附：好的Bug报告应满足以下几方面的要求：

• 结构清晰
• 复现故障再写报告
• 隔离Bug：更改条件复测
• 归纳：是否其他模块也有相同的Bug
• 比较：其他测试用例是否使用到此Bug
• 总结：报告的开头有Bug的总结
• 精简：不要有多余的步骤和语言
• 无歧义：语言明确
• 中立：无批评性语言
• 讨论：将要发出的报告送其他测试人员讨论

小结

• 通过专业的技术测试出精确的Bug；
• 通过准确的文档报告Bug；
• 通过良好的沟通使Bug尽快解决。

 经常碰到超过远程连接数而无法连接服务器，你可以采用如下方法解决
此时一般有以下选
1.打托管商电话要求机房手动强制重启.
2.使用专用远程连接器.
如果以上两条不方便实现,那请看下面这条最方便的吧
用如下命令形式解决超过最大连接数问题
运行 mstsc /v:IP /console ,比如
就可以连接到远程系统的的会话。mstsc /v:211.211.0.5 /console
其实这主要是mstsc参数的了解，可通过mstsc /?学习一下。

远程桌面连接
MSTSC [＜Connection File＞] [/v:＜sever[:port]＞] [/console] [/f[ullscreen]]
[/w:＜width＞ /h:＜height＞] | /Edit"ConnectionFile" | /Migrate | /?
＜Connection File＞ -- 指定连接的 .rdp 文件的名称。
/v:＜sever[:port]＞ -- 指定要连接到的终端服务器。
/console -- 连接到服务器的控制台会话。
/f -- 以全屏模式启动客户端。
/w: ＜width＞ -- 指定远程桌面屏幕的宽度。
/h:＜height＞ -- 指定远程桌面屏幕的亮度。
/edit -- 打开指定的 .rdp 文件来编辑。
/migrate -- 将客户端连接管理器创建的旧版连接文件迁移到新的 .rdp 连接文件。
/? -- 生成这个用法消息。


而要从根本上解决还是需要修改服务器端配置:

使用远程桌面链接登录到终端服务器时经常会遇到“终端服务器超出最大允许链接数”，引起该问题的原因在于终端服务的缺省链接数为2个链接，并且当登录远程桌面后如果不是采用注销方式退出，而是直接关闭远程桌面窗口，那么实际上会话并没有释放掉，而是继续保留在服务器端，这样就会占用总的链接数，当这个数量达到最大允许值时就会出现上面的提示。
　　解决方式：
　　一、用注销来退出远程桌面而不是直接关闭窗口
　　二、限制已断开链接的会话存在时间
　　三、增加最多链接数，即设置可连接的数量多些

第三可采用如下几种方式来修改：

1.从终端服务配置中修改：
打开管理工具里的终端服务配置，再单击连接，双击右边的RDP-Tcp，弹出RDP-Tcp属性，选择网卡，可设置最多连接数，或者设置为无限制的连接数。当然这个值不也能太大，否则会占用较多的系统资源。不过这里修改的值好像不起作用，设置成无限制时照样还是会出现本文所说的情况。

修改会话存在时间：运行－Tscc.msc－连接－双击RDP-Tcp或右击－属性－会话－选中第一个的替代用户设置(O)－结束已断开的会话〔将默认值“从不”改为一个适当的时间，比如30分钟〕
2.打开“控制面板”，双击“添加删除程序”，单击“添加删除Windows组件”*“组件”
，在Windows组件向导对话框中选中“终端服务” * “下一步” * “应用服务器” * “下
一步”，然后按照提示即可改变终端服务的模式。
不过听说用此法，改了应用需要许可证，90天后过期:(

3.win2003的话可以从组策略修改：
　　组策略级别要高于终端服务配置，当启用组策略后终端服务配置中的相应选项会变成灰色不可修改
　　运行－gpedit.msc－计算机配置－管理模板－Windows组件－终端服务
　　双击右边的”限制连接数量“－选择”已启用“－填入允许的最大连接数

以上方法无法根本破解2003系统最大连接数的问题.试用大概也就几个月的时间.

安全卫士360修补漏洞后,企业管理器无法打开

打开SqlServer的企业管理器，突然出现如下错误：
---------------------------
Microsoft Management Console
---------------------------
MMC 不能打开文件 C:\Program Files\Microsoft SQL Server\80\Tools\Binn\SQL Server Enterprise Manager.MSC。

这可能是由于文件不存在，不是一个 MMC 控制台，或者用后来版本的 MMC 创建。也可能是由于您没有访问此文件的足够权限。
---------------------------
确定  
---------------------------


解决方法：
运 行mmc，控制台--添加/删除管理单元--添加--找到Microsoft SQL 企业管理器--添加--关闭--确定，再回到控制台--选项--控制台模式选择"用户模式完全访问"--将下面的选择全部取消。最后，从控制台--另存为 --存储为:C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC（即SqlServer的安装目录下的binn文件夹）。

实在不行的话，重新注册DLL

运行：regsvr32 C:\Windows\system32\msxml3.dll  (转载网上解决办法)