我目前正处于从客户网站解析数据的环境中。我想使用我的测试来确保当客户改变他们的网站时，我知道我们什么时候不再收到这些信息。
我的第一个方法是进行纯粹的集成测试，我的测试点击客户端的网站并断言已找到数据。然而，在中途和500次测试中，测试运行变得无法忍受，并且在某些情况下开始超时。因此，我清除了尽可能多的测试，而不会失去他们提供的核心保护，而我已经降到350左右。我只是害怕添加更多测试才能打破所有测试。我发现自己不再运行5分钟以上（有些客户端会因为基于与网站的通信速度而变长）。我认为这完全失败了。
我一直在考虑这个并在办公室周围询问，我对下一次尝试的想法是拉下客户端的页面并在我的项目中针对这些嵌入式资源编写测试。这将给我更高的测试覆盖率，让我可以单独回到测试阶段。但是，我需要在进行更改时收到通知，然后重新下拉页面进行测试。我认为客户不会坚持这一点。
我建议使用一套“随机”集成测试来增强这一功能，这些测试与我失败的测试（访问客户端站点）具有相同的功能，但数量比之前少得多。我真的不喜欢随机测试的想法，有时可能会获得红灯，有时可能会使用相同的代码获得绿灯。但到目前为止，这听起来像是我听到的最好的想法，仍然可以了解客户端网站何时发生变化，而我的代码不再能够找到数据。
有没有人发现自己正在测试这样的环境？测试社区给我的任何建议？
答案 0 :(得分：0)
当您说大测试变得无法忍受时，它表明您手动运行此测试套件。你不应该这样做。它应该在后台持续运行，无论以何种速度完成套件 - 然后重新开始（如果有相关成本，可能会延迟）。只有在出现问题时才能收到警报。
如果您的测试中有某些因素导致它们的数量增长变慢 - 找到并修复它。测试应该彼此独立，因此只需要更多测试就不应该导致单个测试超时。
答案 1 :(得分：0)
我的建议是尝试尽可能地分离处理不确定性的代码部分。此部分应该是一个API，作为所有其他代码使用的服务。这样，您可以保护大多数代码免受更改。
代码的稳定部分应进行单元测试。由于该部分独立于与客户端站点的连接，因此测试应该更快，并且还可以使这些测试更可靠。
可以减少必须处理客户网站上的更改的部分。这样您就无法解决问题，但至少您要将其最小化并将其集中在代码的一个模块中。
建议客户将数据公开为Web服务，这对您来说是最好的。但我想这并不取决于你：P。
答案 2 :(得分：0)
您应该考虑将测试分开，也可以分成可以独立运行的独立程序集。我通常有一个单元测试组件和一个运行速度较慢的集成测试组件。
我的单元测试程序集非常快（因为代码是使用模拟单独测试的）并且在我开发时会非常频繁地运行。集成测试速度较慢，我只在完成功能/签入时才运行它们，或者我对打破某些内容感觉不好。
也许你可以做类似的事情，甚至可以进一步采用这个想法，并拥有3个测试套件，第三个包含更慢的客户端UI轮询测试。
如果您没有持续集成服务器/进程，则应该考虑设置一个。这将持续构建您的软件并执行测试。这可以设置为监视签入并在后台工作，如果有任何失败则发送通知。有了这个，您就不会关心客户端UI轮询测试需要多长时间，因为您不必自己运行它们。
答案 3 :(得分：0)
绝对将测试分开 - 至少将单元测试与集成测试分开。
正如Martyn所说，建立一个持续集成系统。我使用的Teamcity非常好，易于使用，前20个版本免费使用，如果你没有服务器，你可以在自己的机器上运行它 - http://www.jetbrains.com/teamcity/
设置一个构建以在每次签入时运行，并使该构建运行单元测试，或者运行快速运行的测试。
设置第二个版本在每晚午夜（或其他方便的时间）运行，并在此包含更长时间运行的客户端调用集成测试。有了这个，测试需要多长时间并不重要，如果你的客户破坏了你的东西，你会在早上得到一个大红旗。如果您怀疑可能存在问题，也可以按需手动运行这些。