我们目前正在开发一个中型/大型PHP / MySQL项目。我们正在使用PHPUnit＆QUnit进行单元测试，并且有两个全职测试人员正在手动测试应用程序。我们的测试（模拟）数据当前是使用SQL脚本创建的。
我们在维护测试数据脚本方面遇到问题。业务逻辑非常复杂，测试数据中的一个“简单”更改通常会在应用程序中产生多个错误（不是真正的错误，只是无效数据的产物）。由于我们不断创建和更改表，因此这已成为整个团队的一大负担。
我真的看不到在脚本中维护测试数据的意义，因为可以使用UI在大约5分钟内将所有内容手动添加到应用程序中。我们的PM不同意，并说拥有无法使用测试数据进行部署的项目是一种不良做法。
我们是否应该放弃使用测试数据来维护脚本，而只是让测试人员在没有数据的情况下测试应用程序？最佳做法是什么？
Answers:
您正在混合两个不同的概念。一种是验证，它基于单元测试和同行评审。这可以由开发人员自己完成，而无需测试数据，其目的是验证是否满足一组要求。
第二个是验证，这是由质量检查人员（您的测试人员）完成的。对于此步骤，您确实需要测试数据，因为测试人员不需要了解应用程序中的程序，只需了解其预期的用例即可。其目的是验证应用程序在生产环境中的行为是否符合预期。
这两个过程对于向客户交付优质产品都非常重要和必要。您不能仅依靠单元测试。您需要找出一种可靠的方式来处理测试数据以确保其有效。
编辑：好的，我明白了你的要求。答案是肯定的，因为测试人员的工作不是生成测试数据，而只是为了测试应用程序。您需要以一种易于维护的方式构建脚本，并确保插入有效数据。没有测试数据，测试人员将无法测试。话虽如此，但是，如果您可以访问测试环境，我不明白为什么您不能手动而不是使用脚本来插入测试数据。
是的，进行单元测试和数据模型化是最佳实践。项目经理是正确的。由于在测试数据中执行“简单”更改通常会产生错误，因此这就是问题的核心。
该代码需要改进。不这样做（说嘿，我们不需要测试）不是解决办法，只是增加技术负担。将代码分解为更小的可测试单元，因为无法识别而不破损的单元是一个问题。
开始进行重构。保持小的改进，使其易于管理。寻找诸如上帝的课程/方法之类的反模式，而不遵循DRY，单一职责等。
最后，查看TDD，以了解它是否适用于团队。TDD可以很好地确保您的所有代码都是可测试的（因为您首先编写测试），并且可以通过编写足够多的代码来通过测试来确保精简（最大限度地减少工程设计）。
通常，如果一系列复杂的业务逻辑流程产生了一组数据，那么我将其视为报告。封装报告。运行报告，并将结果对象用作下一个测试的输入。
这是一个非常普遍的问题，也是一个非常困难的问题。针对某DATABSE（甚至是内存数据库，如进行自动测试HSQLDB）通常是缓慢的，非确定性，而且由于测试失败只是表明有问题的地方在你的代码或在您的数据，它们是没有太多的信息。
以我的经验，最好的策略是专注于业务逻辑的单元测试。尝试尽可能覆盖您的核心域代码。如果您正确地做到这一点，这本身就是一个挑战，那么您将获得自动化测试的最佳成本效益关系。至于持久层，我通常会花更少的精力在自动化测试上，而将其留给专用的手动测试人员进行。
但是，如果您真的想要（或需要）自动化持久性测试，我建议您阅读Tests指导的Growing Oriented Oriented Software。本书有一整章专门介绍持久性测试。