- Главная
- Разное
- Дизайн
- Бизнес и предпринимательство
- Аналитика
- Образование
- Развлечения
- Красота и здоровье
- Финансы
- Государство
- Путешествия
- Спорт
- Недвижимость
- Армия
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Тест-дизайн презентация
Содержание
- 1. Тест-дизайн
- 2. Почему чем позже, тем дороже? Тест-дизайн Удельная
- 3. Стоимость исправления ошибок Тест-дизайн Задачи тестирования ПО
- 4. Сколько это будет стоить исправить? Тест-дизайн Невозможно
- 5. АВТОРСКИЙ КОЛЛЕКТИВ Вячеслав Панкратов http://pankratov.org.ua/ Дмитрий Лысенко http://dmitrylysenko.info/ Тест-дизайн
- 6. РАСПИСАНИЕ: 10.00-17.00 I день Входное анкетирование Качество
- 7. СОДЕРЖАНИЕ КУРСА Процесс тестирования ПО и место
- 8. БАЗОВЫЕ ПОНЯТИЯ Качество информационных систем Процесс тестирования
- 9. Характеристики качества ПО Тест-дизайн Функциональность, надежность, производительность
- 10. Эволюция представлений о тестировании Проверка соответствия между
- 11. Определение: Тестирование ПО Тест-дизайн Тестирование ПО –
- 12. Место тестирования в процессе разработки ПО
- 13. Тестирование программного продукта Проектирование тестов
- 14. Стадии тестирования Отладка тестов Выполнение
- 15. BUC-UC-TC и другие страшные слова Тест-дизайн BUC/BR
- 16. Тест-дизайн Тест-дизайн Определение и практика Тест-дизайн –
- 17. ОБЗОР РОЛИ: ДИЗАЙНЕР ТЕСТОВ Круг ответственности Круг активностей Артефакты роли Тест-дизайн
- 18. Тестирование в картинках (RUP) Тест-дизайн
- 19. Тест дизайн в картинках (RUP)
- 20. Тест-аналитик: внимание, совмещаем! Тест-дизайн Определяет, приоритизирует и
- 21. Тест-дизайнер Тест-дизайн Устанавливает и определяет операции,
- 22. Обзор артефактов тестирования Аналитик Test Case Test-Ideas
- 23. ТЕСТ, ТЕСТОВЫЙ НАБОР, СТРАТЕГИЯ Определения Тест, тестовый набор, тестовое покрытие Стратегия тестирования Тест-дизайн
- 24. Определение теста и тестового набора Тест-дизайн Тест
- 25. Определение теста и тестового набора Тест-дизайн Тестовый
- 26. Определение теста и тестового набора Тест-дизайн Разработка
- 27. Тестовое покрытие Requirements-based Test Coverage Метрика покрытия,
- 28. Тест дизайн, как этап тестирования Тест-дизайн На
- 29. Стратегия тестирования Тест-дизайн Типы тестирования Тестирование данных
- 30. Типы тестирования: целостность данных Тест-дизайн Цель: убедиться
- 31. Типы тестирования: функциональное тестирование Тест-дизайн 90% нашего
- 32. Типы тестирования: бизнес циклы Тест-дизайн Бизнес-циклы: сущность,
- 33. Типы тестирования: GUI, usability Тест-дизайн Обычно данный
- 34. Типы тестирования: производительность Тест-дизайн Производительность: способность совершать
- 35. Типы тестирования: безопасность и доступ Тест-дизайн Выделяют
- 36. Типы тестирования: конфигурационные тесты Тест-дизайн Тестирование системы
- 37. Типы тестирования: тестирование инсталляций Тест-дизайн Школа жизни
- 38. РАБОТА С ТРЕБОВАНИЯМИ Работа с изменяющимися требованиями
- 39. Что было написано в требовании Тест-дизайн SRS-01
- 40. Что изменилось в требовании Тест-дизайн SRS-01.1 (после
- 41. Практический кейс Что должно произойти в тест-кейсах?
- 42. Работа с требованиями Пример нетестируемого требования производительности
- 43. Работа с требованиями Пример тестопригодного требования Время
- 44. Работа с требованиями Что мы упустили в
- 45. Работа с требованиями Пример тестопригодного требования Время
- 46. Работа с требованиями Практические соображения Изменения в
- 47. Работа с требованиями Практические соображения При условии
- 48. Работа с требованиями Практические соображения Требования могут
- 49. ЭКВИВАЛЕНТНОЕ РАЗБИЕНИЕ Что значит «протестировать полностью»? Классы эквивалентности Виды тестовых сценариев Тест-дизайн
- 50. Что значит «протестировать полностью»?
- 51. Полное тестирование это – Когда покрыты все:
- 52. Количество всех возможных комбинаций входных данных
- 53. Виды тестовых сценариев Позитивные сценарии Негативные сценарии
- 54. Чтобы избежать ненужного тестирования, разбейте область входных
- 55. Если тест с некоторым значением из данного класса эквивалентности
- 56. Рассмотрим пример Программа складывает два целых числа
- 57. Классы эквивалентности
- 58. Порядок действий Перечисляются все переменные (как входные,
- 59. Какие еще сущности можно разбивать на классы
- 60. «Треугольник» Программа запрашивает три числа Определяется тип
- 61. Корректный разносторонний треугольник Корректный равносторонний треугольник Три
- 62. ТЕСТИРОВАНИЕ НА ОСНОВЕ СЦЕНАРИЕВ И РИСКОВ Пользователь
- 63. Техники: тестирование на основе сценариев Суть метода
- 64. Сценарии могут использоваться как в разработке, так
- 65. Сценарии, использовавшиеся при разработке: Уже проверены самими
- 66. Техники: тестирование на основе рисков Подходы к
- 67. Техники: тестирование на основе рисков Как понять
- 68. Техники тестирования. Проблемы выбора Не рекомендуется ограничиваться
- 69. Техники тестирования. Проблемы выбора Контрольные вопросы при
- 70. Практические примеры Описание тестируемого функционала: Поле для
- 71. Практический пример Диалог сохранения файла
- 72. «Фиксируем шаги» Сначала выделяем наиболее рискованные (и
- 73. Способы снижения количества тестов Рассмотрим пример Окно поиска в текстовом редакторе
- 74. Подсчитаем количество тестов 5 переменных: Find what
- 75. Способы снижения количества тестов Выбор комбинаций Для
- 76. Способы снижения количества тестов Полный перебор (все Nки)
- 77. Способы снижения количества тестов Все значения хотя
- 78. Способы снижения количества тестов Все пары (каждый
- 79. Тест управляемый данными Форма валидации введенного значения
- 80. Тест управляемый поведением Форма заказа sushi Требование:
- 81. «Фиксируем подход» Разработка тестов Определение типа теста:
- 82. Практические примеры Тест-дизайн Входные данные Бизнес по
- 83. Практические примеры Тест-дизайн
- 84. Анализ архитектуры Архитектура Сервер приложений Сервер БД
- 85. Анализ конфигурационных требований Требования к конфигурациям Клиентская
- 86. Пытаемся планировать Вопросы к обсуждению Какие виды
- 87. Попробуем прикинуть трудоёмкость Допущения Допустим, на одно
- 88. Считаем окружения Окружений: 16 4 клиентские ОС
- 89. Считаем время Расчеты Всего тестовых сценариев: 16
- 90. Давайте подумаем Что мы не учли? Требования
- 91. Разбор тестируемых функций Что зависит обычно от
- 92. Подбиваем баланс по группам требований Получаем: 5
- 93. Пересчитываем Итого: 25 тестовых сценариев * 8
- 94. Сила тест-дизайна Расчеты Всего тестовых сценариев: 725
- 95. Введение в тестирование программного обеспечения Луиза Тамре
- 96. Быстрое тестирование Роберт Калбертсон, Крис Браун, Гэри
- 97. Рекомендуемая литература Тест-дизайн Тестирование dot com Роман
- 98. Слава Панкратов «Тест-дизайн» http://pankratov.org.ua slava@pankratov.org.ua icq: 109882167
Почему чем позже, тем дороже? Тест-дизайн Удельная стоимость исправления дефектов быстро растет по мере продвижения продукта к стадии эксплуатации. Так, в статье B. Boehm and V. Basili «Software Defect Reduction Top
Слайд 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%).
По данным, опубликованным Национальным институтом стандартов (NIST 2002 RTI Project 7007.011), основное количество ошибок в продукте (70%!) закрадывается на стадии выработки требований и построения дизайна.
А обнаруживается подавляющее большинство дефектов либо в процессе тестирования (около 60%), либо уже при эксплуатации (21%).
Слайд 5АВТОРСКИЙ КОЛЛЕКТИВ
Вячеслав Панкратов
http://pankratov.org.ua/
Дмитрий Лысенко
http://dmitrylysenko.info/
Тест-дизайн
Слайд 6РАСПИСАНИЕ: 10.00-17.00
I день
Входное анкетирование
Качество информационных систем
Процесс тестирования ПО
Место практики «Тест-дизайн»
Обзор роли:
дизайнер тестов
Связь проектных артефактов
Тест, тестовый набор, покрытие, стратегия
Работа с требованиями
II день
Техники тестирования
Практика
Финальное анкетирование
Связь проектных артефактов
Тест, тестовый набор, покрытие, стратегия
Работа с требованиями
II день
Техники тестирования
Практика
Финальное анкетирование
Слайд 7СОДЕРЖАНИЕ КУРСА
Процесс тестирования ПО и место практики «Тест-дизайн»
Преимущества и недостатки методов
тест дизайна
Определение роли дизайнера тестов: зона ответственности
Активности разработки/дизайна тестов
Практические соображения работы с требованиями
Обзор артефактов тест дизайнера
Практические примеры
Определение роли дизайнера тестов: зона ответственности
Активности разработки/дизайна тестов
Практические соображения работы с требованиями
Обзор артефактов тест дизайнера
Практические примеры
Слайд 8БАЗОВЫЕ ПОНЯТИЯ
Качество информационных систем
Процесс тестирования ПО
Тест-дизайн: определение и практика
Место практики «Тест-дизайн»
Связь
проектных артефактов
Тест-дизайн
Слайд 9Характеристики качества ПО
Тест-дизайн
Функциональность, надежность, производительность
Надежность — работает ли приложение без сбоев,
«зависаний» или вызова исключений
Функциональность — делает ли приложение то, что от него требуется
Производительность — работает ли приложение с приемлемой скоростью при доступе к нему многих пользователей
Функциональность — делает ли приложение то, что от него требуется
Производительность — работает ли приложение с приемлемой скоростью при доступе к нему многих пользователей
Слайд 10Эволюция представлений о тестировании
Проверка соответствия между реальным поведением программы и ее
ожидаемым поведением на конечном наборе тестов, выбранном определенным образом. [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]
Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц. [С. 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]
Тест-дизайн
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)
Эксплуатация и
поддержка
Стадии
динамического
тестирования
Непосредственная проверка спроектированных
тестов, анализ всевозможных тестовых случаев
Функциональная проверка, тестирование для определения рабочих характеристик
Альфа-тестирование,
Бета-тестирование
Проверка результатов, исправление дефектов.
Пересмотр и отладка тестовых случаев
Слайд 15BUC-UC-TC и другие страшные слова
Тест-дизайн
BUC/BR – business use case или business
rule, бизнес-требование или бизнес-правило
UC – use case, сценарий использования
TC – test case, сценарий тестирования
UC – use case, сценарий использования
TC – test case, сценарий тестирования
Слайд 16Тест-дизайн
Тест-дизайн
Определение и практика
Тест-дизайн – это этап процесса тестирования ПО, который включает
создание/проектирование тестовых сценариев и определение необходимых типов тестов, для достижения заданного уровня тестового покрытия приложения или системы под тестом
Тест-дизайн – это техника, кардинально влияющая на стоимость тестирования, так как задаёт объёмы работ и границы проекта по тестированию
Тест-дизайн – это попытка найти баланс между трудозатратами на тестирование и приемлемым уровнем доверия к результатам тестирования
Тест-дизайн – это техника, кардинально влияющая на стоимость тестирования, так как задаёт объёмы работ и границы проекта по тестированию
Тест-дизайн – это попытка найти баланс между трудозатратами на тестирование и приемлемым уровнем доверия к результатам тестирования
Слайд 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
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 (ожидаемые Выход, выходные данные или выходной состояние системы)
Триплет 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)
Смешанные методики – комбинация подходов
На основе сценариев использования
На основе ортогональной классификации дефектов
Формальные методики оценки объемов работ
Метод расчета цикломатической сложности, основанный на метрике МакКаби (McCabe)
Смешанные методики – комбинация подходов
Слайд 27Тестовое покрытие
Requirements-based Test Coverage
Метрика покрытия, основанная на анализе тестовых требований,
Собирается
несколько раз в течении одного цикла тестирования для анализа завершенности тестирования
Вычисляется как соотношение всех запланированных, имплементированных и выполненных тестовых случаев к количеству тестовых требований, существующих для тестового цикла
Вычисляется как соотношение всех запланированных, имплементированных и выполненных тестовых случаев к количеству тестовых требований, существующих для тестового цикла
Тест-дизайн
Слайд 28Тест дизайн, как этап тестирования
Тест-дизайн
На этапе тест-дизайна выясняется и определяется
Список тестируемых
функций и модулей
Тестируемость каждой функции и модуля
Наиболее оптимальный подход (техника) для проверки каждой функции, модуля или подсистемы
Набор типов тестов
Последовательность проведения и критерии завершенности тестирования
Основные артефакты:
тест кейс и стратегия тестирования ПО
Тестируемость каждой функции и модуля
Наиболее оптимальный подход (техника) для проверки каждой функции, модуля или подсистемы
Набор типов тестов
Последовательность проведения и критерии завершенности тестирования
Основные артефакты:
тест кейс и стратегия тестирования ПО
Слайд 29Стратегия тестирования
Тест-дизайн
Типы тестирования
Тестирование данных и целостности базы данных
Функциональное тестирование
Тестирование бизнес-циклов
Тестирование пользовательского
интерфейса
Нагрузочное тестирование
Тестирование безопасности и управления доступом
Конфигурационное тестирование
Инсталляционное тестирование
Инструментальные средства
Нагрузочное тестирование
Тестирование безопасности и управления доступом
Конфигурационное тестирование
Инсталляционное тестирование
Инструментальные средства
Слайд 30Типы тестирования: целостность данных
Тест-дизайн
Цель: убедиться в невозможности создания «несвязных данных» -
данных, которые могут быть созданы-отредактированы-агрегированы при нормальной работе системы или при возникновении сбоев в работе.
Обращайте внимание:
На включение-отключение триггеров и ограничений при импорте-экспорте данных
На включение-отключение триггеров и ограничений при переводе системы в production режим
На включение-отключение триггеров и ограничений при операциях архивирования и завершении бизнес-циклов
На поведение системы относительно данных при разрывах соединений клиент-сервер-БД в любых сочетаниях
Обращайте внимание:
На включение-отключение триггеров и ограничений при импорте-экспорте данных
На включение-отключение триггеров и ограничений при переводе системы в production режим
На включение-отключение триггеров и ограничений при операциях архивирования и завершении бизнес-циклов
На поведение системы относительно данных при разрывах соединений клиент-сервер-БД в любых сочетаниях
Слайд 31Типы тестирования: функциональное тестирование
Тест-дизайн
90% нашего с вами рабочего времени
Проверка функциональных требований:
логики и бизнес-правил приложения или системы
Как правильно полноценное системное/функциональное тестирование является самым трудоёмким процессом и может занимать (Ф.Брукс) до 80% всего бюджета проекта по тестированию
Обращайте внимание:
На невозможность полного покрытия – всегда надо выбирать
На необходимость постоянно отслеживать приоритетность требований от версии к версии: требования меняются, приоритеты тоже
Как правильно полноценное системное/функциональное тестирование является самым трудоёмким процессом и может занимать (Ф.Брукс) до 80% всего бюджета проекта по тестированию
Обращайте внимание:
На невозможность полного покрытия – всегда надо выбирать
На необходимость постоянно отслеживать приоритетность требований от версии к версии: требования меняются, приоритеты тоже
Слайд 32Типы тестирования: бизнес циклы
Тест-дизайн
Бизнес-циклы: сущность, которая описывает и задаёт следующий уровень
функционального тестирования и служит про проверки корректности работы алгоритмов и механизмов, автоматизирующих не столько пользовательские операции, сколько естественную цикличность любого бизнеса, завершающуюся отчётами, архивированием данных, выполнением нетипичных для системы операций.
Закрытие месяца, закрытие года, получение очередной крупнооптовой партии товаров, расчёт пени, реструктуризации долгов и т.п.
Закрытие месяца, закрытие года, получение очередной крупнооптовой партии товаров, расчёт пени, реструктуризации долгов и т.п.
Слайд 33Типы тестирования: GUI, usability
Тест-дизайн
Обычно данный тип тестирования не обладает формальным признаком
запрета выпуска версии
Результатом выполнения данного типа тестов является список рекомендаций и предложений по улучшению
Основной для проведения данного типа тестов могут являться принятые в компании/проекте стандарты оформления пользовательских интерфейсов или общепринятые User Interface Guidelines:
Например, Microsoft Windows XP/2000 User Interface Guidelines
Результатом выполнения данного типа тестов является список рекомендаций и предложений по улучшению
Основной для проведения данного типа тестов могут являться принятые в компании/проекте стандарты оформления пользовательских интерфейсов или общепринятые User Interface Guidelines:
Например, Microsoft Windows XP/2000 User Interface Guidelines
Слайд 34Типы тестирования: производительность
Тест-дизайн
Производительность: способность совершать определённое количество операций в единицу времени
Тестирование
производительности: нормальная, ожидаемая модель нагрузки
Нагрузочное: предельная или превышающая нормальную модель нагрузки
Стрессовое тестирование: сознательное превышение нагрузок или урезание ресурсов с целью посмотреть «как будет падать и подниматься»
Объёмное тестирование: тестирование способности обработки больших объёмов операционных или хранения архивных данных
Нагрузочное: предельная или превышающая нормальную модель нагрузки
Стрессовое тестирование: сознательное превышение нагрузок или урезание ресурсов с целью посмотреть «как будет падать и подниматься»
Объёмное тестирование: тестирование способности обработки больших объёмов операционных или хранения архивных данных
Слайд 35Типы тестирования: безопасность и доступ
Тест-дизайн
Выделяют два больших типа тестов:
Разграничение прав доступа
к данным и операциям и соотв. невозможность несанкционированного доступа к данным и выполнению операций
Устойчивость системы к внешним проникновениям, несанкционированным вызовам функций, инъекциям исполняемого кода, вызова нештатных ситуаций, переполнений и т.д.
Применяют как средства анализа кода, так и накопленную (зачастую внешнюю) экспертизу
Устойчивость системы к внешним проникновениям, несанкционированным вызовам функций, инъекциям исполняемого кода, вызова нештатных ситуаций, переполнений и т.д.
Применяют как средства анализа кода, так и накопленную (зачастую внешнюю) экспертизу
Слайд 36Типы тестирования: конфигурационные тесты
Тест-дизайн
Тестирование системы на различных конфигурациях программно-аппаратного стенда
Цели:
Проверка-выявление списка
поддерживаемых окружений
Подбор минимальных-оптимальных-рекомендуемых параметров аппаратного обеспечения
Обращайте внимание на составления «матрицы покрытия»
Очень ресурсоёмкий и затратный тип тестов
Относиться в основном к тестированию функциональности, но также может затрагивать и вопросы тестирования производительности
Подбор минимальных-оптимальных-рекомендуемых параметров аппаратного обеспечения
Обращайте внимание на составления «матрицы покрытия»
Очень ресурсоёмкий и затратный тип тестов
Относиться в основном к тестированию функциональности, но также может затрагивать и вопросы тестирования производительности
Слайд 37Типы тестирования: тестирование инсталляций
Тест-дизайн
Школа жизни для тестировщика ☺
Современные инсталляции умеют очень
глубоко залазить в систему и на лету менять её компоненты
Развёртывание – вариант инсталляции
Инсталляция – отдельное и потенциально достаточно сложное приложение, которое требует отельного планирования и выполнения тестов
Для тестирования инсталляций характерно выделять отдельный список поддерживаемых окружений и проводить отдельный цикл конфигурационного тестирования
Развёртывание – вариант инсталляции
Инсталляция – отдельное и потенциально достаточно сложное приложение, которое требует отельного планирования и выполнения тестов
Для тестирования инсталляций характерно выделять отдельный список поддерживаемых окружений и проводить отдельный цикл конфигурационного тестирования
Слайд 38РАБОТА С ТРЕБОВАНИЯМИ
Работа с изменяющимися требованиями
Пример нетестируемого требования
Пример тестопригодного требования
Почему не
все могут и должны заниматься дизайном
Слайд 39Что было написано в требовании
Тест-дизайн
SRS-01 (до изменения)
Форма регистрации нового пользователя
в системе “InfoSecurityManagement” позволяет вводить в реестр пользователей данные о пользователе и его роли:
Имя,
Доменное имя,
Должность,
Полномочия в системе
Имя,
Доменное имя,
Должность,
Полномочия в системе
Слайд 40Что изменилось в требовании
Тест-дизайн
SRS-01.1 (после изменения)
Форма регистрации нового пользователя в
системе “InfoSecurityManagement” позволяет вводить в реестр пользователей данные о пользователе и его роли:
Имя,
Доменное имя,
Должность,
Полномочия в системе
Если такой пользователь уже существует в реестре системы “InfoSecurityManagement”, на форме ввода появляется его E-mail адрес.
Имя,
Доменное имя,
Должность,
Полномочия в системе
Если такой пользователь уже существует в реестре системы “InfoSecurityManagement”, на форме ввода появляется его E-mail адрес.
Слайд 41Практический кейс
Что должно произойти в тест-кейсах?
Кто это должен сделать?
Когда это может
происходить?
Вы уверены, что ваш рядовой тестер понимает глубину задачи?
Вы уверены, что ваш рядовой тестер понимает глубину задачи?
Тест-менеджмент
Слайд 42Работа с требованиями
Пример нетестируемого требования производительности ПО
Время отклика системы должно находится
в приемлемых рамках
Время отклика (Отклика на какой операции?) системы (что такое система в этом требовании: UI, DB, client + server + network?) должно находится (Условия? Нагрузка?) в приемлемых рамках (Цифры?)
Время отклика (Отклика на какой операции?) системы (что такое система в этом требовании: 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ЭКВИВАЛЕНТНОЕ РАЗБИЕНИЕ
Что значит «протестировать полностью»?
Классы эквивалентности
Виды тестовых сценариев
Тест-дизайн
Слайд 51Полное тестирование это –
Когда покрыты все:
строки кода программы
ветви кода в программе
пути
в коде
входные данные и все их возможные комбинации
последовательности комбинаций входных данных
...
входные данные и все их возможные комбинации
последовательности комбинаций входных данных
...
Слайд 52
Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно
было проверить полностью
Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью
Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования
Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью
Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования
Почему нельзя полностью протестировать программу
Слайд 53Виды тестовых сценариев
Позитивные сценарии
Негативные сценарии
Граничные сценарии
Исследовательские сценарии:
«А что должно быть если…»
Слайд 54Чтобы избежать ненужного тестирования, разбейте область входных значений на группы эквивалентных
тестов
Два теста считаются эквивалентными если они настолько похожи, что проводить оба бессмысленно
Два теста считаются эквивалентными если они настолько похожи, что проводить оба бессмысленно
Техники тестирования. Эквивалентное разбиение
Слайд 55Если тест с некоторым значением из данного класса эквивалентности обнаруживает ошибку, то было бы разумно
ожидать обнаружения той же ошибки тестом с любым другим значением из данного класса эквивалентности
Выберите одно входное значение из каждого класса эквивалентности в качестве представителя целой группы значений
Выберите одно входное значение из каждого класса эквивалентности в качестве представителя целой группы значений
Техники тестирования. Эквивалентное разбиение
Слайд 56Рассмотрим пример
Программа складывает два целых числа
Каждое из слагаемых – не более
чем целое двузначное число
Программа запрашивает у пользователя два числа и выводит результат
Предлагайте тесты >>
Программа запрашивает у пользователя два числа и выводит результат
Предлагайте тесты >>
Техники тестирования. Эквивалентное разбиение
Слайд 58Порядок действий
Перечисляются все переменные (как входные, так и выходные)
Для каждой переменной
определяется разбиение на классы
Строятся все возможные комбинации классов
В качестве представителей берутся граничные, приграничные или специальные значения
Строятся все возможные комбинации классов
В качестве представителей берутся граничные, приграничные или специальные значения
Техники тестирования. Эквивалентное разбиение
Слайд 59Какие еще сущности можно разбивать на классы эквивалентности
числа
символы
количество (записей в
БД, строк)
длина строки
размер файла
объем памяти
разрешение экрана
версии операционной системы, библиотек
объем передаваемых данных
длина строки
размер файла
объем памяти
разрешение экрана
версии операционной системы, библиотек
объем передаваемых данных
Техники тестирования. Эквивалентное разбиение
Слайд 60«Треугольник»
Программа запрашивает три числа
Определяется тип треугольника, имеющего стороны введенной длины: равносторонний,
равнобедренный, разносторонний
Предлагайте тесты >>
Предлагайте тесты >>
Практические примеры
Техники тестирования. Эквивалентное разбиение
Слайд 61Корректный разносторонний треугольник
Корректный равносторонний треугольник
Три корректных равнобедренных треугольника (a=b, b=c, a=c)
Одна,
две или три стороны равны нулю (5 тестов)
Одна сторона отрицательная
«Почти» выполняется правило треугольника (три варианта a+b=c, a+c=b, b+c=a)
Не выполняется правило треугольника (три варианта a+bНецелое число или не число
Неправильное количество аргументов
Одна сторона отрицательная
«Почти» выполняется правило треугольника (три варианта a+b=c, a+c=b, b+c=a)
Не выполняется правило треугольника (три варианта a+b
Неправильное количество аргументов
Техники тестирования. Эквивалентное разбиение
Слайд 62ТЕСТИРОВАНИЕ НА ОСНОВЕ СЦЕНАРИЕВ И РИСКОВ
Пользователь прежде всего
Немного agile и экстрима
Когда
страшно это хорошо
Тест-дизайн
Слайд 63Техники: тестирование на основе сценариев
Суть метода – тестировщик выполняет сценарии пользователей
Разновидности
сценариев:
Истории пользователя
Варианты использования (use cases)
Тестовые сценарии (test cases)
Истории пользователя
Варианты использования (use cases)
Тестовые сценарии (test cases)
Слайд 64Сценарии могут использоваться как в разработке, так и в тестировании
При использовании
их в тестировании
Тестировщики следуют сценариям, которые использовались при разработке
Создают новые сценарии путем комбинации имеющихся
Тестировщики следуют сценариям, которые использовались при разработке
Создают новые сценарии путем комбинации имеющихся
Техники: тестирование на основе сценариев
Слайд 65Сценарии, использовавшиеся при разработке:
Уже проверены самими разработчиками
Не учитывают нестандартные случаи, намеренно
неправильное использование
Новые сценарии:
Возможно никогда не встретятся в реальной эксплуатации
Требуют время на написание
Новые сценарии:
Возможно никогда не встретятся в реальной эксплуатации
Требуют время на написание
Техники: тестирование на основе сценариев
Слайд 66Техники: тестирование на основе рисков
Подходы к тестированию на основе рисков
Приоритезация требований
в соответствии с оценкой рисков; проверка требований соглано приоритетам
Приоритезация проблемных областей в соответствии с оценкой рисков; целенаправленный поиск ошибок определенного типа
Приоритезация проблемных областей в соответствии с оценкой рисков; целенаправленный поиск ошибок определенного типа
Слайд 67Техники: тестирование на основе рисков
Как понять что такое «рискованная область»
Рисуем схему
приложения
Сайт бронирования билетов
Определяем веса узлов и переходов
Контролируем основные и альтернативные пути
«Где тонко – там и рвётся»
Сайт бронирования билетов
Определяем веса узлов и переходов
Контролируем основные и альтернативные пути
«Где тонко – там и рвётся»
Слайд 68Техники тестирования. Проблемы выбора
Не рекомендуется ограничиваться какой-либо одной техникой тестирования. Как
правило, используются их сочетания
В общем случае комбинация техник такова:
Определить зоны высшего риска
Выделить сценарии и их параметры
Создать тестовые сценарии
Разбить параметры на классы эквивалентности
В общем случае комбинация техник такова:
Определить зоны высшего риска
Выделить сценарии и их параметры
Создать тестовые сценарии
Разбить параметры на классы эквивалентности
Слайд 69Техники тестирования. Проблемы выбора
Контрольные вопросы при использовании комбинации техник тестирования:
Какие области
наиболее рискованы? Как будут приоритезированы требования?
Какие есть сценарии использования для этих областей?
Какие параметры есть у этих сценариев?
На какие классы эквивалентности их можно разбить?
И наконец: какие тест-кейсы нужно составить?
Какие есть сценарии использования для этих областей?
Какие параметры есть у этих сценариев?
На какие классы эквивалентности их можно разбить?
И наконец: какие тест-кейсы нужно составить?
Слайд 70Практические примеры
Описание тестируемого функционала:
Поле для ввода названия папки
Кнопка «Сохранить»
Название папки не
должно превышать 64 символа
Ваши предложения?
Ваши предложения?
Слайд 72«Фиксируем шаги»
Сначала выделяем наиболее рискованные (и важные) области – собственно сохранение
, выбор нужного места, сохранение с длинным именем, с национальными символами, перезапись и т.п.
Потом выясняем какие сценарии использования (use case)
Выясняем классы эквивалентности
Пишем тест-кейсы (позитивные, негативные, исследовательские)
Потом выясняем какие сценарии использования (use case)
Выясняем классы эквивалентности
Пишем тест-кейсы (позитивные, негативные, исследовательские)
Слайд 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 тестов
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Способы снижения количества тестов
Выбор комбинаций
Для данного случая методы выбора на основе
рисков и на основе сценариев малопригодны
Оптимальнее использовать механический перебор по некоторой системе:
Полный перебор
Все пары (каждый с каждым)
Все значения хотя бы по разу
Оптимальнее использовать механический перебор по некоторой системе:
Полный перебор
Все пары (каждый с каждым)
Все значения хотя бы по разу
Слайд 78Способы снижения количества тестов
Все пары (каждый с каждым)
Этот метод является «золотой
серединой»
Метод «всех пар» хорошо работает для независимых переменных
Зачастую случайное тестирование хорошо приближается к методу «всех пар»
Метод «всех пар» хорошо работает для независимых переменных
Зачастую случайное тестирование хорошо приближается к методу «всех пар»
Слайд 79Тест управляемый данными
Форма валидации введенного значения
Требование: если введено целочисленное значение от
0 до 9 (включительно), возвращается значение TRUE
Предлагайте тесты (я записываю)
Предлагайте тесты (я записываю)
Тест-дизайн
Слайд 80Тест управляемый поведением
Форма заказа sushi
Требование: пользователь может оформить или отредактировать сформированный
ранее в разделе «Меню» заказ. Счёт формируется с учётом накопительных скидок, выбранного способа оплаты и доставки.
Предлагайте тесты (я записываю)
Предлагайте тесты (я записываю)
Тест-дизайн
Слайд 81«Фиксируем подход»
Разработка тестов
Определение типа теста: «поведение» или «данные»
Logic-driven или data-driven test
case
Если тест управляется логикой поведения
Составление путей и «узлов»
Определяется основной «путь»
Определяются и ограничиваются альтернативные «пути»
Если тест управляется данными
Составляется набор данных
Данные приоретезируются
Допустимые значения
Граничные значения
Значения за границами диапазона
Если тест управляется логикой поведения
Составление путей и «узлов»
Определяется основной «путь»
Определяются и ограничиваются альтернативные «пути»
Если тест управляется данными
Составляется набор данных
Данные приоретезируются
Допустимые значения
Граничные значения
Значения за границами диапазона
Тест-дизайн
Слайд 82Практические примеры
Тест-дизайн
Входные данные
Бизнес по продаже апельсинов, имеющий несколько представительств в различных
городах.
Задача
Разобраться в системе и разработать пакет тестовых сценариев
Задача
Разобраться в системе и разработать пакет тестовых сценариев
Слайд 84Анализ архитектуры
Архитектура
Сервер приложений
Сервер БД
«Толстые» клиенты, около 10 операторов
Тест-дизайн
Первые выводы и вопросы
Большинство
операций происходит на стороне клиента
Тестируем клиентскую часть и сервер приложений
Сервер приложения может работать со своей БД и с БД центрального отделения
БД не содержит никакой логики – только хранилище?
Тестируем клиентскую часть и сервер приложений
Сервер приложения может работать со своей БД и с БД центрального отделения
БД не содержит никакой логики – только хранилище?
Слайд 85Анализ конфигурационных требований
Требования к конфигурациям
Клиентская часть поддерживается на 4-х ОС
Сервер приложения
поддерживается на 2-х ОС
Локализация – система поддерживает два языка
На тестирование выносится 20 функциональных требований к клиентской части и 10 функциональных требований к серверной части
Локализация – система поддерживает два языка
На тестирование выносится 20 функциональных требований к клиентской части и 10 функциональных требований к серверной части
Тест-дизайн
Слайд 86Пытаемся планировать
Вопросы к обсуждению
Какие виды тестов будем проводить?
Нагрузочного тестирования не
будет, 10 операторов – это не та нагрузка, которую стоит проверять (или будет?)
Что стоит автоматизировать, что нет?
Какие окружения выделяем для тестирования?
Что стоит автоматизировать, что нет?
Какие окружения выделяем для тестирования?
Тест-дизайн
Слайд 87Попробуем прикинуть трудоёмкость
Допущения
Допустим, на одно функциональное требование мы предполагаем написать 5
тестовых сценариев
Допустим, на прохождение 1-го тестового сценария мы предполагаем потратить 5 минут
Посчитайте сами и ответьте на следующие вопросы:
Сколько всего окружений получается?
Сколько всего тестовых сценариев будет в системе?
Время затраченное на проведение 1-го раунда тестирования?
Допустим, на прохождение 1-го тестового сценария мы предполагаем потратить 5 минут
Посчитайте сами и ответьте на следующие вопросы:
Сколько всего окружений получается?
Сколько всего тестовых сценариев будет в системе?
Время затраченное на проведение 1-го раунда тестирования?
Тест-дизайн
Слайд 88Считаем окружения
Окружений: 16
4 клиентские ОС * 2 языка = 8 клиентских
конфигураций * 2 серверные ОС = 16 окружений
Тестовых сценариев в системе: 150
(20 клиентских требований + 10 серверных требований) * 5 тестовых сценариев на одно требование = 150.
Сколько всего тестовых сценариев для проведения 1-го раунда тестирования?
Тестовых сценариев в системе: 150
(20 клиентских требований + 10 серверных требований) * 5 тестовых сценариев на одно требование = 150.
Сколько всего тестовых сценариев для проведения 1-го раунда тестирования?
Тест-дизайн
Слайд 89Считаем время
Расчеты
Всего тестовых сценариев: 16 окружений * 150 тестовых сценариев =
2400
Время на проведение 1-го раунда тестирования: (2400 тестовых сценарев * 5 минут) / 60 = 200 часов или 5 недель
Время на проведение 1-го раунда тестирования: (2400 тестовых сценарев * 5 минут) / 60 = 200 часов или 5 недель
Тест-дизайн
Слайд 90Давайте подумаем
Что мы не учли?
Требования относятся к функциональности (логике приложения) или
к окружению (системные функции, работа с ресурсами ОС и т.д.).
Тест-дизайн
Слайд 91Разбор тестируемых функций
Что зависит обычно от окружения на клиенте и сервере?
Вход,
выход, печать форм, получение языка ОС, получение цветовой гаммы ОС, работа с протоколами общения между серверами приложений
Что не зависит от окружения?
Получение информации из БД, запрос на сервер приложения, анализ полученных данных на клиенте и т.д.
Что не зависит от окружения?
Получение информации из БД, запрос на сервер приложения, анализ полученных данных на клиенте и т.д.
Тест-дизайн
Слайд 92Подбиваем баланс по группам требований
Получаем:
5 требований зависят от окружений на клиенте
5
требований зависят от всех окружений
5 требований зависят только от окружений сервера приложений
15 требований относятся к функциональности и не зависят от окружений
5 требований зависят только от окружений сервера приложений
15 требований относятся к функциональности и не зависят от окружений
Тест-дизайн
Слайд 93Пересчитываем
Итого:
25 тестовых сценариев * 8 = 200 тестовых сценариев зависящих от
окружения на клиенте
25 тестовых сценариев * 16 = 400 тестовых сценариев зависящих от всех конфигураций
25 тестовых сценариев * 2 = 50 тестовых сценариев зависящих от окружения на сервере приложений
75 тестовых сценариев относятся к функциональным тестам
200 + 400 + 50 + 75 = 725 тестовых сценариев
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 недели
Экономия достигается за счёт принимаемых допущений и связанных с ними рисков
Было: 200 часов или 5 недель
Стало: 60,5 часов или 1,5 недели
Экономия достигается за счёт принимаемых допущений и связанных с ними рисков
Тест-дизайн
Слайд 95Введение в тестирование программного обеспечения
Луиза Тамре
Introducing Software Testing
Издательство: Вильямс, 2003
г.
В этой книге изложены:
Последовательность вхождения в процесс тестирования с акцентом на ключевых функциях;
Определение недостающих сведений и проведение адекватного тестирования при недостаточно четких требованиях;
Изучение различных форматов документации для регистрации тестовых примеров.
В этой книге изложены:
Последовательность вхождения в процесс тестирования с акцентом на ключевых функциях;
Определение недостающих сведений и проведение адекватного тестирования при недостаточно четких требованиях;
Изучение различных форматов документации для регистрации тестовых примеров.
Рекомендуемая литература
Слайд 96Быстрое тестирование
Роберт Калбертсон, Крис Браун, Гэри Кобб
Издательство: Вильямс, 2002 г.
Технология быстрого
тестирования находит `золотую середину` между соблюдением сроков и гарантией высокого качества. Описанию этой технологии и посвящена книга.
Книга написана с учетом громадного опыта работы авторов в области тестирования ПО. Она окажет несомненную пользу всем специалистам, которые работают как в крупных, так и в небольших организациях, занимающихся созданием ПО.
Книга написана с учетом громадного опыта работы авторов в области тестирования ПО. Она окажет несомненную пользу всем специалистам, которые работают как в крупных, так и в небольших организациях, занимающихся созданием ПО.
Рекомендуемая литература
Слайд 97Рекомендуемая литература
Тест-дизайн
Тестирование dot com
Роман Савин
Издательство: Дело, 2007 г.
Этот курс лекций создан
для тех, кто хочет обучиться тестированию, понять, как вести себя в корпоративном окружении, и добиться профессионального и личностного роста. Он будет интересен и участникам процесса разработки программного обеспечения, рекрутерам, людям, связанным с интернетом или пишущим о нем, и просто всем желающим понять кухню интернет-стартапов
