先说说列表
在如今的大数据浪潮下，列表作为一个方便用户进行数据查阅及快速筛选的功能，几乎每个产品都会有。如下图所示：
也许有人会说了，测试列表页面看起来就是一个普通的页面，根据业务需求验证一下内容、看下分页及每页的数量、试一试筛选、做做功能和边界值测试等等不就行了吗？其实不然！虽然看似刚才说的验证点覆盖了列表的全部功能，但是还是有很多细节需要我们深入的了解和测试的。
测试提升
测试列表页，我们可以从业务需求合理性、前端页面功能、后台接口实现三方面来分析出测试提升的点，分别为：需求合理性、性能、排序、筛选、搜索、分页等
需求合理性
需求合理性是最早需要关注的点。由于需求是早期产品评审时做的，表面上还没有进入技术，所以很多开发测试人员并没有重视；但正是因为它是最早期的一环，恰恰才是最重要的，因为它如果出问题就会带来下面几个点的连锁问题。
我见过很多列表需求，产品（或者客户）希望列表中每个条目显示的数据越多越好。这个要求看似合理，但是无论从UI上还是从后台设计上都会造成过度设计，最终导致效果并不好。
列表的目的其实就是实现数据的快速选取，所以只要每个条目展示能够帮助用户判断选择的最关键数据即可，如果要看详细信息，可以点击去查看详情。如果什么数据都要展示，而且如果这些数据还不在一个数据来源中的时候（比如多表、或者不同的数据库，如mysql、mongo等），数据复杂度和性能等问题可想而知。硬要做也行，解决方案可能只能是修改数据存储结构，时间和人力成本无法估量。但是来个灵魂拷问：如果之后再加这种需求呢？
列表加载的性能
上一条已经提到了，如果需求设计或者之前技术实现方案不合理，导致列表中内容是各种数据表中数据的聚合，往往会出现性能问题。列表往往是用户使用产品时最早看到的页面，所以它的响应时间非常重要。要解决性能问题，除了保证产品和技术设计的合理性外，还要结合业务需求采用合适的数据库类型（mysql、mongo、redis、ES等）并合理的加索引提高查询效率。
排序
排序需求一定是列表的标配，合理的排序规则能帮助用户更快速的找到目标。目前我们大部分的列表都是按照更新时间或者创建时间排序，但也不排除采用其他的方式比如浏览数量等。如果是非时间的排序方式，就需要考虑排序项相同的情况下的多级排序问题，比如按照浏览数排序下如果浏览数相同的条目，就采用创建时间排序。如果列表排序规则复杂，如需要多种排序规则的情况建议使用tab的方式。
同样的，如果列表涉及多张表数据的聚合，那也需要考虑进行排序的性能问题。
筛选
筛选的目的往往是按照一定的规则找到一部分数据，大部分产品默认的筛选就是展示全部！筛选往往基于属性、标签、状态等，如时间（属性）、性别（属性）、是否公开（自定义标签）、是否完成（状态）等。筛选的条件明确，但也涉及到性能问题，业务是否合理、是否连表查询、索引是否合理均会影响其性能。
搜索
为了让用户更精确的获取想要的条目，搜索一定是首选。搜索带来的问题多多，除了上面说的性能外，数据准确性也是需要提一下。大部分的产品是强调支持模糊查询的，而模糊查询如果在mysql中实现就不能使用索引，数据量一大很容易造成性能问题。所以行业经常使用的是ES存储并使用分词器，而分词的规则直接影响了数据的准确性（这里面的逻辑相当复杂，如果有想要了解的小伙伴可以去看ES的介绍文档）。这是一种博弈，如果业务不需要进行模糊搜索，那其实只要有索引mysql应该就能很好的进行条件搜索，包括左右匹配搜索（也可以使用索引）；如果需要模糊搜索，那就考虑使用ES。如果使用ES，分词的规则是需要我们重点关注的，因为会影响搜索数据的准确性。
分页加载
列表数据成千上万，不可能一个接口获取到全部，否则前台和后台都受不了。所以列表获取接口的默认值和最大获取数量是要约定好的。且分页加载时的边界值问题需要重点关注，如一个列表一共20个数据，每页加载10条，那一定是2页展示完整，可不能出现第三页哦～
测试人需关注
列表的测试有很多隐含的坑，大部分其实是在性能上。除了性能，我们还要了解各种不同数据库类型的特点和应用场景，才能设计出有针对性的测试用例。
祝大家负责的列表功能又快又准确～
