Слайд 1Лекция 1.
Введение в функциональное тестирование
общие сведения, примеры
Авторы: К. Хлопов, А.
Родичев, А. Александров, А. Анисимов, М. Волошинов, Д.Васильев
Тренер: С. Базуев
Слайд 2Введение
Основные понятия и определения
Жизненный цикл ПО и место тестирования в ЖЦ
Методы
тестирования
Обзор видов тестирования
Разбиение тестирования на этапы
План тестирования
Построение тестовой модели
Введение в тестовые требования
Создание тестовых сценариев и наборов сценариев
Выполнение тестирования
Различные методы проведения тестирования
Работа с дефектами
Содержание
Слайд 3Введение
Тестирование ПО, равно как и разработка ПО, является наиболее востребованной профессией
в IT сфере. Такие организации как the British Computer Society или the International Software Testing Qualifications Board (ISTQB) начали разрабатывать сертификационные уровни тестирования.
Тестировщики должны обладать знаниями, техническими навыками и определенными талантами для того, чтобы в сжатые сроки протестировать продукт таким образом, чтобы он максимально полно соответствовал потребностям Заказчика.
Тестирование не интуитивный процесс, тестировщик должен знать, как это делается.
Слайд 4Основные понятия и определения (1 из 4)
Тестирование – процесс, помогающий определить
корректность, полноту и качество разработанного программного обеспечения. Вместе с тем, тестирование никогда не может полностью установить корректность программы. Только процесс формальной проверки может доказать, что дефекты отсутствуют.
Качество - способность программы делать то, что ждет от нее пользователь.
Надежность - вероятность того, что программа будет работать без ошибок определенный промежуток времени.
Слайд 5Основные понятия и определения (2 из 4)
Тестируемость - степень, до которой
могут быть запланированы объективность и реализуемость тестирования, проверяющего соответствие требованию
Ошибка - различие между полученным и описанным или ожидаемым результатом (поведением) системы, количественный параметр неверности результата (поведения)
Дефект (fault) - возможная причина ошибки
Неисправность (failure) – неспособность системы выполнить требуемое действие, результат наличия в системе дефекта
Ошибочное действие (mistake) – действие пользователя приводящее к неверному результату
Слайд 6Основные понятия и определения (3 из 4)
Регрессионное тестирование - повторное тестирование
программы после внесения изменений, с учетом ранее заявленной функциональности и ранее обнаруженных ошибок
Среда тестирования (test environment) - инфраструктура для подготовки и проведения тестирования и интерпретации результатов
Покрытие (test coverage) – часть функционала, тестируемая данным набором проверок
Слайд 7Основные понятия и определения (4 из 4)
Валидация (validation) - проверка того,
что программа делает то, что нужно
Верификация (verification) - проверка того, что программа делает все правильно.
Позитивный тест - проверка на правильных данных, реакция на корректные действия.
Негативный тест - проверка на неправильных данных, реакция на некорректные действия
Тест кейс - выполняемый тест с конкретными входными данными, начальными условиями и ожидаемым результатом.
Pass/ Fail Criteria - установленное правило, позволяющее определить удачно или неудачно прошла система данный тест
Слайд 8Типовой пример установки заказного ПО
Слайд 9Организация процесса тестирования
ОТК должен быть независимым и могущественным.
Он не должен
отчитываться перед отделом разработки.
В идеале, начальник ОТК должен иметь право вето на выпуск продукта, который не прошёл успешного освидетельствования.
Слайд 10Важность тестирования
Большинство дефектов вносятся на этапе сбора требований и разработки
… а
обнаруживаются на стадии приемочных испытаний.
Слайд 11Важность тестирования
Стоимость исправления ошибки возрастает с каждым этапом ЖЦ
Слайд 12Принципы тестирования (Майерс)
Описание предполагаемых значений выходных данных или результатов должно быть
необходимой частью тестового набора
Следует избегать тестирования программы ее автором
Необходимо досконально изучать результаты применения каждого теста
Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных
Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и ни делает ли она то, что не должна делать
Не следует выбрасывать тесты, даже если программа уже не нужна
Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены
Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части
Тестирование - процесс творческий. Вполне вероятно, что для тестирования большой программы требуется больший творческий потенциал, чем для ее проектирования
Слайд 13Методы тестирования (1 из 4)
Белый ящик – тестирование на основе анализа
структуры кода
Серый ящик - промежуточный уровень, на котором определен интерфейс между компонентам.
Черный ящик – поведенческое тестирование, глобальное представление, основанное на спецификации.
Слайд 14Методы тестирования (2 из 4). «Белый» ящик
Данный метод включает в себя
следующие процедуры:
анализ структуры программы;
покрытие операторов;
покрытие ветвей.
Слайд 15Методы тестирования (3 из 4). «Серый» ящик
Данный метод включает в себя
следующие процедуры:
анализ архитектуры.
проверка навигации.
проверка интерфейсов.
модель событий.
Слайд 16Методы тестирования (4 из 4). «Чёрный» ящик
Данный метод включает в себя
следующие процедуры:
анализ потоков.
таблица решений.
функциональный анализ.
граничные значения.
история ошибок.
целостность данных.
диаграмма переходов состояний.
Слайд 17Задачи и виды тестирования
Функциональное тестирование (functionality)
Регрессионное тестирование (regression)
Интеграционное тестирование (integration)
Тестирование производительности
(performance)
Надежность и стрессовое тестирование (reliability)
Эргономика, удобство (usability)
Совместимость с программно-аппаратной платформой (infrastructure testing)
Тестирование документации
Тестирование поддержки (supportability)
Слайд 18Тестирование функциональности
Проверка соответствия поведения системы/подсистемы и т.д. спецификациям функциональных требований (requirements
specification)
Слайд 19Регрессионное тестирование
Проверка работоспособности базового функционала и/или тестирование повторения ошибок предыдущих версий.
При большой истории все проверки выполнить невозможно, поэтому, как правило, они выполняются выборочно.
Слайд 20Тестирование производительности
Проверка отдачи от основных процессов, контроль временных показателей системы.
Проверка
соответствия системы/подсистем критериям производительности
Скорость выполнения операций;
Время отклика;
Использование ресурсов
Слайд 21Нагрузочное и стрессовое тестирование
Проверка работы программы в условиях реальной нагрузки с
целью выявить оптимальную конфигурацию системы и «возможности» системы.
Может проводиться на большом объеме данных в условиях эмуляции реальных нагрузок или в условиях превышения планируемых нагрузок в несколько раз.
Слайд 22Тестирование эргономики
человеческий фактор;
эстетичность;
логичность в пользовательском интерфейсе;
online и контекстно-зависимая помощь;
пользовательская документация;
учебные
материалы;
Слайд 23Тестирование поддержки (supportability)
тестируемость
расширяемость (открытость)
приспособляемость
удобство сопровождения
совместимость
способность к изменению конфигурации
удобство эксплуатации
удобство инсталляции
локализуемость (глобализация)
Слайд 24Ход тестирования
Планирование
Выполнение
Анализ результатов
Представление результатов
Слайд 25Структура плана тестирования
Введение
Цель тестирования
Причина тестирования
Объект тестирования
Стратегия тестирования
Углубление по видам тестирования
Планируемые результаты
тестирования
Ресурсы
Требования к тестированию (тестовые требования)
Слайд 26План тестирования. Введение
Сертификация
Определение уровня качества продукта
Подбор аппаратных средств
Подбор настроек конфигурации окружения
Выработка
рекомендаций по оптимальному использованию
Слайд 27План тестирования. Объект тестирования
Основные функции
Структурная схема
Назначение компонентов
Список систем, с которыми интегрируется
Обоснование
необходимости разработки эмуляторов (если необходимо)
Слайд 28План тестирования. Стратегия тестирования
Виды тестирования
Сложности тестирования
Ограничения тестирования
Риски тестирования
Критерии окончания тестирования
Слайд 29План тестирования. Виды тестирования
Цель тестирования
Ход тестирования
Критерии завершения тестирования
Слайд 30План тестирования. Планируемые результаты
Документы, являющиеся результатом тестирования
Отчет о тестировании
Bug reports
Полученные значения
настроек
Выводы о готовности системы к эксплуатации
Слайд 31План тестирования. Ресурсы
Аппаратные ресурсы
Человеческие ресурсы
Программное обеспечение
Прочее
Слайд 32Тестовые требования
Требование – это формализованное описание свойств системы.
Бизнес-требования
Функциональные требования
Нефункциональные требования
Тестовые требования
Тестовое
требование – это формализованное описание свойств системы, которые необходимо протестировать.
Слайд 33Варианты построения модели требований
По структуре
Плоская
Иерархическая
По подробности
Поверхностная
Детальная
Слайд 34Плоская структура требований
Достоинства
Простота
Наглядность при печати
Недостатки
Осложненный поиск
Сложно понять, что покрыли требованиями, а
что нет
Достаточно тяжело отразить структуру программы
Слайд 35Иерархическая модель требований
Достоинства:
Легко найти интересующее требование (или понять, что оно отсутствует)
Структура
требований отражает структуру программы, что облегчает определение уровня качества отдельных модулей ПО
Недостатки
Тяжело читается в печатном виде
Очень тяжело читается в печатном виде
Слайд 36Подробность тестовых требований
Распределение времени поверхностной модели требований:
Распределение времени подробной модели требований:
Слайд 37Взаимосвязь требований к функциональности
Ограничение функциональности
Рост детализации
Слайд 38Классификация тестовых требований
Функциональные
Нефункциональные
К ресурсам
К безопасности
К производительности
К отказоустойчивости
К масштабируемости
К документации
Слайд 39Назначение тестовых требований
Инструмент анализа требований к системе с точки зрения тестирования
Исходный
документ для написания тестовых сценариев (актуальный, качественный и удобный)
Согласование объемов тестирования
Установление приоритетов тестирования на детальном уровне
Отслеживание тестового покрытия
Слайд 40Разработка тестовых требований
Выявление доступной документации описывающей систему
Получение выявленной документации
Выяснение степени актуальности
полученной документации
Изучение полученной документации
Подготовка иерархической структуры тестовых требований
Анализ полноты иерархической структуры тестовых требований
Наполнение требований описаниями
Анализ требований на предмет соответствия критериям качества и внесение изменений
Слайд 41Как получаются тестовые требования?
Функциональные и нефункциональные требования к ПО
Ограничения, изложенные в
проектных документах
Архитектурные особенности IT окружения ПО
Общие принципы разработки ПО
Эргономика
Безопасность
Слайд 42Задание №1
Необходимо подготовить небольшое эссе в форме ответов на вопросы:
Что нового
Вы узнали на лекции?
Что Вам было известно ранее?
На какие вопросы Вы ожидали получить ответ, но не получили?
Опишите назначение тестовых требований.
Опишите критерии качества тестовых требований.
Слайд 43Создание тестовых сценариев
Состав тестового сценария
Название
Описание проверок сценария
Предварительные условия
Необходимые действия
Ожидаемый результат
Полученный результат
Отметка
о прохождении
Статус прохождения
Слайд 44Пример тестового сценария
Предусловия
Windows калькулятор запущен
Вид калькулятора - научный
Шаги
Нажать кнопку “5”
Нажать кнопку
“/”
Нажать кнопку “(”
Нажать кнопку “2”
Нажать кнопку “-”
Нажать кнопку “2”
Нажать кнопку “)”
Нажать кнопку “=”
Ожидаемый результат:
Приложение корректно сообщило о невозможности деления на 0.
Проверка обработки ошибки деления на 0
Слайд 45Оптимизация тестов: баланс между риском и затратами
Риск – ущерб, вызванный ошибкой
* вероятность возникновения ошибки
Как определить ущерб и вероятность ошибки?
Слайд 47Определение ущерба
Высокий ущерб – бизнес функция с двумя и более критериями
«высокий ущерб»; или двумя или более критериями «средний ущерб» и одним критерием «высокий ущерб»
Средний ущерб – бизнес функция с двумя и более критериями «средний ущерб» без критерия «высокий ущерб»; или одним критерием «средний ущерб», одним критерием «высокий ущерб» и несколькими критериями «низкий ущерб»
Низкий ущерб – любые другие комбинации
Слайд 49Определение вероятности
Наиболее вероятно– бизнес функция с двумя и более критериями «Наиболее
вероятно»; или двумя или более критериями «Вероятно» и одним критерием «Наиболее вероятно»
Вероятно– бизнес функция с двумя и более критериями «Вероятно» без критерия «Наиболее вероятно»; или одним критерием «Наиболее вероятно», одним критерием «Вероятно» и несколькими критериями «Почти не вероятно»
Низкий риск – любые другие комбинации
Слайд 51Характеристики хорошего теста
Существует обоснованная вероятность выявления тестом ошибки
Набор тестов не должен
быть избыточным
Тест должен быть наилучшим в своей категории
Он не должен быть слишком простым или слишком сложным
Слайд 52Разработка набора тестовых сценариев
Идентификация всех значений, которые вводятся действующими субъектами, содержащимися
в модели случая использования
Выделение классов эквивалентности значений каждого типа входных данных
Построение таблиц, в которые помещен список комбинаций значений из различных классов эквивалентности
Построение тестовых случаев, в которых сочетаются одна перестановка значений с необходимыми внешними ограничениями
Слайд 53Пример классов эквивалентности
Как пример рассматривается некая система управления персоналом. В случаях
использования этой системы употребляются три переменных. Каждый служащий представлен в системе именем и переменными, показывающими, является ли он новым сотрудником фирмы или уже работает в ней в течении определенного времени, и уровнем полномочий, санкционированных системой безопасности.
В таблице показаны классы эквивалентности этих трех переменных.
Слайд 54Построение тестов (продолжение примера)
В таблице ниже каждой из этих переменных отводится
отдельный столбец. В эти столбцы помещены значения из различных классов эквивалентности рассматриваемых переменных. Каждая строка таблицы представляет собой описание конкретного теста.
Количество тестовых случаев, которые необходимо построить, зависит от значения атрибута частоты использования каждого случая использования. Один из способов оценки соответствующего числа тестовых случаев заключается в том, что вычисляется произведение количества различных входов и количества классов эквивалентности каждого типа ввода с целью получения максимального количества перестановок.
Слайд 56Выполнение тестовых сценариев
Тестировщик работает с печатным носителем
Выполнение тестов поддерживается ИС тестирования
(HP QC)
Выполнение тестов полностью автоматизировано
Варианты выполнения тестовых сценариев
Слайд 57Разбиение тестирования на стадии
Для эффективной работы тестировщик должен:
знать метод тестирования
знать тестируемое
приложение
Но неправильно считать, что тестирование осуществляется только на предоставляемых разработчиками данных. Важен накопленный опыт о тестировании подобных систем, о допущенных ранее ошибках тестирования, которые проявились на этапах тестирования и сопровождения.
Таким образом тестирование должно разбиваться на несколько стадий.
Слайд 58Стадии тестирования
Рекомендуемая последовательность проведения тестов
ознакомление с системой. Исследовательское тестирование.
базовый тест.
выявление зависимостей между данными
тестирование для различных категорий данных
граничные оценки
тестирование на ошибочных данных
попытка «сломать» систему
регрессионное тестирование
Слайд 59Ознакомление с системой
В ходе изучения тестировщик узнает, как работает система, что
представляют результаты, тип входных данных и т.п.
Формы изучения:
ознакомление по документации
по учебным материалам
привлечение специалиста (авторитетное лицо проекта)
метод «тыка»
проверка всех возможностей системы
Недостатки: принятие неверных результатов работы за верные; сложность воспроизведения ошибок
Слайд 60Базовый тест
Обычно базовый тест несложен и описывает наиболее простую и логичную
последовательность действий. Результат теста должен быть легко прогнозируемым и очевидным.
Проведение базового теста имеет ряд преимуществ:
тестируемый исследовал приложение и знаком с функционалом достаточно, чтобы написать полноценный кейс на основе базового
система настроена, система тестирования создана
большая вероятность нахождения ошибки
Слайд 61Выявление зависимостей между данными
Анализ тенденций – это необязательная стадия, необходимая если:
знакомство
с системой весьма поверхностно
входные/выходные данные содержат численные значения
неизвестны граничные значения
сложно вычислить ожидаемые результаты
имеется предположение относительно диапазона ожидаемых результатов
Слайд 62Тестирование для различных категорий данных
Стадия состоит из определения типов данных, доступных
в приложении с последующей классификацией состояний, в которых может находиться каждый элемент данных.
Тестирование должно быть построено таким образом, чтобы каждое состояние использовалось хотя бы один раз.
Тестирование должно содержать как позитивные так и негативные тесты для каждой категории.
Слайд 63Проверка граничных значений
Ошибки концентрируются на границах значений
Необходимы позитивные и негативные проверки
Продолжение
метода эквивалентных разбиений
Правило тестирования границ: граничное значение, ГЗ+1, ГЗ-1
Слайд 64Артефакты процесса тестирования
Отчеты о тестировании
История прохождения тестов
План проведения тестирования
Отчеты по дефектам
Слайд 65Критерии оценки качества ПО
Формальные
Число ошибок
Распределение серьезности ошибок
Процент нахождения ошибки (отношение общего
числа сценариев к числу непрошедших сценариев)
Неформальные
Качество пользовательской документации
Качество процедуры установки
Слайд 66Критерии завершения тестирования
устойчивая работа системы;
время и/или другие ресурсы исчерпаны;
руководство или клиент
теряют терпение;
все тесты, предусмотренные планом, проходят без ошибок;
найденные ошибки исправлены;
регрессионное тестирование проходит без ошибок;
число найденных ошибок соответствует ожидаемому.
Слайд 67Понятие и классификация ошибок
Классификация по типу
ошибки в функциональности
ошибки эргономики модуля или
бизнес-процесса
ошибки документирования
ошибки производительности
ошибки локализации
ошибки совместимости
ошибки безопасности
Степени критичности
Максимальная критичность
Высокая критичность
Нормальная критичность
Низкая критичность
Слайд 68Действия при обнаружении ошибок
Можно привести два отношения к найденным ошибкам на
примере автомобильной промышленности:
принцип Форда (GM)
принцип Таичи Оно (Taiichi Ohno, Toyota)
Слайд 69Принцип Форда
Принцип Форда
Все должно непрерывно двигаться к нам и от нас.
Заминки вызывают огромные убытки.
В организованном производстве рабочий во время работы не должен делать более одного шага и ничуть не наклоняться вперед или в стороны.
Слайд 70Принцип Оно
Принцип Оно
Над десятилетиями казавшейся незыблемой американской автомобильной «большой тройкой» -
Genaral Motors, Ford и Chrysler — нависла опасность. В 2003 г. впервые в истории японская Toyota продала в Америке больше автомобилей, чем американские производители. Западных менеджеров и экономистов всегда интересовали секреты эффективности японских производителей.
Оказалось, что весь секрет — в уникальной по эффективности организации производства. При ближайшем рассмотрении выяснилось, что японцы очень много внимания уделяют таким, казалось бы, очевидным вещам, как удовлетворение потребностей клиентов, качество продукции, экономия, исключение лишних операций.
При появлении ошибки следует сразу же найти ее причину, устранить ее и не допустить ее появления в будущем. Цель: отсутствие ошибок.
Все сотрудники и поставщики должны постоянно повышать качество продукции и совершенствовать производственный процесс.
Слайд 71Действия при обнаружении ошибок
Необходимо убедиться, что ошибка произошла не из-за ввода
тестируемым неверного значения.
Следует как более полно описать действия, которые привели к ошибке, понять, не проявляется ли ошибка на других типах данных.
Слайд 72Дефект. Атрибуты дефекта
Минимальные данные о дефекте:
краткое наименование
дата
автор (обнаруживший дефект)
ссылка на систему
и ее версию (build)
приоритет (Priority)
серьезность проблемы (Severity)
описание (предусловия, шаги для воспроизведения, ожидаемый результат, фактический результат)
состояние, статус
Слайд 73Баг-трекинг
Работа с дефектами:
Баг-трекинговые системы;
Почтовая переписка
Плюсы баг-трекинговых систем:
Дефекты не теряются
Возможность построения любой
отчётности по дефектам
Удобство работы с полной базой данных с дефектами
Слайд 75Задание №2
Необходимо составить набор тестов для проверки корректности работы следующей программы:
На
вход подается 3 целых числа, обозначающие длины сторон треугольника
Программа сообщает, является ли указанный треугольник равнобедренным или равносторонним