讲师 ：林曙湧 现任诺基亚西门子公司自动化测试教练，曾任UTStarcom杭州研发中心的测试组长和自动化测试组长，在测试和自动化测试领域已经有10多年的工作经验。目前工作在敏捷转型中的组织，游走于开发和测试的边缘，常常面临敏捷软件过程和传统软件方法的冲击，对于研究测试人员技能如何能不断提高很有兴趣。对于创新的测试技术和敏捷测试都有极大的热情，专注于解决测试和自动化测试中的问题，坚信总有更好的方法解决问题。 信念：测试完全可以比我们大多数人意识到的，或者已经做到的更加有趣和富有创造性。回首推广自动化测试的道路，感觉走得如此艰难，但又有几许收获。也曾经迷惘，彷徨，但从未放弃，一直坚持，如今仍在测试和自动化测试的道路上不断探索前进。相信明天会更好。 话题介绍： 在实际资源受限的环境下，特别对于电信领域的大型设备，设备非常昂贵且有限，但是对于产品的可靠性要求很高。 如何真正地做到每日构建都能被充分测试到，是一个比较困难但是又必须要面对的 问题。本次演讲专注于如何采用一些新的测试理念，结合一些新的测试技术，比如测试思维导图，测试用例的建模，全配对测试，动态的自动化测试技术等达到持续集成中测试覆盖率和反馈周期之间平衡。通过本次演讲，听众可以得到经验的分享，结合自己的工作领域得到一些体会，并可以讨论如何在自己的工作领域应用这些技术。 对于独立的测试团队，应用这些技术也可以带来效率上的极大提高。

1. 通过测试卓越来推动
电信领域持续集成
诺基亚西门子WCDMA 无线网络平台
自动化测试教练林曙湧

2. 分享要点
 持续集成碰到的困境
 我们的破冰之旅
 从思维方式的转变开始
 实践经验分享及相关思考点
 方案回顾

3. 持续集成的困境

4. 我们的产品
 3G 核心网软件平台
 超过1200万行的代码维护量
 电信级的软件质量要求，面向全球上
百个运营商进行发布
 系统启动领域的代码和板子硬件类型
和逻辑类型绑定的很紧，所以很必要
测试每种可能的情况

5. 研发背景介绍
 我们已经运行Scrum模式了，但仍然是Component
Team为主
 自动化测试用例的比例大约达到70%多
 需要逐渐转到下一代开发平台，在投入减少的情况
又保证老平台的质量
 持续集成被认可为非常有效的手段来控制风险

6. 持续集成在自动化测试环节上的困难
 为了达到高质量的要求，测试人员需要考虑所有用
户可能的使用场景
 各个团队基于自己模块的特点选取了很多场景做测
试，但很多场景是重复的
 自动化比例较高，但测试步骤重复的很多，测试执
行时间很长
 很多测试的执行时间受限于硬件和系统本身的性能，
已经无法优化，
 自动化测试用例数量很多（10000+）
 测试用例维护和执行成本很高
 测试需要的真实设备，非常有限和昂贵

7. 系统启动领域典型例子介绍

8. 计算一共多少可能的组合
12*4*5*2*3 ==1440
在每个小的迭代我们真的可能执
行所有的用例吗?

9.  硬件资源有限
 人力资源有限
 需要时间做探索性测试
 需要休息
 需要考虑投资回报率
…
 回答是 否!
 但如何保证 测试覆盖率呢?

10. 破冰之旅

11. 如果产品还有Bug的话，你会交
付吗？

12. 基于风险的测试的相关理念
20%的功能可以让用户做80%
的事情
不管你在测试上投资多少，总
是会遗留风险
为了最大化降低风险，我们在
测试上的最小投入该是多少？

13. 测试对于风险的控制曲线
测试的频率 vs. 测试的覆盖率
及时的测试比全面的测试能带来
更高的回报

14. 回到我们的最初持续集成的目的
 作为一个电信设备供应商,
 当需要把人力资源转换到下一代平台的开发的时候
 我希望
能够有效地利用昂贵的设备投资
持续执行高效的测试用例
来控制老平台的软件因为代码改动被破坏掉的
风险

15. 对于
风险 基于风险
持续集成 的控
制
的测试

16. 如何更快的
测试，同时又
保证一定的覆
盖率？

17. 业界研究
 1997 年Telcordia科技研究表明，假如一个软件
系统由N构件组成(或者说由N个因素决定)，大
部分的软件错误是由一个构件的错误所导致，
或者由 2 个构件之间的交互错误导致
 基于这个理论，构造测试用例就需要涵盖每个
因素的所有状态，并且涵盖每 2 个因素之间的
所 有 交 互 ，这 种 测 试 理 论叫 作Pair-wise
测 试。因此 ， 没有必要构造覆盖所有因素的
所有组合的测试用例集合。只需要构造覆盖每
个因素的所有状态，覆盖任意 2 个因素所有状
态的测试用例集合.

18. 内在逻辑
 最简单的问题往往可以由一个输入因子触发
 次简单的问题往往可以有两个输入因子触发
 必须三个或者三个以上的输入因子触发的问题往往
比较少，要想全部抓住他们往往也很贵
 全配对测试技术可以起作用的就是在第一和第二个
领域，在产品质量和成本之间达到一个最佳的平衡
 全配对的测试技术产生的测试用例可以覆盖所有因
子的两两组合，并且总的用例数目远远小于穷举的
组合，并且在发现问题上面仍然非常有效

19. 例子 I
 A寝室有3个人，B寝室有2个人，C寝室有4个人，假设每
次从各寝室抽取一个人，召开茶话会，增进了解，这样
的茶话会要召开多少次才能让所有的人都互相认识？
 3×2×4 = 24？- NO
24 VS 12

20. 例子 2
 A寝室有4个人，B寝室有5个人，C寝室有6个人，D寝室
3个人假设每次从各寝室抽取一个人，召开茶话会，增进
了解，这样的茶话会要召开多久才能让所有的人都互相
认识？
 4×5×6 ×3= 360 ？- NO
360 30

21. 全组合测试用例 vs. 全配对的测试用例

22. 实践经验分享
 测试设计思维导图
 抓住重点，建立全景图
 创建基本测试用例
 利用 PairWise 等算法生成测试数据
 自动化的用例生成
 部署于持续集成环境
 回顾和反思

23. 测试设计思维导图
创建基本测 补充测试数 高级测
创建测试模型
试用例 据 试
From <<Essential Test Design by>> by
TORBJÖRN RYBER HAS

24. 原有的测试用例

25. 如何从现有测试用例提炼测试模型
 抓住重点，建立全景图
 合适的抽象层面来建立测试的模型
 解决我们到底要测什么的问题（What）
 抽象抽象再抽象！！！
 归纳归纳再归纳！！！
 如何保证测试重构的覆盖率
 假设我们重新开始设计测试用例的话
 测试思维导图工具的运用（Xmind)
 解决到底从哪些角度来测试的问题

26. 从比较高的层次来概括测试需求
需求领域: 系统与板子的启动
 核心需求的描述
考虑到电信领域软件高可靠性的要求，
所有可能的板子
在各种可能的环境下
比如不同的硬件平台
不同的上层应用比如基站控制器或者媒体网关，
在各种可能的状态
以各种可能的模式的重启
都必须获得成功，并遵循一定的时间约束。

27. 测试设计思维导图

28. 创建基本测试用例
 对正常的单板重启抽象出统一的测试过程，并涵盖
各模块测试点
 以领域语言描述业务检查点

29. 补充测试数据
 没有约束的话会
产生非法组合
 加上约束条件来
过滤非法组合
 产生测试用例的
不同方法
• 全组合
• 随机
• 全配对

30. 自动化的用例生成
 直接创建可读可执行的自动化用例
 测试用例的数据和测试环境自适应
 每次插入随机因子生成不同的组合
 实例演示

31. 如何部署于持续集成环境
自动
自动 测试
部署 动态和静态
自动 的自动化用
例
编译
31

32. 持续集成的部署策略

33. 测试技术回顾
基于风险
测试思维
的测试思
导图
想
全配对测 动态的自
试数据生 动化测试
成 用例生成

34. 经验回顾
 测试模型和测试数据的分离
 以频繁的测试来弥补每次测试覆盖率的不足
 测试领域知识的集中存放
 不同的风险对应不同的测试覆盖率
 探索性的自动化测试

35. Q&A
@林曙湧
http://www.cnblogs.com/blue_energy/

36. 对测试卓越的理解
 1: Demand Technical Excellence
 2: Promote Individual Change and Lead Organizational Change
 3: Organize Knowledge and Improve Education
 4: Maximize Value Creation Across the Entire Process
编程
技术 卓越
卓越
测试
卓越