Файл: Функциональные Нефункциональные Связанные с изменениями.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.01.2024
Просмотров: 39
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Виды тестирования
| Функциональные | Нефункциональные | Связанные с изменениями |
| Базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном, интеграционном, системном и приемочном. Также к функциональному тестированию относится тестирование безопасности. | Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. | Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д. |
| Уровни: | Виды: | Виды: |
| 1 Модульное тестирование Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности. | 1 Нагрузочное тестирование — это автоматизированное тестирование, имитирующее работу определенного количества пользователей на каком-либо ресурсе. | 1 Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции. |
| 2 Интеграционное тестирование Проверяем взаимодействие между компонентами внутри системы, так и со сторонними системами(другими сайтами). | 2 Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса, т.е. повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. | 2 Санитарное тестирование — это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Используется для определения работоспособности определенной части приложения после изменений, произведенных в ней или окружающей среде. Обычно выполняется вручную. |
| 3 Системное тестирование Это тестирование программного обеспечения выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям, как функциональным, так и не функциональным | 3 Тестирование стабильности или надежности – это проверка работоспособности приложения при длительном тестировании со средним уровнем нагрузки. | 3 Регрессионное тестирование — это вид тестирования, направленный на проверку изменений, сделанных в приложении, для подтверждения того факта, что существующая ранее функциональность работает, как и прежде. Таким образом, мы можем сказать, что цель регрессионного тестирования – убедиться, что исправление одних багов не стало причиной возникновения других и что внесение изменений в код не создало новых дефектов в уже проверенном коде. |
| 4 Приемочное тестирование Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью: • определения удовлетворяет ли система приемочным критериям; • вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет. | 4 Тестирование на отказ и восстановление проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети) | |
| | 5 Тестирование пользовательского интерфейса (UI - User Interface) - соответствие интерфейса приложения(сайта), которые сделал разработчик макетам, сделанным дизайнером интерфейсов | |
| | 6 Тестирование удобства пользования (UX - User Experience) - характеризует систему с точки зрения удобства использования конечного пользователя. Это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий | |
Методы тестирования
| Black-box (Чёрный ящик) | White-box (Белый ящик) | Gray-box (Серый ящик) |
| это метод тестирования ПО, при котором функциональность исследуется без рассмотрения кода, деталей реализации и знаний о внутреннем устройстве программного обеспечения Тестировщик осуществляет проверку продукта, не имея информации об особенностях его реализации, используя только интерфейс. Метод имитирует поведение пользователя, у которого нет никаких знаний о внутреннем устройстве программы. | Проверка «белого ящика» – это метод тестирования программного обеспечения, который предполагает, что внутренняя структура, устройство и реализация системы известны тестировщику. Тестировщик имеет доступ к реализованному коду, тестовой документации, изучает их и получает всю необходимую информацию, как должен работать продукт. Как правило, таким видом тестирования на проектах занимаются сами программисты. | это метод тестирования программного продукта или приложения с частичным знанием его внутреннего устройства. Для выполнения тестирования «серого ящика» нет необходимости в доступе тестировщика к исходному коду. Тесты пишутся на основе знания алгоритма, архитектуры, внутренних состояний или других высокоуровневых описаний поведения программы |
Тестовая документация
Тест план — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта тестирования, стратегии, расписания, критериев начала и окончания тестирования. (Тест-план пишет тим-лид).
Тест-план отвечает на следующие вопросы:
1.Что необходимо тестировать? - Описание объекта тестирования: системы, приложения.
2.Что будем тестировать? - Список функций и описание тестируемой системы или её компонентов в отдельности (форма регистрации, форма авторизации, чат, комментарий, лайк).
3.Как будем тестировать? - Указываем те виды тестирования, которые будем использовать при тестировании.
4.Когда будем тестировать? - Последовательность проведения работ: чтение технической документации(требований), создание тестовой документации, тестирование, анализ результатов тестирования, заведение баг-репортов.
5.Критерии начала тестирования. - Готовность тестового стенда (сайта, на котором мы тестируем), наличие всей необходимой документации, законченность разработки требуемого функционала.
6.Критерии окончания тестирования. - Весь функционал работает согласно заявленным требованиям. Чек-лист — это документ, описывающий что должно быть протестировано. Как правило, чек-лист содержит только действия (шаги) т.е. то, что будем проверять (т.е. чек-лист — это список необходимых проверок).
Чек-лист — это документ, описывающий что должно быть протестировано. Как правило, чек-лист содержит только действия (шаги) т.е. то, что будем проверять (т.е. чек-лист — это список необходимых проверок).
Тест-кейс (тестовый сценарий) — это документ, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Тест-кейс состоит из 3-х частей:
1 - Предварительные условия - что нужно сделать до проведения тестирования, например, протестировать только на устройстве Android, или только в браузере Safari. (Предварительные условия не являются обязательной частью).
2 - Шаги (Действия) – последовательность действий, которые мы должны осуществить для проверки тестируемого функционала с целью убедиться, что всё работает согласно заявленным требованиям.
3 - Ожидаемый результат - что должно получиться по результатам наших действий
☻Отличия чек-листов от тест-кейсов
Чек-лист менее детализирован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. (Например, проверить функционал лайка, кол-ва просмотров записи на стене, функционал репоста)
Виды тестовых сценариев
Тест-кейсы разделяются по ожидаемому результату на позитивные и негативные
| Позитивный тест-кейс | Негативный тест-кейс |
| Использует только корректные данные и проверяет, что приложение работает согласно заявленным требованиям. | Оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и проверяет, что вызываемая приложением функция не выполняется. (т.е. на примере формы авторизации vk.com когда мы вводим корректный логин и некорректный пароль нам выведется уведомление о том, что введены некорректные данные, т.е. осуществились проверки полей и сработал обработчик ошибок, который вывел уведомление о неправильном пароле). |
Сначала мы пишем позитивные тест-кейсы, чтобы убедиться, что функционал работает согласно заявленным требованиям, а затем создаём негативные тест-кейсы для того, чтобы убедиться в том, что, когда мы сделали что-то неправильно или ввели некорректные значения, у нас сработают обработчики ошибок и функция не выполнится.
Дефект (баг) – это несоответствие фактического результата выполнения программы ожидаемому результату
Баг Репорт — это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Основные составляющие баг-репорта
Короткое описание (Заголовок) - короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. (Пишется кратко и лаконично. Т.е. что, где поломалось. Например, в форме авторизации не работает кнопка "Войти").
Описание - в описании указываем предварительные условия, шаги, ожидаемый и фактический результаты. (Ожидаемый результат — это то, что должны были получить по требованиям, фактический — это то, что получили по итогу, т.е. то что сделал разработчик.)
Проект - название тестируемого проекта (если вы работаете в команде, у которой много проектов, то нужно указывать в каком проекте произошла ошибка, если проект одни, то он будет выбран по умолчанию).
Статус - статус бага. На какой стадии жизненного цикла бага находится дефект (смотри первый урок). Автор - создатель баг репорта.
Исполнитель - сотрудник, назначенного на решение проблемы.
Прикрепленные файлы - скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы.
Серьезность (Severity) - влияние дефекта на работоспособность (т.е. насколько дефект влияет на работу приложения). Выставляется тестировщиком.
Градация серьезности дефекта
| Тривиальная (Trivial) | Незначительная (Minor) | Значительная (Major) | Критическая (Critical) | Блокирующая (Blocker) |
| Обычно это грамматические, орфографические и пунктуационные дефекты. | Дефект, не относящийся к функциональности системы. Такая серьезность проставляется для дефектов, которые относятся к удобству использования или интерфейсу. (Текст выходит за рамки блока, слипающиеся кнопки, съехавшая иконка, картинка выезжает за пределы блока). | Дефект, указывающий на некорректную работу части функциональности. Существует более одной способа реализации функционала. Наиболее часто встречаются дефекты, которые можно отнести именно к этому уровню серьезности. (Например, на главной странице сайта есть форма для получения кредита и она не работает, но заявку на кредит можно заполнить в личном кабинете, во вкладке "Кредиты", во вкладке "Особые предложения" и т.п.) | Дефект блокирует часть функциональности, но есть альтернативный путь для его обхода. (Мы заполнили форму регистрации, нажали на кнопку "Зарегистрироваться" и ничего не происходит. Таким образом мы не можем зарегистрироваться, но есть кнопка "Зарегистрироваться через социальные сети", при нажатии на которую мы можем выбрать соцсеть, через которую можно создать профиль. Например, через Google-аккаунт, или через профиль в Instagram). | Дефект полностью блокирует выполнение функционала, нет никакого способа его обойти. (Мы открыли форму авторизации, заполнили все поля, нажали на кнопку "Войти" и ничего не происходит. На сайте есть только одна форма авторизации и мы не можем другим никаким другим способом войти в профиль.) |
Приоритет (Priority) - очерёдность выполнения бага. Выставляется тимлидом отдела тестирования. Чем выше приоритет, тем быстрее нужно исправить дефект.
Приоритеты дефектов:
Высокий Требуется исправить в первую очередь.
Средний Требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом.
Низкий Исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.
Тест дизайн
Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).
Техники тест-дизайна
| Эквивалентное разделение | Анализ граничных значений | Предугадывание ошибки |
| Метод эквивалентного разделения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения, а выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений в данной группе результат будет аналогичным | Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разделения, из-за чего часто используется с ней в паре. | Используя свои знания о системе, тестировщик может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами. |
| Исчерпывающее тестирование | Матрица соответствия требованиям | Попарное тестирование |
| Используется крайне редких случаях. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в результате, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений | Матрица соответствия требованиям – это двумерная таблица, содержащая соответствие функциональных требований продукта и подготовленных тестовых сценариев. В заголовках строк таблицы расположены требования, а в заголовках колонок – тестовые сценарии или наоборот. На пересечении соответствующих строки и столбца ставится отметка, обозначающая, что данное требование покрывается данным тест-кейсом. Таким образом, таблица дает визуальное отображение двух параметров: наличие в системе требований, которые еще не покрыты (если у требования нет ни одного пересечения с тест-кейсами); есть ли в системе избыточное тестирование — если требования имеет несколько пересечений (необходимое условие). | Попарное тестирование – это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов. Сформулировать суть попарного тестирования можно следующим образом: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. Главные цели попарного тестирования: убрать избыточные проверки; обеспечить хорошее тестовое покрытие; выявить наибольшее количество багов на минимальном наборе тестов |