在接口测试中，经常需要对系统进行分页查询测试。这次遇到了一个bug，就是有关于分页查询测试的。因为分页查询时，每次返回的都是第一页的数据，而我们的测试用例中没有考虑测试比较两页数据是否一致的校验点，因此出现了这个bug。随后，我从接口测试的角度仔细考虑了一下，同时吸取了一些功能测试的建议，感觉在进行分页查询测试时，需要校验的部分还真不少。虽然经常进行这方面的测试，但是还是很容易漏掉其中的某一方面。这次在此小小总结一下～～：
以下page_no代表页码，page_size代表每页数量。一般情况下，page_no和page_size都会有默认值和最大值的限制。
1、正常情况下，测试完成后，page_no和page_size应该返回相应页数的相应条目数据。比如page_no=1、page_size=10，那么正常应该返回第一页的十条数据。这是保证接口可以调通的第一步。
2、对于获取分页的列表元素进行校验。比如每个字段是否与数据库中的字段一致。这种校验可以分为两种情况：如果数据比较少，那么可以每条数据的每个字段都作比对；否则，就随机选择其中的几条数据与数据库进行比对，保证字段正确性即可。而且，在随机选择时，除了一些普通数据的对比之外，一定不能忽略一些特殊数据的校验。否则，出现了BUG也会很难查到哦。
3、这一点要说的，也正是这次的教训。这次在分页查询时，每次返回的都是第一页的数据，因此留下了一个BUG。而自己习惯性地将注意力放在校验数据是否正确这方面来了，认为只要数据正确就没有问题。其实，要避免这个问题也不难，即测试时同时取出两页数据，校验一下这两页数据是否一致，如完全一致就要小心了哦。只有经过这样一丝不苟的校验、测试，才能保证功能的正确性～～。
4、异常的情况，比如page_no和page_size小于0或者为字符的时候，直接返回第一页的默认条数，或者报出错误信息，防止接口抛异常。
5、最后，需要注意的是，作为接口测试人员，不仅要熟悉测试技术方面的问题，而且应该了解清楚该接口应用的业务场景。比如，数据的最大量可能是多少，对于最大数据量调用的时候会不会出现超时或者其他性能方面的问题等等。比如这次某个接口，描述说每页最多1000条数据，但实际情况是取600条的时候已经报超时了。因此，如果不了解接口的应用场景，很可能会留下一些潜在的BUG。
以上是我对分页查询测试的一点小小理解和总结，让自己不再犯同样的错误，也供大家参考参考，希望对大家有所帮助哦～～
