《BI测试指南》由会员分享，可在线阅读，更多相关《BI测试指南（6页珍藏版）》请在金锄头文库上搜索。
1、 BI测试指南1 测试概述1.1 测试方法BI系统测试分为：数据和功能及界面展示两方面，数据测试主要采用白盒测试方法，功能及界面展示测试主要采用黑盒测试方法；1.2 测试策略BI系统的测试引入了类似开发的过程，对于开发中的各个过程：业务分析数据处理-报表展示，进行逐层分析、检查、验证，具体如下：1.根据需求和设计文档，在源系统的界面和数据库中验证：所分析的业务，表关系等，是否正确；2.检查开发人员进行数据处理的代码，同时编写基于源表的数据查询sql，将执行的结果与开发得到的数据结果（目标表数据）进行对比，以验证数据抽取并处理的正确性；3.编写基于明细目标表和汇总目标表的查询语句（可提供给前端开
2、发人员参考），检查界面展现和后台数据的一致性。4.引入自动化测试方法：编写从各类数据表（源表，目标明细表，目标汇总表）进行查询和结果比较的语句，整理成自动化测试代码，每天执行代码即可自动检查数据是否正确抽取和处理，以保证项目的质量。以上测试方法可以比较好地测试数据仓库类项目的业务数据和功能，保证项目质量。2 测试步骤2.1 理解需求根据需求文档，和UI理解需求文档，根据需求文档中个业务点设计到的业务界面截图，将需求中涉及到的业务在源系统的界面进行理解和分析确认；2.2 检查存储过程逻辑首先了解存储过程的整体实现思路，对其从源系统取数的关键逻辑，进行数据验证；根据需求，检查数据处理逻辑是否正确；
3、检查代码本身有无编写错误。可按以下三点进行：1) 从源系统取数的关键逻辑，在源系统业务界面进行数据核对：根据开发人员编写的数据处理逻辑，将其拆分成可在原系统验证的逻辑段，进行逐段验证，特别是对于统计对象，关键字段（例如：时间周期）和关键逻辑（指标考核点）在源系统进行验证。源系统验证方法，可以采用抽样数据的正向数据验证（将查询出来的数据，在原系统核对），和反向数据验证（从源系统查找出数据，和后台查询结果进行比较）（抽样数据的对比结果要严格一致），对统计对象的总体数据量进行比较（可以容许少量偏差的存在）；2) 根据之前已验证的数据逻辑，检查该存储过程是否与改逻辑保持一致（知识库的整理）。3) 根据
4、自身业务需求的需要，检查存储过程对于数据的各种过滤和取数处理是否符合需求，检查存储过程是否存在自身代码编写的错误，或性能需要优化的地方；4) 最终目标数据结果的反向验证：将得到的最终数据结果，抽样具有代表性的数据，在源系统进行反向验证，例如某指标，可抽取考核通过，即“及时”的几条数据，在源系统中业务界面检查其时间周期，和是否符合“及时”条件；重点检查考核不通过，即“不及时”数据（因为这部分数据少），根据需求，选择各种原因导致“不及时”的数据，在源系统进行反向验证我们 的逻辑（4方法可以在一定程度上代替或补充1中测试的不足，实行的技术难度也会低一些，更容易操作）2.3 编写测试用例用例包括数据用
5、例和功能场景用例，数据用例适合用EXCELE进行编写（模板见附件1），功能场景用例（适合在QC中编写，多场景扩展，适合用MM编写）2.3.1 数据用例根据验证通过的存储过程，编写基于源表的综合查询语句；根据目标表逻辑，编写基于汇总表和明细表的查询语句（里面可以包括提供给前端使用的下转逻辑，可将很多汇总和下转对不上的问题，解决在萌芽状态）； 1) 编写基于源表的综合查询语句（根据需要可创建部分的中间临时表以简化逻辑和提供性能），得出关键数据汇总结果（例如，及时条数，不及时条数），以和目标表结果进行对比。2) 编写基于目标明细表的查询语句，可用于和三方面数据进行比较，以逐层定位问题：和源表查询结果
6、进行比较；和汇总表查询结果进行比较；和界面下转数据进行比较；对于业务性较强的下转，还需要编写可以给前端参考的明细下转逻辑，以提高效率，减少返工（下转逻辑可以是数据开发人员提供的，也或者是前端开发自己编写的，但是测试人员必须知道，并检查改逻辑，同时整理到测试用例文档中）；3) 编写基于目标汇总表的查询语句：用于：和界面汇总数据进行比较，检查前端取数是否正确；用于和明细表查询进行比较，以定位汇总逻辑是否出现问题；4) 自动化脚本：将上面三种查询语句整合在一个存储过程中，对查询结果进行比较，并返回比较结果，可以将很多指标的三表查询逻辑整合在一个存储过程中，做为项目的自动化测试代码，每天执行该存储代码
7、即可自动检查每个指标数据的正确性，每天的自动检查，可减少测试人力，保证项目的质量。（可以选择必要的模块使用该方法）。2.3.2 数据用例的使用对数据用例进行使用时，可直接执行基于源表的查询语句，和前端界面展现结果进行对比，如果一致，证明中间的过程都是正确的，如果不一致，需要再定位是前端取数错误，还是后台数据错误。出现问题的情况有：1) 界面汇总数据和源表查询结果对不上：定位时，需要直接从目标汇总表进行查询，如果界面汇总数据=目标汇总表数据，则表明前端展现没有问题，是后台数据问题，这样再查询目标明细表，以定位到底是目标汇总表，还是目标明细表的问题。2) 界面汇总和下转对不上：因为前端的汇总从汇总
8、表取数，下转从明细表进行取数，所以定位是否界面取数问题，只需界面汇总和汇总表查询结果进行比较，下转数据从明细表查询结果进行比较，如果不一致，可定位是前端问题，如果一致，则再定位是数据的汇总还是明细出了问题；具体为：需要从目标汇总表查询和界面汇总进行比较，如果不一致，则是前端问题； 需要从目标明细表查询和界面下转进行比较，如果不一致，则是前端问题，下转一般会比较复杂，带有一些业务性，发现下转出现问题，一般把问题反应给前端开发人员，并叫他们提供前端下转的逻辑，测试人员通过比较下转的查询语句和测试用例中基于明细的查询语句，可比较直观快捷地发现问题，前端开发人员修改问题之后，也需要把修正后的下转逻辑提
9、供给测试人员检查，检查通过后，在再界面上进行检查，这样可以提高工作效率，避免要通过前端界面的大量测试才能发现一些比较隐含的问题，或者需要有特殊的数据才能发现的问题。（测试人员对于前端开发人员提供的下转逻辑代码需要整理到相应的测试用例中，做为之后的参考）2.3.3 界面场景用例根据UI原型和需求文档，以及对于业务的一些深入理解，可编写基于界面场景的测试用例（可在做测试过程中，边测试，边整理完善，同时也可记录下执行的路径，用于之后复查有无遗漏的重要场景）；1) 根据UI设计的场景：就是根据UI有哪些报表，有哪些下转，设计各种场景组合的用例路径，这个可根据“后台的数据逻辑实现，或前端查询逻辑不同，而
10、设计”，如果是同类逻辑实现的部分，可以只执行代表性的场景即可，测试用例可在MM中设计，把测试的框架路径列出，在备注中说明需要注意的内容，执行过程中，将执行过的场景进行标识，发现BUG的场景的进行标识，并记录BUG，如上附件所示，通过标识执行的场景，有利于场景的不被遗漏的有序执行，同时也方便其他人同步开展测试，并且相互发现设计的场景是否有遗漏，；2) 对于一些设计到业务性的场景，需要设计特殊场景测试，例如物资流程可视化中，修改数据后点击更新，其他相关数据更新按钮不可用（并发控制），更新时，需要同步更新几个界面的数据（这样要在用例中，明确说明需要在那些界面，对哪个数据进行检查验证）（类似输入，预期
11、输出）；3) 场景测试用例可在QC中设计，也可在MM中设计好，附在QC对应测试用例中。2.4 测试成果要求 测试的成果，包括1) 测试的设计（测试用例，应能满足上面所说的数据用例和场景用例的内容和格式要求）；2) 测试的执行过程记录（可以用文档记录一些数据验证的过程，如附件，将场景执行的完成情况进行标记，如在MM中标记场景执行完成情况）；3) 测试结果的记录（BUG的录入和跟踪关闭）；BUG需要录入的信息基本如下；一般需要附图进行说明。3 测试流程控制3.1 测试提交流程控制 为了实现提交功能的统一管理，不遗漏需要测试的功能，开发和测试进行及时充分的交互，并对提交功能进行全流程管理，需要有测试
12、提交流程。执行过程如下： 开发人员开发并自测后的功能，提交到QC中，并说明功能对应开发人员，功能的描述，测试需要注意的地方（提交状态）-测试组根据提交情况，分配并接受测试任务（接受状态）-测试完成后，将测试的结论和发现的一些重要的BUG，以及遗留的问题，写入备注中（完成状态）-每次版本发布时，可以把已测试完成的功能进行发布（发布主要是发布测试完成的功能，和BUG中已验证通过的BUG）； 对于一些小的变更修改，或者是自身的优化，可以不当作提交项，而是在BUG中录入一个BUG来进行交互和开发测试跟进；目的就是，对于所有需要修改，或已修改的内容，都要进行交互记录，并进行全过程跟踪，以免问题或者功能人
13、为的遗漏修改或测试。3.1 BUG流程控制 BUG流程的控制，主要为 新建（还不确定的BUG，这类BUG开发不用关注）-打开（未解决）（已确定是问题，需要分配给对应开发人员）-已解决（开发人员解决完问题置成已解决，并在备注中说明修改情况和测试需注意情况）-关闭（测试人员验证通过后，进行关闭，如不通过，则置成“重新打开”）。 测试人员需要重点关注“已解决”问题，开发人员重点关注“未解决”问题。通过状态来进行问题流转。 其他的一些状态，一般还有延迟（之后处理），不处理（不解决），拒绝（不是问题），不能只有项目经理有权限置这些状态。资产分析系统目前是和客户共用一个缺陷管理系统，所以在状态上加入了科腾
14、和监理之间的流程状态。BUG 的基本字段信息在这里不做叙述，在QC中有一个查看BUG历史流程的功能，可以看到每个BUG的操作人和操作情况。QC的日常使用如附件：4 其他信息4.1 测试所使用工具可使用EXCELE记录数据测试用例；可使用QC编写测试用例，并分配每个测试用例的执行人和关联用例对应的BUG情况；可使用MM进行场景设计，记录多次测试的场景执行情况；可使用WORD进行验证过程记录，并附在测试用例中；可使用QC管理测试提交和BUG 的全生命管理；可使用LOADRUNNER 进行性能测试；4.2 其他一些可共用的经验1) 需求文档需要有功能各业务点对于源系统业务页面截图，方便开发和测试人员准确定位源系统业务界面，方便对数检查；2) 数据组人员提供给前端人员从目标表取数的逻辑，也需要同时提供给测试人员测试检查，这样可将很多汇总和下转对不上的问题，阻止在萌芽状态，减少联调的误差，前端人员实现以后，提交测试时，在提交文档中，附上下转逻辑，测试人员通过检查下转逻辑，可以直观快速的发现汇总和下转的问题，可以很好地提高工作效率。3) 将得到验证的源系统的一些表逻辑关系，业务，进行记录，以便之后的开发和测试参考，实现共享，减少重复劳动；
