还是得，good good study,  day day up
考试目标：系统分析师
考试内容：
 

第一部分系统分析师最新考试大纲

系统分析师级考试大纲

一、考试说明
1．考试要求：
（1）具有系统工程的基础知识；
（2）掌握开发信息系统的综合技术知识（硬件、软件、网络、数据库）；
（3）熟悉企业和政府信息化建设，并具有组织信息化战略规划的知识；
（4）熟练掌握信息系统开发过程和方法；
（5）熟悉信息系统开发标准；
（6）掌握信息安全的相关知识与技术；
（7）理解软件质量保证的手段；
（8）具有经济与管理科学的相关基础知识，熟悉有关的法律法规；
（9）具有大学本科的数学基础；
（10）熟练阅读和正确理解相关领域的英文文献。

2．通过本考试的合格人员熟悉应用领域的业务，能分析用户的需求和约束条件，写出信息系统需求规格说明书，制订项目开发计划，协调信息系统开发与运行所涉及的各类人员，能指导制订企业的战略数据规划，组织开发信息系统，能评估和选用适宜的开发方法和工具，能按照标准规范编写系统分析、设计文档，能对开发过程进行质量控制与进度控制，能具体指导项目开发；具有高级工程师的实际工作能力和业务水平。

3．本考试设置的科目包括：
（1）信息系统综合知识，考试时间为150分钟，笔试；
（2）信息系统分析与设计案例，考试时间为90分钟，笔试；
（3）信息系统分析与设计论文，考试时间为120分钟，笔试。
二、考试范围
考试科目1：信息系统综合知识

1．计算机系统综合知识
1.1 计算机组成与体系结构
·构成计算机的各类部件的功能及其相互关系
·各种体系结构的特点与应用（SMP、MPP）
·计算机体系结构的发展

1.2 数据通信与计算机网络
1.2.1 数据通信的基本知识
1.2.2 网络体系结构与协议
·开放系统互连参考模型
· TCP/IP 分层模型
·常用的协议标准
1.2.3 计算机网络分类
·分类方法
·局域网定义及类型
·广域网定义及类型
1.2.4 Internet
·路由结构
·地址和域名
·万维网应用
·可扩展标记语言（XML）

1.3 软件知识
1.3.1 操作系统
·操作系统的类型与结构
·系统的并行机制
·网络操作系统
·分布式操作系统
·嵌入式操作系统
·主流操作系统产品
1.3.2 数据库系统
·数据库管理系统的类型、结构
·关系数据库及其主流产品
·数据仓库与联机分析处理
·数据挖掘
1.3.3 中间件

1.4 系统配置与性能评价
· Client/Server与Browser/Server结构、三层或多层结构、分布式系统
·系统配置方法（双份、双重、热备份、容错、集群）
·典型基准测试程序（Benchmark）
·系统性能计算，系统性能指标，系统性能评估
·系统可靠性指标、经济效益指标

1.5 计算机应用知识
·信息管理、数据处理、辅助设计、自动控制、科学计算、人工智能
·远程通信服务，Web计算
·多媒体技术基础

2．信息化基础知识
2.1 信息化
·信息与信息化
·信息化对组织的意义
·组织对信息化的需求

2.2 政府信息化与电子政务
·政府信息化的服务对象
·电子政务的概念、内容和技术形式
·电子政务建设中政府的作用和地位
·我国政府信息化的策略和历程
·电子政务建设的过程模式和技术模式
·信息化建设中政府领导部门、业务部门和技术部门各自的作用
·新形势（政务公开、公共应急事件预警报警）对政府信息化思路的影响

2.3 企业信息化与电子商务
·企业信息化的概念、目的、规划、方法
·企业资源规划（ERP）的结构和功能
·客户关系管理（CRM）在企业的应用
·企业门户
·企业应用集成
·供应链管理（SCM）的思想
·商业智能（BI）
·电子商务的类型、标准

2.4 信息资源管理（信息系统的管理，标准、法规的制定与实施，信息资源的安全管理，人力资源管理等）

2.5 信息化的有关的法律和规定（知识产权、标准、质量、安全、互联网管理等方面的法规）

3．信息系统知识
3.1 信息系统
·信息系统概念
·信息系统的功能
·信息系统的类型
·信息系统的发展

3.2 信息系统建设
·信息系统建设的复杂性
·信息系统的生命周期，各阶段目标和主要工作内容
·信息系统建设的原则
·信息系统开发方法（结构化分析设计方法、原型化方法、战略数据规划方法等）

3.3 软件工程
·软件需求分析与定义
·软件设计、测试与维护
·软件复用
·软件质量保证及软件质量评价
·软件配置管理
·软件开发环境
· CASE工具
·软件的知识产权保护

3.4 项目管理知识
·信息项目计划
·项目计划的控制
·项目工作量估算
·风险管理
·资源和任务分配
·项目的生命周期管理

3.5 软件过程
·软件过程的定义和范围
·软件过程的作用
·主要的软件过程及其特点
·软件过程能力评估（CMM、CMMI）
·软件过程改进
·软件过程标准

3.6 质量管理
·质量保证计划
·质量认证体系
·质量管理和质量管理技术
·全面质量管理
·质量管理理论

4．信息系统开发与运行知识
4.1 软件工程技术
·软件生命周期
·软件开发模型（瀑布模型、螺旋模型、喷泉模型）
·成本模型
·软件复用技术（构件、逆向工程）

4.2 软件需求分析和设计方法
·结构化分析与设计
·分析设计图示（DFD、ERD）
·面向对象分析与设计（继承、抽象、代理、封装、多态）
·统一建模语言（UML）
·模块设计（内聚性、耦合性）
· I/O设计（报表设计、屏幕设计、代码设计）
·人机界面设计

4.3 开发环境与开发工具
·集成开发环境
·开发工具（建模工具、分析设计工具、开发平台、测试工具、项目管理工具等）
·软件开发平台的比较

4.4 软件包
·开发工具
·管理工具
· OA工具
·群件

4.5 程序设计
·程序设计语言（种类、发展和特点）
·程序设计方法（结构化、面向对象、并行、网络程序设计）

4.6 测试与评审
·常用测试方法
·测试计划和测试过程
·测试报告和测试结果分析
·软件测试自动化
·软件测试规范标准
·评审方法和原则

4.7 应用系统构建、集成
·应用系统开发（分析设计方法的选择，开发的组织、分析设计的实施）
·软件包的使用
·数据库设计（E-R模型，范式，SQL，数据分布）和实施
·网络工程（网络规划、设计、实施和测试）
·系统集成（控制集成，数据集成，表示集成，应用集成，外部资源使用）

4.8 系统运行
·系统运行管理（计算机系统、数据库、网络）
·系统成本管理
·系统运行（作业调度、数据I/O管理、操作手册）
·用户管理
·分布式系统管理
·硬件资源管理
·软件资源管理（程序库管理、版本管理）
·数据资源管理，网络资源管理
·设备和设施管理（电源、设备管理、设施安全管理）
·系统故障管理（处理手续、监视、恢复过程、预防措施）
·安全性管理
·系统运行工具（操作工具、监视工具、诊断工具）
·系统转换（转入运行阶段、运行测试、版本控制）
·系统运行服务标准

4.9 系统维护
·维护的类型（完善性维护、纠错性维护、适应性维护、预防性维护）
·维护的实施（日常检查、定期维护、预防性维护、事后维护、远程维护）
·硬件维护、软件维护
·合同维护

4.10 系统评价
·性能评价
·经济效益评价

5．安全性知识
·数据安全和保密、加密与解密机制
·通信和网络安全
·系统访问控制技术
·数据库完整性
·计算机安全操作
·计算机故障诊断和防范，防治计算机病毒，防计算机犯罪，入侵监测
·安全管理措施，有关的法律、法规、制度
·风险管理与分析（风险类型、抗风险措施和内部控制）

6．标准化知识
·标准化的概念（标准化的意义、标准化的发展，标准的生命周期）
·标准的层次（国际标准、国家标准、行业标准、地方标准、企业标准、项目规范）
·标准的对象（代码标准、文件格式标准、安全标准、软件开发规范和文档标准）
·标准化机构

7．经济等相关知识
·会计常识
·财务成本管理
·现代企业组织结
· IT审计的相关常识（审计标准、审计实施和审计报告）

8．数学
·事件和概率
·随机变量和分布函数
·数理逻辑
·图论
·组合分析
·算法及其复杂性

9．管理科学
·运筹学模型
·系统模型
·数量经济模型
·系统工程

10．专业英语
·具有大学毕业程度的英文词汇量
·能熟练阅读和准确理解相关领域的英文科技文献

考试科目2：信息系统分析与设计案例

1．系统计划
·信息系统项目的提出与选择，项目优先级的确定
·基于管理层次的业务评价
·根据现在的情况对未来的信息系统的目标、功能、构架、能力、维护、应用方法及困难情况进行分析
·可行性研究与效益分析
·系统方案的制订、评价和改进
·新旧系统的分析和比较
·遗留系统的评价和处理策略
·所需资源估计
·现有软件、硬件和数据资源的有效利用
·对企业信息战略有益的技术调研和评估
·制订信息系统的评价标准
·计划变更与控制

2．需求获取
·业务模型的提取以及图形化和文档化
·对象业务流的提取和确认
·从信息系统的观点对确认的内容进行整理
·对业务问题的分析和解决方法
·业务功能的模型化
·全体对象业务以及业务功能整合方面的探讨
·现有软件系统的分析
·确认测试计划
·流行的需求分析方法
·前提条件（人员、交付期及成本等）的可满足性以及在技术、经济等方面的可行性的研究

3.系统分析
·组织结构与功能分析
·业务流程分析
·数据汇总与数据流程分析
·系统功能划分与数据资源分布
·主题数据库的建立
·成本/效益分析
·系统的故障模型和可靠性模型
·系统的可靠性分析和可靠度计算
·提高系统可靠性的措施
·系统的故障对策和系统的备份与恢复
·系统分析的实用技术
·流行的系统分析方法

4．系统设计

4.1 建模技术
·建模的作用和意义
·需求建模的步骤
·用例驱动的开发方式
·概念模型与设计模型
·结构化建模技术，数据流图
·面向对象建模技术
·逆向工程
·定义问题与归结模型（目标、功能、性能等）
·数据库建模

4.2 系统设计
·系统构架设计
·处理流程设计
·系统人机界面设计
·数据库管理系统的选择与数据库设计
·系统的文件设计
·系统安全性设计
·网络环境下的计算机应用系统的设计
·分布式应用系统的设计
·多媒体应用系统的设计
·系统运行环境的集成与设计
·系统处理能力评估
·系统测试计划以及测试的实施
·系统转换计划

5．文档编制和沟通能力
·信息战略文档化
·信息系统构想文档化
·可行性研究报告
·项目开发计划
·需求规格说明书
·数据要求规格说明书
·用户手册
·操作手册
·测试计划、测试分析报告
·技术报告
·开发进度记录
·项目开发总结报告

6．系统运行和维护
·系统转换的需求和基本方法（数据库转换、网络环境转换、业务规范的转换与变更）
·软件维护的实施和管理
·系统软硬件配置管理
·系统使用效率的跟踪
·基本软件和软件包的引入、应用、管理和二次开发
·系统的集成和扩充
·操作设计和运行管理
·系统的更新与维护
·短期计划和长期计划
·新旧系统的转换交接
·日常的故障对策与恢复
·系统的日常安全管理
·系统的服务质量和运用评价

7．软件过程改进
·软件过程改进的管理
·软件过程改进的体系设计
·软件过程改进的技能
·软件过程改进的工具

8．系统开发项目管理
·进度管理
·成本管理
·质量管理
·采购管理
·风险管理
·资源管理

9．企业信息化战略与实施
·信息规划与战略规划的关系
·信息规划的概念、活动与角色
·信息系统规划方法
·企业过程重组
· CIO的概念和主要职责
·管理咨询在信息化中的作用和意义
·管理咨询的类型
·我国管理咨询的发展现状
· "信息孤岛"形成的根源、预防，以及应对措施
·典型的信息化实施过程
·知识管理的含义
·知识管理对组织信息化的意义
·知识管理常用的工具和手段

考试科目3：信息系统分析与设计论文

　　根据试卷上给出的与系统分析设计有关的四个论文题目，选择其中一个题目，按照规定的要求撰写论文。论文涉及的内容如下：

1．信息系统工程
·系统计划和分析
·需求分析与定义
·系统测试
·系统维护
·项目管理
·质量保证
·面向对象技术
·计算机辅助软件工程
·软件过程改进
·实时系统的开发
·应用系统分析设计（嵌入式系统、数据仓库、互联网应用等）

2．数据库工程
·数据库分析
·数据库建模
·数据库管理

3．系统安全
·数据安全
·网络安全
·容错与容灾

4．应用系统集成
·集成的对象
·集成的方法
·集成的工具

5．企业信息化和政府信息化
·战略和策略
·组织和实施
·方法和步骤

6．新技术的应用
·极限编程（XP）
·敏捷开发

 

 

又是好久没有更新，看来真的和一个朋友说的一样，工作最近几年来，自己变懒了，没以前那么爱学习，没以前那么上进，

3 其它度量
这里介绍一些其它的基本的很少使用的度量的益处和弱点。
3.1 函数覆盖（Function Coverage ）
这个度量报告是否你调用了每个函数或过程。对于初步的测试来保证至少在所有的软件没有总的不足非常有用。 
大多数覆盖率工具都支持。
3.2 函数出入口覆盖（Function Exits Coverage）
报告对函数的入口、出口和终止指令.覆盖情况统计。
据我所知，TestRT支持此覆盖。
3.3 调用覆盖（Call Coverage ）
这个度量报告是否你执行每个函数调用。前提是缺陷一般发生在模块的接口处。 
也称呼为调用对覆盖（call pair coverage）。
据我所知，TestRT支持此覆盖。
3.4 线性代码顺序及跳转覆盖（Linear Code Sequence and Jump (LCSAJ)  Coverage ）
这个是路径覆盖（path coverage ）的一个变更。考虑到在源代码中只有子路径可以被容易的替，不需要一个流程图。一个LCSAJ 是一系列源代码线执行的序列。
优点是这个度量比判定覆盖测试的更彻底，而且避免了路径覆盖的指数级的难度。缺点是它不能避免不可实行的路径。 
据我所知，LDRA TestBed支持此覆盖。
3.4.1 覆盖率的计算公式：
 
如下图所示：
 
一个LCSAJ是由以下四个特征的数量决定的。
A Start Point：可以是程序的开始或任何控制流跳转的目标的线。
A Linear Code Sequence：通过可以系列处理的控制流的代码体。可以由几个连续的基本块组成。
An End Point：The first line encountered from which a jump is made which has been reached from the start point by the unbroken linear sequence of code.
A Target Point： The point to which the End Points" control flow jump is made. This will be the Start Point of the next LCSAJ. Therefore, since the start point of the linear code sequence is a line which is the target of another jump, these fragments are also called jump-to-jump paths.
这个例子的计算此LCSAJ覆盖的分母就是11。
3.5 数据流覆盖（Data Flow Coverage ）
这是path coverage的一个变种，只是考虑到从变量的分配到后来的变量的引用的子分支。
好处是直接适当的报告程序处理的数据。一个缺点是不包含判定覆盖，另一个缺点是太复杂。很多的变量，用于计算的、用于判定的、局部的、全局的，如果有指针就更复杂。 
3.6 目标代码分支覆盖（Object Code Branch Coverage ）
这个度量报告是否机器语言条件分支通过了分支。 
这个度量给出的报告更多的是依赖编译器而不是程序结构。因为目标代码的结构和源程序的结构很不相似。而且，分支破坏了指令通道，编译起有时候避免产生一个分支，而替换为一个系列的无分支指令。 
3.7 循环覆盖（Loop Coverage ）
这个度量报告你是否执行了每个循环体零次、只有一次还是多余一次（连续地）。对于do-while 循环，循环覆盖报告是否执行了每个循环体只有一次还是多余一次（连续地）。
这个度量的有价值的方面是确定是否对于while循环和for循环执行了多于一次，这个信息在其它的覆盖率报告中是没有的。 
据我所知，GCT和rational TestRT可以执行这个度量。 
3.8 竞争覆盖（Race Coverage）
这个度量报告是否多个线程在同一时间执行了同一块代码。它帮助检测资源的同步失败问题。对于多线程的程序例如操作系统程序非常有用。 
据我所知，GCT可以执行这个度量。 
3.9 比较操作符覆盖（Relational Operator Coverage）
这个度量报告是否对于比较操作符(<, <=, >, >=)是否发生了边界条件。假设边界条件测试用例发现了off-by-one errors ，并且 错误使用了比较操作符，例如把< 用作了<=。例如，考虑如下的C/C++ 代码： 
if (a < b)
    statement;
比较操作符报告是否发生了条件a==b。如果If a==b 发生了而且程序执行正常，那么。。。。。。 
据我所知，GCT可以执行这个度量。
3.10 弱变化覆盖（Weak Mutation Coverage）
这个度量和relational operator coverage 相似，但是更普遍[Howden1982]。它报告是否测试用例发生了错误的引用了操作符和操作数。
据我所知，GCT可以执行这个度量。 
3.11 表覆盖（Table Coverage）
这个度量显示是否一个特殊的数组的每个入口都被引用。这个度量对于一个通过有限状态机来控制的程序非常有用。
4 比较各种覆盖
· Decision coverage 包含statement coverage， 
· Condition/decision coverage 包含decision coverage 和 condition coverage 
· Path coverage 包含 decision coverage. 
· Predicate coverage 包含 path coverage 和multiple condition coverage 
Academia说强的覆盖率度量包含了弱的覆盖率度量。
各种覆盖率度量结果不能从数量上比较。
4.1 对Release版本的覆盖目标
每个项目都要选择一个最低的覆盖率目标，对安全标准严格要求的软件应该制定一个高的目标。单元测试的目标应该比系统测试的高，因为一个在低水平代码的failure 可以影响到多个高水平代码的调用者。 
用statement coverage, decision coverage或condition/decision coverage ，在发行版本前80 -90  或更多的覆盖率。可能有人觉得制定的目标少于100 的覆盖率不能保证软件质量，但是你耗在覆盖率技术上的时间如果用于其它测试技术，例如代码走读等，将会发现更多的faults，要避免制定的目标少于80 。 
4.2 中间版本的覆盖目标
选择一个好的中间的覆盖率目标可以很大的提高测试的生产力。 
当你发现最多的 failures用了最少的努力， 那你就有最高的测试生产力。努力怎么测量呢？创建测试用例，把它们加入到你的测试套并运行它们的总时间就是。 
5 总结
覆盖分析是一种结构化测试技术，帮助弥补测试套中的缝隙。对缺少具体的、没有更新需求定义项目帮助很多。分支条件组合覆盖（Condition/Decision Coverage ）技术我觉得是对于 C, C++和Java语言的最好的。 设置一个目标100  的覆盖率(对于任一种覆盖率) 都将阻止测试的生产力，在发放版本之前，定一个80 -90  或更多的目标对于语句、分支、条件覆盖率较好。
6 参考
Beizer1990 Beizer, Boris, "Software Testing Techniques", 2nd edition, New York: Van Nostrand Reinhold, 1990 
Chilenski1994 John Joseph Chilenski and Steven P. Miller, "Applicability of Modified Condition/Decision Coverage to Software Testing", Software Engineering Journal, September 1994, Vol. 9, No. 5, pp.193-200. 
RTCA/DO-178B, "Software Considerations in Airborne Systems and Equipment Certification", RCTA, December 1992, pp.31, 74. 
Howden1982 "Weak Mutation Testing and Completeness of Test Sets", IEEE Trans. Software Eng., Vol.SE-8, No.4, July 1982, pp.371-379. 
McCabe1976 McCabe, Tom, "A Software Complexity Measure", IEEE Trans. Software Eng., Vol.2, No.6, December 1976, pp.308-320. 
Morell1990 Morell, Larry, "A Theory of Fault-Based Testing", IEEE Trans. Software Eng., Vol.16, No.8, August 1990, pp.844-857. 
Ntafos1988 Ntafos, Simeon,"A Comparison of Some Structural Testing Strategies", IEEE Trans. Software Eng., Vol.14, No.6, June 1988, pp.868-874. 
Roper1994 Roper, Marc, "Software Testing", London, McGraw-Hill Book Company, 1994 
7 术语表
Fault ――― A bug. A defect。一个臭虫，一个过失。 
Error ―――一个人为的错误，结果是一个fault。
Failure ―――fault的一个实时运行时的表现。

2 基本的度量
有许多覆盖率度量存在，这里介绍一些基本的度量的益处和弱点。 
2.1 语句覆盖（Statement Coverage ）
这个度量报告每一个可执行语句是否被执行。 
也称为：行覆盖（line coverage）, 段覆盖（segment coverage） [Ntafos1988], C1 [Beizer1990 p.75] 和基本块覆盖（basic block coverage）。基本块覆盖当每一个序列的语句是无分支的语句时和语句覆盖相同。 
这个覆盖度量的主要好处是它可以直接应用在目标码上，不需要对源代码进行处理。执行轮廓就完成了这个度量。
这个覆盖度量的主要缺点是对一些控制结构很迟钝。例如，考虑下列的C/C++ 代码： 
int* p = NULL;
if (condition)
    p = &variable;
*p = 123;
如果当condition 取假的情况下，语句覆盖率显示这四句都覆盖到了，但是代码执行是失败的。这是一个语句覆盖率的严重的缺陷，IF语句是很普通的一种情况。 
语句覆盖不能报告循环是否到达它们的终止条件―――只能显示循环是否被执行了。 
既然do-while 循环通常要至少执行一次，语句覆盖认为它们和无分支语句是一样的。 
语句覆盖率对逻辑运算符反映是迟钝的(|| and &&)。 
语句覆盖不能区分连续的switch 语句。 
测试用例通常和判定有关而不是和语句有关。你可能不必用10个单独的测试用例来测试一个有10个无分支语句的语句，你可能只用一个测试用例就够了；考虑一个IF－else语句，包含一条语句在then子句，99条语句在else子句，当执行两个可能路径的其中之一时，语句覆盖率得到如下的结果： 1  或 99  的覆盖率。基本块覆盖率就忽略了这个问题。 
2.2 判定覆盖（Decision Coverage ）
这个度量报告是否BOOL型的表达式取值true 和false在控制结构中被测试到了(例如if-statement和while-statement)。 整个的BOOL型的表达式被认为是取值一个true 和false，而不考虑是否内部包含了logical-and 或 logical-or 操作符。另外，这个度量包括switch-statement cases, exception handlers, and interrupt handlers的覆盖. 
也被称为：分支覆盖（branch coverage）, 所有边界覆盖（all-edges coverage） [Roper1994 p.58], 基本路径覆盖（basis path coverage ）[Roper1994 p.48], C2覆盖 [Beizer1990 p.75], 判定到判定路径覆盖（decision-decision-path或DDP testing [Roper1994 p.39]. ）"Basis path" 测试就是选择路径来达到所有的判定覆盖. 
这个度量有语句覆盖的简单性，但是没有语句覆盖的问题。 
缺点是这个度量忽略了在BOOL型表达式内部的BOOL取值。例如考虑如下的C/C++/Java 代码： 
if (condition1 && (condition2 || function1()))
    statement1;
else
    statement2;
这个度量可以完全可以不用调用function1. 测试表达是为真时可以取condition1 为true 和condition2 为true，测试表达是为假时可以取condition1 为false。 
2.3 条件覆盖（Condition Coverage ）
条件覆盖报告每一个子表达式的结果的true 或false 。logical-and 和logical-or 独立起来。条件覆盖独立的度量每一个子表达式.
这个度量和decision coverage 相似，但是对控制流更敏感。 
但是，完全的条件覆盖并不能保证完全的判定覆盖。例如，考虑下列的C++/Java 代码。 
bool f(bool e) { return false; }
bool a[2] = { false, false };
if (f(a && b)) ...
if (a[int(a && b)]) ...
if ((a && b) ? false : false) ...
所有三个IF语句不管a和b取值是什么，判定覆盖率只能达到50％。但是条件覆盖率却能达到100％。
2.4 多条件覆盖（Multiple Condition Coverage ）
多条件覆盖报告每一个可能的BOOL型子表达式的组合发生了。相对于条件覆盖，即通过logical-and和logical-or把子表达式独立起来相比， 多条件覆盖需要的测试用例是用一个条件的逻辑操作符的真值表来确定的。 
对于C, C++和Java等具有short circuit operators的语言，多条件覆盖的益处是它需要一个彻底的测试。
缺点是它可能是非常冗长乏味的来决定一个需要的测试用例的最小设置，尤其是对于非常复杂的BOOL型表达式。另一个缺点是，这个度量需要的测试用例对于相似的复杂性的条件却需要非常大的变化。例如，考虑如下的C/C++/Java 条件：
要达到完全的多条件覆盖，第一个需要6个测试用例，
而第二个需要11个测试用例。

但是两个条件却有相同的操作数和操作符。 
对于Visual Basic 和Pascal等不具有short circuit operators的语言, 多条件覆盖对于逻辑表达式是非常有效的路径覆盖，具有相同的优缺点。考虑下列的Visual Basic 代码： 
If a And b Then
...
多条件覆盖需要四个测试用例，a 和b分别取值true 和false. 
2.5 分支条件组合覆盖（Condition/Decision Coverage ）
分支条件组合覆盖是条件覆盖（condition coverage）和分支覆盖（decision coverage）的一个混血。 它有两者的简单性但是没有两者的缺点。 
2.6 修正条件/判定覆盖（Modified Condition/Decision Coverage）
也被称为MC/DC 和MCDC. 
这个度量需要足够的测试用例来确定每个条件能够影响到包含的判定[Chilenski1994]的结果。这个度量是最早是被波音公司创建被用于航空软件中RCTA/DO-178B。 
这个度量起初是是设计来对于无short circuit operators的语言。 short circuit logical operators 在C, C++和Java语言中的作用仅仅是当它们的结果能够影响到被包含的判定的评估条件。
当以下的需求遇到时，需要考虑用MCDC覆盖：
• 需求1： 每一个程序模块的入口和出口点都要考虑要至少被调用一次，每个程序的判定到所有可能的结果值要至少转换一次。
• 需求2：程序的判定被分解为通过逻辑操作符(AND, OR, etc.)连接为BOOL条件。每一个条件对于判定的结果值是独立的，或者说单条件的变化将导致判决的变化。
所以，据以上的定义，以下三组数据是必须的。(单条件的变化将导致判决的变化)
其中T1 & T2,或T1&T3已经满足要求1，但要求满足条件2，就必须存在同时存在T1&T2&T3。
T4：（F，F），是多余的，因为一个条件改变并不能导致判决的改变。
T1（T，T）与T2（T，F）表明Y独立影响了判决，Y的独立对；
T1（T，T）与T3（F，T）表明X独立影响了判决，X的独立对。
再如：
测试用例1 (T,T,T) 和测试用例5 (F,T,T) ,对于X独立。 
测试用例2 (T,T,T) 和测试用例6 (F,T,T) ,对于X独立。 
测试用例3 (T,T,T) 和测试用例7 (F,T,T) ,对于X独立。 
测试用例2 (T,T,T) 和测试用例4 (F,T,T) ,对于Y独立。 
测试用例3 (T,T,T) 和测试用例4 (F,T,T) ,对于Z独立。 
结果，测试用例组{1,5,2,4,3} 满足MCDC覆盖对表达式X, Y和Z的要求。
明显，这不是唯一的组合，例如还有｛6,2,4,3｝。 

2.6.1 覆盖率的计算公式：
 
或者：            number of tests           
        number of tests + minimal nuber of test required

2.7 路径覆盖（Path Coverage ）
这个度量报告是否函数的每一个可能的分支都被执行了。一个路径就是一个从函数的入口到函数的出口的唯一的系列分支。 
也称呼为断言覆盖（predicate coverage）。断言覆盖可以看出可以组合的逻辑条件的路径[Beizer1990 p.98]。
因为循环引入了一个很大的路径数，这个度量只考虑一个有限数量的循环可能性。有很多的变种来处理循环，内部边界路径测试（Boundary-interior path testing）只考虑循环的两个可能性。重复零次和多于零次的重复[Ntafos1988]。对于do-while 循环，两种，零次反复和多于零次反复。 
路径覆盖的一个好处是：需要彻底的测试。
但有两个缺点：
一是，路径是以分支的指数级别增加的，例如：一个函数包含10个IF语句，就有1024个路径要测试。如果加入一个IF语句，路径数就达到2048。
二是，许多路径不可能与执行的数据无关。例如 
if (success)
    statement1;
statement2;
if (success)
    statement3;
路径覆盖认为以上语句包含四个路径，实际上只有两个是可行的：success=false 和 success=true. 
研究者发明了很多种的路径覆盖技术来避免大数量的路径。如，n-length sub-path coverage 报告你是否exercised each path of length n branches.其它变种包括linear code sequence and jump (LCSAJ) coverage 和data flow coverage. 

  1 简介
1.1 代码覆盖率分析
这篇文章给出了一个完整的代码覆盖率分析方面的概念。 
代码覆盖率分析是这样一个过程： 
· 找出程序经过一系列测试而没有执行的部分代码 
· 创建一个附加的测试用例来增加覆盖率 
· 决定代码覆盖的定量度量。 
代码覆盖率分析的一个有效方面是： 
· 识别出没有增加覆盖率的无效的测试用例。 
覆盖率分析需要被测试程序的源代码，并且经常需要用一个特殊的命令重新编译它。 
这篇文章讨论你应当考虑你的测试计划中应该如何增加覆盖率分析的细节问题。覆盖率分析有一定的好处和弱点。你应该选择一个测量方法的范围。你应该建立一个覆盖率要达到的最小百分比，来决定你什么时候停止覆盖率分析。覆盖率分析只是许多测试技术的一种，你不能只是依靠它。 
1.2 结构化测试和功能测试（Structural testing&Functional testing）
代码覆盖率分析是一种结构化测试技术 (AKA glass box testing and white box testing). 结构化测试是比较被测试程序的行为和源代码的外观目的。和功能测试相比 (AKA black-box testing), 功能测试是比较被测试程序的行为和确定的需求。结构化测试检查程序的工作，考虑结构中可能存在的逻辑缺陷。功能测试检查被测试程序的完成需求的能力，不考虑它是怎么工作的。 
结构化测试也叫路径测试（path testing）， 因为你选择测试用例来通过程序结构的路径。不要和路径覆盖率度量（path coverage）混淆，下面会介绍。 
粗略的看，结构化测试似乎不安全，结构化测试不能发现需求疏忽的错误，但是，需求定义有时并不存在，而且并不完整。这个现象是实际存在的，当产品开发的时间线就要到的时候，当需求定义很少更新，产品自身代替了需求定义的作用的时候。 
1.3 假定
一些基本原理的假定如下所列： 
· Faults ―――和控制流相关的缺陷，你可以发现这些缺陷通过变更控制流[Beizer1990 p.60]。例如，一个程序写为"if (c)" 比"if (!c)"好 。
· 你可以寻找缺陷而不必知道这个缺陷可能引起的后果和所有测试的可靠性。 
· 其它的假定包括可完成需求的定义、没有疏忽的缺陷和没有不可以达到的代码等。 

简介

　　许多测试管理者是从技术部门进到管理阶层的。尽管他们有可能受过很多测试或软件工程的培训和指导，但他们还是很难经常从失败和错误中学到管理技巧。作为一个管理者，你有两项基本工作：找出为你工作的最好的员工并且建立一个能够使员工完成工作的环境（使他们最好地完成工作）。这篇文章讲述了一些我学过的关于这些管理工作的经验。

　　总是那些人――帮助人们最好地完成工作

　　1． 为工作雇佣最好的员工

　　我遇到许多管理者，他们要雇佣的员工仅仅是他们上一个雇佣的翻版。作为一个测试管理者，你必须对你需要什么人做出评估。假设现在你的部门满是极好的探索型的测试员。如果你还要雇另一个探索型的测试员，也许比你现在的要好，但是他对你的空白领域有作用吗？也许有，也许没有。

　　工作的最佳人选也许就是你现在这个小组里所没有的类型。最佳人选或许并不“适合”你通常的工作方式。作为一个测试管理者，雇佣一个最佳的员工要用发展的雇佣策略，面试时要检验他是否符合这个策略。这可以让你找到最适合这份工作的人员，他能够完成必要的工作。

　　2.安排每周与你的每个小组成员在不被打扰的环境进行谈话

　　最为一个测试经理，主要工作之一就是定期的评定你的组织做了些什么并且是怎样做的。你还要为你的员工做一个报告，关于充分了解他们正在做什么和他们是怎样做的，以此来给做他们正式的和非正式的工作成绩考核。如果你没有了解到每个人的动态你就不应该对你的报告满意。

　　我定期地给我的小组成员每周在不被打扰的条件下做一对一的谈话。（当我管理12个员工的时候，我安排在另外一周会见另一些人）。我每周用30分钟来和每个员工谈谈他们的工作：他们工作中的问题或是意见；他们是否需要帮助，他们的表现和他们达到目标的兴奋。我一般安排一周的某天来进行一对一谈话。我事先安排出和每个人的特定时间，接下来我亲自会见他们每个人。如果我们不能把所有需要谈到的细节都包括，我们会安排另外一个时间来继续。

　　许多管理者说他们没有时间在一周会见每一个员工来谈他们的工作。据我的经验，如果我不能安排时间和我的员工进行每周的谈话，他们会来打扰我的工作，因为他们无论如何还是必须要来找我。

　　如果你安排和你员工的谈话，你必须减少计划外的打扰（既有他们的也有你自己的），并且更多的了解他们在做什么。当你清楚你的小组正在做的，你才能更有效率地帮助他们明确优先应该做的工作，重聚资源，重新计划工程的部分，排除障碍等等。
　　3.假定员工知道如何完成他们的工作的人员

　　因为很多管理者起初做的是技术工作，他们知道他们的员工现在从事的工作。他们认为他们现在知道。如果你已经管理了两三年，你也许还没有你的技术员工知道的多，尤其是怎么样完成日常工作。

　　你或者你的前任者雇佣你小组的员工。假设你雇佣这些人因为你认为他们能够完成工作，如果你设想每个人都知道如何完成他们的工作，你将得到比假设他们都不知道怎么完成的更好的效果。即使有些员工在无论你设想是否都能成功完成工作，但是有些员工将会被你对他们的想法所影响工作。

　　因为我知道我的员工都知道怎样做他们的工作，我给他们分派任务。问他们是否需要帮助，然后留他们独自完成（除非他们寻求帮助）。我的意思并不是你不应该在他们工作的时候和他们说话，你只是不该打扰他。打扰可以分为几种不同的形式：

　　· 如果你在不知不觉的情况下来到他身后，来到他的肩膀旁边，问他：“进行的如何了？”，尤其是在他们绞尽脑汁仍不得其解时, 这将仍然不能使你对他们的要求达到。。

　　· 如果你每天都问，更糟的是每个钟头都问,他们是如何做的。这看起来就像对你员工进行微机管理，很惹人烦。毕竟,你没有工作要做吗？另外, 他们会以为你认为他们不知道该如何完成工作。

　　· 如果当他们没有问你意见，你说“我会用这种方法”。这种予以打击的帮助不会有用。
.如果你不确定怎样能知道你的员工是否胜任，和每一个小组成员商讨寻求帮助的时机。每个人，包括你自己，应该选择一个规则来知道他或她什么时候成为了一个令人讨厌的家伙了。我的一个客户有一个15分钟法规。如果有人在某方面令人讨厌持续15分钟以上，他就必须停止并且和别人谈谈他的工作。

　　当你分配工作时，问问你的员工是否明白该做什么，他或她是否有方法完成。确定工作进程，如果员工遇到麻烦，他应该主动找你寻求帮助，但是如果你坚决干涉，你的员工将会把找你寻求帮助作为最后的解决方法。

　　4.对待你的员工要用他们能接受的方式,而不是你可以自己可以接受的方式“对待别人要用你愿意接受的方式”（己之不予，勿施于人）――这条黄金法则可能会对许多生活中的纯的社交因素有效，但是并不是总对工作有用。

　　有效率的管理者知道他的每一个员工需要怎样的对待方式。当其他的人更乐意接受更多的信息。一些人去需要特定的任务和指示。一些因为解决新的，很棒的，复杂的问题而更有冲劲，但是还有一些只是对他们已经知道如何去处理的问题而感到舒服。

　　另外，针对于不同的工作，我们都喜欢不同的认同方式。金钱不是表示认同的唯一方式，你可以用其他的方式来酬劳你的员工。有些人喜欢对他个人的感谢，有人乐意在公众面前的认可，一些喜欢以M﹠M方式，或者是奖励电影票，还有人希望有团队的排队来庆祝。记住无论什么的激励你的方式都不一定能激励你小组的每一个其他成员。和你的小组成员们通过讨论来了解他们每个人对奖励比较喜欢的给予方式。创造一个好的工作环境

　　5．重视结果而非时间

　　许多认可建立在员工完成工作的时间上，而不是他们最后的成绩上。但是，花费在工作上的时间不一定和创造性有必然的联系。如果你真的想改善对创作性和工作效率的认可的话，不妨考虑保证你员工每周只工作40个小时。 我常常听到一种表示对员工的异议就是“你整整一天什么都做不出来。”假设你自己处在一个巨大的障碍前，考虑你可以做什么来解决的时候，你是不是取消了会议？你的小组成员能否井然有序地安排他们的工作以至于能够最大限度发挥创造性？

　　当人们每周工作超过40个小时的时候，他们开始在工作的时候关心他们自己的事。他们花钱，他们给很久没有联系的人打电话，因为他们一直都在工作。

　　一旦你创造了一个环境，让员工在工作时间完成工作，开始鼓励他们每周不要超过40小时，接着你就可以基于他们在40个小时能够完成的工作量给他们酬劳。我总是发现这样能够提升创造力（因为员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己）。

　　当你开始注意规律，不仅仅是时间，还包括更容易地给员工的表现给予精确的适度的评价。你的员工是否完成了他们的计划和测试设计？当他们开发测试的时候，他们还要修订那些他们需要的改进的部分？（如果你只是注意有多少测试可以使用，我可以重复地开展相同的测试）计划每周工作40个小时，并且为你要在这段时间完成的工作付报酬。
　　6.承认自己的错误

　　每个人都会犯错。他们会因为忘记开会而使客户发怒。承认你犯错是令人尴尬的。我们中的许多人认为对小组承认自己犯错会失去尊严。

　　如果你不是经常犯错，你承认错误的时候其实能够赢得尊敬。如果你忘记一次会议，你为此道歉，其他的人会理解你并且最终原谅你。

　　不管你做了什么，不要否认或故意忽略你的失误。故意忽略不会让错误消失这只会让错误成长为怪物。最近，有一个委托人在会上对他的员工大声斥责。会后，他认识到他不应该那样在小组会上那样做。他只是想让他们安心工作，等过几天再道歉。

　　我建议在他们对他积累怒气之前，应该用正确的方式和他的员工交谈。他起初不愿意，但是他后来还是温和地在两天后和他的每个员工单独进行了交谈。每个人都是这样对他说的：“我只是在会后才对你感到生气的。如果您能够立即和我谈谈，我就不会把它们积累起来。但是现在已经两天过去了,我仍然对您感到生气，事实上，我还更加恼火，我现在不能确信现在是否能相信您。我不介意你对我们大吼，但是我不能确定是否还会再这样做。

　　我的客户不知道应该如何处理这种情况。他认为他的等待是正确的，但是却让问题变得更加严重。.他已经决定再也不会犯这样的错误了，而且会立刻和会员工交流。

　　他的员工用了好几个月来重新相信他，但是我的这位客户的确通过承认过错而增加了他的个人魅力。现在，他和他的员工对这件事可以当做是玩笑来说。他们说这是他的认知和能力的巨大转折点。

　　7.决定承担一个项目必须首先问你的组员是否有能力完成当你是一个下级的员工，你的老板对你说“我们是否可以在下个十月完成项目？”回答说“当然”会令人惊讶。但是，你的员工会因为你回答“我要考虑一下。”而表示赞赏。

　　即使你已经在考虑这个问题，告诉了你的员工你们将来做它，你还是应该得到足够的信息来考虑。你应该从这几方面来看：

　　·一段时间内，你也许会因为另一件工作而感到对这个问题迷惑。

　　· 也许有你正被其它需要考虑的问题所累，因为你不再有相同的时间像你第一次看到它的时候。

　　· 如果你“训练”你的上司让你的回答有漏洞，你的上司会继续给你让你回答他的压力。

　　当你与你的员工在做决定之前讨论问题时，你应该把这些和他们说一说：

　　· 我想知道是什么让你想做这个项目。

　　· 我不怕告诉我的上司要怎么处置它。

　　在决定做一个项目之前先好好做考虑是一种对你员工的尊重。另外，考虑他们的想法也会使你从他们那里赢得尊重和忠诚。

　　8.计划定期的培训

　　作为管理学的一部分，测试是一种挑战和对规则的经常性的改变。因为经常的改变，要制定定期的培训计划。如果你没有基于不断的变化而培训你的员工，你就会有损失。

　　培训可以是关于特定项目或者是技术。你可以进行训练用不同的方法：

　　· 提供一个简单的午餐，让每个你的每个组员讨论一个特定的领域。这特别对同时要做很多不同项目的小组有用。当每个人做不同的项目，这会有助于每个人了解你小组所有的工程。

　　· 做一个对每个部门的阶段说明。无论幸运与否，每个部门都会有和你小组相仿的工作，但是一般来说其它部门都不知道另外的部门在做什么。

　　· 如果你们有交叉利益的小组，你可以让两个小组都展现他们各自为公司所作的项目，或者只是针对你的测试小组。

　　· 邀请外面的专家来讲一个特定的技术或者一种项目。这些专家或者是专业的顾问，善演讲的人，也或是一个博学的朋友或同事。

　　· 如果你买了工具或者已经进行了培训，考虑组织一个内部的“使用者”会议。人们可以在那里分享他们使用这种工具的感受并且讨论它的问题，优点和恶作剧。这特别对有缺陷的追踪系统和构造管理系统有效果。

　　9.计划测试

　　作为一个测试经理，你不可能有时间去做所有你想做的事。所以，计划你和你小组能做什么。作为测试经理，首先应该确定自己的任务，是在发布之前找到大的缺陷？还是评估软件的状态？或者是帮助开发经理在发布之前做风险评估？你的任务有可能是其中一项又或者是其中几项结合。无论是怎样，在进入的玩命工作时期之前, 对测试进行计划, 你组里的每个人都要竭尽全力你不需要做所有的事。你不是对所有事都计划而是精简，你就会有时间, 然后你就可以计算出你能再做什么。

　　测试的计划是对每个产品或是对各个开发阶段的产品开展测试的策略。测试要多严格？什么测试不用进行？你在测试里要用硬件和软件的那些组合？什么样的组合不能作为彻底的，可能的，在所有的测试里都运用到的。

　　测试是一种危险的评估。你和你项目里的其它成员能够进一步做出决定：你乐意对产品的测试部分和非测试部分冒多大的的险？

　　一旦你决定要测试什么，对每个产品发展发布标准。发布标准是对每一项发布挑剔的重要性评判的客观的标准。“如果那样将会不错”不是步伐标准。“如果不那样做客户将会置我们于死地”才是发布标准的组成部分。

　　如果你计划一个测试并和你的组员一起开展项目, 你不能一直只扮演一个守门人的角色。你无须停止准许运用.你和你的项目小组或者你和项目经理一起制定评判的标准。当你们都通过了这些标准，就可以交货了。加入你们没有达成共识 ，诚实的，决定你下一步该做什么。我所有做过的项目当中，我们都必须对发布标准达成共识,所以我们为此一直工作.一些客户提出了很苛刻的标准，我们最后也达成了共识。他们更换了文件当中的发布标准,

　　解释他们在项目小组里的位置, 并且支配管理, 最后交接工作

中国象棋即军际象棋，具有悠久的历史。战国时期，已经有了关于象棋的正式记载，如：《楚辞•招魂》中有"蓖蔽象棋，有六簿些；分曹并进，遒相迫些；成枭而牟，呼五白些。"。《说苑》载：雍门子周以琴见孟尝君，说："足下千乘之君也，……燕则斗象棋而舞郑女。"由此可见，远在战国时代，象棋已在贵族阶层中流行开来了。据上述情况及象棋的形制推断，象棋当在周代建朝（公元前11世纪）前后产生于中国南部的氏族地区。早期的象棋，棋制由棋、箸、局等三种器具组成。两方行棋，每方六子，分别为：枭、卢、雉、犊、塞（二枚）。棋子用象牙雕刻而成。箸，相当于骰子，在棋之前先要投箸。局，是一种方形的棋盘。比赛时,"投六箸，行六棋"，斗巧斗智，相互进攻逼迫，而制对方于死地。春秋战国时的兵制，以五人为伍，设伍长一人，共六人，当时作为军事训练的足球游戏，也是每方六人。由此可见，早期的象棋，是象征当时战斗的一种游戏。在这种棋制的基础上，后来又出现一种叫"塞"的棋戏，只行棋不投箸，摆脱了早期象棋中侥幸取胜的成分。

秦汉时期，塞戏颇为盛行，当时又称塞戏为"格五"。从湖北云梦西汉墓出土的塞戏棋盘和甘肃武威磨嘴子汉墓出土的彩绘木俑塞戏，可以映证汉代边韶《塞赋》中对塞戏形制的描写。三国时期，象棋的形制不断地变化，并已和印度有了传播关系。至南北朝时期的北周朝代，武帝（公元561～578年在位）制《象经》，王褒写《象戏•序》，庚信写《象戏经赋》，标志着象棋形制第二次大改革的完成。隋唐时期，象棋活动稳步开展，史籍上屡见记载，其中最重要的是《士礼居丛书》载《梁公九谏》中对武则天梦中下象棋频国天女的记叙和牛僧孺《玄怪录》中关于宝应元年（公元762年）岑顺梦见象棋的一段故事。结合现在能见到的北宋初期饰有"琴棋书画"四样图案，而以八格乘八格的明暗相间的棋盘来表示棋的苏州织锦，和河南开封出土的背面绘有图形的铜质棋子，可以得到这样的结论：唐代的象棋形制，和早期的国际象棋颇多相似之处。当时象棋的流行情况，从诗文传奇中诸多记载中，都可略见一斑。而象棋谱《樗薄象戏格》三卷则可能是唐代的著作。宋代是象棋广泛流行，形制大变革的时代。北宋时期，先后有司马光的《七国象戏》，尹洙的《象戏格》、《棋势》，晁补之的《广象戏图》等著术问世，民间还流行"大象戏"。

经过近百年的实践，象棋于北宋末定型成近代模式：32枚棋子，有河界的棋盘，将在九宫之中等等。南宋时期，象棋"家澈户晓"，成为流行极为广泛的棋艺活动。李清照、刘克庄等文学家，洪遵、文天祥等政治家，都嗜好下象棋。宫廷设的"棋待诏"中，象棋手占一半以上。民间有称为"棋师"的专业者和专制象棋子和象棋盘的手工业者。南宋还出现了洪迈的《棋经论》、叶茂卿的《象棋神机集》、陈元靓的《事林广记》等多种象棋著述。元明清时期，象棋继续在民间流行，技术水平不断得以提高，出现了多部总结性的理论专著，其中最为重要的有《梦入神机》、《金鹏十八变》、《桔中秘》、《适情雅趣》、《梅花谱》、《竹香斋象棋谱》等。杨慎、唐寅、郎英、罗颀、袁枚等文人学者都爱好下棋，大批著名棋手的涌现，显示了象棋受到社会各阶层民众喜爱的状况。新中国建立之后，象棋进入了一个崭新的发展阶段。1956年，象棋成为国家体育项目。以后，几乎每年都举行全国性的比赛。1962年成立了中华全国体育总会的下属组织——中国象棋协会，各地相应建立了下属协会机构。40多年来，由于群众性棋类活动和比赛的推动，象棋棋艺水平提高得很快，优秀棋手不断涌现，其中以杨官璘、胡荣华、柳大华、赵国荣、李来群、吕钦、许银川等最为著名。
      象棋是由两人轮流走子，以“将死”或“困毙”对方将（帅）为胜的一种棋类运动，有着数以亿计的爱好者。它不仅能丰富文化生活，陶冶情操，更有助于开发智力，启迪思维，锻炼辨证分析能力和培养顽强的意志。
　　唐代以前，象棋只有将、车、马、卒4个兵种。宋晁无咎的“广象棋”有棋子32个，与现代象棋棋子总数相同，但是不知道棋盘上有没有河界。宋、元期间的《事林广记》刊载了两局象棋的全盘着法。明、清时期，棋书出版较多，尤以明代徐芝的《适情雅趣》、明末清初朱晋桢的《桔中秘》、清代王再越的《梅花谱》和张乔栋的《竹香斋象戏谱》更为著名。1956年起象棋列为我国国家体育项目，近年来，在全国性比赛中，除男子个人赛，又先后增加了男子团体、女子个人、女子团体等比赛项目。成绩优异的棋手由国家体委授予“象棋大师”和“特级大师”等称号。
　

最近一直在北京出差，够冷的。
最高-3度，想想广州20几度的温度，真是冰火2重天，特别是早上出门，风一吹，真TMD的刺骨啊。赶紧找地方喝热豆浆啊。
 做还买了帽子和手套，这样装备就齐套啦。
 工作还是按计划进行着。

曾几何时，自己看着身边的朋友一个个都博客了，以为自己已经落伍了，但工作关系，以前实在是没有精力和机会能写些东西。（主要是自己太懒）。
    这次出差前，终于买了自己的本本，唉，虽然累点，要整天背着，不过终于可以在出差的时候上网。
   今天应该是有意义的一天。肯定是N个伟人的诞辰之日。
 因为今天我的博客也开张了。