Меню

Виконання тесту при тестуванні програмного забезпечення: точний процес та план на прикладі

test execution software testing

Спробуйте Наш Інструмент Для Усунення Проблем

Точний процес та плануйте виконання тестових справ на реальних прикладах.

Сьогодні в нашому Міні-навчальний курс тестування програмного забезпечення , ми переходимо до останнього етапу STLC, яким є Виконання тесту .

Ви можете ознайомитися зі списком усіх навчальних посібників, опублікованих у цій безкоштовній серії навчальних програм з контролю якості на цій сторінці: Навчання з тестування програмного забезпечення на живому проекті.

Виконання тесту - це, без сумніву, найважливіший та найпотужніший етап у STLC а також весь життєвий цикл розробки. Причина полягає в тому, що внесок і робота кожної команди / члена команди перевіряється тут:

Виконання тесту при тестуванні програмного забезпечення

  • Чи правильно аналізував бізнес-аналітик вимоги?
  • Чи перетворила команда розробників бізнес-вимоги на функціональні вимоги і врешті-решт правильно кодувати?
  • Чи спроектували архітектор даних та адміністратори адміністраторів даних правильні внутрішні системи?

Ну, тестове виконання - це місце, де можна знайти всі відповіді на ці запитання. Це робить нас, QA, героями всього процесу побудови програмного забезпечення, чи не так? :)

Виконання тесту також є частиною 'Тестування' SDLC.

що мені потрібно для запуску файлу jar -

Після того, як тестові кейси будуть написані, передані BA та команді розробників, переглянуті ними, команди з контролю якості (якщо такі є) повідомляються про зміни, команда QA вносить необхідні зміни - Фаза проектування тесту завершена. Зараз підготовка тестових кейсів не означає, що ми можемо розпочати тестовий запуск. Потрібно, окрім іншого, мати готову програму.

Що ви дізнаєтесь:

Керівництво тестовим виконанням

Давайте зараз складемо перелік усіх речей, важливих для розуміння етапу виконання тесту:

# 1) побудувати (код, написаний командою розробників, упакований у те, що називається збіркою - це не що інше, як встановлене програмне забезпечення (AUT), готове до розгортання в середовищі контролю якості.), що розгортається (іншими словами, встановлюється і надано доступним) для середовища контролю якості - це один з найважливіших аспектів, який повинен відбутися для початку виконання тесту.

# два) Виконання тесту відбувається в QA середовище . Щоб переконатися, що робота команди розробників над кодом знаходиться не в тому самому місці, де тестує команда контролю якості, загальна практика полягає у створенні спеціального середовища для розробників та контролю якості. (Існує також виробниче середовище для розміщення програми в реальному часі).

Це в основному для збереження цілісності програми на різних етапах життєвого циклу SDLC. В іншому випадку в ідеалі всі 3 середовища однакові за своєю суттю.

# 3) Розмір тестової групи не є постійною з початку проекту. Коли ініціюється план тестування, команда може просто мати керівника команди. На етапі проектування тестів на борт з’являється кілька тестувальників. Виконання тесту - це фаза, коли команда перебуває на максимальному рівні.

Запитання та відповіді на основі сценарію sql

# 4) Виконання тесту також відбувається в принаймні 2 цикли (3 у деяких проектах). Як правило, у кожному циклі будуть виконуватися всі тестові кейси (весь набір тестів). Метою першого циклу є виявлення будь-яких блокуючих, критичних дефектів та більшості високих дефектів.

Завдання другого циклу - виявити залишилися високі та середні дефекти, виправити прогалини в сценаріях та отримати результати.

# 5) Етап виконання тесту складається з- Виконання тестових скриптів + ​​обслуговування тестових скриптів (виправлення прогалин у сценаріях) + звітування (дефекти, стан, показники тощо) Тому при плануванні цього етапу графіки і зусилля слід оцінити беручи до уваги всі ці аспекти, а не лише виконання сценарію.

# 6) Після завершення тестового сценарію та розгортання AUT - і перед початком виконання тесту відбувається посередницький крок. Це називається “Огляд готовності до тесту (TRR)” . Це свого роду перехідний крок, який завершить етап проектування тесту та полегшить нам виконання тесту.

Для отримання інформації щодо цього кроку та зразка «Контрольний список перевірки готовності до перевірки» перегляньте це посилання: Контрольний список тестування програмного забезпечення

# 7) На додаток до TRR, є ще кілька додаткових перевірок, перш ніж ми гарантуємо, що зможемо продовжувати приймати поточну збірку, яка розгортається в середовищі контролю якості для виконання тесту.

Це такі Тести на дим і розум . Детальна інформація про те, що це таке: Що таке тест на дим і розум?

# 8) Після успішного проходження тестів TRR, Smoke and Sanity цикл випробувань офіційно розпочинається.

# 9) Пошукове тестування буде виконано, як тільки збірка буде готова до тестування. Мета цього тесту - переконатися, що критичні дефекти усунені до початку наступних рівнів тестування. Це дослідне тестування проводиться в додатку без будь-яких сценаріїв тестування та документації. Це також допомагає ознайомитись з AUT.

# 10) Як і інші фази STLC, робота також розділена між членами команди на етапі тестового виконання. Розподіл може базуватися на мудрому модулі чи підрахунку тестових випадків або на чомусь іншому, що може мати сенс.

# одинадцять) Первинний результат етапу виконання тесту - у формі звітів, в першу чергу, тобто звіту про дефекти та звіту про стан тесту. Детальний процес складання звітності можна знайти за адресою Звіти про виконання тестів.

Нові стовпці в тестових справах Документ

Документ «Тестовий випадок» тепер можна розширити за допомогою наступних двох стовпців - Статус та фактичний результат .

( Примітка : Для тестового виконання тестового проекту ми додали та оновили ці стовпці з результатами виконання тесту в таблиці тестових випадків, наданій для завантаження нижче)

№1) Стовпець стану

Виконання тесту - це не що інше, як використання кроків тесту на AUT, надання тестових даних (як визначено в документі тестового випадку) та спостереження за поведінкою AUT, щоб перевірити, чи задовольняє він очікуваний результат чи ні.

Якщо очікуваний результат не буде досягнутий, це можна трактувати як дефект. І статус тестового випадку стає “Fail”, а якщо очікуваний результат досягнуто, статус “Pass”. Якщо тестовий випадок не може бути виконаний з будь-яких причин (наявний дефект або середовище, яке не підтримується), статус буде 'Заблоковано'.

Статус тестового випадку, який ще не запущено, можна встановити на Не запущено / не виконано або залишити порожнім.

  • Для тестового випадку з декількома кроками, якщо певний крок (посередині етапів тестового випадку) очікуваний результат не буде досягнутий, статус тестового випадку можна встановити на “Fail” прямо там, і наступні кроки виконувати не потрібно.
  • Статус 'Не вдалося' може бути позначений червоним кольором, якщо ви хочете негайно звернути на це увагу.

# 2) Стовпець фактичного результату

Це простір, де ми, тестери, можемо записати, яке відхилення очікуваного результату. Коли досягнуто очікуваного результату (або тестового випадку, статус якого - «Прохід»), це поле можна залишити порожнім. Оскільки, якщо очікуваний результат досягнуто, це означає фактичний результат = очікуваний результат, а це означає, що перезапис його у стовпець фактичного результату буде повторенням та надмірністю.

Знімок екрану відхилення можна додати до цього стовпця для більшої ясності суті проблеми.

Результати тестування для проекту OrangeHRM Live

Давайте зараз отримаємо OrangeHRM і проведемо тестування, виходячи з перелічених вище вказівок.

Ось кілька моментів, на які слід звернути увагу:

  • Шаблон розширеного тесту.
  • Дослідницькі випробування, як зазначено, слід проводити без сценаріїв випробувань. Тож, будь ласка, сміливо тестуйте програму паралельно, як вважаєте за потрібне.
  • Через обмеження, які ми маємо, представляючи проект у реальному часі у формі читабельного вмісту, у зразку шаблону Test Execution відображається лише обмежена кількість тестових кейсів / функціональності програми OrangeHRM. Знову ж таки, будь ласка, попрацюйте над іншим для максимально практичного досвіду.
  • Також до документа додаються набори тестів Sanity and Smoke, які дають вам уявлення про те, які тестові кейси розглядаються на цих етапах.
  • Дефекти ще не реєструються, навіть якщо статус деяких тестових випадків встановлений як 'Fail'. Це пов’язано з тим, що реєстрація дефектів - це наступний найважливіший / загально опрацьований аспект нашого життя в якості тестувальників. Отже, ми хочемо детально з цим розібратися в наступній статті.

Тестові випадки з результатами виконання:

=> Клацніть тут, щоб завантажити документ про тестування.

Це містить - Результат виконання тестових кейсів, тести на дим, тести на розум, дослідницькі тести - електронні таблиці

Нарешті, якщо інструмент керування тестом був використаний для створення та ведення тесту, той самий може бути використаний і для виконання тесту. Використання інструменту полегшує звітування, але в іншому випадку процес запуску тестових випадків однаковий. Будь ласка, ознайомтеся з цією статтею, щоб отримати уявлення про як використовувати HP ALM для виконання тестового випадку .

(Клацніть на зображення для збільшення)

ALM для результату тестування

Це підводить нас до кінця ще одного цікавого сегменту процесу тестування. У наступній і останній статті цього безкоштовний онлайн-курс з тестування програмного забезпечення з питань контролю якості , ми детально розглянемо дефекти; підсумуйте такі теми, як «коли припиняти тестування», показники та підпис QA.

=> День підготовки до якості 6: Відстеження помилок, тестові показники та тестовий вихід

Будь ласка, повідомте нам, як у нас справи, і слідкуйте за наступною статтею.

запитання та відповіді співбесіди бізнес-аналітика

Рекомендована література

^