我正在为一个网站制定测试计划，其中一些测试采用以下路径：
- 点击请求的 URI 并获取在某个表中呈现的数据（每页 20 行）。
- 进行数据库查询以获取应该在该表中呈现的数据。
- 逐行比较2个数据，它们应该匹配。
这是进行功能测试的正确方法吗？如果该请求是 Ajax 请求，那么答案又是什么？集成测试的答案会有所不同吗？
我有一些理由让我相信这在某种程度上是错误的......仍然需要你们的意见！
问问题
161 次
4 回答
1
这对于功能测试来说似乎很好。在我看来，集成测试与测试应该协同工作的不同技术或组件有关，这通常比功能测试更广泛。但是当然，这种测试也可以被认为是集成测试，这取决于你的应用程序是如何组合在一起的，以及测试在你的开发生命周期中发生的位置。例如，为了使该站点正常运行，您可能必须将一些独立开发的组件放在一起；这可能是验证集成是否有效的测试之一。
看不出这是否是 Ajax 与使答案不同有什么关系。
于 2009-12-15T16:05:15.523 回答
1
我可能会在这里持不同意见，但我不认为这是一个富有成效的测试。您所做的只是复制生成页面的代码。任何时候你引入重复的代码（甚至跨部门），你都会看到长期出现的缺陷。
最好用已知数据（通过应用程序或直接）加载数据库，然后检查输出是否符合您的预期。这还可以确保您的数据库层或数据库本身没有以您不期望的方式修改数据。
那是：
- 加载已知数据（最好通过应用程序本身）
- 加载请求的 URI
- 检查显示的数据是否与您的已知数据匹配
于 2009-12-18T09:34:12.893 回答
1
是的，这可能是一个富有成效的测试。要么你有一个固定的数据集，要么你没有。
如果你有一个固定的数据集，这更容易测试，因为你所做的只是与一个固定的输出进行比较。
如果您没有固定的数据集，那么您需要复制业务逻辑，有效地复制开发人员已经完成的工作。然后你有两组逻辑要维护。
第二种是最好的方法，因为你有两种方法可以做同样的事情，实际上是对规范和代码的同行评审。它在时间和资源方面也非常昂贵，这就是为什么大多数人选择拥有固定数据集的原因。
回答你的问题，如果你在查询中的业务逻辑很简单，那么你可以很容易地得到一个测试。但是，测试带来的价值并不大，因为您没有进行太多测试。
如果业务逻辑很复杂，你会从测试中获得更多价值，但从长远来看，它会更难维护。
对我来说，你的测试带来的是一个简单的集成测试，证明系统从数据库中正确读取，并正确显示数据。这是一个很好的测试，如果它是自动化的会更好。
于 2009-12-18T09:57:26.177 回答
1
如果数据库和最终用户的显示之间没有太多的开发人员逻辑，这种测试可以很好地以相对较少的测试人员工作量测试大量数据。我们的团队已经多次这样做了，这对于通过我们的测试运行大量真实生产数据以确保按预期处理实际场景特别有用。请确保您至少对罕见的场景进行了一些固定的输入测试，这些场景可能特别有可能在数据库和网页上以不同方式处理 - 空值、特殊字符和其他奇怪的东西。
就个人而言，我将其称为“集成测试”，因为您正在测试数据库和网站的集成，而不是“功能测试”。对于“功能测试”，我可能想要模拟数据源（例如，数据库），它将以您期望的格式提供预先编写的数据集。
话虽如此，如果我对 DB 数据的有效性有很高的信心，如果 DB 查询和网页显示之间的逻辑非常小且风险低，我可能不会理会 mock，而会让集成测试也涵盖了功能。在这种情况下，我不知道单独测试功能和集成是否会带来巨大的质量胜利，并且您可能可以利用可用的测试时间做更好的事情。如果围绕这些数据有很多逻辑，您可能应该将集成与功能分开测试。额外的集成测试可能包括诸如“如果无法访问数据库怎么办？”之类的内容。和“如果数据库很慢怎么办？”。
虽然这种技术适用于 Ajax，但请确保您的测试工具适用于 Ajax。具体来说，考虑如何捕获数据库查询结果以及如何收集网页上显示的结果。
我假设查询中数据的有效性正在其他地方进行测试，因为您提到这只是测试计划中的一种测试。我也只是讨论与数据库和此报告的集成，而不是其他功能或组件，而不是测试的其他方面（性能、安全性等），因为那是您问题的范围。
于 2010-11-30T19:37:07.127 回答