CC BY
31
Научни трудове на Съюза на учените в България - Пловдив. Серия В. Техника и технологии. Том XVII, ISSN 1311 -9419 (Print); ISSN 2534-9384 (Online), 2019. Scientific Works of the Union of Scientists in Bulgaria - Plovdiv. Series C. Technics and Technologies. Vol. XVII.,ISSN 1311-9419 (Print); ISSN 2534-9384 (Online), 2019
МНОГОСЛОЙНА АРХИТЕКТУРА ЗА АВТОМАТИЗАЦИЯ НА
ТЕСТОВЕ В AGILE Денислав Лефтеров, Светослав Енков Пловдивски Университет „Паисий Хилендарски"
MULTILAYER ARCHITECTUbTt FOR TEST AUTO^TION IN AGILE Denislav Lefterov, Svetoslav Enkov Plovdiv University "Paisii Hilendarski"
Abstract
This article presents a multilayer architecture for software automation testing with Agile flexible methodology, by increasing the test coverage and the depth of each layer. Test automation is an act of converting manual test cases into automated scripts that can be performed autonomously. Multilayer architecture divides the automation project into separate levels: representative, business, data layer and service layer. These abstractions allow automated testing to continue providing feedback despite the constant change of the system. This approach has been explored in a real working environment, and observations have shown that the architecture of automation is change-resistant, while increasing test coverage, depth of testing, and overall the application quality.
Key words: software, testing, automation, architecture, agile
Въведение
През последните години софтуерното инженерство се адаптира към промените в глобалния процес на разработка на софтуер, за да се облекчат високите разходи, високата сложност, времето за пускане на пазара, трудностите при поддръжка и увеличаване на удовлетвореността на крайните потребители. Анализите показват, че тестовете съставляват около 60% от общия бюджет за развитие, като приблизително 50% са регресионни. Тенденцията показва, че много от софтуерните организации поетапно мигрират към практиките за разработка на софтуер по модела "Agile" и автоматизираното тестване с цел да намалят разходите, дългите регресионни цикли и времето за пускане на пазара. Традиционно тестовата автоматизация се изпълнява върху стабилни, не променящи се приложения. В средата "Agile" кодът постоянно се променя, автоматизираните тестови случаи стават неактуални и трябва непрекъснато да се преработват. В много от случаите цената на поддръжката на автоматизирания тестов код напълно засенчва цялото усилие за автоматизация и прави невъзможна възвръщаемостта на инвестициите (Return On Investment).
Цели
При използването на принципите на "Agile" фирмата може да добавя нова функционалност и да пусне актуализирана версия много бързо. Това включва изпълнение на планирането, разработване, тестване и събиране на обратна информация в рамките на кратки итеративни цикли или спринтове. Тези видове системи се оказват по-ефективни и по-качествени от тези, разработени в класическия водопаден модел. Основна характеристика на един напреднал екип за развитие при гъвкава методология е включването
на тестовата автоматизация като част от процеса. Автоматизирането основно се прилага върху солидно работещи системи, които са стабилни, което означава, че има много малко промени и обикновено се фокусира около потребителския интерфейс (GUI). Постоянните промени правят тестовете за автоматизиране изключително комплексни (сложни) и в някои случаи - непрактични. Тестовете, които са автоматизирани в предишен спринт, може да са вече остарели в текущия, поради промените в изходния код. При многослойната структура всеки слой има различна рамка, която е подходяща за функционалността на конкретната система и обикновено се интегрира с непрекъснато изграждане и проследяване.
Тази статия представя подробно описание на архитектурата за тестова автоматизация в "Agile" и обхваща основни етапи на регресионното тестване и непрекъснатата интеграция. Проследено е цялостното проектиране и подробен обхват на многослойната архитектура и е направен анализ на съответното проучване. Накрая са описани постигнатите резултати от изследването.
Регресионно тестване
Регресионното тестване е от решаващо значение за фазата на разработване на жизнения цикъл на софтуера, тъй като целта е да се премахнат грешките, преди производството и внедряването на продукта. Тестовете за регресия се натрупват и конструират в хода на цикъла на разработка, докато продуктът се стабилизира. Разходите, свързани както с управлението, така и с изпълнението на регресионни тестове, стават основна пречка пред много организации днес, защото сложността на софтуера се увеличава, както и времето, необходимо за разработването му. В повечето случаи дългите регресионни цикли могат да удължат цялостното изпълнение на продуктите и могат да имат тежки последици при навлизането на нови етапи на приложението. Следователно, производителите на софтуер търсят начини да съкратят времето на регресионния цикъл и да увеличат максимално приходите си от настоящата итерация. Един общ подход е да се изберат части от кода за тестване, особено тези, за които се счита, че имат най-висок риск. Селективното тестване има по-голям риск при неоткрити грешки, които може да не бъдат идентифицирани преди внедряването, където разходите за поправка са много по-големи. Предизвикателството се състои в намирането на баланс при избора на регресионни групи, изпълнявани върху малко зони и потенциално позволяващи промъкването на сериозен дефект. Последните тенденции показват, че разработчиците на софтуер, използващи "Agile", се обръщат към тестването на автоматизацията като отговор на намирането на точния баланс.
Тестова автоматизация
Тестовата автоматизация увеличава дълбочината и скоростта на процеса на осигуряване на качеството, тя е ядрото в "Agile" и ключов елемент на успешното развитие. Тестовата автоматизация използва софтуер за контрол на изпълнението на тестовете, сравнението на реалните резултати с предвидените резултати, настройването на предварителните условия за тестване и други функции за измерване на тестовете.
Софтуерната рамката е интерфейс за програмиране на приложения, който се използва за улесняване на процеса на автоматизиране на тестовите случаи. Примерите за рамки включват JUnit на Java, "Robot Test Framework", SeleniumHQ, Selenium Web Driver. Архитектурата представлява интеграция на множество рамки в една интегрирана система. От гледна точка на системното инженерство, една рамка е оприличена на индивидуална независима система и архитектурата е система от системи, където минимум две са интегрирани, за да постигнат нови възможности [4] [11] [16].
Непрекъсната интеграция
Постоянната интеграция (Continuous Integration) е практика, при която малките промени често се проследяват. Всяка промяна на кода е отбелязана, пакетирана и тествана, а основната й цел е да предотврати проблеми с интеграцията на нови версии. Бързото приемане на методологията "Agile" в толкова голям мащаб увеличава използваемостта. Повечето сървъри с непрекъсната интеграция на пазара днес имат основен интерфейс за приложно програмиране с цел разширяване на функционалността. Това доведе до разработването на голямо количество приставки с отворен код, което увеличава гъвкавостта и полезността им. Сървърът извършва тестове на няколко нива (единица, функционалност и интеграция) като включва внедряване на новата функционалност в отделни аспекти. Това осигурява множество показатели на всеки етап за проследяване на процесите и напредъка на даденото приложение.
Управление на данните от теста
Едно от най-големите предизвикателства при тестването на софтуер е да се реши какъв вид тестови данни да се използват и как да бъдат създадени. Проблемът с данните от теста е, че трябва да бъдат поддържани. Наборите от данни често се оказват "остарели" поради промени в бизнес логиката. Статичните (непроменящи се често) данни увеличават поддръжката през целия живот на проекта за автоматизация. Без стратегия за управление на тестовете, всяко начинание за автоматизация ще бъде неефективно. Най-добрият подход за смекчаване на този проблем е ясното и решително разделяне на отговорността, чрез изграждане на абстрактен слой между данните от теста и кода за изпълнение. Има няколко по-често използвани метода, вариращи спрямо сложност и надеждност, използвани за осигуряване на правилната информация в точното време [15].
Файлове с данни
Съхраняването на данни от тестове в XML или в схема като .xsd файл е по-ефективно от електронните таблици или .csv файлове, защото позволяват задълбочено описание и дефиниране на данните от теста. За предвидими и статични набори от данни тази техника е най-ефективна, тъй като схемите могат да се четат и зареждат в паметта, което осигурява печалба под формата на допълнителен ресурс. Също така размерите на файловете са доста малки, транспортирането им през мрежата или споделянето им между системите е практично и бързо. Запазването на файлове с данни добавя ненужна сложност към цялостната архитектура. Постоянните (статични) данни, подобни на функционалността на дадена база данни, изискват допълнителни механизми за съхраняване и извличане на информацията, което въвежда допълнителни точки на поддръжка към системата [13].
Управление на тестови обекти
Тестовите обекти наподобяват всеки друг обект или клас, присъщи в обектно-ориентираното програмиране (ООП). Те се предлагат в много различни типове и имат потенциал да си сътрудничат между едно или повече нива. Например DAO/ADO обектите са свързани с данни и се използват предимно за взаимодействието с данни, но могат да се използват и в рамките на бизнес слоя. Всеки обект има състояние (свойства) и асоциирано поведение (методи), което позволява на тестовите обекти да взаимодействат със системата.
Многослойна архитектура за автоматизация на тестове
Софтуерните проекти следват многослоен процес на проектиране, където разработката е разделена на отделни слоеве или нива. Системата предоставя различни интерфейси на различни типове клиенти. Всеки клиент се интересува от използването или консумирането на тази система по различни начини. Потребителският интерфейс може да взаимодейства с дадена услуга, за да генерира информация, необходима за визуализиране на потребителя. С уеб услуга се извличат или поддържат данните в базата данни или чрез външен интерфейс към други системи. Тестовата автоматизация изисква значително разработване на софтуер,
поради което усилията трябва да се третират по същия начин като всеки друг софтуер. Структурирането на автоматизацията в отделни слоеве създава абстракция, което увеличава гъвкавостта и дълбочината на покритие, това води до по-добро общо качество на тестваната система. Няма определен (фиксиран) брой нива, които дадена система трябва да има. Обикновено има поне две: представителен и бизнес слой [12] [13] [14].
Визуализационно ниво
Графичният потребителски интерфейс (GUI) се намира в презентационния слой. Повечето проекти за автоматизация се фокусират върху GUI - това е главната входна точка. Този подход обаче е фундаментално недостатъчен. Чрез фокусирането на средствата за автоматизация единствено върху потребителския интерфейс, ефективността на проекта е ограничена чрез третиране на част от тестваната система като "черна кутия". Маскирането на бизнес логиката като графични обекти и писане на тестови скриптове с тази сложна логика, вградена в тях, става твърде трудна за разработване и поддържане задача. Подреждането на слоевете трябва да се фокусира върху опита на разработчиците и по-малко върху основната логика. След като бизнес логиката бъде създадена и обработена, писането на тестови скриптове става много по-лесно. Не само ефективността и скоростта на скриптовете ще се подобри, но и покритието на тестовете ще се увеличи.
Бизнес ниво
Бизнес слоя е двигателят, който дава изискванията на приложението. Постигането на това ниво е крайната цел на разработващия екип, това консумира голяма част от ресурсите за развитие. Тестовете за автоматизация трябва да отразяват тази приложимост. Разбирането на бизнес логиката е от решаващо значение за успешното внедряване на автоматизирани тестове. Използването на различни интерфейси намалява риска от пропуски при тестовете. Изпробването само чрез графичния интерфейс не е достатъчно, за да се тестват напълно всички аспекти и интерфейси, които дадена система може да представя.
Ниво на данните
От самото начало архитектът по автоматизация трябва да участва в дискусиите, свързани с първоначалния дизайн на системата. На този етап проектната документация може да бъде прегледана от гледна точка на качеството. Целта в тази подредба е да се гарантира сигурност, че данните, които приложението използва, са верни. Повечето хранилища за данни предоставят механизъм за абстракция и съществуват няколко рамки за създаване на обекти за данни. Взаимодействието с база данни, използваща обекти за достъп до данни (DAO), позволява висока степен на гъвкавост, стабилност и изпитание.
Уеб услуги
Сървърът за уеб услуги на приложението е насочен към интерфейса на дадена уеб услуга. Интерфейсът, като WSDL/WADL или REST, служи като връзка между доставчика и потребителите на услуги. Основното изпълнение на услугата е без значение; като основно функционира като "черна кутия", приема заявка и връща отговор (резултат). Тестването на уеб услуги обикновено се извършва в две форми: тестове за функционалност и за натоварване. При функционалното тестване целта е да се потвърди, че услугата действително работи според очакваните резултати. При тестовете за натоварване се цели проверка, дали услугата работи според очакванията при повишено външно натоварване на потребителско ниво. На пазара има редица инструмента, които се специализират в тестване на уеб услуги. Най-добрите резултати обикновено се получават, когато динамичните входни данни са разпръснати и смесени със статични, което е от съществено значение не само за тестване на функционалността и производителността, но и за изследване на конкретното поведение на системата [8] [9].
Изследване
Описваното изследване беше проведено върху корпоративно приложение, разработено чрез Java. Архитектурният подход за автоматизация на тестовете е разработен чрез многослойния модел, описан по-горе и включен при второто пускане на новите функционалности на системата. Беше използвана следната схема за работа: 10 двуседмични спринтове. Проектът е предназначен да управлява и поддържа система за записване на специфични за потребителя обекти и да извършва специфични за домейна анализи, като същевременно координира съобщенията и комуникацията между тези структури. Технологичният стек е изцяло базиран на Java, като използва Tomcat сървър на приложения, Java Messaging Service (JMS) за кореспонденция, Java Web Persistence Architecture (JPA) I6 Web Service. Maven 2 за управление на библиотеките в целия проект. [2] [3].
Архитектурата на автоматизацията за този проект трябва да бъде достатъчно гъвкава, за да се справи с постоянните промени, които възникват при всеки спринт. За да се постигне това, всички етапи бяха сведени до това приложението да бъде разделено на две отделни архитектури - визуализационно ниво и слой за обработка.
Визуализационно ниво
Слоят за визуализация обхваща графичния потребителски интерфейс (GUI), изобразен на Фигура 1. Тази подредба се фокусира върху тестването на основното валидиране на GUI и взаимодействията на потребителите, използвайки smoke тестове. Целта на тестовете в тази подредба е да потвърдят, че правилната функционалност се поддържа при потребителския слой. За този слой автоматизираните тестове са ориентирани към GUI, изградени чрез технологията Selenium Web Driver. Изходен код хранилището наречен Git, който действа като система за управление на тестови случаи. Това се прави защото автоматичните тестови скриптове са написани на Java и са синхронизирани заедно с изходния код на приложението [5] [10].
Фигура 1
Сървърът Jenkins Cl се използва за управление на тестове, както и визуализиране на резултатите. При всяка нова промяна или внедряване на нова функционалност. Освен това настройката му включва изпълнението на всички тестове на определен интервал от време и генериране на специфичен отчет (report) [6].
Обработващ слой
Обработващия слой представлява подразделението на бизнес логиката на приложението: данни и уеб услуги, което е представено на Фигура 2. Целта е да се изолират и валидират бизнес правилата, целостта на данните и функционалността на уеб услугите отделно от визуализационния слой GUI. Проектирането на алгоритми за валидиране и системните точки са добри примери за бизнес логика, която се нуждае от тестване в тези нива. Проектът използва "Cucumber", която е рамка за разработване на тестове на поведение (BDD), заедно с JUnit - рамка за тестване на единиците (units), за да се справи с бизнес слоя [7]. Данните се достъпват чрез обекти. Тестването на уеб услуги се извършва с Apache JMeter - друг инструмент с отворен код. JMeter осигурява възможността за едновременно тестване на функционалността и производителността. Отново всички автоматизирани тестови скриптове бяха съхранени в хранилището на изходния код, а Jenkins е включен за интегриране на всички инструменти заедно [1] [6] [14].
Фигура 2
Наблюдения
Проектът се развиваше с всеки изминал спринт, функционалността беше добавяна и усъвършенствана. Обикновено в гъвкавите среди изискванията към софтуера не винаги са напълно разработени, поради това всеки нов спринт може потенциално да въведе значителни промени в работния поток на потребителския интерфейс, бизнес правилата и дори в схемата на базата данни. Тези видове промени обикновено причиняват хаос в един проект за автоматизация поради времето, необходимо за рефакториране, докато същевременно се опитват да се справят с тестовете. По време на това изследване, поддръжката значително намаля. Абстракцията между слоевете позволи относително бърза оптимизация. Всяко ниво позволи фокусирано тестване в контекста, за да стане по-лесно да се разработят по-сложни сценарии, като се увеличи както дълбочината, така и обхватът.
Заключение
Тази статия представи описание на многослойна тестова архитектура, чрез нов подход за оптимизиране на разработването на тестове в среда на "Agile". Основният принцип, който стои зад този метод, е извеждането на проекта на отделни нива. Разгледани са конструктивните съображения на архитектурата за автоматизация и са описани четирите най-често използвани принципа. Беше проведено изследване, като тази архитектура беше приложена към софтуерна система разработвана в "Agile", използваща технологията Java във втората фаза на продукта. Проучването показа, че чрез прилагане на абстракции тестовата автоматизация е в състояние да обхване по-широк набор от функционалности, като същевременно позволява по-подробно тестване в критични области. Освен това, разходите за поддържане на тестовата инфраструктура бяха значително намалени и това доведе до увеличаване на мащабируемостта и гъвкавостта. Крайният резултат показва, че продуктът е вече оптимизиран и с по-високо качество в сравнение с първоначалното си състояние.
Литература
1.Apache JMeter, http://jmeter.apache.org. (Accessed on 02.10.2018)
2. Apache Maven Project http://maven.apache.org. (Accessed on 03.10.2018)
3.Apache Tomcat, http://tomcat.apache.org. (Accessed on 06.10.2018)
4.SeleniumHQ: Browser Automation', http://www.se1eniumhq.org. (Accessed on
07.10.2018)
5.Git - Distributed-Even-If-Your-Workflow-Isnt', http://git-scm.com. (Accessed on 07.10.2018)
6.Jenkins: An Extendable Open Source Continuous Integration Server, http://jenkins-ci.org. (Accessed on 10.10.2018)
7.JUnit: A Programmer—Oriented Testing Framework for Java', http://junit.org. (Accessed on 10.10.2018)
8.Martin Kalin, Java Web Services: Up and Running. O'Reilly Media, 2009.
9.Vicente Lucena Eliane Collins ' Iterative Software Testing Process for Serum and Waterfall Projects with Open Source Testing Tools.
10. David A. Chappell, Java Message Service O'Reilly Media, 2000. p.240.
11. Michael Kelly, 'Choosing a Test Automation Frarnework'2003) http://www. ibm.com/developerworks/rationa1/1 ibrary/591 .htm1.
12. The Fully Integrated Standalone Wiki and Acceptance Testing Framework, http://fitnesse.org. (Accessed on 10.10.2018)
13. Eberhardt Rechtin Mark W. Maier, The Art of Systems Architecting. 3rd Press,
2009.
14. Aslak Helleszy Matt Wynne, The Cucumber Book: Behavior-Driven Development for Testers and Developer, 2012.
15. Dorothy Graham Mark Foster, Software Test Automation, Effective Use of Test Execution Tools Addison-Wesley, 2010).
16. 'Robot Framework: A Generic Test Automation Framework,
https://code.google.com/p7robotframework. (Accessed on 08.10.2018)
За контакти:
Пловдивски университет „Паисий Хилендарски", ул. Цар Асен 24, 4000 Пловдив докторант Денислав Лефтеров, ФМИ, e-mail: denislav.lefterov@uni-plovdiv.bg доц. д-р Светослав Енков, ФМИ, e-mail: enkov@uni-plovdiv.bg
