Превод по кнеа на Христо Александров Стефанов гр. 45 N 101207092



Дата08.05.2018
Размер50.62 Kb.
Превод по КНЕА

На Христо Александров Стефанов гр. 45 N 101207092

Testing Automation
Софтуерното тестване може да бъде скъпо. Автоматизацията е добър начин да се намалят време и разходи . Софтуерните тестови средства и техники обикновено страдат от липсата на общо приложение и иновативност. За да се автоматизира процеса , трябва да се има в предвид начини да се породят предсказания от спецификация и да се създадът тестови случаи да изпитат целевия софтуер срещу предсказанията за да се реши тяхната точност. Общо взето , значително количество човешки интервенции са необходими. Нивото на автоматизация остава на ниво автоматизиран тестов скрипт.
Проблема е намален по отношение на надеждното тестване и представителното тестване .
Кога да спрем тестинга?

Тестинга е на практика безкраен. Не може да се тества докато не бъдат намерени и премахнати всички дефекти – това е невъзможно. В даден момент трябва да се спре изпитанието и да се превози софтуера. Въпроса е кога? Реалистично изпитанието е размяна между разходи , време и качество. Води се от модели на изгода. Песимистичен и за съжаление най-често използван подход е да се спре тестинга когато някои или няколко от определените ресурси – време , разходи или тестови случаи са изчерпани. Оптимистичното решение за спиране е да се спре изпитанието когато надеждността срещне съответните изисквания или когато печалбата от продължаващото изпитание не може да оправдае цената за изпитанието. Това ще изисква употребата на модели за надеждност за оценяване и предвиждане надеждността на софтуера.

Всяко изчисление изисква повторно стартиране на следния цикъл : грешка при събиране на данни – моделиране – предвиждане. Този модел не се вмества добре в ултра сигурни системи , обаче защото истинския обсег на грешка в данните ще отнеме доста време за събиране.
Алтернативи за тестване
Софтуерното тестване е все повече считано за проблематичен метод към по добро качество. Използването на изпитанието за локализиране и поправяне на софтуерни дефекти може да бъде безкраен процес. Бъговете немогат да се изключат напълно. Понякога поправянето на проблем може да внесе много повече тежки проблеми в системата
Проверка / Потвърждаване / Разрешение
В развитието на вградените системи , важно е да може да се определи дали системата среща необходимите спецификации и дали изходните устройства са правилни. Това е процес на проверка и потвърждаване( V & V). Двата аспекта са необходими когато системата среща необходимите спецификации не е необходимо да означава че е технически изправно и обратното.

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

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

Затова трябва да се вземе особенна грижа при разработването на вградени системи за да се уверим че е изразходвано необходимото време за В и В .


Проверка , Потвърждаване и Разрешение са съществени в жизнения цикъл на всяка сигурна вградена системта. Проверката и потвърждението станаха важни особено в софтуера тъй като комплексността на софтуера в системите се повиши и планиране на В и В е необходимо от началото на разработването на жизнения цикъл. За изминалите 20 до 30 години , софтуерното развитие прозхожда от малки задания включвайки малко хора до огромни задачи включвайки много хора. Заради тази промяна Проверката и потвърждението претърпяват промяна.

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

Техники на Проверка


  • Динамичен тестинг – това е изпитание което включва изпълнението на система или елемент . Основно се избират тестови случаи , където всеки тестови случай се състои от тестови данни. Тези входни тестови случаи се използват за да се определят изходните тестови резултати. Динамичното изпитание се разделя на 3 категории – функционално , структурно и избираемо изпитания.

  • Функционално Изпитание – тест който включва разпознаване и тестване на всички функции на системата като дефинирани в рамките на изискванията. Този вид на изпитание е пример за блек бокс тестинга тъй като не включва знания за изпълнение на системата.

  • Структурен тестинг – изпитание което разполага с пълно познаване за изпълнение на системата и е пример за уайт бокс тестинг. Използва информацията от вътрешна структура на система за създаване на тестове за проверяване на операцията на индивидуален елемент. Функционалния и структурния тестинг избират тестови случаи които разследват определена характеристика на системата.

  • Избираем тестинг – тест който свободно избира тестови случаи сред набор от всички възможни тстови случаи. Използването на избираемо определящи входове може да засече грешки които не са били открити от други систематични тестинг техники. Изчерпателният тестинг е вид избираем тестинг където входните тестови случаи се състоят от всеки възможен набор от входни величини.

  • Статичен тестинг – това е изпитание което не вклюва операция на системата или елемент . Някои от тези техники се изпълняват ръчно докато други автоматизирано. Статичния тестинг се разделя на 2 категории – техники които анализират постоянство и техники които оценяват програмно свойство .

  • Техники на постоянство – Техники които се използват да подсигурят програми свойства като правилен синтаксис , правилно параметрично съвпадение между процедури , правилен печатане.

Техники на потвърждаване


Има също така многобройни техники на потвърждение включвайки формални методи и надеждни анализи. Потвърждението обикновено става в края на цикъла на развитие

  • Формален метод – Формалния метод не е само проверовъчна техника а и потвърждаваща техника.

  • Дефектно впръскване – дефектното впръскване е преднамерено активиране на дефекти от хардуерни или софтуерни особености за наблюдение на системни операции под дефектни условия

  • Хардуерно дефектно впръскване – известно още като физично дефекнтно впръскване защото ние по точно инжектираме дефекти във физичния хардуер .

  • Софтуерно дефектно впръскване – Грешките са инжектирани в паметта на компютъра чрез софтуерни техники.

  • Надежден анализ – надеждния анализ включва разпознаване на опасности и предлагане на методи които намаляват риска от поява на опасност

  • Рискови анализи – включва използването на указания за разпознаване на опасности , техните основни вреди и възможни предпазни мярки


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


База данных защищена авторским правом ©obuch.info 2016
отнасят до администрацията

    Начална страница