假设您具有自动化测试(我的示例使用Selenium)来声明网站的复杂业务逻辑。断言数千个不同的测试用例在软件中输出正确值的最佳方法是什么?我考虑过只复制实际软件用于我们期望值的业务逻辑,但是那不就是重新发明轮子吗?

示例:

目标是断言对于所有订单情况运输都是正确的。电子商务站点有50,000种产品(假设)。运输成本是根据运输提供商和每个客户的费率,额外的手续费,基本运输费率(无论用户是批发商还是零售商)确定的,可能取决于订购的物品类型等因素导致的产品数量阈值。 />
当针对所有产品运行自动化测试用例时,我们是否应该将此业务逻辑(从站点服务器代码)移至Selenium代码库中的断言业务逻辑?还是根据这些测试用例的参数,我们应该对数千种产品的运输成本进行硬编码?

让我改一下这个问题...

我过去做过的所有测试案例都是确保在对我们的软件进行增强后,网站功能不会中断(例如:工作流程中的所有页面都可以正常工作,并且不会崩溃-例如下订单,创建具有一组值的产品,并在编辑产品时确保该产品具有相同的值,并确保重定向工作正常等。)这些测试用例很容易编写。但是,对于这个问题,我想断言/验证运输成本(本质上是基于一组参数的输出值)基于我们的业务逻辑是正确的。此业务逻辑有效性测试的最佳方法/方法是什么?我是否只是将业务逻辑从服务器代码移至Selenium类库代码,以确保所有产品的运输都是正确的?还是我们应该有一个电子表格/矩阵来说明我们的参数以及Selenium测试用例中的期望值和硬代码?我希望业务逻辑将来会变得更加复杂,但是我们需要确保对于我们预计业务逻辑不会在未来发生变化的产品,其运输成本也将保持不变。

定价比运输(带有折扣等)要复杂得多,因此我也想使用相同的方法。

评论

我想我听完了你所有的问题,除了最后一句话。您介意用不同的方式对最后一句话进行措词吗?

我希望最后一段更清楚。.

#1 楼

不,您既不应该复制也不实现复杂的业务逻辑。 (有关该做法的弊端,请参阅“如何测试使用SQL查询选择,分组和计数数据的Excel宏的答案?”)。

我怀疑您没有资源来测试50,000种产品的行为。以下是一些替代方法:



针对合成的规范产品测试业务逻辑。如果您知道业务逻辑(而不是实现,而是预期的行为),则可以设计一个测试套件来执行它。如果由于变量数量过多而遇到组合问题,则可能需要尝试“全对”方法。请参阅我对高度复杂的开发项目适用什么标准以保证获得“真实世界”数据?有关该主题的更多信息。

对特定产品的行为进行采样。如果您了解业务逻辑但又不想解决组合问题,则可以选择一组您认为特别重要的产品进行测试。您的选择标准可能基于其财务重要性,与其他产品的相似性或某些与业务相关的指标。我个人不喜欢这种方法,但是我已经看到组织使用它。

回归测试特定产品的行为。如果您不了解业务逻辑,但是有理由相信当前结果对于一组产品是正确的,则可以捕获这些结果并将其与将来版本的结果进行比较。

如果可能的话,我建议在API级别而不是UI级别执行这些测试。

最后,如果业务逻辑确实很复杂,则应调查是否可以在较低级别(即一次进行一个组件)进行测试。 (我不会讨论是将其视为单元测试,还是将这种测试视为开发人员或测试人员的工作。如果需要进行较低级别的测试,则您的团队需要自己弄清楚这一点。) br />

评论


我们知道系统中的值是正确的,但是我们计划在定价和运输中添加新的逻辑,所以我喜欢#3!

– MacGyver
2012年1月25日17:40

#2 楼

MacGyver,首先要看的地方之一是单元测试中业务逻辑的覆盖程度。如果单元测试涵盖了边界逻辑,费用逻辑等,那么您只需要运行测试就可以确保最终数据正确。

对于您在寻找正确的结束日期时,我建议使用一种线束,该线束将独立处理测试步骤,可以将所有步骤串在一起,然后从数据存储中提取以生成多个事务。您的数据可能类似于:

“ STEPKIND = NEWSALE,ACTION = SELECTNEW”
“ STEPKIND = PICKITEM,ACTION =(ItemName)”

事务运行时,您从系统数据库中提取数据并运行逐个单元的比较。由于在建立交易集的同时也在建立基准,因此此后唯一需要做的更改就是添加新交易及其基准数据-我将这种方法(使用其他工具)用于特定的目标销售系统和链接的电子商务站点,在其中必须正确计算运费,税金,客户折扣等。有用。每当重构破坏计算时,我的团队就会知道。

评论


当您说基线时,您只是说从实时数据库中的订单中扣除过去的运输成本(我们知道每种订单中的产品组合都是正确的),将该数据作为基线同步到我们的质量检查数据库中,然后将这些运输成本与开发站点输出的运输成本?将来,如果我们在运输中添加新的逻辑,那么在质量检查数据库中建立新的基准?

– MacGyver
2012年1月25日17:05

我的意思是说,从订单中存储一笔已知的好成本-无论它们是否存在,都没有关系,只要您知道它们是正确的并且可以对应用程序的行为进行抽样即可。如果逻辑发生了变化,但是成本却没有变化,则您无需更改任何内容-测试将检查新逻辑是否仍获得相同的结果。如果成本发生变化,则可以更新基准,以使测试保持正确。因此,如果订单367的运费应该为$ 5.78,这就是您的基准所说的。

–凯特·保罗(Kate Paulk)
2012年1月25日19:45