Софтуерното тестване е процес на изследване и проучване на софтуер с цел получаване на информация за качеството на продукта и услугата, която се изпитва. Процесите на софтуерното тестване са неразделна част от софтуерното инженерство и осигуряване на качеството на софтуера.What is Software Testing? - Answered by community of Software Testers at Software Testing Board]
Съществуващите методи на тестване на софтуер не позволяват еднозначно и напълно да се видят, проявят и установят всички дефекти и правилното функциониране на една програма, така че методите на тестване работят в рамките на формалния процес на проверка върху изследвания или разработвания софтуер.
Обобщение Тестването на софтуер е изследване, което се прави с цел да се даде информация на всички заинтересовани страни за качеството на продукта или услугата. То трябва да даде обективна и безпристрастна оценка на софтуера, която да позволи на бизнеса да прецени и разбере рисковете от употребата му. Техниките за тестване могат да включват изпълнение на програмата с цел откриването на грешки (бъгове). Тестването на софтуер може да се разглежда като процес на валидация и верификация, че дадена компютърна програма/приложение/продукт: Отговарят на изискванията, залегнали при неговия проект и разработка Работи според очакванията Може да се въведе в употреба при тези си параметри Отговаря на нуждите на всички заинтересувани страни
Тестването на софтуера, в зависимост от избрания метод на тестване, може да се проведе по всяко време в процеса на разработка. В традиционния случай повечето тестове се провеждат след като изискванията са формулирани и етапът на писане на код е приключил. За сравнение, при гъвкавия подход на разработка, тестването е продължителен процес, който обхваща целия период на разработката, а не една отделна фаза накрая. Методологията на тестване е в пряка зависимост от метода на разработка.
Процесът на тестване не може да открие всички грешки в даден софтуер, поради тяхното разнообразие. Вместо това, той прави сравнения, служещи за съпоставка на състоянието и поведението на продукта. Създават се „оракули“ – принципи или механизми за разпознаване на проблеми. Те може да са във формата на: Спецификации Договори Еталонни продукти (benchmarking) Стари версии на същия продукт Заявки за очаквани ползи Клиентски очаквания Приложими стандарти Приложими закони Други критерии, поставени от самите разработчици
Основната цел на тестовете е да се открият софтуерни дефекти с цел тяхното отстраняване. Тестването не може да установи дали продуктът ще действа нормално при всички обстоятелства, а по-скоро при какви обстоятелства спира да действа нормално. Обхватът на тестовете може да включва проверка на самия код, неговата работа в различни среди и при различни условия, както и допълнителни аспекти: прави ли това, което се очаква и изисква от него. В съвременната индустрия често компанията, която извършва тестовете, е различна от компанията разработчик. Провеждащият тестовете има различни роли и резултатите от тестовете могат да окажат влияние върху модела и процеса на разработка.
Всеки софтуер има целева група клиенти. Например потребителите на игри се различават в изискванията и очакванията си от потребителите на банков софтуер. Следователно всяка организация, която разработва софтуер, се стреми да прецени дали продуктът им ще се приеме от крайните потребители, купувачите, инвеститорите и други заинтересовани страни. Тестването на софтуера се стреми да помогне с тази оценка.
Грешки и дефекти Не всички дефекти са породени от грешки в кода. Един чест източник на скъпоструващи дефекти е „разминаване в изискванията“, което води до пропуски в работата на разработчиците. То може да се прояви на не-оперативно ниво (не засяга сериозно работата на продукта) – например: Трудно тестване Невъзможност да поеме нарастващ обем работа (невъзможност за разширение/подобрение) Трудна поддръжка Трудна навигация Непостоянно представяне/работа Проблеми със сигурността
Софтуерните дефекти често се появяват в следната последователност. Разработчик допуска грешка (error), която довежда до дефект (defect, fault, bug) в изходния код (source code). Ако този дефект се изпълни, програмата в дадена ситуация ще даде грешен резултат, което може да предизвика срив (failure). Не всички дефекти задължително предизвикват срив. Например дефектите в неизползван/мъртъв код (dead code) няма да имат никакъв ефект. Един дефект може да се превърне в срив при промяна на обстоятелствата. Примери за подобна промяна са нова машина (хардуерен проблем), промяна във входните данни (софтуерен проблем) или съвместната работа на дадената програма с друг софтуер (комуникационен проблем). Един дефект може да доведе до различни по причина сривове.
Обхват на тестовете Фундаменталният проблем на тестването на софтуер е невъзможността да се тестват всички възможни входни данни, комбинации от условия и изисквания. Това означава, че разнообразието от дефекти в един софтуер е безкрайно голямо и колкото по-рядко се проявяват те, толкова по-трудно е да се открият чрез тестове. Още повече, че не-операционните аспекти на софтуера (как трябва да бъде, а не какво трябва да прави) са често доста субективни.
Пример: Според разработчика даденият софтуер се очаква да обслужва не повече от десет хиляди потребители, докато инвеститорът иска продукт с капацитет поне сто хиляди потребители.
Софтуерните разработчици не могат да тестват абсолютно всичко, но те могат да използват комбинирани тестове, за да си осигурят покритието, което им трябва. Комбинираните тестове позволяват да се постигне по-голямо покритие с по-малко тестове. В зависимост от това дали се търси скорост, или дълбочина на тестово проникване може да се използват комбинирани тестове за изграждане на структурирани вариации от тестове.
Икономическо отражение Според проучване на Националния институт за стандарти и технологии в САЩ от 2002 година, „софтуерните грешки костват на САЩ близо 59.5 милиарда долара годишно“. Над една трета от тези загуби могат да се избегнат, ако се прилага по-добро тестване на софтуера.
Общоприето е, че колкото по-рано се открие даден дефект, толкова по-евтино е да се отстрани. Съществуват различни изследвания за това колко ще струва отстраняването на даден дефект в зависимост от етапа на разработка, на който е възникнал, спрямо момента, в който е открит. Пример: Дефект, възникнал при определяне на изискванията, ще струва 10 – 100 пъти повече да се отстрани на етап продукт в продажба, отколкото ако е бил открит още при възникването си.
Политики за поетапно пускане в продажба и облачните технологии биха намалили подобни загуби, защото не се изисква изтегляне на продукт от продажба и бракуване на физически носители.
Комбинации за принос и прекондиции
Разликата на precondition от предварително условие е, в това, че предварителното условие се базира на вече реализирани прекондиции или това са контекстите при AI прогностиката.
Роля През 20 век тестването на софтуера се извършва предимно от самите програмисти, като по-късно се появява идеята за „софтуерен тестър“ или област за софтуерно тестване, като професионална област, като този термин се използва общо за всеки специалист извършващ дейността. В различни периоди и в зависимост от различните цели на тези специалисти са се обособили различни роли: мениджър, водещ на тест екип, анализатор на тестове, разработчик на тестове, тестър (извършващ тестовете), разработчик на автоматични тестове и системен администратор на тестовите машини. С това тестването на софтуер постепенно се е обособява и като отделна професия, която дори има своите подварианти, различни отдели и т.н.
История Отделянето на дебъгването (debugging – намиране и отстраняване на дефекти, бъгове) от тестването на софтуер е първоначално представено от Гленфорд Дж. Майерс през 1979 г. Въпреки че неговото внимание е насочено към тестове, целящи срив („успешен тест е този, който намери бъг“), става ясно, че по това време сред програмистите нараства желанието да се отделят фундаментални дейности по разработката (като „дебъгването“) от чистата верификация (виж т.11.1).
През 1988 Дейв Гелперин и Уйлям Хетцел класифицират фазите и целите на тестването на софтуер през годините: До 1956 – Насочено към дебъгване 1957 – 1978 – Насочено към демонстрация (че софтуерът работи според изискванията) 1979 – 1982 – Насочено към предизвикване на срив (теорията на Майерс) 1983 – 1987 – Насочено към оценка 1988 – 2000 – Насочено към превенция
Методи за тестване Статични и динамични тестове Има много начини за тестване на софтуер. Статичните методи са: Ревю – разработчикът или негов колега минава през целия код и следи за грешки Постъпково изпълнение – разработчикът представя кода пред заинтересованите страни или негови колеги и те задават въпроси Инспекция – специалист (често външен за проекта) преглежда методично кода и пише доклад / отчет.
За динамични се считат методи, които изискват кодът да се изпълни, програмата да се натовари с предварително подготвени тестови данни или сценарии. В практиката статичните методи често се прескачат за сметка на динамичните.
Методи, които разчитат само на преглед на кода, са статични, а тези, които изискват да се види и неговата работа, са динамични.
Динамичните тестове могат да започнат преди програмата да е на 100% завършена, като тогава говорим за тестове на отделните градивни единици – например функции и методи. Някои типични техники за това са употребата на драйвери (drivers) или работа в режим на дебъгване.
Статичните методи са свързани с верификация (verification), а динамичните с валидация (validation). Виж т.11.1.
Принципът на кутията Методите за тестване на софтуер традиционно се разделят на две групи – метод на отворената кутия () и метод на затворената кутия (). Основната разлика идва от фокуса на разработчика – дали се интересува повече как работи софтуерът, или дали работи според изискванията. Оттук и аналогията: Отворена кутия – виждаме какво се случва вътре и гледаме само навътре Затворена кутия – виждаме само какво влиза и излиза, без да ни интересува какво се случва вътре в кутията
Отворена кутия Методът на отворената кутия (известен още като clear box testing, glass box testing, transparent box testing, и structural testing) е метод за тестване на софтуер, който тества вътрешните структури или начина на действие на приложението, но не и неговата функционалност (за разлика от затворената кутия). Той се основава на вътрешния изглед на системата, както и на уменията за програмиране на този, който тества. Специалистът, който тества, избира входни данни, за да проследи обработката им от системата и определя съответните резултати. Това е аналогично на тестването „възли в схема“ (in-circuit testing, ICT).
Методът на отворената кутия може да се прилага на ниво модул (unit), на интеграционно и системно ниво, но обикновено се прави на ниво модул. Един от начините е тестване на пътя (). Може да се тества път в рамките на модула, път между отделни модули по време на интеграция, както и между подсистемите по време на тестване на системно ниво. Въпреки че този метод може да разкрие много грешки или проблеми, той не може да открие неизпълнени части на спецификацията или липсващи изисквания.
Методът на отворената кутия включва: Тестове на системата за контрол Тестове на системата за пренос на данни Тестове на разклоненията Тестове на пътищата Statement coverage Decision coverage
Преглед Методът на отворената кутия работи на ниво изходен код за предотвратяване на всякакви скрити грешки по-късно. Тестовете използват техниките за тестване, посочени по-горе, както и промяната на обсега условие/решение. Методът използва тези техники като насоки за създаване на среда без грешки чрез проучване на всякакъв чуплив код. Те изпълняват всеки видим път на изходния код, като целият смисъл на тестването е да се узнае коя линия на кода се изпълнява и да се определи какъв трябва да бъде правилният изход.