1、查询功能：
前后端需要做 trim【trim：去掉文本左右的空格】
边界值测试：
前端传给后端的字段需与接口 wiki 保持一致
边界值可以通过 review 代码或者前端输入边界值测试
查询结果如果异常时，需要有明确的 errorMsg 提示
2、内容提交：
必填项非空校验，前后端都需要做
提交内容需要做 trim 后的非空校验，尤其是必填项
非空校验时，需要注意空格在逻辑中也算文本的。
特殊字符：文本中含有特殊字符时，前端解析时可能会转义导致文本丢失。特别需要注意%、\n 等特殊字符
提交按钮防幂等【抖动】：防止重复提交，一般采用前端判断，提交一次之后，按钮转圈无法再次提交
内容提交是以弹窗的形式输入提交，则需要注意点击旁边弹窗空白不能关闭弹窗，防止用户误操作，将输入内容清空
内容提交后页面加载有延迟，需要给用户明确的提示，告知用户数据正在加载中。
对于异常问题的提交要有明确的 errorMsg 提示
必填项未填写。eg：如果页面需要拖动展示时，看不见的必填项的文案提示需要以弹窗的形式提示用户
字段内容过多需要展示时，需要根据业务需要部分展示点击后全部展示
3、页面：
页面内容展示要简洁，整洁，直观，能够突出重点，样式不能覆盖，遮挡，显示不全，看不清
页面风格要一致
4、逻辑：
业务字段的定义要精准明确。eg：一月前和 30 天前两个看似是以月为单位，但真正的效果不一样的
关联性逻辑 update&delete 时，需要注意上下逻辑之间的引用，需要给出明确的逻辑关联性与操作时的用户提示文案
有关联逻辑的配置删除时，需要校验逻辑是否在使用中，是否可删除
内容的增删改需要做二次确认校验，避免误操作
根据业务逻辑，在一定程度上限制用户的操作。避免用户的大量操作后发现这样操作不可行，导致用户需要校验页面内容。用户操作的每一项都可以清楚的知道什么样的操作是被禁止的。
输入文案的最大字数限制【可以在 input 框中的默认文案写清楚最多输入多少字且输入超过最大值时 toast 提示用户或者不可继续输入】
逻辑之间的限制，A 和 B 之间有逻辑关联，选择 A 后，B 只能选择与 A 有关的选项
梳理具有相似逻辑的点，并形成文档同步到产品，开发。统一逻辑，减少测试和开发成本
异常逻辑的兜底
5、C 端异常流程：
测试 APP 的最基础的四种异常情况：未登陆/无网/无定位/所在地无任何入口