Софт, твърд - Интернет - Оценка на качеството на тестване на софтуер
Личен опит в опитомяването на компютри
Оценка на качеството на тестване на софтуера. Част 1: Въведение
Ще обсъдим начини за оценка на качеството на тестването на софтуера. Не толкова съществуващите методи, а обосновката - защо го правят по този начин, дали е възможно да се направи по-добре и как да се действа в случаи, с които никой досега не се е сблъсквал.
Вие сте софтуерен тестер. Какви са вашите задачи? Първо проверете далипрограмата се държи споредизискванията. Отчитаме функционалните изисквания към системата или част от нея. Второ, да докладвате на клиента, че сте свършили работата сикачествено.
Първата задача изисква набор оттестове. Всеки тест е вариант на взаимодействие с тестваната система с проверка на коректността на поведението на системата. Методът на взаимодействие се определя отинтерфейса на системата, например:
- програмен интерфейс - последователност от извиквания на функции или методи;
- команден ред - стартиране с определен набор от аргументи (с предварителна подготовка на средата - файлове с данни и др.);
- графичен интерфейс - последователност от действия върху контролни елементи (бутони, полета за въвеждане и др.);
- протоколи - последователността на изпратените пакети.
Във всеки случай ще трябва да решите две основни задачи -избор на тестови данни ианализ на коректността на поведението на системата. Добре, най-малкото - справихте се с тази задача. Да преминем към втория проблем – как да убедите клиента, че сте си заслужили сандвича с хайвер?
Идеалният случай - всички опции за взаимодействие са проверени (пълно или изчерпателно тестване) - затова е идеален, за да не се срещне в действителност. Вечеима толкова много от тези опции. Това означава, че ще трябва да избирате, да търсите компромис между сложността на тестването и качеството на резултата. На този етап всички са съгласни, чее възможнода се открият грешки с помощта на тестове , нода се гарантира липсата на грешки - уви,това е невъзможно.
И така, стигнахме до необходимостта да изберем набор от тестове, който с приемлива сложност ни позволява да постигнем необходимото ниво на качество на софтуера.Процедурата за проверка дали тестовият пакет има тези характеристикитрябва да бъде формална, за да бъдеобективна, т.е. да се избягват разногласия между страните.
В такава ситуация е общоприето във всички области да се измерват някакви числени характеристики и на тази база да се прави извод за нивото на постигане на дадена цел. Тези числени характеристики се наричат метрики. Трябва да се отбележи, честойността на показателите зависи от степента на тяхнатаадекватност, тоест колко точно отразяват постигането на целта.
В този случай показателите се наричат критерии за тестово покритие, а изчислените стойности на показателя се наричат постигнатото ниво на тестово покритие.
Пример за неадекватна метрика за качество на тестване е броят на грешките, открити по време на тестване - малък брой може да означава както тестване с ниско качество, така и продукт с високо качество с тестване с високо качество. Но броят на откритите грешки може да се използва за оценка на качеството на самия продукт.
Следващият път ще разгледаме и класифицираме съществуващите критерии за покритие.
[…] Предишната част завърши със заключение за необходимостта от използване на метрики за оценка на качеството на тестването и обещание за класифициране на използваните метрики (те също са критерии за покритие на теста).Обещанията трябва да се спазват. Майърс определено е прав, когато определя тестването като процес на изпълнение на програма с цел откриване на грешки [1]. Въпреки че от моя гледна точка положителните дефиниции също имат право на съществуване, когато се опитате да ги проверите „от противно“, се получава определението на Майерс. […]