【问题标题】:Designing a CRUD test suite设计一个 CRUD 测试套件
【发布时间】:2023-03-30 14:47:01
【问题描述】:

我正在为我们的应用程序编写一套黑盒自动化测试。我一直遇到同样的设计问题,所以我想知道这里的人们是怎么想的。

基本上,这是一个简单的 CRUD 系统。为方便起见,让我们看看您正在测试创建、查看、编辑和删除用户帐户的屏幕。我希望 做的是编写一个测试来测试用户创建是否正常工作,另一个测试来检查查看用户是否显示与您最初输入的数据相同的数据,另一个测试来检查编辑一个用户工作,最后测试一下删除一个用户就OK了。

问题是,如果我这样做,那么测试必须按特定顺序运行,否则它们将无法工作。 (例如,您不能删除尚未创建的用户。)现在有人说测试设置应该创建测试需要的所有内容,并且拆卸应该使系统恢复到一致状态。但是想一想……创建用户测试之后需要删除该用户,而删除用户测试必须先创建一个用户……所以这两个测试现在有相同的代码,唯一的区别是该代码是否在设置/正文/拆卸中。这似乎错误

简而言之,我似乎面临着几种选择,所有这些似乎都被打破了:

  1. 使用 setup 创建用户并使用 teardown 删除用户。这会将所有创建用户和删除用户测试代码复制为设置/拆卸代码。
  2. 强制测试以特定顺序运行。这违反了测试应该独立工作并且可以按任何顺序运行的原则。
  3. 编写一个 giant 测试来创建用户,查看用户,编辑用户,然后删除用户,所有这些都作为一个巨大的整体块。

请注意,创建用户并非易事;涉及很多步骤。同样,在删除用户时,您必须指定如何处理分配给他们的项目等。无论如何这都不是一项简单的操作。

现在,如果这是一个白盒测试,我可以模拟用户帐户对象,或模拟保存它们的数据库,甚至是在磁盘上测试真实数据库。但这些是黑盒测试,只测试外部的、用户可见的界面。 (即,单击屏幕上的按钮。)这个想法是从头到尾测试整个系统,而不需要修改它[显然通过 GUI 命令除外]。

【问题讨论】:

    标签: testing automated-tests integration-testing


    【解决方案1】:

    我们有同样的问题。我们走了两条路。在一种测试方式中,我们使用您建议的设置和拆卸来创建测试所需的数据(用户、票证等)。在另一种风格中,我们使用数据库中预先存在的测试数据。所以,例如,如果测试是AdminShouldBeAbleToCreateUser,我们不做任何一个,因为那是测试本身。但是如果测试是ExistingUserShouldBeAbleToCreateTicket,我们在测试数据中使用预定义用户,如果测试是UserShouldBeAbleToDeleteOwnTicket,我们使用预定义用户并在设置中创建票证。

    【讨论】:

      猜你喜欢
      • 2015-06-27
      • 2018-07-27
      • 1970-01-01
      • 2019-12-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-02-06
      • 1970-01-01
      相关资源
      最近更新 更多