2012 china 软件测试大会
Post on 18-Dec-2014
538 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
分享内容大纲
• 敏捷精要:分层质量保证 ( 吴穹 )• ATTD - Acceptance Test Driven Development
( 吴穹 )• RBT – Requirement Based Testing ( IBM
Richard Bender )• MBT - Module Based Testing (华为)• 敏捷测试实践 (微软 Bill Liu )• 测试看开发,开发看测试( Google 段念)
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 库
分享内容大纲
• 敏捷精要:分层质量保证 ( 吴穹 )• ATTD - Acceptance Test Driven Development
( 吴穹 )• RBT – Requirement Based Testing ( IBM
Richard Bender )• MBT - Module Based Testing (华为)• 敏捷测试实践 (微软 Bill Liu )• 测试看开发,开发看测试( Google 段念)
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
分享内容大纲
• 敏捷精要:分层质量保证 ( 吴穹 )• ATTD - Acceptance Test Driven Development
( 吴穹 )• RBT – Requirement Based Testing ( IBM
Richard Bender )• MBT - Module Based Testing (华为)• 敏捷测试实践 (微软 Bill Liu )• 测试看开发,开发看测试( Google 段念)
Module Based Testing
• 华为 07年开始引入,目前 4 个产品使用, 20 个项目,生成测试用例 3W 个,整体效率提升 20%
分享内容大纲
• 敏捷精要:分层质量保证 ( 吴穹 )• ATTD - Acceptance Test Driven Development
( 吴穹 )• RBT – Requirement Based Testing ( IBM
Richard Bender )• MBT - Module Based Testing (华为)• 敏捷测试实践 (微软 Bill Liu )• 测试看开发,开发看测试( Google 段念)
敏捷测试实践
• 一个微软测试工程师的敏捷历程– 发现不少严重 bug ,得到团队肯定,但没有技术含量– 通过技术手段,发现了更多隐藏 bug ,但没有参与感– 通过参加需求评审,提前发现了 bug ,有成就感,但仍然有遗漏 bug ,而测试工程师在项目前期却比较空闲
– 需求变化频繁,因为一开始用户根本不知道自己的真实需求或者讲不清楚,能不能先做一个原型给客户看
– 调整心态,积极应对变化,尽早测试、不间断测试– 迭代、单元测试通过才能 checkin 、自动化 build 、自
动化测试、自动化报告、自动化发布– 提出可测性(自动化)概念 SOCK 原则
分享内容大纲
• 敏捷精要:分层质量保证 ( 吴穹 )• ATTD - Acceptance Test Driven Development
( 吴穹 )• RBT – Requirement Based Testing ( IBM
Richard Bender )• MBT - Module Based Testing (华为)• 敏捷测试实践 (微软 Bill Liu )• 测试看开发,开发看测试( Google 段念)
测试看开发,开发看测试
– 开发:我改了点东西,帮我测试一下– 测试:噢,按流程没有正式提测,我们不能测试– 开发:这个奥运版本,明天一定要上线,今天下午才
能提测,帮忙安排测试资源– 测试:噢,按流程一个版本测试需要 3 个工作日,不
可能明天发布– 开发:自动化测试能提高效率– 测试:没有人力– 开发:我们来帮忙搞起来– 测试:好啊好啊– 若干时间后,开发:算了吧,自动化测试就是浮云
核心价值:帮助开发、项目团队提高效率
• 技术上修炼内功,达到和对应的开发一个 level ,这样才便于讨论技术细节
• 测试方法、技术、工具、策略改进提高效率• 测试流程优化• 测试不仅仅发现 bug ,最好能定位、修复,直接告诉开发修复那一行代码
• 开发和测试共担质量指标
敏捷
• 基础设施保障:自动化 UT 、 Build 、 ST 、发布• 持续集成• 质量反馈
测试管理
• 测试绩效考核是指挥棒• 不要用单纯的 bug 数量,漏测率等作为 KPI去考核测试绩效
• 开发和测试共担产品质量风险
总结
• 心态:开放、合作,开发测试共担质量风险• 原则:价值导向的测试策略• 素质:对测试人员的要求越来越高• 敏捷:如何用最小的代价应对变化
top related