Теория Тестирования Flashcards
(36 cards)
По позитивности:
Позитивное - это все то, что указано в документации
Негативное - ввод не корректных данных
По автоматизации:
Ручное - проводим мы
Автоматизированное - проводит автотестеровщик
По уровням:
Приемочное(end2end)- проверка всего функционала для проверки готовности к передачи заказчику
Системное - прохождение критического пути за пользователя
Интеграционное- несколько модулей тестируются вмести
Модульное - тестирование одного компонента
По функциональности:
Функциональное - Какие функции должен выполнять продукт. Ручное тестирование по требованиям, ТЗ, документации
Регресс - Проверка всего функционала после доработок, чтобы проверить не сломался ли существующий функционал. (тестировщики)
Санитарное(Sanity) - Точечное тестирование. Тщательно проверяется одна новая функция. Если тест не проходит, то он отправляется на доработку. Например авторизация или добавление в избранное(тестировщики).
Смоук -Тестирование критически важного функционала без подробных проверок, которое проводиться буквально за 5 минут и в самом начале. Проверка функционала “Оплата” на корректных данных. (разработчики и тестировщики).
Нефункциональное - Какие технические требования к качеству продукта
-Инсталляционное - Установка, Удаление, Обновление
-Верстка - верстка сайта пиксель в пиксель
-Безопасность - SQL инъекция, Пентест тестирование, анализ системы на наличие уязвимости
-Удобство UX - проверяем удобно и понятно ли приложение для пользователя
-Удобство интерфейса - (GUI/UI Testing) - проверка результата к макету
-Нагрузочное - тест стабильности, что приложение в течение 24 часов выдерживает нагрузку
-Стрессовое - нагрузка х10 на 30 секунд. Нагружаем пока бэк не слетит. Нагружаем пока скорость ответа не повыситься
-По атрибутам требования
По степени подготовки документации:
По документации
Без требований:
Исследовательское- тестирование при котором тестировщики одновременно изучают приложение, проектируют и выполняют тесты (проводит тестировщик). При таком тестирование происходит постоянно обучение. Тестовые сценарии разрабатываются в процессе. Подход эффективен для выявления сложных ошибок.
Ad-Hoc - метод тестирования без какого-либо плана(может провести кто угодно). Не требуется подготовки и выполняется в любое время. Помогает выявить ошибки, которые могли быть пропущены. Используется как дополнительный метод.
По исполнителю:
Альфа - проверка ранней версии программного продукта внутри организации.
Бета - ПО, выпускаемое для ограниченного количества пользователей для получения отзывов.
По методам:
Белый ящик - основывается на анализе внутренней структуры программы, тестирование основано на доступе к коду. QA-специалисты могут проверить каждую строку кода, что позволяет обнаружить скрытые ошибки и улучшить качество программного обеспечения.
Серый ящик -метод тестирования ПО, используя комбинацию Черного и Белого ящика. Внутренние устройство нам известно частично
Черный ящик- тестирование без знания внутренней структуры и реализации продукта.
Компонентный уровень(Модульный)
- в основном называют Юнит тестирование. Тестируют отдельные части кода. Это могут быть классы, функции и методы классов.
Юнит тесты находят ошибки на фундаментальном уровне, их легче разрабатывать и поддерживать. Преимущество модульных тестов в том, что они быстрые и при изменение кода позволяют быстро провести регресс.
Тест на компонентном уровне:
-Всегда автоматизируют.
-Модульных тестов всегда больше, чем других.
-Юнит тесты выполняются быстрее и требуют меньше ресурсов.
-Практически всегда Юнит тесты не зависят от других модулей и UI системы.
Интеграционный уровень и способы тестирования
Проверка взаимодействия между различными модулями или компонентами и интеграцию компонентов с системой. Важный этап, т.к. содержит большое количество багов. Чаще используют метод черного и серого ящика.
Три основных способа тестирования:
-Снизу вверх - Все мелкие части модуля собираются в один модуль и тестируются. Далее собираются следующие мелкие модули в один большой и тестируются с предыдущими.
-Сверху вниз - Компоненты интегрируются и тестируются от самого высокого уровня к самому низкому.
-Большой взрыв - Собираем все реализованные модули всех уровней, интегрируем в систему и тестируем. Если что-то не работает, то фиксим это.
Системный уровень
Проверка работы всей системы, максимально приближенной к реальному окружению.
Приемочное тестирование
Происходит валидация требований. Проверка требований происходит на наборе приемочных тестов. Багов быть не должно. Система практически готова к эксплуатации.
Пирамида тестирования
это концепция в разработке ПО, которая помогает структурировать процесс тестирования, оптимизировать его и сделать более эффективным.
Тест (ручной, на высоких уровнях, или автотест, на низких уровнях), должен быть на том же уровне, что и тестируемый объект. Например, модульный тест (проверяющий функции, классы, объекты и т.п.) должен быть на компонентном уровне. Это неправильно, если на приемочном уровне запускается тест, который проверяет минимальную единицу кода.
Тесты уровнем выше не проверяют логику тестов уровнем/уровнями ниже.
Чем выше тесты уровнем, тем они:
-сложней и дороже в реализации;
-важнее для бизнеса и критичней для пользователей;
-замедляют скорость прохождения тестовых наборов, например, регресса.
Почему именно такой порядок у пирамиды тестирования, и почему юнит тесты в самом низу?
-Чем выше уровень, тем меньше тестов. В юнит их больше всего.
-По сложности и стоимость исправления багов. Баг сложно исправить на приемочном уровне и не задеть другую ее часть. На модульно уровне исправление бага дешевле.
-Степень готовности продукта. Приемочное - почти готово к релизу. Модульное - начальный этап разработки и тестирования.
Почему unit тестирования в поддержке сложны
Частые изменения в коде.
Сложность модульной разработки.
Избыточное использование заглушек и моков.
Тестирование приватных методов.
Проблемы с поддержанием тестовых данных.
Трудности с пониманием и воспроизведением ошибок.
Что такое тестирование?
проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранных определённым образом.
Что такое баг?
Различие Ор от ФР
Цель тестирования
проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводят тестирование ПО?
- Для проверки соответствия требованиям.
- Для выявления проблем на более ранних этапах разработки и предотвращения увеличения стоимости продукта.
- Для выявления вариантов использования, которые не были предусмотрены при разработке. А также для оценки продукта с точки зрения пользователя.
- Для повышения лояльности к компании и продукту, поскольку любой обнаруженный дефект негативно влияет на доверие пользователей.
QA Quality Assurance(Обеспечение качества)
- изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникации в команде, где тестирование является лишь одним из аспектов обеспечения качества. QA подключается к задачам с момента появления идеи. (ВАЛИДАЦИЯ и ПРОВЕРКА)
К задачам обеспечения качества относятся:
1 - Проверка технических характеристик и требований к ПО;
Применение: у нас есть требования к фиче (новому функционалу), которые сформировал аналитик. Мы сравниваем ожидаемые (требования и тестовую документацию) результаты с фактическими. Также бывают нефункциональные требования, которые в целом понятны, но не были учтены аналитиком или разработчиком. FE: Кнопка «ОК» должна быть зеленой, а «Отмена» — красной, но в нашем продукте все наоборот.
2 - Оценка рисков;
Применение: зачастую при планировании следующего спринта (далее вы узнаете, что это такое) при оценке задач мы, как QA, поднимаем вопрос о том, в чем могут возникнуть проблемы, что может быть затронуто + оценка времени, которое потребуется на тестирование.
3 - Планирование задач для улучшения качества продукции;
Применение: инженер по контролю качества может предлагать улучшения при обсуждении новой функции, например, как можно оптимизировать или улучшить функцию, уже придуманную аналитиком.
4 - Подготовка документации, тестового окружения и данных;
5 - Тестирование;
Применение: Само тестирование ПО
6 - Составленной тестовой документации
анализ результатов тестирования, а также составление отчётов и других документов.
Применение: когда мы запускаем тест в нашей TMS (системе управления тестированием — месте, где хранится наша документация), мы формируем отчёт о том, сколько успешных кейсов было пройдено, сколько багов, сколько пропусков и сколько найдено блокировщиков.
QC Quality Control (Контроль качества)
- анализ результатов тестирования и качества новых версий выпускаемого продукта. Инженер по контролю качества, как и тестировщик, подключается к проекту, когда разработка завершена. Он проверяет, что продукт получился таким, каким его хотел видеть заказчик. (По факту только ПРОВЕРКА)
К задачам контроля качества относятся:
Проверка готовности ПО к релизу;
проверка соответствия требованиям и качества данного проекта.
Проверка ФР к ОР
Верификация (verification)
Это процесс оценки системы с целью понять, соответствуют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале. Иными словами, соответствуют ли требования, сформулированные аналитиком, текущему виду приложения.
Валидация (validation)
Это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
