Меню

Какво е STLC V-модел?

what is stlc v model

Опитайте Нашия Инструмент За Премахване На Проблемите

Какво е STLC V-модел?

Един от основните недостатъци на модел водопад STLC беше, че дефекти бяха открити на много по-късен етап от процеса на разработване, тъй като тестването беше направено в края на цикъла на разработка. Стана много трудно и скъпо да се поправят дефектите, тъй като беше открит на много по-късен етап. За да се преодолее този проблем, беше въведен нов модел за развитие, наречен „V модел“

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

STLC V-модел

Какво ще научите:

Проверка и валидиране

За да разберем V модела, нека първо разберем какво е проверка и валидиране в софтуера.

Проверка : Проверката е техника за статичен анализ. При тази техника тестването се извършва без изпълнение на кода. Примерите включват - рецензии, проверка и инструкции.

Проверка : Проверката е техника за динамичен анализ, при която тестването се извършва чрез изпълнение на кода. Примерите включват функционални и нефункционални техники за тестване.

V-модел

При V модела разработките и QA дейностите се извършват едновременно. Няма дискретна фаза, наречена Тестване, а тестването започва точно от фазата на изискванията. Дейностите по проверка и валидиране вървят ръка за ръка.

За да разберем V модела, нека разгледаме фигурата по-долу:

STLC V модел

най-добрият безплатен софтуер за часовник за служители

В типичен процес на разработка лявата страна показва дейностите по разработка, а дясната показва дейностите по тестване. Не бива да греша, ако кажа, че във фазата на разработка се извършват както проверка, така и валидиране заедно с действителните дейности по разработка.

Сега нека разберем фигурата:

Лява страна

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

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

  • Дейности по проверка : Прегледи на изискванията.
  • Дейности по валидиране : Създаване на UAT ( Тест за приемане от потребителя ) тестови случаи
  • Произведени артефакти : Документ за разбиране на изискванията, тестови случаи на UAT.

Системни изисквания / Дизайн на високо ниво : В тази фаза се изгражда дизайнът на високо ниво на софтуера. Екипът проучва и проучва как биха могли да бъдат изпълнени изискванията. Проучва се и техническата осъществимост на изискванията. Екипът предлага и модули, които ще бъдат създадени / зависимости, Хардуер / софтуерни нужди

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

Архитектурен дизайн: В тази фаза, въз основа на дизайна на високо ниво , създава се софтуерна архитектура. Модулите, техните взаимоотношения и зависимости, архитектурни диаграми, таблици на бази данни, технологични детайли са финализирани в тази фаза.

  • Дейности по проверка : Прегледи на дизайна
  • Дейности по валидиране : Интеграционен план за изпитване и тестови случаи.
  • Произведени артефакти : Проектни документи, Тестови план за интеграция и тестови случаи, Дизайн на таблици на база данни и др

Модулен дизайн / Дизайн на ниско ниво: На този етап всеки модул от софтуерните компоненти се проектира индивидуално. Методите, класовете, интерфейсите, типовете данни и т.н. са финализирани в тази фаза.

  • Дейности по проверка : Прегледи на дизайна
  • Дейности по валидиране : Създаване и преглед на единични тестови случаи.
  • Произведени артефакти : Единични тестови случаи,

Изпълнение / Кодекс : В тази фаза се извършва действителното кодиране.

  • Дейности по проверка : Преглед на кода, преглед на тестови случаи
  • Дейности по валидиране : Създаване на функционални тестови случаи.
  • Произведени артефакти : тестови случаи, преглед на контролния списък.

Дясна страна

От дясната страна се показват тестовите дейности или фазата на валидиране. Ще започнем отдолу.

Единично тестване: В тази фаза се изпълняват всички модулни тестови случаи, създадени във фазата на проектиране на ниско ниво.

* Единичното тестване е техника за тестване на бяла кутия, при която се записва част от кода, която извиква метод (или която и да е друга част от кода), за да провери дали кодовият фрагмент дава очаквания изход или не. Това тестване се извършва основно от екипа за разработка. В случай на някаква аномалия дефектите се регистрират и проследяват.

Произведени артефакти : Резултати от изпълнение на единичен тест

Интеграционно тестване : В тази фаза се изпълняват тестовите случаи на интеграция, които са създадени във фазата на архитектурния дизайн. В случай на някакви аномалии, дефектите се регистрират и проследяват.

* Интеграционно тестване: Интеграционното тестване е техника, при която модулните тествани модули се интегрират и тестват дали интегрираните модули показват очакваните резултати. С по-прости думи, той проверява дали компонентите на приложението работят заедно, както се очаква.

Произведени артефакти : Резултати от теста за интеграция.

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

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

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

Произведени артефакти : Резултати от UAT, актуализирани матрици за покритие на бизнеса.

Кога да използвам V модела?

V модел е приложим, когато:

  • Изискването е добре дефинирано и не е двусмислено
  • Критериите за приемане са добре дефинирани.
  • Проектът е кратък до среден по размер.
  • Използваните технологии и инструменти не са динамични.

Плюсове и минуси на използването на V модел

ПРОФЕСИОНАЛИСТИПРОТИВ
- Развитието и напредъкът са много организирани и систематични-Не е подходящ за по-големи и сложни проекти
- Работи добре за по-малки и средни проекти.- Не е подходящо, ако изискванията не са последователни.
- Тестването започва от началото, така че неяснотите се идентифицират от самото начало.- В междинен етап не се произвежда работещ софтуер.
- Лесен за управление, тъй като всяка фаза има добре дефинирани цели и цели.- Няма разпоредби за извършване на анализ на риска, така че има несигурност и рискове.

Препоръчително четене

^