在功能测试中，我是否应该将浏览器中呈现的所有表格数据与来自数据库的表格数据进行比较？
我正在为一个网站制定一个测试计划，其中一些测试采用以下路径：
- 点击请求的 URI 并获取在某个表中呈现的数据（每页 20 行）。
- 进行数据库查询以获取应该在该表中呈现的数据。
- 逐行比较2个数据，它们应该匹配。
这是进行功能测试的正确方法吗？如果该请求是 Ajax 请求，那么答案是什么？集成测试的答案会有所不同吗？
我有一些理由让我相信这是错误的......仍然需要你们的意见！
I'm working on a test plan for a website where some tests are taking the following path:
- Hit the requested URI and get the data rendered inside some table(20 rows per page).
- Make a database query to get the data that is supposed to be rendered in that table.
- Compare the 2 data row by row, they should match.
Is that a correct way of doing functional testing? If that request was an Ajax request, what will be the answer also? Would the answer differ for integration testing?
I have some reason that makes me believe that this is wrong somehow.... still need your opinions guys!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，这可能是一个富有成效的测试。您要么有固定的数据集，要么没有。
如果您有固定的数据集，则测试起来会容易得多，因为您所做的只是与固定输出进行比较。
如果您没有固定的数据集，那么您需要复制业务逻辑，有效地复制开发人员已经完成的工作。然后你需要维护两组逻辑。
第二种是最好的方法，因为您有两种方法可以做同一件事，即有效地对规范和代码进行同行评审。它在时间和资源方面也非常昂贵，这就是为什么大多数人选择拥有固定数据集的原因。
回答你的问题，如果你的查询中的业务逻辑很简单，那么你可以很容易地得到测试。然而，测试带来的价值并不大，因为你没有进行太多测试。
如果业务逻辑很复杂，您将从测试中获得更多价值，但从长远来看，维护起来会更加困难。
对我来说，你的测试确实带来的是一个简单的集成测试，证明系统正确地从数据库读取数据，并正确地显示数据。这是一个很好的测试，如果是自动化的就更好了。
Yes, this could be a productive test. Either you have a fixed data set or you don't.
If you have a fixed data set, this is much easier to test, because all you're doing is comparing against a fixed output.
If you don't have a fixed data set, then you need to duplicate the business logic, effectively duplicating the work already done by the developer. Then you have two sets of logic to maintain.
The second is the best approach because you get two ways of doing the same thing, effectively a peer review of the specification and code. It's also very expensive in terms of time and resources, which is why most people choose to have a fixed data set.
To answer your question, if your business logic in the query is simple, then you can get a test very easily. However, the value that the test brings isn't great, because you aren't testing very much.
If the business logic is complex, you are getting more value from the test, but it's going to be harder to maintain in the long term.
For me, what your test does bring is a simple integration test that proves that the system reads correctly from the database, and displays the data correctly. This is a good test, even better if it is automated.
这对于功能测试来说似乎很好。在我看来，集成测试与测试应该协同工作的不同技术或组件有关，这通常比功能测试更广泛。当然，这种测试也可以被视为集成测试，具体取决于应用程序的组合方式以及测试在开发生命周期中的位置。例如，为了使该网站正常运行，您必须将一些独立开发的组件组合在一起；这可能是验证集成是否有效的测试之一。
不明白这是否是 Ajax 与使答案不同有什么关系。
This seems fine for functional testing. Integration testing in my mind has to do with the testing of different technologies or components that are supposed to work together which is generally broader than functional testing. But of course this sort of testing could also be considered integration testing, depending on how your application is put together and where the testing is happening in the lifecycle of your development. For example it may be that in order for this site to work you have to put together a few components that were developed independently; this might be one of the tests to validate that the integration works.
Don't see how this being Ajax or not has anything to do with making the answer different.
我可能会在这里提出反对意见，但我不认为这是一个富有成效的测试。您所做的只是复制生成页面的代码。每当您引入重复的代码（甚至跨部门）时，您都会看到长期出现的缺陷。
最好使用已知数据（通过应用程序或直接）加载数据库，然后检查输出是否与您的预期相符。这还可以确保您的数据库层或数据库本身不会以您不期望的方式修改数据。
即：
I will likely be a dissenting opinion here, but I don't consider this to be a productive test. What you are doing is simply duplicating the code which produces the page. And any time you introduce duplicated code (even across departments) you'll be looking at defects cropping up long-term.
It is far better to load the DB with known data (either through the app, or directly) and then check that the output matches what you'd expect. This also ensures that your DB layer, or DB itself, hasn't modified the data in a way you do not expect.
That is:
如果数据库和最终用户的显示之间没有太多的开发人员逻辑，这种测试可能适合用相对较少的测试人员工作来测试大量数据。我们的团队已经多次这样做了，这对于通过我们的测试运行大量实际生产数据以确保实际场景按预期进行处理特别有用。请确保您至少对罕见的情况进行了一些固定输入测试，这些情况特别有可能在数据库和网页上以不同的方式处理 - 空值、特殊字符和其他奇怪的情况。
就个人而言，我将其称为“集成测试”，因为您正在测试数据库和网站的集成，而不是“功能测试”。对于“功能测试”，我可能想要模拟数据源（例如数据库），它将以您期望的格式提供预先编写的数据集。
话虽如此，如果我对数据库数据的有效性有很高的信心，并且如果数据库查询和网页显示之间的逻辑非常小且风险较低，我可能不会费心进行模拟并让集成测试也涵盖了功能。我不知道在这种情况下，单独测试功能和集成是否会取得巨大的质量胜利，并且您可能可以利用可用的测试时间做更好的事情。如果此数据有很多逻辑，您可能应该与功能分开测试集成。额外的集成测试可能包括诸如“如果无法访问数据库怎么办？”之类的内容。和“如果数据库很慢怎么办？”。
虽然此技术适用于 Ajax，但请确保您的测试工具适用于 Ajax。具体来说，考虑如何捕获数据库查询结果以及如何收集网页上显示的结果。
我假设查询中数据的有效性正在其他地方进行测试，因为您提到这只是测试计划中的一种测试。我也只是讨论与数据库和此报告的集成，而不是其他功能或组件，也不是测试的其他方面（性能、安全性等），因为这就是你问题的范围。
This kind of test could be good for testing a large set of data with relatively little tester effort if there is not much developer logic between the database and the display to the end user. Our team has done this on a number of occasions, and it is especially useful for running large quantities of real production data through our tests to be sure that actual scenarios are handled as expected. Do make sure you do at least a little fixed input testing for rare scenarios that might be especially likely to be handled differently in the DB and on the web page - null values, special characters, and other oddities.
Personally, I would call this "integration testing", since you are testing the integration of the DB and the web site, and not "functional testing". For "functional testing", I'd probably want to make a mock of the datasource (e.g., the database) that will provide pre-written sets of data in the format you expect.
Having said that, if I had high confidence in the validity of the DB data and if the logic between the DB query and the web page display was very small and low-risk, I would probably not bother with the mock and would let the integration test cover the functionality as well. I don't know that testing the functionality and integration separately would be a big quality win in this case, and there are likely better things you could do with the available testing time. If there is a lot of logic around this data, you should probably test the integration separately from the functionality. Additional integration testing would probably include things like, "What if the database can't be reached?" and "What if the database is slow?".
While this technique will work with Ajax, make sure your testing tools will work with Ajax. Specifically, think about how you will capture the database query results and how you will gather the results displayed on the web page.
I'm assuming that the validity of the data in the query is being tested elsewhere, since you mentioned that this was just one type of test in the test plan. I'm also just discussing integration with the database and this report and not other features or components, and not other aspects of testing (performance, security. etc.), since that was the scope of your question.