设计CRUD测试套件

Question

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

基本上，它是一个简单的CRUD系统。为了论证，我们看到您正在测试屏幕以创建，查看，编辑和删除用户帐户。我喜欢做的是编写一个测试，用于测试用户创建是否正常工作，另一个测试用于检查查看用户是否显示与您最初输入的数据相同的数据，另一个用于检查编辑的测试用户工作，最后是删除用户的测试。

问题是，如果我这样做，那么测试必须以某种顺序运行，否则它们将无法运行。 （例如，您无法删除尚未创建的用户。）现在有人说测试设置应该创建测试所需的所有内容，并且拆除应该使系统恢复到一致状态。但想想看......创建用户测试后来需要删除该用户，删除用户测试必须先创建一个用户...所以这两个测试现在有相同的代码，唯一的区别是该代码是否在setup / body / teardown中。这似乎错误。

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

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

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

现在，如果这是 white-box 测试，我可以模拟用户帐户对象，或者模拟包含它们的数据库，甚至可以在磁盘上生成真实数据库。但这些是黑盒测试，它只测试外部的用户可见界面。 （即，点击屏幕上的按钮。）想法是从头到尾测试整个系统，而不是修改它[显然除了通过GUI命令]。

Answer 1

我们有同样的问题。我们走了两条路。在一种测试方式中，我们建议您使用设置和拆解来创建测试所需的数据（用户，票证等）。在另一种风格中，我们使用数据库中预先存在的测试数据。因此，例如，如果测试是AdminShouldBeAbleToCreateUser，我们不会执行其中任何一项，因为这是测试本身。但是如果测试是ExistingUserShouldBeAbleToCreateTicket，我们在测试数据中使用预定义的用户，如果测试是UserShouldBeAbleToDeleteOwnTicket，我们使用预定义的用户并在设置中创建票证。 / p>