狠狠撸

2012 中国首届软件测试大会

2012-08-06 上海

测试界的共识

? Driven Quality Upstream

分享内容大纲

? 敏捷精要：分层质量保证 ( 吴穹 )
? ATTD - Acceptance Test Driven Development
( 吴穹 )
? RBT – Requirement Based Testing （ IBM
Richard Bender ）
? MBT - Module Based Testing （华为）
? 敏捷测试实践（微软 Bill Liu ）
? 测试看开发，开发看测试（ Google 段念）

敏捷精要：分层质量保证

? 质量是开发人员的神圣责任，而不仅仅是测试人
员的责任
– The burden of quality is on the shoulders of those
writing the code. Quality is never “some tester’s”
problem.

? 只有将开发和测试完全地混合在一起，不分彼此
，才能够真正获得好的质量
– Quality is achieved by putting development and
testing into a blender and mixing them until one is
indistinguishable from the other.

分层质量保证的基本思想
? 为什么要分层质量保证？
– 分层才能保证快速反馈，而不是都等到最后才反馈
– 恰当的分层测试可以降低总测试成本

风险 1 风险 2 风险 3 风险 4

开发测试

集成测试

验收测试

5

开发者测试的成本曲线
示
? 启工缺陷定位成本打桩成本
– 作者测试粒度并非越小越好；
开发
– 量者测试粒度过小，将导致打桩成本急剧提升，迫
开发
使开发人员偷工减料（省略打桩，忽略输出检查），
导致开发者测试名存实亡；
– 因此，找到正确粒度的单元是开发者测试成功的第一
步。
甜点
? 结论
– 高内聚、低耦合
大单元大小小
– 由 1-3 个开发人员完成，最好是 1 个
– 不直接访问网络、数据库、文件系统；

分层测试实践： Google

? 谷歌采用 70/20/10 原则 : 70% 小， 20%
中， 10% 大
– Projects at Google are encouraged to maintain a
healthy mixture of test sizes among their various test
suites.
– Overinvesting in end-to-end automation often ties you
to a product’s specific design

Acceptance Test Driven
Development
? 工具平台
– Robot Framework + Selenium2
– http://code.google.com/p/robotframework/
– https://github.com/robotframework/RIDE/wiki
– http://code.google.com/p/robotframework-
seleniumlibrary/
? 示例
– quickstart.html
– report.html
– log.html

? 关键点
– 框架和业务分离，业务和数据分离
– 通过不断抽象，消除冗余
– 测试用例应尽量简单易读，避免复杂逻辑
– 建立测试用例分层架构，并坚守
– 自动化测试用例必须非常健壮，避免误报

? 要敏捷，要持续集成，要自动化不仅仅是测试团
队的事
– 干系人需要权衡迭代频率和产物质量
– 敏捷团队在拥抱变化的同时要控制变化，变化的目标
是更省事不是找麻烦
– 开发团队在做新需求的时候要尽可能减少不必要的变
化，比如 Web 产物可以确定 DOM 里面的 ID 、 Name
不要变
– 测试团队可以和开发约定一些完全可以不用变的元素
，比如控件的 classname

? 经验积累
– 即便正常关闭浏览器， IE 可能存在僵死进程， IE 僵尸
进程对 Web 自动化的稳定性影响较大，比如可能导致
HTTP 请求带不上 cookie
– Autoitlibrary 库提供模拟 window 动作的能力
– 用 JS 框架里面的 AJAX 计数器实现对 AJAX 的验证，
比如 JQuery 库

Requirement Based Testing

? Goals
– Deliver more functions in less time with fewer
resources and with higher quality
? Key Issue
– Poor quality requirements
? How to do
– Test the specifications to ensure that they are correct,
complete, unambiguous, and logically consistent
– Design a necessary and sufficient set of tests to
ensure that the design and code fully implement the
requirements

? Distribution of Bugs
– Requirements 56%
– Design 27%
– Coding 7%
– Other 10%
? US Average Defect Rate
– 5.9-7 defects per thousand lines of code
– 15% increased in recent years
? Costs per hour for outages
– Pay-per-view TV $150,000
– Financial services $6.4 Million

The RBT Process

? Validate requirements aganist objectives
? Apply scenarios aganist requirements
? Perform initial ambiguity review
? Perform domain expert review
? Design test case by RBT
? Test case review with PM/RD/expert
? Walk test cases

Module Based Testing

? 华为 07 年开始引入，目前 4 个产物使用， 20 个
项目，生成测试用例 3W 个，整体效率提升 20%

敏捷测试实践
? 一个微软测试工程师的敏捷历程
– 发现不少严重 bug ，得到团队肯定，但没有技术含量
– 通过技术手段，发现了更多隐藏 bug ，但没有参与感
– 通过参加需求评审，提前发现了 bug ，有成就感，但
仍然有遗漏 bug ，而测试工程师在项目前期却比较空
闲
– 需求变化频繁，因为一开始用户根本不知道自己的真
实需求或者讲不清楚，能不能先做一个原型给客户看
– 调整心态，积极应对变化，尽早测试、不间断测试
– 迭代、单元测试通过才能 checkin 、自动化 build 、自
动化测试、自动化报告、自动化发布
– 提出可测性（自动化）概念 SOCK 原则

测试看开发，开发看测试
– 开发：我改了点东西，帮我测试一下
– 测试：噢，按流程没有正式提测，我们不能测试
– 开发：这个奥运版本，明天一定要上线，今天下午才
能提测，帮忙安排测试资源
– 测试：噢，按流程一个版本测试需要 3 个工作日，不
可能明天发布
– 开发：自动化测试能提高效率
– 测试：没有人力
– 开发：我们来帮忙搞起来
– 测试：好啊好啊
– 若干时间后，开发：算了吧，自动化测试就是浮云

核心价值：帮助开发、项目团队
提高效率

? 技术上修炼内功，达到和对应的开发一个 level ，
这样才便于讨论技术细节
? 测试方法、技术、工具、策略改进提高效率
? 测试流程优化
? 测试不仅仅发现 bug ，最好能定位、修复，直接
告诉开发修复那一行代码
? 开发和测试共担质量指标

敏捷

? 基础设施保障：自动化 UT 、 Build 、 ST 、发布
? 持续集成
? 质量反馈

测试管理

? 测试绩效考核是指挥棒
? 不要用单纯的 bug 数量，漏测率等作为 KPI 去考
核测试绩效
? 开发和测试共担产物质量风险

总结

? 心态：开放、合作，开发测试共担质量风险
? 原则：价值导向的测试策略
? 素质：对测试人员的要求越来越高
? 敏捷：如何用最小的代价应对变化

狠狠撸

2012 China 软件测试大会

Recommended

More Related Content

What's hot (17)

Viewers also liked (17)

Similar to 2012 China 软件测试大会 (20)

2012 China 软件测试大会

Editor's Notes