Увод
У многим пројектима са којима сам радио, људи нису прилагођавали ТестРаил за себе и задовољавали су се стандардним подешавањима. Због тога ћу у овом чланку покушати да опишем пример појединачних подешавања која вам могу помоћи да побољшате ефикасност свог рада. На пример, узмимо пројекат развоја мобилних апликација.
Мала изјава о одрицању одговорности. Овај чланак не садржи опис основне функционалности ТестРаил-а (постоји много водича о томе) и продајне изразе који живописно описују зашто треба да изаберете овог конкретног продавца да бисте креирали спремиште са тестовима.
План оправдања (шта ће се применити)
-
Општи захтеви
-
Апсолутно свако би требао моћи да прође случај.
-
Случајеви треба да остану релевантни што је дуже могуће
-
Случајеви треба да покрију функционалност мобилне апликације што је детаљније могуће у мери у којој то није у супротности са прве две тачке
-
-
Поделите на ТестЦасе и ТестСценарио
-
Брзо генерисање ТестРун различитих типова
-
Пушити
-
Назадовање
-
Испитивање утицаја итд.
-
-
Оптимизација подршке за случај
-
Напуштање „мртвих“ чврсто кодираних снимака екрана и прелазак на „покретне податке“
-
Захтеви
Да бисте уређивали поља, биће вам потребан администраторски приступ
Избор типа пројекта
Постоје три типа пројекта које можете изабрати:
Одабраћемо подразумевани тип. У њему ће сви случајеви бити доступни у исто време. Користићемо паметно филтрирање и динамички управљати свим случајевима одједном.
Додавање поља за преглед листе тест случајева
Хајде да додамо поље за приказ приоритетних тест случајева:
Можете додати и друга поља.
Подешавање тестних поља и ознака
Отворите мени подешавања:
Биће нам потребна следећа поља:
Поље „Резиме“ (заглавље тест случаја)
Ово поље већ постоји, само га систематизујемо. Случајеве ћемо поделити на ТестЦасе и ТестСценарио. За бољу читљивост велике листе случајева, боље је унапред договорити правила за писање резимеа.
Тест Сценарио:
Пример: ТестСценарио – Основни сценарио за коришћење мобилне апликације
ТестЦасе:
Пример: Главни екран - Одељак за ауторизацију - Унесите пријаву
Укупно, у резимеу случаја видимо класично схватање: „шта, где, када“. Такође визуелно раздвајамо тест скрипте високог нивоа и тест случајеве ниског нивоа у облику који је најпогоднији за аутоматизацију.
Ознака „СтартСцреен“ (екран са којег почиње ТестСценарио; такође, многи тестни случајеви могу да додирују суседне екране)
За оно што може бити потребно: уклонићемо из текста текст случајева типичних корака који воде корисника на екран тренутног тест случаја. (типични кораци за креирање специфичне тест ситуације) Сви типични кораци за све тест случајеве биће написани у једној датотеци. О томе ћу писати детаљније одвојено.
Направите ново поље:
Попуните компоненте новог поља:
У овом случају, креирамо поље за одабир са листе вредности. Унесите вредности овог поља:
Имајте на уму да ид вредности не почињу са једном и да нису узастопне. Зашто се ово ради? Поента је да ако имамо тест случајеве са забележеним унетим ИД-ом,
а након тога ћемо морати да направимо трећи екран између два постојећа,
онда ћемо морати да препишемо ид, а пошто су ознаке постојећих текстуалних случајева већ прикачене уз њега, они ће једноставно бити избрисани. Биће веома непријатно.
Ознака „Екран“ (назив екрана који утиче на ТестЦасе)
Шта би вам могло затребати: једно од сидришта за испитивање на удар. На пример, програмери су направили нову цоол функцију. Морамо да га тестирамо, али за ово морамо да разумемо на шта тачно ова функција може да утиче. Подразумевано, можемо поћи од парадигме да различити екрани (активности) апликације имају различите класе и стога чине различите компоненте апликације. Наравно, у овом случају је потребан индивидуални приступ.
Пример: хоме_сцреен, МапСцреен, ПаиСцреен, итд.
Поље „МоваблеДата“ (линк до прокси базе података са променљивим подацима теста)
Затим ћемо покушати да решимо проблем одржавања релевантности података у тест случајевима:
-
Везе до тренутних распореда (ово је много боље од прављења мртвих снимака екрана)
-
Типични кораци да се дође до екрана са тестном ситуацијом
-
СКЛ упити
-
Везе ка спољним подацима и другим подацима
Уместо писања тестних података унутар сваког тест случаја, направићемо једну екстерну датотеку и повезати се са њом на свим тест случајевима. Приликом ажурирања ових података нећемо морати да пролазимо кроз све тест случајеве и да их мењамо, већ ће ове податке бити могуће мењати само на једном месту. Ако неко неспреман отвори тест случај, видеће у телу тест случаја везу до датотеке и наговештај да треба да оде до ње ради података о тесту.
Све ове податке ћемо спаковати у једну екстерну датотеку, која ће бити доступна свима на пројекту. На пример, можете користити Гоогле Схеет или Екцел и подесити претрагу унутар датотеке. Зашто баш ови добављачи? Чињеница је да полазимо од парадигме да свака особа у тиму треба да буде у могућности да отвори и прође тест случај без претходног инсталирања било каквих алата.
За Гоогле лист можете користити СКЛ упите. Пример:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")За екцел Можете да подесите погодне макрое за тренутну претрагу. (филтрирање) Пример .
Заправо, идеја није нова и описана је у књизи првог тестера „Тестинг дот цом“. (аутор Савин Роман) Управо интегришемо методе које је предложио Роман Савин у ТестРаил. Да бисте то урадили, креирајте поље са везом до креиране датотеке:
попуните подразумевану вредност везе тако да сваки нови тест случај већ има везу:
Ако се локација спољне датотеке промени (ми предвиђамо било какву вишу силу), онда можете лако променити једно или више поља одједном у свим тест случајевима:
Поље „Описи“ (опис или идеја тест случаја, стандардна упутства)
Шта ће вам можда требати: У ово текстуално поље поставићемо кратак опис тест случаја и стандардна упутства.
Пример: Сви тест подаци (тренутни изгледи, употреба алата и други подаци) из овог тест случаја су означени везама {...} и налазе се у датотеци МоваблеДата. Веза до МоваблеДата у одговарајућем пољу на врху.
Ознака „Компонента“ (компонента мобилне апликације)
За шта би могао бити потребан: за испитивање утицаја. Ако се мобилна апликација може поделити на компоненте (које што мање утичу једна на другу), онда ће промене у једној компоненти бити довољне (са извесним ризицима) да се провере у оквиру исте компоненте и биће мање разлога да се изврши опште регресије свега. Ако постоје информације да једна компонента може утицати на другу, онда се саставља матрица за испитивање утицаја.
Примери компоненти: ГооглеПаи, Поруџбина, Корисници, Мапа, Ауторизација итд.
Ознака „ТАГ“ (друге ознаке за филтрирање)
Означавање тест случаја ознакама за произвољно филтрирање.
Веома корисно за:
-
брзо компајлирање ТестРун-а за различите типичне задатке: дим, регресија, итд.
-
да ли ће тестови бити аутоматизовани или већ аутоматизовани?
-
било које друге ознаке
Пример: Смоке, Аутоматед, ВхитеЛабел, ФорДелете, итд.
Подешавање редоследа приказа поља у тест случају
Направили смо много нових поља, време је да их уредимо по погодном редоследу:
Креирање ТестРун-а
Сада ћемо направити нову пробну вожњу са тренутним случајевима за спровођење тестирања дима у три клика:
Други корисни савети
-
Ако ТестРаил има неколико пројеката, онда не заборавите да креирате нова поља само за свој пројекат, иначе ће колеге из суседних тимова бити веома изненађени појавом нових необичних поља. Могућа је локална несвестица.
2. Случајеви са великим бројем поља је лакше копирати из сличног типа групе него креирати нове:
3. Налози се могу делити. На пример: један администратор, неколико корисника.
Закључак
Горе описани примери су имплементирани на неколико пројеката и показали су своју ефикасност. Надам се да ће вам помоћи да побољшате ваше разумевање ове алатке и помоћи вам да креирате ефикасне и згодне „складишта за тестирање“. Био бих вам веома захвалан ако у коментарима опишете своје искуство коришћења ТестРаила и корисне савете.
Референце:
књига:
Много вам хвала на пажњи!
Извор: ввв.хабр.цом