Testing dan Implementasi Sistem materi 4

State-Transition Testing Example in Reservation system

State-Transition Testing Example State-Transition diagrams are an excellent tool to capture certain types of system requirements and to document internal system design. These diagrams document the events that come into and are processed by a system as well as the system's responses.

Reservation system example 1- Make a reservation Provide information including departure and destination cities, dates, and times. A reservation agent uses that information to make a reservation. At that point, the Reservation is in the Made state. The system creates and starts a timer. If this timer expires before the reservation is paid for, the reservation is cancelled by the system.

The Reservation is Made giveInfo, is an event that comes into the system from the outside world. The command after the "/" denotes an action of the system; in this case startPayTimer.

2- Pay for the Reservation - PayMoney The Reservation transitions to the Paid state. Events may have parameters associated with them. For example, Pay Money may indicate Cash, Check, Debit Card, or Credit Card

3- Print the ticket: - print The Reservation transitions to the Ticketed state.

4- Give ticket giveTicket to the gate agent to board the plane The Reservation transitions to the Used state.

4- Give ticket (Cont.) The path ends

5- Cancel for no payment by the ‘PayTimer’ If the Reservation is not paid the PayTimer expires and the Reservation is cancelled for non-payment.

6- Cancel by customer When the customer asks to cancel the Reservation Cancel the Reservation from the Made state

7- Cancel by customer after payment A Reservation is cancelled from the Paid state, a Refund should be generated and leave the system Cancellation from the Paid state

8- Customer cancels after receiving the ticket From the Ticketed state, the customer can cancel the Reservation. In that case a Refund should be generated. The airline will generate a refund but only when it receives the printed Ticket from the customer. This introduces one new notational element—square brackets [....] that contain a conditional that can be evaluated either True or False. This conditional acts as a guard allowing the transition only if the condition is true.

8- Customer cancels after receiving the ticket (cont.) Cancellation from the Ticketed state

State-Transition Tables  Creating Test Cases State-transition tables may be easier to use in a complete and systematic manner. State-transition tables consist of four columns  Current State, Event, Action, and Next State.

A set of test cases that "visit" each state Creating Test Cases Create a set of test cases such that all states are "visited" at least once under test. The set of three test cases shown below meets this requirement. Generally this is a weak level of test coverage. A set of test cases that "visit" each state

A set of test cases that trigger all transitions at least once Create a set of test cases such that all transitions are exercised at least once under test. This level of testing provides a good level of coverage without generating large numbers of tests. This level is generally the one recommended. A set of test cases that trigger all transitions at least once

4. A set of test cases that trigger all transitions at least once (Cont.) Test cases can also be read directly from the state-transition table. The gray rows in the following table show all the valid transitions.

The End Session Any Problems???

Kelas “Reservation”

Kelas “Made”

Kelas “Paid”

State-Transition Testing (Cont.) Summary State-Transition diagrams efforts by identifying the states, events, actions, and transitions . These define how a system interacts with the outside world, the events it processes, and the valid and invalid order of these events. The generally recommended level of testing using state-transition diagrams is to create a set of test cases such that all transitions are exercised at least once under test. In high-risk systems, you may want to create even more test cases, approaching all paths if possible or create test cases for some or all of the invalid state/event pairs to make sure the system has not implemented invalid paths.

State-Transition Tables (Cont.) The advantage of a state-transition table is that it lists all possible state-transition combinations, not just the valid ones. When testing critical, high-risk systems such as avionics or medical devices, testing every state-transition pair may be required, including those that are not valid. Creating a state-transition table often unearths combinations that were not identified, documented, or dealt with in the requirements. It is highly beneficial to discover these defects before coding begins.

State-Transition Tables (Cont.) Using a state-transition table can help detect defects in implementation that enable invalid paths from one state to another. The disadvantage of such tables is that they become very large very quickly as the number of states and events increases. In addition, the tables are generally sparse; that is, most of the cells are empty.

Contoh Software Testing SILK CENTRAL http://www.borland.com/Products/Software-Testing/Test-Management/Silk-Central?gclid=CjwKEAjw4-SrBRDP483GvreDr2ASJAD5sCIucEXCeYdWJENRpltmoiyW92C1v4tyf9mxPCERKv-RnhoCVP_w_wcB The open test management solution which unifies all test assets into one easy-to-use planning, tracking, reporting and execution hub. Silk Central enables you to gain control, collaboration and traceability across all areas of your software testing, whether your methodology is Agile, Traditional or hybrid. Silk Central provides integration of requirements, manual and automated tests, defect tools and your test execution, giving full traceability of the quality of your software testing regardless of role.

TESSY The Invaluable Test Tool http://www.hitex.com/index.php?id=module-unit-test&L=0&gclid=CjwKEAjw4-SrBRDP483GvreDr2ASJAD5sCIueeIJVq3L72HvWvc9MVLY9FGuayriZ4ZI7bAa9KJ03hoComnw_wcB New: TESSY V3.2 released! Automated unit / module testing of embedded software Traceability of requirements Component testing = Integration testing of the units Easy to begin using - no script language to learn Test drivers and stubs built automatically Ideal for regression testing For certifications according to IEC 61508, ISO 26262, DO-178B, and other standards Includes the Classification Tree Editor (CTE) for Test Case Specification

Software Quality: Tools Handle standards using RiskCAT  Standards like IEC 61508 or ISO 26262 comprise of several hundreds of possible measures. RiskCAT helps to select and comment the measures of IEC 61508 and other standards. Static software analysis Static software analysis generates investigates the source code of a program. This may reveal questionable constructs in the code, or allows calculating metrics. Advanced techniques point to actual errors that will occur during runtime if not fixed. Static software analysis using DAC. The Development Assistant for C (DAC) checks coding rules like the MISRA rule set, calculates metrics, displays call graphs, etc. Static software analysis using PC-lint.   The command line tool PC-lint checks C / C++ source code. Works across modules. Supports MISRA C and C++. Test case specification using CTE Specify your test cases using the Classification Tree Method (CTM) which is supported by the Classification Tree Editor (CTE).  Unit / module / integration testing using Tessy Tessy provides automated unit / module / integration testing of embedded software written in C/C++ directly on the actual target hardware. It determines code coverage and generates test documentation. http://www.hitex.com/index.php?id=1722&L=0%2F%2Fasset%20%E2%80%A6%2F%2F%2Fassets%2Fsnippets%2Freflect%2Fsnippet.reflect.php%3Freflect_base%3D%5C%27%5C%22