state transition testing technique
Дізнайтеся, що таке тестування державного переходу та як використовувати діаграму державного переходу:
У нашій останній статті ми побачили Графік причин і наслідків ’Техніка написання тестових кейсів. Сьогодні перейдемо до наступного динамічного методу написання тестового випадку - техніки переходу держави.
У цьому документі розглядається розширення цієї концепції тестування на більші програми, які не є FSM в цілому, але деякі їх компоненти є, щоб прийняти його унікальну особливість 'бути державними' та правилами переходу, що призводить до багатьох переваг.
Державне перехідне тестування
Тестування державного переходу є Техніка тестування чорної скриньки , який можна застосувати для випробування „Машин кінцевого стану”.
„Кінцевий автомат (FSM)“ - це система, яка буде знаходитися в різних дискретних станах (наприклад, „готовий“, „не готовий“, „відкритий“, „закритий“…) залежно від вхідних даних або стимулів.
Дискретні стани, якими закінчується система, залежать від правил переходу системи. Тобто, якщо система дає різний вихід для одного і того ж входу, залежно від свого попереднього стану, то це система кінцевих станів.
Крім того, якщо кожна транзакція тестується в системі, це називається покриттям '0 перемикачів'. Якщо тестування охоплює 2 пари дійсних транзакцій, то це охоплення “1 перемикачем” тощо.
Що ви дізнаєтесь:
Що таке державна перехідна методика випробувань?
Техніка переходу стану - це методика динамічного тестування, яка використовується, коли система визначається з точки зору кінцевої кількості станів, а переходи між станами регулюються правилами системи.
Або іншими словами, цей прийом використовується, коли ознаки системи представляються як стани, які перетворюються одне на одне. Перетворення визначаються правилами програмного забезпечення. Живописне зображення може бути показано у вигляді:
Отже, тут ми бачимо, що сутність переходи від держави 1 до держави 2 через деякі введення стан, що призводить до подія та результати в дії і нарешті дає вихід .
Щоб пояснити це на прикладі:
Ви відвідуєте банкомат і знімаєте 1000 доларів. Ви отримуєте свої гроші. Тепер у вас закінчується баланс і ви робите такий самий запит на зняття 1000 доларів. Цього разу банкомат відмовляється передати вам гроші через недостатній баланс. Отже, тут перехід , що спричинило зміна держави - це попередній вихід
Визначення державного перехідного тестування
Зрозумівши, що таке державний перехід, ми можемо прийти до більш значущого визначення для тестування державного переходу. Отже, це своєрідне тестування чорної скриньки, в ході якого тестувальник повинен дослідити поведінку AUT (Application Test Test) проти різних умов введення, поданих послідовно.
Поведінка системи реєструється як для позитивних, так і для негативних значень тесту.
Коли застосовувати державне тестування на перехід?
Тестування державного переходу можна застосовувати в таких ситуаціях:
компанії, які платять вам за тестування їхньої продукції
- Коли тестована програма - це система реального часу з різними станами та переходами.
- Коли заявка залежить від події / цінностей / умов минулого.
- Коли потрібно перевірити послідовність подій.
- Коли додаток потрібно протестувати з кінцевим набором вхідних значень.
Коли не використовувати державне тестування на перехід?
Ви не повинні покладатися на тестування державного переходу в таких ситуаціях:
- При тестуванні не потрібно для послідовних комбінацій введення.
- Коли потрібно протестувати різні функціональні можливості програми (більше схоже на дослідницьке тестування).
Приклад тестування державного переходу в тестуванні програмного забезпечення
У практичному сценарії тестувальникам, як правило, дають діаграми державного переходу, і ми зобов'язані їх інтерпретувати.
Ці діаграми надаються або бізнес-аналітиками, або зацікавленою стороною, і ми використовуємо ці діаграми для визначення наших тестових випадків.
Давайте розглянемо нижченаведену ситуацію:
Назва програмного забезпечення - Manage_display_changes
Технічні характеристики - Програмне забезпечення відповідає на запити введення для зміни режиму відображення пристрою відображення часу.
Для режиму відображення можна встановити одне з чотирьох значень:
- Два, що відповідають відображенню часу або дати.
- Два інших при зміні або часу, або дати.
Різні стани такі:
- Режим зміни (CM): Активація цього призведе до переходу режиму відображення між “часом відображення (T)” та “датою відображення (D)”.
- Скинути (R): Якщо для режиму відображення встановлено значення T або D, тоді “скидання” призведе до того, що режим відображення буде встановлений на режими “зміни часу (AT)” або “зміни дати (AD)”.
- Набір часу (TS): Активація цього призведе до повернення режиму відображення до Т від AT.
- Встановлення дати (DS): Активація цього призведе до повернення режиму відображення до D з AD.
Діаграма переходу держави
Тепер давайте перейдемо до його інтерпретації:
Тут:
# 1) Різні держави:
- Час відображення (S1),
- Час зміни (S3),
- Відображення дати (S2) та
- Дата зміни (S4).
# 2) Різні входи:
- Режим зміни (CM),
- Скинути (R),
- Встановлений час (TS),
- Встановлення дати (DS).
# 3) Різні результати:
- Змінювати час (AT),
- Час відображення (T),
- Відображення дати (D),
- Змінювати дату (AD).
# 4) Змінені держави:
- Час відображення (S1),
- Час зміни (S3),
- Відображення дати (S2) та
- Дата зміни (S4).
Крок 1: Напишіть усі стартові стани. Для цього візьміть по одному стану і подивіться, скільки стрілок виходить з нього.
- Для штату S1 з нього виходять дві стрілки. Одна стрілка буде мати стан S3, а інша стрілка - стан S2.
- Для штату S2 - є 2 стрілки. Один йде до штату S1, а інший - до S4
- Для штату S3 - з нього виходить лише 1 стрілка, яка переходить до стану S1
- Для штату S4 - з нього виходить лише 1 стрілка, яка переходить до стану S2
Покладемо це на наш стіл:
Оскільки для станів S1 і S2 виходять дві стрілки, ми писали це двічі.
Крок -2: Для кожного штату запишіть їх остаточні перехідні стани.
- Для стану S1 - кінцевими станами є S2 та S3
- Для штату S2 - кінцевими станами є S1 та S4
- Для штату S3 - кінцевим станом є S1
- Для штату S4 - кінцевим станом є S2
Помістіть це на стіл як вихідний / результуючий стан.
Крок 3: Для кожного стартового стану та відповідного йому фінішного стану запишіть умови введення та виведення
- Щоб стан S1 перейшов у стан S2, вхідним параметром є режим зміни (CM), а виходом - дата відображення (D), показана нижче:
Подібним чином запишіть умови введення та його вихід для всіх станів таким чином:
Крок 4:
Тепер додайте ідентифікатор тесту для кожного тесту, показаного нижче:
Тепер перетворимо це на офіційні тестові кейси:
Таким чином можна отримати всі інші тестові приклади. Я припускаю, що інший атрибути тестових кейсів як передумови, серйозність, пріоритет, середовище, збірка тощо також включаються до тесту.
Підсумовуючи кроки ще раз:
- Визначте початкові стани та їх кінцевий стан на основі ліній / стрілок, які виходять із початкового стану.
- Для кожного початкового стану з’ясуйте вхідні умови та вихідний результат
- Позначте кожен набір як окремий тест.
Інші приклади державної перехідної техніки
Ось ще один приклад техніки державного перехідного тестування у більших програмних додатках.
Опис:
' Державне функціональне тестування ' підхід може бути використаний для тестування конкретних частин або компонентів програми, що характеризує машину скінченного стану (FSM).
Етапи впровадження:
# 1) Першим кроком у впровадженні «Тестування функціонального стану» є визначення різних компонентів / частин програми, які можуть бути віднесені до категорій FSM. Входи, стани та виходи ретельно відстежуються для кожного з цих FSM.
# два) Наступним кроком буде розробка тестових кейсів для цих FSM на основі правил переходу, входів, результатів та перехідних станів.
# 3) Третім кроком було б інтегрувати тестування цих компонентів з іншими взаємозв'язуючими компонентами для перевірки додатка від кінця до кінця.
Це можна пояснити на прикладі програми, яка називається «Проект будинку», яка відстежує будівництво будинку з різними компонентами програми, такими як затвердження архітектури будинку, реєстрація ділянки та будинку, вибір підрядника будівництва , затвердження житлової позики тощо.
Наприклад,
Ми розглянемо тестування одного компоненту FSM програми «Проект будинку»: схвалення житлової позики.
Заява про затвердження житлової позики (HLA)
Заяву HLA буде запускати незалежний Користувач обробки позики, який обробляє заявку на позику. Різні етапи обробки заявки докладно описані нижче:
1.1.1 Крок 1: Збір документів
Першим кроком є збір відповідних документів для оформлення позики, як зазначено в таблиці нижче. Вони є «умовами» для успішного подання заявки. Заявник збирає необхідні документи та застосовує їх до житлової позики.
Користувач обробки позики підтверджує отримання документів та переводить стан Заявки на позику (тобто стан компоненту Заяви HLA) у стан “Застосований”.
Таблиця 1: Перелік документів
1.1.2 Крок 2: Оцінка позики
На цьому етапі позикодавець оцінює заявку на позику, щоб визначити, чи відповідає вона його вимогам щодо кредитування. Підтверджуючі документи перевіряються на даний момент.
Таблиця 2: Критичність документів
Документи, необхідні для оцінки, тобто “умови”, які необхідно перевірити на цьому етапі, перевіряються. Кожна умова має критичність (згадана як 'Y' у таблиці вище). Як тільки всі необхідні критичні умови виконуються, програма переходить у стан “Підтверджено” - тобто компонент програми HLA знаходиться в стані “Підтверджено”.
безкоштовно DVD Ripper для Windows 10 - -
Зауважте:
# 1) Цей принцип вносить структуру та об'єктивність в умови тестування та визначення стану системи .
Крім того, не всі «умови» для перевірки системи є критичними для того, щоб вона дійшла до цього «Підтвердженого» стану. У наведеній вище таблиці 4 умови позначені як “Не критичні”, щоб програма дійшла до стану “Підтверджено”.
# два) Кількість перевірок можна оптимально зменшити, залежно від ризику або критичності правил, необхідних для кожного штату. Це значно зменшить час, необхідний для виконання тесту, і в той же час не погіршуючи якість тестування.
# 3) Це корисно не тільки для тестування окремих компонентів, але і для тестування системи в кінці.
# 4) Крім того, дуже корисно при створенні тестових наборів для регресії.
Отже, на цьому етапі це тестування з 0 перемикачами. Але пізніші етапи затвердження можуть бути типами перевірки на 1 або 2 перемикачі для цього етапу.
Наприклад, „Свідоцтво про шлюб” на цьому етапі може бути не надто актуальним, але на останніх етапах затвердження, коли розглядається ризик заявника сплатити EMI, свідоцтво про шлюб може стати актуальним - тобто, якщо чоловік / дружина теж працює , це зменшує ризик, а якщо не застосовується, то збільшує ризик.
# 5) Зазначений вище принцип може бути використаний для розширення умов випробування залежно від вимог компонента на цьому етапі.
1.1.3 Крок 3: Умовне схвалення
Поточний стан програми 'Підтверджено'. Кредитор надасть 'умовне схвалення' для просування позики вперед. Подальші перевірки необхідні для переміщення програми HLA у стан 'Затверджено'.
1.1.4 Крок 4: Схвалення
На цьому етапі проводяться критичні перевірки:
- Оцінка іпотечного страхування позикодавців (LMI): це передбачає перевірку справжності власності на два перемикачі або більше.
- Кредитор може вимагати інформацію, яку не було надано на етапі “Підтвердження”.
Після виконання вищезазначених умов додаток переходить у стан “Затверджено”. Остаточний орган процесу затвердження може перехресно перевірити достовірність заявника на позику, запитуючи більше деталей, або не запитувати, чи є інші документи заявника остаточними. Тобто для підтвердження дійсності потрібно більше вхідних даних від різних компонентів основної програми .
# 6) Іншими словами, може знадобитися (або зменшити) більше перевірок для переходу в інший стан залежно від умов введення в компонент інших компонентів програми.
На діаграмі нижче зображено процес затвердження.
Рисунок 1: Процес затвердження позики
Ризики та виклики
- Для великих додатків необхідні глибокі знання програми для розбиття програми на різні логічні компоненти, щоб забезпечити можливість класифікації як FSM та звичайні компоненти. Це може зажадати від МСП дорогого часу.
- Не всі додатки мали б можливість здійснити такий вид категоризації FSM.
- Оскільки компоненти FSM взаємодіють із звичайними компонентами програми, входи до FSM від різних компонентів вимагають ретельного планування та виконання.
Переваги державного перехідного тестування
- За цією методикою, використовуючи графічне або табличне зображення поведінки системи, тестувальник знайомиться з дизайном програми та відчуває легкість висвітлювати та розробляти тести ефективно та ефективно.
- Заплановані або недійсні стани системи також охоплюються використанням цієї техніки.
- Використовуючи діаграму державного переходу, легко перевірити, чи всі умови виконуються.
Недоліки державного перехідного тестування
- Цей прийом не можна використовувати для систем з нескінченним станом.
- Визначення всіх можливих станів для великих і складних систем є досить громіздким завданням.
Висновок
Тестування державного переходу є корисним підходом, коли для перевірки різних системних переходів для систем кінцевих станів.
Тестування програми з концепцією “Державне функціональне тестування” може надати тестуючим організаціям унікальний підхід до тестування для тестування складних додатків, який збільшить продуктивність виконання тестів без шкоди для покриття тесту.
Тестування державного переходу - це унікальний підхід до тестування складних додатків, який збільшить продуктивність виконання тесту без шкоди для покриття тесту.
Обмеження цієї методики полягає в тому, що вона не може бути використана до тих пір, поки система, що тестується, не має лише скінченних станів.
Рекомендована література
- Що таке техніка тестування на основі дефектів?
- Що таке техніка тестування ортогональних масивів (OATS)?
- Функціональне тестування проти нефункціонального тестування
- Що таке порівняльне тестування (Дізнайтеся на прикладах)
- Що таке тестування мутацій: Підручник із прикладами
- Що таке тестування на витривалість у тестуванні програмного забезпечення (приклади)
- Що таке наскрізне тестування: Структура тестування E2E з прикладами
- Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)