ТЕОРИЯ ТЕСТИРОВАНИЯ:
Расскажите о себе?
Почему вы решили стать тестировщиком?
(Пример: Потому что без тестирования невозможно выявить истинное состояние
производимого продукта, и насколько он соответствует ожиданиям потребителя.)
Тестирование программного обеспечения — это проверка соответствия между
реальным и ожидаемым поведением программы, а также выявление, насколько ПО
удовлетворяет потребности пользователя и требованиям заказчика. Оно осуществляется на
конечном наборе тестов, который составляет тестировщик.
Цель тестирования - проверка соответствия ПО предъявляемым требованиям,
обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном
обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи
программы.
Для чего проводится тестирование ПО?
- Для проверки соответствия требованиям.
- Для обнаружения проблем на более ранних этапах разработки и предотвращение
повышения стоимости продукта.
- Обнаружение вариантов использования, которые не были предусмотрены при
разработке. А также взгляд на продукт со стороны пользователя.
- Повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект
негативно влияет на доверие пользователей.
Этапы тестирования (Жизненный цикл тестирования - совокупность
выполнения всех этапов):
- Инициация тестирования и Анализ продукта (событие, которое извещает команду
тестирования о необходимости сессии тестирования, а также гарантирует выполнение
требований к продукту для проведения тестирования).
- Выявление и анализ требований.
- Разработка стратегии тестирования и планирование процедур контроля качества.
- Создание тестовой документации (генерация и отбор тестовых случаев).
- Тестирование прототипа (процесс оценки первого проекта любого продукта).
- Основное тестирование.
- Создание отчётов о ходе и результатах тестирования (фиксация результатов).
- Стабилизация.
- Оценка качества объекта тестирования (анализ результатов).
- Эксплуатация.
Что можно и нужно тестировать:
- код (область модульного (unit) тестирования);
- software (софт, сам продукт) и hardware (взаимодействие софта с железом);
- prototype проекта (сырой продукт (может измениться):
- документация (требования, спецификация).
Жизненным циклом программного обеспечения (SLC) является период времени,
начинающийся с момента появления концепции ПО и заканчивающийся тогда, когда
использование ПО более невозможно. Жизненный цикл программного обеспечения обычно
включает в себя следующие этапы: концепт, описание требований, дизайн, реализация,
тестирование, инсталляция и наладка, эксплуатация и поддержка и, иногда, этап вывода из
эксплуатации. Данные фазы могут накладываться друг на друга или проводиться
итерационно.
Жизненным циклом разработки программного обеспечения (SDLC) является
концепция, которая описывает комплекс мероприятий, выполняемых на каждом этапе
(фазе) разработки программного обеспечения.
3
Этапы:
- принятие решение о необходимости создания продукта;
- сбор и анализ требований к проекту;
- проектирование (дизайн (Системы и ПО) на основе требований);
- реализация (кодирование на основе дизайна системы);
- тестирование продукта;
- внедрение и поддержка (сопровождение (в том числе фиксация найденных в
пользовательской среде ошибок)).
Преимущество использования модели жизненного цикла разработки ПО
(SDLC):
- обеспечение основы проекта (методологии, активность...);
- обеспечение визуализации хода реализации проекта;
- помощь компании в эффективности и успешного завершения проекта (сокращение
затрат, уменьшение сроков разработки и тестирования, повышение качества
конечного продукта);
- уменьшение рисков, связанных с процессом разработки ПО;
- обеспечение специальным механизмом отслеживания прогресса проекта.
Принципы тестирования:
1– Тестирование показывает наличие ошибок, а не их отсутствие.
Тестирование ПО сокращает количество ошибок. Оно снижает вероятность того, что
необнаруженные ошибки останутся, но даже если ничего не было найдено, это не является
доказательством исправности. Даже многократное тестирование никогда не может
гарантировать, что программное обеспечение на 100% не содержит ошибок. Тестирование
уменьшает их количество, но не устраняет.
2– Исчерпывающее тестирование невозможно.
Невозможно протестировать все функциональные возможности со всеми
допустимыми и недопустимыми комбинациями данных во время фактического
тестирования. Вместо этого подхода рассматривается тестирование нескольких
приоритетных комбинаций с использованием различных методов.
Например, если у вас есть поле ввода, которое принимает буквы (имя), представьте,
сколько имен будет проверяться – невозможно проверить все комбинации для каждого типа
ввода.
3– Раннее тестирование.
Чтобы обнаружить ошибку в программном обеспечении, необходимо начать раннее
тестирование. Ошибка, выявленная на ранних этапах жизненного цикла разработки ПО,
обойдется гораздо дешевле. Для повышения качества программного обеспечения
тестирование должно быть запущено на начальном этапе, т.е. выполняться на этапе анализа
требований. Затраты, необходимые для устранения ошибки, обнаруженной в этот момент,
меньше, и они продолжают расти по мере перехода к этапу тестирования или технического
обслуживания.
4– Кластеризация дефектов.
Кластеризация дефектов означает, что небольшое количество модулей содержит в
себе большинство обнаруженных ошибок. Это закон Парето, примененный к тестированию
программного обеспечения: примерно 80% проблем, обнаруживаются в 20% модулей.
5– Тестирование зависит от контекста.
Подход к тестированию зависит от контекста разрабатываемого программного
обеспечения. Различные типы тестирования должны выполняться для различных типов ПО.
Например, тестирование сайта отличается от тестирования приложения для Android.
6– Парадокс пестицида.
Многократное повторение одних и тех же тестовых кейсов с одними и теми же
тестовыми данными не приведет к обнаружению новых ошибок. Поэтому необходимо
4
проанализировать тестовые кейсы и обновить их или добавить другие, чтобы найти новые
ошибки.
7- Заблуждение в отсутствии ошибок.
Если версия встроенного программного обеспечения на 99% рабочая, но не
соответствует пользовательским запросам, то она непригодна для использования.
Необходимо не только, чтобы программное обеспечение на 99% не содержало ошибок, оно
также обязательно должно выполнять все требования пользователя. В таких случаях даже
своевременные обнаружение и устранение ошибок не помогут, поскольку тестирование
будет выполняться на основе неправильных требований, несоответствующих потребностям
конечного пользователя.
QC (Quality Control) — Контроль качества продукта — это совокупность
действий, проводимых над продуктом в процессе разработки, для получения информации
о его актуальном состоянии в разрезах: (задачи контроля качества) «готовность продукта
к выпуску», «соответствие зафиксированным требованиям», «соответствие заявленному
уровню качества продукта».
QA (Quality Assurance) — Обеспечение качества продукта — это совокупность
мероприятий, охватывающих все технологические этапы разработки, выпуска и
эксплуатации
программного
обеспечения
(ПО)
информационных
систем,
предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого
уровня качества выпускаемого продукта, где тестирование является только одним из
аспектов обеспечения качества.
К задачам обеспечения качества относятся:
- проверка технических характеристик и требований к ПО;
- оценка рисков;
- планирование задач для улучшения качества продукции;
- подготовка документации, тестового окружения и данных;
- тестирование;
- анализ результатов тестирования, а также составление отчетов и других
документов.
Обеспечение качества определено в стандарте ISO 9000:2005 «Системы
менеджмента качества. Основные положения и словарь» как «часть менеджмента качества,
направленная на создание уверенности в том, что требования к качеству будут выполнены».
Верификация (verification) — это процесс оценки системы, чтобы понять,
удовлетворяют ли результаты текущего этапа разработки условиям и требованиям, которые
были сформулированы в его начале.
Валидация (validation) - это определение итогового результата, соответствия,
разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к
системе.
Существует шесть базовых типов задач:
Эпик (epic) — большая задача, на решение которой команде нужно несколько
спринтов.
Требование (requirement) — задача, содержащая в себе описание реализации той или
иной фичи.
История (story) — часть большой задачи (эпика), которую команда может решить за
1 спринт.
Задача (task) — техническая задача, которую делает один из членов команды.
Подзадача (sub-task) — часть истории / задачи, которая описывает минимальный
объем работы члена команды.
Баг (bug) — задача, которая описывает ошибку в системе.
5
Тестовые среды:
Среда разработки (Development Env) – за данную среду отвечают разработчики, в
ней они пишут код, проводят отладку, исправляют ошибки
Среда тестирования (Test Env) – среда, в которой работают тестировщики
(проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
Интеграционная среда (Integration Env) – среда, в которой проводят тестирование
взаимодействующих друг с другом модулей, систем, продуктов.
Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену.
Здесь проводится заключительное тестирование функционала.
Продакшн среда (Production Env) – среда, в которой работают пользователи.
Основные фазы тестирования:
Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка
неполный функционал. Необходим для ознакомления с будущими возможностями
программ.
Alpha: является ранней версией программного продукта, тестирование которой
проводится внутри фирмы-разработчика.
Beta: практически готовый продукт, который разработан в первую очередь для
тестирования конечными пользователями.
Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и
разработчики выпускают версию на которой проводится регрессионное тестирование.
Release: финальная версия программы, которая готова к использованию.
ТРЕБОВАНИЯ — это спецификация (описание) того, что должно быть
реализовано. Требования описывают то, что необходимо реализовать, без детализации
технической стороны решения.
Источники требований:
- заказчик;
- мозговой штурм;
- документы;
- фокус группа;
- наблюдение;
- моделирование;
- анкетирование;
- прототип;
- описание;
- нормы;
- лучшие практики;
- конкуренты.
Виды требований:
1) Прямые (формализованные в технической документации, спецификации, юзерстори и прочих артефактах) и Косвенные (проистекающие из прямых, либо являющимися
негласным стандартом для данной продукции или основывающихся на опыте и здравом
смысле использования продукта); (пример про ссылку)
2) Функциональные (Уровни требований: бизнес-требования, требования
пользователей, функциональные требования) и Нефункциональные (описание
производительности, интерфейсы работы (платформа, протоколы)).
Атрибуты требований:
Корректность — точное описание разрабатываемого функционала.
Проверяемость — формулировка требований таким образом, чтобы можно было
выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Полнота — в требовании должна содержаться вся необходимая для реализации
функциональности информация.
Недвусмысленность — требование должно содержать однозначные формулировки.
6
Непротиворечивость — требование не должно содержать внутренних
противоречий и противоречий другим требованиям и документам.
Приоритетность — у каждого требования должен быть приоритет
(количественная оценка степени значимости требования). Этот атрибут позволит грамотно
управлять ресурсами на проекте.
Атомарность — требование нельзя разбить на отдельные части без потери деталей.
Модифицируемость — в каждое требование можно внести изменение.
Прослеживаемость — каждое требование должно иметь уникальный
идентификатор, по которому на него можно сослаться.
МОДЕЛИ РАЗРАБОТКИ:
1. Каскадная (водопадная (Waterfall)) базовым принципом является
последовательный порядок выполнения задач. Это значит, что мы можем переходить к
следующему шагу разработки или тестирования только после того, как предыдущий был
успешно завершен. (Анализ требований, проектирование, разработка, тестирование,
техническая поддержка).
2. V-Model (Модель верификации и валидации) основана на прямой
последовательности шагов, тестирование в данном случае планируется параллельно с
соответствующей стадией разработки. Согласно этой методологии тестирования ПО,
процесс начинается, как только определены требования и становится возможным начать
статическое тестирование, т.е. верификацию и обзор, что позволяет избежать возможных
дефектов ПО на поздних стадиях. Соответствующий план тестирования создается для
каждого уровня разработки ПО, что определяет ожидаемые результаты, а также критерии
входа и выхода для данного продукта.
Основные этапы этой методологии могут изменяться, однако обычно они
включают следующие:
Этап определения требований. Приемочное тестирование относится к этому этапу.
Его основная задача состоит в оценке готовности системы к финальному использованию.
Этап, на котором происходит высокоуровневое проектирование, или High-Level
Design (HDL). Этот этап относится к системному тестированию и включает оценку
соблюдения требований к интегрированным системам.
Фаза детального дизайна (Detailed Design) параллельна фазе интеграционного
тестирования, во время которой происходит проверка взаимодействий между различными
компонентами системы.
После этапа написания кода начинается другой важный шаг — юнит-тестирование.
Очень важно убедиться в том, что поведение отдельных частей и компонентов ПО
корректно и соответствует требованиям.
3. Инкрементная модель:
Данная методология может быть описана, как мультикаскадная модель тестирования
ПО. Рабочий процесс разделяется на некоторое количество циклов, каждый из которых
также делится на модули. Каждая итерация добавляет определенный функционал к ПО.
Инкремент состоит из трех циклов:
- дизайн и разработка;
- тестирование;
- реализация.
В этой модели возможна одновременная разработка разных версий продукта.
Например, первая версия может проходить этап тестирования в то время, как вторая версия
находится на стадии разработки. Третья версия в то же самое время может проходить этап
дизайна. Этот процесс может продолжаться до самого завершения проекта.
7
4. Спиральная модель:
Спиральная модель — это методология тестирования ПО, которая основана на
инкрементном подходе и прототипировании. Она состоит из четырех этапов:
- Планирование;
- Анализ рисков;
- Разработкам
- Оценка;
Сразу после того, как первый цикл завершен, начинается второй. Тестирование ПО
начинается еще на этапе планирования и длится до стадии оценки. Основным
преимуществом спиральное модели является то, что первые результаты тестирования
появляется незамедлительно после появления результатов тестов на третьем этапе каждого
цикла, что помогает гарантировать корректную оценку качества. Тем не менее, важно
помнить о том, что эта модель может быть довольно затратной и не подходит для маленьких
проектов.
5. Agile (SCRUM, CANBAN):
Методология гибкой (Agile) разработки и тестирование ПО может быть описана как
набор подходов, ориентированных на использование интерактивной разработки,
динамического формирования требований и обеспечения их осуществления как результата
постоянного взаимодействия внутри самоорганизующейся рабочей группы. Большинство
гибких методологий разработки ПО нацелены на минимизацию рисков посредством
разработки в рамках коротких итераций. Одним из главных принципов этой гибкой
стратегии является возможность быстрого реагирования на возможные изменения, нежели
стремление положиться на долгосрочное планирование.
«SCRUM» - это процессный фреймворк, предназначенный для быстрой
разработки и поставки сложных продуктов клиентам с максимально
возможной ценностью
процесс разработки разбивается на отдельные этапы, результатом каждого из
которых является готовый продукт. В конце каждого этапа (в терминологии Scrum —
спринта) готовый продукт предоставляется заказчику. Полученный от заказчика отзыв
позволяет выявить возможные проблемы или пересмотреть некоторые аспекты
первоначального плана.
Прежде чем приступить к описанию жизненного цикла Scrum-проекта, стоит
рассказать об основных ролях, принятых в Scrum-методологии:
Владелец продукта (Product owner) представляет интересы конечного пользователя.
Скрам-мастер (Scrum master) следит за соблюдением принципов Scrum-разработки,
координирует процесс, проводит ежедневные собрания (Scrum Meetings).
Скрам-команда (Scrum team) участвует в разработке продукта. В скрам-команду
входят программисты, тестировщики, аналитики и прочие специалисты. (5-9 чел.)
Стейкхолдеры (бизнес-заказчик) и пользователи.
Шаг 1. Создание бэклога продукта
Бэклог продукта (Product backlog) представляет собой упорядоченный по степени
важности список требований, предъявляемых к разрабатываемому продукту. Элементы
этого списка называются Пользовательскими историями (User story (описание
функциональной возможности ПО простыми словами, составленное с точки зрения
пользователя)). Каждой истории соответствует уникальный ID.
Описание каждой истории должно включать в себя набор обязательных полей,
необходимых для дальнейшей работы над проектом:
Важность (Importance). Степень важности задачи, по мнению владельца продукта.
Описывается произвольным числом.
Предварительная оценка (Initial estimate). Предварительная оценка объема работ.
Измеряется в story point’ах.
Как продемонстрировать (How to demo). Описание способа демонстрации
завершенной задачи.
8
Шаг 2. Планирование спринта и создание Бэклога спринта
На этапе планирования определяется длительность спринта. Короткий спринт
позволяет чаще выпускать работающие версии продукта, а, следовательно, чаще получать
отзывы от клиента и вовремя выявлять возможные ошибки. С другой стороны, длинные
спринты позволяют посвятить решению проблемы больше времени. Оптимальная длина
спринта выбирается как нечто среднее между этими двумя решениями и составляет обычно
около 2-ух недель. На этом этапе важно взаимодействие владельца продукта и скрамкоманды. Владелец продукта определяет приоритет той или иной задачи, а задача скрамкоманды состоит в определении необходимых трудозатрат.
Во время планирования спринта команда выбирает самые приоритетные
пользовательские истории из бэклога продукта и решает, каким образом будут решаться
поставленные задачи. Истории, выбранные для реализации в течение данного спринта,
составляют Бэклог спринта (Sprint backlog). Количество историй, попадающих в бэклог
спринта зависит от их длительности в story point’ах, присвоенных каждой истории на этапе
предварительной оценки. Это количество выбирается так, чтобы каждая история была
успешно реализована к концу спринта.
Шаг 3. Работа над спринтом. Scrum meetings
После того, как определены актуальные для данного спринта пользовательские
истории, начинается процесс разработки.
Для визуализации процесса разработки удобно использовать учетные карточки. Они
могут иметь вид больших карточек с названием конкретной истории и маленьких стикеров,
описывающих отдельные задачи, необходимые для реализации истории. После начала
работы над определенной задачей, ее стикер перемещается из поля «Запланировано» в
область «В работе». По завершении работы над задачей, стикер перемещается в поле
«Тестирование» и затем, при успешном выполнении тестирования, в поле «Готово».
Расположив истории согласно их важности, можно получить представление о текущем
состоянии проекта:
Также может быть использовано программное обеспечение, предназначенное для
такого рода задач. Примером такого ПО может служить, например, Atlassian JIRA.
Важной отличительной особенностью Scrum являются ежедневные совещания
(Scrum meetings), целью которых является дать команде полную и достоверную
информацию о том, на каком этапе находится процесс разработки. Во время совещания
каждый участник скрам-команды сообщает о том, какая задача им выполнена, какая будет
выполняться и какие у него возникли трудности во время работы.
Шаг 4. Тестирование и демонстрация продукта
Поскольку в идеале результатом каждого спринта является продукт, готовый к
работе, важное место в Scrum занимает процесс тестирования. Существуют разные способы
свести к минимуму затраты на данном этапе: от уменьшения количества историй в спринте
и, как результат, снижения количества ошибок до включения тестировщиков в скрамкоманду.
Финал каждого спринта — демонстрация готового продукта. Скрам-команда
составляет ревью, в котором описывает цели спринта, поставленные задачи и то, как они
были решены. Владелец продукта, заказчики и пользователи на основе ревью и
демонстрации принимают решение о том, что должно быть изменено в дальнейшем
процессе разработки.
Шаг 5. Ретроспектива. Планирование следующего спринта
На основе отзыва о продукте, полученного после демонстрации, проводится
ретроспектива. Ее основная цель — определить, как можно улучшить процесс разработки
на следующем спринте, чтобы избежать возникших проблем и работать более эффективно.
После того, как пути улучшения качества работы были определены, команда может
приступать к планированию следующего спринта.
«KANBAN» стал символом визуализации рабочего процесса (карточки на стенде) и
сейчас обозначает стратегию оптимизации потока поставки ценности посредством
9
процесса, использующую систему вытягивания и имеющую ограничение незавершённой
работы. Этот метод, демонстрирующий, что происходит в процессе работы, увеличивает
предсказуемость процедур, благодаря чему рабочий процесс становится прозрачным и
равномерным. Kanban также можно использовать, чтобы достичь большей согласованности
действий, а это означает более быстрое достижение стратегических целей.
ВИДЫ ТЕСТИРОВАНИЯ:
Вид тестирования — это совокупность активностей, направленных на
тестирование заданных характеристик системы или её части, основанная на конкретных
целях.
1) Классификация по запуску кода на исполнение:
Статическое тестирование — процесс тестирования (без запуска кода), который
проводится для верификации практически любого артефакта разработки: программного кода,
требований, системных спецификаций, функциональных спецификаций, документов
проектирования, архитектуры программных систем и их компонентов. (Предотвращение деф.)
Динамическое тестирование — тестирование проводится на работающей системе, не
может быть осуществлено без запуска программного кода приложения. (Поиск и испр. деф.)
10
2) Классификация по доступу к коду и архитектуре (Методы тестирования (на
сколько глубоко можно погрузиться в техническую составляющую продукта, к потоку
хранения информации и ее передачи, к кодовой базе)):
Тестирование белого ящика — метод тестирования ПО, который предполагает
полный доступ к коду (внутренняя структура/устройство/реализация системы) проекта.
Согласно ISTQB, тестирование белого ящика — это:
тестирование, основанное на анализе внутренней структуры компонента или
системы;
тест-дизайн, основанный на технике белого ящика — процедура написания или
выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Тестирование серого ящика — метод тестирования ПО, который предполагает
комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы
нам известно лишь частично (DevTools, база данных, API, техническая документация,
логи).
Тестирование чёрного ящика — метод тестирования ПО, который не предполагает
доступа (полного или частичного) к системе. Основывается на работе исключительно с
внешним интерфейсом тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
тестирование, как функциональное, так и нефункциональное, не предполагающее
знания внутреннего устройства компонента или системы;
тест-дизайн, основанный на технике черного ящика — процедура написания или
выбора тест-кейсов на основе анализа функциональной или нефункциональной
спецификации компонента или системы без знания ее внутреннего устройства.
3) Классификация по уровню детализации приложения:
Модульное тестирование (Unit test) — проводится для тестирования какого-либо
одного логически выделенного и изолированного элемента (модуля) системы в коде.
Проводится самими разработчиками, так как предполагает полный доступ к коду.
Интеграционное тестирование — тестирование, направленное на проверку
корректности взаимодействия нескольких модулей, объединенных в единое целое.
Системное тестирование — процесс тестирования системы, на котором проводится
не только функциональное тестирование, но и оценка характеристик качества системы —
ее устойчивости, надежности, безопасности и производительности. (Набор end-to-end tests).
Приёмочное тестирование — проверяет соответствие системы потребностям,
требованиям и бизнес-процессам пользователя.
4) Классификация по степени автоматизации:
Ручное тестирование.
Автоматизированное тестирование.
5) Классификация по принципам работы с приложением:
Позитивное тестирование — тестирование, при котором используются только
корректные (валидные) данные.
Негативное тестирование — тестирование приложения, при котором используются
некорректные (не валидные) данные и выполняются некорректные операции.
6) Классификация по уровню функционального тестирования:
Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке,
с целью подтверждения того, что программное обеспечение стартует и выполняет основные
для бизнеса функции. (Связанные с изменениями:
Санитарное тестирование (Sanity testing) - проверка того, что определённые части
приложения так же работают как положено после минорных изменений или исправлений багов.
Регрессионное тестирование (regression testing) — тестирование уже проверенной
ранее функциональности после внесения изменений в код приложения, для уверенности в том,
что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
11
Повторное/подтверждающее тестирование (re-testing/confirmation testing) —
тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время
последнего запуска, для подтверждения успешности исправления этих ошибок).
Тестирование критического пути (critical path) — направлено для проверки
функциональности, используемой обычными пользователями во время их повседневной
деятельности.
Расширенное тестирование (extended) — направлено на исследование всей
заявленной в требованиях функциональности.
7) Классификация в зависимости от исполнителей:
Альфа-тестирование — является ранней версией программного продукта. Может
выполняться внутри организации-разработчика с возможным частичным привлечением
конечных пользователей.
Бета-тестирование — программное обеспечение, выпускаемое для ограниченного
количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести
соответствующие изменения.
8) Классификация в зависимости от целей тестирования:
Функциональное тестирование (functional testing) — направлено на проверку
корректности работы функциональности приложения. (Подразумевает что нужно
проверить все функции программы и сравнить фактический результат с ожидаемым).
Этапы функционального тестирования:
- требования (спецификации, user-story, примеры конкурентов и др.);
- входные данные (позитивные и негативные сценарии);
- выходные данные (ожидаемый результат);
- прохождение сценариев (получение фактического результата);
- сравнение результатов.
Нефункциональное тестирование (non-functional testing) — тестирование атрибутов
компонента или системы, не относящихся к функциональности.
Тестирование производительности (performance testing) — определение
стабильности и потребления ресурсов в условиях различных сценариев
использования и нагрузок.
Нагрузочное тестирование (load testing) — определение или сбор
показателей производительности и времени отклика программно-технической
системы или устройства в ответ на внешний запрос с целью установления
соответствия требованиям, предъявляемым к данной системе (устройству). (JMetter).
Тестирование масштабируемости (scalability testing) — тестирование,
которое измеряет производительность сети или системы, когда количество
пользовательских запросов увеличивается или уменьшается.
Объёмное тестирование (volume testing) — проводится для тестирования
программного приложения с определенным объемом данных.
Стрессовое тестирование (stress testing) — проверка, как система
обращается с нарастающей нагрузкой (количеством одновременных пользователей).
Тестирование на отказ и восстановление (помехоустойчивость) – проверка
способности противостоять и успешно восстанавливаться после сбоев, в связи с
ошибками ПО, отказами оборудования или проблемами связи/сети.
Инсталляционное тестирование (installation testing) — тестирование,
направленное на проверку успешной установки и настройки, обновления или
удаления приложения.
Тестирование интерфейса (GUI/UI testing) — проверка требований к
пользовательскому интерфейсу.
Тестирование удобства использования (usability testing/user experience UX) —
это метод тестирования, направленный на установление степени удобства
использования,
понятности
и
привлекательности
для
пользователей
разрабатываемого продукта в контексте заданных условий.
12
Конфигурационное тестирование — это проверка работы программного
обеспечения на различных программных и аппаратных окружениях. Данный вид
тестирования применяется, если известно, что информационный продукт будет
использоваться с разной конфигурацией, на разных платформах, в различных
браузерах, будет поддерживать разные версии драйверов.
Тестирование совместимости - предназначено для определения того, может
ли программное обеспечение или продукт работать в различных браузерах, базах
данных, оборудовании, операционной системе, мобильных устройствах и сетях.
Тестирование локализации (localization testing) — проверка адаптации
программного обеспечения для определенной аудитории в соответствии с ее
культурными особенностями. (Интернациализации – как расположен текст в окне).
Тестирование безопасности (security testing) — это стратегия тестирования,
используемая для проверки безопасности системы, а также для анализа рисков,
связанных с обеспечением целостного подхода к защите приложения, атак хакеров,
вирусов, несанкционированного доступа к конфиденциальным данным.
Тестирование надёжности (reliability testing) - проверка работоспособности
приложения при длительном тестировании с ожидаемым уровнем нагрузки.
Тестирование документации (Documentation testing) - минимизации рисков
несоответствия фактически реализованной функциональности и прохождения
приемочных испытаний.
АРТЕФАКТЫ ТЕСТИРОВАНИЯ:
Внешняя документация:
- замечание (короткая записка, комментарий о небольшой неточности в реализации
продукта);
- баг-репорт;
- запрос на изменение (улучшение) (описание неявных/некритичных косвенных
требований, которые не были учтены при планировании/реализации продукта, но
несоблюдение, которых может вызвать неприятие у конечного потребителя. И
пути/рекомендации по модификации продукта для соответствия им.)
- отчет о тестировании (тест репорт) (документ, предоставляющий сведения о
соответствии/несоответствии продукта требованиям).
Внутренняя документация:
- тест-план;
- тестовый сценарий (последовательность действий над продуктом, которые
связаны единым ограниченным бизнес-процессом использования, и сообразным им
проверок корректности поведения продукта в ходе этих действий);
- чек-лист
- тест-кейс;
- тест-сьют.
Проектная документация — включает в себя всё, что относится к проекту в целом.
Продуктовая документация — часть проектной документации, выделяемая
отдельно, которая относится непосредственно к разрабатываемому приложению или
системе.
Тест план (Test Plan) — это документ, который описывает весь объем работ по
тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и
окончания тестирования, до необходимого в процессе работы оборудования, специальных
знаний, а также оценки рисков. (Является артефактом тестирования)
Тест-планы бывают:
1) Приемо-сдаточный план (набор смоук-тестов);
2) Сам тест-план (динамичный (или версии плана), почти готовый отчет):
13
- что надо тестировать;
- что будем тестировать;
- как будем тестировать;
- когда будем тестировать;
- критерии начала тестирования;
- критерии сдачи и приемки.
Основные пункты тест плана: (в идеале)
Идентификатор тест плана (Test plan identifier);
Введение (Introduction);
Объект тестирования (Test items);
Функции, которые будут протестированы (Features to be tested;)
Функции, которые не будут протестированы (Features not to be tested);
Тестовые подходы (Approach);
Критерии прохождения тестирования (Item pass/fail criteria);
Критерии приостановления и возобновления тестирования (Suspension criteria
and resumption requirements);
Результаты тестирования (Test deliverables);
Задачи тестирования (Testing tasks);
Ресурсы системы (Environmental needs);
Обязанности (Responsibilities);
Роли и ответственность (Staffing and training needs);
Расписание (Schedule);
Оценка рисков (Risks and contingencies);
Согласования (Approvals).
Пункты плана: (в жизни)
- Перечень работ;
- Критерии качества и оценки (ошибки на релизе и др.);
- Оценки рисков (области в которых не квалифицированы, время, деньги на закупку
устройств, замена тестировщика и др.);
- Документация (тест-кейсы или чек-листы, шаблоны тестовых атрибутов, как часто
тест-кейсы должны пересматриваться, будет ли ревью кейсов внутри команды, сроки
приемки тест-кейсов);
- Тестовая стратегия (методы, уровни, виды тестирования, виды для конкретного
модуля, объем регрессионного тестирования, метрики по передаче тест-кейсов в регресс,
сроки принятия исправленных дефектов);
- Ресурсы (человеческие (сколько и кого), аппаратные (ноуты, телефоны),
программные (лицензии программ, платные интерфейсы и софт));
- Расписание (даты, контрольные точки).
3) Мастер план (требования к заводимым дефектам, условия принятия сборки,
критерии принятия продукта к релизу, инструменты).
Чек-лист (Check list) — список проверок (идея проверки), без указания шагов и
ожидаемого результата. (Группируются по смыслу, модулям) (Для небольших проектов)
Атрибуты чек-листа (не исчерпывающий перечень, гибкость составления):
- Номер;
- Описание (название, идея) проверки;
- Статус (результат);
- Комментарий.
Плюсы: гибкость, простота создания и поддержки, простота визуализации,
расширение тестового покрытия, каждый выполняет по-своему.
Минусы: каждый выполняет по-своему, неопределенность тестовых данных,
неэффективен для джунов, высокая вероятность разночтения.
Основные программы: Excel, Trello, Jira + плагины.
14
Тестовый сценарий (Test-case) — это артефакт, описывающий совокупность шагов,
конкретных условий (пред- и пост-), параметров (входных значений) и ожидаемых
результатов, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест-кейса:
- Номер кейса;
- Заголовок (название);
Предусловия (PreConditions) — список действий или условий, выполнение
которых говорит о том, что система находится в пригодном для проведения основного теста
состояния.
Шаги (Steps) — список действий, переводящих систему из одного состояния
в другое, для получения результата, на основании которого можно сделать вывод о
удовлетворении реализации, поставленным требованиям.
Ожидаемый результат (Expected result) — что по факту должны получить.
Окружение;
Тестовые данные;
Статус;
Фактический результат;
Постусловия;
Модуль;
Приоритет;
Уровень (модульное, интеграционное, системное, приемочное);
Вид тестирования;
Связанное требование;
Комментарии.
Правила написания тест-кейса:
1) независимость (тест-кейсов друг от друга);
2) однозначность (введите логин (чем?) латиницей);
3) полнота (никто не должен что-то где-то додумывать или спрашивать);
4) обезличенность (нажать на кнопку);
5) упрощай (НЕ НАДО - нажмите на красную кнопку с надписью: «Войти» в верхнем
правом углу экрана, под меню; НАДО – нажать на кнопку «Войти»);
6) 1 тест-кейс = 1 проверка, цель (отдельно авторизация и покупка товара).
Классификация тест-кейсов: высокоуровневые (описывают поведение как в чеклисте, больше идея для проверки, чем подробное описание (нехватка времени)
(больше для API)) и низкоуровневые (подробные).
Статусы проверки:
- Passed (пройден, успешен);
- Failed (сломался);
- Skipped (пропущен (нет необходимости, убрали функционал));
- No run (не запускался (по умолчанию));
- Blocked (заблокирован (каким-то найденным багом в предыдущем тесте)).
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом
недостатке в компоненте или системе, который потенциально может привести компонент
или систему к невозможности выполнить требуемую функцию. (Описывает ситуацию или
последовательность действий, приведшую к некорректной работе объекта тестирования, с
указанием причин и ожидаемого результата). (Баг-трекеры: Jira, Redmine, Mantis, «Excel»).
Ошибка (Error) – несоответствие производимого продукта предъявляемым к нему
прямым и косвенным требованиям. (Ошибка пользователя, то есть он пытается
использовать программу иным способом (например, вводит буквы в поля, где требуется
вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются
сообщение об ошибке (error message)). (Это ошибка программиста (или дизайнера или ещё
15
кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так,
как планировалось. Например, внутри программа построена так, что изначально не
соответствует тому, что от неё ожидается).
Дефект, баг (defect, bug) — отклонение фактического результата от ожидаемого.
(Недостаток в рабочем продукте, если он не соответствует его требованиям).
Failure (неудача) — это сбой в работе компонента, всей программы или системы
(может быть, как аппаратным, так и вызванным дефектом).
Локализация дефекта:
– Выявление причины возникновения дефекта. (Например, не проходит
восстановление пароля. Необходимо выявить, откуда приходит запрос на сервер в неверном
формате – от backend или frontend).
- Исследовать окружение. (Необходимо воспроизвести баг в разных операционных
системах (IOS, Android, Windows и т.д.) и браузерах (Google Chrome, Mozilla, Internet
Explorer и др.). При этом нужно проверить требования к продукту, чтобы выяснить, какие
системы должны поддерживаться.)
- Проверить на разных устройствах.
- Проверить на разных версиях ПО (версионность продукта).
- Проанализировать возможность влияния найденного дефекта на другие области.
Атрибуты отчета о дефекте:
1.
Уникальный идентификатор (ID) — присваивается автоматически системой
при создании баг-репорта.
2.
Тема (краткое описание, Summary) — кратко сформулированный смысл
дефекта, отвечающий на вопросы: Что? Где? Когда (при каких условиях)?
3.
Подробное описание (Description) — более широкое описание дефекта
(указывается опционально).
4.
Шаги для воспроизведения (Steps To Reproduce) — описание четкой
последовательности действий, которая привела к выявлению дефекта. В шагах
воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых
значений, если они играют роль в воспроизведении дефекта.
5.
Фактический результат (Actual result) — описывается поведение системы на
момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного
поведения (может совпадать с темой отчета о дефекте).
6.
Ожидаемый результат (Expected result) — описание того, как именно должна
работать система в соответствии с документацией.
7.
Окружение (Environment) – окружение, на котором воспроизвелся баг.
8.
Критичность (серьёзность) дефекта (важность, Severity) — характеризует
влияние дефекта на работоспособность приложения.
9.
Приоритет дефекта (срочность, Priority) — указывает на очерёдность
выполнения задачи или устранения дефекта.
10.
Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов
могут быть разными в разных баг-трекинговых системах.
11.
Вложения (Attachments) — скриншоты, видео или лог-файлы.
12.
Возможность обойти баг, воспроизводимость,комментарии (не обязательные
атрибуты).
Шаги воспроизведения:
- описывайте каждое действие в отдельном шаге;
- описывайте безличные формулировки, призывающие к действию;
- описывайте каждый шаг, пока не столкнетесь с дефектом;
- найдите кратчайший путь воспроизведения;
- найдите точный путь воспроизведения;
- пишите так, чтобы любой новичок мог его воспроизвести.
Релиз багов – это преднамеренное действие, а утечка багов - случайное. Релиз
багов подразумевает, что при отправке приложения команде тестировщиков разработчики
16
знали, что оно содержит ошибки. Но они могут быть не критичными, поэтому можно
проводить релиз. Утечка багов подразумевает, что группа тестировщиков не выявила
ошибку, и конечный пользователь или заказчик получает приложение с ошибкой.
(Выяснить причину, провести анализ пропуска дефекта, внедрить корректирующие
мероприятия, чтобы этого больше не происходило (Обсудить ситуацию с командой
разработки, установить новые правила в команде, которые позволят повлиять на эту
ситуацию).).
Жизненный цикл бага:
Severity vs Priority:
Критичность (серьёзность) (severity) показывает степень ущерба, который
наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Критичности (серьезности) дефекта (Severity):
Блокирующий (S1 – Blocker) тестирование значительной части
функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в
нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или
ее ключевыми функциями становится невозможна.
Критический (S2 – Critical) критическая ошибка, неправильно работающая
ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному
падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть
не работает важная часть одной какой-либо функции либо не работает значительная часть,
но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить
тестирование.
Значительный (S3 – Major) не работает важная часть одной какой-либо
функции/бизнес-логики, но при выполнении специфических условий, либо есть
workaround, позволяющий продолжить ее тестирование либо не работает не очень
значительная часть какой-либо функции. Также относится к дефектам с высокими visibility
– обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако,
сразу бросаются в глаза.
Незначительный (S4 – Minor) часто ошибки GUI, которые не влияют на
функциональность, но портят юзабилити или внешний вид. Также незначительные
функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
17
Тривиальный (S5 – Trivial) почти всегда дефекты на GUI — опечатки в
тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не
касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не
оказывающая никакого влияния на общее качество продукта.
Приоритет (срочность) (priority) показывает, как быстро дефект должен быть
устранён. Priority выставляется менеджером, тимлидом или заказчиком.
Градация Приоритета (срочности) дефекта (Priority):
P1 Высокий (High) Критическая для проекта ошибка. Должна быть
исправлена как можно быстрее.
P2 Средний (Medium (Normal)) Не критичная для проекта ошибка, однако
требует обязательного решения.
P3 Низкий (Low) Наличие данной ошибки не является критичным и не
требует срочного решения. Может быть исправлена, когда у команды появится время на ее
устранение.
Высокий приоритет и низкая серьезность:
Такое сочетание бывает, когда баг на функционал влияет незначительно, но зато на
пользовательский опыт влияет очень сильно. Также в эту категорию попадают баги, не
влияющие на программу, но требующие исправления.
Вот пара примеров:
1.
Кнопки перекрывают друг друга. Они кликабельны, но визуальное
впечатление портится.
2.
Логотип компании на главной странице содержит орфографическую ошибку.
На функционал это вообще не влияет, но портит пользовательский опыт. Этот баг нужно
исправить с высоким приоритетом, несмотря не то, что на продукт он влияет минимально.
Высокая серьезность и низкий приоритет:
Такое сочетание бывает у багов, которые возникают в отдельных функциях
программы. Эти баги не позволяют пользоваться системой, при этом обойти их
невозможно. Но сами функции, содержащие эти дефекты, конечным потребителем
используются редко.
Примеры:
1.
Домашняя страница сайта ужасно выглядит в старых браузерах.
Перекрывается текст, не загружается логотип. Это мешает пользоваться продуктом,
поэтому серьезность бага высокая. Но так как очень мало пользователей открывают сайт
при помощи устаревшего браузера, такой баг получает низкий приоритет.
2.
Допустим, у нас есть приложение для банкинга. Оно правильно рассчитывает
ежедневный, ежемесячный и ежеквартальный отчет, но при расчете годового возникают
проблемы. Этот баг имеет высокую степень серьезности. Но если сейчас формирование
годовой отчетности не актуально, такой дефект имеет низкий приоритет: его можно
исправить в следующем релизе.
Советы:
- убирайте лишние шаги;
- упрощайте шаги, чем длиннее шаг/описание шага, тем хуже;
- проверьте на дубликаты;
- убедитесь, что репорт очевидный и понятный;
- 1 отчет для 1 дефекта;
- прослеживаемость с другими артефактами (возможность привязаться к тесткейсу, тест-сьюту, тестовому прогону, к пунктам требований);
- проверьте грамотность.
Что делать, если разработчик утверждает, что найденный дефект таковым не
является?
Указывать на требования, апеллировать к здравому смыслу, подключать
аналитика, чтобы объяснил.
18
Если это поведение в требованиях не указано, то обратиться к аналитику, за
уточнением этого поведения.
Если они считают, что все хорошо – дефект закрывается.
Основные ошибки:
недостаточно предоставленных данных, для воспроизведения бага, или баг
воспроизводится только при обстоятельствах, но они не указаны;
название репорта и ожидаемый результат не соответствуют друг другу;
завышение/занижение severity (критичности (серьезности) влияния на
систему);
неверное употребление терминологии;
сложные речевые обороты;
отсутствует ожидаемый результат;
критика программиста.
Отчет о тестировании – часть тестовой документации, включающая в себя
описание процесса тестирования, суммарную информацию о протестированных за
подотчетный период билдах, информацию о деятельности тестировщиков, а также другие
статистические данные (анализ результатов тестирования, который проводится с некоторой
периодичностью (календарный график, например, раз в 2 неделю, в конце тестирования
билда или в конце спринта) в процессе работы с проектом, а также в конце работы с
проектом). Его основная задача – оценить текущее или финальное качество проекта и
принять (если необходимо) соответствующие решения и меры. (Отчет создается на основе
принятого в компании или предоставленного заказчиком шаблона).
Цель отчета – предоставить лицам, заинтересованным в проекте, полную и
объективную информацию о текущем состоянии качества проекта. Эта информация
выражается в конкретных фактах и цифрах.
Структура отчета:
Титульный лист (название продукта, билд, версия, автор).
Команда тестировщиков (задействованные лица с указанием должности и
роли на проекте в подотчетный период).
Описание процесса тестирования (testing process description) (краткое
описание того, как происходило тестирование: окружение, какие использовались методы,
техники, виды, инструментальные средства и т.п.).
Краткое описание (summary) (какие билды были протестированы (прошел
или не прошел тестирование), есть ли в качестве продукта прогресс или регресс, есть ли
какие-либо проблемы, требующие внимания руководства).
Расписание (testing timetable) (детализированное описание того, какая работа
и на протяжении какого времени выполнялась каждым тестировщиком).
Рекомендации (recommendations) (выделить важные моменты, на которые
следует обратить внимание руководству или лидерам проектных команд, рекомендация
если проект готов на передачу заказчику или в продакшн).
Статистика по ошибкам (bags statistics). (Найдено, исправлено, проверено,
отклонено, открыто заново (все этапы (статусы) с отображением критичности)).
- Список новых ошибок (new bugs found) (найденных за подотчетный период).
Статистика по всем ошибкам (за все время работы над проектом) (all bugs
statistics). (Найдено, исправлено, проверено, отклонено, открыто заново (все этапы
(статусы) с отображением критичности)).
ТЕХНИКИ ТЕСТ-ДИЗАЙНА:
Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются
тестовые случаи (тест-кейсы). (Принцип Парето - «20% усилий дают 80% результата, а
остальные 80% усилий — лишь 20% результата»).
19
Задачами тест-дизайна являются:
Анализ требований и рисков тестирования;
Определение проверок для тестирования;
Формализация проверок в виде тестовых сценариев;
Приоритезация проверок;
Определение подходов к тестированию.
Техники тест-дизайна:
1.
Тестирование на основе классов эквивалентности (equivalence
partitioning) — это техника, основанная на методе чёрного ящика, при которой мы
разделяем функционал (часто диапазон возможных вводимых значений, поле ввода) на
группы эквивалентных по своему влиянию на систему значений, или которые приводят
систему к одному результату.
То есть, это некое множество значений, которое вы можете подставлять в программу
и получать один и тот же результат. Результатом можем быть не только конкретные
значения, действия программы, но и просто область применения. Поэтому, самые простые
классы эквивалентности, на которые делятся проверки, это 2 основных класса: позитивные
(валидные значения) и негативные (не валидные значения) сценарии. Далее, каждый класс
эквивалентности можем разделить на дополнительные классы и т.д. до того момента, пока
проверки не будут приводить к точечным и конкретным результатам тестирования.
Рассмотрим пример:
Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя
из его возраста, который вводится в форму:
От 18 до 25 лет – 18%
От 25 до 45 лет – 16 %
Свыше 45 лет – 20%
Мы определяем 2 основных класса – это позитивные и негативные сценарии.
Позитивными сценариями будут все значения, которые приводят к получению
результата, негативными сценариями – значения, результаты которых не описаны, как
ожидаемый результат.
Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 2544 и 45 +.
В классе негативных сценариев мы формируем значения, исходя из необходимости
проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод
символов и т.д.
Результатом данного разбиения будет значение или диапазон значений, в котором
нам необходимо выполнить всего одну проверку с любым значением из диапазона данных.
Могут возникнуть такие ситуации, как одно значение в диапазоне. Это тоже отдельный
класс эквивалентности и тоже требует проверки.
Итого мы имеем.
Позитивные проверки: Ввод значений: 19, 30, 48 (значения могут быть
любыми из данного диапазона класса).
Негативные проверки: 0, 3, -1, А и т.д.
2.
Техника анализа граничных значений (boundary value testing) — это
техника дополняет классы эквивалентности дополнительными проверками поведения
продукта на крайних (граничных) значениях входных данных.
Граничные значения определяются не только для числовых значений, но и для
буквенных (например, границы алфавита и кодировки), даты и времени, смысловых
значений. Граница числовых значений зависит от формата ввода, если у вас целые числа,
например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для
числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д. Главное определить шаг.
Дополним вышеописанный пример:
Далее исключаем повторяющиеся значения, и получаем значения для проверки
элемента ввода данных.
-
20
-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.
Значение max обычно уточняется у Заказчика или аналитика. Если не могут
предоставить, то нужно подобрать значение, соответствующее здравому смыслу (вряд ли
кто-то придет за кредитом в возрасте 100 лет).
Следующий шаг, это наложить граничные значения на значения классов
эквивалентности, исключить лишние проверки, пользуясь правилом «достаточно одного
значения для проверки одного класса» и финализировать список.
3.
Попарное тестирование (pairwise testing) — это одна из техник тестдизайна, основанная на комбинаторике и разделению входных параметров «по парам»
(почему и называется pairwise testing). Проводится комбинирование вариантов и подбор
нужных, то есть оцениваются все возможные комбинации (сочетания) входных
переменных, и из них выбираются только нужные (значимые). Техника основана на том,
что 99,9…% дефектов возникают при взаимодействии не более двух факторов
одновременно/
ISTQB определяет попарное тестирование как технику тест-дизайна методом
черного ящика, при которой тест-кейсы создаются таким образом, чтобы выполнить все
возможные отдельные комбинации каждой пары входных параметров.
Быстрый пример:
QA-команде передали приложение, в которое пользователь должен вводить свои
значения. Всего 10 полей ввода, может быть по 10 вариантов в каждом. Получается всего
10х10=100 комбинаций нужно будет протестировать, если пойти по ошибочному пути
«исчерпывающего тестирования».
Или, например, есть простое приложение, в которое ввод подается выбором
значений из таких объектов ввода: выпадающего списка (с числами от 0 до 9), чекбокса,
радиокнопки, текстового поля, и кнопки ОК. Текстовое поле принимает только числа от 0
до 100. Получаются варианты следующие:
Список: 0,1,2,3,4,5,6,7,8,9
Чекбокс: Отмечен / нет
Радиокнопка: Выбрана / не выбрана
Текстовое поле: числа 0…100
Сколько же тест-кейсов нужно создать? Невероятно много. Исчерпывающее
тестирование такого приложения предполагает (умножаем все количества вариантов)
10*2*2*100 = 4000 тест-кейсов. Если же к этому добавить «негативные варианты» (то есть
с вводом заведомо некорректных значений, а так обязательно случается в реальном мире),
то количество будет «сильно выше» 4000.
Как же сократить это количество, упрощая себе задачу? То есть, в чем заключается
суть попарного тестирования?
Во-первых, что здесь можно сократить? Нельзя — варианты радиокнопки и
чекбокса, они всегда будут иметь только возможных 2 значения. С текстовым полем можно
ограничиться тремя числами: валидное целое, невалидное целое, буква или спецсимвол. Со
списком: здесь предположим, для упрощения, что значение будет или 0, или “любое другое
кроме 0”, то есть получается только 2 варианта, «0» и «другое». Считаем количество
вариантов (тест-кейсов) теперь: 2*2*2*3 = всего 24. То есть, при «обычном» подходе у нас
24 тест-кейса, что уже неплохо.
Идем дальше по пути сокращения:
1.
Упорядочиваем объекты ввода так, чтобы объект ввода с самым большим
количеством вариантов шел первым, и т.п.
2.
Делаем таблицу. Список у нас будет принимать 2 значения.
3.
Следующая колонка — чекбокс, тоже 2 значения.
4.
Проверяем, что у нас «покрыты» все комбинации списка и чекбокса
5.
То же делаем с радиокнопкой (2 значения)
6.
Проверяем, что все пары «покрыты». (используем программу)
21
Текстовое поле
Выпадающий список
Чекбокс
Радиокнопка
Валидное
0
Отмечен
Включена
Валидное
“Другое значение” (не 0)
Не отмечен
Выключена
Невалидное
“Другое значение” (не 0)
Отмечен
Включена
Невалидное
0
Отмечен
Выключена
Невалидное
0
Не отмечен
Включена
Буква
0
Не отмечен
Включена
Буква
0
Отмечен
Выключена
Буква
“Другое значение” (не 0)
Отмечен
Включена
Таким образом, пользуясь техникой попарного тестирования, сократили количество
тест-кейсов сначала с 4000 до 24, затем до 8 как в таблице, что уже вполне посильно. И при
этом надежность такого метода вполне нормальная.
Полезности метода:
- Уменьшает количество тест-кейсов;
- Позволяет быстро повысить тестовое покрытие;
- Достаточно эффективно повышает % найденных багов;
- Ускоряет создание и выполнение тест-кейсов;
- Снижает издержки проекта.
Недостатки:
- Не работает с некоторыми типами переменных;
- Нужен опыт в определении комбинаций;
- Трудоемкость.
4.
Тестирование на основе состояний и переходов (State-Transition
Testing) — применяется для фиксирования требований и описания дизайна приложения.
(Схема состояний и переходов (от англ. State & Transition Diagram, S&T) — это схема
переходов и состояния, специальная техника для перехода ТЗ из одного статуса в другой. С
ее помощью пользователь в наглядной форме может просматривать переход продукта из
одной стадии в другую. Идеально подходит для длительных проектов, где техническое
задание разбито на большие спринты, где требуется контроль и верификация любого
действия). (Можно сказать, что это совокупность причин и следствий (но есть действия,
которые не имеют определенного состояния)).
В проекте может быть большой набор требований с описанием состояния системы и
условий, при которых она в них переходит. Без визуального представления этих состояний
трудно увидеть всю цепочку событий. А это может привести к дефектам архитектуры и
дизайна приложения уже на уровне требований. Например, теперь в мессенджерах можно
удалять сообщения как у отправителя, так и у получателя. То есть для состояния сообщения
«Отправлено» или «Прочитано» должен быть предусмотрен переход в состояние
«Удалено». Если он будет упущен при составлении требований — приложение получится
неудобным для пользователей, вряд ли его станут часто запускать.
22
Чтобы избежать таких ошибок, можно использовать технику тест-дизайна
«Тестирование состояний и переходов». Она позволяет составлять тестовые сценарии,
основываясь на визуальном представлении состояний и переходов системы.
Прежде чем рассматривать эту технику, познакомимся с основными понятиями,
которые используются при составлении диаграмм переходов и состояний.
Точка входа — старт работы системы или приложения.
Переход (transition) — переход системы из одного состояния в другое, который
происходит в результате действий пользователя или при определённых условиях.
Событие (event) — (надпись над стрелкой) — действие пользователя, которые он
выполнил для перевода системы в другое состояние, или действия самой системы,
меняющие её состояние.
Действие (action) — реакция приложения на действия пользователя или самой
системы (на событие).
Условия перехода (transition conditions) — условия, которые необходимы для
перехода системы в другое состояние, например, изменение даты для начисления
процентов на вклад.
Состояние (state) — состояние системы до или после перехода в результате действий
пользователя или при определённых условиях.
Точка выхода — успешное окончание полного цикла работы приложения, то есть
выполнение всех переходов и состояний.
Роли пользователей (actors) — пользователи, которые могут по-разному влиять на
систему в зависимости от уровня прав доступа (зарегистрированный пользователь,
менеджер, администратор).
Классический пример — бронирование авиабилетов. Начнём с позитивного
сценария: пользователь успешно осуществляет весь цикл бронирования, включая оплату и
использование билета. Всегда стоит начинать с позитивных проверок, чтобы убедиться, что
система работоспособна и выполняет ключевые функции. Если это не так, то дальнейшее
тестирование не имеет смысла до устранения дефектов.
1.
Точкой старта в этом случае будет вход в систему бронирования и выбор
нужного билета. Затем пользователь передаёт информацию, необходимую для
23
бронирования билета (имя и фамилию, паспортные данные), и нажимает кнопку
«Забронировать». Это нажатие можно считать событием. Под его воздействием стартовал
таймер времени до окончания срока оплаты. Система перешла в первое состояние «Билет
забронирован».
2.
Дальнейшее событие — «Оплата билета», которое переведёт систему в
следующее состояние «Билет оплачен».
3.
Затем по событию «Получить билет» система должна выполнить действие
«Отправка билета по email» и перейти в другое состояние — «Билет получен».
4.
Последним звеном в этой цепочке будет событие «Предъявление билета при
посадке» (в примере часть событий пропущена — в реальных проектах их, конечно, может
быть намного больше). Состояние «Билет использован» — цикл бронирования успешно
завершён, система попадает в точку выхода.
Рассмотренный сценарий — позитивный, он не предполагает дополнительных
действий пользователя. Это, конечно, невозможно, так как не всегда бронирование билета
должно заканчиваться его использованием. Пользователь может не оплатить билет — или
оплатить, но потом отменить, и прочее. Эти состояния также необходимо отразить на
диаграмме.
Так как пользователь может забронировать билет, но не оплатить его, отмена брони
произойдёт по истечении времени на оплату. В таком случае необходимо добавить в
диаграмму состояние «Отменено по таймеру». А также «Отменено клиентом», в которое
система может перейти из трёх предыдущих: «Билет забронирован», «Билет оплачен»,
«Билет получен».
При переходе из «Билет забронирован» в «Отменено клиентом» пользователю
достаточно просто произвести событие «Отмена». Если билет уже был оплачен, действием
системы должен стать возврат денежных средств — «Возврат».
Предположим, что для перехода системы из состояния «Билет получен» в
«Отменено клиентом» помимо отмены билета пользователь должен выполнить условие
перехода — позвонить в авиакомпанию. Это тоже необходимо отразить на диаграмме.
Условие перехода указывается над стрелкой в квадратных скобках.
Так визуализируется работа системы бронирования, и можно сразу увидеть
состояния, которые принимает система, и условия для их изменения. Такая визуализация
актуальна для сложных проектов с множеством состояний, переходов и условий для них.
Она позволяет не пропустить важные звенья системы и наиболее полно описать тестовые
сценарии для проверки. Например, первым сценарием может стать проверка полного цикла
работы системы от входа в неё до точки выхода. Затем уже можно выполнять тестирование
более детально, добавляя новые сценарии на основании диаграммы переходов и состояний.
При построении диаграмм состояний и переходов стоит учитывать следующее:
24
не допускать пересечения линий переходов — это усложняет визуальное
восприятие диаграммы и может привести к ошибочному переходу;
сложные процессы лучше представлять в виде нескольких диаграмм — если
охватить всё одной схемой, она будет слишком сложной;
главную последовательность состояний следует размещать на одной
горизонтальной линии, чтобы прослеживался позитивный сценарий работы системы.
Дополнительные состояния можно представить в виде ответвлений и разместить по бокам
от основной последовательности.
Плюсы диаграмм состояний и переходов:
- позволяют визуализировать состояния продукта;
- демонстрируют варианты переходов, которые можно пропустить;
- помогают отследить дефект, сужая его локацию до конкретного перехода;
- показывают внутреннюю механику продукта.
Минусы:
- можно пропустить неочевидные переходы;
- при слишком сложной структуре продукта диаграммы могут стать громоздкими и
запутанными;
- являются только основой к применению других методов;
- бесполезны при плохом знании продукта.
5.
Таблицы принятия решений (Decision Table Testing) — техника
тестирования, основанная на методе чёрного ящика, которая применяется для систем со
сложной логикой, помогающая наглядно изобразить комбинаторику условий из ТЗ,
повысить общее тестовое покрытие, не упуская все (возможные) комбинации.
Ячейки таблицы заполняются с опорой на три параметра, которые расположены в
шапке и первом столбце. Всё начинается с условий работы системы, выбранных из
требований. Далее идут правила, которые отражают выполнение условий. Завершается
таблица действиями — это результаты, которые наступают при соблюдении правил.
Преимущества:
Наглядность. Это главное преимущество метода. Вместо того, чтобы текстом
описывать тест-кейсы и бояться что-то упустить, можно составить матрицу и быть
уверенным, что ни одна проверка не потеряется.
Удобство. Один столбец таблицы — один готовый тест-кейс.
25
Простота. Таблицу решений можно составить в Google-таблице, Excel, на бумаге
или даже на салфетке, если хочется. Чтобы использовать метод, не нужно уметь писать код
или осваивать специальную программу.
Недостатки:
Долго. Главный минус метода: для составления таблицы нужно время, которого
всегда не хватает. Иногда тестировщик думает, что проще потратить полчаса-час на
тестирование, а не на составление таблицы.
Рассмотрим составление таблицы на примере:
Требование: для поддержания системы лояльности провести информационную
рассылку постоянным клиентам.
Содержание писем зависит от следующих условий:
1.
Клиенты типа А, В получают стандартное письмо.
2.
Клиенты типа С получают специальное письмо.
Клиентам, совершившим пять и более покупок или купившим на сумму более 500
долларов, в письме сообщается о дополнительной скидке 20% на следующий заказ.
Начнём составлять таблицу по плану:
1.
Разбить требование на условия.
2.
Посчитать количество возможных правил (комбинаций).
3.
Составить таблицу принятия решений.
4.
Исключить лишние комбинации, если они есть.
5.
Создать тесты.
Разберём каждый пункт.
1. Разбить требование на условия.
В данном случае можно выделить три условия:
тип клиента;
пять и более покупок;
сумма больше 500 долларов.
2. Посчитать количество возможных правил (комбинаций).
Расчёт можно выполнить по формуле: X = Y1 ⋅ Y2 ⋅ … ⋅ Yn, где:
Х — вычисляемое количество комбинаций;
Y1...Yn — количество вариантов каждого условия;
N — количество условий.
Таким образом получим:
Y1 = 4 (четыре значения для условия «Тип клиента» — «A, B, C, D»);
Y2 = 2 и Y3 = 2 (по два значения для условий «Пять и более покупок» и
«Сумма больше 500 долларов» — «YES/NO»);
N = 3 (требование содержит три условия);
X = 4 ⋅ 2 ⋅ 2;
Х = 16 правил (комбинаций условий).
3. Составить таблицу принятия решений.
Заносим в таблицу условия, значения и правила следующим образом:
26
В таблицу был добавлен тип клиента «D» — это все остальные типы клиентов (если
существуют), если будут выявлены те, что не подпадают под характеристики для клиентов
типа «А, В, С». Для правил, которые не отражены в требованиях, использован «?» (в
требованиях не указано, какое письмо должно быть отправлено в ситуации, когда
сочетаются условия «более пяти покупок» и «сумма больше 500 долларов», а также как
поступить с клиентами типа D). Ситуации, помеченные знаком вопроса, надо прояснить с
аналитиком или заказчиком.
Первая строка в таблице формируется так: количество всех правил (комбинаций)
делится на количество значений первого условия. То есть 16 (число правил) делим на 4
(число значений для условия «Тип клиента»). Получаем ряд из четырёх одинаковых
значений подряд (см. таблицу выше). Заполняя остальные строки, необходимо соблюдать
последовательность: каждая следующая строка — это предыдущая строка, разделённая
пополам. То есть в первой строке каждое значение повторялось четыре раза подряд, во
второй — два раза, в третьей уже происходит чередование значений. Если бы в таблице
было ещё одно условие, то в следующей строке каждое значение снова повторялось бы
четыре раза, потом два раза и так далее.
Также в таблице указываем действия, которые произойдут при совпадении тех или
иных условий. И отмечаем, какое именно действие выполняется при совпадении условий.
В данном случае выделим четыре действия: «Стандартное письмо», «Специальное письмо»,
«Сообщение о скидке», «Не получают письмо».
4. Исключить/добавить комбинации.
В этом случае были добавлены комбинации для дополнительного типа клиента «D».
Также могут возникать ситуации, когда в таблице появятся комбинации условий, которые
на практике невозможны. Например, если тестируется форма с двумя кнопками
«Сохранить» и «Отменить», каждая кнопка имеет два значения: «Нажата» / «Не нажата».
Одновременно обе кнопки не могут принимать значение «Нажата» — значит, такая
комбинация должна быть исключена из таблицы.
5. Создать тесты.
В результате получаем тестовые сценарии, которые можно либо перенести в тесткейсы, либо оставить в таблице и добавить строку с результатом проверки.
6.
Доменный анализ (Domain Analysis Testing) — это техника основана на
разбиении диапазона возможных значений переменной на поддиапазоны, с последующим
выбором одного или нескольких значений из каждого домена для тестирования.
(Используется для определения действенных и эффективных тестовых сценариев в случаях,
когда множественные параметры могут или должны быть протестированы одновременно).
(Комбинация техник классов эквивалентности, граничных значений, попарного
тестирования).
Плюсы и минусы доменного тестирования:
Плюсы:
- Обнаружение ошибок при минимальном количестве тестов.
- Интуитивно понятный, универсальный подход.
Минусы:
- Низкая вероятность обнаружения ошибок НЕ на граничных условиях.
- Низкая вероятность обнаружения ошибок в сложных взаимодействиях.
- Пространство значений часто бывает сложно формализовать.
Пример техники доменного тестирования:
Представим ситуацию, когда нужно одновременно протестировать несколько
параметров, для которых существуют линейные классы эквивалентности.
Сервис прогноза погоды развивается и обогащается функциональностью для
профессиональных путешественников.
User story 1: Я как пользователь хочу узнать прогноз погоды, указав координаты
точки на карте.
27
User story 2: Я как пользователь хочу узнать прогноз погоды на выбранное
количество дней.
Пользователь: заполняет поле “Широта” значением от -90,000000 до 90,000000.
Пользователь: заполняет поле “Долгота” значением от -180,000000 до 180,000000.
Пользователь: заполняет поле “Дней” значением от 1 до 3.
Пользователь: выбирает язык.
Пользователь: выбирает информацию по осадкам.
Пользователь: выбирает детализацию по дням / часам.
Данные валидные:
Система: показывает прогноз погоды.
Данные невалидные:
Система: показывает сообщение об ошибке “Прогноз не найден. Уточните
параметры поиска”.
Сколько нужно тестов, чтобы обеспечить оптимальное покрытие с учетом
тестирования граничных значений?
● Поле “Широта”: 6 тестов
○ -90,000000
○ -90,000001
○ -89,999999
○ 90,000000
○ 90,000001
○ 89,999999
● Поле “Долгота”: 6 тестов
○ -180,000000
○ -180,000001
○ -179,999999
○ 180,000000
○ 180,000001
○ 179,999999
● Поле “Дней”: 5 тестов
○0
○1
○2
○3
○4
● Язык, осадки, детализация по pairwise: 4 теста – по технике “Классы
эквивалентности”.
Итого 21 тест, если проверять все по отдельности. Но количество тестов можно
сократить при помощи техники доменного анализа.
Основной принцип доменного анализа - скомбинировать значения на границах и
внутри интервалов и таким образом сократить количество тест-кейсов. Доменный анализ
оперирует понятиями:
● точка on - лежит строго на границе;
● точка off - лежит слева или справа от границы, т.е. точки on;
○ если интервал закрыт со стороны точки on, то точка off лежит вне интервала;
○ если интервал открыт со стороны точки on, то точка off лежит внутри интервала;
● точка in - любое значение внутри интервала, ближе к середине.
Алгоритм доменного анализа:
1. Создадим таблицу и внесем в нее:
a. параметры, для которых есть линейные классы эквивалентности;
b. для каждого параметра - граничные значения со знаками >, =, .
Также ошибка будет сгенерирована и в следующем примере, если название
организации взять в обычные кавычки (английские двойные):
Чтобы ошибки не возникали, нужно заменить символ < на его сущность. В XML
существует 5 предопределенных сущностей:
67
Таблица I.1 — Сущности
Сущность
Символ
Значение
<
<
меньше, чем
>
>
больше, чем
&
&
амперсанд
'
'
апостроф
"
"
кавычки
Примечание
Только символы < и & строго запрещены в XML. Символ > допустим, но лучше
его всегда заменять на сущность.
Таким образом, корректными будут следующие формы записей:
или
В последнем примере английские двойные кавычки заменены на французские
кавычки («ёлочки»), которые не являются служебными символами.
Поиск информации в XML файлах (XPath):
XPath (англ. XML Path Language) — язык запросов к элементам XML-документа.
XPath расширяет возможности работы с XML.
XML имеет древовидную структуру. В документе всегда имеется корневой элемент
(инструкция к дереву отношения не имеет). У элемента дерева
всегда существуют потомки и предки, кроме корневого элемента, у которого предков нет,
а также тупиковых элементов (листьев дерева), у которых нет потомков. Каждый элемент
дерева находится на определенном уровне вложенности (далее — «уровень»). У элементов
на одном уровне бывают предыдущие и следующие элементы.
Это очень похоже на организацию каталогов в файловой системе, и строки XPath,
фактически, — пути к «файлам» — элементам. Рассмотрим пример списка книг:
Everyday Italian
Giada De Laurentiis
2005
30.00
Harry Potter
J K. Rowling
2005
29.99
68
Learning XML
Erik T. Ray
2003
39.95
XPath запрос /bookstore/book/price вернет следующий результат:
30.00
29.99
39.95
Сокращенная форма этого запроса выглядит так: //price .
С помощью XPath запросов можно искать информацию по атрибутам. Например,
можно
найти
информацию
о
книге
на
итальянском
языке:
//title[@lang="it"] вернет Everyday Italian .
Чтобы
получить
больше
информации,
необходимо
модифицировать
запрос //book[title[@lang="it"]] вернет:
Everyday Italian
Giada De Laurentiis
2005
30.00
В приведенной ниже таблице представлены некоторые выражения XPath и
результат их работы:
Таблица I.2 — Выражения XPath
Выражение XPath
/bookstore/book[1]
/bookstore/book[position()35.00]
Результат
Выбирает
первый
элемент book ,
который
является потомком элемента bookstore
Выбирает первые два элемента book , которые
являются потомками элемента bookstore
Выбирает все элементы title с атрибутом lang
Выбирает все элементы title с атрибутом lang ,
который имеет значение en
Выбирает
все
элементы book ,
которые
являются потомками элемента bookstore и
которые содержать элемент price со значением
больше 35.00
69
Таблица I.2 — Выражения XPath
Выражение XPath
Результат
Выбирает все элементы title элементов book
/bookstore/book[price>35.00]/title
элементов bookstore ,
которые
содержать
элемент price со значением больше 35.00
Кодировки:
Самыми распространенными кириллическими кодировками являются Windows1251 и UTF-8 . Последняя является одним из стандартов, но большая часть ФНС
отчетности имеет кодировку Windows-1251 .
В XML файле кодировка объявляется в декларации:
Часто можно столкнуться с ситуацией, когда текстовый редактор некорректно
распознает кодировку и отображает кракозябры. В такой случае, необходимо выбрать
кодировку вручную, для этого выполните:
Таблица I.3 — Смена кодировки в разных программах
Программа
Кодировка
Notepad++
«Документ → Кодировка»
Geany
«Документ → Установить кодировку»
Firefox
«Вид → Кодировка»
Chrome
«Настройка → Дополнительные инструменты →
Кодировка»
Примечание
В большинстве случаев при работе с русскоязычными файлами помогает
переключение кодировки на Windows-1251 или UTF-8 . Если все равно не удается
прочитать содержимое XML документа, стоит открыть его в Mozilla Firefox, он отлично
распознает кодировки.
Если ничего не помогает, вполне возможно, что файл был поврежден.
XSD схема:
XML Schema — язык описания структуры XML-документа, его также
называют XSD. Как большинство языков описания XML, XML Schema была задумана для
определения правил, которым должен подчиняться документ. Но, в отличие от других
языков, XML Schema была разработана так, чтобы её можно было использовать в создании
программного обеспечения для обработки документов XML.
После проверки документа на соответствие XML Schema читающая программа
может создать модель данных документа, которая включает:
словарь (названия элементов и атрибутов);
модель содержания (отношения между элементами и атрибутами и их
структура);
типы данных.
Каждый элемент в этой модели ассоциируется с определённым типом данных,
позволяя строить в памяти объект, соответствующий структуре XML-документа. Языкам
70
объектно-ориентированного программирования гораздо легче иметь дело с таким
объектом, чем с текстовым файлом.
WSDL:
WSDL - это описательный язык, основанный на языке разметки XML, и именно в
wsdl описан веб-сервис, который вам придется тестировать. (Можно сказать, что это полная
документация веб-сервиса). WSDL включает в себя информацию о местоположении
сервиса, часто включает в себя XSD. Именно из WSDL SOAPUI генерирует проверяемые
классы.
Если Вы направите в веб-сервис нестандартный запрос, он ответит на это ошибкой.
WSDL - это свод правил общения с вашим сервисом, соблюдая которые вы сможете с этим
сервисом коммуницировать. Собственно, WSDL и XSD подробно описывают что и в каком
виде слать на сервер, чтобы получить хороший ответ.
Основные теги, с которыми вы столкнетесь в описании WSDL-сервера:
Message — сообщения, используемые web-сервисом.
PortType — список операций, которые могут быть выполнены с
сообщениями.
Binding — способ, которым сообщение будет доставлено.
Для работы с SOAP API используют Soap UI:
SoapUI - это приложение для тестирования веб-сервисов с открытым исходным
кодом для сервисно-ориентированных архитектур (SOA) и передач состояния
представления (REST).
Язык программирования, на котором пишут скрипты в SOAP UI, называется Groovy.
Его функциональность охватывает проверку веб-сервисов, вызов, разработку,
моделирование и имитацию, функциональное тестирование, нагрузочное тестирование и
проверку соответствия.
Он полностью построен на платформе Java и использует Swing для
пользовательского интерфейса. Это означает, что SoapUI является кросс-платформенным.
Сегодня SoapUI также поддерживает IDEA, Eclipse и NetBeans.
SoapUI может тестировать веб-службы SOAP и REST, JMS, AMF, а также совершать
любые вызовы HTTP(S) и JDBC.
Как отправлять запросы:
New REST Project → Пишем URI → Запрос создаётся, можно добавлять новые.
Method можно выбирать из выпадающего списка.
Проект имеет иерархическую структуру.
Project → Service → Resource → Method → Request
Названия отражают суть:
Request (запрос) это то место, где можно поменять тело запроса и просмотреть ответ
сервера. Чтобы отправлять запросы нужно нажимать зелёный треугольник.
Method (метод) указывает GET, POST, PUT или другой метод, который Вы будете
использовать. Все дочерние запросы будут иметь один и тот же Method.
Resource (ресурс) отвечает за ту часть URL, которая добавляется к базовой.
Service (сервис) отвечает за базовую часть URL
Как сохранять проекты:
Советую помимо использования «Save all projects» закрывать все новые окна
вручную. Тогда SOAP UI предложит Вам сохранить каждый проект по отдельности.
После того, как все новые проекты сохранены, Вы можете закрыть SOAP UI. Я
стараюсь закрывать SOAP UI только когда все окна закрыты.
Создание Test Suit in SOAP UI:
Коротко:
→Правый клик Project → Create New TestSuit (CTRL + T)
Укажите имя для TestSuit → Правый клик на TestSuit
71
New TestCase (CTRL + N) → Укажите имя для TestCase
Expand Test Case → Кликните на Test Steps → Add Step
Выберите request (e.g. SOAP Request) → Укажите имя для new step
Выберите операцию, которая запускает request
Добавьте Request в TestCase (OK)
Зелёная «+» иконка плюса появится наверху.
Кликнув на неё Вы можете добавить Assertions.
Подробно:
Правый клик на названии проекта
→ Create New TestSuit (CTRL + T)
Укажите имя для TestSuit
→ Правый клик на TestSuit
New TestCase (CTRL + N)
Укажите имя для TestCase
72
→ Expand Test Case
→ Кликните на Test Steps
→ Add Step
→ Выберите request (e.g. SOAP Request)
→ Укажите имя для new step
→ Выберите операцию, которая запускает request
→ Добавьте Request в TestCase (OK)
Зелёная «+» иконка плюса появится наверху. Кликнув на неё Вы можете добавить
Assertions.
Assertions в SOAP UI:
Assertions добавляются в TestSuit
Поэтому, чтобы добавлять Assertions нужно создать хотя бы один TestSuit и затем
кликнуть на зелёную+ иконку.
Затем Вы можете выбрать один из многих доступных в SOAP UI типов Assertions.
Property Content → Contains:
Выберите Contains. С помощью этого подтверждения (Assertions) можно искать
присутствует ли в ответе заранее определённое ключевое слово. Оно поддерживает
регулярные выражения и применимо ко всем ответам.
73
Specify unique name of Assertion
Type in content that you expect to receive in case of successful request
Property Content → Not Contains:
Выберите Not Contains. С помощью этого подтверждения (Assertions) можно
проверить отсутствие в ответе заранее определённого ключевого слова. Оно поддерживает
регулярные выражения и применимо ко всем ответам.
Введите уникальное имя для Assertions
Введите сюда то, что Вы точно не хотите видеть в теле ответа
74
Compliance, Status и Standards:
SOAP Response:
Выберите SOAP Response. Этим assertion вы можете проверить что последний
полученные ответ является валидным SOAP ответом. Это можно применять только к SOAP
TestRequest Steps. Не пытайтесь применять этот assertion к REST запросам.
Двойной клик на Assertion. Никакие дополнительные параметры не нужны этот шаг
можно добавить только один раз.
Compliance, Status и Standards:
Valid HTTP Status Code:
Выберите Valid HTTP Status Code. С помощью этого assertion Вы можете
проверить является ли последний полученный ответ (Response) валидным SOAP ответом
(Response). Как Вы уже, наверное, догадались, этот assertion применим только к SOAP
TestRequest Steps. Не пытайтесь использовать его для REST запросов.
75
Type in the HTTP Status Codes that are appropriate for your request.
Обычно это 200, но всё же стоит прочитать спецификацию системы, которую Вы
тестируете.
SLA → Response SLA:
Выберите Response SLA. С помощью этого assertion Вы можете подтвердить, что
последний полученный ответ (Response) был получен в течении определенного времени.
Можно применять к Script TestSteps и TestSteps которые посылают запросы и
получают ответы.
Укажитемаксимальное время ответа (мс)
Если время, в которое нужно уложиться не указано в спецификации - поставьте
какое-то разумное время.
Property Content → XPath Match:
Выберите XPath Match. Этот Assertion использует выражение типа XPath чтобы
выбрать содержимое указанного объекта и сравнить результат с ожидаемым значением.
Может быть применён к любому объекту, который содержит XML.
76
Нажмите Declare
Чтобы подтвердить, что нужные данные присутствуют в ответе напишите exists
(//данные_которые_должны_придти).
В поле Expected Result напишите true.
Чтобы проверить не наличие как таковое, а значение какой-то величины введите
в XPath Expression либо полный путь до величины, либо её имя.
А само значение, которое Вы ожидаете получить введите в поле Expected Result.
77
В случае, если, например, мы не можем соединиться с сервером и все наши Assertions
зафейлились у них появятся красные индикаторы.
Выводы:
REST (передача самоописываемого состояния) и SOAP (простой протокол доступа
к объектам) предлагают разные методы вызова веб-службы. И если REST – это, как мы уже
разобрали, архитектурный стиль, то SOAP определяет стандартную спецификацию
протокола связи для обмена сообщениями на основе XML.
Веб-службы RESTful не имеют состояния. Реализация на основе REST проста по
сравнению с SOAP, но пользователи должны понимать контекст и передаваемое
содержимое, поскольку не существует стандартного набора правил для описания
интерфейса веб-служб REST.
Службы REST полезны для устройств с ограниченным профилем (таких, как
мобильные) и их легко интегрировать с существующими веб-сайтами.
Для SOAP требуется меньше кода (низкоуровневого инфраструктурного кода,
который соединяет основные модули кода вместе), чем для проектирования служб REST.
Язык описания веб-служб описывает общий набор правил для определения сообщений,
привязок, операций и местоположения службы. Веб-службы SOAP полезны для
асинхронной обработки и вызова.
SOAP и применим в сложных архитектурах, где взаимодействие с объектами
выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки
данной теории, вполне применимым может оказаться именно REST ввиду своей простоты
и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более
сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как
правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным
выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более
производительным, так как не требует затрат на разбор сложных XML команд на сервере
(выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою
очередь, более надежен и безопасен.
78
gRPC:
RPC — это протокол вызова удаленных процедур, который одна программа может
использовать, чтобы вызвать метод, функцию или процедуру в другой, доступной в сети.
При этом не нужно досконально разбираться в сети. У клиента и сервера есть
дополнительный уровень в общении — клиентская и серверная заглушки. Они созданы для
того, чтобы отправлять данные по нужному адресу. Соответственно, в самом коде мы об
этом вообще не переживаем. Эти заглушки генерируются автоматически. Все, что нам
остается сделать — вызвать нужную процедуру.
Новая и, пожалуй, наиболее действенная и перспективная реализация этой
концепции — фреймворк gRPC. По сравнению с другими реализациями RPC, у него есть
множество преимуществ:
Идиоматические клиентские библиотеки на более чем 10 языках. Мы
можем использовать библиотеки на Java, C#, JavaScript, Python и т.д. Все это выглядит
нативно — не так, словно мы используем какую-то инопланетную технологию.
Простая структура определения сервисов. Для этого используются .protoфайлы.
HTTP/2. Двунаправленная потоковая передача на основе HTTP/2.
Трассировка. Позволяет мониторить вызовы процедур, что очень полезно
для отладки приложения и анализа работы сервисов для их дальнейших оптимизаций и
улучшений.
Health check. С помощью этого механизма можно быстро проверить,
работоспособен ли сервис и готов ли он обрабатывать запросы. Это помогает для
балансировки нагрузки.
Балансировка нагрузки. Эта особенность позволяет распределять нагрузку
на несколько экземпляров серверного приложения, тем самым значительно упрощая вопрос
масштабирования. Балансировка может производиться как на клиентской части (например,
клиентское приложение поочередно отправляет запросы на разные серверы), так и на
промежуточной (специальной прокси) посредством сервис-меша.
Подключение аутентификации. Ее отсутствие было главным недостатком
прошлых реализаций протокола. Из-за такой уязвимости RPC рекомендовали только для
внутреннего общения.
Сравнивая гугловскую технологию с REST, здесь тоже находим свои плюсы:
Работа с Protobuf. В REST для передачи данных применяется текстовый
формат JSON, который не сжимается. Protobuf — это бинарный формат. Используя его, мы
избегаем передачи лишних данных и нам не надо будет десериализовать после этого
полученные сообщения.
Обработка HTTP-запросов. В случае с REST необходимо постоянно думать,
какой статус-код может прийти, какие данные будут храниться и т.п. В gRPC мы
прикладываем минимум усилий для вызова удаленных процедур и их определения.
Простота определения контрактов. В REST для описания интерфейсов и
документации нужно использовать сторонние инструменты и библиотеки — такие, как
OpenAPI или Swagger. В gRPC происходит простое определение контрактов в .protoфайлах.
HTTP/2. REST зачастую использует более старую версию данного протокола
— HTTP/1.1.
Чем хорош HTTP/2? Среди важных преимуществ:
бинарный формат передачи данных (уменьшает размер сообщений и ускоряет
работу);
экономия трафика (усовершенствованное сжатие HTTP-сообщений, в первую
очередь хедеров);
возможность передавать потоки данных;
79
мультиплексирование (в HTTP 1.1 для передачи трех файлов надо установить
три соединения, в каждом из которых будет запрашиваться и отправляться определенный
файл. В HTTP/2 можно все передать по одному соединению);
приоритезация потоков.
Как настроить соединение по gRPC:
Последовательность создания gRPC канала включает несколько этапов:
1.
Открытие сокетов.
2.
Установка TCP-соединения.
3.
Согласование TLS.
4.
Запуск HTTP/2-соединения.
5.
Выполнение вызова gRPC-процедуры.
Мы могли бы избежать первых четырех пунктов за счет того, что один раз
устанавливаем соединение и просто пользуемся им — это называется Persistent Connection.
Почему бы не работать с таким решением постоянно? Однако возникает вопрос, как
настроить балансировку нагрузки, когда, допустим, нам понадобится несколько
экземпляров сервиса — как их распределять? Вариантов несколько:
Балансировка нагрузки на стороне клиента. В этом случае клиентская
библиотека знает о существовании нескольких инстансов данного сервиса. Например, она
будет отправлять запросы на каждый из них в процентном соотношении.
Балансировка нагрузки через прокси. Если эти сервисы хостятся на какомто оркестраторе (типа Kubernetes), он может решить, что инстансов слишком много, и
убирает один или, наоборот, добавляет новый. В этом случае помогает балансировка
нагрузки через прокси Service Mesh. Это может быть Linkerd, Istio, Consul и т.п. Клиент
будет устанавливать одно постоянное соединение к Mesh, а уже он посмотрит, какие есть
экземпляры сервиса, когда они появляются или исчезают и будет хендлить это. Соединение
будет только к актуальным сервисам, а клиент об этом знать не будет — у него всегда один
коннекшн.
Иногда gRPC сравнивают с WCF. Я не думаю, что это актуально, поскольку gRPC
— это узконаправленный фреймворк, который хорошо решает одну задачу. WCF — более
универсальный фреймворк, который поддерживает RPC, но также поддерживает REST,
SOAP и т.п. К сожалению, WCF не является универсальным в плане поддерживаемых
платформ, ведь пока он сильно привязан к .NET. В свою очередь gRPC может работать в
любой среде, и писать его можно на любых языках из списка поддерживаемых.
Однако на данный момент gRPC не может полноценно функционировать в
браузерах. Реализовать HTTP/2-общение в браузере невозможно, потому что нет такого
контроля над каналом связи, какой может быть, допустим, в .NET-приложении. Поэтому
Google предлагает альтернативу: использовать gRPC-прокси. То есть сам браузер будет
отправлять запросы HTTP 1.1 на прокси, который будет мапить сообщение в вызов gRPC
процедуры.
HTML/CSS:
HTML — это язык разметки гипертекстовых документов. Он нужен, чтобы
отображать в браузере специальным образом отформатированный документ с множеством
вложенных
элементов:
заголовками,
абзацами,
списками,
гиперссылками,
медиаисточниками, расположением изображений, видео и аудио.
Что такое HTML:
Дословно HTML означает Hypertext Markup Language (язык гипертекстовой
разметки). Из расшифровки названия понятно, что инструмент применяется для управления
отображением контента на интернет-странице, его структуризации.
Технология гипертекстовой разметки веб-страниц была предложена в 1989 году
британским специалистом Тимом Бернерсом-Ли. Сначала язык применялся для обмена
научной рабочей документацией между инженерами института CERN, сотрудником
80
которого был Бернерс-Ли. Немного позднее применение языка HTML было расширено
настолько, что он, наряду с такими базовыми элементами, как HTTP и URL лег в основу
Всемирной паутины.
Зачем нужен HTML:
Когда пользователь посещает сайт, браузер «подтягивает» файл HTML с данными о
структуре и содержании веб-страницы. Функция HTML состоит в выстраивании внешней
базы, фундамента, но сам запуск сайта в функционал не входит. HTML только указывает,
где должны располагаться элементы, каков их базовый визуал, где брать стили для
элементов и скрипты.
Возможности HTML:
HTML-документ можно составлять в любом редакторе, который есть в
операционной системе: Notepad на MS Windows, TextEdit в Mac, Pico на Linux. Браузер для
работы HTML–документа желателен, но необязателен. Он нужен для того, чтобы показать
отформатированный документ.
Просматривать HTML-страницы можно и без выхода в интернет. Для этого нужно
создать несколько HTML-файлов в одной папке, расположить в них гиперссылки и
переходить по ним от одного документа к другому.
Что можно и нельзя сделать на HTML:
HTML представляет собой основу внутренней структуры сайта, его базовый каркас.
Необходимо учитывать, что этот код является не языком программирования, как, например,
Python или C#, а инструментом для разметки гипертекста. С его помощью браузер
выстраивает интернет-страницу в виде, который понятен для людей, вырисовывает ее с
помощью CSS и добавляя логику через JavaScript. HTML оптимален для начинающих
программистов, он прост в освоении, а приобретенные навыки помогут уже в изучении
языков программирования.
В HTML-файле можно задавать:
гиперссылки;
списки;
формы;
разметку страницы;
таблицы;
абзацы;
картинки;
видео;
заголовки.
Создать базовый дизайн только с помощью HTML тоже можно. Например,
установить цвет и шрифт текста на странице или фон для блоков. Использовать только код
HTML для оформления веб-страниц не рекомендуется, дизайн будет примитивным и не
современным. С CSS же творческий процесс ничем не ограничивается. Тем не менее, ряд
функций в настоящий момент приходит в HTML из других, более серьезных инструментов.
Например, Drag&Drop (перемещение элементов мышкой) ранее было исключительно в
JavaScript, теперь это можно делать и на HTML.
Что такое теги HTML:
HTML-документ — это текстовый файл с расширением .html или .htm. В браузере
он преобразуется в веб-страницу и состоит из набора тегов. Они как раз и помогают
представлять текст на экране: благодаря им браузер понимает, что он читает не просто
текст, а структурированную информацию, разбитую на блоки.
Тег выглядит как набор символов, заключенный в угловые скобки. Символы в
скобках обозначают имя тега, которое описывает его функции. Вот несколько примеров:
— заголовок;
— абзац;
— курсив.
81
Тег – это составной элемент, определяющий разметку структурных блоков. Он
открывается, и этим начинает свое действие; и закрывается, обозначая завершение
команды. Закрытые и открытые теги различаются только слешем перед именем тега. Эти
теги создают оболочку, в которую помещается текст.
Именно незакрытые теги приводят к частым ошибкам и некорректным
отображениям страницы. Для наглядности представим, что теги – это матрешки, из которых
можно собрать набор. Складывая в большую матрешку все фигурки важно не забывать
закрывать все половинки (ставить закрывающие теги), иначе игрушка не получится.
Внутри тега могут быть атрибуты – дополнительная информация, которую нужно
скрыть из основного текста. Они ставятся только в открывающий тег, между ним и именем
тега должен быть пробел, а после него идет знак равенства. Значение атрибута заключается
в кавычки. С их помощью можно расширить возможности тегов и обратиться к ним, чтобы
узнать подробную информацию.
Есть теги, которые нет необходимости закрывать. Пример: тег переноса строки
— он одиночный и закрывать его не нужно. Раньше одиночные теги писались с
закрывающим слэшем перед закрывающей скобкой. Например: . В стандарте HTML5
использование закрывающего слеша в одиночных тегах необязательно. Примеры
одиночных тегов: , , .
Помимо атрибутов в тег можно добавлять вложения, эти элементы могут менять
стиль текста. Например, можно выделить какое-то слово жирным
шрифтом.
Как выглядит код на HTML:
Привет!
82
–предназначается для указания типа документа, так как браузер
может интерпретировать разные версии HTML (например, EXtensible HyperText Markup
Language, расширенный язык разметки гипертекста). По умолчанию его всегда включают в
начало страницы.
– сообщает браузеру, что это за HTML-документ. Этот тег хранит в
себе остальные теги.
– нужен для хранения других элементов, которые помогают
браузеру в работе с данными. Внутри него есть метатеги, которые применяются, чтобы
сохранять информацию для браузеров и поисковых систем.
– тело документа, в котором находятся все видимые пользователю
элементы.
– заголовок веб-страницы. Именно его браузер загрузит как название,
а при сохранении страницы в избранное он использует эту фразу как описание закладки.
– помещает изображение в нужное место. Обычно к нему добавляют атрибут
src, в котором содержится путь к этому изображению. Атрибуты width, height определяют
ширину и высоту изображения в пикселях.
Основная разметка HTML-страницы – это заголовки, абзацы и списки. Они
структурируют информацию на странице, все как в документе Word.
Заголовки:
В HTML бывает шесть уровней заголовков: – .
Привет!
Расскажешь
Какие бывают
Уровни заголовка
Заголовок типа используют обычно один раз, потому что он основной.
Абзац:
Как и на обычном письме, делит текст по смыслу.
Спасибо, всё понятно. Давай дальше
Списки:
Самые распространенные типы списков нумерованные и ненумерованные.
Ненумерованные или маркированные списки добавляются тегом . Такие
списки применяются, когда нам не важна последовательность их элементов.
В нумерованном списке, где пункты расположены в определенном порядке,
используется тег .
Отдельные элементы в любом типе списков заводятся тегом , который также
нужно закрывать после каждого пункта.
Преимущества и недостатки HTML:
Преимущества:
широкое распространение;
совместимость с подавляющим числом браузеров;
доступность;
поддержка стандарта консорциумом Всемирной паутины (WWW
Consortium);
простая интеграция с базовыми языками программирования, такими как PHP.
Недостатки:
не подходит для создания динамических страниц. Для этого может
понадобиться JavaScript или PHP;
некоторые браузеры медленно осваивают поддержку новых функций;
иногда бывает сложно предугадать реакцию старых браузеров (Internet
Explorer версии 8 и более ранней) на новые теги.
Является ли HTML языком программирования?
HTML не обрабатывает данные, а только их отображает. То есть с помощью него
нельзя выполнить сложение или умножение, можно только показать текст, в котором будет
83
содержаться нужная формула с ответом. Он отвечает за разметку – ограниченный набор
действий, который помогает браузеру отображать страницы.
Однако HTML обладает синтаксисом, семантикой и лексикой, поэтому он попадает
в категорию декларативных языков программирования.
CSS:
CSS (от английского Cascading Style Sheets) — это «каскадные таблицы стилей».
Являются формальным языком для задания дизайна документа на HTML или в других вебформатах (XHTML, XML). Другими словами, этот язык описывает, как именно HTMLкомпоненты страницы должны отображаться на экране или других носителях, например,
бумажных. Сегодня большая часть сайтов в глобальном интернете работает именно
благодаря каскадным таблицам стилей. Также термин CSS используется для обозначения
файла «стилей» сайта — такой файл не может использоваться отдельно от HTML-файла
сайта. CSS-файл экономит время веб-программиста и верстальщика, так как позволяет
оптимизировать управление дизайном для всех страниц сайта. Внешние таблицы стилей
хранятся в CSS-файле, обычно он один для всего сайта.
Простыми словами, CSS — это язык описания внешнего вида веб-страницы,
который используется для настройки: цветов, типографики, местоположения компонентов
страницы, стилей элементов и любого другого дизайна компонентов страницы.
Как работает CSS:
В HTML-документе находятся данные только о структуре веб-страницы. Чтобы
правильно вывести её на экран, с учётом дизайна сайта и особенности экрана
пользовательского устройства, браузер объединяет HTML-документ с файлом стилей,
который есть у любого сайта. Такое объединение происходит поэтапно. Вот основные шаги,
как работает CSS:
1.
Пользователь открывает сайт, например, переходя на него со страницы
результатов поиска.
2.
Браузер начинает загрузку HTML-документа.
3.
Файл преобразуется в DOM (объектная модель документа в оперативной
памяти).
4.
Браузер анализирует все компоненты, на которые в HTML-документе есть
URL, и которые связаны с этим документом. К таким ресурсам и компонентам как раз и
относятся стили (а также, например, любые медиафайлы: картинки, GIF, видеофайлы).
Внимание: если в HTML-документе ссылки на стили нет, то браузер не сможет получить к
ним доступ. JS-код обрабатывается далее, но не на этом этапе.
5.
Браузер начинает проверять файл стилей. В частности, он пытается
отсортировать правила, содержащиеся в нём (по их типу селектора). Каждое правило
определяется в свою категорию (например, ID, элемент, класс). Далее, на этом
промежуточном шаге, также происходит связывание обнаруженных селекторов с
правилами. Правила применяются к определенным DOM-узлам, а затем к каждому из них
привязывается определённый стиль. Всё, теперь браузер знает, как именно нужно
отрисовывать страницу.
6.
Происходит отрисовка страницы уже с настроенным дизайном её элементов.
Если вышеуказанная последовательность работы CSS показалась для вас слишком
сложный, посмотрите на эту схему:
Последовательность работы со стилями элементов в браузере.
84
Вообще существует не один, а несколько методов сформировать правила «стилей».
Это не только задание набора свойств с фиксированными значениями, но и метод при
помощи селекторов, например.
Основы:
Синтаксис CSS:
Начнём с подключения стилей к веб-странице. Файл стилей может публиковаться
разными способами, внутренними и внешними. Самый частый сценарий подключения
CSS — самостоятельный файл, который затем подключается к веб-странице через тег link:
.....
.....
Другой способ подключения стилей к сайту — самостоятельный, без файлародителя. Для этого можно использовать директиву import в контейнере style:
.....
@import url(style.css);
При этом CSS может быть указан непосредственно внутри документа: (опять же,
обратите внимание на тег style внутри head)
.....
body {
color: red;
}
.....
85
Наконец, CSS может быть указан в атрибуте style:
.....
.....
Теперь давайте посмотрим на важные особенности синтаксиса CSS. Напомним,
главная цель CSS — передать браузеру инструкции, согласно которым он будет
отрисовывать страницу. Согласно этой идее главными будут являться два элемента:
property и value.
1.
Первый элемент (property) — это непосредственное свойство, которое и будет
изменено.
2.
Второй элемент (value) — это значение, которым движок браузера будет
обрабатывать свойство. Вот от этих двух блоков и строится дальнейший синтаксис
«стилей».
Объявления. Два вышеуказанных блока (property and value) используются в
качестве объявлений.
Так работает объявление или declaration в CSS.
Поиск совпадений между такими объявлениями и элементами — основная задача
движка «стилей». Посмотрите на этот пример синтаксиса CSS:
selectorlist { property: value; [more property:value; pairs] }
Как видим для списка селекторов указываются: свойство, затем его значение, затем
— добавляются аналогичные пары. Здесь всё просто. Но большое разнообразие свойств и
огромное количество допустимых значений, часто приводят к тому, что новички допускают
ошибки в синтаксисе (и не только). А если выбрано некорректное значение для какого-либо
элемента, то браузер не будет выполнять такое объявление.
Ещё один простой пример синтаксиса CSS:
strong { color: red; }
div.menu-bar li:hover > ul { display: block; }
Важно: данные внутри пары свойство / значение всегда зависимы от регистра.
Пробелы, при этом, игнорируется (в любых местах). Сама пара всегда отделяется при
помощи знака «:» (двоеточие).
86
Блоки. Традиционно объявления в CSS объединяются в блоки. Их синтаксис
подразумевает открывающую и закрывающую фигурную скобку. Схематично
вышесказанное можно представить вот так:
Между фигурными скобками располагается содержимое.
Блок объявлений. Подразумевает отделение самих объявлений внутри при помощи
знака ;
Вот как работают объявления, блоки и блоки объявлений друг с другом:
Первым указываются объявления. Точка с запятой — используется для разделения
двух объявлений.
Операторы CSCS (они же statements):
Наборы правил — своего рода кирпичики для постройки финального файла стиля
для сайта. Обычно — это длинный-длинный список из разных параметров.
Пример пересечения действия операторов at-rules и rulesets.
87
Но не только данные о внешнем виде элементов страницы передают в «стилях».
Также есть технические сведения, которые должны передаваться движку браузера
(например, данные о счетчиках веб-аналитики, наборах, настройках типографики и другое).
Для таких данных задействуются иные, специфические виды утверждений. Это, в первую
очередь, at-rules и rulesets (наборы правил).
At-rules. Их характерный маркер — наличие символа @ в начале. Например, вот так:
/* Наша структура */
@ID (ПРАВИЛО);
/* Пример: приказывает браузеру задействовать UTF-8 кодировку*/
@charset "utf-8";
Примеры:
@charset — установка кодировки. Определяет кодировку символов,
используемую таблицей «стилей».
@import — нужно задействовать внешний файл CSS.
@namespace — содержимое документа должно интегрироваться как для XML
(только пространство имён).
Существуют и вложенные at-rules. Это множество CSS-операторов, которое
допустимо задействовать в качестве разных правил в какой-либо группе или как
самостоятельный оператор-CSS. Примеры вложенных операторов: @media, @page,
@viewport, @supports.
Rulesets (наборы правил). Применяемость CSS файла по отдельности к каждому
элементу на странице — это хорошо, но неудобно. Именно поэтому в «стиле»
подразумевают применение любых объявлений к любым частям веб-страницы. В «стилях»
вы можете объединить наборы правил с конкретными блоками объявлений.
Чтобы соединить наборы правил с блоками объявлений, каждому блоку должен
предшествовать селектор.
Парные селекторы объявления — это и есть набор правил CSS. Но здесь есть
некоторые сложности, например: часто определённому элементу в документе релевантны
сразу несколько селекторов. Для определения приоритета иерархичности используется
каскадный алгоритм. Именно он уточнит иерархию какого-либо свойства, если оно
упоминается с различными значениями.
О селекторах, комбинаторах и псевдоэлементах CSS:
Селектор устанавливает точное правило, которое будет использоваться для
конкретного элемента веб-страницы.
В стилях CSS распространено большое количество контейнеров: по атрибуту,
универсальный, по ID, по типу элемента, по классу. Также для работы с селекторами
88
предусмотрены комбинаторы и псевдоэлементы (используются для выбора того, что
отсутствует в HTML-коде). Что касается комбинаторов, то они упрощают выбор элементов.
Например, комбинатор adjacent sibling — позволяет выбирать последующие соседние
элементы, но только если у них имеется общий родитель.
Комбинатор comma (в качестве него используется знак запятой). Он позволяет
сгруппировать и выделить все идентичные узлы следующего соседнего элемента. Также
есть отдельные комбинаторы для всех соседних элементов, для потомков, дочерних
элементов.
Важно: при помощи селекторов вы не сможете выбрать родительский элемент с
контейнером внутри.
Разбираем пример CSS верстки:
Чтобы лучше усвоить всю информацию выше — предлагаем изучить реальный
пример файла стилей для сайта.
p {
font-family: Liberation Sans, helvetica, sans-serif;
}
h2 {
font-size: 22pt;
color: green;
background: white;
}
.note {
color: green;
background-color: white;
font-weight: bold;
}
p#paragraph1 {
padding-left: 12px;
}
a:hover {
text-decoration: none;
}
#news p {
color: green;
}
[type="button"] {
background-color: green;
}
Давайте посмотрим, что есть в этом коде и как его расшифровать.
Сразу в глаза бросается наличие семи CSS-правил с различающимися селекторами.
Рассмотрим их подряд сверху вниз, также, как они расписаны в этом коде.
1.
Правило для абзаца обозначено привычным элементом р. Шрифт по
умолчанию — Liberation Sans, но если он не может быть загружен, то будут использоваться
другие шрифты.
Если Liberation Sans будет недоступен, его заменит Helvetica.
89
2.
Правило для заголовка второго уровня обозначено элементом h2. Начертание
такого заголовка должно иметь зеленый цвет, а бэкграунд — белый цвет. Обратите
внимание, что указан весьма крупный шрифт (22 pt).
Это правило для всех H2-заголовков.
3.
Правило для одного или нескольких элементов, имеющих класс note.
Устанавливает зеленый цвет в качестве основного и белый в качестве фонового цвета.
Кроме того, это правило задаёт элементам полужирное начертание.
Настраиваем внешний вид элементам с классом note.
4.
Правило для конкретного элемента р (с идентификатором paragraph1).
Устанавливает для указанного элемента отступ в 12 px.
Настраиваем отступ для параграфа.
5.
Правило убирает подчеркивание по умолчанию во всех ссылках при
наведении курсора на такой элемент.
Убираем подчеркивание при наведении на ссылки.
90
6.
Правило для конкретных элементов p, расположенных внутри другого
компонента c идентификатором news.
Теперь этот элемент будет иметь зеленый цвет.
7.
Правило только для элементов, имеющих атрибут type со значением button.
Устанавливает зеленый цвет фона.
Поменяли цвет фона у кнопок на зеленый.
Методологии CSS:
Методологии CSS регулируют способы работы и написания кода. Они также
устанавливают то, как именно будет выглядеть итоговый код и по каким правилам он
должен писаться.
В разное время существовали несколько популярных методологий. Часть из них —
продолжает жить, другая часть — была забыта по разным причинам. Упоминать все
существующие когда-либо методологии — не имеет смысла. Ведь в конце 2022 — начале
2023 разработчики активно используют только пять из них:
BEM. Вся суть этой методологии сразу становится понятна, если знать, как
расшифровывается это название — модификатор блочных элементов. Посмотрите на этот
код:
Username
Password
Sign in
При помощи BEM мы формируем такие компоненты, которые можно задействовать
повторно. Вернёмся к примеру выше. Обратите внимание — класс loginform включает в
себя три компонента:
91
loginform__username (используется для ввода имени пользователя).
loginform__password (используется для ввода пароля пользователя).
loginform__btn (используется для того, чтобы пользователь мог повторно
отправить форму).
Systematic, она же систематическая. В этой методологии можно обнаружить
большую часть принципов, заложенных в популярных SUIT CSS, OOCSS, SMACSS и
конечно BEM. Systematic CSS — довольно интуитивная методология, которая является
хорошей альтернативой искусственно усложненным системам. Вот как может выглядеть
код CSS, согласно этой методологии, для вывода панели навигации и поисковой формы.
Пример кода по методологии Systematic.
Объектно-ориентированная, она же OOCSS. Хорошо продуманная методология,
которая отличается гибкостью и возможностью заменять некоторые компоненты. Нужно
просто привыкнуть к ней. Набор кода станет более логичным и прозрачным. Модульность
— ещё одна черта OOCSS. Пример:
.button {
box-sizing: border-box;
height: 60px;
width: 90%;
}
.grey-btn {
background: #EEE;
border: 2px solid #DDD;
box-shadow: rgba(0, 0, 0, 0.5) 2px 2px 4px;
color: #666;
Как видим, мы установили стиль кнопки при помощи двух классов (button используем
для показа структуры, а gret-btn — для настройки дизайна элемента).
HTML-файл, с учетом вышесказанного, будет выглядеть следующим образом:
Нажми здесь!
92
SMA CSS. Неплохая методология для CSS. Чтобы не объяснять словами, сразу
проведём пример кода, который хорошо иллюстрирует особенности этой методологии:
Atomizer-подход (назван в честь одноименной CSS-библиотеки). Вот несколько
маркеров этой методологии: имена базируются на внешнем поведении функции, а
одноцелевые классы — становятся основными строительными блоками. Но вместо
подробного описания, лучше посмотрите на пример ниже:
Primer
Мы определили цвет, задав значение в шестнадцатеричной системе. Примечательно,
как реализован opacity-канал — он сделан через применение одноименного параметра к
hex-цвету.
Резюмируя:
Ключевые различия между HTML и CSS:
HTML является основным языком разметки, который описывает содержание
и структуру веб-страниц. С другой стороны, CSS является расширением HTML, которое
изменяет дизайн и отображение веб-страниц.
HTML-файл может содержать код CSS, в то время как таблицы стилей CSS
никогда не могут содержать HTML-код.
HTML состоит из тегов, окружающих контент. В то время как CSS состоит
из селекторов, за которыми следует блок объявления.
Преимущества HTML:
Простой в использовании и имеющий свободный синтаксис (хотя, будучи
слишком гибким, не будет соблюдать стандарты).
Широко используется, устанавливается практически на каждом веб-сайте и
поддерживается каждым браузером.
Аналог синтаксиса XML, который все чаще используется для хранения
данных.
Это бесплатно, так как вам не нужно покупать программное обеспечение.
Легко учиться и писать код даже новичкам.
Преимущества CSS:
CSS экономит ваше время, написав CSS один раз и повторно используя один
и тот же лист на нескольких страницах.
Страницы требуют меньше времени для загрузки из-за меньшего количества
кода.
Простота в обслуживании, глобальные изменения просты в использовании.
CSS имеет лучшие стили для HTML и гораздо более широкий диапазон
атрибутов.
Обеспечение совместимости нескольких устройств.
Теперь атрибуты HTML осуждаются, и рекомендуется использовать CSS на
всех страницах HTML, чтобы сделать их совместимыми с будущими браузерами.
Поддержка автономного просмотра с помощью автономного кэша.
Скрипт обеспечивает постоянную независимость от платформы и может
поддерживать новейшие браузеры.
93
Недостатки HTML:
Поскольку это статический язык, он не может генерировать динамический вывод.
Предлагает ограниченные функции безопасности.
Недостатки CSS:
Фрагментация - CSS отображает разные размеры в каждом браузере. Программисты
должны рассмотреть и протестировать весь код в нескольких браузерах, прежде чем
запускать любой веб-сайт или мобильное приложение, чтобы не возникало проблем с
совместимостью.
HTML и CSS — два основных языка, обычно используемых для вебразработки. Разница между HTML и CSS заключается в том, что HTML — это язык
разметки, который используется для создания структуры веб-страницы, а CSS — это язык
стилей, который используется для того, чтобы сделать веб-страницы более
презентабельными.
-
SQL:
SQL (Structured Query Language, или язык структурированных запросов) — это
декларативный язык программирования (язык запросов), который используют для
создания, обработки и хранения данных в реляционных БД.
На чистом SQL нельзя написать программу — он предназначен только для
взаимодействия с базами данных: получения, добавления, изменения и удаления
информации в них, управления доступом и так далее.
Реляционная база данных – это набор данных с предопределенными связями
между ними. Эти данные организованны в виде набора таблиц, состоящих из столбцов и
строк. В таблицах хранится информация об объектах, представленных в базе данных. В
каждом столбце таблицы хранится определенный тип данных, в каждой ячейке – значение
атрибута. Каждая стока таблицы представляет собой набор связанных значений,
относящихся к одному объекту или сущности.
SELECT и FROM:
SELECT в запросе определяет, какие столбцы данных отобразить в результатах.
Кроме того, в SQL есть возможности отображать данные не из столбца таблицы. В примере
ниже показаны 3 столбца, взятые из таблицы студентов Student (через SELECT и FROM) и
один вычисляемый столбец. В базе данных хранятся ID (studentID), имя (FirstName) и
фамилия (LastName) студента. Мы можем объединить столбцы с именем и фамилией и
создать вычисляемое поле с полным именем (FullName).
SELECT studentID, FirstName, LastName, FirstName + ' ' + LastName AS FullName
FROM student;
Вывод:
94
CREATE TABLE:
Название CREATE TABLE говорит само за себя – оператор создает таблицу. Вы
можете задать название таблицы и настроить, какие столбцы будут присутствовать в
таблице.
CREATE TABLE table_name (column_1 datatype, column_2 datatype, column_3
datatype);
ALTER TABLE:
ALTER TABLE изменяет структуру таблицы. Вот так можно добавить столбец в базу
данных:
ALTER TABLE table_name ADD column_name datatype;
CHECK:
CHECK ограничивает диапазон значений, которые можно добавить в столбец.
Когда вы настраиваете ограничение CHECK для отдельного столбца, оператор
проверяет, что в этом столбце присутствуют строго определенные значения. Если же
CHECK настраивается для таблицы, то он может ограничивать значения в отдельных
столбцах на основании значений из других столбцов этой строки.
В следующем примере при создании таблицы Persons используется ограничение
CHECK для столбца «Возраст» (Age). Таким образом проверяется, что в таблицу не
попадают лица младше 18 лет.
CREATE TABLE Persons (ID int NOT NULL, LastName varchar (255) NOT NULL,
FirstName varchar (255), Age int, CHECK (Age>=18));
Следующий синтаксис используется для присвоения названия оператору CHECK и
настройки CHECK для нескольких столбцов:
CREATE TABLE Persons (ID int NOT NULL, LastName varchar (255) NOT NULL,
FirstName varchar (255), Age int, City varchar (255), CONSTRAINT CHK_Person CHECK
(Age>=18 AND City='Sandnes'));
WHERE (AND, OR, IN, BETWEEN и LIKE):
Оператор WHERE используется для ограничения количества возвращаемых строк.
Сначала, в качестве примере, мы покажем оператор SELECT и его результат без
оператора WHERE. Затем добавим оператор WHERE, в котором используются сразу 5 из
вышеуказанных квалификаторов.
SELECT studentID, FullName, sat_score, rcd_updated FROM student;
95
Теперь повторим запрос SELECT, но ограничим возвращаемые строки оператором
WHERE.
UPDATE:
Для обновления записи в таблице используется оператор UPDATE.
Условием WHERE можно уточнить, какие именно записи вы бы хотели обновить.
Вы можете обновлять по одному или нескольким столбцам сразу. Синтаксис выглядит так:
UPDATE table_name SET column1 = value1, column2 = value2, ... WHERE condition;
В примере ниже обновляется название записи (поле Name) с Id 4:
UPDATE Person SET Name = “Elton John” WHERE Id = 4;
Помимо этого, можно обновлять столбцы в таблице значениями из других таблиц.
Чтобы получить данные из нескольких таблиц, воспользуйтесь оператором JOIN.
Синтаксис выглядит так:
UPDATE table_name1 SET table_name1.column1 = table_name2.columnA
table_name1.column2 = table_name2.columnB FROM table_name1 JOIN table_name2 ON
table_name1.ForeignKey = table_name2.Key
В примере ниже мы обновляем поле «Менеджер» (Manager) для всех записей:
UPDATE Person SET Person.Manager = Department.Manager FROM Person JOIN
Department ON Person.DepartmentID = Department.ID
GROUP BY:
GROUP BY позволяет объединять строки и агрегировать данные.
Вот так выглядит синтаксис GROUP BY:
SELECT column_name, COUNT(*) FROM table_name GROUP BY column_name;
HAVING:
HAVING позволяет сортировать данные, которые собираются через GROUP BY.
Таким образом, пользователю показывается лишь ограниченный набор записей.
Вот так выглядит синтаксис HAVING:
SELECT column_name, COUNT(*) FROM table_name GROUP BY column_name
HAVING COUNT(*) > value;
AVG():
AVG, или среднее, вычисляет среднее значение числового столбца из набора строк,
которые возвращает оператор SQL.
Вот так выглядит синтаксис:
SELECT groupingField, AVG(num_field) FROM table1 GROUP BY groupingField
А вот пример этого оператора для таблицы Student:
SELECT studentID, FullName, AVG(sat_score) FROM student GROUP BY studentID,
FullName;
96
AS:
AS позволяет переименовать столбец или таблицу с помощью псевдонима.
SELECT user_only_num1 AS AgeOfServer, (user_only_num1 - warranty_period) AS
NonWarrantyPeriod FROM server_table
И вот так будет выглядеть результат.
STUDENT studentID, FullName, sat_score, recordUpdated FROM student WHERE
(studentID BETWEEN 1 AND 5 OR studentID = 8) AND sat_score NOT IN (1000, 1400);
Кроме того, через оператор AS вы можете задать название таблицы – так будет
проще обращаться к ней в JOIN.
SELECT ord.product, ord.ord_number, ord.price, cust.cust_name, cust.cust_number
FROM customer_table AS cust JOIN order_table AS ord ON cust.cust_number =
ord.cust_number
Результат выглядит так.
ORDER BY:
ORDER BY позволяет сортировать результирующий набор данных по одному или
нескольким элементам в разделе SELECT. Ниже дан пример сортировки студентов по
имени (FullName) в порядке убывания. Изначально используется стандартная сортировка
по возрастанию (ASC), поэтому для сортировки в обратном порядке мы применяем DESC.
SELECT studentID, FullName, sat_score FROM student ORDER BY FullName DESC;
97
COUNT:
COUNT вычисляет количество строк и возвращает результирующее значение в
столбце.
Ниже приводятся возможные сценарии использования COUNT:
Подсчет всех строк в таблице (не требуется Group by)
Подсчет общего числа подмножеств данных (в операторе обязательно
прописывается Group By)
Этот оператор SQL выводит количество всех строк. Кроме того, что вы можете
настроить название результирующего столбца COUNT с помощью AS.
SELECT count(*) AS studentCount FROM student;
DELETE:
DELETE используется для удаления записи из таблицы.
Будьте внимательны! Вы можете удалить несколько записей в таблице, либо сразу
все. С помощью условия WHERE вы указываете, какие записи необходимо удалить.
Синтаксис выглядит так:
DELETE FROM table_name WHERE condition;
Вот так выглядит удаление из таблицы Person записи с Id 3:
DELETE FROM Person WHERE Id = 3;
INNER JOIN:
JOIN, или внутреннее соединение, выбирает записи, соответствующие значениям в
двух таблицах.
SELECT * FROM A x JOIN B y ON y.aId = x.Id
LEFT JOIN:
LEFT JOIN возвращает все строки из левой таблицы и соответствующие им строки
из правой таблицы. Строки из левой таблицы возвращаются даже при пустых значениях в
правой таблице. Если для строк из левой таблицы нет соответствия в правой, то в значениях
последней будет стоять null.
SELECT * FROM A x LEFT JOIN B y ON y.aId = x.Id
RIGHT JOIN:
RIGHT JOIN возвращает все строки из правой таблицы и соответствующие им
строки из левой. В отличие от левого соединения, здесь возвращаются все строки из правой
таблицы, даже если им ничего не соответствует в левой. В таком случае, в значениях
столбцов из левой таблицы будет стоять null.
SELECT * FROM A x RIGHT JOIN B y ON y.aId = x.Id
FULL OUTER JOIN:
FULL OUTER JOIN возвращает все строки, соответствующие условиям в любой из
таблиц. Если в левой таблице есть строки, которым ничего не соответствует в правой, то
они все равно отобразятся в результирующих значениях. То же самое распространяется и
на строки из правой таблицы без соответствующих значений в левой.
SELECT Customers.CustomerName, Orders.OrderID FROM Customers FULL OUTER
JOIN
Orders
ON
Customers.CustomerID=Orders.CustomerID
ORDER
BY
Customers.CustomerName
INSERT:
INSERT используется для добавления данных в таблицу.
INSERT INTO table_name (column_1, column_2, column_3) VALUES (value_1,
'value_2', value_3);
LIKE:
LIKE используется в связке с WHERE или HAVING (в составе оператора GROUP
BY) и ограничивает выбранные строки по элементам, если в столбце содержится
определенный шаблон символов.
Этот SQL запрос выбирает студентов, чье значение в FullName начинается с
«Monique» или заканчивается с «Greene».
98
SELECT studentID, FullName, sat_score, rcd_updated FROM student WHERE FullName
LIKE 'Monique%' OR FullName LIKE '%Greene';
Перед LIKE вы можете добавить NOT, и тогда строки, соответствующие условию,
будут исключаться, а не добавляться. Этот SQL исключает записи, у которых в столбце
FULL NAME содержится «cer Pau» и «Ted».
SELECT studentID, FullName, sat_score, rcd_updated FROM student WHERE FullName
NOT LIKE '%cer Pau%' AND FullName NOT LIKE '%"Ted"%';
