Методы тестирования ПО ПРОЦЕСС ТЕСТИРОВАНИЯ Содержание лекции

Методы тестирования ПО ПРОЦЕСС ТЕСТИРОВАНИЯ

Содержание лекции 3 1. Процесс тестирования 2. Организация группы тестирования

Тестирование – это процесс “Testing is not a chaotic process! It mustn, t be chaotic!” (C. Kaner)

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

Часть жизненного цикла проекта Ø Прогнозирующие модели (Водопад, Прототипирование, RAD, Инкрементное построение, Спираль) Ø Адаптивные жизненные циклы (ASD, XP, SCRUM)

Каскадная модель

Спиральная модель

Итеративная модель

Тестирование в ЖЦ проекта

Этапы процесса тестирования 1. 2. 3. 4. 5. 6. 7. 8. Анализ требований Планирование тестирования Подготовка тестового окружения Тест-дизайн (написание тестов) Проверка (в том числе по разработанным тестам) Создание отчета по тестированию Работа с ошибками (проверка исправленных, заведение новых) Анализ

Треугольник тестирования

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

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

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

Системное тестирование Основная задача системного тестирования - выявление дефектов, связанных с работой системы в целом: Ø Ø Ø Ø отсутствующая или неверная функциональность неверное использование ресурсов системы непредусмотренные комбинации данных пользовательского уровня несовместимость с окружением непредусмотренные сценарии использования неудобство в применении и тому подобное. Системное тестирование производится над проектом в целом с помощью метода «черного ящика»

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

Приемочное тестирование (Acceptance testing) - тестирование готового продукта конечными пользователями в реальном окружении. Приемочные тесты разрабатываются пользователями (обычно в виде сценариев).

Проблемы процесса тестирования Ø Ø Ø Искать все ошибки или грубейшие? Если не все, то как установить порог допустимости ошибки? Когда завершать тестирование? Что делать, если сроки поджимают и/или нет ресурсов на дальнейшее тестирование? Где остановиться в документировании тестов? Изменять тест или следовать первоначальной инструкции?

Риски тестирования

Цена ошибки Ошибки в ПО - все возможные несоответствия между демонстрируемыми характеристиками его качества и сформулированными или подразумеваемыми требованиями и ожиданиями пользователей. 4. 06. 1996 через 39 сек. после запуска ракеты-носителя Ariane 5 произошёл автоподрыв 50 -метровой ракеты (оборудование стоило полмиллиарда долларов, не говоря об “упущенной выгоде”). Причина - некорректный перенос из ПО Ariane 4 в ПО Ariane 5 спецификации программного модуля. Ракета Ariane 4 успешно запускалась более 100 раз. 21

Найденные ошибки vs вероятность обнаружения

Баг или фича?

Эффект Пестицида

Кто эти люди? ОТДЕЛ ТЕСТИРОВАНИЯ

Структура группы тестирования 1 2 3 4 Ведущий тестировщик Тест-менеджер Начальник отдела тестирования Менеджер группы независимой верификации и аттестации Тестировщики Ведущие Тест-менеджер (1 -4) тестировщики (1 -2) Тестировщики (4 -8) Ведущие тестировщики (3 -5) Тестировщики (10 -20) Ведущий тестировщик группы независимой верификации и аттестации Специалисты по верификации и аттестации (1 -4)

Составляющие успеха группы тестирования Ø Ø Ø Ø Ø Знание бизнес-процессов Технические знания Разграничения задач Управления ресурсами Взаимодействие с группой разработки Привлечение тестировщиков на раннем этапе ЖЦ Выбор методологии тестирования Гибкость и применимость Метрики Совершенствование процесса

Структура отдела в Транзасе Руководитель отдела, заместитель руководителя отдела Ведущий тестировщик Ведущий тестировщик Зам. ведущего 5 -7 тестировщиков 5 -7 тестировщиков

Взаимовыручка – наша сила! ØПоддерживаемое дублирование компетенций внутри группы ØОграниченное межгрупповое дублирование компетенций Единые стандарты работы в отделе: ØПонятийные ØПринципы ведения документирования ØПроцедуры, описывающие процесс ØИнструментарий

Пожар!

Руководитель отдела q. Общая постановка процесса и его изменение q. Проведение политик отдела, общие процедуры и тп q. Метрики q. Инструментарий q. Ресурсный менеджер: üПерераспределение ресурсов между группами üПодбор персонала üОбучение üРешение разнообразных конфликтов (ресурсов, на уровне групп, департаментов, межличностных) q. Другие технологические задачи

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

Тестировщики ü ü ü ü Принимает участие в митингах по проекту Разрабатывает и записывает Test Cases Выполняет тесты, составляет отчеты, проверяет исправленные баги При любых проблемах связанных с тестированием обращается к руководителю группы тестирования Оценивает результаты тестирования Ведет багтрекинговую систему Автоматизирует Test Cases (при необходимости) сообщает о результатах тестирования руководителю группы тестирования

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