文档分享了一个基于风险的项目管理案例，探讨了如何在七天内有效地管理和测试软件项目。通过快速迭代和风险分析，团队能够识别和应对潜在风险，确保项目的成功交付。强调了在敏捷开发中，风险评估和团队协作的重要性。

1. 七天基于 测试
一个基于风险的项目/测试管理案例分享
@柴阿峰
测试者
at
Testart
策艺

2. 关于我和这个PPT
• 关于我自己
– @柴阿峰
– Chaiafeng@163.com
• 关于PPT
– 是基于我2008年的一个项目案例

3. 感谢大家冒着被台风吹跑的 来听报告

4. 什么是 ?!
• 定义
– Risk
=
Damage*Probability
– Damage就是会给相关方带来的（经济、时间、
声誉、精神）损失
– Probability就是这个损失可能发生的概率
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

5. 什么是基于 的测试?
• 难道测试的目的，天生不就是为了降低软
件出现问题的风险吗？
• 这是一个关于“资源饥饿感”和“在正确
的时间做正确的事”的故事；
• 基于风险的测试，就是用风险分析的方法
来指导测试计划、设计、执行的方法论；
• 一种战略战术。
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

6. 执行基于 测试的难点
• 掌控风险
• 积累风险
• 追踪风险
• 控制成本
在案例中，我如何应对这些问题？
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

7. 为什么只有七天？
• 从一本书<Manage
your
Cme
in
7
days>得到
的灵感
• 想象一下我们需要用七天时间来完成一个
项目.
– 1
天时间应对需求.
– 1
天时间进行设计.
– 4
天时间进行迭代开发和测试.
– 1
天时间进行系统测试.
– 我们可以把这个模式看做是一个“半敏捷开发”
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

8. 什么是半敏捷开发？
• 由于项目组常年合作，所以可以使用一些敏捷开发
理念：
– 快速建立软件模型
– 缩短开发迭代周期，持续集成和交付
– 快速的变更响应
– 开发测试紧密配合
– 较好的客户参与
• 同时由于项目自身的特点，我们放弃了一些敏捷模
式中的理念：
– 不使用自动化测试
– 仍然使用独立测试组
– 需求和设计仍依赖于（测试人员维护）文档
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

9. 在某些合作时间长的团队中，敏捷是自然形成的。

10. 项目介绍
• 一个基于Web-­‐GIS的企业应用
• 系统包含移动终端、服务器、PC终端
• 与多个已有业务系统存在接口
• 十人研发团队，核心人员配合默契
• 项目经理是测试经理出身，有开发背景
• 客户是一家金融机构
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

11. 7天流程
接口/集成
性能测试
测试
需求 设计 迭代开发 迭代测试 系统测试
Day 1 Day 2 Day 3 Day 4 Day 7
Day 5 Day 6
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

12. 中小型团队如何快速获得团队的风险清单?
• 风险是分析得来的，更是积累来的
• 依赖于核心人员经验
• 通过简单表格和快速会议进行风险分析
– 常见风险表
– 测试应对表
– 风险经验清单
– 风险分析表
• 控制风险数量
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

13. 如何快速的管理你的 ?
• 关注风险中最重要的几个相关点:
– 风险是什么？
– 风险的等级？
– 在哪个阶段风险会发生？
– 如何做？
– 谁来对风险应对负责？
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

14. 管理的目的是什么?
• 风险管理的最终目的是不再有风险；
• 基于风险测试的目的是建立对高风险目标
的质量信心；
• 建立“风险”-­‐“需求”-­‐“用例”-­‐“缺陷”的追溯关
系；
• 间接可以达到优化配置和节省资源的效
果；
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

15. 团队的常见 清单版本0.1
• 我们有一个项目组常见风险清单
• 我们在这个清单中列出了在项目不同阶段
我们可能会遇到的风险
• 这张清单实际上包含了我们公认的“高可
能性高危害”和“低可能性高危害”风险
• 在项目的不同阶段，我们会依据这个清单
和项目情况再制作一个实际的风险清单
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

16. 团队的常见 清单版本0.1
• 复杂的新功能
• 新手开发的功能
• 算法工程师梁X的代码的性能问题
• 高时间压力下开发的模块
• 需求分析不足的模块
• 上一版本有大量bug的模块
• 使用了新技术和工具开发的模块
• 由于各种因素未使用质量保证的开发成果
• 过于复杂的UI
…以及其他项目组公认的风险，但一般不超过10条
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

17. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Day
1,
项目合同已经签订，首付款来了。项目组
士气高涨，所有人都在期待一个成功的项目。
• 但是，在这个阶段，许多风险就开始显现。
• 第一次风险评审会开始。
• 技术负责人，核心开发，核心测试，客户或者客
户代表参加。
…在会议以后，我们拥有了这个阶段的风险分析表
格。
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

18. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
RR RS ID IT AT Integrate Load
复杂的功能 √ √
复杂的新功能 √ √
频繁调整的功能 √ √
使用了新工具和环境 √ √
开发者变更的模块 √ √ √
时间压力下完成模块 √ √ √ √
曾有大量缺陷的模块 √ √ √
复杂的用户界面 √ √
开发者经验不足 √
需求不充分 √ √ √ √
沟通不足 √ √ √
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

19. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
风险 明细 解决 负责人 级别
任务发起的流程复杂 简化任务 HuangXM Mid
复杂的功能
建demo，针对性
图上考核功能复杂 LiuRY Mid
测试
管理部门A的业务需求不清楚 Beta测试提前 ChaiAF High
需求不充分
远程接口调用B的技术细节不清晰 B的接口测试提前 ChaiAF High
延长TMS相关功
TMS的技术支持在1000公里外 ChaiAF Low
能的测试周期
沟通不足
功能模块C的开发者是一个兼职程序 延长C的测试周期
LiuRY Low
员
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

20. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Tips：
• 这个阶段团队士气高涨，是开各种会议召集人手最容
易的时候；
• 这个阶段的大部分风险都和需求有关，而在这个阶段
与客户的每一次沟通都很重要，应该做记录，必要的
时候可以做确认；
• 对于小团队来说，关键风险的确认，只需要有一两个
核心人员的意见就足够了；
• 对于测试，暂时放弃
vs
提前进行
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

21. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Day
2,
我们有了不少文档。技术负责人开始考虑
架构上的细节。
• 第二次风险分析会议举行。
• 技术负责人，核心开发，核心测试参会。
…在风险分析会议后，我们有了如下表格。
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

22. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
RR RS ID IT AT Integrate Load
复杂的功能 √ √ √
复杂的新功能 √ √
频繁调整的功能 √ √
使用了新工具和环境 √ √
开发者变更的模块 √ √ √
时间压力下完成模块 √ √ √ √
曾有大量缺陷的模块 √ √ √
复杂的用户界面 √ √
开发者经验不足 √
需求不充分 √ √ √ √
沟通不足 √ √ √
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

23. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
RISK DETAIL SOLUTION RP DL
需求不充分 管理部门A的业务需求不清楚 原型测试 ChaiAF Mid
从YouSql向Pracle过渡 数据集成测试 ChaiAF High
更换地图引擎GisAPI 2.0 引擎测试 ChaiAF High
使用了新的工具和环境
Timcat更新至版本6 Env集成测试 ChaiAF Low
CVN向SVS过渡 Env集成测试 LiuRY Low
UI测试
复杂的用户界面 任务管理界面元素过多 WangJX Mid
客户确认
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

24. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Tips：
– 对于任何从上个阶段被遗留下来的风险要特别注意，
提高警惕，做出更好的应对；
– 任何需求的风险在设计阶段以后都可能会被隐藏很
久，直到最终验收时才被发现；
– 过于复杂的实现很可能意味着需求理解或者技术实现
上有问题；
– 虽然有点早，但是培养一两个来自客户的核心用户很
重要，现在是建立感情的好机会。
– 简化用例
vs
精细用例
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

25. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Day
3,
团队经历了困难的时间，我们有了第一个
原型，新手已经没有开始时那么生涩了，他们已
经可以正常的完成功能，提交代码。
• 我们召开了第三次风险分析会议
• 技术负责人，核心开发，核心测试，客户代表参
加。
…会议后，我们拥有了如下表格。
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

26. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
RR RS ID IT AT Integrate Load
复杂的功能 √ √ √
复杂的新功能 √
频繁调整的功能 √
使用了新工具和环境 √ √
开发者变更的模块 √ √
时间压力下完成模块 √ √ √
曾有大量缺陷的模块 √ √ √
复杂的用户界面 √ √
开发者经验不足 √
需求不充分 √ √ √ √
沟通不足 √ √ √
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

27. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Tips：
– 核心开发人员可能忙于完成复杂的代码而不愿意参加
会议，此时必要的激励措施可以帮助召集会议；
– 试着从客户的“核心用户”那里获得一些情报；
– 对于还在带来风险的新手，考虑是否暂停工作，提供
一些培训；
– 考虑技术选择的最后机会，现在还可以选择放弃那些
不成熟的工具、平台；
– 核心测试
vs
新手测试
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

28. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• 测试团队迎来show
Cme，我们需要对版本0.1进行
第一次测试；
• 第四次风险分析会议在这天举行；
• 技术负责人，核心开发，核心测试参会；
…会后我们有了如下的风险分析表格。
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

29. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
RR RS ID IT AT Integrate Load
复杂的功能 √ √ √
复杂的新功能
频繁调整的功能
使用了新工具和环境 √ √ √
开发者变更的模块 √
时间压力下完成模块 √ √ √
曾有大量缺陷的模块 √
复杂的用户界面 √ √ √
开发者经验不足 √ √
需求不充分 √ √ √ √ √
沟通不足 √ √ √
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

30. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• 基于风险的测试管理将在这一天被完整的实施，
所以这一天很重要。
– 最好的测试人员去测试那些高风险的复杂模块；
– 由于业务和需求的风险依然存在，我们暂时不考虑UI的
测试；
– 对所有使用新工具和引擎开发的模块施加更多的关注，
对应的用例应该足够详细；
– 第一次交付时间前一个小时内完成的功能应该着重测
试；
– 在早期阶段就可以做性能测试，而且效果很好。
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

31. 那么 和测试关系是什么？
• 首先，风险是项目级别的而非测试级别的；
• 风险分析的结果可以为测试管理提供辅助：
– 暂时放弃
vs
提前进行
– 简化用例
vs
精细用例
– 核心测试
vs
新手测试
– 暂缓修改
vs
立刻修改
– 继续使用
vs
选择放弃
– 测试资源类风险的应对
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

32. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Day
5,
疲惫的团队。有人离开去了别的项目组，
核心开发开始兼职做别的项目，好消息是新人们
终于成长了起来。
• 我们有了第五次风险分析会议。
…会后获得了风险分析表格：
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

33. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
RR RS ID IT AT Integrate Load
复杂的功能 √ √ √
复杂的新功能 √ √
频繁调整的功能 √ √
使用了新工具和环境 √
开发者变更的模块 √ √ √
时间压力下完成模块 √ √ √ √
曾有大量缺陷的模块 √ √ √
复杂的用户界面 √ √
开发者经验不足
需求不充分 √ √ √ √
沟通不足 √ √ √
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

34. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
RISK DETAIL SOLUTION RP DL
提高功能A测试优先
复杂的新功能 客户提出需要绩效报表A WangJX Mid
级直至其稳定
由于需求有误，开发经验不足，功能 需 求 探 求 ， 提 高 测
频繁调整的功能 ChaiAF High
B已经修改了多次 试优先级
高级测试人员辅助
原来的SD已经离开，其负责部分转移
开发者变更的模块 新SD理解功能，针 LiuRY Mid
至新的SD。
对性测试直至稳定
时间压力下完成模块 应对功能清单中的时间压力进行分析 压力大的优先测试 ChenJW High
项 目 经 理 分 析 原 因，HuangXM
曾出现过大量Bug的模块 绩效报表B的数据一直不准确 High
高级测试人员应对 ChaiAF
专人负责测试至稳
复杂的用户界面 任务处理界面复杂 DongMM Low
定
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

35. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Tips：
– 最艰难的时期。
– 技术负责人和测试负责人开始花费很多时间在bug跟踪
系统上。
– 开始出现修复成本过高而无法被修正的bug。
– 开始试图平衡开发与测试。
– 测试人员开始提供越来越多关于项目的反馈信息。
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

36. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Day
6,
最后进行大范围接口和系统测试的时机；
• 此时的风险会议，测试人员开始提供大量信息；
• 接口和集成测试的风险几乎肯定出现；
• 时间压力导致的风险在这个阶段无处不在；
• 毫无疑问我们会发现被忽略的已经出现的风险：
– 以为很成熟但实际不成熟的第三方软件系统
– 经常被忽略的硬件问题
– 希望远方的接口正常，但是他们一定会出错
– 有些风险我们还可以堪堪应对，有些则只能作为教训，
在下个版本时再考虑了！
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

37. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
RR RS ID IT AT Integrate Load
复杂的功能 √ √ √
复杂的新功能 √ √
频繁调整的功能 √ √
使用了新工具和环境 √
开发者变更的模块 √ √ √
时间压力下完成模块 √ √ √ √
曾有大量缺陷的模块 √ √ √
复杂的用户界面 √ √
开发者经验不足
需求不充分 √ √ √ √
沟通不足 √ √ √
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

38. Review
of
Review
of
IteraCon
IteraCon
Test Acceptance
Requirement SpecificaCon Develop
• Day
7.
经过了长期的痛苦的开发，项目已经接近于完成。
• 此时的项目风险发生了许多改变：
– 首先，许多最终客户交付失败是由非功能性缺陷引起的，而我们
的技术人员时常最关注的是功能是否正常；
– 如果有核心用户可以在最终交付之前使用和反馈信息，可以大幅
度提高项目成功可能性；
– 在项目的后期，大量小范围改动可能带来的配置管理风险开始显
现；
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

39. 为什么把接口和性能测试单独提出来？
接口/集成
性能测试
测试
需求 设计 迭代开发 迭代测试 系统测试
Day
1 Day
2 Day
3 Day
4 Day
7
Day
5 Day
6
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

40. 我们何时可以做接口和性能测试？
• Tips:
– 虽然接口测试在ISTQB中被作为一个单独的级别，但是现实项目中，
由于条件限制，我们的接口测试可能是贯穿始终的：
• 需要等待对方配合的，有时只能何时对方准备好了何时测；
• 需要等待己方模块开发的，有时只能何时准备好了何时测；
• 总之，由于条件的限制，很难把接口作为单独的级别来做测试；
– 同样的，性能测试也应该贯穿始终：
• 如果是架构和项目组代码规范造成的性能缺陷，第三天，甚至第二天就该进行
性能测试；
• 在验收阶段的性能测试只能作为客户验收的参考，实际的调整大多已经来不
及；
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

41. 关于七天风险管理模型
• 对于中小团队，我们应该简化风险管理模型，降低准入门槛：
– 可以使用Excel而不用专业工具
– 简化模型，减少公式的运用
– 对于很难量化的指标，例如发生概率等，要进行简化
– 更多依赖团队核心成员的能力和经验
– 长期配合的研发团队应该有自己的风险清单并定期维护
• 但是我们仍然使用了大量的风险管理知识：
– 风险管理是项目管理的核心内容之一，指导整个项目
– 风险的识别应该有依据，有讨论，有记录
– 风险的应对要落实到人并持续跟踪
– 不同项目阶段、项目背景面临的风险不同
– 要使用风险分析结果指导测试
– 风险分析是动态的，在不同阶段要具体情况具体分析
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

42. 个人关于风险管理的最佳/最差实践
• 风险，总有些是你想所未想，闻所未闻——所以经验和积累很重要：
– 我们没有想到看似成熟的智能机平台不足以支撑应用；
– 我们没有想到电量会成为易用性上的最大问题；
– 我们没有把高楼对于GPS信号的遮蔽考虑的足够清楚；
– 但是，只要有了第一次的经验，以后我们一定可以考虑到。
• 风险，是一种模型，更是一种理念：
– 风险分析会议、文档做的再简化，一样要消耗成本，但是它可以节省更多；
– 风险理念应该可以作为项目管理、测试管理的基石，尤其是对于企业类产品；
– 风险管理没有唯一模型，合适的就是好的。
• 测试组对于风险的作用：
– 测试组几乎是唯一全程逆向考虑风险因素的团队；
– 越到项目后期，测试组的风险意见越有价值；
– 测试组自身也有风险，要注意和项目风险的平衡和融合，这考验项目经理的能力。
Manage
Your
Risk
in
7
Days
@2012
Bill
Chai

43. Manage
Your
Risk
in
7
Days
@2012
Bill
Chai