【转】测试设计工具BenderRBT与T-VEC的比较

在上期的关于BenderRBT工具介绍的Webinar中,有学员提问BenderRBT工具与T-VEC工具有什么不同,Richard Bender现场做了解答,现将Richard更详细的答复共享给各位参考。

The biggest difference between RBT and T-VEC is that RBT is far more sophisticated in how it designs the tests.  There are two major challenges any test design tool must overcome.  The first is to reduce the nearly infinite number of possible tests down to a finite number that can be developed and run in the project’s time constraints.  RBT’s algorithms are highly optimized and beat all other tools by at least a 4 to 1 margin – i.e. more coverage with fewer tests. 

 

The second issue goes to why we are testing in the first place – to identify any defects that might be hidden in the code.  Only RBT “sensitizes” the path through the logic to ensure that you are getting the right answer for the right reason.  We do this by using the algorithms based on the hardware logic testing’s path sensitizing algorithms – the same ones used by Intel, IBM, AMD, and anyone else producing large scale integrated circuits.  T-VEC uses rather simple path coverage – i.e. go through each requirement at least once.  T-VEC’s approach cannot find defects that cancel each out sometimes or defects that are sometimes hidden by other parts of the logic working correctly and taking precedence.  RBT is also stronger at negative testing.

 

T-VEC requires that the requirements be written in their tool.  RBT does not care how the original requirements are written.  The testers easily model the important behavior via the Cause-Effect Graph.

 

There are numbers of vendors that have test case design tools.  What makes RBT unique is a number of things:

 

            1. It is the only tool which supports both Cause-Effect Graphing and pair-wise / equivalence class testing.

            2. For pair-wise testing there are three different test design engines: orthogonal pairs and two optimized pairs engines.  Other tools only have one choice.  This allows RBT to also be used for

                 functional testing (using cause-effect graphing or optimized pairs) as well as configuration testing and creating seed tests for performance testing (via orthogonal pairs)

            3. It is the only tool that sensitizes the path through the logic to ensure that you got the right answer for the right reason – which is why we testing in the first place.

            4. It produces the smallest test library with the maximum coverage.  No other tool’s test design engine is as optimized as ours.

            5. RBT supports the full set of constraints – e.g. Exclusive, Inclusive.  Very few tools have this feature at all which means they produce many invalid tests.  This also allows it to do a full logical

                consistency check of the rules.

            6. RBT does full negative testing.

            7. Tests that RBT designs include the expected output.  Almost all other tools only tell you what inputs to use.  The user has to determine the output for each test. (note: T-VEC also predicts the

                 results).

            8. RBT is the only tool I know of that supports using existing tests (whether designed by RBT or not) by measuring their coverage and telling you what you need to update given the rules changes.

            9. RBT is the only tool I know of that includes functional coverage based on which tests passed or failed which factors in the issue that defects might be hiding each other (see Strong and Weak

                Coverage in RBT).  T-VEC just uses a simple path coverage.

          10. RBT is the only tool that identifies the optimal subset of tests with the most coverage if you do not have time to build and run them all initially.

          11. RBT has exports to many other tools.  Most other test design tools have no exports.  It also has an export API which can be used to drive home grown tools – e.g. for embedded systems.

Comment Box is loading comments...