Más contenido relacionado Scrum Gathering 2012 Shanghai_敏捷测试与质量管理分会场演讲话题:通过测试卓越来推动电信领域持续集成(林曙湧)4. 我们的产品
3G 核心网软件平台
超过1200万行的代码维护量
电信级的软件质量要求,面向全球上
百个运营商进行发布
系统启动领域的代码和板子硬件类型
和逻辑类型绑定的很紧,所以很必要
测试每种可能的情况
6. 持续集成在自动化测试环节上的困难
为了达到高质量的要求,测试人员需要考虑所有用
户可能的使用场景
各个团队基于自己模块的特点选取了很多场景做测
试,但很多场景是重复的
自动化比例较高,但测试步骤重复的很多,测试执
行时间很长
很多测试的执行时间受限于硬件和系统本身的性能,
已经无法优化,
自动化测试用例数量很多(10000+)
测试用例维护和执行成本很高
测试需要的真实设备,非常有限和昂贵
12. 基于风险的测试的相关理念
20%的功能可以让用户做80%
的事情
不管你在测试上投资多少,总
是会遗留风险
为了最大化降低风险,我们在
测试上的最小投入该是多少?
15. 对于
风险 基于风险
持续集成 的控
制
的测试
17. 业界研究
1997 年Telcordia科技研究表明,假如一个软件
系统由N构件组成(或者说由N个因素决定),大
部分的软件错误是由一个构件的错误所导致,
或者由 2 个构件之间的交互错误导致
基于这个理论,构造测试用例就需要涵盖每个
因素的所有状态,并且涵盖每 2 个因素之间的
所 有 交 互 ,这 种 测 试 理 论叫 作Pair-wise
测 试。因此 , 没有必要构造覆盖所有因素的
所有组合的测试用例集合。只需要构造覆盖每
个因素的所有状态,覆盖任意 2 个因素所有状
态的测试用例集合.
23. 测试设计思维导图
创建基本测 补充测试数 高级测
创建测试模型
试用例 据 试
From <<Essential Test Design by>> by
TORBJÖRN RYBER HAS
25. 如何从现有测试用例提炼测试模型
抓住重点,建立全景图
合适的抽象层面来建立测试的模型
解决我们到底要测什么的问题(What)
抽象抽象再抽象!!!
归纳归纳再归纳!!!
如何保证测试重构的覆盖率
假设我们重新开始设计测试用例的话
测试思维导图工具的运用(Xmind)
解决到底从哪些角度来测试的问题
33. 测试技术回顾
基于风险
测试思维
的测试思
导图
想
全配对测 动态的自
试数据生 动化测试
成 用例生成
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
编程
技术 卓越
卓越
测试
卓越