Автоматизирано тестване

от Уикипедия, свободната енциклопедия
Направо към: навигация, търсене

В софтуерното тестване, автоматизирано тестване (на английски: test automation) е използването на специален софтуер (различен от софтуера, който е тестван), за да се контролира извършването на тестове, сравнението на реалните резултати към предвижданите резултати, определянето и полагането на тестовите предусловия и друг тип тестови контрол и функции на тестовото докладване.[1] Често автоматизираното тестване включва автоматизация на процесът на ръчно тестване, който е вече налице, като се ползва формализация на тестовия процес.

Обща информация[редактиране | редактиране на кода]

Някои видове тестове отнемат много време и усилия, когато са извършвани ръчно. Този подход може да не е особено ефективен при намирането на определен тип дефекти. Автоматизираното тестване дава възможност за ефективното провеждане на такъв тип тестове. Веднъж разработени, автоматизираните тестове могат да бъдат прилагани бързо и многократо повторени. Съществуват много подходи към автоматизираното тестване, като основно използваните са:

  • Програмно ориентирано тестване . Публичните интерфейси към класове, модули или библиотеки са тествани с разнообразни входни аргументи, за да се гарантира, че връщаните резултати са верни.
  • Тестване на графичен потребителски интерфейс (ГПИ). Генерират се действия, извършвани от потребителя(напр. натискане на клавиш, клик с мишка) и се наблюдават промените в резултат на това взаимодействие, за да се гарантира, че поведението на програмата е коректно.
  • Тестоване на Приложно-програмен интерфейс (ППИ). Използва се програмен интерфейс към приложението за валидиране на поведението му по време на тест. Обикновено ППИ тестовете не вземат под внимание взаимодействието на потребителя със ситемата.

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

При автоматизираното тестване инженера по Софтуерно осигуряване на качеството трябва да има опит в разработката на софтуер, тъй като тестовите случай са написани под формата на изходен код (английски: source code), стартирането на който осигурява изходни данни според съдържанието му.

Един от начините за автоматично генериране на тестове е модел-базираното тестване (английски: model-based testing). При него се използва модел на система за генериране на тестови случай. В някои случай използването на този подход позволява на нетехнически потребители да създават автоматизирани бизнес тест случаи на чист английски език, като не е необходима никаква софтуерна програма за конфигурирането им за различни операционни системи, браузъри и устройства.[2]

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

Програмно ориентирано тестване[редактиране | редактиране на кода]

Развиваща се насока в разработването на тестов софтуер е използването на софтуерни рамки (английски: software frameworks) като xUnit (като например JUnit и NUnit)това дава възможност да се изпълнят тестове на отделни части (елементи) от програмния код за да се установи какво е поведението им при различни обстоятелства. Тестовите варианти определят отделни тестове, които са необходими да бъдат изпълнени за да се установи дали програмата работи според очакванията.

Програмно ориентираното тестване е като основна характеристика на Гъвкавата методология за разработка на софтуер. Тестовете на елементите на програмата са написани преди да е написан самия програмен код. Същевременно тези тестове биват доразвивани с написването на кода на програмата. Биват откривани нови проблеми и кода на програмата бива преработван. [3] След като всички тестове са преминати кода бива считан за завършен. Защитниците на този метод излагат доводи от рода на това, че създадения по този начин софтуер е много по-надежден и с много по-ниска себестойност от софтуера изследван ръчно. Счита се и че е по-надежден, защото код написан по този начин е обхванат по-добре, поради факта че е тестван многократно по време на написването му, отколкото веднъж в края на разработването му при каскаден цикъл (английски: Waterfall model) на написване. Разработчика тествайки, докато създава програмата открива дефектите моментално и прави изменения, когато е най-ефективно да бъдат направени. В заключение преработката на кода става по-безопасна, а трансформирането му, когато не е значително усложнен е по-лесно и с по-малко усложнения като същевременно при подобни ситуации е по-малко вероятно да се появят нови дефекти.

Тестване на графичен потребителски интерфейс (ГПИ)[редактиране | редактиране на кода]

В софтуерното инженерство, тестване на графичен потребителски интерфейс (ГПИ на англиски: Graphical User Interface (GUI) testing) е процес, при който се провеждат тестове на графичната среда на продукта, чрез която потребителя взаимодейства със системата за да се гарантира, че отговаря на съответните спецификации. Това обикновено се извършва чрез прилагането на различни тестови случаи.

Генериране на тестове[редактиране | редактиране на кода]

За да генерират определен набор от тестове, разработчиците на тези тестове, наричани тестери се опитват да покрият цялата функционалност на системата и напълно да изпитат възможностите на  ГПИ. Трудността при изпълнение на тази задача е двойна: да се справят с обема на задачата и проблема с последователността. В допълнение, тестера е изправен пред още трудности, когато трябва да се направи регресивно тестване.

За разлика от интерфейса на командния ред(ИКР) (превод от анг. Command Line Interface (CLI)), ГПИ има много функционалности, които трябва да бъдат изпитани. Сравнително малка програма като Microsoft WordPad има 325 възможни графични операции. В една голяма програма, броят на операциите може да бъде число с един порядък по-голямо.

Вторият проблем е проблемът със последователността. Някои функционалности на системата могат да бъдат извършени само чрез поредица от ГПИ събития. Например, за да отвори файл потребителят може да се наложи да избере първо файловото меню, след това да избере операция Отвори, да използва диалоговия прозорец за да зададе името на файла, и да посочи на приложението новоотворения прозорец. Увеличаването на броя на възможните операции увеличава проблема с последователността експоненциално. Това може да се превърне в сериозен проблем, когато тестерът създава тест случаи ръчно.

Тези неудобства са довели проблемната за тестване ГПИ област към автоматизация. Много различни техники са били предложени за автоматично генериране на тестови варианти, които са напълно завършени и симулират реално поведение на потребители.

Повечето от техниките за тестване, се опитват да надградят тези,  използвани по-рано за тестване на ИКР програми, но могат да имат значителни проблеми когато се прилагат за ГПИ. Например, краен автомат на базата на моделиране - когато дадена система се моделира като краен автомат и дадена програма се използва за генериране на тестови случаи, които изпитват всички състояния - може да работи добре на система, която има ограничен брой такива, но може да стане твърде сложна и тромава за ГПИ (виж също тестване базирано на модела (на англ. Model-based testing)).

Планиране и изкуствен интелект[редактиране | редактиране на кода]

Един нов подход за генериране на тестове, адаптиран от ИКР техника включва използването на система за планиране. Планирането е добре изучена техника от областта на изкуствения интелект (ИИ на англ. Artificial Intelligence), която се опитва да реши проблеми, включващи следните четири параметър.

  • първоначално състояние,
  • желано състояние,
  • набор от оператори, и
  • набор от обекти, които да бъдат управлявани.

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

Потребителския интерфейс на системата се анализира за да се определят възможните операции. Те стават операторите, които ще се използват в планирането. Следва да се определи първоначалното състояние на системата и се уточнява желаното такова, така че тестера да установи начина, по който да се изпита системата. Системата за планиране определя пътя от началното състояние до желаното състояние, което се превръща в план за тестване.

Генерирането на тестови случаи чрез използването на система за планиране има някои специфични предимства пред ръчното генериране. Системата за планиране, сама по себе си, генерира решения на дадени проблеми по начин, който е много полезен за тестера. 

  1. Плановете са винаги валидни. Изхода от системата е или валиден и правилен план, който използва операторите за постигане на желаното състояние или изобщо няма план. Това е полезно, защото може да бъде изгубено много време при ръчното създаване на тестови пакети, когато са на лице невалидни тестови случаи, които тестера е мислил, че ще работят, а те не работят.
  2. Системата за планиране обръща внимание на реда. Често за тестването на отделна функция, тестовия случай трябва да бъде комплексен и следва метод, в който операциите се извършват в определен ред. Когато се прави ръчно, това може да доведе до грешки и също така може да бъде доста трудно и да отнеме доста време.
  3. Последно и най-важно, системата за планиране е ориентирана към желания резултат. Тестерът фокусира генерирането на набор от тестове върху това, което е най – важно, тестване на функционалността на системата.

Когато се създаде ръчно един тестов пакет, тестера е по-фокусиран върху това как да се тества дадена функция (т.е. специфичен път през ГПИ). С помощта на системата за планиране, този път е подсигурен и тестера може да се съсредоточи върху това, коя функция да тества. Допълнителна полза от това е, че системата за планиране не е ограничена по никакъв начин, когато генерира път и често се случва да намери път, който никога не би бил предвиден от тестера. Този проблем е много основен.

Тестване на Приложно-програмен интерфейс (ППИ)[редактиране | редактиране на кода]

Приложно-програмен интерфейс (ППИ, на английски: Application Programming Interface, API) е колекция от класове и методи, които могат да бъдат достъпвани и изпълнявани от други софтуерни приложения. Осигурява комуникацията и обмена на данни между две отделни софтуерни системи.

При ППИ тестовете се използва външен софтуер, който взаимодейства с ППИ на тестваната система, изпитва функционалността му и валидира поведението му по време на теста. Вместо използването на стандартните потребителски вход(клавиатура) и изход, комуникацията се осъществява чрез подаване на заявки към ППИ, генерират се изходни данни и се наблюдава отклика на системата.[4]

При този тип тестове се следи за:

  • Осигуряване на разнообразни входни параметри към ППИ, които проверяват функционалността му и предизвикват грешки. Разглеждат се както обичайни случаи, така и гранични състояния.
  • Генериране на комбинации от параметри за проверка на заявките към ППИ с два или повече параметри.
  • Определяне на условията, при които се извършва заявка към ППИ. Те могат да бъдат външни (настройка на файлове, периферни устройства и др.) или вътрешни данни, които оказват влияние върху ППИ.
  • Осигуряване на разнообразна последователност от заявки към ППИ и проверяване дали се генерират търсените резултати при последователни заявки[4]

ППИ тестването е различо от останалите видове, тъй като графичния потребителски интерфейс (ГПИ) не е наличен. Въпреки това е необходимо да се направят първоначални настройки на средата, която взаимодейства с ППИ и накрая да се анализират резултатите от теста. Сървърът и базата данни трябва де се конфигурират според изискванията на приложението. Необходимо е да се създадат условия, при които се извиква ППИ. Възможно е това да става директно, в резултат на събитие или като отговор от възникване на изключение.[5][6]

Основните случай при ППИ тестване са базирани на:

  • Връщана стойност, на базата на условие - връщаните стойности от ППИ са проверени спрямо предварително зададено условие. Сравнително лесно изпълнимо, тъй като входящите данни са дефинирани и резултата може да се анализира.
  • Не се връща никаква стойност – проверява се поведението на ППИ, когато няма връщана стойност.
  • Извикване на друг ППИ , събитие или прекъсване – ако ППИ задейства събитие или предизвика спиране на процеса, тези събития трябва да се проследят и отбележат.
  • Актуализиране на структурата от данни – този процес би оказал влияние върху системата и това трябва да бъде валидирано.
  • Промяна на определени ресурси – ако при извикването на ППИ се променят някои ресурси(напр. смяна на регистри, спиране на процес) , трябва да се валидира достъпа до съответните ресурси.[5][6]

Какво да се тества[редактиране | редактиране на кода]

Инструментите за тестване могат да спомогнат автоматизирането на задачи като инсталация на продукт, създаване на тестови данни, взаимодействие с ГПИ, откриване на проблеми (разбор или избор на агенти оборудвани с предсказания необходима е повече информация), дефекти при вход в системата и др. без необходимостта от автоматизирани тестове от край до край.

Необходимо е да се удовлетворяват изискванията, свързани с автоматизираното тестване:

  • Независимост от платформа и операционна система
  • Способност за управление на данни (Входни данни, Изходни данни, Метаданни)
  • Отчети, подлежащи на обработка (Достъп до база данни, Crystal Reports)
  • Лесно отстраняване на грешки и вход в системата
  • Лесен контрол на продуктовата версия – минимум бинарни файлове (английски: binary files)
  • Разширяемост и персонализация( ППИ-тата да могат да бъдат интегрирани с други инструменти)
  • Общ софтуер за управление
  • Поддържа нестартирани тестове за интеграция с процеси за изграждане и партидни пускания. Сървърите с продължителна интеграция изискват това.
  • Изскачащи съобщения през имейл 
  • Поддръжка на разделна заобикаляща среда за изпълнение(разделно тестване)
  • Разделна поддръжка на приложението

Софтуерен рамков (фреймуърк) подход в автоматизацията[редактиране | редактиране на кода]

Софтуерната рамка (фреймуърк на английски: software framework) за  автоматизирано тестване е интегрирана система, която определя правилата за автоматизация на определен продукт. Тази система интегрира функционални библиотеки, източници за тестване на данни, инфорамация за обекта и различни преизползваеми модули. Тези компоненти се държат като малки градивни елементи, които е необходимо да бъдат сглобени за да формират даден бизнес процес. Фреймуъркът дава основите на автоматизираното тестване и опростява  процеса на автоматизация.

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

Правилният избор на софтуерна рамка или техника за описване на сценария помага за поддържането на по-ниски разходи. Разходите свързани с тестването на сценарии се дължат на усилията положени за разработка и поддържане. Сценарийният подход използван по време на автоматизираното тестване оказва влияние на разходите.

Различни софтуерни рамки/техники за описване на сценарии се използват предимно:

  1. Линейно (процедурен код, вероятно генериран от инструменти като тези, които използват запис и възпроизвеждане)
  2. Структурно (използва конструкции за управление - обикновено ‘if-else’, ‘switch’, ‘for’, ‘while’ конструкции)
  3. Ориентирано към данните (данните се пазят извън тестовете в база данни, електронни таблици или чрез друг механизъм)
  4. Ориентирано към ключова дума
  5. Смесено (хибридно - използват се два или повече шаблона)
  6. Софтуерна рамка за автоматизация „Agile“ (английски: Agile automation framework)

Софтуерните рамки за тестване са отговорни за:

  1. Определяне на формата, в който да се изложат очакванията.
  2. Създаването на механизъм, който да бъде вмъкнат или управлението на приложението по време на тест.
  3. Изпълнението на тестовете.
  4. Извеждане на резултатите.

Интерфейс на автоматизираното тестване

Интерфейси на автоматизирано тестване са платформи, осигуряващи въможност за съчетаване на многобройни инструменти и софтуерни рамки за системно/интеграционно тестване на приложения. Целата е да се опрости процеса на прилагане на тестовите случаи към бизнес критерийте. Очакванията са интерфейсите да подобрят ефективността и гъвкавостта на поддръжката на тестовите скриптове.[7]

Test Automation Interface Model

Интерфейса на автоматизирано тестване е съставен от следните основни модули :

  • Интерфейсен двигател (енджин на английски: engine)
  • Интерфейсна среда
  • Хранилище на обектите

Интерфейс двигател (енджин)

Интерфейс енджина е изграден върху интерфейс средата му. Състои се от компонент за обработка на входните данни(парсър на английски: parser) и стартиращ компонент. Парсърът преобразува файловете, идващи от обектното хранилище, на специфичен скриптов език. Стартиращият компонент изпълнява съответните скриптовете.[7]

Интерфейс среда

Интерфейс средата се състои от Проектни библиотеки и Фреймуърк библиотеки. Фреймуърк библиотеките разполагат с модули, свързани с цялостната тестова система, докато Проектните библиотеки имат модули, специфични за приложението, подложено на тест.[7]

Хранилище на обектите

Хранилище на обектите е съвкупността от обектни данни записани по време на теста на приложението .[7]

Определяне на границите между автоматизирания софтуер за тестване и инструментите за тестване[редактиране | редактиране на кода]

Инструментите за тестване са специално създадени и насочени към една определена тестова среда като Windows, инструменти за уеб и т.н. Инструментите за тестване служат като задвижващ помощник за автоматизирания процес. От друга страна автоматизиращия фреймуърк е неприложим като инструмент за конкретна задача, но дава инфраструктурата, в която различни инструменти могат да извършват дейностите си уеднаквено. Това дава една обобщаваща платформа на софтуерния инженер. Съществуват различни типове фреймуърци. Те се категоризират според компонента от автоматизацията, на когото залагат. Това са:

  1. Тестване базирано на данните
  2. Тестване базирано на модулиране
  3. Тестване базирано на ключови думи
  4. Хибридно тестване
  5. Тестване базирано на модел
  6. Програмно ориентирано тестване
  7. Поведенческо ориентирано тестване

Източници[редактиране | редактиране на кода]

  1. Kolawa, Adam и др. Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press, 2007. ISBN 0-470-04212-5. с. 426.
  2. Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications.. //
  3. Learning Test-Driven Development by Counting Lines; Bas Vodde & Lasse Koskela; IEEE Software Vol. 24, Issue 3, 2007
  4. а б What is API Testing?. // Software QA and Testing Resource Center.
  5. а б Ramdeo, Anand. API Testing. // May 5, 2011.
  6. а б Learn API testing. // API Testing. guru99.
  7. а б в г Conquest: Interface for Test Automation Design. // Посетен на 2011-12-11.
Криейтив Комънс - Признание - Споделяне на споделеното Лиценз за свободна документация на ГНУ   Тази страница частично или изцяло представлява превод на страницата „Test automation“ в Уикипедия на английски. Оригиналната статия, както и този превод, са защитени от Лиценза „Криейтив Комънс - Признание, Споделяне на споделеното“, а за статии създадени преди юни 2009 — от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната статия, както и преводната страница, за да видите списъка на съавторите.

Външни препратки[редактиране | редактиране на кода]