Как установить testrail на windows

Обновлено: 30.06.2024

Во многих проектах, с которыми я работал, люди не настраивали под себя TestRail и обходились стандартными настройками. Поэтому в данной статье я постараюсь описать пример индивидуальных настроек, которые могут помочь Вам повысить эффективность своей работы. Для примера возьмем проект разработки мобильного приложения.

Небольшой дисклеймер. В данной статье нет описания базового функционала TestRail (на это есть много гайдов) и продающих выражений красочно описывающих почему нужно выбрать именно этого вендора для создания репозитория с тестами.

План-обоснование (что будет реализовано)

Кейс должен смочь пройти абсолютно любой человек

Кейсы должны сохранять актуальность как можно дольше

Кейсы должны максимально тщательно покрывать функционал мобильного приложения в той мере, в которой это не противоречит первым двум пунктам

Разделение на TestCase и TestScenario

Быстрое формирование TestRun различных типов

Impact тестирование и т.д.

Оптимизация поддержки кейсов

Отказ от «мертвых» захардкоженных скриншотов и переход на «movable data»

Requirements

Для редактирования полей Вам потребуется администраторский доступ

Выбор типа проекта

Можно выбрать три типа проекта:

Мы выберем тип по умолчанию. В нем будут доступны одновременно все кейсы. Мы будем пользоваться умной фильтрацией и динамически управлять всеми кейсами сразу.

Добавление полей для просмотра списка тест кейсов

Добавим поле для отображения priority тест кейсов:

Также можно добавить и другие поля.

Настройка полей и тегов тест кейса

Открываем меню настройки:

Нам потребуются такие поля:

Поле "Summary" (шапка тест кейса)

Данное поле уже существует, мы только систематизируем его использование. Будем разделять кейсы на TestCase и TestScenario. Для лучшей читаемости большого списка кейсов лучше заранее договорится по регламенту написания summary.

TestScenario:

TestCase:

Итого мы видим в summary кейса классическое понимание: “что, где, когда”. Также визуально мы разделяем верхнеуровневые тестовые сценарии и низкоуровневые тест кейсы в наиболее подходящем для автоматизации виде.

Тег "StartScreen" (экран с которого начинается TestScenario, также многие тест кейсы могут задевать соседние экраны)

Для чего может понадобится: мы будем удалять из текста текст кейсов типовые шаги приводящие пользователя на экран текущего тест кейса. (типовые шаги для создания определенной тестовой ситуации) Все типовые шаги для всех тест кейсов будут прописаны в одном файлике. О нём более подробно напишу отдельно.

Создаем новое поле:

Заполняем компоненты нового поля:

В данном случае мы создаем поле выбора из списка значений. Вводим значения этого поля:

Обратите внимание, что id значений начинаются не с единицы и идут не подряд. Почему так сделано? Дело в том, что если у нас будут записаны тесткейсы с введенным id,

и после этого нам потребуется создать третий экран между двумя существующими,

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

Тег "Screen" (наименование экрана который затрагивает TestCase)

Для чего может понадобится: один из якорей для импакт тестирования. Например, разработчики сделали новую крутую фичу. Нам нужно её протестировать, но для это нужно понять, что именно эта фича могла затронуть. По умолчанию мы может отталкиваться от парадигмы, что разные экраны (Activity) приложения имеют разные классы и следовательно составляют различные компоненты приложения. Конечно же в данном случае нужен индивидуальный подход.

Пример: home_screen, MapScreen, PayScreen и т.д.

Поле "MovableData" (cсылка на прокси БД c изменяемыми тестовыми данными)

Далее мы постараемся решить проблему поддержки актуальности данных в тесткейсах:

Ссылки на актуальные макеты (это гораздо лучше чем делать мертвые скриншоты)

Типовые шаги до экрана с тестовой ситуацией

Ссылки на внешние данные и прочие данные

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

Все эти данные мы упакуем в один внешний файлик, который будет доступен всем желающим на проекте. Например можно использовать Google Sheet или Excel и настроить внутри файла поиск. Почему именно эти вендоры? Дело в том, что мы отталкиваемся от парадигмы, что открыть и пройти тест кейс должен смочь любой человек в команде без необходимости предварительно всякие тулзы устанавливать.

Для Google Sheet можно использовать SQL запросы. Пример:

Для Excel можно настроить удобные макросы мгновенного поиска. (фильтрации) Пример по ссылке.

Собственно идея не нова и описана в первой книжке тестировщика “Тестирование dot com”. (автор Савин Роман) Мы лишь только интегрируем в TestRail предложенные Романом Савиным методики. Для этого создадим поле со ссылкой на созданный файлик:

заполняем дефолтное значение ссылки, чтобы в каждом новом тест кейсе уже ссылка была:

Если местоположение внешнего файла изменится (мы предусматриваем любой форс мажор) то можно удобно во всех тест кейсах сразу изменить одно или несколько полей:

Поле “Descriptions” (описание или идея тест кейса, типовые инструкции)

Для чего может понадобится: В данное текстовое поле мы поместим краткое описание тест кейса и типовые инструкции.

Пример: Все тестовые данные (актуальные макеты, использование тулов и прочие данные) из данного тест кейса обозначены ссылками и находятся в файле MovableData. Ссылка на MovableData в соответствующем поле вверху.

Тег "Component" (компонент мобильного приложения)

Для чего может понадобится: для импакт тестирования. Если мобильное приложение можно разделить на компоненты (которые как можно меньше друг друга аффектят) то изменения в одном компоненте будет достаточно (с какими-то рисками) проверить в рамках этого же компонента, и будет меньше оснований для проведения всеобщих регрессов всего и вся. Если есть информация, что один компонент может аффектить другой, то составляется матрица импакт тестирования.

Пример компонентов: GooglePay, Order, Users, Map, Authorization и т.д.

Тег "TAG" (Прочие теги для фильтрации)

Тегирование тест кейса метками для произвольной фильтрации.

Очень полезно для:

быстрого составления TestRun для различных типовых задач: smoke, регресс и т.д.

будут ли тесты автоматизированы или уже автоматизированы

любые другие теги

Пример: Smoke, Automated, WhiteLabel, ForDelete и т.д.

Настраиваем порядок отображения полей в тест кейсе

Мы создали много новый полей, пришло время расположить их в удобном порядке:

Создание TestRun

Теперь мы создадим новый test run с актуальными кейсами для проведения smoke тестирования в три клика:

Другие полезные советы

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

2. Кейсы с большим количеством полей проще копировать из аналогичной группы\типа чем создавать новые:

3. Можно использовать учетные записи совместно. Например: одна администраторская, несколько пользовательских.

Заключение

Вышеописанные примеры были внедрены на несколько проектов и показали свою эффективность. Надеюсь они помогут улучшить Ваше понимание данной тулы и помогут создавать эффективные и удобные“тестохранилки”. Буду очень благодарен, если Вы в комментариях опишите Ваш опыт использования TestRail и полезные советы.

Современный человек ежедневно пользуется различными программами на телефоне и компьютере, практически не задумываясь об особенностях разработки этого софта. В данном процессе важную роль играет тестирование , помогающее устранить ошибки в функционале, и которое, в свою очередь, необходимо контролировать. В этом могут помочь специальные «инструменты управления тестированием», одним из которых является TestRail .

Предназначение TestRail

Во время тестирования выполняются различные процессы, направленные на улучшение качества продукта: анализ требований, составление плана тестирования, разработка тест-кейсов и т. д. Среди всех этих действий подготовка тест-кейсов играет очень важную роль.

Многие тестировщики предпочитают записывать тест-кейсы в Excel или другие таблицы. Но в эпоху автоматизации использовать Excel немного старомодно. Причём существует немалая вероятность потери данных.

Чтобы избавиться от этой проблемы, немецкая компания Gurock Software разработала TestRail — специальное программное обеспечение, помогающее специалистам QA и разработчикам наладить процесс тестирования . Оно помогает контролировать и отслеживать все процессы тестирования программ и организовывать деятельность отдела QA.

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

Специальные фильтры, уведомления и списки задач помогают получать полную информацию о ходе тестирования.

Особенности TestRail:

— удобное разделение и эффективное управление тест-кейсами, сьютами и тест-планами;

— простой и удобный пользовательский интерфейс;

— графическое отображение тестового прогона;

— предоставление информации о ходе тестирования в реальном времени;

— интеграция с такими баг-трекерами, как Jira ;

— гибкость и настраиваемость под любые нужды;

— развитая система генерирования отчетности;

— организация и отслеживание действий всех сотрудников;

— лицензируется по количеству реально пользующихся им пользователей.

Основные вкладки TestRail

После авторизации в TestRail открывается стартовая страница. Это рабочий стол, на котором отображаются все проекты и диаграмма активности за последнее время (от 7 до 90 дней). При нажатии на проект открывается страница управления проектом.

Вкладка « Overview » представляет собой сводку по текущему состоянию проекта, которая содержит список недавно завершённых проверок, а также последние тестовые прогоны и предстоящие майлстоуны . На специальной диаграмме активности отображается общий результат тестирования за определённый промежуток времени.

Можно посмотреть все пройденные тест-кейсы и их статусы: passed (пройден), failed (не удалось пройти), blocked (заблокирован) и retest (нуждается в повторном тестировании). Всякий раз, когда требуется переключиться на другой проект, нужно вернуться на стартовый экран, нажав на «Return to Dashboard» в верхнем левом углу.

Раздел Todo является важной частью TestRail и считается отправной точкой для тестировщиков . В чём же заключаются его особенности?

— отслеживает и фильтрует текущие активности;

— помогает отследить и распределить нагрузку между пользователями;

— отображает текущий прогресс тестирования проекта с помощью цветовой шкалы;

— является лучшим способом для тестера работать над конкретными задачами;

— страница Todo интегрирована со страницей запуска тестовых прогонов, чтобы тестировщик сразу мог перейти к выполнению своих задач.

Тестировщики могут создавать и работать над несколькими тестовыми прогонами одновременно. Более того, некоторые команды работают с различными версиями, итерациями, спринтами и майлстоунами в течение реализации проекта.

Пользователи могут использовать вкладку Milestone для создания отдельных этапов проекта, в которых поэтапно тестируются различные версии.

При создании нового этапа ( майлстоуна ) можно установить дату его начала и завершения, что помогает отслеживать сроки выполнения и порядок тестирования версий. Также можно добавить описание и пометить завершённые этапы, что поможет сконцентрироваться на активных задачах.

В этом разделе при необходимости можно создать тестовые планы и прогоны для конкретной версии, чтобы легко отслеживать прогресс в этой области. Если команда тестировщиков работает одновременно с несколькими папками, их прогресс отображается параллельно.

Test Runs & Results

Здесь осуществляется управление тест-кейсами и их выполнение в основной части тестирования. TestRail старается как можно сильнее упростить процесс ввода результатов и отслеживания прогресса тестирования.

Тестировщик может создать прогон чек-листа, благодаря кнопке « Add Test Run ». В начале ему потребуется указать имя для теста и по необходимости дополнительные данные:

— Milestone : чтобы связать тестовый прогон с нужным этапом тестирования;

— AssignTo : в этом параметре назначается ответственный за осуществление прогона;

— Description : подробное описание тестового прогона;

— All test cases include (select cases): по умолчанию все хранящиеся в проекте тест-кейсы включаются в тестовый прогон, но пользователь может вручную выбрать из общего списка необходимые для проверки кейсы.

Test Run можно редактировать и после его создания, изменять майлстоун или добавлять дополнительные кейсы.

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

Для проверки кейса и добавления результата его необходимо открыть, ознакомиться с предложенными условиями и, после проведения теста, проставить статус. Также тестировщик может добавить собственный комментарий, указать время, потраченное на проверку, и выявленные баги. Поскольку TestRail может подключаться к Jira , Bugzilla и Firebug в пункте результата под названием “ Defects ” можно указать идентификатор конкретного бага, заведённого в данных сервисах.

Test Suites and Cases

Данная вкладка является неотъемлемой частью TestRail , здесь создаются и хранятся все тест-кейсы и чек-листы тестируемого приложения, которые необходимо проверять. В проекте может содержаться более тысячи тест-кейсов для различных версий, которые группируются в подразделы для удобного использования. Как правило, это позволяет разбить тестирование проекта на различные группы с определёнными типами заданий. Например, одни отвечают за проверку механики или серверной части проекта, другие за проверку интерфейса, локализации и т. д.

Для того чтобы добавить новый раздел, необходимо нажать на кнопку Add Subsection , и после создания перейти на его страницу, где уже создать необходимые тест-кейсы с помощью « Add Case ».

Во время создания тест-кейса по необходимости заполняются следующие поля:

— Title : название кейса;

— Section : раздел, к которому будет относиться задание;

— Type : определяет тип тестирования: смоук, функциональное, юзабилити, регрессия и т. д.;

— Priority : установка приоритета тест-кейса;

— Template : установка шаблона (exploratory session, steps, text);

— Estimate : оценка задачи;

— Milestone : выбирается этап, к которому относятся задания;

— Reference : сюда указывается ссылка на таск из Jira или другого сервиса;

— Description : подробное описание задачи;

— Precondition : предварительные условия, которые необходимо осуществить перед выполнением задачи;

— Steps : шаги, которые необходимо осуществить для проверки кейса и выявления багов;

Также можно создавать таблички внутри кейса, ещё больше расширяя его возможности:

— Expected Result : ожидаемый результат, описывающий как должно работать приложение без дефектов.

Сервис позволяет изменять или добавлять новые поля, настраивая функционал максимально практично для каждого проекта. Кейс может содержать не только текстовую информацию, но и графическую (картинки).

В одной из статей мы с вами разбирали установку TestRail на Debian. В данной статье разберём установку TestRail на CentOS 7.

В статье будут рассмотрены следующие вопросы:

Открытие портов в CentOS
Установка Apache в CentOS
Установка и настройка MariaDB в CentOS
Установка PHP в CentOS
Установка «ionCube PHP Loader»
Создание каталогов и назначение прав доступа в CentOS
Настройка Apache Virtual Hosts в CentOS
Установка TestRail в CentOS
Настройка планировщика задач TestRail в CentOS

Все команды выполнять буду из-под учётной записи «root», поэтому в строке команд нет команды «sudo». Если вы выполняете команды под другой учётной записью, то в начале каждой строки дописывайте sudo. Пример:

У меня: yum -y update
У вас: sudo yum -y update

Перед выполнением всех дальнейших манипуляций проведём обновление установленных пакетов:

Установим редактор «nano», так как в нём будем редактировать и создавать файлы:

Установим «wget», который в дальнейшем нам понадобится для скачивания ionCube:

Открытие портов в CentOS

Если у вас установлен на CentOS файрволл/брандмауэр, то необходимо обязательно открыть порты, по которым будет обращение к системе TestRail. Мы ничего менять на сервере не будем, поэтому доступ будет к системе по стандартному порту (80).

Выполним в терминале по порядку команды:

Если будет ошибка, в которой говорится, что команда не найдена, то скорее всего у вас не установлен файрволл и нет необходимости открывать порты.

Установка Apache в CentOS

Для установки Apache выполняем команды:

Что сделали:
1. Установили.
2. Добавили Apache в автозагрузку.
3. Запустили Apache.

Проверим работу Apache. Создадим файл с любым содержимым:

Сохранить и закрыть «Ctrl + O», «Enter», «Ctrl + X».

Открыть созданный файл в браузере перейдя по ссылке:

Я указал IP своего сервера и далее в статье буду указывать его, вы указываете IP своего сервера.

Если не открылась страница, то ищите причину, а у кого открылась идём дальше.

Установка и настройка MariaDB в CentOS

Мы сделали следующее:
1. Установили.
2. Добавили в автозагрузку.
3. Запустили.
4. Проверили статус (в окне терминала должна присутствовать надпись «active (running)» зелёного цвета).

Проведём первичную настройку:

На запрос пароля просто жмём «Enter»:

Enter current password for root (enter for none):

Set root password? [Y/n] y

И устанавливаем новый пароль для администратора базы данных (для учётки «root» базы данных).

Remove anonymous users? [Y/n] y

Disallow root login remotely? [Y/n] n

Remove test database and access to it? [Y/n] y

Reload privilege tables now? [Y/n] y

Теперь создадим базу данных «testrail» и учётку к этой базе:

Мы сделали следующее:
1. Вошли в консоль MariaDB.
2. Создали базу.
3. Создали пользователя.
4. Назначили пользователю права на созданную базу данных.
5. Обновили привилегии.
6. Вышли из консоли MariaDB.

123456 – пароли для наглядности, вы задаёте свои пароли и пароли должны быть надёжными.

Проверьте корректность созданной учётной записи:

Должны успешно войти в консоль MariaDB.

Установка PHP в CentOS

Я здесь устанавливаю PHP по умолчанию. Вы можете установить самую последнюю версию.

Устанавливаем PHP и модули для него:

Установка «ionCube PHP Loader»

Определяем версию CentOS (32-х или 64-х разрядная):

У меня 64-х разрядная.

x86_64 = 64-х разрядная
i386 = 32-х разрядная

Скачиваем и распаковываем архив с «ionCube PHP Loader»:

Для 64-х разрядной:

Для 32-х разрядной:

Распакуется в папку «/tmp/ioncube». В папке будет множество файлов для различных версий PHP.

Просматривать быстро содержимое папок можно с помощью «mc» (установите, если не установлен).

Узнаём свою версию PHP:

Узнаём, где находится каталог с дополнениями PHP:

Копируем требуемую нам версию ionCube в требуемый нами каталог (для моего случая так):

Теперь подключим данное расширение в PHP. Правим следующие php.ini файлы:

Допишем в самом начале (в моём случае):

Сохраним и закроем. Перезапустим Apache:

Создание каталогов и назначение прав доступа в CentOS

Создадим каталог будущего сайта вместе со служебными каталогами TestRail:

Сделали:
1. Назначили права на каталог.
2. Создали каталоги.
3. Назначили права на каталог.

Домены прописывайте свои я указал «testrail.local».

Настройка Apache Virtual Hosts на CentOS

Пример, который я ниже буду показывать прост и удобен.

Нужно создать каталоги для хранения виртуальных хостов и включения сайтов. Каталог «sites-available» должен содержать файлы виртуальных хостов. Каталог «sites-enabled» должен содержать символические ссылки на виртуальные хосты, которые нужно включить.

Веб-сервер Apache должен искать виртуальные хосты в каталоге sites-enabled. Отредактируем файл настроек:

Вписать в конце файла:

Сохранить и закрыть.

Создать файл виртуального хоста:

Сохраните и закройте.

Создав файл виртуального хоста, нужно включить его. Для этого создайте символическую ссылку для хоста в каталоге «sites-enabled» и перезагрузите Apache:

Если сайт находится в локальной сети, и вы хотите, чтобы он был доступен с локальной машины, то попросите вашего администратора сети прописать его в зоне DNS.
Если вы всё проделываете в домашних условиях, то пропишите у себя на компьютере (не на настраиваемом сервере) в файле «hosts» следующее (домен свой указываете):

И сайт станет доступен в локальной сети.

Установка TestRail в CentOS

Если в процессе установки у вас появляется ошибка как на картинке, то вам необходимо настроить SELinux или отключить его (на ваш выбор):

Отключение SELinux: отредактируйте файл «/etc/selinux/config» и установите для секции «SELINUX» режим «disabled». Перезагрузить систему.

Переходим по адресу testrail.local и далее всё по аналогии как на картинках (картинки кликабельны):

На следующем шаге проверяем что всё правильно указали и нажимаем «Install».

Если TestRail сообщит, что не смог записать настройки в файл в своём каталоге, то необходимо создать файл настроек вручную. Для этого создаём его:

nano /var/www/testrail.local/config.php

Вставляем в создаваемый файл, то что укажет установщик TestRail, сохраняем и закрываем:

Настройка планировщика задач TestRail в CentOS

Определяем по какому пути у нас находится PHP:

Редактируем файл с задачами cron-а, которые запускаются от имени администратора системы:

* * * * * root /usr/bin/php /var/www/testrail.local/task.php

Сохраняем и закрываем. Перезапустим cron:

Через минуту в TestRail (в панели администратора) видим, что у нас каждую минуту будет запускаться планировщик и выполнять фоновые задания:

В этой статье мы познакомимся с практической возможностью управления процессом тестирования на основе инструмента TestRail: разберем его практическое применение и основные особенности.

Итак, с помощью TestRail можно достичь полного управления тестовыми случаями на проекте в сочетании различных практик и методологий тестирования, а также функции, специально оптимизированные под процесс тестирования ПО.

Данный инструмент может запросто быть использован в случае применения как Agile разработки, так и методологии тестирования. Однако, гибкость TestRail в процессе тестирования ПО позволяет использовать его при любой методологии ведения проекта в сфере QA.

Функциональность TestRail

Основные возможности данного продукта:

Полная документация тестовых шагов со скриншотами и дополнительными текстовыми описаниями;
Организация тест кейсов с последующим внесением в тестовые наборы;
Распределение тестовых заданий проектной команде;
Назначение тестовых кейсов и управление загруженностью команды;
Обзор ранее выполненного тестирования на виртуальной доске;
Генерирование отчетов по наиболее востребованным показателям.

Данная программа поддерживает различные типы тестирования. Ее можно использовать для задач мануального и скриптового тестирования, организации исследовательского тестирования, а также для потенциальной интеграции с выбранными инструментами автоматизации проверок.

Функционал TestRail включает в себя открытый API, а значит, пользователи могут самостоятельно создавать открытые интеграции. Подобная гибкость делает инструмент TestRail максимально востребованным в своей нише.

Отдельно стоит отметить простой в понимании пользовательский интерфейс, который позволяет максимально быстро усвоить основные команды, без существенной затраты времени на обучение. Более того, среди доступного клиенту функционала TestRail есть специальные расширенные возможности, например, настраиваемые отчеты.

Далее разберем методику использования TestRail на основе тестового примера, где будет отображаться ежедневный ход тестирования, сумма пройденных этапов и неудавшиеся тесты.

Вверху экрана расположены вкладки Test Runs и Milestones. Test run применяется для группировки всех тестовых случаев перед процессом их выполнения. В свою очередь Milestones показывает сумму тестов под конкретные задачи (к примеру, для финального релиза ПО).

Разбор программы TestRail

Чтобы ознакомится с другим перечнем предлагаемой функциональности или загрузить себе пробную версию данного продукта перейдите по ссылке.

Итак, пользователь может выбрать размещенную в облаке версию для быстрой настройки, или специальную версию Server для установки на локальный компьютер.

Для начала нужно корректно заполнить все обязательные поля, как продемонстрированно на скриншоте ниже.

Установка пробной версии TestRail

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

Важная информация! В зависимости от вашего местонахождения вам может понадобиться заключить договор на обработку данных для подтверждения соответствия Общим правилам защиты данных (GDPR).

После этого настройка учетной записи в TestRail может считаться официально завершенной.

Приступая к работе

Экран, который пользователь видит при открытии программы – это специальная приборная панель TestRail.

Приборная панель TestRail

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

При переходе на вкладку Users and Roles можно увидеть, что вам присвоена роль администратора проекта.

Открыв вкладку Roles, будет виден перечень ролей на проекте – Read-only, Tester, Designer, и Lead.

Перечень ролей на проекте

Если вы нажмете на иконку карандаша, откроется панель, где будут отображены права для каждой роли. Администратор здесь может поменять описания, создать дополнительные тестовые задания, добавить или удалить с проекта одного или нескольких пользователей, организовать группы и прочее.

Вкладка Dashboard позволяет открыть перечень инструментов по полному управлению проектом, отслеживанию выполнения тестов и их менеджмента.

Создание нового проекта

Данный параметр позволяет начать проект с одного набора тестов, а затем по мере выполнения добавлять новые наборы проверок при необходимости.

Нажимаем на Add Project.

Пользователь сразу увидит панель с новым проектом. Можно изменить название проекта или удалить его позже, если захотите.

На скриншоте ниже показана приборная панель, например, проект с несколькими тестовыми наборами и другой проект с одним репозиторием.

Приборная панель проекста с несколькими тест-кейсами

Перейдите по вкладке Test Suites. Так как это новый проект, должен отобразиться набор тестов под названием Master. Просто нажмите на название пакета для редактирования его разделов и тестовых случаев.

Либо же нажмите на кнопку Add Test Suite и попробуйте добавить новый набор тестов к вашему проекту, как это отображено на скриншоте ниже.

Добавление набора тестов

Создание тестового случая

Заполнение полей при создании тест-кейса

Следующие четыре поля обязательны для заполнения, и могут быть использованы для сортировки и фильтрации тестовых случаев: Section, Template, Type и Priority.

Раздел (Section) по умолчанию равный Test Cases. Раздел создается автоматически для каждого нового проекта.
Шаблон (Template) по умолчанию настроен на Test Case (текст). TestRail поставляется с тремя встроенными шаблонами тестов:
•Тестовый пример (текст): Включает текстовые области для предварительных условий, этапов тестирования и ожидаемого результата. Вы можете добавить скриншоты в эти текстовые области.
• Тестовый пример (шаги): Включает текстовую область для предварительных условий, плюс строки для отдельных этапов тестирования с ожидаемым результатом для каждого этапа. Вы можете добавить скриншот экрана к каждому отдельному шагу.
•Исследовательская сессия: включает области текста для миссии и целей ознакомительной сессии.
Выберите тип теста (Type). Например, регрессионный, функциональный, производительности либо же автоматический.
Установите приоритет (Priority). Например, High, Medium, или Low.

Теперь можно выполнить тест с внесенными ранее предварительными условиями, шагами и ожидаемыми результатами. После завершения теста, нажимаем на кнопку Add Case.

Будет отображаться краткое описание тестового случая, как на рисунке:

Краткое описание тестового случая

Можно добавить еще несколько тестовых случаев.

Для этого нажимаем на ссылку Test Cases для открытия меню тестовых случаев. Остается только внести оригинальные наименования тестов.

Важная информация!

Пользователь может импортировать тестовые случаи из файла CSV или XML.

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

После успешного сохранения тестов, можно просмотреть легко настраиваемые отчеты внутри программы TestRail.

Скриншот ниже показывает отчеты, которые будут доступны в процессе тестирования конкретного проекта. К слову, весь перечень дополнительных отчетов доступен на специальной вкладке Reports.

Особенности настройки контрольных точек

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

Итак, для добавления контрольных точек стоит использовать вкладку с таким же названием.

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

Однозначно, использование на проектах TestRail существенным образом повышает общую производительность команды тестировщиков при выполнении независимого тестирования.

TestRail – это хорошая и удобная альтернатива архаичным таблицам и текстовым документам, где можно быстро и качественно отслеживать все шаги тестирования веб-продуктов.

Читайте также: