让我来描述一下场景：针对实时系统进行测试的策略
我们的VB.NET web应用程序通过webservices与第三方数据提供者交谈。它还将数据保存在HUGE SQLServer数据库中，该数据库在存储过程和触发器中实现了广泛的业务逻辑。网络服务提供商还采用相当动态的复杂商业逻辑。
两难的是，web服务提供者和sqlserver基本上都是实时系统，我们公司在正常操作（web和SQL调用）之外不能访问它们。他们都没有提供有用的支持。
此外，webservice没有“测试模式”，所有的调用都被视为实时事务。无法在这些系统中模拟逻辑，也不可能获得sqlserver数据库的副本。
所以，我的问题是：
你怎么做任何类型的测试我们对这些活动的系统VB.NET应用（手动或自动）的？
您的意见，将不胜感激。
让我们首先挑战您的假设“在这些系统中无法模仿逻辑”。
当然，如果你使用正确的工具，你可以模仿行为。您的系统通过数据库对象与数据库交互;您的系统应通过Web服务对象与Web服务进行交互。通过使用适当的模拟框架，这些对象中的任何一个或两个都可以是mocked。对于任何对数据库对象的单元测试调用，您都会为该对象创建一个模拟，设置其调用的期望和结果，然后将该模拟交给代码测试（CUT），而不是“真正的”数据库对象。您的代码调用模拟，然后将其参数与预先设定的期望进行比较，并回传预期结果（而不是实际与数据库通信）。您的代码然后对结果进行操作。如果方法参数与预期不符，则模拟对象将抛出异常。
你可以阅读有关mock对象和单元测试对于.NET这里的文章：
提个醒，工具如NMock和Typemock使工作更容易，但它仍然很难 - 你需要设计你的代码进行测试，而不是先写代码，并祈祷你稍后可以测试它。
您可能想与您的web服务提供商交谈 - 除了简单查询之外，我曾经与之交互的每个第三方web服务都有测试模式（您使用测试凭证和测试服务器，而不是实时服务器）。任何到测试服务器的交易在一天结束时都会被清理干净。如果他们不要提供测试服务和他们的服务涉及的不仅仅是简单的查询，那么我强烈建议找到另一个服务提供商。
在某些情况下，您可以采用另一种策略来处理数据库：使用事务。在单元测试期间打开数据库连接时，请打开一个事务。在每个单元测试结束时，回滚事务。这是一个简单的想法，但恶魔在细节中，如果你搞砸了，并且意外地犯下了交易，将会出现混乱。我不推荐它，但我在一个项目上工作了两年。
这听起来像是在构建一个业务线应用程序：一家公司将在一个地方使用的软件。在这种情况下，测试并不是那么重要。最好的测试人员会发现代码中大约有20％的问题，所以无论您是否测试，您仍然需要做好准备处理生产中的问题。
所以，我会跳过测试，而是专注于强大的脚手架，允许你开发一个可控制的方式对活的服务器应用程序：
我从经验中知道这可以很好地工作。与最终用户的紧密合作使您能够更好地理解他们的需求，并且通常添加他们真正感激的功能。
一句警告：尽管用户会认为你是一个认为完成的人，但企业架构师会认为你是黑客。根据你所在的组织，这可能是非常健康或非常不健康:)