1. Инициация (идея). Приходит от заказчика
2. Анализ и сбор требований. Аналитики общаются с заказчиком.
3. Дизайн (Design). UX/AX дизайнеры
4. Разработка (Development). Разработчики пишут
5. Тестирование (Testing)
6. Эксплуатация

Тестировщик участвует на всех этапах.
На этапе сбора требований тестирует требования нет ли противоречий?
На этапе дизайна тестирует удобство использования (usability).
На этапах разработки и тестирования составляет отчет о дефектах и отправляет их девелоперу. После фиксинга опять тестирует.

Тестирование - процесс выявления несоответствия между фактическими и ожидаемыми (запланированными) результатами качества функционирования системы. Выявление дефектов.

Факт (ФР) =/= План (ОР) - это дефект

Цели тестировщика:

• проверить программу на соответствие требованиям
• дать оценку качества продукта
• проинформировать команду о качестве
• сделать предложения по улучшению качества

Активности:

• анализ требований
• разработка тестовой документации
• создание среды тестирования
• выполнение тестов
• документирование результатов тестирования
• коммуникации

1. New Feature Test (новая функциональность) Smoke, CPT, ET

• Smoke. Минимальный набор тестов на явные ошибки. Проводится программистом до передачи тестировщику. Выполняется каждый раз когда появляется новый билд (билд - промежуточная версия продукта). Идея этого вида тестирования заключается в том, что бы выявить серьезные проблемы как можно раньше. Проверяются критически важные функции (Application Under Test)
• Critical Path Testing (критический путь). Основной тип тестирования типичных задач. Может быть позитивным и негативным.
• Extended Test (расширенный тест). Проверка с учетом возможности нестандартного сценария эксплуатации объекта. Проводится при наличии временных и др. ресурсов

2. Regression Testing (регрессионное тестирование). Тестирование ранее проверенной функциональности с целью удостовериться, что изменение в коде не повлияло на качество функционирования объекта тестирования.

• обязательно проводится в каждом бильде
• проверяются исправленные баги
• проверяются только те участки, которые соприкасаются с изменениями
• рекомендуется проверять по несколько раз
• рекомендуется автоматизировать

3. Re-test. Проверка результата работы над дефектом после пофикшеного бага.

1. Unit test (компонентное, модульное тестирование). Тестируются отдельные модули

2. Интеграционное. Тестируется взаимодействие модулей и взаимодействие с интерфейсами:

• API (Application programming interface) - интерфейс программирования приложений
• CLI (Command line interface) - интерфейс командной строки
• GUI (graphical user interface) - графический интерфейс пользователя

3. Системное. Полная проверка объекта

4. Приемочное. На этапе сдачи в эксплуатацию, перед релизом.

• Пользовательское (UAT User Acceptance Testing) выполняет группа пользователей
• Эксплуатационное

- Альфа. На стороне разработчика
- Бетта. На стороне без разработчика

• На соответствие контракту и другим нормативным актам (ГОСТ и пр.)

Основные виды тестовой документации

Основные понятия

Определение: процесс проектирования и создания тест-кейсов (тестовых случаев)
Цель: обнаружение ошибок при оптимальном количестве тестов и привлеченных ресурсов
Основные техники:

• Эквивалентное разбиение (разбивка тестовых данных на классы допустимых значений). В рамках каждого класса выполнение теста с любым значением тестовых данных приводит к эквивалентному результату. После определения классов необходимо выполнить хотя бы один тест в каждом классе.
• Анализ граничных значений. Выбираются диапазоны значений – как правило, это классы эквивалентности. Затем определяются границы диапазонов. На каждую из границ создается 3 тест-кейса: первый проверяет значение границы, второй – значение ниже границы, третий – значение выше границы.

Основные понятия

Основные понятия

Основные понятия

Клиент-сервисная архитектура, поставщики и заказчики (клиенты) услуг.
2-х уровневая (клиент - сервер)
3-х уровневая (клиент - сервер - сервер БД)

Тонкий клиент (все вычисления на сервере)
Толстый клиент (все вычисления на компьютере клиента)

Если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.

• Веб- сайт - (web - «паутина, сеть» и site — «место») одна или несколько логически связанных между собой веб-страниц
• Веб-приложение - это прикладное программное обеспечение, которое работает на веб-сервере, в отличие от компьютерных программ, которые запускаются локально в операционной системе (ОС) устройства. Доступ к веб - приложениям осуществляется пользователем через веб - браузер с активным сетевым подключением.
• Веб-сервис - это реализация обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.

Взаимодействие построено на протоколах

Веб-сервис (англ. web service) программная система, обладающая заданным интерфейсом, идентифицируемая уникальным веб-адресом (URL адресом).
Обеспечивает возможностью взаимодействия между программами через сеть по Протоколу передачи и обмена данными.

Характеристики веб-сервиса:

• интерфейс веб-сервиса (≃ интерфейс компонента): определяемые операции,
• типы входных и выходных данных;
• формат спецификации интерфейса: на основе формального представления (языка спецификации) или неформального описания;
• используемый протокол передачи данных (HTTP, UDP, ...);
• формат представления данных: на основе XML, JSON, простого текста, ...

На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:

• SOAP (Simple Object Access Protocol) — по сути это тройка стандартов SOAP/WSDL/UDDI
• REST (Representational State Transfer)
• XML-RPC (XML Remote Procedure Call)

SOAP более применим в сложных архитектурах взаимодействия.
Если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.

Модель OSI в нынешнее время служит только в качестве обучения ролям каждого уровня.
Работают же сети по стеку протоколов TCP/IP.
Хоть TCP/IP состоит из 4 уровней, он вполне реализует все функциональные возможности, реализуемые в модели OSI. Ниже на картинке приведены сравнения уровней и их ролей.

Протоколы прикладного уровня обеспечивают взаимодействие между человеком и сетью. Этих протоколов огромное количество, и выполняют они совершенно различные роли. Примеры часто используемых протоколов в сети: HTTP, DNS, DHCP, SMTP и POP3, Telnet, SSH, FTP, TFTP.

Протоколы прикладного уровня обеспечивают взаимодействие между человеком и сетью. Протоколов огромное количество, и выполняют они совершенно различные роли. Часто используемые протоколы в сети: HTTP, DNS, DHCP, SMTP и POP3, Telnet, SSH, FTP, TFTP.

HTTP (HyperText Transfer Protocol ) — протокол передачи данных прикладного уровня в виде гипертекстовых документов в формате HTML.
HTTP предполагает использование клиент-серверной структуры передачи данных.
Клиентское приложение формирует запрос (Request) и отправляет его на сервер, после чего серверное программное обеспечение обрабатывает данный запрос, формирует ответ (Response) и передаёт его обратно клиенту.
Сам по себе протокол HTTP не предполагает использование шифрования для передачи информации. Тем не менее, для HTTP есть распространённое расширение, которое реализует упаковку передаваемых данных в криптографический протокол SSL или TLS.

Название этого расширения - HTTPS (HyperText Transfer Protocol Secure).

HTTP запросы - это сообщения, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера. Их стартовая строка состоит из трёх элементов:

1. Метод HTTP, глагол (например, GET, PUT или POST) или существительное (например, HEAD или OPTIONS), описывающие требуемое действие. Например, GET указывает, что нужно доставить некоторый ресурс, а POST означает отправку данных на сервер (для создания или модификации ресурса, или генерации возвращаемого документа).
2. Цель запроса, обычно URL, или абсолютный путь протокола, порт и домен обычно характеризуются контекстом запроса.
3. Версия HTTP, определяющая структуру оставшегося сообщения, указывая, какую версию предполагается использовать для ответа.

Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:

1. Версию протокола, обычно HTTP/1.1.
2. Код состояния (status code), показывающая, был ли запрос успешным.

• 100 - информация
• 200 - ОК
• 300 (301 - сервер вернул информацию, 304 - информация в кэше)
• 400 - ошибки
• 500 - фатальная ошибка, сервер не отвечает

3. Пояснение (status text). Краткое текстовое описание кода состояния, помогающее пользователю понять сообщение HTTP.

Версии протоколов HTPP/1.1 и HTTP/2

Сообщения HTTP/1.x имеют несколько недостатков в отношении производительности:

• Заголовки не сжимаются.
• Заголовки, которые зачастую практически совпадают у идущих подряд сообщений, приходится передавать по отдельности, последовательно.

HTTP/2 переходит на новый уровень: он делит сообщения HTTP/1.x на фреймы, которые внедряются в поток. Фреймы данных из заголовков отделены друг от друга, что позволяет сжимать заголовки. Несколько потоков можно объединять друг с другом - такой процесс называется мультиплексированием - что позволяет более эффективно использовать TCP-соединения.
Для реализации фреймов HTTP веб-разработчикам не требуется вносить изменения в имеющиеся APIs; если HTTP/2 доступен и на сервере, и на клиенте, он включается и используется.

URL обозначает Uniform Resource Locator.
URL это адрес, который выдан уникальному ресурсу в интернете. В теории, каждый корректный URL ведёт на уникальный ресурс. Такими ресурсами могут быть HTML-страница, CSS-файл, изображение и т.д. На практике, существуют некоторые исключения, когда, например, URL ведёт на ресурс, который больше не существует или который был перемещён.

Стоит представлять URL как обычный почтовый адрес:

• протокол обозначает почтовый транспорт, который вы собираетесь использовать,
• доменное имя - это город,
• порт - это почтовый индекс;
• адрес - это номер дома;
• параметры представляют собой дополнительную информацию, как, например, номер квартиры;
• якорь представляет собой конкретного получателя, которому вы адресуете своё письмо.