Презентация

УРОВНИ, ВИДЫ И ТИПЫ ТЕСТИРОВАНИЯ
С тех­ни­чес­кой точ­ки зре­ния тес­ти­рова­ние зак­лю­ча­ет­ся в вы­пол­не­нии при­ложе­ния на не­кото­ром мно­жес­тве ис­ходных дан­ных в свер­ке по­луча­емых ре­зульта­тов с за­ранее из­вес­тны­ми (эта­лон­ны­ми) с целью ус­та­новить со­от­ветс­твие раз­личных свойств и ха­рак­те­рис­тик при­ложе­ния за­казан­ным свойствам.

ТЕС­ТИ­РОВА­НИЕ
Тес­ти­рова­ние — кон­тро­лиру­емое вы­пол­не­ние прог­раммы на ко­неч­ном мно­жес­тве тес­то­вых дан­ных и ана­лиз ре­зульта­тов это­го вы­пол­не­ния для по­ис­ка оши­бок.
Тер­мин «от­ладка» в оте­чес­твен­ной ли­тера­туре трак­ту­ет­ся дво­яко: для обоз­на­чения ак­тивнос­ти по по­ис­ку оши­бок (собс­твен­но тес­ти­рова­ние), по на­хож­де­нию при­чин их по­яв­ле­ния и ис­прав­ле­нию или ак­тивнос­ти по ло­кали­зации и ис­прав­ле­нию оши­бок.

ТЕСТИРОВАНИЕ И ОТЛАДКА
Тес­ти­рова­ние — это про­цесс вы­пол­не­ния ПО сис­те­мы или ком­по­нен­та в ус­ло­ви­ях ана­лиза или за­писи по­луча­емых ре­зульта­тов в це­лях про­вер­ки (оцен­ки) не­кото­рых свойств тес­ти­ру­емо­го объек­та; ана­лиза пун­кта тре­бова­ний к ПО в це­лях фик­са­ции раз­ли­чий меж­ду су­щес­тву­ющим сос­то­яни­ем ПО и тре­бу­емым (что сви­де­тельству­ет о про­яв­ле­нии ошиб­ки) при эк­спе­римен­тальной про­вер­ке со­от­ветс­тву­юще­го пун­кта тре­бова­ний.
По­рой тер­ми­ны «тес­ти­рова­ние» и «от­ладка» ис­пользу­ют вза­имо­заме­ня­емо, но вни­мательные прог­раммис­ты раз­ли­ча­ют два этих про­цес­са. Тес­ти­рова­ние — это средс­тво об­на­руже­ния оши­бок, тог­да как от­ладка яв­ля­ет­ся средс­твом по­ис­ка и ус­тра­нения при­чин уже об­на­ружен­ных оши­бок.

Ша­ги про­цес­са за­да­ют­ся тес­та­ми.
Каж­дый тест оп­ре­деля­ет:
свой на­бор ис­ходных дан­ных и ус­ло­вий для за­пус­ка прог­раммы;
на­бор ожи­да­емых ре­зульта­тов ра­боты прог­раммы.
Дру­гое наз­ва­ние тес­та — тес­то­вый ва­ри­ант. Пол­ную про­вер­ку прог­раммы га­ран­ти­ру­ет ис­черпы­ва­ющее тес­ти­рова­ние. Оно тре­бу­ет про­верить все на­боры ис­ходных дан­ных, все ва­ри­ан­ты их об­ра­бот­ки и вклю­ча­ет в се­бя большое ко­личес­тво тес­то­вых ва­ри­ан­тов. В большинс­тве слу­ча­ев ис­черпы­ва­ющее тес­ти­рова­ние не­воз­можно, преж­де все­го из-за ог­ра­ниче­ния по вре­мени.
Хо­рошим счи­та­ют тес­то­вый ва­ри­ант с вы­сокой ве­ро­ят­ностью об­на­руже­ния еще не рас­кры­той ошиб­ки. Ус­пешным на­зыва­ют тест, ко­торый об­на­ружи­ва­ет до сих пор не рас­кры­тую ошиб­ку.

ЦЕЛЬ ПРО­ЕК­ТИ­РОВА­НИЯ ТЕС­ТО­ВЫХ ВА­РИ­АН­ТОВ
Целью про­ек­ти­рова­ния тес­то­вых ва­ри­ан­тов яв­ля­ет­ся сис­те­мати­чес­кое об­на­руже­ние раз­личных клас­сов оши­бок при ми­нимальных зат­ра­тах вре­мени и сто­имос­ти.
Тес­ти­рова­ние обес­пе­чива­ет:
об­на­руже­ние оши­бок;
де­монс­тра­цию со­от­ветс­твия фун­кций прог­раммы ее наз­на­чению;
де­монс­тра­цию ре­али­зации тре­бова­ний к ха­рак­те­рис­ти­кам прог­раммы;
отоб­ра­жение на­деж­ности как ин­ди­като­ра ка­чес­тва прог­раммы.

Целью тес­ти­рова­ния яв­ля­ет­ся на­хож­де­ние оши­бок. Ус­пешным счи­та­ет­ся тест, на­руша­ющий ра­боту ПО. Все ос­тальные эта­пы раз­ра­бот­ки нап­равле­ны на пре­дот­вра­щение оши­бок и не­допу­щение на­руше­ния ра­боты прог­раммы.
Тес­ти­рова­ние ни­ког­да не до­казы­ва­ет от­сутс­твие оши­бок. От­сутс­твие оши­бок мо­жет ука­зывать как на бе­зуп­речность прог­раммы, так и на не­эф­фектив­ность или не­пол­но­ту тес­тов.
Тес­ти­рова­ние не по­выша­ет ка­чес­тва ПО — оно ука­зыва­ет на ка­чес­тво прог­раммы, но не вли­яет на не­го.

ВИДЫ ТЕСТИРОВАНИЯ
Тес­ти­рова­ние — са­мая по­пуляр­ная ме­тоди­ка по­выше­ния ка­чес­тва, под­креп­ленная мно­гими ис­сле­дова­ни­ями и бо­гатым опы­том раз­ра­бот­ки ком­мерчес­ких при­ложе­ний. Су­щес­тву­ет мно­жес­тво ви­дов тес­ти­рова­ния: од­ни обыч­но вы­пол­ня­ют са­ми раз­ра­бот­чи­ки, а дру­гие — спе­ци­али­зиро­ван­ные груп­пы.
Пе­речис­лим ви­ды тес­ти­рова­ния:
блоч­ное;
тес­ти­рова­ние ком­по­нен­та;
ин­тегра­ци­он­ное тес­ти­рова­ние;
рег­рессив­ное тес­ти­рова­ние;
тес­ти­рова­ние сис­те­мы.

блоч­ное — это тес­ти­рова­ние пол­но­го клас­са, ме­тода или не­большо­го при­ложе­ния, на­писан­но­го од­ним прог­раммис­том или груп­пой, вы­пол­ня­емое от­дельно от про­чих час­тей сис­те­мы;
тес­ти­рова­ние ком­по­нен­та — это тес­ти­рова­ние клас­са, па­кета, не­большо­го при­ложе­ния или дру­гого эле­мен­та сис­те­мы, раз­ра­ботан­но­го нес­кольки­ми про­грам­миста­ми или груп­па­ми, вы­пол­ня­емое в изо­ляции от ос­тальных час­тей сис­те­мы;
ин­тегра­ци­он­ное тес­ти­рова­ние — это сов­мес­тное вы­пол­не­ние двух или бо­лее клас­сов, па­кетов, ком­по­нен­тов или под­систем, соз­данных нес­кольки­ми про­грам­миста­ми или груп­па­ми;
рег­рессив­ное тес­ти­рова­ние — это пов­торное вы­пол­не­ние тес­тов, нап­равлен­ное на об­на­руже­ние де­фек­тов в прог­рамме, уже про­шед­шей этот на­бор тес­тов;
тес­ти­рова­ние сис­те­мы — это вы­пол­не­ние ПО в его окон­ча­тельной кон­фи­гура­ции, ин­тегри­рован­но­го с дру­гими прог­рам­мны­ми и ап­па­рат­ны­ми сис­те­мами.

РЕ­АЛИ­ЗАЦИЯ ТЕС­ТИ­РОВА­НИЯ
Этап 1. Соз­да­ние тес­то­вого на­бора (test suite) пу­тем руч­ной раз­ра­бот­ки или ав­то­мати­чес­кой ге­нера­ции для кон­крет­ной сре­ды тес­ти­рова­ния (testing environment).
Этап 2. Про­гон прог­раммы на тес­тах, уп­равля­емый тес­то­вым мо­нито­ром (test monitor, test driver) с по­луче­ни­ем про­токо­ла тес­ти­рова­ния (test log).
Этап 3. Оцен­ка ре­зульта­тов вы­пол­не­ния прог­раммы на на­боре тес­тов в це­лях при­нятия ре­шения о про­дол­же­нии или ос­та­нов­ке тес­ти­рова­ния.

КРИТЕРИИ ТЕСТИРОВАНИЯ

Мож­но вы­делить тре­бова­ния к иде­ально­му кри­терию тес­ти­рова­ния:
кри­терий дол­жен быть дос­та­точ­ным, т.е. по­казы­вать, ког­да не­кото­рое ко­неч­ное мно­жес­тво тес­тов дос­та­точ­но для тес­ти­рова­ния дан­ной прог­раммы;
кри­терий дол­жен быть пол­ным, т.е. в слу­чае ошиб­ки дол­жен су­щес­тво­вать тест из мно­жес­тва тес­тов, удов­летво­ря­ющих кри­терию, ко­торый рас­кры­ва­ет ошиб­ку;
кри­терий дол­жен быть на­деж­ным, т.е. лю­бые два мно­жес­тва тес­тов, удов­летво­ря­ющих ему, од­новре­мен­но дол­жны рас­кры­вать или не рас­кры­вать ошиб­ки прог­раммы;
кри­терий дол­жен быть лег­ко про­веря­емым, нап­ри­мер, вы­чис­ля­емым на тес­тах.

КЛАС­СЫ КРИ­ТЕРИ­ЕВ
Для нет­ри­ви­альных клас­сов прог­рамм в об­щем слу­чае не су­щес­тву­ет пол­но­го и на­деж­но­го кри­терия, за­вися­щего от прог­рамм или спе­цифи­каций. По­это­му, как пра­вило, стре­мят­ся к иде­ально­му об­ще­му кри­терию че­рез ре­альные час­тные.
Вы­деля­ют сле­ду­ющие клас­сы кри­тери­ев:
струк­турные кри­терии — ис­пользу­ют ин­форма­цию о струк­ту­ре прог­раммы (кри­терии так на­зыва­емо­го бе­лого ящи­ка);
фун­кци­ональные кри­терии — фор­му­лиру­ют­ся в опи­сании тре­бова­ний к прог­рам­мно­му из­де­лию (кри­терии так на­зыва­емо­го чер­но­го ящи­ка);
кри­терии сто­хас­ти­чес­ко­го тес­ти­рова­ния — фор­му­лиру­ют­ся в тер­ми­нах про­вер­ки на­личия за­дан­ных свойств у тес­ти­ру­емо­го при­ложе­ния, средс­тва­ми про­вер­ки не­кото­рой ста­тис­ти­чес­кой те­ории;
му­таци­он­ные кри­терии — ори­ен­ти­рова­ны на про­вер­ку свойств прог­рам­мно­го из­де­лия на ос­но­ве под­хо­да Мон­те-Кар­ло.

СТРУК­ТУРНЫЕ КРИ­ТЕРИИ (КЛАСС I)
Струк­турные кри­терии ис­пользу­ют мо­дель про­грам­мы в ви­де «бе­лого ящи­ка», что пред­по­лага­ет зна­ние ис­ходно­го тек­ста прог­раммы или спе­цифи­кации прог­раммы в ви­де по­токо­вого гра­фа уп­равле­ния. Струк­турная ин­форма­ция по­нят­на и дос­тупна раз­ра­бот­чи­кам под­систем и мо­дулей при­ложе­ния, по­это­му дан­ный класс кри­тери­ев час­то ис­пользу­ет­ся на эта­пах мо­дульно­го и ин­тегра­ци­он­но­го тес­ти­рова­ния.

Струк­турные кри­терии ба­зиру­ют­ся на ос­новных эле­мен­тах: опе­рато­рах, вет­вях и пу­тях.
Ус­ло­вие кри­терия тес­ти­рова­ния ко­манд (кри­терий С0) — на­бор тес­тов в со­вокуп­ности дол­жен обес­пе­чить про­хож­де­ние каж­дой ко­ман­ды не ме­нее од­но­го ра­за. Это сла­бый кри­терий, ис­пользу­ет­ся в больших прог­рам­мных сис­те­мах, где дру­гие кри­терии при­менить не­воз­можно.
Ус­ло­вие кри­терия тес­ти­рова­ния вет­вей (кри­терий С1) — на­бор тес­тов в со­вокуп­ности дол­жен обес­пе­чить про­хож­де­ние каж­дой вет­ви не ме­нее од­но­го ра­за. Это дос­та­точ­но сильный и при этом эко­номич­ный кри­терий. Дан­ный кри­терий час­то ис­пользу­ет­ся в сис­те­мах ав­то­мати­зации тес­ти­рова­ния.
Ус­ло­вие кри­терия тес­ти­рова­ния пу­тей (кри­терий С2) — на­бор тес­тов в со­вокуп­ности дол­жен обес­пе­чить про­хож­де­ние каж­до­го пу­ти не ме­нее од­но­го ра­за. Ес­ли прог­рамма со­дер­жит цикл (в осо­бен­ности с не­яв­но за­дан­ным чис­лом ите­раций), то чис­ло ите­раций ог­ра­ничи­ва­ет­ся кон­стан­той (час­то — 2, или чис­лом клас­сов вы­ход­ных пу­тей).
Струк­турные кри­терии не про­веря­ют со­от­ветс­твие спе­цифи­кации, ес­ли оно не от­ра­жено в струк­ту­ре прог­раммы.

ФУН­КЦИ­ОНАЛЬНЫЕ КРИ­ТЕРИИ (КЛАСС II)
Фун­кци­ональный кри­терий — важ­нейший для прог­рам­мной ин­дус­трии кри­терий тес­ти­рова­ния. Он обес­пе­чива­ет, преж­де все­го, кон­троль сте­пени вы­пол­не­ния тре­бова­ний за­каз­чи­ка в прог­рам­мном про­дук­те. По­скольку тре­бова­ния фор­му­лиру­ют­ся к про­дук­ту в це­лом, они от­ра­жа­ют вза­имо­действие тес­ти­ру­емо­го при­ложе­ния с ок­ру­жени­ем. При фун­кци­ональном тес­ти­рова­нии пре­иму­щес­твен­но ис­пользу­ет­ся мо­дель «чер­но­го ящи­ка». Проб­ле­ма фун­кци­онально­го тес­ти­рова­ния — это, преж­де все­го, тру­до­ем­кость. Де­ло в том, что до­кумен­ты, фик­си­ру­ющие тре­бова­ния к прог­рам­мно­му из­де­лию (Software requirement specification, Functional specification и т.п.), как пра­вило, дос­та­точ­но объем­ны, тем не ме­нее, со­от­ветс­тву­ющая про­вер­ка дол­жна быть все­объем­лю­щей.

ВИ­ДЫ ФУН­КЦИ­ОНАЛЬНЫХ КРИ­ТЕРИ­ЕВ

ТЕС­ТИ­РОВА­НИЕ ПУН­КТОВ СПЕ­ЦИФИ­КАЦИИ
На­бор тес­тов в со­вокуп­ности дол­жен обес­пе­чить про­вер­ку каж­до­го тес­ти­ру­емо­го пун­кта не ме­нее од­но­го ра­за. Спе­цифи­кация тре­бова­ний мо­жет со­дер­жать сот­ни и ты­сячи пун­ктов тре­бова­ний к прог­рам­мно­му про­дук­ту и каж­дое из этих тре­бова­ний при тес­ти­рова­нии дол­жно быть про­вере­но в со­от­ветс­твии с кри­тери­ем не ме­нее чем од­ним тес­том.

ТЕС­ТИ­РОВА­НИЕ КЛАС­СОВ ВХОД­НЫХ ДАН­НЫХ
На­бор тес­тов в со­вокуп­ности дол­жен обес­пе­чить про­вер­ку пред­ста­вите­ля каж­до­го клас­са вход­ных дан­ных не ме­нее од­но­го ра­за при соз­да­нии тес­тов клас­сы вход­ных дан­ных со­пос­тавля­ют­ся с ре­жима­ми ис­пользо­вания тес­ти­ру­емо­го ком­по­нен­та или под­систе­мы при­ложе­ния, что за­мет­но сок­ра­ща­ет ва­ри­ан­ты пе­ребо­ра, учи­тыва­емые при раз­ра­бот­ке тес­то­вых на­боров. Сле­ду­ет за­метить, что, пе­реби­рая в со­от­ветс­твии с кри­тери­ем ве­личи­ны вход­ных пе­ремен­ных (нап­ри­мер, раз­личные файлы — ис­точни­ки вход­ных дан­ных), мы вы­нуж­де­ны при­менять мощ­ные тес­то­вые на­боры. Действи­тельно, на­ряду с ог­ра­ниче­ни­ями на ве­личи­ны вход­ных дан­ных, су­щес­тву­ют ог­ра­ниче­ния на ве­личи­ны вход­ных дан­ных во все­воз­можных ком­би­наци­ях, в том чис­ле про­вер­ка ре­ак­ций сис­те­мы на по­яв­ле­ние оши­бок в зна­чени­ях или струк­ту­рах вход­ных дан­ных. Учет это­го мно­го­об­ра­зия — про­цесс тру­до­ем­кий, что соз­да­ет слож­ности для при­мене­ния кри­терия

ТЕС­ТИ­РОВА­НИЕ ПРА­ВИЛ
На­бор тес­тов в со­вокуп­ности дол­жен обес­пе­чить про­вер­ку каж­до­го пра­вила, ес­ли вход­ные и вы­ход­ные зна­чения опи­сыва­ют­ся на­бором пра­вил не­кото­рой грам­ма­тики. Сле­ду­ет за­метить, что грам­ма­тика дол­жна быть дос­та­точ­но прос­той, что­бы тру­до­ем­кость раз­ра­бот­ки со­от­ветс­тву­юще­го на­бора тес­тов бы­ла ре­альной (впи­сыва­лась в сро­ки и штат спе­ци­алис­тов, вы­делен­ных для ре­али­зации фа­зы тес­ти­рова­ния)

ТЕС­ТИ­РОВА­НИЕ КЛАС­СОВ ВЫ­ХОД­НЫХ ДАН­НЫХ
На­бор тес­тов в со­вокуп­ности дол­жен обес­пе­чить про­вер­ку пред­ста­вите­ля каж­до­го вы­ход­но­го клас­са, при ус­ло­вии, что вы­ход­ные ре­зульта­ты за­ранее рас­клас­си­фици­рова­ны, при­чем от­дельные клас­сы ре­зульта­тов ука­зыва­ют, в том чис­ле, ог­ра­ниче­ния на ре­сур­сы или на вре­мя (time out); при соз­да­нии тес­тов клас­сы вы­ход­ных дан­ных со­пос­тавля­ют­ся с ре­жима­ми ис­пользо­вания тес­ти­ру­емо­го ком­по­нен­та или под­систе­мы, что за­мет­но сок­ра­ща­ет ва­ри­ан­ты пе­ребо­ра, учи­тыва­емые при раз­ра­бот­ке тес­то­вых на­боров

ТЕС­ТИ­РОВА­НИЕ ФУН­КЦИЙ
На­бор тес­тов в со­вокуп­ности дол­жен обес­пе­чить про­вер­ку каж­до­го действия, ре­али­зу­емо­го тес­ти­ру­емым мо­дулем, не ме­нее од­но­го ра­за. Очень по­пуляр­ный на прак­ти­ке кри­терий, ко­торый, од­на­ко, не обес­пе­чива­ет пок­ры­тия час­ти фун­кци­ональнос­ти тес­ти­ру­емо­го ком­по­нен­та, свя­зан­ной со струк­турны­ми и по­веден­чески­ми свойства­ми, опи­сание ко­торых не сос­ре­дото­чено в от­дельных фун­кци­ях (опи­сание рас­сре­дото­чено по ком­по­нен­ту)

КРИ­ТЕРИЙ ТЕС­ТИ­РОВА­НИЯ ФУН­КЦИЙ
Объеди­ня­ет от­части осо­бен­ности струк­турных и функ­ци­ональных кри­тери­ев. Он ба­зиру­ет­ся на мо­дели «по­луп­розрач­но­го ящи­ка», где яв­но ука­заны не только вхо­ды и вы­ходы тес­ти­ру­емо­го ком­по­нен­та, но так­же сос­тав и струк­ту­ра ис­пользу­емых ме­тодов (фун­кций, про­цедур) и клас­сов

КОМ­БИ­НИРО­ВАН­НЫЕ КРИ­ТЕРИИ ДЛЯ ПРОГ­РАММ И СПЕ­ЦИФИ­КАЦИЙ
На­бор тес­тов в со­вокуп­ности дол­жен обес­пе­чить про­вер­ку всех ком­би­наций неп­ро­тиво­речи­вых ус­ло­вий прог­рамм и спе­цифи­каций не ме­нее од­но­го ра­за. При этом все ком­би­нации неп­ро­тиво­речи­вых ус­ло­вий на­до под­твер­дить, а ус­ло­вия про­тиво­речий сле­ду­ет об­на­ружить и лик­ви­диро­вать

СТО­ХАС­ТИ­ЧЕС­КИЕ КРИ­ТЕРИИ (КЛАСС III)
Сто­хас­ти­чес­кое тес­ти­рова­ние при­меня­ет­ся при тес­ти­рова­нии слож­ных прог­рам­мных ком­плек­сов, ког­да на­бор де­тер­ми­ниро­ван­ных тес­тов (X, Y) име­ет гро­мад­ную мощ­ность. Ког­да по­доб­ный на­бор не­воз­можно раз­ра­ботать и ис­полнить на фа­зе тес­ти­рова­ния, мож­но при­менить сле­ду­ющую ме­тоди­ку:
раз­ра­ботать прог­раммы-ими­тато­ры слу­чайных пос­ле­дова­тельных вход­ных сиг­на­лов {x};
вы­чис­лить не­зави­симым спо­собом зна­чения {y} для со­от­ветс­тву­ющих вход­ных сиг­на­лов {y} и по­лучить тес­то­вый на­бор {X,Y};
про­тес­ти­ровать при­ложе­ние на тес­то­вом на­боре {X,Y}, ис­пользуя два спо­соба кон­тро­ля ре­зульта­тов: детерминированный контроль и стохастический контроль

КРИ­ТЕРИИ СТО­ХАС­ТИ­ЧЕС­КО­ГО ТЕС­ТИ­РОВА­НИЯ:
ста­тис­ти­чес­кие ме­тоды окон­ча­ния тес­ти­рова­ния — сто­хас­ти­чес­кие ме­тоды при­нятия ре­шений о сов­па­дении ги­потез о рас­пре­деле­нии слу­чайных ве­личин. К ним при­над­ле­жат ши­роко из­вес­тные ме­тод Стьюден­та (St), ме­тод Хи-квад­рат (χ2) и т.д.;
ме­тод оцен­ки ско­рос­ти вы­яв­ле­ния оши­бок — ос­но­ван на мо­дели ско­рос­ти вы­яв­ле­ния оши­бок, сог­ласно ко­торой тес­ти­рова­ние прек­ра­ща­ет­ся, ес­ли оце­нен­ный ин­тервал вре­мени меж­ду те­кущей ошиб­кой и сле­ду­ющей слиш­ком ве­лик для фа­зы тес­ти­рова­ния при­ложе­ния.

МУ­ТАЦИ­ОН­НЫЙ КРИ­ТЕРИЙ (КЛАСС IV)
Пос­ту­лиру­ет­ся, что про­фес­си­ональные прог­раммис­ты пи­шут сра­зу поч­ти пра­вильные прог­раммы, от­ли­ча­ющи­еся от пра­вильных мел­ки­ми ошиб­ка­ми или опис­ка­ми (нап­ри­мер, пе­рес­та­нов­ка мес­та­ми мак­си­мальных зна­чений ин­дексов в опи­сании мас­си­вов, ошиб­ки в зна­ках ариф­ме­тичес­ких опе­раций, за­ниже­ние или за­выше­ние гра­ницы цик­ла на 1 и т.д.). Пред­ла­га­ет­ся под­ход, поз­во­ля­ющий на ос­но­ве мел­ких оши­бок оце­нить об­щее чис­ло оши­бок, ос­тавших­ся в прог­рамме.

Под­ход ба­зиру­ет­ся на сле­ду­ющих по­няти­ях:
му­тации — мел­кие ошиб­ки в прог­рамме;
му­тан­ты — прог­раммы, от­ли­ча­ющи­еся друг от дру­га му­таци­ями;
ме­тод му­таци­он­но­го тес­ти­рова­ния — в раз­ра­баты­ва­емую прог­рамму P вно­сят му­тации, т.е. ис­кусс­твен­но соз­да­ют прог­раммы-му­тан­ты P1, P2, … За­тем прог­рамма P и ее му­тан­ты тес­ти­ру­ют­ся на од­ном и том же на­боре тес­тов {X,Y}.
Ес­ли на на­боре {X,Y} под­твержда­ет­ся пра­вильность прог­раммы P и, кро­ме то­го, вы­деля­ют­ся все вне­сен­ные в прог­раммы-му­тан­ты ошиб­ки, то на­бор тес­тов (X,Y) со­от­ветс­тву­ет му­таци­он­но­му кри­терию, а тес­ти­ру­емая прог­рамма объяв­ля­ет­ся пра­вильной.
Ес­ли не­кото­рые му­тан­ты не вы­яви­ли всех му­таций, то на­до рас­ши­рять на­бор тес­тов (X,Y) и про­дол­жать тес­ти­рова­ние.

ПРИНЦИПЫ ТЕСТИРОВАНИЯ

Сов­ре­мен­ные при­ложе­ния име­ют больше воз­можнос­тей бла­года­ря вза­имо­действию мно­гих мо­дулей. Чис­ло тес­то­вых ус­ло­вий, не­об­хо­димых для об­ра­щения к при­ложе­ни­ям это­го ти­па, мо­жет пре­высить бюд­жет и тре­бова­ния пла­на. Это про­ис­хо­дит из-за не­эф­фектив­ности про­цес­са тес­ти­рова­ния, сос­ре­дото­чен­но­го на ис­сле­дова­нии ко­да за­кон­ченно­го при­ложе­ния. Только ор­га­низа­ции, спо­соб­ные вы­дер­жать та­кие зат­ра­ты и гиб­кий вре­мен­ной гра­фик, мо­гут и дальше уве­личи­вать про­дол­жи­тельность тес­ти­рова­ния и от­но­шение вре­мени тес­ти­рова­ния ко вре­мени раз­ра­бот­ки.

Тес­ти­рова­ние дол­жно по­мочь на­ходить и ис­прав­лять ошиб­ки на са­мой ран­ней воз­можной ста­дии. Пе­рес­мотр про­цес­са тес­ти­рова­ния вклю­ча­ет в се­бя оп­ре­деле­ние кон­цепту­альной струк­ту­ры, ор­га­низу­ющей раз­личные тех­но­логии тес­ти­рова­ния. Сре­да для это­го про­цес­са пос­тро­ена на кон­цепции «ста­дийной ло­кали­зации» (stage containment), т.е. об­на­руже­нии и ис­прав­ле­нии оши­бок на той ста­дии, где они и по­яви­лись.
Пе­рес­мотр про­цес­са тес­ти­рова­ния вклю­ча­ет в се­бя со­пос­тавле­ние ста­дии об­на­руже­ния ошиб­ки со ста­ди­ей, на ко­торой ошиб­ка в сис­те­ме впер­вые воз­никла. В ре­зульта­те ме­роп­ри­ятия по­ис­ка оши­бок сдви­га­ют­ся на ран­ние ста­дии про­цес­са раз­ра­бот­ки, ког­да вно­сить из­ме­нения про­ще и де­шев­ле.

ВЕ­РИФИ­КАЦИЯ
Ве­рифи­кация удос­то­веря­ет, что объект ра­боты внут­ренне не про­тиво­речив и со­от­ветс­тву­ет стан­дартам. Пре­иму­щес­тво ве­рифи­кации сос­то­ит в об­на­руже­нии оши­бок на ран­них эта­пах раз­ра­бот­ки до то­го, как они по­падут на сле­ду­ющую ста­дию. Это уменьша­ет зат­ра­ты. Ве­рифи­кация при­мени­ма ко всем объек­там (как к тес­то­вым мо­делям, так и к спе­цифи­каци­ям). Ме­тоды ве­рифи­кации вклю­ча­ют в се­бя эк­спертные оцен­ки, фор­мальный кон­троль и про­вер­ки на неп­ро­тиво­речи­вость.

ПРО­ВЕР­КА НА КОР­РЕК­ТНОСТЬ
Здесь про­веря­ет­ся, удов­летво­ря­ет ли объект тре­бова­ни­ям, спе­цифи­циро­ван­ным на пре­дыду­щей и бо­лее ран­них ста­ди­ях. Пре­иму­щес­тво про­вер­ки на кор­рек­тность зак­лю­ча­ет­ся в от­лавли­вании оши­бок до то­го, как они пе­реш­ли в сле­ду­ющую ста­дию раз­ра­бот­ки. Эти ме­тоды так­же при­мени­мы ко всем объек­там (к тес­то­вым мо­делям и спе­цифи­каци­ям). Ис­пользу­емые здесь при­емы мо­гут вклю­чать в се­бя об­зо­ры и фор­мальные про­вер­ки, а так­же про­тоти­пиро­вание и мо­дели­рова­ние

ТЕС­ТИ­РОВА­НИЕ, ОС­НО­ВАН­НОЕ НА СПЕ­ЦИФИ­КАЦИ­ЯХ
Ме­роп­ри­ятия тес­ти­рова­ния сос­ре­дото­чены на про­вер­ке оп­ре­делен­ных спе­цифи­каций на каж­дой ста­дии раз­ра­бот­ки. Это уменьша­ет сте­пень на­ложе­ния тес­тов и точ­но оп­ре­деля­ет рам­ки и за­дачу каж­до­го из них. Про­вер­ка на ос­но­ве спе­цифи­каций поз­во­ля­ет от­сле­живать тре­бова­ния на про­тяже­нии все­го про­цес­са тес­ти­рова­ния и пре­дос­тавля­ет ос­но­ву для уп­равле­ния про­цес­сом тес­ти­рова­ния.