The Classification Tree Method is a method for test design, [1] as it is used in different areas of software development. [2] It was developed by Grimm and Grochtmann in 1993. [3] Classification Trees in terms of the Classification Tree Method must not be confused with decision trees.
The classification tree method consists of two major steps: [4] [5]
The identification of test relevant aspects usually follows the (functional) specification (e.g. requirements, use cases …) of the system under test. These aspects form the input and output data space of the test object.
The second step of test design then follows the principles of combinatorial test design. [4]
While the method can be applied using a pen and a paper, the usual way involves the usage of the Classification Tree Editor, a software tool implementing the classification tree method. [6]
Prerequisites for applying the classification tree method (CTM) is the selection (or definition) of a system under test. The CTM is a black-box testing method and supports any type of system under test. This includes (but is not limited to) hardware systems, integrated hardware-software systems, plain software systems, including embedded software, user interfaces, operating systems, parsers, and others (or subsystems of mentioned systems).
With a selected system under test, the first step of the classification tree method is the identification of test relevant aspects. [4] Any system under test can be described by a set of classifications, holding both input and output parameters. (Input parameters can also include environments states, pre-conditions and other, rather uncommon parameters). [2] Each classification can have any number of disjoint classes, describing the occurrence of the parameter. The selection of classes typically follows the principle of equivalence partitioning for abstract test cases and boundary-value analysis for concrete test cases. [5] Together, all classifications form the classification tree. For semantic purpose, classifications can be grouped into compositions.
The maximum number of test cases is the Cartesian product of all classes of all classifications in the tree, quickly resulting in large numbers for realistic test problems. The minimum number of test cases is the number of classes in the classification with the most containing classes.
In the second step, test cases are composed by selecting exactly one class from every classification of the classification tree. The selection of test cases originally [3] was a manual task to be performed by the test engineer.
For a database system, test design has to be performed. Applying the classification tree method, the identification of test relevant aspects gives the classifications: User Privilege, Operation and Access Method. For the User Privileges, two classes can be identified: Regular User and Administrator User. There are three Operations: Add, Edit and Delete. For the Access Method, again three classes are identified: Native Tool, Web Browser , API . The Web Browser class is further refined with the test aspect Brand, three possible classes are included here: Internet Explorer , Mozilla Firefox , and Apple Safari .
The first step of the classification tree method now is complete. Of course, there are further possible test aspects to include, e.g. access speed of the connection, number of database records present in the database, etc. Using the graphical representation in terms of a tree, the selected aspects and their corresponding values can quickly be reviewed.
For the statistics, there are 30 possible test cases in total (2 privileges * 3 operations * 5 access methods). For minimum coverage, 5 test cases are sufficient, as there are 5 access methods (and access method is the classification with the highest number of disjoint classes).
In the second step, three test cases have been manually selected:
The CTM introduced the following advantages [2] over the Category Partition Method [7] (CPM) by Ostrand and Balcer:
The classification tree method first was intended for the design and specification of abstract test cases. With the classification tree method for embedded systems, [8] test implementation can also be performed. Several additional features are integrated with the method:
The module and unit testing tool Tessy relies on this extension.
One way of modelling constraints is using the refinement mechanism in the classification tree method. This, however, does not allow for modelling constraints between classes of different classifications. Lehmann and Wegener introduced Dependency Rules based on Boolean expressions with their incarnation of the CTE. [9] Further features include the automated generation of test suites using combinatorial test design (e.g. all-pairs testing).
Recent enhancements to the classification tree method include the prioritized test case generation: It is possible to assign weights to the elements of the classification tree in terms of occurrence and error probability or risk. These weights are then used during test case generation to prioritize test cases. [10] [11] Statistical testing is also available (e.g. for wear and fatigue tests) by interpreting the element weights as a discrete probability distribution.
With the addition of valid transitions between individual classes of a classification, classifications can be interpreted as a state machine, and therefore the whole classification tree as a Statechart. This defines an allowed order of class usages in test steps and allows to automatically create test sequences. [12] Different coverage levels are available, such as state coverage, transitions coverage and coverage of state pairs and transition pairs.
In addition to Boolean dependency rules referring to classes of the classification tree, Numerical Constraints allow to specify formulas with classifications as variables, which will evaluate to the selected class in a test case. [13]
The Classification Tree Editor (CTE) is a software tool for test design that implements the classification tree method. [14] [15] [16] [17]
Over the time, several editions of the CTE tool have appeared, written in several (by that time popular) programming languages and developed by several companies.
The original version of CTE was developed at Daimler-Benz Industrial Research [6] [16] facilities in Berlin. It appeared in 1993 and was written in Pascal. It was only available on Unix systems.
In 1997 a major re-implementation was performed, leading to CTE 2. Development again was at Daimler-Benz Industrial Research. It was written in C and available for win32 systems.
The CTE 2 was licensed to Razorcat in 1997 and is part of the TESSY unit test tool. The classification tree editor for embedded systems [8] [15] also based upon this edition.
Razorcat has been developing the CTE since 2001 and has CTE registered a brand name in 2003.
The last version CTE 3.2 was published with the tool TESSY 4.0 in 2016. Note the Versions table below.
The CTE 4 was implemented in TESSY 4.1.7 as an Eclipse plug-in in 2018. The latest CTE 4 version is still being developed as part of TESSY 4.3 in 2021.
In 2000, Lehmann and Wegener introduced Dependency Rules with their incarnation of the CTE, the CTE XL (eXtended Logics). [9] [14] [17] [18] Further features include the automated generation of test suites using combinatorial test design (e.g. all-pairs testing). [19]
Development was performed by DaimlerChrysler. CTE XL was written in Java and was supported on win32 systems. CTE XL was available for download free of charge.
In 2008, Berner&Mattner acquired all rights on CTE XL and continued development till CTE XL 1.9.4.
Starting in 2010, CTE XL Professional was developed by Berner&Mattner. [10] A complete re-implementation was done, again using Java but this time Eclipse-based. CTE XL Professional was available on win32 and win64 systems.
New developments included:
In 2014, Berner&Mattner started releasing its classification tree editor under the brand name TESTONA.
A free edition of TESTONA is still available for download free of charge, however, with reduced functionality.
Version | Date | Comment | Written in | OS |
---|---|---|---|---|
CTE 1.0 | 1993 | Original Version, [6] [16] limited to 1000 test cases (fix!) | Pascal | Unix |
CTE 2.0 | 1998 | Windows Version, [15] unlimited number of test cases | C++ | win32 |
CTE 2.1 | 2003 | Embedded system version of Razorcats part of the TESSY tool. | C++ | win32 |
CTE XL 1.0 | 2000 | Dependency Rules, Test Case Generation [9] [14] [17] | Java | win32 |
CTE XL 1.6 | 2006 | Last Version by Daimler-Benz [18] | Java | win32 |
CTE XL 1.8 | 2008 | Development by Berner&Mattner | Java | win32 |
CTE XL 1.9 | 2009 | Last Java-only Version | Java | win32 |
CTE XL Professional 2.1 | 2011-02-21 | First Eclipse-based Version, Prioritized Test Case Generation, [10] Deterministic Test Case Generation, Requirements-Tracing with DOORS | Java 6, Eclipse 3.5 | win32 |
CTE XL Professional 2.3 | 2011-08-02 | QualityCenter integration, Requirements Coverage Analysis and Traceability Matrix, API | Java 6, Eclipse 3.6 | win32 |
CTE XL Professional 2.5 | 2011-11-11 | Test result annotation, MindMap import | Java 6, Eclipse 3.6 | win32, win64 |
CTE XL Professional 2.7 | 2012-01-30 | Bug fix release | Java 6, Eclipse 3.6 | win32, win64 |
CTE XL Professional 2.9 | 2012-06-08 | Implicit Mark Mode, Default classes, command-line interface | Java 6, Eclipse 3.7 | win32, win64 |
CTE XL Professional 3.1 | 2012-10-19 | Test Post-Evaluation (e.g. for Root Cause Analysis), Test Sequence Generation, [12] Numerical Constraints [13] | Java 6, Eclipse 3.7 | win32, win64 |
CTE XL Professional 3.3 | 2013-05-28 | Test Coverage Analysis, Variant Management (e.g. as part of Product Family Engineering), Equivalence Class Testing | Java 6, Eclipse 3.7 | win32, win64 |
CTE XL Professional 3.5 | 2013-12-18 | Boundary Value Analysis Wizard, Import of AUTOSAR and MATLAB models | Java 7, Eclipse 3.8 | win32, win64 |
TESTONA 4.1 | 2014-09-22 | Bug fix release | Java 7, Eclipse 3.8 | win32, win64 |
TESTONA 4.3 | 2015-07-08 | Generation of Executable Test Scripts (Code Generation), Import of Test Results [21] | Java 7, Eclipse 3.8 | win32, win64 |
TESTONA 4.5 | 2016-01-21 | Enhanced Export Facilities, GUI Improvements | Java 7, Eclipse 3.8 | win32, win64 |
TESTONA 5.1 | 2016-07-19 | Bug fix release, Switch to Java 8, Eclipse 4.5 | Java 8, Eclipse 4.5 | win32, win64 |
CTE 4.0 | 2018-08-01 | New implementation of Razorcat as a plug-in for the TESSY 4.1 tool based on Eclipse. Support in creating (model-based) test cases. | Java | win32 win64 |
Software is a set of computer programs and associated documentation and data. This is in contrast to hardware, from which the system is built and which actually performs the work.
Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not necessarily limited to:
An embedded system is a computer system—a combination of a computer processor, computer memory, and input/output peripheral devices—that has a dedicated function within a larger mechanical or electronic system. It is embedded as part of a complete device often including electrical or electronic hardware and mechanical parts. Because an embedded system typically control the physical operations of the machine that it is embedded within, it often has real-time computing constraints. Embedded systems control many devices in common use. In 2009, it was estimated that ninety-eight percent of all microprocessors manufactured were used in embedded systems.
In computer programming, unit testing is a software testing method by which individual units of source code—sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures—are tested to determine whether they are fit for use. It is a standard step in development and implementation approaches such as Agile.
In the context of hardware and software systems, formal verification is the act of proving or disproving the correctness of a system with respect to a certain formal specification or property, using formal methods of mathematics. Formal verification is a key incentive for formal specification of systems, and is at the core of formal methods. It represents an important dimension of analysis and verification in electronic design automation and is one approach to software verification. The use of formal verification enables the highest Evaluation Assurance Level (EAL7) in the framework of common criteria for computer security certification.
In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
Model-based testing is an application of model-based design for designing and optionally also executing artifacts to perform software testing or system testing. Models can be used to represent the desired behavior of a system under test (SUT), or to represent testing strategies and a test environment. The picture on the right depicts the former approach.
FitNesse is a web server, a wiki and an automated testing tool for software. It is based on Ward Cunningham's Framework for Integrated Test and is designed to support acceptance testing rather than unit testing in that it facilitates detailed readable description of system function.
Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.
Software project management is the process of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.
In software engineering, graphical user interface testing is the process of testing a product's graphical user interface (GUI) to ensure it meets its specifications. This is normally done through the use of a variety of test cases.
Data-driven testing (DDT), also known as table-driven testing or parameterized testing, is a software testing methodology that is used in the testing of computer software to describe testing done using a table of conditions directly as test inputs and verifiable outputs as well as the process where test environment settings and control are not hard-coded. In the simplest form the tester supplies the inputs from a row in the table and expects the outputs which occur in the same row. The table typically contains values which correspond to boundary or partition input spaces. In the control methodology, test configuration is "read" from a database.
Model-based design (MBD) is a mathematical and visual method of addressing problems associated with designing complex control, signal processing and communication systems. It is used in many motion control, industrial equipment, aerospace, and automotive applications. Model-based design is a methodology applied in designing embedded software.
Domain-driven design (DDD) is a major software design approach, focusing on modeling software to match a domain according to input from that domain's experts.
A metaCASE tool is a type of application software that provides the possibility to create one or more modeling methods, languages or notations for use within the process of software development. Often the result is a modeling tool for that language. MetaCASE tools are thus a kind of language workbench, generally considered as being focused on graphical modeling languages.
TPT is a systematic test methodology for the automated software test and verification of embedded control systems, cyber-physical systems, and dataflow programs. TPT is specialised on testing and validation of embedded systems whose inputs and outputs can be represented as signals and is a dedicated method for testing continuous behaviour of systems. Most control systems belong to this system class. The outstanding characteristic of control systems is the fact that they interact closely interlinked with a real world environment. Controllers need to observe their environment and react correspondingly to its behaviour. The system works in an interactional cycle with its environment and is subject to temporal constraints. Testing these systems is to stimulate and to check the timing behaviour. Traditional functional testing methods use scripts – TPT uses model-based testing.
In computer programming and software development, debugging is the process of finding and resolving bugs within computer programs, software, or systems.
Fastest is a model-based testing tool that works with specifications written in the Z notation. The tool implements the Test Template Framework (TTF) proposed by Phil Stocks and David Carrington.
VisualSim Architect is an electronic system-level software for modeling and simulation of electronic systems, embedded software and semiconductors. VisualSim Architect is a commercial version of the Ptolemy II research project at University of California Berkeley. The product was first released in 2003. VisualSim is a graphical tool that can be used for performance trade-off analyses using such metrics as bandwidth utilization, application response time and buffer requirements. It can be used for architectural analysis of algorithms, components, software instructions and hardware/ software partitioning.
Tricentis Tosca is a software testing tool that is used to automate end-to-end testing for software applications. It is developed by Tricentis.
{{cite book}}
: |last=
has generic name (help){{cite book}}
: |last=
has generic name (help){{cite book}}
: |last=
has generic name (help)