ТРПО

Требования и выполнение тестов

Требования к хорошему тесту.

1. Должна быть достаточной вероятность выявления тестом ошибки

2. Набор тестов не должен быть избыточным

3. Тест должен быть наилучшим в своей категории

4. Тест не должен быть слишком простым или слишком сложным

Классы эквивалентности и граничные условия.

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

С.132

Гл.4-5

Тестирование ПП – процесс исследования, испытание ПП, имеющее две различные цели:

1. Продемонстрировать работникам и заказчикам

2. Выявить ситуации в которых поведение программы является неправильным, нежелательным или не соответствует спецификации

С точки зрения ISO 91.26 качество ПО можно определить как совокупную характеристику, исследуемого ПО с учетом следующих составляющих:

1. Надежность

2. Сопровождаемость

3. Практичность

4. Эффективность

5. Мобильность

6. Функциональность

Классификация видов тестирования:

1. По объекту тестирования

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

   2. Тестирование производительности – тестирование, которое проводится с целью определения, как быстро работает вычислительная система или её часть под определенной нагрузкой

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

1.2.2. Стресс-тестирование – оценка надежности и устойчивости системы в условиях повышения пределов нормального функционирования

1.2.3. Тестирование стабильности – цель данного тестирования – проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки

1.4. Юзабилити-тестирование – тестирование , исследование выполняемое с целью определения, удобен ли некоторый искусственный объект для его предполагаемого применения

1.5. Тестирование интерфейса пользователя

1.6. Тестирование безопасности

1.7. Тестирование локализации

1.8. Тестирование совместимости

2. По знанию системы:

2.1. Тестирование белового ящика

2.2. Тестирование черного ящика

2.3. Тестирование серого ящика

3. По степени автоматизации:

3.1. Ручное тестирование

3.2. Автоматизирование тестирование

3.3. Полуавтоматизированное тестирование

4. По степени изолированности:

4.1. Модульное тестирование (компонентное)

4.2. Интеграционное тестирование

4.3. Системное тестирование

4.4. Выходное тестирование

5. По времени проведения тестирования

5.1. Альфа-тестирование

5.1.1. Дымовое тестирование

5.1.2. Тестирование новой функциональности

5.1.3. Подтверждающее тестирование

5.1.4. Регрессионное тестирование

5.1.5. Приемочное тестирование

5.2. Бета-тестирование

6. По признаку позитивности сценария

6.1. Позитивное тестирование

6.2. Негативное тестирование

7. По степени подготовленности тестированию

7.1. Тестирование по документации

7.2. Тестирование at-hock (интуитивное)

Классы эквивалентности и граничные условия

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

Группа тестов представляет собой класс эквивалентности, если выполняются следующие условия:

-все тесты предназначены для выявления одной и той же ошибки;

-если один из тестов выявит ошибку, то остальные тоже это сделают;

-если один из тестов не выявит ошибку, то остальные тоже это не сделают

Практические критерии отнесения группы тестов к одному классу:

1. Тесты включают в себя значения одних и тех же входных данных

2. Для проведения тестов выполняются одни и те же операции программы

3. В результате всех тестов формируются одни и те же значения выходных данных

4. Либо ни один из тестов не вызывает блок обработки ошибок программы, либо этот блок вызывается всеми тестами группы.

Границы классов эквивалентности

Структурное тестирование

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

Недостатки:

1. Тестовые наборы не обнаруживают пропущенных маршрутов

2. Тестовые наборы не обнаруживают, зависящих от обрабатываемых данных

3. Тестовые наборы не дают гарантии, что программа правильна, например, если вместо сортировки по убыванию реализовано сортировка по возрастанию

Формирование тестовых наборов для тестирования маршрутов может осуществляться по нескольким критериям:

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

1. Покрытие решений (переходов) –для реализации этого критерия необходимо такое количество и состав тестов, чтобы результат проверки каждого условия (решение) принимал значение истина/ложь по крайней мере 1 раз

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

3. Покрытие решений/условий – согласно этому методу, тесты должны составляться так, чтобы по крайней мере 1 раз выполнялись всевозможные результаты каждого условия и все результаты каждого решения и каждому оператору управление передавалось по крайней мере 1 раз

4. Комбинаторное покрытие условий

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

1. Генерировать все возможные комбинации, результатов проверок условий

2. Передавать управление каждому оператору по крайней мере хотя бы 1 раз