Кафедра «Вычислительная техника»

Факультет Автоматики и информационных технологий

 

Кафедра «Вычислительная техника»

 

 

 

 

ЛЕКЦИИ

для студентов заочной формы обучения

 

по дисциплине: «Тестирование и отладка программного обеспечения»

 

(8 часов)

основная образовательная программа по направлению подготовки (специальности): 231000 «Программная инженерия»

 

по уровню высшего образования: бакалавр

 

направленность (профиль) программы: «Программная инженерия»

Самара 2015

 

Лекция 1. Концепция и организация процесса тестирования

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

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

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

Качество программного обеспечения можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

• надёжность
• сопровождаемость,
• практичность,
• эффективность,
• мобильность,
• функциональность.

Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998.

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

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

В начале 1970-х годов тестирование программного обеспечения обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы программного обеспечения». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности — неэффективный метод тестирования программного обеспечения. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приёмо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест — это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой — выявляет ошибки в программах, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки программного обеспечения.

В 1980-е годы тестирование расширилось таким понятием, как предупреждение дефектов. Проектирование тестов — наиболее эффективный из известных методов предупреждения ошибок. В это же время стали высказываться мысли, что необходима методология тестирования, в частности, что тестирование должно включать проверки на всем протяжении цикла разработки, и это должен быть управляемый процесс. В ходе тестирования надо проверить не только собранную программу, но и требования, код, архитектуру, сами тесты. «Традиционное» тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надёжно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.

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

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

Лекция 2. Критерии и виды тестирования

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

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

• Функциональное тестирование
• Тестирование производительности
• Нагрузочное тестирование
• Стресс-тестирование
• Тестирование стабильности
• Конфигурационное тестирование
• Юзабилити - тестирование
• Тестирование интерфейса пользователя
• Тестирование безопасности
• Тестирование локализации
• Тестирование совместимости

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

• Тестирование чёрного ящика
• Тестирование белого ящика
• Тестирование серого ящика

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

• Ручное тестирование
• Автоматизированное тестирование
• Полуавтоматизированное тестирование

По степени изолированности компонентов

• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование

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

• Альфа-тестирование
• Дымовое тестирование (англ. smoke testing)
• Тестирование новой функции (new feature testing)
• Подтверждающее тестирование
• Регрессионное тестирование
• Приёмочное тестирование
• Бета-тестирование

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

• Позитивное тестирование
• Негативное тестирование

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

• Тестирование по документации (формальное тестирование)
• Интуитивное тестирование (англ. ad hoc testing)

Уровни тестирования

Модульное тестирование — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками программного обеспечения.

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

Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться программа.

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

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

Лекция 3.Особенности процесса и технологии тестирования

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

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

Тестовые сценарии

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

Покрытие кода

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

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

Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях.

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

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

Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения (покрытия) каждого оператора программы. Более сильным критерием является так называемый критерий С1: каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз.

Использование критерия покрытия условий может вызвать подбор тестов, обеспечивающих переход в программе, который пропускается при использовании критерия С1 (например, в программе на языке Паскаль, использующей конструкцию цикла WHILE х AND y DO..., применение критерия покрытия условий требует проверки обоих вариантов выхода из цикла: NOT x и NOT y). С другой стороны покрытие условий может не обеспечивать покрытия всех переходов.

Например, конструкция IF A AND B THEN... требует по критерию покрытия условий двух тестов (например, A=true, B=false и A=false, B=true), при которых может не выполняться оператор, расположенный в then - ветви оператора if. Практически единственным средством, предоставляемым современными системами программирования, является возможность определения частоты выполнения различных операторов программы. Но с помощью этого инструмента поддержки тестирования можно проверить выполнение только слабейшего из критериев полноты - покрытие всех операторов. Правда, с помощью этого же инструмента можно проверить и выполнение критерия С1. Но для этого предварительно текст программы должен быть преобразован таким образом, чтобы все конструкции условного выбора (IF, CASE или SWITCH) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма, не выполнявшиеся на данном тесте, будут “видимы” из таблицы частоты выполнения операторов преобразованной программы.

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

· накапливать информации о покрытых и непокрытых ветвях для всех использованных тестов;

· выделять разработчику еще не покрытые при тестировании участки программы, облегчая выбор следующих тестов;

· поддерживать более мощные критерии полноты структурного тестирования.

Семантическая отладка

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

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

Существует 3 способа отладки программы:

1. Пошаговая отладка программ с заходом в подпрограммы;

2. Пошаговая отладка программ с выполнением подпрограммы как одного оператора;

Документирование программы

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

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

Пример. Система тестов для задачи нахождения корней квадратного уравнения:

Квадратное уравнение — это уравнение вида

ax² + bx + c = 0, где a не равно 0.

Для решения квадратного уравнения можно использовать формулы:

и
где D = b² - 4ac — дискриминант многочлена ax² + bx + c.
Если D > 0, то уравнение имеет два различных вещественных корня.
Если D = 0, то оба корня вещественны и равны.
Если D < 0, то оба корня являются комплексными числами.

Номер теста	Проверяемый случай	Коэффициенты	Результаты
a	b	c
	d >0			-2	x1 = 1, x2 = - 2
	d=0				Корни равны: x1 = - 1, x2 = - 1
	d < 0				Действительных корней нет
	a=0, b=0, c=0				Все коэффициенты равны нулю. х — любое число.
	a=0, b=0, c<>0				Неправильное уравнение
	a=0, b<>0				Линейное уравнение. Один корень: x = - 0,5
	a <> 0, b <> 0, с = 0				x1 = 0, x2 = - 0,5

 

КОМПЛЕКТ ЗАДАНИЙ НА КОНТРОЛЬНУЮ РАБОТУ
для студентов заочной формы обучения

Тема контрольной работы: «Проектирование теста для отладки программы» одинаковая для всех студентов и различается только индивидуальными исходными данными.

Каждое задание является индивидуальным.

Контрольная работа содержит пояснительную записку, в которой приводится:

Текст программы

Тесты

Результаты тестирования.

 

Исходными данными является словесное описание некоторой процедуры обработки данных.

 

Процесс тестирования содержит три этапа:

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

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

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

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

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

Индивидуальные задания для контрольной работы

Номер задания соответствует номеру студента в списке группы.

1. Найдите наибольший общий делитель двух заданных целых чисел.

2. Найдите наименьшее общее кратное двух заданных целых чисел.

3. Определите, является ли заданное число нечетным двузначным числом.

4. Заданы площади квадрата и круга. Определите, поместится ли квадрат в круге.

5. Решите биквадратное уравнение.

6. Найдите среднее арифметическое положительных элементов заданного одномерного массива.

7. Элементы заданного одномерного массива разделите на его первый элемент.

8. Определите, лежит ли заданная точка на одной из сторон треугольника, заданного координатами своих вершин.

9. Определите, имеют ли общие точки две плоские фигуры — треугольник с заданными координатами его вершин и круг заданного радиуса c центром в начале координат.

10. Задано целое А > 1. Найдите наименьшее целое неотрицательное k, при котором 2^k > А.

11. Дана последовательность целых чисел. Определите, со скольких чётных чисел она начинается.

12. В заданном двумерном массиве найдите количество строк, не содержащих нули.

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

14. Преобразуйте число, заданное в римской системе счисления, в число десятичной системы.

15. В заданном двумерном массиве найдите сумму элементов диагонали, не содержащих нули.

16. В заданном двумерном массиве найдите сумму элементов, не содержащих нули и имеющих значение больше некоторой заданной величины М мин.

17. В заданном двумерном массиве найдите сумму элементов, не содержащих нули и имеющих значение меньше некоторой заданной величины М мах.

18. В заданном двумерном массиве найдите сумму элементов, не содержащих нули и имеющих значение больше некоторой заданной величины М мин но меньше некоторой заданной величины М мах..

19. В заданном двумерном массиве найдите процентное отношение каждого элемента в сумме элементов, не содержащих нули.

20. В текстовом файле провести проверку корректности данных, если известно, что это должны бать только целые положительные числа.

21. В текстовом файле провести проверку корректности данных, если известно, что это должны бать только слова определенной длинны.

22. В текстовом файле провести проверку корректности данных, если известно, что это должны бать только слова из букв латинского алфавита.

23. В текстовом файле провести проверку корректности данных, если известно, что это должны бать только слова из букв кириллицы.

24. В текстовом файле провести проверку корректности данных, если известно, что это должны бать только слова из заданного набора символов.

П 24. может иметь множество модификаций в зависимости от заданного набора символов

 

 

Факультет Автоматики и информационных технологий

 

Кафедра «Вычислительная техника»

 

 

 

 

ЛЕКЦИИ

для студентов заочной формы обучения

 

по дисциплине: «Тестирование и отладка программного обеспечения»

 

(8 часов)

основная образовательная программа по направлению подготовки (специальности): 231000 «Программная инженерия»

 

по уровню высшего образования: бакалавр

 

направленность (профиль) программы: «Программная инженерия»

Самара 2015

 

Лекция 1. Концепция и организация процесса тестирования

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

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

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

Качество программного обеспечения можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

• надёжность
• сопровождаемость,
• практичность,
• эффективность,
• мобильность,
• функциональность.

Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998.

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

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

В начале 1970-х годов тестирование программного обеспечения обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы программного обеспечения». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности — неэффективный метод тестирования программного обеспечения. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приёмо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест — это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой — выявляет ошибки в программах, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки программного обеспечения.

В 1980-е годы тестирование расширилось таким понятием, как предупреждение дефектов. Проектирование тестов — наиболее эффективный из известных методов предупреждения ошибок. В это же время стали высказываться мысли, что необходима методология тестирования, в частности, что тестирование должно включать проверки на всем протяжении цикла разработки, и это должен быть управляемый процесс. В ходе тестирования надо проверить не только собранную программу, но и требования, код, архитектуру, сами тесты. «Традиционное» тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надёжно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.

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

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

Лекция 2. Критерии и виды тестирования

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

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

• Функциональное тестирование
• Тестирование производительности
• Нагрузочное тестирование
• Стресс-тестирование
• Тестирование стабильности
• Конфигурационное тестирование
• Юзабилити - тестирование
• Тестирование интерфейса пользователя
• Тестирование безопасности
• Тестирование локализации
• Тестирование совместимости

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

• Тестирование чёрного ящика
• Тестирование белого ящика
• Тестирование серого ящика

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

• Ручное тестирование
• Автоматизированное тестирование
• Полуавтоматизированное тестирование

По степени изолированности компонентов

• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование

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

• Альфа-тестирование
• Дымовое тестирование (англ. smoke testing)
• Тестирование новой функции (new feature testing)
• Подтверждающее тестирование
• Регрессионное тестирование
• Приёмочное тестирование
• Бета-тестирование

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

• Позитивное тестирование
• Негативное тестирование

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

• Тестирование по документации (формальное тестирование)
• Интуитивное тестирование (англ. ad hoc testing)

Уровни тестирования

Модульное тестирование — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками программного обеспечения.

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

Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться программа.

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

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

Лекция 3.Особенности процесса и технологии тестирования