Від льодовикового періоду до Месників за допомогою Appium

Уроки роботи роботів Kite

Дозвольте розпочати тут із нудного гачка: мій особистий досвід тестування програми вручну. Оскільки розробка продукту включає доставку шматочками та шматками, для члена команди QA стає одноманітним виконувати одні й ті ж дії знову і знову. Кожен раз, коли мені довелося щось тестувати, мені потрібен був новий користувач, і тому мені довелося підписувати нового користувача вручну. Це нудніше, ніж це звучить.

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

Команда QA в компанії Kite провела досить багато досліджень і розробок, щоб знайти потрібні інструменти. Ми зважилися на Appium, оскільки він:

  1. Є відкритим кодом
  2. Не потрібен вихідний код
  3. Не потрібно ніяких інструментів
  4. Має легко доступний тон підручного матеріалу

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

У цій публікації я висвітлю недоліки класичного підходу до Appium, і те, як наш робот-підхід у Kite робить Appium порівняно безпроблемним. Ми використовували підхід Robot у першому додатку Kite, Kite Cash. Він був запущений для експериментальних цілей і органічно об'єднався в мережу з понад 100 000 користувачів у більш ніж 1100 містах.

Класичний підхід

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

Маючи на увазі ці обмеження, давайте підходимо до Appium як до історії.

Класичний сценарій

Розглянемо екран входу з ім'ям користувача, екраном пароля та кнопкою входу. Якщо я введіть правильні облікові дані та натисніть "Увійти", я повинен мати можливість увійти та переглянути наступний екран.

Думаючи про тест, ми задаємо наступні запитання: Чого ми хочемо досягти? і як ми цього досягнемо? Наш раніше підхід щільно поєднав цю пару Що і як. Однак якщо ця пара зберігається разом, QA ускладнює підтримку та масштабування сценаріїв. Проблема неминуче полягає в тому, що вимоги бізнесу змінюються, і ми повинні пройти і змінити тест завдяки цій зв'язку. Ось приклад:

Чого потрібно досягти: передача правильного імені користувача / пароля повинна перенести користувача на екран приладової панелі.

  • Введіть ім’я користувача "hulk@spiderman.com"
  • Введіть пароль "HS @ 1235"
  • Натисніть кнопку "Увійти"
  • Перевірте, чи відображається екран інформаційної панелі

Розглянемо код:

Давайте подивимося, які проблеми існують у такому підході:

  1. Існує високий рівень дублювання коду, що ще більше погіршує продуктивність автоматизації.
  2. Код, наведений вище, не читабельний. У швидко зростаючих компаніях, таких як Kite (та багатьох інших), нові члени постійно приєднуються до окремих команд. Новий учасник не зрозуміє цей код та його призначення, якщо вони приєднаються після написання коду.
  3. Нам не буде зручно керувати таким кодом найближчим часом, коли посилюються робочі процеси в додатках.
  4. Будь-які нові вбудовані зміни інтерфейсу важко включити до цього коду, тому що для його повторної роботи потрібно провести багато рефакторингу - у кількох точках.

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

Роботний підхід

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

Шаблон тестування роботів схожий на широко використовувану модель об'єкта сторінки, яка є дизайнерською схемою, призначеною для створення об’єктного сховища елементів інтерфейсу для веб-платформ.

В даний час ми покладаємось на користувача, який вручну виконує дії. Що робити, якщо роботи все це зробили для нас? У підході Robot ми знаємо, що екран дозволяє нам вводити ім’я користувача / пароль, не враховуючи, куди ці значення переходять.

Робочий сценарій

Робот існує в UsernamePasswordScreenBot, який передає значення у полях імені користувача / пароля та натискає "Увійти". Тепер екран змінюється, і цей робот має лише контроль над класом UsernamePasswordScreenBot. Звідси інший бот приймає, скажімо, ResultScreenBot для подальшого виконання дій на наступному екрані.

Іншими словами, створіть робота на екрані, і він виконає необхідні дії.

Сядьте, розслабтеся і дозвольте роботам працювати на вас.

Цей код пояснює, що ми хочемо, тобто мати можливість ввести ім’я користувача та пароль, які повинні увійти користувач.

Порівняння

Порівняємо показники та зміни продуктивності в класичному підході та підході робота:

  1. Дублювання коду зводиться до мінімуму, оскільки ми розміщуємо ідентифікатори елементів в одному класі та використовуємо той самий клас кожного разу.
  2. Читання коду покращилося, оскільки новий член, який приєднується до команди, може зрозуміти, що цей код робить інтуїтивніше.
  3. Керувати таким кодом та пристосовуватися до змін інтерфейсу тепер простіше. Змініть код в одному місці, і ця зміна відображається всюди. Розглянемо приклад: у потоці входу ідентифікатор елемента змінюється або додається нове поле. У класичному підході ми повинні вносити зміни в кожній точці, де ми реєструємо користувача. У підході Robot ми просто додамо або відредагуємо елементи класу UsernamePasswordScreenBot та зателефонуємо прямо звідти.

Область тестування роботів

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

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

Економія часу та нарощування потенціалу

Ми заощадили помітну кількість часу і розширили наші можливості, перейшовши на підхід Robot.

  1. Наш тестовий покрив збільшився порівняно з тестуванням вручну.
  2. Ми скоротили час, необхідний для виконання санітарії, з цілого дня до 5–10 хвилин.
  3. Ми скоротили час створення сценарію на 50% і вирішили проблему масштабованості.
  4. За допомогою сценарію підходу ми можемо створити набір регресії, який робить тестування більш простим та точним.

Висновок

Будучи таким чином, як Kite, я мав можливість випробовувати нові речі та вкладати час у дослідження - саме через це мені вдалося вийти з новим підходом до використання Appium. Я щодня стикаюся з кращими практиками завдяки команді, яка дуже підтримує, з якою я працюю в Kite. Шляхом відкритого обміну ми змогли внести інновації таким чином, щоб зробити нашу роботу більш ефективною, ефективною та веселою. Якщо ваше робоче місце це підтримує, я рекомендую вам організовувати сесії обміну знаннями та встановлювати спеціальні години щотижня для експериментів над новими методами; це найефективніший спосіб розробити довгострокові стратегії для того, щоб ваші команди були тісно пов'язаними та постійно впроваджували інновації.