首先在www.eclipse.org免费下载Eclipse，笔者写作此篇时比较稳定是3.0，安装非常简单，也同时有非常详细的帮助文档。顺利启动后，就可以看到华丽的欢迎界面。

Tomcat是著名开源组织apache的巨献，当前的主要版本是Tomcat 5，笔者写作时使用的是4.0.1，已经是比较“历史悠久”的版本 :-).

为了更好的管理J2EE项目，一个很好的插件是MyEclipse，你可以在www.myeclipseide.com 得到30天的免费使用版本。

下面，让我们来走一遍。

把myEclipse解压到Eclipse的本地路径上，重新启动Eclipse以后，你在首选项将会发现多了MyEclipse选项。

在Application Server中，选定你采用的服务器类型，在这里，我选中Tomcat 4，并将Tomcat的安装路径(右侧)选中，接着，将Tomcat Server置为Enable状态。

新建一个Web Project，输入自己的项目名称以及准备采用的J2EE标准版本。

可以看到，在浏览器中，Eclipse所体现出来的项目体系结构与WSAD是非常类似的，习惯上，在scr目录中放置java后台源代码，而在WebRoot中放置页面设计文件。

下面，我要做的只是将这个建立好的web工程与服务器连接起来

这里有一个小而关键的细节，在安装Tomcat中，你所选择（或者是系统所替你选择的JRE也许和Web项目本身不一样，Web项目的JRE环境可以在右键单击项目名称->Properties->java Build Path中看到），所以在window->Preferences->MyEclipse->Tomcat 4的展开节点的JDK上，你需要为自己的连接新建一个server name，如图，笔者add... 了一个Tomcat 4，并为其指定了Tomcat在安装时所对应的JRE环境路径，而不是Eclipse项目自身对应的JRE：

到了这里，我们所做的工作就基本完成了，

点击工具栏上的部署(红色)按钮，在弹出对话框中选择自己的项目，并安(黄色)的添加按钮来添加一个服务器实例，在弹出的部署服务器上选择Tomcat，选择Exploed Archive后，IDE会为你提供热编译的一致性。

最后完成关联后，不要忘记启动Tomcat服务器哟。在浏览器中输入自己的地址，就可以看看效果了，如http://localhost:8080/hyweb/MyJsp.jsp, 当然，还要注意自己的服务器端口设置了。

下面就以Tomcat作为JSP引擎，配合Tomcat、Apache、IIS这三种Web服务器来讲述3种搭建JSP运行环境的方案。

一、相关软件介绍

1、 J2SDK：Java2的软件开发工具，是Java应用程序的基础。JSP是基于Java技术的，所以配置JSP环境之前必须要安装J2SDK。

2、 Apache服务器：Apache组织开发的一种常用Web服务器，提供Web服务。

3、 Tomcat服务器：Apache组织开发的一种JSP引擎，本身具有Web服务器的功能，可以作为独立的Web服务器来使用。但是，在作为Web服务器方面，Tomcat处理静态HTML页面时不如Apache迅速，也没有Apache健壮，所以我们一般将Tomcat与Apache配合使用，让Apache对网站的静态页面请求提供服务，而Tomcat作为专用的JSP引擎，提供JSP解析，以得到更好的性能。并且Tomcat本身就是Apache的一个子项目，所以Tomcat对Apache提供了强有力的支持。对于初学者来说，Tomcat是一个很不错的选择。

4、 mod_jk.dll：Apache组织Jakarta项目组开发的使Apache支持Tomcat的插件。有了这个插件，Tomcat能够和Apache进行无缝连接。

5、 tc4ntiis.zip：Apache组织Jakarta项目组开发的使IIS支持Tomcat的插件。

二、 软件下载

1、j2sdk Webjx.Com

版本：j2sdk1.4.1(35.9MB)

地址：http://java.sun.com/j2se/1.4.1/download.html

http://www.timefound.com.cn/info/data/resource/download/j2sdk-1_4_1_01-windows-i586.exe 20070108

2、Apache2

版本：Apache2.0.43（6.69MB） 　　地址：http://www.apache.inetcosmos.org/dist/httpd/binaries/win32/

3、Tomcat4

版本：4.1.21（8.33MB）

地址：http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/

http://apache.seekmeup.com/tomcat/tomcat-5/v5.5.20/bin/apache-tomcat-5.5.20.exe20070108

http://tomcat.apache.org/download-55.cgi#5.5.20

4、mod_jk.dll： (136KB)

地址：http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/

5、tc4ntiis.zip（220KB）

地址：http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/tc4ntiis.zip

以上均为免费软件。

三、 配置前的准备

（一）准备一个测试用的JSP网页

打开文本编辑器，比如记事本，输入下列代码，并保存为test .jsp（注意扩展名为.jsp）。

以下为引用的内容：

＜HTML＞
            ＜HEAD＞
            ＜TITLE＞JSP测试页面＜/TITLE＞
            ＜/HEAD＞
            ＜BODY＞
            ＜%out.println("＜h1＞Hello World! ＜/h1＞");%＞
            ＜/BODY＞
            ＜/HTML＞

（二）安装J2SDK

不管哪种方案，在安装和配置JSP引擎之前必须先完成J2SDK的安装。

1、安装J2SDK

在Windows下，直接运行下载的j2sdk-1_4_1_01-windows-i586.exe文件，根据安装向导安装到一个目录，例如安装到f:\j2sdk 1.4.1；

2、 添加环境变量

（1）如果你的操作系统是Win 98，可以用记事本直接编辑Autoexec.bat，添加下面命令行：

以下为引用的内容：

PATH=％PATH%;f:\j2sdk1.4.1\bin

SET JAVA_HOME=f:\j2sdk1.4.1

SET CLASSPATH=f:\j2sdk1.4.1\lib\tools.jar

保存后，重新启动计算机，这样所添加的环境变量才会有效。

（2）如果你的操作系统是Win2000，那么右击“我的电脑”，在弹出菜单中选择"属性"→"系统特性" →"高级" →"环境变量"， 弹出环境变量对话框，就可以编辑系统的环境变量了。添加PATH、JAVA_HOME和CLASSPATH三个变量，变量值同上。

四、 JSP环境的配置方案

（一）方案一：J2SDK＋Tomcat

在这种方案里Tomcat既作为JSP引擎又作为Web服务器，配置比较简单。

1、安装Tomcat

直接运行下载的jakarta-tomcat-4.0.1.exe，按照一般的Windows程序安装步骤即可安装好Tomcat,安装时它会自动寻找J2SDK的位置。例如安装到f:\tomcat4。

2、配置Tomcat的环境变量

添加一个新的环境变量TOMCAT_HOME，变量值为f:\tomcat4，添加方法同J2SDK环境变量的配置方法。

3、测试默认服务

设置完毕后就可以运行Tomcat服务器了。用f:\tomcat4\bin\startup.exe启动Tomcat，用f:\tomcat4\bin\shutdown.exe关闭。（如果在执行startup.exe或shutdown.exe的时候提示Out of Environment Space错误，选择DOS 窗口的菜单中的"属性"→" 内存"→" 常规内存"， 把"初始环境"由"自动"修改成"2816"就可以了。）

启动Tomcat后，打开浏览器，在地址栏中输入http://localhost:8080（Tomcat默认端口为8080），如果在浏览器中看到Tomcat的欢迎界面，表示Tomcat工作正常。

4、测试项目

把刚才准备好的test.jsp放在f:\Tomcat\webapps\examples\jsp目录下, 在地址栏中输入http://localhost:8080/examples/jsp/test.jsp，如果浏览器中显示"Hello World！"，则说明你的JSP环境配置成功了！

由于Tomcat本身具有web服务器的功能，因此我们不必安装Apache，当然它也可以与Apache集成到一起，下面介绍。

（二）方案二：J2SDK＋Apache＋Tomcat

虽然Tomcat也可以作Web服务器,但其处理静态HTML的速度比不上Apache,且其作为Web服务器的功能远不如Apache,因此把Apache和Tomcat集成起来，用Apache充当Web服务器，而Tomcat作为专用的JSP引擎。这种方案的配置比较复杂，但是能让Apache和Tomcat完美整合，实现强大的功能。

注意，因为IIS Web服务器默认使用80端口，而Apache的默认端口也是80，所以如果你使用的是Win2000操作系统，而且预装了IIS，为方便请在进行以下操作之前先将IIS服务停掉。

1、安装Apache

运行下载的apache_2.0.43-win32-x86-no_ssl.exe，按照向导安装到f:\Apache2。（注意，Apache2.0.43安装成功后，必须将f:\Apache2\htdocs目录下的index.html.en改名为index.html，这样在测试默认服务时才会正常显示Apache的欢迎界面）。

2、测试Apache默认服务

安装完后，Apache服务器就已经自动运行了。打开浏览器，在地址栏中输入：http://localhost（Tomcat默认端口为80），如果在浏览器中看到Apache的欢迎界面，说明Apache工作正常。

3、 按照方案一的步骤安装Tomcat，并保证它正常运行。

4、 将下载的mod_jk-2.0.42.dll复制到f:\Apache2\modules目录下。

5、 建立mod_jk模块工作所需要的工作文件。

打开文本编辑器，输入下列语句：

以下为引用的内容：

workers.tomcat_home=f:\tomcat4 （让mod_jk模块知道Tomcat）

workers.java_home=f:\j2sdk1.4.1 （让mod_jk模块知道JSDK）

ps=\

worker.list=ajp13 （mod_jk的模块版本）

worker.ajp13.port=8009 （mod_jk的工作端口）

worker.ajp13.host=localhost

worker.ajp13.type=ajp13

worker.ajp13.lbfactor=1

把上面的语句以workers.properties为文件名保存在f:\Tomcat4\conf目录下（注意:文件的扩展名是.properties）。 　　

6、 配置Apache。

用文本编辑器打开f:\Apache2\conf\httpd.conf

1）找到"DirectoryIndex"，在index.html.var后面再添加index.jsp；

2）在httpd.conf的最后加入下面这段代码（括号里为解释） Webjx.Com

以下为引用的内容：

LoadModule jk_module modules/mod_jk-2.0.42.dll

（装载mod_jk模块，用于处理Apache和Tomcat的连接）

JkWorkersFile "f:/tomcat4/conf/workers.properties"

（指出mod_jk模块工作所需要的工作文件workers.properties的位置）

JkMount /servlet/* ajp13

JkMount /*.jsp ajp13

（将所有servlet 和jsp请求通过Ajp13的协议送给Tomcat，让Tomcat来处理）

3）添加完毕后保存。

7、 配置Tomcat

用文本编辑器打开f:\Tomcat4\conf\server.xml。因为Tomcat4默认不启用Ajp13，所以查找到如下这段代码：

以下为引用的内容：

＜!--
            ＜Connector className="org.apache.ajp.tomcat4.Ajp13Connector"
            port="8009" minProcessors="5" maxProcessors="75" acceptCount="10" debug="0"/＞
            --＞

把注释符号＜!-- --＞ 删掉就可以启用Ajp13了。

然后保存，现在Tomcat和Apache的整合配置基本完成了。

8、 整体测试

把test.jsp放在f:\Tomcat\webapps\examples\jsp 目录下，依次启动Apache2，Tomcat4。打开浏览器，在地址栏里输入http://localhost:8080/examples/jsp/test.jsp，如果浏览器中出现"Hello World！"，则Tomcat重新配置后工作正常；在地址栏中输入http://localhost/examples/jsp/test.jsp，若与http://localhost:8080/examples/jsp/test.jsp的结果相同，那就表明Apache和Tomcat整合成功了！

（三）方案三：J2SDK＋IIS＋Tomcat Webjx.Com

Windows平台下最常用的Web服务器无疑是IIS，正常情况下IIS不支持JSP，我们可以通过使用一个IIS到Tomcat重定向插件，使IIS能够将所有的JSP请求发送到Tomcat执行，可以使IIS增加处理JSP的功能。如果你已经习惯了使用IIS，那么可以尝试这种配置。（如果您已经安装过Apache服务器，为了便于后面的操作请先卸载Apache。）

1、按照方案一的步骤安装Tomcat，并保证它正常运行。（例如安装到f:\tomcat4）； Webjx.Com

2、将下载的tc4ntiis.zip直接解压缩到f:\tomcat4目录下。查看配置所需要的文件，确保它们在以下位置：

f:\tomcat4\server\lib\ajp.jar

f:\tomcat4\server\lib\tomcat-util.jar f:\tomcat4\bin\native\isapi_redirect.dll f:\tomcat4\conf\ntiis\workers.properties f:\tomcat4\conf\ntiis\uriworkermap.properties f:\tomcat4\conf\ntiis\iis_redirect.reg

f:\tomcat4\log\iis_redirect.log Webjx.Com

3、用文本编辑器打开f:\tomcat4\conf\ntiis\workers.properties ，修改下列值为：

workers.tomcat_home=f:\tomcat4

workers.java_home=f:\j2sdk1.4.1

4、双击f:\tomcat4\conf\ntiis\iis_redirect.reg ，将此注册文件内的信息添加到注册表中，但是要修改log_file、worker_file 、worker_mount_file这三个键的键值，以适合你的环境（比如本文中的Tomcat就安装在f:\tomcat4，而不是默认的c:\tomcat4）。添加并修改完毕后如下图。

5、打开Internet服务管理器，在默认站点上添加一个新的虚拟目录，名称为jakarta，这个虚拟目录指向f:\tomcat4\bin\native ，并启动该默认站点。

6、在Internet服务管理器中用鼠标右键单击服务器名，选择"属性"→主属性中"WWW服务"的"编辑" →"ISAPI筛选器"选项卡，添加一个ISAPI筛选器，名字为Jakarta Redirect，可执行文件指定为f:\Tomcat4\bin\native\isapi_redirector.dll。在添加ISAPI过滤器后, Jakarta Redirect的状态是一个红色的向下的箭头，重新启动IIS服务，就会变成绿色的箭头。

7、编辑 server.xml 文件并保存（同方案二的第7步）。

8、重新启动IIS和Tomcat。

9、测试项目：把test.jsp放在f:\Tomcat\webapps\examples\jsp 目录下。打开浏览器，在地址栏里输入http://localhost:8080/examples/jsp/test.jsp，如果浏览器中出现"Hello World！"，则Tomcat重新配置后工作正常；在地址栏中输入http://localhost/examples/jsp/test.jsp，若与http://localhost:8080/examples/jsp/test.jsp的结果相同，那就表明IIS和Tomcat整合成功了！

五、结束语

搭建JSP的运行环境是学习JSP技术的基础，JSP引擎种类很多，配置方法也很多，而且软件的版本也在不断的升级，大家可以根据自己的需要和实际情况选择合适的配置方法。希望本文给出的几种JSP环境配置方案，对想学习JSP的人有所帮助。

问题：

WINXP+ACCESS平台进行TD移植到WIN2003+ACCESS平台。报告的错误分别为：

新增bug时报错为:failed to add new bug;
                        Details:  Failed to add new bug.
                                   Cannot get sequence value
                                   CSequence :: Get_Next_Sequence
                                   CBug :: AddBug
修改bug时报错为:CDBLock::OBjLock-unable to insert new lock
                         Details:   CDBLock::ObjLock - unable to insert new lock
                                      CDBLock::ObjLock - unable to insert new lock
                                      CDBLock::DBLOCK

解决：

此问题为TD进行平台移植过后的权限问题。会发现在WIN2003系统NTF格式下，站点目录TD_Dir只有只读权限，无法对项目中进行写操作。因此需要将ACCESS数据库目录读写权限打开就能解决此问题了。

在此将ACCESS权限读写打开图解记录如下：

win2000和win2003的用户也可以参考这个步骤（前几步不需要）。

一、如果动力系统的数据库所在的分区为NTFS分区，则进入后台或其他一些操作时会提示出错：数据库只读。  FAT32分区无些问题。

二、请进入文件管理器的文件夹选项

三、将“使用简单文件共享”前的勾选去掉

四、右键点击数据库目录－共享和安全

五、添加组和用户名称

六、点击高级选项

七、查找用户或组

八、选择IUSR_*** （***为你的机器的名称）

九、点击确定

十、勾选数据库目录对于IUSR_***的读写权限

【关键词】项目移植集成工作环境分布式工作环境

这里我们先将以上的几个名词解释一下：

项目移植：这里说的项目移植是指将已经建立的TD项目整体文件在保证数据安全和完整的前提下移植到其他服务器的过程，这个过程包括以下几个方面（1）数据库的移植（2）项目文件的移植（3）项目配置文件的移植。经过移植后的TD项目可以实现双机备份的功能。

集成工作环境：我们把TD服务程序和TD 使用的数据库存放在同一台计算机上的这种工作环境称为集成工作环境。这种工作环境节省成本，维护较复杂，不利于数据的安全性。

分布式工作环境：我们把TD服务器程序和TD后台使用的数据库存放在不同机器上，也就是使用单独的一台计算机作为TD项目的数据库服务器，TD服务程序通过网络访问数据库服务器，这种工作环境称为分步式工作环境。这种环境的成本较高，但是利用维护，数据的安全性较高。对一些专业性的企业尤其是需要将TD开放到Internet上，我们建议使用这种工作环境。

。移植说明

基于IIS WEB服务下的TD服务程序支持的数据库有ACCESS,SQL SERVER、SYBASE、ORACLE。由于ACCESS数据库的迁移比较容易本文就不介绍，本文主要讨论SQL SERVER数据库的移植。掌握SQL SERVER数据库类型的TD项目移植，对ORACLE、SYBASE类型数据库的项目移植工作也能做到触类旁通。下面大家就跟我们一切进入TD项目移植的具体工作吧！

下面的移植工作，我们选用了一个名为：E-CIS的项目进行实例移植，同时我们将其他计算机上的TD项目（SAAA、SIMS、E-ICID）与E-CIS进行了合并。

。集成工作环境的数据迁移

1、拟分析产生的原因和解决方法

产生的原因：

由于我们配置的TD服务器与数据库服务器是同一台计算机，一旦计算机发生故障，TD项目中的数据既便是备份出来也很难恢复，其主要原因是：

• 使用TD建立项目时，TD会在数据库中自动建立一个名为TD的用户，我们运行的E-CIS项目中所有的表都是由TD这个用户建立的，无法删除和添加这个用户。
• 在SQL查询分析器中可以看到所有相关的表都是td.*的格式，这样会造成如果SQL查询分析器是以其他用户登入，执行select * from all list出现错误。出现一定要加前缀后才能查询出来数据问题，这个就是造成恢复数据库后即使其他项目都配置正确，但TD依然不能正常使用的一个重要原因。
• 在安装TD后会在安装盘符：\Program Files\Common Files\Mercury Interactive\Domsinfo目录下，有一个用来存放系统信息的ACCESS数据库Doms.mdb，这个数据库由TD创建，并且是经过加密的，它存放着TD所有的配置信息。这个数据库是是否能够成功恢复TD项目的一个重要因素。

2、移植前的备份工作

在正式移植之前，我们首先要做好数据的备份工作，这也是我们移植工作的一部分，虽然我们现在的移植技术已经相对较成熟，但是我们还是要建议大家移植之前的备份是很有必要的。备份主要备份以下的数据：

．备份DomsInfo目录；

默认在C:\Program Files\Common Files\Mercury Interactive下。这个目录包含了Doms.mdb文件（用户信息和工程列表）、connection strings（连接字符串）、parameters（参数）、global style sheets（全局风格表）、the database template（Empty_DB.mdb）（一些临时数据）

．备份TD项目安装文件；

TD_Dir包含每个工程的自动测试、附件、设置、风格列表。默认在C:\TD_Dir\Default目录下，打开这个目录可以看到TD的工程文件，我们需要将这些工程文件备份下来。

．备份项目数据库；

备份项目用的数据库文件。

3、移植工作

移植工作分为四个部分：

――数据库的迁移；

――建立访问数据表文件的TD用户；

――修改TD的项目配置数据库(Access)；

――修改Project中的INI文件。

1）数据库的迁移：

数据库的移植目的是：将项目数据库从原来的计算机移植到新的计算机。

具体思路：通过SQL Server 集成的导入和导出数据功能将原数据库文件导入新的SQL Server服务器中。在这个过程，原表中由TD用户创建的表也会更改为DBO用户创建。例如：数据库中的表ALL_LISTS原来由td用户创建，移植后ALL_LISTS表的用户更改为dbo这样问题也就解决了。

我们现在开始图解数据库的操作：

　　　　　　　　　单击 “Next”

　　　　　　　　　选择要恢复的数据源后单击“Next”

　　　设置数据库恢复到的位置，注意：需要在数据库这里设定数据库被恢复的名称，点击 　　　

　　　　　　　　　　建立数据库名称后，单击确定后，再“Next”按钮：

　　　　　　　　　再“Next”（这个选项选择第三项更具有完整性）

　　　　　　　　　选择需要恢复的数据表后（在这里选择全部表），再”Next”：

　　　　　　　　　准备开始恢复，单击“Next”：

　　　　　　　　　单击”Finish”按钮，开始恢复：

　　　　　　　　　　恢复成功后出现提示：

数据库恢复完成。

2）建立访问数据表文件的TD用户：

建立td用户的目的是：使td用户具有访问新恢复项目数据库的权限。

具体思路：建立一个名为td的用户，使这个用户具有访问TD项目数据库的控制权限，TD通过这个用户对项目数据库进行增、删、改的操作。

打开企业管理器，在目标数据库计算机中建立TD用户，并且设定TD用户访问的数据库。

　　　　　　　　在登录项中新建用户，在弹出的对话框中设定td用户相关的属性，如：

设定的密码可以根据用户确定，这里设定为：tdtdtd；在“服务器角色”中设定td用户的权限，我们给出建议设定为“System Administrators”：

　　　　　　　　　　　　　　完成“服务器角色”的设定，为td用户设定数据库访问的权限：

设定td用户能够访问TD项目的数据库和Master数据库。设定完成后，确认td用户默认数据库是否为Default_e-cis_db

设定完成。

3）：修改TD的配置项目文件(Access)：

修改配置文件目的是：将项目文件（TDDIR目录下存在的项目文件）和项目数据库进行关联。

具体思路：修改ACCESS数据库中每一个配置参数，使TD项目文件和项目数据库关联，通过这个操作我们还可以实现多个TD项目合并删除的功能。（在这里我们就不详细介绍，有兴趣的朋友可以研究一下）

在TD安装的计算机中的C:\Program Files\Common Files\Mercury Interactive\DomsInfo目录下打开doms.mdb文件，此文件是经过加密处理的，其密码为：tdtdtd

打开后可以看到相应的表：

这些表，存放着TD所有的配置信息，是很重要的，我们根据自己的工作环境实际配置这个表，其中需要修改的表是：DBSERVER、DOMAINS、PARAMS、PROJECT和TDSERVERS这五个表。

　　　　　　b.DOMAINS表中主要修改PHYSICAL_DIRECTORY字段的值。(基本上不要修改)

　　　　　c.PARAMS表中主要修改PARAM_VALUE字段的值。（基本上不要修改）

d.PROJECT表中主要增加或修改一个记录就行了，其关键字段表示的意思是PROJECT_ID(项目ID号不能重复),PROJECT_NAME（项目名称）,DB_NAME（项目对应的数据库名称如本例的default_e_cis_db）,DB_TYPE(数据库类型１为ACCESS，2为SQL SERVER),PHYSICAL_DIRECTORY(TD服务器中的共享目录如本例为\\10.168.188.152\td_dir\default\e_cis、DB_USER_PASS(TD用户密码如本例为tdtdtd)、DBSERVER_NAME(数据库的IP地址)。

　　　　　e.TDSERVERS中主要修改DBSERVER_NAME、TD_IP_ADDRESS

说明：以上修改是针对移植工作修改的表，如果我们需要将分布在多台计算机上的TD项目合并移植到一台服务器上，还需要修改ACCESS数据库中的SEQUENCES表中的USER_SEQ字段的数值，这个字段是用来控制用户数量，如果数值太小TD部分用户就出现无法登录的现象。

总结：修改的内容还需要根据自己的实际情况进行修改，我这里只列出常修改的一些字段。

4）：修改Project中的INI文件：

修改INI文件目的是：ini文件保存数据库信息，TD程序信息，项目名称以及相关的内容。

具体思路：修改ini文件配置参数，使TD项目文件和项目数据库关联。

将C：\TD_Dir\Default目录下面的E-CIS项目文件，拷贝到备份的计算机中，然后修改E-CIS文件夹内的Dbid.ini文件：

Dbid.ini 内容：

[General]

Database_Type=MSSQL

Created_Date=08/11/04 15：44：39

Created_By=td

AliasName=E-CIS

Database Name=default_e_cis_db

Database Server=10.168.188.229

Domain Name=DEFAULT

SendAllQualified=Y

Has_VCS_DB=Y

主要修改的内容是：

Database Name=default_e_cis_db

Database Server=10.168.188.229

按照实际情况填写这些信息，就ok了。

总结：通过以上的介绍，我们集成工作环境的移植工作就已经完成了。经过这样的移植，我们可以实现TD项目的双机备份，双机备份可以让我们的数据更安全、更有保障。

．分布式工作环境的备份和恢复方法

分布式工作环境的项目移植相对集成工作环境移植更简单，在这里我们不详细介绍，相信大家看过集成工作环境的移植对分布式移植不在话下了。

我们对分布式工作环境移植的思路：

• 强调首先备份项目的数据。
• 移植TDDir目录下的项目文件到新的服务器上。
• 复制DomsInfo目录到新服务器C:\Program Files\Common Files\Mercury Interactive下。
• 修改这个目录下Doms.mdb文件的参数。（修改的详细方法见集成工作环境的移植）

总结：相对集成工作环境移植来说，分布式结构移植少了数据库的移植，可以继续使用原有的数据库，在移植过程中数据库的移植是移植成功与否的关键因素之一，少了这个过程相信大家移植更为方便。

【小结】以上我们介绍了两种结构的移植工作，经过上述修改项后，迁移数据的工作就已经成功，td服务器可以访问迁移后的数据库。通过移植工作，同时可以解决TD项目的双机相互备份的问题，保障数据的安全性。

再次备份TD项目，只需要将原来TD后台数据库表中的数据导入另一台计算机中的数据库中，就可以实现。

　　很多人在应用vss的简单功能，但是对于VSS的分支合并功能，却很少应用。今天正好做了下vss的分支合并功能的测试。在此共享给大家！

　　一、测试步骤：1、建立两个vss目录，QA目录和Jessie目录（假设QA为公共源代码目录，Jessie为个人工作目录）

　　2、检入5种文件进QA目录：

　　.ini

　　.cpp

　　.h

　　.txt

　　.doc

　　3、然后再把五个文件托进“Jessie”目录，点击菜单上“branch...”确定后，进入分支开发状态；

　　4、修改“Jessie”下面的文件，将5个文件都chenck out进行修改，在最后一行新增或插入修改，然后check in；

　　5、进入“QA”目录下，分别选择每个文件，点击菜单上“merge branches... ”，出现提出框，此时vss匹配两目录下的文件，有3种情况：

　　if 文件类型是Vss不支持文件 then

　　提示不能合并

　　else 进行匹配，匹配结果有两种：

　　a.如果同名的两处文件不存在冲突，提示确认后，即可按照“Jessie”目录下的文件更新；

　　b.如果同名的两处文件存在冲突，系统弹出显示框，显示文件中的每处冲突位置和内容，这是需要人干预决定。

　　6、合并完毕，查看各文件内容，发现测试的ini、cpp、h、txt文件都能进行分支合并，但是doc这种binary类型的文件不能进行分支合并操作。

　　二、 vss分支合并操作的优缺点分析：

　　1、优点：分支合并操作简单，方便控制好权限，且能及时得到的工作产物；

　　2、缺点：分支合并操作支持的类型有限制，对binary类型的文件不支持；

　　多人修改同一文件的同一处，合并时，需要人工手工合并；

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。

　　关键字：头脑风暴法、德尔菲法、要素加权法;RM：需求管理，CCB：变更控制委员会，QFD：质量功能调配，HOQ：质量屋。

　　约定：本文涉及到的关键字概念和采用的技术的概念都不做详细解释，里面的概念定义请查阅相关书籍，这里只讨论这些在需求管理中的使用;同时里面的案例信息也不在这里做详细交代。

　　引用案例：某市网上审批项目。

　　1　概述

　　我们知道现代项目管理的六要素是：时间、成本、质量、组织、范围、客户满意度，实际上，要满足这六个要素，计划一个良好的需求分析是实现这六因素的前提，如果我们在项目生命周期的某些阶段出了问题，而我们可能还不知道，这将影响整个项目周期，无论该计划如何详尽，如果需求有误和需求分析不到位，项目的控制将没有任何价值，IT软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell 1997)，从某种意义来讲，项目的成功基于项目的需求管理的成功。

　　2　需求的定义及特点

　　根据IEEE项目工程标准词汇表(1997)年中对需求的描述如下：业主解决问题或达到目的所需的条件或权能，和系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。在PMBOK中，项目需求就是在“项目范围”约定的。

　　需求最显著的特点是“随着项目而改变、随着项目而渐进明晰”，项目管理的特点是随着进展而渐进明细化，可以看出需求管理和项目管理一样，这就意味着需求在项目的整个生命周期都可能存在的，这样项目管理的过程，也必不可少需求的管理。

　　3　如何获取需求

　　获得需求的方式可以有多种多样：电话询问、现场考察、聆听用户讲解、阅读用户编制的相关文件(如招标书)，其实这些方法都是GET方式，我们可以通过以下两类技术手段来达到：GET(获取)和PUSH(引导、反馈、激发)相互结合的方式来得到我们真正的需求，而这两个过程都是必须交互进行的，一般我们可以筛选一名非常有经验(包括谈判技巧、深厚的业务和技术背景、人缘很好、勤奋努力)的人士担任需求工程师，长期在客户那里工作，他的工作主要是界定项目的范围和需求变更管理，通过我们编制的各类模板文档来实现需求变更的控制;

　　一般来讲IT集成需求包含三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需求提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明;用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明;功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求，必须具备一定的业务背景和技术背景，能从三个不同的层次发掘客户的需求。

　　根据我们在某市网上审批项目中的经验，我们采用如下方法，其中每项工作都记录文档备案：如查阅了大量资料和病历资料格式、各类应急防御措施、统计分析报表、系统规划书、旧系统业务状况、历史资料、还访谈了操作员的应用感受、多次技术交流、专题讨论等多种形式的交互式讨论和分析。这样无论是业务、功能、用户详尽的期望我们都了解的比较透彻。

4　需求管理

　　获取了需求接着要作的的工作就是对需求分析、消化和评审、基线制定、需求说明书制定，这里我们主要集中在需求分析和需求说明书两方面来。

　　4.1需求分析

　　1)建立需求关联图：需求关联图是用于定义系统与系统外部实体间的界限和接口的简单模型，同时它也明确了通过接口的信息流和物质流，通过关联图，对用户需求的约定和确认以及CCB的评审都是非常关键的。

　　2)创建开发原型：创建用户接口原型可以在如下应用如下情况：如果开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。通过开发原形，业主和集成商都可以相互了解业务，发掘潜在的信息，避免用户需求的不必要变更。

　　3)分析可行性：分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍，这个主要用于内部评审和制定技术线路提供依据，如在什么情况下采用.NET技术,什么情况下采用J2EE技术,我们在2003年电子政务网上审批系统中充分对需求(业务、技术、用户操作人员需求、现有系统需求等)做整体提取分析来确定技术线路的选型。

　　4)确定需求优先级：确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

　　5)为需求建立模型：为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

　　6)编写数据字典：在需求阶段，很难使团队的思路一致，建立一个合适的机制是完全必要的，这就是数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

　　4.2建立需求与产品质量的关系模型

　　需求是项目正确实施的一个前提,如果没有抓住用户的需求,那么很可能是漏洞百出，最终产品将不是一个真正的可交付物。我们知道，质量是一个客户满意度的一个主要因素，质量在项目中又有许多影响因素，这里我们着重从需求的角度出发来讨论需求与质量的关系，那么如何来从需求的角度出发建立与质量的控制呢?

　　我们来建立一个思路如下：客户所有的期望 需求产生 转换矩阵 产品开发 可交付物 客户满意。在这里转换矩阵就非常关键了，如何来实现需求与质量的关联呢，可以通过质量功能调配(QFD)来实现，通过QFD可以把需求(用户期望)、产品特性关联起来，这里要用到一个工具：质量屋(House of Quality)，我现在用一个案例来说明这个工具，在做某市网上审批项目中，我们从客户哪里收集和整理了许多需求：审批项目、报表要求、认证方式、工作流要求、数据范围及格式、操作界面、医药管理规范等等;我们通过建立质量屋完成了需求与如何去实现，如下图所示：

4.3需求说明书编写经验谈

　　目前需求说明书有固定的格式和要求,可以从专门介绍需求说明书的相关书籍中获得,在本论文中,我着重阐述需求说明书的经验，编写优秀的是没有公式化的方法的，这需要大量的经验，要从你在过去的文档中发现的问题学习。

　　1) 采用IT项目需求规格说明模版,要注意的是很多人拿来需求说明书模板就套用,这就有很大的风险,例如:会出现需求不全、需求范围界定不到位、需求分类不明确等因素，我们应该把需求规格说明书拿来后先罗列许多要点：约定、法律法规、需求分类、技术限制、采用的技术和工具等等全面考虑，与项目干系人特别是用户进行沟通，然后讨论，可以采用头脑风暴法和德尔菲方法来讨论，确定说明书大纲，而不能照本著书。

　　2) 附加文档的管理，值得注意的是需求说明书并非一成不变的，我们可以通过附加文档来跟踪用户的新的需求和需求变更，这样必须建立一个配套的文档集合，随时跟踪需求，保证开发团体步进统一，一般这些文件是要考虑的：《需求(或功能)变更申请书》、《需求(或功能)变更规格书》、《需求清单一览表》等。这样做的好处是对需求时实监控，保证项目的安排，同时让用户知道变更是一件很严肃的事情，可以防止个别人提出无法界定的需求(因为现实IT项目中，很多问题是其他系统的遗留而又超出本项目技术线路可以弥补的问题等)。

　　3) 编写需求说明书的时候，可能还会遇到一些解决不了的需求，我们也一定用专门的章节要罗列出来，防止漏项，同时也利于我们在做实施计划的时候来采取那种措施，采购其他设备、投入相关人力或其他办法。

　　4) 需求必须要客户确认，许多项目，可能开发商为了保护自己的“利益”很多事情都没有得到客户的确认，其实在需求阶段，我们的需求是要跟客户确认的，比如数据字典、界面选型、技术线路、功能模块等，这样做的好处是防止需求把握不得当，缺少了用户必要的功能，另一个就是防止了开发商需求镀金，提供了不必要的功能。

　　5　总结

　　经过以上各个方面来讨论需求管理在整个项目生命期所起到的作用，结合自身的经验，和一个案例《某市网上审批系统》综合分析了需求管理的办法和用到的工具，根据自身经验提出编写需求说明书要注意的地方。

　　单元测试大多数由开发人员来完成，测试人员技术背景较好或者开发系统软件时可能会安排测试人员进行单元测试，大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。讨论这个问题主要是扩充一下读者的视野。

　　单元测试一般包括五个方面的测试：

　　（1）模块接口测试：模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：

输入的实际参数与形式参数的个数是否相同；
输入的实际参数与形式参数的属性是否匹配；
输入的实际参数与形式参数的量纲是否一致；
调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
调用预定义函数时所用参数的个数、属性和次序是否正确；
是否存在与当前入口点无关的参数引用；
是否修改了只读型参数；
对全程变量的定义各模块是否一致；
是否把某些约束作为参数传递。
　　如果模块功能包括外部输入输出，还应该考虑下列因素：

文件属性是否正确；
OPEN/CLOSE语句是否正确；
格式说明与输入输出语句是否匹配；
缓冲区大小与记录长度是否匹配；
文件使用前是否已经打开；
是否处理了文件尾；
是否处理了输入/输出错误；
输出信息中是否有文字性错误。
局部数据结构测试；
边界条件测试；
模块中所有独立执行通路测试；
        （2）局部数据结构测试：检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

不合适或不相容的类型说明；
变量无初值；
变量初始化或省缺值有错；
不正确的变量名（拼错或不正确地截断）；
出现上溢、下溢和地址异常。
　　（3）边界条件测试：边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。

　　（4）模块中所有独立路径测试：在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：

误解或用错了算符优先级；
混合类型运算；
变量初值错；
精度不够；
表达式符号错。
　　比较判断与控制流常常紧密相关，测试时注意下列错误：

不同数据类型的对象之间进行比较；
错误地使用逻辑运算符或优先级；
因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
比较运算或变量出错；
循环终止条件或不可能出现；
迭代发散时不能退出；
错误地修改了循环变量。
　　模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。如果用户不按照正常操作，程序就退出或者停止工作，实际上也是一种缺陷，因此单元测试要测试各种错误处理路径。一般这种测试着重检查下列问题：

输出的出错信息难以理解；
记录的错误与实际遇到的错误不相符；
在程序自定义的出错处理段运行之前，系统已介入；
异常处理不当；
错误陈述中未能提供足够的定位出错信息。
　　2、 如何理解强度测试？

　　强度测试是为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资源的最下限指标。
它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统能力达到的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境.

　　强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大\最小\平均)以及顺序指标等

　　强度测试需要对系统的结构熟悉,针对系统的特征设计强度测试的方法

　　3、 如何理解压力、负载、性能测试测试？

　　性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。

　　压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。

　　实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。性能测试的相关内容，读者可以参考10.2.2节。

　　4、 什么是系统瓶颈？

　　瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。

　　严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100％时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。

　　因此我们测试系统瓶颈主要是实现下面两个目的：

发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。
5、 文档测试主要包含什么内容？

　　在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：

　　文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。

　　描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。

　　易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。

　　文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。

　　印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。

6、 功能测试用例需要详细到什么程度才是合格的？

　　这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。

　　另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。

　　实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系统”的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况（），如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。

　　另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。

　　因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。

　　7、 配置和兼容性测试的区别是什么？

　　配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。

　　配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：

　　（1） 软件在不同的主机上的运行情况，例如Dell和Apple；

　　（2） 软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况；

　　（3） 不同的外设；

　　（4） 不同的接口；

　　（5） 不同的可选项，例如不同的内存大小；

　　兼容性测试的核心内容：

　　（1） 测试软件是否能在不同的操作系统平台上兼容；

　　（2） 测试软件是否能在同一操作系统平台的不同版本上兼容；

　　（3） 软件本身能否向前或者向后兼容；

　　（4） 测试软件能否与其它相关的软件兼容；

　　（5） 数据兼容性测试，主要是指数据能否共享；

　　配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。

8、 软件文档测试主要包含什么？

　　随着软件文档系统日益庞大，文档测试已经成为软件测试的重要内容。文档测试对象主要如下：

包装文字和图形；
市场宣传材料、广告以及其它插页；
授权、注册登记表；
最终用户许可协议；
安装和设置向导；
用户手册；
联机帮助；
样例、示范例子和模板；
… …
　　文档测试的目的是提高易用性和可靠性，降低支持费用，因为用户通过文档就可以自己解决问题。因此文档测试的检查内容主要如下：

读者对象——主要是文档的内容是否能让该级别的读者理解；
术语——主要是检查术语是否适合读者；
内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
图标和屏幕抓图——检查图表的准确度和精确度；
样例和示例——是否与软件功能一致；
拼写和语法；
文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；
　　文档测试是相当重要的一项测试工作，不但要给予充分的重视，更要要认真的完成，象做功能测试一样来对待文档测试。

　　9、 没有产品说明书和需求文档地情况下能够进行黑盒测试吗？

　　这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。

　　在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。

　　10、测试中的“杀虫剂怪事”是指什么？

　　“杀虫剂怪事”一词由Boris Beizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。

　　为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。

　　11、在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？

　　在进行配置测试时，测试工程师仍然会发现一些普通的缺陷，也就是与配置环境无关的缺陷。因此判断新发现的问题，需要在不同的配置中重新执行发现软件缺陷的步骤，如果软件缺陷不出现了，就可能是配置缺陷；如果在所有的配置中都出现，就可能是普通缺陷。

需要注意的是，配置问题可以在一大类配置中出现。例如，拨号程序可能在所有的外置Modem中都存在问题，而内置的Modem不会有任何问题。

　　二、其它常见问题

　　1、 为什么尽量不要让时间有富裕的员工去做一些测试？

　　表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。

　　2、 完全测试程序是可能的吗？

　　软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件“零缺陷”发布。实际上完全测试是不可能的。主要有以下一个原因：

完全测试比较耗时，时间上不允许；
完全测试通常意味着较多资源投入，这在现实中往往是行不通的；
输入量太大，不能一一进行测试；
输出结果太多，只能分类进行验证；
软件实现途径太多；
软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；
　　因此测试的程度要根据实际情况确定。

　　3、 软件测试的风险主要体现在哪里？

　　我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。

　　因此，我们要尽可能的选择最合适的测试量，把风险降低到最小。

　　4、 发现的缺陷越多，说明软件缺陷越多吗？

　　这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接二连三的发现很多缺陷，颇有个人成就感。其中的原因主要如下：

代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。
程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。
　　“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。

　　5、 所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？

　　从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：
没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。 
        有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。 
        不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。
　　最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。

　　6、 软件测试人员就是QA吗？

　　软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。

　　软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。

　　7、 如何减少测试人员跳槽带来的损失？

　　在IT行业里跳槽已经是一种司空见惯的现象，而且跳槽无论给公司还是给个人都会带来一定的损失。测试队伍也无疑会面临跳槽的威胁，作为测试经理管理者，只有从日常工作中开始做起，最能最大限度的减少损失。建议我们从以下两个方面做起：

        加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。 
        通常情况下，企业能为员工提供足够大的发展空间时，如果不是待遇特别低，员工都不会主动离开企业。因此我们要想留住员工，管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。不过这项要求做起来比较，要有比较好的企业文化为依托。
　　8、 测试产品与测试项目的区别是什么？

　　习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件，例如Windows 2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：

        质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。 
        测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。 
        项目最后要和用户共同验收测试，这是产品测试不具有的特点。
　　此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作。

　　9、 和用户共同测试（UAT测试）的注意点有哪些？

　　软件产品在投产前，通常都会进行用户验收测试。如果用户验收测试没有通过，直接结果就是那不到“Money”，间接影响是损害了公司的形象，而后者的影响往往更严重。根据作者的经验，用户验收测试一定要让用户满意。

　　实际上用户现场测试更趋于是一种演示。在不欺骗用户的前提下，我们向用户展示我们软件的优点，最后让“上帝”满意并欣然掏出“银子”才是我们的目标。因此用户测试要注意下面的事项：

　　（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。

（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向

　　用户做成合理的解释。争得时间后，及时修改缺陷来弥补。

　　（3）永远不能欺骗用户，蒙混过关。道理很简单，因为软件是要给用户用的，问题早晚会暴露出来，除非你可以马上修改。

　　和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好基础。

　　10、如何编写提交给用户的测试报告？

　　随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。很多人会问：“我们可以把工作中的测试报告提供给客户吗？”答案是否定的。因为提供内部测试报告，可能会让客户失去信心，甚至否定项目。

　　测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况，这里不过多讨论，读者可以参考第9章的相关内容。这里主要讨论一下外部测试报告的写法，一般外部测试报告要满足下面几个要求：

根据内部测试报告进行编写，一般可以摘录；
不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；
报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；
报告上面的内容尽量要真实可靠；
整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。
　　总之，外部测试报告要小心谨慎的编写。

　　11、开发人员老是犯一些低级错误怎么解决？

　　这种现象在开发流程不规范的团队里特别常见，尤其是一些“作坊式”的团队里。解决这种问题一般从两个方面入手：

　　一方面从开发管理入手，也就是从根源来解决问题。可以制定规范的开发流程，甚至可以制定惩罚制度，还有就是软件开发前做好规划设计。

　　另一方面就是加强测试，具体做法就是加强开发人员的自己测试，把这些问题“消灭”在开发阶段，这是比较好的做法，读者可以参考第13章试案例分析的“13.1.2缺陷反复出现，谁的责任”小节，13.1.2专门讨论了这类问题的方法。

　　此外，还可以通过规范的缺陷管理来对开发人员进行控制，比如测试部门整理出常见的缺陷，让开发人员自己对照进行检查，以减少这类低级错误的发生。

　　开发人员犯错误是正常的现象，作为测试人员一定不能抱怨，要认认真真的解决问题才是上策。

　　12.测试工具在测试工作中是什么地位？

　　国内的很多测试工程师对测试工具相当迷恋，尤其是一些新手，甚至期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。自动化测试弥补了手工测试的不足，减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等自动化测试也是手工所不能完成的。

　　对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。

$ svnadmin create /usr/local/svn/newrepos

IMPORT MODULE

$ svn import mytree file:///usr/local/svn/newrepos/fooproject
Adding mytree/foo.c
Adding mytree/bar.c
Adding mytree/subdir
Adding mytree/subdir/quux.h
Committed revision 1.

START STANDALONE SVN SERVER

svnserve.exe -d -r d:/temp/repos

STARTING SVN UNDER APACHE

  DAV svn
  SVNPath d:/Data/SVN
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile d:/Data/SVN/svn-auth-file
  Require valid-user

svn co http://ip:port/path/to/repo/

ENABLING SIMPLE AUTHORIZATION

1) create passw file:

htpasswd -cm d:/Data/svn-auth-file

htpasswd -m d:/Data/svn-auth-file

2) create svn-policy-file file:

[groups]
project1-developers = anton, mike
project2 = anton, mike, peter
[project1:/]
@project1-developers = rw
[project2:/]
@project2-developers = rw

3) httpd.conf:

  DAV svn
  SVNPath d:/Data/SVN
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile d:/Data/svn-auth-file
  Require valid-user
  AuthzSVNAccessFile d:/Data/svn-policy-file

ENABLING SVN TRAFFIC COMPRESSION

It is required to invoke mode_deflate in httpd.conf:

DeflateBufferSize 8096
DeflateCompressionLevel 9

...

  SetOutputFilter DEFLATE
  SetInputFilter DEFLATE
  DAV svn
  SVNPath d:/temp/repos
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile d:/temp/svn-auth-file
  Require valid-user

EXTRACTING ONE PROJECT FROM MULTIPROJECT REPOSITORY

1) Dumping repos:

svnadmin dump d:datasvn > repo-dump
or svnadmin dump myrepos --revision 100:200 > revs-100-200.dumpfile

2) taking 1 project from repo:

type repo-dump | svndumpfilter include project1 > project1-dump

3) removing root dir:

Node-path: project1
Node-action: add
Node-kind: dir
Content-length: 0

Replace all "Node-path: project1/" strings with "Node-path: "

4) creating repo:

svnadmin create d:datasvnproject1

5) restoring:

svnadmin load d:datasvnproject1 < project1-dump

6) browsing

svnlook tree d:datasvn

7) Configuring Apache:

  SetOutputFilter DEFLATE
  SetInputFilter DEFLATE
  DAV svn
  # any "/svn/foo" URL will map to a repository /usr/local/svn/foo
  SVNParentPath d:/Data/SVN
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile d:/Data/svn-auth-file
  Require valid-user

[to a new branch] svn switch http://newIP:newPort/path/to/repo
[to a new URL] svn switch --relocate http://oldIP:oldPort/path/to/repo http://newIP:newPort/path/to/repo

BERKLEY DB recovery

1) download appropriate bdb release from berkley site

2) build win tools usinn VC 6.0+

3) run db_recover -vec -h d:datasvnproject1

4) move _db files from d:datasvnbroker into d:datasvnproject1db folder

5) if fail problem persists, after 4th step do backup/restore svn repo:

 
 svnadmin dump d:datasvnproject1 > project1.timestamp.dump
 
 svnadmin create d:datasvnproject1
 svnadmin load d:datasvnproject1 < project1.timestamp.dump

本文档的大多数内容假定你是从一个二进制发布版安装Apache到Windows上。 如果你想自己编译Apache(可能有助于开发和跟踪bugs)，参看编译Windows下的Apache。

现在，对Windows 9x的支持是不完善的。 当前Apache 2.0并不期望在Windows 9x平台上运行。 如果你有兴趣在那方面给于帮助，请看开发者站点上的如何加入主题的信息。 将来可能会因为某些原因提供这方面的支持， 我们欢迎提供使Apache能够运行在Windows 9x上的补丁。

本文档使用到的缩写及其意义解释包括：

• Windows NT: 指所有版本的基于NT核心的Microsoft Windows操作系统， 包括Windows NT, Windows 2000, Windows XP and Windows.NET Server 2003及后续版本。
• Windows 9x: 指所有版本的定位于家庭使用的Microsoft Windows操作系统， 包括Windows 95, Windows 98 and Windows ME。

• 对操作系统的要求

  Apache 2.0被设计为在Windows NT 4.0和Windows 2000上运行。 它的二进制安装程序只能在x86族的处理器上运行，比如Intel芯片。 Apache可能也能够运行在Windows 9x上，但是并没有经过测试， 也不建议在实际工作的系统上这样使用。 任何情况下都必须确保TCP/IP网络协议已经安装。

  如果在Windows 95上运行，必须安装"Winsock2"升级补丁。 "Winsock2" for Windows 95可以在 这里下载。

  如果在NT 4.0上运行，建议安装Service Pack 6， 因为Service Pack 4有众所周知的TCP/IP和Winsock完整性的问题， 在以后的Service Pack中解决了这些问题。

  

  下载 Apache for Windows

  关于Apache最新版本的有关信息可以在位于http://httpd.apache.org/ 的Apache web服务器上找到。那里会列出当前发行版本、 所有最近的alpha和beta测试发行版本以及镜像web站点和匿名ftp服务器的信息。

  你应该下载带有.msi扩展名的Apache for Windows版本。 这是一个单一的Microsoft Installer文件，包含了Apache，可以立即安装并运行。 还有一个单独的.zip文件只打包了源码， 可以用Microsoft Visual C++ (Visual Studio)工具来编译。

  

  安装 Apache for Windows

  Apache的安装需要有Microsoft Installer 1.2或更高版本。 在Windows 9x中，你可以从这里 升级Microsoft Installer到2.0，在Windows NT 4.0和2000中，2.0的升级版在这里. Windows XP不需要这个升级。

  注意，使用这个安装包不能在同一个机器上安装两套Apache 2.0。 但是，在同一个机器上，安装一个1.3系列和一个2.0系列的Apache则没有问题。 如果你需要在同一个机器上安装两套不同的2.0版本， 则必须用代码编译和安装Apache.

  运行已下载的上述Apache .msi文件。安装程序会要求提供下列信息：

  • 安装Apache的文件夹(缺省是 \Program Files\Apache Group\Apache， 虽然你可以把它指定为任何其他文件夹)
  • 开始菜单上的名称(缺省是"Apache Web Server")
  • 安装类型。选择]"Typical"选项会安装除源码以外的所有内容。 选择"Minimum"选项不安装说明手册和源码。如果希望安装源码请选择"Custom"安装方式。

  安装期间，Apache将会配置你所选择安装目录下的conf文件夹中的文件。 但是如果那个目录下已有同名文件存在，原有文件将不会被覆盖， 而新的相应的文件将会被加上.default扩展名。 所以，举例来说，如果conf\httpd.conf已经存在，那么不会对它做任何改变， 而新版本http.conf的内容将会被写入文件conf\httpd.conf.default。 安装完成以后你应该检查.default文件中的内容看看有没有不同， 如果必要，更新你原有的配置文件。

  而且，如果你已经有一个名为htdocs\index.html的文件，它也不会被覆盖掉 (也不会安装index.html.default文件)。 这意味着你在一个旧版本Apache上安装新版本是安全的 (但是你必须在安装之前首先停掉原有服务器然后在安装完成后再启动服务器)。

  安装Apache以后，要求你应该编辑conf目录下的配置文件。这些 文件已在安装期间被配置以便Apache能够从安装目录运行，文档目录被配置为安装 目录下的子目录htdocs。在你开始真正使用之前还有很多选项需要设 置。但是为了尽快开始，可以使用安装时自动配置的配置文件。

  

  配置 Apache for Windows

  Apache使用conf目录下的文件进行配置，与Unix系统下的版本一样， 但是Windows版本有几个不同的指令，可阅读Apache 文档察看全部可用指令。

  Apache for Windows主要的不同点是：

  • 因为Apache for Windows是多线程的，它并不像Unix版本那样为每个请求使用一个单独的进程。 而是通常运行两个Apache进程：一个父进程，和一个处理请求的子进程。 在子进程内部由单独的线程来处理每个请求。

    因此"process"-管理指令族是不同的：

    MaxRequestsPerChild - 就像在Unix版本中的相同指令，这条指令控制一个进程退出前将为多少个请求提供服务。 然而，与Unix不同的是，一个进程将即时为所有请求而不是只为一个请求服务， 因此如果设置这条指令，建议将它设为一个很大的值。 缺省的设置，MaxRequestsPerChild 0，不会引起进程总是退出。

    警告： 启动新的子进程时将会重新读入服务器配置文件。如果你修改了httpd.conf， 新的子进程将有可能不能启动或者可能得到预期之外的结果。

    ThreadsPerChild - 这是一条新的指令，用来告诉服务器应该使用多少个线程。 指明了服务器可以立刻处理的连接的最大数量； 如果你的站点有大量的点击，确认并为你的站点设置这条足够大的值。 缺省值是ThreadsPerChild 50。

  • 接收文件名作为参数的指令必须使用Windows文件名取代Unix文件名。 但是，因为Apache内部使用Unix风格的名字，你必须使用正斜杠而不是反斜杠。 可以使用盘符；如果省略，将假定使用Apache执行文件所在盘符。

  • Apache for Windows具有运行时装入模块的能力，不需要重新编译。 如果Apach是e在正常情况下编译，它会在\Apache\modules目录下安装许多可选模块。 要激活它们或者其他模块，必须使用新的LoadModule指令。 举例来说，要激活状态模块，使用下列指令(除了access.conf中的状态激活指令以外):

    LoadModule status_module modules/mod_status.so

    也可使用创建可装载模块中的信息。

  • Apache也可以装载ISAPI扩展(i.e., Internet Server Applications)，例如Microsoft IIS服务器和其他一些Windows服务器所使用的。 这里有更多相关信息。注意Apache不能装载ISAPI 过滤器。

  • 当运行CGI脚本时，Apache查找脚本解释器使用的方法是由 ScriptInterpreterSource 指令配置的。

  • 由于在Windows下管理具有像.htaccess这样名字的文件经常是很困难的， 你会发现在配置文件中使用AccessFilename 指令改变使用的配置文件的名字是很有用。

  

  以服务方式运行Apache for Windows

  用于指定服务名的-n选项只在Apache 1.3.7 及以后的版本中可用。 早期版本只支持缺省服务名"Apache"。

  你可以像下面这样将Apache安装为Windows NT服务：

  apache -i -n "服务名"

  要安装一个使用特定配置的服务，安装时指定配置文件：

  apache -i -n "服务名" -f "\my server\conf\my.conf"

  要移除一个Apache服务，使用:

  apache -u -n "服务名"

  如果没有指定服务名，缺省地，将使用"Apache"。

  一旦服务被安装，你可以使用-n选项和其他选项一起访问该服务的配置文件。例如：

  测试一个服务的配置文件：

  apache -n "服务名" -t

  启动一个使用某服务配置文件的控制台Apache：

  apache -n "服务名"

  

  关于服务依存关系的重要提示：

  对于Apache发行版1.3.13更早的版本，成功运行已安装服务所要求的依存关系并没有配置。 安装了一个早期版本Apache的服务以后， 你还必须做以下工作：

  运行 regedt32
从菜单选择窗口 - "HKEY_LOCAL_MACHINE on Local Machine"
双击打开 SYSTEM, 然后打开 the CurrentControlSet
滚动到Apache服务名并点击
从菜单选择 Edit - Add Value...
用下列值填充Add Value对话框
数值名称: DependOnGroup
数据类型: REG_MULTI_SZ
点击确定
保留多字符串编辑器为空并点击确定
Select Edit - 从菜单选择 Edit - Add Value...
用下列值填充Add Value对话框
数值名称: DependOnService
数据类型: REG_MULTI_SZ
点击确定
在多字符串编辑器中输入下列列表(每行一条)
Tcpip
Afd
点击确定


  如果你从第三方模块、ISAPI或者其他像ActiveState Perl那样的附加脚本技术使用了COM或者DCOM，你可能还需要在DependOnService列表中加入Rpcss条目。为了避免不必要地暴露TCP端口135，Apache安装时没有创建那个条目。如上述步骤在找到或是创建数值名称DependOnService，双击它并加入Rpcss条目到列表。

  

  运行Apache服务的用户帐号(NT/2000)

  当Apache第一次被安装为服务(例如使用-i选项)，它会以用户"System"(本地系统账号)运行。 如果web服务器的所有资源都在本地系统上，这样做会问题比较少，但是将会具有很大的安全权限来影响本地机器！

  本地系统账号是一个很有特权的本地账号，因此你不应该用它运行任何共享软件应用程序。 但是，它没有网络权限，不能通过任何NT安全机制离开本地机器，包括文件系统、命名管道、DCOM或secure RPC。

  永远不要把网络权限授予SYSTEM账号！创建一个新的用户帐号来代替它， 给这个用户授予合适的权限，并使用"Log On As:"选项。选择开始菜单 -> 设置 -> 控制面板 -> 服务 -> apache服务 ...并点击"启动服务"来访问该设置

  一个运行在本地系统账号背景中的服务继承了SCM(服务控制管理器)的安全背景，与任何已登录账号都没有关联，也没有用于验证的任何证书(域名、用户名和密码)。

  SYSTEM账号没有网络权限，因此对于服务一个Apache的共享安装实例或者共享页都是不可见的。如果你打算使用任何网络资源，下面的步骤应该有所帮助：

  • 在控制面板的服务对话框中选择Apache并点击启动服务。
  • 证实服务的账号是正确的。你可能希望为Apache服务创建一个账号。
  • 重新输入密码和确认密码。
  • 转到域的用户管理。
  • 从标题栏菜单点击策略，选择用户权限。
  • 选择高级用户权限选项。
  • 在下拉列表中，确认以下权限已授予选择的账号：
    • 作为操作系统一部分运行
    • 备份文件和目录
    • 作为服务登录
    • 还原文件和目录
  • 确认选择的账号是user组的成员。
  • 确认选择的账号获得了访问所有文档和脚本目录的权力(最少需要读取和浏览访问)。
  • 确认选择的账号对Apache日志目录有读/写/删除访问权限！

  如果你允许使用这个帐号登录为一个用户，你就可以自己登录上去测试执行脚本、读取web页的权限，还可以用控制台窗口启动Apache。如果这样工作正常，你又执行了上述的操作，那么Apache就能够正常地作为服务运行了。

  错误代码2186是一个很好的提示，说明你需要检查"log On As"选项，因为服务器不能访问必要的网络资源。
  

  Apache for Windows作为服务运行的故障分析

  当启动Apache为服务的时候你可能会遇到一个来自Windows服务管理器的错误信息。 例如，如果你想使用控制面板中的服务小程序启动Apache，可能会得到下面这条信息：

  Could not start the apache service on \\COMPUTER
Error 1067; The process terminated unexpectedly.

  启动Apache时一出现问题你就会得到这个错误信息。为了弄清是什么引起了错误， 你应该遵循从命令行运行Running Apache for Windows中的建议。

  还有，如果Apache作为服务运行，Apache 1.3.13 目前在Windows NT/2000下把启动错误记录在应用程序事件日志里。 运行事件察看器并选择应用程序日志检查相应纪录。

  即使没有错误信息弹出警告你发生了错误，也应该用事件查看器检查应用程序日志以防有错误发生。
  

  从命令行运行Apache

  要了解从命令行控制Apache服务的细节，请参照控制台命令行部分。

  

  控制服务方式的Apache

  可以以服务方式安装并运行Apache的多个实例。像下面这样启动、重启及关闭/停止Apache服务：

  apache -n "服务名" -k start
apache -n "服务名" -k restart
apache -n "服务名" -k shutdown
apache -n "服务名" -k stop

  对于缺省的"Apache"服务，选项-n仍然需要，因为如果命令中使用-k选项而没有-n 选项的话，命令会作用在运行于控制台窗口的Apache上。引号只是在服务名含有空格时才是必要的。

  注意-k shutdown的别名-k stop只是到了1.3.13版本才被引入。 早期版本的Apache只认识-k shutdown选项。先于1.3.3版本的Apache不认识任何-k选项！

  此外，你可以使用NT本机命令NET来启动和停止Apache服务，像这样：

  NET START "服务名"
NET STOP "服务名"

  同样，引号只是在服务名含有空格时才是必需的。

  

  高度试验性的Windows 95/98 服务

  只有Apache 1.3.13 及以后版本才有Windows 95 and 98 下的服务选项。早期版本的Apache在Windows 95/98 下只支持控制台窗口方式运行。

  对于让Apache在Windows 95/98 下以类似Windows NT/2000服务的方式运行有一些支持。都是高度试验性的, 即使能够工作，Apache软件基金会将不会证实其可靠性和未来的支持。继续进行你自己的冒险吧！

  一旦你确认Apache在命令行提示符下正确工作，你就可以像在Windows NT/2000版本下那样用同样的命令安装、控制和卸载Apache服务。

  但是，其中有相当大的区别你需要注意：

  如果你输入下列命令，Apache会尝试启动，如果成功他将在后台运行：

  Apache -n "服务名" -k start

  例如，通过桌面的快捷方式运行，如果服务启动成功一个控制台窗口会快速闪过并立刻消失。 如果启动时Apache检测到比如httpd.conf文件中有不正确的设置这样的问题，则控制台窗口会保持可见。 这样将显示一个有助于追踪错误原因的错误信息。

  Windows 95/98 不支持NET START或者NET STOP命令，因此你在命令中必须使用Apache的服务控制选项。 你可能希望为每个命令设置一个快捷方式以便你能够只需要从开始菜单或者桌面一点就能执行所需的操作。

  Apache和Windows 95/98 没有提供让Apache服务以特定的具有网络权限的用户身份运行的支持。 实际上，Windows 95/98 在本地机器上根本没有提供安全性。这就是Apache软件基金会从不支持使用Windows 95/98 作为公用httpd服务器的原因。这个便利存在的唯一目的是协助用户开发web内容和学习Apache服务器，或者也许在一个安全的、私有的网络上充当intranet服务器。

  

  安装的测试

  启动Apache运行以后(不管是控制台窗口还是作为服务)， 它会在80端口上进行监听(除非你改变了配置文件中的Listen指令。 要连接到服务器访问默认页面，启动一个浏览器并输入下列URL:

  http://localhost/

  应该出现一个欢迎页面作为应答，并且页面上有到Apache用户手册的链接。 如果什么都没有发生或是得到了一个错误，检查logs文件夹中的 error_log文件。如果你的主机没有联网，你也许需要输入这样的URL:

  http://127.0.0.1/

  一旦你的基本配置可以工作了，你应该编辑conf目录下的文件来恰当地配置Apache。 此外，如果你改变了作为NT服务运行的Apache的配置， 你应该首先尝试从命令行启动来保证能够无错地启动Apache服务。

  因为Apache 不能 与其他TCP/IP应用程序共享同一个端口， 你可能需要先停止或者卸载某些特定的服务。这包括(但不限于) 别的web服务器和BlackIce那样的防火墙。如果你只能在禁止其他服务的情况下启动Apache， 那么需要重新配置Apache或者其他程序使它们不监听同一个TCP/IP端口。

作为新一代的开源版本控制工具，Subversion 以其目录版本化、原子提交、版本化的元数据、更加有效的分支和标签等优良特性，正逐渐受到开源软件社区的重视，并有望取代 CVS，成为开源软件开发中版本控制的首选系统。在服务器端，Subversion 最大的独特之处，在于它可以通过一个扩展模块与 Apache 的 HTTP 服务器相结合，实现很多高级的管理功能和安全特性。与 CVS 相比，Subversion 实现了更加先进和安全的用户认证功能。在 Apache 的支持下，用户可以通过 HTTP 协议访问版本库，管理员可以对用户访问 HTTP 的权限做出具体的设置，同时 Subversion 还可以获得 SSL 传输加密，用户数据加密，以及目录级的访问控制等特性。

本文将在服务器端配置工作的角度，结合作者在实际开发工作当中的配置实例，介绍 Subversion 服务器端的基本配置和管理，以及如何将 Subversion 与 Apache 结合，实现一些高级管理功能。

Subversion 简介

在开源软件的开发过程当中，由于开发方式自由和开发人员分散这些特性，版本控制问题一直是关系到项目成败的重要问题。没有版本控制系统的支持，开源软件的开发过程就是混乱和不可控制的。

长期以来，CVS 作为一种普遍采用的开源版本控制工具，在很多的开源软件项目当中充当了重要的角色。在 Eclipse 当中，更是把 CVS 作为一个默认的插件，与 Ant，JUnit 等工具并列在一起，成为 Eclipse 软件开发的基本工具。近年来，随着开源社区的发展，一种功能更加强大的开源版本控制工具逐渐进入了人们的视野，那就是 Subversion，凭借着更为优秀的特性，Subversion 正在逐步取代 CVS，成为新一代的开源版本控制工具。

相比 CVS，Subversion 中的目录、文件以及改名等元数据都是被版本化的，例如文件的改名、拷贝等等操作；而且，在 Subversion 中，提交操作是不可分割的，修订版本号是基于每次提交操作而非文件；另外，Subversion 可以独立运行，有着轻量级的分支（Branching）与标签（Tagging）操作，版本库可以采用数据库（Berkeley DB）或者是使用特定格式的文件进行存储，对二进制文件进行处理更为有效；最后，Subversion 工具以及相关插件都有着很好的国际化支持，可以支持包括简体中文在内的多种语言版本，方便全球各地的开发人员。这些优秀的新特性，使得 Subversion 成为开源社区目前的最佳选择。

对于普通用户，即应用程序开发者而言，尤其是对 Eclipse 的用户而言，Subversion 的使用十分的简单。通过官方提供的 Eclipse 插件 Subclipse，用户可以在 Eclipse 里面很方便的使用 Subversion 客户端的各项基本功能。具体的客户端设置和使用方法，请参考 Subversion 官方网站和 Subclipse 官方网站。简单说来，在 Eclipse 中使用 Subversion 插件的基本功能，如更新、提交、同步、分支等等，基本上同使用 Eclipse 自带的 CVS 插件一模一样，这样，用户就可以从 CVS 方便的转移到 Subversion。

目前，Subversion 已经升级到 1.3.2 版本，相关下载、特性说明和详细使用手册可以在 Subversion 主页上找到。

简单的版本库管理

有了简单易用的客户端，大部分的用户都可以轻松使用 Subversion 了，不过，作为服务器端的管理人员，还必须进一步了解服务器端的基本配置管理，才可以充分利用 Subversion 的各项优秀特性。

版本库创建

Subversion 的版本库（repository），就是位于服务器端，统一管理和储存数据的地方。本文中，我们以 Linux 为例，介绍在服务器端配置和管理 Subversion 版本库的基本方法。

要创建一个版本库，首先要确定采用哪种数据存储方式。在 Subversion 中，版本库的数据存储有两种方式，一种是在 Berkeley DB 数据库中存放数据；另一种是使用普通文件，采用自定义的格式来储存，称为 FSFS。

两种存放方式各有优缺点，读者可以参考 http://svnbook.org/ 上面的文档来了解两者详细的比较和区别，这里，我们仅引用上述文档当中的简单对照表，给出一个简明的比较。

确定了具体的数据存储类型，只要在命令行当中执行 svnadmin 命令就可以创建一个 Subversion 版本库，命令如下

# 创建文件夹
            $ mkdir /etc/svn/
            $ mkdir /etc/svn/repos
            # 运行创建版本库的命令，指定数据存储为 FSFS，如果要指定为 Berkeley DB，则将 fsfs 替换为 bdb
            $ svnadmin create --fs-type fsfs /etc/svn/repos
            

如果一切正常，命令执行后不会有任何反馈信息而迅速返回，这样，一个新的版本库就被创建出来了。我们来查看一下生成的版本库结构：

$ ls -l /etc/svn/repos
            总用量 56
            drwxrwxr-x  2 robert robert 4096  8月 27 17:27 conf
            drwxrwxr-x  2 robert robert 4096  8月 27 17:27 dav
            drwxrwsr-x  5 robert robert 4096  8月 27 17:27 db
            -r--r--r--  1 robert robert    2  8月 27 17:27 format
            drwxrwxr-x  2 robert robert 4096  8月 27 17:27 hooks
            drwxrwxr-x  2 robert robert 4096  8月 27 17:27 locks
            -rw-rw-r--  1 robert robert  229  8月 27 17:27 README.txt
            

其中，conf 目录下存放了版本库的配置文件，包括用户访问控制和权限控制等内容，文件本身的注释说明十分详细，读者可以根据注释自行配置；dav 目录是提供给 Apache 相关模块的目录，目前为空；db 目录下存放着 Subversion 所要管理的所有受版本控制的数据，不同的存储方式（Berkeley DB 或者 FSFS）下有着不同的目录结构，不过我们一般不用直接修改和查看这个目录下的内容，Subversion 的命令可以安全的操作这个目录；另外，hooks 目录存放着钩子脚本及其模版（一种版本库事件触发程序），locks 目录存放着 Subversion 版本库锁定数据，format 文件记录了版本库的布局版本号。

项目添加

有了新建的版本库，就可以往里面添加项目了。不过，管理员必须考虑的问题是，应该将每一个项目分别放在不同的版本库里面，还是应该将它们放在统一的版本库里面。统一的版本库可以让管理员更加容易的升级和备份，不过，由于访问权限控制是针对整个版本库的，所以，统一的版本库也为不同项目配置不同的访问权限带来了麻烦。所以，管理员应该根据实际情况权衡考虑。

我们以统一的版本库为例，添加两个项目 project_luni 和 project_test。要做到这个，最好的办法就是用 svn import 命令导入已有的目录树。

首先，我们在一个临时目录下，根据 Subversion 版本控制的一般布局结构，创建出两个项目的主要目录树，如下：

/etc/svn/tmp
            |
            ――project_luni
            |	|
            |	――branches
            |	|
            |	――tags
            |	|
            |	――trunk
            |
            ――project_test
            |
            ――branches
            |
            ――tags
            |
            ――trunk
            

然后，用 svn import 命令来进行项目的导入：

$ svn import /etc/svn/tmp/ file:///etc/svn/repos/ --message "init"
            新增           /etc/svn/tmp/project_test
            新增           /etc/svn/tmp/project_test/trunk
            新增           /etc/svn/tmp/project_test/branches
            新增           /etc/svn/tmp/project_test/tags
            新增           /etc/svn/tmp/project_luni
            新增           /etc/svn/tmp/project_luni/trunk
            新增           /etc/svn/tmp/project_luni/branches
            新增           /etc/svn/tmp/project_luni/tags
            提交后的修订版为 1。
            

版本库查看

作为版本库管理员，我们经常需要查看 Subversion 版本库的状况，这就需要一些“只读”的查看工具。

在上述项目导入完成以后，我们可以用 svn list 确认导入的项目是否正确：

$ svn list --verbose file:///etc/svn/repos/
            1 robert                 8月 27 18:24 project_luni/
            1 robert                 8月 27 18:24 project_test/
            

另外，如果要查看最新修订版本的信息，可以使用 svnlook info 命令：

$ svnlook info /etc/svn/repos/
            robert
            2006-08-27 18:24:27 +0800 (日, 27  8月 2006)
            0
            

命令输出了这个版本库的最新修订版本信息，包括作者、时间、日志字数和日志内容等。除开最新修订版以外，我们还可以在命令后面接上 “--revision 版本号” 来指定某一个修订版的显示。

另外，我们还可以用如下命令来显示版本库的具体树形结构，后面的 “--show-ids” 选项指定显示每一个显示元素的修改版本 ID。

$ svnlook tree /etc/svn/repos/ --show-ids
            / <0.0.r1/1007>
            project_test/ <1.0.r1/333>
            trunk/ <2.0.r1/0>
            branches/ <3.0.r1/74>
            tags/ <4.0.r1/152>
            project_luni/ <5.0.r1/793>
            trunk/ <6.0.r1/454>
            branches/ <7.0.r1/530>
            tags/ <8.0.r1/609>
            

其他

这里有一个需要新手，尤其是习惯了 Subversion 客户端命令 “svn” 的用户注意的问题，那就是，“svnadmin” 和 “svnlook” 都被认为是服务器端的管理工具，只被用于版本库所在的机器，用来检查和维护版本库，不能通过网络来执行任务。所以，试图将 URL 甚至本地 file 路径传递给这两个程序，都是错误的。

Subversion 还有很多管理工具可供管理员应用，需要了解这项工具的使用方法，读者们可以用 svn help, svnadmin help, svnlook help 等等命令查看帮助信息，另外，Subversion 参考手册提供了更为全面和详细的使用介绍。

基本的服务器配置

Subversion 设计了一个抽象的网络层，版本库建立完毕之后，可以通过各种服务器向外公布。svnserve 是 Subversion 自带的一个小型的服务器，它使用独立的协议与客户端。我们可以通过

svnserve –i
            

作为 inetd 启动或者

svnserve –d
            

作为守护进程启动一个服务。服务器启动后，客户端即可以通过绝对路径访问。如上例可以访问 svn://服务器IP/etc/svn/repos。同时可以指定一些选项，常用的如 -r，用来指定版本库的根路径，例如假设版本库位于 /etc/svn/repos：

svnserve –d -r /etc/svn

则客户端可以通过如下 URL 访问服务器：svn://服务器IP/repos， 这样可以有效的避免暴露本地路径。另外如 --listen-port，--listen-host 可以指定绑定的地址和端口，-R 可以强制设定为 Read-Only 模式。如果在 Windows 操作系统下，可以将版本库设定在 C 分区，如 c:\svnroot\repos 可以通过 svn://服务器IP/svnroot/repos访问，如果在其他分区，就必须要通过 -r 选项来指定 root 位置。

svnserve 可以通过配置 svnserve.conf 来进行一些简单的访问权限控制。你可以在版本库的 conf 子文件夹下发现这个文件。文件的初始内容大致如下：

[general]
            # anon-access = read
            # auth-access = write
            password-db = passwd
            # authz-db = authz
            # realm = My First Repository
            

其中 anon-access 表示匿名用户的权限，auth-access 表示认证用户的权限设置，password-db 指向保存用户帐号密码的文件的位置，可以使用相对路径。svnserve 只能对全局提供简单的访问控制，如果想要更加灵活的方式，可以使用 Apache Http Server 作为向外公布版本库的方式。

与 Apache Http Server 的结合

通过 Http 协议访问版本库是 Subversion 的亮点之一。使用 Http 协议意味着只需要打开浏览器，输入 URL 即可轻松的浏览整个版本库。灵活通常带来复杂性，Http 方式相对于 svnserve 方式来说需要更多的配置。

由于 Subversion 需要版本化的控制，因此标准的 Http 协议不能满足需求。要让 Apache 与 Subversion 协同工作，需要使用 WebDAV（Web 分布式创作和版本控制）。WebDAV 是 HTTP 1.1 的扩展，关于 WebDAV 的规范和工作原理，可以参考 IETF RFC 2518。

为了使 Subversion 与 dav 模块通信，需要安装 mod_dav_svn 插件，可以在 Subversion 的安装目录中找到。将其拷贝到 Apache 安装目录的 modules 文件夹下。接下来就是配置 Apache 的 httpd.conf 文件，让 Apache 在启动的时候加载上述模块。

需要添加的内容如下：

LoadModule dav_module modules/mod_dav.so
            LoadModule dav_svn_module modules/mod_dav_svn.so
            <Location /repos>
            DAV svn
            SVNPath /etc/svn/repos
            </Location>
            

首先需要启用 dav_module，然后加载 dav_svn_module。Location 标签指出访问的 URL 以及在服务器上的实际位置。配置完毕后重新启动 Apache，打开浏览器，输入 http://服务器IP/repos 将会看到如下画面：

这表示 Apache 的 dav_svn 模块已经可以正常工作了。用户可以使用任何一种 Subversion 的客户端通过 Http 协议访问你的版本库。

如果想要指定多个版本库，可以用多个 Location 标签，也可以使用 SVNParentPath 代替 SVNPath，例如在 /etc/svn 下有多个版本库 repos1，repos2 等等，用如下方式指定：

<Location /repos>
            DAV svn
            SVNParentPath /etc/svn
            </Location>
            

"SVNParentPath /etc/svn" 表示 /etc/svn 下的每个子目录都是一个版本库。可以通过 http://服务器IP/repos/repos1，http://服务器IP/repos/repos2 来访问。

现在你的版本库任何人都可以访问，并且有完全的写操作权限。也就是说任何人都可以匿名读取，修改，提交，以及删除版本库中的内容。显然大部分场合这是不符合需求的。那么如何进行权限设置呢，Apache 提供了基本的权限设置：

首先需要创建一个用户文件。Apache 提供了一个工具 htpasswd，用于生成用户文件，可以在 Apache 的安装目录下找到。具体使用方法如下：

htpasswd etc/svn/passwordfile username
            

如果 passwordfile 不存在，可以加上 -c 选项让 htpasswd 新建一个。创建好的文件内容是用户名加上密码的 MD5 密文。

接下来修改 httpd.conf，在 Location 标签中加入如下内容：

AuthType Basic
            AuthName "svn repos"
            AuthUserFile /etc/svn/passwordfile
            Require valid-user
            

重新启动 Apache， 打开浏览器访问版本库。Apache 会提示你输入用户名和密码来认证登陆了，现在只有 passwordfile 文件中设定的用户才可以访问版本库。也可以配置只有特定用户可以访问，替换上述 "Require valid-user" 为 "Require user tony robert" 将只有 tony 和 robert 可以访问该版本库。

有的时候也许不需要这样严格的访问控制，例如大多数开源项目允许匿名的读取操作，而只有认证用户才允许写操作。为了实现更为细致的权限认证，可以使用 Limit 和 LimitExcept 标签。例如：

<LimitExcept GET PROPFIND OPTIONS REPORT>
            require valid-user
            </LimitExcept>
            

如上配置将使匿名用户有读取权限，而限制只有 passwordfile 中配置的用户可以使用写操作。如果这还不能满足你的要求，可以使用 Apache 的 mod_authz_svn 模块对每个目录进行认证操作。

用 mod_authz_svn 进行目录访问控制

首先需要让 Apache 将 mod_authz_svn 模块加载进来。在 Subversion 的安装目录中找到 mod_auth_svn 模块，将其拷贝到 Apache 安装目录的 modules 子目录下。修改 httpd.conf 文件，找到

LoadModule dav_svn_module modules/mod_dav_svn.so
            

在其后面加上

LoadModule authz_svn_module modules/mod_authz_svn.so
            

现在可以在 Location 标签中使用 authz 的功能了。一个基本的 authz 配置如下：

<Location /repos>
            DAV svn
            SVNPath /etc/svn/repos
            AuthType Basic
            AuthName "svn repos"
            AuthUserFile /etc/svn/passwd
            AuthzSVNAccessFile /etc/svn/accesspolicy
            Satisfy Any
            Require valid-user
            </Location>
            

AuthzSVNAccessFile 指向的是 authz 的策略文件，详细的权限控制可以在这个策略文件中指定，如：

#两个分组：committers，developers
            [groups]
            committers = paulex richard
            developers = jimmy michel spark sean \
            steven tony robert
            #在根目录下指定所有的用户有读权限
            [/]
            * = r
            #追加 committers 组用户有读写权限
            @committers = rw
            #在 branches/dev 目录下指定 developers 组的用户有读写权限
            [/branches/dev]
            @developers = rw
            #在 /tags 组下给予用户 tony 读写权限
            [/tags]
            tony = rw
            #禁止所有用户访问 /private 目录
            [/private]
            * =
            #给 committers 组用户读权限
            @committers= r
            

使用 SVNParentPath 代替 SVNPath 来指定多个版本库的父目录时，其中所有的版本库都将按照这个策略文件配置。例如上例中 tony 将对所有版本库里的 /tags 目录具有读写权限。如果要对具体每个版本库配置，用如下的语法：

[groups]
            project1_committers = paulex richard
            project2_committers = jimmy michel spark sean \
            steven tony robert
            [repos1:/]
            * = r
            @ project1_committer = rw
            [repos2:/]
            * = r
            @ project2_committer = rw
            

这样项目1的 committer 组只能对 repos1 版本库下的文件具有写权限而不能修改版本库 repos2，同样项目2的 commiter 也不能修改 repos1 版本库的文件。

用 MySQL 代替文件形式存放密码

到目前为止我们的用户名密码文件还是以文本文件形式存放在文件系统中的，出于安全性的需要或者单点登陆等可扩展性的考虑，文本文件的管理方式都不能满足需求了。通过 Apache 的 module_auth_mysql 模块，我们可以用 MySQL 来保存用户信息。该模块的主页在 http://modauthmysql.sourceforge.net/，你也可以在 http://modules.apache.org/ 找到它的发行版本。安装方法同上述 Apache 的模块一样，拷贝至 modules 目录并在 httpd.conf 文件中添加如下语句：

LoadModule mysql_auth_module modules/mod_auth_mysql.so
            

相应的 Location 区域改写为：

<Location /repos>
            AuthName "MySQL auth"
            AuthType Basic
            AuthMySQLHost localhost
            AuthMySQLCryptedPasswords Off
            AuthMySQLUser root
            AuthMySQLDB svn
            AuthMySQLUserTable users
            require valid-user
            </Location>
            

然后在 mysql 中添加名为 svn 的数据库，并建立 users 数据表：

create database svn;
            use svn;
            CREATE TABLE users (
            user_name CHAR(30) NOT NULL,
            user_passwd CHAR(20) NOT NULL,
            user_group CHAR(10),
            PRIMARY KEY (user_name)
            );
            

在 users 表中插入用户信息

insert into users values('username','password','group');
            

重新启动 Apache，在访问版本库的时候 Apache 就会用 mysql 数据表中的用户信息来验证了。

用 SSL 实现安全的网络传输

通过 Apache 的网络链接，版本库中的代码和数据可以在互联网上传输，为了避免数据的明文传输，实现安全的版本控制，需要对数据的传输进行加密。Apache 提供了基于 SSL 的数据传输加密模块 mod_ssl，有了它，用户就可以用 https 协议访问版本库，从而实现数据的加密传输了。SSL 协议及其实现方式，是一个非常复杂的话题，本文只是介绍 Apache 提供的最基本的SSL配置方法，更加详细的介绍内容，请参考 http://httpd.apache.org/docs-2.0/ssl/ 上的文档。

开始配置前，我们需要一个实现 Apache 中 SSL 模块的动态程序库，通常名为 mod_ssl.so，及其配置文件，通常名为 ssl.conf。这个实现是跟 Apache 的版本相关的，不匹配的版本是不能用的；而且，并不是每一个 Apache 的版本都自带了相关实现文件，很多情况下，我们需要自己去搜寻相关文件。另外，我们还需要 OpenSSL 软件及其配置文件，来生成加密密钥和数字证书。这里，我们可以使用一些免费网站，如 http://hunter.campbus.com/ 上提供的集成版本的 Apache。

有了相关的工具和文件，我们就可以开始生成 SSL 的证书和密钥了。首先，我们需要找到 openssl 程序及其配置文件 openssl.cnf，运行如下命令来生成 128 位的 RSA 私有密钥文件

my-server.key：
            openssl genrsa -des3 -out my-server.key 1024
            Loading 'screen' into random state - done
            Generating RSA private key, 1024 bit long modulus
            .....++++++
            ........++++++
            e is 65537 (0x10001)
            Enter pass phrase for server.key:********
            Verifying - Enter pass phrase for server.key:********
            

命令运行期间需要用户输入并确认自己的密码。

现在，我们需要 SSL 的认证证书，证书是由 CA（certificate authority） 发放并且认证的。为此，我们可以用如下命令生成一个 CSR(Certificate Signing Request) 文件发给 CA，从而得到 CA 的认证：

openssl req -new -key my-server.key -out my-s erver.csr -config openssl.cnf
            

当然，一般情况下，如果 Subversion 的用户不是太多，安全情况不是很复杂，我们也可以生成一个自签名的认证证书，从而省去了向 CA 申请认证的麻烦。如下命令：

openssl req -new -key my-server.key -x509 -out my-server.crt -config openssl.cnf
            

以上两个命令都需要用户输入那个 key 文件的密码，以及一些网络设置信息，如域名，邮箱等等，这里输入的服务器域名应该与 Apache 配置文件当中的一致。现在，我们可以在 Apache 的 conf 目录下新建一个 ssl 目录，将 my-server.key 和 my-server.crt 文件都移动到 ssl 目录里面。然后修改 ssl.conf 文件，将 SSLCertificateKeyFile 和 SSLCertificateFile 项指向这两个文件。

如果 Apache 的 module 目录里面没有 mod_ssl.so 文件，可以将事先准备好的文件拷贝过去。然后，我们可以设置 Apache 的配置文件 httpd.conf，将 ssl 模块加入其中：

LoadModule ssl_module modules/mod_ssl.so
            

然后，在配置文件的最后，加上如下 SSL 相关配置项：

SSLMutex default
            SSLRandomSeed startup builtin
            SSLSessionCache none
            ErrorLog logs/SSL.log
            LogLevel info
            <VirtualHost svntest.ut.cn.ibm.com:443>
            SSLEngine On
            SSLCertificateFile conf/ssl/my-server.crt
            SSLCertificateKeyFile conf/ssl/my-server.key
            </VirtualHost>
            

这样，基本的设置工作就完成了。重新启动 Apache 服务器，现在可以用 https 协议代替 http 协议来访问版本库了。如果要限定版本库只能用 https 访问，我们可以在 Apache 配置文件当中 Subversion 部分加上 “SSLRequireSSL”。如下：

<Location /repos>
            DAV svn
            SVNPath /etc/svn/repos
            ………….#other items
            SSLRequireSSL
            </Location>
            

总结

Subversion 以其优良的版本控制功能，灵活的网络访问模型，以及与 Apache 服务器联合配置所带来的更强大的管理控制功能，逐渐在开源软件开发的实践当中得到广泛的应用。本文重点介绍了 Subversion 服务器端的配置以及与 Apache 服务器联合配置的基本步骤和简单应用，实现了简单的实例应用。读者如果想要进一步了解相关信息，请参考文章后面列出的相关资料。

　　安装设置服务端

　　Windows XP和2000本身就拥有构件SMTP服务器的功能，只是一般还没有安装。选择“控制面板→添加/删除程序→添加/删除Windows组件”，弹出“Windows组件向导”对话框，在其中双击“Internet信息服务(IIS)”项，就会打开详细选择项，选中“SMTP Service”，按“确定”，插入Windows XP安装盘进行安装(如图1)。

　　安装好SMTP服务器后，选择“控制面板→性能和维护→管理工具→Internet信息服务”打开Internet信息服务设置窗口,在窗口左侧点击本地计算机名，展开本地计算机目录，可以看到有两个分支“Wed站点”和“默认SMTP虚拟服务器”。在“默认SMTP虚拟服务器”上点击鼠标右键选择“属性”，打开“默认SMTP虚拟服务器属性”窗口。

　　“常规”选项卡主要设置IP地址，单击IP地址下拉项选择“127.0.0.1”（或者是本机IP：172.16.5.87），表示指向本地计算机IP地址，其他项使用默认即可。如果你是局域网接入，拥有固定IP地址，那么IP地址就应该选择相应的地址(如图2)。

　　“访问”选项卡中设置访问权限。单击“身份验证”，选择“匿名访问”，表示任何用户都可以发送，其他两项不用选择；单击“连接控制”中的“连接”和“中段限制”中的“中断”，选中“仅以下列表除外”，表示可以许接入所有用户的访问。

　　“邮件”选项卡中设置邮件传输条件及限制，“限制邮件大小为”等四个选项可以使用默认值，无须更改；

　　“将未传递报告的副本发送到”可将发送不成功的邮件返回发件人，并且写明不成功的原因；“死信目录”设置没有发送成功的邮件被存放的位置。

　　“传输”选项中设置邮件传递时间，这里不用修改，使用默认值；“LDAP路由”选项用来指定服务器使用的目录服务器标识和属性，这里也不用启动它。

　　“安全”选项中设置使用发送服务器的有权用户，默认用户是“Administrators”，你可以单击“添加”添加使用用户。

　　一切设置好后，你就拥护了自己的邮件发送服务器了！下面我们来看看在Outlook Express和Foxmail中如何设置使用自己的SMTP来发信。

在.net中的web.config文件需要配置成如下代码：
 <system.net>
  <mailSettings>
   <smtp from="juwan.yang@clochase.com" deliveryMethod="Network">
    <network host="172.16.5.87" port="25" defaultCredentials="false" /> 
   </smtp>
  </mailSettings>
 </system.net>
此处的host主机IP需要跟SMTP服务器中的IP配置相一致，才能发送出邮件
　　

首先，咱们来看看IIS 7.0的十大改进：

1.  更简便的命令行配置功能
2.  更强的兼容性
3.  抛弃MetaBase
4.  集中管理
5.  委任配置
6.  AppCmd 与其它新的管理手段
7.  失败请求追踪
8.  请求过滤
9.  UNC 内容支持
10.动态内容输出缓存

那么，到底Windows Vista的哪些版本支持 IIS7呢？先来看看下图：

首先安装IIS7组件

打开控制面板->程序->程序和组件，点击"打开或关闭Windows功能"弹出组件，选项容器，选中"Internet 信息服务"，点击"确定"。确认后Vista会启动安装程序，完成后要重启电脑。

接下来要把我们安装好的IIS7组件放在控制台中，便于使用。

Win键+R键打开运行窗口，输入mmc 然后回车，或者打开开始程序，在搜索样里输入"mmc"，然后回车,打开一个新的Windows控制台程序。如下所示：

在新打开的控制台中选择文件，点击"添加/删除管理单元"...

在打开"添加/删除管理单元"后我们会看到添加的IIS，选中，添加，然后点击确定。

一个IIS的控制台程序建成了，点关闭窗口时，它会提示保存，命名后确定，如下：

打开开始菜单里的管理工具,就会出现我们刚建好的“Internet 信息服务(IIS)管理器”。

点击即可,本次IIS 7安装成功！

需求管理

因业务需要，“中科永联”正式更名为“中程在线”，欢迎大家浏览新网站“中程在线信息产业培训网”

svn://proj/
|
+-trunk
+-branches
+-tags

1. 1.0开发完毕，代码冻结
2. 基于已经冻结的trunk，为release1.0打tag
   此时的目录结构为
   svn://proj/
                +trunk/  (freeze)
                +branches/
                +tags/
                        +tag_release_1.0　(copy from trunk)
   
3. 2.0开始开发，trunk此时为2.0的开发版
4. 发现1.0有bug，需要修改，基于1.0的tag做branch
   此时的目录结构为
   svn://proj/
                +trunk/  ( dev 2.0 )
                +branches/
                              +dev_1.0_bugfix (copy from tag/release_1.0)
                +tags/
                        +release_1.0　(copy from trunk)
   
5. 在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发
6. 在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等
7. 根据需要选择性的把dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）
   

1. 1.0开发，做dev1.0的branch
   此时的目录结构
   svn://proj/
                +trunk/  (不担负开发任务 )
                +branches/
                              +dev_1.0 (copy from trunk)
                +tags/
   
2. 1.0开发完成，merge dev1.0到trunk
   此时的目录结构
   svn://proj/
                +trunk/  (merge from branch dev_1.0)
                +branches/
                              +dev_1.0 (开发任务结束，freeze)
                +tags/
   
3. 根据trunk做1.0的tag
   此时的目录结构
   svn://proj/
                +trunk/  (merge from branch dev_1.0)
                +branches/
                              +dev_1.0 (开发任务结束，freeze)
                +tags/
                        +tag_release_1.0 (copy from trunk)
   
4. 1.0开发，做dev2.0分支
   此时的目录结构
   svn://proj/
                +trunk/ 
                +branches/
                              +dev_1.0 (开发任务结束，freeze)
                              +dev_2.0 （进行2.0开发）
                +tags/
                        +tag_release_1.0 (copy from trunk)
   
5. 1.0有bug，直接在dev1.0的分支上修复
   此时的目录结构
   svn://proj/
                +trunk/ 
                +branches/
                              +dev_1.0 (1.0bugfix)
                              +dev_2.0 （进行2.0开发）
                +tags/
                        +tag_release_1.0 (copy from trunk)
   
6. 选择性的进行代码merge

[HostingEnvironmentException: Failed to access IIS metabase.]
   System.Web.Configuration.MetabaseServerConfig.MapPathCaching(String siteID, VirtualPath path) +3500426
   System.Web.Configuration.MetabaseServerConfig.System.Web.Configuration.IConfigMapPath.MapPath(String siteID, VirtualPath vpath) +9
   System.Web.Hosting.HostingEnvironment.MapPathActual(VirtualPath virtualPath, Boolean permitNull) +163
   System.Web.CachedPathData.GetConfigPathData(String configPath) +382
   System.Web.CachedPathData.GetConfigPathData(String configPath) +243
   System.Web.CachedPathData.GetApplicationPathData() +68
   System.Web.CachedPathData.GetVirtualPathData(VirtualPath virtualPath, Boolean permitPathsOutsideApp) +3393747
   System.Web.Configuration.RuntimeConfig.GetLKGRuntimeConfig(VirtualPath path) +189

C:\WINNT\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis.exe -i