automated regression testing
Цей підручник пояснює проблеми автоматизованого тестування регресії. Ми також дізнаємося про процес та кроки для автоматизації тестування регресії:
Ми дізнаємося, як автоматизувати випадки регресійних тестів, починаючи з їх ідентифікації, вибору інструменту для автоматизації, аналізу витрат, часу та зусиль, написання сценаріїв і, нарешті, передачі його команді ручних тестів, щоб вони могли виконати тестові кейси з будь-якого місця в будь-який час.
Якщо вам цікаво, чому тільки набір тестів на регресію, це тому, що набір тестів на регресію є головним кандидатом для автоматизації, оскільки це сукупність тестових випадків, які повторюються і займають багато часу. Таким чином, автоматизація їх дійсно заощадить багато ресурсів, і це також буде менш трудомістким.
Ви отримаєте швидкі звіти про випадки регресійних тестів, і ви можете використовувати ці кроки для автоматизації будь-яких інших тестових наборів.
=> Клацніть тут, щоб отримати повну серію випробувань на регресію.
Що ви дізнаєтесь:
- Автоматизоване тестування регресії
- Автоматизоване тестування: виклики у гнучкому середовищі
- Кроки для автоматизації тестування регресії
- Висновок
Автоматизоване тестування регресії
Нещодавно, коли я хотів розпочати свій новий проект автоматизованого тестування з чотирьох ресурсів, я подумав застосувати будь-яку з методологій Agile. Але я не зміг продовжити, оскільки в моїй свідомості була порушена низка питань.
Запитання були такими:
- Чи можна застосовувати гнучкі методології в автоматизованому тестуванні?
- Чи можу я використовувати традиційні інструменти?
- Чи слід мені шукати інструменти з відкритим кодом?
- З якими проблемами мені доводиться стикатися, якщо я впроваджую автоматизацію в Agile Environment?
У цій статті давайте проаналізуємо деякі виклики, з якими стикаємось при впровадженні методів автоматизації за допомогою Agile. Автоматизоване тестування регресії в середовищі Agile є ризиком стати хаотичним, неструктурованим і неконтрольованим.
Agile Projects представляють власні завдання команді автоматизації. Методологія Agile робить акцент на співпраці команд та частій доставці товару. Такі фактори, як незрозумілий обсяг проекту, багаторазові ітерації, мінімальна документація, ранні та часті потреби в автоматизації та активне залучення зацікавлених сторін тощо, вимагають від команди автоматизації багатьох проблем.
Автоматизоване тестування: виклики у гнучкому середовищі
Перед командою автоматизації є кілька складних завдань. Однак a деякі з них коротко подані нижче.
Завдання 1:Фаза вимог
Розробник Test Automation фіксує вимоги у вигляді 'історій користувачів', що являють собою короткі описи функціональних можливостей, що стосуються замовника.
Кожна вимога має бути пріоритетною таким чином:
Високий: Це критично важливі вимоги, які необхідно виконати в першому випуску
Середній: Це вимоги, які є важливими, але їх можна опрацювати до впровадження.
Низький: Це вимоги, які приємно мати, але не мають вирішального значення для роботи програмного забезпечення.
Після встановлення пріоритетів планується випуск “ітерацій”. Зазвичай кожна ітерація випуску Agile займає від 1 до 3 місяців. Клієнти / користувачі програмного забезпечення беруть на себе свободу вносити занадто багато змін до вимог. Іноді ці зміни настільки нестабільні, що ітерації стикаються. Ці зміни є більшими проблемами при впровадженні процесу тестування Agile Automation.
безкоштовні провайдери електронної пошти в США -
Завдання 2:Вибір правильних інструментів
Традиційні, останні тестові інструменти з функціями запису та відтворення змушують команди чекати, поки закінчиться програмне забезпечення. Більше того, традиційні засоби автоматизації тестів не працюють у контексті Agile, оскільки вони вирішують традиційні проблеми, які відрізняються від проблем, з якими стикаються команди Agile Automation.
Автоматизація на ранніх стадіях гнучкого проекту, як правило, дуже жорстка, але в міру зростання та розвитку системи деякі аспекти врегульовуються, і стає доречним застосовувати автоматизацію. Тож вибір засобів тестування стає критично важливим для отримання переваг ефективності та якості від Agile.
Завдання 3:Етап розробки сценарію
Тестери автоматизації, розробники, бізнес-аналітики та зацікавлені сторони проекту беруть участь у початкових зустрічах, на яких для наступного спринту обираються 'Історії користувачів'. Коли для спринту вибрано “Історії користувачів”, вони використовуються як основа для набору тестів.
Оскільки функціональність зростає з кожною ітерацією, необхідно проводити тестування регресії, щоб переконатися, що впровадження нової функціональності в кожному циклі ітерацій не вплине на існуючу функціональність. шкала регресійного тестування зростає з кожним спринтом і гарантує, що це залишається керованим завданням, а тестова група використовує автоматизацію тесту для набору регресії.
Завдання 4:Управління ресурсами
Підхід Agile вимагає поєднання навичок тестування, тобто для визначення незрозумілих сценаріїв та тестових випадків, проведення Тестування вручну поряд з розробниками пишіть автоматизовані тести регресії та виконуйте автоматизовані пакети регресії.
У міру реалізації проекту також будуть потрібні навички спеціалістів для охоплення подальших тестових областей, які можуть включати інтеграцію та тестування продуктивності.
Повинна бути відповідна суміш спеціалістів з доменів, які планують та збирають вимоги. Складною частиною управління ресурсами є виявлення тестових ресурсів із різними навичками та їх розподіл.
Завдання 5:Спілкування
Хороший зв’язок повинен існувати серед Тестування автоматизації команда, розробники, бізнес-аналітики та зацікавлені сторони. Повинна існувати взаємодія між клієнтом та командами доставки. Більша участь клієнта передбачає більше пропозицій або змін від клієнта. І це передбачає більшу пропускну здатність для спілкування.
Ключовою проблемою є те, що процес повинен мати можливість охопити та ефективно впровадити всі зміни, а цілісність даних потрібно зберегти. У традиційному тестуванні розробники та тестувальники схожі на нафту та воду, але в рухливих умовах складним завданням є те, що вони обоє повинні працювати разом для досягнення цілі.
Завдання 6:Щоденна зустріч Scrum
Щоденна зустріч у сутичках є одним із ключових напрямків у Agile Process. Команди збираються протягом 15-хвилинних сеансів стоячи. Яка ефективність цих зустрічей? Наскільки ці зустрічі допомагають розробникам практики автоматизації? тощо, які обговорюються на цій зустрічі.
Завдання 7:Фаза випуску
Метою проекту Agile є якомога швидше доставити базовий робочий продукт, а потім пройти процес постійного вдосконалення. Це означає, що для продукту не існує єдиної фази випуску. Складна частина полягає в інтеграційних випробуваннях та прийнятних випробуваннях продукту.
Кроки для автоматизації тестування регресії
Процес автоматизації регресії можна точно розділити на такі етапи:
Ці 7 кроків детально описані нижче, щоб ви могли легко зрозуміти.
1. Ідентифікація
# 1) Визначте тестові кейси що має бути частиною набору тестів на регресію.
- Щоб розпочати автоматизацію регресійних тестових випадків, найперше, що вам потрібно зробити, це визначити та правильно визначити випадки регресійних тестів з усіма етапами, даними та передумовами.
- Щоб переконатися, що у вас є ефективний набір тестів регресії, не забудьте включити:
- Тестові кейси з повторюваними дефектами.
- Тестові випадки, що охоплюють кінцеві сценарії.
- Тестові кейси, які більш помітні для кінцевих користувачів.
- Тестові приклади граничних значень.
- Гарне поєднання позитивних та негативних тестів.
- Складні тестові кейси.
# два) Визначте засоби автоматизації які найкраще відповідають вашим вимогам та поведінці програми. Як тільки тестові випадки регресії будуть визначені та готові до автоматизації, визначте інструменти, які найкраще відповідають вашим тестовим кейсам.
Найкращий спосіб визначити інструменти - це скласти матрицю з інструментами та вашими вимогами, а потім відстежувати, який інструмент відповідає яким вимогам.
Пропоноване читання => Список найкращих засобів тестування автоматизації
# 3) Визначте Мова програмування що ви хочете використовувати. Оскільки на ринку доступно так багато інструментів, ці інструменти підтримують декілька мов. Таким чином, важливо визначити мову програмування, на якій ви хочете писати свої тести автоматизації.
Приклад :Припустимо, що у нас є проект, де ми хочемо автоматизувати набір тестів регресії для додатків на основі браузера.
Як пояснювалося вище, ми визначимо тестові випадки.
- Припустимо, наш тестовий випадок - 'Переконайтеся, що користувач може успішно увійти, використовуючи дійсне ім’я користувача та пароль'.
Далі ми визначимо засоби автоматизації.
- Тестовий кейс на основі браузера можна автоматизувати за допомогою “ Селен ',' Ранорекс ”,„ TestComplete ”. Давайте визначимось із інструментом «Селен», оскільки він найкраще відповідає вимогам.
Тепер визначимо мову програмування.
- Ми хочемо використовувати “ Java ”Як мову програмування як свою високо підтримувану мову.
2. Аналіз
# 1) Роби Вартість аналіз. Дуже важливо працювати в рамках бюджетних лімітів. Таким чином, після етапу ідентифікації ви матимете уявлення про те, скільки тестових випадків потрібно автоматизувати та які можливі інструменти можна використовувати.
Усі висновки на етапі ідентифікації допоможуть вам скласти приблизний бюджет, а отже, ви можете отримати будь-яке схвалення тощо, якщо потрібно.
# два) Роби ресурс і зусилля аналіз, щоб побачити, чи є у вас ресурси для роботи над цим. Поряд з аналізом витрат, дуже важливо провести аналіз ресурсів та зусиль для кращого розподілу ресурсів та ефективного використання їх часу на проекті.
Оцінюючи ресурси та зусилля, обов’язково враховуйте такі ризики, як, якщо хтось захворіє, або якщо деякі випадки тестів потребують більше ресурсів для виконання тощо.
# 3) Роби Час Аналіз. Потрібен аналіз часу, щоб переконатися, що ви можете завершити проект автоматизації в межах бюджету та термінів. Працюючи над аналізом часу, корисно буде підготувати часову шкалу для моніторингу прогресу під час розробки.
Для кращого часового аналізу проекту:
- Визначте завдання та підзавдання у своїх проектах.
- Розставте пріоритетні завдання та підзавдання.
- Намалюйте діаграму Ганта або схему мережі для кращого зображення часової шкали.
Приклад :Продовжуючи наш приклад, який розглядається на етапі ідентифікації, пояснення цього етапу наведено нижче:
Аналіз витрат:
Припустимо, що приблизна вартість цього проекту складає $ X.
Ресурс та зусилля:
Для цього один тестовий випадок повинен бути автоматизований з кінця в кінець, і нам потрібен один ресурс на повний робочий день протягом приблизно 24 годин, а також нам потрібен ще один ресурс для перегляду роботи. Таким чином, нам потрібні 2 ресурси, і оцінка зусиль становить близько 40 годин.
Аналіз часу:
Для цього намалюємо невелику діаграму Ганта, щоб побачити часову шкалу.
3. Навчання / найм
# 1) Якщо потрібні деякі ресурси навчання , потім сплануйте їх навчання. Іноді у вас можуть бути ресурси для ручного тестування, які зацікавлені в написанні тестових кейсів для автоматизації, або деякі люди працювали над автоматизацією, але різні інструменти і готові вивчити інструмент, який ви вибрали для своєї автоматизації.
У цьому випадку визначте ці ресурси та сплануйте їх навчання, щоб вони могли розпочати роботу над автоматизацією регресійних тестів.
# два) Якщо нам потрібно більше ресурсів, тоді попрацюйте над найму плану. Коли ви зробите аналіз ресурсів для своїх зусиль і якщо ви не зможете задовольнити потреби вже наявними ресурсами, тоді плануйте найняти нові ресурси з належними навичками, які необхідні для проекту в рамках бюджету.
Приклад:
Скажімо, ми вже маємо ресурс, який знайомий з поняттями Java і хоче вивчити селен. Тоді ми домовимось про тренування селену для цієї людини.
Якщо у нас немає ресурсів для автоматизації. Тоді ми наймемо людину, яка має певний досвід в автоматизації таких тестових випадків за допомогою селену та Java.
4. Основи та керівні принципи
# 1) Коли інструмент і ресурси будуть готові, працюйте над розробкою рамки або прийняття рішення щодо того, який із них використовувати з існуючих фреймворків. Можна використовувати декілька вже побудованих фреймворків або створити фреймворк з нуля.
Вибираючи або будуючи фреймворк, переконайтеся, що ви залучаєте компоненти про, тестові кейси, журнали, звіти, введення, підключення до бази даних тощо.
# два) Вирішіть з іншого допоміжні інструменти що ви хочете використовувати. Оскільки розробка сценарію автоматизації є завданням розробки, яке передбачає написання коду, було б набагато краще з'ясувати інші інструменти розробки, які були б потрібні для підтримки написання ваших сценаріїв.
Наприклад , Деякі інструменти, які можуть допомогти, включають git, GitHub, Jenkins тощо.
# 3) Окресліть настанови для написання сценаріїв автоматизації. Необхідно окреслити настанови, щоб усі ресурси, що працюють над проектом, синхронізувались і використовували однакові конвенції щодо іменування, однакові процедури реєстрації / виїзду коду та однакову мову програмування.
бінарний клас дерева c ++
Приклад:
Основи: Давайте вирішимо BDD (побудована поведінкою розробка) структура для тестування автоматизації.
Допоміжні засоби: Інструментами, які нам потрібні для повної підтримки автоматизації, будуть GitHub, Jenkins, Log4J, Cucumber та JUnit.
5. Сценарії автоматизації
Почніть писати сценарії автоматизації. Отримавши все, тобто інструмент, мову програмування, необхідні навички та тестові кейси, які потрібно автоматизувати, ми можемо почати писати сценарії автоматизації.
Під час написання сценаріїв ми повинні переконатися, що:
- Настанови дотримуються.
- Ми використовуємо інструменти.
- Тестові кейси модулюються.
- Ми повинні мати можливість повторно використовувати компоненти, якщо вони потрібні в багатьох тестових випадках.
Ми також повинні переконатися, що код належним чином підтримується в інструменті контролю версій, і всі члени команди можуть легко співпрацювати.
Приклад:
Давайте напишемо фактичні сценарії, щоб запустити цей тест. Зразок із сценаріїв можна показати, як показано нижче.
По-перше, сценарій огірка для цього тесту буде виглядати нижче:
Характеристика: Перевірка функціональності входу
Як користувач я хочу увійти до програми
Сценарій: Підключення до програми
Враховуючи, що я відкрив заявку
Коли я вводжу ім’я користувача “”
І я вводжу пароль “”
І я натискаю на кнопку Увійти
Потім я переходжу на домашню сторінку
Приклади:
| ім'я користувача | пароль |
| testuser1 | пароль1 |
| testuser2 | пароль2 |
Після файлу функції ми реалізуємо визначення кроку для кроків, зазначених у файлі функцій.
public class Login { LoginImpl loginImpl = new LoginImpl(); @Given('^I open application$') public void i_open_application() { loginImpl.openURL('URL'); } @When('^I Enter username '((^')*)'$') public void i_Enter_username(String arg1) { loginImpl.enterUserName(arg1); } @When('^I Enter password '((^')*)'$') public void i_Enter_password(String arg1) { loginImpl.enterPassword(arg1); } @When('^I click on Login button$') public void i_click_on_Login_button() { loginImpl.clickLoginButton(); } @Then('^I go to Home page$') public void i_go_to_Home_page() { loginImpl.verifyHomePage(); } }
Зрештою, фактична реалізація класу функціональності входу виглядатиме так:
public class LoginImpl { WebDriver driver; public LoginImpl(){ System.setProperty('webdriver.chrome.driver', 'webdriver/chromedriver.exe'); driver = new ChromeDriver(); } public void openURL(String string) { driver.get(string); } public void enterUserName(String arg1) { driver.findElement(By.id('UserName')).sendKeys(arg1); } public void enterPassword(String arg1) { driver.findElement(By.id('Password')).sendKeys(arg1); } public void clickLoginButton() { driver.findElement(By.id('LoginButton')).click(); } public void verifyHomePage() { String currUrl = driver.getCurrentUrl(); if(currUrl.equals('homePageURL')) { System.out.println('Home page verified'); } } }
6. Огляд
(зображення джерело )
# 1) Огляд коду: Коли розробник автоматизації закінчує писати сценарії автоматизації, дуже важливо пройти різні рівні перегляду коду.
Код огляди допомогти в
- Виявлення помилкових перевірок.
- Пошук точок оптимізації коду.
- Пошук кращих способів реалізації функціоналу для ефективного використання ресурсів.
Огляди коду також виставляють роботу розробника іншим розробникам і надають йому іншу перспективу та можливість для вдосконалення.
# 2) Огляд тестових випадків: Поряд із переглядом коду дуже важливим є також огляд тестового випадку. Нам потрібно переконатись, що сценарії тесту автоматизації при виконанні виконують той самий набір дій та перевірок, що ми очікуємо від ручних тестових випадків.
Таким чином, розгляд тестових випадків автоматизації з бізнес-аналітиками або експертами тестування допомагає підвищити впевненість у автоматизованому тестуванні цих тестових випадків.
Приклад:
Для нашого прикладу, який ми розглядаємо, скажімо, для перегляду коду ми отримали коментарі на зразок «шукати елемент за ідентифікатором, а не за іменем». Тут ми врахуємо це та відповідно змінимо наш сценарій.
Крім того, можна зробити тестовий огляд, щоб додати кроки для тестування, якщо ви перебуваєте на домашній сторінці після успішного входу. Потім ми також додамо це до наших сценаріїв.
7. Доставити
Доставити тестові кейси, щоб кожен міг запускати їх у будь-який час. Після того, як сценарії автоматизації готові до використання, дуже важливо скласти план постачання сценаріїв автоматизації.
Цей план необхідний, оскільки ми хочемо переконатись, що автоматизація тестових випадків не обмежує його виконання певним набором людей або навичок. Кожному члену команди або проекту слід дозволити виконувати тестові справи.
Одним із можливих планів доставки є надання роботи Дженкінса, яка може бути ініційована для виконання автоматизованих тестових випадків.
Приклад:
У нашому випадку припустимо, що ми провели тестовий випадок, використовуючи завдання Дженкінса. Ця робота Дженкінса бере код від GitHub, створює його та запускає тести на іншій машині.
Після успішного виконання завдання відображається згенерований звіт про тестування. Кожен, хто має доступ до Дженкінса, може керувати цією роботою. Крім того, цю роботу можна запланувати на певний час.
Висновок
Якщо ми можемо впоратися з цими проблемами добре оптимізовано, то автоматичне тестування регресії в середовищі Agile - це чудова можливість для контролю якості взяти на себе керівництво спритними процесами. Краще подолати розрив між користувачами та розробниками, зрозуміти, що потрібно, як цього можна досягти та як це можна забезпечити до розгортання.
Практика автоматизації повинна бути зацікавлена як в результаті, так і в тому, щоб продовжувати гарантувати, що вся система, що розвивається, відповідає бізнес-цілям і відповідає цілі.
Автоматизація регресійного тесту завжди корисна, оскільки є найкращим кандидатом для початку тестування автоматизації . Ви можете виконати згадані вище кроки для автоматизації будь-якого набору тестів, а не лише регресії.
Тестування автоматизації теж дуже корисне та економічно вигідне, а час на тестування автоматизації витрачається лише на написання сценаріїв та їх обслуговування. Отже, тестування автоматизації має бути належним чином спланованим і запланованим для успішного проекту.
Про автора: Дж. Б. Райкумар має понад 15 років досвіду як в академічній, так і в тестувальній роботі з програмним забезпеченням. Він працював корпоративним тренером, керівником випробувань, менеджером з контролю якості та менеджером з контролю якості.
Повідомте нам свої коментарі / пропозиції щодо цієї статті.
=> Завітайте сюди, щоб отримати повну серію випробувань на регресію.
Рекомендована література
- Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
- Завантажити тестувальник електронної книги
- 4 кроки до розробки гнучкого мислення для тестування для успішного переходу до гнучкого процесу
- Проблеми, пов'язані з ручним та автоматичним тестуванням
- Різниця між тестуванням та тестуванням на регресію на прикладі
- 5 Виклики та рішення для мобільного тестування
- Тестування SaaS: виклики, інструменти та підхід до тестування
- 10 найпопулярніших засобів тестування регресії в 2021 році