bb数据库测试

话单入库后	1	话单入库后原表数据与话单数据对比，对比数据、条数、列数
	2	异常话单能否入库及入库后保存样式
	3	涉及到入库原表的表，是否会定期删除，删除前，数据是否会正常转移
	4	入库表的属性查看（表结构定义与话单/预统计/预处理/etl等一致；表空间设置；分区设置；有无索引等）	表结构/表空间/分区/索引：plsql中右键表名，选择view
表结构测试	1	话单原表与话单结构一致
	2	入库后数据会层层收敛，查看1层、2层等表的结构是否与需求一致，是否与来源的表一致
	3	查看临时表，是否按临时表建立	临时表：plsql中右键表明，选view，查看是否临时表
	4	创建数据库对象时判断数据对象是否存在	创建话单表一般先用函数f_sys_base_isexists检查对象是否存在
数据收敛过程	1	表数据转移、收敛的过程验证（针对不同的版本数据收敛的过程不同）
	2	验证收敛的存储过程及被调用的其它对象（如视图、函数、包等）	如merge语句，on条件字段是否完整，是否有空保护等
	3	验证收敛后的表数据是否正确（特别重要，每一次收敛都有可能出错，所以每一次数据转移、收敛都要着重验证）
	4	收敛后的表属性（表空间、索引等）。这里提到的属性要与基础版本的对比，如5月1号搭建基础环境，5月3号升级，升级后表数据应该与1号的对比	表结构/表空间/分区/索引：plsql中右键表名，选择view
	5	考量性能，在数据量大的表上有索引或其它措施提升查询速度	话单月表一定有索引，至少是时间列上索引
	6	是否有不正确的编码导致索引失效	select * from user_indexes where lower(status) != 'valid'
	7	话单转移到结果表，考虑UTC时间转本地时间，要关注话单说明中，时间字段是本地时间还是utc时间（utc居多）	处理时需要有自定义函数加载在时间字段外层
	8	业务表转移到结果表，要看有没有时间字段，考虑UTC时间转本地时间	处理时需要有自定义函数加载在时间字段外层
其它情况	1	时间跨日、周、月、年的话单入库转移后，数据是否收敛正常，日志是否报错
	2	临时表调用前是否有删除的操作（虽然临时表会话级别）	truncate 临时表
	3	存储过程、函数等代码里特别关注时间的操作（date型，varchar型），有可能会varchar型时间进行加减运算。	时间类型加减，要看这个变量是否是时间类型（即date型）
	4	分区表的分区名称是否正确，分区索引是否建立	select * from user_ind_partitions;
	5	编码规范问题	ST时就应该测试了
	6	每张表都有对应的存储空间，是否正确	升级脚本中，创建表就不应该带有表空间的字样，除了索引表空间，其他表空间都默认是用户表空间
	7	不能随意使用以往版本配置表，会带来性能和业务风险	旧版本有的配置表，修改、删除数据或增加带有编号类的数据，要确认好，现网是否有修改
	8	字符串需要有大小写保护	where lower(xx)=lower('a_b_c')； decode(lower(serviceid),'abc',1,0)；
	9	多批话单入库到不同的入库表，也就是持续的入话单测试
数据维护	1	文档中提及的维护任务需要在文档分析的时候查看是否合理	删除xx天前数据，要构造数据并测试； 有时需求中说的保存天数不合理，如明细保存30天，可以提出异议
	2	定时维护作业的测试（如多久删除一次等）	user_jobs中删除表数据的job
	3	定时维护后，对象是否存在、是否能释放空间（如drop前先truncate），回收站是否存在数据等
	4	话单或日志维护	话单从ETL采集后，是否有备份，备份的话单，删除多少天前的； 日志表是否维护？删多久前的数据
job任务查看	1	查看job任务是否每天正常运行，运行后相应表中是否有数据，数据是否正确	user_jobs中上次运行时间
报表返回过程	1	注意话单表、业务表、配置表之间的外连接
	2	注意0.00的保留两位(trim(to_char(,'99990.90')))	否则会出现.00的情况
	3	order by排序