一、现象：

公告的列表中，显示了翻页，但翻到第二页，报了系统错误。

二、排查思路

试着重现问题，走到系错误的报错时，打开控制台或者抓包，找到对应的接口请求和返回情况，通过接口的请求和返回，去找是端侧调用的入参有问题，还是后端处理的接口返回有问题。

通过查看接口情况，发现接口的返回如下，count数：19，list里只有1个

那到底是哪一端的问题呢？

先来了解一下前端开发实现分页的逻辑，前端开发通过count返回数来决定是否分页，通过List 返回的对象决定展示的每一页具体内容。通常情况下前端页面可以按10页，20页面去分页，假设是10个一分页，那19条数据应该分两页，然后在向每个10页去填充List里的内容，但是List的数据只有一条，所以第二页就报错了。那么可以看出来，后端返回的count和List数不一致了。

此时，作为后端的测试，可以去sql查询一下，为何count会返回为19条而list只有一条，可能的情况是count没有去掉删除的数据，还有一种情况是List 聚合的数据中可能有错误所以未返回，当然以查询到的结果为准，然后就可以给开发提一个bug了。

对于后端测试同学的一个反思就是，1、后续测试用例里，对于分页的场景，可以把这个校验点考虑进去 2、自动化测试的校验可以加上count和list 数据返回一致的校验，3、根据最终的原因，补充到历史用例里，例如是删除的数据count里没有去掉，那么删除后list的展示是需要补充的用例点。

另外开发修复时，要和开发对修复的方案是怎么样的，以免引入新的问题。一旦Bug Fixed了可以合理地设计回归的场景。

作为前端的测试，或者前端的开发，如果系统要健壮和易用，是要考虑异常场景，就是一旦后端程序出错（要假设上游不可靠），需要考虑是否引发以下问题：

1、会引起前端的崩溃，例如数据越界、空指针之类

2、分页数据业务属性很重要，没有返回会造成用户的误解和紧张，例如金融业务，资产等，无法正确的展示、导致无法正常的操作。此时还需要交互引导，是否可以去其他地方查看操作，以免用户的正常业务无法进行。或者引导联系客服之类。

3、无大的影响，可以看情况给出合理的提示

此时，作为前端的测试同学和前端开发根据业务的重要程度，给出合理的错误引导。

如果是端到端的测试，能分别从前后端考虑到影响点，就非常不错了。

三、研发流程角度

最后从研发流程的角度：

1、对开发的要求，分页应该是一个通用的场景，应该有统一的处理方案，开发内部统一处理方式，举一反三去自查其他业务场景是否也有类似问题。

2、对于测试：

a. 补充测试用例，自动化脚本补充场景和校验点，作为回归case，一旦开发再出现这种问题，回归脚本可以帮助发现，这是一种经验的总结。

b. 后续要引导开发加强自测，这类情况作为自测要通过的点，分页的通用测试点可以梳理出来。

c. 可通过代码review，了解开发在此处处理是否有其他问题。

3、对于需求和交互，需要举一反三，给出通用场景的通用处理方案，后续在这种地方，无需单独评审。

以上actions，我认为是通过问题的总结，减少了后续反复踩坑的情况，提高研发效率。

四、对于测试同学的启示

作为测试同学的你，可以做到哪个层次。