Bender RBT基于需求的测试用例设计工具.docVIP

Bender RBT基于需求的测试用例设计工具 基于需求的测试用例设计工具Bender-RBT 产品综述 在动态测试中，测试需要依赖测试用例驱动，测试用例分为基于需求的测试用例和基于覆盖的测试用例，也可以称为黑盒测试用例和白盒测试用例，基于黑盒测试用例的设计方法包括边界值法，等价类法，正交组合对法(Orthogonal Pairs)和因果图法(Cause Efffect)等等，其中组合对法和因果图法由于涉及到输入条件与输出结果直接的组合与逻辑关系比较复杂，不适合用人工的方式计算。 因果图法就是从需求规格说明书的描述中找出因(输入条件)和果(输出或程序状态的改变)，通过因果图转换为判定表，最后为判定表中的每一列设计一个测试用例。这种方法的起源是硬件数字集成电路的测试方法(敏感路径法)，能够设计出有效的测试用例，而舍弃对测试没有贡献的测试用例，并且覆盖全部功能。 组合对法就是把多个输入和多个输出两两结对，以发现两个因子的交互关系导致的可观测的软件故障，这种方式设计的测试用例数量比穷举测试减少很多但是依然可以有效地发现软件缺陷。 BenderRBT是基于需求的功能测试用例设计工具，具有组合对法(Orthogonal Pairs)和因果图(Cause Effect)两种功能模块，通过对被测应用的需求进一步清晰化整理，进而设计出最小数目的测试用例实现最大的功能覆盖率。BenderRBT深入地分析应用的需求规格说明找出其中存在的错误和逻辑冲突，软件开发团队使用BenderRBT可以在软件开发的早期尽早地优化并且验证需求。在软件生命周期中越早发现并纠正错误，所付出的开销和时间就会越少。BenderRBT把需求作为最基本的输入来设计能够覆盖所有功能的测试用例，需求或者测试用例可以以逻辑图或者文本的方式输出，软件团队的成员可以对输出的结果进行审查以确保需求是正确的、完整的、完全可理解的、可以测试的。 工具对软件测试活动的支持可以分为下面这些阶段： ·定义测试完成的准则 ·设计测试用例 ·建立测试用例 ·执行测试 ·确认测试结果 ·确认测试覆盖率 ·管理测试库 BenderRBT的主要任务放在定义测试完成准则，设计功能测试用例满足必须的准则，确认测试覆盖率，并且协助确认测试结果和测试库管理上面。 产品参数 BenderRBT包含了两个完全独立的测试用例设计引擎： 1.RBT：因果图测试用例设计模块 2.Quick Design：基于正交组合对测试用例设计模块 RBT的主要功能： 优化需求 系统的需求必须是明确的没有歧义的才能够使得开发的系统是正确的，并且是可测试的，通过使用RBT，开发团队必须对需求进行认真分析和审查，这样可以发现需求中存在的错误或者不一致的地方，通过因果图可以对需求中的输入和输出之间的关系和约束进行全面的了解，RBT提供的多种形式的报告可以让开发单位和用户单位对所开发的系统对需求统一认识，尽早的发现需求中存在的问题。 因果图设计 因果图是成熟的技术，在工程中常用来需求验证和测试用例设计，因果图法实际上是把文本的需求规格说明转化为图形的一种方法，需求规格说明中的功能之间的关系通过因果图清晰的表示出来，每个输入和其他输入的关系，和输出直接的关系，还包括条件制约，节点的可观测性在这个阶段都需要指定，软件工程师在这个过程中可以充分的理解需求发现需求中存在的错误、不一致、不够详细或者存在模糊的描述等等问题，这些问题通常只有到集成测试时才能发现。 图一 RBTg是因果图编辑工具，提供了一个简单快捷的因果图编辑环境，直接从绘图工具里面选择现成的节点，逻辑关系符号、制约条件加上连线就构成一个因果图。RBT所生成的测试用例或者格式化的需求报告可以用来作为开发单位和用户之间评审交流的基本资料，RBT提供的测试脚本包含了测试过程中每一步的输入和输出(见图二) 图二 最少的测试用例实现最大的功能覆盖 如果测试工程师完全按照自己的经验或者感觉来设计测试用例，很难保证100%覆盖系统的所有的功能，研究报告表明一般来讲只能覆盖30-40%，BenderRBT采用的是严格的数学逻辑算法推到出最小数目的测试用例，并实现最大的功能覆盖率，实际上如果一个系统有37个输入，如果穷举测试的话需要1300亿测试用例，BenderRBT在1秒的时间内算出只需要22个测试用例就可以满足文档中描述的所有的功能需求覆盖。BenderRBT也提供功能和测试用例的对应关系表(图三)。 图三 Quick Design的主要功能： 基于正交组合对法设计测试用例 Quick Design提供了变量输入和变量状态的输入功能，用户需要按照需求规格说明找出系统的输入，和输入的各个状态，比如对于GUI测试，每个输入的下拉框选项对应的就是输入的各个状态，当GUI比较复杂，选项、菜单、按钮很多的时候