Эквивалентирование и анализ граничных значений.

Область входных данных программы или модуля можно разбить на конечное число классов эквивалентности. Как минимум существует два класса эквивалентности: допустимые и запрещенные значения.

Разбиение эквивалентности – полезный метод, который может повысить результативность тестирования. Суть – многие состояния ввода очень похожи друг на друга, но отличаются только в нескольких аспектах. Если 1 такой ввод выполняется довольно хорошо, то существует высокая вероятность, что б. успешно выполняться другой ввод.

Можно также выполнить группировку или разбиение эквивалентности пространства ввода. Для этого нужно выбрать т. одно состояние ввода из каждой группы с вероятностью, равной общей вероятности возникновения всех состояний в данной группе.

Ускоряется процесс тестирования, т.к. не выполняются те состояния ввода, которые могут привести к новым сбоям.

 

Памятка для простого разбиения классов эквивалентности:

Пространство входных данных	Действительные значения	Недействительные значения
восходящая область: (2,3,4,6)	min-2 max-6, среднее 3или4	min-0 max-10
Перебор значений (2,4,12,17,19)	min-2 max-19, номинальное 17или19	min-0 max-20 и 8
Несколько подмножеств значений: (2,3,4,5) (b,c,d,e) (73,106)		min-(0,А) max-(17,q), а также значение, не принадлежащее интервалу (100)
Содержит обязательное значение: первый символ д.б. Z или X	ZOOM	ROOM

Граничные значения определяются как min и max значения каждого класса эквивалентности. Т.о. для критического теста проверяются все граничные значения верных классов эквивалентности, а также их серединные значения. Для углубленного теста характерна та же ситуация: проверка на границах неверных значений, на серединных, на пустых полях, на символах и спецсимволах.

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

Если классы верных и неверных зн-ний имеют общую границу (0), тогда надо проверять граничное зн-ние справа и граничное зн-ние слева. Т.е. для класса верных зн-ний: 1 и 2⁶⁴; для неверных – 0 и -2⁶⁴.

 

Памятка:

1. постр-ть тесты для границ области допустимых значений исход. данных и тесты с недопустимыми знач-ми на границе.

([1,100] провер. 1, 100, 0, 101, 0.99, 100.1)

2. тоже для дискретных значений;

3. для кажд. выходного условия;

4. для кажд. выходного условия

17. Тестовый план. Тестовая стратегия.

После появления первой рабочей версии треб-ний к ПП, тест-щики приступают к разработке тестовых сценариев. Руководитель группы тест-щиков приступает к написанию тестового плана. Это базовый док-т, согласно к-рому будут проводиться все действия по тест-нию. В нем описывается:

· перечень тестируемых компонентов;

· критические факторы и риски;

· ресурсы (человеческие и аппаратные);

· стратегия и виды тест-ния.

При составлении тестового плана необходимо определить:

Ø какой продукт будем тест-вать, как он работает и для чего нужен;

Ø понять, как будет использоваться продукт;

Ø разобраться с требования к продукту;

Ø решить, какие части продукта будем тест-вать и как;

Ø выбрать, какие из методов тест-ния будут наиб. эффективны для проверки нашего продукта;

Ø определение критериев кач-ва продукта;

Ø опред-ть возможные риски, т.е. сит-ции, к-рые могут привести к ухудшению продукта, и подумать, как предотвратить эти ситуации;

Ø позаботиться о тестовом оборудовании, на к-ром будет производиться тест-ние, т.к. условия тест-ния д.б. max приближены к тем, при к-рых будет эксплуатироваться продукт.

В качестве примера тестового плана м. служить следующий: 1) Введение; 2) Список рисков; 3) Ресурсы (человеческие, железные); 4) Инструментарий (какие эл-ты б. тест-ваться вручную, какие автоматич.); 5) Сроки доставки; 6) Стратегия тестирования.

Тестовая стратегия.

Указ. какие конфиг. тестов будут тест-ся в 1-ю очередь, объемы тест-х работ, типы методик тестир-я, критерии входа и выхода испытаний.

Для успешного тестирования необходимо определить:

1. Определение объема тестовых работ заключается в определении той части проги, к-рая будет тест-ваться. Надо установить баланс м/у избыточным и недостаточным тест-нием.

2. Подход к тестированию, т. е. для каждого этапа определить необходимые шаги и документы.

3. Определить критерии входа и выхода. критерии входа – описать, что надо делать перед началом тест-я и какими располагать док-ми; критерии выхода – необходимые для завершения испытаний.

Статическое тестирование, его виды.

Static testing – часть процедуры тестирования осущ-ая без запуска ПО. Среди его этапов м выделить сл: - тестирование требований; - Разработка стратегии тест-ния; - Составление тестового плана; - Подготовка тестовых сценариев; - Пересмотр и отладка тестов.

При статич. тестир-ии должны обнаруж-ся ошибки исп-ся только текстовые или графич. формы ПО. М проводиться как вручную, так и с использ-ем инструм-ых ср-в. Сущ-т ряд технологий статич-го тестир-я, кот-е явл эфф-ым ср-вом обнаружения ошибок. К ним относятся: - Формальные оценки; - Инспекции; - Аудиты.

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

Аудит провод-ся для того, чтобы убедиться в соблюдении инструкций и стандартов организацией. Аудит представляет собой беседы с пред-ми разных производственных ур-й, причем отдельно с руководителем и отдельно со спец-ми по качеству, разр-ми и т.д. Получ-е выводы направ-ся рук-ву для доведения их до всех членов орг-ции.

Экспертные оценки встречаются в бол-ве проектов. (чтение и пометки польз-й или клиентской документации; беседы др с др прогр-в с целью подел. некоторой отладочной инфо).

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

Испекции явл одной из форм экспортных оценок и обладает рядом общих черт с неформальным просмотром кода и критической оценкой. Инспекции начинаются с предоставления исходного кода и проекта. Инспекции – беседы, в составе кот входят след члены координатор, председатель, 2-3 человека по теме рассм-й инспекции. Показатели, полученные в ходе инспекции могут служить основой для составления контрольных перечней.

Процесс динамического тестирования.

Тестирование - ПО – процесс анализа или эксплуатации ПО с целью выявления дефектов.

Дефект – изъян в разработке ПП, которые не соответствует ожидаемым результатам выполнения программы с фактическим.

Динамическое тестирование ПО – это вид тестирования, который предусматривает эксплуатацию ПО. Проводится путем запуска проги (черный ящик).

Динамическое тестирование состоит из 3 этапов:

1. приемочное тестирование (smoke test) – короткий тест, кот длиться не > 30 мин для того, чтобы проверить самую глобальную функц-ность системы и сделать вывод о пригодности ПП для тест-я вообще. Т. обр. ПТ принято разраб. для кажд. этапа тест-я в отд-ти.

2. критическое (critical) – проверка работы проги при стандартных условиях.

3. углубленное (расширенное) – extended – проверка работы проги для нестандартных ситуаций.

Для упрощения поиска ошибки используются контрольные перечни.

Для проведения динамического тестирования используются тестовые план (в кот описывается инструкции для тестирования, способы тестирования, сроки и т.д.)

Для каждого теста должен быть описан тестовый сценарий (алгоритм проверки каждой функциональности). В тестовом сценарии прописываются тестовые случаи на каждую функциональность.

 

Ошибка. Свойства ошибки.

Ошибка (дефект, Bug) – расхождение м-ду прогой и ее спецификацией.

или если прога не делает того, что пользователь от нее вполне обоснованно ожидает.

Если прога не делает того, что польз-ль от нее ожидает – программная ошибка.

Свойства ошибок:

1. Важность:

1) критическая ошибка – происходит крах прилож-я, крах сервера, ОС, невозможность продолж-я раб. с прил-ем без его перезапуска.

2) серьезная – не работ-ая или неправильно раб-щая осн. функциональность прилож-я: невозм-ть сохр. данные, выбора опер-й продукта, потеря информ.

3) средняя – не раб. или неправильно раб. неосн. функц-ть, но есть др. сп-б для ее реализ-ии: не раб Save As(раб. Save).

4) Низкая – все дефекты, не влияющие на функциональность (грам. ошибки, некорректная табуляция и т.д.)

2. Воспроизводимость – как часто проявляется ошибка:

- всегда

- иногда при каком-то условии

3. Симптом – категория ошибки:

- Неверное действие;

- Отказ системы;

- Потеря данных;

- Искажение данных;

- Косметическая ошибка;

- Ошибка документации;

- Различие со спецификацией.

4. Приоритет ошибки по отношения с другими ошибками:

- Очень высокий; - Высокий; - Средний; - Низкий.