Изпълнете тестовете чувстват по-добра перспектива на моделите на работа на потребителите - софтуер

Да, Анди (Andy Яп), Rational Software IBM Software Group

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

Въпреки това, с помощта на предварително планиране, който се подкрепя от Rational Unified Process (или RUP). екипи, които работят по проекти, които могат да осигурят необходимото време за тестване на олово през целия жизнен цикъл на развитие. RUP предвижда, наред с други функции, повтарящи се и въз основа на прецедента с помощта на подход за разработка на софтуер. Този подход изисква екип от разработчици да посочи точните изисквания за управление, като допълнителни добавки към капацитет, както и тестване на базата на тестови сценарии. Оперативни прецеденти предлагат добре описани етапи на взаимодействие на потребителите със системата. Като правило, оперативните стъпки на прецеденти могат да бъдат използвани като процедурите за изпитване, така че има тенденция да се направи сравнение между преминаването на оперативни сценарии за изпитване и случаи на използване.

Какво е тест скрипт? RUP той определя, както следва:

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

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

Има два основни елемента, които, ако своевременно и правилно идентификация, улесняват тестването:

• тестови сценарии
• тестови данни

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

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

Нека да видим как процес UX моделиране започва да открива тестови мотиватори на.

В типичен проект първо се моделира екран, който ще видите на крайния потребител. Това се прави с помощта на класа стереотипи <<экран>> И / или <<форма ввода>>. Екраните са свързани заедно в верига екрани смяна диаграма, която представлява използването на прилагането по никакъв начин. Текст, допълни тази презентация е да архивирате оперативните прецеденти. Многобройни ползване случай оперативна описва как потребителят взаимодейства с приложението. Всички основни начина, по който потребителят може да ползват приложението, е карта за навигация.

Ние ще премине през примера на закупуване на билет за кино (Покупка билет за кино) на базата на модела UX, който се състои от навигационна карта (Фигура 1), архив на примери за оперативна закупуване на билет за кино (Фигура 2) и серия от екрани (виж Фигура 3).

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

• Разбирането на навигационната карта.
• Определяне на значителни сделки.
• Оценка на усилията за тестване.
• Определяне на данни от изпитвания.
• модулност план.
• Определяне на пригодността на сделката.

Фигура 1 показва навигационна карта за множество екрани, които принадлежат към една и съща архивни оперативни дела. За завършване на сделката за покупка на потребителското билет за кино, трябва да си взаимодействат с три екрана и две форми на въвеждане на данни. Тези две форми на въвеждане на данни (обикновено наричани <<форма ввода>>) Се използват, за да въведете стойности за въвеждане, като потребителско име и парола. Фиг. 1 Всеки екран има средна част, което показва, че потребителят може да види, и долната част, което показва, че потребителят може да направи.

Фигура 1: Графика навигационни оперативни прецеденти архив

навигационната карта показва всички напречното връзката между екрани. Предприемачът може да използва тези тестове, за да се симулира поток комуникация сделка. За този пример, създаващи тестови скриптове, които са свързани навигационни потоци са дадени в таблица 1.

Общият брой на тест време за запис stsenarievOzhidaemoe на един тест stsenariyUsilie

На първо място, тестери трябва да видят всички съответни сделки да бъдат проверени. Обикновено всяка важна сделка съответства на един тест скрипт. Терминът "значително" да се разбира като гледна точка на потребителя, за изпълнение на задача с помощта на приложението. Според тази дефиниция е значителен само завършена и точна сделка, тъй като сделката е непълни и неточни работи напълно потребителски желания. Два възможни пътища за излизане от навигационната карта може да се види за да се постигне две крайни точки: Покажете прегледа на филма и на резултатите от избора на филми. Таблицата те съответстват на първични и подчинени потоци.

За операции очакване ще бъде обсъдено в раздел "Подробни тест случаи". Чакащите сделки в архива оперативни прецеденти съответстват алтернативен поток.

Таблица 1 обяснява и усилията, необходими за извършване на сценарии за изпитване. Усилията, свързани с технология, която е необходима за постигане на крайния резултат. Ако усилията за автоматизиране на инструмент, използван за запис и възпроизвеждане, съчетани с минимално време за изпълнение на тестови случаи е двойно процеса на запис. Това ще бъде важен фактор при вземане на решение за необходимите ресурси и тестове за планиране. Например, ако потребителят трябва да у минути, за да се постигне резултат селекция филм страница и приключването на сделката за покупка, за да се получи общото време (Z), необходимо за записване и възпроизвеждане на една такава сделка, у може да бъде умножена по 2. Общата необходима сила ще бъде равна на Z, умножена броят на случаите на изпитване. Този краен брой може да се използва за повторение планиране.

Колона 5 от Таблица 1 показва определя необходимо данните за извършване на сценарии за изпитване. Тестови данни за първия сценарий тест (основна поток 1) могат лесно да бъдат получени, като погледнете в селекцията на формуляр за регистрация и образуват филма. За да намерите данните от изпитванията за втория сценарий тест (Slave поток 1) е необходимо да се провери действията, които трябва да се покаже на следващия екран, който изброява филми, които могат да бъдат избрани.

Създателят на тестове вече има списък с данни от изпитвания, които може да се управлява. Когато има вече съществуваща база данни, приложения, повечето от работата на тестването на експертната насочени към определяне на полезността на записи в базата данни. За постигане на ширината и дълбочината на покритие инженери тест случаи за изпитване трябва да прегледате информация от архивите на оперативните прецеденти. До тогава, докато не сте напълно обмислена данните за реалния тест за подпомагане на съответните случаи за изпитване, няма реална работа ще бъде направено.

По-рано обясни необходимостта да се идентифицират смислен сделка. Всеки един от тези сделки може да бъде представляван от един тест сценарий. Сделки има определена прилика. Например, всяка сделка трябва да започва с регистрацията в системата, и в края на изхода на системата. Така че тестовете за всеки от сделката ще има напълно идентични части. Когато едно от тези сделки трябва да се направят някои промени, тези промени трябва да се повтори в сценариите с идентични сделки. Разбира се, прилагането на голям брой повторения може да бъде тромава и отнема много време.

С използването на модулни тестови поддръжка на скриптове стане по-удобно. Чрез разделяне на операцията на последователност на екрана (както в колона 4 на Таблица 1) е възможно да се постигне модулност в случай, ако, например, един екран съответства на една тестване сценарий.

По този начин, когато се променя основната регистрация екрана (MainFrm), от колона тест скрипт (колона 6 от Таблица 1) може да се види, че засегнатите два тест сценарий. Всичко, което трябва да се направи - е да се промени само един сценарий: сценария за вход.

Модулност изисква създаване на зависимости между сделки и следователно изисква колона "Зависимост" в Таблица 1. Зависимостта може да има и по-широк контекст: например, тя може да покаже състоянието на заявлението, което определя сегашната сделка, или да покаже завършване на друга сделка. За извършване на първия сценарий тест Има три сценария в следната последователност: а за влизане скрипт, скрипт, а сценарият на страницата с резултатите за избор на филм.

Последната колона в таблица 1 идентифицира очакваните резултати на тестовите сценарии. В тази графа е необходимо. Не всички стъпки са тествани, защото това би било преувеличение тестване. Тъй като целта е възможността за потребителя на една сделка, проверката е ограничена до крайния резултат на сделката, която се проверява. За да тествате сценария "Основният поток" цена на билета се проверява (или билети) към филма, получен от системата. Това е целта на тестването. В междинната проверка е необходимо.

тест на цял екран, т.е. провери всички бутони, падащ списък, списъка на държавите, в които те се намират, цветовата схема на страницата, всеки размер шрифта на буквите и т.н. Определено не е необходимо и никога не би било добра главна цел. Един начин да разберете, не е работа на тестване излишно, е да погледнете целта на скриптове за изпитване, или каквито и да било законови изисквания. С изключение на изрични указания назад, обикновено най-добрият вариант би бил да не излиза извън рамките на тези изисквания. Следвайте това правило и друго изпитване може да бъде твърде непрактично.

С една дума, навигационната карта позволява контрол на следните изследвания: (1) за разработване на тестови проект на високо ниво случаи за целия заявлението; (2) определяне на количеството на генерираните данни от изпитвания. Този проект може да пробия в степен, достатъчна за да покаже, сканираното сделката и очакваните изходни стойности.

Заслужава да се отбележи, е "тест на идеи" и каталога на изпробване на идеи (RUP артефакт). Които не са обхванати операции досега изпитване са тестови идеи. Тестовите сценарии, които те представляват, все още трябва да бъдат изяснени и подробно. RUP определя идеята за изпитване, както следва:

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

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

В повечето организации, опита за тестване е колекция от твърде разнообразните опит на членовете на екипа, които работят по проекта. Методология за стандартизация на опита е обикновено отсъства. Като решение на този проблем, изпробване на идеи директория осигурява механизъм за събиране и повторно използване на опит за тестване на различни групи и отделни служители. За да бъде наистина полезно, каталог на изпробване на идеи, трябва ясно съответствие между изпробване на идеи и тяхното изпълнение (т.е., всички известни случаи на изпитване).

Пример за директория за изпробване на идеи служи като таблица 2. Съответната информация за проекта се събира в линиите "Създаване (рекорд за билети за кино)" и "Изберете (в прегледа на филм)." Може да има и подобни да се тества идеи от друг проект, като в "Създаване на (други)."

Таблица 2: Тест идеи директория

тестови сценарии, използващи бормашина оперативни прецеденти архив

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

За определяне на стъпките при тестови сценарии, които ние наричаме архивния оперативен прецедент, който е на оперативните етапи на прецеденти с допълнителна информация за работата на потребителите. Архив оперативни прецеденти е показано на фигура 2.

Фигура 2: архив оперативни прецеденти

Съберете всички на потребителя да архивирате производителност осигурява безпрецедентна целенасочено избран важна информация за извършване на работа по тестването. Всички тези правила помагат за подробности сценарии за изпитване, както е показано в таблица 1. С помощта на таблица за събиране на цялата информация на едно място дава възможност тестери бързо да се справят с изискванията на изпитванията, и да определят колко много работа е необходима, за да ги изпълни. По-късно, експертите могат да открият по-голям брой от тестовете, но общата сума трябва да бъде възможно с подобряване на работата в екип с тестовете. Обикновено, тестери трябва да изпълнява една итерация на оценката и разбирането на процеса на тестване.

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

Фигура 3: редуващи екрани при закупуване на билети за кино

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

UX модел помага екипи, за да започнете успешен тест. Те могат да произвеждат първоначално планиране на ресурсите с навигационна карта, а не да харчите твърде много време на детайлите. След това, колкото напредък, развитие и растеж на значението на подробни сценарии за изпитване, те ще бъдат в състояние да намери най-необходимата информация в досиетата на оперативните прецеденти.