Лекция 1. Введение в функциональное тестирование. Общие сведения, примеры презентация

Введение Введение Основные понятия и определения Жизненный цикл ПО и место тестирования в ЖЦ Методы тестирования Обзор видов тестирования Разбиение тестирования на этапы План тестирования Построение тестовой модели Введение в тестовые требования Создание тестовых сценариев и наборов сценариев Выполнение тестирования Различные методы проведения тестирования Работа с дефектами

ОТК должен быть независимым и могущественным. ОТК должен быть независимым и могущественным. Он не должен отчитываться перед отделом разработки. В идеале, начальник ОТК должен иметь право вето на выпуск продукта, который не прошёл успешного освидетельствования.

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

Введение Введение Цель тестирования Причина тестирования Объект тестирования Стратегия тестирования Углубление по видам тестирования Планируемые результаты тестирования Ресурсы Требования к тестированию (тестовые требования)

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

Основные функции Основные функции Структурная схема Назначение компонентов Список систем, с которыми интегрируется Обоснование необходимости разработки эмуляторов (если необходимо)

Виды тестирования Виды тестирования Сложности тестирования Ограничения тестирования Риски тестирования Критерии окончания тестирования

Документы, являющиеся результатом тестирования Документы, являющиеся результатом тестирования Отчет о тестировании Bug reports Полученные значения настроек Выводы о готовности системы к эксплуатации

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

По структуре По структуре Плоская Иерархическая По подробности Поверхностная Детальная

Достоинства: Достоинства: Легко найти интересующее требование (или понять, что оно отсутствует) Структура требований отражает структуру программы, что облегчает определение уровня качества отдельных модулей ПО Недостатки Тяжело читается в печатном виде Очень тяжело читается в печатном виде

Распределение времени поверхностной модели требований: Распределение времени поверхностной модели требований:

Ограничение функциональности Ограничение функциональности Рост детализации

Функциональные Функциональные Нефункциональные К ресурсам К безопасности К производительности К отказоустойчивости К масштабируемости К документации

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

Функциональные и нефункциональные требования к ПО Функциональные и нефункциональные требования к ПО Ограничения, изложенные в проектных документах Архитектурные особенности IT окружения ПО Общие принципы разработки ПО Эргономика Безопасность

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

Риск – ущерб, вызванный ошибкой * вероятность возникновения ошибки Риск – ущерб, вызванный ошибкой * вероятность возникновения ошибки Как определить ущерб и вероятность ошибки?

Высокий ущерб – бизнес функция с двумя и более критериями «высокий ущерб»; или двумя или более критериями «средний ущерб» и одним критерием «высокий ущерб» Высокий ущерб – бизнес функция с двумя и более критериями «высокий ущерб»; или двумя или более критериями «средний ущерб» и одним критерием «высокий ущерб» Средний ущерб – бизнес функция с двумя и более критериями «средний ущерб» без критерия «высокий ущерб»; или одним критерием «средний ущерб», одним критерием «высокий ущерб» и несколькими критериями «низкий ущерб» Низкий ущерб – любые другие комбинации

Наиболее вероятно– бизнес функция с двумя и более критериями «Наиболее вероятно»; или двумя или более критериями «Вероятно» и одним критерием «Наиболее вероятно» Наиболее вероятно– бизнес функция с двумя и более критериями «Наиболее вероятно»; или двумя или более критериями «Вероятно» и одним критерием «Наиболее вероятно» Вероятно– бизнес функция с двумя и более критериями «Вероятно» без критерия «Наиболее вероятно»; или одним критерием «Наиболее вероятно», одним критерием «Вероятно» и несколькими критериями «Почти не вероятно» Низкий риск – любые другие комбинации

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

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

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

В таблице ниже каждой из этих переменных отводится отдельный столбец. В эти столбцы помещены значения из различных классов эквивалентности рассматриваемых переменных. Каждая строка таблицы представляет собой описание конкретного теста. В таблице ниже каждой из этих переменных отводится отдельный столбец. В эти столбцы помещены значения из различных классов эквивалентности рассматриваемых переменных. Каждая строка таблицы представляет собой описание конкретного теста.

Классификация по типу Классификация по типу ошибки в функциональности ошибки эргономики модуля или бизнес-процесса ошибки документирования ошибки производительности ошибки локализации ошибки совместимости ошибки безопасности Степени критичности Максимальная критичность Высокая критичность Нормальная критичность Низкая критичность

Можно привести два отношения к найденным ошибкам на примере автомобильной промышленности: Можно привести два отношения к найденным ошибкам на примере автомобильной промышленности: принцип Форда (GM) принцип Таичи Оно (Taiichi Ohno, Toyota)

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

Принцип Оно Принцип Оно Над десятилетиями казавшейся незыблемой американской автомобильной «большой тройкой» - Genaral Motors, Ford и Chrysler — нависла опасность. В 2003 г. впервые в истории японская Toyota продала в Америке больше автомобилей, чем американские производители. Западных менеджеров и экономистов всегда интересовали секреты эффективности японских производителей.

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

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