不能保证或预测初始状态的自动回归的良好策略

情况

我需要开始为具有成千上万用户的大型Web应用程序构建自动回归。无法从已知状态开始，甚至无法确保输入到应用程序中的数据将保存到已知状态。该应用程序是一个薪资输入系统，在该系统中，只有当薪资尚未开始时，所有数据才被读取，并且具有大量的配置选择。

该应用程序不能在具有以下条件的本地数据库上运行本地设置：它需要多个互锁的Web服务（使用-不要问我为什么-系统注册表来确定将结果提交到何处），并且不实用进行重置（数据库刷新可能需要一整天的时间）。多个用户可以访问测试沙箱环境，并以完全改变系统预期行为的方式更改配置。在进行大型项目时，开发沙箱环境经常会停顿几天。

我认为可行的策略

我正在考虑的潜在策略考虑的是：



先设置我的初始条件---有点复杂。我将需要进行几个数据库查询或做一些屏幕快照，以确定公司是否已更改其配置，是否需要启动工资核算运行，将配置更改回应有的状态，然后提交false在使用正确的配置开始全新运行之前运行。这也将使测试结束检查复杂化，因为我将需要查找并丢弃初始提交文件，以便使用我的测试实际输入的数据检查该提交文件的有效性。从好的方面来说，在提交之前保存到待处理事务表中的值以及提交文件的内容将符合预期。

动态结果检查-我的意思是根据我测试时激活的配置标志来检查结果所需的编码要复杂得多，无论它们是否是我期望看到的。我在这里看到的优点是，我无需尝试强制将系统设置为开始时的设置，而我将通过倾斜检查来确定仅在启用某些配置标志时才显示某些字段。另一方面，正确地编写代码要复杂得多，结果也更容易出错。

混合方法-我在其中设置某些键值，但让其余键执行任何操作有人将它们设置为。这将给我每种方法的一些弊端，但可以使我将额外的复杂性限制在无论如何都倾向于移动目标的区域。

其他一些注意事项

我（在使用该系统六个月之后）对系统在何处与Web服务交互（这些都是在-房子，但往往不会得到很大的发展。它们通常也可以从Web应用程序中调用或轮询Web应用程序数据库，因此，在此阶段不单独进行测试。在某种程度上，Web服务是系统不可或缺的，无法仅测试Web应用程序。

编写的应用程序是经典的ASP。没有办法将前端和业务逻辑分开。由于它不是可单元测试的，所以未进行单元测试。虽然有计划用更好的工程系统代替它，但我将对该系统进行至少2年的测试，甚至可能更长。

鉴于这些“有趣的”复杂性，我应该采用哪种方法为该应用程序构建自动回归？

术语更新
响应@ user246，要求澄清我使用的一些术语：



提交错误的运行-我的意思是提交工资单，该工资单只包含配置设置更改，而我实际上不在乎发送什么。

提交文件-这有点复杂。所有计算逻辑和检查生成逻辑都发生在我无权访问的后端服务器中。我到后端服务器的唯一接口是固定长度格式的文本文件：提交文件。使用定义的命名约定为每个工资单提交生成此文件。如果在短时间内为给定客户提交了多个工资单，则很难找到包含我感兴趣的信息的工资单。

待定交易表-在开始之间在进行工资核算运行并提交运行之后，所有发生的事情都会记录到许多数据库表之一中。它们被称为挂起的事务表，因为对配置，工资单和人员数据的更改直到在Web应用程序和后端服务器之间进行了所有同步之后才是最终的。在提交工资核算之前，更改不是永久性的，并且取决于所涉及的逻辑，更改只能存在于挂起的事务表中。