'

Тест-дизайн

Понравилась презентация – покажи это...





Слайд 0

Тестирование программного обеспечения 2008, v.2.6 Тест-дизайн


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

Авторский коллектив Вячеслав Панкратов http://pankratov.org.ua/ Дмитрий Лысенко http://dmitrylysenko.info/ Тест-дизайн


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 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 610.12-1990: Glossary of SE Terminology. NY:IEEE, 1987] Процесс выполнения программы с намерением найти ошибки. [Г.Майерс. Надежность программного обеспечения. М:Мир, 1980] Тест-дизайн 10 1980 1987 1990 1999 2004


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

Обзор роли: дизайнер тестов Круг ответственности Круг активностей Артефакты роли Тест-дизайн


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

Тест, тестовый набор, стратегия Определения Тест, тестовый набор, тестовое покрытие Стратегия тестирования Тест-дизайн 23


Слайд 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 (ожидаемые Выход, выходные данные или выходной состояние системы)


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

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


Слайд 28

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


Слайд 29

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


Слайд 30

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


Слайд 31

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


Слайд 32

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


Слайд 33

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


Слайд 34

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


Слайд 35

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


Слайд 36

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


Слайд 37

Работа с требованиями Работа с изменяющимися требованиями Пример нетестируемого требования Пример тестопригодного требования Почему не все могут и должны заниматься дизайном


Слайд 38

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


Слайд 39

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


Слайд 40

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


Слайд 41

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


Слайд 42

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


Слайд 43

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


Слайд 44

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


Слайд 45

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


Слайд 46

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


Слайд 47

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


Слайд 48

Эквивалентное разбиение Что значит «протестировать полностью»? Классы эквивалентности Виды тестовых сценариев Тест-дизайн


Слайд 49

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


Слайд 50

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


Слайд 51

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


Слайд 52

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


Слайд 53

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


Слайд 54

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


Слайд 55

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


Слайд 56

Классы эквивалентности 57


Слайд 57

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


Слайд 58

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


Слайд 59

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


Слайд 60

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


Слайд 61

Тестирование на основе сценариев и рисков Пользователь прежде всего Немного agile и экстрима Когда страшно это хорошо Тест-дизайн


Слайд 62

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


Слайд 63

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


Слайд 64

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


Слайд 65

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


Слайд 66

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


Слайд 67

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


Слайд 68

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


Слайд 69

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


Слайд 70

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


Слайд 71

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


Слайд 72

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


Слайд 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 тестов


Слайд 74

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


Слайд 75

Способы снижения количества тестов 76 Полный перебор (все Nки)


Слайд 76

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


Слайд 77

Способы снижения количества тестов 78 Все пары (каждый с каждым) Этот метод является «золотой серединой» Метод «всех пар» хорошо работает для независимых переменных Зачастую случайное тестирование хорошо приближается к методу «всех пар»


Слайд 78

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


Слайд 79

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


Слайд 80

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


Слайд 81

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


Слайд 82

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


Слайд 83

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


Слайд 84

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


Слайд 85

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


Слайд 86

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


Слайд 87

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


Слайд 88

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


Слайд 89

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


Слайд 90

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


Слайд 91

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


Слайд 92

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


Слайд 93

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


Слайд 94

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


Слайд 95

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


Слайд 96

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


Слайд 97

Слава Панкратов «Тест-дизайн» http://pankratov.org.ua slava@pankratov.org.ua icq: 109882167


×

HTML:





Ссылка: