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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Kolawa, Adam и др. Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press, 2007. ISBN 0-470-04212-5. с. 426.
  2. а б What is API Testing?. // Software QA and Testing Resource Center.
  3. а б Ramdeo, Anand. API Testing. // May 5, 2011.
  4. а б Learn API testing. // API Testing. guru99.
Криейтив Комънс - Признание - Споделяне на споделеното Лиценз за свободна документация на ГНУ   Тази страница частично или изцяло представлява превод на страницата „Test automation“ в Уикипедия на английски. Оригиналната статия, както и този превод, са защитени от Лиценза „Криейтив Комънс - Признание, Споделяне на споделеното“, а за статии създадени преди юни 2009 — от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната статия, както и преводната страница, за да видите списъка на съавторите.

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