• MBT Modeling - Finite State Machine notation.
• SuperState and SubModel - organize and partition larger model into smaller re-usable library components.
• Graphs - model graph, sequence graph and coverage graph.
• Model Import/Merge - UML XMI model and other XML based graph modeling formats (GraphXML and GraphML).
• Test Case Generation - from random walk to minimal traversals to mCase (custom test case).
• Scripting - java and mScript (xml based scripting).
• Data Driven Testing (DDT) - scriptless DDT, read data from database or Excel.
• JDBC/ODBC Support - access to relational databases to read, write, store and verify test result.
• Integration - java IDE (Eclipse, NetBeans), JUnit, batch / cron, REST websvc and remote agent to integrate with other test automation tools.
• Cross Browser - test web applications on IE, Firefox and many other browsers.
• Extensibility - custom plug-in capability to test varied types of applications.
• Debug - set breakpoints and step through model execution, visual highlighting during debugging, automatically log test steps that lead to the failures.
• Load Testing - virtual users, realistic simulation of production load.
• Reporting - test coverage, failure and performance stats, statistical analysis, 5 levels of defect categorization.
• IDE Web App - browser based application on major browsers including PDA and iPhone
• Security - Ldap and file based HTTP authentication to prevent unauthorized access.
• Requirement Traceability - tag requirements to states, transitions or mSript.
• Test Data Generation - various ways to generate test data including pairwise and combinatorial algorithms.
• Model Animation - visually displays transition traversals on the graph during model execution.
• Test Multiple Types of Applications Simultaneously - synchronize testing of web application, windows application and backend process at the same time.

mScript is a very simple xml style scripting language. You write a snippet of mScript within the integrated mScript editor and attached it to recognized triggers (such as events). Triggers are fired in sequence when the states and transitions are traversed. When triggers are fired, the attached mScripts are executed.

There are many triggers associated with states, transitions and severl system events. For example a transition has these triggers (listed in the order of execution): prep, action and verify.

Additionally there are non-state/transition specific triggers like model start and end triggers and error and exception handling triggers.

mScript can also be used to write the generated test sequences to a file in external format for offline testing. For example, you can format the output to VBScript, java, Phython, TTCN-3 compatible or to csv file, which are then executed outside TestOptimal to test your target applications using other test automation tools. This can can also be done with an XSL transformer script.

Click here for an example of an mScript.

mCases are an executable group of states and transitions organized into an executable scenarios. mCase's are executed by unique sequencers: mCaseOptimal and mCaseSerial. When run with multiple virtual users, you can readily replicate the load created in a realistic simulation of production use pattern.

You can easily reuse any states and transitions from a prepared model and copy thein these into an mCase. The states and transitions do not need to be consecutive. TestOptimal uses built-in optimization algorithm to find the shortest test sequence to traverse all states and transitions listed in the mCase with minimum duplicates. This is a well-known Chinese Postman Problem.

mCase allows you to perform incremental testing of parts of your application affected by the changes. You can create as many mCases as you need and execute subsets or all of mCases at will.

You can also create Data-Driven testing using mCase. As each transition in an mCase is traversed, a row of test data is retrieved from the dataset to set up unique test scenario. The dataset can be loaded from either a database, csv file or MS Excel workbook.

-RandomSequencer
RandomSequencer generates test sequences by randomly selecting an available transition from the current state. You can set conditions when to stop the test execution.

• GreedySequencer
  GreedySequencer works the same way as RandomSequencer except that it prefers un-traversed (un-executed) transitions over already traversed transitions. This helps to achieve the desired coverage with less number of test steps.
  
• OptimalSequencer
  OptimalSequencer uses proven optimization algorithms to generate the optimal test sequences to achieve 100% coverage of your application in least amount of time.
  
• PriorityPath
  PriorityPath sequencer generates test sequences based on weights assigned to each transition, as the result, transitions with higher weight tend to be tested first.
  
• mCaseOptimal
  mCaseOptimal generates optimal test sequences to cover all states and transitions contained in the mCase. mCase can be created and removed easily. It allows you quickly create test cases/scenarios to test specific aspects of the application.
  You may also use mCaseOptimal with virtual users to simulate concurrent users running certain usage patterns scenarios.
  
• mCaseSerial
  mCaseSerial works the same way as mCaseOptimal except that the test sequence preserves the order of transitions/states listed in the mCase.
  

With TestOptimal's plug-in architecture you can create your own plug-in to test any type of application, e.g. GUI rich client/server application or processes that don't have the user interface.

You can also create user defined functions and make them available in mScript.

You can re-purpose all of your models created for functional testing to perform load testing with minimal changes involving removing the verification steps from the models created. Runtime virtual users simulate concurrent user activities on the actual application. Each virtual user runs in its own thread executing the test sequences. Depending on which sequencer you choose, you can simulate different use patterns for your application as they would occur in production.

If you have a set of scenarios you want to ensure are tested under production load, you can create mCases for those scenarios and set the model to iterate through these mCases for each virtual user.

You can control how long the stress / load testing should run or use the real-time statistics collected / analyzed by TestOptimal to determine when the test execution should be stopped. The test execution can be monitored anywhere with a browser.