При софтуерното тестване, автоматизирано тестване (, ) е автоматизация чрез скриптове, приложения или платформи за автоматизация на теста, както при софтуерния тест, така и в автоматизирания хардуерен тест. Използването на „специалния“ софтуер за автоматизация (който е различен от софтуера, който е тестван), за да се контролира извършването на тестове, сравнението на реалните резултати към предвижданите резултати, определянето и полагането на тестовите предусловия и друг тип тестови контрол и функции на тестовото докладване. Често автоматизираното тестване включва автоматизация на процеса на ръчно тестване, който е вече налице, като се ползва формализация на тестовия процес.
Обща информация Някои видове тестове отнемат много време и усилия, когато са извършвани ръчно. Този подход може да не е особено ефективен при намирането на определен тип дефекти. Автоматизираното тестване дава възможност за ефективното провеждане на такъв тип тестове. Веднъж разработени, автоматизираните тестове могат да бъдат прилагани бързо и многократно повторени.
Съществуват много подходи към автоматизираното тестване, като основно използваните са: Програмно ориентирано тестване. Публичните интерфейси към класове, модули или библиотеки са тествани с разнообразни входни аргументи, за да се гарантира, че връщаните резултати са верни. Тестване на графичен потребителски интерфейс (ГПИ). Генерират се действия, извършвани от потребителя (напр. натискане на клавиш, клик с мишка) и се наблюдават промените в резултат на това взаимодействие, за да се гарантира, че поведението на програмата е коректно. Тестване на Приложно-програмен интерфейс (ППИ). Използва се програмен интерфейс към приложението за валидиране на поведението му по време на тест. Обикновено ППИ тестовете не вземат под внимание взаимодействието на потребителя със системата. Автоматизираното тестване, което отговаря на изискванията за медицинско програмиране или тестване на медицинско устройство, за бели устройства (medical device testing)
Инструментите са автоматизирано тестване са скъпи и обикновено се използват в комбинация с ръчно тестване. Автоматизираното тестване може да бъде рентабилно в дългосрочен план, особено при многократното повтаряне на регресивните тестове.
При автоматизираното тестване инженера по Софтуерно осигуряване на качеството трябва да има опит в разработката на софтуер, тъй като тестовите случаи са написани под формата на изходен код (source code), стартирането на който осигурява изходни данни според съдържанието му.
Един от начините за автоматично генериране на тестове е модел-базираното тестване (английски: model-based testing, тестване на основата на модели). При него се използва модел на система за генериране на тестови случаи. В някои случаи използването на този подход позволява на нетехнически потребители да създават автоматизирани бизнес тест случаи на чист английски език, като не е необходима никаква софтуерна програма за конфигурирането им за различни операционни системи, браузъри и устройства.
Основните въпроси пред екипа тестващ софтуер са какво и кога да се автоматизира. Избирането на правилните характеристики на продукта за автоматизация до голяма степен определя успеха на автоматизирането. Автоматизирането на нестабилни характеристики и такива, в процес на промяна трябва да се избягват.
Програмно ориентирано тестване Развиваща се насока в разработването на тестов софтуер е използването на софтуерни рамки () като xUnit (като например JUnit и NUnit). Това дава възможност да се изпълнят тестове на отделни части (елементи) от програмния код, за да се установи какво е поведението им при различни обстоятелства. Тестовите варианти определят отделни тестове, които са необходими да бъдат изпълнени, за да се установи дали програмата работи според очакванията.
Програмно ориентираното тестване е като основна характеристика на Гъвкавата методология за разработка на софтуер. Тестовете на елементите на програмата са написани преди да е написан самият програмен код. Същевременно тези тестове биват доразвивани с написването на кода на програмата. Биват откривани нови проблеми и кодът на програмата се преработва.Learning Test-Driven Development by Counting Lines; Bas Vodde & Lasse Koskela; IEEE Software Vol. 24, Issue 3, 2007 След като всички тестове са преминати, кодът се счита за завършен. Защитниците на този метод излагат доводи от рода на това, че създаденият по този начин софтуер е много по-надежден и с много по-ниска себестойност от софтуера, изследван ръчно. Счита се и че е по-надежден, защото код, написан по този начин, е обхванат по-добре, поради факта че е тестван многократно по време на написването му, отколкото веднъж в края на разработването му при каскаден цикъл () на написване. Разработчикът тествайки, докато създава програмата, открива дефектите моментално и прави изменения, когато е най-ефективно да бъдат направени. В заключение преработката на кода става по-безопасна, а трансформирането му, когато не е значително усложнен, е по-лесно и с по-малко усложнения, като същевременно при подобни ситуации е по-малко вероятно да се появят нови дефекти.
Тестване на графичен потребителски интерфейс (ГПИ) В софтуерното инженерство, тестване на графичен потребителски интерфейс (ГПИ; ) е процес, при който се провеждат тестове на графичната среда на продукта, чрез която потребителя взаимодейства със системата, за да се гарантира, че отговаря на съответните спецификации. Това обикновено се извършва чрез прилагането на различни тестови случаи.
Софтуерно генериране на тестове За да генерират определен набор от тестове, разработчиците на тези тестове, наричани инженери по софтуерна автоматизация, се опитват да покрият цялата функционалност на системата и напълно да изпитат възможностите на ГПИ. Трудността при изпълнение на тази задача е двойна: да се справят с обема на задачата и проблема с последователността. В допълнение, тестерът е изправен пред още трудности, когато трябва да се направи регресивно тестване.
За разлика от интерфейса на командния ред (ИКР) (превод от анг. Command Line Interface (CLI)), ГПИ има много функционалности, които трябва да бъдат изпитани. Сравнително малка програма като Microsoft WordPad има 325 възможни графични операции. В една голяма програма броят на операциите може да бъде число, по-голямо с един порядък.
Вторият проблем е проблемът с последователността. Някои функционалности на системата могат да бъдат извършени само чрез поредица от ГПИ събития. Например, за да отвори файл, потребителят може да се наложи да избере първо овото меню, след това да избере операция Отвори, да използва диалоговия прозорец, за да зададе името на файла, и да посочи на приложението новоотворения прозорец. Увеличаването на броя на възможните операции увеличава проблема с последователността експоненциално. Това може да се превърне в сериозен проблем, когато тестващият създава тест случаи ръчно.
Тези неудобства са довели проблемната за тестване ГПИ област към автоматизация. Много различни техники са били предложени за автоматично генериране на тестови варианти, които са напълно завършени и симулират реално поведение на потребители.
Повечето от техниките за тестване, се опитват да надградят тези, използвани по-рано за тестване на ИКР програми, но могат да имат значителни проблеми, когато се прилагат за ГПИ. Например краен автомат на базата на моделиране – когато дадена система се моделира като краен автомат и дадена програма се използва за генериране на тестови случаи, които изпитват всички състояния – може да работи добре на система, която има ограничен брой такива, но може да стане твърде сложна и тромава за ГПИ (виж също тестване базирано на модела ().
Планиране и изкуствен интелект Един нов подход за генериране на тестове, адаптиран от ИКР техника, включва използването на система за планиране. Планирането е добре изучена техника от областта на изкуствения интелект (ИИ; ), която се опитва да реши проблеми, включващи следните четири параметъра: първоначално състояние, желано състояние, набор от оператори, и набор от обекти, които да бъдат управлявани.
Системите за планиране обособяват път от първоначалното състояние до желаното състояние с помощта на операторите. Прост пример за проблем на планирането: дадени са две думи и една операция, която заменя една буква в думата с друга. Целта обаче може да бъде да се промени една дума в друга.
Потребителският интерфейс на системата се анализира, за да се определят възможните операции. Те стават операторите, които ще се използват в планирането. Следва да се определи първоначалното състояние на системата и се уточнява желаното такова, така че тестващият да установи начина, по който да се изпита системата. Системата за планиране определя пътя от началното състояние до желаното състояние, което се превръща в план за тестване.
Генерирането на тестови случаи чрез използването на система за планиране има някои специфични предимства пред ръчното генериране. Системата за планиране сама по себе си генерира решения на дадени проблеми по начин, който е много полезен за тестващия. Плановете са винаги валидни. Изходът от системата е или валиден и правилен план, който използва операторите за постигане на желаното състояние, или изобщо няма план. Това е полезно, защото може да бъде изгубено много време при ръчното създаване на тестови пакети, когато са налице невалидни тестови случаи, които тестващият е мислил, че ще работят, а те не работят. Системата за планиране обръща внимание на реда. Често за тестването на отделна функция, тестовият случай трябва да бъде комплексен и следва метод, в който операциите се извършват в определен ред. Когато се прави ръчно, това може да доведе до грешки и може да бъде доста трудно, и да отнеме доста време. Последно и най-важно, системата за планиране е ориентирана към желания резултат. Тестерът фокусира генерирането на набор от тестове върху това, което е най-важно, тестване на функционалността на системата.
Когато се създаде ръчно един тестов пакет, тестващият е по-фокусиран върху това как да се тества дадена функция (т.е. специфичен път през ГПИ). С помощта на системата за планиране, този път е подсигурен и тестващият може да се съсредоточи върху това коя функция да тества. Допълнителна полза от това е, че системата за планиране не е ограничена по никакъв начин, когато генерира път и често се случва да намери път, който никога не би бил предвиден от тестващият. Този проблем е много основен.
Тестване на Приложно-програмен интерфейс (ППИ) Приложно-програмен интерфейс (ППИ, , API) е колекция от класове и методи, които могат да бъдат достъпвани и изпълнявани от други софтуерни приложения. Осигурява комуникацията и обмена на данни между две отделни софтуерни системи.
При ППИ тестовете се използва външен софтуер, който взаимодейства с ППИ на тестваната система, изпитва функционалността му и валидира поведението му по време на теста. Вместо използването на стандартните потребителски вход (клавиатура) и изход, комуникацията се осъществява чрез подаване на заявки към ППИ, генерират се изходни данни и се наблюдава отклика на системата.
При този тип тестове се следи за: Осигуряване на разнообразни входни параметри към ППИ, които проверяват функционалността му и предизвикват грешки. Разглеждат се както обичайни случаи, така и гранични състояния. Генериране на комбинации от параметри за проверка на заявките към ППИ с два или повече параметри. Определяне на условията, при които се извършва заявка към ППИ. Те могат да бъдат външни (настройка на файлове, периферни устройства и др.) или вътрешни данни, които оказват влияние върху ППИ. Осигуряване на разнообразна последователност от заявки към ППИ и проверяване дали се генерират търсените резултати при последователни заявки