Веб-сервис – это программа, которая организовывает взаимодействие между сайтами. Веб-ориентированная технология, которая позволяет веб-сайтам общаться между собой, используя такие форматы передачи данных, как XML и JSON и посредством протокола SOAP и архитектурного стиля REST.
API — это Application Programming Interface, или программный интерфейс приложения, с помощью которого одна программа может взаимодействовать с другой. API определяет ф-ть, которую предоставляет программа,
JSON (англ. JavaScript Object Notation — текстовый формат обмена данными, основанный на JavaScript. Как и многие другие текстовые форматы, JSON легко читается людьми.
Несмотря на происхождение от JavaScript (точнее, от подмножества языка стандарта ECMA-262 1999 года), формат считается независимым от языка и может использоваться практически с любым языком программирования. Для многих языков существует готовый код для создания и обработки данных в формате JSON.
Синтаксис
В качестве значений в JSON могут быть использованы:
• запись — это неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки «{ }». Ключ описывается строкой, между ним и значением стоит символ «:». Пары ключ-значение отделяются друг от друга запятыми.
• массив (одномерный) — это упорядоченное множество значений. Массив заключается в квадратные скобки «
• число (целое или вещественное).
• литералы true (логическое значение «истина»), false (логическое значение «ложь») и null.
• строка — это упорядоченное множество из нуля или более символов юникода, заключённое в двойные кавычки. Символы могут быть указаны с использованием escape-последовательностей, начинающихся с обратной косой черты «\» (поддерживаются варианты \", \\, \/, \t, \n, \r, \f и \b), или записаны шестнадцатеричным кодом в кодировке Unicode в виде \uFFFF.
Следующий пример показывает JSON-представление данных об объекте, описывающем человека. В данных присутствуют строковые поля имени и фамилии, информация об адресе и массив, содержащий список телефонов. Как видно из примера, значение может представлять собой вложенную структуру.
{
"firstName": "Иван",
"lastName": "Иванов",
"address": {
"streetAddress": "Московское ш., 101, кв.101",
"city": "Ленинград",
"postalCode": 101101
},
"phoneNumbers": [
"812 123-1234",
"916 123-4567"
]
}
JSON (англ. JavaScript Object Notation) — простой формат обмена данными, основанный на языке программирования JavaScript. Использует человекочитаемый текст для передачи объектов данных.
Синтаксические правила JSON
Данные указываются в парах имя / значение, разделяемые двоеточием «firstName»:«Lev»
Данные разделяются запятыми «firstName»:«Anna», «lastName»:
«Karenina»
Фигурные скобки удерживают объекты {«firstName»:«Lev»,«lastName»:«Tolstoy»},
Квадратные скобки содержат массивы
Преимущества JSON
Html язык разметки, т.е. как блоки на странице располагаются, изображения и др элементы, а xml/json используются для передачи данных по протоколу, чтобы была связь между клиентом и сервером. Это каркас, в который мы вписываем информацию. Но она структурирована. Это форматы передачи данных, мы вписываем данные, сервер их считывает, поскольку они структурированы, правильно описаны.
Сейчас я говорю про массивы данных, про сложную иерархическую структуру.
Для передачи информации как в интеграции, так и для сайтов используются определенный формат данных.
JSON и XML используются для получения и отправки данных с веб-сервера.
Преимущества json - Меньше слов больше дела
XML требует открытия и закрытия тегов, а JSON использует пары имя / значение, четко обозначенные «{«и»}» для объектов, «[«и»]» для массивов, «,» (запятую) для разделения пары и «:»(двоеточие) для отделения имени от значения.
При одинаковом объеме информации JSON почти всегда значительно меньше, что приводит к более быстрой передаче и обработке.
Близость к javascript
JSON является подмножеством JavaScript, поэтому код для его анализа и упаковки вполне естественно вписывается в код JavaScript.
XML
XML — язык разметки, который определяет набор правил для кодирования документов в формате, который читается человеком и читается машиной. Но чем больше информации (вложений, комментариев, вариантов тегов и т.д.) в xml, тем сложнее ее читать человеку.
XML (eXtensible Markup Language) — расширяемый язык разметки. Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в документах: разработчик волен создать разметку в соответствии с потребностями к конкретной области, будучи ограниченным лишь синтаксическими правилами языка.
XML является подмножеством SGML.
XML хранит данные в текстовом формате. Это обеспечивает независимый от программного и аппаратного обеспечения способ хранения, транспортировки и обмена данными. XML также облегчает расширение или обновление до новых операционных систем, новых приложений или новых браузеров без потери данных.
Синтаксис XML Deep Purple 1968 Machine Head 1972 Рок
Stormbringer 1974 Рок
Весь XML документ должен иметь корневой элемент.
Все теги должны быть закрыты (либо самозакрывающийся тег).
Все теги должны быть правильно вложены.
Имена тегов чувствительны к регистру.
Имена тегов не могут содержать пробелы.
Значения атрибута должны появляться в кавычках («»).
Атрибуты не могут иметь вложения (в отличие от тегов).
Пробел сохраняется.
Преимущества:
Поддержка метаданных
Одним из самых больших преимуществ XML является то, что мы можем помещать метаданные в теги в форме атрибутов. В JSON атрибуты будут добавлены как другие поля-члены в представлении данных, которые НЕ могут быть желательны.
Визуализация браузера
Большинство браузеров отображают XML в удобочитаемой и организованной форме. Древовидная структура XML в браузере позволяет пользователям естественным образом сворачивать отдельные элементы дерева. Эта функция будет особенно полезна при отладке.
Поддержка смешанного контента
Хорошим вариантом использования XML является возможность передачи смешанного контента в пределах одной и той же полезной нагрузки данных. Этот смешанный контент четко различается по разным тегам.
WSDL – правила, принципы, чтобы веб-сервер знал, что мы посылаем то, что надо, пришла ли ему правильная xml, подходит ли формат, какая информация и т.д. Когда мы посылаем серверу xml, он приходит к wsdl и сравнивает, что пришло. Например, мы прислали в xml integer, а должен быть текстовый формат, и сервер не примет xml, пока мы не исправим цифру на букву. ПО факту это тоже xml-ка, которая содержит этот свод правил.
XSD – чтобы построить xml, нам нужны эти файлы. В этой схеме описан тип данных, количество. Это структура со всеми возможными вариантами строк. Мы ее заполняем и можем построить грамотно xml.
Разница между XML и JSON заключается в том, что XML - это язык мета-языка/разметки, а JSON - это легкий обмен данными. Таким образом, синтаксис XML разработан специально, чтобы не иметь внутренней семантики. Конкретные имена элементов ничего не значат, пока конкретное приложение обработки не обработает их определенным образом. Напротив, синтаксис JSON имеет особую семантику, встроенную в вещи между {} - это объект, вещи между [] - это массив и т.д.
Soap – xml
SOAP и REST – программный интерфейс, чтобы не мы отсылали сами запросы, а программы сами общались, для координации запросов, чтобы программы могли коммуницировать.
SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.
Структура SOAP-сообщения
Envelope — корневой элемент, который определяет сообщение и пространство имен, использованное в документе.
Header — содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации.
Body — содержит сообщение, которым обмениваются приложения.
Fault — необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений.
Пример
Пример SOAP-запроса на сервер интернет-магазина:
12345
Недостатки
Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки. В системах, где скорость важна, чаще используется пересылка XML-документов через HTTP напрямую, где параметры запроса передаются как обычные HTTP-параметры.
Rest – все, ибо это всего лишь стиль.
REST (Representational State Transfer — «передача состояния представления») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине.
В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса.
Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».
В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, JSON и, реже, XML.
Отсутствие дополнительных внутренних прослоек означает передачу данных в том же виде, что и сами данные. Т.е. мы не заворачиваем данные в XML, как это делает SOAP. Просто отдаем сами данные. Каждая единица информации однозначно определяется URL – это значит, что URL по сути является первичным ключом для единицы данных. Т.е. например третья книга с книжной полки будет иметь вид /book/3, а 35 страница в этой книге — /book/3/page/35. Отсюда и получается строго заданный формат. Причем совершенно не имеет значения, в каком формате находятся данные по адресу /book/3/page/35 – это может быть и HTML, и отсканированная копия в виде jpeg-файла, и документ Microsoft Word. Как происходит управление информацией сервиса – это целиком и полностью основывается на протоколе передачи данных. Наиболее распространенный протокол конечно же HTTP. Так вот, для HTTP действие над данными задается с помощью методов: GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить).
Преимущества
Филдинг указывал, что приложения, не соответствующие приведённым условиям, не могут называться REST-приложениями. Если же все условия соблюдены, то, по его мнению, приложение получит следующие преимущества:
• Надёжность (за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна);
• Производительность (за счёт использования кэша);
• Масштабируемость;
• Прозрачность системы взаимодействия (особенно необходимая для приложений обслуживания сети);
• Простота интерфейсов;
• Портативность компонентов;
• Лёгкость внесения изменений;
• Способность эволюционировать
Логи (лог-файлы) — это файлы, содержащие системную информацию работы сервера или компьютера, в которые заносятся определенные действия пользователя или программы. Иногда также употребляется русскоязычный аналог понятия — журнал.
Их предназначение — протоколирование операций, выполняемых на машине, для дальнейшего анализа администратором. Регулярный просмотр журналов позволит определить ошибки в работе системы в целом, конкретного сервиса или сайта (особенно скрытые ошибки, которые не выводятся при просмотре в браузере), диагностировать злонамеренную активность, собрать статистику посещений сайта.
Виды логов
Поскольку основное программное обеспечение, установленное на сервере, чаще всего производит запись в системные журналы, то для каждой из таких программ будет свой журнал. В частности, можно выделить такие наиболее распространенные логи:
• основной файл лога (общая информация — данные о действиях с ядром системы, работе FTP-сервисов, DNS-сервера, файервола);
• лог загрузки системы (помогает выполнить отладку системы в случае, если она не загружается, сохраняет основные системные события (например, сбои оборудования));
• логи веб-сервера (данные об обращениях к серверу, информация об ошибках веб-сервера);
• логи сервера баз данных (запросы к базам данных, ошибки сервера);
• логи хостинговой панели, через которую осуществляется управление сайтом на хостинге (попытки входа в панель, обновления лицензии и панели, статистика использования ресурсов сервера);
• логи почтового сервера (записи о всех отправленных и доставленных сообщениях, ошибки почтового сервера, причины отклонения писем);
• логи планировщика задач — cron (протоколирование выполнения задач, ошибок при запуске крона).
Расположение
Месторасположение журналов зависит от программного обеспечения, реализации настроек по умолчанию или пути, заданного администратором. То есть, в зависимости от того, что вы используете (возможно, это виртуальный хостинг, доступный VPS-план или аренда серверов в Европе или США), доступность и расположение логов будут значительно отличаться. Как правило, большая часть логов сервера хранится по пути /var/log/, но некоторые сервисы могут хранить логи в других каталогах. Для удобства всегда можно задать подходящий путь в конфигурационных файлах нужного программного обеспечения. Например, на сервере можно настроить демон syslog/rsyslog, который будет упорядочивать поступающие в него записи о работе сервисов и сохранять их в заданные пользователем файлы логов.
Логи, или журнал действий пользователя, помогает тестировщикам понять, что означает ошибка, а также - откуда она взялась.
Что нужно логировать
Разумеется, логировать все подряд не стоит. Иногда это и не нужно, и даже опасно. Например, если залогировать чьи-то личные данные и это каким-то образом всплывет на поверхность, будут реальные проблемы, особенно на проектах, ориентированных на Запад. Но есть и то, что логировать обязательно:
1. Начало/конец работы приложения. Нужно знать, что приложение действительно запустилось, как мы и ожидали, и завершилось так же ожидаемо.
2. Вопросы безопасности. Здесь хорошо бы логировать попытки подбора пароля, логирование входа важных юзеров и т.д.
3. Некоторые состояния приложения. Например, переход из одного состояния в другое в бизнес процессе.
4. Некоторая информация для дебага, с соответственным уровнем логирования.
5. Некоторые SQL скрипты. Есть реальные случаи, когда это нужно. Опять-таки, умелым образом регулируя уровни, можно добиться отличных результатов.
6. Выполняемые нити (Thread) могут быть логированы в случаях с проверкой корректной работы.
Главное отличие между тестированием и отладкой является то, что тестирование - это процесс обнаружения дефектов ПО, а отладка - это процесс устранения выявленных дефектов.
Техники тест-дизайна
Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования. Попросту говоря, задача тест сводится к тому, чтобы используя различные стратегии и техники тест дизайна, создать набор тестовых случаев, обеспечивающий оптимальную проверку тестируемого приложения.
1. Тестирование Классами Эквивалентности (Equivalence Class Testing).
Тестовые данные разбиваются на определенные классы допустимых значений. В рамках каждого класса выполнение теста с любым значением тестовых данных приводит к эквивалентному результату. После определения классов необходимо выполнить хотя бы один тест в каждом классе.
2. Тестирование Граничных Значений (Boundary Value Testing).
Эта техника основана на том факте, что одним из самых слабых мест любого программного продукта является область граничных значений. Для начала выбираются диапазоны значений – как правило, это классы эквивалентности. Затем определяются границы диапазонов. На каждую из границ создается 3 тест-кейса: первый проверяет значение границы, второй – значение ниже границы, третий – значение выше границы.
3. Таблица Принятия Решений (Decision Table Testing).
Таблицы решений – это удобный инструмент для фиксирования требований и описания функциональности приложения. Таблицами очень удобно описывать бизнес-логику приложения, и они могут служить отличной основой для создания тест-кейсов. Способ хорош, когда таблица не слишком объемная и сложная.
Таблицы решений описывают логику приложения, основываясь на условиях системы, характеризующих ее состояния. Каждая таблица должна описывать одно состояние системы.
Она также известна как таблица причинно-следственных связей.
Таблица решений, как правило, имеет четыре составляющих:
Условия – список возможных условий.
Варианты выполнения действий – это комбинация из списка условий, выполненных или невыполненных.
Действия – это список всевозможных действий.
Необходимость действий – указание нужно или не нужно выполнять соответствующее действие для каждой из комбинаций условий.
Преимущества применения таблицы решений при тестировании программного обеспечения:
1. Даже самая сложная бизнес-логика, используя данный метод, может быть легко преобразована в тестовые сценарии и случаи.
2. Итеративность работы. Таблица, созданная на первом этапе, используется в качестве входной таблицы для всех последующих. Итерация выполняется только в том случае, если исходные данные не являются удовлетворительными.
3. Простая и понятная техника. Каждый может использовать этот метод для разработки тестовых сценариев и случаев.
4. Обеспечение полного охвата тестовых случаев, что существенно помогает сократить объем работы.
5. Гарантия рассмотрения всех возможных комбинаций условий и значений.
6. Предоставление более компактной документации.
7. Легкое изменение данных.
Недостатки таблиц решений при тестировании программного обеспечения.
1. Трудность в масштабировании. Нужно «разделять» большие таблицы на более мелкие, чтобы устранить избыточность.
2. Увеличение количества входных данных делает таблицу более сложной.
«Decision Table» всегда состоит из «Условий» («Conditions») и «Действий» («Actions»), информация о которых берется из требований.
Для чего нужна «Decision Table»? для удобного составления тест-кейсов. И более того: эта таблица помогает определить минимальное количество тестов, покрывающих все возможные варианты комбинаций исходных условий.
Для примера рассмотрим следующие требования. Пароль действителен только тогда, когда он состоит как минимум из 12 символов и содержит буквы и цифры одновременно. Пароль не должен быть похож на два предыдущих. Столбец должен состоять из условий выполнения требований и связанных с ними действий. В нашем примере в требованиях указаны три условия:
Пароль должен состоять как минимум из 12 символов.
Пароль должен содержать и буквы, и цифры.
Пароль не должен совпадать с предыдущим.
И одно действие — результат проверки требований:
При соблюдении вышеперечисленных условий, пароль будет действительным.
4. Тестирование Состояний и Переходов (State-Transition Testing).
Система переходит в то или иное состояние в зависимости от того, какие операции над нею выполняются.
НЕ подходит для графич.интерфейса, а только для объектов. Напр, рецепт на сайте. Если это GUI, то нет объекта (страница сайта – не объект, ибо она постоянно меняется – то одна страница, то другая).
Кроме действий, которые влияют на объект и изменяют его состояние, есть еще действия, которые влияют на объект, но не изменяют его состояние. Например, поворот или перемещение здания. Такое действие затрагивает сам объект, но не влияет на его состояние. Их также необходимо определить и отобразить на нашей диаграмме.
Далее необходимо перенести нашу модель в таблицу и составить из нее чек-лист проверок.
5. Метод Парного Тестирования (Pairwise testing). (Пикт)
Метод парного тестирования основан на следующей идее: подавляющее большинство багов выявляется тестом, проверяющим либо один параметр, либо сочетание двух. Ошибки, причиной которых явились комбинации трех и более параметров, как правило, значительно менее критичны.
• Используя метод парного тестирования, мы не тестируем все возможные сочетания входных параметров, а составляем тестовые наборы так, чтобы каждое значение параметра хотя бы один раз сочеталось с каждым значением остальных тестируемых параметров. Таким образом, метод существенно сокращает количество тестов, а значит, и время тестирования.
• Но изюминка метода не в том, чтобы перебрать все возможные пары параметров, а в том, чтобы подобрать пары, обеспечивающие максимально эффективную проверку при минимальном количестве выполняемых тестов. С этой задачей помогают справиться математические методы, называемые ортогональными таблицами. Также существует ряд инструментов, которые помогают автоматизировать этот процесс (например, AllPairs).
7. Сценарий использования (Use Case Testing).
Use Case описывает сценарий взаимодействия двух и более участников (как правило – пользователя и системы). Пользователем может выступать как человек, так и другая система. Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (тест-кейсов), так как они описывают, в каком контексте должно производиться каждое действие пользователя. Use Case, по умолчанию, являются тестируемыми требованиями, так как в них всегда указана цель, которой нужно достигнуть, и шаги, которые надо для этого воспроизвести. Хотя бы один тест-кейс должен проверять основной сценарий и хотя бы по одному кейсу должно приходится на альтернативные сценарии. НАПРИМЕР: авторизация пользователя через гугл-аккаунт.
Верификация - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. (требования реализованы)
Валидация - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. Верификация и валидация являются одними из техник тест дизайна. (реализованные требования соответствуют желаниям заказчика)
