Download to read offline
2012 China 软件测试大会
- 1. 2012 中国首届软件测试大会 2012-08-06 上海
- 2. 测试界的共识 • Driven QualityUpstream
- 3. 分享内容大纲 • 敏捷精要：分层质量保证 (吴穹 ) • ATTD - Acceptance Test Driven Development ( 吴穹 ) • RBT – Requirement Based Testing （ IBM Richard Bender ） • MBT - Module Based Testing （华为） • 敏捷测试实践 （微软 Bill Liu ） • 测试看开发，开发看测试（ Google 段念）
- 4. 敏捷精要 ：分层质量保证 • 质量是开发人员的神圣责任，而不仅仅是测试人 员的责任 – 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 开发测试 集成测试 验收测试 5
- 6. 开发者测试的成本曲线 示 • 启工 缺陷定位成本 打桩成本 – 作 者测试粒度并非越小越好； 开发 – 量 者测试粒度过小，将导致打桩成本急剧提升，迫 开发 使开发人员偷工减料（省略打桩，忽略输出检查）， 导致开发者测试名存实亡； – 因此，找到正确粒度的单元是开发者测试成功的第一 步。 甜点 • 结论 – 高内聚、低耦合 大 单元大小 小 – 由 1-3 个开发人员完成，最好是 1 个 – 不直接访问网络、数据库、文件系统；
- 7. 分层测试实践 ： 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
- 8. 分享内容大纲 • 敏捷精要：分层质量保证 (吴穹 ) • ATTD - Acceptance Test Driven Development ( 吴穹 ) • RBT – Requirement Based Testing （ IBM Richard Bender ） • MBT - Module Based Testing （华为） • 敏捷测试实践 （微软 Bill Liu ） • 测试看开发，开发看测试（ Google 段念）
- 9. 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
- 10. • 关键点 – 框架和业务分离，业务和数据分离 – 通过不断抽象，消除冗余 – 测试用例应尽量简单易读，避免复杂逻辑 – 建立测试用例分层架构，并坚守 – 自动化测试用例必须非常健壮，避免误报
- 11. • 要敏捷，要持续集成，要自动化不仅仅是测试团 队的事 – 干系人需要权衡迭代频率和产品质量 – 敏捷团队在拥抱变化的同时要控制变化，变化的目标 是更省事不是找麻烦 – 开发团队在做新需求的时候要尽可能减少不必要的变 化，比如 Web 产品可以确定 DOM 里面的 ID 、 Name 不要变 – 测试团队可以和开发约定一些完全可以不用变的元素 ，比如控件的 classname
- 12. • 经验积累 –即便正常关闭浏览器， IE 可能存在僵死进程， IE 僵尸 进程对 Web 自动化的稳定性影响较大，比如可能导致 HTTP 请求带不上 cookie – Autoitlibrary 库提供模拟 window 动作的能力 – 用 JS 框架里面的 AJAX 计数器实现对 AJAX 的验证， 比如 JQuery 库
- 13. 分享内容大纲 • 敏捷精要：分层质量保证 (吴穹 ) • ATTD - Acceptance Test Driven Development ( 吴穹 ) • RBT – Requirement Based Testing （ IBM Richard Bender ） • MBT - Module Based Testing （华为） • 敏捷测试实践 （微软 Bill Liu ） • 测试看开发，开发看测试（ Google 段念）
- 14. 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
- 15. • Distribution ofBugs – 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
- 16. 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
- 17. 分享内容大纲 • 敏捷精要：分层质量保证 (吴穹 ) • ATTD - Acceptance Test Driven Development ( 吴穹 ) • RBT – Requirement Based Testing （ IBM Richard Bender ） • MBT - Module Based Testing （华为） • 敏捷测试实践 （微软 Bill Liu ） • 测试看开发，开发看测试（ Google 段念）
- 18. Module Based Testing •华为 07 年开始引入，目前 4 个产品使用， 20 个 项目，生成测试用例 3W 个，整体效率提升 20%
- 19. 分享内容大纲 • 敏捷精要：分层质量保证 (吴穹 ) • ATTD - Acceptance Test Driven Development ( 吴穹 ) • RBT – Requirement Based Testing （ IBM Richard Bender ） • MBT - Module Based Testing （华为） • 敏捷测试实践 （微软 Bill Liu ） • 测试看开发，开发看测试（ Google 段念）
- 20. 敏捷测试实践 • 一个微软测试工程师的敏捷历程 –发现不少严重 bug ，得到团队肯定，但没有技术含量 – 通过技术手段，发现了更多隐藏 bug ，但没有参与感 – 通过参加需求评审，提前发现了 bug ，有成就感，但 仍然有遗漏 bug ，而测试工程师在项目前期却比较空 闲 – 需求变化频繁，因为一开始用户根本不知道自己的真 实需求或者讲不清楚，能不能先做一个原型给客户看 – 调整心态，积极应对变化，尽早测试、不间断测试 – 迭代、单元测试通过才能 checkin 、自动化 build 、自 动化测试、自动化报告、自动化发布 – 提出可测性（自动化）概念 SOCK 原则
- 21. 分享内容大纲 • 敏捷精要：分层质量保证 (吴穹 ) • ATTD - Acceptance Test Driven Development ( 吴穹 ) • RBT – Requirement Based Testing （ IBM Richard Bender ） • MBT - Module Based Testing （华为） • 敏捷测试实践 （微软 Bill Liu ） • 测试看开发，开发看测试（ Google 段念）
- 22. 测试看开发 ，开发看测试 – 开发：我改了点东西，帮我测试一下 –测试：噢，按流程没有正式提测，我们不能测试 – 开发：这个奥运版本，明天一定要上线，今天下午才 能提测，帮忙安排测试资源 – 测试：噢，按流程一个版本测试需要 3 个工作日，不 可能明天发布 – 开发：自动化测试能提高效率 – 测试：没有人力 – 开发：我们来帮忙搞起来 – 测试：好啊好啊 – 若干时间后，开发：算了吧，自动化测试就是浮云
- 23. 核心价值 ：帮助开发 、项目团队 提高效率 • 技术上修炼内功，达到和对应的开发一个 level ， 这样才便于讨论技术细节 • 测试方法、技术、工具、策略改进提高效率 • 测试流程优化 • 测试不仅仅发现 bug ，最好能定位、修复，直接 告诉开发修复那一行代码 • 开发和测试共担质量指标
- 24. 敏捷 • 基础设施保障：自动化 UT、 Build 、 ST 、发布 • 持续集成 • 质量反馈
- 25. 测试管理 • 测试绩效考核是指挥棒 • 不要用单纯的bug 数量，漏测率等作为 KPI 去考 核测试绩效 • 开发和测试共担产品质量风险
- 26. 总结 • 心态：开放、合作，开发测试共担质量风险 • 原则：价值导向的测试策略 • 素质：对测试人员的要求越来越高 • 敏捷：如何用最小的代价应对变化
Editor's Notes
- #11 自动化测试用例必须非常健壮，避免误报（脚本验收标准：连续跑 10 次， 100% 通过） Yun 2012-08-05 上海：结合中心目前的情况， yunma 认为自动化测试脚本的质量和产品质量同等重要，自动化脚本开发完成后必须组织 code review ，验收标准可以参考（脚本验收标准：连续跑 10 次， 100% 通过）。在往深的讲，就涉及到测试框架是否好用、易用，脚本开发人员能力提升
- #12 要敏捷，要持续集成，要自动化不仅仅是测试团队的事 Yunma 2012-08-05 上海：这里的思路就是想方设法使得自动化测试脚本维护工作最小化地应对需求变化（因为敏捷就是要拥抱变化）
- #15 分析发现 60% 以上的 Bug 都是由于需求相关 需求错误 需求不明确 提高质量的前提就是确保需求的质量
- #17 测试人员就是用户，因此测试人员参加需求评审可以确保需求满足用户期望 测试思维能够帮助需求定义考虑到各种场景，从而验证需求定义的完整性和准确性 需求测试属于静态黑盒测试，分为两个层面： high level 从行业同类软件、用户习惯、标准、规范的角度考虑 detailed 从一些关键词入手，确保需求无二义性 比如 NASA 为了测试太空使用的圆珠笔花费 $1Million ，而俄罗斯人用铅笔就解决这个问题
- #21 提出可测性（自动化）概念 SOCK 原则 比如提供 API 查询模块状态、输出结果到文件、约定 classname 、 ID 等
- #23 本质是开发认为测试太慢了，开发希望看到改了一点东西马上看到测试结果，作为测试，如何能做到这一点？ 快速发现、定位和修复问题在 Web 类产品中显得尤为重要 站在不同的角度去思考问题
- #24 以价值为核心的测试策略，测试实践没有边际，没有最好，怎样做最有价值就怎样做