在敏捷组织里实施

自动化测试的问题及解决之道

林曙湧

诺基亚西门子自动化测试教练

背景介绍

• 移动通信核心网软件平台

• >1200万行的代码

• 2007年转型Scrum

• 10000+的自动化用例

• 平均每天执行5000左右

• 每日编包

• 每周向内部客户发布一次

常见的一些困惑

• 自动化测试太难了,我们太忙了

• 看不懂的自动化测试用例

• 维护自动化测试的成本太高

• 自动化测试做好了，下一步呢？

•自动化测试太难了,

我们太忙了

自动化测试太难了

• 测试人员缺乏编程技能

• 开发人员对测试缺乏兴趣

• 自动化团队缺乏领域知识的深入了解

• 产品可测性缺乏

• 接口经常改变

• ……

我们太忙了

• 对，我们真的很忙

• 忙着做重复低效的事情？

• 可是没有自动化测试，如何实施敏捷和CI呢？

改变是如何发生的？

• 测试部门和开发部门的融合

• 自动化测试的持续投入

• CI的优先级很高

• 专人来支持自动化测试

管理层的有力支持

团队协作的自动化实施策略

• 团队共同来计划自动化测试的任务

• 开发人员提供编程或者可测性支持

• 开发人员来写自动化测试用例

看不懂的自动化测试用例

自动化测试脚本

以下的脚本问题在哪里？

自动化测试脚本

以下的呢？

• 关键字驱动的自动化测试框架 • Robot Framework

伪关键字驱动自动化测试

引入外部Coach

好的测试用例的标准

测试用例的评审机制

重视测试用例的可读性

改变从新的测试用例开始

投资时间来做老的测试代码的重构

描述业务逻辑而不是测试实现

维护自动化测试的成本太高

原因分析

• 复杂的自动化测试

• 没有在持续集成中频繁的验证

• 问题会堆积

• 测试用例数目爆炸式增长

复杂的自动化测试

• 难以复现的问题

• 真的是软件问题吗？

有些复杂性是固有的

• 控制端到端的用例数量

• 分层自动化测试

• 测试用例实现变与不变的分离

实现造成的复杂性

• 功能视角 vs. 模块视角

• 自动化测试的架构

• 可重用的Keyword

持续集成的频繁验证

加大回归测试的频率，悖论？

用进废退？

独立的测试环境

不要去掉失败的测试

在增加新用例之前先修复失败用例

投资于健壮的自动化测试

直面和解决问题

测试用例数目爆炸式增长

板子启动测试用例设计

各种类型的板子，假设

12种

各种板子状态，4种

各种网元类型，

2种

各种系统硬件类型，3种

各种重启模式，4种

PairWise Testing

自动化的生成用例

• 测试模型的建立

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

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

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

如果你只关心覆盖率的话…

自动化测试做好了，下一步呢？

• Sleep? Are you kidding?

• 重构你的测试用例

• 优化测试库

• 内建可测性

• 并行执行

高效测试执行

Lean Follow up Style

• 尽可能多地自动化重复工作

• 减少结果分析的时间

• 省到就是赚到

• 结果的可见性

追求测试卓越

• 前沿的测试技术

– 基于模型的测试

– 探索性的测试自动化

Q&A

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