Тестирование программного обеспечения. Цели и задачи тестирования

1.

Тестирование программного обеспечения
ЦЕЛИ И ЗАДАЧИ ТЕСТИРОВАНИЯ ПО

2.

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

3.

1. Целью тестирования является обнаружение
ошибок
в
тестируемом
объекте,
а
не
доказательство их отсутствия.
2. Тестировщики не отвечают за качество. Они
помогают тем, кто за него отвечает.
3. Тестирование даёт тем большую экономическую
отдачу, чем на более ранних стадиях работы над
проектом оно выявило дефект.
4. Тестирование имеет смысл прекращать тогда,
когда устранены все критические и 85% и более
некритических
дефектов
программы,
т.к.
дальнейшее тестирование, как правило, является
неоправданной статьёй расходов.

4.

Несколько определений
Дефект (баг, глюк; defect, bug) – любое несоответствие
фактического
и
ожидаемого
результата
(согласно
требованиям или здравому смыслу).
Тест-кейс (test case) – набор входных данных, условий
выполнения и ожидаемых результатов, разработанный с
целью проверки того или иного свойства или поведения
программного средства.
Тест-план (test plan) – часть проектной документации,
описывающая и регламентирующая процесс тестирования.
Билд (build) – промежуточная версия программного средства
(финальный бил часто называют релизом (release)).

5.

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

6.

Продукты, подвергаемые тестированию
Тестировать можно (и нужно!):
Программы при их непосредственном запуске и исполнении (software).
Код программ без запуска и исполнения (code).
Прототип программного продукта (product prototype).
Проектную документацию (project documentation):
Требования к программному продукту (product requirements).
Функциональные спецификации к программному продукту (functional
specifications).
Архитектуру (architecture) и дизайн (design).
План проекта (project plan) и тестовый план (test plan).
Тестовые случаи сценарии (test cases, ).
Сопроводительную документацию (и документацию для пользователей):
Интерактивную помощь (on-line help).
Руководства по установке (Installation guide) и использованию
программного продукта (user manual).
Проверка соответствия программы требованиям, осуществляемая
путем наблюдения за ее работой в специальных, искусственно
созданных ситуациях, выбранных определенным образом.

7.

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

8.

План Тестирования (Test Plan) - это документ, описывающий весь объем
работ по тестированию, начиная с описания объекта, стратегии,
расписания, критериев начала и окончания тестирования, до
необходимого в процессе работы оборудования, специальных знаний, а
также оценки рисков с вариантами их разрешения.
Тест дизайн (Test Design) - это этап процесса тестирования ПО, на
котором проектируются и создаются тестовые случаи (тест кейсы), в
соответствии с определёнными ранее критериями качества и целями
тестирования.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность
шагов, конкретных условий и параметров, необходимых для проверки
реализации тестируемой функции или её части.
Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию
или последовательность действий приведшую к некорректной работе
объекта тестирования, с указанием причин и ожидаемого результата.
Каждый тест определяет:
- свой набор исходных данных и условий для запуска программы;
- набор ожидаемых результатов работы программы.

9.

КАЧЕСТВО ПО
Для того, что бы понять, что
требованиям
пользователя
и/или
верификацию и валидацию.
продукт соответствует
заказчика
применяют
Верификация отвечает на вопрос: «Соответствует ли продукт
требованиям?», а валидация: «Можно ли использовать продукт
для определенных целей?»
Верификация – это процесс оценки системы или её компонентов с
целью определения удовлетворяют ли результаты текущего этапа
разработки условиям, сформированным в начале этого этапа. Т.е.
выполняются ли наши цели, сроки, задачи по разработке проекта,
определенные в начале текущей фазы.
Валидация – это определение соответствия разрабатываемого ПО
ожиданиям и потребностям пользователя, требованиям к системе.

10.

КЛАССИФИКАЦИЯ ТЕСТИРОВАНИЯ ПО
Статическое тестирование (static testing) - это процесс анализа самой
разработки программного обеспечения, иными словами – это тестирование
без запуска программы (проверка кода, требований, функциональной
спецификации, архитектуры, дизайна и т.д.)
Примерами ошибок, которые потенциально можно выявить с помощью
автоматического статического тестирования, могут быть:
• утечки ресурсов (утечки памяти, неосвобождаемые файловые дескрипторы
и т.д.)
• возможность переполнения буфера (buffer overflows)
• ситуации частичной (неполной) обработки ошибок
Динамическое тестирование (dynamic testing) - это тестовая деятельность,
предусматривающая эксплуатацию (запуск) программного продукта.
• Оно делится на несколько подтипов: тестирование белого ящика,
тестирование черного ящика, а иногда выделяют и тестирование серого
ящика.
• Эта классификация уже относится к методам тестирования, т.е. как
именно тестируют программу.

11.

Сравнение методов
• Достоинство статических методов состоит в сравнительно
небольшом количестве необходимых ресурсов. Однако их
реализация может содержать непредсказуемый процент брака
(нереализуемых путей). Кроме того, в этих системах переход от
покрывающего множества путей к полной системе тестов
пользователь должен осуществить вручную (трудоемко).
• Динамические методы требуют значительно больших ресурсов
как при разработке, так и при эксплуатации, однако увеличение
затрат происходит, в основном, за счет разработки и
эксплуатации аппарата определения реализуемости пути
(символический интерпретатор, решатель неравенств).
Достоинство этих методов заключается в том, что их продукция
имеет некоторый качественный уровень - реализуемость путей.
Методы реализуемых путей дают самый лучший результат.
11

12.

МЕТОДЫ ТЕСТИРОВАНИЯ
Метод белого ящика (white-box testing, glass-box testing) –
тестирование, при котором тестировщик имеет доступ к коду. Его
еще называют тестированием стеклянного ящика или
тестированием прозрачного ящика..
Тесты основаны на знании кода приложения и его внутренних
механизмов.
Метод белого ящика часто используется на стадии, когда
приложение ещё не собрано воедино, но необходимо
проверить каждый из его компонентов, модулей, процедур и
подпрограмм.

13.

МЕТОДЫ ТЕСТИРОВАНИЯ
Метод чёрного ящика (black-box testing) заключается в том,
что тестировщик имеет доступ к ПО только через те же
интерфейсы, что и заказчик или пользователь.
Тестирование чёрного ящика ведётся с использованием
спецификаций или иных документов, описывающих требования
к системе на основе применения пользовательского
интерфейса для ввода входных и получения выходных данных.
Цель данного метода – проверить работу всех функций
приложения на соответствие функциональным требованиям.
Метод серого ящика (gray box testing) – совокупность подходов из
методов белого и чёрного ящика.
Этот метод, как правило, используется при тестировании вебприложений, когда тестировщик знает принципы функционирования
технологий, на которых построено приложение, но может не видеть
кода самого приложения.

14.

Метод белого ящика
• Модель программы в виде "белого ящика"
предполагает знание исходного текста программы
или спецификации программы в виде потокового
графа управления.
• Структурная информация понятна и доступна
разработчикам подсистем и модулей приложения,
поэтому данный вид тестирования часто
используется на этапах модульного и
интеграционного тестирования (Unit testing,
Integration testing).
• Структурные критерии тестирования базируются на
основных элементах управляющего графа
программы - операторах, ветвях и путях.
14

15.

Управляющий граф программы
Управляющий граф программы (УГП) отображает поток управления
программы. Это граф G(V, A), где V(V1,… Vm) – множеств вершин
(операторов), A(A1,… An) – множество дуг (управлений), соединяющих
вершины.
Путь – последовательность вершин и дуг УГП, в которой любая дуга
выходит из вершины Vi и приходит в вершину Vj
Ветвь – путь(V1, V2, … Vk), где V1 - либо первый, либо условный
оператор, Vk - либо условный оператор, либо оператор выхода из
программы, а все остальные операторы – безусловные.
Число путей в программе может быть не ограничено (пути,
различающиеся хотя бы числом прохождений цикла – разные). Ветви линейные участки программы, их конечноe число.
Существуют реализуемые и нереализуемые пути в программе, в
нереализуемые пути в обычных условиях попасть нельзя.
15

16.

Реализуемые и нереализуемые пути
float Calc(float x, float y) {
float H;
1 if (x*x+y*y+2<=0)
2 H = 17;
3 else H = 64;
4 return H*H+x*x; }
16

17.

Пример
/* Функция вычисляет неотрицательную
степень n числа x */
1 double Power(double x, int n){
2 double z=1; int i;
3 for ( i = 1;
4
i <= n;
5
i++ )
6
{ z = z*x; } /* Возврат в п.4 */
7 return z;
}
Управляющий граф
программы
примеры путей: (3,4,7), (3,4,5,6,4,5,6), (3,4), (3,4,5,6)
примеры ветвей: (3,4) (4,5,6,4) (4,7)
17

18.

Структурные критерии
Используются на этапах модульного и интеграционного тестирования
(Unit testing, Integration testing).
• Тестирование команд (критерий С0) - набор тестов в совокупности
должен обеспечить прохождение каждой команды не менее одного
раза.
• Тестирование ветвей (критерий С1) - набор тестов в совокупности
должен обеспечить прохождение каждой ветви не менее одного раза.
• Тестирование путей (критерий С2) - набор тестов в совокупности
должен обеспечить прохождение каждого пути не менее 1 раз. Если
программа содержит цикл (в особенности с неявно заданным числом
итераций), то число итераций ограничивается константой.
• Тестирование условий - покрытие всех булевских условий в
программе. Критерии покрытия решений (ветвей - С1) и условий не
заменяют друг друга, поэтому на практике используется
комбинированный критерий покрытия условий/решений, совмещающий
требования по покрытию и решений, и условий.
18

19.

2)x > 17
Пример
3)x = 17 - x
4)x = -13
1
2
3
4
5
6
public void Method (ref int x) {
if (x>17)
x = 17-x;
if (x==-13)
x = 0;
}
5)x = 0
критерий команд (C0):
(вх, вых) = {(30, 0)} - все операторы трассы 1-2-3-4-5-6
критерий ветвей (C1):
(вх, вых) = {(30, 0),
(17, 17)}
критерий путей (C2):
(вх, вых) = {(30,0), (17,17),
(-13,0), (21,-4)}
Условия операторов if
(30,0)
(17,17)
(-13,0)
(21,-4)
2 if (x>17)
>
<=
<=
>
4 if (x==-13)
=
!=
=
!=
19

20.

Недостаток структурных критериев
• Критерий ветвей С2 проверяет программу более
тщательно, чем критерии - C1, однако даже если он
удовлетворен, нет оснований утверждать, что программа
реализована в соответствии со спецификацией.
Например, если спецификация задает условие, что|x|<100,
невыполнимость которого можно подтвердить на тесте
(-177,-177).
• Структурные критерии не проверяют
соответствие спецификации, если оно не отражено в
структуре программы. Поэтому при успешном тестировании
программы по критерию C2 мы можем не заметить ошибку,
связанную с невыполнением некоторых условий
спецификации требований.
20

21.

Метод черного ящика
Функциональное тестирование (functional testing) –
процесс
проверки
программного
обеспечения,
сконцентрированный на анализе соответствия ПО
требованиям
и
спецификациям.
Функциональное
тестирование
ещё
называют
поведенческим
или
тестированием на поведенческом уровне.
Цели функционального тестирования:
Обнаружить дефекты в программном продукте.
Определить степень соответствия программного
продукта требованиям и ожиданиям заказчика.
Принять решение о возможности передачи продукта
заказчику.

22.

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

23.

При функциональном тестировании различают следующие
методы формирования тестовых наборов:
• эквивалентное разбиение;
• анализ граничных значений;
• анализ причинно-следственных связей;
• предположение об ошибке
Тестирование «черного ящика» обеспечивает поиск
следующих категорий ошибок:
1) некорректных или отсутствующих функций;
2) ошибок интерфейса;
3) ошибок во внешних структурах данных или в доступе к
внешней базе данных;
4) ошибок характеристик (необходимая емкость памяти и
т. д.);
5) ошибок инициализации и завершения.

24.

Разбиение по эквивалентности
В этом способе входная область данных программы делится на классы
эквивалентности. Для каждого класса эквивалентности разрабатывается один
тестовый вариант.
Класс эквивалентности — набор данных с общими свойствами. Обрабатывая
разные элементы класса, программа должна вести себя одинаково.
Например, если спецификация задает в качестве допустимых входных величин 5разрядные целые числа в диапазоне 15 000...70 000, то класс эквивалентности
допустимых ИД (исходных данных) включает величины от 15 000 до 70 000, а
два класса эквивалентности недопустимых ИД составляют:
- числа меньшие, чем 15 000;
- числа большие, чем 70 000.
Класс эквивалентности включает множество значений данных, допустимых или
недопустимых по условиям ввода.
Условие ввода может задавать:
1) определенное значение;
2) диапазон значений;
3) множество конкретных величин;
4) булево условие.

25.

1. Если условие ввода задает диапазон п...т, то определяются один допустимый и два
недопустимых класса эквивалентности:
- V_Class={n.. .т} — допустимый класс эквивалентности;
- Inv_С1аss1={x|для любого х: х < п} — первый недопустимый класс эквивалентности;
- Inv_С1аss2={y|для любого у: у > т} — второй недопустимый класс эквивалентности.
2. Если условие ввода задает конкретное значение а, то определяется один допустимый и два
недопустимых класса эквивалентности:
- V_Class={a};
- Inv_Class1 ={х|длялюбого х: х < а};
- Inv_С1аss2={y|для любого у: у > а}.
3.Если условие ввода задает множество значений {а, b, с}, то определяются один допустимый и
один недопустимый класс эквивалентности:
q V_Class={a, b, с};
q Inv_С1аss={x|для любого х: (х а)&(х b)&(х с)}.
4. Если условие ввода задает булево значение, например true, то определяются один
допустимый и один недопустимый класс эквивалентности:
q V_Class={true};
q Inv_Class={false}.
После построения классов эквивалентности разрабатываются тестовые варианты. Тестовый
вариант выбирается так, чтобы проверить сразу наибольшее количество свойств класса
эквивалентности.

26.

Анализ граничных значений
Как правило, большая часть ошибок происходит на границах области ввода, а не в
центре.
Основные отличия анализа граничных значений от разбиения по эквивалентности:
1) тестовые варианты создаются для проверки только ребер классов
эквивалентности;
2) при создании тестовых вариантов учитывают не только условия ввода, но и
область вывода.
Сформулируем правила анализа граничных значений.
1. Если условие ввода задает диапазон п...т, то тестовые варианты должны быть
построены:
- для значений п и т;
- для значений чуть левее п и чуть правее т на числовой оси.
Например, если задан входной диапазон -1,0...+1,0, то создаются тесты для
значений - 1,0, +1,0, - 1,001, +1,001.
2. Если условие ввода задает дискретное множество значений, то создаются
тестовые варианты:
- для проверки минимального и максимального из значений;
- для значений чуть меньше минимума и чуть больше максимума.
Так, если входной файл может содержать от 1 до 255 записей, то создаются тесты
для 0, 1, 255, 256 записей.

27.

3. Правила 1 и 2 применяются к условиям области вывода.
Рассмотрим пример, когда в программе требуется выводить таблицу
значений. Количество строк и столбцов в таблице меняется. Задается
тестовый вариант для минимального вывода (по объему таблицы), а
также тестовый вариант для максимального вывода (по объему
таблицы).
4. Если внутренние структуры данных программы имеют предписанные
границы, то разрабатываются тестовые варианты, проверяющие эти
структуры на их границах.
5. Если входные или выходные данные программы являются
упорядоченными множествами (например, последовательным файлом,
линейным списком, таблицей), то надо тестировать обработку первого
и последнего элементов этих множеств.
Большинство разработчиков используют этот способ интуитивно. При
применении описанных правил тестирование границ будет более
полным, в связи с чем возрастет вероятность обнаружения ошибок.

28.

Диаграммы причинно-следственных связей
способ проектирования тестовых вариантов, который обеспечивает
формальную запись логических условий и соответствующих действий.
Используется автоматный подход к решению задачи.
Шаги способа:
1) для каждого модуля перечисляются причины (условия ввода или
классы эквивалентности условий ввода) и следствия (действия или
условия вывода). Каждой причине и следствию присваивается свой
идентификатор;
2) разрабатывается граф причинно-следственных связей;
3) граф преобразуется в таблицу решений;
4) столбцы таблицы решений преобразуются в тестовые варианты.

29.

Пример, когда программа выполняет расчет оплаты за электричество по среднему или
переменному тарифу.
При расчете по среднему тарифу:
при месячном потреблении энергии меньшем, чем 100 кВт/ч, выставляется фиксированная
сумма;
при потреблении энергии большем или равном 100 кВт/ч применяется
процедура А планирования расчета.
При расчете по переменному тарифу:
- при месячном потреблении энергии меньшем, чем 100 кВт/ч, применяется
процедура А планирования расчета;
- при потреблении энергии большем или равном 100 кВт/ч применяется
процедура В планирования расчета.
Причинами являются:
1) расчет по среднему тарифу;
2) расчет по переменному тарифу;
3) месячное потребление электроэнергии меньшее, чем 100 кВт/ч;
4) месячное потребление электроэнергии большее или равное 100 кВт/ч.
На основе различных комбинаций причин можно перечислить следующие следствия:
- 101 — минимальная месячная стоимость;
- 102 — процедура А планирования расчета;
- 103 — процедура В планирования расчета.
Ограничение Е (устанавливает, что Е должно быть
истинным, если хотя бы одна из причин — а или b —
принимает значение 1 (а и b не могут принимать значение 1
одновременно).
Ограничение О (одно и только одно) устанавливает, что одна
и только одна из величин а или b должна быть равна 1.

30.

При генерации причины рассматриваются как условия,
а следствия — как действия.
Порядок генерации.
1. Выбирается некоторое следствие, которое должно
быть в состоянии «1».
2. Находятся все комбинации причин (с учетом
ограничений), которые устанавливают это следствие
в состояние «1». Для этого из следствия
прокладывается обратная трасса через граф.
3. Для каждой комбинации причин, приводящих
следствие в состояние «1», строится один столбец.
4. Для каждой комбинации причин доопределяются
состояния всех других следствий. Они помещаются в
тот же столбец таблицы решений.

31.

Функциональные критерии
• Функциональный критерий - важнейший для
программной индустрии критерий тестирования. Он
обеспечивает, прежде всего, контроль степени
выполнения требований заказчика в программном
продукте. Поскольку требования формулируются к
продукту в целом, они отражают взаимодействие
тестируемого приложения с окружением.
• При функциональном тестировании преимущественно
используется модель "черного ящика" (см. остальную
часть курса).
• Проблема функционального тестирования - это,
прежде всего, трудоемкость.
31

32.

Частные виды функциональных критериев
1. Тестирование пунктов спецификации - набор тестов в совокупности
должен обеспечить проверку каждого тестируемого пункта не менее
одного раза.
2. Тестирование классов входных данных - набор тестов в
совокупности должен обеспечить проверку представителя каждого
класса входных данных не менее одного раза.
3. Тестирование правил - набор тестов в совокупности должен
обеспечить проверку каждого правила, если входные и выходные
значения описываются набором правил некоторой грамматики.
4. Тестирование классов выходных данных - набор тестов в
совокупности должен обеспечить проверку представителя каждого
выходного класса
5. Тестирование функций - набор тестов в совокупности должен
обеспечить проверку каждого действия, реализуемого тестируемым
модулем, не менее одного раза ("полупрозрачный ящик«).
6. Комбинированные критерии для программ и спецификаций
32

33.

Стохастические критерии
Стохастическое тестирование применяется при тестировании сложных
программных комплексов. Когда набор детерминированных тестов
(X,Y) имеет громадную мощность и его невозможно разработать и
исполнить, можно применить следующую методику:
• Разработать программы-имитаторы случайных последовательностей
входных сигналов {x}.
• Вычислить независимым способом значения {y} для соответствующих
входных сигналов {x} и получить тестовый набор (X,Y).
• Протестировать приложение на тестовом наборе (X,Y), используя два
способа контроля результатов:
• Детерминированный контроль - проверка соответствия
вычисленного значения значению, полученному в результате
прогона теста на наборе {x}.
• Стохастический контроль - проверка соответствия множества
значений, полученного в результате прогона тестов на наборе
входных значений {x}, заранее известному распределению
результатов F(Y). В этом случае множество Y неизвестно (его
вычисление невозможно), но известен его закон распределения.
33

34.

Cтатистические методы окончания
тестирования
Cтатистические методы окончания тестирования - стохастические
методы принятия решений о совпадении гипотез о распределении
случайных величин. К ним принадлежат: метод Стьюдента (St), метод
Хи-квадрат (χ2) и т.п.
Метод оценки скорости выявления ошибок - основан на модели
скорости выявления ошибок, согласно которой тестирование
прекращается, если оцененный интервал времени между текущей
ошибкой и следующей слишком велик для фазы тестирования
приложения.
34

35.

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

36.

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ
Тестирование производительности (performance testing) – проверяет
способность программы выполнять заданное количество операций в заданный
промежуток времени:
• Нагрузочное тестирование (load testing) – проверяет способность
приложения работать при запланированной нагрузке.
• Стресс-тестирование (stress testing) – обычно используется для
понимания пределов пропускной способности приложения. Этот тип
тестирования проводится для определения надёжности системы во время
экстремальных или диспропорциональных нагрузок и отвечает на вопросы
о достаточной производительности системы в случае, если текущая
нагрузка сильно превысит ожидаемый максимум.
• Тестирование стабильности (stability/endurance/soak testing) –проводится
с целью убедиться в том, что приложение выдерживает ожидаемую
нагрузку в течение длительного времени.
• Конфигурационное тестирование – ещё один из видов традиционного
тестирования производительности. В этом случае вместо того, чтобы
тестировать производительность системы с точки зрения подаваемой
нагрузки, тестируется эффект влияния на производительность изменений в
конфигурации. Конфигурационное тестирование может быть совмещено с
нагрузочным, стресс или тестированием стабильности.

37.

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ
Тестирование удобства использования (usability testing) – проверка того,
насколько пользователю удобно и приятно работать с приложением.
Юзабилити-тестирование охватывает пять аспектов тестирования, обучаемость, эффективность, удовлетворенность, запоминаемость, и ошибки.
Тестирование безопасности (security testing)
Тестирование безопасности представляет собой ряд работ: от разработки
политики безопасности до тестирования безопасности на уровне приложения,
операционной системы и сетевой безопасности.
Тестирование безопасности может иметь различную степень покрытия:
Первичное тестирование безопасности.
Полное тестирование приложения.
Полное тестирование приложения и сервера.

38.

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ
Тестирование совместимости (compatibility testing) – проверка
того,
как
приложение
взаимодействует
с
другими
приложениями и операционной системой. В случае вебориентированных приложений особое внимание уделяется
совместимости с различными браузерами.
Инсталляционное тестирование (installation testing) –
проверка всего того, что связано с инсталляцией продукта в
систему и удалением продукта из системы.
Тестирование документации (documentation testing) – вид
тестирования, с которого начинается почти любой проект. Призвано
обнаружить ошибки в документации. Эти ошибки опасны тем, что они,
как маленький комок снега могут вызвать лавину проблем, вырастая
на более поздних стадиях работы с проектом в очень сложноустранимые и дорогостоящие последствия.

39.

ПО СТЕПЕНИ АВТОМАТИЗАЦИИ:
• Ручное
тестирование
(manual
testing)
–
тестирование без применения различных средств
автоматизации.
• Автоматизированное тестирование (automated
testing) – тестирование с применением различных
средств автоматизации.

40.

ПО СТЕПЕНИ ИЗОЛИРОВАННОСТИ
КОМПОНЕНТОВ:
Компонентное (модульное) тестирование (component/unit
testing) – тестирование отдельного модуля программного
средства (под модулем может пониматься в т.ч. отдельный
класс, метод и т.д.)
Интеграционное тестирование (integration testing) –
проверка того, как отдельные компоненты, проверенные на
предыдущем уровне, взаимодействуют друг с другом.
Системное тестирование (system/end-to-end testing) –
полная
проверка
приложения:
проверяются
как
функциональные, так и нефункциональные требования.

41.

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

42.

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

43.

Нисходящее и восходящее тестирование можно сравнить по четырем направлениям.
1.
Верификация и аттестация системной архитектуры. При нисходящем тестировании
больше возможностей выявить ошибки в архитектуре системы на раннем этапе процесса
разработки. Обычно это структурные ошибки, раннее выявление которых предполагает их
исправление без дополнительных затрат. При восходящем тестировании структура высокого
уровня не утверждается вплоть до последнего этапа разработки системы.
2.
Демонстрация системы. При нисходящей разработке незаконченная система вполне
пригодна для работы уже на ранних этапах разработки.. Аттестация проводится в начале
процесса тестирования путем создания демонстрационной версии системы. Но если система
создается из повторно используемых компонентов, то и при восходящей разработке также
можно создать ее демонстрационную версию.
3.
Реализация тестов. Нисходящее тестирование сложно реализовать, так как
необходимо моделировать программы-заглушки нижних уровней. Программы-заглушки могут
быть упрощенными версиями представляемых компонентов. При восходящем тестировании
для того, чтобы использовать компоненты нижних уровней, необходимо разработать тестовые
драйверы, которые эмулируют окружение компонента в процессе тестирования.
4.
Наблюдение за ходом испытаний. При нисходящем и восходящем тестировании
могут возникать проблемы, связанные с наблюдениями за ходом тестирования. В большинстве
систем, разрабатываемых сверху вниз, более верхние уровни системы, которые реализованы
первыми, не генерируют выходные данные, однако для проверки этих уровней нужны какиелибо выходные результаты. Испытатель должен создать искусственную среду для генерации
результатов теста. При восходящем тестировании также может возникнуть необходимость в
создании искусственной среды (тестовых драйверов) для исследования компонентов нижних
уровней

44.

Тестирование интерфейсов
Как правило, тестирование интерфейса выполняется в тех случаях, когда модули или
подсистемы интегрируются в большие системы
Ошибки в интерфейсах являются наиболее распространенными типами ошибок в сложных
системах и делятся на три класса.
1.
Неправильное использование интерфейсов. Компонент вызывает другой компонент и
совершает ошибку при использовании его интерфейса. Данный тип ошибки особенно
распространен в параметрических интерфейсах; например, параметры могут иметь
неправильный тип, следовать в неправильном порядке или же иметь неверное количество
параметров.
2.
Неправильное понимание интерфейсов. Вызывающий компонент, в который заложена
неправильная интерпретация спецификации интерфейса вызываемого компонента,
предполагает определенное поведение этого компонента. Если поведение вызываемого
компонента не совпадает с ожидаемым, поведение вызывающего компонента становится
непредсказуемым. Например, если программа бинарного поиска вызывается для поиска
заданного элемента в неупорядоченном массиве, то в работе программы произойдет сбой.
3.
Ошибки синхронизации. Такие ошибки встречаются в системах реального времени, где
используются интерфейсы разделяемой памяти или передачи сообщений. Подсистема –
производитель данных и подсистема – потребитель данных могут работать с разной
скоростью. Если при проектировании интерфейса не учитывать этот фактор, потребитель
может, например, получить доступ к устаревшим данным, потому что производитель к тому
моменту еще не успел обновить совместно используемые данные
правила тестирования интерфейсов: Просмотреть тестируемый код и составить список
всех вызовов, направленных к внешним компонентам. Разработать такие наборы тестовых
данных, при которых параметры, передаваемые внешним компонентам, принимают
крайние значения из диапазонов их допустимых значений. Использование экстремальных
значений параметров с высокой вероятностью обнаруживает несоответствия в
интерфейсах.

45.

ПО ВРЕМЕНИ ПРОВЕДЕНИЯ
ТЕСТИРОВАНИЯ:
Альфа-тестирование (alpha testing) – имитация реальной работы с системой штатными
разработчиками,
либо
реальная
работа
с
системой
потенциальными
пользователями/заказчиком.
Тестирование при приёмке (smoke testing)
Тестирование новой функциональности (newfeature testing) – проверка того, что заявленный
в данном билде новый функционал работает должным образом.
Регрессионное тестирование (regression testing) - проверка того, что внесённые в приложение
изменения не привели к потере работоспособности того, что ранее работало, и/или привели к
работоспособности того, что ранее не работало.
Тестирование при сдаче (acceptance testing)
Бета-тестирование (beta testing) – интенсивное использование почти готовой версии продукта
(как правило, программного или аппаратного обеспечения) с целью выявления максимального
числа ошибок в его работе для их последующего устранения перед окончательным выходом
(Релизом) продукта на рынок, к массовому потребителю. Кроме того, открытие бетатестирования может использоваться как стратегия: продвижение продукта на рынок, т.к.
реклама, а также получение предварительных отзывов.
В отличие от альфа-тестирования, проводимого силами штатных разработчиков или
тестировщиков, бета-тестирование предполагает привлечение добровольцев из числа
обычных будущих пользователей, которым доступна упомянутая предварительная версия
продукта (так называемая бета-версия).

46.

ПО ПРИЗНАКУ ПОЗИТИВНОСТИ
СЦЕНАРИЕВ:
• Позитивное тестирование (positive testing) –
проверка того, как приложение работает в заведомо
“тепличных условиях” (корректные данные, условия
работы и т.п.)
• Негативное тестирование (negative testing) –
проверка того, как приложение реагирует на
различные “неприятности” (пропала сеть, повреждён
файл, введены некорректные данные и т.п.)
Ожидаемый результат (expected result) – такое
поведение программного средства, которое мы
ожидаем в ответ на наши действия.

47.

ПО СТЕПЕНИ ПОДГОТОВЛЕННОСТИ К
ТЕСТИРОВАНИЮ:
• Тестирование по документации (formal testing) –
тестирование
по
заданному
плану,
по
разработанным чек-листам и тест-кейсам.
• Тестирование
ad
hoc
или
интуитивное
тестирование (ad hoc testing) – в данном случае
тестировщик пытается поставить себя на место
пользователя или просто решает «Как можно
сломать программу?». При таком тестировании план
тестировщик держит в голове или делает для себя
пометки.

48.

Психологические аспекты тестирования
Хороший
тестировщик
должен
обладать следующими
психологическими качествами:
• Повышенной ответственностью.
• Хорошими коммуникативными навыками.
• Способностью ясно, быстро, чётко выражать свои мысли.
• Исполнительностью.
• Терпением, усидчивостью, внимательностью к деталям,
наблюдательностью.
• Гибким мышлением, хорошей способностью к обучению.
• Хорошим абстрактным и аналитическим мышлением.
• Способностью ставить нестандартные эксперименты.
• Высокими техническими навыками.
• Склонностью к исследовательской деятельности.

49.

Технические навыки тестировщика
Тестировщик (в идеале) должен знать следующие
технологии:
Программирование: C/C++/C#, Java, Object Pascal,
Visual Basic, JavaScript, VBScript, HTML, .NET.
Администрирование СУБД: Oracle, MS SQL, IBM
DB2, Sybase, Informix.
Системное администрирование: Windows, Sun
Solaris, HP-UX, IBM AIX, Linux, Free BSD.
Сетевое администрирование: NetWare, Cisco IOS,
TCP/IP, IPX/SPX, NetBIOS.
Автоматизированное
тестирование:
Segue
SilkTest
and
SilkPerformer,
Mercury
Interactive
WinRunner, Quick Test Pro and LoadRunner, JUnit, HTTP
Unit.