筛选功能看起来是所有后台系统里最“没技术含量”的功能但真正做过一轮完整手动验证的人都知道它反而是最容易翻车、最容易漏测、也最容易被开发怼“需求就是这么定的”的地方。我见过太多次线上问题最后定位出来就是筛选条件组合逻辑错了、翻页后筛选状态丢了、或者某个边界值把列表页直接打到报错。这篇不是讲自动化测试怎么做筛选而是要把“筛选功能手动验证”这件事讲透——如果你想系统性把筛选功能验证干净或者你正在为团队梳理一份可复用的筛选功能测试清单这篇文章值得你花十分钟读完。1. 筛选功能的常见形态与验证难点1.1 先搞清你拿到的是哪种筛选器很多人一上来就按“输入几个条件点查询看列表变化”这种想当然的流程去点结果漏了一堆问题。原因很简单筛选器在不同系统里的形态差异非常大验证策略自然也要跟着变。我通常会把筛选器先分成几类每一类的验证侧重点完全不同筛选器形态典型场景核心验证点单选下拉状态、类型、部门默认值、选择后回显、选项合法性多选下拉标签、城市、渠道全选/清空、选中项管理、多选逻辑AND还是OR模糊搜索输入框名称、手机号、订单号关键字匹配规则、特殊字符、空值日期范围选择创建时间、下单时间边界日期、跨月跨年、时区、格式组合筛选多维度同时筛选条件间是AND还是OR、条件叠加后的结果远程搜索选择器输入关键字远程拉取选项防抖、下拉数据加载、选中后选项回显不同形态的组合验证起来的复杂度是指数级上升的。举个最常见的例子一个订单管理页面筛选项有“订单状态”单选下拉、“创建时间”日期范围和“支付渠道”多选下拉这三个条件组合起来至少需要考虑几十种情况。1.2 为什么筛选功能通常不在“回归测试的第一优先级”这是个很现实的问题。筛选功能在UI上表现非常直观点一下下拉框选一个值列表刷新了看起来“没问题”于是很多团队在排测试优先级时会把它排在核心业务流程后面。但恰恰是这种“看起来简单”的功能隐藏问题最多。我复盘过自己经手的几个线上问题发现筛选功能出问题的共性原因有三个组合逻辑经常被后加的筛选项破坏。开发在原有查询上加条件时可能改了一个SQL的where拼接顺序导致原本互不干扰的条件互相影响。筛选状态与列表状态不同步。比如翻页后筛选条件还在但数据却查询了未筛选的全量或者筛选条件变了页码还停留在第5页导致用户看到一片空白。边界值很少有人认真设计。空字符串、null、超长字符串、日期边界这些一旦触发轻则结果不对重则接口直接报错。所以我的观点是筛选功能虽然不用排在最高优先级但它的验证不能靠“顺手点点”必须有一套明确的手动验证方案。这一篇就专门讲这件事。2. 手动验证的核心维度从结果正确性到交互细节2.1 第一层筛选结果到底对不对这是最基础也是最核心的一层。说白了就是问你一个问题我选了条件A列出来的数据是不是都满足A验证结果正确性时我建议按下面的思路来先单条件验证。每个筛选条件单独选一个值对照列表数据逐条确认是否符合预期。这一步能快速暴露最基础的查询问题。再组合条件验证。两个条件组合、三个条件组合确认组合逻辑是AND且还是OR或。很多系统默认都是AND但有的需求明确要OR这就要对照需求文档确认。验证筛选条件的“叠加顺序”。比如先按状态筛选再按时间筛选和先按时间筛选、再按状态筛选最终结果应该一致。如果结果不一致说明查询条件存在耦合这是个值得深挖的bug。验证结果正确性最有效的方法是先在心里或文档里明确“期望结果”再动手操作。不要先看页面页面只会给你“看起来正常”的感觉而不会告诉你数据有没有多出来或少掉。我在实际验证时习惯先在数据库里用同样的条件查一遍再和页面结果做对比。这个方法花不了多少时间但排查问题的效率极高。2.2 第二层交互路径上的每一个动作都不能放过结果正确只是及格线。很多筛选功能的问题是出现在用户的“操作路径”上的也就是用户在筛选前后做了一连串动作某一环没衔接上问题就冒出来了。我整理了一份交互路径验证的检查清单你可以直接拿去用设置筛选条件后列表刷新此时页面URL是否携带参数刷新页面后筛选条件还在吗筛选后点击翻页页码变化后筛选条件还在吗还是被重置了筛选后切换Tab或菜单再回来之前设置的筛选条件还在吗清空筛选条件后列表回到全量数据的第1页还是停留在原页码重置按钮是只清空筛选条件还是会顺带重置分页筛选条件下执行导出、批量操作导出的数据是否也是筛选后的数据多选下拉切换“全选”时已选的其他条件是否被异常取消日期范围选择后日期显示的格式和查询传参格式是否一致这里我想重点说一下第4条。很多系统在清空筛选条件后页码仍然停留在之前的页数上。比如你筛选后翻到了第8页然后清空条件结果列表直接显示“第8页无数据”空白一片。这个问题的本质是筛选条件与分页状态没有联动重置属于非常典型的筛选功能bug。2.3 第三层边界值与异常数据前两层验证的是“正常情况下的功能逻辑”边界值和异常数据才是区分老手和新手的分水岭。筛选功能最常见的边界问题有这些数值范围筛选最小值等于最大值、最小值大于最大值、输入负数、输入0、输入极大值。日期范围筛选开始日期等于结束日期、开始日期晚于结束日期、跨月、跨年、2月29日、未来日期、1970年之前。字符串输入空字符串、前后空格、全角/半角字符、超长字符比如1000个字符、特殊字符、%、、等、大小写。多值筛选不选任何值、选择全部值、选择部分值。空值数据某条记录的筛选字段本身为null或空它该不该出现在筛选结果里边界值验证的关键在于“主动构造数据”而不是“碰运气”。我会在测试环境专门准备一批边界数据确保每个边界场景都有对应的数据可查。否则你选了某个条件页面显示“暂无数据”你根本分不清是这个筛选条件本身有问题还是只是没有测试数据。3. 一整套可落地的筛选功能手动验证用例设计3.1 用例设计的基础结构手动验证最怕的就是“想到哪点到哪”。没有用例的验证覆盖率完全取决于测试人员当时的脑力状态今天状态好就多点几个组合明天状态差就少点几个。所以设计一套可复用的用例模板是所有筛选功能验证的第一步。我用过很多用例模板最后沉淀下来的一套字段结构是这样的用例编号前置条件操作步骤预期结果实际结果是否通过备注FLT-S-001存在10条状态为“已支付”的订单1. 进入订单列表页。2. 状态筛选选择“已支付”。3. 点击查询列表仅显示“已支付”状态的订单共10条这个模板看似简单但有两个设计细节值得注意用例编号必须带模块前缀FLT代表筛选方便追溯和执行统计。前置条件必须写清楚数据准备。没有一个具体的“存在10条已支付订单”作为前提后面操作步骤和预期结果都可能变得不可靠。3.2 从“单条件”到“组合条件”的用例设计顺序用例设计不要乱来要遵循从简单到复杂、从单条件到组合条件的递增逻辑。我一般按下面这个顺序设计单条件用例。每个筛选条件单独处理覆盖正常值、空值、边界值。两两组合用例。所有筛选条件两两组合。如果有N个筛选条件那就有N×(N-1)/2个组合。比如4个条件就需要设计6个两两组合用例。全组合用例。所有筛选条件同时生效验证最终的组合结果。交互叠加用例。在筛选基础上叠加翻页、排序、批量操作、导出等操作。你可能会问条件多了之后两两组合的用例数量也会爆炸怎么办我的建议是用正交法或用户使用频率来取舍。先覆盖用户最常用的组合方式再把剩余的覆盖面用随机组合来补充不必追求100%全覆盖。3.3 验证记录表的设计思路设计完用例之后还要有一张执行记录表来追踪验证进度。这个表不需要太复杂核心是能统计“执行了多少条”“通过多少条”“失败多少条”“阻塞多少条”。我的执行记录表长这样执行日期用例编号执行人测试环境数据版本结果缺陷编号备注2025-01-10FLT-S-001张三测试环境-1v2.3通过无2025-01-10FLT-S-002张三测试环境-1v2.3失败BUG-1047状态组合查询结果异常有了这张表你在回归验证时可以快速看出哪些用例被覆盖过、哪些还没执行也方便在项目复盘时统计筛选功能的缺陷密度。4. 数据准备与边界测试手动验证的成败关键4.1 造数原则真实感比数据量更重要很多人做筛选功能验证时随意往数据库里插几条数据就开始测。这个做法会导致一个很尴尬的结果筛选条件选下去列表要么有数据要么没数据看起来都能出结果但因为你造的数据太“假”了根本验证不了真实用户会遇到的情况。我对造数有三条原则覆盖“正常 边界 异常”三种类型。正常数据用于验证基本逻辑边界数据用于验证极限情况异常数据用于验证容错能力。数据要可辨识。比如造订单数据时订单号前缀带上测试标记如TEST开头这样筛出来一眼就能认出来是自己造的。时间数据要有梯度。创建时间分布在昨天、上周、上个月、去年、未来这样验证日期范围筛选时才能测出真正的边界效果。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就会产生差异。验证时最好的办法是确认接口的传参格式然后在数据库里用同样的格式查一遍对比结果是否一致。写到这里我心里其实还想再强调一遍筛选功能的手动验证本质上不是“点几下页面看有没有数据”这么简单它考验的是对业务条件的理解、对数据边界的设计、对交互状态的持续追踪。我自己的体会是筛选功能很少有“一次就能验证干净”的情况每一次都会冒出新的边界场景。所以现在我做筛选验证时都会特意把“已发现的坑”记录进用例库越攒越多后面再遇到同类系统直接复用效率翻倍。如果你也在做筛选功能验证建议你从现在开始就建立自己的筛选用例库这个习惯会在后续项目里省下大把时间。