我的应用程序除其他外，使用一些抓取工具来读取另一个应用程序通过远程xml提要公开的信息（我们对此不负责任）。稍后会向用户显示已爬网的数据。 xml可能包含简单数据和链接，如果需要其他数据，我们会遵循这些数据和链接。
我们系统中的测试都是单元测试，测试我们正确解析xml文档，以及验证测试，用于测试我们在ui中显示的内容。
我是在接受验收测试，而这就是这个问题的关键所在。 现在，对于每个验收测试，我们带来一个嵌入式http服务器，它提供一些特定于测试的测试数据。然后我们启动我们的应用程序，我们抓取测试数据并验证测试的标准。虽然这种方法具有从头到尾测试整个系统的优势，但每次添加新的验收测试时，它还会产生大大增加构建时间的副作用。
这是接受测试的正确方法吗？ 我想知道，由于提供订阅源的系统是外部系统，在单元级别测试网络通信层和爬行器并且假设数据已经被爬行时运行验收测试是不是更好？
我想听别人的想法。 ： - ）
谢谢！
答案 0 :(得分：3)
验收测试确实倾向于运行缓慢，需要更多设置，并且往往比单元测试或集成测试更脆弱。如果你在网上搜索＆＃34;测试金字塔＆＃34;你会发现很多这方面的信息。普遍的共识是，您应该在单元，集成和验收级别进行测试。大多数测试都是单元测试，只有少数验收测试可以进行端到端的测试。通常，开发团队会将他们的ci服务器设置为仅在其每晚构建过程中运行任何长时间运行的验收测试，这样它们就不会影响单元测试运行的性能。
答案 1 :(得分：0)
我同意Andrew所写的内容，但我想在答案中添加一个不同的角度，我认为在这种讨论中经常会错过这个角度。
您的团队正在构建产品，您的公司希望通过这项努力获得最佳性价比。
一开始你可能认为测试会让你失望 - 你的系统很简单，每个人都理解它，所以为什么要浪费时间。通过编写测试，你可能觉得自己没什么价值。但是，如果您采用产品开发的长期视图，这显然是错误的。但我会在这里停下来，因为我正在向皈依的人宣讲。
但是，如果您在尝试回答问题时采用相同的心态，您会发现实际上答案很大程度上取决于您的情况。我将使用一个相当简化的数学模型来解释我的想法：
如果您运行P(bug | test)，则bug表示test的概率，让C(test)表示运行测试的费用，并让C(bug) }表示错误的成本。
如果您专注于特定的错误*，您希望最小化以下内容：
P(bug | test_1)*C(bug) + C(test_1) ... P(bug | test_n)*C(bug) + C(test_n)
您的套件包含n个测试。
如果你忽略测试成本，显然你拥有的测试越多越好？但由于测试需要维护，执行等，因此它们的成本非零。这意味着你需要权衡，最后你在这里进行U曲线优化（有点像picture，他们试图找到释放和持有成本之间的最佳权衡）。 / p>
实际成本在很大程度上取决于特定的域，产品领域和测试类型。
如果你在银行业，那么一个bug的成本可能是巨大的，所以它会使测试成本相形见绌。但是，如果您正在为音乐编写推荐引擎，那么关闭几小时的建议将不会成为问题。实际上，在后一种情况下，您可能希望自由地尝试不同的算法和快速迭代的能力，因此测试的成本可能会过度削弱错误的成本。
让我们说你在一个特定的产品上工作。即使这不是同质的。您的产品中有些区域比其他区域更重要。以Twitter为例，如果一个人不能发推文或加载他们关注的人的推文将是一个大问题。另一方面，如果＆＃34;谁跟随建议＆＃34;是空的，对产品的影响会小得多。
最后，测试成本也不统一。但正如我先前所说，它不可忽视，需要谨慎考虑。我在两个测试覆盖率都很差的地方工作，因为他们没有信心将他们的变化推向生产，而且在测试运行时间很长以至于人们抱怨他们不断建设并且几乎不工作的地方。
最后一件事。建立具有弹性以防止故障的好处 - 将降低您的错误成本。
