дома › Инсталација и конфигурација › Тестирање на софтверски производ. Како да се тестира функционалноста на функција која користи други функции во неа? Тестирање поврзано со промени

Тестирање на софтверски производ. Како да се тестира функционалноста на функција која користи други функции во неа? Тестирање поврзано со промени

Дури и ако сте толку толерантни што можете да ја рестартирате програмата 18 пати по падот во рок од половина час и дури потоа да го фрлите мониторот директно на прозорецот, ќе се согласите дека работата со оваа програма би била поудобна доколку не „падне “.

Како можете да бидете сигурни дека случаите на падови, замрзнување или неисполнување на потребните дејства од програмата што сте ја развиле стануваат многу ретки?

Нема точен одговор на ова прашање. Но, низ вековите, најмудрите научници размислувале за оваа тема со години и успеале да најдат лек кој, ако не ги отстрани сите програмски грешки, тогаш барем создава илузија за акција за нивно отстранување.

И овој лек се нарекува ТЕСТИРАЊЕ на софтверскиот производ.

Според мудрите луѓе, тестирањето е еден од најпотврдените начини за обезбедување на квалитетот на развојот софтвери е дел од збир на ефективни алатки модерен системобезбедување на квалитетот на софтверскиот производ.

Квалитетот на софтверскиот производ се карактеризира со збир на својства кои одредуваат колку е „добар“ производот од гледна точка на засегнатите страни, како што се клиентот на производот, спонзорот, крајниот корисник, развивачите на производи и тестерите, инженерите за поддршка, маркетингот , обука и продажен персонал. Секој од учесниците може да има различна идеја за производот и колку е добар или лош, односно колку е висок квалитетот на производот. Така, поставувањето на проблемот за обезбедување квалитет на производот резултира со задача да се идентификуваат засегнатите страни, нивните критериуми за квалитет и потоа да се најде оптимално решение кое ги задоволува овие критериуми.

Кога и кој?

Според искусни развивачи, тестирањето на софтверски производ треба да се изврши уште од самиот почеток на неговото создавање. Но, во исто време, самите искусни програмери не треба да учествуваат во тестирањето, бидејќи ова не е кралска работа. Софтверскиот производ мора да биде тестиран од специјално обучени вработени наречени тестери, бидејќи ниту најискусниот развивач нема да може да ја види својата грешка, дури и користејќи ги најновите оптички инструменти.

Сепак, сите развивачи се согласуваат дека тестирањето на софтверски производ од гледна точка на класификација по намена треба да се подели во две класи:

Функционално тестирање
Нефункционално тестирање

Функционално тестирање

Функционалното тестирање значи проверка на усогласеноста на софтверски производ со функционалните барања наведени во техничките спецификации за создавање на овој производ. Едноставно кажано, функционалното тестирање проверува дали софтверскиот производ ги извршува сите функции што треба.

Така, конечно решивте да спроведете функционално тестирање. Ја разгледувате техничката спецификација, ги читате функционалните барања и сфаќате дека барем тие не се по редоследот по кој може да се направи тестирање. Ќе се изненадите што многу одамна, други веќе го забележале ова несовпаѓање и сфатиле како да го надминат.

За спроведување на функционално тестирање, персоналот на одделот за техничка контрола развива програма за документи и методологија за тестирање на функционалноста на апликацијата (API). Документот PMI содржи листа на сценарија за тестирање на софтверски производи (тест случаи) со Детален описчекори. Секој чекор од сценариото за тестирање се карактеризира со активностите на корисникот (специјалист за тестирање) и очекуваните резултати - одговорот на програмата на овие дејства. Тест програмата и методологијата мора да ја симулираат работата на софтверскиот производ во реален режим. Тоа значи дека сценариото за тестирање треба да биде изградено врз основа на анализа на операциите што ќе ги вршат идните корисници на системот, а не да биде вештачки составена низа од манипулации разбирлива само за развивачот.

Вообичаено, функционалното тестирање се врши на две нивоа:

Тестирање на компоненти (единица). Тестирање на поединечни компоненти на софтверски производ, фокусирано на нивните специфики, намена и функционални карактеристики.
Тестирање за интеграција. Овој типтестирањето се врши по тестирањето на компонентите и е насочено кон идентификување на дефекти во интеракцијата на различни потсистеми на ниво на контролни текови и размена на податоци.

Нефункционално тестирање

Нефункционалното тестирање ги оценува квалитетите на софтверскиот производ, како што се ергономијата или перформансите.

Мислам дека важноста на овој тип на тестирање е јасна и не бара оправдување. На крајот на краиштата, сите разбираат дека ако, на пример, перформансите на системот не се доволни, тогаш корисниците ќе мора да чекаат половина ден за одговор на нивните постапки, што може да доведе до нивно масовно хибернација.

Како што сугерира името, нефункционалното тестирање потврдува дека софтверскиот производ ги исполнува нефункционалните барања на Услови за работењеза неговото создавање. И, како и во случајот со функционалното тестирање, развиена е програма за тестирање и методологија за нефункционално тестирање.

Тестирање на вграден софтвер и усогласеност во агилната ера

Усогласеноста со индустриските стандарди не е нешто што можете да го занемарите или да го направите подоцна; тој е составен дел од процесот на развој на вграден софтвер (софтвер). За некои индустрии - како што се авиониката, автомобилската индустрија и здравството - строгото почитување на стандардите за квалитет во развојот на сложени и непроблематични вградени системи е од витално значење за да се донесе производ на пазарот. Традиционално, тестирањето игра важна улога во развојот на вградени системи за индустрии регулирани со стандарди. Сепак, во последниве години, воспоставените практики и процеси за тестирање, нивното место и улога во вакви проекти, значително се променија. Тоа беше промена на играта, и кога правилата на играта се менуваат, мора да се менувате со нив за да победите.

Со постојаниот развој на нови, најсовремени технологии, компаниите треба брзо да понудат производи на пазарот кои се сигурни, безбедни, лесни за користење и компатибилни со други системи - само за да не се изгубат во брзо менувачкиот технолошки свет. Во таква ситуација, традиционалниот модел на водопад, каде што процесот на развој на софтвер е строго последователен и тестирањето се врши на самиот крај, станува минато. DevOps и Agile методите стануваат сè попопуларни затоа што им овозможуваат на инженерите да ги завршуваат задачите кои претходно се следеа една со друга истовремено.

Тестирање на перформанси

За време на фазата на тестирање на перформансите, првиот чекор е тестирање на оптоварување, чија цел е да се провери дали системот адекватно ќе одговори на надворешните влијанија во режим близок до реалниот живот.

Покрај тестирањето на оптоварување, тестовите се вршат во услови на минимално хардверско и максимално оптоварување - стрес-тестирање, како и тестови во услови на максимален волумен на обработени информации - волуметриско тестирање.

Постои уште еден вид на тестирање: тестирање на стабилност и доверливост, кое вклучува не само долгорочно тестирање на софтверски производ во нормални услови, туку и неговата способност да се врати во нормална работа по кратки периоди на стресни оптоварувања.

Документација за тестирање

Како што споменавме погоре, тестирањето се врши во согласност со програмата и методологијата за тестирање, која е развиена во согласност со ГОСТ 34.603-92.

За тестирање, ние се развиваме тест случај, кој треба да содржи доволно податоци за проверка на сите начини на работа на софтверскиот производ. Вообичаено, тест-случајот се креира заеднички од клиентот и изведувачот врз основа на реални податоци.

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

За време на тестирањето, се составува протокол за тестирање, кој содржи информации за завршувањето на сите фази и чекори на тестирање и коментари добиени за време на тестирањето.

Доколку резултатот од тестот е негативен, недостатоците се коригираат и повторно се тестираат.

Истражувачко тестирање

Истражувачко тестирање (ад хок тестирањето е подтип на функционално тестирање. Се користи во брзорастечки проекти со флексибилни развојни методи, каде што нема јасна документација и барања. Истражувачкото тестирање е највисоката аеробатика во тестирањето на софтверот. Квалитативното тестирање е достапно за висококвалификувани специјалисти и речиси целосно зависи од изведувачот, неговото искуство, знаење (и во предметната област и во методите за тестирање) и способноста брзо да се дојде до суштината.

Тестирање на стрес

Тестирањето на оптоварување е процес на анализа на перформансите на системот што се тестира под оптоварување. Целта на тестирањето на оптоварувањето е да се одреди способноста на апликацијата да издржи надворешни оптоварувања. Обично, тестовите се вршат во неколку фази.

1. Генерирање тест скрипти

За ефикасна анализа, сценаријата мора да биде што е можно поблиску до реалните случаи на употреба. Важно е да се разбере дека исклучоците се секогаш можни, па дури и најдеталниот план за тестирање може да не опфати ниту еден случај.

2. Развој на тест конфигурација

Имајќи тест сценарија, важно е да се дистрибуира редоследот на зголемување на оптоварувањето. За успешна анализа, неопходно е да се идентификуваат критериумите за евалуација на перформансите (брзина на одговор, време за обработка на барањата итн.).

3. Спроведување на тест тест

При спроведување на тестови, важно е навремено да се следи извршувањето на сценаријата и одговорот на системот што се тестира. Емулирањето на големи оптоварувања бара сериозна хардверска и софтверска инфраструктура. Во некои случаи, методите на математичко моделирање се користат за да се намалат трошоците за работа. Податоците добиени при мали оптоварувања се земаат како основа и се приближуваат. Колку е повисоко нивото на симулираното оптоварување, толку е помала точноста на проценката. Сепак, овој метод значително ги намалува трошоците.

Тест на автоматизација

Главната карактеристика на автоматското тестирање е способноста за брзо спроведување на регресивни тестови. Главните предности на автоматизацијата (според извештајот на Worksoft) се зголемена ефикасност на персоналот, порано откривање на дефекти и друго висок квалитетделовните процеси. Овие предности се компензирани со значителен недостаток: високата цена - поради високите трошоци за спроведување и поддршка на автоматизација на тестовите, околу 50% од компаниите сè уште користат главно рачно тестирање.

Тестирање на употребливост

Секоја апликација е креирана со цел да се користи. Леснотијата на користење е важен индикатор за квалитет на програмата. ИТ индустријата знае многу примери на проекти кои полетуваат по успешното поправање на употребливоста. Колку е поширока публиката, толку е поважен факторот на употребливост. Тестирањето на употребливост вклучува детална анализа на однесувањето на корисниците. За да се процени ергономијата, важно е да имате податоци не само за брзината на завршување на деловната задача, туку и за емоциите на корисникот, изразите на лицето и гласовниот тембр.

Конфигурациско тестирање

Конфигурациското тестирање дава доверба дека апликацијата ќе работи на различни платформи, а со тоа и за максимален број корисници. За WEB апликациите, обично се избира тестирање со вкрстени прелистувачи. За Windows апликации - тестирање на различни оперативни системии големини на битови (x86, x64). Важна компонента на конфигурациското тестирање е инфраструктурата за тестирање: за спроведување на тестови, треба постојано да одржувате флота од машини за тестирање. Нивниот број варира од 5 до неколку десетици.

Тестирање за интеграција

Ако вашиот проект има повеќе од една компонента, потребно е тестирање за интеграција. Со комплексна архитектура на апликации, неопходен услов за обезбедување квалитет е проверка на интеракцијата на програмските делови. Тестирањето се постигнува со развивање и спроведување случаи „од крај до крај“. Тестирањето за интеграција се врши по тестирањето на компонентите. Затоа, многу е важно да се земе предвид искуството од тестирањето на компонентите, притоа почитувајќи ја деловната ориентација на тест случаите.

Тестирање на стрес

Секој систем има граница нормално функционирање. Кога ќе се надмине границата, системот оди во состојба на стрес и значително го менува своето однесување. Стрес-тестирањето ја тестира работата на апликацијата под услови што ги надминуваат границите на нормалното функционирање. Ова е особено важно за „критичните“ програми: банкарски софтвер, програми за воздухопловна индустрија, медицина. Стрес-тестирањето се врши не само во фазата на развој на софтвер, туку и во текот на целиот оперативен циклус со цел да се добијат и обработуваат податоци за однесувањето на системот во подолг временски период.

Да претпоставиме дека има функција за добивање податоци, кој враќа мапа на информации за корисничкиот ID што поминал. Сега оваа функција користи 3 функции source-a , source-b и source-c за да произведе три различни видови на мапи. Сега ќе ги комбинираме сите овие мапи во една мапа и ќе се вратиме од добивање-податоци.

Кога ги тестирам податоците за добивањедали треба да проверам дали има достапност на податоци за клучеви? Дали има смисла оваа функција да не успее тестовите на единицата ако еден од изворот-a , изворот-б и изворот-c не успее? Ако работата на таа функција е да се спојуваат податоци, и тоа го прави, тоа би требало да биде доволно, нели?

2 одговори

Да претпоставиме дека има функција за добивање податоци која враќа мапа на информации за корисничкиот идентификатор доставен до.

Одлично. Потоа треба да го проверите. За дадена лична карта, дали ги враќате точните податоци?

сега оваа функција користи 3 функции source-a, source-b и source-c за да произведе три различни видови на мапи.

Кој детал од имплементацијата треба да го игнорирате во тестот. Сè што тестирате е дека вашата единица на работа (овој метод) го прави она што треба да го направи (земи ID и врати XYZ податоци за тој ID). Какоовој метод навистина не е важен - на крајот на краиштата, клучната придобивка од овој единица тест е тоа што можете да ја рефакторирате имплементацијата на методот и тестот ќе провери дали сте го направиле правилно.

Сепак, веројатно ќе треба да се потсмевате на изворите на податоци, па во одреден момент тестот веројатно ќе треба да знае како функционира овој код. Тука треба да балансирате три конкурентни цели: да го направите тестот изолиран (со исмевање на податоците), додека тестот да се фокусира на барањата и прагматизмот.

На крајот на краиштата, ова е важен код. Постојат тестови за поддршка на вистинскиот код, трошењето многу време и маката за проверка на полирањето не е толку корисна како тестовите правење .

Во единечното тестирање треба да ја тестирате само функционалноста на една класа, ако вашите методи source-a, source-b и source-c повикуваат други класи, треба да ги исмевате (тие треба да бидат тестирани во единиците во нивните класи).

Во тестирањето за интеграција, вие го тестирате однесувањето на повеќе класи кои комуницираат меѓу нив, тоа значи дека вашата функција за добивање податоци мора да провери дали податоците што се преземаат се точни (извор-a, извор-б и извор-c се точни и податоците се поврзани правилно) .

Тестовите за единици се поедноставни и пофокусирани и треба да бидат напишани од програмери. Тестовите за интеграција обично застаруваат релативно брзо (ако ги има внатрешна компонентае променет), што ги отежнува изведбата. Мора да биде креиран од профил за QA.

И овој лек се нарекува ТЕСТИРАЊЕ на софтверскиот производ.

Според мудрите луѓе, тестирањето е еден од најпознатите начини за обезбедување на квалитетот на развојот на софтверот и е вклучено во збирот на ефективни алатки на модерен систем за обезбедување квалитет на софтверски производи.

Кога и кој?

Функционално тестирање
Нефункционално тестирање

Функционално тестирање

За спроведување на функционално тестирање, персоналот на одделот за техничка контрола развива програма за документи и методологија за тестирање на функционалноста на апликацијата (API). Документот PMI содржи листа на сценарија за тестирање на софтверски производи (тест случаи) со детален опис на чекорите. Секој чекор од сценариото за тестирање се карактеризира со активностите на корисникот (специјалист за тестирање) и очекуваните резултати - одговорот на програмата на овие дејства. Тест програмата и методологијата мора да ја симулираат работата на софтверскиот производ во реален режим. Тоа значи дека сценариото за тестирање треба да биде изградено врз основа на анализа на операциите што ќе ги вршат идните корисници на системот, а не да биде вештачки составена низа од манипулации разбирлива само за развивачот.

Вообичаено, функционалното тестирање се врши на две нивоа:

Тестирање на компоненти (единица). Тестирање на поединечни компоненти на софтверски производ, фокусирано на нивните специфики, намена и функционални карактеристики.
Тестирање за интеграција. Овој тип на тестирање се спроведува по тестирање на компонентите и е насочен кон идентификување на дефекти во интеракцијата на различни потсистеми на ниво на контролни текови и размена на податоци.

Нефункционално тестирање

Како што сугерира името, нефункционалното тестирање ја проверува усогласеноста на софтверски производ со нефункционалните барања од техничките спецификации за неговото создавање. И, како и во случајот со функционалното тестирање, развиена е програма за тестирање и методологија за нефункционално тестирање.

Тестирање на вграден софтвер и усогласеност во агилната ера

Тестирање на перформанси

Документација за тестирање

За да се изврши тестирањето, се развива тест случај, кој мора да содржи доволно податоци за тестирање на сите начини на работа на софтверскиот производ. Вообичаено, тест-случајот се креира заеднички од клиентот и изведувачот врз основа на реални податоци.

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

Доколку резултатот од тестот е негативен, недостатоците се коригираат и повторно се тестираат.

Истражувачко тестирање

Тестирање на стрес

1. Генерирање тест скрипти

2. Развој на тест конфигурација

3. Спроведување на тест тест

Тест на автоматизација

Главната карактеристика на автоматското тестирање е способноста за брзо спроведување на регресивни тестови. Главните предности на автоматизацијата (според извештајот на Worksoft) се зголемената ефикасност на персоналот, порано откривање на дефекти и повисок квалитет на деловните процеси. Овие предности се компензирани со значителен недостаток: високата цена - поради високите трошоци за спроведување и поддршка на автоматизација на тестовите, околу 50% од компаниите сè уште користат главно рачно тестирање.

Тестирање на употребливост

Конфигурациско тестирање

Конфигурациското тестирање дава доверба дека апликацијата ќе работи на различни платформи, а со тоа и за максимален број корисници. За WEB апликациите, обично се избира тестирање со вкрстени прелистувачи. За Windows апликации - тестирање на различни оперативни системи и бит-стапки (x86, x64). Важна компонента на конфигурациското тестирање е инфраструктурата за тестирање: за спроведување на тестови, треба постојано да одржувате флота од машини за тестирање. Нивниот број варира од 5 до неколку десетици.

Тестирање за интеграција

Тестирање на стрес

Секој систем има ограничување на неговото нормално функционирање. Кога ќе се надмине границата, системот оди во состојба на стрес и значително го менува своето однесување. Стрес-тестирањето ја тестира работата на апликацијата под услови што ги надминуваат границите на нормалното функционирање. Ова е особено важно за „критичните“ програми: банкарски софтвер, програми за воздухопловна индустрија, медицина. Стрес-тестирањето се врши не само во фазата на развој на софтвер, туку и во текот на целиот оперативен циклус со цел да се добијат и обработуваат податоци за однесувањето на системот во подолг временски период.

Меѓу сите видови, функционалното тестирање со право зазема водечка позиција, бидејќи програмата пред сè мора да работи правилно, инаку леснотијата на користење, безбедноста и доволната брзина нема да бидат од апсолутно никаква корист. Покрај совладувањето на различни техники за тестирање, секој специјалист мора да разбере како правилно да спроведе тест за да се добие најефикасен резултат.

Функционално тестирање: каде да се насочат главните напори?

За тестирање на единицата и системот;

За да го проверите полето „бело“ или „црно“;

За рачно тестирање и автоматизација;

За тестирање на нова функционалност или;

За „негативни“ или „позитивни“ тестови.

Помеѓу сите овие области на активност, важно е да се најде вистинскиот пат, кој ќе биде „средината“, за да се балансираат напорите, максимално искористувајќи ги предностите на секоја од областите.

Се врши верификација на софтверот различни начини, од кои едно е тестирање за црна кутија или податоци.

Програмата во овој случај е претставена од гледна точка на „црна кутија“, а тестот се спроведува за да се утврдат околностите во кои однесувањето на програмата нема да биде во согласност со спецификацијата. Сите грешки се идентификуваат преку управување со податоци, што се врши преку исцрпно тестирање, односно со користење на сите можни

Ако за некоја програма извршувањето на командата зависи од настаните што и претходат, тогаш тоа ќе бара проверка на сите можни секвенци. Сосема е очигледно дека за повеќето случаи е едноставно невозможно да се спроведе исцрпно тестирање, па почесто тие избираат прифатлива или разумна опција која е ограничена на извршување на програмата на мало подмножество од сите влезни податоци. Оваа опција целосно гарантира дека нема отстапувања од спецификациите.

Функционалното тестирање вклучува избор на вистинскиот тест. Во исто време, вообичаено е да се направи разлика помеѓу следниве методи за генерирање множества за нив:

Анализа на гранични вредности;

Еквивалентна партиција;

Претпоставка за грешка;

Анализа на врските помеѓу причините и последиците.

Можете да го разгледате секој од нив посебно.

Анализа на гранични вредности. Граничните вредности обично се подразбираат како оние лоцирани на границите на класите на еквивалентност. На такви места, најверојатно, ќе се најде грешка. Употребата на таков метод бара одредена креативност од специјалистот, како и специјализација за овој конкретен проблем што се разгледува.

Еквивалентна партиција. Сите можни множества на влезни параметри се поделени во неколку класи на еквивалентност. Податоците се комбинираат врз основа на принципот на откривање слични грешки. Општо е прифатено дека ако множество од една класа покаже грешка, тогаш еквивалентните исто така ќе ја покажат. Функционално тестирање од овој методсе изведува во две фази: во првата се идентификуваат класите за еквивалентност, а во втората веќе се формираат специјални тестови.

Анализа на причинско-последичните односи. Системот може да избере тестови со високи перформанси со спроведување на такви проверки. Во овој случај, посебна влезна состојба се зема како причина, а излезната состојба се гледа како ефект. Методот се заснова на идејата за припишување на сите видови причини на одредени последици, односно на разјаснување на истите тие причинско-последични односи. Тестирањето на софтверски производ се врши во неколку фази, што резултира со листа на причини и последователни последици.

ненамерни отстапувања на програмерите од работните стандарди или плановите за имплементација;
спецификациите на барањата за функционални и интерфејси се направени без усогласување со развојните стандарди, што доведува до нарушување на функционирањето на програмите;
организација на развојниот процес - несовршено или недоволно управување со ресурсите на проектниот менаџер (човечки, технички, софтверски и сл.) и прашања за тестирање и интеграција на проектните елементи.

Да го погледнеме процесот на тестирање врз основа на препораките на стандардот ISO/IEC 12207 и да ги дадеме типовите на грешки кои се откриени во секој процес на животниот циклус.

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

Типични грешки во овој процес се:

несоодветност на спецификацијата на барањата за крајните корисници - неточна спецификација на интеракцијата на софтверот со оперативната средина или со корисниците;
неусогласеност со барањата на клиентите за индивидуалните и општите софтверски својства;
неточен опис на функционалните карактеристики;
недостаток на достапност на алатки за сите аспекти на спроведување на барањата на клиентите итн.

Процес на дизајнирање.Грешки во дизајнот на компонентите може да се појават при опишување на алгоритми, контролна логика, структури на податоци, интерфејси, логика за моделирање на протокот на податоци, формати на влезно/излез, итн. Овие грешки се засноваат на дефекти во спецификациите на аналитичарот и недостатоци во дизајнот. Тие вклучуваат грешки поврзани со:

со дефинирање на корисничкиот интерфејс со околината;
со опис на функциите (несоодветност на целите и задачите на компонентите што се откриваат при проверка на збир на компоненти);
со дефинирање на процесот на обработка на информации и интеракцијата помеѓу процесите (резултат на неправилно одредување на односите на компонентите и процесите);
со неточна спецификација на податоците и нивните структури при опишување на поединечни компоненти и софтверот како целина;
со неточен опис на алгоритмите на модулите;
со утврдување на условите за појава на можни грешки во програмата;
со прекршување на стандардите и технологиите усвоени за проектот.

Фаза на кодирање.Во оваа фаза се јавуваат грешки кои се резултат на дефекти во дизајнот, грешки на програмерите и менаџерите при развојот и дебагирањето на системот. Причините за грешки се:

недостаток на контрола врз вредностите на влезните параметри, индексите на низи, параметрите на јамката, излезните резултати, делењето со 0, итн.;
неправилно справување со неправилни ситуации при анализа на повратните кодови од наречените потпрограми, функции итн.;
прекршување на стандардите за кодирање (лоши коментари, ирационални распределба на модулии компонента, итн.);
употреба на едно име за означување на различни објекти или различни имиња на еден објект, лоша мнемоника на имињата; - неконзистентни промени на програмата од различни развивачи итн.

Процес на тестирање.Во овој процес, програмерите и тестерите прават грешки при изведување на технологија за склопување и тестирање, избирање на тест сетови и сценарија за тестирање, итн. софтверски грешки воопшто.

Процес на одржување.Во текот на процесот на одржување се откриваат грешки кои се предизвикани од недостатоци и дефекти во оперативната документација, недоволни показатели за модификација и читливост, како и неспособност на лицата одговорни за одржување и/или подобрување на софтверот. Во зависност од природата на промените што се прават, во оваа фаза може да се појават речиси сите грешки слични на претходно наведените грешки во претходните фази.

Сите грешки што се појавуваат во програмите обично се поделени во следните класи [7.12]:

логички и функционални грешки;
грешки во пресметката и времето на работа;
влезно/излез и грешки при манипулација со податоци;
грешки во интерфејсот;
грешки во обемот на податоци итн.

Логички грешкисе причина за нарушување на логиката на алгоритмот, внатрешна неусогласеност на променливите и операторите, како и програмските правила. Функционалните грешки се последица на неправилно дефинирани функции, повреда на редоследот на нивната примена или некомплетност на нивната имплементација итн.

Грешки во пресметкатасе јавуваат поради неточност на изворните податоци и имплементираните формули, грешки во методот, неправилна примена на пресметковните операции или операнди. Грешките во траење се поврзани со неуспехот да се обезбеди потребната брзина на обработка на барањата или времето за обновување на програмата.

I/O грешкиа манипулацијата со податоците е последица на неквалитетна подготовка на податоците за извршување на програмата, неуспеси при нивното внесување во базите на податоци или при нивното преземање од нив.

Грешки во интерфејсотсе однесуваат на грешки во односот на поединечните елементи едни со други, што се манифестира при пренос на податоци меѓу нив, како и при интеракција со оперативната средина.

Грешки во јачината на звукотсе однесуваат на податоци и се последица на фактот што имплементираните пристапни методи и големини на бази на податоци не ги задоволуваат реалните волумени на системските информации или интензитетот на нивната обработка.

Дадените главни класи на грешки се карактеристични за различни видови софтверски компоненти и тие се манифестираат во програмите на различни начини. Така, при работа со база на податоци, се појавуваат грешки во презентацијата и манипулацијата на податоците, логички грешкипри специфицирање на применетите процедури за обработка на податоци итн. Кај компјутерските програми преовладуваат пресметковните грешки, а во програмите за контрола и обработка доминираат логички и функционални грешки. Софтверот, кој се состои од многу различни програми кои спроведуваат различни функции, може да содржи грешки различни типови. Грешките на интерфејсот и прекршувањата на јачината на звукот се типични за секој тип на систем.

Анализирањето на видовите грешки во програмите е предуслов за креирање тест планови и методи за тестирање за да се обезбеди исправност на софтверот.

Во сегашната фаза на развој на алатки за поддршка за развој на софтвер (CASE технологии, објектно-ориентирани методи и алатки за дизајнирање модели и програми), се спроведува дизајн во кој софтверот е заштитен од најчестите грешки и со тоа спречува појава на софтверски дефекти.

Врска помеѓу грешка и неуспех.Присуството на грешка во програмата, по правило, доведува до откажување на софтверот при неговото работење. За да се анализираат причинско-последичните врски на „грешка-неуспех“, се вршат следните дејства:

идентификација на недостатоци во технологиите за дизајн и програмирање;
односот помеѓу недостатоците во процесот на дизајнирање и човечките грешки;
класификација на дефекти, недостатоци и можни грешки, како и дефекти во секоја фаза на развој - споредба на човечки грешки направени во одреден развоен процес и дефекти на објектот, како последица на грешки во спецификацијата на проектот, програмските модели;
верификација и заштита од грешки во сите фази од животниот циклус, како и откривање на дефекти во секоја фаза на развој;
споредба на дефекти и неуспеси во софтверот за развој на систем на меѓусебни врски и методи за локализирање, собирање и анализа на информации за дефекти и дефекти;
развој на пристапи кон процесите на документирање и тестирање на софтвер.

Крајната цел на причинувањето на грешки-неуспех е да се дефинираат методи и средства за тестирање и откривање на грешки на одредени класи, како и критериуми за завршување на тестирањето на повеќе збирки податоци; во идентификување начини за подобрување на организацијата на процесот на развој, тестирање и одржување на софтвер.

Еве ја следнава класификација на типови неуспеси:

хардвер, во кој софтверот низ целиот систем е нефункционален;
информативни, предизвикани од грешки во влезните податоци и преносот на податоци преку комуникациски канали, како и дефект на влезните уреди (последица на хардверски дефекти);
ергономски, предизвикани од грешки на операторот за време на неговата интеракција со машината (овој дефект е секундарен дефект и може да доведе до информации или функционални дефекти);
софтвер, доколку има грешки во компонентите итн.

Некои грешки може да се резултат на недостатоци во дефинирањето на барањата, дизајнот, генерирањето на излезниот код или документацијата. Од друга страна, тие се генерираат при изработка на програма или при развивање на интерфејси на поединечни програмски елементи (повреда на редот на параметри, помалку или повеќе параметри итн.).

Извори на грешки.Може да се генерираат грешки при изработката на проектот, компонентите, кодот и документацијата. Како по правило, тие се откриваат за време на извршувањето или одржувањето на софтверот на најнеочекуваните и различни точки.

Некои грешки во програмата може да се резултат на недостатоци во дефинирањето на барањата, дизајнот, генерирањето код или документацијата. Од друга страна, грешките се генерираат за време на развојот на програмата или интерфејсите на нејзините елементи (на пример, кога се нарушува редоследот на поставување на параметрите за комуникација - помалку или повеќе од потребното, итн.).

Причината за грешките е недоволното разбирање на барањата на клиентите; неточна спецификација на барањата во проектните документи итн. Ова води до фактот дека се имплементирани некои системски функции кои нема да работат како што е предложено од клиентот. Во овој поглед, се спроведува заедничка дискусија помеѓу клиентот и развивачот за некои детали од барањата за да се разјаснат.

Тимот за развој на системот може исто така да ја промени синтаксата и семантиката на описот на системот. Сепак, некои грешки може да не се откријат (на пример, индексите или променливите вредности на овие изјави се погрешно поставени).

Популарни во категоријата: