Софтуерни технологии
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
| 1.ОСНОВНИ ПОНЯТИЯ
1.1. Програми и програмни продукти 1.1.1.Хронология Естественият път за навлизане в тематиката и преди всичко в проблема програми—програмни продукти (прилики и разлики) е хронологичният. Заед- но с построяването на първите компютри от средата на 40-те години се появя- ват и първите програми за тях. Както е известно, предназначението им е било за военни цели. Доколкото в разработката и на хардуера, и на софтуера са участ- вали учени, естествено е било да се направят опити за използване на компютри- те за подпомагане на научните изследвания, преди всичко за изчисления. Много скоро, още преди края на 50-те години, ръководителите на банките установяват, че банковата дейност би могла да бъде направена по-точна и по- бърза, ако бъдат приложени компютри. Така и става и до днес банките си оста- ват едни от най-сериозните консуматори на компютърни ресурси. Отдавна е станало ясно (както впрочем и в много други области), че банково дело без компютри е просто немислимо. Постепенно компютрите навлизат в търговската дейност, в медицината, в дейността на авиолиниите и в много други области. Всяка от тях налага създа- ването на съответните програми. Компютрите обаче си остават „големи" (main frame) или се произвеждат с известни вариации нагоре (свръхкомпютри) или надолу (мини). Във всички случаи обаче потребителите остават или професио- налисти, или добре обучени специалисти в конкретната област на приложение. Характеристиките на софтуера (интерфейс, надеждност, лекота на усвояване и др.) са следствие от тези особености на потребителите В края на 60-те години е извършена и една решаваща за по-нататъшното развитие на софтуерното производство стъпка. Известната фирма IBM, по това време най-големият производител на хардуер и софтуер в света, въвежда т. нар. политика на unbundling. Това означава, че софтуерът, който дотогава се е давал като безплатна (поне така е било обявявано) добавка към хардуера, започва постепенно да се продава. В началото това се е отнасяло само до част от доста- вяния софтуер, постепенно обаче кръгът му се разширява. Какви са били стра- тегическите помисли на IBM c този техен ход, е предмет на обсъждане дълго време, но едно е ясно — той всъщност дава тласък за развитие на софтуерната промишленост. дява, като се създава таблица на използваните имена и срещанията им (cross- reference). Създава се и тъй нареченият статичен профил на програмата, по- казващ кои оператори са използвани и колко пъти. При потоковия анализ се построява управляващ граф на програмата и граф на обръщенията, отразяващ връзките между отделните програмни части. Потоковият анализ дава възможност да се открият няколко вида грешки: — структурни — недостижими програмни части, недопустими пресичания | в телата на цикли, рекурсивни обръщания към подпрограми, когато това не e| разрешено; в дефинирането и използването на променливи — използване на про- менлива, преди да е получила начална стойност, дефиниране на променливи, които по-нататък не се използват, установяване на случаи при цикли, управля- вани от логически израз, в които никоя от променливите, участващи в израза, не променя стойността си в тялото на цикъла; несъответствия и грешки при предаване на параметри между различни програмни части и използването на тези програмни части и параметри. Обикновено потоковият анализ се извършва на две нива: локално — за всяка програмна единица; глобално — за програмната система като цяло. Съобщенията за грешки и документиращата информация съответстват на| тези две нива. Потоковият анализ има два недостатъка: дълбочината на анализа се постига с цената на големи изчислителни ресурси, които са пропорцонални на размера на изследваните програми; поради наличието на условни или изчислителни преходи откриваните аномалии се делят на установени и на предполагаеми, т. е. на такива, които непременно ще се случат, и такива, които биха могли да се случат. Пример конструиран може би изкуствено, показва, че след статичен анализ на програма от 760 оператори са обявени 20 установени и 1700 предполагаеми аномалии. Основни тенденции при статичните анализатори са разработването им 3i програми, написани на различни езици за програмиране, и включването на ста- тичните анализатори в интегрирани системи за тестване. При динамичния анализ програмата се изпълнява по управляем и систе- матичен начин и се изследва нейното поведение, за да се потвърди функционал- ната й коректност или некоректност. При планирането на динамичния анализ се избира стратегия, подготвят с съответстващи на стратегията тестови данни и се определя начинът на тълкува не на получаваните резултати. ! Исторически първият реализиран метод за динамичен анализ е бил тъй на реченият подход на черната кутия, при който изследваната програмна час се разглежда като елемент с неизвестно съдържание. Към нея се подават входни данни и след изпълнението се получават определени резултати. За съжалени при този подход има възможност за установяване на несъответствията, без да се изясняват причините за тях. Така се достига до идеята за реализиране в „бяла кутия" — програмата се инструментира по такъв начин, че да се нат- рупва информация за поведението й по време на изпълнение. При метода на пробите за всеки изпълним оператор се дава броят на изпълненията му при конкретни входни данни. Тази справка показва не сам 62 каква част от програмата е тествана, но и кои са най-често използваните прог- рамни части. Те могат да бъдат обект на по-нататъшна оптимизация. Развитие на този метод е програмата да се инструментира така, че след изпълнението й да се създаде анотиран листинг, в който за всеки изпълним оператор освен броя на изпълненията му се дава и допълнителна информация (например за операто- ра на присвояване — каква е минималната и максималната присвоявана стой- ност, колко пъти се е променила стойността и т. н.). Друг подход е вграждане в програмата на твърдения, които първона- чално са като коментари, но могат да се активизират за целите на динамичните анализатори. Тези твърдения описват някакви условия и какви да бъдат дейст- вията при нарушаването им. Формално-функционалните анализатори реализират „символично из- пълнение на програмата". Програмата се разглежда като изчислима функция, която може да се декомпозира на частични функции, изчислявани върху логи- ческите пътища в програмата с подмножество на входните данни. Сложността на тези анализатори е близка до сложността на системите за доказване правилността на програми и затова практическото им използване за- сега е ограничено. Мутационните анализатори генерират мутанти на изследваните прог- рами чрез внасяне на различни по вид и сложност грешки. След това се изслед- ва приложимостта на избрана съвкупност от тестови данни и чувствителността на избран метод към типа на внесените грешки. б) Генератори на тестови данни Тези програмни средства подпомагат или реализират съставянето на тесто- ви данни в съответствие с избрана стратегия на тестване. Например при структурните стратегии на тестване проблемът е да се избе- рат тестови данни, които ще предизвикат изпълнението на неизпълнявана досе- га програмна част. Ясно е, че автоматичното генериране на тестове в този слу- чай изисква сложен анализ с цел да се определи дали има осъществим път от началото на програмата до тази програмна част; от стойностите на кои промен- ливи зависи изпълнението й и т. н. в) Помощни програмни средства Те подпомагат определени стъпки от процеса на тестване — планиране, оценяване на постигнатото ниво на тестваност, реализиране на определен сце- нарий на тестване, документиране и др. г) Интегрирани системи за тестване Интегрираните системи (понякога наричани среди за тестване) могат да подпомагат няколко метода на тестване или да реализират изцяло избран метод на тестване, като автоматизират планирането, генерирането на тестови данни, управляемото изпълнение, анализа на получаваните резултати и оценяване на ефективността на тестването [2]. 5.1.4. Осъществяване на тестването Натрупаният практически опит показва, че резултатите от тестването уста- новяват наличие на грешки и дефекти твърде късно — тогава, когато програм- ният продукт е почти завършен. Доказано е, че усилията за отстраняване на 63 грешките растат експоненциално в зависимост от дължината на времевия ин- тервал t, определен от момента на допускане на грешката t1, до момента на отк- риването на грешката .: Затова се разработват специални методи и техники, позволяващи ранното: откриване и отстраняване на грешки. Изтегляне 2.27 Mb. Сподели с приятели:
|