企业官网建设流程全解析

筛选功能看起来是所有后台系统里最“没技术含量”的功能，但真正做过一轮完整手动验证的人都知道，它反而是最容易翻车、最容易漏测、也最容易被开发怼“需求就是这么定的”的地方。我见过太多次线上问题，最后定位出来就是筛选条件组合逻辑错了、翻页后筛选状态丢了、或者某个边界值把列表页直接打到报错。这篇不是讲自动化测试怎么做筛选，而是要把“筛选功能手动验证”这件事讲透——如果你想系统性把筛选功能验证干净，或者你正在为团队梳理一份可复用的筛选功能测试清单，这篇文章值得你花十分钟读完。

1. 筛选功能的常见形态与验证难点

1.1 先搞清你拿到的是哪种筛选器

很多人一上来就按“输入几个条件，点查询，看列表变化”这种想当然的流程去点，结果漏了一堆问题。原因很简单：筛选器在不同系统里的形态差异非常大，验证策略自然也要跟着变。

我通常会把筛选器先分成几类，每一类的验证侧重点完全不同：

不同形态的组合，验证起来的复杂度是指数级上升的。举个最常见的例子：一个订单管理页面，筛选项有“订单状态”（单选下拉）、“创建时间”（日期范围）和“支付渠道”（多选下拉），这三个条件组合起来，至少需要考虑几十种情况。

1.2 为什么筛选功能通常不在“回归测试的第一优先级”

这是个很现实的问题。筛选功能在UI上表现非常直观，点一下下拉框，选一个值，列表刷新了，看起来“没问题”，于是很多团队在排测试优先级时，会把它排在核心业务流程后面。但恰恰是这种“看起来简单”的功能，隐藏问题最多。

我复盘过自己经手的几个线上问题，发现筛选功能出问题的共性原因有三个：

• 组合逻辑经常被后加的筛选项破坏。开发在原有查询上加条件时，可能改了一个SQL的where拼接顺序，导致原本互不干扰的条件互相影响。
• 筛选状态与列表状态不同步。比如翻页后筛选条件还在，但数据却查询了未筛选的全量；或者筛选条件变了，页码还停留在第5页，导致用户看到一片空白。
• 边界值很少有人认真设计。空字符串、null、超长字符串、日期边界，这些一旦触发，轻则结果不对，重则接口直接报错。

所以我的观点是：筛选功能虽然不用排在最高优先级，但它的验证不能靠“顺手点点”，必须有一套明确的手动验证方案。这一篇就专门讲这件事。

2. 手动验证的核心维度：从结果正确性到交互细节

2.1 第一层：筛选结果到底对不对

这是最基础也是最核心的一层。说白了就是问你一个问题：我选了条件A，列出来的数据是不是都满足A？

验证结果正确性时，我建议按下面的思路来：

1. 先单条件验证。每个筛选条件单独选一个值，对照列表数据逐条确认是否符合预期。这一步能快速暴露最基础的查询问题。
2. 再组合条件验证。两个条件组合、三个条件组合，确认组合逻辑是AND（且）还是OR（或）。很多系统默认都是AND，但有的需求明确要OR，这就要对照需求文档确认。
3. 验证筛选条件的“叠加顺序”。比如先按状态筛选，再按时间筛选，和先按时间筛选、再按状态筛选，最终结果应该一致。如果结果不一致，说明查询条件存在耦合，这是个值得深挖的bug。

验证结果正确性最有效的方法，是先在心里或文档里明确“期望结果”，再动手操作。不要先看页面，页面只会给你“看起来正常”的感觉，而不会告诉你数据有没有多出来或少掉。我在实际验证时，习惯先在数据库里用同样的条件查一遍，再和页面结果做对比。这个方法花不了多少时间，但排查问题的效率极高。

2.2 第二层：交互路径上的每一个动作都不能放过

结果正确只是及格线。很多筛选功能的问题，是出现在用户的“操作路径”上的，也就是用户在筛选前后做了一连串动作，某一环没衔接上，问题就冒出来了。

我整理了一份交互路径验证的检查清单，你可以直接拿去用：

• 设置筛选条件后列表刷新，此时页面URL是否携带参数？刷新页面后筛选条件还在吗？
• 筛选后点击翻页，页码变化后筛选条件还在吗？还是被重置了？
• 筛选后切换Tab或菜单再回来，之前设置的筛选条件还在吗？
• 清空筛选条件后，列表回到全量数据的第1页还是停留在原页码？
• 重置按钮是只清空筛选条件，还是会顺带重置分页？
• 筛选条件下执行导出、批量操作，导出的数据是否也是筛选后的数据？
• 多选下拉切换“全选”时，已选的其他条件是否被异常取消？
• 日期范围选择后，日期显示的格式和查询传参格式是否一致？

这里我想重点说一下第4条。很多系统在清空筛选条件后，页码仍然停留在之前的页数上。比如你筛选后翻到了第8页，然后清空条件，结果列表直接显示“第8页无数据”，空白一片。这个问题的本质是筛选条件与分页状态没有联动重置，属于非常典型的筛选功能bug。

2.3 第三层：边界值与异常数据

前两层验证的是“正常情况下的功能逻辑”，边界值和异常数据才是区分老手和新手的分水岭。筛选功能最常见的边界问题有这些：

• 数值范围筛选：最小值等于最大值、最小值大于最大值、输入负数、输入0、输入极大值。
• 日期范围筛选：开始日期等于结束日期、开始日期晚于结束日期、跨月、跨年、2月29日、未来日期、1970年之前。
• 字符串输入：空字符串、前后空格、全角/半角字符、超长字符（比如1000个字符）、特殊字符（&、%、'、<>等）、大小写。
• 多值筛选：不选任何值、选择全部值、选择部分值。
• 空值数据：某条记录的筛选字段本身为null或空，它该不该出现在筛选结果里？

边界值验证的关键在于“主动构造数据”，而不是“碰运气”。我会在测试环境专门准备一批边界数据，确保每个边界场景都有对应的数据可查。否则你选了某个条件，页面显示“暂无数据”，你根本分不清是这个筛选条件本身有问题，还是只是没有测试数据。

3. 一整套可落地的筛选功能手动验证用例设计

3.1 用例设计的基础结构

手动验证最怕的就是“想到哪点到哪”。没有用例的验证，覆盖率完全取决于测试人员当时的脑力状态，今天状态好就多点几个组合，明天状态差就少点几个。所以设计一套可复用的用例模板，是所有筛选功能验证的第一步。

我用过很多用例模板，最后沉淀下来的一套字段结构是这样的：

这个模板看似简单，但有两个设计细节值得注意：

• 用例编号必须带模块前缀（FLT代表筛选），方便追溯和执行统计。
• 前置条件必须写清楚数据准备。没有一个具体的“存在10条已支付订单”作为前提，后面操作步骤和预期结果都可能变得不可靠。

3.2 从“单条件”到“组合条件”的用例设计顺序

用例设计不要乱来，要遵循从简单到复杂、从单条件到组合条件的递增逻辑。我一般按下面这个顺序设计：

1. 单条件用例。每个筛选条件单独处理，覆盖正常值、空值、边界值。
2. 两两组合用例。所有筛选条件两两组合。如果有N个筛选条件，那就有N×(N-1)/2个组合。比如4个条件就需要设计6个两两组合用例。
3. 全组合用例。所有筛选条件同时生效，验证最终的组合结果。
4. 交互叠加用例。在筛选基础上叠加翻页、排序、批量操作、导出等操作。

你可能会问，条件多了之后，两两组合的用例数量也会爆炸，怎么办？我的建议是：用正交法或用户使用频率来取舍。先覆盖用户最常用的组合方式，再把剩余的覆盖面用随机组合来补充，不必追求100%全覆盖。

3.3 验证记录表的设计思路

设计完用例之后，还要有一张执行记录表来追踪验证进度。这个表不需要太复杂，核心是能统计“执行了多少条”“通过多少条”“失败多少条”“阻塞多少条”。

我的执行记录表长这样：

有了这张表，你在回归验证时可以快速看出哪些用例被覆盖过、哪些还没执行，也方便在项目复盘时统计筛选功能的缺陷密度。

4. 数据准备与边界测试：手动验证的成败关键

4.1 造数原则：真实感比数据量更重要

很多人做筛选功能验证时，随意往数据库里插几条数据就开始测。这个做法会导致一个很尴尬的结果：筛选条件选下去，列表要么有数据要么没数据，看起来都能出结果，但因为你造的数据太“假”了，根本验证不了真实用户会遇到的情况。

我对造数有三条原则：

1. 覆盖“正常 + 边界 + 异常”三种类型。正常数据用于验证基本逻辑，边界数据用于验证极限情况，异常数据用于验证容错能力。
2. 数据要可辨识。比如造订单数据时，订单号前缀带上测试标记（如TEST开头），这样筛出来一眼就能认出来是自己造的。
3. 时间数据要有梯度。创建时间分布在昨天、上周、上个月、去年、未来，这样验证日期范围筛选时才能测出真正的边界效果。

4.2 边界值分析只盯这几个点就行

边界值分析不用搞得很复杂，对筛选功能来说，绝大多数边界问题集中在下面几类：

• 数值边界：0、负数、最小值、最大值。比如价格筛选，价格上限填0，列表怎么显示？填一个负数会怎样？
• 日期边界：当天、月初、月末、跨年、2月29日（闰年）、1970-01-01、9999-12-31。日期边界是筛选功能最容易出问题的地方，很多系统在跨年或跨月的时间查询上会有bug。
• 字符串长度边界：空字符串、最小长度1、等于字段最大长度、大于字段最大长度。很多系统对超长字符串没有做截断，结果接口直接报500错误。
• 分页边界：筛选结果正好是每页条数的整数倍、结果总数小于每页条数、结果正好为0条。

我在验证的时候，会把边界值设计成一组“边界数据矩阵”，然后逐条执行，确保每一个边界点都有对应的测试数据。

4.3 准备一套“脏数据”清单

除了边界数据，我还要特意准备一套脏数据。所谓脏数据，就是那些“用户可能会意外触发、但正常造数时不会想到”的数据。我的脏数据清单包括：

• 前后带空格的值，比如“已支付 ”（后面有个空格）。
• 大小写混用的值，比如“ZhangSan”。
• 带有SQL特殊字符的值，比如“%”、“_”、“'”、“"”。
• 超长文本，比如500个中文字符。
• 带有HTML标签的值，比如“ ”。
• 换行符、Tab符等不可见字符。

为什么要专门准备这套脏数据？因为很多看起来不合理的输入，真实用户完全可能碰得到。你永远不知道用户会在搜索框里粘贴什么奇奇怪怪的东西。提前验证过脏数据，可以避免线上被用户搞出问题。

5. 我在实际项目中踩过的筛选验证的坑

5.1 组合条件的“与/或”逻辑被忽视

有一次我负责验证一个客户管理系统的筛选功能，筛选项有“客户等级”（单选）、“客户行业”（多选）和“创建时间”（日期范围）。我原本老老实实按单条件、两两组合、全组合的路径测完，结果都正常。但后来发现一个隐藏问题：当“客户行业”多选时，系统内部查询逻辑是按OR拼接的，而和其他条件组合时又变成AND。也就是说，“选了A行业+B行业+等级为VIP”的查询，实际产生的结果是“(A行业 OR B行业) AND VIP”，而不是所有条件都是AND。这个逻辑看起来没问题，但如果不看SQL，只凭页面结果很难发现潜在风险。

后来我养成了一个习惯：组合条件验证时，不仅要看页面结果，还要配合看接口请求参数或数据库查询日志。尤其是多选条件，一定要确认“多选内部”和“条件之间”是两个独立的逻辑层。

5.2 翻页后筛选条件悄悄消失了

这个bug我印象很深。某次验证一个工单列表页，设置了“状态=待处理”筛选条件，然后翻到第3页。这时候我没动任何东西，只是刷新了一下页面，回来发现筛选条件变成了“全部状态”，而列表还停在“待处理”的筛选结果上。页面展示的数据和筛选条件完全不一致，用户还以为自己在看“待处理”的工单，实际上已经是在看全部工单了。

这个问题的根因是：刷新页面时，前端把筛选条件重置了，但由于页面URL里带了第3页的页码参数，列表查询仍然带着“第3页”的分页参数去请求“全部状态”的数据，导致数据和筛选条件错位。这类问题在手动验证时，一定要专门设计“刷新页面”和“复制URL重新打开”这两个场景。

5.3 多选下拉的“全选”状态不对

多选下拉里的“全选”也是个常见坑。有些系统的全选只是选中当前页的选项，有些则是选中所有选项。如果选项超过一页，用户勾选“全选”时，列表只显示了当前页的数据，但实际上是按“全部选项”来查询的，结果自然对不上。

我遇到过最极端的情况是：选项列表有8页，用户在第1页点击“全选”，页面上只勾选了第1页的10项，但查询时却按全部选项查，导致查询结果异常缓慢。这种问题在手动验证时，要专门测“全选到底选中了多少项”和“全选后查询结果数量是否正确”。

5.4 日期范围的时区与格式问题

日期范围筛选的坑主要集中在两个地方：一是时区，二是格式。时区问题在国内系统里不太容易出现，但一旦涉及到海外业务或跨时区用户，就要特别注意。有一次我验证一个订单系统的“下单时间”筛选，测试环境数据库存储的是UTC时间，页面展示的是北京时间。我选了“1月1日到1月31日”的时间范围，查询出来的数据却把1月1日0点到8点的订单漏掉了，因为这段时间在UTC里还是前一年的12月31日。

格式问题则更隐蔽。有的系统日期筛选传参是“yyyy-MM-dd”，有的是“yyyy-MM-dd HH:mm:ss”，如果后端没有统一处理，边界时间（比如23:59:59和00:00:00）就会产生差异。验证时最好的办法是：确认接口的传参格式，然后在数据库里用同样的格式查一遍，对比结果是否一致。

写到这里，我心里其实还想再强调一遍：筛选功能的手动验证，本质上不是“点几下页面看有没有数据”这么简单，它考验的是对业务条件的理解、对数据边界的设计、对交互状态的持续追踪。我自己的体会是，筛选功能很少有“一次就能验证干净”的情况，每一次都会冒出新的边界场景。所以现在我做筛选验证时，都会特意把“已发现的坑”记录进用例库，越攒越多，后面再遇到同类系统直接复用，效率翻倍。如果你也在做筛选功能验证，建议你从现在开始就建立自己的筛选用例库，这个习惯会在后续项目里省下大把时间。