数据库，对任何一个系统来说，都是基础，所以qtp脚本自然不能避免和数据库打交道。

首先我们需要在odbc数据源中定义一个系统dsn，配置我们的服务器名和用户名。

然后我们就可以在dba中访问这个数据库了：建立数据库链接，查询或更新数据库数据内容。

数据库的访问，无疑可以说是公共的，任何一个脚本只要向数据库发送请求，就需要写相同的脚本，完全可以把这部分内容进行抽取，形成公共函数调用。公共函数保存在 *.vbs文件中。

'----------------------------------------------------------------
'函数名：OpenConnection(DataSource)
'参数说明：DataSource 数据源
'作用：链接数据库
'-----------------------------------------------------------------
Function OpenConnection(DataSource)
Dim cnn
Set cnn = CreateObject("ADODB.Connection")
If DataSource = "vcc" Then
        cnn.ConnectionString = "Provider=MSDASQL.1;Persist Security Info=true;User ID=vcctest;Password=vcc;Data Source=vcc"
End If
cnn.Open
Set penConnection = cnn
End Function

'----------------------------------------------------------------
'函数名：DataOperate(DataSource,sql,optype)
'参数说明：DataSource 数据源,sql 删除sql语句记录,optype 操作类型“query”、“insert”、“update”、“delete”
'作用：根据sql和datasource更新记录
'-----------------------------------------------------------------
Function DataOperate(DataSource,sql,optype)
Dim cnn,rs
cnn = OpenConnection(DataSource)
Set rs = CreateObject("ADODB.RecordSet")
rs.open sql,cnn,1,1
DataOperate = null

If ptype = "query" Then
'   rs.open sql,cnn,1,1
   If not rs.eof Then
    DataOperate = rs.Fields(0).value
   End If
   rs.close
elseif ptype = "insert" or ptype = "update" or ptype="delete" then
'   rs.open sql,cnn,1,3
   rs.open "commit",cnn,1,1
End If
Set rs = nothing
End Function

----单独的查询、更新、插入、删除函数---------

'----------------------------------------------------------------
'函数名：GetOne(DataSource,sql)
'参数说明：DataSource 数据源,sql 查询sql语句
'作用：根据sql和datasource获取一条查询记录
'-----------------------------------------------------------------
Function GetOne(DataSource,sql)
   Dim cnn,rs
   cnn = OpenConnection(DataSource)
   Set rs = CreateObject("ADODB.RecordSet")
   rs.open sql,cnn,1,1
   GetOne = null
   '如果结果集有记录，且不是指向结果集最后，rs.eof = false
   If not rs.eof Then
    GetOne = rs.Fields(0).value
   End If
   Set rs = nothing
End Function

'----------------------------------------------------------------
'函数名：InsertOne(DataSource,sql)
'参数说明：DataSource 数据源,sql 插入sql语句记录
'作用：根据sql和datasource插入新记录
'-----------------------------------------------------------------
Function InsertOne(DataSource,sql)
   Dim cnn,rs
   cnn = OpenConnection(DataSource)
   rs = CreateObject("ADODB.RescordSet")
   rs.open sql,cnn,1,1
   rs.open "commit",cnn,1,1
   Set rs = nothing
End Function

'----------------------------------------------------------------
'函数名：UpdateOne(DataSource,sql)
'参数说明：DataSource 数据源,sql 更新sql语句记录
'作用：根据sql和datasource更新记录
'-----------------------------------------------------------------
Function UpdateOne(DataSource,sql)
   Dim cnn,rs
   cnn = OpenConnection(DataSource)
   Set rs = createObject("ADODB.RecordSet")
   rs.open sql,cnn,1,1
   rs.open "commit",cnn,1,1
   Set rs = nothing
End Function

'----------------------------------------------------------------
'函数名：DeteleOne(DataSource,sql)
'参数说明：DataSource 数据源,sql 删除sql语句记录
'作用：根据sql和datasource更新记录
'-----------------------------------------------------------------
Function DeleteOne(DataSource,sql)
   Dim cnn,rs
   cnn = OpenConnection(DataSource)
   Set rs = CreateObject("ADODB.RecordSet")
   rs.open sql,cnn,1,1
   rs.open "commit",cnn,1,1
   Set rs = nothing
End Function

转自 http://hi.baidu.com/hihelens/blog/item/4baee5247b8d052cd5074232.html

什么是数据库，其实很简单，数据库就是存储数据的一种媒介。比如常用的文件就是一种，在Oracle10G中，数据的存储有好几种。第一种是文件形 式，也就是在你的磁盘中创建一批文件，然后在这些文件中存储信息。第二种就是磁盘阵列形式，这个是什么意思呢，这个就是说明数据库不是存放为某个文件，而 是把一个或者多个磁盘格式化成Oracle的一种格式了，等于整个磁盘就是存放Oracle数据库的，不能作为别的用途。这样的优点是存储性能高，因为不 再借助别的文件格式了，而是把整个磁盘都成为Oracle最适应的文件系统格式。当然还可能有别的形式，比如网络什么的。不过我们最常用的还是文件格式 的，在文件格式中，数据库指的就是那些数据文件，控制文件以及REDO文件等等一系列文件。

　　而什么是Instance呢，Instance其实就是指的操作系统中一系列的进程以及为这些进程所分配的内存块。在Oracle中，我们可以 新建一个Oracle的Instance，这个时候虽然有了进程还有SGA等一系列的内存快，但是这个时候并没有把数据库文件读取进来。所以只是一个实 例，在后来，你可以通过命令手动或者自动地把数据库文件加载进我们的数据库Instance中，这个时候的数据库才可以让我们真正的开始访问操作。

　　所以说，数据库的应用如果想实现，数据库和数据库Instance是缺一不可的，如果只有数据库的那些文件，那么，只能代表数据在这个文件中， 但是我们无法直接进行操作。而如果只有数据库Instance，那么我们虽然可以急性操作，但是也不知道操作哪些数据，操作生成的数据也无法保存等等。所 以，当一个Oracle Instance真正Load了一个Oracle Database了以后，数据库才可以被我们使用。

　　在这里要注意一点的是，Oracle的实例在启动以后，只能load一次数据库，如果想把数据库与Instance断开，然后再重新挂在一个数 据库Instance，那么就需要你首先把数据库Instance进程结束，然后重新建立这个instance的一个进程，再load另外一个数据库。否 则肯定要抛除ORA-16169错误，说数据库已经被打开。因为一个数据库Instance在其生存期中最多只能load和打开一个instance。

 

ORACLE实例 = 进程 + 进程所使用的内存(SGA)
实例是一个临时性的东西，你也可以认为它代表了数据库某一时刻的状态！
数据库 = 重做文件 + 控制文件 + 数据文件 + 临时文件
数据库是永久的，是一个文件的集合。
ORACLE实例和数据库之间的关系
1.
临时性和永久性
2.
实例可以在没有数据文件的情况下单独启动 startup nomount , 通常没什么意义
3.
一个实例在其生存期内只能装载(alter database mount)和打开(alter database open)一个数据库
4.
一个数据库可被许多实例同时装载和打开(即RAC)，RAC环境中实例的作用能够得到充分的体现!

下面对实例和数据库做详细的诠释：
在Oracle领域中有两个词很容易混淆，这就是“实例”（instance）和“数据库”（database）。作为Oracle术语，这两个词的定义如下：
q
数据库（database）：物理操作系统文件或磁盘（disk）的集合。使用Oracle 10g的自动存储管理（Automatic Storage Management，ASM）或RAW分区时，数据库可能不作为操作系统中单独的文件，但定义仍然不变。
q
实 例（instance）：一组Oracle后台进程/线程以及一个共享内存区，这些内存由同一个计算机上运行的线程/进程所共享。这里可以维护易失的、非 持久性内容（有些可以刷新输出到磁盘）。就算没有磁盘存储，数据库实例也能存在。也许实例不能算是世界上最有用的事物，不过你完全可以把它想成是最有用的 事物，这有助于对实例和数据库划清界线。
这两个词有时可互换使用，不过二者的概念完全不同。实例和数据库之间的关系是：数据库可以由多个实例装载和打开，而实例可以在任何时间点装载和打开一个数据库。实际上，准确地讲，实例在其整个生存期中最多能装载和打开一个数据库！稍后就会介绍这样的一个例子。
是 不是更糊涂了？我们还会做进一步的解释，应该能帮助你搞清楚这些概念。实例就是一组操作系统进程（或者是一个多线程的进程）以及一些内存。这些进程可以操 作数据库；而数据库只是一个文件集合（包括数据文件、临时文件、重做日志文件和控制文件）。在任何时刻，一个实例只能有一组相关的文件（与一个数据库关 联）。大多数情况下，反过来也成立：一个数据库上只有一个实例对其进行操作。不过，Oracle的真正应用集群（Real Application Clusters，RAC）是一个例外，这是Oracle提供的一个选项，允许在集群环境中的多台计算机上操作，这样就可以有多台实例同时装载并打开一个 数据库（位于一组共享物理磁盘上）。由此，我们可以同时从多台不同的计算机访问这个数据库。Oracle RAC能支持高度可用的系统，可用于构建可扩缩性极好的解决方案。

数据库的体系结构是指数据库的组成、工作过程与原理，以及数据在数据库中的组织与管理机制
1.2.1 ORACLE服务器
Oracle服务器由Oracle数据库和Oracle实例组成。Oracle数据库是一个数据的集合，该集合被视为一个逻辑单元。在一个装有 Oracle数据库的服务器上，必须运行一系列进程来管理该数据库。这些进程使用大块的内存，这些内存块分别具有与特定任务相关的用途。
后台进程和内存结构的集合称为Oracle实例。如果要访问数据库中的数据，就需启动该实例。每一个运行的Oracle数据库都与一个Oracle实例相联系。

1.2.2 ORACLE组件

实例、用户进程和服务器进程驻留在内存中，而所有其他文件都存储在硬盘上。

 Oracle实例：
Oracle实例是后台进程和内存结构的集合。必须启动实例才能访问数据库中的数据。Oracle实例启动时，将分配一个系统全局区（ＳＧＡ）并启动一系列Oracle后台进程。每一个后台进程在数据库中执行不同的任务。一个实例只能打开并使用一个数据库。

 Oracle数据库：
Oracle数据库由操作系统文件组成，这些文件也称为数据库文件，为数据库信息提供实际物理存储区。Oracle数据库包括逻辑结构和物理结 构。数据库的物理结构包含数据库中的一组操作系统文件。数据库的逻辑结构是指数据库创建之后形成的逻辑概念之间的关系，如表、视图、索引等对象。


 会话：
会话是用户与Oracle服务器的单个连接。当用户与服务器建立连接时创建会话。当用户与服务器断开连接时关闭会话。当一个数据库用户同时用多个不同的应用程序或从多个终端连接数据库时，则为该用户创建多个并行会话。

 Oracle实例内存结构：
Oracle的内存结构包含以下两个内存区：

 系统全局区：（ＳＧＡ）：实例启动时分配该内存区。
Oracle实例的ＳＧＡ（System Global Area）又称为共享全局区，它用来存储数据库信息，并由多个数据库进程共享。当数据库实例启动时，ＳＧＡ的内存被自动分配。ＳＧＡ是数据库中占用服务器 内存最大的一个区域，同时也是影响数据库性能的一个重要指标。ＳＧＡ按其作用不同，可以分为共享池、数据缓冲区及日志缓冲区。
 共享池
共享池是对SQL、PL/SQL程序进行语法分析、编译、执行的内存区域
共享池由库缓存和数据字典缓存组成。
共享池的大小直接影响数据库的性能。

 数据缓冲区
用于存储从磁盘数据文件中读入的数据，所有用户共享。
服务器进程将读入的数据保存在数据缓冲区中，当后续的请求需要这些数据时可以在内存中找到，不需要再从磁盘读取，提高了读取速度。
数据缓冲区的大小对数据库的读取速度有直接的影响。

 日志缓冲区
日志记录数据库的所有修改信息，日志信息首先产生于日志缓冲区。
当日志缓冲区的日志数据达到一定数量时，由后台进程将日志数据写入日志文件中。相对来说，日志缓冲区对数据库的性能影响较小。

 程序全局区：（ＰＧＡ）：服务器进程启动时分配该内存区。
程序全局区ＰＧＡ（Program Global Area）包含单个服务器进程或单个后台进程所需的数据和控制信息。ＰＧＡ是在用户进程连接到数据库并创建一个会话时自动分配的，该区内保留每个与 Oracle数据库连接的用户进程所需的内存。ＰＧＡ为非共享区，只能单个进程使用，当一个用户会话结束后，ＰＧＡ释放。

 Oracle实例进程结构：

 用户进程：
用户进程是一个需要与Oracle服务器进行交互的程序。此进程在数据库用户请求连接Oracle服务器时启动。如用户启动数据库客户端工具SQL *Plus时，系统自动建立一个用户进程。

 服务器进程：
服务器进程用于处理连接到该实例的用户进程的请求。此进程在用户建立会话并连接Oracle实例时启动。服务器进程直接与Oracle数据库交互，实现调用和返回结果。

 后台进程：
在Oracle数据库中，为了使系统性能最好和协调多个用户，实例系统中使用一些附加进程，称为后台进程。这些后台进程存在于服务器操作系统中，在实例启动时自动启动。
常用的几个后台进程如下所示：

 进程监控：（PMON）
在用户进程出现故障时执行进程恢复。（常见任务见书７）
 系统监控：（SMON）
在实例启动时执行实例恢复。（常见任务见书７）
 数据写入进程：（DBWR）
将所有修改后的缓冲区数据写入数据文件。（常见任务见书８）
 日志写入进程：（LGWR）
将日志缓冲区中的日志数据信息写入日志文件中。
 检查点：（CKPT）
保证所有修改过的数据库缓冲区数据都被写入数据库文件中。
 归档进程：（ARCH）
当数据库运行在归档模式下时，产生该进程，用于写归档日志文件。

1.2.3 ORACLE的物理组件
数据库的物理组件是指从物理角度分析数据库的组成，也就是Oracle数据库创建后使用的操作系统物理文件。Oracle数据库的物理文件可分为三类，即数据文件、日志文件和控制文件。

 数据文件：（SYSTEM01.DBF／SYSTEM01.ORA）
数据文件（Data Files）用于存储数据库数据的文件。如表、索引等数据都是存储在数据文件中。每个Oracle数据库有一个或多个物理数据文件。一个数据文件只能与一个数据库关联。
 日志文件：（REDO01.LOG）
日志文件（Redo Log Files）用于记录对数据库所进行的修改。日志文件主要用于在数据库出现故障时实施数据库恢复。

 控制文件：（CONTROL01.CTL）
控制文件（Control Files）用于记录数据库物理结构的二进制文件。该文件包含维护和验证数据库完整性的必要信息。

1.2.4 ORACLE的逻辑组件
数据库的逻辑组件是从逻辑的角度分析数据库的组成。Oracle对于逻辑结构的描述是通过数据字典存储完成的。Oracle数据库的逻辑组件包括
表空间、段、区、块和用户模式等。

 表空间（TABLESPACE）：
表空间是数据库中最大的逻辑单位，Oracle数据库采用表空间将相关的逻辑组件组合在一起，一个Oracle数据库至少包含一个表空间。每个表空间由一个或多个数据文件组成，一个数据文件只能与一个表空间相联系。
在每一个数据库中都有一个名为SYSTEM的表空间，即系统表空间，该表空间是在创建数据库或数据库安装时自动创建的，用于存储系统的数据字典表、程序单元、过程、函数、包和触发器等。
创建表空间的语法如下：

扩展数据文件的语法如下:


 段（SEGMENT）：
一个表空间包含一个或多个段。段是一种指定类型的逻辑存储结构一个段由多个区组成。如常用的４类段结构：
（数据段——索引段——回滚段——临时段）
 区（EXTENT）：
区是磁盘空间分配的最小单位。磁盘按区划分，每次至少分配一个区。区为段分配空间，它由连续的数据块组成。一个区由多个数据块组成，块是进行数据读写操作的最小单元。
 数据块（DATA BLOCK）：
数据块是数据库中最小的数据组织单位与管理单位，Oracle数据库中的数据存储于数据块中。数据块的取值范围在2KB~64KB之间。
 模式（SCHEMA）：
模式是对用户所创建的数据库对象的总称，在Oracle数据库中任何数据库对象都属于一个特定用户，一个用户及其所拥有的对象即称为模式。模式对象包括表、视图、索引、同义词、序列、过程和程序包等。一个用户与相同名称的模式相关联，所以又称为用户模式。

本文主要是对Oracle数据库中service_name、tablespace、schema、user四者之间的关系一些分析与实际应用中的举例。
　　首先简单总结一下：
　　1. service name 服务名(其实揍是：数据库名)，装 ORACLE 时肯定要指定的一个名字
　　2. tablespace 表空间，数据库对象的磁盘存储位置
　　3. schema 方案，数据库对象的逻辑分类
　　4. user 用户，等同于 schema
　　5. service name > tablespace > schema(user)
　　详细说明：
　　schema 为数据库对象的集合，为了区分各个集合，我们需要给这个集合起个名字，这些名字就是我们在企业管理器的 schema 下看到的许多类似用户名的节点，这些类似用户名的节点其实就是一个schema，schema 里面包含了各种对象如：tables，views，sequences，stored procedures，synonyms，indexes，clusters，and database links。
　　一个用户(user) 一般对应一个 schema，该用户的 schema 名等于用户名，并作为该用户缺省的 schema。这也就是我们在企业管理器的 schema 下看到 schema 名都为数据库用户名的原因。Oracle 数据库中不能新创建一个 schema，要想创建一个 schema，只能通过创建一个 user 的方法解决(Oracle 中虽然有 create schema 语句，但是它并不是用来创建一个 schema 的)，在创建一个 user 的同时为这个 user 创建一个与用户名同名的 schem 并作为该用户的缺省 shcema。即 schema 的个数同 user 的个数相同，而且 schema 名字同 user 名字一一对应并且相同，所有我们可以称 schema 为 user 的别名，虽然这样说并不准确，但是更容易理解一些。
　　一个 user 有一个缺省的 schema，其 schema 名就等于用户名，当然一个 user 还可以使用其他的 schema。如果我们访问一个表时，没有指明该表属于哪一个 schema 中的，系统就会自动给我们在表上加上缺省的 sheman 名。比如我们在访问数据库时，访问 scott 用户下的 emp 表，通过select * from emp; 其实，这 sql 语句的完整写法为 select * from scott.emp。在数据库中一个对象的完整名称为 schema.object，而不属 user.object。类似如果我们在创建对象时不指定该对象的 schema，在该对象的 schema 为 user 的缺省 schema。这就像一个 user 有一个缺省的 tablespace，但是该 user 还可以使用其他的 tablespace，如果我们在创建对象时不指定 tablespace，则对象存储在缺省 tablespace 中，要想让对象存储在其他 tablespace 中，我们需要在创建对象时指定该对象的 tablespace。
　　举例如下： 　　SQL> Gruant dba to scott 　　SQL> create table test(name char(10)); 　　Table created. 　　SQL> create table system.test(name char(10)); 　　Table created. 　　SQL> insert into test values('scott'); 　　1 row created. 　　SQL> insert into system.test values('system'); 　　1 row created. 　　SQL> commit; 　　Commit complete. 　　SQL> conn system/manager 　　Connected. 　　SQL> select * from test; 　　NAME 　　---------- 　　system 　　SQL> ALTER SESSION SET CURRENT_SCHEMA = scott; --改变用户缺省schema名 　　Session altered. 　　SQL> select * from test; 　　NAME 　　---------- 　　scott 　　SQL> select owner ,table_name from dba_tables where table_name=upper('test'); 　　OWNER TABLE_NAME 　　------------------------------ ------------------------------ 　　SCOTT TEST 　　SYSTEM TEST ------------------------------ ------------------------------

　　--上面这个查询就是将 schema 作为 user 的别名的依据。实际上在使用上，shcema 与 user 完全一样，没有什么区别，在出现 schema 名的地方也可以出现 user 名。

　　schema 和 user 一般是一致的，建立一个 user 后即可得到一个 schema，如：HR 用户建立后便有 HR 方案，接下来建立表、索引等数据库对象时，要指定其属于哪个 schema，也要指定其存放在哪个 tablespace 里。

　　也可以这样理解，schema 是数据库对象的逻辑归属和分类，而 tablespace 是数据库对象的物理和实际存放位置。

原文出处：http：//tech.ccidnet.com/art/1107/20100720/2121277_1.html

以为早已经忘掉了

为什么一收到他的消息

还是脸红心跳呢

Recover from rm

#!/bin/bash

   NO=3
   sqlplus u0510b/creditderivative@\"//172.20.30.13:1521/shacolb\" <<EOF >log.txt
      select jobid from f3jobrunning where jobname='Empty Task ${NO}';
      quit;
   EOF

<转载>

1．Interview我要找工作

常用应急场景

范例一：I am working on it

Hi, Monica, how is everything going?

Everything goes well, but I am thinking about quitting my current job.

Why? You’re not satisfied anymore?

I just sense. But I cannot grow anymore. My boss is not really supporting me. I am interested in some positions in other JV companies, but I need to do some more in-step research before I send my application letters out.

That is important. Doing research on a company you are interested in will definitely help your application.

Certainly, it is very nice talking with you. But I really have to go now. Catch you later.

Ok, good luck to you.

范例二：Calling a company

ABC Company, my name is Lucy. How can I help you?

Hello, Lucy, this is Monica. I’m calling for the accountant position. I saw the information about the vacancy on your company’s website. Is it still available?

Thank you for your interest. The position is still available. Have you already sent your CV to us?

No, not yet. First, I want to check about the availability and see if you could give more information.

It is urgent for us to fill this position now and I would like to stress that English is a must because of the international contacts and most likely traveling abroad very soon. If all these is not problem for you, I recommend you to mention these in your cover letter and send it to me directly.

The notification period of my current job is not that long and I’m quite profession to English and I am happy with the traveling abroad as I’m good dealing with the people from other cultures. It makes the whole job even more interesting. I will send my resume to you still this week.

范例三：E-resume or paper resume

Hello, Lucy. This is Monica again. I have a question.

Please ask.

I was wondering what kind of resume do you prefer, an e-resume or paper one?

For this position we prefer e-resume at the very beginning. Please send it to our department’s e-mail box.

Ok, thank you.

You’re welcome.

2.接到猎头电话

常用应急场景

范例一：A call from a head-hunter

R: Hello, I am Richard from the Brooks Head-hunter company. Can I have a private talk with you?

M: Er? I am driving right now. Can you call back in 30 minutes?

R: Sure.

R: Hi, Monica, Richard again. Have you ever heard about our company? It is an international one with good reputation. We have a lot of successful cases. If you’re trying advance your career, I would love to help you. XYZ Company is one of our clients. They’re in need of the talent like you. Would you be interested in taking part in an interview? It is scheduled some time within this week.

M: Thank you for calling. I really appreciate your kindness. But right now, I’m very busy preparing for an interview of another company. I don’t think I am available for this opportunity.

R: Ok, I see. Good luck to you. You have my number. Call me when you change your mind. I can send you more detailed information about company and jobs you might be interested in if you give me your private e-mail address.

M: Well, I will text to you. Thank you, bye for now.

R: You’re welcome. Bye.

3.第一次去公司

常用应急场景

范例一：How can I get there?

Hello, this is Lucy from ABC Company. Is this Monica?

Yes, it is.

I am calling to inform. you that we have arranged an interview for this accountant position at 2 PM this Thursday afternoon. Please come on time.

Ok, thank you. By the way, could you please tell me how I can get there from A community?

Oh, you can take the subway, get off at B stop and walk north for several minutes. You will find a building. It will take about 40 minutes in total.

I got it. Thank you so much.

You’re welcome.

范例二：Could you show me the way?

Excuse me, could you please show me the way to the human resource department?

Yeah, but have you made an appointment ahead?

Yes, of course. I am Monica. I have made an appointment with your HR manager.

Just a minute please. I’ll make a call to the HR office.

Yes, they confirm your appointment. Please come in. it is on the 3rd floor, room 3106. You can take the right elevator as the left on is in maintenance today.

Thank you very much.

You’re welcome.

4.初次面试

常用应急场景

范例一：Three rounds is successful

Good afternoon. How can I help you?

Good afternoon. My name is Monica. I am here for the job interview at 2 PM.

Ok, please first fill in the form. and return it to me. You can do it in the next door.

Done. Here is my paper.

Everybody attention. I would like to make sure you all know the process. The interview consists of three parts. One, all of the interviewees will answer the question there and lasts for maximum one hour. Two, we will take a 30-minute’s break. After the break, we all come back to this office and I will announce the successful candidates for the 2nd round. In which, you have a small interview with your future manager.

What about the 3rd round?

Good question. But I will tell you when you pass the first two.

范例二：Meeting the manager

Good afternoon. I suppose you are Ms. Monica. My name is Mr. Thomas, the general manager of ABC Company. Here is my business card.

Thank you very much.

I am very impressed by your resume. Therefore, I am very interested to know why you’re willing to leave your current company.

I am looking for a more challenging position. I can’t grow anymore in my current job.

Ok, I understand. But why you choose us to work for?

I have studied carefully the information about your company on the internet and I have checked your company’s homepage. I am impressed by the company. And I like the products a lot. Since you’re growing steadily, I would be very eager to help you to improve your accounting system.

How do you work with a team?

I work quite well with a team. I’m a good team player. I respect people, cooperate well with member’s team. And I will do my best to help team members.

What’s your long term goal?

I’d like to bring to ABC Company not only my technical skills, ambition, enthusiasm, but also my loyalty, a sensor desire to become an administrative assistant. It is the hardest of my career plans.

5.面试终于结束了

常用应急场景

范例一：It is enough for today

It is enough for today. Do you have any last question? If not, thank you for taking your time to come to our interview.

You’re welcome. For the moment, I have no further questions. I got a good picture of the job and the company. All my questions have been answered. Thank you for your time.

We will have an internal discussion and then we will contact to inform. you of our decision on whether we continue with you or not.

Ok, it was very nice to talk with you and I look forward to your decision at your earliest convenience. Bye.

Goodbye.

范例二：Still a little on the edge

Any plans tonight?

Not really, do you?

Well, I am wondering if we took a hang-out for a drink or something. You know, I just came back from a really tough interview. I was quite nervous during the interview. I really want to have the job. Right now, I am still a little on the edge. I am not sure if I could convince them during the interview.

Take it easy. It is all over now. How was it going, anyway?

I don’t know. I think I did well in the paper exams. I was prepared to answer a lot of questions, but they didn’t ask those as I expected. To my surprise, the manager tried to talk about the Chinese poesy with me.

That’s strange. But probably, it is the new interview technique they call it “Getting to know you more personally”. What about your answers?

Just did my best.

 

6.复试通知

常用应急场景

范例一：Please come for the next round

Hello. This is Lucy from ABC Company. Is this Monica?

Yes.

I am calling to inform. you that you have passed the first two rounds of interview. Could you please come for the final round? It is scheduled on the morning of next Monday 10AM in the HR manager office.

Thank you for calling me. I will be there on time.

Ok, see you then, bye.

Bye.

范例二：Share the news with Tina

Hi, Tina, I’ve got good news. I have successfully passed the first two rounds of interview with ABC Company. They informed me to go to the final round next Monday. It looks very promising.

That is awesome. Congratulation! I know you can make it.

Thanks. Let’s go for a celebration this evening. Are you free?

Yes. Wait for me at the café down my office building. See 5PM, ok?

No problem. See you!

See you!

敏捷开发概述

　　敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发的路线^[1]

　　

　　图：敏捷开发的路线图

　　Test-Driven Development，测试驱动开发。

　　它是敏捷开发的最重要的部分。在ThoughtWorks，我们实现任何一个功能都是从测试开 始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提 出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能 编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。

　　Continuous Integration，持续集成。

　　在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成 的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码、编译源代码、运行所有测试，包括单元测试、功能测试 等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。在我们公司里，开发人员的桌上有一个火山灯 用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心 了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。在持续集成上，我们公司使用的是自己开发的产品CruiseControl。

　　Refactoring，重构。

　　相信大家对它都很熟悉了，有很多很多的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是 在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而 对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码之前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复， 也要对它进行重构。

　　Pair-Programming，结对编程。

　　在敏捷开发中，做任何事情都是Pair的，包括分析、写测试、写实现代码或者重构。Pair做事有很多好处，两个人在一起探讨很容易产 生思想的火花，也不容易走上偏路。在我们公司，还有很多事都是Pair来做，比如Pair学习，Pair翻译，Pair做PPT，关于这个话题，钱钱同学 有一篇很有名的文章对它进行介绍，名为Pair Programming (结对编程)。

　　Stand up，站立会议。

　　每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议的内容并不是需求 分析、任务分配等，而是每个人都回答三个问题：1. 你昨天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。

　　Frequent Releases，小版本发布。

　　在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。 这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，不需要复 杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变动，也能很快的适应。

　　Minimal Documentation，较少的文档。

　　其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。如果用书面文档或者注释，某天代码变 化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化了，代码 才会变化，测试是真实反应代码的。这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可 读了，别人一看就能够看懂，这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂，就表示设计还不够简单，需要对它进行重 构。

　　Collaborative Focus，以合作为中心，表现为代码共享。

　　在敏捷开发中，代码是归团队所有而不是哪些模块的代码属于哪些人，每个人都有权利获得系统任何一部分的代码然后修改它，如果有人看到某 些代码不爽的话，那他能够对这部分代码重构而不需要征求代码作者的同意，很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码，即使团队的人 员变动，也没有风险。

　　Customer Engagement ，现场客户。

　　敏捷开发中，客户是与开发团队一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快速度得到客户的反馈。

　　Automated Testing ，自动化测试。

　　为了减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开 发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作，包括Selenium开源项目。

　　Adaptive Planning，可调整计划。

　　敏捷开发中计划是可调整的，并不是像以往的开发过程中，需求分析->概要设计->详细设计->开发 ->测试->交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反 馈随时作出相应的调整和变化。

　　敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情有活力的，能够适应更大的变化，做出更高质量的软件。

敏捷开发的特点

　　敏捷方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要特征:

　　（1）敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

　　这里说的预设性，可以通过一般性工程项目的做法理解，比如土木工程，在这类工程实践中，有比较稳定的需求，同时建设项目的要求也相对固定，所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

　　然而，在软件开发的项目中，这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。所以，这类方法在不可预测的环境下，很难适应变化，甚至是拒绝变化。

　　与之相反的敏捷方法则是欢迎变化，目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。所以称之为适应性方法。 　　 　　（2）敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

　　Matin Flower认为：“在敏捷开发过程中，人是第一位的，过程是第二位的。所以就个人来说，应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容)

　　在传统的软件开发工作中，项目团队分配工作的重点是明确角色的定义，以个人的能力去适应角色，而角色的定义就是为了保证过程的实施，即个人以资源的方式被分配给角色，同时，资源是可以替代的，而角色不可以替代。

　　然而，传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。

　　敏捷开发的目的是建立起一个项目团队全员参与到软件开发中，包括设定软件开发流程的管理人员，只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策，因为他们是最了解什么技术是需要和不需要的。再者，敏捷开发特别重视项目团队中的信息交流，有调查显示：“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”

敏捷开发的价值观

　　实际上敏捷开发运动在数年前就开始了，但它正式开始的标志是2001年2月的“敏捷宣言”（Agile Manifesto），这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的，他们的价值观是：个人与交互重于开发过程与工具；可用的软件重于复杂的文档；寻求客户的合作重于对合同的谈判；对变化的响应重于始终遵循固定的计划。

　　个人与交互重于开发过程与工具的原因：一个由优秀的人员组成但使用普通的工具，要比使用优秀的工具但由普通人组成、紊乱的小组做得更 好。多年来人们花了很多时间试图建立一种过程，以便把人当作机器上的一个可以替代的齿轮，但结果却并不成功。敏捷过程是承认每个人都有特定的能力（以及缺 点）对之加以利用，而不是把所有的人当成一样来看待。更重要的是，在这样的理念下，几个项目做下来，每个人的能力都从中得以提高。这种人的能力的提高，对公司是无价之宝。而不至于把人当成齿轮，随着时间的推移，人的能力慢慢被消耗掉，最后变成留之无用、弃之可惜的尴尬人物。

　　可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候，获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始，并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件的增长，以保证开发小组始终是处理最有价值的功能，而且这些功能可以满足用户的期待。

　　寻求客户的合作重于对合同的谈判的原因:敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力，合同谈判有 时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢，要么大家一起输。换句话说，就是希望开发小组和客户在面对项目的时候，以一种合 作的态度共同向目标前进。当然，合同是必需的，但是如何起草条款，往往影响到不同的团体是进行合作式的还是对抗式的努力。

　　对变化的响应重于始终遵循固定的计划的原因：敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付 尽可能多的价值。除了最简单的项目以外，用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法，也许今天看起来是必需的功 能，明天就会觉得不那么重要了。随着小组获得更多的知识和经验，他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说，一个计划是从某个角度对未来的看法，而具有多个不同的角度看问题是有可能的。

项目的敏捷开发方法

　　敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程（RUP）等多种法，这些方法本质实际上是一样的，敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果； 关注业务优先级； 检查与调整。下图是典型的敏捷过程总图，下面介绍其有关的特点。

　　

　　1、敏捷小组作为一个整体工作

　　项目取得成功的关键在于，所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计 师和架构师不会把程序设计“扔”给编码人员；编码人员也不会把只经过部分测试的代码“扔”给测试人员，一个成功的敏捷开发小组应该具有“我们一起参与其中 的思想”， “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然，尽管强调一个整体，小组中应该有一定的角色分配，各种敏捷开发方法角色的起名方案可能不 同，但愿则基本上是一样的。第一个角色是产品所有者，他的主要职责包括：确认小组成员都在追求一个共同的目标前景；确定功能的优先等级，以便总是处理最有 价值的功能；作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员，在开发内部使用的软件的时候，产品所有者可能是用户、用户的上级、分析师，也可能是为项目提供资金的人。

　　2、敏捷小组按短迭代周期工作

在敏捷项目中，总体上 并没有什么上游阶段、下游阶段，你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计，但只要项目真正开始，每次迭代都会做同样的工作 （分析、设计、编码、测试。等等）。迭代是受时间框限制的，也就是说即使放弃一些功能，也必须结束迭代。时间框一般很短，大部分是 2～4周，在 Scrum中采用的是 30个日历天，也就是 4 周。迭代的时间长度一般是固定的，但也有报告说，有的小组在迭代开始的时候选择合适的时间长度。

　　3、敏捷小组每次迭代交付一些成果

　　比选择特定迭代长度更重要的，是开发小组在一次迭代中要把一个以上的不太精确的需求声明，经过分析、设计、编码、测试，变成可交付的软 件（称之为功能增量）。当然并不需要把每次迭代的结果交付给用户，但目标是可以交付，这就意味着每次迭代都会增加一些小功能，但增加的每个功能都要达到发 布质量。每次迭代结束的时候让产品达到可交付状态十分重要，但这并不意味着要完成发布的全部工作，因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”（MTBF）测试，他们不可能缩短这两个月的时间，但这个小组仍然是按照 4 周迭代，除了MTBF测试，其它都达到了发布状态。

　　4、敏捷小组关注业务优先级

　　敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先，他们按照产品所有者制定的顺序交付功能，而产品所有者一般会按照组织在项目上的投资回报最 大化的方式来确定优先级，并且把它组织到产品发布中去。要达到这个目的，需要综合考虑开发小组的能力，以及所需功能的优先级来建立发布计划。在编写功能的 时候，需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能，那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的，但把功能依赖性控制在最低程度还是相当可行的。

　　5、敏捷小组检查与调整

　　任何项目开始的时候所建立的计划，仅仅是一个当前的猜测。有很多事情可以让这样的计划失效：项目成员的增减，某种技术比预期的更好或更差，用户改变了想法，竞争者迫 使我们做出不同的反应，等等。对此，敏捷小组不是害怕这种变化，而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始，敏捷小组都 会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性，也可能更改计划。比如发现某项工作比预计的更耗费时间，可能就会调 整进展速度。也许，用户看到交付的产品后改变了想法，这就产生反馈，比如他发现他更希望有另一项功能，或者某个功能并不像先前看得那么重。通过先期发布增 加更多的用户希望的功能，或者减少某些低价值功能，就可以增加产品的价值。迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变，而在迭代开发期间不 能改变，以期集中精力完成已经确定的工作。由于一次迭代的时间并不长，所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身，对 于项目投资最 大化是有益处的。从这个观点来看，迭代周期的长度选择就比较重要了，因为两次迭代之间是提供变更的机会，周期太长，变更机会就可能失去；周期太短，会发生 频繁变更，而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑，对于一个复杂项目，迭代周期选择4周还是有道理的。

　　MIT Sloan Management Review（麻省理工学院项目管理评论）所刊载的一篇为时两年对成功软件项目的研究报告，报告指出了软件项目获得成功的共同因素，排在首位的是迭代开发，而不是瀑布过程。其它的因素是：

　　1、至少每天把新代码合并到整个系统，并且通过测试，对设计变更做出快速反应。

　　2、开发团队具备运作多个产品的工作经验。

　　3、很早就致力于构建和提供内聚的架构。

　　从这个报告中所透露出的信息告诉我们，认真研究敏捷过程对软件项目的成功是非常有意义的，它的意义在于：

　　1）给开发小组的自组织提供了机会

　　经典项目管理就好比一个具备中央调度服务的航空管理系统，这个系统是自治的，而且是封闭的，但现实中更庞大的系统，似乎并不属于中央调 度控制系统，但也同样也是有效的。假如我们开车到某个地方，我们可以任意选择所需要的路线，我们甚至不需要准确计算停车，只要我们遵守交通法规，驾驶员可 以临时根据路况改变某个转弯点，在驾驶游戏规则的框架内，依照自身最大利益做出决策。成千上万的驾驶者，并不需要中央控制和调度服务，人们仅仅在简单的交 通法规的框架内，就可以完成综合起来看是更庞大的目标，很多事情从管理的角度只要抓住关键点，并不需要多么复杂的规则，往往会更有效。随着系统复杂度的提 高，中央控制和调度系统面临崩溃。仔细研究交通系统的特点，我们会发现这样的系统中独立的个体在一组适当的规则下运行，并不需要设计每个个体临时变更的方 案，而每个个体只需要知道目标和大致的状况，他们完全可以利用自己的聪明才智来决定自己的行为。

　　2）缩短了反馈通道

　　敏捷过程有效运作的另一个原因是，它极大的缩短了用户与开发者、预测目标与实施状况、投资与回报之间的反馈回路。在面对不断变化的市场、业务过程以及不断发展的技术状态的时候，便需要有一种方法在比较短的时间内发展完善。事实上，所有的过程改进都不同程度的使用着戴明循环，以研究问题、测试解决方案、评估结果，进而根据已知的事实来进行改进，这就称之为基于事实的决策模式，我们都知道，这比前端预测的决策方式更加有效。

　　3）易于集思广益

　　敏捷过程能有效应用的另一个原因在于，它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候，总有某些人员知道问题所 在，但他的观点却遭到忽视。例如航天飞机在起飞阶段发生爆炸，事后分析出了各种原因，但这种调查也提供给我们一个惊人的事实，就是部分工程师早就意识到这 些潜在问题，却无法说服他人重视这个担忧。对这些事实的深入思考，促使我们研究我们应该采取何种管理系统，使前线工作人员的经验、观点及担忧得到充分的重 视呢？

对敏捷开发的误解

　　误解一：敏捷对人的要求很高

　　很多人在尝试实施敏捷时说：敏捷对人的要求太高了，我们没有这样的条件，我们没有这样的人，因此我们没法敏捷。可是，敏捷对人的要求真的那么高么？ 软件归根到底还是一种创造性活动，开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用，各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作，从而产生更高的生产力。不管用什么方法，开发人员的水平永远都是一个主要的因素。

　　从另一个角度来看：过程和方法究竟能帮开发人员多大忙？对于技术水平较低的开发人员，敏捷方法和传统方法对他的帮助是差不多的，因此看不到显着的效果，甚至有些时候还有反效果；而随着开发人员技术水平的提高，敏捷方法能够解开对人的束缚，鼓励创新，效果也会越来越显着。

　　敏捷对人的要求并不高，而且会帮助你培养各种所需的能力，当然前提是你处在真正敏捷的环境中。

　　误解二：敏捷没有文档，也不做设计

　　这个误解从XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准，并不 是所有的文档都不写。例如，用户手册是不是“必要且意义重大”？这取决于客户的要求，如果客户不需要，那就不用写,如果客户需要，就一定要写；再如，架构 设计文档要不要写？复杂要写，不复杂不用写。通常架构设计只需要比较简单的文档，对于有些项目，一幅简单的UML图就够了。因此，写不写，怎么写，都要根据这个文档到底有多大意义，产出和投入的比例，以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定，尽量避免由某一个人（比如lead）来决定。

　　至于设计，XP奉行的是持续设计，并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中，不断的设计、改善（重构），使得设计 一直保持灵活可靠。至于编码前的预先设计，Kent Beck等人确实实行着不做任何预先设计的开发方式，但是对于我们这些“非大师”级开发人员，必要的预先设计还是需要的，只是不要太多，不要太细，要有将 来会彻底颠覆的准备。

　　误解三：敏捷好，其他方法不好

　　有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好，而提到CMMI等方法就大呼不好，不管是什么只要沾上边就哪里都不好，似乎敏捷和其他方法是完全对立的。牛顿说过，我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点，也是站在了巨人的肩膀上，敏捷依然保持了很多历史悠久的实践和原则，只是表现方式不同罢了。

　　从另一个方面来看，方法本没有好环，好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境，在需求稳定、软件复杂度相对不高的时代，瀑布模型也可以工作的很好，而敏捷恰好适用于变化快风险高的项目 － 这恰恰是现在很多项目的共性。

　　因此选择一个方法或过程，并不是根据它是否敏捷，而应根据它是否适合。而要了解一个东西是否适合，还是要尝试之后才知道，任何没有经过实践检验的东西都不可信。

　　误解四：敏捷就是XP（极限编程），就是Scrum

　　XP 和Scrum只是众多敏捷方法中的两种，还有很多其他的敏捷方法。龙生九子各个不同，敏捷的这些方法看起来差别也是很大的，可是他们之所以被称为敏捷方 法，就是因为他们背后的理念和原则都是相同的，这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践，还要理解实践后的原则，不仅要理解怎么做，还要理解 为什么这么做，以及什么时候不要这么做。

　　即使将XP或Scrum完全的应用的你的项目中，也未见得就能成功，适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点，但绝对不是终点，最适合你的方式还要由你自己在实际工作中探索和寻找。

　　误解五：敏捷很好，因此我要制定标准，所有项目都要遵循着个标准

　　没有哪两个项目是一样的，客户是不一样的，人员是不一样的，需求是不一样的，甚至没有什么可能是一样的。不一样的环境和问题，用同样的 方法解决，是不可能解决的好的。方法是为人服务的，应该为项目团队找到最适合他们的方法，而不是先确定方法，再让团队适应这个方法。因此也不存在适合所有 项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

　　同时，对于同一个团队，随着项目的进行，对需求理解的深入，对技术理解的深入，一开始适合项目的过程和方法也会渐渐的不适合。这时候 也需要团队对过程进行及时的调整，保证项目的质量和效率。敏捷是动态的，而非静止不变的，因为这个世界本身就是变化的，在变化的世界使用不变的方法，是不 现实的。银弹从来就没有过，在有限的将来也不会存在。

来源：chinaxp  http://www.xpchina.org     waltson
     Extreme Programming（极限编程，简称XP）是由Kent Beck在1996年提出的。Kent Beck在九十年代初 期与Ward Cunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有
效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月，
Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。

XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观
是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简
单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个
相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚
开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

什么是软件开发

软件开发的内容是：需求、设计、编程和测试！
需求：不仅仅是用户需求，应该是开发中遇到的所有的需求。比如，你首先要知道做这个项目是为了解
决什么问题；测试案例中应该输入什么数据……为了清楚地知道这些需求，你经常要和客户、项目经理
等交流。
设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。你一定要按照这个来做，否则可能会
一团糟。
编程：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。
测试：目的是让你知道，什么时候算是完成了。如果你聪明，你就应该先写测试，这样可以及时知道你
是否真地完成了。否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。

软件开发中，客户和开发人员都有自己的基本权利和义务。
客户：
 • 定义每个用户需求的商业优先级；
 • 制订总体计划，包括用多少投资、经过多长时间、达到什么目的；
 • 在项目开发过程中的每个工作周，都能让投资获得最大的收益；
 • 通过重复运行你所指定的功能测试，准确地掌握项目进展情况；
 • 能随时改变需求、功能或优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划；
 • 能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的，
正在进行或未完成的的工作则应该是不难接手的。
开发人员：
 • 知道要做什么，以及要优先做什么；
 • 工作有效率；
 • 有问题或困难时，能得到客户、同事、上级的回答或帮助；
 • 对工作做评估，并根据周围情况的变化及时重新评估；
 • 积极承担工作，而不是消极接受分配；
 • 一周40小时工作制，不加班。

这就是软件开发，除此之外再还有其它要关心的问题！

灵巧的轻量级软件开发方法

一套软件开发方法是由一系列与开发相关的规则、规范和惯例。重量级的开发方法严格定义了许多的规
则、流程和相关的文档工作。灵巧的轻量级开发方法，其规则和文档相对较少，流程更加灵活，实施起
来相对较容易。

在软件工程概念出现以前，程序员们按照自己喜欢的方式开发软件。程序的质量很难控制，调试程序很
繁琐，程序员之间也很难读懂对方写的代码。1968年，Edsger Dijkstra给CACM写了一封题为GOTO 
Statement Considered Harmful 的信，软件工程的概念由此诞生。程序员们开始摒弃以前的做法，转
而使用更系统、更严格的开发方法。为了使控制软件开发和控制其它产品生产一样严格，人们陆续制定
了很多规则和做法，发明了很多软件工程方法，软件质量开始得到大幅度提高。随着遇到的问题更多，
规则和流程也越来越精细和复杂。

到了今天，在实际开发过程中，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的
制作过程正在失去控制。人们试图提出更全面更好的一揽子方案，或者寄希望于更复杂的、功能更强大
的辅助开发工具（Case Tools），但总是不能成功，而且开发规范和流程变得越来越复杂和难以实施。
为了赶进度，程序员们经常跳过一些指定的流程，很少人能全面遵循那些重量级开发方法。

失败的原因很简单，这个世界没有万能药。因此，一些人提出，将重量级开发方法中的规则和流程进行
删减、重整和优化，这样就产生了很多适应不同需要的轻量级流程。在这些流程中，合乎实际需要的规
则被保留下来，不必要的复杂化开发的规被抛弃。而且，和传统的开发方法相比，轻量级流程不再象流
水生产线，而是更加灵活。

Extreme Programming（XP）就是这样一种灵巧的轻量级软件开发方法。

为什么称为“Extreme”（极限） 

“Extreme”（极限） 是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、
做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其
开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。 



XP的软件开发是什么样

1 极限的工作环境

为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也
做得最好。每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利
和义务。所有的人都在同一个开放的开发环境中工作，最好是所有人在同一个大房子中工作，还有茶点
供应；每周40小时，不提倡加班；每天早晨，所有人一起站着开个短会；墙上有一些大白板，所有的
Story卡、CRC卡等都贴在上面，讨论问题的时候可以在上面写写画画；下班后大家可以一起玩电脑游
戏……。

2 极限的需求

客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户一
直起着很重要的作用。开发人员和客户一起，把各种需求变成一个个小的需求模块（User Story），例
如“计算年级的总人数，就是把该年级所有班的人数累加。”；这些模块又会根据实际情况被组合在一
起或者被分解成更小的模块；它们都被记录在一些小卡片（Story Card）上，之后分别被程序员们在各
个小的周期开发中（Iteration，通常不超过3个星期）实现；客户根据每个模块的商业价值来指定它们
的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验）
需求模块将被优先研究、探索和开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被
安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；客户为每个需求模块指定验收测试
（功能测试）。

每发布一次开发的软件（经过一个开发周期），用户都能得到一个可以开始使用的系统，这个系统全面
实现了相应的计划中的所有需求。而在一些传统的开发模式中，无论什么功能，用户都要等到所有开发
完成后才能开始使用。 

3 极限的设计 

从具体开发的角度来看，XP内层的过程是一个个基于测试驱动的开发（Test Driven Development）周
期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试
（Unit Test）。刚开始，因为什么都没有实现，所以所有的单元测试都是失败的；随着一个个小的需
求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行
了对客户的承诺。XP提倡对于简单的设计（Simple Design），就是用最简单的方式，使得为每个简单
的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式（Big 
Design Up Front），因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计
复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过
程；在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需
求。 

4 极限的编程 

既然编程很重要，XP就提倡两个人一起写同一段程序（Pair Programming），而且代码所有权是归于整
个开发队伍（Collective Code Ownership）。程序员在写程序和重整优化程序的时候，都要严格遵守
编程规范。任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。 

5 极限的测试 

既然测试很重要，XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到
一起（Continuous Integration），每次整合后都要运行单元测试；做任何的代码复核和修改，都要运
行单元测试；发现了BUG，就要增加相应的测试（因此XP方法不需要BUG数据库）。除了单元测试之外，
还有整合测试，功能测试、负荷测试和系统测试等。所有这些测试，是XP开发过程中最重要的文档之
一，也是最终交付给用户的内容之一。
============================================================
XP中的重要惯例和规则

1 项目开发小组（Team）

在XP中，每个对项目做贡献的人都应该是项目开发小组中的一员。而且，这个小组中必须至少有一个人
对用户需求非常清晰，能够提出需求、决定各个需求的商业价值（优先级）、根据需求等的变化调整项
目计划等。这个人扮演的是“客户”这个角色，当然最好就是实际的最终用户，因为整个项目就是围绕
最终用户的需求而展开的。程序员是项目开发小组中必不可少的成员。小组中可以有测试员，他们帮助
客户制订验收测试；有分析员，帮助客户确定需求；通常还有个Coach（教练），负责跟踪开发进度、
解决开发中遇到的一些问题、推动项目进行；还可以又一个项目经理，负责调配资源、协助项目内外的
交流沟通等等。项目小组中有这么多角色，但并不是说，每个人做的工作是别人不能插手或干预的，XP
鼓励每个人尽可能地为项目多做贡献。平等相处，取长补短；这就是最好的XP开发小组。

2 计划项目（Planning Game）、验收测试、小规模发布（Small Releases）

XP开发小组使用简单的方式进行项目计划和开发跟踪，并以次预测项目进展情况和决定未来的步骤。根
据需求的商业价值，开发小组针对一组组的需求进行一系列的开发和整合，每次开发都会产生一个通过
测试的、可以使用的系统。

•  计划项目

XP的计划过程主要针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该
做些什么。不断的回答这两个问题，就是直接服务于如何实施及调整开发过程；与此相比，希望一开始
就精确定义整个开发过程要做什么事情以及每件事情要花多少时间，则事倍功半。针对这两个问题，XP
中又两个主要的相应过程：

软件发布计划（Release Planning）。客户阐述需求，开发人员估算开发成本和风险。客户根据开发成
本、风险和每个需求的重要性，制订一个大致的项目计划。最初的项目计划没有必要（也没有可能）非
常准确，因为每个需求的开发成本、风险及其重要性都不是一成不变的。而且，这个计划会在实施过程
中被不断地调整以趋精确。

周期开发计划（Iteration Planning）。开发过程中，应该有很多阶段计划（比如每三个星期一个计
划）。开发人员可能在某个周期对系统进行内部的重整和优化（代码和设计），而在某个周期增加了新
功能，或者会在一个周期内同时做两方面的工作。但是，经过每个开发周期，用户都应该能得到一个已
经实现了一些功能的系统。而且，每经过一个周期，客户就会再提出确定下一个周期要完成的需求。在
每个开发周期中，开发人员会把需求分解成一个个很小的任务，然后估计每个任务的开发成本和风险。
这些估算是基于实际开发经验的，项目做得多了，估算自然更加准确和精确；在同一个项目中，每经过
一个开发周期，下一次的估算都会有更过的经验、参照和依据，从而更加准确。
这些简单的步骤对客户提供了丰富的、足够的信息，使之能灵活有效地调控开发进程。每过两三个星
期，客户总能够实实在在地看到开发人员已经完成的需求。在XP里，没有什么“快要完成了”、“完成
了90%”的模糊说法，要不是完成了，要不就是没完成。这种做法看起来好象有利有弊：好处是客户可以
马上知道完成了哪些、做出来的东西是否合用、下面还要做些什么或改进什么等等；坏处是客户看到做
出来的东西，可能会很不满意甚至中止合同。实际上，XP的这种做法是为了及早发现问题、解决问题，
而不是等到过了几个月，用户终于看到开发完的系统了，然后才告诉你这个不行、那个变了、还要增加
哪个内容等等。

•  验收测试

客户对每个需求都定义了一些验收测试。通过运行验收测试，开发人员和客户可以知道开发出来的软件
是否符合要求。XP开发人员把这些验收测试看得和单元测试一样重要。为了不浪费宝贵的时间，最好能
将这些测试过程自动化。

•  频繁地小规模发布软件（Small Releases）

每个周期（Iteration）开发的需求都是用户最需要的东西。在XP中，对于每个周期完成时发布的系
统，用户都应该可以很容易地进行评估，或者已经能够投入实际使用。这样，软件开发对于客户来说，
不再是看不见摸不着的东西，而是实实在在的。XP要求频繁地发布软件，如果有可能，应该每天都发布
一个新版本；而且在完成任何一个改动、整合或者新需求后，就应该立即发布一个新版本。这些版本的
一致性和可靠性，是靠验收测试和测试驱动的开发来保证的。

3 简单设计，Pair Programming，测试驱动开发，重整和优化

XP程序员不但做为一个开发小组共同工作，还以两个人为一个小开发单元编写同一个程序。开发人员们
进行简单的设计，编写单元测试后再编写符合测试要求的代码，并在满足需求的前提下不断地优化设
计。

•  简单设计

XP中让初学者感到最困惑的就是这点。XP要求用最简单的办法实现每个小需求，前提是按照这些简单设
计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何
画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。

在XP中，没有那种传统开发模式中一次性的、针对所有需求的总体设计。在XP中，设计过程几乎一直贯
穿着整个项目开发：从制订项目的计划，到制订每个开发周期（Iteration）的计划，到针对每个需求
模块的简捷设计，到设计的复核，以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不
断前进和发展的过程。从这个角度看，XP是把设计做到了极致。

•  Pair Programming

XP中，所有的代码都是由两个程序员在同一台机器上一起写的——这是XP中让人争议最多、也是最难实
施的一点。这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因
此得到提高。看起来这样象是在浪费人力资源，但是各种研究表明事实恰恰相反。—— 这种工作方式
极大地提高了工作强度和工作效率。

很多程序员一开始是被迫尝试这点的（XP也需要行政命令的支持）。开始时总是不习惯的，而且两个人
的效率不会比一个人的效率高。这种做法的效果往往要坚持几个星期或一两个月后才能很显著。据统
计，在所有刚开始Pair Programming的程序员中，90%的人在两个月以后都很认为这种工作方式更加高
效。

项目开发中，每个人会不断地更换合作编程的伙伴。因此，Pair Programming不但提高了软件质量，还
增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解。这不但有利于个人，也有利于整个
项目、开发队伍和公司。从这点看，Pair Programming不仅仅适用于XP，也适用于所有其它的软件开发
方法。

•  测试驱动开发

反馈是XP的四个基本的价值观之一——在软件开发中，只有通过充分的测试才能获得充分的反馈。XP中
提出的测试，在其它软件开发方法中都可以见到，比如功能测试、单元测试、系统测试和负荷测试等；
与众不同的是，XP将测试结合到它独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。
另外，由于强调整个开发小组拥有代码，测试也是由大家共同维护的。即，任何人在往代码库中放程序
（Check In）前，都应该运行一遍所有的测试；任何人如果发现了一个BUG，都应该立即为这个BUG增加
一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设
计，改动完以后如果能通过所有测试，就证明他的工作没有破坏愿系统。这样，测试才能真正起到帮助
获得反馈的作用；而且，通过不断地优先编写和累积，测试应该可以基本覆盖全部的客户和开发需求，
因此开发人员和客户可以得到尽可能充足的反馈。

•  重整和优化 (Refactoring)

XP强调简单的设计，但简单的设计并不是没有设计的流水帐式的程序，也不是没有结构、缺乏重用性的
程序设计。开发人员虽然对每个USER STORY都进行简单设计，但同时也在不断地对设计进行改进，这个
过程叫设计的重整和优化（Refactoring）。这个名字最早出现在Martin Fowler写的《Refactoring: 
Improving the Design of Existing Code》这本书中。

Refactoring主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。Refactoring
的概念并不是XP首创的，它已经被提出了近30年了，而且一直被认为是高质量的代码的特点之一。但XP
强调，把Refactoring做到极致，应该随时随地、尽可能地进行Refactoring，只要有可能，程序员都不
应该心疼以前写的程序，而要毫不留情地改进程序。当然，每次改动后，程序员都应该运行测试程序，
保证新系统仍然符合预定的要求。

4 频繁地整合，集体拥有代码（Collective Code Ownership），编程规范

XP开发小组经常整合不同的模块。为了提高软件质量，除了测试驱动开发和Pair Programming以外，XP
要求每个人的代码都要遵守编程规范，任何人都可以修改其他人写的代码，而且所有人都应该主动检查
其他人写的代码。

•  频繁地整合 （Integration ）

在很多项目中，开发人员往往很迟才把各个模块整合在一起。在这些项目中，开发人员经常在整合过程
中发现很多问题，但不能肯定到底是谁的程序出了问题；而且，只有整合完成后，开发人员才开始稍稍
使用整个系统，然后就马上交付给客户验收。对于客户来说，即使这些系统能够通过终验收测试，因为
使用时间短，客户门心里并没有多少把握。

为了解决这些问题，XP提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的USER STORY
（每次整合一个新的USER STORY）。每次整合，都要运行相应的单元测试和验收测试，保证符合客户和
开发的要求。整合后，就发布一个新的应用系统。这样，整个项目开发过程中，几乎每隔一两天，都会
发布一个新系统，有时甚至会一天发布好几个版本。通过这个过程，客户能非常清楚地掌握已经完成的
功能和开发进度，并基于这些情况和开发人员进行有效地、及时地交流，以确保项目顺利完成。

•  集体拥有代码（Collective Code Ownership）

在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。
因此，即使可能有相应的比较详细的开发文档，但一个程序员却很少、也不太愿意去读其他程序员的代
码；而且，因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代
码。同时，因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被
发现或得到比较好的解决。针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代
码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开
发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好。

为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序。（从这点，我们可
以再次看到，XP的各个惯例和规则是怎样有机地结合在一起的。）

•  编程规范

XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为
有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是是实现Collective Code 
Ownership的重要前提之一。

5 Metaphor（系统比喻），不加班

XP过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识。XP认为加班是不正常的，因
为这说明关于项目进度的估计和安排有问题。 

•  Metaphor（系统比喻）

为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻
来描述系统或功能模块是怎样工作的。比如，对于一个搜索引擎，它的Metaphor可能就是“一大群蜘
蛛，在网上四处寻找要捕捉的东西，然后把东西带回巢穴。”

•  不加班

大量的加班意味着原来的计划是不准确的，或者是程序远不清楚自己到底什么时候能完成什么工作。而
且，开发管理人员和客户也因此无法准确掌握开发速度；开发人员也因此非常疲劳。XP认为，如果出现
大量的加班现象，开发管理人员（比如Coach）应该和客户一起确定加班的原因，并及时调整项目计
划、进度和资源。
============================================================
XP中一些基本概念的简介

User Story：开发人员要求客户把所有的需求写成一个个独立的小故事，每个只需要几天时间就可以完
成。开发过程中，客户可以随时提出新的User Story，或者更改以前的User Story。

Story Estimates和开发速度：开发小组对每个User Story进行估算，并根据每个开发周期
（Iteration）中的实际情况反复计算开发速度。这样，开发人员和客户能知道每个星期到底能开发多
少User Story。

Release Plan和Release Scope：整个开发过程中，开发人员将不断地发布新版本。开发人员和客户一
起确定每个发布所包含的User Story。

Iteration（开发周期）和Iteration Plan：在一个Release过程中，开发人员要求客户选择最有价值的
User Story作为未来一两个星期的开发内容。

The Seed：第一个开发周期（Iteration）完成后，提交给客户的系统。虽然这不是最终的产品，但它
已经实现了几个客户认为是最重要的Story，开发人员将逐步在其基础上增加新的模块。

Continuous Integration（整合）：把开发完的User Story的模块一个个拼装起来，一步步接近乃至最
终完成最终产品。

验收测试（功能测试）：对于每个User Story，客户将定义一些测试案例，开发人员将使运行这些测试
案例的过程自动化。

Unit Test（单元测试）：在开始写程序前，程序员针对大部分类的方法，先写出相应的测试程序。

Refactoring (重整和优化) ：去掉代码中的冗余部分，增加代码的可重用性和伸缩性。 



小结

XP的一个成功因素是重视客户的反馈——开发的目的就是为了满足客户的需要。XP方法使开发人员始终
都能自信地面对客户需求的变化。XP强调团队合作，经理、客户和开发人员都是开发团队中的一员。团
队通过相互之间的充分交流和合作，使用XP这种简单但有效的方式，努力开发出高质量的软件。XP的设
计简单而高效；程序员们通过测试获得客户反馈，并根据变化修改代码和设计，他们总是争取尽可能早
地将软件交付给客户。XP程序员能够勇于面对需求和技术上的变化。

XP很象一个由很多小块拼起来的智力拼图，单独看每一小块都没有什么意义，但拼装好后，一幅美丽的
图画就会呈现在你面前。

   随着现代信息产业的蓬勃发展，软件开发已经成为一项浩大繁复的工程。就象是建造一座宏伟的宫殿，从计划、设计到施工，每一个环节都必须严格把关，稍有不 慎，整个工程就会失败。据统计，仅在美国，每年就有180,000个信息技术项目，耗资大约$2500亿美元，其中25-30%的项目会流产。由此可见， 由于管理不善和设计上的失误所造成的损失是巨大的。现代软件开发的管理和方法论显得比以往任何时候都更为重要。 

　　软件开发的过程由方法论和工具构成（process = methodology + tools）。正如装配电子设备一样，仅有工具就可以胜任装配 任务。但为了减少失误和提高效率，人们往往采用流水线作业，流水线作业便是一种应用于电子设备装配中的方法论。目前，信息技术市场流行的方法论有RUP （Rational Unified Process）, The Zachman Framework, XP (Extreme Programming)等。在这些方法论中，最流行的要数RUP。RUP是由Rational Software公司首创的。因它与 当前流行的JAVA, J2EE技术和面向对象的设计思想（OOAD）紧密的结合在一起，所以在大型的信息技术项目中得到了广泛的应用。在这篇文章中，我 们试图对RUP的特点作一个初步的探讨，并且讨论它是如何贯穿在整个软件开发的生命周期之中的。 

　　RUP最重要的它有三大特点：1）软件开发是一个叠代过程，2）软件开发是由Use Case驱动的，3）软件开发是以构架设计（Architectural Design）为中心的。 

　　按照传统的瀑布（Waterfall）开发模式，软件开发大致经历如下几个步骤：商务需求分析 （Business Requirement Analysis），系统分析（System Analysis），系统设计 （System Design），开发实现（Implementation），测试（Test），发布（Deployment），系统支持 （Supporting）和系统变更管理（Change Management）。 

　　传统的瀑布开发模式假定在进行新的开发过程时，上一个过程已经完成，而且不会回到上一个过程。初看起来，这似乎是一个非常合理，高效率的解决方案，但 20多年的实践证明，这个开发模式存在着很大的弊病，原因是软件开发是一个非常复杂的工程，有诸多的因素影响工程的效率和成败。软件开发需要许多不同背景 的个人和团队参与。由于这些复杂性，在软件开发的整个生命周期中每一个阶段都有可能留下隐患和错误。如果等到系统已经开发实现完毕，在测试阶段发现了重大 问题，这时的返工将会造成人力、物力、财力及时间上的巨大浪费。鉴于以上的考虑，RUP强调软件开发是一个叠代模型（Iterative Model）， RUP定义了四个阶段（Phase）：开端（Inception），阐述（Elaboration），建造（Construction），过渡 （Transition）。其中每个阶段都有可能经历以上所提到的从商务需求分析开始的各个步骤，只是每个步骤的高峰期会发生在相应的阶段。例如开发实现 的高峰期是发生在建造阶段。实际上这样的一个开发方法论是一个二维模型。这种叠代模型的实现在很大程度上提供了及早发现隐患和错误的机会，因此被现代大型 信息技术项目所采用。 

　　RUP 的另一大特征是Use Case 驱动。Use Case是RUP方法论中一个非常重要的概念。简单地说，一个Use Case就是系统的一 个功能。例如在一个基于电子商务的医疗系统中，病人可以坐在家里通过网上浏览器与医生约定看病的时间（Makeappointment），这样， “Makeappointment”就是系统的一个Use Case。在系统分析和系统设计中，Use Case被用来将一个复杂的庞大系统分割、定义成 一个个小的单元，这个小的单元就是Use Case,然后以每个小的单元为对象进行开发。按照RUP, Use Case贯穿整个软件开发的生命周期。在 商务需求分析中，客户或用户对Use Case进行描述，在系统分布和系统设计过程中，设计师对Use Case进行分析，在开发实现过程中，开发编程人 员对Use Case进行实现，在测试过程中，测试人员对Use Case进行检验。 

　　RUP的第三大特征是它强调软件开发是以构架为中心的。构架设计（Architectural Design）是系统设计的一个重要组成部分。在构架 设计过程中，设计师(Architect)必须完成对技术和运行平台的选取，整个项目的基础框架（Framework）的设计，完成对公共组件的设计，如 审计（Auditing）系统，日志（Log）系统，错误处理（Exception Handling）系统，安全（Security）系统等。设计师必 须对系统的可扩展性（Extensibility），安全性（Security），可维护性（Maintainability），可延拓性 （Scalability），可重用性（Reusability）和运行速度（Performance）提出可行的解决方案。 

　　在RUP方法论中，不同的角色可以从不同的侧面来认识同一个项目。RUP定义了“4+1”个场景（View）：Use Case场景(Use Case View)，逻辑场景(Logic View)，进程场景(process View)，实现场景(Implementation View)和发布场景(Deployment View)。 在Use Case场景中，客户和商务分析员对Use Case进行描述，在逻辑场景中，设计师对系统进行分析和设计，在进程场景中，设计师对系统可能出 现的并发性，运行速度和分布特性进行描述。实现场景则反映了程序开发员开发实现的过程。发布场景是描述系统管理员和组装人员实施系统发布和管理的过程。值 得强调的是，系统构架的设计是在逻辑场景中描述的。 

　　RUP还定义了4个模型，即Use Case模型（Use Case Model），分析模型(Analysis Model)，设计模型(Design Model)和实现模型(Implementation Model)。Use Case 模型包含Use Case Diagram和Use Case文档。Use Case模型是其他三个模型的基础，分析模型即是概念模型 (Conceptual Model)，是系统分析所得到的结果，分析模型包含了类图(Class Diagram)，次序图 (Sequence Diagram)以及活动图(Activity Diagram)。设计模型则是构架设计和系统设计的结果。当设计模型完成后，开发 编程人员便可以进行编程了。设计模型主要包含了类图，次序图和状态图(State Chart Diagrams)。分析模型和设计模型看起来有许多相似 之处，但两者的含义有本质的区别。分析模型强调的是问题的范围，但并不给出解决问题的方案，分析模型并不涉及具体的技术和平台。例如它并不关心是否应用 EJB或一般的JAVA BEANS，系统是安装在WebSphere或是在WebLogic。但是与之相反，设计模型要考虑这些细节，而且要提供解决这 些问题的全部方案。当然设计模型是建立在分析模型之上的，分析模型中的一个类可直接映射成为设计模型中的类，但这种映射关系一般并不是一一对应的，最后一 个模型是实现模型。实现模型包含构件图（Component Diagram），从这个模型出发，开发编程人员可以产生骨架源程序 (Skeleton Source Code)，也可以从源程序出发更新设计模型。 

　　目前应用于系统分析和设计的工具主要有Rational Rose和Together Software Center(TogetherJ)。 JAVA和J2EE的开发工具有IBM Websphere Application Developer(WSAD),  Borland Jbuilde和WebGain VisualCafe. WSAD和WebSphere Application Server应用 在一起，使得服务器端的排错和系统的发布变得非常的容易。Jbuilder和VisualCafe一般与WebLogic erver紧密结合在一起。目 前WebSphereServer和WebLogic Server占据了Application Server市场的66%，其中 WebSphere Server占据了37%，成为同类产品的No.1。在单位测试和集成测试中，广泛应用的工具和框架有Junit,  JunitPerf和Cactus.。 

　　综上所述，软件开发的方法论已经成为现代软件工程过程中不可缺少的一个重要部分。是目前在Java/J2EE和面向对象的大型项目中广泛被采用的一种 方法论。他对整个软件开发的生命周期提供了基础框架和指导。RUP, UML/Rational Rose, Java/J2EE, WSAD,  Websphere Application Server和Oracle这样的技术、工具和平台的组合是目前许多公司、政府信息技术项目中采用的方 案。因此，RUP的知识和经验也是现在求知是场所需求的热门技能。 转自: http://www.killuakun.com/article.asp?id=419

宅了近一个月，日复一日地下来，并未像当初辞职之时那样的果断来对待学习，无论是专业还是英语，似乎都无所大的进步。看到朋友们都有那么清晰的人生轨迹，而自己的目标似乎总是一个模糊的概念，有时真的很烦躁。

晚上睡不着时，总有爬起来写日记的冲动，可是，很多话想说，其实什么都不想写。或许该把三毛的书翻出来看看，她的洒脱和浪漫也许能够鼓励自己，多点不羁，少点现实。

情绪归情绪，事情还得照做。好不容易在虚拟机上装了一个linux版本，对着它，却不知道如何下手。去论坛逛逛，好好学学吧，能有一点进步也是好的。

 

第一步、投递简历 投递简历，让招聘公司发现你，一般有4种方式： 1.       通过招聘网站搜索测试招聘信息，选择合适的公司和职位，投递简历； 2.       通过招聘网站发布自己的简历，等待招聘公司发现并下载你的简历； 3.       通过本公司内部招聘、内部人员推荐； 4.       通过招聘会，现场投递简历。 以上4种招聘方式，最为常用的是1、2两种，而且结合使用，第3种的成功率最高，第4种应用很少。第1种方式是现在大多数测试朋友找工作的主要途径，目前，国内知名的人才招聘网站：中华英才网（www.chinahr.com）、51job前程无忧（www.51job.com）、卓博（www.jobcn.com）、中国国家人才网（www.newsjob.com.cn）、北京人才网（www.bjrc.com）等，相信各位想找工作的测试朋友，早已对这些网站如数家珍了。如果你想被猎头看重，那就赶快注册（更新）一下自己的简历吧，很快将会有一大堆公司给你打电话，通知你去面试，这就是第2种方式。一般说来，你在人才网上发布简历找工作的同时，猎头公司也在找你，所以说，1、2两种方式结合使用。接下来，我们再来探讨一下第3种方式。在外企以及一些大公司，为了减缓员工在从事一项工作几年之后产生的乏味情绪，特别推出一种内部招聘的方式，允许公司内部相关部门的相关人员的应聘，比如说作技术支持的要应聘作市场，作开发的要应聘作测试等等，或者在公司内部公布招聘信息，希望本公司的员工推荐符合招聘要求的人员，可以直接到公司进行面试。因为公司对内部员工相当了解，员工对招聘要求十分清楚，必然按要求搜寻符合条件的熟人进行推荐，所以，公司内部招聘、内部推荐十分容易成功。第4种招聘方式，近两年已经很少应用，因为招聘会有时间限制，还要跑到现场，在人山人海中搜寻符合自己条件的公司和职位，投递简历并进行简单面试，既费时、费力，效果也不佳，故而应用越来越少。 第二步、准备面试 想要参加面试，就一定要做好面试的准备： 公司情况： 在接到面试通知时，一定要简单而客气地询问一下公司的情况， 正所谓知己知彼，百战不殆。看看公司是否有你所关注的地方，比如公司的规模、办公地点、测试组的情况等，最主要的要知道公司的主要业务，测试什么，软件还是硬件，那个行业的，问话不要多，否则对方很容易反感，最好是要来对方的公司网址，到网站上浏览一下，大体也就知道了。 穿衣戴帽： 陌生人见面，第一印象很重要，你给招聘方的第一印象，主要通过衣着来表现。我们这些测试人员，都是搞技术的IT人士，不能穿的象个新新人类，试想一下，你作为主考官，见一个身穿乞丐服、头戴鸭舌帽的人进来应聘测试工程师，你会相信他的技术吗。所以在面试时，一定要穿洁净、整齐的职业装或者夹克，或者适中的风衣。女士稍微画一点淡妆，男式记得刮胡子。头发都要梳的整齐。 言谈举止： 言谈举止要透出一股自信，让人感觉你就是很棒，什么任务都可以放心的交给你去作，你都能圆满完成。 证书、简历： 很多公司可能在通知你面试的时候，就会通知你带相关的学历证件、培训证书，如果招聘方没有通知，你可以礼貌的问一下，是否需要携带。至于你的简历，一定要多带上几份，不要以为招聘方看过你的简历，就一定有你的简历。因为也许是人事部发现了你的简历，通知测试部一同面试，或者测试部发现了你的简历，通知人事部一同面试，而面试又是在几天之后的事情，早不知把你的简历扔到哪里去了。你以为网站上有你的简历，可以直接打印，那你就错了。因为招聘负责人可能工作比较忙，比较累，应聘的人又那么多，手头没有现成的简历，随便应付一下，就打发你走了。感觉难受吧，可你改变不了人家，如果不想失去这次机会，就自己准备简历吧，需要就拿出来，不需要可以留着下次用。 语言表达： 面试的关键就是语言表达，看你是否能够很有条理的把自己的经历、知识、技能表达清楚，并且在讲的过程中，注意观察招聘方的表情，看人家是否感兴趣，如果人家皱眉头，表情不悦，就尽快结束自己的话题。因此，在面试之前，你可以自己练习练习。 知识、技能： 知识、技能是测试人员平时积累下来的宝贵财富，面试之前，你可以将其条分缕悉，以备面试时表达清楚。 英语能力： 国内企业对英语要求不是十分苛刻，只要有良好的英文文档阅读能力即可；倘若是外企或者承包外企项目的公司，对英语要求则十分严格：要求你能够用日常英语会话，能够用英语撰写测试文档，汇报测试工作。所以在学习测试知识和技能的同时，我们也要注意对英语知识的积累。 第三步、参加面试 在约定的时间、约定的地点，你最好准时出现，如果不能准时赴约，一定要提前打电话，告知对方是什么原因导致你迟到，多长时间以后能你到达约定地点。进入公司，会有接待人员招呼你坐下，通知招聘负责人接待你面试，此间接待人员会给你送上来一杯水。 1.       考试 招聘负责人给你一份试卷(一般为笔试，也有上机的，如果对英语有严格要求，还会有一份英文试卷)，规定一定的时限，到时间他来收卷。试卷的命题一般分为填空、选择、判断、逻辑推理、程序改错、简答，也有让你找bug的题，这些题给人的感觉都是在简单中透漏着怪异。如果你问为什么要有考试这一关，招聘人会告诉你，是想考察应聘者的能力。其实，不尽然，最根本是公司的质量保证体系，要求公司所有活动都得有记录，所以才出现了考试这回事。 2.       初试 初试是最关键的，几乎决定是否录用你。初试之前招聘负责人可能会寒暄几句，让你放松一下心情。招聘负责人一般有两位，一位负责测试技术，一位负责人事，招聘负责人会作自我介绍，也可能其中一位捎带介绍另一位的资历(比如留美博士)，表示这家公司很有诱惑力，连这么好的人才都吸引来了。接下来负责测试技术的会问你几个问题： l       请你简单谈谈你的经历？ l       你在某某家公司主要作哪些工作？ l       测试过那些东西？ l       测试流程是什么？ l       手工测试还是自动测试？ l       使用过哪些测试工具？使用过Rational系列测试工具吗？ l       作过白盒测试吗？ l       作过XXX测试吗？以前接触过XXX吗？你对XXX了解到什么程度？（XXX代表招聘公司所要测试的东西） l       平时使用哪些操作系统？Linux操作熟练吗？ l       以前作过开发吗？开发了哪些东西？使用的什么语言？ l       你觉得测试工程师应该具备哪些素质？ l       对一个测试工程师来说，什么素质最重要？ l       结合自己的实际工作，谈谈你对测试的理解？ l       为什么要离开上一家公司？ l       居住在哪里？离公司远不远？ 有经验的招聘负责人都会简单介绍一下自己的公司（背景、主营业务、发展前景等），然后开始问问题。一般开门见山的问题是’请你简单谈谈你的经历？’，回答这个问题，只要简单的叙述你从毕业到现在都在那些公司作了那些事情即可，叙述时一定要从容、清晰而有条理，眼睛瞅着招聘负责人，观察其表情，如果有些不耐烦，要尽早结束这一话题。招聘负责人此时会大致浏览你的简历，在你叙述完自己的经历时，招聘人会就你简历的某一项问你，比如’你在某某家公司主要作什么？测试过那些东西？测试流程是什么？’，待你回答完这些之后，继而问你测试的具体细节，手工测试、自动测试、用过那些工具？是否作过白盒测试？使用过什么操作系统？熟悉那些语言？是否作过开发？如果你肯定回答这些问题，那么还要继续问具体操作，比如你答作过白盒测试，那么招聘人会问你测了哪些东西？怎么进行的？是独立进行的还是和别人一起进行的？测试出的bug 如何处理？是否作进一步的分析？…… 负责测试技术的问完后，就由负责人事的继续发问： l       你的期望薪金是多少？税前还是税后？ l       一旦录用多长时间可以来上班？ l       你的户口在哪里？调档案是否有问题等？ 等你回答完毕，接下来他会告诉你： l       公司是否有试用期，试用期多长时间； l       试用期的薪金如何发放，其他待遇怎样处理； l       如果符合初试条件，多长时间之内通知复试； l       有无医疗保险、养老保险、失业保险、住房公基金等福利待遇。 一般面试的会谈与过程掌控在招聘人手中，如果不想变得很被动，就要试着主动发问。不过，招聘人很少会给你机会，或者你问的不是时机，会让他很反感。只有到最后，招聘人才会说“我们的问题问完了，你有什么问题吗？”，这时你就可以放心大胆的问了，比如： l       公司是那年成立的？ l       主要业务是什么？ l       现有规模怎么样？ l       测试组的情况怎么样？ l       作息制度等等？ 凡是你所关心的问题都可以问。 之后是几句寒暄的话，诸如： l       谢谢您来参加面试 l       耽误您宝贵时间了 l       我送您出门 l       ByeBye，再见 （注明：如果是外企公司或承包外企项目的公司，几乎整个初试将用英语进行。） 这样，初试就结束了。一般初试后一周之内会通知你参加复试，如果没有接到通知，就不要再怀念这家公司了。假如你仍不死心，当然也可以打电话咨询一下，也许他们真的没有想好通知谁复试，也许因为你打了电话，通知复试就是你了；也许他们已经将你Pass掉了，就会委婉的告诉你，或者直截了当的告诉你。 3.       复试 在考试和初试综合成绩出来之后，招聘负责人决定推荐几位综合成绩好的初试者给老板（最终负责人），由其对你进行复试。谈话的内容与初试差不多，但你会觉得比较随和，因为大老板一般都很会做人，而且觉得你可能就是我们公司的员工了，所以会相对放松些。 经过复试之后，几乎当场或者很快就会给你电话，告知你被录用了，报到时需要携带哪些证件，询问你何时能够上班？如果复试后几天都没有讯息，就不要再等了，招聘公司已经将你Pass掉了。 (注明：不是所有公司的面试都有考试、初试、复试，但至少一次面谈是必需的)

➤ Using the Backslash Character ( \ )
➤ Matching Any Single Character ( . )
➤ Matching Any Single Character in a List ( [xy] )
➤ Matching Any Single Character Not in a List ( [^xy] )
➤ Matching Any Single Character within a Range ( [x-y] )
➤ Matching Zero or More Specific Characters ( * )
➤ Matching One or More Specific Characters ( + )
➤ Matching Zero or One Specific Character ( ? )
➤ Grouping Regular Expressions ( ( ) )
➤ Matching One of Several Regular Expressions ( | )
➤ Matching the Beginning of a Line ( ^ )
➤ Matching the End of a Line ( $ )
➤ Matching Any AlphaNumeric Character Including the Underscore ( \w )
➤ Matching Any Non-AlphaNumeric Character ( \W )
➤ Combining Regular Expression Operators

 

 

很贸然地就辞职了，很贸然地就离开了公司。不想说太多，仅copy下这封辞职信，让我记得这曾经的一站。

尊敬的X经理：

我很遗憾在这个时候正式向公司提出辞职。

承蒙您的错爱，我于08年6月加入公司，在这近一年的时间里，我在测试能力方面得到了成长，而加入项目管理小组后，对项目管理也有了一定的认识，我真的很感激你和XX（公司副经理，也是项目管理小组组长）不嫌我只是一名毫无项目管理经验的员工，而鼓励我加入了管理小组。从个人情感而言，离开公司，我有太多的舍不得，舍不得这么多热心的同事，舍不得我在公司积累的一切，更舍不得公司独有的开放努力的气氛。无论我将来情况怎样，不可否认，XX都是我人生很重要的一站，我会永远记得这里的一切，包括您这位没有官僚主义、叫我们直呼其名的领导，热心能干的MM，一直比较照顾我的RJ，还有每次都帮我搬电脑的HF，以及每位几乎每天都比我晚下班、努力而有责任心的同事，你们都会永远的影响着我，引导着我努力。

在公司见证我成长的同时，我也看到了公司的进步，虽然肆虐的金融危机给公司造成了一定的影响，可是在这一年的时间里，还是有着那么多的正面的变化。比如重庆分公司名称及logo的创建，公司价值观的确立，项目管理小组的成立，以及搬大办公室、游凤凰，每一个点都是公司及员工的成长和融合，我很荣幸在这些事情上，自己不是以一个旁观者而是一个参与者的身份来见证和铭记。唯一遗憾的就是我们测试部门的撤销，虽然理解公司的难处，但还是觉得有点遗憾和难过，不过，我相信这都只是暂时的，希望公司能尽快摆脱金融危机的阴影，并获得大的发展，到时，也希望测试部门能重振雄风，为公司产品的质量保证发挥更大的作用。

说句真心话，离开公司没有带着半点的怨气，真的只是很感激。我也很感谢您的理解和支持。在这里，唯有祝公司在今后的发展中步步为赢、蒸蒸日上！

 

CMMI基础知识扫盲

作者：张传波

摘自：http://www.cmmionline.net

摘要：

CMMI全称是Capability Maturity Model Integration，CMMI是个好东西来的，但行内人士对她的认识并不全面，甚至有种种的误解。尽管网上有很多CMMI相关介绍，但一般都是比较苦涩难懂的。本文将用生动通俗的语句，让大家初步看清楚CMMI的真面面孔。

 

CMMI是什么东西？

CMMI英文全称是Capability Maturity Model Integration，直接翻译就是能力成熟度模型，直接看这几个中文字，你还是没有办法搞清楚CMMI是什么东西的。

大家可能在网上见过很多《成功人士的七个习惯》（可能还有很多类似的名字）的文章吧？有人总结了成功人士的成功的原因，总结出他们的习惯，如果我们也能具备这些习惯，那么我们也很可能成为成功人士。类似的，CMMI可以看作是成功企业如何做好软件的一些习惯、做法、准则等的集合，是如何做好软件的最佳实践的集合。如果企业也能按照CMMI的要求做好，那么企业就很可能成为成功的企业。

CMMI里面所有的要求，都是来自于成功企业的最佳实践的，她的先进性我们不必怀疑，如果我们没有做好，那不是CMMI本身的问题，而是我们自己没有理解好或者是没有执行好的原因。

说到CMMI，就不可避免会提到另外3个字母SEI，SEI全称是Software Engineering Institute的全称，直译就是软件工程学院，是美国的一所大学，CMMI标准就是他们搞出来的。

CMMI目前最新版本是V1.2，如果你是现在才开始了解CMMI的，那么你完全没有必要去搞清楚V1.1与V1.2的差别，更加没有必要去比较CMM与CMMI的差别，直接了解CMMI V1.2就可以了，你只需要知道CMM是CMMI的前身，而CMMI V1.1虽然比CMM要新很多，但现在已经不用了。现在在互联网上还有很多比较CMM与CMMI的文章的，除非你很想了解或者你有很多时间，建议不必去看这些内容。

 

连续式vs阶段式

CMMI有两种表述方式：连续式与阶段式，两种方式只是从不同的角度来阐述CMMI，其实质上表达的内容是一致的。就好像我们做数据库设计的时候，可能会设计不同的视图来查看相同数据表的数据，只是角度不一样。

大家可能会问，好好的CMMI，为什么要搞两种表达方式呢？不怕把大家搞糊涂吗？

确实这两种方式把不少人给搞糊涂了，这是SEI的一个败笔。以前的CMM是只有阶段式的表达方式的，连续式是后来提出来的，SEI内部分成两派，一派支持连续式，一派支持阶段式，互不相让，最后达不成一致，就出来了现在这个样子，连续式与阶段式两者共存。

连续式其实更加能反应过程改进的本质，并且能更好地引导企业把过程改进做到实处，但连续式比较难以理解。阶段式是直接继承CMM的，大家都比较容易理解，而且阶段式有一个级别，在商业上更好宣传，但很容易导致企业为了过级而过级。

连续式和阶段式同时也是评估的两个不同角度，用连续式评估，企业会得到很多个PA的Level，用阶段式评估，企业会得到一个整体的Level。

对CMMI还不是很熟的人士，先了解这么多就可以了，以后再慢慢了解。

 

CMMI 1至5级简述

这里我们用比较容易理解的阶段式的角度，来描述一下CMMI的级别。

在模型中，所有软件组织的软件能力成熟度划分为5个等级——第1到第5级。数字越大，成熟度越高，高成熟度等级代表比较强的综合软件能力。

5个成熟度等级分别是：

l 第1级：初始级

l 第2级：受管理级

l 第3级：已定义级

l 第4级：定量管理级

l 第5级：持续优化级

第1级是不需要评估的，哪怕你们是手工作坊开发的软件公司，也可以说是CMMI1级。从2级开始到5级，SEI在每个级别都有详细的标准。

那怎样才算达到某个级别呢？

要通过高级别的评估，要满足这个级别以下所有级别的标准。

例如：

l 一个进行4级评估的企业，评估的时候首先是看是否达到2级要求，然后是3级要求，然后才是4级要求。

l 评估的时候，如果2级的标准达到，但3级的要求达不到，就算4级的要求达到了，也只能算2级。

每个级别又代表怎样的意思呢？下表简要地说明了1到5级的差异：

 

 

2级比较容易做到，要做到3级要做的事情多很多，一般来说建议2、3级一起来做。3级到4级跨度很大，要做到4级非常不容易。如果4级做得比较好，要做到5级难度不算很大。以下是各级难度的示意图：

 

 

过程域(PA)、目标(Goal)与实践(Practice)

CMMI2级到5级，每个级别都包含几个到十几个PA(Process Area)，直接翻译就叫做：过程域。

PA简单地说就是要做好软件开发的某一个方面，如果要达到某个级别的要求，就要达到该级别所有PA的要求。一个PA包含几个Goal（目标），如果要达到某个PA的要求，就意味着要达到该PA每个Goal的要求。

每个Goal怎样才算达到要求呢？每个Goal又包含几个到十几个Practice（实践），如果这些Practice都做到了，就认为该Goal达到要求了。

级别、PA、Goal与Practice的关系示意图如下：

2级有7个PA，3级有11个PA，4级有2个PA，5级有2个PA，一共22个PA，Practice的总数量超过400个。如果要达到5级的要求，意味着必须满足这400多个Practice的要求。

 

评估办法

评估一个企业达到多少级别的要求，其实就是看相应的Practice是否达到要求。评估办法根据严谨的程度，分为以下办法：

l SCAMPI C

l SCAMPI B

l SCAMPI A

SCAMPI A是最严谨的，进行正式评估的时候，必须采用该办法。下面我们简单体会一下SCAMPI A评估方法。

举一个日常的例子，比方说你今天中午吃了饭，但别人不知道，别人要判断你是不是吃了饭，用SCAMPI A的办法来判断的话，需要提供以下证据：

1)书面直接证据，能证明你吃了饭的书面的直接的证据。如果你去餐厅吃饭的，你的帐单就可以用来做直接证据，如果你在家做饭，那就麻烦，可能没有能留下直接书面证据了。

2)书面间接证据：比方说你在家做饭，之前去买菜了，你买菜的账单就可以作为间接书面证据。

3)访谈证据：如果别人问你，今天中午有没有吃饭，你能准确说出来，并且没有疑点，那就认为证据有效了，或者是如果你和别人吃饭，别人能说出跟你吃了饭，也认为证据有效了。

以上3方面的证据，第一个证据书面直接证据，是必须要有的，同时第2和第3类证据，至少要有一个。以上证据都具备，才能认为你吃了饭。

我想大家可能要“吐血”了，为了要证明吃了饭，居然要这样麻烦！当然吃饭只是一个例子，我们进行CMMI评估的时候，每一个Practice都需要提供这样的证据。

准备评估没有什么捷径，就是老老实实按照CMMI的要求去做，认真做好过程改进的工作，认真准备书面证据，访谈的时候就按照实际的做法老老实实的回答。

 

企业商业目标与CMMI

有一种业内普遍的误解，好像CMMI级别越高，项目的成本就越高。那么我们要问，为什么我们还要去追求高级别呢？企业到底为什么要去评估CMMI？

业内也有另外一种误解，CMMI是用来提高软件质量的。那么CMMI不用来加快软件开发进度，节省成本吗？软件开发从来就是质量、进度、成本的平衡，CMMI只关注一个方面吗？

公司的商业目标，简单地说两个字可以概括——“赚钱”！为了赚钱，我们有很多办法：

l 提高质量，我们的质量不需要很高，比竞争对手高就可以了。

l 加快进度，我们的进度也不需要很快，但至少要比竞争对手快。

l 减少成本，成本也不必减少很多，关键是能支持公司运作，能带来利润就可以了。

CMMI是为企业的商业目标服务的！既不是纯粹提高质量，也不是光增加公司的成本而不提高效益。CMMI是为了提高企业的生产力！

如果贵公司实施了CMMI，而没有提高生产力的话，改进是失败的，违背CMMI的初衷的。CMMI是个好东西，我们没有做好，并不是CMMI的错，是我们没有理解好或者是执行好。

要让CMMI切实为企业带来价值，难度很高，如何才能做到？这些内容可以写一本书。本文希望能澄清大家的一些思想误区，扫扫CMMI的文盲，为切实发挥CMMI的作用做好准备。

关于如何提高公司的测试力量的思考

 

（也是很久以前的一篇随笔了）

这段时间虽然很少做测试工作，可是无论是准备测试外包推广资料，还是听外国客户分析需求，或者是对其他项目组进行的规范检查，感触都颇多。大概由于自己是一名测试人员，所以也就更多的以测试角度去思考这些事情。特别是在检查youtalk项目组后，再结合以前检查Open Activity的情况，我更深刻地意识到提高测试力量不应该只是测试部门要做的事情，而应该是一个“全民意识”。

在这里，我就将自己在测试工作中或者是在规范检查中遇到的几种比较典型的现象列举下来，如果我的认识有偏差，希望大家批评指正；当然更希望大家能够讨论，给出解决建议。另外，也有一些是包括我在内的部分测试人员都比较头疼却还没有解决方案的问题，也希望能得到大家的帮助。

 

1.       测试依赖客户

这是我在规范检查中发现的问题，这通常发生在没有安排专门测试人员的项目组中。至于后果，大家应该都清楚，那就是长期这样，将会大大降低客户对我们的信任度，并且这对于我们的质量提高也是毫无好处的。

解决这个问题，得从思想上增强质量意识，而对象，则应是公司的每一个人。

 

2.       这是谁提交的bug

测试人员几乎都遇到过这样的情况，“这是谁提交的bug，客户提出的吗？需求上明确说明了吗？”如果后两个问题都给出的是否定的回答，那么，很可能这个bug就会被降低优先级甚至是拒绝修改。

当然这得从两个方面来考虑改进，对于测试人员而言，得提高自己的测试技术，提高bug的质量；另一方面，大家都得意识到，提高质量是我们共同的目标。

 

3.       侥幸心理

虽然在以前的规范检查中，也曾意识到这个问题，而真正思考它，则是本次SPP客户反溃回来的bug引起的。这次的bug有几个改动比较大，特别是在产品已基本成型的后期，则要付出更大的代价。然而，那些bug本来在之前就已发现，可就是一种“反正不影响使用，客户不提出来就不用改了”的侥幸心理搁置到了现在。

该如何平衡质量与代价？

 

4.       测试从何下手

检查过两个不含测试人员的项目组，关于测试方面，都抱怨着同一个问题：测试技术缺乏，测试力度不够，有时甚至不知从何着手。

我想能意识到这一点是很好的，但要解决这个问题，一方面希望测试部门能制定相应的测试规范，同时随时将经验总结并共享；另一方面，如果能组织一些测试人员与开发人员之间的沟通交流及学习培训活动，相信能够有所帮助。

 

5.       没有领头羊

测试部门正处于发展建设中，我想我们可以更多地从这方面进行考虑，希望部门内每个测试人员都有自己的特点和长处，譬如某项目需要进行性能测试时，希望能够立即找到可以请教及协助的测试人员，而不是抓瞎。

 

6.       忽视bug分析

以前总以为bug分析是测试流程的一部分，理应测试人员来完成。可是在完成本次规范检查后，我意识到，bug分析对于测试人员重要，对于开发人员或者是兼任测试的开发人员更为重要。毕竟，我们的最终目的不是发现bug，而是杜绝bug的产生。

 

似乎想得挺多，真正写出来却也没有几点。只是希望通过大家的讨论，能提高所有人的质量意识，并给出一些建议，特别是对于测试力量薄弱的项目组。

 

                                            Created at 2008-9-5 17:54

初识用户体验

 

（很久以前写出来的一点小东西，当时大概也是东拼西凑吧。今天整理电脑中的文件时，想想曾经也是认真地对待过它，不忍丢弃，所以将它粘贴在了这里）

近段时间接触的是WEB方面的测试，感觉与测试Win程序的不同之处除了业务逻辑的差别而外，还有比较重要的一点就是更关注于用户体验，于是也就下意识地多做了一些了解，再此整理出来，一来可以看看自己是否真有条理地理解了这一概念，同时也可将自己的想法粘贴出来与大家共享，权作抛砖引玉之意。

 

一、什么是用户体验

用户体验，英文叫做user experience，缩写为UE, 或者UX。一个较常见的定义是“指用户访问一个网站或者使用一个产品时的全部体验。他们的印象和感觉，是否成功，是否享受，是否还想再来使用。他们能够忍受的问题，疑惑和BUG的程度。”

这是由英文直接翻译而来，生硬费解。而在我看来，用户体验就是一种用户在使用产品时所建立起来的心理感受。心理感受是纯主观性的，也就带有一定的不确定因素，不过，在界定用户基本确定的情况下，其用户体验的共性是能够通过良好的设计来实现的。

 

二、提升用户体验的重要性

从用户角度来说，如今软件行业发展甚为迅速，各种软件产品更是形形色色，用户成了强势的群体，他们不再满足于使用的软件能实现其需要的功能，更追求一种使用过程中的良好的心理感受，用一种形象的说法就是用户是用他的脚来为软件投票的，非常简单的道理，你的产品不好，他就走掉了。

从软件公司的角度来讲，提升产品的用户体验度可增加用户对软件产品乃至公司品牌的好感和信任度，这会使得我们的产品在市场上更有竞争力。同时，若从产品开发之初，就本着一种提升用户体验度的思想，那么还可节约后期的开发及测试成本。

因此，提升用户体验度从近处来说是为了完善当前产品，从长远来看，则可影响到公司的长期发展。

 

三、用户体验包括什么

有人将用户体验与软件的运行效率混为一谈，认为用户体验就指响应时间、可靠性、稳定性这三方面。其实这只是用户体验的一部分。我认为用户体验度可用几个简单的词来概括：

有用：此处的有用是指正确的实现了用户的需求，勿庸置疑，这是最基本最首要的一点。

易用：这也非常关键，不容易使用的产品，也是没用的。产品要让用户一看就知道怎么去用，而不要去读用户手册。这也是设计的一个方向。

好用：这就包括软件的运行效率等方面，社会节奏越来越快，用户不会接受需要两分钟才能进入某页面的一个软件。

友好：良好的人机交互，这就要求我们开发过程中以用户为中心，这一点会体现到产品的各个细节，包括一句简单的提示用语。我们需要记住一点：我们要做的是去适应用户，而不是改变用户。

 

四、如何提升产品的用户体验度

1、树立意识

若要使我们开发出来的产品具有良好的用户体验度，我觉得，首先大家要树立以用户为中心的这样一种意识，这一点无论对于开发人员或是测试人员都是必需的（当然，测试人员的这种意识会显得更重要）。在软件产品的使用中，用户不会介意我们当他当成“傻瓜型用户”，越简便的操作越会得到用户喜欢。

当这种意识贯彻到了软件生命周期的各个阶段，那么，我们开发出来的产品会是成功的。

2、把握规则与灵活

所谓规则也就是强调统一性：整个软件产品的风格应是一致的，相同功能在不同地方的操作方式应是统一的，等等。

所谓灵活，就是允许特殊情况特殊处理：有时，当常规的几个操作可以揉为一个简单的步骤时，那么我们绝不会要求用户分几步。

遵守统一的规则是基本原则，适情况的灵活处理是‘改革开放’。

3、完善细节

前面我们说过，用户体验是一种纯主观的心理感受，因此，某些细节之处对于软件功能来说也许影响甚小，但对于用户、对于我们要将软件实现产品化，或许就起着很大的作用了。只要会使用电脑的人大概都不会不知道百度、Google，我们稍稍留意就可发现它们在细节方面是下了很大的功夫的。举例来说，5.12地震发生后，当国家刚公布全民哀悼日的消息，百度就在第一时间将网站的style换成了灰白色；又如，它们的Logo不会一成不变，在情人节、端午节等时刻我们就会发现Logo换成了漂亮的、有节日特征的图片了。而事实上，百度有专门的“用户体验部”和用户体验设计师，也由此可见，欲成功的产品是不会忽视用户体验的。

细节分布于软件产品的各个方面，但概括来说，我以为我们可从以下几个点着手完善：

优化流程：此处的流程单指用户要完成某任务的操作流程而并非指软件系统的开发流程。这需要我们在开发或测试的时候通过揣测用户的心理、模拟用户的操作来评估当前流程是否还需要优化，如考虑当前操作若细分为两个步骤是否更恰当？这几个操作步骤是否可简化？这个功能移植到某处是否更方便用户操作？

界面美观与协调：这在用户体验话题中大概是被提得最多的要素，这一点上本身又包括太多的细节，如布局、色彩、字体，甚至按钮及输入框的长宽大小等都应考虑到。

提示用语友好规范：提示用语会伴随在用户的整个使用过程中，因此，强调用语规范并且温馨友好的是很有必要的。特别是对于我们做外包行业的公司，更应该要强调这一点，因为这不只会影响用户的心情，还会影响对我们人员及公司水平和服务态度的看法。

符合用户习惯：由于每个用户都有个体特殊性，因此不可能面面俱到，但是至少得符合通用操作习惯，如支持鼠标与键盘操作等等。

适时提供帮助：这包括两个方面，一是在操作过程中，对软件要执行的动作等应有简略的说明；另一方面，当用户在使用过程中，遇到难题时，应该能够即时地寻求到帮助，包括提供用户手册等。

针对于我们公司的具体实际，我觉得还应该强调一点，那就是本地化与全球化：本地化和全球化不仅仅是简单的文字翻译转换，还必须根据目标语言国家的市场特点、文化习惯、法律法规、风俗禁忌等情况进行本地特性开发、界面布局调整等工作。这对于我们树立一个成功的外包企业形象是必需的。

 

我觉得用户体验是一个既浅显又高深的话题，作为一名测试人员，我要做的就是不断地学习、应用和总结。上面所说的都是一些认识还很浅的理论，可能还有一些不完善甚至不正确的观点在里面，希望能够得到大家指正。

 

 

通过分解页面可以得到：比较大的响应时间到底是页面的哪个组件引起的？问题出在服
务器上还是网络传输上。
这里为了解说各个时间（比如：DNS 解析时间、连接时间、接受时间等），简单说一下浏览器从发送一个请求到最后显示的全过程。

1. 浏览器向Web Server 发送请求，一般情况下，该请求首先发送到DNS Server 把DNS名字解析成IP 地址。解析的过程的时间就是DNS Resolution。这个度量时间可以
确定DNS 服务器或者DNS 服务器的配置是否有问题。如果DNS Server 运行情况比较好，该值会比较小。

2. 解析出Web Server 的IP 地址后，请求被送到了Web Server，然后浏览器和Web Server 之间需要建立一个初始化连接，建立该连接的过程就是Connection。这个度量时间可以简单的判断网络情况，也可以判断Web Server 是否能够响应这个请求。如果正常，该值会比较小。

3. 建立连接后，从Web Server 发出第一个数据包，经过网络传输到客户端，浏览器成功接受到第一字节的时间就是First Buffer。这个度量时间不仅可以表示Web　Server 的延迟时间，还可以表示出网络的反应时间。

从浏览器接受到第一个字节起，直到成功收到最后一个字节，下载完成止，这段时间就是Recieve。这个度量时间可以判断网络的质量（可以用size/time 比来计算接受速率）。
其他的时间还有SSL Handshaking（SSL 握手协议，用到该协议的页面比较少）、client Time（请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的think time 或者客户端其他方面引起的延迟）、Error Time（从发送了一个HTTP 请求，到Web Server 发送回一个HTTP 错误信息，需要的时间）。

熟悉了以上各个时间的含义后，我们开始看分解页面的图形。

首先看“Downlaod Time Breakdown”，可以看出login 事务分解的各个组件的大小，以及各个组件的下载时间。
从下图可以看出，login 页面有5 个组件组成，其中next.gif 下载用的时间最长，并且几乎所有的时间都用在了First Buffer 上，而其大小为1.256KB，并不是很大。

上图提供的组件大小的信息比较简单，更详细的信息参考“Download Component SizeGraph”。利用该图可以看出该页面各种组件的大小所占的比例关系。

同样，要看各个组件下载时间的更详细的信息，可以参考“Page Component Breakdown”。利用该图可以看出该页面各种组件下载时间的比例关系。

选择“Component Breakdown（Over Time）”，可以以图形曲线的形式看出各个组件在场景运行中的每秒钟的下载时间，比较具体。要看到具体的值，可以参考Page Component Breakdown（Over Time）

然后再选择“Download Time BreakDown（Over Time）”，从中可以看出在场景运行中的每一秒钟，组件用在传输的各部分的时间。要看到具体的值，可以参考Page Download Time　Breakdown（Over Time）

为了确认问题缘由到底是服务器还是网络，选择“Time to First Buffer Breakdown”，可以看出Server 时间比network 时间要高的多，从而确定问题是服务器引起的。然后我们就可以参考Web Server 的相关图表，来确定问题是由服务器的哪个部分引起。遵从这样的步骤，可以一步步的接近问题源；如果问题由网络引起，可以参考NetWork 相关的图表，确定什么样的网络问题是性能的瓶颈。同时可以参考“Time To First Buffer BreakDown(Over Time)”