19.08.2016, 15:37:31
Войти Зарегистрироваться
Авторизация на сайте

Ваш логин:

Ваш пароль:

Забыли пароль?

Навигация
Новости
Поход в Холодный Яр

Если вы ищете, чем заняться в выходные, любите походы и природу Украины, то вероятно вам понравится поход. Поход в Холодный Яр, если точнее. Холодный

Увлекательный тур пешком по Карпатам

Украина самая большая страна Европы с неплохой инфраструктурой и разнообразием ландшафта. Здесь действительно есть, что посмотреть, от памятников славянской старины до изумительных природных красот.

Бизнес план кредитного потребительского
Финансовый рынок нашей страны довольно развит, что в общем-то характерно для государств всего мира с развитыми или развивающимися экономики. Но потребности в финансовых услугах все равно, в значительной

Бизнес онлайн от сбербанка
Услуга Сбербанк бизнес онлайн от Сбербанка России – это новая, уникальная и, несомненно удобная возможность для предпринимателей и юридических лиц управлять своими счетами в банке, а также проводить необходимые

Кредит круглосуточно
Кредит является довольно популярным экономическим термином, который употребляют в своей речи люди разного возраста, пола, вероисповедания, социального положения и так далее. Слово это имеет разные значения,

Перевод диплома
Приветствую всех читателей моего блога. Как и обещал, начинаю вновь публиковать интересные и актуальные статьи о сфере ЖКХ. Наиболее актуальная тема последних дней – это уборка снега на дворовой

Фильмы в качестве 2020
Пока страна ждёт фильм «Купала» – амбициозный проект Национальной киностудии о судьбе народного поэта, – мы встретились с его автором Владимиром Янковским. Режиссёр и актёр из знаменитой

Тамада или ведущий на свадьбу
Не стоит, наверно, говорить, что все празднования и свадьбы без тамады просто не могут существовать о приоре. И ведущий на корпоратив тоже обязателен. Кто с этим не согласен, то пусть побывает хоть на

Домашний интернет
Современный человек, априори, не может прожить без интернета. Это и работа и учеба и развлечение и общение. Хотя подключить интернет сегодня и не проблема, но качество подключения, как и дальнейшее предоставление

Система dwh
Неуклонный рост производительности производственных и управленческих процессов напрямую связан с широким внедрением информационных технологий. Существенную роль в данном процессе играет система dwh, внедрение

Архив новостей
Реклама
Календарь событий
Right Left

Як зрозуміти, що пора автоматизувати тестування

  1. Як ми зрозуміли, що потрібно автоматизувати
  2. План дій по автоматизації
  3. що автоматизувати
  4. повна автоматизація
  5. чим автоматизувати
  6. Разом

Як зрозуміти, що автоматизація тестування принесе користь?
Як зрозуміти, що автоматизувати, а що ні?
Як безболісно для проекту почати автоматизацію?

Якщо ви хоч раз замислювалися над цими питаннями, наша стаття допоможе в них розібратися.

    цілі автоматизації
  • Підвищити ефективність тестування. Регулярні Автотест звільняють час фахівців для дослідження нового функціоналу замість контролю якості вже готового (особливо регресійного тестування). Можна налаштувати запуск Автотест у нічний та неробочий час. Це скоротить час на тестування і забезпечить точність результатів, адже машини не допускають помилок;
  • Скоротити терміни тестування. Скорочується процес «знаходження бага - реєстрація - виправлення - перевірка». У «ручному» режимі он займає близько дня, в автоматизованому - 2 хвилини. Наприклад, якщо під час smoke-тестування після збірки додатку в CI будь-якої з тестів «впав», збірка буде позначена як дефектна і логи тестів спрямовані відповідальним за виправлення розробникам;
  • Прозорість процесу тестування. Всім учасникам команди доступна повна і регулярна звітність про дефекти. Звіти формуються автоматично і містять всю інформацію про пройдені і непройденого кроках;
  • Зменшення витрат на тестування. Одного разу спроектовані і написані Автотест потребують мінімальному супроводі - в разі зміни функціоналу та / або інтерфейсу в нових версіях. На коригування скриптів піде від 10 хвилин до декількох годин в залежності від кількості змін в продукті.

  • Як зрозуміти, що автоматизація тестування принесе користь
      Коли впровадження автоматизації принесе користь:
  • Величина проекту. Проекту більше року, він складається з безлічі підсистем. Кількість тестів, які потрібно проганяти, зростає. Ми почали автоматизувати тестування системи управління ресурсами, коли «ручних» тест-кейсів накопичилося 600, і на їх перевірку однією людиною йшла тиждень. Фахівці повинні тестувати, а не проходити тест-кейси;
  • Велика команда. У команді більше двох розробників. Розробник повинен бути впевнений, що його зміни не зламають чужий код. Без авто-тестів він дізнається про це в кращому випадку через день-два, в гіршому - від користувачів;
  • Підтримка старих версій. Ви підтримуєте кілька версій продукту і випускаєте патчі і сервіс-паки під кожну з них. Тестування на різних конфігураціях - це рутина, яку можна автоматизувати;
  • Генерація тестових даних забирає багато часу. Ви розробляєте сервіс для обробки і трансформації всіляких даних: системи заявок, обліку профілів і т.д. Займатися ручним вбивання в систему даних і візуальним аналізом результатів або відправкою запитів і аналізом відповідей - невиправдана трата ресурсів. Часті релізи. У вас Agile з короткими ітераціями і частими релізами. Витрачати тиждень на тестування в рамках спринту - занадто довго, коли можна витратити 1 день.

  • Якщо хоча б 1 ознака відноситься до вашого проекту, автоматизація принесе поліпшення: тестові дані будуть генеруватися автоматично, часті регреси не забиратимуть час, а проміжок між виявленням дефекту і його виправленням скоротиться.
    Якщо поки ваш проект не такий, почекайте, поки розростеться функціонал або команда. Не варто робити Автотест заради Автотест.

    Як ми зрозуміли, що потрібно автоматизувати

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


    Передумови для автоматизації:
    Продукту 3 роки;
    У команді 5 розробників;
    Релізи зазвичай раз в 3 тижні;
    Багато генерації тестових даних
    Разом: 4 ознаки з 5. До автоматизації на перевірку всіх тест-кейсів йшло 4 дня.


    Рішення
    Ми вирішили частково автоматизувати систему, але покрити Автотест не всі 900 тест-кейсів, а тільки зачіпають функціонал, який не змінюється в кожному спринті: авторизація, відновлення пароля, дії з користувачами, нотифікації, створення подій. В результаті написали smoke-Автотест для всіх модулів, які прогоняются в безперервної інтеграції (CI) при кожній збірці. Ми могли б витратити більше часу і автоматизувати інші кейси, але це було б недоцільно: проект розвивається, бізнес-логіка і інтерфейс змінюються занадто часто, щоб писати Автотест. Їх довелося б переписувати в кожному спринті.


    результат

    В результаті smoke-Автотест запускаються в CI при кожній збірці і сигналізують розробникам про дефекти в реальному часі. Так розробники відразу починають виправляти їх, не перемикаючись на інші завдання, а у QA з'явилося більше часу на ретельне тестування тільки що реалізованого функціоналу замість повторних роботи старого.


    Протилежна ситуація склалася на іншому проекті - додатку для створення оцінок і аналітики.


    передумови автоматизації
    Автоматизувати вирішили в якості експерименту. Це молодий проект, в ньому поки не так багато функціоналу - всього 61 тест-кейс.


    Рішення
    Проект примітний тим, що на ньому немає жодного ручного тестувальника. Дослідницьке ручне тестування робить Автоматор на етапі написання і налагодження скрипта автотеста, який потім просто проганяється в CI, замінюючи тим самим ручна праця.


    результат

    На липень 2017 року автоматизовано 46 тест-кейсів на бекенда і 14 на фронтенд, покриття кейсів Автотест близько 96% На липень 2017 року автоматизовано 46 тест-кейсів на бекенда і 14 на фронтенд, покриття кейсів Автотест близько 96%.
    Цей проект - наочний приклад того, що буде, якщо почати автоматизувати з самого старту робіт: часові витрати на тестування за весь час життя проекту менше, ніж якби спочатку ми тестували вручну, а потім запровадили автоматизацію.

    План дій по автоматизації

    Отже, ви переконалися, що автоматизація тестування принесе користь. Що далі? Розробляємо план дій:

    • що автоматизувати;
    • як автоматизувати;
    • ніж автоматизувати.

    що автоматизувати

    1. Важкодоступні місця в системі: бекенд процеси, логирование файлів, запис в бази даних;
    2. Часто використовуваний функціонал, де високі ризики помилок: системи оплати, реєстрації і т.д. Автоматизація перевірки критичної функціональності гарантує швидке знаходження помилок - 1 тест в середньому йде 2 хвилини. Швидше знайдемо - швидше виправимо;
    3. Рутинні операції: перебори даних, форми з великою кількістю введених полів. Автоматизувати заповнення полів даними і їх перевірку після збереження;
    4. Валідаційні повідомлення: автоматизувати заповнення полів некоректними даними та перевірку на появу валідації;
    5. Довгі end-to-end сценарії. Наприклад, сценарій для ріелторської CRM: реєстрація користувача - заклад заявки від його імені - створення завдання - взяття в роботу - призначення завдань на фахівців - отримання завдань назад в роботу-реєстрація результату;
    6. Перевірку даних, що вимагають точних математичних розрахунків: бухгалтерське або аналітичне ПО;
    7. Перевірку правильності пошуку даних.

    як автоматизувати

    Не всі тест-кейси потрібно автоматизувати в першу чергу. Наприклад, якщо у вас 300 тест-кейсів для перевірки модулів, 100 для компонентів, 20 для підсистем і всього 5 призначених для користувача сценаріїв (див. Рис.2), починати автоматизацію краще з тестів, які перевіряють окремі функції, тобто з unit-тестів. Вони виконуються швидко, але їх більше. Коли ці кейси вже покриті Автотест, можна приступати до автоматизації тест-кейсів з перевірки компонентів, далі - підсистем і т.д.

    повна автоматизація


    Передумови для автоматизації
    Приклад повної автоматизації - надбудова над Jira для планування і управління проектами. На проекті порядку 600 тест-кейсів, все покриті Автотест. У разі змін логіки або інтерфейсу, доводиться правити близько 100 скриптів. Це все одно займає менше часу, ніж ручне тестування.


    Рішення
    На етапі планування автоматизації для визначення кількості автоматизованих тест-кейсів для кожного рівня архітектури ми взяли пропорції з піраміди тестування (рис.). В результаті у нас вийшло більше 300 unit-тестів, 200+ на інтеграцію і API і 38 GUI-тестів, які повторюють сценарії використання продукту кінцевим користувачем.


    результат

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

    Звідси запитання: навіщо нам така різноманітність складних і довгих тестів з одними сценаріями, якщо можна написати багато невеликих, швидких і легких в підтримці unit-тестів?

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


    Загальна рекомендація тут одна: мати всі види Автотест в пропорціях згідно піраміді на кожному з рівнів архітектури системи. Тоді з'являється можливість отримувати ефективну віддачу від таких тестів. Функціональні тести, які тестувальники проводили протягом спринту: негативні, позитивні, комбінаторні і т.п., потрібно поміщати на рівень API-тестів. Так створюється швидкий і стабільний пакет регресійних тестів.
    На рівень UI-тестів виносяться приймальні випробування або призначені для користувача сценарії веб та мобільних додатків.
    Слідуючи рекомендаціям піраміди, ми отримуємо гарантовано перевірений функціонал і при цьому економимо час команди. Порівняйте: регулярні витрати на багатоденне регресійне тестування 3-4 фахівцями з ручного тестування і 2-3 тижні розробки Автотест одним фахівцем і пара годин на їх підтримку.

    чим автоматизувати


    Вибір інструмента залежить від специфіки програми та вимог до тестових сценаріїв. Найчастіше вибирається кілька інструментів - окремо для кожного рівня архітектури системи. Наприклад, GUI тестується за допомогою Selenium, API з java + restAssured, а навантаження з jMeter.

    На що звернути увагу при виборі

    1. Ми не розглядаємо бета-версії і нестабільні збірки інструментів. Це економить час на вирішення проблем, пов'язаних з дефектами самого інструменту. Наприклад, проблеми з кодуванням в RF HTTPLibrary ;
    2. Бажано, щоб документація інструменту була російською мовою (як, наприклад, для Selenium );
    3. Спеціалізовані форуми по конкретному інструменту допомагають швидше отримати відповіді на питання використання. Наприклад, якщо використовуєте зв'язку java TestNG + Selenium , В інтернеті можна знайти відповідь будь-яке питання. А ось якщо візьметеся за Python based Robot Framework - документація буде тільки англійською і без опису особливостей використання кейвордов, в пошуках яких доводиться аналізувати код бібліотек;
    4. Звертаємо увагу на можливість інтеграції інструментів тестування з програмним забезпеченням, яке використовується в компанії;
    5. Вартість інструментів тестування: якщо плануєте одноразове тестування, купувати дорогі інструменти недоцільно.

    Що для чого підходить
    Для автоматизації функціонального тестування важливі підтримка конкретної мови програмування, можливість побудови звітів про тестування для автоматичної реєстрації виявлених дефектів при регулярному прогоні тестів в CI.

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


    приклади:
    jMeter , Яндекс.Танк , Siege , HP LoadRunner .


    Ми вважаємо за краще працювати з популярними і надійними засобами тестування: Selenium Webdriver, Java TestNG, jUnit, RestAssured, Allure, jMeter, хоча у нас є досвід використання та інших інструментів (наприклад, Robot Framework).
    Практично кожне завдання в межах одного виду тестування можна вирішити за допомогою будь-якого інструменту, проте трудомісткість і вартість рішення будуть відрізнятися. Наприклад, якщо у інструменту немає коштів аналізу результатів і побудови звітів (як у випадку використання, припустимо, testNg + Selenium без Allure), то час на аналіз результатів автоматизованого тестування буде приблизно таким же, як при ручному тестуванні. Вигоди ніякої. Впровадження автоматизації тестування пройде легко і швидко, тільки якщо на самому початку правильно підібрати інструмент під змогу оцінити потреби. Одне лише це вже може стати ключем до успіху.

    Разом

    Чи не на всіх проектах дійсно потрібна повноцінна автоматизація. Іноді, щоб прискорити роботу команди, досить допоміжних скриптів.


    Якщо ви планує розвивати продукт роками великою командою, без автоматизації не обійтися. У нашій практиці були випадки, коли ми впроваджували автоматизацію після 3-4 років роботи над продуктом. І результат був видний і команді, і кінцевим користувачам. У таких випадках автоматизація починається поступово, поки команда звикає до нових інструментів і процесу роботи. Зверніть увагу на інструменти - важливо вибрати ті, які підходять до вже застосовуваних інструментів і бібліотекам.


    Автоматизоване тестування покликане допомогти команді робити ті ж завдання швидше і оперативніше випускати нові релізи продукту. Якщо зазвичай на тестування йде 3-4 дні, з автоматизацією цей час скоротитися до декількох годин. Це особливо актуально для великих і постійно розвиваються IT-продуктів.

    Як зрозуміти, що автоматизувати, а що ні?
    Як безболісно для проекту почати автоматизацію?
    Що далі?
    Звідси запитання: навіщо нам така різноманітність складних і довгих тестів з одними сценаріями, якщо можна написати багато невеликих, швидких і легких в підтримці unit-тестів?