【关于存储过程的测试】存储过程如何做单测？如何评估覆盖率？
目前在做清单报表类的测试，测试对象主要是oracle的存储过程。测试设计基本是基于业务场景去准备测试数据，核对报表结果。目前基于业务场景的这种测试方法，无法评估对存储过程的代码和逻辑的覆盖率是怎样的。
希望通过增加存储过程的单元测试来保证关键的复杂逻辑的代码部分的正确性，同时从成本的角度考虑，兼顾边界值和异常情况的测试。
即有两个困惑，希望大家一起讨论：
1.存储过程如何做单元测试？有哪些通用的check点
2.如何评估对存储过程的代码覆盖或逻辑覆盖的情况
欢迎讨论，感谢~ 直接写SQL，别在业务层做，业务层有代码的逻辑处理。你要只针对存储过程，就把SQL提出来，如果不需要并发，就单独把一个或多个执行语句放在一个事务里，用oracle自己的计时功能判断一个事务的执行时间。如果需要并发，就用JDBC写数据库的访问，注意不是业务访问，然后在LR里做并发。 至于覆盖度，看你的SQL语句写的程度和你理解的程度了，这方面需要业务知识。 回复 2# gaha
谢谢GAHA，目前是直接针对存储过程进行测试。因为主要是准备测试数据的工作，测试数据的准备主要依据对业务场景的分析。是业务层面的比较粗的粒度，代码层面的更细致的逻辑判断可能就覆盖不到了。
所以，我就想存储过程应该怎么做单元测试，这样就可以关注到代码层面的逻辑，不知道有没有什么通用的检查点或者合适的单测工具。
因为是清单报表，基本是每天晚上定时运行，所以目前并发涉及的不多。 回复 3# gaha
从业务层面我们是尽量去覆盖了。
但想知道有什么评估方法或思路或工具，去回顾我们的测试究竟在代码层面的覆盖率是怎样的。 我觉得直接在命令行里写SQL就可以 回复 6# gaha
通常的思路是怎样的呢？
我开始的想法是：找一些切入点，比如嵌套子查询有可能出现什么样的问题，单测的点在哪里。比如带gourp by有可能出现什么样的问题，单测点在哪里。带左右连接外连接的会怎样怎样。。。。等等
总结和抽象出一些通用的check点出来，作为每次单测的指导思路。不知道这种想法是否可行和有效？ 1 首先你要看你的被测系统，也就是你的存储过程，实现了哪些功能；
2 看看能不能把存储过程拆分成独立的SQL，因为存储过程里肯定是多个操作的集合；
3 根据业务逻辑，把这个存储过程看做是一个业务处理过程，根据情况独立进行执行测试；
4 拆分到最基本的SQL之后，根据SQL的基本语法，检查是否符合标准；
5 单独的SQL通过之后，再组合到存储过程中，赋值验证；
这样的话如果不并发，通常写一个或几个SQL就搞定了。也不是很复杂，这样至少保证系统里的数据逻辑是正确的。至于gourp by什么的，看源码中SQL的部分是不是有，这里和业务实现是有关系的，没有也别乱加，没必要。 回复 8# gaha
谢谢gaha的耐心解答，我自己也再想想，初衷是想编写一份存储过程的单测checklist，用这份checklist来指导和检查开发自己去进行单测 怎么就我们两在说啊？好冷清的坛子啊 怎么就我们两在说啊？好冷清的坛子啊
暖洋洋 发表于 2014-5-15 15:32 http://bbs.51testing.com/images/common/back.gif
大部分人都在关注自己能挣多少钱呢
页:
[1]
