1 / 30

三步实践“验收测试驱动开发” 让团队交付正确的软件

三步实践“验收测试驱动开发” 让团队交付正确的软件. 葛锋 测试自动化教练 诺基亚西门子杭州研发中心. 案例背景 如 何做到的 ATDD 的几个常见问题 三 sprint 实践 ATDD. 摘要. 三步实践“验收测试驱动开发” —— 让团队交付正确的软件. 案 例 背 景（问题解决前的糟糕状态）：

halen
Download Presentation

三步实践“验收测试驱动开发” 让团队交付正确的软件

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 三步实践“验收测试驱动开发” 让团队交付正确的软件 葛锋 测试自动化教练 诺基亚西门子杭州研发中心

  2. 案例背景 • 如何做到的 • ATDD的几个常见问题 • 三sprint实践ATDD 摘要

  3. 三步实践“验收测试驱动开发”——让团队交付正确的软件三步实践“验收测试驱动开发”——让团队交付正确的软件 • 案例背景（问题解决前的糟糕状态）： 在每次迭代开发开始之前，团队均会召开会议商讨开发的内容，以及相应的测试用例。但真实情况是，貌似大家都已经讨论清楚的内容，实际上并没有达成统一性的理解，因而就存在了过度开发或开发不足的问题，最终导致在迭代结束的时候团队并没有交付完全正确的特性或软件；更胜的是我接触过的一个团队因此原因导致整个迭代的直接失败。 b) 此案例实施后达到的目标： 让团队掌握实施ATDD的实践方式，以此对需求达成统一共识，最终构建出正确的软件。

  4. 怎么做到的（思路） • 理解人性，从团队愿意采用的方式切入，降低抵触情绪 • 适当经历曲折与错误，帮助团队摄取经验与教训

  5. ATDD的几个常见问题

  6. 组员：Sprint开始之前的grooming会议上讨论，会后编写完成组员：Sprint开始之前的grooming会议上讨论，会后编写完成 我：你们是在什么时候讨论和编写的验收测试用例 1.验收测试用例讨论与编写的时间 GOOD

  7. 组员：我们放在Excel表格中，基本都是描述性的组员：我们放在Excel表格中，基本都是描述性的 我：这些用例是以什么样的方式存储，含有测试数据吗 2.验收测试用例的数据与存储 BAD

  8. 组员：我们开始不觉得性能是个问题，不想最后会成这样组员：我们开始不觉得性能是个问题，不想最后会成这样 我：你们是不是在一开始压根就没有考虑过性能的验收 3.验收测试用例的维度 BAD

  9. 组员：当然是测试人员，一般采用手工的方式 我：你们是怎样执行验收测试用例的，谁来执行的？ 4.验收测试用例怎样执行 BAD

  10. 三Sprint实践ATDD

  11. 第一个Sprint

  12. 讨论并设计完可测的关键测试数据之后，我们都知道了特性的scope。随后我们准备将验收测试进行自动化，但紧接着问题就来了讨论并设计完可测的关键测试数据之后，我们都知道了特性的scope。随后我们准备将验收测试进行自动化，但紧接着问题就来了 谁来负责编写验收代码？ 用基于关键字的框架还是纯脚本语言？

  13. 测试：功能都没有实现，怎么来编写验收测试代码测试：功能都没有实现，怎么来编写验收测试代码 开发：我的开发任务很重，很难有精力还要写验收测试 关于谁来编写验收测试代码

  14. 既然各有难处，且都没有相关经验，我决定作为一名测试开发人员的角色帮助他们实现验收测试代码，以帮助他们认识到可行性和积累相关经验。既然各有难处，且都没有相关经验，我决定作为一名测试开发人员的角色帮助他们实现验收测试代码，以帮助他们认识到可行性和积累相关经验。

  15. 我：验收测试代码后续是交付给你持续测试维护的，你觉得哪种你更擅长？我：验收测试代码后续是交付给你持续测试维护的，你觉得哪种你更擅长？ 开发：当然是纯脚本的语言，编写更类似于高级语言 用基于关键字的框架还是纯脚本语言

  16. 验收测试代码片段

  17. 我和开发人员配合得很愉快，在验收测试代码基本完成后，我将所有权传递给了开发人员，每次他有小的代码改动都会运行一下验收测试脚本，如果没有问题就交给测试人员。这做到了开发自测，并且测试效率很高，开发和测试都很happy我和开发人员配合得很愉快，在验收测试代码基本完成后，我将所有权传递给了开发人员，每次他有小的代码改动都会运行一下验收测试脚本，如果没有问题就交给测试人员。这做到了开发自测，并且测试效率很高，开发和测试都很happy

  18. 一切看起来似乎都很好，但问题在sprint review会议上出现了

  19. 当PO看到测试脚本的console output不断打印着输出时，一脸疑惑 你们是怎样设计测试的？测试数据在哪里？这些不断输出的内容是什么？

  20. 我们让团队满意了，但没有让PO满意，PO并不关心测试实现我们让团队满意了，但没有让PO满意，PO并不关心测试实现

  21. 我：你喜欢怎样的测试结果展示呢？Robot Framework那样的方式吗？ PO：是的，因为那样可以让我清楚看到测试需求和数据 PO喜欢怎样的实现呢

  22. 第二个Sprint

  23. 团队开始自己实现验收测试代码 我们在设计和编写测试代码的时候，注意上下层次分离，即测试需求和实现分离。 在review meeting前，针对PO的需求，我们采用robot framework替换python展现测试需求和数据，同时也保留python的方式，因为开发倾向于此种方式。

  24. PO很满意，同时团队也意识到基于关键字驱动的测试框架更利于展现测试需求，因为它结合关键测试数据、基于自然语言描述，更接近于需求文档。PO很满意，同时团队也意识到基于关键字驱动的测试框架更利于展现测试需求，因为它结合关键测试数据、基于自然语言描述，更接近于需求文档。

  25. 既然大家都认识到这点，并且已经掌握了上下层分离，下一个sprint似乎就不需要上层的python实现了。既然大家都认识到这点，并且已经掌握了上下层分离，下一个sprint似乎就不需要上层的python实现了。

  26. 第三个Sprint

  27. 我们将关键测试数据填写在Robot Framework的表格中，辅助以下层的python测试实现。

  28. 至此，团队已经理解了ATDD存在的意义和价值，以及相关的技能。至此，团队已经理解了ATDD存在的意义和价值，以及相关的技能。 Celebrate时刻？ 为了让自动化测试用例成为活的需求文档，我们还有很长的路要走！！

  29. 微博：@葛锋-Roger 邮件：roger.feng.ge@gmail.com

More Related