质量检查人员如何测试他们看不到的缓存逻辑？

我刚刚在Web应用程序中实现了一个缓存层，现在我想知道QA应该如何测试它，因为缓存对用户是透明的。

我的一个想法是将登录记录在调用填充缓存的代码的方法中，并记录何时从缓存中提取对象以及何时需要从数据库中重新创建对象，然后测试人员可以查看日志以查看是否，例如，每隔10分钟就会从数据库中重新加载某个对象，而不是每一次页面浏览。

但是有人可以针对这种情况提出一些更好的做法吗？

一个问题是，缓存本身是否真的应由质量检查部门进行测试。缓存可以提高性能，因此他们可以测试性能差异，以确保满足某些要求。

但是最好对缓存进行测试，无论谁负责。我们使用了性能计数器。如果您的缓存系统利用了这些优势，那么它们很简单。如果有任何方法可以从缓存本身获取计数，那是另一种选择。

使用您的方法也很好。如果将其中任何一项包装在检查结果的自动测试中，则无需查看日志即可找到答案。

您实现了一个缓存（我认为）是因为系统性能不够好。那是与用户相关的东西。质量检查可以检查的内容如下：

• 引入缓存后，系统仍然正确。这意味着他们应该尝试欺骗缓存以提供过时的数据（QA可以对此进行验证），并确保没有其他问题被破坏。
• 系统现在满足性能阈值，即您决定提高性能时未达到要求。他们可以比较旧的度量并将它们与新的度量进行比较。

请记住，用户（以及扩展的质量检查）并不关心您如何解决问题。他们只关心问题已解决，而没有创造新的问题。无论您实施了缓存，改进了String解析，进行了硬件升级还是在服务器上撒了魔幻仙子，这都是事实。

在黑盒中深埋重要的业务逻辑或系统状态使验证正确的系统行为变得困难。详尽测试系统中单个组件的行为要比整个系统容易。我喜欢通过某种机制显式地公开这些东西，以便可以某种有意义的方式对其进行单元/回归/集成/ QA测试。

缓存的一种选择是公开一个特殊页面，该页面提供有关缓存的一些详细信息（内容，状态等）。这可以帮助调试开发以及潜在地进行生产。如果提供了有关高速缓存预期行为的详细信息，QA也可以使用此页面为高速缓存创建测试用例。使用性能计数器和/或日志文件显式记录缓存行为是另一种不太明显但可行的方法。

请注意，这种方法不能替代端到端性能测试。这是确保缓存本身行为正确的机制。应该使用性能测试来确定缓存是否对性能产生了预期的影响。

还要注意，用实现相同接口的新组件（例如引入缓存）替换系统的组件可能会造成不稳定和看似复杂的变化。在缓存示例中，您正在以以前无状态的状态引入状态，这会创建难以发现或重现的错误。此类更改应始终伴随完整的回归测试，以验证预期的系统行为。

测试性能，如安迪的答案所示。

我发现，在许多组织中实现缓存（和性能）的最大障碍实际上是拥有一个环境，您可以在其中进行良好的性能测试并针对各种实际负载和性能测试运行测试。

为此，您应该建立一个性能测试环境，该环境应尽可能接近并考虑到成本，以反映生产。这可能不是您当前的开发环境，它应该更小，更独立，以便快速进行应用程序开发。开发环境还倾向于使用较少的缓存，因此不能很好地进行生产以进行性能测试。

在性能测试环境中，应用程序应以生产“模式”运行。如果进行生产，则应该使用多个服务器，并且应为生产环境设置数据库连接池和缓存等。

您还需要考虑一种有助于负载测试的工具。
jmeter非常受欢迎，尽管我发现它非常不友好且无法使用。
我使用的另一种方法是curl使用ruby脚本仅对url 进行编码。

要清楚

• 基准性能测试用于测试一个请求的时间。
• 负载测试与性能测试类似，但是在系统也受到其他请求的负载时着眼于响应。

您可能还会发现以下链接有用：

• 大量使用缓存的单元测试方法的最佳做法？
• 缓存的负载测试方法
• 有什么方法可以测试网站在负载下的性能如何
• http://www.procata.com/cachetest/

请记住要让测试人员重启服务器，并检查他们输入的数据是否仍然存在。我看到一个系统经过了许多人的几个月的测试，但这样做失败了！

最难测试的部分是，无论数据如何更新，缓存都永远不会返回任何过时的结果。

通过始终使用缓存中的数据填充用户进行更改后看到的确认页面，可以部分地帮助您。例如，不要使用您用来更新数据库的对象，而是从高速缓存中请求数据，然后从高速缓存中请求数据。速度稍慢，但更可能更快地发现错误。

实际上，这是一个非常简单的答案，它与缓存的级别有关。当缓存正确时，您将观察到请求的目标处没有请求。因此，归结为“期望的结果”这个质朴的质量检查短语。

如果在Web层上实现缓存，那么我希望受缓存的项目对于每个经过测试的用户会话只会显示一次（如果实现客户端缓存），对于多个用户只会出现一次（如果实现CDN样式缓存）。如果您正在数据层上实现高速缓存以获取常见结果，那么我希望您的高速缓存层中看到较高的高速缓存命中率，并且在数据层的配置文件日志中没有查询。

等等...

程序员（也许是编写代码的人）使用单元测试可以更好地测试某些东西。测试缓存代码的正确性就是其中之一。（从您提出这个问题的方式出发，我假设您的质量检查人员将应用程序视为“黑匣子”，并通过其外部接口对其进行测试。）

缓存逻辑是开发人员应该进行单元测试的内容，因为质量检查主要是进行黑盒测试。

QA只关心性能方面或您实施的任何修复，您可以为QA提供启用/禁用缓存的机制或您用来提高性能的任何机制，然后他们可以验证性能差异。当然，质量检查人员也可以对照性能改进版本来验证旧版本。

当我测试缓存解决方案时，我们已经实现了，然后我们基本上测试了性能。我们已经完成了针对XML结果的缓存解决方案，并且在缓存之后，它花费非常少的时间来给出响应。此外，我们还通过检查日志条目将其与服务器日志一起检查。