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

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

Софтуерното осигуряване на качеството (на английски: 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

Вижте също

• Осигуряване на качеството
• Тестване на софтуер

Източници

• Telerik Academy Архив на оригинала от 2013-08-31 в Wayback Machine.

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