当我们有Specflow时,为什么要使用编码的ui？

Question

我们在当前项目中使用Specflow和WatIn进行验收测试.客户希望我们使用Microsoft编码的ui.我从来没有测试过编码的ui,但是到目前为止我看到它看起来很麻烦.我想在我有一个ui之前预先指定我的验收测试,而不是由于一些记录/回放的东西.无论如何,有人可以告诉我为什么我们应该扔掉Specflow/watin组合并用编码的ui替换它？

我还读过你可以将specflow和编码的ui结合起来,但对于我在specflow中已经做得很好的事情来说,它看起来很像开销.

Answer 1

我写了一篇关于如何做到这一点的博客文章,你可能觉得它很有用

http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/

我能想到的编码UI测试的专业和概念是您正在测试应用程序用户将如何使用它.这对于验收测试很有用,但它也有其局限性.它也非常适合端到端测试.在过去,UI测试已被证明是脆弱的.例如,当MS创建VS2010 UI时,几乎所有的UI测试都破了.主要原因是技术变革.编码的UI测试确实有助于通过匹配控件的方式来限制这种情况.它使用更多基于概率的匹配.这意味着它将尝试根据其拥有的信息(例如控件名称)找到最佳匹配.对我们来说,由于技术限制,我们选择了编码UI测试.我们的Legacy应用程序是VB,虽然CUIT不能很好地工作,但我正在编写扩展以获得更好的控制信息,它仍然是我们唯一的选择.另外请记住,CUIT是新的,有其自身的局限性.您应该准备好按照布局项目的方式进行结构化,因为VS2010中当前的端到端行为可以保持您的UIMap可以进行一些手动操作,例如从现有的操作记录创建CUIT总是放置UIMap中的测试称为UIMap.uitest,无法更改或转移到另一个UIMap.如果您使用多个ui地图,这意味着您需要先记录您的步骤,然后在测试中使用它们.然而,在.net它仍然非常灵活.

到目前为止,关于specflow的最好的事情是它的可读性和生活文档的gerkin语法.通常,您的应用程序的测试功能或行为是值得的地方.它通常将测试目标定位在UI下方.当UI在这里发生变化时,测试破坏的可能性会小一些.当您的应用程序不断变化并且您希望确保现有功能仍然有效时,我的规格很棒.它非常适合Scrum环境,您可以将其编写为关于它应如何工作的描述.我可以看到specflow的一个限制是它可以解释.因此,编写一个不可重用且难以维护的测试很容易.我喜欢使用更通用的术语来描述我的步骤,如"以User1登录"而不是"转到登录页面,输入用户名和密码,单击登录".更细粒度地描述它使得重新使用它更难以将其耦合到UI.登录实际上如何工作应该取决于后面的代码而不是specflow功能.

然而,将2与我们结合起来似乎比仅使用编码的UI测试更有益.如果我们决定完全更改UI,我们至少会以任何人都能理解的方式将预期的行为存储在我们的specflow功能中.最后,您需要考虑应用程序的演变方式和应用程序类型.