Уикипедия

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

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

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

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

Съществуват много подходи към автоматизираното тестване, като основно използваните са:

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

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

При автоматизираното тестване инженера по Софтуерно осигуряване на качеството трябва да има опит в разработката на софтуер, тъй като тестовите случаи са написани под формата на изходен код (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]

Подходи и приложения. Какво да се тества редактиране

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

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

  • Независимост от платформа и операционна система
  • Отчети, подлежащи на обработка (Достъп до база данни, 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]

Проблеми на автоматизацията редактиране

Продължаващо тестване редактиране

Продължаващото тестване е процесът на изпълнение на автоматизирани тестове като част от процеса за доставка на софтуер, за да се получи съответна обратна връзка за бизнес рисковете, свързани с даден програмен продукт, който е софтуерен кандидат за пускане към потребителите.[8] За този тип тестване, обхватът на тестването се простира от валидиране на изискванията от долу нагоре до оценка на системните изисквания, свързани с различни бизнес цели.[9]

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

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

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

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

  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 // 5 май 2011.
  6. ↑ а б Learn API testing // API Testing. guru99.
  7. ↑ а б в г Conquest: Interface for Test Automation Design // Архивиран от оригинала на 2012-04-26. Посетен на 11 декември 2011.
  8. ↑ The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola, by Cameron Philipp-Edmonds, Stickyminds December 2015
  9. ↑ Errors after pushing software to the client machine

Външни препратки редактиране

    Тази страница частично или изцяло представлява превод на страницата Test automation в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​

Взето от „https://bg.wikipedia.org/w/index.php?title=Автоматизирано_тестване&oldid=12138856“.