Последовательность проектирования и прогона тестовых наборов. Принципы и стратегии тестирования. Критерии выбора тестов: функциональный и структурный подход

Взято из электронных версий лекции Смирновой Н.Н.

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

Дейкстра: "Никакое тестирование не может подтвердить правильность программы: в лучшем случае, оно может показать только ее ошибочность".

Отладка – локализация и исправление ошибок.

Виды программных ошибок Способы их обнаружения

1. Синтаксические Статический контроль и диагностика компилятором и компоновщиком

2. Ошибки выполнения, выявляемые Динамический контроль:

автоматически:

а) переполнение, потеря порядка,... - аппаратурой процессора

б) несоответствие типов - run-time системы программирования

в) зацикливание - операционной системой – по превы-

шению лимита времени задачи

3. Программа не соответствует специ- Целенаправленное тестирование

фикации

4. Спецификация не соответствует Испытания, бета-тестирование

требованиям – ошибка спецификации

Глубина контроля 1-го вида зависит и от языка, и от компилятора. Строгая типизация весьма полезна: DO 3 I = 1.3 – “точка стоимостью 800 млн $” (вместо запятой) – ошибка в Фортран-программе бортового вычислителя ракеты к Венере [1].

Набор ошибок 2-го вида может быть расширен программистом: контроль можно программировать с помощью утверждений (asserts) проверок, вставляемых в код. Это полезно для проверки правдоподобности промежуточных результатов вычислений и допустимости значений фактических параметров подпрограмм.

Собственно процесс тестирования направлен на выявление ошибок 3 и 4 видов. Большинство программистов сами исправляют 99% своих текущих ошибок. Однако порядка одной ошибки на 100 строк кода обычно еще остается, когда программист сдает работу тестеру, утверждая, что ошибок в ней нет [2].

Тест – это набор контрольных входных данных совместно с ожидаемыми результатами. К входным данным здесь относятся не только конкретные значения ввода, но и события, их последовательность и временные параметры. Ожидаемые результаты берутся из спецификации программы, а на этапе приемо-сдаточных испытаний это – ожидания пользователей.

Ключевой вопрос – полнота тестирования: какое количество каких тестов гарантирует возможно более полную проверку программы? Исчерпывающая проверка на всем множестве входных данных недостижима. Пример: программа, вычисляющая функцию двух переменных: Y = f (X, Z). Если X, Y, Z – real, то полное число тестов (2³²)² = 2⁶⁴ ≈ 10³¹. Если на каждый тест тратить 1 мс, то 10³¹ мс = 800 млн лет (отсюда видно, что ошибка FDIV Pentium’а вполне простительна). Все траектории выполнения кода также невозможно воспроизвести. В [1] приведена программа из двадцати строк кода (цикл и несколько операторов IF), у которой 10¹⁷ возможных путей выполнения.

Следовательно:

· В любой нетривиальной программе на любой стадии ее готовности содержатся необнаруженные ошибки

· Продолжительность тестирования – технико-экономическая проблема: компромисс между временем и полнотой. Поэтому нужно возможно меньшее количество хороших тестов с желательными свойствами:

Ø Детективность: тест должен с большой вероятностью обнаруживать возможные ошибки.

Ø Покрывающая способность: один тест должен выявлять как можно больше ошибок.

Ø Воспроизводимость: ошибка должна выявляться независимо от изменяющихся условий (например, от временных соотношений) – это трудно достижимо для время-зависимых программ, реультаты которых часто невоспроизводимы.

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

Два вида критериев:

§ Функциональные – если тесты составляются исходя из спецификации программы (тестирование черного ящика). Проверяется правильность выполнения программой всех ее заданных функций. Именно этим критериям в основном и следуют при независимом тестировании.

§ Структурные – если тесты составляются исходя из текста программы (тестирование прозрачного ящика). Проверяется правильность работы при прохождении всех участков кода. Эту работу программисты выполняют постоянно в ходе разработки.

Вид критерия Что должно обеспечивать множество тестов

А. Функциональные

1. Тестирование классов вх. данных! Содержать представителей всех вх или вых

2. Тестирование классов вых. данных! классов и точки на границах классов

3. Тестирование функций Каждая функция внешнего интерфейса должна быть проверена >= 1раза

Б. Структурные

1. Тестирование команд Каждая команда (оператор) д.б. выполнена

>= 1раза

2. Критерий С1 – тестир. ветвей Каждая ветвь д.б. выполнена >= 1раза

3. Критерий С2 – тестир. путей Каждый путь в графе программы д.б.

выполнен >= 1раза (Вопрос 3)

На рис 10-1 а) видно отличие тестирования команд (достаточен один тест) от С1 (необходимы два теста как минимум). Рис 10-1 б) иллюстрирует отличие С1 (достаточно двух тестов, покрывающих пути 1, 4 или 2, 3) от С2 (необходимо 4 теста для всех четырех путей). С2 в принципе недостижим в реальных программах из-за их цикличности, поэтому ограничиваются тремя путями для каждого цикла: 0, 1 и N повторений цикла.

Идея назначения классов эквивалентности вх/вых данных для функционального тестирования основана на разумном предположении, что программа на всем классе ведет себя так же, как на его одном представителе. Классы назначаются исходя из семантики решаемой задачи. В таблице 1 дан пример тестирования классов выходных данных: минимальный набор тестов для программы нахождения вещественных корней квадратного уравнения ax² + bx + c = 0 (Грюнбергер, 1968).

Рис.10-1. Траектории вычислений при структурном тестировании

Таблица 1

Таким образом, для этой программы предлагается минимальный набор из 7 функциона-льных тестов, исходя из 7 классов выходных данных.

Пример, где назначаются классы входных данных – на рис. 10-2. Здесь классы- точечные множества; внутри области А они отмечены штриховкой; символом * отмечены представители классов - тестовые значения. На рис. 10-2 предложен минимальный набор из 18 тестов – по одному для каждого класса и границы –

стороны многоугольника, ограничивающего область А. В состав тестового набора следует включать значения, непосредственно примыкающие к граничным. Например, если допустимые входные значения – целые от 1 до 99, то для тестирования допусти-мых данных можно выбрать 1 и 99, а для недопустимых – 0 и 100. Если программа получает 8 входных данных, то нужно предусмотреть 3 теста: ввод 8, 7 и 9 данных.

Запись классов эквивалентности входных данных в текстовой форме является частным случаем плана тестирования, пример которого приведен на рис. 10-3. Заметим, что классы эквивалентности могут пересекаться, как в этом примере (классы 1.2.4.1 и 1.2.4.3) – это приводит к некоторой избыточности, но не страшно.

Рис 10-2. Классы входных данных для тестирования

1. Ввод числа

1.1 Допустимые варианты

1.1.1 Числа от 0 до 99

1.2 Недопустимые варианты

1.2.1 0

1.2.2 > 99

1.2.3 Отрицательные числа

1.2.4 Буквы и другие нечисловые символы

1.2.4.1 Буквы

1.2.4.2 Символы с ASCII-кодами, меньшими кода 0

1.2.4.3 Символы с ASCII-кодами, большими кода 9

2. Ввод первой буквы имени

2.1 Допустимые варианты

2.1.1 Первый символ является заглавной буквой

<и т.д.>

Рис 10-3. Классы входных данных: фрагмент плана тестирования

Различие между функциональным и структурным тестированием относительно. Для интерактивных и реального времени программ оно стирается: входные данные – различные последовательности действий пользователя или внешних событий – однозначно отображаются на различные траектории переключения состояний программы, т.е. пути в ней. Таких траекторий – необозримо много, поэтому приходится ограничиваться тестированием наиболее вероятных действий пользователя или последовательностей событий, имитируемых специальной тестовой программой. К ним добавляются случайные действия, например, нажатие клавиш в случайные моменты времени. Профессиональные тестеры составляют схемы меню – диаграммы состояний и переходов при вводе диалоговых команд – для контроля полноты прохождения типичных траекторий диалога.

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

Рекомендуемая последовательность разработки тестов для программного модуля

1. По внешней спецификации готовятся тесты:

- для каждого класса входных данных

- для граничных и особых значений входных данных

- проверяется, все ли классы выходных данных при этом проверяются, и при необходимости добавляются нужные тесты

2. Готовятся тесты для тех функций, которые не проверяются в п. 1.

3. По тексту программы проверяется, все ли условные переходы выполнены в

каждом направлении (С1). При необходимости добавляются новые тесты.

4. Аналогично проверяется, проходятся ли пути для каждого цикла: без

выполнения тела, с однократным и максимальным числом повторений.

5. Готовятся тесты, проверяющие исключительные ситуации, недопустимые

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

Функциональное тестирование дополняется здесь структурным. Классы вх/вых данных должны быть определены в плане тестирования уже во внешней спецификации. Согласно статистике, 1 и 2 пункты обеспечивают степень охвата С1 в среднем 40-50%. Проверка по С1 (пункт 3) обычно выявляет 90% всех ошибок, найденных при тестировании. Все программное обеспечение ВВС США принимается с проверкой по С1. На практике, для менее ответственных программ, ограничиваются функциональ-ным тестированием, особенно при независимом тестировании.

Примеры систематического функционального тестирования:

· Полный набор тестов для Excel 4.0 - около 12000 последовательностей команд по 5-20 команд в каждой (1996, MS Europe Division, Dublin).

· Стандартный набор тестов для приемо-сдаточных испытаний трансляторов с языка Ада: 1200 коротких программ с исходными данными и ожидаемыми результатами. Более 200 компиляторов для разных машин были приняты с такими испытаниями.

Аксиомы тестирования по Майерсу [1]

1. Тест должен быть направлен на обнаружение ошибки, а не на подтверждение правильности программы.

2. Автор теста – не автор программы.

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

4. Необходимо предсказывать ожидаемые результаты теста до его выполнения и анализировать причины расхождения результатов.

5. После каждого исправления ошибки нужно повторять тест(ы), ее обнаруживший.

6. Следует повторять полное тестирование после каждого внесения исправлений и изменений в программу или после переноса ее в другую среду.

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

Пункты 5 и 6 называют регрессионным тестированием. Исправление может не устранить ошибку, а может и породить новые ошибки. По статистике эффективности исправления ошибок, 10% неудачных исправлений – это очень хороший показатель; 25% - средний, а в сложных проектах зафиксированы гораздо большие значения, вплоть до 80%. Требование п. 6 – слишком сильное; на практике прогон полного набора тестов (или его представительного подмножества) производится не после каждого исправления, а после их серии – цикла тестирования. В больших проектах проходят 10-30 таких циклов, синхронизированных с различными стадиями готовности продукта.

Этапы и стратегии тестирования

Автономное тестирование модулей выполняется по мере их готовности.

Комплексное, или интеграционное тестирование допускает три стратегии:

§ Восходящее тестирование применяется последовательно к постепенно наращиваемым снизу-вверх совокупностям модулей. Оно требует написания специальных кодов-оболочек (отладочных программ) и заглушек, подменяющих еще не готовые модули.

§ Нисходящее тестирование, наоборот, начинается с интеграции модулей верхнего уровня. Оно не требует специальных отладочных программ, но заглушки нужны.

Обычно стратегия тестирования согласована со стратегией разработки.

§ Целостное тестирование – «разовый штурм»: до полной интеграции системы ее модули не проходят особо тщательного тестирования. Это наиболее экономная стратегия (не нужны заглушки и оболочки), но в целом наименее эффективная.

Документирование и анализ ошибок

Вариант структуры отчета об ошибке (Вug report), рекомендуемой в [2]:

<А. Пункты, заполняемые сотрудником, обнаружившим ошибку >

№ ошибки

Программа (с указанием версии и даты выпуска)

Тип отчета (1- 6)

1. Ошибка кодирования

2. Ошибка проектирования

3. Предложение

4. Расхождение с документацией

5. Взаимодействие с аппаратурой

6. Вопрос

Степень важности (1-3)

1. Фатальная

2. Серьезная

3. Незначительная

Приложения (да/нет)

Распечатки результатов, копии экрана, тестовые программы или данные.

Проблема

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

Воспроизводимость (да, нет, не всегда)

Подробное описание проблемы и способ ее воспроизведения

Описание входных данных и действий, приводящих к ошибке. Если ошибка не воспроизводится, описание попыток воспроизвести ее снова.

Предлагаемое исправление (необязательный пункт)

Сотрудник (фамилия)

Дата обнаружения

(Отчет об ошибке следует составлять немедленно при ее обнаружении.)

<Б. Пункты, предназначенные в основном для разработчиков>

Функциональная область Категория ошибки с точки зрения разработчиков

Поручено Ответственный за исправление (заполняется руководителем проекта)

Комментарии Поле для обсуждения сотрудниками

Состояние (1-2)

1. Открыто (начальное состояние при написании отчета)

2. Закрыто (устанавливается тестером, подтверждающим исправление)

Приоритет (1-6) заполняется руководителем проекта

1. Исправить немедленно – ошибка задерживает работу остальных

2. Исправить как можно быстрее

3. Исправить в текущей версии

4. Исправить до выхода окончательной версии

5. Исправить, если возможно

6. Не обязательно исправлять

Резолюция (1-6)

1. Рассматривается (устанавливается руководителем проекта)

2. Исправлено (устанавливается программистом)

3. Не воспроизводится (устанавливается программистом)

4. Отложено (устанавливается руководителем проекта)

5. Соответствует проекту (устанавливается программистом или руководителем проекта)

6. Нужна дополнительная информация (у программиста есть вопросы к тестеру)

Исправленная версия № и дата версии

Рассмотрено/дата Сотрудник, решивший проблему

(он устанавливает резолюцию «Исправлено»)

Проконтролировано/дата Тестер, согласный с резолюцией

(он устанавливает состояние «Закрыто»)

Исходное состояние отчета – «Открыто». В состояние «Закрыто» его переводит тестер, проверивший исправление или согласившийся с резолюцией «Соответствует проекту». На рис. 10-4 приведена диаграмма состояний и переходов пункта «Резолюция», где у каждого перехода указано, кто его инициирует.

Рук. проекта Рук. проекта

Рук. проекта

Тестер

		Отложено
		Исправле- но
	Соответст- вует проекту			Не воспро- изводится или Есть вопросы

Тестер Руков. Тестер Программист

проекта

Рис. 10-4. Диаграмма состояний и переходов пункта «Резолюция» отчета об ошибке

В безбумажной системе отчеты накапливаются в базе данных коллективного доступа (существуют специальные системы управления ими, напр., Bugzilla). Такая база данных является ядром системы отслеживания проблем и управления качеством продуктов.

Литература

1. Майерс. Тестирование программ. М., Мир, 1984.

2. С.Канер, Д.Фолк, Е.Нгуен. Тестирование программного обеспечения. Киев, ДиаСофт, 2000.