理解业务是解决一切问题的根源，我不信懂业务逻辑还需要问测试点，无非就是让开发讲清楚入参出参分别是什么意思而已

数据库调存过呗，看结果和预期是否一致

看业务吧，如果业务不稳定，迭代很快，又有分布式高并发。我会丢一句 “【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。” 给开发。（前提是开发不是数据库大神哈，是大神你会被打死）
如果比较稳定的领域模型，看存储过程做的是什么功能，有没有什么性能指标，再根据需求来。

很少有单独甩个存储过程来给你测试的，如果有，说明你们测试资源很丰富。。

业务不是万能的，如果懂业务就能测试的话，那产品经理就可以直接干测试的活了。有些代码方面注意的点时需要开发提出来的

业务不是万能，但是没有业务万万不能；代码方面注意的点也是需要结合业务角度出发分析。

产品经理不能直接干测试的活的原因大约就是缺乏断章取义来 dis 别人观点的能力吧

1、对调用如参数组合进行覆盖，观察数据表读写是都正常（功能验收）
2、尝试输入错误入参数，注入异常，观察数据的一致性和事务的是否正常（异常验收）
3、尝试高频调用，观察 DB 测内存 CPU 开销，及早发现定位性能瓶颈，这样可以为上层调用推荐合理的并发和隔离策略（性能验收）

还有直接提测存储过程的，如果你是做单元测试，当我没说。如果要测试的话：
1、看读写的数据是否正确
2、数据是否可以重复读写
3、存储过程执行中报错，是否会回档
4、各种类型的参数
5、分布式读写
实际上这样测试意义不是很大，投入/付出不成正比。应该怼回去。收益最高的，是以接口为单位的提测。

开发自测

就是这么测试的；
然后具体看了下逻辑，发现了个边界问题，数组边界错误；
接口层其实也提测了，但是作为另一条需求，对于存过的提测之前也比较少，所以没有一个相对标准的做法，才抛出来问问大家，至于性能方面，因为这个调用的频率是每日一次，应该还好的。

在另一个地方看到有这个回复，感觉还比较完整：
sql 存储过程测试：1，校验入参和出参；2，校验 SQL 逻辑；3，优化 SQL 性能。
楼主文章涉及了第一点，其实我们最重要是第二点，最难得是第三点。
我的理解和测试是，在充分读懂要测试的 SQL 存储过程，将它的 SQL 逻辑，一点点分解，然后自己写 SQL 校验所测试得到的数据是否和开发的 SQL 逻辑得到的数据能一致，这个还是要多提高 SQL 能力。
至于 SQL 性能，很多开发的 SQL 存储过程有可能会出现冗长，在你的能力范围内给出响应更快的 SQL，尤其是当 SQL 出现索引要重点注意。