以QTP 11.00自带的订飞机票的小示例程序为例，手工开发以下脚本代码：
If Dialog("Login").Dialog("Flight Reservations").Exist(2)Then
Dialog("Login").Dialog("FlightReservations").WinButton("确定").Click
End If
Dialog("Login").WinEdit("Agent Name:").Set "test"
Dialog("Login").WinEdit("Agent Name:").Type micTab
Dialog("Login").WinEdit("Password:").SetSecure"5103f48e3ccaaa3c50b39191d30cc0e56ac005b2"
Dialog("Login").WinEdit("Password:").Type micReturn
If Window("Flight Reservation").Exist(5) Then
Wait(3)
End If
Window("Flight Reservation").ActiveX("MaskEdBox").Type"013113"
Window("Flight Reservation").WinComboBox("Fly From:").Select"Denver"
Window("Flight Reservation").WinComboBox("Fly To:").Select"Paris"
Window("Flight Reservation").WinButton("FLIGHT").Click
Window("Flight Reservation").Dialog("FlightsTable").WinList("From").Select"15791 DEN 03:12PM PAR 05:12PM AF $165.60"
Window("Flight Reservation").Dialog("FlightsTable").WinButton("OK").Click
Window("Flight Reservation").WinEdit("Name:").Set "bussiness"
Window("Flight Reservation").WinButton("Insert Order").Click
msgbox "Finished! Program will exit!"
Window("Flight Reservation").Close |
首先是要判断主界面是否正常，如果Help按钮被点击过了，则先恢复它。
用户名和密码输入完成之后，因为不同的机器性能表现不同，为了脚本达到同步，检查软件主界面是否加载成功，未成功时等待3秒再判断，直到成功再进入下一步。
完成之后输出提示信息，在用户确认之后再关闭程序。
好了，最主要的调整就到这里了，下一步也就是最关键的步骤，就是参数化了。下期发布。
引言
说到软件项目的质量管理，首先要弄清楚什么是质量管理。国际标准组织ISO9000对质量的定义就是：质量是产品或服务用于满足人们潜在或明示的需求的所有特征和性能的总和。
软件项目的质量管理就是确定软件项目的质量方针、目标和职责，并通过质量规划、质量保证、质量控制和改进等工作确保软件项目的质量得以实现的全部管理活动的总称。
怎样才能做好软件项目的质量管理呢？我们要在理解现代软件项目的质量管理的理念的基础上，使软件项目的质量管理具有可操作性和可衡量性。
现代软件项目的质量管理的理念包括：
①顾客满意：就是我们的交付件(本文指软件)要满足客户的期望；
②预防胜于检查：质量管理的重点在事前的预防，而不是事后的检查；
③管理层责任；
④持续改进：软件项目的质量管理是一个持续改进的过程。
即使我们理解了现代质量管理的理念，达到质量管理所要求的高度，我们在实际操作中，还需要理论联系实际。这就要求软件项目的质量管理具有更强的可操作性和可衡量性，为此将软件的质量定义为达到要求(Conformance to Requirements)和适合使用(Fitnessof Use)两个层面。也就是说，软件项目的项目工作要提交出原来所要求的、具有实际用途的软件产品。简单地说，软件项目的质量管理就是产出的软件，满足客户明确需求、隐含需求的能力的所有特性。在现实生活中，监控所有对质量有影响的关键点，采用有效的测量手段来管理软件的质量，从而实现软件项目的“高”质量。
1 质量管理的流程总述
一般软件项目可分为启动、规划、执行、监控和收尾五个部分。其中质量管理涉及到规划、执行、监控三个部分。软件的质量管理包括质量规划、实施质量保证、实施质量控制三个部分。
质量规划在软件项目的规划过程组中；实施质量保证在软件项目的执行过程组中；实施质量控制在软件项目的监控过程组中。他们之间的关系并不是相互独立的，而是相互作用，相互影像的。
在软件项目的质量管理中，质量规划就是判断哪些质量标准与本项目相关，并决定应如何达到这些质量标准。它是软件的项目管理计划的一部分，一般在项目的规划时处理。
软件项目的质量保证是指质量系统内实施了计划的、系统的活动；同时为项目满足所有项目利益相关方的要求提供信心，相对于内部的质量控制，质量保证可以说是对外的，它包含：
①涉及整体项目、提高信心；
②涉及经验教训总结/质量审计；
③重新评价质量标准是否合适；
④实施阶段。
软件项目的质量控制是在项目生命周期的几个关键点上进行的，它决定了项目进行的方式并进行了必要的纠正。质量控制是质量保证的输出，它考虑了项目的效果和效率。
它通常包含：
①涉及项目的具体工作成果(软件，开发过程中的文档等)；
②涉及到具体工作成果是否可以被接受；
③检查具体工作成果是否符合相关质量标准；
④监控阶段。下面将介绍软件项目中质量管理的各个流程。
2 软件项目的质量管理流程
1·1 质量规划
从前文可知，软件项目的“高”质量来自于“好”的计划。只有一个好的质量规划，才有可能产出高质量的产品。质量规划既然如此重要，那如何做才能制定一个“好”的软件项目的质量规划呢？
制定软件项目的质量规划，依据的是公司的质量方针。公司的质量方针是“由最高层管理部门正式阐明的、组织关于质量的总的打算与努力方向”。由此可见，质量管理是最高层责任。
项目质量规划的目的都是为了产出“高”质量的产品。那么怎样衡量软件项目质量的高低呢？我们主要的手段是将软件项目的质量和其质量基准进行对照。基准对照是将软件项目的实际做法或计划做法与其他项目的做法进行对照，从中萌生出如何改进思路，或者提供一项量度的标准。
1·2实施质量保证
质量保证指通过实施计划中的系统质量活动，确保项目实施满足要求所需的所有过程。
质量保证的内容有：
①清晰的软件质量要求说明(包含在软件的需求分析和范围说明书中)；
②科学可行的质量标准；
③建立和健全软件项目质量体系；
④配备合格和必要的资源；
⑤持续开展有计划的质量改进活动；
⑥项目变化全面控制。
1·3实施质量控制
实施质量控制指监视软件项目的具体结果，确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源。
软件项目的质量控制包括两项内容：
①监控具体的交付软件，以确定他们是否与相关质量标准一致；
②确定消除造成不满意结果的影响因素。
其中“结果”也包含两项：
①产品结果(交付的软件)；
②项目管理结果(成本与进度计划执行绩效)。实施软件项目的质量控制，就必须实施质量监控。
如何对质量进行有效的监控呢？有如下几条原则：
①监控工作对事不对人；②监督与服务相结合；③采用结构化的监控方法；④制定合理基线；⑤动态持续监控；⑥监控信息交流；⑦采取必要的变更和纠偏行动。
在质量监控的原则上，我们对软件项目的质量实施控制。
质量控制主要有以下步骤：
①收集质量数据；②整理数据；③统计分析；④判断质量状况；⑤分析原因；⑥拟定措施。
再严格的质量保证，质量控制都会有变更的情况出现。
质量变更方法有如下几种：
①利用质量保证，检查质量标准的有效性，如必要，重复进行质量计划；
②利用质量控制，检查项目成果质量，如必要重复进行质量计划；
③利用边际分析：对单位质量改进能够产生的效益增加和需要支付的成本增加的分析。
最佳的质量应该是效益增加和成本增加相等时的质量。对于软件项目的质量变更，事前判断质量的成本，然后才决定是否变更。软件项目的质量成本包含多个方面，它不仅包括预防成本，评估成本，还包括内部缺陷成本和外部缺陷成本。
对于软件项目的质量成本，在实际处理中我们可 以通过提高符合成本来降低不符合成本，实现质量总成本的降低。
2 实际处理过程
理论很容易学会，但是理论联系实际一直都是一个问题。下面我们将从六个方面说明软件项目的质量管理。其中第一、二、三为质量规划部分，第四为实施质量控制部分，第五条为实施质量保证部分。第六条贯穿质量管理的全过程。
(1)确定交付物的质量特性。
①软件产品的“质量”很大程度上是由其设计确定的；
②并非所有软件过程中的设计细节都可以进行质量控制；
③软件的功能系指软件完成自身工作的“好坏”程度。
(2)选择各个软件项目的质量特性的测量指标。
要控制软件项目的质量，所确定的特性必须是可以测量的。如证券软件的委托笔数在一定客户量下每秒能达到的性能等指标。
(3)设定各个软件项目的质量特性的指标。
对所确定的软件项目的质量特性指标要建立一个质量标准作为评价标准。这就涉及两个方面：①标准的可行性：并不是所有质量管理的标准都适用于软件项目，标准是否可行可从三个方面进行考量：与顾客期望比较；与同行比较；与历史比较等；②成本制约应是：无论对顾客还是我们，都必须要考虑软件项目的成本和进度等问题。
(4)根据这些标准对软件项目的质量进行控制。
设定标准后质量控制部门的任务就是对软件进行检验测试，看它们是否符合标准。现代质量管理的理念是质量是管理层责任。那么管理层该采取哪些措施来避免重大责任的发生呢？
以下以项目经理为例来进行阐述管理层应采取的措施。在软件项目中，项目经理有三个职责(工作方向)可以提高软件的质量：
1)在运作系统的什么位置上检验？项目经理在软件开发过程中设定关键控制点(包括但不限于里程碑)：即进行检验以保证软件符合规范的位置：开发前、开发中、开发后。
项目经理设立检查点的基本原则是：
①在一个业务逻辑特别复杂的流程开始之前；
②在与其他软件系统进行对接前；
③在一个模块功能完成前；
④在潜在的损害、破坏可能发生前；
⑤在责任发生转移前。
2)检验的方法。在软件项目中，一般采用测试软件来模拟一定的环境对软件进行测试，例如压力测试等，通过测试来达到检验软件的目的。
2·1产品审计计划
(1)在实际项目中，质量管理人员依据剪裁后的项目过程表(含工作产品)、项目计划，制定项目的《质量保证计划》，在计划中列出质量管理人员需要审计的产品、审计活动的时间，以及需要参照的标准。
(2)在实际项目中，审计的工作产品一般包括：业务需求说明书、需求分析说明书、项目计划、概要设计说明书、单元测试报告、测试用例、测试计划和配置管理计划等。
2·2过程审计计划
(1)在实际项目中，质量管理人员根据剪裁后的项目过程表(含过程元素)、项目计划，制定项目的《质量保证计划》，在计划中列出需要审计的过程活动、审计活动的时间、需要参照的标准。审计活动的时间根据具体项目的活动时间确定。
(2)在实际项目中，审计的过程包括管理过程、开发过程、支持过程。过程活动一般包括：立项管理活动、需求管理活动、项目策划活动、项目监控活动、收尾管理活动、软件工程产品活动、同行评审活动、里程碑评审活动、配置管理活动、培训活动、度量与分析。
(3)组织级相关活动包括：组织培训活动、项目工作量度量(即周计划制定与项目时间填写)、组织级配置管理活动、过程改进(如PMO会议)。审计时机：定期(一般每两周或每月一次)。
3 结语
对软件项目进行质量管理，首先需要知道企业的质量方针；在企业的质量方针下制定详细的质量规划。在制定完质量规划后，要让软件项目的质量管理具有可操作性和可衡量性。同时我们需要牢记，任何类型的质量管理过程，都是一个持续改进的过程，需要不断变更。
现代软件项目的质量管理的思路是：加大前期预防成本的投入，减少后期缺陷成本的支出，从而实现“质量免费”。
很多同学，都跟赵容一样，盲目的买进一些VPS，买到了也基本没有测试下VPS的性能，所以，今天我就把几个简单的VPS性能测试（也可以说是查看）命令发出来，大家参考下（新手参考，老鸟请勿见笑）
1.top
Top命令显示了实际CPU使用情况，默认情况下，它显示了服务器上占用CPU的任务信息并且每5秒钟刷新一次。你可以通过多种方式分类它们，包括PID、时间和内存使用情况。
第一行的load average即为系统负载，就是说整个VPS资源占用情况，如果正常建站，一般很少有超过5的时候；
第三行的，这个是CPU占用资源。还有后面的？？%wa这个是硬盘状态，正常情况下CPU最好不要超过30%占用.wa指数长期30%以上，基本上硬盘就是不给力状态。
第四行是内存，总内存，已使用内存，空闲内存。我这里是W2的VPS，内存为1GB，大家可以参考下。
2.查看CPU，硬盘和内存信息
命令：cat /proc/cpuinfo（CPU信息）
cat /proc/meminfo（内存信息）
df –lh（查看硬盘信息）
这些，都只是简单的查看VPS的参数，我就不截图了。
3.下载测试
命令：wget http://cachefly.cachefly.net/100mb.test
图中有下载速率，我这个是W2的，下载超级不给力，大致上，如果你是100MB端口的话，应该7-10m/s，10MB端口的话，也有1m/s左右了。
4.磁盘I/O测试
命令：dd if=/dev/zero of=test bs=64k count=16k oflag=dsync
这个命令，是测试磁盘I/O性能的，图中有磁盘写入速率，可以作为参考。
或者使用此命令：dd if=/dev/zero of=test bs=64k count=4k oflag=dsync
【小提示】其实正常做站，这个DD值不必过于纠结，只要不是低得离谱都没有很大的差异，赵容本人也在DD值不到1M/s的VPS做了很久的站。
SSD磁盘用这个命令：hdparm -t /dev/xvda
经过上面两步测试，磁盘多出了2个文件：100mb.test,test，我们用命令删除它们。
rm 100mb.test rm test
5.UBI跑分综合性能测试
命令：wget http://www.CTOHome.com/linux-vps-pack/unixbench.sh;sh./unixbench.sh;
这个命令运行的时间比较久，因为好多VPS都是赵容借来半小时看看简单性能的，所以一般没有做这项测试。这个测试完成后的综合分数也可以看出一个VPS的性能：一般高于400分就算正常水准，如果高于1000的话，就是非常给力。
6.其他测试命令
命令：iostat （磁盘和内存使用率）
命令：Vmstat （进程、内存、页面I/O块和CPU等信息的监控）
一.官网下载方法
1.1 官网下载JDKDK
官方下载地址：http：//www.Oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html
找到对应系统的下载
1.2 版本区别
这里简单地阐述一下rpm、tar.gz的区别。
1.2.1 rpm格式的软件包适用于基于Red Hat发行版的系统，如Red Hat Linux、SUSE、Fedora. 类似地，
1.2.2 deb格式的软件包则是适用于基于Debian发行版的系统，如Debian、Ubuntu、Mint.
1.2.3 tar.gz格式只是一个压缩包，里面一般是源码，因此只要使用tar命令或解压软件解压到相应路径就可以了。如果使用的是Ubuntu amd64，故选择jdk-7u11-linux-x64.tar.gz，下载后解压到了/usr/lib/java/目录下（需要root权限）。
1.3 JDK变量配置
JDK环境变量配置如下：
执行命令sudo gedit /etc/environment，在打开的编辑器中PATH变量上面两行新建两个变量，
JAVA_HOME="/usr/lib/java/jdk1.7.0_11"
CLASSPATH=".：$JAVA_HOME/lib/tools.jar：$JAVA_HOME/lib/dt.jar" |
在PATH中添加$JAVA_HOME/bin，注意与PATH原有的值之间用英文冒号：分隔，切勿把原来的值删除。
然后保存关闭，使用命令source /etc/envrionment更新。
Ubuntu系统默认安装并使用OpenJDK(usr/lib/jvm/)，因此需要手动修改系统默认的JDK，
sudo update-alternatives --install /usr/bin/javac javac /usr/lib/java/jdk1.7.0_11/bin/javac 300
sudo update-alternatives --install /usr/bin/java java /usr/lib/java/jdk1.7.0_11/bin/java 300
sudo update-alternatives --config javac，再选择相应的Priority 300
sudo update-alternatives --config java，再选择相应的Priority 300
至此配置完成，输入java -version、javac或java检查是否配置成功。
本文基于http：//www.linuxidc.com/Linux/2013-01/78221.htm修改而成如需要原版请点击链接前往
二.apt-ge方法
2.1 在控制台下输 apt-cache search jdk
之后在查看版本 看中想安装的版本
然后在控制台输入 sudo apt-get install xxxx（xxxx为jdk版本）
然后等待安装完毕即可
三.遇到问题
3.1 Ubuntu怎么解压 tar.gz ？
2.1.2参考了 Ubuntu解压缩zip，tar，tar.gz，tar.bz2这篇文章，各个格式相应的压缩解压命令如下
ZIP
zip可能是目前使用得最多的文档压缩格式。
优点跨平台：比如Linux， Windows以及Mac OS
缺点：压缩率不是很高，而tar.gz和tar.gz2在压缩率方面做得非常好。
我们可以使用下列的命令压缩一个目录：
# zip -r archive_name.zip directory_to_compress
下面是如果解压一个zip文档：
# unzip archive_name.zip
TAR
Tar是在Linux中使用得非常广泛的文档打包格式。
优点：消耗非常少的CPU以及时间去打包文件
缺点：他仅仅只是一个打包工具，并不负责压缩。
如何打包一个目录：
# tar -cvf archive_name.tar directory_to_compress
如何解包：
# tar -xvf archive_name.tar.gz
上面这个解包命令将会将文档解开在当前目录下面。
也可以用这个命令来捏住解包的路径：
# tar -xvf archive_name.tar -C /tmp/extract_here/
TAR.GZ
这种格式是我使用得最多的压缩格式。java的jdk有用格式本压缩
优点：压缩时不会占用太多CPU的，而且可以得到一个非常理想的压缩率。
使用下面这种格式去压缩一个目录：
# tar -zcvf archive_name.tar.gz directory_to_compress
解压缩：
# tar -zxvf archive_name.tar.gz
上面这个解包命令将会将文档解开在当前目录下面。
也可以用这个命令来捏住解包的路径：
# tar -zxvf archive_name.tar.gz -C /tmp/extract_here/
TAR.BZ2
这种压缩格式是我们提到的所有方式中压缩率最好的。当然，这也就意味着，它比前面的方式要占用更多的CPU与时间。
这个就是你如何使用tar.bz2进行压缩。
# tar -jcvf archive_name.tar.bz2 directory_to_compress
上面这个解包命令将会将文档解开在当前目录下面。
也可以用这个命令来捏住解包的路径：
# tar -jxvf archive_name.tar.bz2 -C /tmp/extract_here/
3.2 如何把解压好的文件放到 /usr/lib/java/ 目录下？
1.ubuntu 终端下获取root
sudo -i
2.创建文件夹（usr下需要权限）
sudo mkdir /usr/lib/java
3.把文件移动到usr文件中（权限）
sudo mv /home/h/java/jdk1.7.0_25 /usr/lib/java
把/home/h/java/j下 的jdk文件夹 移动到usr/lib/java文件
4.copy完毕后进行JDK环境配置
相关文章：
Java菜鸟学习笔记(1)--Windows JDK环境变量配置与常见问题
软件项目开发中，有些开发人员对单元测试的重视不够，可能有几种原因：
一、开发人员主观原因，认为“测试主要是测试人员的事情，我主要负责代码实现，功能实现就可以了，测试不是我的重要工作”，重代码轻测试；
二、环境客观原因，如由于项目进度的迫切要求和压力，使开发人员也不得不快速编码实现作为重要任务，而来不及或忽视了测试；
三、单元测试方法、工具单一，或者成本太高，没有方便支持单元测试的工具，依靠简单编写测试方法、用例，花费额外多余的时间，有些测试用例用完可能就丢弃不用了，得不偿失；
四、一些编程高手编程经验丰富，不需要单元测试就能满足要求。
这些对单元测试的片面认识，可能都会造成项目质量成果的不同程度的危害。从项目整体生命周期看，可能在项目早期能够快速实现软件功能需求，提高开发进度，但可能存在潜在的bug，bug量可能会很多，或者可能在送交正式测试阶段都难以发现，有些可能延迟到运维期才发现，修改不当会使代码变得更加膨胀臃肿，难以维护，使修改维护成本大大增加了，可维护性变得差，反而”欲速则不达“，整体成本还是很高。与其如此，不如早期未雨绸缪，“bug发现越早，成本越低”，若在编码早期进行更多的单元测试，即将bug隐患消除在早期，成本就大大降低了。所以，对项目质量、成本都造成直接或间接的危害后果，我们要重视单元测试。
测试是保证项目质量的一个重要手段。一般测试可分为单元测试、系统测试、集成测试。项目开发编码实现后，一般要经过项目组内部测试，测试通过后，将项目产品交付给测试人员送测。是在项目开发中的一项测试工作，一般由开发人员进行一段，自行测试，做完编码开发后，提交给测试人员完在项目开发中
单元测试能带来哪些益处？
1.方便分析学习源代码。把单元测试可以作为分析、学习编码的工具，编码不仅是原创开发人员编写的，而且是需要给人阅读，共享给后续开发人员进行维护修改的，所以学习理解原创人员代码，对于正确维护修改意义很大。可以通过单元测试，对自己不理解的代码部分进行分析、调试，很有帮助。
2.方便跟踪测试源代码。单元测试用例，可以作为指导后续开发人员理解编码的工具，有许多开发人员抱怨前期开发人员遗留代码缺少注释，可理解性差，自己又没有有效方法切入修改代码，因为如果在没有理解别人代码的时候，贸然修改或者注释别人的代码，可能会更增加代码的复杂度、难理解性。单元测试用例则与源代码是分开管理的，白盒测试，可以针对源代码的方法进行debug跟踪测试，并可以根据自己测试后的理解，写出自己的理解注释，而不影响源代码。
如何能有效运用单元测试工具提高开发效率？
·功能概述
主要采用Junit4。推荐采用注解方式测试。
·本组件所在项目位置
各项目源码的unittest包下，测试类与相应的目标类的包目录相同。
·本组件主要涉及的元件
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"classpath:META-INF/application-*.xml"})
public class WarnRuleParserTest {
@Test
public void testGetWarnRule4Cpu() {//cpu
WarnRuleValue warnRuleValue=WarnRuleParser.getWarnRule4Cpu();
System.out.println( JSONObject.fromObject(warnRuleValue).toString());
}
|
本人从网上收集整理的几个需求管理工具 - 项目管理
需求是研发团队工作的起点，很多研发团队的开发过程混乱的源头都在于需求管理没有做好。这里是本人收集整理的几个需求管理系统，希望对大家有点帮助。
RationalRequisitePro
Rational RequisitePro是一个强大、易用、集成的需求管理产品。而通过与Rational系列软件产品的广泛集成，大大扩展了RequisitePro及其他产品的功能，给软件工程生命周期内的各个阶段都提供了强大、方便的信息查询、跟踪、管理功能。从而能够促进更好的团队沟通、帮助管理变更和评估变更的影响，帮助验证所有的规划需求被交付物所满足、降低项目风险。
IBM RationalDOORS
IBM Rational DOORS前身是大名鼎鼎的TelelogicDOORS，被IBM收购后更名为IBM Rational DOORS。DOORS
是最老牌的企业需求管理套件，通过使用DOORS/ERS，可以帮助企业更有效地进行沟通并加强协作与验证，从而降低失败的风险。通过对整个组织实施多种需求管理的方法，可以使项目的管理更加透明。它可以使企业跨越地域与组织的边界来按国际化的方式运行。
青铜器RDM
青铜器RDM是IPD+CMMI+Scrum一体化研发管理解决方案，针对需求管理，涵盖需求的全生命周期管理，从市场客户需求收集（创意管理）、产品路线图（Roadmap）定义、产品特性需求、产品设计需求与规格、项目开发Build划分（迭代划分）、测试用例库、测试计划、测试执行、缺陷跟踪、全方位的需求跟踪矩阵RTM；同时实现Scrum开发模式，基于项目需求直接生成项目任务，实现基于需求和缺陷的迭代开发模式；全面实现了IPD、CMMI、Scrum业界主流研发管理框架的需求管理要求。
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿
比较内容 | Telelogic Doors | IBM Rational RequisitePro | 青铜器RDM | 结论 |
项目级别的比较 | （1）Doors 将所有的与需求相关的数据均存放在服务器上的 doors 数据库（不是商业数据库）中。 （2）一个 DOORS Database 能够同时支持许多个不同的项目开发，从而使得新的项目能够复用和共享过去的文件和信息。不同项目（文件）之间的追踪关系可以跨项目建立。 | （1）ReqPro 将需求的数据存放在数据库中，而把与需求相关的上下文信息存放在 Word 文档中。 （2）一个 Database 只能支持一个项目的开发 , 无法支持对过去文件和信息的复用和共享。不同项目之间无法建立联系。 | （1）RDM所有项目的需求统一保存在一个Database，该数据库可以是Oracle、Sql、Mysql任何商用数据库 （2）不同项目之间的需求可以相互关联、共享；同时支持产品标准化需求库，从而支持平台化产品开发模式，可以基于产品标准需求库构建项目，实现具体客户的个性化。 | RDM、Doors 占优 （1） Doors 中的项目显然是从企业的级别考虑，任何一个用户，只要有权限，就可以访问企业中的任何一个项目的需求数据。 （2）RDM需求集中保存，便于统一维护，跨项目共享也更方便，同时产品通用需求库概念，支持平台化开发模式，兼顾平台化和项目个性化要求。 |
多人同时访问 | （1）一个时刻，只能有一个人修改一个 module （类似于 requisitepro 中的一个 word 文档），其他人只读方式打开。 DOORS 有访问方式：独占、共享和只读。当某人独占打开某个 module 时，其他人只能只读访问。但 DOORS 提供共享方式，特别是可以允许不同的人同时修改同一文档的不同部分，比如 A 用户负责修改第一章， B 用户负责修改第二章。这是 tool-setup for sharing 的功能。 | （1）一个时刻，只能有一个人修改一个 word 文档。其他人只读方式打开。 | （1）RDM支持需求检入/检出，版本化操作；同时不同版本之间的差异化能自动对比分析 （2）RDM的需求可以灵活根据需求类型、需求状态划分权限，支持多人并发对需求进行编辑、维护。 | RDM占优，ReqPro、Doors两者相同。 |
需求创建和编辑 | 在 doors 中创建和编辑（与 word 的使用类似。）创建方法简单直观。 | 在 word 文档中创建和编辑，创建方法和理解上略有困难。在 requistitepro 中创建的需求放在数据库中，不能被文档使用 | RDM支持在线创建编辑需求 和 基于Excel编辑需求，然后集中导入RDM 两种模式。 在线编辑支持富文本、直接插入图片等个性化手段 | 各有优劣， ReqPro、RDM略占优 （1） doors 中创建和使用简单，不需要 word 。但是，它毕竟没有 word 的编辑功能强大。 （2）RDM支持富文本、直接插入图片方式，能使需求展现的更直观 |
需求修改历程的纪录和管理 | （1）可以针对 module （类似于 requisitepro 中的一个 word 文档）打基线。可以比较基线之间的不同点。基线可以作为创建新的 moduel 的模版。 （2）需求项的修改有历史记录，并且可以回滚到任何一个历史点的内容。 （3）可以和主流的配置管理工具集成使用； | （1）需求项的修改有历史记录。 （2）可以和 clearcase 工具集成使用 , 完成基线功能，但是只是形成版本，没有比较功能。 | （1）RDM支持需求检入/检出，版本化记录，同时一个页面展现版本间差异 （2）RDM本身提供变更管理流程，并且流程可配置，需求和流程的集成性高 （3）RDM同时提供变更关联提醒功能，需求变更后自动通知子需求、关联需求、对应的测试用例。 | Doors、RDM占优 （1）优势明显，而且该功能比较有用。 （2）RDM的版本间差异对比、变更关联通知非常有价值。 |
对需求变更的管理 | Doors 本身具备变更管理系统，即变更的提交，评审，应用，并因此可以给指定的用户分配不同的角色（如提交者，审阅者，应用者）；内容讨论能力较弱 可以和主流的变更管理工具集成使用； DOORS 可以和 ClearQuest 集成，可以使用 CQ 的功能扩展变更流程，使需求项和变更请求紧密相关 | RequisitePro 有针对需求项的讨论功能。类似于 bbs 中的主题讨论。使用比较方便。 讨论没有区分权限，但是有明显的讨论人和讨论时间。 与 clearquest 工具集成； | 1）RDM支持需求检入/检出，版本化记录，同时一个页面展现版本间差异 （2）RDM本身提供变更管理流程，并且流程可配置，需求和流程的集成性高 （3）RDM同时提供变更关联提醒功能，需求变更后自动通知子需求、关联需求、对应的测试用例。 | 各有优劣， RDM 略占优 |
多个需求项及追踪关系的显示 | Doors 能够在一个专门的界面上给用户一次显示一个 module 文件中的所有需求项和相互之间的追踪关系 ( 即支持 in 和 out 的需求追踪 ) ，从而支持用户同时观看所有相互依赖的需求项。 | 有专用的追踪矩阵图，以二维表的形式展示需求项之间的追踪关系。 | （1）针对单个需求，一个页面可以追踪到市场需求、产品需求、设计需求、物理模块、项目构建、测试用例、开发任务、测试缺陷，实现端到端追踪 （2）针对集中追踪，提供跟踪矩阵、跟踪表两种模式 | RDM占优 （1）RDM跟踪更全面，涉及到测试用例、项目任务、物理模块、测试缺陷。 （2）RequisitePro 的功能强大，界面也比较复杂，使用不便，但RDM同样功能，RDM界面更清晰、明了。 |
可疑 link （需求变更）的通知 | （1）当 link 的一方产生变更时， Doors 可以自动产生提示符通知另一方，而不需要在 link 的矩阵上查找； （2）可以清楚地看到导致可疑 link 的需求内容变更情况 | 没有自动提示，必须通过追踪关系矩阵来查找，当追踪矩阵比较大时，非常费时费力； | （1）当 link 的一方产生变更时， RDM 可以自动产生提示符通知另一方，同时自动把变更的信息推给对方 （2）Link方不仅仅是需求还涵盖测试用例，通知更全面 | RDM、Doors 占优 （1）RDM更优，可以灵活配置哪些属性变化才通知，同时变化信息能自动推送给link方，更易用 （2）Doors 的可疑 link 原理是通过需求内容的改变自动置 link 为可疑，比较科学。 |
与已有产品的集成 | Clearquest 、 clearcase 、 rose | Clearquest 、 clearcase 、 rose 、 testManager 、 project2002 | RDM本身就是研发一体化平台，可以使客户最大程度节约投入 | Requistitepro 占优 |
与 word 的集成 | 需求的创建和修改工作完全在 doors 中完成。只是提供了导出符合格式的 word 文档。 | 与 word 紧密集成，需求的创建和修改工作大部分在 word 中完成。 | 需求的创建和修改工作在 RDM 中完成。灵活定义导出的内容和格式，可以直接导出为Word、PDF、Excel格式。 | Requistitepro 、RDM占优 |
从现有 word 文档的导入功能 | 。支持，基本上是 word 文档中的一段对应 doors 中的一个需求项（ object ）。同时， word 中的表格、图像等 ole 对象也可以导入。 支持 Word 文档的导入，同时支持 table ， picture 和 OLE object 的导入 | 不支持普通 word 文档的导入 | 不支持Word，支持Excel | Doors 占优 |
离线编辑功能 | 没有找到离线编辑的好方法。 | 可以使用 word 把文档下载到本地编辑（可以离开网络环境）。然后再提交到 requisitepro. | 没有找到离线编辑的好方法。 | Requistitepro 占优 该功能比较有用。 |
权限控制 | Doors 具有灵活的权限控制，包括：只读，修改，创建，删除，管理等五种级别。权限控制可以针对每一个用户在每一个 database ，项目目录，文件，实施等； | 权限控制的种类和级别有限。包括：只读、完全控制。权限只能针对项目 。 | RDM 具有非常灵活的权限控制，包括：只读、编辑、创建、删除、管理等五种级别。同时可以基于需求字段属性配置权限 | RDM 占优 |
数据备份和恢复 | 简单有效 | 复杂，要保证文件和数据库同时备份。可能使用 access 数据库会 … | 简单方便，只需要配置数据库、服务器上的文件库目录即可 | RDM、Doors 占优 |
异地需求管理 (Multi-site) | Doors 提供灵活的方式实现需求异地管理的方式； Doors 强大的性能优势也保障了大型项目异地需求开发 / 管理的可能； | 无异地使用模式 | RDM是B/S结构，提供领会异地访问管理模式 | RDM已经有众多实际案例 |
是否易于掌握 | 容易使用 | 较容易使用 | 容易使用，但前期配置有一定的工作量 | Requistitepro 上手较快（因为是在 word 中编辑），想各个功能用的比较顺手需要一段时间。 Doors 大部分功能比较容易掌握。 RDM终端用户操作方便，但系统配置需要一定工作量。 |
Mysql的tee功能是用来记录用户的操作记录的，由于对mysql进行大量的更改操作，比如删除，修改，添加等动作等等，涉及到生产环境中时候，这些操作有时候很有必要把整个操作记录下来，以便核对查找。Tee功能类似于oracle中的spool，下面对几种tee的不同保方式测试：
一、直接指定文件
出于这种是由于之前使用spool的时候每次spool时候都会使用spool '文件路径'，结束后便用spool off即可。下面是测试截图：
初看结果，好像是正确指定了文件和路径，那么我们去这个路径是否看到这个tee.log呢，进入mysql用户根目录下的tmp目录查看，已经生成了tee.log文件，然后运行一些简单操作测试是否记录成功；
查看tee.log文件；发现都是实时记录了所有的操作记录和结果。跟oracle有点不同的是，oracle每次都是在spool off之后才生成（应该没有记错）。关闭即用notee或者\t命令。
二、通过启动带参数--tee
启动使用命令：mysql -uroot -p --tee=/home/mysql/tmp/ceshi.log -S /usr/local/mysql/tmp/3306/mysql.sock登录成功后，按正常同样再测试一次操作记录
查看ceshi.log，所有记录均实时记载。
三、通过更改设置配置文件my.cnf
测试环境，先kill掉mysqld服务（生产环境一般没有在my.cnf中增加该配置，这里仅仅只是用来测试）。
关闭mysql，然后修改mysql的配置文件中的[client]选项段，添加以下内容：
[client]
port = 3306
socket = /usr/local/mysql/tmp/3306/mysql.sock
default-character-set = utf8
tee = /home/mysql/tmp/result.log
再次启动mysql，查看/home/mysql/tmp/下是否生成了result.log文件，一看没有，奇怪了，按理说这样的方式是正确的，在网上找了下大部分都讲到了这三点，也没有见谁说这种方式不行。会不会是版本有问题，我本机装的是32位的mysql 5.1.57版本。于是换台机器，换个64位的mysql 5.1.50版本测试下；
一样的配置一样重新启动了mysql。测试后发现还是没有出现结果记录；
原来写入mysql配置文件中，在不同版本中有差异，目前有一些有些版本的mysql数据库的tee功能在写入配置文件的时候不生效，但是支持终端下命令行直接操作，例如上面2个版本都是没有效果的，所以写入配置文件中并不保险。目前还不清楚原因何在，猜测也有可能是某些版本存在bug ，希望知道的不吝赐教。