装备电子系统的研发、测试、保障解决方案中心

基于需求的测试用例设计工具 BenderRBT
产品中心 基于需求的测试用例设计工具 BenderRBT
产品概述

      BenderRBT是基于需求的功能测试用例设计工具,可以验证应用程序的需求,为最大的功能覆盖设计最少数量的测试用例。BenderRBT全面评估应用程序需求的错误和逻辑的不一致,使得项目团队在开发过程的早期完成对需求的调节和验证,然后以需求为基础设计最小数量的测试用例满足功能的全部覆盖。BenderRBT允许项目团队以各种格式查看需求和测试用例,包括逻辑图和结构化规范说明,以确保需求正确、完整、得到了充分理解和可测试性。


功能特性

      基于因果图的设计引擎

      因果图提供了基于图形的测试引擎,用于业务关键、任务关键和/或安全关键的功能,它确保你不仅得到了正确的答案,而且正确的答案是来自于正确的原因。它指出了这样一个事实,即多个缺陷有时可以相互抵消。因果图确保缺陷被传播到测试人员可以看到问题的可观测点。具有完整的约束规则支持(One、Only One、Exclusive、Inclusive、Requires和Masks),以确保所创建的测试在物理上是可能的,同时支持完整的逆向测试。

      ● 更好的需求

      RBT协助项目团队分析和评审需求,消除逻辑矛盾和错误。利用因果图这种创新的方法,以图形方式显示应用中的节点(输入和输出)之间的关系和约束。项目团队可以在RBT中分析功能需求的各个方面,然后RBT计算它记录的信息,找出关系的优先级问题和逻辑错误。RBT以各种易于阅读的格式提供详细的分析信息,分析师和项目利益相关者共同审查RBT生成的以自然语言写就的测试用例,在开发周期的早期识别和纠正任何需求错误。

      ● 因果图

      作为有效的需求验证和测试用例设计的一种行之有效的技术,因果图将功能规范转换为图形化表示。这个图形表示描绘了需求中呈现的功能关系和条件,描述每个输入如何与其他输入以及每个输出相关的。在此过程中还建立了节点的约束和可观测性,允许项目团队识别潜在的问题区域。在开发因果图时,测试团队评估需求的完整性、一致性、充分的细节和是否有二义性,经常能发现若不用此方法则在集成测试之前找不到的缺陷。


测试用例设计.jpg

      ● 本地化支持

      所有用户输入的信息——图标题、备注、节点名称、节点说明——可以是任何语言。然后,RBT将使用这些信息生成其所有输出。

      ● 最小化测试

      在许多测试环境中,测试是使用“直觉”或基于组合的方法开发的。直觉测试依赖于单独的测试人员来开发要使用的测试,而基于组合的测试则使用所有可能的输入组合。虽然这些测试开发方法被广泛使用,但它们不能确保全功能覆盖,更不用说保证所需测试的最小数量。 BenderRBT使用数学上严格的算法来确定全功能测试覆盖率所需的最少测试用例数量。

      ● 最大化覆盖

       RBT的成熟的自动化测试用例的设计方法保证了功能测试的覆盖率将达到100%,同时使用最少的测试。RBT仔细评估它获取的所有因和果,将测试用例减少到足以实现完整功能覆盖的数量。RBT也交叉引用功能与测试用例。当评估执行的测试状态时,此信息允许项目团队计算正确运行的功能的百分比,然后管理层可以对应用程序是否准备好生产做出明智的决定。

      ● 保护在测试用例上的投入

      因果图是一个迭代的过程。一般来说,你要绘制图、检查结果、调整图,直到你确信需求是可靠的,并且图反映了这些需求。然后实现测试用例。当你提交建立可执行的测试时,你想要确保RBT知道这套测试是你正在实施的测试。这将使你能够保护在这些测试中的投入。

      如果RBT知道了现有的测试集,那么当需求和图形变化时可以评估这些测试。旧的测试实现了多少覆盖?你需要什么新的测试?必须对旧的测试进行哪些修改?RBT可以为你回答这些问题。


BenderRBT.png

       ● 矩阵视图

       RBT提供两个矩阵视图显示这类详细信息。覆盖矩阵显示每个测试所覆盖的功能变化,它也描述每一个测试执行至少一个没有被其他测试覆盖的功能变化。使用这个矩阵,测试团队可以确信他们正在测试应用程序功能的100%。定义矩阵总结RBT生成的每一个测试用例的输入和输出条件。这两个矩阵都可以导出到Excel,供测试人员进一步说明。


测试用例设计.png


      BenderRBT的功能覆盖矩阵识别哪些功能变化在哪些测试用例中。 “X”表示功能变化是在两个或更多测试中。“#”表示变化仅在一次测试中出现。


BenderRBT.png


      BenderRBT的覆盖分析矩阵允许项目团队量化地确定测试状态。当选择一个或多个测试用例时,覆盖率分析功能将计算所选测试用例的弱和强功能覆盖率的百分比。


测试用例工具.png

      Fewer Tests Dialog

     此功能允许你输入一个小于或等于测试总数的数字,RBT会决定哪些是测试的最优子集——哪些测试会带来最大的覆盖


测试用例工具.png


      BenderRBT定义矩阵用表格显示在每个测试用例中每个节点的状态,一目了然的了解每一个测试案例。

       ● 对敏捷的强大支持

      敏捷项目在版本内部和跨版本中都是高度迭代的,常见的问题是测试往往落后于项目,规范从来没有完整的文档化。RBT除了保护在先前版本的图上实现的测试的能力,还可以从模型生成的功能规格说明,这确保了代码、测试和规格在发布时都是同步的。

      基于组合对的设计引擎

      快速设计(QD)提供了基于组合对的测试引擎,包括正交对和优化对。QD用于测试用户界面(例如Web页面、客户机服务器应用程序中的屏幕),它也适用于设计配置测试,以及关键功能的快速测试。具有完整的约束规则支持(One、Only One、Exclusive、Inclusive、Requires和Masks),以确保所创建的测试在物理上是可能的,同时支持完整的逆向测试。


典型应用

       发动机控制软件测试

      为保证控制系统软件的质量,在进行航空发动机控制系统控制软件测试的时候,不仅要覆盖到全部的软件功能点,还需要考虑各种输入情况的组合。在输入情况较多时,各种输入情况的完全组合数目将变得非常大。譬如在10个输入条件下,全部组合将达到210(1024)种情况之多。所以在测试中穷举全部输入情况的组合往往是不可能的,并且,从发现软件缺陷、提高软件质量的角度来看,穷举全部输入情况的组合的意义也并不大,如何选取合适的用例成为了测试过程中一项具有挑战性的工作。

     发动机控制状态监视中的需求示例:

     燃油系统元件状态检查:在Ng>60%情况下,检查燃油压力Pt,超限时报警;

      防冰系统接通检查:在PAL>=115°1秒后,判断防冰接通检查指令和防冰电磁阀吸合的终端开关的反馈信息是否一致,若不一致,则防冰系统失效;

      发动机过热保护:如果Ng<66%且T45-T45max>50℃且保持时间>=5秒,则发动机过热;如果Ng>=66% 且T45-T45max>40℃且保持时间>=3秒,则发动机过热。

      使用BenderRBT绘制需求的因果关系,在确认因果图和软件需求一致后,继续运行工具软件,形成最小的测试用例集。

      某大型系统的单元测试

     某大型系统的单元测试项目,测试人员每天面对庞大复杂的系统、繁杂的功能场景以及逻辑分支,要做到完全的覆盖率需要做很多的分析工作。其中某个11行代码的函数,需要28个初始节点,这些节点之间还有一些复杂的逻辑依赖关系。单靠人工花费一下午时间画完真值表,再针对表格又花了几个小时设计了将近四十个用例,才做好了完整的MC/DC覆盖。而且这些节点之间的逻辑关系是否合理还未知。

     借助于BenderRBT图形化地表示需求中的功能及逻辑关系,节省了大量的时间。特别针对某些逻辑中,节点之间有多重的依赖关系,这个工具就显得快捷方便,大大提高了工作效率。并且,工具算法可靠,用例最优化,形成测试用例的同时,检测软件需求中的缺陷,这些缺陷的分析,有利于我们更加深入的分析需求。