本文来自于淘宝QA，这是第一次看到有这样的贴子，是测试cache的贴子。虽然他不是测试cache本身，但从文中的测试要点来说，还是有借鉴意义的。像他说的：触发点、何时使用cache等都是一个要点。
众所周知，任何一个程序，为了效率，总有部分资料是需要被缓存的。比如，系统配置，这玩意一旦设定，很可能就再也不会修改了（或者说，修改的频率非常低），如果每次都查询数据库，那效率也太低了。所以它应该是被缓存的对象之一。
分类也是应该能够被缓存的，谁TMD有事没事去修改分类、删除分类？一个成熟的网站，分类定下来后，基本也就定下来了，除非更改业务方向，增加业务范围，才会去修改分类。当然还有一种情况，那就是为了促销，人为修改（但这应该不属于分类了啦）所以，分类也应该是被缓存的对象之一。。。
好了不说废话了，看测试是怎么说的吧：
原文：http://rdc.taobao.com/blog/qa/?p=3434
前段时间做了一个cache相关的接口测试，这里要说的并不是测试cache本身，而是测试一个使用了cache的业务系统，该业务系统通过调用另一个专 门提供cache服务的系统来实现数据的cache。也就是说cache服务本身对于我来说是黑盒的。那么在这种情况下，我们应该从哪些方面来考虑测试， 才能够保证业务系统对cache服务的调用是正确的呢？我是从以下几方面考虑的：
一．Cache的触发点
如果一个系统使用了cache，那么它就一定会有cache的触发点，所谓触发点就是会触发cache缓存数据或者更新数据的事件。这些事件往往就是对某 些接口的调用。例如查询数据的时候，如果缓存里没有该数据应该会触发cache来缓存该数据。更新数据的时候，如果缓存里有该数据，应该会触发cache 删除该数据的缓存等等。我们必须要掌握每一个触发点才能够知道如何来设计针对cache的测试，因为我们的目的就是要验证所有的触发点是否都正确的触发了 我们所期望的缓存事件。
二．何时应该使用cache，何时应该使用数据库
掌握了系统中所有的cache触发点之后我们就可以开始设计如何来验证这些触发点了。一般来说，被缓存起来的数据都是供查询使用的，明确了这点之后，其实 归结起来，我们只需要考虑两个问题：一是何时应该查询cache中的数据，二是何时应该查询数据库中的数据。
举例来说，一个典型的使用了cache的查询接口应该是这样的，当查询数据的时候，接口会首先去缓存中查找数据，如果缓存中没有数据，再去数据库中查找， 如果在数据库中找到了指定的数据，它会在返回数据的同时，对该数据做缓存处理。了解了这个过程之后，你可以先通过直接插数据库的方式准备一条数据，这个时 候该数据是没有缓存的，因为没有触发缓存数据的事件发生，那你如何来验证这个数据确实没有缓存呢？很简单，直接把该数据从数据库删除掉，再调用查询接口查 询该数据，如果没有查询到，说明该数据确实没有被缓存。另外一方面，你还应该保证如果数据被查询到了，那么它就应该被缓存起来，这个时候你同样可以直接删 除数据库中的数据，再次查询该数据，如果可以查询到，那么就说明它确实是被缓存起来了。总的来说就是了解缓存过程，分解过程，保证过程的每一步结果都是所 期望的，这就有别于通常的接口测试只关注输入和最终的输出结果了。它的思想和切面编程的思想有点类似，也许我们可以把这种测试方法叫做切面测试。
三．多触发点联合测试
在保证了每个触发点的正确性之后。我们还应该进一步把这些触发点按照实际的业务场景串联起来测试。例如，可能会有这样一个业务场景：生成数据→查询数据→ 编辑数据→查询数据→删除数据→查询数据。值得注意的是对于这样的联合测试除了保证每个步骤的结果都正确的同时，我们应该尽量采用调用业务系统接口的方式 来完成每一步，尽量避免直接操作数据库，因为这样更能模拟出真实的调用场景。
不同的cache方式会有不同的测试方法，以上仅是我在测试特定cache的时候的一些想法，仅供参考。如果你测试过cache，不妨也来说说你自己的测试方法，如果你没有测试过cache也可以来谈谈自己的想法。
