Test design print

4,266 views
4,106 views

Published on

Published in: Technology, Education
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,266
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
118
Comments
0
Likes
3
Embeds 0
No embeds

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
  • Test design print

    1. 1. ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 200 8, v.2. 6 Тест-дизайн
    2. 2. Почему чем позже, тем дороже? <ul><ul><li>Удельная стоимость исправления дефектов быстро растет по мере продвижения продукта к стадии эксплуатации. Так, в статье 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.) показано, что стоимость исправления дефекта после ввода системы в эксплуатацию вдвое превышает аналогичную стоимость на стадии тестирования продукта и более чем в тысячу раз — в период выработки требований к продукту. </li></ul></ul>Тест-дизайн
    3. 3. Стоимость исправления ошибок <ul><li>Задачи тестирования ПО – снизить стоимость разработки путем раннего обнаружения дефектов; </li></ul><ul><li>Тест дизайн – самая ранняя фаза, на которой тестирование врезается в разработку </li></ul>Тест-дизайн
    4. 4. Сколько это будет стоить исправить? <ul><li>Невозможно представить себе разработку ПО, которое было бы свободно от тех или иных ошибок. </li></ul><ul><li>По данным, опубликованным Национальным институтом стандартов (NIST 2002 RTI Project 7007.011), основное количество ошибок в продукте (70%!) закрадывается на стадии выработки требований и построения дизайна. </li></ul><ul><li>А обнаруживается подавляющее большинство дефектов либо в процессе тестирования (около 60%), либо уже при эксплуатации (21%). </li></ul>Тест-дизайн
    5. 5. АВТОРСКИЙ КОЛЛЕКТИВ <ul><li>Вячеслав Панкратов </li></ul><ul><li>http://pankratov.org.ua/ </li></ul><ul><li>Дмитрий Лысенко </li></ul><ul><li>http://dmitrylysenko.info/ </li></ul>Тест-дизайн
    6. 6. РАСПИСАНИЕ: 10.00-17.00 <ul><li>I день </li></ul><ul><ul><li>Входное анкетирование </li></ul></ul><ul><ul><li>Качество информационных систем </li></ul></ul><ul><ul><li>Процесс тестирования ПО </li></ul></ul><ul><ul><li>Место практики «Тест-дизайн» </li></ul></ul><ul><ul><li>Обзор роли: дизайнер тестов </li></ul></ul><ul><ul><li>Связь проектных артефактов </li></ul></ul><ul><ul><li>Тест, тестовый набор, покрытие, стратегия </li></ul></ul><ul><ul><li>Работа с требованиями </li></ul></ul><ul><li>II день </li></ul><ul><ul><li>Техники тестирования </li></ul></ul><ul><ul><li>Практика </li></ul></ul><ul><ul><li>Финальное анкетирование </li></ul></ul>
    7. 7. СОДЕРЖАНИЕ КУРСА <ul><ul><li>Процесс тестирования ПО и место практики «Тест-дизайн» </li></ul></ul><ul><ul><li>Преимущества и недостатки методов тест дизайна </li></ul></ul><ul><ul><li>Определение роли дизайнера тестов: зона ответственности </li></ul></ul><ul><ul><li>Активности разработки/дизайна тестов </li></ul></ul><ul><ul><li>Практические соображения работы с требованиями </li></ul></ul><ul><ul><li>Обзор артефактов тест дизайнера </li></ul></ul><ul><ul><li>Практические примеры </li></ul></ul>
    8. 8. БАЗОВЫЕ ПОНЯТИЯ <ul><ul><li>Качество информационных систем </li></ul></ul><ul><ul><li>Процесс тестирования ПО </li></ul></ul><ul><ul><li>Тест-дизайн: определение и практика </li></ul></ul><ul><ul><li>Место практики «Тест-дизайн» </li></ul></ul><ul><ul><li>Связь проектных артефактов </li></ul></ul>Тест-дизайн
    9. 9. Характеристики качества ПО <ul><li>Функциональность, надежность, производительность </li></ul><ul><ul><li>Надежность — работает ли приложение без сбоев, «зависаний» или вызова исключений </li></ul></ul><ul><ul><li>Функциональность — делает ли приложение то, что от него требуется </li></ul></ul><ul><ul><li>Производительность — работает ли приложение с приемлемой скоростью при доступе к нему многих пользователей </li></ul></ul>Тест-дизайн
    10. 10. Эволюция представлений о тестировании <ul><li>Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004] </li></ul><ul><li>Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц. [ С.  Kaner, 199 9] </li></ul><ul><li>Э то не действие . Это интеллектуальная дисциплина, имеющая целью получение надежного программного обеспечения без излишних усилий на его проверку. [B. Beizer. Software Testing Techniques, Second Edition. NY : van Nostrand Reinhold, 1990] </li></ul><ul><li>Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов. [ANSI/IEEE standard 610.12-1990: G lossary of SE T erminology. NY:IEEE, 1987] </li></ul><ul><li>Процесс выполнения программы с намерением найти ошибки. [Г.Майерс. Надежность программного обеспечения. М:Мир , 1980] </li></ul>Тест-дизайн 1980 1987 1990 1999 2004
    11. 11. Определение: Тестирование ПО <ul><ul><li>Тестирование ПО – процесс проверки соответствия заявленных к продукту требований и реально реализованной функциональности, осуществляемый путем наблюдения за его работой в искусственно созданных ситуациях и на ограниченном наборе тестов, выбранных определенным образом </li></ul></ul>Тест-дизайн
    12. 12. Место тестирования в процессе разработки ПО Анализ требований Спецификации ( Specification ) Программная архитектура ( Software Architecture ) Поддержка Анализ требований Планирование процесса тестирования Поддержка Программирование ( Coding ) Проектирование тестов Отладка тестов Выполнение тестов ( testing cycles ) Системное тестирование (System testing) Приемочные испытания ( Acceptance Testing ) Development Process Testing Process Версия ( build ) Результат ( test result )
    13. 13. Стадии тестирования Тестирование программного продукта Проектирование тестов Анализ требований Планирование процесса тестирования Изучение спецификаций, функциональных требований к системе. Получение данных для составления плана проведения тестирования Определение объемов тестирования, подходов, ресурсов и расписание выполнения намеченных действий Определение цели тестирования, спецификации входных данных, архитектуры тестов для упорядочивания тестов по группам Стадии статического тестирования >>
    14. 14. Стадии тестирования Отладка тестов Выполнение тестов ( testing cycles ) Системное тестирование (System Testing) Приемочные испытания ( Acceptance Testing ) Эксплуатация и поддержка Стадии динамического тестирования Непосредственная проверка спроектированных тестов, анализ всевозможных тестовых случаев Функциональная проверка, тестирование для определения рабочих характеристик Альфа-тестирование, Бета-тестирование Проверка результатов, исправление дефектов. Пересмотр и отладка тестовых случаев
    15. 15. BUC-UC-TC и другие страшные слова <ul><li>BUC/BR – business use case или business rule , бизнес-требование или бизнес-правило </li></ul><ul><li>UC – use case , сценарий использования </li></ul><ul><li>TC – test case , сценарий тестирования </li></ul>Тест-дизайн
    16. 16. Тест-дизайн <ul><li>Определение и практика </li></ul><ul><ul><li>Тест-дизайн – это этап процесса тестирования ПО, который включает создание / проектирование тестовых сценариев и определение необходимых типов тестов, для достижения заданного уровня тестового покрытия приложения или системы под тестом </li></ul></ul><ul><ul><li>Тест-дизайн – это техника, кардинально влияющая на стоимость тестирования, так как задаёт объёмы работ и границы проекта по тестированию </li></ul></ul><ul><ul><li>Тест-дизайн – это попытка найти баланс между трудозатратами на тестирование и приемлемым уровнем доверия к результатам тестирования </li></ul></ul>Тест-дизайн
    17. 17. ОБЗОР РОЛИ: ДИЗАЙНЕР ТЕСТОВ <ul><li>Круг ответственности </li></ul><ul><li>Круг активностей </li></ul><ul><li>Артефакты роли </li></ul>Тест-дизайн
    18. 18. Тестирование в картинках (RUP) Тест-дизайн
    19. 19. Тест дизайн в картинках (RUP)
    20. 20. Тест-аналитик: внимание, совмещаем! <ul><li>Определяет, приоритизирует и обеспечивает разработку тестовых случаев </li></ul><ul><li>Ответственность: </li></ul><ul><ul><li>Разрабатывает модель тестирования </li></ul></ul><ul><ul><li>Оценивает эффективность тестирования </li></ul></ul>Тест-дизайн
    21. 21. Тест-дизайнер <ul><li>Устанавливает и определяет операции, атрибуты и связи тестовых классов </li></ul><ul><li>Ответственность: </li></ul><ul><ul><li>Устанавливает и определяет тестовые классы </li></ul></ul><ul><ul><li>Устанавливает и определяет тестовые наборы (пакеты) </li></ul></ul>Тест-дизайн
    22. 22. Обзор артефактов тестирования <ul><li>Аналитик </li></ul><ul><ul><li>Test Case </li></ul></ul><ul><ul><li>Test-Ideas List </li></ul></ul><ul><ul><li>Workload Analysis Model </li></ul></ul><ul><ul><li>Test Data </li></ul></ul><ul><ul><li>Test results </li></ul></ul><ul><li>Дизайнер </li></ul><ul><ul><li>Test Strategy </li></ul></ul><ul><ul><li>Test Automation Architecture </li></ul></ul><ul><ul><li>Test Environment Configuration </li></ul></ul><ul><ul><li>Test Suite </li></ul></ul>Тест-дизайн
    23. 23. ТЕСТ, ТЕСТОВЫЙ НАБОР, СТРАТЕГИЯ <ul><li>Определения </li></ul><ul><li>Тест, тестовый набор, тестовое покрытие </li></ul><ul><li>Стратегия тестирования </li></ul>Тест-дизайн
    24. 24. Определение теста и тестового набора <ul><li>Тест – последовательность действий, которая переводит систему из одного состояния в другое </li></ul><ul><li>Триплет ISO, где: </li></ul><ul><ul><li>I - is input data or action (входные данные или действия) </li></ul></ul><ul><ul><li>S - is State of system at which data will be input (состояние системы, которая получает входные данные или воздействие) </li></ul></ul><ul><ul><li>O - is the expected Output (ожидаемые Выход, выходные данные или выходной состояние системы) </li></ul></ul>Тест-дизайн
    25. 25. Определение теста и тестового набора <ul><li>Тестовый набор </li></ul><ul><ul><li>Набор тестов , реализующих бизнес - задачу, выполняемую тестируемой системой </li></ul></ul><ul><ul><li>Тестовый набор включает кроме тестовых сценариев еще и тестовые данные или правила их генерации </li></ul></ul>Тест-дизайн
    26. 26. Определение теста и тестового набора <ul><li>Разработка тестовых сценариев – практические соображения </li></ul><ul><ul><li>Формальные методы разработки тестовых сценариев </li></ul></ul><ul><ul><ul><li>На основе сценариев использования </li></ul></ul></ul><ul><ul><ul><li>На основе ортогональной классификации дефектов </li></ul></ul></ul><ul><ul><li>Формальные методики оценки объемов работ </li></ul></ul><ul><ul><ul><li>Метод расчета цикломатической сложности, основанный на метрике МакКаби ( McCabe ) </li></ul></ul></ul><ul><ul><li>Смешанные методики – комбинация подходов </li></ul></ul>Тест-дизайн
    27. 27. Тестовое покрытие <ul><li>Requirements-based Test Coverage </li></ul><ul><ul><li>Метрика покрытия, основанная на анализе тестовых требований , </li></ul></ul><ul><ul><ul><li>Собирается несколько раз в течении одного цикла тестирования для анализа завершенности тестирования </li></ul></ul></ul><ul><ul><li>Вычисляется как соотношение всех запланированных, имплементированных и выполненных тестовых случаев к количеству тестовых требований, существующих для тестового цикла </li></ul></ul>Тест-дизайн
    28. 28. Тест дизайн, как этап тестирования <ul><li>На этапе тест-дизайна выясняется и определяется </li></ul><ul><ul><li>Список тестируемых функций и модулей </li></ul></ul><ul><ul><li>Тестируемость каждой функции и модуля </li></ul></ul><ul><ul><li>Наиболее оптимальный подход (техника) для проверки каждой функции, модуля или подсистемы </li></ul></ul><ul><ul><li>Набор типов тестов </li></ul></ul><ul><ul><li>Последовательность проведения и критерии завершенности тестирования </li></ul></ul><ul><li>Основные артефакты: </li></ul><ul><li>тест кейс и стратегия тестирования ПО </li></ul>Тест-дизайн
    29. 29. Стратегия тестирования <ul><ul><li>Типы тестирования </li></ul></ul><ul><ul><ul><li>Тестирование данных и целостности базы данных </li></ul></ul></ul><ul><ul><ul><li>Функциональное тестирование </li></ul></ul></ul><ul><ul><ul><li>Тестирование бизнес - циклов </li></ul></ul></ul><ul><ul><ul><li>Тестирование пользовательского интерфейса </li></ul></ul></ul><ul><ul><ul><li>Нагрузочное тестирование </li></ul></ul></ul><ul><ul><ul><li>Тестирование безопасности и управления доступом </li></ul></ul></ul><ul><ul><ul><li>Конфигурационное тестирование </li></ul></ul></ul><ul><ul><ul><li>Инсталляционное тестирование </li></ul></ul></ul><ul><ul><li>Инструментальные средства </li></ul></ul>Тест-дизайн
    30. 30. Типы тестирования: целостность данных <ul><ul><li>Цель: убедиться в невозможности создания «несвязных данных» - данных, которые могут быть созданы-отредактированы-агрегированы при нормальной работе системы или при возникновении сбоев в работе. </li></ul></ul><ul><ul><li>Обращайте внимание: </li></ul></ul><ul><ul><ul><li>На включение-отключение триггеров и ограничений при импорте-экспорте данных </li></ul></ul></ul><ul><ul><ul><li>На включение-отключение триггеров и ограничений при переводе системы в production режим </li></ul></ul></ul><ul><ul><ul><li>На включение-отключение триггеров и ограничений при операциях архивирования и завершении бизнес-циклов </li></ul></ul></ul><ul><ul><ul><li>На поведение системы относительно данных при разрывах соединений клиент-сервер-БД в любых сочетаниях </li></ul></ul></ul>Тест-дизайн
    31. 31. Типы тестирования: функциональное тестирование <ul><ul><li>90% нашего с вами рабочего времени </li></ul></ul><ul><ul><li>Проверка функциональных требований: логики и бизнес-правил приложения или системы </li></ul></ul><ul><ul><li>Как правильно полноценное системное / функциональное тестирование является самым трудоёмким процессом и может занимать (Ф.Брукс) до 80% всего бюджета проекта по тестированию </li></ul></ul><ul><ul><li>Обращайте внимание: </li></ul></ul><ul><ul><ul><li>На невозможность полного покрытия – всегда надо выбирать </li></ul></ul></ul><ul><ul><ul><li>На необходимость постоянно отслеживать приоритетность требований от версии к версии: требования меняются, приоритеты тоже </li></ul></ul></ul>Тест-дизайн
    32. 32. Типы тестирования: бизнес циклы <ul><ul><li>Бизнес-циклы : сущность, которая описывает и задаёт следующий уровень функционального тестирования и служит про проверки корректности работы алгоритмов и механизмов, автоматизирующих не столько пользовательские операции, сколько естественную цикличность любого бизнеса , завершающуюся отчётами, архивированием данных, выполнением нетипичных для системы операций. </li></ul></ul><ul><ul><li>Закрытие месяца, закрытие года, получение очередной крупнооптовой партии товаров, расчёт пени, реструктуризации долгов и т.п. </li></ul></ul>Тест-дизайн
    33. 33. Типы тестирования: GUI, usability <ul><ul><li>Обычно данный тип тестирования не обладает формальным признаком запрета выпуска версии </li></ul></ul><ul><ul><li>Результатом выполнения данного типа тестов является список рекомендаций и предложений по улучшению </li></ul></ul><ul><ul><li>Основной для проведения данного типа тестов могут являться принятые в компании / проекте стандарты оформления пользовательских интерфейсов или общепринятые User Interface Guidelines: </li></ul></ul><ul><ul><ul><li>Например, Microsoft Windows XP/2000 User Interface Guidelines </li></ul></ul></ul>Тест-дизайн
    34. 34. Типы тестирования: производительность <ul><ul><li>Производительность : способность совершать определённое количество операций в единицу времени </li></ul></ul><ul><ul><li>Тестирование производительности: нормальная, ожидаемая модель нагрузки </li></ul></ul><ul><ul><li>Нагрузочное: предельная или превышающая нормальную модель нагрузки </li></ul></ul><ul><ul><li>Стрессовое тестирование: сознательное превышение нагрузок или урезание ресурсов с целью посмотреть «как будет падать и подниматься» </li></ul></ul><ul><ul><li>Объёмное тестирование: тестирование способности обработки больших объёмов операционных или хранения архивных данных </li></ul></ul>Тест-дизайн
    35. 35. Типы тестирования: безопасность и доступ <ul><ul><li>Выделяют два больших типа тестов: </li></ul></ul><ul><ul><ul><li>Разграничение прав доступа к данным и операциям и соотв. невозможность несанкционированного доступа к данным и выполнению операций </li></ul></ul></ul><ul><ul><ul><li>Устойчивость системы к внешним проникновениям, несанкционированным вызовам функций, инъекциям исполняемого кода, вызова нештатных ситуаций, переполнений и т.д. </li></ul></ul></ul><ul><ul><li>Применяют как средства анализа кода, так и накопленную (зачастую внешнюю) экспертизу </li></ul></ul>Тест-дизайн
    36. 36. Типы тестирования: конфигурационные тесты <ul><ul><li>Тестирование системы на различных конфигурациях программно-аппаратного стенда </li></ul></ul><ul><ul><li>Цели: </li></ul></ul><ul><ul><ul><li>Проверка-выявление списка поддерживаемых окружений </li></ul></ul></ul><ul><ul><ul><li>Подбор минимальных-оптимальных-рекомендуемых параметров аппаратного обеспечения </li></ul></ul></ul><ul><ul><li>Обращайте внимание на составления «матрицы покрытия» </li></ul></ul><ul><ul><li>Очень ресурсоёмкий и затратный тип тестов </li></ul></ul><ul><ul><li>Относиться в основном к тестированию функциональности, но также может затрагивать и вопросы тестирования производительности </li></ul></ul>Тест-дизайн
    37. 37. Типы тестирования: тестирование инсталляций <ul><ul><li>Школа жизни для тестировщика  </li></ul></ul><ul><ul><li>Современные инсталляции умеют очень глубоко залазить в систему и на лету менять её компоненты </li></ul></ul><ul><ul><li>Развёртывание – вариант инсталляции </li></ul></ul><ul><ul><li>Инсталляция – отдельное и потенциально достаточно сложное приложение, которое требует отельного планирования и выполнения тестов </li></ul></ul><ul><ul><li>Для тестирования инсталляций характерно выделять отдельный список поддерживаемых окружений и проводить отдельный цикл конфигурационного тестирования </li></ul></ul>Тест-дизайн
    38. 38. РАБОТА С ТРЕБОВАНИЯМИ <ul><li>Работа с изменяющимися требованиями </li></ul><ul><li>Пример нетестируемого требования </li></ul><ul><li>Пример тестопригодного требования </li></ul><ul><li>Почему не все могут и должны заниматься дизайном </li></ul>
    39. 39. Что было написано в требовании <ul><li>SRS-01 (до изменения) </li></ul><ul><ul><li>Форма регистрации нового пользователя в системе “InfoSecurityManagement” позволяет вводить в реестр пользователей данные о пользователе и его роли: </li></ul></ul><ul><ul><ul><li>Имя, </li></ul></ul></ul><ul><ul><ul><li>Доменное имя, </li></ul></ul></ul><ul><ul><ul><li>Должность, </li></ul></ul></ul><ul><ul><ul><li>Полномочия в системе </li></ul></ul></ul>Тест-дизайн
    40. 40. Что изменилось в требовании <ul><li>SRS-0 1.1 (после изменения) </li></ul><ul><ul><li>Форма регистрации нового пользователя в системе “InfoSecurityManagement” позволяет вводить в реестр пользователей данные о пользователе и его роли: </li></ul></ul><ul><ul><ul><li>Имя, </li></ul></ul></ul><ul><ul><ul><li>Доменное имя, </li></ul></ul></ul><ul><ul><ul><li>Должность, </li></ul></ul></ul><ul><ul><ul><li>Полномочия в системе </li></ul></ul></ul><ul><ul><li>Если такой пользователь уже существует в реестре системы “InfoSecurityManagement” , на форме ввода появляется его E-mail адрес. </li></ul></ul>Тест-дизайн
    41. 41. Практический кейс <ul><li>Что должно произойти в тест-кейсах? </li></ul><ul><li>Кто это должен сделать? </li></ul><ul><li>Когда это может происходить? </li></ul><ul><li>Вы уверены, что ваш рядовой тестер понимает глубину задачи? </li></ul>Тест-менеджмент
    42. 42. Работа с требованиями <ul><li>Пример нетестируемого требования производительности ПО </li></ul><ul><ul><li>Время отклика системы должно находится в приемлемых рамках </li></ul></ul><ul><ul><li>Время отклика (Отклика на какой операции?) системы (что такое система в этом требовании: UI, DB, client + server + network?) должно находится (Условия? Нагрузка?) в приемлемых рамках (Цифры?) </li></ul></ul>
    43. 43. Работа с требованиями <ul><li>Пример тестопригодного требования </li></ul><ul><ul><li>Время отклика системы с точки зрения конечного пользователя (end-to-end) во время продуктивной нагрузки (50 пользовательских сессий в режиме « менеджер » / 15 пользовательских сессий в режиме « аналитик » ) при загруженности пропускного канала от клиентской системы до сервера приложений в пределах 50% для сети 100 Mb/sec и утилизации ресурсов сервера приложений (CPU, RAM) в рамках 70-80%, а клиентской машины в рамках 40-60%, не должно превышать 1 секунды для операций создания записи (сущности) и 3 секунд для операций поиска. </li></ul></ul><ul><ul><li>Время выполнения аналитических отчётов определяется отдельно для каждого отчёта </li></ul></ul>
    44. 44. Работа с требованиями <ul><li>Что мы упустили в требовании? </li></ul><ul><ul><li>Время отклика … при загруженности пропускного канала … , не должно превышать 1 секунды … время выполнения … </li></ul></ul><ul><li>Что с ресурсами?.. Какими они должны быть? </li></ul>
    45. 45. Работа с требованиями <ul><li>Пример тестопригодного требования </li></ul><ul><ul><li>Время отклика системы с точки зрения конечного пользователя ( end-to-end ) во время продуктивной нагрузки (50 пользовательских сессий в режиме « менеджер » / 15 пользовательских сессий в режиме « аналитик » ) при загруженности пропускного канала от клиентской системы до сервера приложений в пределах 50% для сети 100 Mb/sec , не должно превышать 1 секунды для операций создания записи и 3 секунд для операций поиска записи. </li></ul></ul><ul><ul><li>Время выполнения аналитических отчётов определяется отдельно для каждого отчёта. </li></ul></ul><ul><ul><li>Объём используемой оперативной памяти должен оставаться стабильным. </li></ul></ul>
    46. 46. Работа с требованиями <ul><li>Практические соображения </li></ul><ul><ul><li>Изменения в требованиях должны однозначно отражаться в изменении функциональности системы и покрывающего тестового набора </li></ul></ul><ul><ul><li>Анализ покрытия требований рекомендуется проводить на этапе проектирования тестов, при условии что процесс гарантирует фиксированные требования в рамках итерации </li></ul></ul>
    47. 47. Работа с требованиями <ul><li>Практические соображения </li></ul><ul><ul><li>При условии « плавающих » требований, анализ покрытия производится по факту поставки версии системы, в которую включается набор актуальных требований. Данный подход увеличивает общее время отведённое на тестирование за счёт технологических простоев </li></ul></ul><ul><ul><li>Каждое требование должно быть протестировано (иметь тест) </li></ul></ul><ul><ul><li>Каждый тест должен относиться к какому-либо требованию </li></ul></ul>
    48. 48. Работа с требованиями <ul><li>Практические соображения </li></ul><ul><ul><li>Требования могут порождаться тестами (при использовании agile- методологий) </li></ul></ul><ul><ul><li>Требования обязательно должны находиться под версионным контролем </li></ul></ul>
    49. 49. ЭКВИВАЛЕНТНОЕ РАЗБИЕНИЕ <ul><li>Что значит «протестировать полностью»? </li></ul><ul><li>Классы эквивалентности </li></ul><ul><li>Виды тестовых сценариев </li></ul>Тест-дизайн
    50. 50. Что значит « протестировать полностью » ?
    51. 51. Полное тестирование это – <ul><li>Когда покрыты все: </li></ul><ul><ul><li>строки кода программы </li></ul></ul><ul><ul><li>ветви кода в программе </li></ul></ul><ul><ul><li>пути в коде </li></ul></ul><ul><ul><li>входные данные и все их возможные комбинации </li></ul></ul><ul><ul><li>последовательности комбинаций входных данных </li></ul></ul><ul><ul><li>... </li></ul></ul>
    52. 52. <ul><li>Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью </li></ul><ul><li>Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью </li></ul><ul><li>Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования </li></ul>Почему нельзя полностью протестировать программу
    53. 53. Виды тестовых сценариев <ul><li>Позитивные сценарии </li></ul><ul><li>Негативные сценарии </li></ul><ul><li>Граничные сценарии </li></ul><ul><li>Исследовательские сценарии : </li></ul><ul><ul><li>«А что должно быть если…» </li></ul></ul>
    54. 54. <ul><li>Чтобы избежать ненужного тестирования , разбейте область входных значений на группы эквивалентных тестов </li></ul><ul><li>Два теста считаются эквивалентными если они настолько похожи, что проводить оба бессмысленно </li></ul>Техники тестирования. Эквивалентное разбиение
    55. 55. <ul><li>Если тест с   некоторым значением из   данного класса эквивалентности обнаруживает ошибку, то   было бы   разумно ожидать обнаружения той   же   ошибки тестом с   любым другим значением из   данного класса эквивалентности </li></ul><ul><li>Выберите одно входное значение из каждого класса эквивалентности в качестве представителя целой группы значений </li></ul>Техники тестирования. Эквивалентное разбиение
    56. 56. <ul><li>Рассмотрим пример </li></ul><ul><ul><li>Программа складывает два целых числа </li></ul></ul><ul><ul><li>Каждое из слагаемых – не более чем целое двузначное число </li></ul></ul><ul><ul><li>Программа запрашивает у пользователя два числа и выводит результат </li></ul></ul><ul><li>Предлагайте тесты >> </li></ul>Техники тестирования. Эквивалентное разбиение
    57. 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. 58. <ul><li>Порядок действий </li></ul><ul><li>Перечисляются все переменные (как входные, так и выходные ) </li></ul><ul><li>Для каждой переменной определяется разбиение на классы </li></ul><ul><li>Строятся все возможные комбинации классов </li></ul><ul><li>В качестве представителей берутся граничные, приграничные или специальные значения </li></ul>Техники тестирования. Эквивалентное разбиение
    59. 59. <ul><li>Какие еще сущности можно разбивать на классы эквивалентности </li></ul><ul><li>числа </li></ul><ul><li>символы </li></ul><ul><li>количество (записей в БД, строк) </li></ul><ul><li>длина строки </li></ul><ul><li>размер файла </li></ul><ul><li>объем памяти </li></ul><ul><li>разрешение экрана </li></ul><ul><li>версии операционной системы, библиотек </li></ul><ul><li>объем передаваемых данных </li></ul>Техники тестирования. Эквивалентное разбиение
    60. 60. Практические примеры <ul><li>« Треугольник » </li></ul><ul><ul><li>Программа запрашивает три числа </li></ul></ul><ul><ul><li>Определяется тип треугольника, имеющего стороны введенной длины: равносторонний, равнобедренный, разносторонний </li></ul></ul><ul><li>Предлагайте тесты >> </li></ul>Техники тестирования. Эквивалентное разбиение
    61. 61. <ul><li>Корректный разносторонний треугольник </li></ul><ul><li>Корректный равносторонний треугольник </li></ul><ul><li>Три корректных равнобедренных треугольника (a=b, b=c, a=c) </li></ul><ul><li>Одна, две или три стороны равны нулю (5 тестов ) </li></ul><ul><li>Одна сторона отрицательная </li></ul><ul><li>«Почти» выполняется правило треугольника ( три варианта a+b = c, a+c = b, b+c = a) </li></ul><ul><li>Не выполняется правило треугольника ( три варианта a+b<c, a+c<b, b+c<a) </li></ul><ul><li>Нецелое число или не число </li></ul><ul><li>Неправильное количество аргументов </li></ul>Техники тестирования. Эквивалентное разбиение
    62. 62. ТЕСТИРОВАНИЕ НА ОСНОВЕ СЦЕНАРИЕВ И РИСКОВ <ul><li>Пользователь прежде всего </li></ul><ul><li>Немного agile и экстрима </li></ul><ul><li>Когда страшно это хорошо </li></ul>Тест-дизайн
    63. 63. Техники: тестирование на основе сценариев <ul><li>Суть метода – тестировщик выполняет сценарии пользователей </li></ul><ul><li>Разновидности сценариев: </li></ul><ul><ul><li>Истории пользователя </li></ul></ul><ul><ul><li>Варианты использования ( use cases ) </li></ul></ul><ul><ul><li>Тестовые сценарии ( test cases ) </li></ul></ul>
    64. 64. <ul><li>Сценарии могут использоваться как в разработке, так и в тестировании </li></ul><ul><li>При использовании их в тестировании </li></ul><ul><ul><li>Тестировщики следуют сценариям, которые использовались при разработке </li></ul></ul><ul><ul><li>Создают новые сценарии путем комбинации имеющихся </li></ul></ul>Техники: тестирование на основе сценариев
    65. 65. <ul><li>Сценарии, использовавшиеся при разработке: </li></ul><ul><ul><li>Уже проверены самими разработчиками </li></ul></ul><ul><ul><li>Не учитывают нестандартные случаи, намеренно неправильное использование </li></ul></ul><ul><li>Новые сценарии: </li></ul><ul><ul><li>Возможно никогда не встретятся в реальной эксплуатации </li></ul></ul><ul><ul><li>Требуют время на написание </li></ul></ul>Техники: тестирование на основе сценариев
    66. 66. Техники: тестирование на основе рисков <ul><li>Подходы к тестированию на основе рисков </li></ul><ul><li>Приоритезация требований в соответствии с оценкой рисков; проверка требований соглано приоритетам </li></ul><ul><li>Приоритезация проблемных областей в соответствии с оценкой рисков; целенаправленный поиск ошибок определенного типа </li></ul>
    67. 67. Техники: тестирование на основе рисков <ul><li>Как понять что такое «рискованная область» </li></ul><ul><li>Рисуем схему приложения </li></ul><ul><ul><li>Сайт бронирования билетов </li></ul></ul><ul><li>Определяем веса узлов и переходов </li></ul><ul><li>Контролируем основные и альтернативные пути </li></ul><ul><li>«Где тонко – там и рвётся» </li></ul>
    68. 68. Техники тестирования. Проблемы выбора <ul><ul><li>Не рекомендуется ограничиваться какой-либо одной техникой тестирования. Как правило, используются их сочетания </li></ul></ul><ul><ul><li>В общем случае комбинация техник такова: </li></ul></ul><ul><ul><ul><li>Определить зоны высшего риска </li></ul></ul></ul><ul><ul><ul><li>Выделить сценарии и их параметры </li></ul></ul></ul><ul><ul><ul><li>Создать тестовые сценарии </li></ul></ul></ul><ul><ul><ul><li>Разбить параметры на классы эквивалентности </li></ul></ul></ul>
    69. 69. Техники тестирования. Проблемы выбора <ul><li>Контрольные вопросы при использовании комбинации техник тестирования: </li></ul><ul><ul><li>Какие области наиболее рискованы? Как будут приоритезированы требования? </li></ul></ul><ul><ul><li>Какие есть сценарии использования для этих областей? </li></ul></ul><ul><ul><li>Какие параметры есть у этих сценариев? </li></ul></ul><ul><ul><li>На какие классы эквивалентности их можно разбить? </li></ul></ul><ul><ul><li>И наконец: какие тест-кейсы нужно составить? </li></ul></ul>
    70. 70. Практические примеры <ul><li>Описание тестируемого функционала: </li></ul><ul><li>Поле для ввода названия папки </li></ul><ul><li>Кнопка «Сохранить» </li></ul><ul><li>Название папки не должно превышать 64 символа </li></ul><ul><li>Ваши предложения? </li></ul>
    71. 71. Практический пример <ul><li>Диалог сохранения файла </li></ul>
    72. 72. «Фиксируем шаги» <ul><li>Сначала выделяем наиболее рискованные (и важные) области – собственно сохранение , выбор нужного места, сохранение с длинным именем, с национальными символами, перезапись и т.п. </li></ul><ul><li>Потом выясняем какие сценарии использования ( use case ) </li></ul><ul><li>Выясняем классы эквивалентности </li></ul><ul><li>Пишем тест-кейсы (позитивные, негативные, исследовательские) </li></ul>
    73. 73. Способы снижения количества тестов <ul><li>Рассмотрим пример </li></ul><ul><li>Окно поиска в текстовом редакторе </li></ul>
    74. 74. <ul><li>Подсчитаем количество тестов </li></ul><ul><li>5 переменных: </li></ul><ul><ul><li>Find what (FW) – строка </li></ul></ul><ul><ul><li>Match whole words only (MW) – Boolean </li></ul></ul><ul><ul><li>Match case (MC) – Boolean </li></ul></ul><ul><ul><li>Regular expression (RE) – Boolean </li></ul></ul><ul><ul><li>Direction (D) – перечисляемый тип ( Up, Down ) </li></ul></ul><ul><li>Тестовые значения </li></ul><ul><ul><li>FW = { ‘ lower ’ ; ‘ UPPER ’ ; ‘ MiXeD ’ } </li></ul></ul><ul><ul><li>MW, MC, RE = {Yes; No} </li></ul></ul><ul><ul><li>В = {Up; Down} </li></ul></ul><ul><li>Итого: 3 х 2 х 2 х 2 х 2 = 48 тестов </li></ul>
    75. 75. Способы снижения количества тестов <ul><li>Выбор комбинаций </li></ul><ul><li>Для данного случая методы выбора на основе рисков и на основе сценариев малопригодны </li></ul><ul><li>Оптимальнее использовать механический перебор по некоторой системе: </li></ul><ul><ul><li>Полный перебор </li></ul></ul><ul><ul><li>Все пары (каждый с каждым) </li></ul></ul><ul><ul><li>Все значения хотя бы по разу </li></ul></ul>
    76. 76. Способы снижения количества тестов <ul><li>Полный перебор (все Nки ) </li></ul>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. 77. Способы снижения количества тестов <ul><li>Все значения хотя бы по разу </li></ul>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. 78. Способы снижения количества тестов <ul><li>Все пары (каждый с каждым) </li></ul><ul><li>Этот метод является « золотой серединой » </li></ul><ul><li>Метод « всех пар » хорошо работает для независимых переменных </li></ul><ul><li>Зачастую случайное тестирование хорошо приближается к методу « всех пар » </li></ul>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. 79. Тест управляемый данными <ul><ul><li>Форма валидации введенного значения </li></ul></ul><ul><ul><li>Требование: если введено целочисленное значение от 0 до 9 (включительно), возвращается значение TRUE </li></ul></ul><ul><li>Предлагайте тесты (я записываю) </li></ul>Тест-дизайн
    80. 80. Тест управляемый поведением <ul><ul><li>Форма заказа sushi </li></ul></ul><ul><ul><li>Требование: пользователь может оформить или отредактировать сформированный ранее в разделе «Меню» заказ. Счёт формируется с учётом накопительных скидок, выбранного способа оплаты и доставки. </li></ul></ul><ul><li>Предлагайте тесты (я записываю) </li></ul>Тест-дизайн
    81. 81. «Фиксируем подход» <ul><li>Разработка тестов </li></ul><ul><ul><li>Определение типа теста: «поведение» или «данные» </li></ul></ul><ul><ul><ul><li>Logic-driven или data-driven test case </li></ul></ul></ul><ul><ul><li>Если тест управляется логикой поведения </li></ul></ul><ul><ul><ul><li>Составление путей и «узлов» </li></ul></ul></ul><ul><ul><ul><ul><li>Определяется основной «путь» </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Определяются и ограничиваются альтернативные «пути» </li></ul></ul></ul></ul><ul><ul><li>Если тест управляется данными </li></ul></ul><ul><ul><ul><li>Составляется набор данных </li></ul></ul></ul><ul><ul><ul><li>Данные приоретезируются </li></ul></ul></ul><ul><ul><ul><ul><li>Допустимые значения </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Граничные значения </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Значения за границами диапазона </li></ul></ul></ul></ul>Тест-дизайн
    82. 82. Практические примеры <ul><li>Входные данные </li></ul><ul><li>Бизнес по продаже апельсинов, имеющий несколько представительств в различных городах. </li></ul><ul><li>Задача </li></ul><ul><li>Разобраться в системе и разработать пакет тестовых сценариев </li></ul>Тест-дизайн
    83. 83. Практические примеры Тест-дизайн
    84. 84. Анализ архитектуры <ul><li>Архитектура </li></ul><ul><li>Сервер приложений </li></ul><ul><li>Сервер БД </li></ul><ul><li>«Толстые» клиенты, около 10 операторов </li></ul>Тест-дизайн <ul><li>Первые выводы и вопросы </li></ul><ul><li>Большинство операций происходит на стороне клиента </li></ul><ul><li>Тестируем клиентскую часть и сервер приложений </li></ul><ul><li>Сервер приложения может работать со своей БД и с БД центрального отделения </li></ul><ul><li>БД не содержит никакой логики – только хранилище? </li></ul>
    85. 85. Анализ конфигурационных требований <ul><li>Требования к конфигурациям </li></ul><ul><li>Клиентская часть поддерживается на 4-х ОС </li></ul><ul><li>Сервер приложения поддерживается на 2-х ОС </li></ul><ul><li>Локализация – система поддерживает два языка </li></ul><ul><li>На тестирование выносится 20 функциональных требований к клиентской части и 10 функциональных требований к серверной части </li></ul>Тест-дизайн
    86. 86. Пытаемся планировать <ul><li>Вопросы к обсуждению </li></ul><ul><li>Какие виды тестов будем проводить? </li></ul><ul><li>Нагрузочного тестирования не будет, 10 операторов – это не та нагрузка, которую стоит проверять (или будет?) </li></ul><ul><li>Что стоит автоматизировать, что нет? </li></ul><ul><li>Какие окружения выделяем для тестирования? </li></ul>Тест-дизайн
    87. 87. Попробуем прикинуть трудоёмкость <ul><li>Допущения </li></ul><ul><li>Допустим, на одно функциональное требование мы предполагаем написать 5 тестовых сценариев </li></ul><ul><li>Допустим, на прохождение 1-го тестового сценария мы предполагаем потратить 5 минут </li></ul><ul><li>Посчитайте сами и ответьте на следующие вопросы: </li></ul><ul><li>Сколько всего окружений получается? </li></ul><ul><li>Сколько всего тестовых сценариев будет в системе? </li></ul><ul><li>Время затраченное на проведение 1-го раунда тестирования? </li></ul>Тест-дизайн
    88. 88. Считаем окружения <ul><li>Окружений: 16 </li></ul><ul><li>4 клиентские ОС * 2 языка = 8 клиентских конфигураций * 2 серверные ОС = 16 окружений </li></ul><ul><li>Тестовых сценариев в системе: 150 </li></ul><ul><li>(20 клиентских требований + 10 серверных требований) * 5 тестовых сценариев на одно требование = 150 . </li></ul><ul><li>Сколько всего тестовых сценариев для проведения 1-го раунда тестирования? </li></ul>Тест-дизайн
    89. 89. Считаем время <ul><li>Расчеты </li></ul><ul><li>Всего тестовых сценариев: 16 окружений * 150 тестовых сценариев = 2400 </li></ul><ul><li>Время на проведение 1-го раунда тестирования: (2400 тестовых сценарев * 5 минут) / 60 = 200 часов или 5 недель </li></ul>Тест-дизайн
    90. 90. Давайте подумаем <ul><li>Что мы не учли? </li></ul><ul><li>Требования относятся к функциональности (логике приложения) или к окружению (системные функции, работа с ресурсами ОС и т.д.). </li></ul>Тест-дизайн
    91. 91. Разбор тестируемых функций <ul><li>Что зависит обычно от окружения на клиенте и сервере? </li></ul><ul><li>Вход, выход, печать форм, получение языка ОС, получение цветовой гаммы ОС, работа с протоколами общения между серверами приложений </li></ul><ul><li>Что не зависит от окружения? </li></ul><ul><li>Получение информации из БД, запрос на сервер приложения, анализ полученных данных на клиенте и т.д. </li></ul>Тест-дизайн
    92. 92. Подбиваем баланс по группам требований <ul><li>Получаем: </li></ul><ul><li>5 требований зависят от окружений на клиенте </li></ul><ul><li>5 требований зависят от всех окружений </li></ul><ul><li>5 требований зависят только от окружений сервера приложений </li></ul><ul><li>15 требований относятся к функциональности и не зависят от окружений </li></ul>Тест-дизайн
    93. 93. Пересчитываем <ul><li>Итого: </li></ul><ul><li>25 тестовых сценариев * 8 = 200 тестовых сценариев зависящих от окружения на клиенте </li></ul><ul><li>25 тестовых сценариев * 16 = 400 тестовых сценариев зависящих от всех конфигураций </li></ul><ul><li>25 тестовых сценариев * 2 = 50 тестовых сценариев зависящих от окружения на сервере приложений </li></ul><ul><li>75 тестовых сценариев относятся к функциональным тестам </li></ul><ul><li>200 + 400 + 50 + 75 = 725 тестовых сценариев </li></ul>Тест-дизайн
    94. 94. Сила тест-дизайна <ul><li>Расчеты </li></ul><ul><li>Всего тестовых сценариев: 725 </li></ul><ul><li>Время на проведение 1-го раунда тестирования: (725 тестовых сценариев * 5 минут) / 60 = 60,5 часов или 1,5 недели </li></ul><ul><li>Было: 200 часов или 5 недель </li></ul><ul><li>Стало: 60,5 часов или 1,5 недели </li></ul><ul><ul><ul><ul><li>Экономия достигается за счёт принимаемых допущений и связанных с ними рисков </li></ul></ul></ul></ul>Тест-дизайн
    95. 95. <ul><li>Введение в тестирование программного обеспечения </li></ul><ul><li>Луиза Тамре </li></ul><ul><li>Introducing Software Testing </li></ul><ul><li>Издательство: Вильямс, 2003 г . </li></ul><ul><li>В этой книге изложены: </li></ul><ul><ul><li>Последовательность вхождения в процесс тестирования с акцентом на ключевых функциях; </li></ul></ul><ul><ul><li>Определение недостающих сведений и проведение адекватного тестирования при недостаточно четких требованиях; </li></ul></ul><ul><ul><li>Изучение различных форматов документации для регистрации тестовых примеров . </li></ul></ul>Рекомендуемая литература
    96. 96. <ul><li>Быстрое тестирование </li></ul><ul><li>Роберт Калбертсон, Крис Браун, Гэри Кобб </li></ul><ul><li>Издательство: Вильямс, 2002 г. </li></ul><ul><li>Технология быстрого тестирования находит `золотую середину` между соблюдением сроков и гарантией высокого качества. Описанию этой технологии и посвящена книга. </li></ul><ul><li>Книга написана с учетом громадного опыта работы авторов в области тестирования ПО. Она окажет несомненную пользу всем специалистам, которые работают как в крупных, так и в небольших организациях, занимающихся созданием ПО. </li></ul>Рекомендуемая литература
    97. 97. Рекомендуемая литература <ul><li>Тестирование dot com </li></ul><ul><li>Роман Савин </li></ul><ul><li>Издательство: Дело, 2007 г. </li></ul><ul><li>Этот курс лекций создан для тех, кто хочет обучиться тестированию, понять, как вести себя в корпоративном окружении, и добиться профессионального и личностного роста. Он будет интересен и участникам процесса разработки программного обеспечения, рекрутерам, людям, связанным с интернетом или пишущим о нем, и просто всем желающим понять кухню интернет-стартапов </li></ul>Тест-дизайн
    98. 98. Слава Панкратов «Тест-дизайн» http://pankratov.org.ua [email_address] icq: 109882167

    ×