Софтуерно осигуряване на качеството

от Уикипедия, свободната енциклопедия
Карта с всички процеси, съпътстващи осигуряването на качеството

Софтуерното осигуряване на качеството (на английски: Software Quality Assurance, SQA) се състои от средства за наблюдение на процесите на софтуерното инженерство, както и методите, използвани за осигуряване на качеството. Методите, чрез които това се постига, са много и варират, като могат да включват осигуряване на съответствието с изискванията на един или повече стандарти като тези от групата ISO 9000 или модели като CMMI.

Според терминологията на IEEE качеството на софтуера се дефинира в две насоки:

  • степента, в която дадена система, компонент или процес отговаря на определените изисквания
  • степента, в която дадена система, компонент или процес отговаря на клиентските (потребителски) потребности или очаквания.

История[редактиране | редактиране на кода]

Разделението на термините „отстраняване на грешки“ и „тестване“ (изпитване) първоначално е представено от Glenford J. Myers през 1979 г. Той е смятал, че успешен тест е този, който успее да открие бъг. Софтуерната общност предлага да се разделят тези две фундаментални дейности и така Dave Gelperin и William C. Hetzel класифицират през 1988 г. фазите и целите на софтуерното тестване, разделяйки ги на следните етапи:

  • До 1956 г. – дотогава тестването било асоциирано с дебъгването и не се правила разлика между двата термина
  • 1957 – 1978 г. – период на демонстрациите, когато тестването и дебъгването били изтъквани
  • 1979 – 1982 г. – „унищожителен“ период, когато главната цел била да се откриват грешки
  • 1983 – 1987 г. – този период е класифициран като период на оценка. Представя се терминът измерване на качеството.
  • 1988 – 2000 г. – период на предотвратяване – тогава тестовете трябвало да покажат, че софтуерът покрива нужните критерии, засичат се грешки и се предотвратяват бъдещи такива.

Ролята на тестването при разработката на софтуер[редактиране | редактиране на кода]

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

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

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

Най-общо ролята на тестването може да се разграничи на:

  1. редуциране риска от проблеми
  2. намаляване в дългосрочен план на разходите, свързани с грешки
  3. допринасяне за качеството на софтуера
  4. помага за постигане на съответствие със стандартите:
    1. договорни или законови изисквания
    2. промишлени стандарти

Други ползи от тестването са:

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

Тестване[редактиране | редактиране на кода]

Тестването като понятие може да се дефинира в две насоки:

  • процес на изпитване на софтуера – за установяване дали са покрити посочените изисквания и за откриване на грешки
  • процес на анализиране на софтуерен продукт – за откриване на разликите между съществуващите и необходимите условия (т.е. „бъгове“) и за оценка на функциите на продукта.

Основни документи, използвани в процеса на тестването:

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

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

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

Методи на тестване[редактиране | редактиране на кода]

Софтуерните методи за тест традиционно се разделят на White Box и Black Box тестване. Тези два метода се използват за описване на подхода на QA инженерите при проектиране на тестовете.

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

Техниките, използвани в White Box Test, включват:

  1. API testing (програмен интерфейс на приложения) – тестване на приложение, използващо публичния и частния APIs.
  2. Code coverage – създаване на тестове, за да се отговаря на някои критерии за код покритие (например: създава се тест, за да се изпълни програмата поне веднъж)
  3. Fault injection methods – умишлено се въвеждат грешки, за да се прецени ефективността на изпитване
  4. Mutation testing methods
  5. Static testing methods
  • Black Box разглежда функционалността, без тестващият QA инженер да знае дали е правилна имплементацията. Тестващият е наясно само с това, което програмата е трябвало да направи, а не как го прави. Black Box тестове имат за цел да тестват функционалността на софтуера в съответствие със зададените изисквания. Това ниво на изпитване обикновено изисква задълбочени тестове. След това се проверява дали за даден вход изходната стойност (или поведение) е: „е“ или: „не е“ същата като очакваната стойност, определена в теста.

Съществува и трети метод на тестване:

  • Grey-Box включва познаване на вътрешните структури от данни и алгоритми. Тестващият не се изисква да има пълен достъп до изходния код на софтуера. Използва се, когато има тест на два интегрирани модула с код, писани от различни разработчици.

Седем принципа на тестването[редактиране | редактиране на кода]

  1. Тестването показва наличието на дефекти – т.е. тестването не доказва липсата на дефекти
  2. Изчерпателно тестване е невъзможно – според ресурсите (време, хардуер и т.н.) се избират подходящите тестове
  3. Ранно тестване – тестването трябва да започне колкото се може на по-ранен етап – спестяват се време и разходи
  4. Групиране на грешките – обикновено малък брой модули съдържат по-големият процент дефекти
  5. „Пестицид“ парадокса – повтарящите се тестове губят своята ефективност, което налага постоянната промяна на тестовете
  6. Тестването зависи от контекста на софтуера – различният софтуер се тества по различен начин, например един сайт за електронна търговия се тества по съвсем различен начин от софтуер за авиацията
  7. Заблудата „липса на грешки“ – дори да бъдат намерени и отстранени грешките в софтуера, това не означава, че софтуерът ще бъде използваем и ще отговаря на нуждите на клиента

Основни етапи и дейности[редактиране | редактиране на кода]

Етапи на тестовия процес
Етапи на тестовия процес
  1. Планиране и контрол
  2. Избиране на условията за тестването
  3. Проектиране и изпълнение на случаите за тестване
  4. Проверка на резултатите
  5. Оценяване на критериите за изход от програмата
  6. Докладване за процеса на тестване и състоянието на тестваната система
  7. Финализиране или завършване на заключителните действия

Основни цели при тестването[редактиране | редактиране на кода]

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

Видове тестване[редактиране | редактиране на кода]

  • Инсталационно тестване – показва дали системата е правилно инсталирана спрямо клиентския хардуер.
  • Тест за съвместимост – тества се дали продуктът е съвместим със средата, в която ще се ползва. Проверява се дали няма да има конфликт с някоя друга програма, инсталирана на системата.
  • „Разумно тестване“ и „Пушачен тест“ (Smoke test)– разумното тестване определя дали може да се пристъпи към по-нататъшно тестване. Пушачния тест се използва, за да се намери дали има сериозни софтуерни проблеми преди по-нататъшни действия.
  • Регресивно тестване – показва дали има съществуващи бъгове при добавянето на нов код. Ако програмата допреди е работила коректно и изведнъж започнат да се появяват проблеми, се използва регресивното тестване за откриване на проблема.
  • Приемно тестване – извършва се от клиента, на негова машина. Клиента използва Пушачен тест, за да открие дали има някакви несъответствия в софтуера, спрямо неговите изисквания.
  • Алфа тестване – сформира се отбор от Quality Assurance представяйки си, че са крайния клиент. Това е първичен тест, след който следва Бета тестване.
  • Бета тестване – използва се след Алфа тестването. Софтуера се предоставя на лица извън програмния отбор, за да може да се вземе фийдбек и от тях.
  • Функциониращо срещу нефункциониращо тестване – функциониращото тестване се използва, когато дадена операция има конкретен резултат. Тества се дали резултата отговаря на документацията на софтуера. Нефункциониращото тестване се използва в случаи, когато програмата има непредвидимо поведение.
  • Разрушително тестване – използва се, за да се види, дали програмата работи коректно в условия на грешка. Умишлено се причинява грешка, след което се наблюдава поведението на софтуера.
  • Тестване на изпълнението – тества се скоростта на изпълнение в конкретна среда. Работи се с големи по обем данни, също се симулира работа в стресова среда.
  • Потребителско тестване – тества се дали интерфейса на програмата е достатъчно разбираем.
  • Тестване за достъпност – използва се, за да се провери дали всякакви среди са подходящи за програмата и дали всеки потребител би могъл да ползва програмата.
  • Тест по сигурността – важен тест, който предотвратява бъдещи опити за злонамерени действия срещу програмата. Много важен тест, когато се работи с поверителна информация.
  • Интернационализация и локализация – тест, който проверява дали софтуера би работил нормално в различна часова зона, на друг език (без да има превод, само с псевдо локализация)
  • Развиващ тест – използва се още преди софтуера да се предостави на QA за тест. Премахват се множество грешки, оправят се синхронизации – по този начин QA имат по-малко работа, така се спестяват време и разходи.

Разлика между дебъгване и тестване[редактиране | редактиране на кода]

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

Автоматизирано тестване[редактиране | редактиране на кода]

Чрез софтуера за автоматизирано тестване се проверяват за бъгове множество еднотипни задачи. Използвайки такъв софтуер се намалява времето и усилията за тестване. Недостатъците на този софтуер са невъзможността на автоматизираната програма да оцени удобството за потребителя и откриването само на бъгове включени за тестване.

Selenium е javascript базиран софтуер за тестване на уеб приложения. Тестовете които използва Selenium могат да бъдат на езиците C#, PHP, Java, Ruby, Python, Perl, Javascript. Selenium софтуерът има различни разновидности(Selenium WebDriver, Selenium Grid, Selenium Remote Control, Selenium IDE). Selenium IDE например се инсталира като приставка и работи използвайки браузъра Mozilla Firefox. Selenium Grid дава възможността за тестване под различни браузъри и операционни системи.

Списък на по-известните програми за автоматизирано тестване[редактиране | редактиране на кода]

Създадена от Последна версия
AutoIt Jonathan Bennett & AutoIt Team 3.3.8.1
Cucumber Open source 1.0.2
eggPlant TestPlant 2012
EiffelStudio AutoTest Eiffel Software 7.1, Jun 2012
FitNesse Open source v20111026
HP QuickTest Professional HP Software Division 11.5
IBM Rational Functional Tester IBM Rational 8.3.0
LabVIEW National Instruments 2011
Maveryx Maveryx 1.3.1
Oracle Application Testing Suite Oracle Corporation 12.1
QF-Test Quality First Software GmbH 3.5.2
Ranorex Ranorex GmbH 4.0.5
Rational robot IBM Rational 2003
Robot Framework Open source 2.7.5
Selenium Open source 2.33.0
Sikuli Open source X 1.0
SilkTest Borland 14.0
Soatest Parasoft 9.5
TestComplete SmartBear Software 9.1
Testing Anywhere Automation Anywhere 8.0
TestPartner Micro Focus 6.3
Test Studio Telerik 2012
Time Partition Testing (TPT) PikeTec GmbH 4.2
TOSCA Testsuite TRICENTIS Technology & Consulting 7.5.0
Visual Studio Test Professional Microsoft 2012
Watir Open source 3.0

Вижте също[редактиране | редактиране на кода]

Източници[редактиране | редактиране на кода]

  Тази страница частично или изцяло представлява превод на страницата Software quality assurance в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​