2012 china 软件测试大会

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.

5

分层质量保证的基本思想

开发测试

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

集成测试

验收测试

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

6

开发者测试的成本曲线

• 启示– 开发者测试粒度并非越小越好；– 开发者测试粒度过小，将导致打桩成本急剧提升，迫

使开发人员偷工减料（省略打桩，忽略输出检查），导致开发者测试名存实亡；

– 因此，找到正确粒度的单元是开发者测试成功的第一步。

• 结论– 高内聚、低耦合– 由 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 resour

ces 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 ensur

e 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 软件测试大会

Documents