Please enable JavaScript.
Coggle requires JavaScript to display documents.
Lee Copeland. Soft Testing - Coggle Diagram
Lee Copeland. Soft Testing
Набор ключевых стратегий тест-дизайна, которые позволят улучшить эффективность тестировщика
Процесс тестирования
Процесс сравнения "что" с "что должно быть"?
5 уровней видения тестирования
Нет разницы между тестированием и дебаггингом. У тестирования нет цели
Показать, что программа работает. Не создаютя очень сложные теты, которые могут найти баг
Показать, что ПО не работает
Цель не доказать что-то , а уменьшить риск неработоспособности до приемлемого значения
Не действие. Это ментальная дисциплина, результат которой - низкий риск в ПО без особых усилий по тестированию
включает ревлю, дезайн, код
Типы тестирования
Черного ящика
Тестирование основывается на требованиях и спецификации
требует знания внутренних путей и структур
Белого ящика
Тестирование основывается на внутренних путях, структурах и применений
требует склиллов программирования
Серый ящик
Заглядываем в коробочку, чтобы понять, как она устроена. Закрываем ее, чтобы тестировать черным ящиком более эффективно
Уровни тестирования
Юнит
Маленькая часть. В разных языках, юниты разные - классы, методы, программа
Интеграционные
Собираем юниты в подсистему и систему
Системные
вся система
Приемочные
клиент примет по и отдст нам свои деньги
Черный ящик
Граничные значения
Классы эквивалентности
Таблица принятия решений
Есть условие. Правило. Действие
Используется для документации сложных бизнес-требований
По таблице могут быть созданы тест-кейс
Pairwise
Тестирование всех пар
Значительно уменьшает число тестов, когда комбинаций слишком много, а время сильно ограничено
Техники
Ортогональный массив
При выборе любых колонок все значения будут иметь пары
Алгоритм всех пар
готовая программа
1-20% процентов тестов найдут 70-85 процентов багов
Диаграмма переходов состояний
Когда система должна помнить о том, что случится до или при валидных-невалидных последовательностях существующих операций
Элементы
Состояние - круг
Стрелка - переход к сотоянию
Подпись у стрелки - событие, которое привело к состоянию/доп.
Черная точка - начало
/действие - это операция, которая была инициирована когда состояние изменилось
Описывается только одна сущность!
Для чего?
Документация поведения системы
Тетстирование качества состояний, события
Не применима, когда нет состояний или не требуется ответ в реальном времени от внешней сисмтем
Хорший уровенб покрытия - все переходы
Доменнай анализ
Когда?\
Множество переменных могут или должны тестироваться вместе.
Ищем ситуации, где границы определяются некорректно
Основные понятия
Точка включения
Значение на границе. Если >= = <= , то входит в домен. Инче - нет
Точка отключения
Значение вне границы. Если >= = <=, то находится вне домена. Иначе - в домене
Точка входа
Удовлетворяет всем границам, но не входит в нее
Точка выхода - не удовлетворяет границе
Как?
Для каждых условия отношений выбрать одну точку включения и выключения (>= > <= <)
Для равенств выбрать одну точку включения и две точки выключения(немного меньше чем условие и немного больше чем условие)
Тестирование юзкейсов
Юзкейс - сценарий использования системы конкретным пользователем(иди др система) с конкретной целью. Набор юзкейсов определяет функциональные требованя к системе
Захватываем ункциональные требования с точки зрения ползователя!
Когда используется?
Когда приемочные и системные тестыявляются краеугольным камнем. И транзакци четко определены
Тестируем систему в целом
Ограничения
Кейсы создаютя на 1 позтивный сценарий и все расширения.. Но это не позволяет быть уверенным, что покрыто всё
Правильные мысли
Предугадывание требований не является приемлемой практикой
Если есть контракт - можно не проверять другие значения
Ортогональну матрицу не нужно создавать. Можно определить размер и задать значения через программу
Часто не бвает времени на создание индивидуальных кейсов для переменных. Кроме того, значения одной переменной могут блокировать другие.
Используй доменный аналих
Каждое негативное условие всегда проверяется отдельно
Сценарное тестирование: Есть детский и взрослый бильярд. То же самое с тестированием. Детское тестирование - это когда ты тетировщик говорит уже постфактум, что полученный результат бы ожидаемым. Во взрослом тестировании ожиаемый результат предполагается до тестирования
«Планировать нашу работу, работать по нашему плану, переоценивать нашу работу, переоценивать наш план».
Во многих случаях более целесообразно быстро найти работоспособное решение и улучшить его, как только позволяет время. ...
Белый ящик
Тестирование потоков управления
Что?
Определяем пути управления через модули кода
Path: A sequence of statement execution that begins at an entry and ends at an exit.
Уровни покрытия
Ур 1 - Уровень операторов(каждый оператор пройден хотя бы 1 раз)
Ур0 - пусть пользователи проверят всё остльное. Т.е. непротестированные части
Ур 2 - покрытие ветвлений/решений(каждое ветвление в условии будет протестировано хотя бы 1 раз)
Ур 3 - 100% покрытие условий
Ур4 0 100% покртие условий и решений
Ур5 - 100% покрытие нескольких условий
Ур7 - кол-во путей
Ур6 - уровень охвата. Если это цикл, то сколько раз он выполняется? 0, 1, n
Тестирование базового пути
Определить циклическую сложность С = ребра - узлы +2
Это независимые незацикленые пути
1 кейс для каждого базового пути
Когда
Модульное тестирование
Тестировщик должен обладать хорошими навыками программирования
Тестирование потоков данных
Зачем?
это мощный инструмент для обнаружения неправильного использования значений данных из-за ошибок кодирования.
Как?
Статическое тестирование потока данных
диаграмма потока управления. Паттерн define-use-kill для каждой переменной
Тестирование динамичесских потоков данных
Выбор достаточного кол-ва данных, чтобы:
Каждое определение прослеживалось до каждого из использований
Каждое использование прослеживается от соответствующего определения
Основано на потоках управления и расширяет его. Однако, требует знания программирования
тестовые парадигмы
Набор правил, которые делают 2 вещи
кстанавливают или определяют границы
он говорит вам, как вести себя внутри границ, чтобы добиться успеха
Подходы
Сценарное тестирование
Планируй свою работу. Работай свой план
Минусы
Зависит от качества сист.требований
Тетирование чисто по сценарию. Игнорируем что-то интересное
скорее, подходит чтобы разучиться тестировать
Плюсы
Формальная документация
Покрытие
Прослеживаемость
Исследовательское тестирование
Одновременное изучение программы, дизайн и исполнение кейсов
Происходит в соответствии с планом. Но не строгим
Информация, которую получает тестировщик, позволяет выполнить следующие тесты
Что самое важное я должен проверить сейчас?
Когда?
Нужно предоставить быструю ОС в короткие сроки
требовани расплывчаты или отутствуют
В начале процесса разработки, когда система может быть нестабильной
Выбор следующего сценария не может быть определен заранее
Хотим изучить масштабы дефекта, чтобы составить лучшую ОС
В дополнение к основному тестированию, когда тестировщики устают
Планирование тестирования
Классическое
По мере выполнения требований, анализа, проектирования и кодирования — задолго до создания системы и начала тестирования.
Адаптивное
Выбор стратегии(от текущих знаний)
Перед каждым скрином, фкнецией, потоком
В начале индивидуального тестирование(выбор разных стратегий)
В процессе тестирование(наблюдаем за неизвестным поведением и багами)
Ошибки планирования
Попытка прогнозировать события слишком далеко в будущее. Мы думаем, что контролируем ситуацию
Попытка спланрировать слишком подробно. Ни один план не выдержт контакта с врагом
Мы не должны строго следовать плану. Мы должны «Планировать нашу работу, работать по нашему плану, переоценивать нашу работу, переоценивать наш план».
Думать о плане как о неизменном решении проблемы
Игнорирование механизма обратной связи для выявления проблем в нашем плане