ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 2008, v.2.6 Тест-дизайн

Почему чем позже, тем дороже? Тест-дизайн 2 Удельная стоимость исправления дефектов быстро растет по мере продвижения продукта к стадии эксплуатации. Так, в статье B. Boehm and V. Basili «Software Defect Reduction Top 10 List» (IEEE Computer, IEEE Computer Society, Vol. 34, No.1, January 2001, pp ) показано, что стоимость исправления дефекта после ввода системы в эксплуатацию вдвое превышает аналогичную стоимость на стадии тестирования продукта и более чем в тысячу раз в период выработки требований к продукту.

Стоимость исправления ошибок Тест-дизайн 3 Задачи тестирования ПО – снизить стоимость разработки путем раннего обнаружения дефектов; Тест дизайн – самая ранняя фаза, на которой тестирование врезается в разработку

Сколько это будет стоить исправить? Тест-дизайн 4 Невозможно представить себе разработку ПО, которое было бы свободно от тех или иных ошибок. По данным, опубликованным Национальным институтом стандартов (NIST 2002 RTI Project ), основное количество ошибок в продукте (70%!) закрадывается на стадии выработки требований и построения дизайна. А обнаруживается подавляющее большинство дефектов либо в процессе тестирования (около 60%), либо уже при эксплуатации (21%).

АВТОРСКИЙ КОЛЛЕКТИВ Вячеслав Панкратов Дмитрий Лысенко Тест-дизайн

РАСПИСАНИЕ: I день Входное анкетирование Качество информационных систем Процесс тестирования ПО Место практики «Тест-дизайн» Обзор роли: дизайнер тестов Связь проектных артефактов Тест, тестовый набор, покрытие, стратегия Работа с требованиями II день Техники тестирования Практика Финальное анкетирование

СОДЕРЖАНИЕ КУРСА Процесс тестирования ПО и место практики «Тест-дизайн» Преимущества и недостатки методов тест дизайна Определение роли дизайнера тестов: зона ответственности Активности разработки/дизайна тестов Практические соображения работы с требованиями Обзор артефактов тест дизайнера Практические примеры

БАЗОВЫЕ ПОНЯТИЯ Качество информационных систем Процесс тестирования ПО Тест-дизайн: определение и практика Место практики «Тест-дизайн» Связь проектных артефактов Тест-дизайн8

Характеристики качества ПО Тест-дизайн 9 Функциональность, надежность, производительность Надежность работает ли приложение без сбоев, «зависаний» или вызова исключений Функциональность делает ли приложение то, что от него требуется Производительность работает ли приложение с приемлемой скоростью при доступе к нему многих пользователей

Эволюция представлений о тестировании Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004] Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц. [С. Kaner, 1999] Это не действие. Это интеллектуальная дисциплина, имеющая целью получение надежного программного обеспечения без излишних усилий на его проверку. [B. Beizer. Software Testing Techniques, Second Edition. NY:van Nostrand Reinhold, 1990] Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов. [ANSI/IEEE standard : Glossary of SE Terminology. NY:IEEE, 1987] Процесс выполнения программы с намерением найти ошибки. [Г.Майерс. Надежность программного обеспечения. М:Мир, 1980] Тест-дизайн

Определение: Тестирование ПО Тест-дизайн 11 Тестирование ПО – процесс проверки соответствия заявленных к продукту требований и реально реализованной функциональности, осуществляемый путем наблюдения за его работой в искусственно созданных ситуациях и на ограниченном наборе тестов, выбранных определенным образом

Место тестирования в процессе разработки ПО 12 Анализ требований Спецификации (Specification) Программная архитектура (Software Architecture) Поддержка Анализ требований Планирование процесса тестирования Поддержка Программирование (Coding) Проектирование тестов Отладка тестов Выполнение тестов (testing cycles) Системное тестирование (System testing) Приемочные испытания (Acceptance Testing) Development Process Testing Process Версия (build) Результат (test result)

Тестирование программного продукта Проектирование тестов Анализ требований Планирование процесса тестирования Изучение спецификаций, функциональных требований к системе. Получение данных для составления плана проведения тестирования Определение объемов тестирования, подходов, ресурсов и расписание выполнения намеченных действий Определение цели тестирования, спецификации входных данных, архитектуры тестов для упорядочивания тестов по группам Стадии статического тестирования >> Стадии тестирования 13

Стадии тестирования 14 Отладка тестов Выполнение тестов (testing cycles) Системное тестирование (System Testing) Приемочные испытания (Acceptance Testing) Эксплуатация и поддержка Стадии динамического тестирования Непосредственная проверка спроектированных тестов, анализ всевозможных тестовых случаев Функциональная проверка, тестирование для определения рабочих характеристик Альфа-тестирование, Бета-тестирование Проверка результатов, исправление дефектов. Пересмотр и отладка тестовых случаев

BUC-UC-TC и другие страшные слова Тест-дизайн 15 BUC/BR – business use case или business rule, бизнес- требование или бизнес-правило UC – use case, сценарий использования TC – test case, сценарий тестирования

Тест-дизайн 16 Определение и практика Тест-дизайн – это этап процесса тестирования ПО, который включает создание/проектирование тестовых сценариев и определение необходимых типов тестов, для достижения заданного уровня тестового покрытия приложения или системы под тестом Тест-дизайн – это техника, кардинально влияющая на стоимость тестирования, так как задаёт объёмы работ и границы проекта по тестированию Тест-дизайн – это попытка найти баланс между трудозатратами на тестирование и приемлемым уровнем доверия к результатам тестирования

ОБЗОР РОЛИ: ДИЗАЙНЕР ТЕСТОВ Круг ответственности Круг активностей Артефакты роли Тест-дизайн

Тестирование в картинках (RUP) 18 Тест-дизайн

Тест дизайн в картинках (RUP) 19

Тест-аналитик: внимание, совмещаем! Тест-дизайн 20 Определяет, приоритизирует и обеспечивает разработку тестовых случаев Ответственность: Разрабатывает модель тестирования Оценивает эффективность тестирования

Тест-дизайнер Тест-дизайн 21 Устанавливает и определяет операции, атрибуты и связи тестовых классов Ответственность: Устанавливает и определяет тестовые классы Устанавливает и определяет тестовые наборы (пакеты)

Обзор артефактов тестирования Аналитик Test Case Test-Ideas List Workload Analysis Model Test Data Test results Дизайнер Test Strategy Test Automation Architecture Test Environment Configuration Test Suite Тест-дизайн22

ТЕСТ, ТЕСТОВЫЙ НАБОР, СТРАТЕГИЯ Определения Тест, тестовый набор, тестовое покрытие Стратегия тестирования Тест-дизайн23

Определение теста и тестового набора Тест-дизайн 24 Тест – последовательность действий, которая переводит систему из одного состояния в другое Триплет ISO, где: I - is input data or action (входные данные или действия) S - is State of system at which data will be input (состояние системы, которая получает входные данные или воздействие) O - is the expected Output (ожидаемые Выход, выходные данные или выходной состояние системы)

Определение теста и тестового набора Тест-дизайн 25 Тестовый набор Набор тестов, реализующих бизнес-задачу, выполняемую тестируемой системой Тестовый набор включает кроме тестовых сценариев еще и тестовые данные или правила их генерации

Определение теста и тестового набора Тест-дизайн 26 Разработка тестовых сценариев – практические соображения Формальные методы разработки тестовых сценариев На основе сценариев использования На основе ортогональной классификации дефектов Формальные методики оценки объемов работ Метод расчета цикломатической сложности, основанный на метрике МакКаби (McCabe) Смешанные методики – комбинация подходов

Тестовое покрытие 27 Requirements-based Test Coverage Метрика покрытия, основанная на анализе тестовых требований, Собирается несколько раз в течении одного цикла тестирования для анализа завершенности тестирования Вычисляется как соотношение всех запланированных, имплементированных и выполненных тестовых случаев к количеству тестовых требований, существующих для тестового цикла Тест-дизайн

Тест дизайн, как этап тестирования Тест-дизайн 28 На этапе тест-дизайна выясняется и определяется – Список тестируемых функций и модулей – Тестируемость каждой функции и модуля – Наиболее оптимальный подход (техника) для проверки каждой функции, модуля или подсистемы – Набор типов тестов – Последовательность проведения и критерии завершенности тестирования Основные артефакты: тест кейс и стратегия тестирования ПО

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

Типы тестирования: целостность данных Тест-дизайн Цель: убедиться в невозможности создания «несвязных данных» - данных, которые могут быть созданы-отредактированы-агрегированы при нормальной работе системы или при возникновении сбоев в работе. Обращайте внимание: На включение-отключение триггеров и ограничений при импорте-экспорте данных На включение-отключение триггеров и ограничений при переводе системы в production режим На включение-отключение триггеров и ограничений при операциях архивирования и завершении бизнес-циклов На поведение системы относительно данных при разрывах соединений клиент-сервер-БД в любых сочетаниях 30

Типы тестирования: функциональное тестирование Тест-дизайн 90% нашего с вами рабочего времени Проверка функциональных требований: логики и бизнес-правил приложения или системы Как правильно полноценное системное/функциональное тестирование является самым трудоёмким процессом и может занимать (Ф.Брукс) до 80% всего бюджета проекта по тестированию Обращайте внимание: На невозможность полного покрытия – всегда надо выбирать На необходимость постоянно отслеживать приоритетность требований от версии к версии: требования меняются, приоритеты тоже 31

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

Типы тестирования: GUI, usability Тест-дизайн Обычно данный тип тестирования не обладает формальным признаком запрета выпуска версии Результатом выполнения данного типа тестов является список рекомендаций и предложений по улучшению Основной для проведения данного типа тестов могут являться принятые в компании/проекте стандарты оформления пользовательских интерфейсов или общепринятые User Interface Guidelines: Например, Microsoft Windows XP/2000 User Interface Guidelines 33

Типы тестирования: производительность Тест-дизайн Производительность: способность совершать определённое количество операций в единицу времени Тестирование производительности: нормальная, ожидаемая модель нагрузки Нагрузочное: предельная или превышающая нормальную модель нагрузки Стрессовое тестирование: сознательное превышение нагрузок или урезание ресурсов с целью посмотреть «как будет падать и подниматься» Объёмное тестирование: тестирование способности обработки больших объёмов операционных или хранения архивных данных 34

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

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

Типы тестирования: тестирование инсталляций Тест-дизайн Школа жизни для тестировщика Современные инсталляции умеют очень глубоко залазить в систему и на лету менять её компоненты Развёртывание – вариант инсталляции Инсталляция – отдельное и потенциально достаточно сложное приложение, которое требует отельного планирования и выполнения тестов Для тестирования инсталляций характерно выделять отдельный список поддерживаемых окружений и проводить отдельный цикл конфигурационного тестирования 37

РАБОТА С ТРЕБОВАНИЯМИ Работа с изменяющимися требованиями Пример нетестируемого требования Пример тестопригодного требования Почему не все могут и должны заниматься дизайном

Что было написано в требовании Тест-дизайн 39 SRS-01 (до изменения) – Форма регистрации нового пользователя в системе InfoSecurityManagement позволяет вводить в реестр пользователей данные о пользователе и его роли: Имя, Доменное имя, Должность, Полномочия в системе

Что изменилось в требовании Тест-дизайн 40 SRS-01.1 (после изменения) – Форма регистрации нового пользователя в системе InfoSecurityManagement позволяет вводить в реестр пользователей данные о пользователе и его роли: Имя, Доменное имя, Должность, Полномочия в системе – Если такой пользователь уже существует в реестре системы InfoSecurityManagement, на форме ввода появляется его E- mail адрес.

Практический кейс Что должно произойти в тест-кейсах? Кто это должен сделать? Когда это может происходить? Вы уверены, что ваш рядовой тестер понимает глубину задачи? Тест-менеджмент41

Работа с требованиями 42 Пример нетестируемого требования производительности ПО – Время отклика системы должно находится в приемлемых рамках – Время отклика (Отклика на какой операции?) системы (что такое система в этом требовании: UI, DB, client + server + network?) должно находится (Условия? Нагрузка?) в приемлемых рамках (Цифры?)

Работа с требованиями 43 Пример тестопригодного требования – Время отклика системы с точки зрения конечного пользователя (end-to-end) во время продуктивной нагрузки (50 пользовательских сессий в режиме « менеджер » / 15 пользовательских сессий в режиме « аналитик » ) при загруженности пропускного канала от клиентской системы до сервера приложений в пределах 50% для сети 100 Mb/sec и утилизации ресурсов сервера приложений (CPU, RAM) в рамках 70-80%, а клиентской машины в рамках %, не должно превышать 1 секунды для операций создания записи (сущности) и 3 секунд для операций поиска. – Время выполнения аналитических отчётов определяется отдельно для каждого отчёта

Работа с требованиями 44 Что мы упустили в требовании? – Время отклика … при загруженности пропускного канала …, не должно превышать 1 секунды … время выполнения … Что с ресурсами?.. Какими они должны быть?

Работа с требованиями 45 Пример тестопригодного требования – Время отклика системы с точки зрения конечного пользователя (end-to-end) во время продуктивной нагрузки (50 пользовательских сессий в режиме « менеджер » / 15 пользовательских сессий в режиме « аналитик » ) при загруженности пропускного канала от клиентской системы до сервера приложений в пределах 50% для сети 100 Mb/sec, не должно превышать 1 секунды для операций создания записи и 3 секунд для операций поиска записи. – Время выполнения аналитических отчётов определяется отдельно для каждого отчёта. – Объём используемой оперативной памяти должен оставаться стабильным.

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

Работа с требованиями 47 Практические соображения – При условии « плавающих » требований, анализ покрытия производится по факту поставки версии системы, в которую включается набор актуальных требований. Данный подход увеличивает общее время отведённое на тестирование за счёт технологических простоев – Каждое требование должно быть протестировано (иметь тест) – Каждый тест должен относиться к какому-либо требованию

Работа с требованиями 48 Практические соображения – Требования могут порождаться тестами (при использовании agile-методологий) – Требования обязательно должны находиться под версионным контролем

ЭКВИВАЛЕНТНОЕ РАЗБИЕНИЕ Что значит «протестировать полностью»? Классы эквивалентности Виды тестовых сценариев Тест-дизайн

Что значит « протестировать полностью » ? 50

Полное тестирование это – 51 Когда покрыты все: строки кода программы ветви кода в программе пути в коде входные данные и все их возможные комбинации последовательности комбинаций входных данных...

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

Виды тестовых сценариев 53 Позитивные сценарии Негативные сценарии Граничные сценарии Исследовательские сценарии: «А что должно быть если…»

54 Чтобы избежать ненужного тестирования, разбейте область входных значений на группы эквивалентных тестов Два теста считаются эквивалентными если они настолько похожи, что проводить оба бессмысленно Техники тестирования. Эквивалентное разбиение

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

56 Рассмотрим пример – Программа складывает два целых числа – Каждое из слагаемых – не более чем целое двузначное число – Программа запрашивает у пользователя два числа и выводит результат Предлагайте тесты >> Техники тестирования. Эквивалентное разбиение

Классы эквивалентности Классы корректных данных Классы некорректных данных Граничные и специальные значения Первое слагаемое от -99 до -10 от -9 до -1 0 от 1 до 9 от 10 до 99 > 99 < -99 0, 1, -1, 9, -9 10, , , -100 Второе слагаемое --- Суммаот -198 до -100 от -99 до -1 0 от 1 до 99 от 100 до 198 > 198 < -198 (-99, -99) (-49, -51) (99, 99) (49, 51) 57

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

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

« Треугольник » Программа запрашивает три числа Определяется тип треугольника, имеющего стороны введенной длины: равносторонний, равнобедренный, разносторонний Предлагайте тесты >> Практические примеры 60 Техники тестирования. Эквивалентное разбиение

Корректный разносторонний треугольник Корректный равносторонний треугольник Три корректных равнобедренных треугольника (a=b, b=c, a=c) Одна, две или три стороны равны нулю (5 тестов) Одна сторона отрицательная «Почти» выполняется правило треугольника (три варианта a+b=c, a+c=b, b+c=a) Не выполняется правило треугольника (три варианта a+b

ТЕСТИРОВАНИЕ НА ОСНОВЕ СЦЕНАРИЕВ И РИСКОВ Пользователь прежде всего Немного agile и экстрима Когда страшно это хорошо Тест-дизайн

Техники: тестирование на основе сценариев 63 Суть метода – тестировщик выполняет сценарии пользователей Разновидности сценариев: – Истории пользователя – Варианты использования (use cases) – Тестовые сценарии (test cases)

64 Сценарии могут использоваться как в разработке, так и в тестировании При использовании их в тестировании – Тестировщики следуют сценариям, которые использовались при разработке – Создают новые сценарии путем комбинации имеющихся Техники: тестирование на основе сценариев

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

Техники: тестирование на основе рисков 66 Подходы к тестированию на основе рисков Приоритезация требований в соответствии с оценкой рисков; проверка требований соглано приоритетам Приоритезация проблемных областей в соответствии с оценкой рисков; целенаправленный поиск ошибок определенного типа

Техники: тестирование на основе рисков 67 Как понять что такое «рискованная область» Рисуем схему приложения – Сайт бронирования билетов Определяем веса узлов и переходов Контролируем основные и альтернативные пути «Где тонко – там и рвётся»

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

Техники тестирования. Проблемы выбора 69 Контрольные вопросы при использовании комбинации техник тестирования: – Какие области наиболее рискованы? Как будут приоритезированы требования? – Какие есть сценарии использования для этих областей? – Какие параметры есть у этих сценариев? – На какие классы эквивалентности их можно разбить? – И наконец: какие тест-кейсы нужно составить?

Практические примеры 70 Описание тестируемого функционала: Поле для ввода названия папки Кнопка «Сохранить» Название папки не должно превышать 64 символа Ваши предложения?

Практический пример 71 Диалог сохранения файла

«Фиксируем шаги» 72 Сначала выделяем наиболее рискованные (и важные) области – собственно сохранение, выбор нужного места, сохранение с длинным именем, с национальными символами, перезапись и т.п. Потом выясняем какие сценарии использования (use case) Выясняем классы эквивалентности Пишем тест-кейсы (позитивные, негативные, исследовательские)

Способы снижения количества тестов 73 Рассмотрим пример Окно поиска в текстовом редакторе

Подсчитаем количество тестов 5 переменных: – Find what (FW) – строка – Match whole words only (MW) – Boolean – Match case (MC) – Boolean – Regular expression (RE) – Boolean – Direction (D) – перечисляемый тип (Up, Down) Тестовые значения – FW = { lower ; UPPER ; MiXeD } – MW, MC, RE = {Yes; No} – В = {Up; Down} Итого: 3 х 2 х 2 х 2 х 2 = 48 тестов

Способы снижения количества тестов 75 Выбор комбинаций Для данного случая методы выбора на основе рисков и на основе сценариев малопригодны Оптимальнее использовать механический перебор по некоторой системе: – Полный перебор – Все пары (каждый с каждым) – Все значения хотя бы по разу

Способы снижения количества тестов 76 Полный перебор (все Nки) FWMWMCRED 1LYYYUp 2UYYY 3MYYY 4LYYY 5LNYY ……………… 47MNNNUp 48MNNND

Способы снижения количества тестов 77 Все значения хотя бы по разу FWMWMCRED 1LYNYUp 2UNYND 3MYYN 3 теста, а не 48

Способы снижения количества тестов 78 Все пары (каждый с каждым) FWMWMCRED 1LYNYUp 2LNYND 3UYYN 4UNNYD 5MNNN 6MYYYD Этот метод является « золотой серединой » Метод « всех пар » хорошо работает для независимых переменных Зачастую случайное тестирование хорошо приближается к методу « всех пар »

Тест управляемый данными Форма валидации введенного значения Требование: если введено целочисленное значение от 0 до 9 (включительно), возвращается значение TRUE Предлагайте тесты (я записываю) Тест-дизайн79

Тест управляемый поведением Форма заказа sushi Требование: пользователь может оформить или отредактировать сформированный ранее в разделе «Меню» заказ. Счёт формируется с учётом накопительных скидок, выбранного способа оплаты и доставки. Предлагайте тесты (я записываю) Тест-дизайн80

«Фиксируем подход» Разработка тестов Определение типа теста: «поведение» или «данные» Logic-driven или data-driven test case Если тест управляется логикой поведения Составление путей и «узлов» Определяется основной «путь» Определяются и ограничиваются альтернативные «пути» Если тест управляется данными Составляется набор данных Данные приоретезируются Допустимые значения Граничные значения Значения за границами диапазона Тест-дизайн81

Практические примеры Тест-дизайн82 Входные данные Бизнес по продаже апельсинов, имеющий несколько представительств в различных городах. Задача Разобраться в системе и разработать пакет тестовых сценариев

Практические примеры Тест-дизайн83

Анализ архитектуры Архитектура Сервер приложений Сервер БД «Толстые» клиенты, около 10 операторов Тест-дизайн84 Первые выводы и вопросы Большинство операций происходит на стороне клиента Тестируем клиентскую часть и сервер приложений Сервер приложения может работать со своей БД и с БД центрального отделения БД не содержит никакой логики – только хранилище?

Анализ конфигурационных требований Требования к конфигурациям Клиентская часть поддерживается на 4-х ОС Сервер приложения поддерживается на 2-х ОС Локализация – система поддерживает два языка На тестирование выносится 20 функциональных требований к клиентской части и 10 функциональных требований к серверной части Тест-дизайн85

Пытаемся планировать Вопросы к обсуждению Какие виды тестов будем проводить? Нагрузочного тестирования не будет, 10 операторов – это не та нагрузка, которую стоит проверять (или будет?) Что стоит автоматизировать, что нет? Какие окружения выделяем для тестирования? Тест-дизайн86

Попробуем прикинуть трудоёмкость Допущения Допустим, на одно функциональное требование мы предполагаем написать 5 тестовых сценариев Допустим, на прохождение 1-го тестового сценария мы предполагаем потратить 5 минут Посчитайте сами и ответьте на следующие вопросы: Сколько всего окружений получается? Сколько всего тестовых сценариев будет в системе? Время затраченное на проведение 1-го раунда тестирования? Тест-дизайн87

Считаем окружения Окружений: 16 4 клиентские ОС * 2 языка = 8 клиентских конфигураций * 2 серверные ОС = 16 окружений Тестовых сценариев в системе: 150 (20 клиентских требований + 10 серверных требований) * 5 тестовых сценариев на одно требование = 150. Сколько всего тестовых сценариев для проведения 1-го раунда тестирования? Тест-дизайн88

Считаем время Расчеты Всего тестовых сценариев: 16 окружений * 150 тестовых сценариев = 2400 Время на проведение 1-го раунда тестирования: (2400 тестовых сценарев * 5 минут) / 60 = 200 часов или 5 недель Тест-дизайн89

Давайте подумаем Что мы не учли? Требования относятся к функциональности (логике приложения) или к окружению (системные функции, работа с ресурсами ОС и т.д.). Тест-дизайн90

Разбор тестируемых функций Что зависит обычно от окружения на клиенте и сервере? Вход, выход, печать форм, получение языка ОС, получение цветовой гаммы ОС, работа с протоколами общения между серверами приложений Что не зависит от окружения? Получение информации из БД, запрос на сервер приложения, анализ полученных данных на клиенте и т.д. Тест-дизайн91

Подбиваем баланс по группам требований Получаем: 5 требований зависят от окружений на клиенте 5 требований зависят от всех окружений 5 требований зависят только от окружений сервера приложений 15 требований относятся к функциональности и не зависят от окружений Тест-дизайн92

Пересчитываем Итого: 25 тестовых сценариев * 8 = 200 тестовых сценариев зависящих от окружения на клиенте 25 тестовых сценариев * 16 = 400 тестовых сценариев зависящих от всех конфигураций 25 тестовых сценариев * 2 = 50 тестовых сценариев зависящих от окружения на сервере приложений 75 тестовых сценариев относятся к функциональным тестам = 725 тестовых сценариев Тест-дизайн93

Сила тест-дизайна Расчеты Всего тестовых сценариев: 725 Время на проведение 1-го раунда тестирования: (725 тестовых сценариев * 5 минут) / 60 = 60,5 часов или 1,5 недели Было: 200 часов или 5 недель Стало: 60,5 часов или 1,5 недели Экономия достигается за счёт принимаемых допущений и связанных с ними рисков Тест-дизайн94

Введение в тестирование программного обеспечения Луиза Тамре Introducing Software Testing Издательство: Вильямс, 2003 г. В этой книге изложены: Последовательность вхождения в процесс тестирования с акцентом на ключевых функциях; Определение недостающих сведений и проведение адекватного тестирования при недостаточно четких требованиях; Изучение различных форматов документации для регистрации тестовых примеров. Рекомендуемая литература

Быстрое тестирование Роберт Калбертсон, Крис Браун, Гэри Кобб Издательство: Вильямс, 2002 г. Технология быстрого тестирования находит `золотую середину` между соблюдением сроков и гарантией высокого качества. Описанию этой технологии и посвящена книга. Книга написана с учетом громадного опыта работы авторов в области тестирования ПО. Она окажет несомненную пользу всем специалистам, которые работают как в крупных, так и в небольших организациях, занимающихся созданием ПО. Рекомендуемая литература

Тест-дизайн 97 Тестирование dot com Роман Савин Издательство: Дело, 2007 г. Этот курс лекций создан для тех, кто хочет обучиться тестированию, понять, как вести себя в корпоративном окружении, и добиться профессионального и личностного роста. Он будет интересен и участникам процесса разработки программного обеспечения, рекрутерам, людям, связанным с интернетом или пишущим о нем, и просто всем желающим понять кухню интернет-стартапов

Слава Панкратов «Тест-дизайн» icq: