Какво е статично тестване?

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

Статичното тестване се извършва по 2 начина:

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

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

Както бе споменато по-горе, статичното тестване се извършва или ръчно, което се извършва в рецензии или чрез инструменти за тестване, които се извършват в статичен анализ.

Процес на преглед: По време на статичното тестване Рецензиите могат да се правят по два начина:

1. Неформален преглед

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

2. Официален преглед

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

Видове отзиви

По-долу са споменати различните видове отзиви:

1. Упътване

  • В ръководството, Авторът води процеса на преглед, за да изпълни общото разбиране, а другите членове на екипа задават възможните въпроси и изпращат събраните отзиви.
  • Прегледът може да бъде официален или неофициален преглед.
  • Протоколът от срещата и докладваните дефекти / констатации се записват от Писателя (който не е Авторът), за да ги проследят по-късно.
  • Членовете на екипа не трябва да имат подробни познания за съдържанието, тъй като авторът е добре подготвен за това и това е вид сесия за трансфер на знания.

Основни цели на ръководството

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

2. Инспекция

  • Инспекцията е един от най-формалните видове прегледи.
  • Води се от обучен модератор, който не е автор на срещата.
  • Рецензенти са добре подготвени преди срещата относно документите или какво трябва да се обсъди.
  • На тази среща се използват правила и контролни списъци, по време на които се разглежда продуктът и се регистрират дефекти.
  • Намерените в срещата дефекти се документират в дневника за издаване или в списъка за регистрация.
  • Срещата има правилни критерии за влизане и излизане.
  • Докладите, създадени по време на срещата, се споделят с Автора, за да предприемат подходящи действия по този въпрос.
  • Модераторът прави официален последващ процес за справяне с проблемите с подобрението и обучаване на откритите дефекти.

Основни цели на инспекцията

  • Подобряване на качеството на документите в рамките на инспекцията.
  • Бързо намиране и коригиране на дефектите, открити в срещата.
  • Създаване на по-подробно разбиране чрез групови дискусии и обмен на информация.
  • Да се ​​поучим от вече въведените дефекти и да не ги повтаряме в бъдеще.

3. Технически преглед

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

Основни цели на техническия преглед

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

заключение

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

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

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

  1. Разбиране на концепцията за статично тестване
  2. Какво е нефункционално тестване?
  3. Примери за тестване на бяла кутия
  4. Какво прави динамичното тестване?