Anı*_*lik 9 testing bdd analysis
我们最近开始使用BDD来编写我们的要求.这真的很有帮助,它使分析师和开发人员之间的沟通变得更加容易.(结合用户界面和旧学校要求)
现在我们正在考虑使用BDD编写测试用例.当我在网上搜索最佳实践时,我发现有很多不同的编写方式.
有一些例子,如:
问题几乎所有的例子都是针对非常简单的情况,另一方面我们想编写包含多个动作,多个系统输出(警告,错误等)和多个输出的场景.
我们正试图找出为以下场景编写BDD的最佳方法:
我们希望用户执行以下操作:
我们有这么长的故事的原因是,这是一个常见的情况,我们希望确保用户能够回到幸福的道路.
您认为使用BDD处理此类场景的最佳方法是什么？
Lun*_*ore 11
我将尝试重新描述你在这里所要求的东西,希望它能清除一些东西.
我们最近开始使用BDD编写我们的要求......现在我们正考虑用BDD编写测试用例.
我们最近开始使用示例来阐明我们的要求......现在我们正在考虑自动化这些示例.
当我在网上搜索最佳实践时,我发现有很多不同的编写方式.
当我在线搜索时,我会看到很多不同的背景,事件和结果.
(这不仅仅是在写作中;而是在谈话中导致写作.这就是你变异的原因;因为谈话真的很模糊.)
问题几乎所有的例子都是针对非常简单的情况
问题是,在过去,像我这样的早期采用者使用登录之类的东西作为例子.
我们做错了.简单的例子实际上并不能帮助您理解BDD.整个美丽的是,当我们与了解问题的利益相关者(例如可能是安全或基础设施专家,它不仅仅适用于业务专家)交谈时,我们学到了一些东西.这是关于我们在BDD早期做错的事情的谈话 ; 你遇到了其中一些的成本.抱歉.
我写了一篇关于BDD 3个方面的博客文章:探索,规范和测试.大多数人关注的是第二和第三,但第一是隐含的.探索很重要,围绕场景的对话是一种非常便宜的方式!
我们想编写包含多个操作,多个系统输出(警告,错误等)和多个输出的场景......我们有这么长的故事的原因是这是一个可能发生的常见场景,我们希望确保用户能够回到幸福的道路.
我们想检查完整的客户旅程,以确保我们的系统至少可用,无论发生什么.
所以,如果你想使用像Cucumber这样的BDD工具来编写一个完整的,全栈的,自动化的客户旅程,而不是一个行为方面的例子(我们称之为场景),那么...它不是BDD.
但是,它是仍然一个很好的主意.它不是BDD,但并不意味着它是一件坏事.我和一些曾经做过这件事并且从中受益的组织工作过.(也许它应该有一个名字.)
以下是我根据以下经验给出的提示和提示:
千万不能使用这些作为回归测试!尝试经历每一次旅程都是指数2 ^ n的努力; 算了吧.选择几个旅程(每个理想会议3个似乎很典型)并尝试选择不同但典型的客户选择.不要使用它们来测试边缘情况.您只是检查您的主要客户旅程仍然缝合在一起.
对命令仍然规则的陈述.避免谈论用户界面; 根据每个阶段取得的成就来表达旅程.
如果您可以执行此操作,则可以重复使用较小方案中的步骤.将您的客户旅程(有时称为"冒烟测试")放在一个单独的地方,即使它们在构建的同一部分运行.首先运行它们,直到你不再需要它们(一个月左右的这些破坏将使团队解决根本原因,环境问题等等).
请明确点.它不仅仅是"用户"; 这是路上的女孩Sue,她在地图上使用你的多边形来试图发现她还没有抓到的Pokemons.具体故事真正吸引人们的想象力,让旅程难忘.如果可以的话,让不同的旅程符合不同的角色.
通常,一个场景的"当时"形成具有不同行为方面的另一场景的"给定".如果你把它们串在一起,不要担心"那么".如果您打算在下一步中使用它,则无需检查结果.例如,如果菜单需要显示特定选项,请不要检查选择; 只是使用它并假设它在那里.UI检查可能很昂贵,而且这些长途旅行我们应该在这些通常会经过的地方.如果他们不是,那么在我们弄清楚他们为什么被打破的那段时间里添加缺失的步骤是非常微不足道的.通常这些都是集成测试而不是任何东西; 在运行较长的方案套件之前检查特定服务是否已连接等.
如果您的共同客户旅程包括用户感到困惑,做错事或以其他方式浪费时间,请更改您的用户界面.用户体验专业知识仍然非常非常重要,并且实际上并不是BDD的一部分,因为与UI的比较和建议相比,很难提出"简单"或"宽容"的具体示例.BDD不是银弹.
将整个客户旅程周围的对话中的工件写下来甚至遍布办公室的整个墙壁是很常见的.但是,自动化版本通常是在较小的方案完成且功能正常工作之后创建的.
整个端到端客户旅程与包含边缘案例等行为方面的较小方案之间通常存在重复.端到端的旅程提供快速反馈,确保没有人浪费时间; 较小的方案提供了有关系统应如何表现的文档.在这种情况下复制是可以的.
如果您认为这是一个完整的旅程,那么我希望看到的是这种事情(我在这里所做的只是"声明与命令"的事情):
Given Sue's registered to catch Pokemons
And Bulbasaurs, Koffings and Pikachus were caught in Trafalgar square this year
When she filters for Pokemons caught between January and July
And adds a filter for "Poison" traits
And filters for "Bulbasaur"
When she searches for Pokemons
Then she should be asked to select an area of the map
When she selects an area around Trafalgar Square
Then she should be shown the Bulbasaur density
But not the Pikachu or Koffing density.
使用特定示例.理解和看到上面的缺陷,或者我对Pokemon Go(我还没有玩过)的理解,当它真正有真实的想法时,它会容易得多.这是在这些旅程和较小的场景之间的共同点.
你还会看到有很多很多"蠢",而且它们都相互融合.如果我们讨论行为的单个方面,那么每个方面都将以"给定"为前缀,概述之前的内容,以及允许下一个"何时"为"当时"的结果.在这种情况下,虽然我们将它们链接在一起.在这些类型的旅程中,不间断的"呜呜"序列是非常常见且完全正常的,只要你尊重这不是关注行为的单一方面,也不提供它的例子(因此它不是真正的BDD).当结果是旅程的重要部分时,"旅程中途"出现,特别是提供用户必须具体回应的非特定指导.
不要因误解而自动化这些!自动化的客户旅程代表了一项重大投资(尽管一旦您拥有覆盖相同功能的较小方案,它们就很容易组合在一起).首先获得功能,并将其显示给相关的利益相关者.您不希望在可能随学习和反馈而改变的事情上投入大量资金.
希望这有用,感谢让我想到这一点!
| 归档时间： |
|
| 查看次数： |
1613 次 |
| 最近记录： |