为效益而测试

为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。

缺陷的必然性

软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

软件测试必须有预期结果

没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

软件测试的意义 - 事后分析

软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。

结论：

软件测试是一个需要 “ 自觉 ” 的过程，作为一个测试人员，遇事沉着，把持尺度，从根本上应对软件测试有着正确的认识，希望本文对读者对软件测试的认识有所帮助

一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

qq：316016247

      前两天没事就跟电脑较劲，优化系统，结果在优化过程中不小心把输入法中“简体中文-美式键盘”给误干掉了，但是在输入法设置中却无法重新添加，后果就是只 能在中文输入状态，顶多是切换到英文状态，却无法使用组合快捷键，后来尝试添加了“英文-美式键盘”可以将就着用了，其实添加“繁体中文-美式键盘”也可 以凑合用，但是终究还是不爽，再继续寻找解决方案的时候，发现了这样的介绍：
  我们可以通过修改注册表来实现，在开始菜单运行栏中输入 regedit 打开注册表，找到：HKEY_CURRENT_USER\Keyboard Layout\Preload
  可以看到有1到5甚至更多键值，分别代表：
     简体中文-美式键盘       00000804 
     英语（美国）00000409 
     微软拼音输入法       E00E0804 
     全拼输入法       版本       E0010804 
     郑码输入法       E0030804 
     智能ABC输入法       E0040804
    将新建一个字符串将键值设定为00000804，然后重新启动系统或者注销当前用户再次登录就可以重新出现了。
然后在输入法设置里把“简体中文-美式键盘”设为默认输入语言即可！

Oracle用imp和exp实现数据的导入和导出

---

一直很喜欢google的东西。

偶然间看到google music，很喜欢，给大家推荐！

in sqlserver,if you create a table with identity pk.
you can select by identity pkey as below:
select * from tableName where pkey=@@pkey
the identity pkey is use to the last record that you insert into db only.

Oracle数据导入导出imp/exp就相当于oracle数据还原与备份。exp命令可以把数据从远程数据库服务器导出到本地的dmp文件，imp命令可以把dmp文件从本地导入到远处的数据库服务器中。执行环境：可以在SQLPLUS.EXE或者DOS（命令行）中执行， DOS中可以执行时由于 在oracle 8i 中 安装目录\ora81 \BIN被设置为全局路径， 该目录下有EXP.EXE与IMP.EXE文件被用来执行导入导出。 oracle用java编写，SQLPLUS.EXE、EXP.EXE、IMP.EXE这两个文件有可能是被包装后的类文件。 SQLPLUS.EXE调用EXP.EXE、IMP.EXE所包裹的类，完成导入导出功能。

导出工具 exp:

1. 它是操作系统下一个可执行的文件 存放目录/ORACLE_HOME/bin   exp导出工具将数据库中数据备份压缩成一个二进制系统文件. 它有三种模式：

       a. 用户模式：导出用户所有对象以及对象中的数据；                                                                                                    
        b. 表模式： 导出用户所有表或者指定的表；
         c. 整个数据库： 导出数据库中所有对象。

2. 导出工具exp交互式命令行方式的使用的例子

$exp test/test123@appd
Enter array fetch buffer size: 4096 > 回车
Export file: expdat.dmp > m.dmp 生成导出的文件名
(1)E(ntire database), (2)U(sers), or (3)T(ables): (2)U > 3
Export table data (yes/no): yes > 回车wQeLin
Compress extents (yes/no): yes > 回车      &

nbsp;                                                                         

Export done in ZHS16GBK character set and ZHS16GBK NCHAR character set
About to export specified tables via Conventional Path ...wQeLinux联盟
Table(T) or Partition(T:P) to be exported: (RETURN to quit) > cmamenu 要导出的表名
. . exporting table                        CMAMENU       4336 rows exported
Table(T) or Partition(T:P) to be exported: (RETURN to quit) >要导出的表名n
Table(T) or Partition(T:P) to be exported: (RETURN to quit) > 回车
Export terminated successfully without warnings.

3. 导出工具exp非交互式命令行方式的例子

1) 将数据库TEST完全导出,用户名system 密码manager 导出到D:\daochu.dmp中
   exp system/manager@TEST file=d:\daochu.dmp full=y
2) 将数据库中system用户与sys用户的表导出
   exp system/manager@TEST file=d:\daochu.dmp wner=(system,sys)
3) 将数据库中的表inner_notify、notify_staff_relat导出
    exp aichannel/aichannel@TESTDB2 file= d:\data\newsmgnt.dmp tables=(inner_notify,notify_staff_relat)

4) 将数据库中的表table1中的字段filed1以"00"打头的数据导出
   exp system/manager@TEST

上面是常用的导出，对于压缩，既用winzip把dmp文件可以很好的压缩。
也可以在上面命令后面 加上 compress=y 来实现。 file=d:\daochu.dmp tables=(table1) query=\" where filed1 like ''00%''\"

导入工具 imp

1. 它是操作系统下一个可执行的文件 存放目录/ORACLE_HOME/bin
imp导入工具将EXP形成的二进制系统文件导入到数据库中.
   它有三种模式：
       a. 用户模式： 导出用户所有对象以及对象中的数据；
       b. 表模式： 导出用户所有表或者指定的表；
       c. 整个数据库： 导出数据库中所有对象。

2.导入工具imp交互式命令行方式的例子wQeLinux联盟
$ imp
Import: Release 8.1.6.0.0 - Production on 星期五 12月 7 17:01:08 2001
(c) Copyright 1999 Oracle Corporation. All rights reserved.
用户名: test
口令:****
连接到: Oracle8i Enterprise Edition Release 8.1.6.0.0 - 64bit Production
With the Partitioning option
JServer Release 8.1.6.0.0 - Production
导入文件: expdat.dmp> /tmp/m.dmp
输入插入缓冲区大小（最小为 8192 ) 30720>
经由常规路径导出由EXPORT:V08.01.06创建的文件
警告: 此对象由 TEST 导出, 而不是当前用户
已经完成ZHS16GBK字符集和ZHS16GBK NCHAR 字符集中的导入
只列出导入文件的内容(yes/no)：no>
由于对象已存在, 忽略创建错误(yes/no)：no> yes
导入权限(yes/no)：yes>
导入表数据(yes/no)：yes>
导入整个导出文件(yes/no)：no> yes
. 正在将TEST的对象导入到 SCOTT
. . 正在导入表                       "CMAMENU"       4336行被导入
成功终止导入，但出现警告。
3.导入工具imp非交互式命令行方式的例子

1 )将D:\daochu.dmp 中的数据导入 TEST数据库中。
   imp system/manager@TEST file=d:\daochu.dmp
   imp aichannel/aichannel@HUST full=y file=file= d:\data\newsmgnt.dmp ignore=y
   上面可能有点问题，因为有的表已经存在，然后它就报错，对该表就不进行导入。
   在后面加上 ignore=y 就可以了。
2 )将d:\daochu.dmp中的表table1 导入
imp system/manager@TEST file=d:\daochu.dmp tables=(table1)

基本上上面的导入导出够用了。不少情况要先是将表彻底删除，然后导入。

自动实现数据库的备份/恢复：

       利用oracle提供的数据备份工具Exp进行数据的导出备份或者利用Oracle提供的RMAN进行数据库备份;利用Window22000 提供的定时任务，可以每天设定一个固定的时间，系统自动进行备份。具体实现过程：
1.创建批处理文件Ora_Backup.bat,在批处理文件中包含：

exp username/password@oracleservice file=c:\backup.dmp wner=(lee)

附：（如何动态的产生备份文件的名字？如使用db20071128.dmp，如何在批处理命令中自动获得20071128时间?

解决方法：

1。在批处理中获得时间的方式为：%date%；
C:\Documents and Settings\Administrator>echo %date%
星期三 2007-11-28

2。时间可以获取其中的部分字符：%date:~4,10%
C:\Documents and Settings\Administrator>echo %date:~4,10%
2007-11-28
即：由第4位开始截取，长度为10。
C:\Documents and Settings\Administrator>echo %date:~0,-4%
星期三 2007-1
即：由第0开始截取，长度减掉后4位。

3。如何得到字符串20071128，很简单：%date:~4,4%%date:~9,2%%date:~12,2%
C:\Documents and Settings\Administrator>echo %date:~4,4%%date:~9,2%%date:~12,2%
20071128

）
    使备份的文件名不重复的批处理：

exp username/password@oracleservice file=c:\backup%date:~4,4%%date:~9,2%%date:~12,2%.dmp    wner=(lee)

    其中：username 指oracle数据库用户名；password指oracle数据库用户密码；oracleservice 指oracle网络服务名；lee为要导出的用户。

2.在Windows2000下利用定时任务自动实现数据库的备份-创建任务

创建全备份任务：
创建任务计划，设定每周六早上8:00执行数据备份
打开控制面板->任务计划
点击 添加任务计划
点击 下一步
选择要执行的任务All_backup.bat,输入任务名称all_backup，选择每周,点击下一步。
选择起始时间8:00,在请选择下面日期中选择星期六，点击下一步。
数据用户名和密码，下一步。
点击完成，完成全备份任务的创建。                                                                                         

数据恢复同理，创建批处理文件Orb_Backup.bat,在批处理文件中包含：
imp username/password@oracleservice file=backup.dmp 创建任务计划即可。但这样会出现很多的问题，一般不这样做。

　　注册表（Registry）是微软公司从Windows95系统开始(至目前最新Win2000系统依然使用的是它)，引入用于代替原先Win32系统里.ini文件，管理配置
系统运行参数的一个全新的核心数据库。在这个数据库里整合集成了全部系统和应用程序的初始化信息；其中包含了硬件设备的说明、相互关联的应用程序
与文档文件、窗口显示方式、网络连接参数、甚至有关系到计算机安全的网络享设置
。它与老的win32系统里的ini文件相比，具有方便管理，安全性较高、适于网络操作等特点。

(以下分割符内的内容，摘自《新潮电子》98年第六期 作者：何宗琦 )

在形式上，注册表与INI文件有两个显著的特点：
　　1.注册表采用的是二进制形式登录数据，INI文件采用的则是简单的文本形式登录数据

　　2.注册表支持子关键字，各级子关键字都有自己的“键值”,INI文件中则支持节以及节中的参数。

在功能上，注册表与.INI文件相比，主要有以下三个特点：

　　1.注册表允许对硬件、某些操作系统参数、应用程序和设备驱动程序进行跟踪配置，这使得某些配置的改变可以在不重新启动系统的情况下立即生效。
　　2.注册表中登录的硬件部分数据可以用来支持Win95的即插即用特性。当Win95检测到机器上的各种设备时，就把有关数据保存到注册表中。通常是在安
装时进行这种检测的，但Win95启动或原有配置改变时，也要进行检测。如安装一个新的硬件时，Win95将检查注册表，以便确定哪些资源已被占用，这样就
可以避免新设备与原有设备之间的资源冲突。
　　3.通过注册表，管理人员和用户可以在网络上检查系统的配置和设置，使得远程管理得以实现。

预定义关键字

　　注册表采用“关键字”及其“键值”来描述登录项及其数据。所有的关键字都是以“HKEY”作为前缀开头。实际上，关键字是一个句柄。这种约定使得应用程
序开发人员可以在使用注册表API时把它用于程序之中。为此，Win95提供了若干API函数，以便在开发Win95应用程序时添加、修改、查询和删除注册表的登
录项。关键字可以分为两类：一类是由系统定义的，通常称为“预定义关键字”；另一类是由应用程序定义的，安装的应用软件不同，其登录项也就不同。

　　由于注册表保存的信息中，含有许多系统启动时必要的参数，一旦出现问题将导致系统崩溃等严重后果，此外由于注册表里含有许多的无法通过操作系
统本身进行操作的系统参数，因此了解并学会使用注册表，对每一个老鸟来讲都是一件不可缺少。

 2009年悄悄地来到了，送走了艰难的、折腾的2008年。人们对2009年会充满更多的期望，9是一个吉祥的数字，天长地久，而且农历是牛年，牛年更牛。

     到了2009年，该为软件测试写点什么。顺民意，预测一下2009年国内软件测试的十大热点。

1. 基于云的测试将是新的课题，包括测试方法、技术和工具。而且，云环境下的测试也是减少测试成本的一个途径。
2. 基于Web 2.0/Ajax 的软件测试技术还是热点。Java/Javascript技术变化很快，系统开发框架也是层出不穷。
3. 软件测试自动化也还是热点，包括更多的开源测试工具、自动化测试模型和框架、自动化测试的理论研究等。
4. 移动测试：移动计算、移动应用用来，包括3G的应用，移动测试（包括无线应用系统的测试）将会受到更多的关注，是测试的一个新的增长点。
5. 虚拟技术（如Citrix、微软、VMware的产品）的日益普及，越来越多的测试团队会将虚拟技术应用于测试环境创建、维护和优化，甚至是测试的执行。
6. 安全测试：软件系统安全形势更加严峻，对安全测试会提出更高的要求，软件工具厂商会推出更多的安全测试工具。
7. 软件外包测试：中国软件外包迎来发展良机和挑战，大型的软件外包企业发展更快，小的软件外包企业困难增大、被兼并的可能性增大，软件测试在外包企业得到更好的发展。
8. 测试培训：软件测试培训的竞争将更加激烈，无论宣传还是市场争夺，将会进入白热化的地步。ISTQB将成为2009年国内培训市场的一颗新星。
9. 课程与图书：有越来越多的大学，为研究生和本科生开设“软件测试”课程。软件测试的图书在2008年很热，在2009年热度，可能依旧不减。
10. 测试会议和沙龙：全国性或国际性的软件测试会议会成为新的热点之一，软件测试的沙龙越来越多。

分布式软件系统(Distributed Software Systems)是支持分布式处理的软件系统,是在由通信网络互联的多处理机体系结构上执行任务的系统。它包括分布式操作系统、分布式程序设计语言及其编译(解释)系统、分布式文件系统和分布式数据库系统等。

分布式操作系统负责管理分布式处理系统资源和控制分布式程序运行。它和集中式操作系统的区别在于资源管理、进程通信和系统结构等方面。

分布式程序设计语言用于编写运行于分布式计算机系统上的分布式程序。一个分布式程序由若干个可以独立执行的程序模块组成,它们分布于一个分布式处理系统的多台计算机上被同时执行。它与集中式的程序设计语言相比有三个特点：分布性、通信性和稳健性。

分布式文件系统具有执行远程文件存取的能力,并以透明方式对分布在网络上的文件进行管理和存取。

分布式数据库系统由分布于多个计算机结点上的若干个数据库系统组成,它提供有效的存取手段来操纵这些结点上的子数据库。分布式数据库在使用上可视为一个完整的数据库,而实际上它是分布在地理分散的各个结点上。当然,分布在各个结点上的子数据库在逻辑上是相关的。


---------------

分布式数据库系统是由若干个站集合而成。这些站又称为节点，它们在通讯网络中联接在一起，每个节点都是一个独立的数据库系统，它们都拥有各自的数据库、中 央处理机、终端，以及各自的局部数据库管理系统。因此分布式数据库系统可以看作是一系列集中式数据库系统的联合。它们在逻辑上属于同一系统，但在物理结构 上是分布式的。

分布式数据库系统已经成为信息处理学科的重要领域，正在迅速发展之中，原因基于以下几点：

1、它可以解决组织机构分散而数据需要相互联系的问题。比如银行系统，总行与各分行处于不同的城市或城市中的各个地区，在业务上它们需要处理各自的数据，也需要彼此之间的交换和处理，这就需要分布式的系统。

2、如果一个组织机构需要增加新的相对自主的组织单位来扩充机构，则分布式数据库系统可以在对当前机构影响最小的情况下进行扩充。

3、均衡负载的需要。数据的分解采用使局部应用达到最大，这使得各处理机之间的相互干扰降到最低。负载在各处理机之间分担，可以避免临界瓶颈。

4、当现有机构中已存在几个数据库系统，而且实现全局应用的必要性增加时，就可以由这些数据库自下而上构成分布式数据库系统。

5、相等规模的分布式数据库系统在出现故障的几率上不会比集中式数据库系统低，但由于其故障的影响仅限于局部数据应用，因此就整个系统来讲它的可靠性是比较高的。

特点

1、在分布式数据库系统里不强调集中控制概念，它具有一个以全局数据库管理员为基础的分层控制结构，但是每个局部数据库管理员都具有高度的自主权。

2、在分布式数据库系统中数据独立性概念也同样重要，然而增加了一个新的概念，就是分布式透明性。所谓分布式透明性就是在编写程序时好象数据没有被分布一样，因此把数据进行转移不会影响程序的正确性。但程序的执行速度会有所降低。

3、集中式数据库系统不同，数据冗余在分布式系统中被看作是所需要的特性，其原因在于：首先，如果在需要的节点复制数据，则可以提高局部的应用性。其次， 当某节点发生故障时，可以操作其它节点上的复制数据，因此这可以增加系统的有效性。当然，在分布式系统中对最佳冗余度的评价是很复杂的。

分布式系统的类型，大致可以归为三类：

1、分布式数据，但只有一个总? 据库，没有局部数据库。

2、分层式处理，每一层都有自己的数据库。

3、充分分散的分布式网络，没有中央控制部分，各节点之间的联接方式又可以有多种，如松散的联接，紧密的联接，动态的联接，广播通知式联接等。

---------------------


什么是分布式智能?
NI LabVIEW 8的分布式智能结合了相关的技术和工具，解决了分布式系统开发会碰到的一些挑战。更重要的是，NI LabVIEW 8的分布式智能提供的解决方案不仅令这些挑战迎刃而解，且易于实施。LabVIEW 8的分布式智能具体包括:

可对分布式系统中的所有结点编程——包括主机和终端。尤为可贵的是，您可以利用LabVIEW图形化编程方式，对大量不同类型的对象进行编程，如桌面处理器、实时系统、FPGA、PDA、嵌入式微处理器和DSP。
导航所有系统结点的查看系统——LabVIEW Project Explorer。您可使用Project Explorer查看、编辑、运行和调试运行于任何对象上的结点。
经简化的数据共享编程界面——共享变量。使用共享变量，您可轻松地在系统间(甚至实时系统间)传输数据且不影响性能。无通信循环，无RT FIFO，无需低层次TCP函数。您可以利用简单的对话完成共享变量的配置，从而将数据在各系统间传输或将数据连接到不同的数据源。您还可添加记录、警 报、事件等数据服务――一切仅需简单的对话即可完成。
实现了远程设备及系统内部或设备及系统之间的同步操作——定时和同步始终是定义高性能测量和控制系统的关键问题。利用基于NI技术的系统，探索设备内部并编写其内部运行机制，从而取得比传统仪器或PLC方式下更为灵活的解决方案。


--------------------


在分布式计算机操作系统支持下，互连的计算机可以互相协调工作，共同完成一项任务。

也可以这么解释:
一种计算机硬件的配置方式和相应的功能配置方式。它是一种多处理器的计算机系统，各处理器通过互连网络构成统一的系统。系统采用分布式计算结构， 即把原来系统内中央处理器处理的任务分散给相应的处理器，实现不同功能的各个处理器相互协调，共享系统的外设与软件。这样就加快了系统的处理速度，简化了 主机的逻辑结构

1、为什么要使用中间件？  
2、国内外的中间件厂商都有哪些？  
3、中间件的应用领域？    
4、开发中间件的前景?  

中间件,是指在我们做程序时，当做好一个server端时，我们要在客户端，作相应的应用程序来调用server端的程序！这样，就很麻烦！当一个银行的系统更改时，就需要将每一个客户端都作相应的调试！所以，就出了中间件！  
这样，客户端不用做任何调整！

 
这其实是一个比较虚的概念。广义的中间件范围很广。起沟通作用的都可以认为是中间件。甚至ODBC这样的东西你也可以认为是中间件。  
  现在用的比较多的中间件应该是BEA公司的tuxedo和IBM公司的weblogic?（好象是这个东西），我接触过一点tuxedo。oracle、 sun和ms好象也有类似产品，不过用的人很少。tuxedo是这个领域的领导者，不过IBM正在追赶并有可能超过，毕竟，IBM就是IBM。  
  tuxedo这东西我们用来做数据库和前台应用之间的中间件。  
  使用了中间件之后，以前直接连接的前台应用程序和数据库之前就多了个tuxedo，现在前台程序把请求发给tuxedo，tuxedo再把请求发给数据 库，数据库处理结束之后把结果返回tuxedo，tuxedo再把结果送回给前台。这样一搞，表面看复杂了很多。不过带来一些好处，比如：  
  安全。tuxedo的服务是定制的，这就有点象是存贮过程，因为应用程序无法直接接到数据库而只能通过tuxedo，所以应用程序无法做tuxedo服务之外的事情。你把你的应用逻辑写在tuxedo中，你就可以保证你的数据是安全的。  
  性能。有些数据库性能不好，比如oracle一个连接就是好多M，连接数一多，机器内存就没了，有了tuxedo之后，tuxedo负责连接数据库，连接 数比较少，tuxedo可以用排队的方式来处理这些数据库请求，这样提高了性能。中间件的高级应用好象还可以把数据库分布在不同的机器上，由tuxedo 动态分配前、后台的请求和处理，把它们搞在不同的机器上，所以你用了中间件之后如果后台数据库处理来不及，可以加一台机器，前台请求太多（比如网站）可以 加多前台机器。你可以灵活的调整性能。  
  方便移植。业务逻辑做到了中间件里之后，你更换后台数据库、改变前台的开发工具什么的移植工作较小，因为中间件的工作改动不大。  
   
  应用服务器做的人好象就更多了。而且应用服务器这东西和中间件类似（逻辑上）我觉得它应用也是中间件的一种，不过大家一般说中间件都是指的狭义的中间件，就是tuxedo这些。  

GUI Vusers actually perform. the actions using the client.this means that fewer GUI vusers can be run per workstation than the other types of vusers due to the overload of the client, and is infact limited to one GUI v user per workstation.GUI Vusers are not so much to generate load on a system but to test end -to end performance associated with various business processes

.

相关知识点-面象对象(=Object Oriented)技术
　　1. 对象和类

　　l 面象对象的编程语言：以对象为中心，以消息为驱动，程序=对象+消息

 l 类是一种新的数据类型，是设计的核心，是通过抽象数据类型的方法来实现的一种数据类型

　　l 类是对某一对象的抽象，对象是某一类的实例，两者密切相关

　　2. 封装、继承和多态性

　　(1) 封装：把数据和操作结合一体，使程序结构更加紧凑，避免了数据紊乱带来的调试与维护的困难

　　(2) 继承：可以从一个类派生到另一个类，派生类继承了父类和祖先类的数据成员和函数，增加了软件的可扩充性，并为代码重用提供了强有力的手段

　　(3) 多态性：多种表现形式，可以用‘一个对外接口，多个内在实现方法’表示。

　　一.面向对象测试模型

　　1. 面向对象测试的分类

　　依据面向对象开发模型(面向对象分析、面向对象设计、面向对向编程)，分为：

　　(1) 面向对象分析的测试(OOA Test)、面向对象设计的测试(OOD Test)：是对分析结果和设计结果的测试，主要对分析设计产生的文本进行的，是软件开发前期的关键性测试

　　(2) 面向对象编程的测试(OOP Test)：对编程风格和程序代码实现进行测试，主要的测试内容在OO Unit Test和OO Integrate Test中体现

　　(3) 面向对象单元测试(OO Unit Test)：对程序内部具体单一的功能模块的测试，主要对类成员函数的测试，是OO Integrate Test的基础

 (4) 面向对象集成测试(OO Intergrate Test)：对系统内部的相互服务进行测试，如成员函数间的相互作用，类间的消息传递。不仅要基于OO Unit Test，还要参考OOD、OOD Test的结果

　　(5) 面向对象确认测试(OO System Test)、面向对象系统测试(OO System Test)：最后阶段的测试，以用户需求为测试标准，借鉴OOA 、OOA Test的结果

　　二. 面向对象软件的测试策略

　　1. 面向对象分析的测试

　　(1) 面向对象分析

　　是把E-R图和语义网络模型，即信息造型中的概念，与面向对象程序设计语方中的重要概念结合在一起而形成的分析方法。通常以问题空间的图表的形式进行描述

　　(2) 分析方法

　　直接映射问题空间，全面地将问题空间中实现功能的现实抽象化。将问题空间中的实例抽象为对象，用对象的结构反映问题空间的复杂实例和复杂关系，用属性和服务表示实例的特性和行为。

   (3) 面向对象分析缺点

　　对问题空间分析抽象的不完整，会影响软件的功能实现，导致软件开发后期产生大量原本可避免的修补工作;一些冗余的对象或结构类的选定，程序的整体结构和增加程序员不必要的工作量，因此 OOA测试的重点在其完整性和冗余性

　　(4) OOA测试划分的五个方面

　　对认定的对象的测试、对认定的结构的测试、对认定的主题的测试、对定义的属性和实例关联的测试、对定义的服务和消息关联的测试

　　2. 面向对象设计(OOD)的测试

　　(1) 面向对象设计(OOD)

　　采用‘造型的观点’，以OOA为基础归纳出类，并建立类结构或进一步构造类库，以实现分析结果对问题空间的抽象。OOD归纳的类即可以是对象的简单延续，也可以是不同对象的相同或相似的服务

　　(2) OOD与OOA

　　OOD是OOA的进一步细化和更高层的抽象，所以OOD、OOA的界限很难区分，OOD确定类和类结构不仅是满足当前需求分析要求，更重要是通过重新组合或加以适当的补充，方便实现功能重用和扩增。因此，对OOD的测试，建议针对功能的实现和重用以及OOA结果的分析

　　(3) OOD测试划分的三个方面

　　1、认定的类的测试

　　2、构造的类的层次结构测试

　　3、类库支持的测试

　　3. 面向对象编程(OOP)的测试

　　(1) 面向对象程序

　　把功能的实现分布在类中，能正确实现功能的类，通过消息传递来协同实现设计要求的功能。将出现的错误精确的确定在某一具体的类上。

　　(2) 测试重点

　　忽略类功能实现的细则，将测试的目光集中在类功能的实现和相应的面向对象程序风格上

　　(3) 测试方面

　　1、类的封装

　　2、类的功能

　　4. 面向对象软件的单元测试

　　(1) 可以将一些传统的单元测试方法在面向对象软件的单元测试中使用，如等价类划分、因果图、边界值分析法、逻辑覆盖法、路径分析法、程序插桩法，单元测试一般建议由程序员完成

    (2) 单元级测试的测试分析和测试用例，规模和难度均远小于对整个系统的测试分析和测试用例，并且对语句应该有100%的代码执行覆盖率。

 (3) 设计测试用例选择输入数据的两个假设：

　　l 如果函数(程序)对某一类输入中的一个数据正确执行，对同类中的基他输入也能正确执行(等价类)

　　l 如果函数(程序)对某一复杂度的输入正确执行，对更高复杂度的输入也能正确执行

　　(4) 针对继承性，Brian Marick两方面的考虑

　　l 继承的成员函数是否都不需要测试：当继承的成员函数在子类中做了改动;成员函数调用了改动过的成员函数的部分这两种情况需要对子类重新测试

　　l 对父类的测试是否能照搬到子类：可以重新测试或在父类原有的测试要求和测试用例上增加新的测试要求和测试用例，主要针对子类中变动的部分进行测试

　　5. 面向对象软件的集成测试

　　(1) 传统的自顶向下或自底向上的集成测试策略在面向对象软件的集成测试中无意义，OO软件的集成测试需要在整个程序编译完成后进行，面向对象程序具有动态特性，程序的控制流无法确定，只能对编译完成的程序做基于黑盒子的集成测试

　　(2) 面向对象软件的集成测试两种策略

　　l 基于线程的测试(Thread based testing)：集成对响应系统的一个输入或事件所需的一组类，每个线程分别进行集成和测试，应用回归测试以保证没有产生副作用。

　　l 基于使用的测试(Use based testing)：通过测试那些几乎不使用服务器类的的类(独立类)而开始构造系统，在独立类测试完成后，下一层中使用独立类的类(依赖类)被测试，这个依赖类层次的测试序列一直持续到构造完整个系统。

　　(3) 测试目的

　　能够检测出相对独立的，单元测试无法检测出的，那些类相互作用时才会产生的错误，只关注于系统的结构和内部的相互作用

　　(4) 面向对象软件的集成测试过程

　　第一步：静态测试 针对程序的结构进行，检测程序结构是否符合设计要求。通过使用测试软件的‘可逆性工程’功能，得出源程序的类系统图和函数功能调用关系图，与OOD结果相比较，检测程序结构和实现上是否有缺陷，检测OOP是否达到了设计要求

　　第二步：动态测试 根据静态测试得出的函数功能调用关系图或类关系图作为参考，按照如下步骤设计测试用例，达到如下测试覆盖标准

 设计测试用例步骤：选定检测的类，参考OOD分析结果，确定出类的状态和相应的行为;确定覆盖标准;利用结构关系图确定待测类的所有关联;根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态，使用类的服务和期望产生什么行为等，还要设计一些类禁止的例子，确认类是否有不合法的行为产生

　　覆盖标准：达到类所有的服务要求或服务提供的一定覆盖率;依据类间传递的消息，达到对所有执行线程的一定覆盖率;达到类的所有状态的一定覆盖率等

　　六. 面向对象软件的确认和系统测试

　　(1) 系统测试：需要测试它与系统其他部分配套运行的表现，以确保在系统各部分协调工作的环境下软件也能正常运行

    (2) 要求：测试环境尽量与用户实际使用环境相同，保证被测系统的完整性，对暂时没有的系统设备部件，应采取相应的模拟手段。参考OOA分析结果，检测软件是否能够完全‘再现’问题空间

 (3) 不仅是检测软件的整体行为表现，另一方面对软件设计开发的确认。OO软件的确认和系统测试具体的测试内容与传统的系统测试基本相同，包括：功能测试，强度测试，性能测试，安全测试，易用性测试，恢复测试，安装/卸载测试

　　三.OO软件测试用例设计原则(Berard)

　　关注于设计合适的操作序列以测试类的状态

　　1. 对每个测试用例应当给予特殊的标识，并且还应当与测试的类有明确的联系

　　2. 测试目的应当明确

　　3. 应当为每个测试用例开发一个测试步骤列表，列表包含内容

 l 列出所要测试对象的说明

　　l 列出将要作为测试结果的消息和操作

　　l 列出测试对象可能发生的例外情况

　　l 列出外部条件，为了正确对软件进行测试所必须有的外部环境的变化

　　l 列出为了帮助理解和实现测试所需要的附加信息

　　四.OO软件测试的方法

　　1. 基于故障的测试

　　(1) 具有较高的发现可能故障的能力

　　(2) 从分析模型开始，考察可能发生的故障，设计用例去执行设计和代码

　　(3) 可用于集成测试，发现消息联系中‘可能的故障’(可能的故障指意料之外的结果、错误地使用了操作/消息、不正确地引用等)

　　(4) 除用于操作测试外，还可用于属性测试，用以确定其对于不同类型的对象行为是否赋予了正确的属性值

　　(5) 是从客户对象(主动)上发现错误

　　(6) 不能发现的错误：不正确的规格说明，用户不需要的功能或缺少用户需要的功能;没有考虑子系统间的交互作用

　　2. 基于场景的测试

　　(1) 主要关注用户需要做什么，不是产品能做什么，即从用户任务(使用用例)中找出用户要做什么及如何去执行

　　(2) 有助于在一个单元测试情况下检查多重系统，比基于故障的测试更实际，更复杂一点

  3. OO类的随机测试

　　如果一个类有多个操作(功能)，这些操作(功能)序列有多种排列，这种不变化的操作序列可随机产生，用这种可随机排列来检查不同类实例的生存史，称为随机测试

　　4. 类层次的分割测试

　　(1) 可以减少用完全相同的方式检查类测试用例的数目，类似于等价类划分

　　(2) 分类：基于状态的分割、基于属性的分割、基于类型的分割

　　l 基于状态的分割：按类操作是否会改变类的状态进行分割(归类)

　　l 基于属性的分割：按类操作所得到的属性来分割(归类)

　　l 基于类型的分割：按完成的功能分割(分类)，如初始操作、计算操作、查询操作

 5. 由行为模型(状态、活动、顺序和合作图)导出的测试

 状态转换图(STD)可以用来帮助导出类的动态行为的测试序列，以及这些类与之合作的类的动态行为测试用例，根据状态转换图，设计出最小测试用例，加入其他测试序列到最小测试序列中，保证类所有行为被充分检查

　　总结：

　　本章主要讲述了面向对象软件的测试方法，依据面向对象软件开发模型划分面向对象测试模型，其中单元测试、集成测试、确认测试和系统测试通过与传统的单元测试、集成测试和确认测试、系统测试进行比较，得出面向对象软件的测试内容

关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对 系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。

　　至于冒烟测试这个名称的来历，大概是从电路板测试得来的。 因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回 给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。

　　冒烟测试的说法据说是：

　　就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。

　　冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最 新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务 器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人 员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有TCL，Perl，Python及功能弱弱的批处理。用这些可 以完成系统的每日构建。

  简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费。

RUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。 RUP和类似的产品--例如面向对象的软件过程(OOSP)以及OPEN Process都是理解性的软件工程工具--把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。

一、六大经验

      迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭 代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结 束，可以鼓舞开发人员。

      管理需求。确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以被证明是捕获功能性需求的有效方法。

      基于组件的体系结构。组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。

       可视化建模。RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。

      验证软件质量。在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。

      控制软件变更。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开 发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。

 

二、统一软件开发过程RUP的二维开发模型

　　RUP软件开发生命周期是一个二维的软件开发模型。 横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代 (Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动 (Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。如图1：

三、统一软件开发过程RUP核心概念

      RUP中定义了一些核心概念，如下图：

      角色：描述某个人或者一个小组的行为与职责。RUP预先定义了很多角色。
      活动：是一个有明确目的的独立工作单元。
      工件：是活动生成、创建或修改的一段信息。

四、统一软件开发过程RUP裁剪

      RUP是一个通用的过程模板，包含了很多开发指南、制品、开发过程所涉及到的角色说明，由于它非常庞大所以对具体的开发机构和项目，用RUP时还要做裁 剪，也就是要对RUP进行配置。RUP就像一个元过程，通过对RUP进行裁剪可以得到很多不同的开发过程，这些软件开发过程可以看作RUP的具体实例。 RUP裁剪可以分为以下几步：

1) 确定本项目需要哪些工作流。RUP的9个核心工作流并不总是需要的，可以取舍。

2) 确定每个工作流需要哪些制品。

3) 确定4个阶段之间如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每个制品完成到什么程度。

4) 确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容。

5) 规划工作流内部结构。工作流涉及角色、活动及制品，他的复杂程度与项目规模即角色多少有关。最后规划工作流的内部结构，通常用活动图的形式给出。

五、开发过程中的各个阶段和里程碑

　　RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造 阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人 满意的话，可以允许项目进入下一个阶段。

1． 初始阶段

　　初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段 具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。 初始阶段结束时是第一个重要的里程碑：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。

2． 细化阶段

　　细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础 上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。 细化阶段结束时第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和 范围、结构的选择以及主要风险的解决方案。

3． 构造阶段

　　在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管 理资源及控制运作以优化成本、进度和质量。 构建阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的 产品版本也常被称为“beta”版。

4． 交付阶段

　　交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期 的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。 在交付阶段的终点是第四个里程碑：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

六、统一软件开发过程RUP的核心工作流(Core Workflows)

　　RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期 中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

1． 商业建模(Business Modeling)

      商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。

2． 需求(Requirements)

　　需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。

3． 分析和设计(Analysis & Design)

　　分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设 计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统 (Subsystem)，而描述则体现了类的对象如何协同工作实现用例的功能。 设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。 体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

4． 实现(Implementation)

　　实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

5． 测试(Test)

测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确　　认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷 的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。

6． 部署(Deployment)

　　部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打 包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

7． 配置和变更管理(Configuration & Change Management)

　　配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件 创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

8． 项目管理(Project Management)

　　软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

9． 环境(Environment)

　　环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。

七、RUP的迭代开发模式

　　RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展， 从一个迭代过程到另一个迭代过程到成为最终的系统。 传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期（见图2）。这样做的结果是到实现末期产品完成并开始测试，在 分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。

 

　　一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成 的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成 一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的 经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目（见图3）。

 

 

图3 RUP的迭代模型

　　与传统的瀑布模型相比较，迭代过程具有以下优点：

　　降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。

　　降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。

　　加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

　　由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

八、统一软件开发过程RUP的十大要素

1. 开发前景
2. 达成计划
3. 标识和减小风险
4. 分配和跟踪任务。。
5. 检查商业理由
6. 设计组件构架
7. 对产品进行增量式的构建和测试
8. 验证和评价结果
9. 管理和控制变化
10. 提供用户支持

让我们逐一的审视这些要素，看一看它们什么地方适合ＲＵＰ，找出它们能够成为十大要素的理由。
 
1. 开发一个前景
      有一个清晰的前景是开发一个满足涉众真正需求的产品的关键。 前景抓住了ＲＵＰ需求流程的要点：分析问题，理解涉众需求，定义系统，当需求变化时管理需求。 前景给更详细的技术需求提供了一个高层的、有时候是合同式的基础。正像这个术语隐含的那样，它是软件项目的一个清晰的、通常是高层的视图，能被过程中任何 决策者或者实施者借用。它捕获了非常高层的需求和设计约束，让前景的读者能理解将要开发的系统。它还提供了项目审批流程的输入，因此就与商业理由密切相 关。最后，由于前景构成了“项目是什么？”和“为什么要进行这个项目？”，所以可以把前景作为验证将来决策的方式之一。 对前景的陈述应该能回答以下问题，需要的话这些问题还可以分成更小、更详细的问题： ? 关键术语是什么？（词汇表） ? 我们尝试解决的问题是什么？（问题陈述） ? 涉众是谁？用户是谁？他们各自的需求是什么？ ? 产品的特性是什么？ ? 功能性需求是什么？（Use Cases） ? 非功能性需求是什么？ ? 设计约束是什么？

2. 达成计划
        “产品的质量只会和产品的计划一样好。” (2) 在ＲＵＰ中，软件开发计划（ＳＤＰ）综合了管理项目所需的各种信息，也许会包括一些在先启阶段开发的单独的内容。SDP必须在整个项目中被维护和更新。 ＳＤＰ定义了项目时间表（包括项目计划和迭代计划）和资源需求（资源和工具），可以根据项目进度表来跟踪项目进展。同时也指导了其他过程内容（原 文：process components）的计划：项目组织、需求管理计划、配置管理计划、问题解决计划、QA计划、测试计划、评估计划以及产品验收计划。

      在较简单的项目中，对这些计划的陈述可能只有一两句话。比如，配置管理计划可以简单的这样陈述：每天结束时，项目目录的内容将会被压缩成ZIP包，拷贝到 一个ZIP磁盘中，加上日期和版本标签，放到中央档案柜中。 软件开发计划的格式远远没有计划活动本身以及驱动这些活动的思想重要。正如Dwight D.Eisenhower所说：“plan什么也不是，planning才是一切。” “达成计划”—和列表中第3、4、5、8条一起—抓住了RUP中项目管理流程的要点。项目管理流程包括以下活动：构思项目、评估项目规模和风险、监测与控 制项目、计划和评估每个迭代和阶段。

3. 标识和减小风险
      RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具，又作为确定迭代的基础。

4. 分配和跟踪任务
      有一点在任何项目中都是重要的，即连续的分析来源于正在进行的活动和进化的产品的客观数据。在RUP中，定期的项目状态评估提供了讲述、交流和解决管理问 题、技术问题以及项目风险的机制。团队一旦发现了这些障碍物（篱笆），他们就把所有这些问题都指定一个负责人，并指定解决日期。进度应该定期跟踪，如有必 要，更新应该被发布。（原文：updates should be issued asnecessary。） 这些项目“快照”突出了需要引起管理注意的问题。随着时间的变化/虽然周期可能会变化（原文：While the period may vary。），定期的评估使经理能捕获项目的历史，并且消除任何限制进度的障碍或瓶颈。

5. 检查商业理由
      商业理由从商业的角度提供了必要的信息，以决定一个项目是否值得投资。商业理由还可以帮助开发一个实现项目前景所需的经济计划。它提供了进行项目的理由， 并建立经济约束。当项目继续时，分析人员用商业理由来正确的估算投资回报率(ROI，即return on investment)。 商业理由应该给项目创建一个简短但是引人注目的理由，而不是深入研究问题的细节，以使所有项目成员容易理解和记住它。在关键里程碑处，经理应该回顾商业理 由，计算实际的花费、预计的回报，决定项目是否继续进行。

6. 设计组件构架
      在RUP中，件系统的构架是指一个系统关键部件的组织或结构，部件之间通过接口交互，而部件是由一些更小的部件和接口组成的。即主要的部分是什么？他们又 是怎样结合在一起的？ RUP提供了一种设计、开发、验证构架的很系统的方法。在分析和设计流程中包括以下步骤：定义候选构架、精化构架、分析行为（用例分析）、设计组件。 要陈述和讨论软件构架，你必须先创建一个构架表示方式，以便描述构架的重要方面。在RUP中，构架表示由软件构架文档捕获，它给构架提供了多个视图。每个 视图都描述了某一组涉众所关心的正在进行的系统的某个方面。涉众有最终用户、设计人员、经理、系统工程师、系统管理员，等等。这个文档使系统构架师和其他 项目组成员能就与构架相关的重大决策进行有效的交流。

7. 对产品进行增量式的构建和测试
      在RUP中实现和测试流程的要点是在整个项目生命周期中增量的编码、构建、测试系统组件，在先启之后每个迭代结束时生成可执行版本。在精化阶段后期，已经 有了一个可用于评估的构架原型；如有必 要，它可以包括一个用户界面原型。然后，在构建阶段的每次迭代中，组件不断的被集成到可执行、经过测试的版本中，不断地向最终产品进化。动态及时的配置管 理和复审活动也是这个基本过程元素（原文：essential process element）的关键。

8. 验证和评价结果
      顾名思义，RUP的迭代评估捕获了迭代的结果。评估决定了迭代满足评价标准的程度，还包括学到的教训和实施的过程改进。 根据项目的规模和风险以及迭代的特点，评估可以是对演示及其结果的一条简单的纪录，也可能是一个完整的、正式的测试复审记录。 这儿的关键是既关注过程问题又关注产品问题。越早发现问题，就越没有问题。（原文：The sooner you fall behind, the more time you will have to catch up.）

9. 管理和控制变化
      RUP的配置和变更管理流程的要点是当变化发生时管理和控制项目的规模，并且贯穿整个生命周期。其目的是考虑所有的涉众需求，尽可能的满足，同时仍能及时 的交付合格的产品。 用户拿到产品的第一个原型后（往往在这之前就会要求变更），他们会要求变更。重要的是，变更的提出和管理过程始终保持一致。 在RUP中，变更请求通常用于记录和跟踪缺陷和增强功能的要求，或者对产品提出的任何其他类型的变更请求。变更请求提供了相应的手段来评估一个变更的潜在 影响，同时记录就这些变更所作出的决策。他们也帮助确保所有的项目组成员都能理解变更的潜在影响。

10. 提供用户支持
      在RUP中，部署流程的要点是包装和交付产品，同时交付有助于最终用户学习、使用和维护产品的任何必要的材料。 项目组至少要给用户提供一个用户指南（也许是通过联机帮助的方式提供），可能还有一个安装指南和版本发布说明。 根据产品的复杂度，用户也许还需要相应的培训材料。最后，通过一个材料清单（BOM表，即Bill of Materials）清楚地记录应该和产品一起交付哪些材料。 关于需求 有人看了我的要素清单后，可能会非常不同意我的选择。例如，他会问，需求在哪儿呢？他们不重要吗？我会告诉他我为什么没有把它们包括进来。有时，我会问一 个项目组（特别是内部项目的项目组）：“你们的需求是什么？”，而得到的回答却是：“我们的确没有什么需求。” 刚开始我对此非常惊讶（我有军方的宇航开发背景）。他们怎么会没有需求呢？当我进一步询问时，我发现，对他们来说，需求意味着一套外部提出的强制性的陈 述，要求他们必须怎么样，否则项目验收就不能通过。但是他们的确没有得到这样的陈述。尤其是当项目组陷入了边研究边开发的境地时，产品需求从头到尾都在演 化。 因此，我接着问他们另外一个问题：“好的，那么你们的产品的前景是什么呢？”。这时他们的眼睛亮了起来。然后，我们非常顺利的就第一个要素（“开发一个前 景”）中列出的问题进行了沟通，需求也自然而然的流动着（原文：and the requirements just flow naturally.）。 也许只有对于按照有明确需求的合同工作的项目组，在要素列表中加入“满足需求”才是有用的。请记住，我的清单仅仅意味着进行进一步讨论的一个起点。

九、总结

　　RUP具有很多长处：提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方 面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发 过程提供较大的通用性。但同时它也存在一些不足： RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；此外，它没有支持多项目的开发结构，这在一定程度上 降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端，但并不完美，在实际的应用中可以根据需要对其进行改进并可以用OPEN和 OOSP等其他软件过程的相关内容对RUP进行补充和完善。

RUP是Rational Unified Proces 的缩写，翻译成中文就是“统一软件过程”。
RUP是一个基于6个最佳开发实践的流程定义产品。

6个最佳开发实践
1、迭代始开发
2、需求管理
3、基于组建的体系架构
4、可视化建模
5、持续的质量管理
6、配置管理

RUP如何来实现6个最佳开发实践
1、把软件开发过程看成是多次迭代开发的过程，并且把迭代开发分成4个阶段
(1)Inception phase(开始阶段）
定义出项目目标和范围
(2)Elabration phase（细化阶段）
制定计划、定义项目基线、确定系统的体系架构
(3)construction phase（开发阶段）
主要是编码、单元测试工作，是人工最密集的阶段。
这个时候，虽然允许有小的需求加入进来，但是应该尽量避免大的需求变动。
(4)Transition phase（发布阶段）
将产品提交给用户适用。包括相关的培训等内容

注意：每个阶段有若干次迭代组成。

可以看出RUP虽然是基于迭代式开发，但是在整体的4个阶段划分上还是类时与瀑布式开发的软件过程。


2、定义出一次迭代开发所要遵循的9个disciplines
(1) bussiness modeling
(2) requirements
(3)Analysis & Design
(4) Implementaion
(5) Test
(6) Deployment
(7) Project Management
(8) Configration & change Management
(9)Enviroment
其中前6个称为 core engineering workflows,后3个称为supporting workflows

在每次迭代中，我们都要经历所有的disciplines
其实，RUP的所定义的9个disciplines，跟瀑布式开发是向类时的。（需求－》分析、设计－》开发－》测试－》部署）

四、RUP本质的揭示
1、RUP是风险驱动的、基于Use Case技术的、以架构为中心的、迭代的、可配置的软件开发流程。
2、我们可以针对RUP所规定出的流程，进行客户化定制，定制出适合自己组织的实用的软件流程。
因此RUP是一个流程定义平台，是一个流程框架。

虽然FP已经列了很多的测试书籍了，但是还是看到会有人问看什么书，我在这里把我自己看的书贴出来（包括已经买了，没有看完和没有来得及看的）。

测试书籍：
《软件测试（原书第2版）》
建议先看这本，这本书是软件测试界的经典书籍，里面的很多理论都写的不错，而且翻译的不错。
【原书名】     Software Testing (2nd Edition) [原书信息]
【原出版社】   Sams
【作者】   （美）Ron Patton[同作者作品] [作译者介绍]
【译者】   张小松[同译者作品] 王钰 曹跃 等
【丛书名】   计算机科学丛书
【出版社】   机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=29706

《软件测试的艺术（原书第2版）》
这本书技术性强，建议大家现看《软件测试》再来看这本书
【原书名】     The Art of Software Testing, Second Edition [原书信息]
【原出版社】   John Wiley & Sons
【作者】   （美）Glenford J.Myers 等[同作者作品] [作译者介绍]
【译者】   王峰[同译者作品] 陈杰
【丛书名】   软件工程技术丛书
出版社】   机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=27827


《面向对象的软件测试》
这本书挺难得，如果没有面向对象编程基础就不要看了，看不懂的
【原书名】     A Practical Guide to Testing Object Oriented Software [原书信息]
【原出版社】   Addison Wesley
【作者】   John D.McGregor David A.sykes 著[同作者作品]
【译者】   杨文宏[同译者作品] 李新辉 杨洁 译等
【丛书名】   软件工程技术丛书
【出版社】   机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=7078

《软件测试自动化》
【原书名】     Just Enough Software Test Automation [原书信息]
【原出版社】   Prentice Hall PTR
【作者】   （美）Daniel J.Mosley,Bruce A.Posey[同作者作品]
【译者】   邓波[同译者作品] 黄丽娟 曹青春
【丛书名】   软件工程技术丛书/测试系列
【出版社】   机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=14358

《软件评测师教程》这本书涉及面很广，不过过于理论了，有些地方写的不好不是很看地懂（可能个人水品有限吧，这个考试最近开始火了，不错好像很难考）！
【作者】   全国计算机技术与软件专业技术资格（水平）考试办公室组 柳纯录 黄子河 等[同作者作品]
【丛书名】   全国计算机技术与软件专业技术资格（水平）考试指定用书
【出版社】   清华大学出版社
http://www.china-pub.com/computers/common/info.asp?id=23803

以下的书是有关思想方面的书籍，或者说思考书籍，都是由Gerald M.Weinberg（温伯格）写的，这个人的书籍强调思考，强调本质，大家有了时间可以看看。

《质量·软件·管理：系统思维（第1卷）》
系统的讲述了什么是质量，质量的本质，不过本书本人还没有看完
作者：（美）温伯格 著，邓俊辉 译
出版社：清华大学出版社
系列：软件与系统思想家温伯格精粹译丛
http://www.dangdang.com/product/8867/8867166.shtml

《你的灯亮着吗》
这本书讲了如何思考，不错的
【原书名】     Are Your Lights On? How to Figure Out What the Problem Really Is [原书信息]
【原出版社】   Dorset House
【作者】   （美）Donald C.Gause;Gerald M.Weinberg
【译者】   章柏幸[同译者作品] 刘敏
【丛书名】   软件与系统思想家温伯格精粹译丛
【出版社】   清华大学出版社
http://www.china-pub.com/computers/common/info.asp?id=9919

以下的书籍都没有看过，不过都买好了：

质量·软件·管理（第Ⅱ卷）：一阶测量
还未看
【原书名】     Quality Software Management: First-Order Measurement [原书信息]
【原出版社】   Dorset House Publishing Co.,Inc.
【作者】   （美）Gerald M. Weinberg[同作者作品]
【译者】   李先华[同译者作品] 邢彦 张红艺
【丛书名】   软件与系统思想家温伯格精粹译丛
【出版社】   清华大学出版社
http://www.china-pub.com/computers/common/info.asp?id=27538

《质量·软件·管理--协调行动（第Ⅲ卷）》
还未看
【原书名】     Quality Software Management: First-Order Measurement [原书信息]
【原出版社】   Dorset House Publishing Co.,Inc.
【作者】   （美）Gerald M. Weinberg[同作者作品]
【译者】   李先华[同译者作品] 邢彦 张红艺
【丛书名】   软件与系统思想家温伯格精粹译丛
【出版社】   清华大学出版社
http://www.china-pub.com/computers/common/info.asp?id=26184

《软件自动化测试：引入、管理与实施》
【原书名】     Automated Software Testing Introduction，Management，and Performance
【原出版社】   Pearson Education
【作者】   （美）Elfriede Dustin Jeff Rashka John Paul[同作者作品]
【译者】   于秀山[同译者作品] 胡兢玉 等
【丛书名】   国外IT精品丛书
【出版社】   电子工业出版社
http://www.china-pub.com/computers/common/info.asp?id=8531

《软件子系统测试》
【原书名】     The Craft of Software Testing:Subsystem Testing,Including Object-Based and Object-Oriented Testing [原书信息]
【原出版社】   Prentice Hall PTR
【作者】   （美）Brian Marick[同作者作品]
【译者】   韩柯[同译者作品]
【丛书名】   软件工程技术丛书/测试系列
【出版社】   机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=14355

《软件测试：经验与教训》
【原书名】     Lessons Learned in Software Testing [原书信息]
【原出版社】   John Wiley & sons,Inc.
【作者】   （美）Cem Kaner,James Bach,Bret Pettichord[同作者作品] [作译者介绍]
【译者】   韩柯[同译者作品]
【丛书名】   软件工程技术丛书/测试系列
【出版社】   机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=14718

PC Magazine 2009最佳免费软件173款

PC Magazine2评出的009年度誉奖免费软件共13款：Audacity、iTunes、Winamp、Firefox、IE 8 Beta、Opera、Thunderbird、Adobe Reader、GIMP、AIM、Notepad++、OpenOffice、Ubuntu。 全部173款名单如下：

程序启动
1. Circle Dock
2. ObjectDock
3. Launchy
4. Quicksilver

音频
5. Audacity [年度荣誉奖]
6. Banshee
7. EphPod
8. foobar2000
9. imeem (formerly Anywhere.FM)
10. iTunes [年度荣誉奖]
11. Mojo
12. Songbird
13. Screamer Radio
14. WavePad Sound Editor
15. Winamp [年度荣誉奖]

备份
16. DriveImage XML
17. MozBackup
18. MozyHome Free
19. SpiderOak
20. SyncToy v2.0
21. SyncBack Freeware

博客
22. ScribeFire
23. TweetDeck
24. Twitteriffic
25. Zoundry Raven
26. twhirl
27. Ustream.tv
28. WordPress.com
29. Windows Live Writer

浏览器
30. Camino
31. Flock 2
32. Firefox [年度荣誉奖]
33. FoxReplace
34. Google Chrome
35. Internet Explorer 8 Beta [年度荣誉奖]
36. Opera [年度荣誉奖]
37. OperaTor
38. Safari
39. 30 Boxes

日历/PIM
40. Calgoo Calendar
41. Doomi
42. Google Calendar
43. Lightning
44. Chandler
45. Remember The Milk
46. Remember The Task
47. TaskFive
48. Yahoo Calendar

Email/交流
49. eM Client
50. Gmail
51. gAttach
52. Google Contacts
53. iContact
54. Simple Mail
55. Thunderbird [年度荣誉奖]
56. Windows Live Mail
57. Yahoo Mail
58. Zenbe
会议
59. Dabbleboard
60. SightSpeed
61. Skype
62. Tokbox

文件传输/下载
63. CrossFTP
64. DownThemAll
65. Filezilla
66. FireFTP
67. Halite
68. net2ftp
69. Rightload
70. uTorrent

文件查看/转换
71. Adobe Reader [年度荣誉奖]
72. Foxit Reader
73. PeaZip
74. Sumatra PDF
75. Quick Media Converter (QMC)
76. WinRAR
77. YemuZip
78. Zamzar

财务管理
79. Billeo
80. Buxfer
81. Mint
82. Wesabe

有趣/家用
83. eBay Desktop
84. Geni.com
85. Google Earth
86. Home Inventory
87. Penzu
88. Springpad
89. Timetoast

图形图像
90. Artweaver
91. DestroyFlickr
92. flauntR
93. FastStone Image Viewer
94. GIMP [年度荣誉奖]
95. Google SketchUp
96. IrfanView
97. Paint.NET
98. Pencil
99. Picasa
100. MobaPhoto
101. Photoshop Express
102. Photosynth
103. Picnik
104. Pictomio
105. Splashup
106. SUMO Paint

即时通讯
107. AIM [年度荣誉奖]
108. Dexrex
109. Digsby
110. Meebo

界面强化
111. AccelMan File Manager
112. Desktops
113. DExposE2
114. Emerge Desktop
115. GreenPrint
116. muCommander
117. PlacesBar Tweaker
118. RBTray
119. StandaloneStack
120. Start++
121. TrayEverything
122. UltraExplorer
123. Yahoo Widgets

本地搜索
124. Google Desktop
125. Everything
126. Locate32
127. Adobe Buzzword

办公
128. blist
129. EtherPad
130. Evernote
131. GMDesk
132. Google Docs
133. Incollector
134. Jarte
135. KompoZer
136. Lotus Symphony
137. LucidChart
138. NeoOffice
139. Notepad++ [年度荣誉奖]
140. OpenOffice [年度荣誉奖]
141. SlideRocket
142. SoftMaker Office 2006
143. Springnote
144. Widgenie
145. Zoho

操作系统
146. gOS 3.0 Gadgets
147. pure:dyne
148. Ubuntu [年度荣誉奖]

网络
149. AirSnare
150. AirRadar
151. Axence NetTools
152. GBridge
153. InSSIDer
154. LogMeIn Hamachi
155. NetSetMan
156. Network Notepad
157. PrinterAnywhere

RSS阅读
158. Google Reader
159. Netvibes
160. FeedDemon
161. NetNewsWire
162. RSS Bandit
163. Snarfer

同步
164. Dropbox
165. Windows Live Sync
166. Windows Live Mesh
167. Syncplicity
168. Mozilla Weave

视频
169. CamStudio
170. HandBrake
171. Miro
172. TipCam
173. VLC media player