从以下经验点，类似问题去着手和参考：

大类

检查点

数据库设计相关问题

日期的考虑：默认有creat和modify时间，是否因业务需要增加：审核时间，生效时间，过期时间等

默认值的考虑：需结合业务某操作时该表新插入数据中，各个字段默认值的合理性：如：允许null是否对后继业务有冲突？

关键的状态标志/类型标识中，各个值是否有缺失某种状态/类型的可能，特别需考虑处理失败和异常的标识；是否要增加某个字段来标识中间的一些状态变化的记录？如取消，失败？
需结合数据什么时候插入，什么时候被更新，什么时候会删除。删除是表记录删除还是有状态标识来考虑，表的设计值是否正确

增减字段：是否增加操作员/审核员字段？是否要有备注字段？或为便于业务未来的查询，增加一些金额，pv值之类的字段？

是否增减表：是否需要操作日志记录表，是否主表与明细表分开？是否要有历史表来分担大数据？

有关联的字段设计类型/长度确认： 如果表中的字段与现系统中其他表字段有关联或存放内容一致。 需核对原有表字段类型与长度，确认无偏差

表名不可超过25个字符，表字段名称命名是否合理

vachar类型的长度，是否不需要250长度

结合业务考虑合理性：若表中有多个字段有各状态位标识时，务必结合实际业务有哪些类型，这些类型，对应表中各状态位是什么来区别，一一分析，找出差错，那些自我矛盾？是否可以对业务的需求进行支持（只有提前进行这类测试分析，才能确认表设计的合理）

如果设计中使用现有表，对现有表原有数据来源必须了解清楚

流程逻辑图

在有是否这类判断后面，下一步处理正确吗？

多个判断条件，先后顺序会有什么影响？到底哪个应该在另一个判断条件的前面，为什么？是业务需要还是技术实现需要？ 

是否漏了某个条件判断吗？如：是否需要在运行时刻要判断对象的类型或条件？是否要判断对象的数据存不存在数据库中？

对异常或出错，是否要增加一个 启动重新处理数据的脚本或重试机制？

对并发的处理考虑？特别是界面的处理与数据库状态不一时，判断的处理。

特别是活动等有时间段的业务，QA需结合，多个活动时间段，活动结束/中断 与下一次活动开始的衔接逻辑。 是否与流程图中的流转有冲突？

新老客户，新老流程，用户对接，数据对接问题的考虑（老客户老数据要统一迁移新系统吗？或新系统对老客户要有一定控制吗？）

角色功能关系图

某角色可以操作的内容，QA应拿着整个流程操作来看是不是各类操作全了？ 另外需以逆向（是否可取消，删除，退回至上一步）逻辑状态来考虑

附加操作： 除一般的增删改查，是否有下载打印，发邮件短信类

访问权限是否合适？ 需进一步区分吗？需多一些角色人员区分审核吗？

实现细节与范围考虑

与其他功能有关联，其新增的一系列操作，需考虑通知或改变其他相关点

设计中有配置文件

配置文件中各值的作用与何时会被调用到，需要提前了解清楚

配置文件中各值哪些是固定的，那些是可随时在一定区间修改的，哪些配置项修改需要测试，必须确认。

交互和接口设计

交互中的代码转换机制的确认，二边特殊字符处理清单确认

接口参数与结果中，是否缺少所需内容与信息

接口通信与返回异常处理机制确认 （要重发吗？要默认返回一个值吗？）

数据生成有时间间隔时，间隔合理吗？能连惯展现吗？如：在界面获取显示也有时间段（定期自已刷新或重取方式等），设计上会因这个时间差而取数不正确

正常业务与异常业务不在同界面或模块实现，对异常退款、删除、终止等进行记录时，可能有关键id字段冲突，或异常业务取不到这个关键id字段等

因表中数据来源多处进行insert，但又要求某些关键字段内容唯一，当多处来源并发时，可能会有重复记录出现，破坏唯一性要求。

交互时二边数据唯一性，不应出现重复记录的考虑

sql条件审核

在金额统计上计算的正确性检查

在比对的数字与字符类型不一而会有问题（30 >150是因为进行字符比对）

设计实现的合理性

QA结合对业务的熟悉，提出更好的设计实现方案

实现的可测试性的考虑

考虑实现是否有性能问题