vlambda博客
学习文章列表

我们经常会读到有关测试技术(如TDD)和如何测试应用程序业务逻辑的文章。但是测试应用程序的性能是一个完全不同的问题。你有许多方法可以做到这一点，但是一种常见的方法是设置一个环境，你可以在这个环境中对你的应用程序执行DDoS攻击并观察它的表现。这是一个令人兴奋的话题，但我并不想在这篇博文中谈论它。今天我想介绍一种更简单的测试，你可以使用默认的Django单元测试设置来执行它：测试你的应用程序访问数据库的次数。

这是一件很容易测试的事情，而且它是在很早就会影响应用程序性能的事情之一。这也是我在某些应用程序开始运行缓慢时调查的第一件事情。好消息是，在开始编写这种测试时，你只需要知道一件事:assertNumQueries方法，它使用起来非常简单，这里是一个例子:

上面的代码断言：在"trucks:list_trucks"视图期间，应用程序将只会访问数据库6次。但是还有一点需要注意，在运行此断言之前，我们首先创建一个新的Truck对象，然后我们再断言在该视图的trucks_list上下文数据中有一个对象。在这种测试中，这是一件非常重要的事情，因为它可以确保你没有针对空数据集进行测试。仅仅创建Truck实例还不够，理解这一点是很重要的；你需要检查它是否包含在上下文中。你可能会对该卡车列表数据进行筛选，因此你的Truck实例可能不会被包括在结果中。

通过以上所做的，我们已经取得了显著的进步，但是还有一个重要的步骤是人们经常忘记的。如果我们想让视图进行伸缩，我们需要确保它的性能不会随着它返回的项的数量的增长而下降。毕竟，我们仍然有一个性能问题，如果我们访问数据库6次来获取一个项目的话，但如果我们有100个项目，我们就需要访问数据库106次。我们想要一个固定的数据库访问次数，不论我们正在返回的项的数量是多少。幸运的是，这个问题的解决方案也很简单，我们需要向数据库添加一个(或几个)条目，并再次统计访问次数。下面是该测试的最终版本:

注意，我们再次检查了上下文中返回的项的数量，但是在第二次运行中，我们得到了2个 truck。这里的原因和第一次是一样的。

在添加数据时，确保数据库访问次数不变要比拥有一个低的总访问次数更重要。

最后一件要做的事是确保你的数据尽可能是充足的。这意味着你还需要创建相关的数据，以便在处理视图时使用。如果你不这样做，则存在这样一个风险，你的生产应用程序访问数据库的次数比你的测试预期的次数要多(尽管它可能通过了测试)。在我们的示例中，我们需要为我们的TruckDriver创建一个同伴TruckDriver。

如果在执行上述操作之后，数据库访问次数不再保持不变，请进一步了解select_related和prefetch_related方法。

以上就是今天的全部内容，希望从现在开始，你可以在你的应用程序的早期检查数据库查询的数量。执行这项检查不会占用你太多的时间，而且当你的应用程序的用户数量开始增长时，它将会避免很多麻烦。

英文原文：https://www.vinta.com.br/blog/2020/counting-queries-basic-performance-testing-in-django/ 
译者：一瞬