基于自己的理解总结一下BI测试流程与方法~
1、口径文档
-
口径文档相当于需求文档或契约，口径中要描述清楚本次需求的的逻辑、如需要什么数、这些数的逻辑是什么，基础数据来自哪里，对输出表字段等有没有要求，如果跨团队合作需要和谁对接，口径需QA、RD、PM三方约定确定终版。
-
问题：在业务中BI这块相对独立，一般是基于产品业务需要出各种各样的数，但是每个业务的产品不一致，带来的问题是口径写的五花八门，有的好理解，有的真的不好理解，这里建议QA出一份口径模板push给公司产品，每次需求评审时都需要按模板来出口径。
2、codediff
-
了解代码：建议提测前找RD了解下代码，至少需要清楚输出的终表是哪张，基础数据从哪里取。
-
自己diff：人工代码走读，看，一行行看有没有按口径的统计逻辑去实现、有没有漏的，语法写得有没有问题，边界的统计有没有问题，统计的数据逻辑有没有漏掉某些业务条件，自己把sql拿去跑一下大致看看数据有没有很离谱的。
-
和开发diff：提测前或提测时，和开发进行codediff，主要目的是了解业务实现细节，如数据跑出来同步到mysql，业务再去指定的表中取数，灵魂三问来了：
-
我们什么时间同步，怎么同步、发mq还是走任务，如果发mq，mq有堆积此时业务需要读这份数据怎么办，有没有兜底；
-
每次增量同步还是全量同步；如果是全量同步，每次同步时需要删掉之前的数据吗？如果需要删除，业务在什么时机去读，如果你删了，业务这时候去读，我们有监控吗？如果是增量同步，有同步的版本号吗，数据有问题时怎么回退，回退到哪个版本，这些逻辑有没有做？
-
如果数据出现异常有没有监控报警，报警人有没有添加QA和对应的RD？你取的中间表中某些基础数据很关键，如果他的数据出了问题或者产生了逻辑改动没有通知你，我们怎么监控？
-
3、提测
-
数据抽检：QA、RD、PM三方一起，对照口径进行数据抽检，确保每条口径都需要过几条数据。
-
PM check：PM对自己的业务最熟悉，一般有一些后台工具可以查，按照口径中要求的条件人工看一下查出的数据和BI跑出来的是否一致。
-
实现细节：时间允许的情况下RD要讲清楚中间表的取数逻辑，这部分口径的对接是否准确。
4、测试
-
逆向思维：先把研发写的sql拿出来跑，以结果数据为导向，再按照口径中的统计逻辑按照自己的理解写sql一步步查，比对自己的结果和开发的结果差异。
-
辅助工具：拿到结果数据，通过公司相关业务的一些平台，按照统计逻辑查一遍，比对数据是否有差异。
-
逻辑codediff，看看具体的sql逻辑写的有没有问题，语法不熟悉的网上查，还需要拿开发分支和master比对下，印象中很多BI研发喜欢在master上改代码。
-
大批量数据验证，结果表中写sql查下有没有很诡异的数据，比如为null了，不应该出现的零的数据为零了等等。
-
写单测验证sql。
从以往测试的项目经验来看，按照上面的方式去测，能兜住80%-90%的问题，未出现过数据方面的投诉和bug。
网友评论