通过测试卓越来推动

电信领域持续集成

诺基亚西门子WCDMA 无线网络平台

自动化测试教练林曙湧

分享要点 持续集成碰到的困境

我们的破冰之旅

从思维方式的转变开始

实践经验分享及相关思考点

方案回顾

持续集成的困境

我们的产品 3G 核心网软件平台

超过1200万行的代码维护量

电信级的软件质量要求，面向全球上百个运营商进行发布

系统启动领域的代码和板子硬件类型和逻辑类型绑定的很紧，所以很必要测试每种可能的情况

研发背景介绍 我们已经运行Scrum模式了，但仍然是Component

Team为主

自动化测试用例的比例大约达到70%多

需要逐渐转到下一代开发平台，在投入减少的情况又保证老平台的质量

持续集成被认可为非常有效的手段来控制风险

持续集成在自动化测试环节上的困难 为了达到高质量的要求，测试人员需要考虑所有用户可能的使用场景

各个团队基于自己模块的特点选取了很多场景做测试，但很多场景是重复的

自动化比例较高，但测试步骤重复的很多，测试执行时间很长

很多测试的执行时间受限于硬件和系统本身的性能，已经无法优化，

自动化测试用例数量很多（10000+）

测试用例维护和执行成本很高

测试需要的真实设备，非常有限和昂贵

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

计算一共多少可能的组合

12*4*5*2*3 ==1440

在每个小的迭代我们真的可能执

行所有的用例吗?

硬件资源有限

人力资源有限

需要时间做探索性测试

需要休息

需要考虑投资回报率

…

回答是否!

但如何保证测试覆盖率呢?

破冰之旅

如果产品还有Bug的话，你会交

付吗？

基于风险的测试的相关理念

20%的功能可以让用户做80%的事情

不管你在测试上投资多少，总是会遗留风险

为了最大化降低风险，我们在测试上的最小投入该是多少？

测试对于风险的控制曲线

测试的频率 vs. 测试的覆盖率

及时的测试比全面的测试能带来更高的回报

回到我们的最初持续集成的目的 作为一个电信设备供应商,

当需要把人力资源转换到下一代平台的开发的时候

我希望

能够有效地利用昂贵的设备投资

持续执行高效的测试用例

来控制老平台的软件因为代码改动被破坏掉的

风险

持续集成 基于风险的测试

对于风险的控制

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

业界研究

1997 年Telcordia科技研究表明，假如一个软件系统由N构件组成(或者说由N个因素决定)，大部分的软件错误是由一个构件的错误所导致，或者由 2 个构件之间的交互错误导致

基于这个理论，构造测试用例就需要涵盖每个因素的所有状态，并且涵盖每 2 个因素之间的 所 有 交 互 ，这 种 测 试 理 论叫 作Pair-wise测 试。因此 ， 没有必要构造覆盖所有因素的所有组合的测试用例集合。只需要构造覆盖每个因素的所有状态，覆盖任意 2 个因素所有状态的测试用例集合.

内在逻辑

最简单的问题往往可以由一个输入因子触发

次简单的问题往往可以有两个输入因子触发

必须三个或者三个以上的输入因子触发的问题往往比较少，要想全部抓住他们往往也很贵

全配对测试技术可以起作用的就是在第一和第二个领域，在产品质量和成本之间达到一个最佳的平衡

全配对的测试技术产生的测试用例可以覆盖所有因子的两两组合，并且总的用例数目远远小于穷举的组合，并且在发现问题上面仍然非常有效

例子 I

A寝室有3个人，B寝室有2个人，C寝室有4个人，假设每次从各寝室抽取一个人，召开茶话会，增进了解，这样的茶话会要召开多少次才能让所有的人都互相认识？

3×2×4 = 24？- NO

24 VS 12

例子 2

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

4×5×6 ×3= 360 ？- NO

360 30

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

实践经验分享 测试设计思维导图

抓住重点，建立全景图

创建基本测试用例

利用 PairWise 等算法生成测试数据

自动化的用例生成

部署于持续集成环境

回顾和反思

测试设计思维导图

创建测试模型 创建基本测试用例

补充测试数据

高级测试

From <<Essential Test Design by>> by

TORBJÖRN RYBER HAS

原有的测试用例

如何从现有测试用例提炼测试模型

抓住重点，建立全景图

合适的抽象层面来建立测试的模型

解决我们到底要测什么的问题（What）

抽象抽象再抽象！！！

归纳归纳再归纳！！！

如何保证测试重构的覆盖率 假设我们重新开始设计测试用例的话

测试思维导图工具的运用（Xmind)

解决到底从哪些角度来测试的问题

从比较高的层次来概括测试需求

需求领域: 系统与板子的启动

核心需求的描述

考虑到电信领域软件高可靠性的要求，

所有可能的板子

在各种可能的环境下

比如不同的硬件平台

不同的上层应用比如基站控制器或者媒体网关，

在各种可能的状态

以各种可能的模式的重启

都必须获得成功，并遵循一定的时间约束。

测试设计思维导图

创建基本测试用例

对正常的单板重启抽象出统一的测试过程，并涵盖各模块测试点

以领域语言描述业务检查点

补充测试数据

没有约束的话会产生非法组合

加上约束条件来过滤非法组合

产生测试用例的不同方法

• 全组合

• 随机

• 全配对

自动化的用例生成 直接创建可读可执行的自动化用例

测试用例的数据和测试环境自适应

每次插入随机因子生成不同的组合

实例演示

如何部署于持续集成环境

31

自动编译

自动部署

自动测试

动态和静态的自动化用例

持续集成的部署策略

测试技术回顾

基于风险的测试思

想

测试思维导图

全配对测试数据生

成

动态的自动化测试用例生成

经验回顾

测试模型和测试数据的分离

以频繁的测试来弥补每次测试覆盖率的不足

测试领域知识的集中存放

不同的风险对应不同的测试覆盖率

探索性的自动化测试

Q&A

@林曙湧 http://www.cnblogs.com/blue_energy/

对测试卓越的理解 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

编程卓越

测试卓越

技术卓越