2011-08-23 47 views
3

使用Specflow,我正在编写一套场景模拟月薪,验证每月计算的付款以及最终的年终数字。Specflow - “场景”之间的状态

每个月的结果都是累积的,因此每个后续情景都取决于上个月的增加和减少。支付计算通过第三方工具写入数据库,因此在各种情况之间创建和销毁测试数据非常昂贵。

根据我的测试经验,我知道并不总是可以确保测试的执行顺序。我可以用一些场景命名约定来控制执行顺序,但不能保证远程测试运行器将按字母顺序运行测试。

选项,我认为:

  • 通过一个单一的情况下,包括大量的给定的时候,那么断言运行整整一年。这会导致一个难以阅读的巨大场景。
  • 为每个场景创建一个“给定”级联。 “鉴于:所有到X月的付款都已完成”。这会创建大量的数据库流量,因为每个场景都需要创建和销毁测试数据。

是否有更好的方法来在场景之间存储状态并确保场景按照所需的顺序执行?

+0

您也可能会发现这个答案有帮助,如果您将它映射到您的问题上,并且您想要执行的测试类型选择较高级别的抽象: http://stackoverflow.com/a/23375756/936469 – realtime

回答

4

依靠场景的执行顺序是一种反模式,应该避免。出于同样的原因,测试运动员通常不会提供任何控制执行顺序的机制。这也会违反可执行规范的概念:该方案应该可以自行理解(并且可执行)。

在你的情况下,给定的部分应该为有问题的计算准备数据,当应该计算,然后应该检查单个计算的结果。

为了缩短执行时间,您可以尝试选择“重要”场景,以便测试不同方面。可能没有必要每个月1-11测试一次。你可以为第一个月的工资单进行一次测试,一个为第二个月,一个为结束一整年,一个为开始新的一年等。

这也是一种常见的技术,给定不一定是与“真正的应用程序”(从头开始)完全相同。有时你可以在测试中做快捷键,以更快更简单的方式确保先决条件。例如。你可以指定上个月的总和,如果这是你所有的场景需要计算下个月(而不是让应用程序从头开始计算所有东西)。当然,你必须知道你在做什么,你必须考虑伪造应用程序某些方面的风险。

+0

感谢您的反馈。我已经欺骗了“整个一年”的情景。提供以前的每月付款计算不是成立的,计算太难以模拟。 – Cr1spy

+1

“计算”太难以模拟了吗?当然,前一个月的结果可能是静态数据 - 事实上,您正试图在步骤之间存储的数据恰好是? – perfectionist