- 转帖
- Java性能诊断和调优
- 系统运维
- 职业发展规划
- 项目管理
- 职业英语
- Oracle管理和开发
- 质量
- MySQL
- 性能报告
- 银行软件系统产品管理和研发
- Automation
- Oracle 性能诊断
- 应用服务器性能诊断调优
- 网络性能诊断
- 性能测试环境搭建
- 系统架构性能规划与演进
- Linux and Solaris 性能诊断与优化
- 日志分析
- Java开发
- 性能脚本开发
- End To End Performance
- Foundment of Perf Test
- Personal Folder
- JVM 调优
- HTTP服务器中间服务器
- 自动化脚本
- 技术前沿-分布式系统测试
- 云计算系统测试
- 日志分析工具
- 产品前沿
- Hadoop
- 安全
- 市场与销售
- Selenium自动化平台设计
- 第三方支付
- 服务器实时监控
- Java
-
PT 环境：查看应用系统和数据库系统信息globaltoken
2012-12-10 15:17:16
Step1:用Putty remote login 应用服务器App378Step2: Run command lineview /opt/globaltoken/common-cfg-tokenValue.propertiesStep3: Search DB 连接信息完成 -
Group by having
2012-12-07 11:03:33
select count(*), partner_id from CRM_CONTACT_LOG Group by partner_id having count(*)>100select count(*), partner_id from CRM_CONTACT_LOG Group by partner_id having count(*)>100
and
partner_id in ('B4JT3P3CC', '000035156') -
有效控制项目进度的几点技巧
2012-10-09 16:53:51
转自：http://www.programmer.com.cn/13625/
作者白天，北京合辉信息技术有限公司CEO软件开发的项目周期大体分为3个阶段：获取需求和定义产品、开发和测试、部署和运维。
在获取需求和定义产品阶段，需要防止 的不是进度太慢而是过快、过草率。特别是对于创业公司的产品经理来说，很可能因为看到开发人员无事可做而感到压力，所以尽快完成产品定义，而没有充分了解 市场和竞争对手信息，没有与合作伙伴充分沟通，没有做深入的思考。
这些因仓促而隐藏的问题，发现得早则导致开发阶段大量返工，发现得晚则导致产品上线后不 受欢迎。常听一些人说现在互联网开发，讲究快速迭代和敏捷，边做边想，返工也正常。这是一个误解。快速迭代指的是将不同版本之间的周期缩短，小步快跑，而 不是在一个版本的周期内来回折腾。
在开发和测试阶段，项目管理重在跟踪进度和保持沟通—用集成和演示跟踪进度，基于Bug沟通问题。
要做到各个模块外部接口相对清晰稳定，并尽早完成各个模块间的集成，最晚不超过开发周期的1/4时间。第一次集成之后，就应该开始每日集成和每周演示。每日 集成使得测试团队每天能同步测试最新的代码，帮助开发团队尽早发现问题并及时了解技术细节上的进度；每周演示使产品经理、项目经理和管理层能从用户的角度 感受产品，使他们对产品有信心。集成和演示是项目管理的心跳，合理利用它们，有助于及时把握项目的健康程度。
无论开发流程多敏捷，工程师能 力多强，记录和跟踪Bug都是必不可少的。开发团队和测试团队的沟通都应该基于Bug，才能言之有物。开发工程师每次提交代码都应该记录是针对哪个Bug 的，每日工作简报都应该写今天关/开了哪些Bug。要在每日晨会（站着开，一般15分钟内）时说好，今天打算解决哪些Bug，其中有哪些点不清楚，需要和 谁沟通。
在后期部署和维护阶段，要快速响应。考验的是团队成员的责任心和抗压能力。系统运维工程师要深夜工作，因为部署可能要在流量低的时 候进行；项目经理要保持能随时沟通，做出快速而准确的决定，鼓励团队并做出表率；一旦出现高危害Bug，开发团队要在24小时内准备好补丁。Amazon 的做法比较有趣：在产品刚上线一段时间内，开发工程师要保持24小时开机。如果自己负责的模块中出现高危害Bug，那么很可能会在深夜被系统运维工程师叫醒。这样不仅能保证快速响应，还能让工程师意识到：前期代码不好好写，后期就别指望能好好睡觉了。
-
分布式系统特点背景
2012-08-06 14:44:42
-
BI商务智能解决方案及讲解
2012-07-26 14:23:53
一个典型的BI系统介绍
商业智能系统应具有的主要功能：
读取数据——可读取多种格式（如Excel、Access、以Tab分割的txt和固定长的txt等）的文件，同时可读取关系型数据库 (对应ODBC)中的数据。
分析功能——关联/限定 关联分析主要用于发现不同事件之间的关联性，即一个事件发生的同时，另一个事件也经常发生。关联分析的重点在于快速发现那些有实用价值的关联发生的事件。
数据输出功能——打印统计列表和图表画面等，可将统计分析好的数据输出给其他的应用程序使用，或者以HTML格式保存。
定型处理——所需要的输出被显示出来时，进行定型登录，可以自动生成定型处理按钮。以后，只需按此按钮，即使很复杂的操作，也都可以将所要的列表、视图和图表显示出来。
以国外的一个BI系统为例，我们来介绍一个BI系统的主要功能，这个系统主要包含数据仓库管理器(Warehouse Manager)、数据复制(Data Propagator)、多维数据库(OLAP Server)、前台分析工具(Wired for OLAP)以及数据挖掘(Intelligent Miner)、On Demand。
数据仓库管理器(Warehouse Manager)
它主要由以下几部分功能组成：数据访问，数据转换，数据分布，数据存储，靠描述性数据查找和理解数据，显示、分析和发掘数据，数据转换过程的自动化及其管理。它缩短了复杂的海量数据与有洞察力的商务决策之间的差距，有助于公司更进一步了解其业务、市场、竞争对手和客户。
数据复制 (Data Propagator)
Data Propagator提供的复制功能允许从一个数据源读取数据并把它送到另外一个地方，而且可以是双向的。当发生冲突时，可自动检测出来并进行补偿。此外，它还有以下特色：
1)Pull Architecture Through Staging Tables(分级表牵引式体系结构)：二个组成部分---- Capture和Apply。Capture部分在源数据库服务器上运行，它捕获要被复制的数据，并把数据放入服务器分级表中；Apply部分在目标机上运行。在用户定义的时间间隔里或某个事件发生后，它连到源数据库中，并从分级表中抽取所需的数据。这种被动的“牵引式”体系结构减少了数据源的额外开销，能够支持数据源及目标机的独立运作性以及新一代流动计算机作为目标机的数据复制。这种体系结构还支持中介分级表，其中最初的源可以复制到区域目标中，然后再复制到各区域内的目标机上。
(2)支持更新和修正：既支持更新也支持修正复制。Apply可以完全替换目标数据或者仅仅修正上次复制以来所发生的改变。
(3)改变事务运行记录的Capture：捕获数据修改。它从数据库运行日志(LOG)中读出修改，从而抓取用于复制的数据修改，进而安排好这些数据。这就减少了对源的额外开销，不需要另外处理如触发器。甚至可以直接从内存中读运行记录，以减少I/O。
(4)加工数据：数据首先要从运行记录移到分级表，所以能在复制之前加工或处理它；由于分级表是数据库表，使用标准SQL就能定义加工处理功能。除了通过SQL来构造子集，汇总并连结表以外，分级表还能提供基于时间分析源数据改变的方法。这要考虑到整个新一类的应用包括检查跟踪，历史分析，"asof"查询等等。
( 5)GUI管理机构：通过图形用户界面可以定义和管理数据拷贝，定义代码和触发器没有专门语言。这样最终用户就有权定义和管理，而不仅仅是DBA和程序员的范围。
多维数据库服务器(OLAPServer)
该工具在商务智能中扮演着重要角色，可以深入最终用户的业务，对桌面上的数据进行实时操作，能够快速地分布传统监视和报告范围之外的应用程序数据。
数据挖掘工具(IntelligentMiner)
当用户的数据积累到一定数量时，这些数据的某些潜在联系、分类、推导结果和待发现价值隐藏在其中，该工具帮助客户发现这些有价值的数据。
Wired for OLAP
使用该功能可以提高信息技术组织的效率。信息技术人员可以让用户利用分析和报表的功能获得他们所需的信息，而不会失去对信息、数据完整性、系统性能和系统安全的控制。
(1)强大功能的报表
繁忙的信息技术部门可以在几分钟内创建用于在企业中分发的完善的报表。，决策人员可以从该Web页面上找到可用的一系列报表。
(2)图形化分析
远远超出对数据的静态图形化视图，提供强壮的图形化OLAP分析。决策人员可以根据需要排序、分组数据并改变“图表”(Chart)的类型（直方图、饼形图、线图、堆积图）。图表中的元素可以被“钻取”到其他的细节层次，并可以返回来恢复一个概要性的视图。
(3)多种图表视图：直方图、线图、组合图、饼形图、堆积图和离散点图
(4)可在任何地方“钻取”没有路径的预先定义
(5)完善的报表：复合报表通过用各种不同的形式（交叉表、图表、表格或以上几种形式的组合)来表现分析结果，对工作进行概括；优美格式的商用报表。
(6)交互式的、立即的“所见即所得”(WYSIWYG)显示
OnDemand
该工具提供给客户一套高性能的解决方案来进行在线捕获、存储和重取计算机输出的文档。它使得落后的纸张文件搜索和使用缩微胶片阅读器搜索称为历史。有了OnDemand，客户可以立刻发现特定的信息并且很容易地浏览它，而不用在庞大的数据和纸张中苦苦寻找；存储、重取和分发企业产生的信息比以前更加方便和易于接受。泰康人寿 以BI实现战略转型
泰康人寿保险公司从建立之初，就意识到信息化建设对企业发展的重要性。为促进业务的开展，泰康人寿已经建立有多个业务信息系统，主要包含:财务系统、个险系统、团险和银行险系统，呼叫中心以及用于开展电子商务的泰康在线交易系统。这些系统从企业不同需求层面很好的支持了泰康人寿的业务运营。但由于各个系统都有自己的数据,如何将分散在不同系统的客户数据集中起来有效使用，为各部门提供数据分析能力，为决策提供依据,成为目前需要解决的问题。 为此，泰康人寿希望建立一套以CRM为核心的商务智能系统(BI)，使公司管理人员能够对与客户(现有客户以及潜在客户)有关的各种要素(需要、方式、机遇、风险、代价等)和企业运营当中各项关键指标(KPI)做出分析与评估，以便于为本企业赢得最大的回报。
泰康人寿商务智能项目最终选择了Sybase寿险行业IWS解决方案，并以此为基础整合原有的五大业务系统，实施九项业务分析主题。
在实施方法上，泰康保险采用了增量式开发，也就是整体设计、分布实施的策略，这可以使泰康人寿能够边实施边见效，并且使用过程中的反馈信息将有助于下一步的开发工作，因此极大地提高了开发的效率。BI项目分成两个主要阶段：第一阶段，完成BI项目的一个或二个分析主题。第二阶段，以第一阶段建立的分析环境为原型，进行更进一步的需求调研，完善和明确BI项目的业务需求，全面地进行IWS的客户化工作。
商务职能系统能够使泰康人寿在成本、收入和战略方面获益。
成本方面：借助商务智能系统，泰康人寿可以得到完整的视图，来分析成本构成，改变成本管理现状，降低业务运作成本。通过CRM 系统提供的各项分析数据，泰康人寿能在商业活动中，以更低的风险，做出最明智的决策。
收入方面：通过对营销员和营销机构产能的分析、利润的分析，可以大大改进泰康人寿在营销过程中的效率，加速产品上市时间，获得更精确更全面的市场和客户信息,实现与合作伙伴之间更好的合作，提高团队效率，保证将重要客户信息提供给需要方而提升交叉销售业绩。
战略方面：借助商务智能平台，泰康能对不断变化的市场环境、客户需求做出更快的反应。从历史数据中选择不同的角度考察消费行为,评估客户价值，细分客户群；针对不同的客户群发掘消费特点，建立数据模型，对不同的客户群做出预测；估计对收益或利润的影响，对市场活动的效果进行预测，通过设置商业规则，进行复杂的市场划分；最终帮助泰康实现从以产品为中心的战略，转换到以客户为中心的战略。Session1：医院智能分析业务与需求
Session2：解决方案技术框架与Demo效果；
Session3：关键技术和实现；ETL-如何确定起始来源数据
How is the system-of-record determined?
如何确定起始来源数据？
答：
这个问题的关键是理解什么是System-of-Record。System-of-Record和数据仓库领域内的其他很多概念一样，不同的人对它有不同的定义。在Kimball的体系中，System-of-Record是指最初产生数据的地方，即数据的起始来源。在较大的企业内，数据会被冗余的保存在不同的地方，在数据的迁移过程中，会出现修改、清洗等操作，导致与数据的起始来源产生不同。
起始来源数据对数据仓库的建立有着非常重要的作用，尤其是对产生一致性维度来说。我们从起始来源数据的越下游开始建立数据仓库，我们遇到垃圾数据的风险就会越大。ETL架构师面试题（中文）
ETL架构师面试题（中文）
本部分的题目来自Kimball的ETL Toolkit著作，原著未直接给出答案。这里的中文题目和答案是我参考其原著按自己的理解整理而来的，仅供参考。对于其中不确切的地方，欢迎大家一起沟通。有兴趣的朋友可以直接阅读原著。
-----答案持续更新中，点击题目可见答案。
分析
1．什么是逻辑数据映射？它对ETL项目组的作用是什么？
2．在数据仓库项目中，数据探索阶段的主要目的是什么？
3．如何确定起始来源数据？
架构
4．在ETL过程中四个基本的过程分别是什么？
5．在数据准备区中允许使用的数据结构有哪些？各有什么优缺点？
6．简述ETL过程中哪个步骤应该出于安全的考虑将数据写到磁盘上？
抽取
7．简述异构数据源中的数据抽取技术。
8．从ERP源系统中抽取数据最好的方法是什么？
9．简述直接连接数据库和使用ODBC连接数据库进行通讯的优缺点。
10．简述出三种变化数据捕获技术及其优缺点。
数据质量
11．数据质量检查的四大类是什么？为每类提供一种实现技术。
12．简述应该在ETL的哪个步骤来实现概况分析？
13．ETL项目中的数据质量部分核心的交付物有那些？
14．如何来量化数据仓库中的数据质量？
建立映射
15．什么是代理键？简述代理键替换管道如何工作。
16．为什么在ETL的过程中需要对日期进行特殊处理？
17．简述对一致性维度的三种基本的交付步骤。
18．简述三种基本事实表，并说明ETL的过程中如何处理它们。
19．简述桥接表是如何将维度表和事实表进行关联的？
20．迟到的数据对事实表和维度表有什么影响？怎样来处理这个问题？
元数据
21．举例说明各种ETL过程中的元数据&索林根的软件度量指南
2012-01-04 14:02:53
索林根的软件度量指南
索林根的软件度量指南：十大方针
软件度量专家索林根(Van Solingen)在《聚焦产品的软件过程改善》(Product Focused Software Process Improvement)中详细阐述了软件度量项目工程(Measurement program engineering)，提出软件度量的十大方针，如下所示。
1. 准备让软件开发者参与软件度量项目；
2. 开始软件度量工程前了解软件产品的质量目标、过程模型和学习目的；
3. 软件度量项目工程为目标导向，确保具备有限但相关的度量设定；
4. 指定期望值(假设)；
5. 由具有实际度量经验的人员按照规则对度量数据作出分析和解释；
6．将度量数据的分析和解释聚焦于：详细而精确的过程行为、全局过程、或者产品质量目标，但是决非聚焦于个人绩效；
7. 执行专门资源(人员)来支持度量项目工程的开发团队；
8. 评价实际产品质量和目标产品质量的差距；
9. 评价过程行为的影响(产品质量方面)；
10. 将特定情景中过程行为的知识存储到经验数据库中。
高尔发的关键成功因素：九大要素
品质与生产力管理集团(Q/P Management Group)总裁斯科特·高尔发(Scott Goldfarb)在《建立有效的度量体系》(Establishing a Measurement Program)中认为，建立并实施有效软件度量体系的关键成功因素包括如下：
1. 确定度量目标和计划；
2. 获得高层管理者的支持；
3. 拥有专属资源；
4. 面向员工的培训、教育和营销推广；
5. 日常工作中的度量一体化；
6. 聚焦于项目团队的结果；
7. 度量不要针对个人；
8. 有效定义数据以及实情报告制度；
9. 推动度量自动化。
软件工程研究所的软件度量规则：二十八条规则
美国卡内基·梅隆大学软件工程研究所在《软件度量指南》中列出了如下软件度量的规则：
1. 理解软件度量方法只是达到目的的手段，而其本身并不是目的；
2. 以应用度量结果而不是收集数据为中心；
3. 理解度量的目标；
4. 理解如何应用度量方法；
5. 设定期望值；
6. 制定计划以实现早期成功；
7. 以局部为重点；
8. 从小处着手；
9. 将开发人员与分析人员分开；
10. 确信度量方法适合要实现的目标；
11. 将度量次数保持在最低水平；
12. 避免浮夸度量数据；
13. 编制度量工作成本；
14. 制定计划使数据收集速度至少是数据分析和应用的3倍；
15. 至少每月收集一次关于工作投入水平的数据；
16. 明晰关于工作投入水平数据收集的范围；
17. 仅收集受控软件的错误数据；
18. 不要指望准确地度量纠错工作；
19. 不要指望找到界定完善的放之四海而皆准的过程度量方法；
20. 不要指望找到过程度量的数据库；
21. 理解高级过程的特征；
22. 应用关于生命周期阶段的简单定义；
23. 用代码行表示规模；
24. 明确将哪些软件纳入度量范围；
25. 不要指望使数据收集工作自动化；
26. 使提供数据的工作更容易；
27. 使用商业上可用的工具；
28. 认为度量数据存在瑕疵、不精确也不稳定。
帕克的目标驱动软件度量原则：四大原则体系
帕克(Robert E. Park)、哥特(Wolfhart B. Goethert)和弗罗哈克(William A. Florac)在1996年的《目标驱动软件度量指导手册》(Goal-Driven Software Measurement—— A Guidebook)中提出软件度量的原则如表5-10所示：
表5-10 帕克的目标驱动软件度量原则
1. 部门管理者的度量原则—— 设立清晰的目标；
—— 让员工协助定义度量手段；
—— 提供积极的管理监督：寻求和使用数据；
—— 理解员工报告的数据；
—— 不要使用度量数据来奖赏或者惩罚实施度量的员工，并确信他们知道你和其他任何人都遵守这一规则；
—— 建立保护匿名的惯例，对匿名提供保护将建立起信任并培育起可靠数据的收集机制；
—— 如果员工的报告基于对组织有用的数据，支持他们；
—— 不要强调那些排斥其他度量方式的某种度量方式或者指标。2. 项目管理者的度量原则
—— 知晓组织的战略性焦点并强调支持该战略的度量手段；
—— 在追踪的度量手段上与项目组获得一致，并在项目计划中定义这些度量手段；
—— 向项目组提供规则有序的关于其所收集数据的反馈；
—— 不要私人单独地进行度量。
3. 项目组的度量原则—— 尽最大努力报告准确而及时的数据；
—— 协助在管理中将项目数据聚焦于改善软件过程；
—— 不要使用软件度量夸耀自身的优秀，否则这将鼓励其他人使用其他数据展示其反面。4. 通用原则
—— 软件度量本身不要成为一个战略；
—— 在软件过程改善的全局战略中整合软件度量，为此应该拥有或者开发一种这样的战略来联合软件度量计划；
—— 带着共同目标与课题从点滴做起；
—— 设计一种持续的软件度量过程，以使其：
? 与组织目标与宗旨相联系
? 包括严格的定义
? 持续实施；
—— 在广泛实施所设计的度量手段和过程之前进行测试；
—— 对软件度量手段和度量活动的效果进行度量和监控。
弗罗哈克的实用软件度量原则：十大原则
弗罗哈克(William A.Florac)、帕克(Robert E.Park)和卡尔顿(Anita D.Carleton)在《实用软件度量：过程管理和改善度量》(Practical Software Measurement：Measuring for Process Management and Improvement)中提出成功的过程度量原则如下。
1. 过程度量受商业目标驱动；
2. 过程度量手段源自软件过程；
3. 有效度量需要明确阐述的可操作性的定义；
4. 不同的人拥有不同的度量观点和需求；
5. 度量结果必须在产生结果的过程和环境中检验；
6. 过程度量应当跨越整个生命周期；
7. 保持的数据应当提供分析未来的实际基线；
8. 度量是进行客观沟通交流的基础；
9. 在项目内部和项目之间对数据进行总计和比较需要细心和规划；
10. 结构性的度量过程将强化数据的可靠性。软件度量的要点：来自实战的教训
软件度量这一作业本身比较难以在实际的软件开发中顺利操作，也难以在软件开发改善中产生立竿见影的效果，甚至会让人觉得这是枯燥无味的无用功。这往往会形成妨碍实施软件度量的阻力，挫伤软件度量人员的积极性和热情。那么，如何有效地推动软件度量，就成为软件度量作业的重点课题。下面是软件度量作业的要点，可以作为推动软件度量作业的参考。
1. 从点滴开始。与其采用声势浩大的软件度量运动，还不如从点滴开始：让员工逐渐进入度量状态，避免因为大规模运动带来的不适和阻力。从点滴开始，从小规模的简单的度量项目开始，从能够吸引员工并能让其接纳的度量项目开始，保证软件度量能在避免受挫的情况下得以逐渐推进，同时尽可能提高软件度量的自动化程度。
2. 解释为什么。这是消除抵制情绪和消解阻力的重要环节，因为人们不会切实地践行那些他们没有真正理解和接纳的理念和措施。需让员工明白，使用度量将比没有任何度量要好；度量将在一定程度上增进对软件开发的理解、预测、评估、控制和改善；软件度量仅仅针对软件产品、项目和过程，而不针对个人；等等。
3. 根据项目实情加以具体实施。不同的项目拥有不同的产品、流程、环境、目标和顾客，顾客、软件开发人员、项目组甚至经营者对项目的需求也不同，必须聚焦于解决该项目在产品、流程等方面的问题，而不是直接套用以前曾经实施或者已经模式化的度量标准。
4. 共享数据。度量数据的共享这一行为本身具有四大好处：一则可以让员工感受到度量的切实性，即行动正在按照计划进展；二则可以为员工提供度量的反馈信息，以改进现状；三则可以通过比较，寻找最佳实践，实施标杆学习；四则可以通过数据共享增进信任，消除软件度量可能带来的误解。
5. 保持简单易懂。简单易懂这一点对于降低度量过程中的理解成本、沟通成本和实施成本都不可或缺。因为软件开发人员没有必要成为软件度量理论、统计方法以及度量技术的专家，他们仅仅需要知道软件度量与解决问题之间的关系，知道如何简单高效地实施度量。
6. 塑造度量文化。在软件开发中有意识地塑造一种重视记录、亲近数据、偏好图表、基于度量进行作业的习惯或者说文化，将判断、分析和决策立基于可预测性、可控制性、可改善性之上。
软件度量的陷阱：直面铜板的反面
就像铜板的正反两面，软件度量也具有正反两个方面的影响：正面效用在于通过度量获得定量化的可控过程，负面影响在于其过度滥用带来的危害，比如：
1. 软件开发的量化指标替代了开发目标。软件开发管理中定量化极为重要，这当然是指有目的的、毫无浪费的、明确的定量化。如果视软件度量为目的，那么软件度量就会陷入可悲的误区：纯粹的量化指标替代了目标，数据淹没了宗旨，任务迷糊了方向，软件度量成为软件开发过程的目标而不是手段，成为应付考核和评价的功利性工具。指标仅仅是个反光镜，而不是行进的指向标。如果不能理解软件度量在商务上的目标，那么就会出现这样的情况：收集了错误的数据，以及数据没有被正确使用。要想接近目标，双眼必须注视前方。
2. 软件开发的度量方法取代了度量理念。软件度量不仅仅包含着丰富多样的度量方法，更包含着博大精深的度量理念；不仅仅需要理解软件度量的方式方法，更要践行软件度量的理念。如果仅仅拘泥于软件度量的方式方法而忽略更为本质、更为精髓、更为深刻的理念，那么软件度量对于软件开发的意义就不再重要，因为这种情况下的软件度量虽然获得了看似完美的躯壳，却丢失了灵魂。
3. 软件开发的度量结果成为奖惩的根本依据。软件度量的结果如果成为考核和奖惩的根本依据，那么就偏离了软件度量的用途：软件度量只针对项目、产品和过程，用于对软件项目、产品和过程进行理解、分析、预测、评估和改善；软件度量从不针对个人，既不用于评估个人的能力，也不用于评估个人的绩效，更不用于作为个人奖惩的根据，这样才能保持数据的可靠性、客观性和准确性。如果软件度量针对个人，这将从根本上影响个人的态度和行为，并危害团队的绩效。永远不要让软件度量成为软件开发人员心理上的负担。
过程影响公司的首席咨询顾问卡尔·威格在其《软件度量的十大陷阱》一文中总结了软件度量应该避免的十大陷阱：
1. 缺乏管理承诺；
2. 度量得太多太早；
3. 度量得太少太晚；
4. 度量了错误的事项；
5. 度量定义不严密；
6. 度量用于评估个人；
7. 度量用于激励而非理解；
8. 仅仅收集但不使用数据；
9. 缺乏沟通和培训；
10. 曲解度量数据。
软件度量并非神话，从其诞生之日起就没有预言过任何神话。软件度量仅仅是增进软件理解、预测、评价、控制和改善的富有助益的路径。如果仅仅寄希望于以统计为基础的软件度量来获取软件开发的所谓“银弹”，就需要重温那句富有讽刺意味的名言：谎言有三种，即谎言、该死的谎言、统计数据。introduction for LR
2009-10-25 20:23:06
Are your IT systems expected to support thousands of users across multiple application environments with a complicated mix of homegrown and third-party components?
Does your organization have to deliver 99.9 percent uptime and availability in the face of both unpredictable user loads and a never-ending stream of product patches and upgrades?
Does your IT organization adequately stress test applications for system, user, and network scalability before deployment to ensure no performance surprises?
Mercury LoadRunner™ is the industry-standard performance and load testing product for predicting system behavior. and performance. Using limited hardware resources, LoadRunner emulates hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads. Your IT group can stress an application from end-to-end and measure the response times of key business processes. Simultaneously, LoadRunner collects system and component-level performance information through a comprehensive array of system monitors and diagnostics modules. These metrics are combined into a sophisticated analysis module that allows teams to drill down to isolate bottlenecks within the architecture.
LoadRunner supports a wide range of enterprise environments, including Web Services, J2EE, and .NET. It is the only performance scalability testing product customized and certified to work with ERP/CRM applications from PeopleSoft, Oracle, SAP, and Siebel.
With LoadRunner, you can:
-
Obtain an accurate picture of end-to-end system performance.
-
Verify that new or upgraded applications meet specified performance requirements.
-
Identify and eliminate performance bottlenecks during the development lifecycle.
华为软件外包测试流程
2009-07-24 12:20:59
不知不觉做华为外包项目已一年多了，曾在华为常驻过，也曾负责过项目的测试，感觉对华为外包项目的测试流程较熟悉，故写些心得来与大家分享。
如果竞标成功，项目就开始要启动了。华为方会提供一份CRS(客户需求)和SOW（工作任务书），华为方派人过来进行需求培训，这时该项目的测试组长也要参与到项目需求的培训和评审，也就是测试工作应该从需求开始介入。
项目经理编写《项目计划》，开发人员产出《SRS》，这时测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
《测试计划》编写完成后需要进行评审，参与人员有项目经理，测试经理和华为方人员，测试组长需要根据评审意见修改《测试计划》，并上传到VSS上，由配置管理员管理。
待开发人员把《SRS》归纳好并打了基线，测试组长开始组织测试成员编写《测试方案》，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审，评审人员包括项目经理，开发人员，测试经理，测试组长，测试成员和华为方；如果华为方不在公司，就需要测试组长把《测试方案》发送给华为进行评审，并返回评审结果。测试组长组织测试成员修改测试方案，直到华为方评审通过后才进入下个阶段――编写测试用例。
测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要通过开发人员，测试人员和华为方的评审，测试组长也需要组织测试人员对测试用例进行修改，直到华为方评审通过。
在我们编写测试用例的阶段，开发人员基本完成代码的编写，同时完成单元测试。华为的外包项目一般是一次性集成，所以软件转测试部后直接进行系统测试。测试部对刚转过来的测试版本进行预测试，如果软件未实现CheckList清单上的10％，测试部会把该版本打回。否则，软件转测试部进行系统测试。根据《测试计划》进度安排，测试组长进行多轮次的测试，每轮测试完成后测试组长需要编写测试报告，其中包括用例执行通过情况，缺陷分布情况，缺陷产生原因，测试中的风险等等，这时测试人员就修改增加测试用例。待到开发修改完bug并转来新的测试版本，测试部开始进行第二轮的系统测试，首先回归完问题单，再继续进行测试，编写第二轮的测试报告，如此循环下去，直到系统测试结束。在系统测试期间，测试人员还需要编写验收手册，验收用例和资料测试用例等。
完成系统测试后，软件就开始转到华为进行验收测试，其中大概测试半个月，一般会要求测试部派人到华为方进行协助测试，并发回问题单给公司开发人员修改。
如果验收发现的缺陷率在SOW规定的范围内，那么验收成功，华为方付钱给公司，项目结束。如果超过规定的缺陷率，那么公司可能要罚钱了，整个项目组的成员（包括开发和测试）都可能要罚了。这种情况也会有，如果按照流程做事，概率不会很大。
测试流程的规范是很重要的，但是如果要成为优秀的测试人员只知道流程还是不够的，需要学习的东西还很多，包括熟悉相关测试业务，计算机专业知识（linux，oracle，tcp/ip等），开发的架构和语言，性能测试和系统瓶颈分析、调优等。还有性格（细心，耐心）和人际沟通能力也是很重要的决定条件。任重而道远，我刚起步，希望大家一起在测试的路上互励互勉。
在路由上发布公司端口服务
2009-07-23 19:05:21
亲自配置了Juniper NetScreen-5GT 防火墙 + 路由， 和 syslink RV082 + VPN
NetScreen系列产品，是应用非常广泛的NAT设备。NetScreen－100就是其中的一种。
NetScreen-100是个长方形的黑匣子，其正面面板上有四个接口。左边一个是DB25串口，右边三个是以太网网口，从左向右依次为Trust Interface、DMZ Interface、Untrust Interface。其中Trust Interface相当于HUB口，下行连接内部网络设备。Untrust Interface相当于主机口，上行连接上公网的路由器等外部网关设备；两端口速率自适应（10M/100M）。DMZ Interface介绍从略。配置前的准备
1. PC机通过直通网线与Trust Interface相连，用IE登录设备主页。设备缺省IP为192.168.1.1/255.255.255.0，用户名和密码都为netscreen ；
2. 登录成功后修改System 的IP和掩码，建议修改成与内部网段同网段，也可直接使用分配给Trust Interface的地 址。 修改完毕点击ok，设备会重启；
3. 把PC的地址改为与设备新的地址同网段，重新登录，即可进行配置
4. 也可通过串口登录，在超级终端上通过命令行修改System IP数据配置
数据配置包括三部分内容：Policy、Interface、Route Table。
1. 配置Policy
用IE登陆NetScreen，在配置界面上，依次点击左边竖列中的Network–〉Policy，然 后选中Outgoing。如系统原有的与此不同，可点击表中最后一列的Remove来删除掉，然后点击左下角的New Policy， 重新设置。
2. 配置Interface
在配置界面上，依次点击左边竖列中的Configure–〉Interface选项，则显示如下所示的配置界面，其中主要是配置Trust Interface、Untrust Interface，必要时修改System IP。在 Interface配置图当中;
说明：
1. Trust Interface下面的Inside IP，即指端口本身的IP。因为该端口是设备用以与局域网内部相连的，所以就相当于是设备对内的端口，故此把该端口的IP 就叫做设备的Inside IP。同理，Untrust Interface下面的Outside IP也是指该端口的IP ，因为该端口是面向局域网外部的；Trust Interface下面的Default Gateway，指局域网内部与Trust Interace相连的设备的接口的地址。在本例中即是上行口的地址。Untrust Interface下面的Default Gateway是指外出上公网的网关地址（即NAT的下一跳），本例中指与NAT相连的路由器的接口地址
2. 在接口的配置选项中，Traffic Bandwidth选项是对该端口传输带宽的描述，不用设置。因为两端口都是自适应的，会根据所连对端端口的带宽而自动调整。
3. 在Enable的选项中，Trust Interface端口按照缺省的选择即可。而Untrust Interface因为面对公网，为安全起见，应当把ping、telnet等性能屏蔽掉， 不要选择。只有当有必要进行远程维护时，才把telnet选中。
4. 对于System IP，当第一次登录后把它修改为与Trust Interface或Untrust Interface的IP 在同一网段，则用户就只能从Trust Interface或Untrust Interface登录。为了实现从两个端口都可登陆，以便管理，需要在上述界面上把System IP 的值改为0.0.0.0
5. Untrust Interface和Trust Interface配置内容完全一样，上面的例图由于是用PrtSc屏拷下来的，不能把Untrust Interface的配置内容拷全，特此说明。
3. 配置Route Table
在配置界面上，依次点击左边竖列中的Configure –〉Route Table选项，则显示图5所示界面。系统要正常运行，在NAT内部有两条路由是必不可少的，一条是去内部网段下面的用户网段的 路由，其网关是与NAT相连的接口的地址。该路由为：10.10.0.0 255.255.0.0 10.100.0.1 Trust ；另一条是去外部公网的缺省路由，其网关是与NAT 相连的外部路由器的接口地址。该路由为： 0.0.0.0 0.0.0.0 202.99.6.193 Untrust。
从路由表中可以看出，后一条路由是系统缺省自动生成的，所以只需手工添加的第一条路由。点击界面左下角的New Entry创建新的路由。对于已生成的路由，可以通过点击Edit、Remove进行修改或删除。
至此，所有配置全部完成。netscreen 配置文档
1、进入字符配置界面：
用随机带的CONSOLE线，一头接计算机串口，一头接E1端口，在计算机上打开超级终端进行配置，用户名，密码都是netscreen。2、进入WEB配置界面：
用交叉网线连接E1和计算机的网卡，将计算机IP改成192.168.1.2（与E1端口在同一网段）。打开IE浏览器输入http:/192.168.1.11（192.168.1.11为E1端口管理IP），用户名，密码都是netscreen。3、配置端口IP和管理IP：
E1：内部网端口
端口IP192.168.1.20和管理IP192.168.1.11
更改为当地内部网的IP地址,E1的端口IP设为当地内部网网关，管理IP用于在内部网管理netscreen防火墙。E3: 外网端口
端口IP192.168.42.66和管理IP192.168.42.68
更改为当地电信所分配的IP地址，E3的管理IP用于外网管理者在INTERNET上配置和管理netscreen防火墙。
4、配置由内网到外网的NAT：
在E3端口上配置NAT，用于将内部网地址转换成当地电信所分配的公网IP地址，以便访问INTERNET信息。1. Network > Interfaces > Edit（对于ethernet1）：输入以下内容，然后单击OK：
Zone Name: Trust
IP Address/Netmask: 172.16.40.11/24（当地内部网网关IP）2. Network > Interfaces > Edit（对于ethernet3）：输入以下内容，然后单击OK：
Zone Name: Untrust
IP Address/Netmask: 215.3.4.11/24(当地电信所分配的IP地址)。3. Network > Interfaces > Edit（对于ethernet3）> DIP > New：输入以下内容，然后单击OK：
ID: 6
IP Address Range
Start: 215.3.4.12（当地电信所分配的IP地址）
End: 215.3.4.210（当地电信所分配的IP地址，这是一个地址池，可大可小）
Port Translation: Enable4. Policies > (From: Untrust, To: Trust) > New：输入以下内容，
然后单击OK：
Source Address:
Address Book: （选择） , Any
Destination Address:
Address Book: （选择） , Any
Service: Any
Action: Permit
> Advanced: 输入以下内容，然后单击Return，设置高级选项并返回基本配置页：
NAT: On
DIP On:（选择） , 6 (215.3.4.12–215.3.4.210)：上一步设的地址池。5、配置由外网到内网的VIP：
在E3端口上配置VIP，可将一个外网IP和端口号对应到一个内网IP。通过这种方法可以将WEB服务器，邮件服务器或其他服务放到内网，而从外网只看到一个公网IP，增加安全性。1. Network > Interfaces > Edit（对于ethernet1）：输入以下内容，然后单击Apply：
Zone Name: Trust
IP Address/Netmask: 10.1.1.1/24（当地内部网网关IP）2. Network > Interfaces > Edit（对于ethernet3）：输入以下内容，然后单击OK：
Zone Name: Untrust
IP Address/Netmask: 210.1.1.1/24（当地电信所分配的IP地址）VIP
3. Network > Interfaces > Edit（对于ethernet3）> VIP：输入以下地址，然后单击Add：
Virtual IP Address: 210.1.1.10（对外的服务器地址）4. Network > Interfaces > Edit（对于ethernet3）> VIP > New VIP Service：输入以下内容，然后单击OK：
Virtual Port: 80
Map to Service: HTTP (80)：（此例为WEB服务器的配置，如果是其他的服务器，就加入其服务与对应的端口号）
Map to IP: 10.1.1.10（此为服务器本身IP，内网IP）策略
5. Policies > (From: Untrust, To: Global) > New：输入以下内容，然后单击OK：
Source Address:
Address Book:（选择）, ANY
Destination Address:
Address Book:（选择）, VIP(210.1.1.10)：对外服务器地址
Service: HTTP（WEB服务器选项）
Action: PermitSquid服务器的建立
2009-07-23 19:00:53
为了熟悉整个业务流程，公司让我开始了岗位轮换。
将负责一段时间的服务器搭建和网络环境建立：
一： vi /etc/squid/squid.conf，查找visible_hostname位置，并在下面添加一行：
visible_hostname test
查找auth_param位置，并在下面添加：
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd查找acl ncs_user位置，并在下面添加：
acl ncsa_users proxy_auth REQUIRED查找http_access位置，并在下面添加：
http_access allow ncsa_userstouch /etc/squid/squid_passwdchmod o+r /etc/squid/squid_passwd然后建立一个新用户
htpasswd /etc/squid/squid_passwd test公司运营数据备份和恢复管理
2009-07-23 18:54:36
公司运管数据备份和恢复管理：
最近在与技术总监的几次沟通后，项目之余负责整个公司运管数据备份策略设计，研究和实验。
设计的方案已经正常运行近20天了。
优点：
风险分散，安全度高，便于集中管理，如，备份目录的拆分，添加。
验证机制更可靠。
目前足以应对10T数据。
流程再造
2009-07-23 10:44:30
- 在这里可以跟大家说一下，我就曾经在产品发布权限不在测试这里部门的情况下，成功的让研发决定推迟发布了大约一半以上的项目,。大多数的测试部门主管，很难顶住来自项目/技术经理的压力是有理由的，因为他们根本不了解你做了哪些工作。有时候一些情况下，看似不可能的事情任务要想做成完成，关键要看在于事情的技巧，。流程表示了只是一个大方向的东西，而且，你永远也无法将责任推卸给流程也许是对的，更多情况下，作为测试主管，需要但将做事的方法与风格可以影响到推广到测试流程的推广中。
- 在测试互联网项目时，还有一个更重要的就是如何保证性能。
- 也许大家会说不就是性能测试并不是单独存在的。其实不是完全正确，如果有充足的优秀高手人力资源做性能测试当然很好，但性能测试也不能完全保证所有的项目完全没有性能问题都完美无缺，因此，项目投入期间，同时性能测试是一个这个费时费力的工作，所以往往都是一般在资源不足的情况下开展的。作为测试主管，更应该，要学会判断那些相对更加重要的问题项目影响面会更广，需要集中做性能测试。这时你也许会问，那么会有人问其它相对不太重要的项目与问题怎么办，？其实做过性能调优的人都知道，大部分的性能问题都是由于一两个弱智的SQL语句导致的，所以可以从流程上加强对SQL查询语句在I/O问题的跟踪与评审,，从而避免大部分性能问题。
- 上面分析了不同公司根据上文的分析，不同类型的产品在测试流程上的是有很大差异的。这时，也许大家你也许可以把握测试流程大的方向了，但真正是否适合现有的测试团队与研发团队，则仍需要精心的调整，。当我遇到问题的时候，第一时间往往有时候不是去寻找流程不对的问题，而是通过现有资源与执行的方法可能需要着手来微调一下你的测试流程，直到发现问题的所在，并纪录下来，最后整合到原来设定的流程中。
- 这样的情况大概常常发生：比如说在需求上的处理，可能会有很多的测试人员会经常指责需求人员撰写的文档非常粗糙不详细，无法进行测试，。好像在我的记忆中，需求人员常常就是被骂的得灰头土脸，但是经过这些年在测试岗位上的工作，我才渐渐发现，其实有时候需求人员更需要鼓励, 鼓励是比职责更加有效的工作方式。这可能是一个放之四海皆准的工作态度。，指责只能加深对立，。其实在验收需求时，由于当时大家也只是知道一个大概我们的需求人员也只能从大致上把握核了解，可能大多数情况下是：原则上没有问题就通过了，。但然而，这种不负责任的态度却是给我们在做的测试工作带来相当多的麻烦。也只有在这样的时候，这些问题才能真正暴露出来，从而使测试设计时就会发现很多问题并没有写清楚，。一般情况下，很多测试人员这时就多半会放弃手边的工作，并消极地认为认为无法做工作无法继续下去。，等东西出来，并将问题最终归结到是需求给的不详细，而大加指责。
- 从我对测试主管工作的记事以来，就在印象中保留了这样的一幕。记的刚进一家公司时，我团队中的人员就开始经常会有下属跟我说抱怨，公司的需求工程师让我们太失望了。需求如何如何不好，然而，多少有些经验的我，当时我是把几家国内我服务过的顶尖公司情况作了一个简单的对比，的需求跟公司的需求人员的需求做了比较这时才发现，发现，原来我们公司的需求人员还是做的得不错的，。让测试人员把心态调整过来是测试主管的另外一件事。试问，，如果是你做需求作为需求工程师，是否会比他们做的好吗得更好?？有了这样的基调，就可以让然后建议测试人员去总结不清楚的地方，给需求人员一个相对比较具体和明确的意见，这样顺利的了解了需求。
- 其实有时候不是流程不对流程在这其中并没有太多值得指责的地方，而是相互的理解与支持,换位思考而对流程的执行态度，却是更加关键的。我们不得不学会如何换位思考，并更多地从他人的角度来看待这些问题。
- 同样的问题还出现在还有需求变更上，很多测试人过不了这一关，。总是他们指责研发人员，让研发那些本来就已经恼火的软件工程师更加火冒三丈。换位思考一番，其实不难了解，，其实需求变更对研发工程师来说是更大的麻烦，。他们需要修改设计，、代码，相较而测试只要需改测试用例，他们的工作确实更加麻烦。简单来说，就ok了，其实大家要分析什么样的需求变更最可怕，而不是眉毛胡子一把抓,其实测试对需求变更并不可怕，怕的是只有在提交时才发现，导致测试时间不够，才会真正让测试人员心慌。这时需要从研发流程上保证变更及时的通知到测试就可以了行，。也许有人会说你也需要说：，说的倒很容易，如果研发不按照你的要求做怎么办！其实这里你只要用我所采用的方法是用数据说话，在项目进行时统计发生过多少次这样的事情，让研发管理层知道，让项目组之间有一个比较，。一方面，如果是一家公司重视质量的公司，必然会引起重视；另一方面，从质量管理部门角度本身出发，也应该推动公司重视质量。，随着时间的增加，需求变更给测试人员的反馈一定会有下降的趋势，。关键是测试不能抓住鸡毛就一直揪着不放宽容一些来看待身边的同事，要允许别人他们犯错，对于解决问题本身来说会大有裨益。只要趋势是好的就可以了。同时如果出现这样的情况并且极大影响到了测试进度，则要与研发部门沟通清楚,，如果研发不认可的情况下还可以请上级进行评估一下。
- 上面说的是不同态度在同样流程下的实现不同结果,下面主要讲一下关于自身资源是否胜任做流程上规定的事情，某些工作，也许并不一定是测试部门的优势，而另外一些，则需要根据测试团队的基本能力和资源进行评估。比如像性能测试、SQL的trace、自动化功能测试、单元测试集成、游戏性测试。其实这些流程上的关键点，可能大多数从功能测试上来一路走来的测试人员是无法做的到，这时要善于利用资源，不一定要测试做，可以从通过流程上保正有人来做积极调动其它部门的同事。，或是找有能力的人来做，测试可以进行监控。其实这种技术含量高一点的测试，对人的因素要求更大高，可以借助研发团队一起来做会有更好的效果，。记的第一次做Oracle数据库性能监控时，就是请的Oracle的DBA专家帮助设计了性能参数，成功的地进行了关于Oracle应用的性能测试。现在国内的测试人员普遍的技术水平不高，严重的限制了测试的发展，希望测试的同行能真正的提升测试技术水平，把这些高难度的测试做起来，而不是仅仅只是工具上玩玩，。只有真正提升测试团队的技术含量，这样别人才会更信赖你，这也是我这么多年来的一点经验。如果你对开发很精通，、同时又精通对测试颇有研究，、善于诊断性能与架构上的问题，、经常会帮助研发部门解决一些他们无法解决的事情，、同时又还懂的如何做测试管理，并了解研发人员的心态，那就真得的找不出你还有不成功的理由了任何理由让人不对你刮目相看了。
白盒测试持续改进关键在执行力强一些的经理或QA（转）
2009-04-30 16:06:06
单元测试与集成测试三种发展阶段。
初始阶段一：
刚实施或从未实施白盒测试的发展阶段，一个企业内只有零星的单元测试或集成测试实践，缺少成功案例。重要特点，公司成员普遍对白盒测试缺少概念，大致知道代码审查、单元测试、集成测试该怎么去做，但一涉及具体场景，对某模块实施单元测试或跨模块、跨子系统实施集成测试时，通常茫无头绪，不知从何下手。
发展阶段二：
白盒测试过程也逐渐融入研发流程，典型的例子：将白盒测试发现的问题纳入统计，研发过程中会以缺陷密度（每千行代码发现多少BUG）作为衡量白盒测试是否充分的指标，另外还会以覆盖率指标作为检查个人是否充分测试的依据。个体行为难以转化为组织行为。开始认识到单元测试该由开发人员去做
多数尚处于混沌境界的企业会认为，单元测试应由测试人去做，可能会觉得开发人员自己编码又自己测试会陷入惯性思维，测试效果不佳。但让测试人员现实操作几次，又会冒出几个难以逾越的问题，首先是测试效率，测试人员不熟悉代码，他上手把源码读懂然后想办法做测试，要知道，单元测试面对众多琐碎的函数，随意一个开发人员一天就能写一堆新函数，所以，测试人员若把单元测试做好，通常要比开发人员自测多付10倍的精力，这一情况很致命，单元测试必然难以为继。其次，测试人员做单元测试，经常不能断定某种现象是不是问题，还得找相应开发人员去定位，问题定位了，修正问题又是个麻烦，测试人员不拥有给产品编码的权限，大量时间又浪费在反复沟通上。会发现只拿覆盖率评估测试是否充分是不够的
不同员工做白盒测试，效果差别巨大
这种现象是每个公司都会遇到的，在白盒测试推行初期表现尤为明显。能力强的就是很少漏测，很少遗漏问题到后续阶段，能力差的，尽管他很努力的想把每件事做好，漏测总还很多。会有白盒测试无用论产生
产生白盒测试无用论，多半不是从理论上反对白盒测试，而是实践走不通，做了不少单元测试，效果不佳，发现问题留于表面，深层次逻辑问题或接口问题发现不了，所以就认定白盒测试没多大用处。白盒测试能否成功很大程度上依赖于牛人经理或牛人QA
白盒测试推行初期经常，执行力强一些的经理或QA，白盒测试可以推行成功，执行力弱一些的就不成功。不少企业因为尝试几次单元测试都失败了，就全盘放弃白盒，只做黑盒测试了。有一些企业坚持下来，在一两个项目组取得成功，然后针对性的优化组织机构，比如设置专门工作推动组，建设白盒测试专家资源池，为各个项目提供测试引导人员，进一步优化流程，把白盒测试的监控点纳入流程来控制。当一个企业的组织机构与流程逐步完善，白盒测试能否成功就较少依赖于个别牛人了。
阶段化实施白盒测试，测试用例无法维护
集中一段时间编码，编码完了再集中一段时间做单元测试，单元测试完了开始集成，这时又集中时间做一次集成测试，这是多数企业实施白盒测试的模式。这一模式下，单元测试或集成测试只是特定时间段内（比如一个版本周期内的一两星期中）才实施的活动，但产品修改代码却是时时刻都在进行的，毫无疑问的会带来一个深刻问题：用例维护与产品代码维护不同步！所以，大家就经常会看到，某个产品的第一个版本可以把单元测试完整实施一遍，而此后时不时为解决问题改代码，或为追加功能改代码，单元测试很难继续，常导致单元测试只在V1版本做一遍，其后V2、V3等版本无法再做。或许有人会觉得，为让白盒测试在版本周期内坚持做下去，不见非得引入持续集成吧？试想一下，从编码到版本进入维护，开发人员独立无干扰的编码时间有多少？而从两两开始集成之后，又占去多少时间？无疑后者占去大部分时间。如果开始集成后的每次版本修改都有测试跟进，大家岂非天天写测试用例，这不是持续集成是什么？如果不想天天补充用例，隔周、隔月，或隔一个版本补充用例，怎知你增补的用例会覆盖全部变动过的代码？
嵌入式产品的单元测试该不该上单板？这个问题更多的可归结为实践上可不可行，从理论上讲没人规定单元测试就不能上单板。但现实操作中，通信产品上单板做单元测试大部分都失败。依据实践的推论，通信软件的单元测试应在仿真环境下按纯软件的方式去做，集成测试倒是可以上单板，在真实环境下去做。
成熟阶段三：
设计用例的效率提高了，做测试不再是沉重负担。开发人员自测也上升到个人意愿，即使领导不强制，流程也不限定白盒测试必须要做，开发人员仍自愿去做测试。白盒测试已成员工的普遍行为与自发行为。一批白盒测试专家，他们很清楚哪些被测对象是可以做白盒测试的，哪些不大容易做。即使处于白盒测试最高境界，也并非所有系统都适合完整的做测试，尤其那些严重依赖特定硬件环境的软件层，当白盒专家识别出哪些模块不宜做单元测试或集成测试后，他会考虑替代方案，比如加强代码审查、加强同行评审、为特定接口追加模拟器设计等。
总结
核心焦点是要解决测试效率的问题，只要效率提高了，接着通过组织结构与流程措施的优化，巩固已有成果，然后着重解决持续测试与深入测试的问题IT行业趋势
2009-03-23 20:06:33
最近IT行业发生的最大的一件事就是IBM准备开价65亿美元收购SUN，这也是IBM历史上最大的一次收购。我记得在2001年互联网泡沫破灭之前，SUN一直是一家非常牛的公司，在高端服务器市场占据了绝对的领导地位。记得1993年的时候我还是在国内一家期货交易所做红马甲也就是交易员，当时交易大厅里每个会员的席位上撮合交易用的全都是SUN的小型机，一共有400多个席位呢！1998年我去清华经管读书，正逢互联网大潮，当时有一个广告印象比较深，好像就是SUN做的，意思就是SUN等于.com，SUN给人一种如日中天的感觉。
当然现在SUN确实不行了，这也是一家技术天才公司抓不住商业机会的典型案例，它告诉我们技术虽然重要，但是商业模式和管理同样重要，这个问题留待以后再讨论。我在这里想要说的是，IBM为什么收购SUN？当然除了看中SUN的高端客户，SUN的Java、MySQL之外，还有一个小小的原因就是为了巩固自己在高端服务器领域的领导地位。为什么这个时候要巩固呢？因为思科这个强硬的竞争对手也要杀进来了。对于思科到底要推出什么样的一个产品，现在并没有答案，大家也都是在猜测，但是可以预见的是，无论思科推出的是数据中心的解决方案还是刀片式服务器，都会对IBM在这个市场的领导地位构成挑战。
由此我想起了华为在服务器市场的动作。2001年任正非在会见IBM大中华区董事长周伟焜的时候就曾经跟他探讨过未来服务器是否会与路由器重合的问题。后来几年华为就低调进入了刀片式服务器市场，虽然主要是卖给电信运营商，但是已经对IBM、HP等老牌服务器厂商构成了一定的威胁。如今，思科也杀了进来，看来是英雄所见略同呀。
与其说思科是在学华为，还不如说是互联网在深刻地改变着各个行业的生态。互联网是基于IT和电信的底层技术而产生的，但是它就像潘多拉盒子里面的魔鬼一样，打开之后就再也没有办法收回去了。记得去年一次研讨会上，易观国际总裁于扬说过一句，“互联网在蚕食IT和电信的地盘”，我深以为然。看看现在一些老牌IT和电信厂商如SUN、北电的困境，你能说跟互联网没有关系？你认为电信设备商为什么突然就不行了呢？第一个原因就是电信运营商对于设备的需求减少了，为什么减少了呢？互联网上的应用和需求每年都在大幅度增长呀，但是这些需求只是借用了电信运营商的管道，他们除了收取一次性的管道费用之外，并没有得到多少实利，反而是Google、Facebook这样的互联网公司如火如荼地发展了起来。
还有一个原因就是传统的电信设备逐渐IP化，这其实对于传统的电信设备商也是很大的威胁。为什么呢？因为原来电信设备很难通用，七国八制，因此国外的电信设备商首先进入中国，他们的东西又没法被其他厂商的设备所替代，这也就造成了他们一直垄断了国内的电信设备市场尤其是移动电信设备市场，国内的华为和中兴也只是到了最近几年才突破了这个门槛。为什么能突破呢？有一个小小的原因就在于IP化，如果电信设备全部标准化乃至模块化之后，运营商就可以把核心网和基站的某个模块拆出来单独招标，而不用担心是不是跟其他厂商的设备兼容的问题。华为和中兴的设备不比国外厂商差，又便宜，服务还更好，当然也就逐渐取代国外厂商的产品了。实际上，中国移动已经开始做这件事情了。
所以，你说互联网是不是改变了电信行业呀？那么，互联网行业的基础架构师思科如果杀入传统的IT行业，是不是会让IBM很紧张呀？而对于那些传统意义上的电信设备商来说，不转型能行吗？爱立信开始转型做服务，华为又在做什么呢？
华为的一位朋友告诉我，华为内部的SNS做得相当不错，不比现在的什么海内、校内网差，著名的猛小蛇也在这个团队当中。除此之外，华为开始跟百度、51等互联网公司成立联合实验室，除了卖给他们服务器和交换机之外，也有跟他们学互联网运营经验的意思。据说，现在华为每条产品线底下都有研究互联网的Marketing人员。最近我在华为网站上读到了华为副总裁刘南杰先生的文章“全球电信业2008年回顾和2009年展望”，文中大段大段地文字提到了云计算、SNS、All-IP等互联网词汇而不是基站和核心网，可见华为对于互联网的研究已经相当的深入。
华为未来到底想干什么，难道也要做一个SNS网站？我个人觉得这个可能性不大。华为研究互联网，是因为未来的商业环境变了，运营商的经营模式也要适应互联网的变化，要不然中国移动怎么会专门成立个卓望公司，要做互联网方面的一些探索，下面还有一家139.com，就是专门做SNS的。作为电信设备商的华为如果自己做SNS的运营，显然会跟自己的客户发生冲突，这肯定是华为不愿意看到的。但是，也许将来华为能够做电信运营商的IT总管，不仅仅给他们提供电信设备，还能够帮他们托管网络，甚至还能够帮他们进军互联网。你运营商想做SNS，没问题，我给你把所有的架子都搭好了，Turn Key的，最后把机房的钥匙交给你，你就可以在上面开展业务了。到那个时候，哪家运营商还愿意离开它？
当然，再过多少年，网络已经无所不在的时候，运营商也就不再是运营商，而是变成了媒体公司或者是信息服务公司的时候，华为也就不再是所谓的电信设备商，而转型成了互联网基础架构供应商了。那个时侯，华为也许就会跟自己的老师IBM发生正面冲突，就像思科和IBM即将发生的冲突一样。当然还有一种可能，那个时候的IBM已经不玩IT了，这个就已经超出我的想象范围了，呵呵。
美女黑客曝英特尔CPU漏洞 引发全球用户恐慌
2009-03-23 20:05:06
3月23日消息，据国外媒体报道，波兰知名美女黑客Joanna Rutkowska成为安全业内焦点人物，她在博客上发表一篇论文，曝光了一个英特尔CPU的缓存漏洞。而另一位安全研究人员Loic Duflot将在加拿大温哥华举行的CanSecWest安全大会上介绍该漏洞和攻击代码。如果这一漏洞被证实存在，黑客就可利用该漏洞获得对电脑近乎至高无上的控制权，并且不受任何操作系统控制、关闭或禁用。毋容置疑，此时杀毒软件将毫无用武之地。黑客的攻击范围，可能覆盖Vista、XP、Windows Server、Linux或BSD等任何一个装有英特尔CPU的操作系统，这无疑会给所有安装英特尔计CPU的用户带来极大恐慌。据悉，目前全球计算机系统中，英特尔CPU的市场份额占到85%以上。
庆幸的是，Joanna Rutkowska是一个被归为“灰帽黑客组织”的漏洞挖掘和研究人员，这类天才们往往以安全研究人员自居，他们常常把发现的漏洞曝光，或交给微软官方，从而推动软件厂商积极修补漏洞。
然而，如果这些高危漏洞被另一些属于“黑帽组织”的漏洞挖掘者发现的话，后果将会很糟糕。这类人一般会为了金钱而把挖掘到的漏洞卖到黑市，结果极有可能是漏洞落到商业黑客手中，从而引发网络疫情。
让一线直接呼唤炮火
2009-03-21 18:08:32
任正非呼唤地头力！！！
这是近一个时期以来，中国企业界发出的最强音。这种强音只能发源于中国企业界那个最沉静的灵魂——任正非。
没有对企业经营管理事务的全神贯注，没有洞悉答案永远在现场，没有对每一个滋生官僚的癌细胞深恶痛绝，没有头拱地不找借口解决问题的地头力，就发不出这么强势的呐喊。借用尼采的话说，这仅仅是力的事业：具有本世纪的一切病态特征，但要以充盈的、弹性的、再造的力来调整。让我们静下心来聆听任正非2009年1月份的警世演讲。
王育琨记
任正非：让一线直接呼唤炮火
我们后方配备的先进设备、优质资源，应该在前线一发现目标和机会时就能及时发挥作用，提供有效的支持，而不是拥有资源的人来指挥战争、拥兵自重。谁来呼唤炮火，应该让听得见炮声的人来决策。
· 努力做厚客户界面，以客户经理、解决方案专家、交付专家组成的工作小组，形成面向客户的“铁三角”作战单元。
· 基层作战单元在授权范围内，有权力直接呼唤炮火......一线的作战，要从客户经理的单兵作战转变为小团队作战，而且客户经理要加强营销四要素（客户关系、解决方案、融资和回款条件、以及交付）的综合能力。
· 我们机构设置的目的，就是为作战，作战的目的，是为了取得利润。平台的客户就是前方作战部队，作战部队不需要的，就是多余的。
我们从以技术为中心，向以客户为中心的转移过程中，如何调整好组织，始终是一个很难的题目。刚开始我的认识也是有局限性的。我在EMT（经营管理团队）会上讲了话，要缩短流程，提高效率，减少协调，使公司实现有效增长，以及现金流的自我循环。但提出的措施，确实有一些问题，单纯的强调精简机关，压缩人员，简化流程，遭遇一部分EMT成员的反对。他们认为机关干部和员工压到一线后，会增加一线的负担，增加了成本，并帮不了什么忙。机关干部下去以总部自居，反而干预了正常的基层工作。后来我听取一些中层干部的反映，他们认为组织流程变革要倒着来，从一线往回梳理，平台（支撑部门和管理部门，包括片区、地区部及代表处的支撑和管理部门）只是为了满足前线作战部队的需要而设置的，并不是越多越好、越大越好、越全越好。要减少平台部门，减轻协调量，精减平台人员，自然效率就会提高。这样EMT决议还未出笼就被反了一个方向。但如何去实现这一点呢？问题仍然摆在前面。这次访问利比亚时，听取了北非地区部的汇报，有了一些启发。
北非地区部努力做厚客户界面，以客户经理、解决方案专家、交付专家组成的工作小组，形成面向客户的“铁三角”作战单元，有效地提升了客户的信任，较深地理解了客户需求，关注良好有效的交付和及时的回款。
铁三角的精髓是为了目标，而打破功能壁垒，形成以项目为中心的团队运作模式。公司业务开展的各领域、各环节，都会存在铁三角，三角只是形象说法，不是简单理解为三角，四角、五角甚至更多也是可能的。这给下一阶段组织整改提供了很好的思路和借鉴，公司主要的资源要用在找目标、找机会，并将机会转化成结果上。我们后方配备的先进设备、优质资源，应该在前线一发现目标和机会时就能及时发挥作用，提供有效的支持，而不是拥有资源的人来指挥战争、拥兵自重。
谁来呼唤炮火，应该让听得见炮声的人来决策。而现在我们恰好是反过来的。机关不了解前线，但拥有太多的权力与资源，为了控制运营的风险，自然而然的设置了许多流程控制点，而且不愿意授权。过多的流程控制点，会降低运行效率，增加运作成本，滋生了官僚主义及教条主义。当然，因内控需要而设置合理的流程控制点是必须的。去年公司提出将指挥所（执行及部分决策）放到听得到炮响的地方去，已经有了变化，计划预算开始以地区部、产品线为基础，已经迈出可喜的一步，但还不够。北非地区部给我们提供了一条思路，就是把决策权根据授权规则授给一线团队，后方起保障作用。这样我们的流程优化的方法就和过去不同了，流程梳理和优化要倒过来做，就是以需求确定目的，以目的驱使保证，一切为前线着想，就会共同努力地控制有效流程点的设置。从而精简不必要的流程，精简不必要的人员，提高运行效率，为生存下去打好基础。
用一个形象的术语来描述，我们过去的组织和运作机制是“推”的机制，现在我们要将其逐步转换到“拉”的机制上去，或者说，是“推”、“拉”结合、以“拉”为主的机制。推的时候，是中央权威的强大发动机在推，一些无用的流程，不出功的岗位，是看不清的。拉的时候，看到那一根绳子不受力，就将它剪去，连在这根绳子上的部门及人员，一并减去，组织效率就会有较大的提高。我们进一步的改革，就是前端组织的技能要变成全能的，但并非意味着组织要去设各种功能的部门。基层作战单元在授权范围内，有权力直接呼唤炮火（指在项目管理上，依据IBM的顾问提供的条款、签约、价格三个授权文件，以毛利及现金流进行授权，在授权范围内直接指挥炮火，超越授权要按程序审批），当然炮火也是有成本的，谁呼唤了炮火，谁就要承担呼唤的责任和炮火的成本。后方变成系统支持力量，必须及时、有效地提供支持与服务，以及分析监控。公司机关不要轻言总部，机关不代表总部，更不代表公司，机关是后方，必须对前方支持与服务，不能颐气颇指。
公司的最高决策机构是EMT会议，EMT成员只是在会议结束后，推动决议的执行，他们叫首长负责制，也不能自称总部。机关干部和员工更不能以总部自称，发号施令，更不能要求前方的每一个小动作都必须向机关报告或经机关批准，否则，机关就会越做越大，越来越官僚。一线的作战，要从客户经理的单兵作战转变为小团队作战，而且客户经理要加强营销四要素（客户关系、解决方案、融资和回款条件、以及交付）的综合能力，要提高做生意的能力；解决方案专家要一专多能，对自己不熟悉的专业领域要打通求助的渠道；交付专家要具备能与客户沟通清楚工程与服务的解决方案的能力，同时对后台的可承诺能力和交付流程的各个环节了如指掌。其他非主业务的人员,要加强对主业务的了解,了解达不到一定深度的,不能成为管理干部及骨干，没有这种经历的，要去补好这一课。
以美军在阿富汗的特种部队来举例。以前前线的连长指挥不了炮兵，要报告师部请求支援，师部下命令炮兵才开炸。现在系统的支持力量超强，前端功能全面，授权明确，特种战士一个通讯呼叫，飞机就开炸，炮兵就开打。前线3人一组，包括一名信息情报专家，一名火力炸弹专家，一名战斗专家。他们互相了解一点对方的领域，紧急救援、包扎等都经过训练。当发现目标后，信息专家利用先进的卫星工具等确定敌人的集群、目标、方向、装备……，炸弹专家配置炸弹、火力，计算出必要的作战方式，其按授权许可度，用通信呼唤炮火，完全消减了敌人。美军作战小组的授权是以作战规模来定位的，例如：5000万美元，在授权范围内，后方根据前方命令就及时提供炮火支援。我们公司将以毛利、现金流，对基层作战单元授权，在授权范围内，甚至不需要代表处批准就可以执行。军队是消灭敌人，我们就是获取利润。铁三角对准的是客户，目的是利润。铁三角的目的是实现利润，否则所有这些管理活动是没有主心骨、没有灵魂的。当然，不同的地方、不同的时间，授权是需要定期维护的，但授权管理的程序与规则，是不轻易变化的。
我司正面临流程与组织整改的时机。我们已明确变革要以作战需求为中心，后方平台（包括设在前线的非直接作战部队）要及时、准确满足前线的需求。我们机构设置的目的，就是为作战，作战的目的，是为了取得利润。平台的客户就是前方作战部队，作战部队不需要的，就是多余的。后方平台是以支持前方为中心，按需要多少支持，来设立相应的组织，而且要提高后方业务的综合度，减少平台部门设置，减少内部协调，及时准确地服务前方。
前方要准确清晰地提出并输入需求，后方要能清楚准确地理解前方的需求，按需求提供支持。只要前方的需求没有发生变动，所有的协调工作，应由后方平台之间自行协调完成，而且必须在前方需求的时限内完成。前方的需求变化了，要及时准确提供给后方。而我们现在的情况是，前方的作战部队，只有不到三分之一的时间是用在找目标、找机会以及将机会转化为结果上，而大量的时间是用在频繁地与后方平台往返沟通协调上。而且后方应解决的问题让前方来协调，拖了作战部队的后腿，好钢没有用在刀刃上。后方协调困难有流程问题、有组织机构的设置问题、有思想意识问题，也有相互信任的问题，还有非主业干部对主业不理解的问题……，我们要找到一把提高作战部队效率的钥匙，找到一把后方平台高效服务前方的钥匙。应该说，如何提高作战部队效率的钥匙已经找到，如何打开大门仍然困难重重。IBM顾问提供给我们的关于项目管理的三个授权文件，已经帮助我们开始解开这一团乱麻，并可能帮助我们打开大门。我们应准确理解并严格执行。各级干部要敢于承担自己岗位责任，履行授权，这样就会使我们的管理摆脱僵化的中央集权。当然这些授权文件，随着公司的变革还会不断修改，以适应新的需求。而且这些授权仅是定性的，具体执行要有不同地方、不同时间、不同事件的授权。
我们要积极的先从改革前方作战部队开始，加强他们的作战能力，要综合后方平台的服务与管理，非主业干部要加强对主业务的理解，减少前后方的协调量。然后冷静地思考整个后方大平台的适应性变革，审慎的一步一步前行。哪怕每年提高千分之一的效率都是可喜的，千万不要倒退，千万不要形成臃肿、官僚的机关组织。
中国历史上失败的变革都因操之太急，展开面过大，过于僵化而失败的。华为公司廿年来，都是在不断改良中前进的，仅有少有的一、两次跳变。我们在变革中，要抓住主要矛盾和矛盾的主要方面，要把握好方向，谋定而后动，要急用先行、不求完美，深入细致地做工作，切忌贪天功为己有的盲动。华为公司的管理，只要实用，不要优中选优。天将降大任于斯人也，要头脑清醒，方向正确，踏踏实实，专心致志，努力实践，与大洪流融入到一起，必将在这个变革中，获得进步与收获。
我们并不否定廿年来公司取得的成绩。廿年来公司是实行高度的中央集权，防止了权力分散而造成失控，形成灾难，避免了因发展初期产生的问题而拖垮公司。但世界上没有一成不变的真理，今天我们有条件来讨论分权制衡、协调发展。通过全球流程集成，把后方变成系统的支持力量。沿着流程授权、行权、监管，来实现权力的下放，以摆脱中央集权的效率低下、机构臃肿，实现客户需求驱动的流程化组织建设目标。我相信成功过的华为人，完全有可能实现这一次变革。
我们要继续坚持以有效增长、利润、现金流、提高人均效益为起点的考核（条件成熟的地方，可以以薪酬总额为计算基础），凡不能达到公司人均效益提升改进平均线以上的，体系团队负责人，片区、产品线、部门、地区部、代表处等各级一把手，要进行问责。在超越平均线以上的部门，要对正利润、正现金流、战略目标的实现进行排序，坚决对高级管理干部进行末位淘汰，改变过去刑不上士大夫的做法,调整有一线成功实践经验的人补充到机关。
风华绝代总是乱世生，廿年我们刚刚长成，就遇到了国际风云变幻，各种过激环境的影响，年青的我们大多数还揣满了幻想，我们是否有能力度过这场危机，时代正考验着我们。未来的不可知性使我们的前进充满了风险，面对着不确定性，各级主管要抓住主要矛盾，以及矛盾的主要方面，要有清晰的工作方向，以及实现这些目标的合理节奏与灰度；多作一些自我批判，要清醒感知周围世界的变化，“深淘滩，低作堰”。深淘滩就是多挖掘一些内部潜力，确保增强核心竞争力的投入，确保对未来的投入，即使在金融危机时期也不动摇；低作堰就是不要因短期目标而牺牲长期目标，多一些输出，多为客户创造长期价值。“财散人聚，财聚人散”。能救我们的，只有我们自己。各个部门要自己与自己比，今年与去年比，你进步了没有，没有进步的，你是否可以把位子让出来。只要我们能不断提高效率，我们就能度过风险，而且成长起一代新人。
“沉舟侧畔千帆过，病树前头万木春。”我们要在时代的大潮中，迎着风浪快速前进。只要我们不怕牺牲自己，只要我们努力地提高效率，我们一定会度过难关。三、五年后，我们将屹立在世界的舞台上。风华绝代总是乱世生，相信江山代有才人出，期望你成长起来，担负起我们的未来。
“日出江花红胜火，春来江水绿如蓝”，期盼我们能共享春天的明媚。我们的目的一定要实现，也一定能实现。软件系统原型演示与roadmap
2009-02-28 15:27:26
软件系统原型演示与roadmap
对于属于首创的产品和系统研发，很短的开发周期，有限的人力，我和我的部门非常推荐软件系统原型演示与roadmap。
并多次成功主持此类会议。
通过推演达成以下目标:
1、使开发今早介入需求分析， 确保开发、测试、产品理解一致
2、确认确定内容和待定内容
3、尽早的完善需求，避免后期临时需求改动太大。
思科的制胜战略(转)
2009-02-02 12:37:35
关键词：数据、声音、视频、移动性、安全、无线
一、执行：连贯性、透明度和信任
近年我们认为的“执行”，就是在一季度或一年内实现财务成功及领导力，而领导力体现在产品和市场两个方面。我们的目标就是从技术角度获得领先地位。我们希望在世界任何地方的“四要素”（数据、声音、视频、移动性）成为市场的领导者，改变你娱乐、工作、交流的方式，改变你在家里、公司甚至是交通互动的方式。
二、理念：产品创新
思科的领导力依赖于三个主要因素。首先，对行业发展认识的理念。其次，在此理念基础上，思科获取领导力的战略。第三，我们实施该战略的有效性。我们用产品领导力、市场份额以及在消费细分领域的领导力三方面来衡量。
对思科而言，理念意味着如何广泛地预测通信及IT市场发展的能力，意味着理解网络是如何驱动这种发展趋势的能力。我们看到，正如市场运作的一样，网络会通过为客户提供应用程序和服务，产生更大的生产力、新的商业模式和更广泛形式的娱乐等方式，成为所有生活体验的平台。
网络视频的迅速发展，一定程度上促进了网络流量的持续增长。兼并Scientific Atlanta，为思科提供了帮助完成四要素（数据、声音、视频、移动性）所需的技术、能力和人力资源。我们强调专业性的网络视频日益增长的需求，也强调对网络背后功能需求的独特理解。这些都是我们的竞争对手难以匹敌的。在这一财年，我们强化了作为服务提供商、企业、各类商业组织及消费者的战略合作方的地位。思科拥有为各种网络提供整合商业和技术构建方法的理念及工具。
以转换器为例，消费者安装思科转换器时，他们就会理解思科领导力，所有权成本、灵活度和投资保护等方面的优势。思科转换器是思科公司专门设计的产品，用户可以便捷、低成本地将其声音、数据、安全、无线等各种功能添加在现有的思科网络体系中。该技术的创新是与竞争者抗衡的有力武器。
持续研发是思科不断创新的基础。在财年新技术研发方面，思科投入了40多亿美元。更重要的是，我们3～5年前的投资，为思科今年的业绩增长奠定了坚实的基础。
三、平衡战略：顾客细分和地理分布
思科的战略是围绕四个原则而建立的。首先，我们有能力识别市场转型，并针对这些转型，在消费者反馈的基础上，进行市场定位。其次，从建构角度讲，有独特的进入市场的方式，绝不从单一产品角度考虑市场。第三，我们平衡的商业和技术实施。第四，缜密的合作及团队合作。这是我们在执行“多维棋类游戏”（包括革新、产品、顾客细分、地理）时所采用的。
在用户细分的四个领域——企业、服务提供商、商务及消费者方面，我们的平衡法则使得思科的核心及先进技术、五个关键的地理区域运行良好。兼并Scientific Atlanta，系统整合能力的获得，使我们能够在全球服务提供商市场上分得一杯羹。而该市场，正是以前我们从未涉足过的。兼并也给我们带来了更广泛的产品。Scientific Atlanta是高端置顶盒的提供商。我们相信，该公司的高端设备将会满足服务提供商方面对宽带的需求，这使得思科在服务提供商及消费者两个细分市场上均获得了成功。
财年中，在商业市场领域，我们的产品也得到消费者的信赖，这使得商业市场成为了思科一个快速增长的细分市场。我们界定的商业公司是指一般只有不到1000名员工的企业。我们兴奋地看到，这个细分市场开始接受网络，释放出网络投资的能量和效率。
思科的业务是由五个地理区域组成的，包括美国、加拿大、欧洲市场、新兴市场及日本。在此财年，我们进一步确认了我们的消费领域，并在已有的消费领域内新增了新兴国家。我们与印度、中国、德国、沙特阿拉伯和俄罗斯等国家的政府领导人会面，对话集中在思科如何帮助这些国家通过互联网在教育、商业机会等方面促进经济发展。当这些国家开始运作互联网解决方案时，他们会将思科作为合作伙伴及重要资源。结果，思科在新兴市场的产品收入比去年增长了38%——这是在所有五个地理区域中增幅最大的。如今，新兴市场的增长，是网络力量最真实的写照。
构架师已死(转)
2009-01-07 19:01:00
2006年的职场出奇的冷清，相比前几年，简历的数量和质量都大为不如，很难得找到三年工作经验以上的人，有一个不是特别笨，就是特别怪。就是么，干得好谁没事换工作啊！Simon是一家外企软件公司的总经理，最近给这个问题愁坏了。项目一个接一个的接下来，人手越来越紧张。虽然Simon是个极限编程的粉丝，但也不得不批准了一份又一份的加班申请。HR经理把这个问题归结到房价上，他的妙论是“怕失业了还不上房款，不敢跳槽”。
这天，K项目组长Allen终于忍不住了，带了一个只有一年工作经验的小伙子要Simon面试，“很聪明！经验少了点。”
Simon皱了皱眉毛，说：“你不知道这个职位最低要求是三年工作经验吗？”
Allen说：“这已经是三个月里通过技术考试中最好的一个了，老大，试试吧。”Allen是Simon多年的哥们，比较随便。
抵到面子上来，Simon只好让Allen把小伙子带进来。
Simon的面试通常是三步曲：
问题一：你能说说毕业后的主要工作经历吗？
问题二：再说说你在公司的地位？
问题三：你的发展目标是什么？等回答后，比如说构架师，他就跟着问：想象一下你当构架师的一天，说给我听听？
小伙子回答第一问题很快很清楚，一年工作当然没什么东西。Simon觉得小伙子挺聪明。所以在小伙子回答了第二个问题后，问了一个发散性的问题：“你刚才说你在公司里处于中等水平，那比你差的人为什么会比你差呢？”
这个问题是个陷阱。
小伙子冒冒失失回答说：“我觉得他们每天工作是为工作而工作，工作没有责任感。”
Simon点点头说：“是吗？那真是糟糕的员工。那你刚好比糟糕的员工好一点了？”
小伙子的脸一下子红了，“我不是这个意思……”
“好了，那你说说比你好的人为什么比你强？”
“我觉得他非常努力，工作很多年了还在学习各种构架，水平很高。”于是Simon就问那最后一个问题。果然，小伙子回答的是要成为构架师。大概70％的人想成为构架师。但是构架师是什么呢？
Simon问道：“那你为什么要成为构架师呢？”
小伙子一愣，大概还没有人这么置疑过他。“年纪大了，不能老写程序吧。”这个回答，让Simon想起关于他对什么是老的定义：当你希望做年轻人做的事情时，你就还年轻；如果你希望做老年人做的事情，你就老了。这和你出生了多长时间是没有关系的。
Simon接着问：“好吧，那你说说你成为构架师以后，每天都会做什么？”
小伙子说：“我还没想过，不过，我想应该主要是需求分析，设计构架吧……”这大概是现在年轻人的通病，年轻人很容易追逐一些自己也不清楚的目标。
Simon问：“那设计构架具体都做些什么呢？”
小伙子这次的回答是：“比如，选择程序框架，决定用Spring或Struts等等。”
“哦，那我问你，你怎么说服别人是用Spring还是Struts呢？”
“如果我有经验，我会知道哪个更好……”
“是吗，但关于Spring或Struts的知识任谁都可以很容易得到。如果别人不同意你的建议，你怎么说服他？如果同意你的建议，那你不过是作出了和别人一样的认识，别人又凭什么认可你呢？”
小伙子没想过构架师日子里还有一个说服人的工作，说：“我是构架师，我应该有权力做决定吧？”
Simon想起权力的三种层次，第一层，任命；第二层，专业；第三层，品德。
Simon问：“如果在一个成熟的软件企业里没有你所想象的构架师呢？或者说，构架师这种职业已经死亡或消失了呢？你会怎么定位你的职业？”
小伙子显得很震惊。
Simon画了一个系统构架，然后又给小伙子看了一段代码。
“那一个更难懂？”Simon问。
小伙子指着代码说：“代码难懂。”
Simon的解释是：“这就是为什么实际上所谓的构架师不存在的原因。一个更简单的东西怎么会更有价值呢？每个人都能够画出这种构架图，但不是每个人都能写出好的代码。”
送走了小伙子，Simon有点难受。他有点喜欢这个小伙子，但是，这又是一个被愚蠢的教育和误人子弟的技术杂志污染的家伙。Simon在自己的笔记本中加了一句话：中国程序员最愚蠢的认识之三：我想当构架师。前面两个赫然是：
35岁后写不动程序了；
我只要做Java（C＋＋）；代码评审很必要(转)
2009-01-07 18:59:57
2008-01-18 作者：wingfeng19800215 来源：CSDN
记得刚到公司做第一个项目时，mentor要和我一起看看我刚实现完的一些代码，当时有些不解，难道是不相信我写的代码么？最后事实证明：我的代码中有很多缺陷，有的还是很严重的缺陷。后来知道这个过程叫'代码评审'，是保证软件质量的一种手段，而且是很重要的一种手段。代码评审的形式有多种，最正式的一种就是召集公司或者部门的一些'大牛'们，围坐在会议室中，一行一行的审查你的代码；简单的形式就像我和mentor做的那种，一个编写代码的人和一个对系统特别了解的人在一起评审，效果不见得不如正式的评审，起码我是这么认为的。
那么什么时候进行代码评审呢？代码评审的粒度又该如何确定呢？一般在你的代码已具雏形，并且已通过单元测试，未提交进行集成测试之前的这个时机。评审的粒度要看代码的规模，当然评审的代码覆盖面越大，代码的质量越有保证。对于涉及业务流程较复杂的模块一定要和熟悉业务的人一起完成代码的评审，对这类模块应给予重点关注，因为往往业务流程逻辑的错误多于语言使用的错误。还有一个时机建议作代码评审，即在系统第一版发布后，如果有需求变动需要增加新功能，记住这时代码评审的效果可能好于简单的测试，当然两者都要有才能保证代码质量更高。
粗略的想了一下，代码评审有以下几点好处：
1、代码评审会尽可能的将Bug杀死在萌芽阶段
实践证明：项目先期发现Bug的成本要远远小于后期发现Bug的成本，越早发现代码中的问题对整个系统的控制和把握就越有利。
2、代码评审的过程是一个知识技能传承的过程，有利于新人成长
代码评审类似于师傅手把手教徒弟，是知识、技巧和经验的直接传授，所以这样的机会是很难得的，特别是对于新人，要十分珍惜代码评审这样的机会，新人在这个环节中学习的效率和成果实践证明也都是最高的。
3、代码评审会让你加深对系统的理解
代码评审的过程实际上也是从新梳理思路的一个过程，特别是对于那些业务流程复杂的模块，和精通业务的人一起做代码评审可以让你加深对业务和系统的理解。
总之，代码评审是必要的，而适当的加大代码评审的粒度，你将会收到意想不到的效果。
我的栏目
- 转帖
- Java性能诊断和调优
- 系统运维
- 职业发展规划
- 项目管理
- 职业英语
- Oracle管理和开发
- 质量
- MySQL
- 性能报告
- 银行软件系统产品管理和研发
- Automation
- Oracle 性能诊断
- 应用服务器性能诊断调优
- 网络性能诊断
- 性能测试环境搭建
- 系统架构性能规划与演进
- Linux and Solaris 性能诊断与优化
- 日志分析
- Java开发
- 性能脚本开发
- End To End Performance
- Foundment of Perf Test
- Personal Folder
- JVM 调优
- HTTP服务器中间服务器
- 自动化脚本
- 技术前沿-分布式系统测试
- 云计算系统测试
- 日志分析工具
- 产品前沿
- Hadoop
- 安全
- 市场与销售
- Selenium自动化平台设计
- 第三方支付
- 服务器实时监控
- Java
标题搜索
我的存档
数据统计
- 访问量: 96442
- 日志数: 485
- 书签数: 1
- 建立时间: 2008-02-26
- 更新时间: 2016-04-13
