博客园_杨学明(值得信赖的研发管理专家,软件测试专家)

软件测试管理公开课讲师杨学明 2011-11-25~26 地点:北京

2011-11-16T02:56:00Z

课程编号：RDM-009 课时：14小时（2天×7小时）

软件测试管理

主办单位:汉捷研发管理咨询有限公司

主办日期：2011-11-25~26

主办地点：北京

联系人：0755-26528355 胡海燕

课程收益

l 找到如何管理软件测试组织及团队的方法和思路

l 系统掌握业界领先的产品开发过程中测试项目管理方法，测试人员如何参与项目

l 掌握国际化标准测试流程的建立思路，高效率软件测试的标准及规范

l 掌握软件测试涉及的关键技术，如单元测试、集成测试、系统测试及验收测试

l 学习软件测试的度量指标，以及测试团队的绩效考核

l 找到测试团队跨部门协调困难的解决之道，如何使测试团队发挥最大的价值

l 掌握建立自动化测试平台和方法和思路

l 学习基于敏捷开发流程的测试管理

l 学习企业级测试体系建设的方法和技巧

课程背景

据中国软件行业协会研究报告显示，2010年1-11月，我国软件业呈快速增长态势，同比增长30%，增速比去年同期提高8.6个百分点，软件产业已成为中国高科技发展重要支柱之一，但中国软件产品质量保证手段以及测试流程和管理的规范性，与国外同行（美国、印度等）存在较大的的差距。
在软件业较发达的国家, 软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。例如，在美国的软件开发中，需求分析和规划确定的比重只有3%，设计占5%，编程占7%，而测试要占到15%，其余67% 是投产和维护。微软为打造Windows2000，用了250 多个项目经理、1700 多个开发人员，而测试人员则用了3200 人，几乎是开发人员的两倍。而且，每修改一个错误，都花费大量时间以确保没有新错误产生。

而在我国，由于总体上，国内软件项目过程不规范，导致重视编码和轻视测试的现象，对于软件测试的重要性、测试方法和流程等还存在很多错误的认识。主要表现在：

（1）软件开发完成后进行软件测试

（2）软件发布后如果发现质量问题，是软件测试人员的责任

（3）软件测试哪个人员都行

（4）软件测试是测试人员的事情，与程序员无关

（5）项目进度紧张时少做测试，时间富裕时多做测试

（6）软件测试是没有前途的工作，只有程序员才是软件高手

以上几点是中国很多研发管理人员的误区，虽然很多领导试图提高软件质量，并且大部分领导已认识到测试是提高软件质量的重要手段之一，但总是不得要领，不知如何建立软件测试管理体系，设置了人员但不知如何明确职责，明确了职责但不知如何建立测试流程，建立了流程但不知如何参与研发团队进行测试，测试人员与开发人员之间矛盾重重，很多公司的软件开发团队采用敏捷开发模式，测试人员无从下手等等现象枚不胜举。

本课程关注于软件测试管理体系建设，包括纯管理软件、互联网软件、嵌入式软件等系统级产品。它将从软件测试概念、软件测试工程、软件测试项目管理、软件测试组织与团队、软件测试技术与自动化、敏捷测试管理等几个层面进行培训。

课程特色

p 课程完整介绍项目级以及产品级测试体系，以及软件测试4大活动（单元测试、集成测试、系统测试、验收测试）的基本职责、方法。

p 系统化的课程内容：全面分析测试理论、测试实践、测试流程、团队管理、工具模板及敏捷测试管理。

p 讲师在国内优秀企业（华为、阿里巴巴、蓝韵集团）工作时的切身实践体会和13年多的软件开与与测试管理经历，能够深入浅出地分析讨论各种软件测试管理遇到的问题, 并列举大量的测试管理案例，有助于管理人员借鉴与参考。

p 讲师有国外项目背景，曾参与国际化项目的测试项目管理工作，与美国及印度的同事深入合作，积累了很多国际化软件测试的最佳实践。

p 课程独特，内容丰富而精彩，不但让测试管理者了解测试知识，而且还能从中学习到研发管理流程，QA等方面的知识。

p 课程实践性较强，所有的方法、工具和模板都是来自讲师从事一线管理时的经验和教训。

讲师资历

杨学明：高级顾问，高级讲师

深圳测试协会副会长

研发管理专家

曾担任华为、阿里巴巴高级测试管理职位

o 专业背景：13年产品开发及测试团队管理经验，先后担任软件开发工程师、资深测试工程师、软件技术经理、研发项目经理、研发测试部经理、研发管理总监等职位，积累了丰富的软件开发技术及测试管理方面的经验，曾组建多个测试团队和负责多个大型项目的测试管理工作，并多次参与国际化软件项目的测试工作，有与美国、印度同事的合作经历。

o 培训背景：为阿里巴巴、金山软件、大展科技、蓝韵集团、联想集团、深圳科皓等多家企业讲授过《产品测试管理》、《软件测试管理》、《软件项目管理》、《集成产品开发（IPD）》、《软件单元测试》、《研发质量管理》、《配置管理》、《敏捷测试管理》等课程，担任深圳测试协会副会长职务，对软件自动化测试及性能测试进行了深入的研究，在北京、上海、深圳、杭州等地多次举办研发测试论坛或公开课，是广东测试联盟（www.gztest.com)发起人之一、个人博客：mikeyond.cnblogs.com。

o 咨询背景：作为高级咨询顾问参与了多家高科技企业的研发体系建设，取得了良好的效果。主要参与了蓝韵集团、英威腾电气、上海酷宝、华工正源光子等多家企业的研发管理体系建设与辅导实施。

参加对象

研发副总裁、研发总监、项目总监、研发经理、测试经理、软件测试人员、软件开发人员、项目经理、质量保证人员等

课程大纲

1. 软件测试概述

本章节学习目标：主要让学员了解为什么需要软件测试，软件测试对于软件质量保证的重要性，以及软件测试在整个产品质量体系中的位置。并列举软件测试的原则与方法。

1.1. 软件测试管理面临的常见问题

1.2. 测试在质量体系中的位置

1.3. 测试原则与方法

1.4. 为什么要尽早测试

1.5. 木桶原理 ·20/80原则 ·Good-Enough原则·多快好省原则

1.6. 错误、缺陷、故障、失效 ·测试成本分析

1.7. 测试、调试、测试与调试的关系和区别

1.8. 测试方法分类

1.8.1. 白盒测试、黑盒测试、灰盒测试

1.8.2. 测试策略 ·单元测试、集成测试、系统测试、验收测试

1.8.3. ALPHA测试、BETA测试、功能测试、性能测试

1.8.4. 动态测试、静态测试

1.8.5. 手工测试、自动化测试、负载测试、压力测试、性能测试

本单元研讨案例：列举我公司在软件测试中遇到的问题，并分组讨论，派代表上台发言。

2. 软件测试工程过程

本章节学习目标：让学员了解测试工程过程和流程管理，掌握软件测试的关键活动和管理流程,并向学员展现每个阶段的测试模板。

2.1. 什么是软件测试工程（从阿里巴巴的性能测试谈起）

2.2. 测试在软件工程中的位置(基于不同开发流程中的测试角色）

2.3. 瀑布模型测试过程

2.4. W型测试过程

2.5. H型测试过程

2.6. V型测试过程

2.6.1. 单元测试计划 ·单元测试 ·单元测试报告与详细设计关系

2.6.2. 集成测试计划 ·集成测试·集成测试报告与概要设计关系

2.6.3. 系统测试计划 ·系统测试 ·系统测试报告与需求规格设计关系

2.6.4. 测试用例

2.6.5. 测试缺陷管理

2.6.6. 测试报告

2.7. 代码审查与走读过程

2.7.1. 召开审查走读会议

2.7.2. 专人书面评审

2.7.3. 使用统计和分析工具

2.8. 单元测试过程

2.8.1. 什么是桩（Stub）、驱动器（Driver）、模拟器（Simulator）

2.8.2. 单元测试环境

2.8.3. 单元测试工具选型

2.8.4. 单元/部件测试准备

2.8.5. 单元/部件测试执行

2.8.6. 测试计划和用例评审查检表、测试记录、缺陷报告

2.9. 集成测试过程

2.9.1. 集成测试策略的确定时机

2.9.2. 集成测试基本概念 ·集成测试对象  ·集成测试中的角色定义

2.9.3. 集成测试的特点

2.9.4. 集成测试顺序确定

2.9.5. 集成测试准备 ·集成测试执行   ·缺陷跟踪

2.9.6. 集成测试质量目标   ·典型集成测试平台构造

2.9.7. 集成测试工作开展的制约因素

2.9.8. 集成测试成败关键因素分析

2.10. 系统测试过程

2.10.1. 转测试操作流程和标准

2.10.2. 系统测试基本概念（定义、对象、依据）

2.10.3. 系统测试过程 ·系统测试输入、输出

2.10.4. 系统测试准备

2.10.5. 系统测试执行

2.10.6. 测试环境的规划和管理

2.10.7. 问题跟踪反馈  ·基于产品平台的测试策略

2.10.8. 系统测试成败关键因素分析 ·“黑白唱”

2.11. 文档测试过程

2.11.1. 安装包文字和图片

2.11.2. 安装与设置指南

2.11.3. 用户手册

2.11.4. 在线帮助

2.12. 验收测试

2.12.1. 验收的基本定义与目的

2.12.2. 验收测试类型

2.12.3. 根据合同验收

2.12.4. 用户验收测试

2.12.5. 运行测试

2.12.6. 现场测试

2.12.7. 测试人员在客户验收过程中的职责

模板展示：测试计划、测试用例、单元测试、集成测试、验收测试、文档测试等模板展示。

3. 产品开发中的测试项目管理

本章节学习目标：掌握完整的测试项目的管理方法，分为项目级测试管理，产品级测试管理以及项目外包测试管理三个方面。

研讨案例：某知名通讯企业一个成功的项目测试案例，让学员分组讨论得到的启发，从流程到模板分别进行进述。

3.1. 软件测试人员参与开发项目遇到的常见问题

3.2. 项目级测试管理

3.2.1. 测试管理平台的建立

3.2.2. 测试模板的设计

3.2.3. 测试交付件的管理

3.2.4. 测试计划裁剪

3.2.5. 测试工作量的估算

3.2.6. 测试过程监控

3.2.7. 测试的成本控制

3.2.8. 测试过程的风险控制

3.2.9. 失效模式和影响分析（FMEA）

3.3. 软件需求跟踪

3.4. 测试架构设计

3.5. 测试计划设计

3.6. 测试用例设计

3.7. 测试用例的设计

3.7.1. 等价类划分法

3.7.2. 边界值分析法

3.7.3. 因果图法

3.7.4. 功能图法

3.7.5. 错误推断法

3.7.6. 正交实验设计方法

3.7.7. 测试用例设计的技巧：“弱化定性思维+ 破坏性假设”

3.8. 测试工具设计

3.9. 测试评审

3.9.1. 需求规格评审

3.9.2. 详细设计评审

3.9.3. 测试计划评审

3.9.4. 测试用例评审

3.9.5. 测试报告评审

3.10. 版本测试开始标准及结束标准

3.10.1. 每个阶段开始的标准

3.10.2. 每个阶段结束的标准

3.10.3. 测试中断的标准

3.10.4. 版本测试结束的标准

3.11. 缺陷管理流程

3.12. 测试模板

3.13. 制订测试验收标准

3.14. 测试问题定级标准

3.15. 测试评估

3.16. 产品级测试管理

3.16.1. 产品测试的全局性

3.16.2. 产品测试用例库的建立

3.16.3. 测试用例的管理

3.16.4. 测试用例的维护

3.16.5. 产品自动化测试策略

3.16.6. 每日构建的（Daily Build）的管理方法

3.16.7. 缺陷生命周期管理

3.16.8. 测试覆盖率评估

3.16.9. 其于软件缺陷的质量评估

3.17. 测试外包管理

3.17.1. 降低成本

3.17.2. 保证质量

3.17.3. 提高效率

3.17.4. 灵活的人力资源

3.18. 软件测试与度量

3.18.1. 软件测试成熟度模型（TMM）

3.18.2. 软件开发过程阶段性度量指标

3.18.3. 缺陷度量或缺陷分布度量

3.18.4. 测试用例的深度、质量和有效性

3.18.5. 测试执行的效率和质量

3.18.6. 缺陷报告的质量

3.18.7. 测试覆盖度

3.18.8. 测试环境的稳定性或有效性

3.18.9. 测试过程改进（TPI：Test Process Improvement）

3.18.10. 缺陷预防与分析（ODC缺陷分析、Gompertz分析、Rayleigh分析、四象限分析、根本原因分析、缺陷注入分析、DRE/DRM分析等）

3.18.11. CTP、STEP、CMMI等模型探讨

ü 案例研讨：为什么要进行测试度量？

4. 测试组织与团队

本章节学习目标：了解如何管理一个测试团队，包括个人技能，团队能力，冲突管理，绩效考核，测试团队成员的选、用、育、留等环节。

4.1. 企业测试体系典型问题分析

4.2. 测试技能发展历程

4.3. 测试体系如何从无到有建设?

4.4. 如何从功能测试到测试平台建设?

4.5. 测试组织发展历程

4.6. 建立独立的测试组织

4.7. 如何建设高水平的测试部门?

4.8. 企业测试文化的建立及培养

4.9. 团队组织架构

4.10. 个能技能

4.11. 测试团队角色分类

4.12. 测试团队的沟通

4.13. 测试团队冲突管理

4.13.1. 正确对待缺陷

4.13.2. 具备良好的态度

4.13.3. 开发和测试的合作

4.14. 绩效考核管理

4.15. 招聘优秀的软件测试工程师

4.16. 测试人员的职业通道

4.17. 激励测试人员

4.18. 测试团队的培养和提升

实例演练：在进度紧张的情况下，测试人员如何处理好和项目经理，开发人员的关系？

5. 软件测试技术与自动化

本章节学习目标：了解软件测试自动化工具的应用与实践，掌握什么时候需要引入自动化测试，以用自动化测试所需的条件及自动化工具的选型，了解自动化测试的好处与不足；

5.1. 测试工具的概念

5.1.1. 成本效益和风险

5.1.2. 测试工具策略

5.1.3. 测试工具集成

5.1.4. 脚本和脚本语言（TCL/TK、PYTHON、VB、RUBY、SHELL等）

5.2. 测试缺陷管理工具（QC、BUGZILLA、IBM lutos notes）

5.3. 测试用例管理工具（TD、TESTLINK、BUGFREE等）

5.4. 测试工具部署

5.5. 开源测试工具

5.6. 测试工具开发

5.7. 测试工具分类

5.8. 测试工具的收益分析

5.9. 项目研讨：自动化测试是否可以促进项目进度，节省质量成本？

6. 基于敏捷开发模式的测试管理

本章节学习目标：了解在敏捷开发模式下的测试管理，测试人员如何参与敏捷项目。

6.1. 敏捷测试的必要性

6.2. 敏捷的价值

6.3. 敏捷测试团队中角色与活动场景演练

6.4. 敏捷测试团队的运作方式

6.5. 敏捷测试员的十条法则

6.6. 面向技术的测试管理

6.7. 敏捷测试四象限管理

6.8. 敏捷测试成功的关键要素

6.9. 敏捷开发过程中的自动化测试策略

6.10. 敏捷测试的最佳实践

6.11. 研讨：如何构建高效敏捷测试团队？

7. 构建企业级测试体系建设

7.1. 案例：某企业测试体系存在的问题分析

7.2. 企业测试体系典型问题分析

7.3. 测试技能发展历程

7.4. 测试体系如何从无到有建设?

7.5. 如何从功能测试到测试平台建设?

7.6. 测试组织发展历程

7.7. 建立独立的测试组织

7.8. 如何建设高水平的测试部门?

8. 课程总结与回顾

本章节学习目标：针对两天的课程，进行课程回顾，总结学习成果。

8.1. 研讨：根据我公司现状，如何推进软件测试管理体系？

本文链接

研发项目管理内训在南京成功举办

2011-09-18T04:15:00Z

研发项目管理培训

产品研发是企业可持续发展的战略基石，这就要求项目领导人需要面对组建团队、控制进程、规避风险等重要难题。因此，如何高质高效的完成项目研发，如何有效的管理研发项目是每个企业面临的最大的难题之一，也是许多管理者深感困惑之处。

针对以上问题，2011年9月3日南京埃斯顿公司邀请了深圳汉捷研发管理咨询公司的资深讲师杨学明老师为我们进行了研发项目管理培训，杨老师从项目研发的启动、计划、实施、控制、收尾五个环节为项目管理人员提供了解决思路及应对措施。

课程采用学员分组讨论、经典案例分享、组内交流讨论、组间相互点评等方式，让每位成员快速的融会贯通，受益匪浅。

精彩互动的课程现场

杨老师对大家发表的观点进行汇总、分析

课程休息期间，学员们向杨老师请教在工作中遇到的问题，杨老师耐心的为学员进行详细具体的解答

本次课程中，与会成员带着关注的问题，积极的投入到每次的案例互动中。杨老师凭借自己多年的产品开发和项目管理经验，通过大量的案例分析，形象生动、深入浅出的阐述了在项目管理中经常遇到的问题和解决办法，给在场的每位成员带来了非常丰富的信息和有价值的案例，对今后实际的研发项目管理提供了非常好的借鉴和参考价值。

本文链接

2011年9月23《软件测试管理》公开课，接受报名！

2011-08-11T01:03:00Z

课程编号：RDM-009 课时：14小时（2天×7小时）

软件测试管理

主办单位:汉捷研发管理咨询有限公司

主办日期：2011-9-23~24

地点：南山区中油阳光大酒店二楼若木厅

联系人：李艳飞 liyanfei@higet.com.cn 0755-26528350

课程收益

l 找到如何管理软件测试组织及团队的方法和思路

l 系统掌握业界领先的产品开发过程中测试项目管理方法，测试人员如何参与项目

l 掌握国际化标准测试流程的建立思路，高效率软件测试的标准及规范

l 掌握软件测试涉及的关键技术，如单元测试、集成测试、系统测试及验收测试

l 学习软件测试的度量指标，以及测试团队的绩效考核

l 找到测试团队跨部门协调困难的解决之道，如何使测试团队发挥最大的价值

l 掌握建立自动化测试平台和方法和思路

l 学习基于敏捷开发流程的测试管理

l 学习企业级测试体系建设的方法和技巧

课程背景

（1）软件开发完成后进行软件测试

（2）软件发布后如果发现质量问题，是软件测试人员的责任

（3）软件测试哪个人员都行

（4）软件测试是测试人员的事情，与程序员无关

（5）项目进度紧张时少做测试，时间富裕时多做测试

（6）软件测试是没有前途的工作，只有程序员才是软件高手

课程特色

p 课程完整介绍项目级以及产品级测试体系，以及软件测试4大活动（单元测试、集成测试、系统测试、验收测试）的基本职责、方法。

p 系统化的课程内容：全面分析测试理论、测试实践、测试流程、团队管理、工具模板及敏捷测试管理。

p 讲师有国外项目背景，曾参与国际化项目的测试项目管理工作，与美国及印度的同事深入合作，积累了很多国际化软件测试的最佳实践。

p 课程独特，内容丰富而精彩，不但让测试管理者了解测试知识，而且还能从中学习到研发管理流程，QA等方面的知识。

p 课程实践性较强，所有的方法、工具和模板都是来自讲师从事一线管理时的经验和教训。

讲师资历

杨学明：高级顾问，高级讲师

深圳测试协会副会长

研发管理专家

曾担任华为、阿里巴巴高级测试管理职位

o 专业背景：13年产品开发及测试团队管理经验，先后担任软件开发工程师、资深测试工程师、软件技术经理、研发项目经理、研发测试部经理、研发管理总监等职位，积累了丰富的软件开发技术及测试管理方面的经验，曾组建多个测试团队和负责多个大型项目的测试管理工作，并多次参与国际化软件项目的测试工作，有与美国、印度同事的合作经历。

o 培训背景：为阿里巴巴、金山软件、大展科技、蓝韵集团、联想集团、深圳科皓等多家企业讲授过《产品测试管理》、《软件测试管理》、《软件项目管理》、《集成产品开发（IPD）》、《软件单元测试》、《研发质量管理》、《配置管理》、《敏捷测试管理》等课程，担任深圳测试协会副会长职务，对软件自动化测试及性能测试进行了深入的研究，在北京、上海、深圳、杭州等地多次举办研发测试论坛或公开课，是广东测试联盟（http://www.gztest.com/)发起人之一、个人博客：mikeyond.cnblogs.com。

o 咨询背景：作为高级咨询顾问参与了多家高科技企业的研发体系建设，取得了良好的效果。主要参与了蓝韵集团、英威腾电气、上海酷宝、华工正源光子等多家企业的研发管理体系建设与辅导实施。

参加对象

研发副总裁、研发总监、项目总监、研发经理、测试经理、软件测试人员、软件开发人员、项目经理、质量保证人员等

课程大纲

1. 软件测试概述

本章节学习目标：主要让学员了解为什么需要软件测试，软件测试对于软件质量保证的重要性，以及软件测试在整个产品质量体系中的位置。并列举软件测试的原则与方法。

1.1. 软件测试管理面临的常见问题

1.2. 测试在质量体系中的位置

1.3. 测试原则与方法

1.4. 为什么要尽早测试

1.5. 木桶原理 ·20/80原则 ·Good-Enough原则·多快好省原则

1.6. 错误、缺陷、故障、失效 ·测试成本分析

1.7. 测试、调试、测试与调试的关系和区别

1.8. 测试方法分类

1.8.1. 白盒测试、黑盒测试、灰盒测试

1.8.2. 测试策略 ·单元测试、集成测试、系统测试、验收测试

1.8.3. ALPHA测试、BETA测试、功能测试、性能测试

1.8.4. 动态测试、静态测试

1.8.5. 手工测试、自动化测试、负载测试、压力测试、性能测试

本单元研讨案例：列举我公司在软件测试中遇到的问题，并分组讨论，派代表上台发言。

2. 软件测试工程过程

本章节学习目标：让学员了解测试工程过程和流程管理，掌握软件测试的关键活动和管理流程,并向学员展现每个阶段的测试模板。

2.1. 什么是软件测试工程（从阿里巴巴的性能测试谈起）

2.2. 测试在软件工程中的位置(基于不同开发流程中的测试角色）

2.3. 瀑布模型测试过程

2.4. W型测试过程

2.5. H型测试过程

2.6. V型测试过程

2.6.1. 单元测试计划 ·单元测试 ·单元测试报告与详细设计关系

2.6.2. 集成测试计划 ·集成测试·集成测试报告与概要设计关系

2.6.3. 系统测试计划 ·系统测试 ·系统测试报告与需求规格设计关系

2.6.4. 测试用例

2.6.5. 测试缺陷管理

2.6.6. 测试报告

2.7. 代码审查与走读过程

2.7.1. 召开审查走读会议

2.7.2. 专人书面评审

2.7.3. 使用统计和分析工具

2.8. 单元测试过程

2.8.1. 什么是桩（Stub）、驱动器（Driver）、模拟器（Simulator）

2.8.2. 单元测试环境

2.8.3. 单元测试工具选型

2.8.4. 单元/部件测试准备

2.8.5. 单元/部件测试执行

2.8.6. 测试计划和用例评审查检表、测试记录、缺陷报告

2.9. 集成测试过程

2.9.1. 集成测试策略的确定时机

2.9.2. 集成测试基本概念 ·集成测试对象 ·集成测试中的角色定义

2.9.3. 集成测试的特点

2.9.4. 集成测试顺序确定

2.9.5. 集成测试准备 ·集成测试执行 ·缺陷跟踪

2.9.6. 集成测试质量目标 ·典型集成测试平台构造

2.9.7. 集成测试工作开展的制约因素

2.9.8. 集成测试成败关键因素分析

2.10. 系统测试过程

2.10.1. 转测试操作流程和标准

2.10.2. 系统测试基本概念（定义、对象、依据）

2.10.3. 系统测试过程 ·系统测试输入、输出

2.10.4. 系统测试准备

2.10.5. 系统测试执行

2.10.6. 测试环境的规划和管理

2.10.7. 问题跟踪反馈 ·基于产品平台的测试策略

2.10.8. 系统测试成败关键因素分析 ·“黑白唱”

2.11. 文档测试过程

2.11.1. 安装包文字和图片

2.11.2. 安装与设置指南

2.11.3. 用户手册

2.11.4. 在线帮助

2.12. 验收测试

2.12.1. 验收的基本定义与目的

2.12.2. 验收测试类型

2.12.3. 根据合同验收

2.12.4. 用户验收测试

2.12.5. 运行测试

2.12.6. 现场测试

2.12.7. 测试人员在客户验收过程中的职责

模板展示：测试计划、测试用例、单元测试、集成测试、验收测试、文档测试等模板展示。

3. 产品开发中的测试项目管理

本章节学习目标：掌握完整的测试项目的管理方法，分为项目级测试管理，产品级测试管理以及项目外包测试管理三个方面。

研讨案例：某知名通讯企业一个成功的项目测试案例，让学员分组讨论得到的启发，从流程到模板分别进行进述。

3.1. 软件测试人员参与开发项目遇到的常见问题

3.2. 项目级测试管理

3.2.1. 测试管理平台的建立

3.2.2. 测试模板的设计

3.2.3. 测试交付件的管理

3.2.4. 测试计划裁剪

3.2.5. 测试工作量的估算

3.2.6. 测试过程监控

3.2.7. 测试的成本控制

3.2.8. 测试过程的风险控制

3.2.9. 失效模式和影响分析（FMEA）

3.3. 软件需求跟踪

3.4. 测试架构设计

3.5. 测试计划设计

3.6. 测试用例设计

3.7. 测试用例的设计

3.7.1. 等价类划分法

3.7.2. 边界值分析法

3.7.3. 因果图法

3.7.4. 功能图法

3.7.5. 错误推断法

3.7.6. 正交实验设计方法

3.7.7. 测试用例设计的技巧：“弱化定性思维+ 破坏性假设”

3.8. 测试工具设计

3.9. 测试评审

3.9.1. 需求规格评审

3.9.2. 详细设计评审

3.9.3. 测试计划评审

3.9.4. 测试用例评审

3.9.5. 测试报告评审

3.10. 版本测试开始标准及结束标准

3.10.1. 每个阶段开始的标准

3.10.2. 每个阶段结束的标准

3.10.3. 测试中断的标准

3.10.4. 版本测试结束的标准

3.11. 缺陷管理流程

3.12. 测试模板

3.13. 制订测试验收标准

3.14. 测试问题定级标准

3.15. 测试评估

3.16. 产品级测试管理

3.16.1. 产品测试的全局性

3.16.2. 产品测试用例库的建立

3.16.3. 测试用例的管理

3.16.4. 测试用例的维护

3.16.5. 产品自动化测试策略

3.16.6. 每日构建的（Daily Build）的管理方法

3.16.7. 缺陷生命周期管理

3.16.8. 测试覆盖率评估

3.16.9. 其于软件缺陷的质量评估

3.17. 测试外包管理

3.17.1. 降低成本

3.17.2. 保证质量

3.17.3. 提高效率

3.17.4. 灵活的人力资源

3.18. 软件测试与度量

3.18.1. 软件测试成熟度模型（TMM）

3.18.2. 软件开发过程阶段性度量指标

3.18.3. 缺陷度量或缺陷分布度量

3.18.4. 测试用例的深度、质量和有效性

3.18.5. 测试执行的效率和质量

3.18.6. 缺陷报告的质量

3.18.7. 测试覆盖度

3.18.8. 测试环境的稳定性或有效性

3.18.9. 测试过程改进（TPI：Test Process Improvement）

3.18.10. 缺陷预防与分析（ODC缺陷分析、Gompertz分析、Rayleigh分析、四象限分析、根本原因分析、缺陷注入分析、DRE/DRM分析等）

3.18.11. CTP、STEP、CMMI等模型探讨

ü 案例研讨：为什么要进行测试度量？

4. 测试组织与团队

本章节学习目标：了解如何管理一个测试团队，包括个人技能，团队能力，冲突管理，绩效考核，测试团队成员的选、用、育、留等环节。

4.1. 企业测试体系典型问题分析

4.2. 测试技能发展历程

4.3. 测试体系如何从无到有建设?

4.4. 如何从功能测试到测试平台建设?

4.5. 测试组织发展历程

4.6. 建立独立的测试组织

4.7. 如何建设高水平的测试部门?

4.8. 企业测试文化的建立及培养

4.9. 团队组织架构

4.10. 个能技能

4.11. 测试团队角色分类

4.12. 测试团队的沟通

4.13. 测试团队冲突管理

4.13.1. 正确对待缺陷

4.13.2. 具备良好的态度

4.13.3. 开发和测试的合作

4.14. 绩效考核管理

4.15. 招聘优秀的软件测试工程师

4.16. 测试人员的职业通道

4.17. 激励测试人员

4.18. 测试团队的培养和提升

实例演练：在进度紧张的情况下，测试人员如何处理好和项目经理，开发人员的关系？

5. 软件测试技术与自动化

本章节学习目标：了解软件测试自动化工具的应用与实践，掌握什么时候需要引入自动化测试，以用自动化测试所需的条件及自动化工具的选型，了解自动化测试的好处与不足；

5.1. 测试工具的概念

5.1.1. 成本效益和风险

5.1.2. 测试工具策略

5.1.3. 测试工具集成

5.1.4. 脚本和脚本语言（TCL/TK、PYTHON、VB、RUBY、SHELL等）

5.2. 测试缺陷管理工具（QC、BUGZILLA、IBM lutos notes）

5.3. 测试用例管理工具（TD、TESTLINK、BUGFREE等）

5.4. 测试工具部署

5.5. 开源测试工具

5.6. 测试工具开发

5.7. 测试工具分类

5.8. 测试工具的收益分析

5.9. 项目研讨：自动化测试是否可以促进项目进度，节省质量成本？

6. 基于敏捷开发模式的测试管理

本章节学习目标：了解在敏捷开发模式下的测试管理，测试人员如何参与敏捷项目。

6.1. 敏捷测试的必要性

6.2. 敏捷的价值

6.3. 敏捷测试团队中角色与活动场景演练

6.4. 敏捷测试团队的运作方式

6.5. 敏捷测试员的十条法则

6.6. 面向技术的测试管理

6.7. 敏捷测试四象限管理

6.8. 敏捷测试成功的关键要素

6.9. 敏捷开发过程中的自动化测试策略

6.10. 敏捷测试的最佳实践

6.11. 研讨：如何构建高效敏捷测试团队？

7. 构建企业级测试体系建设

7.1. 案例：某企业测试体系存在的问题分析

7.2. 企业测试体系典型问题分析

7.3. 测试技能发展历程

7.4. 测试体系如何从无到有建设?

7.5. 如何从功能测试到测试平台建设?

7.6. 测试组织发展历程

7.7. 建立独立的测试组织

7.8. 如何建设高水平的测试部门?

8. 课程总结与回顾

本章节学习目标：针对两天的课程，进行课程回顾，总结学习成果。

8.1. 研讨：根据我公司现状，如何推进软件测试管理体系？

本文链接

软件测试为什么失败?

2011-06-30T03:31:00Z

软件测试为什么会失败

汉捷咨询/杨学明

案例1： A公司是一家从事网游点卡交易的互联网公司，去年年底我司做调研时发现一个问题：测试部门有近40人，独立于研发团队，团队成员分为自动化测试和手工测试两个小组，测试经理则是从IBM过来的，但据研发和测试人员反应，测试人员的地位非常低，自动化测试岗位形同虚设，没有起到任何作用，在互联网软件开发的过程中，测试人员的价值非常有限，测试员工的成就感非常低，最近一个月也有30%-40%的离职率，这个问题让负责测试部门的陈总非常头痛，一方面人员不太稳定，一方面软件质量的问题越来越多....

案例2：B公司是深圳一家医疗电子企业，公司有专业的软件测试部，独立向研发管理部汇报。经过我司的调研，B公司的软件测试流程已具备，专业的测试人员也有一批，但测试人员相对于开发人员普遍薪酬低，缺乏激励，加上公司领导层对研发过程质量不太关注，研发过程中测试不充分，导致许多致命的问题到客服现场才发现，最后又把责任推到测试头上，测试人员不愿意承担责任，导致团队的测试效率非常低下，开发与测试之间相互推诿....

以上两个案例，是中国目前很多企业遇到的问题。软件究竟需不需要测试，软件的测试究竟怎么做？如何通过软件测试来保证产品质量？....在软件开发越来越占重要地位的今天，越来越多的领导层已认识到软件测试的重要性，但除了华为、中兴、腾讯等为数不多的几个公司做得好一点之外，很多企业都还在摸索，测试部门的价值在一个公司里往往成了争论的焦点，测试人员的地位也无法与开发人员抗衡。

笔者曾经分别任职于华为和阿里巴巴公司，也曾经服务过一些中小型软件公司，成功和失败的案例都有，总体来说，中国目前的软件测试体系还不成熟，很多公司试图做好软件测试，但由于在测试管理、测试技术、测试流程等方面缺乏高度的认识，往往导致测试失败，如测试人员的待遇问题、测试技术如何提升、自动化需要做到什么程度等等，测试为什么失败？根据笔者多年的测试管理经验，可以归结为以下三个方面：

1）缺乏测试组织的支撑。许多公司的测试组织仍然附属于开发部门，没有独立的测试环境，不能从公平、公正的角度指出软件存在的缺陷，并要求在限定的时间对软件的缺陷进行修复。国外较成熟的测试组织（如微软，Yahoo等），测试组织属于QA部门，而不是研发部门，这样更有利于保证产品质量。另一方面，许多公司对测试部门的定位是QC（质量控制）部门，而测试部门并没有控制质量的权利，而成了QC（质量检测）的角色，即在最后一个环节对软件产品进行验证，这个时候为时已晚，产品质量的很多问题可能已无法测试出来。在华为公司，测试和开发是平等的，两个部门都是PDT（产品开发团队）的组成部分。如下图所示：

PDT是临时小组，在项目开始时成立，在产品成功发布后解散，PDT成员在概念阶段一起作整个项目的计划，PDT成员在执行阶段一起管理整个项目，测试人员和开发人员同时参与项目的整个过程。只有测试人员一开始就进入产品开发团队，才能有效的保证产品质量，因此，建立独立于开发的测试体系是非常必要的。

2）缺乏测试流程的保障。很多公司建立了规范了开发流程，如CMMI或IPD等等，但软件测试往往成了短板，如开发的版本发布频繁，测试人员疲于奔命，测试人员缺乏质量检测标准，测试过程中的软件需求变更过快，没有测试结束标准等...这些都是缺乏规范的测试流程的表现。没有规范的测试流程，研发人员会经常会以此为借口，发布没有完善的软件版本，开发过程中不做版本规划，修改缺陷时经常返工...这些，都会增加测试人员的工作量，而作为开发的下游部门，测试人员很难去改变开发人员的这些不规范的行为，只能用大家公认的流程去约定大家的开发行为，如单元测试、集成测试、系统测试、验收测试的入口条件、中断条件、出口条件等。同时，在开发过程中，对开发人员和测试人员的行为进行约束，如开发修复缺陷后需要返工，要与绩效挂钩；测试人员漏测试致命或严重缺陷需要处罚等等。目前，业界较流行的开发流程采用V模型：

V模型的特点是：开发与测试紧密相连。在V模型中，从项目的需求分析、

概要设计、详细设计到具体的编码编写。开发的每一个环节都和软件的测试紧密

相扣，可以有效的保证产品质量。各个阶段测试的工作如下：

①需求阶段主要活动是：测试工作从需求文档中，设计系统测试的用例，

按照需求文档的功能划分，突出测试重点。完成系统测试的计划工作。

②在功能概要设计阶段活动是：依据功能概要设计的目标，设计测试用例，对集成测试阶段的目标，作好一个准备。

③在详细设计阶段的活动是：在这一阶段，对应的测试工作是单元测试工作，通过详细设计的说明，测试工作人员可以准备好测试用例。这个是最小的测试执行单元。

④在编码阶段的活动是：测试工作可以根据上述的单元测试计划，进行单元测试了。一面编程，一面进行单元测试。充分的单元测试可以极大的提高程序的质量。因为很大的一部分错误都是在单元中发现的，如条件组合问题、边界值问题等。

编码工作全部完成后，测试工作就可以按照计划进行。从单元测试、集成

测试、到系统测试。最后还有验收测试，验收测试工作主要是面向客户，向客户演示软件功能的实现。通过系统测试的用例。给客户展示，并确保用例全部执行通过，测试工作完成。建立规范的测试流程对测试部门的效率提升是非常关键的一环。

3）缺乏合适的测试人员。很多公司的HR认为对测试人员的要求较低，不需要懂得太多的知识，也不需要具备很多经验，测试谁都可以做。其实，这些观点都是错误的。要招聘到一个合适的测试人员不是一件容易的事。因为一个合格的软件测试人员需要同时具备以下条件：

①具备一定的产品和业务知识。

②有一定的怀疑精神，有寻根问底的精神。

③良好的沟通能力。

④具备一定的编程能力，只有懂一两门编程语言，跟开发的交流会更加顺畅。

⑤具备良好的文档编写能力，能编写较规范的测试报告。

⑥总结及分享的能力，能及时总结测试经验及与他人分享的能力。

⑦学习能力较强，对新业务、新技术和新产品功能的掌握较快。

⑧具备发散性思维，需要对客户的正常操作及异常操作进行推断。

⑨掌握一定的自动化测试方法和工具，能对测试效率不断进行改进。

除了上面几点之外，还有些公司对测试人员的英文水平要求较高，或者要求有带领团队的能力。可见，测试人员需要掌握的知识还真多，具备以上要求的测试人员或管理人员少之又少，除了招聘之外，公司内部也可以进行培养。

由此可见，人、流程、组织对软件测试的成功进行缺一不可。当然，研发管理的规范性，测试人员的绩效考核和激励机制也是非常重要的因素，一定要解决测试团队的成就感问题，同时，应建立测试人员的职业通道。只有这样，测试才有可能做好，不会陷入“测试人员走了一批又来了一批”的怪圈，一方面团队不稳定，另一方面产品质量也不会稳定。

本文链接

敏捷开发模式下的质量管理

2011-06-30T03:19:00Z

敏捷开发模式下的质量管理

汉捷咨询/杨学明

前几天，笔者与一位在大型互联网公司从事质量保证的朋友交谈，作为互联网产品质量和测试的负责人，他最近负责的质量管理方面遇到了很多困难。主要有：1）测试团队在敏捷开发模式下的价值非常有限；2）开发人员只顾自已写代码，没有任何文档，测试人员无从下手，3）由于进度的原因，测试人员测试的时间非常有限，上线后出现很多问题；4）由于测试人员得不到开发团队的认可，离职率非常高；5）质量部门无法收集到数据，不能进行质量度量；6）测试团队也有一批自动化测试专家，但派不上用场…..这些问题可能很多开发团队都会遇到，总结一下，大致是这几个方面：

} 越来越多的企业希望采用，但没有把握

} 习惯于传统的瀑布式产品开发流程已不满足快速发展需要，但大规模改动不现实

} 缺少敏捷软件开发专家和人才

} 技术人员需要观念的转变和方法培训

} 缺乏相应的质量控制方法

} 需要经常的和及时的质量度量、测试、决策

} 自动化测试不能落到实处，每日构建仍是纸上谈兵

在现在行业中，需求变化太快，不管我们怎么努力去做，发现还是不能满足客户的需要，不管需求搞得多么细，到交付产品给客户的事情，总是有这样那样的问题，这个时候就不得不去修改我们的软件，这是目前很多企业尤其是互联网公司面临的一个挑战，如何解决这个问题？

笔者先后在华为、阿里巴巴软件质量部门任职，最近也深入研究了腾讯敏捷开发平台TAPD（腾讯敏捷产品开发）和IGD（集成游戏开发）一些资料，对国内敏捷项目的质量管理有很多独到的见解，结合汉捷咨询公司多年的项目经验，总结如下：

1）QA角色的转变

QA要从警察的角色转变到一个教练的角色。在以前，团队实施CMM的时候，QA更多的是一个警察的角色，他整天拿着一个checklist、报告什么的到处去团队里面看，你是否ok，不ok就要怎么怎么样，整天就干这个活，但是引入敏捷之后，QA就觉得有点失落，都敏捷了，我都不知道该怎么下手了，在著名的通信企业华为的做法是将QA转变了一下，将QA更多的充当教练的角色，充当SCRUM Master的角色，他去指导项目团队该如何去开这个站立式会议，该怎么去做迭代的计划等等指导性的工作，这样QA也觉得挺好，这样他能参与到在不同的团队中去，QA的角色更多的偏向于全过程的敏捷活动指导，以提高产品开发效率和质量。QA在这个过程中也能得到一些数据，如代码缺陷率，版本的不良率，上线遗留问题数，团队成员配合度等等。

2）要使敏捷团队整体参与

QA和测试人员也是敏捷团队的一部分，作为敏捷教练，要向他提供支持和训练，以使作们适应开发的快节奏。比如，如果你是敏捷团队中的测试人员，并且计划会议和设计讨论没有邀请你，或者业务用户正在独立定义故事和需求，那你应该主动站出来和团队的其他成员交流，并偿试“三方协作”，即测试人员、开发人员和业务专家。腾讯公司把业务专家称为BA，即

Bussiness Analyst, BA和开发人员DE、测试人员TE组成了敏捷开发团队，这些成员不仅仅把都在忙着最终的交付而努力，他们还乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自已的需求，从而得到他们的需要的功能，同时向所有人提供项目进展的反馈。

3）自动化回归测试。敏捷团队没有自动化会成功吗？可能也会成功，但我们所知道的成功团队都依赖于自动化回归测试，如腾讯和支付宝公司的Selenium框架，阿里巴巴和淘宝网的QTP框架。汉捷咨询认为，敏捷开发利用测试来指导开发，为了编写的代码使测试通过，需要快速而简单地运行测试，没有短期反馈周期和安全的回归测试，团队将很快陷入技术债务，缺陷不断增加，速度越来越慢。

4）提供并获取反馈

反馈是敏捷的核心价值，敏捷的短期迭代可以提供持续的反馈以帮助团队正常运转，测试人员则通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供支馈。如你怎么知道客户手里拿到了预期行为的正确示例？你怎么知道编写的测试用例正确地反映了这些示例？开发人员通过查看测试用例能够理解应该编写什么代码吗？QA和测试人员应该询问开发人员是否得到了足够的信息以理解需求并是否能够指导编码，询问客户是否理解质量标准，应花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。把反馈的结构可表示为如下：

5）构造核心的敏捷实践活动

软件行业有一名老话是：软件质量是设计出来的。对于敏捷开发也是如此，汉捷咨询认为没有一些基础的实践活动，无法产生出高质量的软件。

①持续集成。持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。利用持续集成可以让缺陷在引入的当天就被发现并解决，降低缺陷修改成本；将集成工作分散在平时，通过每天生成可部署的软件；避免产品最终集成时爆发大量问题。

②灰度发布。这是互联网产品的一个特点，说白了，就是对用户一个逐步放量的一个过程，而且不要求团队要尽早的将产品包发布出来，也就是不要求马上发布给所有用户，而是会分批的去发布，比如按号段发布，比如在公司内部先体验。发布的时候也有策略，比如发布时如何放量，对用户有些什么样的实验，技术上怎样做一些后台开关，运营上怎样跟进，怎样保证4小时人员的留守，发布完后怎样收集用户反馈等等都会有一些统一的规则。比方实验室某WEB产品的发布，可以同时有多个版本，1.1版可能会有100%的用户在用，1.2版可能只有1%的用户在用，它们是一个交叉升级的过程，目前腾讯采用了该活动。

③ 每日晨会：每个团队每天大概花15-30分钟，回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作（特点：是站着开会）。笔者在阿里巴巴工作时，就经历过每日晨会，一般主持人由敏捷团队的成员轮流担任，这个时候可以了解每天发生的问题。

④结对编程：两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；领航员检视的同时还必须负责考虑下一步的工作方向，比如可能出现的问题以及改进等。有助于提升代码设计质量；研究表明结对生产率比两个单人总和低15%，但缺陷数少15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高，同时结对编程能够大幅促进团队能力提升和知识传播。

⑤用户故事。用户故事是站在用户角度描述需求的一种方式；每个用户故事须有对应的验收测试用例；用户故事是分层分级的，在使用过程中逐步分解细化；典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。用户故事的好处是：用户故事站在用户视角便于和客户交流，准确描述客户需求；用户故事可独立交付单元、规模小，适于迭代开发，以获得用户快速反馈；用户故事强调编写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计。

⑥迭代回顾会议。在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步；围绕如下三个问题：本次迭代有哪些做得好？本次迭代我们哪些方面还能做得更好？我们在下次迭代准备在哪些方面改进？会议需要Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；会议关注重点是Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；会议结论要跟踪闭环。

总之，汉捷咨询认为，测试和质量是整个敏捷团队的职责，团队中的每一个人都应该关注手边的一个任务或者故事，敏捷模式下的质量管理更具有挑战性，但与传统瀑布模式相比，其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。敏捷的焦点在于持交付有价值的软件让一直到客户满意为止。在这个“快鱼吃慢鱼”时代，要想交付好而快的产品，不防用敏捷模式试试。

本文链接

浅谈IPD模式下的敏捷软件项目管理

2011-06-30T03:17:00Z

浅谈IPD模式下的敏捷软件项目管理

汉捷咨询/杨学明

华为无线的ROSA-RB项目引进敏捷后：

TR5后遗留问题缺陷率降低了30%

TTM（Time To Market）改进了30%

平均生产率提升了49.6%

-----数据来自华为官网

http://www.huawei.com/cn/publications/view.do?id=3269&cid=5764&pid=87

汉捷案例：A公司是汉捷的一个客户，成立于1998年，是国内建设领域信息化服务产业的领军软件企业。公司立足工程建设领域，围绕工程项目的全生命周期，为客户提供以工程造价为核心，以工程项目（综合）管理为主体的软件产品和企业信息化整体解决方案。

2007年，由于产品的BUG比较多，稳定周期相当长，一般正式发布的产品的稳定周期为两到三个月。产品开发完了，测试人员却不敢懈怠，得不断测试，不然不敢交付用户。而且，需求变化快，产品发布后，马上面临修改。答应客户的产品交付时间一推再推。在此形式下，公司高层推动IPD（集成产品开发）体系，但没有收明显的效果，根据汉捷咨询的观察，主要是市场及客户的需求变化太快，难以把握一些新的市场机会点，大家对开发方法不再有信心，研发能力已经无法支撑公司去把握新的市场机会。程序员和测试人员很难有休息的时候，加班强度非常大，产品的发布质量非常糟糕。这让分管研发的副总裁王强压力非常大。

2008年初，A公司研发副总裁王强意识到问题的严重性，在汉捷咨询的帮助下，推动了IPD加敏捷的项目管理模式，持续关注客户价值，并对研发团队辅以有效的激励措施，内部客户的概念，按照价值链排序，公司内部在自己后面的那个人就是自己的客户，因为他更靠近外部客户，那个人满意是自己重要的考核指标，所以这就使得所有人都主动去想客户为什么不满意。在外部目标统一的情况下，很容易形成一个很好的自适应团队。例如，开发人员为让自己的客户——测试人员满意，就会提前不断与做测试人员和做需求人沟通，提前进行很多开发阶段的质量风险控制活动，如此一来，很多BUG在开发阶段被修正，提高了整个开发过程的效率和质量，让产品开发更敏捷。

经过两年多的努力，到了2010年，A公司的这种情况却发生了翻天覆地的变化：公司5月在深交所成功上市，预计年产值4亿多元，主要有四条产品线、7个主要产品，种类涵盖管理类、工具类、互联网类，有33万使用者、280个研发人员，产品的发布周期稳定，能全面满足市场营销计划。“从2009年开始，我们全面按100%计划交付，并且有的工具类产品甚至做到了提前交付，甚至还有27个研究、孵化类产品项目积极探寻市场机会。”王强自豪的说。

提到敏捷开发，大家会不约而同的想到开发一个软件产品可以不需要文档、设计和计划；敏捷只是一些优秀实践，或者是优秀实践的结合；敏捷只适用于小项目开发；敏捷只会对研发产生改变；管理者不需要亲自了解敏捷，只需要管理上支持就可以了；引入敏捷只需要按照既定的步骤去做就可以了；敏捷是CMMI的替代品，是另一种流程……其实，这些观点都是错误的。从上面的案例不难看出，敏捷并不是一种开发流程，汉捷咨询认为，敏捷是一种思想，它是集理念、优秀实践、具体应用于一体的代名词。

目前，国内很多企业都在推行IPD，IPD更加注重流程，在概念、计划、开发、验证、发布、维护阶段设置阶段性决策点，通过决策点对产品开发做出调整、保证投资收益比和产品的质量。而敏捷开发更加关注在软件研发领域，IPD的思想则是产品运营领域，视角不同，着重点就不同，如果把敏捷比喻成导弹，那么IPD就是原子弹，如果把敏捷比喻为战斗机，那么IPD就是航空母舰。敏捷更加注重沟通，强调拥抱变化，强调与客户的紧密合作。那么，如何在IPD模式下实施敏开发模式呢？

笔者先后经历过华为和阿里巴巴公司两家大型企业的研发模式，在华为，IPD早已在2001开始推广并使用，到今天走过10个年头，已经根深蒂固, 牢记在每个研发人员心中的就是IPD的六个过程、六个技术评审点（TR）和四个决策评审点（DCP），但对于敏捷开发，早在2006就开始应用，2009才大规模推广，也走过了一段不寻常的历程；在阿里巴巴，作为中国最大的互联网公司之一，大部分的项目采用敏捷开发模式，以客户价值为中心的交付模式早已深入人心。对于IPD与敏捷的结合，许多人仍持质疑的态度，主要表现在：

1）如何管理企业级敏捷项目，因为几个人的小项目开发好管理，但是要做到多个团队、多个项目、多条产品线敏捷开发的整合管理就不那么容易了；但IPD体系往往是跨团队的，是涉及到多个项目的流程体系，并且涉及到人员较多；

2）开发人员离职带来的风险很大，因为敏捷的很多信息留在开发者的头脑里，并没有形成像IPD和CMMI要求的那样大量、细致的开发文档，一旦开发人员离职，项目进度以及产品开发和维护的可继承性都将受到很大程度的影响。

软件开发和硬件开发不一样，软件的变更比硬件容易得多，变更的成本较低，因此在整个软件生命周期内变更是非常普遍的。如果采用原始的瀑布模型，等到所有变更完成测试后，再交付给客户，那么很有可能项目会延期；同时，有很多的潜在需求是在客户看完DEMO后进行明确的，甚至客户提出新的需求，都是基于研发输出的原始版本，在这种背景下，就产生敏捷的最佳实践之一迭代开发。敏捷/迭代开发的核心思想是：聚集客户价值，以客户为中心，交付刚刚好的系统，随时构建立品质量。

华为公司从2009开始，产品研发部正式推行敏捷/迭代开发模式，对于IPD模式下的部分软件项目进行敏捷转型，通过“三步走”的策略，实现人员技能、工程能力、流程、工具等方面的积累，在风险可控的情况下逐步达到全面敏捷的目标。三步走的内容如下：

1）项目级敏捷：实施的范围限定在TR2—TR4A,聚焦单个项目组或多个项目组或多个项目组协同的开发过程和能力改进；对IPD流程的对外交付点及非研发领域（用服、Marketing等）没影响。

2）版本级敏捷：版本级敏捷实施的范围将扩展到TR1—TR6,对架构、设计、非研发领域协同（用服，Marketing等）等多个方面能力提出了更的要求；版本具备按特性向最终客户分批交付的能力，加快对用户响应速度

3）产品级敏捷：实施范围扩展到产品的全生命周期（含所有版本），以更小的需求包接纳客户需求，给用户提供更快的市场响应速度，将在规划、组织结构、主流程、市场、财务、供应链、商务等方面带来巨大挑战。

路线图如下：

对上图的说明：

①项目级敏捷：聚集在TR2～TR4A的单个项目组或多个项目组协同的开发过程和能力改进。要求实践：持续集成、开发测试拉通、迭代、回顾会议、自动化测试、站立会议、用户代表参加与现场迭代性验收。建议有如下实践活动：建议实践：引入敏捷团队的PO和Scrum Master角色、结对编程、TDD、特性团队、重构。

好处：1.培养人员，储备敏捷实践技能、带来质量和效率的提升2.激发团队士气，逐步掌握敏捷思想。

②版本级敏捷：1.范围扩展到TR1-TR6；2.具备按特性向用户分批交付的能力，保持一个主干；3.要求系统设计、开发和测试、资料、硬件的协同；4.迭代交付模式的改变带来资料、市场、用服等相应的改变。

要求实践：系统Anatomy、需求管理。

好处：缩短交付周期；降低版本维护成本；提高需求命中率；整个版本的质量和效率提升。

③产品级敏捷：1. 聚焦产品全生命周期；2. 将敏捷精益思想（降低批量、减少任务等待时间）融入到产品端到端流程中；从一个R版本中多个小版本的串行开发转变到基于小需求包的并行开发，并且始终保持一个主干3. 交付周期进一步缩短对组织、流程、财务、供应链、商务等带来影响。

要求实践：可能包含的实践：产品需求管理、版本规划和策略、多个并行需求包开发团队的协同和管理。

好处：全流程角度减少需求等待时间，最限度的缩短TTM，更聚焦客户价值。

总之，敏捷是来源于实践的思想和方法体系，具备鲜明的实践特征，真正要应用好敏捷开发方法，需要每个人在领会敏捷精髓的基础上，投入到敏捷实践中，在实践中领悟，在实践中升华。敏捷变革过程中必然伴随着困难、彷徨和阵痛，只要秉持开放进取的心态和坚定不移的决心，持续关注人员培养，加强经验交流，精心准备，耐心实施，敏捷就一定能够成功！从敏捷思想起源至今，不论是新兴的互联网公司，软件开发公司，还是以传统IPD流程为主轴的创新型企业，如华为，腾讯，阿里巴巴等，都在推动中国敏捷项目管理前进的步伐，可以预见，在未来的一段时间，敏捷项目管理将是众多管理者必须迈过的一道槛！

附件：A公司项目级敏捷过程样例：

说明：

首轮迭代启动前：

• 需求分析将原始需求细化成Story，并形成产品Backlog；

• TR1前增加Anatomy活动，将用户需求映射到系统Anatomy图；

• 系统架构设计，输出系统架构，系统设计活动输出DS和模块AR；

• 对于复杂和新增的模块，建议TR2后先完成模块架构设计，再启动迭代开发；

• 版本迭代计划会议输出版本迭代计划和迭代完成标准；

• 无统一TR3点和TR4点，在PDC前增加迭代启动评估活动，评估迭代启动入口条件是否具备。

每轮迭代中：

• 项目组迭代计划会议输出迭代Backlog和Story完成标准；

• 迭代0可选，做为特殊迭代，实现代码框架/公用机制部分，验证系统架构和模块架构的可行性；

• 多项目组在版本迭代计划协同下进行迭代开发（周期2-4周），分批实现产品Story；

• 每轮迭代包括Story开发和验证的小循环、迭代内部验收，用户代表现场验收和迭代回顾会议，达到迭代完成标准后再启动下一轮迭代。

所有迭代完成后：

• TR4A前要进行全系统的功能回归验证；

• TR4A以后活动不变。

关于工作说明：

• 工作件主要目的是：促进当前项目高效地、准确地沟通；用于智力资产传承，便于后续产品开发和维护；

• 本样例中工作件是推荐的最基础的交付文档。

本文链接

任正非:管理的灰度

2011-05-13T01:03:00Z

任正非：管理的灰度

　华为的核心价值观中，很重要的一条是开放与进取，这条内容在行政管理团队的讨论中，有较长时间的争议。华为是一个有较强创新能力的公司，开放难道有这么重要吗？由于成功，我们现在越来越自信、自豪和自满，其实也在越来越自闭。

我们强调开放，更多一些向别人学习，我们才会有更新的目标，才会有真正的自我审视，才会有时代的紧迫感。

清晰的方向来自灰度

一个领导人重要的素质是方向、节奏。他的水平就是合适的灰度。坚定不移的正确方向来自灰度、妥协与宽容。

一个清晰方向，是在混沌中产生的，是从灰色中脱颖而出，方向是随时间与空间而变的，它常常又会变得不清晰。并不是非白即黑、非此即彼。合理地掌握合适的灰度，是使各种影响发展的要素，在一段时间和谐，这种和谐的过程叫妥协，这种和谐的结果叫灰度。

妥协一词似乎人人都懂，用不着深究，其实不然。妥协的内涵和底蕴比它的字面含义丰富得多，而懂得它与实践更是完全不同的两回事。我们华为的干部，大多比较年轻，血气方刚，干劲冲天，不大懂得必要的妥协，也会产生较大的阻力。

我们纵观中国历史上的变法，虽然对中国社会进步产生了不灭的影响，但大多没有达到变革者的理想。我认为，面对它们所处的时代环境，他们的变革太激进、太僵化，冲破阻力的方法太苛刻。如果他们用较长时间来实践，而不是太急迫、太全面，收效也许会好一些。其实就是缺少灰度。方向是坚定不移的，但并不是一条直线，也许是不断左右摇摆的曲线，在某些时段来说，还会划一个圈，但是我们离得远一些或粗一些来看，它的方向仍是紧紧地指着前方。

我们今天提出了以正现金流、正利润流、正的人力资源效率增长，以及通过分权制衡的方式，将权力通过授权、行权、监管的方式，授给直接作战部队，也是一种变革。在这次变革中，也许与二十年来的决策方向是有矛盾的，也将涉及许多人的机会与前途，我想我们相互之间都要有理解与宽容。

宽容是领导者的成功之道

为什么要对各级主管说宽容？这同领导工作的性质有关。任何工作，无非涉及到两个方面：一是同物打交道，二是同人打交道。

不宽容，不影响同物打交道。一个科学家，性格怪癖，但他的工作只是一个人在实验室里同仪器打交道，那么，不宽容无伤大雅。一个车间里的员工，只是同机器打交道，那么，即使他同所有人都合不来，也不妨碍他施展技艺制造出精美的产品。

但是，任何管理者，都必须同人打交道。有人把管理定义为“通过别人做好工作的技能”。一旦同人打交道，宽容的重要性立即就会显示出来。人与人的差异是客观存在的，所谓宽容，本质就是容忍人与人之间的差异。不同性格、不同特长、不同偏好的人能否凝聚在组织目标和愿景的旗帜下，靠的就是管理者的宽容。

宽容别人，其实就是宽容我们自己。多一点对别人的宽容，其实，我们生命中就多了一点空间。

宽容是一种坚强，而不是软弱。宽容所体现出来的退让是有目的有计划的，主动权掌握在自己的手中。无奈和迫不得已不能算宽容。

只有勇敢的人，才懂得如何宽容，懦夫决不会宽容，这不是他的本性。宽容是一种美德。

只有宽容才会团结大多数人与你一齐认知方向，只有妥协才会使坚定不移的正确方向减少对抗，只有如此才能达到你的正确目的。

没有妥协就没有灰度

坚持正确的方向，与妥协并不矛盾，相反妥协是对坚定不移方向的坚持。

当然，方向是不可以妥协的，原则也是不可妥协的。但是，实现目标过程中的一切都可以妥协，只要它有利于目标的实现，为什么不能妥协一下?当目标方向清楚了，如果此路不通，我们妥协一下，绕个弯，总比原地踏步要好，干嘛要一头撞到南墙上？

在一些人的眼中，妥协似乎是软弱和不坚定的表现，似乎只有毫不妥协，方能显示出英雄本色。但是，这种非此即彼的思维方式，实际上是认定人与人之间的关系是征服与被征服的关系，没有任何妥协的余地。

“妥协”其实是非常务实、通权达变的丛林智慧，凡是人性丛林里的智者，都懂得恰当时机接受别人妥协，或向别人提出妥协，毕竟人要生存，靠的是理性，而不是意气。

“妥协”是双方或多方在某种条件下达成的共识，在解决问题上，它不是最好的办法，但在没有更好的方法出现之前，它却是最好的方法，因为它有不少的好处。

妥协并不意味着放弃原则，一味地让步。明智的妥协是一种适当的交换。为了达到主要的目标，可以在次要的目标上做适当的让步。这种妥协并不是完全放弃原则，而是以退为进，通过适当的交换来确保目标的实现。相反，不明智的妥协，就是缺乏适当的权衡，或是坚持了次要目标而放弃了主要目标，或是妥协的代价过高遭受不必要的损失。

明智的妥协是一种让步的艺术，妥协也是一种美德，而掌握这种高超的艺术，是管理者的必备素质。

只有妥协，才能实现“双赢”和“多赢”，否则必然两败俱伤。因为妥协能够消除冲突，拒绝妥协，必然是对抗的前奏；我们的各级干部真正领悟了妥协的艺术，学会了宽容，保持开放的心态，就会真正达到灰度的境界，就能够在正确的道路上走得更远，走得更扎实。

坚决反对完美主义

什么是职业化？就是在同一时间、同样的条件，做同样的事的成本更低，这就是职业化。市场竞争，对手优化了，你不优化，留给你的就是死亡。思科在创新上的能力，爱立信在内部管理上的水平，我们现在还是远远赶不上的。要缩短这些差距，必须持续地改良我们的管理，不缩短差距，客户就会抛离我们。

的确，我们要有管理改进的迫切性，但也要沉着冷静，减少盲目性。我们不能因短期救急或短期受益，而做长期后悔的事。不能一边救今天的火，一边埋明天的雷。管理改革要继续坚持从实用的目的出发，达到适用目的的原则。

我们从一个小公司脱胎而来，小公司的习气还残留在我们身上。我们的员工也受二十年来公司早期的习惯势力的影响，自己的思维与操作上还不能完全职业化。这些都是我们管理优化的阻力。由于我们从小公司走来，相比业界的西方公司，我们一直处于较低水平，运作与交付上的交叉、不衔接、重复低效、全流程不顺畅现象还较为严重。

在管理改进中，要继续坚持遵循“七反对”的原则。坚决反对完美主义，坚决反对繁琐哲学，坚决反对盲目的创新，坚决反对没有全局效益提升的局部优化，坚决反对没有全局观的干部主导变革，坚决反对没有业务实践经验的人参加变革，坚决反对没有充分论证的流程进行实用。

我们不忌讳我们的病灶，要敢于改革一切不适应及时、准确、优质、低成本实现端到端服务的东西。但更多的是从管理进步中要效益。我们从来就不主张较大幅度的变革，而主张不断的改良，我们现在仍然要耐得住性子，谋定而后动。

因地制宜实事求是

西方的职业化，是从一百多年的市场变革中总结出来的，它这样做最有效率。穿上西装，打上领带，并非是为了好看。我们学习它，并非是完全僵化地照搬，难道穿上中山装就不行？

我们二十年来，有自己成功的东西，我们要善于总结出来，我们为什么成功，以后怎样持续成功，再将这些管理哲学的理念，用西方的方法规范，使之标准化、基线化，有利于广为传播与掌握并善用之，培养各级干部，适应工作。

只有这样我们才不是一个僵化的西方样板，而是一个有活的灵魂的管理有效的企业。看西方在中国的企业成功的不多，就是照搬了西方的管理，而水土不服。一个企业活的灵魂，就是坚持因地制宜实事求是。这两条要领的表现，就是不断提升效率。

我们从杂乱的行政管制中走过来，依靠功能组织进行管理的方法虽然在弱化，但以流程化管理的内涵，还不够丰富。流程的上、下游还没有有效“拉通”，基于流程化工作对象的管理体系还不很完善。组织行为还不能达到可重复、可预期、可持续化的可值得信赖的程度。人们还习惯在看官大官小的指令，来确定搬道岔。以前还出现过可笑的工号文化。

工作组是从行政管制走向流程管制的一种过渡形式，它对打破部门墙有一定好处，但它对破坏流程化建设有更大的坏处。而我们工作组满天飞，流程化组织变成了一个资源池，这样下去我们能建设成现代化管理体系吗？一般而言，工作组人数逐步减少的地方，流程化的建设与运作就比较成熟。

我们要清醒地认识到，面对未来的风险，我们只能用规则的确定来对付结果的不确定。只有这样我们才能随心所欲，不逾矩，才能在发展中获得自由。任何事物都有对立统一的两面，管理上的灰色，是我们生命之树。我们要深刻理解开放、妥协、灰度。

本文链接

讨论：研发团队中最合适的开发测试比是多少？

2010-11-20T14:54:00Z

讨论：研发团队中最合适的开发测试比是多少？

在上周六淘宝网和阿里巴巴B2B联合主办、InfoQ独家社区支持的第二届互联网测试交流大会上，来自Google、Baidu、网易、腾讯、淘宝、阿里巴巴、FreeWheel等公司的测试经理分别分享了他们在测试领域的心得体会，原计划500人的会场到会了800人。在讲师交流环节，大家对“研发团队中最合适的开发测试比是多少”话题做了讨论。（编辑注：方便起见，本文对各测试经理均使用花名，请勿对号入座！）

郭靖是某大型网上商城测试团队的负责人，自2003年加入公司后就组建了该网站的测试团队，推动团队进行性能测试、自动化测试、接口测试等。随着团队的壮大，他遇到的比较头疼的问题是一个研发团队中开发测试比究竟多少比较合适？根据他的了解，Google的开发测试比是10比1，微软的比例是1比3，大家都做得很好。在长时间的纠结之后，他问自己，这个比例真的很重要吗？其实在他看来，大家关注的是开发测试人员的技能、效率、成本和质量等维度，而不是某个具体的比例。同时，他也疑问能否有一种合适的手段来说清楚某个研发团队最合适的开发测试比是多少。

来自另一家知名互联网公司的测试经理，也是负责整个公司测试框架的杨康谈到自己对这个问题的理解：

公司高层通常会给质量部定一些目标，要求你的人员配比是多少。但我的理解是，很难定义和衡量质量部的工作成果。对于高层来说，给质量部最有力的一个施压办法就是人员配比，至于下一步你怎么去做，你自己去想办法。坦白来说，高层是希望能有一个手段，让质量部的人员能尽可能快地完成工作。在开始的时候，我们整个研发团队也有过1比2或者1比3的时候，高层就不断地要求我们降低开发测试人员比。但是现在大家已经都不提这个事情了，因为高层认为我们现在做的还可以，对产品的贡献还不错，现在提的更多是如何更好地提高质量。

托雷同样来自一家大型互联网公司，也是测试团队的负责人，就杨康提到的和公司高层相关的问题，他同样深有感触：

在我加入公司后，我的直接老板换过几次。每次新的老板上任，都会问这些问题，我都需要重新给他讲一遍我们是如何做测试的，开发测试比是多少等等。做了一两年之后，他基本就不问了，但是不幸地是老板又换了，第一件事又是来问这个问题。然后自己就将3年前类似的话再说一遍。我想大家都了解这种情况，有时主管测试的高层也许是测试领域外的，可能很多是开发出身，不一定真得懂测试。所以我就想能否找到一种比较科学的方法，像性能测试一样，能大体看到它的瓶颈，看到它的容量规划到什么样的程度等。

来自新创互联网公司的测试经理欧阳克从“存在即合理”的哲学角度分享了自己的观点：

开发测试比其实反映的是公司内部开发和测试结构的关系，有的公司开发人员多一些，测试人员少一些，这个比例相应来说是最低的。而有的公司比较依赖于QA，可能开发测试比就高一些。所以不同的公司，差异肯定会比较大。可能没有一种合适的办法能数清楚这个事情。我的看法就是存在就是合理。

对Google研发团队比较有了解的洪七公介绍了Google开发测试比10比1的背景，同样认为开发测试比不是最重要的，最重要的是要根据公司的情况确定合适的比例：

我非常同意郭靖的观点，其实高层经常的问题就是人员配比，因为这个问题大家都理解，而像缺陷比率这些问题，有些人可能根本就不懂。而且人员配比和成本非常相关，老板都关心这个问题。所以说和高层沟通的时候，一定不能纠缠于这个问题，你要告诉他人员比例不是最关键的问题。如果他非要有个标准逼着你这样去做的话，你要给他讲其他公司的人员配比的背景。

比如Google的开发测试比是10比1，其实是有前提条件的：第一，测试部门并不是要进入所有的项目:，如果你的项目做得太糟，程序写得太烂，测试人员压根就不会进去；第二，测试人员有绝对的权力控制自己的资源；第三是开发工程师自己要做大量的测试。如果没有这三个条件，你怎么去谈10比1？根本是不可能的事情。所以你一定要告诉老板，开发测试比不是最重要的，我们要根据公司的具体情况确定合适的比例。

究竟某个研发团队的开发测试比多少合适，这和团队的开发、测试工程师的素质也有密不可分的关系，一灯大师从大家对测试的偏见，结合Google对开发和测试的理解，解释说要压缩开发测试比，可行的办法是提高测试工程师的素质：

10比1只是一个量的问题，其实背后还有一个质的问题，即人员素质的问题。在很多传统软件公司中，很多测试人员的素质不是非常高，比如大家通常说的观点就是“你做不了开发就去做测试”。像这种情况必须要扭转。在我们公司，现在就特别重视提高测试人员的技能、素质，同时也一直在提高招聘门槛，加强对测试人员的培养，包括调教开发人员配合做单元测试等。所以说Google的研发比例是10比1，这里面不能忽视的一点是Google的研发人员和测试人员素质都很高，尤其是研发工程师对单元测试和代码质量要求非常高。而咱们其他的一些互联网行业的研发、测试人员可能就没有这么高的素质，这种情况下只能采取人海战术。

本文链接

我看软件测试的现状和未来

2009-11-10T01:30:00Z

从阿里巴巴回到深圳快一年多了，从经济危机的谷底到现在的经济回升，我看到了软件测试行业一些微妙的变化。我在现在的公司任测试经理，去年回来的时候，参加各种招聘会，测试的职位寥寥无几，为了组建一个10人的测试团队，我面试过不下100个应聘者，来组建自已的团队，那时候招人是多么容易啊，因为人比较容易招到，大家对待遇的要求也不高，可能是因为经济危机的原因吧，很多公司都从测试下手，裁员，我也感受到在中国软件测...

深圳测试协会第九次论坛在深圳举行

2009-11-03T01:31:00Z

10月18日，深圳测试协会第九次论坛在深圳如期举行。来自深圳大展科技的Edward.zhong与我们分享了《QTP自动化框架的搭建》的PPT和一些实践经验，随后，Mike.Yang与大家分享了阿里妈妈的一些测试经验，这次论坛吸引了来自ORACLE,UT，腾讯，华为等知名企业的测试人员参与，取得了不错的效果。

博客园_杨学明(值得信赖的研发管理专家,软件测试专家)

软件测试管理公开课 讲师 杨学明 2011-11-25~26 地点:北京

研发副总裁、研发总监、项目总监、研发经理、测试经理、软件测试人员、软件开发人员、项目经理、质量保证人员等

课程大纲 1. 软件测试概述

本章节学习目标：针对两天的课程，进行课程回顾，总结学习成果。 8.1. 研讨：根据我公司现状，如何推进软件测试管理体系？

研发项目管理内训在南京成功举办

2011年9月23《软件测试管理》公开课，接受报名！

软件测试为什么失败?

敏捷开发模式下的质量管理

浅谈IPD模式下的敏捷软件项目管理

任正非:管理的灰度

讨论：研发团队中最合适的开发测试比是多少？

我看软件测试的现状和未来

深圳测试协会第九次论坛在深圳举行

软件测试管理公开课讲师杨学明 2011-11-25~26 地点:北京

课程大纲

1. 软件测试概述

本章节学习目标：针对两天的课程，进行课程回顾，总结学习成果。

8.1. 研讨：根据我公司现状，如何推进软件测试管理体系？