测试后台逻辑大概两个月的时间了，总结一下目前系统测试是怎么做的，比较粗陋，慢慢优化吧。
一.关于后台数据逻辑的测试分析
测试分析的目的是对被测对象进行全方位的解剖，主要从以下4个方面：业务场景，程序实现，目标表分析，边界分析。因为对于后台数据逻辑通常最终是得到一个结果表，可以看做是最终的测试对象，边界分析单独提出来是因为边界的地方最容易出问题。
（一） 基于业务场景的分析
1. 背景分析
用户角色：数据的使用者，属于什么岗位，什么角色，关注点是什么。
应用场景：数据在哪些前端业务系统中使用，业务关系是怎样的。
使用目的：使用这些数据的目的是什么，能够为业务带来怎样的效益。
2. 业务场景分解
统计维度：针对每个维度的粒度，层次和成员等。
举例：维度是产品，细分成热销产品，滞销产品等。
统计口径：针对哪个时间段的数据进行统计
举例：统计所有数据,或只统计热销产品。
筛选条件:哪些是符合条件的数据。
举例：同时在地区A和地区B销售的热销产品。
统计指标：每个指标的定义及情景细分
举例：热销产品月销量
计算逻辑：维度和指标的计算逻辑
举例：月销量的统计方法从上月25日到本月24日。
更新频率：数据更新的频率。
举例：销售记录可能每天都有变化，所以数据更新频率是每天更新。
3. 关于历史数据的考量
比如新增字段，历史数据是否需要补数。
比如没有被跑数的当天发生的业务是否进行实时处理。
（二） 基于程序设计的分析
1. 存储过程
所在包名
调用方式：通常是定时程序，数据库job或java quartz
功能说明：初始化逻辑和增量更新逻辑。
改动方式：新增或修改
入参出参:入参的含义,传入到存储过程在哪些条件中使用
目标表：对于有判断逻辑，转换逻辑和计算逻辑的指标特别关注。
2. 数据表
结果表：表结构是否满足业务统计要求
中间表：a.用途；b.更新或删除的机制
源表：a.源数据是否能满足需求；b.源数据的分布；c.源表之间的关联关系
3. Java逻辑
接口类型；接口名称；改动方式；入参返回；实现逻辑
4. 存储过程和java接口的调用时机
存储过程的调用顺序和执行时间。Java接口的调用时机和触发条件。
5. 初始化数据，增量更新数据，实时处理数据
初始化数据：对当前所有数据的处理结果。
增量更新数据：对每日变化数据的处理结果。
实时处理数据：业务系统产生业务数据的同时进行数据处理的结果。
注意：除了测试初始化数据以外，还需要模拟增量更新数据的处理和需要实时处理的数据。
（三） 基于结果表的或基于检查点的分析
1. 列数据（字段）：
检查点：
每个字段的取值赋值是否正确；
哪些场景下需要更新字段值，程序是否都有考虑；
增量跑的时候，是否会错误的更新不该更新的数据；
对列值进行分类，观察是否有特殊数据，给予特别关注。
2. 行数据（记录）：
检查点：分类统计记录数，分析合理性。
（四） 基于边界条件和边界数据的分析
这里只关注系统测试层面的边界条件和边界数据，对于代码层面的边界值测试建议在单元测试阶段完成，成本更低。
1. 边界条件
需要测试上边界和下边界，以及超越上下边界的情况。
举例：宝宝年龄的取值范围，从孕期到学龄童以上。对于在孕期的宝宝取的是预产期时间作为宝宝生日，同时应有预产期合理性的判断。对于学龄儿童，逻辑可能也有些特殊。
在包含边界条件的程序中可能开始一直是大于号判断，到了下边界可能会忘了改成小于号判断。
2. 边界数据
对于值的范围，值的个数，有序集合，需要选取正好等于，刚刚大于，刚刚小于，或者有序集合的第一个和最后一个。
二.后台数据逻辑的测试方法
测试分析完成之后，在测试执行阶段要采取什么样的测试方法。
（一） 全手工：常规测试方法
1. 编写测试数据准备脚本（按维度,按筛选条件）
查询出基于测试分析得到的各种测试数据类型
2. 编写测试数据验证脚本（按指标）
按指标计算逻辑直接查询得到或间接得到一个预期的结果值。
3. 查结果表
根据测试数据ID查结果表，得到一个实际的结果值。
4. 比较预期结果值和实际结果值
有些情况，可以非常确定是程序问题。这种情况，通常业务规则非常清晰，测试数据非常清楚的归属于某种业务情况，可以直接得出程序有逻辑遗漏或逻辑错误。
有些情况，则需要重新review测试脚本和程序代码的差异在哪里，哪个条件的差异导致数据结果的差异。
（二） 自动化：基于存储过程的测试方法
是基于常规测试方法的分析基础上，将SQL打包成procedure，能够更快速的执行，并将测试结果记录到测试表中。
1. 拆分，从复杂到简单：
将复杂的逻辑拆分成若干个简单片段，保证每个片段的数值或属性值容易得到。
2. 建测试表：
在测试环境中，构建一张测试数据表，除ID外，为每个片段设置一个或几个表字段，用于存储每个片段得到的中间值。
3. 编写测试存储过程：
按照Step 1拆分的片段逻辑，直接使用数据库存储过程实现整个过程的统计分析，即写一个测试用的存储过程。
4. 执行测试存储过程和程序代码：
测试执行时，先执行被测功能代码逻辑，再基于同一个数据源执行存储过程的测试用例，最后对比测试表最终计算结果和被测功能代码逻辑的计算结果。
5.分析比较结果并定位问题：
如果结果不一致，可根据测试数据表存储的中间值，方便的进行手工核对，定位出错点是测试用例还是代码逻辑。若用例出错，及时修正测试用例；若测试用例没有出错，则可以根据计算过程的中间值，结合debug工具，定位代码逻辑的bug点
好处：方便进行批量测试。
（三） 半自动化方法：手工和自动化的结合和折中（中庸之道）
由于完全自动化的方式去测试存储过程，本身也是有成本的，如果测试脚本比较复杂也可能需要验证测试脚本的正确性。
故通过把测试数据的关键字段值记入临时表，再加上人为判断，快速得到测试结果。
（四） 基于探索式的随机测试方法
1. 基于结果表，依据维度和筛选条件去查询数据，观察是否有可疑的数据
2. 基于结果表，用明显不合理的条件从反向去验证是否有异常数据存在
3. 基于源表，查询关键字段的数据状态。
观察是否有异常数据，对异常数据是否需要清洗机制。
4. 记录数的检查
根据经验，在跑数之前会根据源数据量大小来预估报表数据的数据量大小，如果明显少于或明显多于就有问题。
5. 基于数据特点，分析是否可能有多对多的表关联情况，或者少了个关联的条件,可能导致数据翻倍
需要分析出存储过程中涉及到哪些源表，源表之间的关系和数据特点
（五）基于生产模拟的用户验收式测试方法
从业务系统前台操作产生业务数据，通过真实模拟源数据的产生，检查结果表的统计数据是否正确。
