• Like
Test design print
Upcoming SlideShare
Loading in...5
×

Test design print

  • 3,790 views
Uploaded on

 

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,790
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
108
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Компания QAExpert | | 2006
  • Цикломатика
  • Исследовательские сценарии могут порождать требования. Пример с 1-01-001.
  • Два основных вопроса в тестировании: Что подать на вход? Чего ожидать на выходе?
  • Два основных вопроса в тестировании: Что подать на вход? Чего ожидать на выходе?
  • Пример с разноязычными инсталляциями
  • В чем + и – такого подхода?
  • Где выход? 
  • Пример – open dialog текстового редактора
  • Убрать нижнее??
  • 3 теста, а не 48

Transcript

  • 1. ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 200 8, 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. 135-137.) показано, что стоимость исправления дефекта после ввода системы в эксплуатацию вдвое превышает аналогичную стоимость на стадии тестирования продукта и более чем в тысячу раз — в период выработки требований к продукту.
    Тест-дизайн
  • 3. Стоимость исправления ошибок
    • Задачи тестирования ПО – снизить стоимость разработки путем раннего обнаружения дефектов;
    • Тест дизайн – самая ранняя фаза, на которой тестирование врезается в разработку
    Тест-дизайн
  • 4. Сколько это будет стоить исправить?
    • Невозможно представить себе разработку ПО, которое было бы свободно от тех или иных ошибок.
    • По данным, опубликованным Национальным институтом стандартов (NIST 2002 RTI Project 7007.011), основное количество ошибок в продукте (70%!) закрадывается на стадии выработки требований и построения дизайна.
    • А обнаруживается подавляющее большинство дефектов либо в процессе тестирования (около 60%), либо уже при эксплуатации (21%).
    Тест-дизайн
  • 5. АВТОРСКИЙ КОЛЛЕКТИВ
    • Вячеслав Панкратов
    • http://pankratov.org.ua/
    • Дмитрий Лысенко
    • http://dmitrylysenko.info/
    Тест-дизайн
  • 6. РАСПИСАНИЕ: 10.00-17.00
    • I день
      • Входное анкетирование
      • Качество информационных систем
      • Процесс тестирования ПО
      • Место практики «Тест-дизайн»
      • Обзор роли: дизайнер тестов
      • Связь проектных артефактов
      • Тест, тестовый набор, покрытие, стратегия
      • Работа с требованиями
    • II день
      • Техники тестирования
      • Практика
      • Финальное анкетирование
  • 7. СОДЕРЖАНИЕ КУРСА
      • Процесс тестирования ПО и место практики «Тест-дизайн»
      • Преимущества и недостатки методов тест дизайна
      • Определение роли дизайнера тестов: зона ответственности
      • Активности разработки/дизайна тестов
      • Практические соображения работы с требованиями
      • Обзор артефактов тест дизайнера
      • Практические примеры
  • 8. БАЗОВЫЕ ПОНЯТИЯ
      • Качество информационных систем
      • Процесс тестирования ПО
      • Тест-дизайн: определение и практика
      • Место практики «Тест-дизайн»
      • Связь проектных артефактов
    Тест-дизайн
  • 9. Характеристики качества ПО
    • Функциональность, надежность, производительность
      • Надежность — работает ли приложение без сбоев, «зависаний» или вызова исключений
      • Функциональность — делает ли приложение то, что от него требуется
      • Производительность — работает ли приложение с приемлемой скоростью при доступе к нему многих пользователей
    Тест-дизайн
  • 10. Эволюция представлений о тестировании
    • Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]
    • Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц. [ С.  Kaner, 199 9]
    • Э то не действие . Это интеллектуальная дисциплина, имеющая целью получение надежного программного обеспечения без излишних усилий на его проверку. [B. Beizer. Software Testing Techniques, Second Edition. NY : van Nostrand Reinhold, 1990]
    • Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов. [ANSI/IEEE standard 610.12-1990: G lossary of SE T erminology. NY:IEEE, 1987]
    • Процесс выполнения программы с намерением найти ошибки. [Г.Майерс. Надежность программного обеспечения. М:Мир , 1980]
    Тест-дизайн 1980 1987 1990 1999 2004
  • 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 ) Эксплуатация и поддержка Стадии динамического тестирования Непосредственная проверка спроектированных тестов, анализ всевозможных тестовых случаев Функциональная проверка, тестирование для определения рабочих характеристик Альфа-тестирование, Бета-тестирование Проверка результатов, исправление дефектов. Пересмотр и отладка тестовых случаев
  • 15. BUC-UC-TC и другие страшные слова
    • BUC/BR – business use case или business rule , бизнес-требование или бизнес-правило
    • UC – use case , сценарий использования
    • TC – test case , сценарий тестирования
    Тест-дизайн
  • 16. Тест-дизайн
    • Определение и практика
      • Тест-дизайн – это этап процесса тестирования ПО, который включает создание / проектирование тестовых сценариев и определение необходимых типов тестов, для достижения заданного уровня тестового покрытия приложения или системы под тестом
      • Тест-дизайн – это техника, кардинально влияющая на стоимость тестирования, так как задаёт объёмы работ и границы проекта по тестированию
      • Тест-дизайн – это попытка найти баланс между трудозатратами на тестирование и приемлемым уровнем доверия к результатам тестирования
    Тест-дизайн
  • 17. ОБЗОР РОЛИ: ДИЗАЙНЕР ТЕСТОВ
    • Круг ответственности
    • Круг активностей
    • Артефакты роли
    Тест-дизайн
  • 18. Тестирование в картинках (RUP) Тест-дизайн
  • 19. Тест дизайн в картинках (RUP)
  • 20. Тест-аналитик: внимание, совмещаем!
    • Определяет, приоритизирует и обеспечивает разработку тестовых случаев
    • Ответственность:
      • Разрабатывает модель тестирования
      • Оценивает эффективность тестирования
    Тест-дизайн
  • 21. Тест-дизайнер
    • Устанавливает и определяет операции, атрибуты и связи тестовых классов
    • Ответственность:
      • Устанавливает и определяет тестовые классы
      • Устанавливает и определяет тестовые наборы (пакеты)
    Тест-дизайн
  • 22. Обзор артефактов тестирования
    • Аналитик
      • Test Case
      • Test-Ideas List
      • Workload Analysis Model
      • Test Data
      • Test results
    • Дизайнер
      • Test Strategy
      • Test Automation Architecture
      • Test Environment Configuration
      • Test Suite
    Тест-дизайн
  • 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. Стратегия тестирования
      • Типы тестирования
        • Тестирование данных и целостности базы данных
        • Функциональное тестирование
        • Тестирование бизнес - циклов
        • Тестирование пользовательского интерфейса
        • Нагрузочное тестирование
        • Тестирование безопасности и управления доступом
        • Конфигурационное тестирование
        • Инсталляционное тестирование
      • Инструментальные средства
    Тест-дизайн
  • 30. Типы тестирования: целостность данных
      • Цель: убедиться в невозможности создания «несвязных данных» - данных, которые могут быть созданы-отредактированы-агрегированы при нормальной работе системы или при возникновении сбоев в работе.
      • Обращайте внимание:
        • На включение-отключение триггеров и ограничений при импорте-экспорте данных
        • На включение-отключение триггеров и ограничений при переводе системы в production режим
        • На включение-отключение триггеров и ограничений при операциях архивирования и завершении бизнес-циклов
        • На поведение системы относительно данных при разрывах соединений клиент-сервер-БД в любых сочетаниях
    Тест-дизайн
  • 31. Типы тестирования: функциональное тестирование
      • 90% нашего с вами рабочего времени
      • Проверка функциональных требований: логики и бизнес-правил приложения или системы
      • Как правильно полноценное системное / функциональное тестирование является самым трудоёмким процессом и может занимать (Ф.Брукс) до 80% всего бюджета проекта по тестированию
      • Обращайте внимание:
        • На невозможность полного покрытия – всегда надо выбирать
        • На необходимость постоянно отслеживать приоритетность требований от версии к версии: требования меняются, приоритеты тоже
    Тест-дизайн
  • 32. Типы тестирования: бизнес циклы
      • Бизнес-циклы : сущность, которая описывает и задаёт следующий уровень функционального тестирования и служит про проверки корректности работы алгоритмов и механизмов, автоматизирующих не столько пользовательские операции, сколько естественную цикличность любого бизнеса , завершающуюся отчётами, архивированием данных, выполнением нетипичных для системы операций.
      • Закрытие месяца, закрытие года, получение очередной крупнооптовой партии товаров, расчёт пени, реструктуризации долгов и т.п.
    Тест-дизайн
  • 33. Типы тестирования: GUI, usability
      • Обычно данный тип тестирования не обладает формальным признаком запрета выпуска версии
      • Результатом выполнения данного типа тестов является список рекомендаций и предложений по улучшению
      • Основной для проведения данного типа тестов могут являться принятые в компании / проекте стандарты оформления пользовательских интерфейсов или общепринятые User Interface Guidelines:
        • Например, Microsoft Windows XP/2000 User Interface Guidelines
    Тест-дизайн
  • 34. Типы тестирования: производительность
      • Производительность : способность совершать определённое количество операций в единицу времени
      • Тестирование производительности: нормальная, ожидаемая модель нагрузки
      • Нагрузочное: предельная или превышающая нормальную модель нагрузки
      • Стрессовое тестирование: сознательное превышение нагрузок или урезание ресурсов с целью посмотреть «как будет падать и подниматься»
      • Объёмное тестирование: тестирование способности обработки больших объёмов операционных или хранения архивных данных
    Тест-дизайн
  • 35. Типы тестирования: безопасность и доступ
      • Выделяют два больших типа тестов:
        • Разграничение прав доступа к данным и операциям и соотв. невозможность несанкционированного доступа к данным и выполнению операций
        • Устойчивость системы к внешним проникновениям, несанкционированным вызовам функций, инъекциям исполняемого кода, вызова нештатных ситуаций, переполнений и т.д.
      • Применяют как средства анализа кода, так и накопленную (зачастую внешнюю) экспертизу
    Тест-дизайн
  • 36. Типы тестирования: конфигурационные тесты
      • Тестирование системы на различных конфигурациях программно-аппаратного стенда
      • Цели:
        • Проверка-выявление списка поддерживаемых окружений
        • Подбор минимальных-оптимальных-рекомендуемых параметров аппаратного обеспечения
      • Обращайте внимание на составления «матрицы покрытия»
      • Очень ресурсоёмкий и затратный тип тестов
      • Относиться в основном к тестированию функциональности, но также может затрагивать и вопросы тестирования производительности
    Тест-дизайн
  • 37. Типы тестирования: тестирование инсталляций
      • Школа жизни для тестировщика 
      • Современные инсталляции умеют очень глубоко залазить в систему и на лету менять её компоненты
      • Развёртывание – вариант инсталляции
      • Инсталляция – отдельное и потенциально достаточно сложное приложение, которое требует отельного планирования и выполнения тестов
      • Для тестирования инсталляций характерно выделять отдельный список поддерживаемых окружений и проводить отдельный цикл конфигурационного тестирования
    Тест-дизайн
  • 38. РАБОТА С ТРЕБОВАНИЯМИ
    • Работа с изменяющимися требованиями
    • Пример нетестируемого требования
    • Пример тестопригодного требования
    • Почему не все могут и должны заниматься дизайном
  • 39. Что было написано в требовании
    • SRS-01 (до изменения)
      • Форма регистрации нового пользователя в системе “InfoSecurityManagement” позволяет вводить в реестр пользователей данные о пользователе и его роли:
        • Имя,
        • Доменное имя,
        • Должность,
        • Полномочия в системе
    Тест-дизайн
  • 40. Что изменилось в требовании
    • SRS-0 1.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%, а клиентской машины в рамках 40-60%, не должно превышать 1 секунды для операций создания записи (сущности) и 3 секунд для операций поиска.
      • Время выполнения аналитических отчётов определяется отдельно для каждого отчёта
  • 44. Работа с требованиями
    • Что мы упустили в требовании?
      • Время отклика … при загруженности пропускного канала … , не должно превышать 1 секунды … время выполнения …
    • Что с ресурсами?.. Какими они должны быть?
  • 45. Работа с требованиями
    • Пример тестопригодного требования
      • Время отклика системы с точки зрения конечного пользователя ( end-to-end ) во время продуктивной нагрузки (50 пользовательских сессий в режиме « менеджер » / 15 пользовательских сессий в режиме « аналитик » ) при загруженности пропускного канала от клиентской системы до сервера приложений в пределах 50% для сети 100 Mb/sec , не должно превышать 1 секунды для операций создания записи и 3 секунд для операций поиска записи.
      • Время выполнения аналитических отчётов определяется отдельно для каждого отчёта.
      • Объём используемой оперативной памяти должен оставаться стабильным.
  • 46. Работа с требованиями
    • Практические соображения
      • Изменения в требованиях должны однозначно отражаться в изменении функциональности системы и покрывающего тестового набора
      • Анализ покрытия требований рекомендуется проводить на этапе проектирования тестов, при условии что процесс гарантирует фиксированные требования в рамках итерации
  • 47. Работа с требованиями
    • Практические соображения
      • При условии « плавающих » требований, анализ покрытия производится по факту поставки версии системы, в которую включается набор актуальных требований. Данный подход увеличивает общее время отведённое на тестирование за счёт технологических простоев
      • Каждое требование должно быть протестировано (иметь тест)
      • Каждый тест должен относиться к какому-либо требованию
  • 48. Работа с требованиями
    • Практические соображения
      • Требования могут порождаться тестами (при использовании agile- методологий)
      • Требования обязательно должны находиться под версионным контролем
  • 49. ЭКВИВАЛЕНТНОЕ РАЗБИЕНИЕ
    • Что значит «протестировать полностью»?
    • Классы эквивалентности
    • Виды тестовых сценариев
    Тест-дизайн
  • 50. Что значит « протестировать полностью » ?
  • 51. Полное тестирование это –
    • Когда покрыты все:
      • строки кода программы
      • ветви кода в программе
      • пути в коде
      • входные данные и все их возможные комбинации
      • последовательности комбинаций входных данных
      • ...
  • 52.
    • Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью
    • Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью
    • Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования
    Почему нельзя полностью протестировать программу
  • 53. Виды тестовых сценариев
    • Позитивные сценарии
    • Негативные сценарии
    • Граничные сценарии
    • Исследовательские сценарии :
      • «А что должно быть если…»
  • 54.
    • Чтобы избежать ненужного тестирования , разбейте область входных значений на группы эквивалентных тестов
    • Два теста считаются эквивалентными если они настолько похожи, что проводить оба бессмысленно
    Техники тестирования. Эквивалентное разбиение
  • 55.
    • Если тест с   некоторым значением из   данного класса эквивалентности обнаруживает ошибку, то   было бы   разумно ожидать обнаружения той   же   ошибки тестом с   любым другим значением из   данного класса эквивалентности
    • Выберите одно входное значение из каждого класса эквивалентности в качестве представителя целой группы значений
    Техники тестирования. Эквивалентное разбиение
  • 56.
    • Рассмотрим пример
      • Программа складывает два целых числа
      • Каждое из слагаемых – не более чем целое двузначное число
      • Программа запрашивает у пользователя два числа и выводит результат
    • Предлагайте тесты >>
    Техники тестирования. Эквивалентное разбиение
  • 57. Классы эквивалентности Классы корректных данных Классы некорректных данных Граничные и специальные значения Первое слагаемое от -99 до -10 от -9 до -1 0 от 1 до 9 от 10 до 99 > 99 < -99 0, 1, -1, 9, -9 10, -10 99, -99 100, -100 Второе слагаемое - ”-”- - ”-”- - ”-”- Сумма от -198 до - 1 00 от -99 до -1 0 от 1 до 99 от 100 до 198 > 198 < - 1 9 8 (-99, -99) (-49, -51) (99, 99) (49, 51)
  • 58.
    • Порядок действий
    • Перечисляются все переменные (как входные, так и выходные )
    • Для каждой переменной определяется разбиение на классы
    • Строятся все возможные комбинации классов
    • В качестве представителей берутся граничные, приграничные или специальные значения
    Техники тестирования. Эквивалентное разбиение
  • 59.
    • Какие еще сущности можно разбивать на классы эквивалентности
    • числа
    • символы
    • количество (записей в БД, строк)
    • длина строки
    • размер файла
    • объем памяти
    • разрешение экрана
    • версии операционной системы, библиотек
    • объем передаваемых данных
    Техники тестирования. Эквивалентное разбиение
  • 60. Практические примеры
    • « Треугольник »
      • Программа запрашивает три числа
      • Определяется тип треугольника, имеющего стороны введенной длины: равносторонний, равнобедренный, разносторонний
    • Предлагайте тесты >>
    Техники тестирования. Эквивалентное разбиение
  • 61.
    • Корректный разносторонний треугольник
    • Корректный равносторонний треугольник
    • Три корректных равнобедренных треугольника (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)
    • Нецелое число или не число
    • Неправильное количество аргументов
    Техники тестирования. Эквивалентное разбиение
  • 62. ТЕСТИРОВАНИЕ НА ОСНОВЕ СЦЕНАРИЕВ И РИСКОВ
    • Пользователь прежде всего
    • Немного agile и экстрима
    • Когда страшно это хорошо
    Тест-дизайн
  • 63. Техники: тестирование на основе сценариев
    • Суть метода – тестировщик выполняет сценарии пользователей
    • Разновидности сценариев:
      • Истории пользователя
      • Варианты использования ( use cases )
      • Тестовые сценарии ( test cases )
  • 64.
    • Сценарии могут использоваться как в разработке, так и в тестировании
    • При использовании их в тестировании
      • Тестировщики следуют сценариям, которые использовались при разработке
      • Создают новые сценарии путем комбинации имеющихся
    Техники: тестирование на основе сценариев
  • 65.
    • Сценарии, использовавшиеся при разработке:
      • Уже проверены самими разработчиками
      • Не учитывают нестандартные случаи, намеренно неправильное использование
    • Новые сценарии:
      • Возможно никогда не встретятся в реальной эксплуатации
      • Требуют время на написание
    Техники: тестирование на основе сценариев
  • 66. Техники: тестирование на основе рисков
    • Подходы к тестированию на основе рисков
    • Приоритезация требований в соответствии с оценкой рисков; проверка требований соглано приоритетам
    • Приоритезация проблемных областей в соответствии с оценкой рисков; целенаправленный поиск ошибок определенного типа
  • 67. Техники: тестирование на основе рисков
    • Как понять что такое «рискованная область»
    • Рисуем схему приложения
      • Сайт бронирования билетов
    • Определяем веса узлов и переходов
    • Контролируем основные и альтернативные пути
    • «Где тонко – там и рвётся»
  • 68. Техники тестирования. Проблемы выбора
      • Не рекомендуется ограничиваться какой-либо одной техникой тестирования. Как правило, используются их сочетания
      • В общем случае комбинация техник такова:
        • Определить зоны высшего риска
        • Выделить сценарии и их параметры
        • Создать тестовые сценарии
        • Разбить параметры на классы эквивалентности
  • 69. Техники тестирования. Проблемы выбора
    • Контрольные вопросы при использовании комбинации техник тестирования:
      • Какие области наиболее рискованы? Как будут приоритезированы требования?
      • Какие есть сценарии использования для этих областей?
      • Какие параметры есть у этих сценариев?
      • На какие классы эквивалентности их можно разбить?
      • И наконец: какие тест-кейсы нужно составить?
  • 70. Практические примеры
    • Описание тестируемого функционала:
    • Поле для ввода названия папки
    • Кнопка «Сохранить»
    • Название папки не должно превышать 64 символа
    • Ваши предложения?
  • 71. Практический пример
    • Диалог сохранения файла
  • 72. «Фиксируем шаги»
    • Сначала выделяем наиболее рискованные (и важные) области – собственно сохранение , выбор нужного места, сохранение с длинным именем, с национальными символами, перезапись и т.п.
    • Потом выясняем какие сценарии использования ( use case )
    • Выясняем классы эквивалентности
    • Пишем тест-кейсы (позитивные, негативные, исследовательские)
  • 73. Способы снижения количества тестов
    • Рассмотрим пример
    • Окно поиска в текстовом редакторе
  • 74.
    • Подсчитаем количество тестов
    • 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ки )
    FW MW MC RE D 1 L Y Y Y Up 2 U Y Y Y Up 3 M Y Y Y Up 4 L Y Y Y Up 5 L N Y Y Up … … … … … … 47 M N N N Up 48 M N N N D
  • 77. Способы снижения количества тестов
    • Все значения хотя бы по разу
    3 теста, а не 48 FW MW MC RE D 1 L Y N Y Up 2 U N Y N D 3 M Y Y N Up
  • 78. Способы снижения количества тестов
    • Все пары (каждый с каждым)
    • Этот метод является « золотой серединой »
    • Метод « всех пар » хорошо работает для независимых переменных
    • Зачастую случайное тестирование хорошо приближается к методу « всех пар »
    FW MW MC RE D 1 L Y N Y Up 2 L N Y N D 3 U Y Y N Up 4 U N N Y D 5 M N N N Up 6 M Y Y Y D
  • 79. Тест управляемый данными
      • Форма валидации введенного значения
      • Требование: если введено целочисленное значение от 0 до 9 (включительно), возвращается значение TRUE
    • Предлагайте тесты (я записываю)
    Тест-дизайн
  • 80. Тест управляемый поведением
      • Форма заказа sushi
      • Требование: пользователь может оформить или отредактировать сформированный ранее в разделе «Меню» заказ. Счёт формируется с учётом накопительных скидок, выбранного способа оплаты и доставки.
    • Предлагайте тесты (я записываю)
    Тест-дизайн
  • 81. «Фиксируем подход»
    • Разработка тестов
      • Определение типа теста: «поведение» или «данные»
        • Logic-driven или data-driven test case
      • Если тест управляется логикой поведения
        • Составление путей и «узлов»
          • Определяется основной «путь»
          • Определяются и ограничиваются альтернативные «пути»
      • Если тест управляется данными
        • Составляется набор данных
        • Данные приоретезируются
          • Допустимые значения
          • Граничные значения
          • Значения за границами диапазона
    Тест-дизайн
  • 82. Практические примеры
    • Входные данные
    • Бизнес по продаже апельсинов, имеющий несколько представительств в различных городах.
    • Задача
    • Разобраться в системе и разработать пакет тестовых сценариев
    Тест-дизайн
  • 83. Практические примеры Тест-дизайн
  • 84. Анализ архитектуры
    • Архитектура
    • Сервер приложений
    • Сервер БД
    • «Толстые» клиенты, около 10 операторов
    Тест-дизайн
    • Первые выводы и вопросы
    • Большинство операций происходит на стороне клиента
    • Тестируем клиентскую часть и сервер приложений
    • Сервер приложения может работать со своей БД и с БД центрального отделения
    • БД не содержит никакой логики – только хранилище?
  • 85. Анализ конфигурационных требований
    • Требования к конфигурациям
    • Клиентская часть поддерживается на 4-х ОС
    • Сервер приложения поддерживается на 2-х ОС
    • Локализация – система поддерживает два языка
    • На тестирование выносится 20 функциональных требований к клиентской части и 10 функциональных требований к серверной части
    Тест-дизайн
  • 86. Пытаемся планировать
    • Вопросы к обсуждению
    • Какие виды тестов будем проводить?
    • Нагрузочного тестирования не будет, 10 операторов – это не та нагрузка, которую стоит проверять (или будет?)
    • Что стоит автоматизировать, что нет?
    • Какие окружения выделяем для тестирования?
    Тест-дизайн
  • 87. Попробуем прикинуть трудоёмкость
    • Допущения
    • Допустим, на одно функциональное требование мы предполагаем написать 5 тестовых сценариев
    • Допустим, на прохождение 1-го тестового сценария мы предполагаем потратить 5 минут
    • Посчитайте сами и ответьте на следующие вопросы:
    • Сколько всего окружений получается?
    • Сколько всего тестовых сценариев будет в системе?
    • Время затраченное на проведение 1-го раунда тестирования?
    Тест-дизайн
  • 88. Считаем окружения
    • Окружений: 16
    • 4 клиентские ОС * 2 языка = 8 клиентских конфигураций * 2 серверные ОС = 16 окружений
    • Тестовых сценариев в системе: 150
    • (20 клиентских требований + 10 серверных требований) * 5 тестовых сценариев на одно требование = 150 .
    • Сколько всего тестовых сценариев для проведения 1-го раунда тестирования?
    Тест-дизайн
  • 89. Считаем время
    • Расчеты
    • Всего тестовых сценариев: 16 окружений * 150 тестовых сценариев = 2400
    • Время на проведение 1-го раунда тестирования: (2400 тестовых сценарев * 5 минут) / 60 = 200 часов или 5 недель
    Тест-дизайн
  • 90. Давайте подумаем
    • Что мы не учли?
    • Требования относятся к функциональности (логике приложения) или к окружению (системные функции, работа с ресурсами ОС и т.д.).
    Тест-дизайн
  • 91. Разбор тестируемых функций
    • Что зависит обычно от окружения на клиенте и сервере?
    • Вход, выход, печать форм, получение языка ОС, получение цветовой гаммы ОС, работа с протоколами общения между серверами приложений
    • Что не зависит от окружения?
    • Получение информации из БД, запрос на сервер приложения, анализ полученных данных на клиенте и т.д.
    Тест-дизайн
  • 92. Подбиваем баланс по группам требований
    • Получаем:
    • 5 требований зависят от окружений на клиенте
    • 5 требований зависят от всех окружений
    • 5 требований зависят только от окружений сервера приложений
    • 15 требований относятся к функциональности и не зависят от окружений
    Тест-дизайн
  • 93. Пересчитываем
    • Итого:
    • 25 тестовых сценариев * 8 = 200 тестовых сценариев зависящих от окружения на клиенте
    • 25 тестовых сценариев * 16 = 400 тестовых сценариев зависящих от всех конфигураций
    • 25 тестовых сценариев * 2 = 50 тестовых сценариев зависящих от окружения на сервере приложений
    • 75 тестовых сценариев относятся к функциональным тестам
    • 200 + 400 + 50 + 75 = 725 тестовых сценариев
    Тест-дизайн
  • 94. Сила тест-дизайна
    • Расчеты
    • Всего тестовых сценариев: 725
    • Время на проведение 1-го раунда тестирования: (725 тестовых сценариев * 5 минут) / 60 = 60,5 часов или 1,5 недели
    • Было: 200 часов или 5 недель
    • Стало: 60,5 часов или 1,5 недели
          • Экономия достигается за счёт принимаемых допущений и связанных с ними рисков
    Тест-дизайн
  • 95.
    • Введение в тестирование программного обеспечения
    • Луиза Тамре
    • Introducing Software Testing
    • Издательство: Вильямс, 2003 г .
    • В этой книге изложены:
      • Последовательность вхождения в процесс тестирования с акцентом на ключевых функциях;
      • Определение недостающих сведений и проведение адекватного тестирования при недостаточно четких требованиях;
      • Изучение различных форматов документации для регистрации тестовых примеров .
    Рекомендуемая литература
  • 96.
    • Быстрое тестирование
    • Роберт Калбертсон, Крис Браун, Гэри Кобб
    • Издательство: Вильямс, 2002 г.
    • Технология быстрого тестирования находит `золотую середину` между соблюдением сроков и гарантией высокого качества. Описанию этой технологии и посвящена книга.
    • Книга написана с учетом громадного опыта работы авторов в области тестирования ПО. Она окажет несомненную пользу всем специалистам, которые работают как в крупных, так и в небольших организациях, занимающихся созданием ПО.
    Рекомендуемая литература
  • 97. Рекомендуемая литература
    • Тестирование dot com
    • Роман Савин
    • Издательство: Дело, 2007 г.
    • Этот курс лекций создан для тех, кто хочет обучиться тестированию, понять, как вести себя в корпоративном окружении, и добиться профессионального и личностного роста. Он будет интересен и участникам процесса разработки программного обеспечения, рекрутерам, людям, связанным с интернетом или пишущим о нем, и просто всем желающим понять кухню интернет-стартапов
    Тест-дизайн
  • 98. Слава Панкратов «Тест-дизайн» http://pankratov.org.ua [email_address] icq: 109882167