Step 3. 按照Step 1拆分的计算片段逻辑，直接使用数据库存储过程实现整个计算过程，数据查询、排序，求大值、小值和平均值等运算都可以方便的使用数据库提供的接口，且存储过程支持变量和游标，逻辑实现起来十分简便。

　　Step 4. 测试执行时，流程如图1所示，先执行被测功能代码逻辑，再基于同一个数据源执行存储过程的测试用例，后对比测试表终计算结果和被测功能代码逻辑的计算结果。如果出现测试用例和代码逻辑计算不一致的情况，QA可根据计算过程，方便的进行手工核对，定位出错点时测试用例还是代码逻辑。若用例出错，及时修正测试用例；若测试用例没有出错，则可以根据计算过程的中间值，结合debug工具，定位代码逻辑的bug点。

　　这种基于存储过程的测试方式总结下来有以下优势：

　　（一）与基于单元测试框架的方法相比，实现起来简单、轻量、高效。直接面向数据库进行操作，不依赖原有代码逻辑和第三方框架，开发用例代码量小，。

　　（二）在测试表中留下计算全过程，方便错误的跟踪。

　　（三）与手工核算的方法相比，本测试方法QA时间开销主要在测试设计阶段，测试执行时间短，且便于维护，方便自动化回归测试。

　　由于盘古项目的计算流程较为复杂且需要许多业务相关知识，这里为举一个简化的模拟场景来说明本文所述基于存储过程的测试方法。表2为原始记录数据表（tb_os_log），记录了销售人员工作拜访日志，

　　表3为销售人员得分表（tb_os_point），这个表已经预先存入参加评分的销售ID，

　　下面两个公式（5）是从原始记录到实际得分的计算公式，

　　其中，为在到时间段内销售人员拜访任务总量，为销售人员的成交订单数量，为转化率，为销售人员中的高转化率，为销售人员中的低转化率，为终销售人员的得分。被测计算功能是将tb_os_log通过上述数学计算得到结果，并存入tb_os_point表的total_point字段。

　　测试时，首先设计并创建测试表（tb_os_test），表4为测试表的各字段说明，is_pass字段为0本条数据通过测试，is_pass字段为1本条数据测试不通过。