how translate manual test cases into automation scripts
Це буде основною статтею 'як до цього' і не стосується жодного інструменту автоматизації. В основному те, що я намагаюся зробити тут, полягає в тому, щоб передумати процес мислення, який входить у створення тестового кейсу автоматизації, словами. Як завжди, я сподіваюся, це буде корисним для всіх вас.
Як розробити тест або сценарій автоматизації?
Автоматизація завжди слідує ручному тестуванню. Як правило, один або кілька раундів ручного тестування вже виконуються на AUT. Це означає, що випадки ручного тестування вже існують і виконувались принаймні один раз.
Наприклад, припустимо, що наступним є ваш Ручний тест . Це просто вхід на сайт Gmail.com. Тепер це виглядає досить просто, чи не так? Як це стає сценарієм автоматизації? (натисніть на зображення, щоб збільшити)
Що ви дізнаєтесь:
Запитання для співбесіди для oracle pl sql за 5 років досвіду
Як перевести цей тестовий посібник у сценарій автоматизації?
Нижче наведено вказівки, якими ми збираємось слідувати для перекладу на сценарій автоматизації:
# 1) Стан AUT: Передумовою стовпця є не що інше, як певний стан фону, який слід встановити для певного кроку, який потрібно виконати. Це особливо важливо у двох сценаріях:
- Щоб розпочати тест: У цьому випадку нам потрібен доступний та запущений браузер. (Доступність імені користувача та пароля буде вирішено через деякий час). Тепер, як написати те саме в світі автоматизації? Розглянемо QTP. У вас є можливість або запустити браузер за допомогою програмних операторів, або ви можете скористатися діалоговим вікном «запис і запуск» для встановлення властивостей. Правильно встановити ці властивості дуже важливо. Часто це причина, чому певний фрагмент коду буде працювати в машині, а не працюватиме в інших.
- Для виконання певного кроку : Для виконання кроку 2 нам потрібно виконати та завершити крок 1. Щоб зробити це вручну, ми можемо просто почекати, поки виконається крок і сторінка завантажиться повністю. Використовуйте синхронізацію або чекайте на оператори у вашому сценарії автоматизації, щоб зачекати, поки бажаний стан збудеться.
Примітка: Коли ви запускаєте один і той самий код для декількох наборів даних, ви хочете переконатися, що повертаєте AUT до стану, який він повинен бути до початку наступної ітерації.
# 2) Кроки тесту
Ми можемо класифікувати етапи ручного тестування на 3 категорії:
- Введення даних : Кроки введення даних - це місце, де ви вводите деяку інформацію як вхід до свого AUT.
- Зміна кроків стану AUT : саме ці кроки спричинять зміни у вашому AUT. Це може включати перехід на нову сторінку, видимість певного поля, редагування поля редагування тощо.
- Комбінація : як випливає з назви, це поєднання обох вищезазначених типів. Візьмемо випадок із прапорця, коли ввімкнено, певне поле стане активним. У цьому випадку ви вводите значення “True” для поля прапорця, і це також призводить до стану вашого AUT.
У наведеному вище тестуванні існують лише кроки типу 1 і 2.
- Тип 1: кроки тестування 2 і 3
- Тип 2: Крок 1 та 4
Обов’язковою умовою створення сценарію автоматизації за допомогою будь-якого інструменту є витратити певний час на аналіз інструменту, а також AUT. Спробуйте побачити, як вони обоє взаємодіють між собою. Наприклад, QTP має 3 способи запису, і кожен працює по-різному.
Якщо ви знаєте, як він ідентифікує об’єкти, ви б знали, який із них використовувати і використовувати їх краще. Якщо у вас є веб-програма, де QTP може легко ідентифікувати об’єкти, ви можете використовувати звичайний режим. Якщо ні, можливо, вам доведеться використовувати аналогові або низькорівневі методи.
Етапи автоматизації:
- Етапи введення даних не сильно відрізняються між собою методами автоматизації та ручного керування. Все, що ви робите, - це вводити дані. Спосіб посилання на поле відрізняється. Оскільки це буде машина, яка виконує кроки, нам просто потрібно переконатися, що ми посилаємося на поля в AUT так, щоб інструмент зрозумів. Це означає, що ви повинні використовувати його логічне ім'я, як воно використовується в коді.
- Для зміни кроків AUT / Комбінація у ручному сценарії ви виконуєте дію (клацання або перевірка або введення) і перевіряєте зміни за один раз. Але в сценарії автоматизації це неможливо. Тому ми повинні переконатися, що додаємо кроки для дії та перевірки / перевірки.
- Коментарі для читабельності.
- Оператори налагодження - це особливо важливо, коли ви створюєте та тестуєте сам тест. Спробуйте часто використовувати вікна повідомлень для виведення різних значень на різних етапах виконання тесту. Це дасть вам видимість тесту, як ніщо інше.
- Вихідні відомості - до пишіть до результатів або до будь-якого іншого зовнішнього місця, як блокнот або аркуш Excel.
# 3) Перевірка та перевірка
Без перевірки та перевірки намір тестування втрачається. Зазвичай вам доведеться використовувати контрольний пункт (не обов’язково означає вбудований). Отже, вам доведеться використовувати багато умовних операторів, а також циклічні оператори для побудови логіки.
Важливо врахувати - атрибут, на основі якого ви базуєте свій V&V, не повинен бути неоднозначним. Наприклад, для успішного входу шукайте сторінку вхідних повідомлень, а не кількість нових листів, оскільки це не є постійним значенням.
Тож вам доведеться вибирати щось, що відповідає дійсності, щоразу, коли відбувається набір операцій - безвідмовно.
# 4) Дані тесту
Нижче наведено деякі запитання, на які ви можете розглянути відповіді щодо вимог до даних тесту:
- Де його розмістити?
- Твердокодувати чи ні?
- Проблеми безпеки?
- Проблеми багаторазового використання?
Озирнувшись до сценарію ручного тестування, ви помітите, що наявність даних тесту, ім’я користувача та пароль є однією з передумов навіть для початку тесту.
# 5) Результати
У випадку ручного тестування ви можете помістити результат кожного кроку у стовпець 'Фактичний результат'. Файл результатів інструменту автоматизації містить результат кожного кроку при виконанні.
У наш час засоби автоматизації мають дуже надійні функції звітування. Однак, можливо, вам все одно доведеться адаптувати Результати тесту . Тож включіть кроки для частого запису у файл результатів, щоб ви точно знали, що відбувалося під час виконання.
Якщо інструмент, який ви використовуєте, не підтримує запис у файл результатів, який він генерує, непогано мати принаймні аркуш Excel або блокнот, пов’язаний з кожним тестом, щоб містити коментарі про стан виконання під час роботи.
# 6) Поштові операції
який найкращий інструмент для видалення шкідливих програм
Після того, як ви закінчите тестування, не потрібно чітко згадувати у вашому тестовому прикладі вручну, щоб закрити браузер або закрити AUT і т. Д. Як тестер, ви будете робити це старанно. У випадку тестування з автоматизацією ви можете включити ці кроки у свій сценарій. Прибирання - це те, що я називаю цією діяльністю. Вбийте всі створені вами зв’язки. Закрийте всі програми. Звільніть пам’ять.
Використовуючи ці вказівки, я перекладаю наш кейс з ручного тестування на тестовий сценарій QTP, який використовує сценарії VB. Результат такий: (натисніть на зображення, щоб збільшити)
Пройдіть кожен крок
Крок 1: Передумова. Ми запускаємо IE із URL-адресою Gmail.com програмно.
Крок 2 і 7: Заява про синхронізацію. Як ми обговорювали вище, вони важливі, щоб переконатися, що AUT доходить до бажаного стану перед наступним виконанням наступного кроку.
Крок 3 і 4: Введення даних. Всі дані жорстко закодовані в сценарії. Хоча це не доцільно, це початок.
Крок 5: Зміна кроку AUT. Крок 5 включає натискання кнопки Увійти. Вам не буде потрібно V&V, коли ця заява буде виконана. Це тому, що є наступне твердження, і якщо воно може працювати; це означає той, який був раніше успішним. Але якщо ви надмірно старанні, можете включити сюди таку.
Крок 6 і 8: Коментарі
Крок 9 і 11: Умовне висловлювання. V & V / Checkpoint. Ми намагаємося перевірити, чи вдалося ввійти в систему, перевіряючи, чи є на отриманій сторінці посилання на вхідні. Якщо ви уважно відзначаєте, шукайте посилання на внутрішній текст, “inbox. *”. Отже, незалежно від кількості отриманих нових електронних листів (які є змінними), якщо у вас є посилання на вхідні повідомлення (яке завжди є константою), це означає, що контрольний пункт пройшов.
Крок 10: Поле повідомлення. Для наочності
Крок 12 і 13: Це заходи з прибирання. Ви виходите з облікового запису та закриваєте браузер.
Висновок
Отже, ви бачите, як легко розгортається сценарій автоматизації, коли у вас є добре написаний сценарій вручну та набір основних вказівок. Оскільки це не стаття, що стосується рамки , Я залишався осторонь функцій, коефіцієнтів багаторазового використання, параметризації тощо. Тестовий скрипт - основний будівельний блок, легко імпровізувати сценарій, коли у вас є основи.
Чи є якісь інші фактори, які ви враховуєте, інший метод, який вам легший, чи якийсь орієнтир, якого вам важко виконувати? Будь ласка, повідомте мені свій відгук у коментарях.
Цей допис написаний членом команди STH Свати Сіелою. Вона має понад 9 років досвіду роботи з різними MNC з ручного та автоматичного тестування. Вона також є нашим інструктором з Навчальний курс з контролю якості програмного забезпечення . Якщо ви зацікавлені в цьому курсі, перевірте майбутній графік партії тут .
НАЗАД Підручник | НАСТУПНИЙ підручник
Рекомендована література
- 10-етапний процес тестування автоматизації: як розпочати тестування автоматизації у своїй організації
- Навіщо нам потрібні рамки для автоматизації тестів?
- Проблеми, пов'язані з ручним та автоматичним тестуванням
- Чим відрізняється планування тестів для проектів, що проводяться вручну та автоматизації?
- Як вирішити, який тип тестування необхідний для проекту? - Ручна або автоматизація
- Що таке тестування автоматизації (Кінцевий посібник із запуску автоматизації тестування)
- Фреймворки QTP - Фреймворки автоматизованих тестів - Приклади, керовані ключовими словами та лінійні фреймворки - Підручник QTP # 17
- 10 найкращих стратегій автоматизації тестів та найкращі практики