Тестването на мутации или мутацията на програми е техника за тестване на „бели кутии“, която помага на компаниите да разработят редица нови софтуерни проверки, като същевременно одитират текущите процеси на проекта. Това е сравнително нов подход, който гарантира, че както разработчиците, така и тестерите работят по висок стандарт.
Едно приложение е толкова успешно или добро, колкото са добри собствените му процедури за осигуряване на качеството, което означава, че е от съществено значение организациите да използват повече от един вид техники за тестване.
Изучаването на тестването за мутации може да помогне на екипите за тестване да повишат своите умения и общия си репертоар, което ще им позволи да подобрят надеждността на тези проверки. Тестването на мутации е сложен и деликатен процес, затова е жизненоважно тестващите да проучат внимателно ползите, предизвикателствата и програмите на трети страни, които могат да гарантират успешното им прилагане.
В тази статия разглеждаме тестването на мутации и как то подобрява осигуряването на качеството, както и други ключови съображения за екипите за тестване на софтуер.
Какво представлява тестването на мутации при тестването на софтуер?
В контекста на софтуера тестването с мутации означава, че екипът за осигуряване на качеството умишлено въвежда грешки – или „мутации“ – в кода на дадено приложение, за да види как реагира екипът. Целта е да се създаде грешка и да се гарантира, че пакетът за тестване може да идентифицира всяка промяна в приложението.
Когато редактира кода на програмата, тестерът на мутациите може да промени израз true/false, да изтрие твърдение или просто да промени стойност. Тези грешки могат да се проявят по различни начини по време на други проверки на софтуера; всички те са лесно откриваеми от квалифициран и опитен екип за тестване.
Самите мутации често са много малки, което позволява на тестера, който мутира кода, да наблюдава как екипът открива тези промени. Значителните промени ще бъдат очевидни дори при бегъл поглед – така че дребните грешки обикновено са най-добрият начин да се уверите, че компанията използва надеждни практики за тестване.
Тази техника разглежда по-специално ефективността на тестовите случаи на екипа; документите, съдържащи информация за тестовете. Екипът може също така да използва софтуер за автоматизация на трети страни за извършване на тези проверки, като в този случай при тестването за мутация се проверява доколко тази платформа може да открива грешки в кода на програмата.
1. Кога трябва да се направи тест за мутации?
Тъй като целта на тестването на мутациите е да се валидират и подобрят текущите проверки за осигуряване на качеството, от съществено значение е екипите да го провеждат в началото на етапа на тестване. Това означава, че ако комплектът за тестване не успее да идентифицира и „убие“ мутантите, има достатъчно време да се направят мащабни промени в процедурите за тестване на организацията.
Тъй като това е изключително гъвкав метод, тестването на мутациите е приложимо за почти всички видове софтуер, включително уеб, мобилни и настолни програми. Това работи най-добре по време на етапа на тестване на единици, при който се изследват най-малките компоненти на приложението.
2. Кога не е необходимо да правите тестове за мутации
Все още има някои сценарии, при които мутацията и общото тестване на „бялата кутия“ не са подходящи за дадена програма; това може да се дължи на различни причини.
Например, ако тестващите имат за цел да проверят само с тестване на черна кутия – в такъв случай те ще се съсредоточат върху front-end за тази сесия или дори върху цялостния етап на тестване.
Има компании, които смятат, че тестването в бялата кутия е досадно и отнема много време, което може да ги накара да пропуснат този процес. Силните, добре проверени тестови случаи могат също така да заобиколят необходимостта от тестване на мутациите, тъй като това показва старанието на екипа и ангажираността му към точните тестови процедури.
3. Кой участва в анализа на мутациите?
В анализа на мутациите участват редица различни роли, включително:
– Тестери на мутации
Те мутират кода, като въвеждат различни дребни дефекти, за да гарантират, че процесът на тестване работи според очакванията. Тези тестери обикновено са вече съществуващи членове на екипа за осигуряване на качеството.
– Тестери на приложения
Те редовно проверяват кода за евентуални проблеми, като идентифицират и коригират всички открити мутации. Те провеждат тестове в бялата кутия, за да открият грешки в кодирането, но използват и други техники.
– Разработчици на приложения
Те проектират функциите на програмата и пишат първоначалния код. Те също така отстраняват всички проблеми, които са открили тестерите, като гарантират, че софтуерът е в стабилно състояние за пускане.
– Ръководители на проекти
Те дават насоки за приложението и могат да работят заедно с тестерите на мутации, за да проверят ефикасността на собствените си екипи. Те гарантират високи стандарти на всеки етап от развитието.
Какво проверяваме с тестовете за мутации?
Тестването с мутации се фокусира повече върху процесите на тестване, вместо върху приложението. За тази цел в него се разглеждат следните въпроси:
1. Тестови случаи
Случаите на тестване са документи, които съдържат подробна информация за всеки тест, включително резултатите, които тестерите очакват от всяка отделна проверка. Последователните и точни тестови казуси дават на членовете на екипа по осигуряване на качеството представа за състоянието на приложението и за това, доколко неговата работа отговаря на очакванията на фирмата.
Информацията в тези тестови случаи може да определи способността на тестера да открива определени дефекти – включително тези, които предизвикват тестовете за мутация.
2. Стандарти за изпитване
Тестовете за мутация изследват отблизо текущите процедури за тестване, за да гарантират, че членовете на екипа могат да идентифицират дори незначителни проблеми, които биха могли да повлияят на възприятието на потребителя за софтуера.
Старанието и компетентността на проверяващите може дори да са основните фактори, които фирмата оценява при тези проверки. Ако не се обръща голямо внимание на детайлите на всеки етап, тестващите могат да пропуснат сериозни мутации, които са налични в програмата.
3. Отделни единици код
Тестовете за мутация са често срещани по време на частта от разработката, свързана с тестването на единици. По този начин се разглеждат отделните компоненти, за да се поддържа силен фокус върху всеки тест, като се оптимизира значително целият процес, като се гарантира, че тестерите работят само със съответните редове код.
Тъй като тестовете за мутации често са в началото на етапа на осигуряване на качеството и могат да бъдат предшественик на пълномащабно тестване, този подход може да увеличи скоростта, без да се прави компромис с точността.
4. Актуализации на програмата
Актуализациите на софтуера обикновено включват рестартиране на тестовия процес, за да се гарантира, че няма нови грешки и че предишни грешки не се появяват отново.
Повтарянето на тестовете за мутация е ключова част от това и помага за насърчаване на последователни стандарти за тестване след големи промени в софтуера.
Екипът по тестване може да смята, че задълбочените проверки след актуализация са ненужни, но мутацията на кода може да гарантира, че те разбират важността на тестването на всеки етап от разработката.
5. Софтуер за автоматизация
Компаниите провеждат и тестване на мутациите, за да проверят своите пакети за автоматизирано тестване и да се уверят, че те са в състояние да забележат мутиралия код, наред с други проблеми.
Ако приложение за тестване от трета страна може да идентифицира външни промени в програмата и евентуално дори да я поправи, това означава, че организацията може да се довери на софтуера за автоматизиране на тестовете.
От съществено значение е фирмите да валидират своя подход за автоматизация; това дава спокойствие на всеки тестер.
6. Стратегия за автоматизация
Начинът, по който компанията интегрира автоматизацията в процесите си, е също толкова важен, колкото и използваният от нея софтуер; например, тя може да реши да приложи хиперавтоматизация. Това позволява на компанията интелигентно да реши кои мутации и софтуерни тестове да автоматизира.
Без силна стратегия за автоматизация, която да отчита огромното разнообразие на кода на приложението, някои тестове могат да бъдат несъвместими с автоматизацията, което ограничава възможностите на платформата.
7. Приложението
Макар че тестването на мутациите се фокусира повече върху екипа за тестване, отколкото върху приложението, то все пак може да подчертае важна информация за тази програма.
Например тестването на мутацията показва как софтуерът реагира на промените в кода, включително дали сигнализира за тези проблеми по начина, по който екипът очаква.
Този подход не е техника за тестване на софтуер, но все пак е в състояние да предложи интересни данни за вътрешните му операции.
Жизнен цикъл на тестовете за мутации
Обичайният жизнен цикъл на тестовете за мутация е следният:
1. Анализ на изискванията
Първата стъпка от жизнения цикъл на мутационното тестване е да се разбере какво точно изисква валидиране и кои части от кода на приложението биха имали най-голяма полза от тези тестове.
Екипът може да разговаря с разработчици и ръководители, за да определи техните опасения и да започне да ги решава.
2. Планиране на тестовете
След това тестващите започват да разработват точните проверки, които възнамеряват да приложат – в този случай мутациите, които ще дадат най-добра представа.
На този етап се определя цялостната стратегия за тестване на мутациите и как екипът ще приложи ефективно планираните мутации на кода.
3. Разработване на тестови случаи
Тестването на мутации включва отделна документация за тестовете, включително информация за мутиралия код и начина, по който се очаква тестерите да отстранят проблема.
Доброто водене на записите гарантира, че всички тестове се провеждат по план, и може да помогне на екипа да запази ангажимента си към високите стандарти за тестване.
4. Настройка на тестовата среда
Тестерите се уверяват, че приложението е готово за промени и че разполагат с процедура за справяне с тези проблеми, ако другите членове на екипа не могат да ги открият.
В рамките на тази дейност тестващите мутации създават тестов сървър и го използват като платно за своите мутации.
5. Изпълнение на теста
След като приключат с подготовката, тестерите променят кода на няколко компонента на приложението; след това изчакват другите тестери да забележат и отстранят проблемите.
Както тестерите на мутации, така и тестерите на приложения трябва да документират това подробно, за да са сигурни, че записите им са надеждни.
6. Приключване на тестовия цикъл
След приключване на тестването тестерите на мутации проверяват повторно дали всички направени от тях промени са поправени от тестерите на приложения или от тях самите.
След това те приключват цикъла на тестване и анализират резултатите, като обсъждат начина, по който тестващите са реагирали на различните грешки, както и способността им да ги коригират.
7. Повтаряне на теста
След затваряне на тестовия цикъл може да се наложи той да бъде активиран отново след бъдещи актуализации на софтуера.
Всяка промяна в дадено приложение променя по някакъв начин неговата функционалност, което води до нови възможности, които екипът трябва да отчете, за да гарантира, че процесът на тестване е достатъчно щателен.
Предимства на изследването на мутации
Провеждането на тестове за мутации има много предимства, включително:
1. Утвърждава процеса на тестване
Основната полза от тестването на мутациите е способността му да покаже как тестерите на компанията подхождат към софтуера – и способността им да разпознават проблеми с кодирането. Това също така гарантира, че тестовите случаи на екипа са достатъчно изчерпателни и обхващат всички необходими тестове.
Тестовете за мутация проверяват цялостната процедура за тестване на организацията, за да гарантират, че тя работи според очакванията.
2. Осигурява силна автоматизация
Тестването на мутации помага на екипа да провери дали платформата за автоматизация на тестове на трета страна е в състояние да идентифицира адекватно грешките в кода и да ги отстрани по правилния начин.
Ако софтуерът не успее да ги открие дори след необходимото калибриране, може би си струва да смените платформата с такава, която лесно преминава тези тестове.
3. Добро покритие
Всеки процес на тестване на софтуер трябва да може да обхване широко цялото приложение, за да се гарантира, че всеки аспект получава необходимото ниво на внимание.
Тестовете за мутация могат да променят всяка част от кода на програмата; доброто изпълнение позволява на тези тестове да обхванат всяка основна функция. Това учи тестерите да търсят проблеми в цялото приложение.
4. Разглеждане на изходния код
Тъй като тестването чрез мутация включва работа с кода и извършване на директни промени, когато е необходимо, този метод може да наблегне и на неоптимизираните скриптове в приложението.
Софтуерните тестери могат да разрешат програмата и да проведат обичайния си кръг от тестове само ако кодът на софтуера е адекватен; тези проверки позволяват на тестерите да подчертаят потенциални бъдещи проблеми.
5. Води до по-добър софтуер
Тестването на мутации помага да се уверите, че процесите на тестване на приложението отговарят на изискванията на програмата.
Ако анализът на мутациите разкрие, че екипът за осигуряване на качеството не следва правилните процедури или тестовите случаи са неподходящи, тестерите могат да работят за подобряване на това. Без тази надлежна проверка организацията може да пусне дефектен продукт, без да разбере това.
6. Ефективен за различни езици
Независимо от езика, който екипът за тестване използва за своето приложение, съществуват софтуерни опции, които могат да предложат висококачествен анализ на мутациите.
Това включва редица специфични за езика функции за качество на живот, които оптимизират проверките за по-голяма надеждност. Индивидуалният подход към различните езици повишава качеството на всеки отделен тест.
7. Високодостъпни инструменти
Много от най-добрите платформи за мутации са с отворен код, което означава, че предлагат повече възможности за персонализация и широк набор от функции безплатно или на драстично по-ниски цени.
С по-малко пречки в сравнение с много други форми на тестване, мутацията на кода е полезен и удобен начин за предприятията да оценят или дори да подобрят своя подход за осигуряване на качеството.
Предизвикателства при тестването на мутации
Този процес е свързан и с множество предизвикателства, като например:
1. Изисква познания по програмиране
За да могат тестерите да извършат тези проверки, те трябва да имат цялостно разбиране на програмата и кода, което затруднява участието на по-малко опитните тестери.
Фирмата може да тества софтуер само по начини, които отговарят на съществуващите умения на тестерите, по-специално на способността им да редактират приложение и да създават поправими грешки в кодирането.
2. Не е подходящ за тестване на черна кутия
Тестването в черна кутия включва основно разглеждане на предната част на приложението, без да се проверяват вътрешните му механизми и код – това е на практика несъвместимо с тестването чрез мутация.
В резултат на това тези проверки са полезни само за някои тестове в сравнение с други методи, много от които могат да предложат много по-голямо покритие на целия етап на тестване.
3. Проектирането на тестове за мутации отнема много време
Мутацията на кода може да бъде досаден процес, тъй като екипът трябва да намери отделни компоненти, които си струва да бъдат мутирани. Самото вземане на решение кои мутации да се въведат може да отнеме много време; това може да бъде проблематично, когато други видове тестване на практика изчакват тези проверки, за да потвърдят напълно подхода на компанията за тестване.
4. Може да изисква много мутации на кода
По подобен начин сложните проекти естествено изискват по-голям брой мутанти, за да се осигури цялостен подход за тестване. Това увеличава времето за етапа на мутация и може да включва много ръчни промени в кода на приложението.
Без висококачествен софтуер за автоматизация на тестването с възможности за мутация на програмите това може да се окаже трудно за успешното изпълнение от страна на тестерите.
5. Тестерите може да не забележат грешки
Най-голямото притеснение, което изпитващите мутации и ръководителите на проекти често изпитват при прилагането на тези проверки, е възможността изпитващите софтуера (ръчни или автоматизирани) просто да не забележат проблемите.
Това може да изисква цялостно преразглеждане на процедурите за тестване на фирмата, въпреки че това може да предостави на тестващите важна информация за стандартите за осигуряване на качеството.
6. Могат да изискват много памет
Тестването на мутации обикновено изисква голяма изчислителна мощ, въпреки че това може да зависи от приложението, което използват тестерите.
Ако организацията разполага с ограничен брой машини или тези устройства имат ниски спецификации, те могат да се затруднят да изпълняват твърде много едновременни мутации. Това се отразява на броя на проверките, които могат да се извършат преди края на етапа на тестване.
7. Докладите могат да са с много информация
Въпреки че това зависи главно от интерфейса на инструмента за тестване на мутации на екипа, генерираните от него отчети могат да бъдат трудни за анализиране.
Това означава, че е необходимо време, за да се сортират ръчно и да се намерят правилните резултати от тестовете; някои програми позволяват на потребителите да персонализират действителния процес на отчитане; това варира в различните приложения.
Характеристики на тестовете за мутации
Основните характеристики на ефективните тестове за мутации са:
1. Изчерпателен
Тези проверки обхващат всеки основен аспект на софтуера; компаниите с достатъчно ресурси могат дори да разработят тест за мутация за всеки обикновен тестов случай.
Въпреки че точният брой зависи от възможностите и предпочитанията на организацията, ефективните тестове за мутация обхващат широк спектър от кодирани функции.
2. Стратегически
Мутациите на програми също трябва да следват ясна и добре планирана структура, която улеснява общите цели на организацията за тестване.
Например грешките, които те произвеждат, могат да се доближават до реалистични неуспешни тестове, което позволява на тестерите да предвидят тези проблеми, ако те възникнат по естествен начин, което значително подобрява процеса на тестване на фирмата.
3. Конструктивен
Целта на мутационното тестване е да се идентифицират недостатъците в тестването – да се покаже как екипът може да подобри проверките си и да отстрани дребни грешки, когато те се появят.
Тестерите на мутации трябва да дават приоритет на „невалидните“ мутации, които засягат функционалността на софтуера, което позволява по-ясни подобрения в тестването на целия проект.
4. Превантивен
Тези проверки съществуват, за да потвърдят цялостната стратегия на екипа; това означава, че тестването на мутациите работи по-добре в ранните етапи на разработката.
Ако тестерите забележат някакви съществени пропуски в подхода си за осигуряване на качеството, това им дава необходимото време да променят тестовите си случаи, за да се уверят, че те са адекватни.
5. Последователен
Тестването на мутации в различни итерации на приложението трябва да дава последователни резултати, като същевременно се добавят повече проверки, за да се адаптират към промените в софтуера.
Следващите проверки трябва да включват същото внимание към детайлите, за да се запази тяхната ефективност – без тази прецизност тестовете за мутация могат да станат по-малко точни.
6. Фина
Тестовете за мутация имат за цел да проверят способността на екипа за осигуряване на качеството да идентифицира дефекти в кода чрез своите тестове и платформи на трети страни.
Това означава, че тестовете не трябва да са непосредствено очевидни за всеки, който проверява софтуера; целта е да се проучи как тестващите реагират на незначителни проблеми в кода.
7. Сътрудничество
Както при всяко софтуерно изпитване, мутацията на кода е процес, който обикновено изисква работа в екип и комуникация, за да се гарантира успехът му. Поддържането на атмосфера на сътрудничество помага да се избегнат информационните прегради, които могат да доведат до неразбирателство – това също така гарантира, че всеки тестер ще остане фокусиран върху текущите задачи.
Видове тестове за мутации
Трите основни вида тестове за мутации са:
1. Мутация на стойности
Стойностните мутации директно променят стойностите в кода, като променят едно число или буква с друго по начин, който влияе на функционалността на приложението.
Например тестерът може да промени точните параметри на програмата, като например числата, на които тя реагира. Тестерите на мутации могат да се насочат специално към константните стойности на софтуера, тъй като те винаги остават същите по време на нормална работа.
2. Мутация на решения
Мутациите за вземане на решения модифицират аритметичните и логическите оператори, като ефективно променят начина, по който приложението реагира на конкретни ситуации.
Например смяната на оператор по-голямо от (>) с оператор по-малко от (<) естествено се отразява на изхода на програмата. Тестерите могат също така да заменят „или“ с „и“ или обратно, като по този начин променят из основи софтуера и начина, по който той интерпретира информацията, предоставена от други тестери и евентуални потребители.
3. Мутация на твърденията
Мутациите на изявленията променят действителните изявления на кода, като променят правилата, които приложението използва, за да взема решения. Тестващите могат да променят съдържанието на тези редове, да ги дублират или дори да ги изтрият, за да проверят как мутиралата програма влияе на функционалността на софтуера.
Тези мутации променят градивните елементи на програмата, като могат да премахнат цели функции или по друг начин да попречат на работата им.
Изясняване на някои неясноти
– Тестване на мутации срещу тестване на регресия
Тестването с мутация и регресия са полезни подходи за тестване на софтуер – разбирането на всяка от тези техники може да подобри цялостното осигуряване на качеството в компанията.
1. Какво представлява регресионното тестване?
Тестването на регресия е, когато тестерите проверяват софтуера между различните итерации, за да се уверят, че той продължава да функционира въпреки промените в кода.
Дори малки промени могат да доведат до сериозни проблеми без тези проверки, което може да доведе до повторна поява на предишни грешки. Това обикновено изисква автоматизация поради сложния характер на повторното тестване на всеки компонент; много компании се отказват от регресионните тестове по тази причина.
Изпитателите могат да извършват тези проверки на отделни единици, отделни компоненти или на целия продукт – точните необходими тестове зависят главно от проекта и неговия мащаб.
2. Каква е разликата между тестовете за мутация и регресия?
Тестването за регресия се фокусира предимно върху проверката на програмата и нейната функционалност, докато мутацията на кода вместо това разглежда начина, по който тестерите реагират на проблемите.
Първата също се извършва в голяма степен след множество итерации на програмата, докато проверките за мутация могат да бъдат на всеки етап от разработката, макар че обикновено са в началото на фазата на тестване.
Както тестовете за регресия, така и тестовете за мутация могат да се занимават с отделни единици код и с това как малки промени могат да доведат до значителни проблеми, които тестерите трябва да отстранят.
3. Заключение: Тестване на мутации срещу автоматизирано тестване
Автоматизацията често е ключова част от тестването на мутации поради огромния брой проверки и единици – това понякога я прави жизненоважна за успешния и цялостен процес на тестване.
Компаниите обикновено използват мутации на кода, за да проверят своята платформа за автоматизация от трета страна и доколко добре тя идентифицира проблемните скриптове.
Комбинирането на задълбочен каталог от проверки за мутации с автоматизиран софтуер може значително да увеличи обхвата на фирмата и да гарантира по-добри резултати.
Въпреки че това са две отделни практики за тестване, не е необходимо те да се противопоставят една на друга. Интегрирането на автоматизация на роботизирани процеси например може да подобри стратегията на компанията за тестване на мутации.
Какво ви е необходимо, за да започнете да използвате Mutation Testing в софтуерното инженерство?
Обичайните изисквания за цялостно изследване на мутациите включват:
1. Ясна стратегия за тестване
Екипът за тестване трябва да създаде стратегия за тестване на мутациите, включително кои компоненти и единици са най-важни за изследване.
Например някои аспекти на кода може да са по-съществени за успеха и функционалността на приложението; тестерите трябва да се уверят, че има достатъчно мутации, за да се съобразят с това.
Графикът за тестване на мутациите на компанията също е от съществено значение, тъй като гарантира, че тестерите имат достатъчно време да изследват кода.
2. Без разширяване на обхвата
Дори при наличието на задълбочена стратегия, която определя подхода на компанията към тестването на мутации, е възможно броят на тестовете да е значително по-голям от необходимото.
Ефективността е от първостепенно значение по време на тази процедура, особено като се има предвид, че други етапи на тестване могат да чакат екипа да открие и унищожи мутациите. Тестерите трябва ясно да определят обхвата си, преди да започнат да променят кода; така се гарантира, че всичко ще може да бъде управлявано в рамките на практическия срок.
3. Строга документация
Всеки процес на тестване има полза от пълна документация – често под формата на тестови случаи, в които подробно са описани отделните проверки и всички съответни мутанти.
Това илюстрира текущия напредък на екипа по време на тестовете, което е особено полезно за мениджъри и ръководители. Документирането на всяка мутация на кода също така помага на тестерите да поддържат ясни записи за промените, които правят.
Ако екипът за осигуряване на качеството се затруднява да открие тези мутации по време на тестването, тези документи ефективно служат като ключ за отговор.
4. Квалифицирани тестери
Тестерите, които мутират кода, трябва да познават добре софтуера – включително многото начини, по които могат да го мутират или дори да го разрушат.
Тестерите на мутации знаят приблизително как техните промени ще се отразят на приложението и как другите членове на екипа за осигуряване на качеството биха могли да идентифицират мутиралия код.
Това обикновено изисква добро ниво на познания по програмиране. За да бъде ефективен анализът на мутациите, тестерите на софтуера също трябва да имат добре развити умения и опит в тестването.
5. Софтуер за автоматизация
Софтуерът за автоматизация на трета страна може да се окаже необходимост преди тестването на мутации поради броя на проверките, които този процес често изисква. Това е особено вярно за сложни приложения с повече код и функции, които екипът за осигуряване на качеството трябва да провери.
Компаниите могат да въведат тези проверки специално, за да проверят как софтуерът за автоматизация реагира на грешки в кодирането. Това може да бъде основна част от процеса на изпитване на фирмата, за да се реши кои програми са най-полезни.
Процес на тестване на мутации
Обичайните стъпки, които тестващите обикновено следват, когато извършват анализ на мутациите, са:
1. Подготовка на тестовете
Подготовката е първата стъпка от всеки процес на тестване. Това включва договаряне на точните проверки, които трябва да се приложат, и получаване на необходимото одобрение – например от ръководството на компанията и заинтересованите страни.
Тестерите трябва да разработят тези проверки по начин, който да е съобразен с графика на проекта и същевременно да обхваща всички основни компоненти. Планирането от страна на екипа може да определи ефективността на мутациите на кода.
2. Въвеждане на мутанти и дефекти
След приключване на подготовката екипът по тестване започва да променя кода, като го мутира в съответствие с плана си за въвеждане на конкретни грешки. Тези грешки трябва да бъдат сравнително малки, тъй като това позволява на тестващите да оценят способността на останалите членове на екипа да идентифицират проблеми с кодирането.
Незначителните грешки могат също така да помогнат на организацията да провери чувствителността на софтуера за автоматизация на трети страни.
3. Прилагане на тестовите случаи
Тестовите случаи трябва да отчитат всички възможни точки на отказ в приложението – това може да изисква пренаписване, ако мутиралата програма е в състояние да функционира без никакви грешки.
Случаите за тестване на дадена програма представляват пълната гама от проверки, които тестерите извършват; всеки от тях трябва да помогне на тестерите да открият скрити мутации и да бъде неразделна част от използваемостта на приложението.
4. Сравнете резултатите
След като добави мутационни грешки към програмата и приложи тестовите случаи на екипа, екипът трябва да сравни резултатите от оригиналната и мутиралата програма.
Надеждата е, че за всяка успешна проверка в оригинала ще има и грешка в мутиралото приложение. Това показва способностите както на тестерите, така и на използваните от тях инструменти.
5. Действайте върху различни резултати
Ако има различни изходи между оригиналната и мутиралата програма, както очакват тестерите, това означава, че тестовият случай може успешно да убие мутанта, като демонстрира неговото наличие.
След това тестващите могат да продължат с увереност в своята методология и способността си да идентифицират проблеми с кодирането. За тези конкретни тестове не са необходими промени в тестовите случаи.
6. Смяна на калъфите, ако е необходимо
Някои мутации на кода могат да доведат до идентични заключения в различните програми, което предполага, че тестовите случаи не са в състояние успешно да откроят всички възможни грешки в приложението.
В тези случаи мутантът остава „жив“ и може да продължи да влияе на софтуера по начини, които тестерите нямат възможност да адресират – това води до създаването на по-добри тестови случаи.
Как се създават мутирали програми
Мутиралите програми на практика са идентични с оригиналните програми, с изключение на една малка промяна, която може да повлияе на функционалността на приложението по малък, но забележим начин.
Изчерпателните и подробни тестови случаи помагат на тестера или на софтуерния пакет да установи тези промени и произтичащите от тях грешки. Всеки случай, който компанията проверява, изисква както оригинална, така и променена програма, показваща ефектите от всяка промяна поотделно.
Програмите обикновено възпроизвеждат реалистични грешки, като например грешки при кодиране. Също така е важно тестерите да избягват „мъртвородени“ мутанти, които пречат на приложението да се изпълни – това е твърде очевидно за тестерите.
Какво да се промени в мутиралата програма?
Както и при много други променливи за тестване на софтуер, точните промени, които тестерите правят, зависят от приложението и неговия код.
Съществуват три категории, които обхващат по-голямата част от тестовете за мутация: операнди, изрази и оператори. Промяната на някоя от тях може да създаде ефективна мутирала програма – показвайки как различните стойности или правила влияят на самата логика, която програмата използва.
Тези категории са свързани с трите основни вида мутации, които тестерите изследват; това са съответно мутации на решения, стойности и твърдения. Промените трябва да са незначителни и да не възпрепятстват изцяло изпълнението на теста.
Най-добри практики за изследване на мутации
При провеждане на тестване на мутации в контекста на софтуерното тестване има някои практики, които си струва да се следват и които гарантират добри резултати, като например:
1. Максимизиране на резултата от мутацията
Резултатът от мутациите на програмата е процентът на мутантите, които екипът или приложението могат успешно да идентифицират или „убият“.
Например, ако в един кръг от тестването на мутациите има 40 мутанта и тестерите открият 36, резултатът от мутациите е 90% – целта на екипа винаги е да осигури резултат от 100%.
2. Изберете мутанти на случаен принцип
Макар че това може да помогне да се приоритизират определени компоненти и да се тестват по-задълбочено, също така е полезно за тестерите да избират на случаен принцип кои мутанти да добавят – особено в кратък срок.
Докато тези проверки представят всички значими видове мутации, екипът за осигуряване на качеството може да валидира цялостната си стратегия за тестване на софтуер.
3. Направете малки промени
Мутациите на кода трябва да представляват незначителни отклонения от оригиналната програма, тъй като това показва колко вероятно е тестерът да идентифицира определени грешки; незначителните проблеми с кодирането също така показват колко чувствителен е техният софтуер.
Изключително важно е специалистите по тестване на мутации да намерят баланса, който позволява тези малки промени да предизвикват забележими грешки.
4. Една мутация на програма
Тестването с мутация разглежда отделни тестови случаи поотделно, за да провери доколко изчерпателни са те. За да помогнем за това, всяка мутирала програма трябва да има само една промяна в сравнение с оригинала.
Програмите с множество мутации може да не са в състояние да се съчетаят ефективно с тестови случаи; мутациите могат да си противоречат една на друга.
5. Внимателно разгледайте софтуера за автоматизация
Компаниите често използват мутацията на кода, за да валидират използването на софтуера за автоматизация от екипа и да се уверят, че той е в състояние да идентифицира грешките толкова ефективно, колкото и човекът тестер.
Това означава, че изборът на подходяща платформа за автоматизация може да бъде важен фактор, както и възможността за интегриране на автоматизация на роботизирани процеси.
6. Използване на разработка, базирана на тестове
Разработката, базирана на тестове (Test-driven development – TDD), се отнася до специфична техника, която взема предвид изискванията за тестване на всеки етап от разработката.
Това помага да се гарантира, че тестовите случаи са напълно съвместими със софтуера – позволявайки му лесно да премине през тестовете за мутация и да направи по-добра програма, която се синхронизира с процесите за осигуряване на качеството.
Видове резултати от тест за мутация
Тестовете за мутации генерират няколко резултата, включително:
1. Мутирала програма
Мутиралите програми са естествен резултат от тези проверки; тестерите ги създават, за да отразят текущите си тестови случаи и проблемите, които те помагат да се открият. Обикновено програмите се отклоняват от оригиналния си аналог само по един незначителен, но съществен начин, за да се гарантира по-голяма надеждност.
2. Жив или мъртъв мутант
След тестовете мутацията или се „убива“, или остава „жива“ – това просто се отнася до това дали тестерът (или неговият софтуер) успешно идентифицира проблем с кодирането, или не.
Ако мутантът остане жив, тестовите случаи може да се нуждаят от сериозни промени.
3. Тестови случай на мутация
Екипът за осигуряване на качеството използва отделни тестови случаи, специфични за мутациите, които регистрират информация за своите мутантни програми.
Това помага да се гарантира, че екипът разполага с изчерпателна документация за всяка проверка; тези документи включват подробности за мутациите и тяхното въздействие върху програмата.
4. Оценка на мутациите
Крайната цел на всеки тест за мутация е да се постигне резултат от 100% мутация, като процедурите за тестване на компанията успешно откриват и унищожават всеки мутант. Всичко, което е по-малко от това, предполага, че техните тестови случаи и общи процеси се нуждаят от подобрение, за да се идентифицира проблемният код.
Примери за тестване на мутации
Ето три примера за изследване на мутации:
1. Пример за мутация на стойност
Мутациите на стойности включват промяна на константа или параметър, които могат да променят границите на програмата. Например софтуерът на автоматичната касова машина може да използва теглото на даден хранителен продукт, за да определи цената му.
Тестващите могат да мутират кода на тази програма, за да променят параметрите на теглото и да оскъпят значително храната за всеки унция или килограм. Тестерът или тестовата платформа трябва да могат да идентифицират ефектите на различните стойности върху тази програма.
Тъй като тази грешка променя една от основните функции на софтуера, тестовите случаи трябва да забележат тази грешка и да предупредят екипа.
2. Пример за мутация на решение
Мутациите на решенията включват промяна на аритметичен или логически оператор, обръщане или друга промяна на начина, по който това приложение реагира на потребителския вход. Ако се върнем към примера със самообслужването, тези машини могат да маркират артикул с неочаквано високо тегло, което може да се дължи на грешка на потребителя.
Кодът на машината би могъл да направи това чрез решение „if (a>b)“ – като „b“ отразява очакваното тегло, а „a“ съответства на действителното тегло. Екипът може да промени това в „if (a≤b)“, което променя начина, по който реагира касата; тя ще маркира елемента дори при очакваното тегло.
3. Пример за мутация на изявление
Мутациите на декларациите включват промяна на правило или изход – това може да включва дори пълно изтриване на декларациите от приложението. Тези мутации могат да бъдат по-забележими от други, в зависимост от честотата на конкретното изявление; жизненоважно е тестващите да изберат изявлението разумно.
Например машината за самообслужване може да покаже предупреждение, ако потребителят се опита да закупи артикул с възрастово ограничение. Без съответното изявление машината може да се срине или да позволи на всеки клиент да закупи какъвто и да е артикул.
Като променят твърдението и го посочат на екипа, тестерите могат да проверят дали техният подход е съобразен с тези проблеми.
Видове грешки и недостатъци, открити чрез тестване на мутации
Тестовете за мутация разкриват основно проблеми в самия процес на тестване. Предвид това, ето редица проблеми, които тези проверки могат да помогнат да се идентифицират:
1. Неясни тестови случаи
Ако анализът на мутациите разкрие нисък резултат на мутация (или дори резултат под 100%), това означава, че тестовите случаи на екипа не са в състояние да отчетат всички възможни грешки, които могат да засегнат приложението.
Възможно е те да не са достатъчно конкретни или широки, за да отговарят на изискванията на екипа. Тези документи трябва да обхващат всички възможности, с които екипът може да се сблъска по време на тестването на софтуера, за да се гарантира неговата надеждност.
2. Необучен екип за тестване
Тестовете за мутации могат също така да илюстрират способностите на екипа, включително доколко добре той лично идентифицира мутациите и други дефекти. Ако те не могат да открият мутантите в програмите въпреки ясните и подробни тестови случаи, това може да се дължи на това, че тестващите не са приложили тези случаи правилно.
Мутиралите програми могат да показват проблеми по време на целия процес на тестване – това може да включва и неквалифицирани или необучени тестери.
3. Неподходящ софтуер за тестване
Ако компанията използва тези проверки за проверка на собствената си платформа за тестване, може да се окаже, че софтуерът не може точно да идентифицира или унищожи мутиралия код.
Фирмата може да реагира, като проучи други варианти, докато не намери съвместим с тестовите си случаи. Ако софтуерът за автоматизация не успее да открие проблемния код, той вероятно ще се затрудни да идентифицира други проблеми, които засягат софтуера.
4. Неоптимизиран код
Тестването на мутации може да разкрие проблеми, които вече са налични в софтуера. Например, тестерите могат да се опитат да променят кода, но сами да открият критични дефекти.
Това е още една важна перспектива на програмата, която показва, че мутацията на кода носи ползи и извън процеса на тестване. Колкото повече тестери разглеждат този код, толкова повече проблеми може да открие и отстрани екипът по време на етапа на тестване.
Обща метрика на теста за мутация
Основните показатели, които се използват в тестовете за мутации, включват:
1. Убити мутанти
Това се отнася до броя на мутантите, които тестерите или софтуерът са успели да идентифицират, като са отбелязали тяхното съществуване, за да гарантират, че персоналът може да открие такива дребни грешки.
Количеството мутанти, които тестерите убиват, зависи от силата на техните тестови случаи.
2. Живи мутанти
Живите мутанти са тези, които тестерът или софтуерът не успяват да идентифицират – това показва всички пропуски, които може да съществуват в стратегията на екипа за осигуряване на качеството. Ако това се случи, проверяващите трябва да пренастроят процеса и тестовите случаи, за да се съобразят с тези мутанти, и да ги унищожат при бъдещи проверки.
3. Валидни мутанти
Този показател определя количеството мутации, които програмата е успяла да включи успешно, без да се получи грешка при изпълнение, която да анулира теста и неговата ефективност.
Валидните мутации са тези, които тестерът и софтуерът за автоматизация могат да изследват; това се дължи на факта, че мутациите са сравнително малки.
4. Невалидни мутанти
Значителните мутации могат да повлияят на приложението дотолкова, че да направят тестването непрактично или дори невъзможно – затова е полезно да се проследи колко „невалидни“ мутации има в мутиралата програма.
Идентифицирането им позволява на проверяващите да ги редактират или дори да ги премахнат, за да се гарантира, че проверките включват само валидни мутации.
5. Общо мутанти
Броят на мутациите, независимо от тяхната валидност, е друг показател, който тестващите следят; това им позволява да наблюдават мутантите и да записват тяхното състояние.
Тъй като всяка мутация обикновено включва отделен тест, общият брой служи и за отчитане на броя на общите мутации на кода.
6. Оценка на мутациите
Най-полезната метрика за анализ на мутациите обикновено е резултатът от мутацията, който на практика представлява процентът на валидните мутации, които тестерът или пакетът за автоматизация е успял да открие.
Всичко, което е по-малко от 100%, може да е признак за неправилни процедури за изпитване.
7 грешки и капани при прилагането на мутантни тестове
Тестването на мутации е сложен процес, който компаниите трябва да прилагат разумно, за да избегнат сериозни проблеми или грешки. Ето седем капана, които тестващите трябва да избягват при провеждането на тестове за мутации:
1. Неправилно мащабиране на мутациите
Мащабът е важно съображение при анализа на мутациите, тъй като този процес съществува, за да гарантира, че тестващите идентифицират незначителни грешки в приложението. Ако мутацията е твърде очевидна за тестерите, това може да не е ефективен начин за проверка на способността им да забелязват или да противодействат на софтуерни проблеми.
2. Невалидни или живи мутации
Дори и в правилния мащаб, много мутации предлагат само ограничена ефективност – например, ако не водят до грешка или водят до проблем, който спира работата на приложението.
Тестерите трябва да имат предвид как всяка промяна в кода може да повлияе на целия софтуер.
3. Несъвместими тестови случаи
Случаите за тестване и мутациите трябва да се съчетават перфектно, за да се осигури последователно и хармонично тестване. При вземането на решение кои мутации да се добавят или дори при проектирането на първоначалните тестови случаи екипът за осигуряване на качеството може да работи, за да гарантира, че те си пасват и водят до по-плавно тестване като цяло.
4. Крайни срокове и графици
Етапите на тестване са с различна продължителност, но винаги трябва да се съобразяват с вътрешните срокове на компанията. Фирмите, които не успеят да планират правилно своите тестове за мутации, може да не успеят да приключат процеса навреме.
Преди проектът да достигне етапа на тестване, екипът трябва да се увери, че графикът за тестване е достатъчно изчерпателен.
5. Неадекватно покритие на тестовете
Предприятията могат да изберат да прилагат своите мутации на кодекси на случаен принцип, но все пак е важно те да обхващат широк кръг от въпроси.
За да са сигурни, че и тестерите, и софтуерът могат да открият всички видове мутации, проверките трябва да включват най-малко няколко мутации на стойности, решения и твърдения.
6. Използване на мутанти за тестване на софтуера
Въпреки че тестването на мутации предлага нова перспектива за приложението, екипите трябва да използват този метод само за проверка на собствения си процес на тестване. Компанията трябва да разбере точните възможности и ограничения на тестването на мутации; тази техника може да бъде успешна само заедно с други проверки на софтуера.
7. Твърде много мутанти
От първостепенно значение е компаниите да осигурят широко покритие на тестовете, но в този процес те могат да внедрят твърде много мутанти. Всяка програма за мутация изисква значително количество изчислителна мощност – това ограничава броя на програмите, които една организация може да провежда едновременно.
Извършването на твърде много мутации може също така да затрудни спазването на крайните срокове за тестване.
Контролен списък, съвети и трикове за тестване на мутации
Съществуват редица допълнителни съвети, които биха могли да помогнат на всеки екип да подобри успеха на процеса на тестване на мутации, като например:
1. Проверка на съвместимостта на езика за програмиране
Както безплатните, така и платените инструменти за тестване на мутации обикновено са специализирани в един език за кодиране, поради което е важно тестерите да изберат инструмент, който е съвместим с приложението и платформата за тестване на софтуер.
Екипът за тестване трябва да проучи много възможности, за да се увери, че използва програма, която отговаря на бюджета му, както и на предпочитания от него език за кодиране.
2. Разумно разпределение на тестовете
Различните членове на екипа за тестване вероятно ще разгледат различни аспекти на приложението, което обикновено е свързано с техните силни и слаби страни и общ опит.
Когато екипът възлага тестове за мутация на всеки тестер, той трябва да има предвид това, за да получи представа за тяхната компетентност; това показва колко добре ще протекат по-нататъшните тестове.
3. Избирайте внимателно грешките
Ако в някоя от последните итерации на софтуера е имало грешка, свързана с дадена стойност или твърдение, може да е полезно да се повтори това и да се проучи как реагира екипът или програмата.
Това помага да се гарантира дълготрайността на приложението и илюстрира способността на екипа да забележи предишни грешки, ако те се повторят – това е ключов компонент на регресионното тестване.
4. Максимално увеличаване на изчислителната мощност
Тъй като проверките за мутация могат да изискват много изчислителна мощност, това помага да се използва максимално хардуерът на компанията.
Например, ако някои машини имат по-силни спецификации, може да е полезно да стартирате мутантите на тези устройства. Това позволява на фирмата да избегне значителни забавяния, до които биха довели по-бавните машини.
5. Не отхвърляйте живите мутации
Дори и при строг график, тестерите трябва да се стремят да променят и разширяват тестовите си казуси, за да се борят с всички мутанти, които оцелеят в процеса.
Въпреки че тези грешки може да не изглеждат значителни, ако софтуерът или тестерът не ги открие, те все пак представляват неуспех на тестовите случаи да идентифицират всички проблеми с кодирането.
6. Проучване на нов софтуер за автоматизация
Ако тестовите случаи на екипа са достатъчно подробни, но автоматизираният пакет за тестване не може да ги използва успешно за идентифициране на всяка мутация, може да се възползва от друг софтуер.
Съществуват много безплатни и платени платформи и компаниите трябва да проверят всички възможности, за да се уверят, че разполагат със софтуера, който най-добре отговаря на техните тестови случаи в дългосрочен план.
7. Синхронизиране на всеки процес на тестване
Сътрудничеството е основен компонент на всяка стратегия за тестване – то помага да се гарантира, че всеки процес може лесно да се съчетае, както екипът възнамерява.
Например екипът по тестване може да разработи тестовите си случаи с оглед на мутацията, за да осигури по-високо ниво на съвместимост, което ще улесни тестващите при валидирането на тяхната стратегия.
8. Използване на тестване на единици
Тестването на единици позволява на екипа за осигуряване на качеството да проверява отделни части от кода, което значително оптимизира тестовете и улеснява екипите при идентифицирането на проблеми.
Тази комбинация може да бъде особено полезна, ако тестерите се притесняват за крайните срокове, като им дава възможност да опростят проверките си и да подобрят цялостното покритие – което води до много по-силни софтуерни тестове.
9. Написване на подробни тестови случаи
Случаите за тестване на мутации трябва да съдържат адекватна информация за мутацията и нейния ефект върху програмата, както и за това как екипът за тестване или платформата са открили тези грешки.
Предоставяйки възможно най-много подробности, тестерът може лично да валидира тестовия случай и да се увери, че екипът знае как точно да осигури безпроблемно тестване.
5 най-добри инструмента за тестване на мутации
Налице е широка гама от инструменти, които могат да помогнат на компаниите да изпълнят изискванията си за тестване на мутации. Както често се случва с приложенията за тестване на софтуер, цените и функциите варират в различните платформи, поради което е жизненоважно организациите да изберат тази, която най-добре отговаря на техните нужди.
Някои от тези програми могат да предлагат безплатни аналози или да са изцяло с отворен код; въпреки че обикновено е необходимо да се плати за по-голямо удобство.
Имайки предвид това, ето петте най-добри инструмента за изследване на мутации.
1. Stryker
Stryker е специализирана в мутациите на JavaScript, като значително оптимизира този процес, за да гарантира липсата на фалшиви положителни резултати и да намали общото количество усилия, които иначе тестерите трябва да положат за всички проверки за мутации.
Платформата на Stryker интелигентно оценява софтуера и използва събраната информация, за да открие низовете или сегментите от кода, които биха имали полза от мутация. Това приложение е снабдено с репортер с ясен текст, който извежда резюме на мутанта, включително дали Страйкър е успял да го убие.
2. PITest
PITest е много популярен избор в целия свят поради способността си да променя байтовия код на Java и да прави хиляди мутации в секунда. Това приложение използва данни за покритието на тестовите случаи, за да научи незабавно кои тестове могат да убият мутант.
Той изпълнява само тестовете, за които знае, че ще бъдат подходящи, като по този начин ограничава изчислителната мощност, която тази процедура обикновено консумира. PITest също така е съвместим с повечето форми на плъгина за тестване на единици Surefire, но може да има проблеми с ефективното управление на зависимостите на тестовите поръчки.
3. Застраховка++
Insure++ разполага с много възможности за тестване, включително анализ на мутациите, което позволява на платформата да открива двусмислици в дадена програма. В отклонение от конвенционалното тестване на мутации Insure++ се отказва от генерирането на дефектни мутанти и вместо това създава функционално еквивалентни мутации, които съответстват на изходния код на проекта.
Това се прави, за да се избегнат имплицитни допускания, които могат неволно да ограничат процеса на тестване и да не отразяват реалистична среда за тестване. Както подсказва името, платформата е съвместима основно с програми на C++ и всяка функция е съобразена с този език.
4. Jumble
Това приложение е специализирано в рамката JUnit JavaScript, с подробни визуални индикатори за това как кодът реагира на анализа на мутациите. Jumble е платформа с отворен код и работи в байтовия код на Java приложенията, за да намали времето за всеки цикъл на тестване.
Подобни приложения, които използват изключително изходния код на програмата, понякога могат да отнемат повече време за извършване на тези проверки поради процеса на прекомпилиране.
Jumble също така използва евристични методи, за да оптимизира още повече тестването с мутация, което улеснява последващите тестове.
5. MutPy
MutPy поддържа тестове за мутации за приложения, базирани на Python, като предлага пълна поддръжка на мутации от висок порядък, както и цялостен анализ на покритието. Интерфейсът на тази програма е лесен за използване по време на етапа на извеждане, който ясно показва на потребителите всеки съществен детайл от тестовете за мутация на екипа.
MutPy предлага много възможности за избор по поръчка за тестващите, което им позволява да калибрират този софтуер специално за своите изисквания. Платформата използва абстрактни синтактични дървета, които осигуряват ясна структура на изходния код на приложението, което дава на тестващите по-голяма увереност в техните мутации.
Заключение
Мутацията на кода намира приложение в почти всеки процес на тестване на софтуер, като предлага редица ясни ползи за компаниите, които прилагат тази техника – особено на по-ранен етап от осигуряването на качеството.
Нито една методология не е лишена от предизвикателства; това означава, че е наложително организациите да обмислят разумно предимствата на анализа на мутациите, като същевременно се уверят, че той е съвместим с обичайните им срокове за разработване на софтуер.
Тези мутации дават възможност на екипите за тестване да проверят собствения си подход и да определят ефективността му за откриване и отстраняване на грешки в изходния код. Тази техника е особено съвместима с процедурите за автоматизация, като позволява на фирмите да валидират софтуера, на който се доверяват, за да обработва техните проверки.
Тестването на мутации предлага на екипите за осигуряване на качеството цялостен начин за по-добро разбиране на собствените им процеси и софтуер, включително проблемите, които иначе не биха открили.
В резултат на това е жизненоважно екипите за тестване да проучат внимателно тази техника, за да преценят дали тя отговаря на нуждите на организацията – включително дали избраният инструмент за мутация е напълно съвместим с техния език за програмиране. Софтуерът за автоматизирано тестване ZAPTEST разполага с много функции, които му позволяват да премине успешно тестовете за мутация, като гарантира, че екипите имат пълно доверие в неговите способности.
Както безплатната, така и корпоративната версия предлагат висококачествен процес на тестване, който може лесно да се адаптира към промените в кода.
Често задавани въпроси и ресурси
1. Най-добрите курсове за тестване на мутации
Онлайн курсовете могат да помогнат на начинаещите тестери да научат основите на мутацията на кода или да затвърдят вече съществуващите умения на опитни служители по осигуряване на качеството. Общите уроци по тестване на софтуер също могат да предложат много ползи на тестерите. Най-добрите онлайн курсове за тестери на мутации включват:
– В доклада на PluralSight „Тестване на мутации в Java с PITest“ се разглеждат конкретно начините за промяна на кода в Java и начините, по които този подход може да бъде от полза за практическите процеси на тестване на софтуер.
– „The Complete 2023 Software Testing Bootcamp“ на Udemy е особено актуален курс, който илюстрира всеки ключов компонент на софтуерните тестове, включително тестването на „бялата кутия“.
– ‘Software Testing – Condition Coverage and Mutation Testing Strategies’ на Алисън е безплатен и разглежда внимателно как разумно да се прилага тестване с мутации.
– В „Основи на тестването на блокове“ на PluralSight се разглеждат ползите и характеристиките на тестването на блокове, като учениците разбират точния процес за писане на силни тестове на блокове.
– „Въведение в тестването на единици“ на Udemy е друг безплатен курс, който предоставя ясна разбивка на тестването на единици, както и значението на стратегиите за разработка, базирани на тестове.
2. Кои са 5-те най-важни въпроса за интервюта относно тестването на мутации?
Има редица въпроси, които фирмите могат да зададат на кандидатите по време на интервюто, за да проверят техния опит или разбиране на тестването на мутации, както и на основните му принципи. Това позволява на компанията да се увери, че наема квалифициран тестер, който може да подходи с лекота към различни сценарии, свързани с мутации.
Точните въпроси варират, но могат да включват въпроси за собственото им мнение или за примери за уменията им за мутиране на код.
Петте най-важни въпроса за интервю за тестване на мутации са:
– С кои инструменти за тестване на мутации имате предишен опит, ако имате такъв? Какви са основните характеристики на този софтуер?
– Как бихте работили, за да осигурите здравословен баланс между скоростта и задълбочеността на тестването, докато извършвате мутация на кода?
– В кои ситуации анализът на мутациите би бил невъзможен? Как бихте проверили процедурата за тестване при тези сценарии?
– Ако дадена мутация на стойност успее да оцелее в процеса на тестване, как бихте постъпили, за да предотвратите повторното й възникване?
– Каква информация бихте включили в тестовия случай за мутация, за да гарантирате, че колегите ви разполагат с необходимите данни?
3. Най-добрите уроци в YouTube за тестване на мутации
В YouTube са достъпни безплатни уроци, уебинари и други видеоклипове, които помагат за по-доброто разбиране на тестовете за мутации. Някои от най-полезните видеоклипове и поредици по темата включват:
– ‘Mutation Testing for Programs’ на Software Testing, която предоставя практически примери за това как мутацията на кода помага на програмите, както и как да се пишат подробни тестови случаи.
– „Тестване на мутации“ на Devoxx: В него се разглежда как анализът на мутациите подобрява цялостните процедури за тестване на всички видове софтуерни проекти.
– Конференциите на НДК „Убий всички мутанти! Intro to Mutation Testing“, която изследва как тестовите пакети могат да се възползват от мутацията на кода и грешките, които тя помага да се създадат.
– „Тестване на мутации в Python“ на GOTO Conferences, в която се разглежда конкретно как приложения, базирани на Python, могат да прилагат анализ на мутациите за постигане на конкретни цели за тестване.
– Диего Пачеко „Тестване на мутации в Java с PITest“, която по подобен начин илюстрира как софтуерът на JavaScript използва мутации на кода – с акцент върху програмата за мутации PITest.
4. Как да поддържаме тестовете за мутации?
Комбинирането на анализа на мутациите с тестването за регресия и други дългосрочни стратегии позволява на компаниите да осигурят висок стандарт за гарантиране на качеството дори след пускането на пазара.
Последващите актуализации могат да доведат до промени в кода, които изискват допълнителни проверки. Тестването с мутация показва, че софтуерът за автоматизация и тестерите са последователни в различните версии на един и същ софтуер, като по този начин се удостоверява отново техният конкретен подход.
Новите функции изискват нови тестови случаи, особено ако тези функции взаимодействат с вече съществуващи такива.
Освен това използването на тестово ориентирана разработка позволява на членовете на екипа да планират дълготрайността на софтуера и да тестват съвместимостта му като част от собствения му цикъл на разработка.
