Виды тестирования
Функциональные
|
Нефункциональные
|
Связанные с изменениями
|
Базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном, интеграционном, системном и приемочном. Также к функциональному тестированию относится тестирование безопасности.
|
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает.
|
Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д.
|
Уровни:
|
Виды:
|
Виды:
|
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) - очерёдность выполнения бага. Выставляется тимлидом отдела тестирования. Чем выше приоритет, тем быстрее нужно исправить дефект.
Приоритеты дефектов:
Высокий Требуется исправить в первую очередь.
Средний Требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом.
Низкий Исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.
Тест дизайн
Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).
Техники тест-дизайна
Эквивалентное разделение
|
Анализ
граничных
значений
|
Предугадывание ошибки
|
Метод эквивалентного разделения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения, а выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений в данной группе результат будет аналогичным
|
Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разделения, из-за чего часто используется с ней в паре.
|
Используя свои знания о системе, тестировщик может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.
|
Исчерпывающее тестирование
|
Матрица соответствия требованиям
|
Попарное тестирование
|
Используется крайне редких случаях. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в результате, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений
|
Матрица соответствия требованиям – это двумерная таблица, содержащая соответствие функциональных требований продукта и подготовленных тестовых сценариев. В заголовках строк таблицы расположены требования, а в заголовках колонок – тестовые сценарии или наоборот. На пересечении соответствующих строки и столбца ставится отметка, обозначающая, что данное требование покрывается данным тест-кейсом. Таким образом, таблица дает визуальное отображение двух параметров: наличие в системе требований, которые еще не покрыты (если у требования нет ни одного пересечения с тест-кейсами); есть ли в системе избыточное тестирование — если требования имеет несколько пересечений (необходимое условие).
|
Попарное тестирование – это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов. Сформулировать суть попарного тестирования можно следующим образом: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. Главные цели попарного тестирования: убрать избыточные проверки; обеспечить хорошее тестовое покрытие; выявить наибольшее количество багов на минимальном наборе тестов
|
Клиент-сервер
Клиент – это графический интерфейс приложения (например, браузер, мобильное приложение, игра, десктопное приложение, например, Microsoft Outlook). Т.к. клиент — это интерфейс, то его разрабатывает frontend программист, в соответствии с макетами, которые предоставил ему дизайнер.
Сервер – это сервер, принимающий HTTP-запросы от клиентов и выдающий им HTTP-ответы. Сервером называют как программное обеспечение, выполняющее функции веб-сервера, так и непосредственно компьютер, на котором это программное обеспечение работает.
База данных — это система, предназначенная для хранения данных на сервере. Базы данных функционируют под управлением так называемых систем управления базами данных (далее – СУБД). Самыми популярными СУБД являются MySQL, MS SQL Server, PostgreSQL, Oracle. Сервер и базы данных разрабатывает backend программист
TCP/IP: Протокол Управления Передачей и Интернет-Протокол являются коммуникационными протоколами, которые определяют, каким образом данные должны передаваться по сети. Они как транспортные средства, которые позволяют сделать заказ, пойти в магазин и купить ваши товары. В нашем примере, это как автомобиль или велосипед (или собственные ноги).
DNS: Система Доменных Имён напоминает записную книжку для веб-сайтов. Когда мы вводим URL-адрес (адрес сайта) в своём браузере, браузер обращается к DNS, чтобы найти реальный адрес веб-сайта (IP-адрес), прежде чем он сможет его получить. Браузеру необходимо выяснить, на каком сервере живёт сайт, чтобы он смог отправить запрос в нужное место.
HTTP: Протокол Передачи Гипертекста — это протокол, который определяет язык для клиентов и серверов, чтобы общаться друг с другом. Как мы поняли HTTP – это язык, с помощью которого взаимодействуют между собой клиент и сервер.
Чем отличаются HTTP от HTTPS — HTTPS не является отдельным протоколом передачи данных, а представляет собой расширение протокола HTTP с надстройкой шифрования; — Передаваемые по протоколу HTTP данные не защищены, HTTPS обеспечивает конфиденциальность информации путем ее шифрования; — HTTP использует порт 80, HTTPS — порт 443
Методы HTTP-протокола
GET
|
POST
|
PUT
|
DELETE
|
Получение данных с сервера (например, когда мы что-то ищем в google, листаем ленту в Instagram, смотрим видео на YouTube). (Работаем с имеющимися данными.)
|
Создать новые данные (например, отправляем сообщение в vk, записали историю в Instagram, добавили комментарий под видео в YouTube). (Создаём новые данные.)
|
Обновить данные или создать новые, если таких не существует (например, изменить логин в Instagram, отредактировать отправленное сообщение vk). (Изменяем имеющиеся данные.)
|
Удалить данные (например, удалить пост из Instagram, удалить сообщение vk, удалить видео с канала на YouTube). (Удаляем имеющиеся данные.)
|
Данные отправляются на сервер в URL-адресе
|
Данные отправляются на сервер в теле запроса
|
3 заголовка (основные, запроса, ответа)
|
4 заголовка (основные, запроса, ответа и тело запроса)
|
Обычно, данные передаются в формате JSON
JSON представляет собой текстовый формат данных в виде набора пар ключ: значение.
Ключ – это характеристика или свойство (например, логин, пароль, имя, фамилия, возраст, текст сообщения и т.д.) (Ключи придумывают программисты и они могут их назвать так как им вздумается.)
Значение – это то, чему эта характеристика равна (например, alex, Qwerty123, Иван, Иванов, 23, привет.)
Основные типы данных
Integer (Int). Целые числа, например, 0, -100, 256, 34900
Float / Doable. Числа с плавающей точкой, например, 0.1, -2.5, 100.25
String. Строки – любое значение, заключенное в двойные кавычки, например, "Привет" , "Apple ", "".
Boolean. Логический тип. Выбор из двух значений true или false (т.е. правда или ложи, да или нет).
null. Значение не задано или неизвестно.
Массив. Коллекция значений или просто список. (Например, список учеников в классе ["Ирина Петрова", "Григорий Мишин", "Алиса Тришина", "Михаил Гвоздев", "Мария Астапова"]).
Объект. Коллекция пар типа ключ-значение. Тот же самый JSON. (Например, {"name": "Иван", "surname": "Иванов"}).
Статус код
1ХХ - Информационные
|
(102 Processing - "В обработке". Этот код указывает, что сервер получил запрос и обрабатывает его, но обработка ещё не завершена.)
|
2ХХ – Успешные
|
(200 OK – "Успешно". Запрос успешно обработан.)
|
3ХХ – Перенаправления
|
(302 Found - "Найдено". Этот код ответа значит, что запрошенный ресурс временно изменён. Например, при переходе на vk.com пользователя 302 статус кодом переведут на страницу vk.com/feed.)
|
4ХХ - Клиентские ошибки
|
(404 Not Found – "Не найден". Сервер не может найти запрашиваемый ресурс. Код этого ответа, наверно, самый известный из-за частоты его появления в вебе.)
|
5ХХ - Серверные ошибки
|
(500 Internal Server Error - "Внутренняя ошибка сервера". Сервер столкнулся с ситуацией, которую он не знает, как обработать.)
|
Базы данных
Postgres – база данных, использовавшаяся на нашем проекте.
PgAdmin – администратор баз данных, с помощью которого делали запросы к базе.
SQL – язык запросов к базе данных.
Основные команды SQL
Select – выбрать данные из таблицы
Select where – выбрать данные из таблицы по условию
Update – обновить данные в таблице
Insert into – вставить данные в таблицу
Delete – удалить данные из таблицы
Group by – сгруппировать данные в таблице
Join – обновить таблицы
Агрегатные Функции:
Min – выбрать минимальное значение
Max – выбрать максимальное значение
Avg – выбрать среднеарифметическое значение
Count – посчитать количество
Sum – посчитать сумму
Виды объединений таблиц (джоинов):
inner join - выводит только совпадения из обоих таблиц
left join - все данные из левой таблицы и только совпадения из правой
right join - все данные из правой таблицы и только совпадения из левой
full join - выведутся все данные из обеих таблиц
Для тех записей, у которых нет совпадений ставится значение null |
Скачать 42.24 Kb.