在设计测试用例前你应该考虑的重点在哪里？

lsekfe

如果你设计用例的时候，经常有漏测点，或者说有人说你的测试用例没有覆盖较深入逻辑，那么分享一些个人心得，希望对你有帮助。
　　一般作为测试，你会和产品、开发、用户打交道，那么在设计用例时，也就需要从“需求”、“开发设计”、“使用者”这几个方面进行思考了。
　　1、了解你的测试需求
　　有没有什么需求是不明确的？--列举不明确的需求点，参考竞品，一条一条和产品确认。
　　案例：
　　需求关键字：上传服务。
　　其他信息：开发设计文档，包括接口信息、服务之间的调用流程、数据库表结构。
　　看到这简单的需求时，你会怎么做？当你毫无头绪的时候，你会怎么做？
　　这时，首先我会根据自己已知的尝试对需求进行分析，然后我会谷歌相关类型的功能需求。
　　以下得出的一些分析点，这里需要再次和产品沟通明确具体的预期：
　　*上传服务是给谁用的--前端调用？其他服务调用？
　　*上传什么内容--文件？视频？图片？压缩包？安装文件？
　　*上传的大小--支持大文件？大文件是多大？
　　*上传模式--断点续传？
　　*上传交互--是否支持重复上传？可暂停上传？可取消上传？上传失败后是否支持重试？
　　业务流程是什么？--首先你得明确业务流程成功后下一步是什么？业务流程失败后下一步是什么？成功或者失败影响到哪些数据的状态变动或影响着哪些数据的计算？
　　案例：
　　采购后是否需要物流？采购后是否需要入库？如果产生退货，退货成功后也影响着库存的变动。
　　采购单成功，那么进行入库，入库成功或者失败都影响着库存的变动。
　　出库成功或者失败都影响着库存的变动。
　　2、了解需求的开发设计
　　2.1数据库表：
　　你在完全清楚需求的场景下，思考数据表结构怎么设计，数据怎么存储，存储是否满足需求？
　　每个表的字段的值是从哪里来的？通过其他数据由服务计算得来的？计算公式是什么？
　　案例：
　　例如订单的总金额=sum(商品单价*数量)-折扣，那么从总金额的边界值考虑，总金额=0时，是否存储成功；从商品单价考虑，商品单价=0时，是否总金额=0，是否存储成功；
　　从折扣考虑，折扣=sum(商品单价*数量)，是否总金额=0？
　　实体之间的关系是怎么样的？是1:1/1:n/n:n的吗？
　　案例：一次下单可以购买多个商品，一个商品可以被多次购买，
　　这时就要看数据库表是怎么存储这样的数据的？
　　能否说一个订单找得到当时下单的商品，通过一个商品找到所有购买该商品的订单。
　　前端界面的数据操作如何影响数据库表的数据存储？
　　其他外键实体的状态字段、逻辑控制字段是否影响着当前表的数据？
　　当前功能涉及的表有哪些？其他功能是否也与这些主体有交互，如果有交互的话，这些主体的数据产生是否有影响？这些表的关联主体是什么？是否会对这些关联主体产生影响。（回归的时候也需要覆盖这些关联主体的地方。）
　　其他方面：
　　1）表结构是否建了索引，为什么这样建索引？怎么设计索引使得用最少的索引覆盖最多的查询场景。
　　2）查询sql语句为什么这么写，这么写性能是否达标？（可以使用explain关键字分析sql的执行情况，从而得到最优的查询sql语句）
　　3）是否有字段使用了乐观锁或者悲观锁？如果使用了，是否存在并发问题导致数据更改失败？是否会出现因为锁而导致性能问题？
　　2.2接口请求交互：
　　*该接口请求如何被前端调用？调用的时序图是什么？
　　*接口的应用场景是什么？谁是使用者？
　　*接口设计的各个字段的用途是什么？是什么意思？是信息字段，还是逻辑控制字段？如果是逻辑控制字段，如何控制着数据的走向？
　　*如果连续请求一堆请求的话，有什么请求失败后会对功能产生影响的？
　　*如果连续请求一堆请求的话，如果有请求失败的话，是否会产生脏数据，这时是否有建立事务机制，要么全部成功，要么全部失败。如果不能建立事务机制的话，是不是处于可接受状态？
　　（ps：可接受状态的标准是：不涉及交易功能；不影响后面的功能，可以再次创建一次；）
　　案例：创建用户，先创建user，再创建用户相关信息，用户的负责人等等，这时创建用户成功，其他信息失败，但这不影响该用户的使用。那么这时这样的数据是可以接受的。
　　2.3功能的算法逻辑
　　背后的逻辑流程图是什么？和需求模块的业务流程有点相似。
　　3、使用者
　　使用者具体对象是谁？--前端交互的用户？某个服务？定时任务？（考虑的是用户操作习惯问题）
　　使用环境是什么？--浏览器？操作系统？手机？计算机？（考虑的是兼容性问题）网络情况如何？（考虑的是网络问题）
　　使用的用户有多少？数据库量级是多少？经常跑的业务线是哪条？什么时间段用户数量激增？（考虑的是性能问题）
　　使用者是否使用过程中是否存在权限问题？数据的保密性如何？用户敏感数据是否得脱敏？