От ледниковия период до Отмъстителите, използващи 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. Всички включени нови промени в потребителския интерфейс са трудни за включване в този вид код, защото трябва да се извърши много рефакторинг - в множество точки - за да работи отново.

Ясно е, че класическият подход може да изглежда лесен, но щом функциите в дадено приложение се увеличат, това се превръща в главоболие за управление на този код.

Роботен подход

Ами ако следваме подход, при който се концентрирахме само върху това, което искаме да постигнем? а не Как искаме да го постигнем? След това бихме създали различни класове за Как и какво. По този начин и как и какви категории ще бъдат независими една от друга.

Моделът за тестване на робота е подобен на широко използвания Page Object Model, който представлява дизайнерски модел, предназначен за създаване на обектно хранилище за UI елементи за уеб-базирани платформи.

В момента ние разчитаме на ръчен потребител за извършване на действия. Ами ако роботите направиха всичко това за нас? При подхода Robot знаем, че екранът ни позволява да въведем потребителско име / парола, без да се отнасяме до това къде отиват тези стойности.

Сценарий за роботи

В PasswordPasswordScreenBot съществува робот, който предава стойности в полетата за потребителско име / парола и кликва върху „Вход.“ Сега екранът се променя и този робот има контрол само над класа на UsernamePasswordScreenBot. Оттук друг бот поема, да речем, ResultScreenBot за извършване на действия по-нататък на следващия екран.

С други думи, създайте робот на екран и той ще извърши необходимите действия.

Седнете, отпуснете се и оставете роботите да работят за вас.

Този код обяснява какво искаме, тоест да можем да въведем потребителско име и парола, които трябва да влизат в потребителя.

сравнение

Нека сравним показателите и промените в ефективността на класическия подход и подхода Robot:

  1. Дублирането на кода е сведено до минимум, тъй като поставяме идентификатори на елементи в един клас и използваме един и същ клас всеки път.
  2. Четеността на кода се подобри, тъй като нов член, който се присъедини към екипа, може да разбере какво прави този код по-интуитивно.
  3. Управлението на такъв код и адаптирането към промените в потребителския интерфейс вече са по-лесни. Променете кода на едно място и тази промяна се отразява навсякъде. Помислете за пример: в потока за вход идентификаторът на елемент се променя или се добавя ново поле. В класическия подход трябва да правим промени във всяка точка, в която влизаме потребител. В подхода Robot просто ще добавим или редактираме елементите в класа на UsernamePasswordScreenBot и ще го извикаме директно оттам.

Обхват за тестване на роботи

В началото може да мислим, че ботовете не са достатъчно умни, за да завършат тест на Sanity или да покрият отрицателните потоци. Въпреки това, вашите ботове ще направят отрицателни, Sanity и регресия тест чрез код като този по-долу - ще ви даде няколко допълнителни заветни минути, които да прекарате в обедната си почивка. За това трябва да създадем различни методи и да предаваме съдържание.

Горният код показва как можете да създадете методи за всички видове данни, които искате да предадете в един клас. Класическият подход се концентрира върху това какво да се постигне и как да се постигне изобщо. Трябва да се отървем от този компонент „Как“, за да опростим нещата.

Спестяване на време и изграждане на капацитет

Спестихме значително време и увеличихме възможностите си, като преминем към подхода Робот.

  1. Тестовото ни покритие се увеличи в сравнение с ръчното тестване.
  2. Намалихме времето, необходимо за завършване на Sanity от пълен ден на 5–10 минути.
  3. Намалихме времето за създаване на скрипт с 50% и решихме проблема с мащабируемостта.
  4. С подхода на сценария можем да създадем регресионен пакет, който прави тестването по-просто и по-точно.

заключение

Като стартирах като Kite, имах гъвкавостта да изпробвам нови неща и да инвестирам време в научни изследвания - поради това успях да изляза с нов подход за използване на Appium. Сблъсквам се с по-добри практики всеки ден благодарение на екипа, който подкрепя много, с който работя в Kite. Чрез открит обмен успяхме да внесем иновации по начин, който направи работата ни по-ефективна, ефективна и забавна. Ако работното ви място го поддържа, аз ви насърчавам да организирате сесии за споделяне на знания и всяка седмица да създавате специални часове, за да експериментирате върху нови техники; това е най-ефективният начин за разработване на дългосрочни стратегии, за да поддържате екипите си плътно сплотени и постоянно иновационни.