先說說列表

在如今的大數(shù)據(jù)浪潮下，列表作為一個方便用戶進行數(shù)據(jù)查閱及快速篩選的功能肴沫，幾乎每個產(chǎn)品都會有粟害。如下圖所示：

簡書列表

也許有人會說了，測試列表頁面看起來就是一個普通的頁面颤芬，根據(jù)業(yè)務需求驗證一下內(nèi)容悲幅、看下分頁及每頁的數(shù)量、試一試篩選站蝠、做做功能和邊界值測試等等不就行了嗎汰具？其實不然！雖然看似剛才說的驗證點覆蓋了列表的全部功能菱魔，但是還是有很多細節(jié)需要我們深入的了解和測試的留荔。

測試提升

測試列表頁，我們可以從業(yè)務需求合理性澜倦、前端頁面功能聚蝶、后臺接口實現(xiàn)三方面來分析出測試提升的點，分別為：需求合理性藻治、性能碘勉、排序、篩選桩卵、搜索恰聘、分頁等

需求合理性

需求合理性是最早需要關(guān)注的點。由于需求是早期產(chǎn)品評審時做的吸占，表面上還沒有進入技術(shù)晴叨，所以很多開發(fā)測試人員并沒有重視；但正是因為它是最早期的一環(huán)矾屯，恰恰才是最重要的兼蕊，因為它如果出問題就會帶來下面幾個點的連鎖問題。
我見過很多列表需求件蚕，產(chǎn)品（或者客戶）希望列表中每個條目顯示的數(shù)據(jù)越多越好孙技。這個要求看似合理，但是無論從UI上還是從后臺設計上都會造成過度設計排作，最終導致效果并不好牵啦。
列表的目的其實就是實現(xiàn)數(shù)據(jù)的快速選取，所以只要每個條目展示能夠幫助用戶判斷選擇的最關(guān)鍵數(shù)據(jù)即可妄痪，如果要看詳細信息哈雏，可以點擊去查看詳情。如果什么數(shù)據(jù)都要展示，而且如果這些數(shù)據(jù)還不在一個數(shù)據(jù)來源中的時候（比如多表裳瘪、或者不同的數(shù)據(jù)庫土浸，如mysql、mongo等）彭羹，數(shù)據(jù)復雜度和性能等問題可想而知黄伊。硬要做也行，解決方案可能只能是修改數(shù)據(jù)存儲結(jié)構(gòu)派殷，時間和人力成本無法估量还最。但是來個靈魂拷問：如果之后再加這種需求呢？

列表加載的性能

上一條已經(jīng)提到了毡惜，如果需求設計或者之前技術(shù)實現(xiàn)方案不合理拓轻，導致列表中內(nèi)容是各種數(shù)據(jù)表中數(shù)據(jù)的聚合，往往會出現(xiàn)性能問題虱黄。列表往往是用戶使用產(chǎn)品時最早看到的頁面悦即，所以它的響應時間非常重要吮成。要解決性能問題橱乱，除了保證產(chǎn)品和技術(shù)設計的合理性外，還要結(jié)合業(yè)務需求采用合適的數(shù)據(jù)庫類型（mysql粱甫、mongo泳叠、redis、ES等）并合理的加索引提高查詢效率茶宵。

排序

排序需求一定是列表的標配危纫，合理的排序規(guī)則能幫助用戶更快速的找到目標。目前我們大部分的列表都是按照更新時間或者創(chuàng)建時間排序乌庶，但也不排除采用其他的方式比如瀏覽數(shù)量等种蝶。如果是非時間的排序方式，就需要考慮排序項相同的情況下的多級排序問題瞒大，比如按照瀏覽數(shù)排序下如果瀏覽數(shù)相同的條目螃征，就采用創(chuàng)建時間排序。如果列表排序規(guī)則復雜透敌，如需要多種排序規(guī)則的情況建議使用tab的方式盯滚。

簡書

篩選

篩選的目的往往是按照一定的規(guī)則找到一部分數(shù)據(jù)，大部分產(chǎn)品默認的篩選就是展示全部撵术！篩選往往基于屬性背率、標簽、狀態(tài)等，如時間（屬性）退渗、性別（屬性）移稳、是否公開（自定義標簽）、是否完成（狀態(tài)）等会油。篩選的條件明確个粱，但也涉及到性能問題，業(yè)務是否合理翻翩、是否連表查詢都许、索引是否合理均會影響其性能。

搜索

為了讓用戶更精確的獲取想要的條目嫂冻，搜索一定是首選胶征。搜索帶來的問題多多，除了上面說的性能外桨仿，數(shù)據(jù)準確性也是需要提一下睛低。大部分的產(chǎn)品是強調(diào)支持模糊查詢的，而模糊查詢?nèi)绻趍ysql中實現(xiàn)就不能使用索引服傍，數(shù)據(jù)量一大很容易造成性能問題钱雷。所以行業(yè)經(jīng)常使用的是ES存儲并使用分詞器，而分詞的規(guī)則直接影響了數(shù)據(jù)的準確性（這里面的邏輯相當復雜吹零，如果有想要了解的小伙伴可以去看ES的介紹文檔）罩抗。這是一種博弈，如果業(yè)務不需要進行模糊搜索灿椅，那其實只要有索引mysql應該就能很好的進行條件搜索套蒂，包括左右匹配搜索（也可以使用索引）；如果需要模糊搜索茫蛹，那就考慮使用ES操刀。如果使用ES，分詞的規(guī)則是需要我們重點關(guān)注的婴洼，因為會影響搜索數(shù)據(jù)的準確性骨坑。

分頁加載

列表數(shù)據(jù)成千上萬，不可能一個接口獲取到全部窃蹋，否則前臺和后臺都受不了卡啰。所以列表獲取接口的默認值和最大獲取數(shù)量是要約定好的。且分頁加載時的邊界值問題需要重點關(guān)注警没，如一個列表一共20個數(shù)據(jù)匈辱，每頁加載10條，那一定是2頁展示完整杀迹，可不能出現(xiàn)第三頁哦～

測試人需關(guān)注

列表的測試有很多隱含的坑亡脸，大部分其實是在性能上。除了性能，我們還要了解各種不同數(shù)據(jù)庫類型的特點和應用場景浅碾，才能設計出有針對性的測試用例大州。
祝大家負責的列表功能又快又準確～