TestRail - Индивидуални настройки за проекта

въведение

В много проекти, с които работих, хората не персонализираха TestRail за себе си и управляваха със стандартни настройки. Затова в тази статия ще се опитам да опиша пример за индивидуални настройки, които могат да ви помогнат да увеличите ефективността на вашата работа. Например, нека вземем проект за разработка на мобилно приложение.

Малък отказ от отговорност. Тази статия не описва основната функционалност на TestRail (има много ръководства за това) и изразите за продажба, колоритно описващи защо трябва да изберете този конкретен доставчик, за да създадете хранилище с тестове.

План-обосновка (какво ще бъде изпълнено)

1. Общи изисквания

   1. Случаят трябва да може да премине абсолютно всеки

   2. Случаите трябва да останат актуални възможно най-дълго

   3. Калъфите трябва да покриват функционалността на мобилното приложение възможно най-внимателно, доколкото това не противоречи на първите две точки.

2. Разделяне на TestCase и TestScenario

3. Бързо формиране на TestRun от различни видове

   1. Дим

   2. Регрес

   3. Тестване на удар и др.

4. Оптимизиране на поддръжката на случая

   1. Отхвърляне на „мъртви“ твърдо кодирани екранни снимки и преход към „преместваеми данни“

Изисквания

Ще ви е необходим администраторски достъп за редактиране на полетата

Избор на тип проект

Има три вида проекти, от които да избирате:

Ще изберем типа по подразбиране. Всички калъфи ще бъдат налични в него едновременно. Ще използваме интелигентно филтриране и ще управляваме динамично всички случаи наведнъж.

Добавяне на полета за преглед на списъка с тестови случаи

Нека добавим поле за показване на приоритетни тестови случаи:

Можете също да добавите други полета.

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

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

Имаме нужда от тези полета:

Поле „Резюме“ (заглавка на тестов случай)

Това поле вече съществува, ние само систематизираме използването му. Ще разделим случаите на TestCase и TestScenario. За по-добра четливост на голям списък от случаи е по-добре да се договорите предварително за правилата за писане на резюме.

Тестов сценарий:

Пример: TestScenario - Основен случай на използване на мобилно приложение

тестов случай:

Пример: Главен екран - Секция за оторизация - Въвеждане за влизане

Като цяло в резюмето на делото виждаме класическо разбиране: „какво, къде, кога”. Ние също визуално разделяме тестови скриптове на високо ниво и тестови случаи на ниско ниво в най-подходящата форма за автоматизация.

Таг "StartScreen" (екранът, от който стартира TestScenario, също много тестови случаи могат да докосват съседни екрани)

За какво може да е необходимо: ще премахнем типичните стъпки от текста на случаите, които водят потребителя до екрана на текущия тестов случай. (типични стъпки за създаване на конкретна тестова ситуация) Всички типични стъпки за всички тестови случаи ще бъдат записани в един файл. За това ще пиша по-подробно отделно.

Създайте ново поле:

Попълнете компонентите на новото поле:

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

Имайте предвид, че стойностите на id не започват от едно и не са последователни. Защо се прави това? Факт е, че ако имаме записани тестови случаи с въведения id,

и след това трябва да създадем трети екран между двата съществуващи,

тогава ще трябва да пренапишем идентификатора и тъй като таговете на съществуващите текстови случаи вече са прикачени към него, те просто се изтриват. Ще бъде много неприятно.

Таг "Екран" (името на екрана, който засяга TestCase)

Какво може да ви е необходимо: една от котвите за изпитване на удар. Например, разработчиците са направили страхотна нова функция. Трябва да го тестваме, но за целта трябва да разберем какво точно може да повлияе тази функция. По подразбиране можем да започнем от парадигмата, че различните екрани (Дейности) на приложението имат различни класове и следователно представляват различни компоненти на приложението. Разбира се, в този случай е необходим индивидуален подход.

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

Поле MovableData (връзка към прокси база данни с променливи тестови данни)

След това ще се опитаме да разрешим проблема с поддържането на уместността на данните в тестови случаи:

1. Връзки към действителни оформления (това е много по-добре, отколкото да правите мъртви екранни снимки)

2. Типични стъпки към екрана на тестовия случай

3. SQL заявки

4. Връзки към външни данни и други данни

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

Ние ще опаковаме всички тези данни в един външен файл, който ще бъде достъпен за всички в проекта. Например, можете да използвате Google Sheet или Excel и да настроите търсене във файла. Защо точно тези доставчици? Факт е, че започваме от парадигмата, че всеки човек в екипа трябва да може да отвори и премине тестовия случай, без да е необходимо първо да инсталира каквито и да е инструменти.

За Google Sheet Могат да се използват SQL заявки. Пример:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

За Excel Можете да настроите удобни макроси за незабавно търсене. (филтриране) Пример по ссылке.

Всъщност идеята не е нова и е описана в първата книга на тестера “Testing dot com”. (автор Savin Roman) Ние просто интегрираме методите, предложени от Roman Savin в TestRail. За да направите това, създайте поле с връзка към създадения файл:

попълнете стойността по подразбиране на връзката, така че във всеки нов тестов случай вече да има връзка:

Ако местоположението на външния файл се промени (ние осигуряваме всякакви форсмажорни обстоятелства), тогава можете удобно да промените едно или повече полета във всички тестови случаи наведнъж:

Поле „Описания“ (описание или идея на тестовия случай, типични инструкции)

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

Пример: Всички тестови данни (действителни оформления, използване на инструменти и други данни) от този тестов случай са маркирани с {...} връзки и се намират в MovableData. Връзка към MovableData в съответното поле в горната част.

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

Какво може да ви е необходимо: за изпитване на удар. Ако едно мобилно приложение може да бъде разделено на компоненти (които се влияят един на друг възможно най-малко), тогава промените в един компонент ще бъдат достатъчни (с известни рискове) за проверка в рамките на същия компонент и ще има по-малко причини за провеждане на общи регресии на всичко и всичко. Ако има информация, че един компонент може да повлияе на друг, тогава се съставя матрица за изпитване на въздействието.

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

Етикет "TAG" (Други тагове за филтриране)

Маркиране на тестов случай с етикети за произволно филтриране. 

Много полезно за: 

1. бърза компилация на TestRun за различни типични задачи: дим, регресия и др.

2. дали тестовете ще бъдат автоматизирани или вече автоматизирани

3. всякакви други тагове

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

Задаване на реда на показване на полетата в тестовия случай

Създадохме много нови полета, време е да ги подредим в удобен ред:

Създаване на TestRun

Сега ще създадем нов тест със съответните случаи за тестване на дим с три щраквания:

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

1. Ако има няколко проекта в TestRail, тогава не забравяйте да създадете нови полета само за вашия проект, в противен случай колегите от съседните екипи ще бъдат много изненадани от появата на нови необичайни полета. Възможно е локално припадък.

2. Случаите с голям брой полета са по-лесни за копиране от група с подобен тип, отколкото за създаване на нови:

3. Сметките могат да се споделят. Например: един администратор, няколко потребители.

Заключение

Горните примери са приложени в няколко проекта и са показали своята ефективност. Надявам се, че ще ви помогнат да подобрите разбирането си за този инструмент и ще ви помогнат да създадете ефективно и удобно „съхранение на тесто“. Ще бъда много благодарен, ако опишете опита си от използването на TestRail и полезни съвети в коментарите.

за справка:

Уебсайт на доставчика на TestRail

книга: „Тестване на .COM“ (автор Роман Савин)

Благодаря ви много за вашето внимание!

Източник: www.habr.com