Методологии за разработване и тестване на софтуер (с плюсове и минуси)

software development

Какви са методологиите за разработване и тестване на софтуер?

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

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

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

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

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

• Значение на методологиите за тестване
• Техники за тестване
  • # 1) Тестване на бяла кутия:
  • # 2) Тестване на черна кутия:
  • # 3) Тестване на сива кутия:
• Модели в SDLC
  • # 1) Модел на водопад
  • # 2) В Модел
  • # 3) пъргав модел
  • # 4) Спирален модел
  • # 5) Модел RAD
• Разлика между методологии за тестване и стратегии за тестване
• Заключение:
• Препоръчително четене

Значение на методологиите за тестване

Методологиите могат да се разглеждат като набор от механизми за тестване, използвани в жизнения цикъл на разработка на софтуер от Unit Testing до System Testing. Изборът на подходяща методология за тестване се счита за ядрото на процеса на тестване.

Техники за тестване

По принцип има 3 методологии за тестване, които се използват за тестване. Те са тестване на бяла кутия, тестване на черна кутия и Тестване на сива кутия . Те също се наричат ​​като Техники за тестване . Всяка от техниките за тестване е дадена накратко по-долу за по-добро разбиране.

# 1) Тестване на бяла кутия:

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

Техниките за тестване на White Box включват:

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

# 2) Тестване на черна кутия:

Метод за тестване на Black Box се използва за тестване на функционалността на приложение въз основа на спецификацията на изискванията. За разлика от White Box Testing, той не се фокусира върху вътрешната структура / код на приложението.

Техниките на Black Box включват:

• Анализ на гранична стойност
• Разделяне на еквивалентност (Разделяне на клас на еквивалентност)
• Таблици за решения
• Тестове на домейни
• Държавни модели
• Изследователско тестване (Изисква по-малко подготовка и също така помага бързо да се открият дефектите).

# 3) Тестване на сива кутия:

Този метод на тестване се извършва с по-малко информация за вътрешната структура на приложението. По принцип това се извършва само като тестване на Black Box, но за някои критични области на приложение се използва тестване на White Box.

Модели в SDLC

Изборът на подходящи методологии за тестване също се съчетава с избора на подходящ модел в SDLC.

Моделите включват:

• Модел на водопад
• В модела
• Пъргав модел
• Спирален модел
• РАД

Нека разгледаме по-отблизо всяка методология за разработване на софтуер с кратко обяснение.

# 1) Модел на водопад

Модел на водопад е основният модел на жизнения цикъл, който е разработен от Уинстън Ройс през 1970 г. Този модел представлява множество етапи или процеси по последователен начин, който тече постепенно надолу.

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

Моделът на водопада се определя от следните етапи:

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

Предимства на модела водопад:

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

Недостатъци на модела водопад:

• Увеличение на размера на риска и несигурността.
• След като влезете във фаза на тестване, не можете да промените нищо в предишните етапи e.g Дизайн и кодиране и др.
• Не е добре за сложни и големи проекти.
• Не е подходящ, когато изискванията продължават да се променят.

# 2) В Модел

V модел е удължаване на модела на водопада където изпълнението на процеса се извършва в последователен стил във V-Shape и е известен също като Verification and Validation Model. При този подход съществува директно свързана фаза на тестване във всяка отделна фаза от цикъла на разработка.

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

V Моделът е класифициран в 3 фази.

• Фаза на проверка
• Фаза на кодиране
• Фаза на валидиране

а) Фаза на проверка :

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

б) Фаза на кодиране:

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

в) Фаза на валидиране :

• Единично тестване: Изпълнява се на индивидуален модул за отстраняване на грешките в ранния етап.
• Интеграционно тестване: Изпълнява се за тестване на комуникацията между различни модули в системата.
• Тестване на системата: Тестване на системата се извършва на система като цяло.
• Изпитване за приемане: Това е свързано с бизнес изискванията. Извършва се в потребителска среда от гледна точка на потребителя.

Предимства на V модел

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

Недостатъците на V Model са повече или по-малко подобни на недостатъците на модела Waterfall.

# 3) пъргав модел

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

Този подход също така позволява непрекъснато взаимодействие с клиента за тяхната обратна връзка и корекции в изискванията на редовни интервали.

Следващата диаграма ще ви помогне да разберете по-точно подхода на Agile Model:

Следващото изображение ще покаже цикъла на итерация в Agile Model:

Предимства на Agile модел:

• Реалистичен подход към разработването на софтуер.
• Насърчава работата в екип.
• Елиминира несъответствието между изискванията и тестовите случаи.
• Бързо и изисква минимално количество ресурси.
• Подходящ за големи и дългосрочни проекти.
• Добре за променящи се изисквания.
• Лесен за управление.

Недостатъци на Agile модел:

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

# 4) Спирален модел

Спиралният модел включва итеративен подход за развитие заедно със системния подход на модела на водопада. Той е подобен на инкрементния модел и акцент върху анализа на риска.

Спиралният модел има четири етапа:

• Фаза на планиране
• Анализ на риска
• Инженерна фаза
• Фаза на оценка

1) Фаза на планиране: На тази фаза изискванията се събират и преразглеждат, за да се финализира тестовият случай.

2) Анализ на риска: Този етап включва идентифициране, наблюдение и оценка на управленските рискове. Изискванията се анализират, за да се идентифицират рисковете, като се използват техники като мозъчна атака, разходка и т.н.

3) Инженерна фаза: В тази фаза софтуерът се разработва и тества в края.

4) Фаза на оценка: Това е последният етап, когато клиентът оценява резултатите от даден проект и дава обратна връзка за следващата спирала или одобрение.

Изобразително представяне на спирален модел:

Кога да използвам спирален модел:

• За високорискови проекти.
• Когато изискванията са сложни.
• Ако даден проект е голям.
• Имайте достатъчно време за получаване на обратна връзка от следващата спирала.
• Изисква значителни промени поради изследвания и проучвания.
• Потребителите не са сигурни в своите нужди.

Предимства на спиралния модел:

• Избягване на риск, тъй като включва голямо количество анализ на риска.
• Бързо развитие.
• Промените в изискванията се приспособяват лесно.
• Изискванията могат да бъдат получени по-точно.

Недостатъци на спиралния модел:

• Комплексно управление.
• Не е подходящ за малки проекти.
• Може да включва не. на спирали (неопределено).
• Скъпо.
• Изисква голям обем анализ на риска и опит за успеха на техния проект.

# 5) Модел RAD

Бързото разработване на приложения (RAD) е вид инкрементален модел. При този подход компонентите се разработват паралелно.

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

Фазите в RAD са както следва:

• Бизнес моделиране: Идентифицира жизненоважна информация и нейния поток между различни бизнес канали.
• Моделиране на данни: Информацията, събрана на предишния етап, се използва за дефиниране на обекти от данни, необходими за бизнеса.
• Моделиране на процеса: Обектите от данни се преобразуват, за да се получат бизнес цели и поток от информация.
• Генериране на приложения: На тази фаза се използват инструменти за автоматизация за преобразуване на модела на процеса в действителен код.
• Тестване и оборот: Тества всички компоненти на системата, поради което общото време за тестване е намалено.

Предимства на модела RAD:

• Напредъкът може да бъде измерен.
• Намалява времето за разработка.
• Повишена повторна употреба.
• Бързи първоначални прегледи.
• Подобрява обратната връзка с клиентите.

Недостатъци на модела RAD:

• Изисква висококвалифицирани ресурси.
• Оценка на високи разходи.
• Не е приложимо за по-евтини проекти.
• Висока зависимост от уменията за моделиране.
• Само модулирана система може да бъде изградена с помощта на RAD.

Разлика между методологии за тестване и стратегии за тестване

Отговорът на това не е много сложен, тъй като има проста разлика между двете.

Методологии за тестване са методите или подходите за тестване, които включват от модулно тестване до системно тестване.

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

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

Някои от тях са изброени по-долу:

1) Тестване на единица:

• Фокусира се върху много малки функционални единици.
• Най-простият начин за проверка на най-малките единици за изолация.
• Обикновено се извършва от разработчици.

2) Интеграционно тестване:

най-доброто безплатно премахване на вируси и зловреден софтуер

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

3) Функционално тестване:

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

4) Регресионно тестване:

Проверява дали отстраняването на грешки се е случило на едно място, така че сложните функционалности да не причиняват промени в друга основна област.

5) Тестване на системата:

• Тестване на всички интегрирани модули като колективна система.
• Комбинира множество функции в сценарии от край до край.

6) Тестване на производителността:

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

7) Изпитване за приемане :

• Като цяло Последно ниво на тестване, където софтуерният продукт се изследва от гледна точка на потребителите от тестерите
• Резултатът от тази стъпка е субективен и отнема малко време, за да се намери точен проблем

Заключение:

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

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

Споделете вашите мисли / предложения в раздела за коментари по-долу.

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

• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Тестване на софтуер QA Assistant Job
• Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
• Изборът на софтуерно тестване като кариера
• Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
• Някои интересни въпроси за интервю за тестване на софтуер
• Обратна връзка и рецензии на курсове за софтуерно тестване
• Тестване на софтуер Помощ Партньорска програма!