Ease of use - Gibiscus/wiki Wiki
COTT — идеальный инструмент тестирования для менее опытных тестировщиков, которые хотят перейти от ручного к автоматизированному тестированию. Они могут начать создавать автоматизированные тесты в течение нескольких дней без знания языка программирования. Для написания тестового сценария, QA специалисту достаточно ознакомится со списком тегов (команд) - которые находятся под капотом фреймворка.
Для составления тестового сценария мы выбрали XML
Язык не зависит от операционной системы и среды обработки. XML служит для представления неких данных в виде структуры, которую мы продолжаем разрабатывать для вас, чтобы QA - специалисты писали скрипты которые будут понятны абсолютно всем членам команды.
Плюсы:
- Легкость чтения, подача в простой форме;
- Стандартный вид кодировки;
- Возможность обмена данными между любыми платформами;
Структура каждого < тега > - имеет однообразный стандарт написания, за счет которого и визуализируется восприятие тестового сценария. Также мы добавили обязательное поле описания к каждому шагу теста, чтобы поощрять не только разработку, но и поддержку теста.
Structure COTT
Для начала работы с COOT вам необходимо создать директорию с ресурсами вашего проекта. В которой будут находится основные папки вашей директории и global-config - file с глобальными настройками конфигураций вашего проекта. Так как COOT - требует наличие обязательных папок которые должны лежать в структуре ваших ресурсов. В данных папках будут лежать данные для тестирования, и сами тестовые сценарии.
Folder structure
'Обязательные папки':
folderName | Extension |
---|---|
credentials | JSON |
csv | CSV |
excel | EXCEL |
javascript | JS |
locators | XML |
component | XML |
pages | XML |
patches | SQL |
report | Reporting Toll |
scenarios | XML |
shell | sh |
Variations | CSV |
'Purpose' ⤵️
-
credentials
- Folder for storing system user data for authorization within the test scenario
{
"username": "Test",
"password": "[email protected]"
}
-
javascript
- Folder to create and store javascript
var greeating = 'Hello, World';
console.log(greeating)
-
locators
- Folder where element locators are stored (For interaction with UI) -
Внутри папки locators должны быть такие папки как:
-
component
- Папка для хранения локаторов которые относятся к footer, header элементам страниц. (Рекомендуется разделять данные локаторы для структурированности и удобства использования) -
pages
- Папка в которой храняться локаторы конкретной страницы -
(В xml файл с локаторами, который находится в папке pages - имеется возможность вызывать нужный компонент footer и header с помощью тега:
<include>
<locator locatorId="registerButton">
<id>registerLink</id>
</locator>
Таким образом мы сможем передавать в сценарий локаторы которые находятся в папке component через xml файл pages
patches
- Folder to store data for testing( датасеты в формате SQL)
INSERT INTO t_role (id, name, description, enabled)
VALUES (1, 'ADMIN', 'Owner company', true),
(2, 'USER', 'Admin company', true),
(3, 'SUPERUSER', 'Lawyer company', true);
report
- Folder where the test pass report will be generated
scenarios
- Folder for creating and storing test scripts
<scenario xmlns="http://www.knubisoft.com/e2e/testing/model/scenario">
<overview>
<description>Demonstration of the work of the 'assert' tag</description>
<name>Assert</name>
</overview>
<tags>
<tag>UI</tag>
</tags>
shell
- Folder for storing Shell - scripts
var="\"The content after crated a file.\""
echo "{ \"content\":" " $var }" > ./shell-1.json
rm -f ./shell-1.json
Variations
- Folder in which a data set is created and stored for interacting with the UI
Global config file structure
global-config.xml
- file в котором будут находится основные настройки конфигураций вашего проекта.
Вы имеете возможность создавать несколько файлов конфигураций и разделять environment тестирования
Например:
global-config-local.xml
global-config-dev.xml
global.config.jenkins.xml
global-config.xml - XSD схема которого имеет опциональный набор тегов из коробки, что максимально упрощает процесс настройки конфигураций.
Набор основных тегов для конфигурации global.config.xml:
<stopScenarioOnFailure>
<runScenariosByTag>
<ui>
<integrations>
<stopScenarioOnFailure>
- тег который контролирует прохождение ваших тестовых сценариев.
<stopScenarioOnFailure>false</stopScenarioOnFailure>
Имеет флаг:
true
( при запуске нескольких или одного тестового сценария, и обнаружении exception в одном из, - стартер будет остановлен, с выводом ошибки, в конкретном сценарии, и на конкретном шаге )
false
( при запуске нескольких или одного тестового сценария, и обнаружении exception, стартер не будет остановлен, все сценарии и шаги будут выполняться до завершения работы стартера, с дальнейшим выводом exception для всех сценариев которые были пройдены, и получили exception.
<runScenariosByTag>
- позволяет иметь возможность реализовывать глобальный запуск тестовых сценариев по определенному тегу. Предназначен для разделения запуска тестовых сценариев.
-
Создавайте свои filterTag для удобства использования
-
Назначайте уникальный тег для каждого сценария
<runScenariosByTag enable="true">
<tag name="UI" enable="true"/>
<tag name="API" enable="false"/>
</runScenariosByTag>
При конфигурации <runScenariosByTag>
- у вас имеется возможность создавать свой набор тегов, и давать им имена, которые будут использоваться для разделения, и запуска тестовых сценариев по тегу.
<ui>
- предназначен для настройки конфигураций UI части
При раскрытии данного тега, выпадает список внутренних тегов UI, которые необходимо заполнить для настройки конфигурации.
Теги внутри UI:
<browserSettings>
<takeScreenshotOfEachUiCommand>
<webElementAutowait>
<browsers>
<chrome>
<opera>
<safari>
<edge>
<firefox>
<browserType>
<localBrowser>
<browserInDocker>
<<remoteBrowser>
<chromeOptionsArguments>
<capabilities>
<baseUrl>
- UI config
<integrations>
- предназначен для настройки интеграций с API, Database
Внутри integration tag - имеется набор интеграций, которые идут из коробки:
<apis>
<clickhouse>
<dynamo>
<elasticsearch>
<kafka>
<mongo>
<mysql>
<oracle>
<postgres>
<rabbitmq>
<redis>
<s3>
<sendgrid>
<ses>
<sqs>
- integration config
При выборе определенного тега, раскрывается список параметров, необходимых к заполнению для реализации интеграций.
За счет автоматизации данных тегов, вы сможете легко конфигурировать ваш global-config.xml - file, подставляя нужные значения для быстрого начала работы с проектом.
После завершения установки, и формирования global-config.xml - file, - можно приступать к изучению используемых для тестирования тегов и написанию первого тестового сценария.
UI - Scripts
Locators
Прежде чем приступить к описанию тегов которые относятся к UI
, необходимо знать как создать locator, и как происходит его связь со сценарием.
Доступные типы локаторов:
- id
- class
- xpath
Для создания локаторов нужно:
- Создать файл с названием страницы или компонента (пример:loginPages.xml)
- Внутри loginPages.xml открыть тег <locators
- Дать уникальное имя локатору элемента
- Указать тип локатора ( id, xpath, class )
- Положить контент внутрь выбранного типа локатора
Пример ( быстрое видео создания локатора ) Анимация
Структура тега:
<locator locatorId="firstName"> - Уникальное имя локатора
<id>register_account_first-name_input</id> - Выбранный элемент взаимодействия
</locator>
У вас возникает вопрос, каким образом происходит связь между локатором и тегами?
Продемонстрируем связь локатора с помощью тега <click>
Тег выполняющий команду ‘клик’ по выбранному элементу страницы
<click comment = "Click on 'Login' button" - Комментарий выполняемого действия
locatorId="locators.firstName"/> - Путь к нужному элементу
После значения
locatorId= ""
- Мы прокладываем путь к нужному нам локатору. Мы уже знаем что все созданные локаторы хранятся в папке под названием: locators, соответственно вводим имя нужной нам папки, и после используем уникальное имя локатора В нашем случае это:
'firstName'
Таким образом мы реализуем связь взаимодействия между локатором и тегами.
Теперь ознакомимся со всеми тегами которые помогут вам качественно тестировать ПО.
Global tag
The tag is the main interpreter, containing a set of all tags for interacting with the user interface, which will be described below.
An example of using the tag:
<ui comment="Start UI scripts">
<navigate command="to" comment="Go to base page"
path="/shop/"/>
<wait comment="Wait for visualize a click"
time="2" unit="seconds"/>
<click comment="Click on the 'Shopizer' website link which opens in a new window"
locatorId="shopizer.webSiteShopizer"/>
</ui>
UI tag's
:
- click
- input
- dropDown
- navigate
- assert
- scrollTo
- scroll
- javascript
- include
- wait
- clear
- closeSecondTab
- repeat
<input>
Тег выполняющий команду ввода значения в выбранное поле
<input comment="Input first name"
`locatorId="ownerRegistration.firstName"
value="Mario"/>` - в value - находится значение ввода ‘Mario
Также с помощью тега <input>
ми имеем возможность вставить image файл нужного формата ( например добавить фото аккаунта )
Для реализации данной функции, нужное изображение должно находится в одной папке с вашим тестовым сценарием, например в папке с названием scenario
<input comment="Add profile photo"
locatorId="userPhoto.addProfilePhotoButton" - Выбранный элемент взаимодействия
value="file:Firmino.jpg"/> - Внутри value обозначаем что мы хотим вставить файл с помощью file: ,после вводим название файла (который находится в папке scenario )
то есть Firmino.jpg.
<DropDown>
Тег взаимодействия с функцией ‘select’
< Данный тег применяется для select and deselect function, с возможностью взаимодействия с мультиселектом
- Select One Value
Выбирает одно значение из списка
<dropDown comment="Select 'Country'" locatorId="registration.country">
<oneValue type="select" by="text" value="Spain"/>
</dropDown>
- deSelect One Values
Сбрасывает одно значение из списка
<dropDown comment="Deselect 'Country'" locatorId="registration.country">
<oneValue type="deselect" by="text" value="Spain"/>
</dropDown>
Параметр by= ""
- предлагает выбор взаимодействия:
- text
- value
- index
- Deselect All Values
Сбрасывает все значения из списка
<dropDown comment="Deselect all values'" locatorId="registration.country">
<allValues type="deselect"/>
</dropDown>
<navigate>
Тег позволяющий выполнять навигацию по страницам UI с помощью URL
Для использования вам нужно добавить только путь к нужной странице, так как по дефолту будет использоваться ваш базовый URL который указан в настройках конфигураций.
Имеет 3 команды:
- to
- back
- reload
1.NavigateTo
Навигация на страницу указанную в path=""
<navigate comment="Go to register account page"
command="to"
path="/registerAccount"/> - путь URL
- NavigateBack
Возврат на предыдущую страницу сценария
<navigate comment="Go to register account page"
command="back"/>
- NavigateReload
Перезагрузка актуальной страницы сценария
<navigate comment="Go to register account page"
command="reload"/>
<assert>
Тег позволяющий подтвердить:
Что выполненное ранее действие привело к нужному результату
- Пример:
Вы использовали тег
<navigateBack>
- для возврата на предыдущую страницу.
Чтобы подтвердить выполнение данной функции, - используется тег <assert>
В качестве подтверждения понадобится создать locatorId
элемента нужной страницы и пробросить его в тег <assert>
<assert comment="Verify that the transition to the previous page was successful"
locatorId="billing.billingPositiveAssert" - имя локатора элемента нужной страницы
attribute="id"> - выбор атрибута ( id, class, xpath, html )
<content>
register_profile-photo_input - сам элемент
</content>
</assert>
<scrollTo>
Тег позволяющий скроллить страницу по определенному элементу
<scrollTo comment="Scroll to element"
locatorId="footer.registerButton"/>
<scroll>
Scroll Up or Down by
pixel
- value="" - takes default value in pixels
<scroll comment="Scroll Down" value="1024" direction="down"/>
<scroll comment="Scroll UP" value="976" direction="up"/>
Scroll Up or Down by
percent
- value="" - has a maximum value of 100 (when scrolling as a percentage)
<scroll comment="Scroll Down in percent" value="60" measure="percent" direction="down"/>
<scroll comment="Scroll Up in percent" value="80" measure="percent" direction="up"/>
<javascript>
Тег вызывающий скрипт находящийся в папке 'javascript'
<javascript comment="Apply javascript function" file="function.js"/>
<include>
Тег позволяющий запустить ‘сценарий внутри сценария’ ( часто используется для связки разных сценариев)
Реализовано с помощью передачи пути к сценарию, который находится в определенной папке
Начало пути всегда начинается с папки scenarios, так как все папки с созданными сценариями должны хранится именно в данной папке
<include comment="Add scenario for login to the system"
scenario="/nameOfScenarioFolderWithSlash"/> - Путь к папке сценария который нужно запустить
( —-- image structure —-- )
<wait>
Тег позволяющий заморозить время прохождения сценария для выполнения определенной функции которая требует ожидания - после выполнения, сценарий будет работать в обычной темпе
<wait comment="Waiting for loading Dashboard page"
time="1" unit="seconds"/> - Имеется выбор: секунды или миллисекунды
<clear>
Тег позволяющий очистить введенные данные в полях
<clear comment="Clear name field"
locatorId="updateProfile.name"/>
<closeSecondTab>
Тег позволяющий закрывать актуальную вкладку браузера
<closeSecondTab comment="Check if closing 'second tab' works correctly"/>
<repeat>
Тег позволяющий повторять любое действие которое используется в вышеуказанных тегах
<repeat comment="Repeat action" times="5"> - количество повторений
<click comment="Click on 'Send button'"
locatorId="locator.clickButton"/>
</repeat>`
Variations
Что такое ‘variations’ в COTT?
CSV - файл, который содержит составленные QA - данные для тестирования
Variations - выполняют важную роль в написании UI автоматизированных тестов. Когда ваши QA - специалисты столкнутся с тестированием функциональности работы полей и селекторов, - с использованием ‘variations’ они смогут за короткое время подготовить необходимый набор данных, который будет находится в табличном виде внутри csv - файла, и с легкостью протестировать валидацию и основной функционал полей и селекторов.
-
Variations — эффективны для проведения «Позитивного» и «Негативного» тестирование
-
Данные очень часто упаковывают именно в таблицы, поэтому CSV-файлы очень просты и эффективны в использовании.
Пример использования:
У нас есть форма регистрации нового пользователя, которая состоит из полей:
- First name
- Last name
- EmailAddress
- Password
- Repat Password
Структура данного csv - файла будет иметь уникальные имена полей, с перебором значений под каждое из них.
Когда мы свяжем наш csv
- файл со сценарием, - сценарий запустится 5 раз подряд, так как в таблица состоит из 5 столбцов с разными данными внутри. Каждый запуск сценария будет выполнять перебор всех значений которые находятся в данной файле.
Для того чтобы протестировать функционал и валидацию каждого поля вручную, понадобилось бы немало времени на составление тестовой документации и проведения мануального тестирования, с помощью Variations - это займет намного меньше времени, а эффективность возрастет.
Составить такой csv - файл с данными для тестирования довольно просто, так как:
CSV-файл состоит из строк с данными и разделителей, которые обозначают границы столбцов. В одном таком файле, позитивном или негативном QA - специалисты смогут перебрать все возможные наборы значений, который помогут эффективно протестировать данный функционал.
Use of variation
To include variations in a script, add the value to the schema path 'variations="fileName"
registerN - имя вызываемого
csv
файла
Пример использования variations
в сценарии
<input comment="Input first name"
locatorId="registerAccount.firstName"
value="{{firstName}}"/> в ‘value’ - использование variation
<input comment="Input lastname"
locatorId="registerAccount.lastName"
value="{{lastName}}"/> - использование variations
<input comment="Input email"
locatorId="registerAccount.emailAddress"
value="{{emailAddress}}"/> - использование variations
<input comment="Input password"
locatorId="registerAccount.password"
value="{{password}}"/> - использование variations
<input comment="Repeat password"
locatorId="registerAccount.repeatPassword"
value="{{repPassword}}"/> - использование variations
Integrations tag's
Database tag's
:
- Postgres
- Mongo
- Oracle
- MySQL
- Dynamo
- ClickHouse
- Redis
<postgres>
Теги взаимодействия с базой данных:
<postgres comment="Get all user's from system" alias="shopDb" file="expected_1">
<query>SELECT * FROM t_user</query>
</postgres>
<mongo>
<mongo comment="Get all user's from system" alias="shopDb" file="expected_1">
<query>SELECT * FROM t_user</query>
</mongo>
<oracle>
<oracle comment="Get all user's from system" alias="shopDb" file="expected_1">
<query>SELECT * FROM t_user</query>
</oracle>
<mysql>
<mysql comment="Get all user's from system" alias="shopDb" file="expected_1">
<query>SELECT * FROM t_user</query>
</mysql>
<dynamo>
<dynamo comment="Get all user's from system" alias="shopDb" file="expected_1">
<query>SELECT * FROM t_user</query>
</dynamo>
<clickhouse>
<clickhouse comment="Get all user's from system" alias="shopDb" file="expected_1">
<query>SELECT * FROM t_user</query>
</clickhouse>
<redis>
<redis comment="Get all user's from system" alias="shopDb" file="expected_1">
<query></query>
</redis>
Queue tag's
:
- Rabbit
- Kafka
- SQS
<rabbit>
<rabbit comment="Receive 2 times and send 1 time"
alias="rabbit-one">
<receive queue="queue">
<file>expected_1.json</file>
</receive>
<receive queue="queue">
<message>[]</message>
</receive>
<send routingKey="queue">
<file>body_1.json</file>
</send>
</rabbit>
<kafka>
<kafka comment="Receive then send and receive 2 time"
alias="kafka-one">
<send topic="queue2" correlationId="343gfrvs-dh4aakgksa-cgo60dmsw-sdf4gj62">
<file>body_2.json</file>
</send>
<send topic="queue3" correlationId="dfskogdfa9sd-rekjdfnkv-sdfkjewnd8-erkfdn">
<file>body_4.json</file>
</send>
<receive topic="queue2" timeoutMillis="1200">
<value>
[ {
"key" : null,
"value" : "{\n \"squadName\": \"Still rule cool\",\n \"homeTown\": \"Metro Tower\",\n \"formed\":
2018,\n \"secretBase\": \"Rower\",\n \"active\": false\n}",
"correlationId" : "343gfrvs-dh4aakgksa-cgo60dmsw-sdf4gj62",
"headers" : { }
} ]
</value>
</receive>
<sqs>
<sqs comment="Compare message from empty queue with file content"
alias="queue_one"
queue="queue">
<receive>expected_1.json</receive>
</sqs>
Email Services
:
- SES
- Sendgrid
<ses>
<ses comment="Sending a message to the email"
alias="ses_one">
<destination>[email protected]</destination>
<source>[email protected]</source>
<message>
<body>
<html>Amazon SES test</html>
<text>Hello World</text>
</body>
<subject>TITLE</subject>
</message>
</ses>
<sendgrid>
<sendgrid comment="Sending a message to the email from file"
alias="sendgrid_one">
<post url="mail/send">
<response code="202"/>
<body>
<from file="body1.json"/>
</body>
</post>
</sendgrid>
Object storage
:
- S3
<s3>
<s3 comment="Upload json file to the bucket"
alias="bucket"
key="/com/tool/integration-testing/expected_2.json">
<upload>expected_2.json</upload>
</s3>
Search system
:
- ElasticSearch
<elasticsearch>
<elasticsearch comment="Execute elasticsearch commands - get list of indexes"
alias="elastic_one">
<get url="/_cat/indices">
<response file="expected_1.json">
<header name="content-length" data="0"/>
</response>
</get>
</elasticsearch>
Multidatasets
COOT - имеет возможность выполнять накатку данных в базу данных, используя такие расширения как:
Все тестовые данные хранятся в папке Dataset
sql
csv
xlsx
partiql
bson
Migrations
Migration tag's:
migrate
csv
excel
<migrate>
- Тег
migrate
взаимодействует со всеми существующими реляционными базами данных
<migrate comment="Add data for database" alias="mySql">
<patches>dataset.sql</patches>
</migrate>
<csv>
<csv comment="Add CSV dataset to db" alias="postgres">
<csvFile>datasetPostgres.csv</csvFile>
</csv>
<excel>
<excel comment="Add data for database" alias="oracle">
<excelFile>central.xlsx</excelFile>
</excel>
REST API - Scripts
<var>
<http>
<auth>
Var
Переменная - поименованная или адресуемая иным способом область памяти, которую можно использовать для доступа к данным.Переменная простыми словами — это хранилище данных. Сюда можно положить какое-то значение (например, число, строку или другой тип данных). В переменных хранятся определенные данные, которые можно впоследствии использовать в программе.
Переменная гибка:
- в ней можно хранить информацию;
- можно из неё извлекать информацию, что не повлияет на значение самой переменной;
- в неё можно записать новые данные.
Для того, чтобы создать переменную, необходимо ее объявить (зарезервировать ячейку памяти под определенные данные)
How to create a variable in COTT?
- Предположим, в нашем тестовом сценарии имеется шаг
<postgres>
когда мы обращаемся в базу данных для того чтобы отобразить данные из определенной таблицы и вытащить токен авторизации.
<postgres comment="Get token and user_id from t_one_time_token table" file="expected_7.json" alias="central">
<query>SELECT token, user_id
FROM t_user_one_time_token ORDER BY ID DESC LIMIT 1
</query>
</postgres>
- После выполнения данного запроса мы получим actual_file_1.json c ответом базы, и перенесем его в expected_1json
Объявление переменной с излечением данных:
<var comment="Created token var" name="TOKEN">
<jpath>$.[0].content.[0].token</jpath> - внутренний тег с помощью которого мы извлекаем нужные нам данные из expected_file
</var>
name="TOKEN"
- Имя обьявленной переменной<jpath>$.[0].content.[0].token</jpath>
- способ извлечения данных из json (expected file)
Пример передачи переменной в http - запросе
<http comment="Get user profile" alias="API">
<get url="/api/v1/profile">
<response code="200" file="expected_1.json"/>
<header name="Authorization" data="Bearer {{TOKEN}}"/> - использование переменной
</get>
</http>
Structure HTTP
Структура HTTP
запроса имеет в себе все основные возможности инструментов для тестирования API.
HTTP в тестовом сценарии
<http comment="Check the ability login system" alias="API"> - описание действия + alias API
<post url="/api/v1/login"> - указание вида запроса + используемый эндпоинт
<response code="200" file="expected_1.json"/> - код ответа + ожидаемый результат
<body>
<from file="request_1.json"/> - передача request body
</body>
</post>
</http>
<var comment="Get JWT token from previous expected_file" - создание переменной
name="profile"
path="$.body.token"/>
<http comment="Get user profile" alias="API">
<get url="/api/v1/profile">
<response code="200" file="expected_1.json"/>
<header name="Authorization" data="Bearer {{profile}}"/> - использование переменной
</get>
</http>
Methods:
- GET
- POST
- PUT
- PATCH
- DELETE
- OPTIONS
- HEAD
- TRACE
Response code
- 1xx
- 2xx
- 3xx
- 4xx
- 5xx
Request file
{
"attributes": [
{
"id": 4
}
],
"product": 1,
"quantity": 1
}
Expected Result
{
"body": null,
"errors": {
"code": [
"Forbidden"
],
"message": [
"Access is denied"
]
},
"debugInfo": {
"requestId": "p(any)",
"stackTrace": null
}
}
Comparison
После выполнения каждого HTTP - запроса, comparison генерирует actual_file в котором содержится ответ API в json формате с кодом ответа и данными.
actual_file
- генерируется для того чтобы QA - специалист на лету понимал как система отреагировала на данную проверку. Если актуальный результат устраивает QA, то все данные из actual_file - тестировщик переносит в файл под названием expected_file ( который стоит в структуре http - запроса как ожидаемый результат проверки, для того чтобы данный тест проходил успешно.
HTTP - в COTT, дает возможность в считанные минуты провести смоук (и убедиться, что ничего важного не сломалось),проводить модульное и интеграционное тестирование, выполнить одни и те же тесты с разнообразными наборами входных данных или быстро проделать какие-либо вспомогательные действия по созданию тестовых данных и ситуаций.
Create HTTP - scripts
Function authentication
In progress