前段时间做了一个cache相关的接口测试，这里要说的并不是测试cache本身，而是测试一个使用了cache的业务系统，该业务系统通过调用另一个专门提供cache服务的系统来实现数据的cache。也是说cache服务本身对于我来说是黑盒的。那么在这种情况下，我们应该从哪些方面来考虑测试，才能够保证业务系统对cache服务的调用是正确的呢？我是从以下几方面考虑的：

一.Cache的触发点

如果一个系统使用了cache，那么它一定会有cache的触发点，所谓触发点是会触发cache缓存数据或者更新数据的事件。这些事件往往是对某些接口的调用。例如查询数据的时候，如果缓存里没有该数据应该会触发cache来缓存该数据。更新数据的时候，如果缓存里有该数据，应该会触发cache删除该数据的缓存等等。我们必须要掌握每一个触发点才能够知道如何来设计针对cache的测试，因为我们的目的是要验证所有的触发点是否都正确的触发了我们所期望的缓存事件。

二.何时应该使用cache，何时应该使用数据库

掌握了系统中所有的cache触发点之后我们可以开始设计如何来验证这些触发点了。一般来说，被缓存起来的数据都是供查询使用的，明确了这点之后，其实归结起来，我们只需要考虑两个问题：一是何时应该查询cache中的数据，二是何时应该查询数据库中的数据。

举例来说，一个典型的使用了cache的查询接口应该是这样的，当查询数据的时候，接口会首先去缓存中查找数据，如果缓存中没有数据，再去数据库中查找，如果在数据库中找到了指定的数据，它会在返回数据的同时，对该数据做缓存处理。了解了这个过程之后，你可以先通过直接插数据库的方式准备一条数据，这个时候该数据是没有缓存的，因为没有触发缓存数据的事件发生，那你如何来验证这个数据确实没有缓存呢？很简单，直接把该数据从数据库删除掉，再调用查询接口查询该数据，如果没有查询到，说明该数据确实没有被缓存。另外一方面，你还应该保证如果数据被查询到了，那么它应该被缓存起来，这个时候你同样可以直接删除数据库中的数据，再次查询该数据，如果可以查询到，那么说明它确实是被缓存起来了。总的来说是了解缓存过程，分解过程，保证过程的每一步结果都是所期望的，这有别于通常的接口测试只关注输入和终的输出结果了。它的思想和切面编程的思想有点类似，也许我们可以把这种测试方法叫做切面测试。

三.多触发点联合测试

在保证了每个触发点的正确性之后。我们还应该进一步把这些触发点按照实际的业务场景串联起来测试。例如，可能会有这样一个业务场景：生成数据→查询数据→编辑数据→查询数据→删除数据→查询数据。值得注意的是对于这样的联合测试除了保证每个步骤的结果都正确的同时，我们应该尽量采用调用业务系统接口的方式来完成每一步，尽量避免直接操作数据库，因为这样更能模拟出真实的调用场景。

不同的cache方式会有不同的测试方法，以上仅是我在测试特定cache的时候的一些想法，仅供参考。如果你测试过cache，不妨也来说说你自己的测试方法，如果你没有测试过cache也可以来谈谈自己的想法。