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

Вовед

Во многу проекти со кои работев, луѓето не го приспособуваа TestRail за себе и се задоволуваа со стандардни поставки. Затоа, во оваа статија ќе се обидам да опишам пример за поединечни поставки кои можат да ви помогнат да ја подобрите ефикасноста на вашата работа. На пример, да земеме проект за развој на мобилни апликации.

Мало одрекување од одговорност. Оваа статија не содржи опис на основната функционалност на TestRail (има многу водичи за ова) и продажни изрази што шарено опишуваат зошто треба да го изберете овој конкретен продавач за да креирате складиште со тестови.

План за оправдување (што ќе се спроведе)

1. Општи барања

   1. Апсолутно секој треба да може да го помине случајот.

   2. Случаите треба да останат релевантни што е можно подолго

   3. Случаите треба да ја покриваат функционалноста на мобилната апликација што е можно потемелно до степен до кој тоа не е во спротивност со првите две точки

2. Поделете се на TestCase и TestScenario

3. Брзо генерирање на TestRun од различни типови

   1. Чад

   2. Уназадување

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

4. Оптимизација за поддршка на случаи

   1. Напуштање на „мртвите“ тврдокодирани слики од екранот и префрлување на „подвижни податоци“

Потребно

За да ги уредите полињата, ќе ви треба администраторски пристап

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

Постојат три типа на проекти за избор:

Ќе го избереме стандардниот тип. Сите футроли ќе бидат достапни во него во исто време. Ќе користиме паметно филтрирање и динамично ќе управуваме со сите случаи одеднаш.

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

Ајде да додадеме поле за прикажување на приоритетни тест случаи:

Можете исто така да додадете други полиња.

Поставување полиња и ознаки за тест случаи

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

Ќе ни требаат следниве полиња:

Поле „Резиме“ (заглавие на тест случај)

Ова поле веќе постои, само ја систематизираме неговата употреба. Ќе ги поделиме случаите на TestCase и TestScenario. За подобра читливост на голема листа на случаи, подобро е однапред да се договорат правилата за пишување резиме.

Тест-сценарио:

Пример: TestScenario - Основно сценарио за користење на мобилна апликација

Тест случај:

Пример: Главен екран - Дел за авторизација - Внесете најавување

Севкупно, во резимето на случајот го гледаме класичното разбирање: „што, каде, кога“. Ние, исто така, визуелно ги одделуваме тест скриптите на високо ниво и тест случаи на ниско ниво во форма најпогодна за автоматизација.

Ознака „StartScreen“ (екранот од кој започнува TestScenario; исто така, многу тест случаи може да ги допрат соседните екрани)

За она што можеби е потребно: ќе го отстраниме од текстот текстот на случаи типични чекори што го водат корисникот до екранот на тековниот тест случај. (типични чекори за креирање специфична тест ситуација) Сите типични чекори за сите тест случаи ќе бидат запишани во една датотека. За тоа подетално ќе пишувам одделно.

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

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

Во овој случај, создаваме поле за избор од листа на вредности. Внесете ги вредностите на ова поле:

Ве молиме имајте предвид дека вредностите за идентификација не започнуваат со еден и не се последователни. Зошто е направено ова? Поентата е дека ако имаме тест случаи со снимен внесен 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&"'")

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

Всушност, идејата не е нова и е опишана во книгата на првиот тестер „Тестирање на точка com“. (автор Савин Роман) Ние само ги интегрираме методите предложени од Роман Савин во TestRail. За да го направите ова, креирајте поле со врска до креираната датотека:

пополнете ја стандардната вредност на врската, така што секој нов тест случај веќе има врска:

Ако локацијата на надворешната датотека се промени (ние обезбедуваме каква било виша сила), тогаш можете лесно да промените едно или повеќе полиња одеднаш во сите тест случаи:

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

Што можеби ќе ви треба: Во ова поле за текст ќе поставиме краток опис на тест случајот и стандардни инструкции.

Пример: Сите податоци од тестот (тековни распореди, употреба на алатки и други податоци) од овој тест случај се означени со врски {...} и се наоѓаат во датотеката MovableData. Врска до MovableData во соодветното поле на врвот.

Означете „компонента“ (компонента за мобилна апликација)

За што може да биде потребно: за тестирање на удар. Ако мобилната апликација може да се подели на компоненти (кои меѓусебно влијаат што е можно помалку), тогаш промените во една компонента ќе бидат доволни (со одредени ризици) да се проверат во рамките на истата компонента и ќе има помалку причини за извршување општи регреси на сè. Ако има информации дека една компонента може да влијае на друга, тогаш се составува матрица за тестирање на влијание.

Пример компоненти: GooglePay, нарачка, корисници, карта, авторизација итн.

Ознака „TAG“ (Други ознаки за филтрирање)

Означување на тест случај со ознаки за произволно филтрирање. 

Многу корисно за: 

1. брзо составување на TestRun за различни типични задачи: дим, регресија, итн.

2. дали тестовите ќе бидат автоматизирани или веќе автоматизирани?

3. сите други ознаки

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

Поставување на редоследот на прикажување на полињата во тест случајот

Создадовме многу нови полиња, време е да ги распоредиме по пригоден редослед:

Креирање на TestRun

Сега ќе создадеме ново тестирање со тековни случаи за спроведување на тестирање на чад со три кликања:

Други корисни совети

1. Ако TestRail има неколку проекти, тогаш не заборавајте да креирате нови полиња само за вашиот проект, инаку колегите од соседните тимови ќе бидат многу изненадени од појавата на нови необични полиња. Можна е локална несвестица.

2. Случаите со голем број полиња полесно се копираат од сличен тип на група отколку да се креираат нови:

3. Сметките може да се делат. На пример: еден администратор, неколку корисници.

Заклучок

Примерите опишани погоре се имплементирани на неколку проекти и ја покажаа нивната ефикасност. Се надевам дека тие ќе помогнат да се подобри вашето разбирање за оваа алатка и да ви помогнат да создадете ефективни и удобни „тест складишта“. Би бил многу благодарен ако го опишете вашето искуство со користење на TestRail и корисни совети во коментарите.

Референци:

Веб-страница за продавач на TestRail

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

Ви благодариме многу за вашето внимание!

Извор: www.habr.com