一条测试用例要对应一个可观察行为

功能测试不是逐个点击菜单，而是确认某项操作在给定条件下产生了符合业务约定的结果。每条用例写明测试目标、执行角色、前置记录、操作步骤、预期结果和实际证据。像“客户管理正常”太笼统，无法判断具体哪里通过；“具备跟进权限的员工保存结果后，记录能按约定对象和时间查询”才可以安排角色操作并核对结果。

预期结果应来自已确认的业务规则或需求，不要在测试过程中临时改标准来匹配当前表现。若规则本身不清楚，先标为待确认，由业务责任人补充决定；否则测试人员容易把一个未经批准的默认设置误当成产品缺陷或正式流程。用例也需要关联需求编号，之后发现遗漏时能回到需求确认，而非单独修补一张测试表。

用输入组合覆盖常见与边界情形

针对数据录入和修改，至少检查正常值、必填资料缺失、格式错误、重复记录和更正后的查询结果。每个边界情况要明确系统应阻止、提示还是允许继续；不同选择都应有业务依据。比如联系方式重复是否一定代表同一顾客，要看团队规则和其他识别信息，不能让测试者仅凭一条相同字段擅自合并记录。

针对流程状态，按实际允许的路径检查创建、处理中、完成、取消或重新打开等变化。重点验证不能跳过的节点、已完成后还能否按规则更正、重新分配时原负责人和历史过程如何保留。没有经过业务批准的状态不应从测试人员习惯里推导。用边界用例验证限制条件，而不是尝试所有可能的排列组合；优先覆盖发生频繁或错误后影响较大的路径。

选择跨岗位的场景复核交接。由一个角色建立记录，另一个角色按授权接手，再检查双方能看到的信息、当前责任人和历史过程是否符合预期。不同账号结果不同时，先保存各自角色和操作路径，再判断是权限规则、数据范围还是具体功能行为。管理员能完成操作，不代表一线岗位也能按日常权限完成。

检查查询、列表和关联结果的一致性

保存成功提示只说明页面接受了操作，不足以证明记录已在团队需要的位置出现。测试完成后从约定入口重新查询，核对关键字段、状态、责任人和时间；若同一记录会出现在多个视图，按业务口径检查其筛选和归属。变更前后的数据都应能解释，避免列表仍显示旧值而详情已变更，造成不同岗位依据不同状态工作。

关联关系要通过具体记录验证。若一项跟进对应某个顾客和某次服务事项，用测试数据建立关系，再从相关入口查看能否回到正确对象；修改关联后也检查原位置和新位置的呈现。只在页面上看到相同姓名或编号，不能推断对象关系正确。跨模块自动传递如果不在本轮测试范围，就列为未验证，勿以字段外观相似代替结果证据。

列表筛选和统计口径也需要小样本核对。准备几条已知状态的测试记录，明确应出现在哪里、哪些应排除，逐条比对查询结果。若只检查总数量，遗漏或重复记录可能相互抵消。把使用的条件、时间范围和账号角色写进记录，让复核者能重现查询。

把权限验证放在具体动作上

针对每个关键功能，列出哪些角色可以查看、创建、修改、分配和复核，然后分别用测试账号执行允许与不允许的动作。验证页面入口、直接查询和保存操作是否符合约定；按钮被隐藏并不必然证明所有操作途径都不可用。发现访问差异时，记录账号类型、数据条件、时间和具体步骤，由权限责任人判断是否符合制度。

测试应使用虚拟或经批准的样例，避免为证明某个限制而复制大量真实顾客资料。遇到员工离岗、临时代理、跨门店查看等情形，依照项目确定的角色安排检查责任转移和可见范围。功能测试只能说明本次账号、场景和环境中的观察结果，不能推出整个系统已完成全面安全审计。

一次用例尽量检验一个主要判断点，复杂场景可拆成前置条件和连续步骤，避免失败时无法定位原因。成功与拒绝两种结果都要记录：规则允许时应完成，条件不满足时应给出可理解的处理结果。测试人员不能为让流程通过而绕过规则。

沿一条记录走完完整生命周期

功能用例还应避免只验证单次提交。选择一条专门样例，从建立、查询、更新、交接到结束，按时间顺序检查每一步留下的状态和责任信息。再用另一角色查询历史，核实能够判断目前由谁处理、上一步做了什么。记录更正时确认旧信息是否按业务规则保留；重复提交时检查是否出现额外记录。这样可以发现单个按钮测试难以暴露的状态断层。

若使用导入、批量操作或移动端等多个入口，确认这些入口是否在本轮范围，并分别验证其行为；一个入口正常不代表其他入口采用相同校验规则。版本、账号和测试数据必须与证据一同注明，出现差异时先排除环境不一致，再判断是否为产品缺陷。

缺陷复现、修复与回归要形成证据链

缺陷单写明用例、环境版本、角色、输入条件、复现步骤、预期与实际结果以及影响范围。截图或录屏只作为补充，不能取代文字步骤；避免截入无关的个人资料或认证信息。若问题偶发，记录重复次数和触发条件，不要只用“有时失败”结束调查。

修复后先复跑原失败用例，再核对可能受影响的邻近路径。例如调整状态转换规则后，检查相关筛选、交接和历史查询；某角色权限变化后，检查同一任务下其他角色仍能按规则工作。结果与预期一致才关闭缺陷；仍未覆盖的角色或数据情况明确保留。回归用例持续维护，业务规则更改时同步更新预期结果，避免测试集与现行制度脱节。

企雀会员管理公开资料介绍会员分层，以及顾客领取分配、跟进进度与结果记录。若评估相关模块，可把这些公开描述拆成待测动作：不同角色如何查看分层、员工领取或主管分配后责任如何呈现、跟进结果在哪里查询。公开资料不能证明特定账号、设置或服务范围已经满足要求，须用当前方案账号、具体用例和实际结果核对。查看企雀会员管理公开介绍