Тестване на софтуера

Software Engineering, 7th edition. Chapter 23 Slide 1

Тестване на софтуера


Цели

Да се обсъди разликата м/у валидиращо тестване и тестване за дефекти

Да опише принципите на тестването на с-ма и компонента

Да опише стратегиите за генериране на тестови случаи за с-мата

Да се разберат основните х-ки на средствата използвани за автоматизиране на тестовете.


Основни теми

Тестване на с-мата Тестване на компонентите Проектиране на тестовите случаи Автоматизация на тестването


Процес на тестване

Тестване на компонентите• Тестване на индивидуални програмни компоненти• Обикновено разработчикът е отговорен за него (освен

за някои критични с-ми)• Тестовете се извличат от опита на разработчика.

Тестване на с-мата• Тестване на групи от компоненти интегрирани да

съдадат с-ма или подс-ма.• За него е отговорен независим екип за тестване.• Тестовете се основават на с-мната спецификация


Фази на тестване

Componenttesting

Systemtesting

Software developer Independent testing team


Тестване за дефекти

Целта е да се открият дефекти в програмата

Успешен тест за дефекти е този, който кара програмата да се държи не по нормалния начин

Тестовете показват наличието, а не отсъствието на дефекти


Цели на тестовия процес

Валидиращо тестване• Да демонстрира на разработчика и на клиента, че

софтуерът отговаря на изискванията му.• Успешен тест е този, който показва, че с-мата

действа, както е замислена Тестване за дефекти

• Да открие грешки или дефекти в софтуера, където поведението е неправилно или има несъответствие със спецификацията;

• Успешен тест е този, който предизвиква неправилно действие или разкрива дефект.


Процес на тестване на софтуера

Design testcases

Prepare testdata

Run programwith test data

Compare resultsto test cases

Testcases

Testdata

Testresults

Testreports


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

Политиките дефинират подхода, който се използва при избор на тестовете на с-мата • Трябва да се тестват всички функции

извиквани от меню• Трябва да се тестват комбинациите от функции

викани от едни също меню• Когато се очаква вход от потребителя, трябва

да се тестват всички функции с правилни и неправилни данни.

Политики за тестване


Тестване на с-мата

Извършва интегрирането на компоненти за създаване на с-ма или подс-ма

Може да включва тестването на инкременти, които се предават на клиента.

Две фази:• Интеграционно тестване. Екипът има достъп до сорс

кода на с-мата. С-мата се тества с интегрирането на компонентите.

• Тестване на изданието. Екипът тества готовата за издаване с-ма като черна кутия.


Интеграционно тестване

Включва изграждането на с-мата от и тестването й за проблеми, които могат да възникнат от взаимодействието на компонентите.

Интегриране отгоре-надолуРазработва се скелета на с-мата и се запълва с компоненти

Интегриране отдолу нагореИнтегрират се инфраструктурните компоненти и след това

функционалните С-мите трябва да се изграждат инкрементално, за

да се опрости локализацията на грешките


Инкрементално интеграционно тестване

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Test sequence 1 Test sequence 2 Test sequence 3


Подходи за тестването

Валидиране на архитектуратаИнтегриращото “отгоре-надолу” тестване е по-добро при

откриване на грешки в с-мната архитектура Демонстрация на с-мата

Интегриращото “отгоре-надолу” тестване позволява ограничена демонстрация в ранен етап на разработката

Осъществяване на тестаЧесто е по-лесно с интегриращото “отдолу-нагоре”

тестване Наблюдение на тестовете

Проблеми и при 2-та подхода. Може да се изисква допълнителен код за наблюдение на тестовете


Тестване на изданието

Това е процесът на тестване на изданието, което ще се достави на клиентите

Основна цел да се повиши увереността на доставчика, че с-мата отговаря на изискванията.

То обикновено е “черна кутия” или функционално тестване• Основава се само на спецификацията;• Тестващите нямат представа от

осъществяването.


Тестване “черна кутия”

IeInput test data

OeOutput test results

System

Inputs causinganomalousbehaviour

Outputs which revealthe presence ofdefects


Насоки за тестването

Това са съвети за тестващия екип, за да им помогнат да изберат тестове, които ще открият дефекти в с-мата • Избери входни данни, които карат с-мата да

генерира всички съобщения за грешки.• Проектирай входа така, че буферите да се

препълнят• Повтори един и същ вход или

последователност от входове няколко пъти• Предизвикай невалиден изход;• Предизвикай много големи или много малки

резултати от изчисленията.


Сценарий за тестване

Студентка от Шотландия изучава американска история и има задание да напише статия за “Манталитета на границата в американския запад от 1840 до 1880”. За тази цел тя се нуждае от източници от редица библиотеки. Тя се идентифицира в с-мата LIBSYS и използва търсенето, за да открие оригинални документи от това време. Тя ги намира в различни библиотеки на американски университети и сваля копия от тях. Но за един документ и е нужно уверение от нейния университет, че е студентка и няма да го използва за комерсиални цели. Тя използва друга функция на LIBSYS, с която може да поиска такова разрешение и регистрира заявката си. Ако и се разреши, документът ще бъде прехвърлен до регистрирания библиотечен сървър и отпечатан за нея. Тя получава съобщение от LIBSYS, в което се казва, че тя ще получи мейл, когато отпечатаният документ бъде на нейно разположение.


Тестове на с-мата


Случаи на използване (Use cases)

Случаите на използване могат да са база за извличане на тестове. Те помагат да се определят операциите, които трябва да се тестват и да се проектират тестваните случаи.

От съответна диаграма на последователностите (sequence diagram) могат да се определят входовете и изходите, които да се тестват.


Диаграма на последователностите за събиране на метео-данни

:CommsController

request (report)

acknowledge ()report ()

summarise ()

reply (report)

acknowledge ()

send (report)

:WeatherStation :WeatherData


Тестване на ефективността

Част от тестовете могат да проверяват интегралните качества на с-мата акто ефективност и надеждност.

Тестовете за ефективност включват планиране на серия тестове с повишаващо натоварване, докато бързодействието стане неприемливо.


Тестване на стрес

Пуска с-мата с натоварване над максималното. Често това предизвиква показването на скрити дефекти.

Стресирането на с-мата тества поведението при срив. Това не трябва да става катастрофа. Тестването проверява за неприемлив отказ от услуги или загуба на данни

То е важно за разпределени с-ми, които могат да покажат разпадане на с-мата при претоварване на мрежата


Тестване на компоненти

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

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

• Отделна функция или метод на обект• Класове от обекти с по няколко атрибута и

методи• Съставни компоненти с дефиниран

интерфейс за достъп до функциите й.


Тестване на клас от обекти

Пълното тестване на клас включва:• Тестване на всички операции асоциирани с

един обект• Даване на стойност на атрибутите и достъп

до тях• преминаване на обекта през всички

възможни състояния Наследяването усложнява проектирането

на тестовете за класове, защото информацията за проверка не е локализирана.


Интерфейс на обекта Метео-станция

identifier

reportWeather ()calibrate (instruments)test ()startup (instruments)shutdown (instruments)

WeatherStation


Тестване на клас Метео-станция

Нужно е да се дефинират тестовите случаи за reportWeather, calibrate, test, startup и shutdown.

Като се използва моделът на състоянията, трябва да се определят последователностите от промени на състоянията и последователностите от събития предизвикващи тези състояния

Например:Waiting -> Calibrating -> Testing -> Transmitting ->

Waiting


Целите са да открият грешки в интерфейсите или неверни предположения за интерфейсите.

Особено важно за обектно ориентираната разработка, където обектите са дефинирани чрез интерфейсите си.

Тестване на интерфейсите


Тестване на интерфейсите

B

C

Testcases

A


Типове интерфейси

Параметричен интерфейсДанните предадени от една процедура на друга

Интерфейси със споделена паметБлок памет, който е общ за процедури и/или функции

Процедурен интерфейсПод-с-ма капсулира напор от процедури, които могат да

бъдат извиквани от друга под-с-ма Интерфейс чрез предаване на съобщения

Под-с-ма иска услуга от друга под-с-ма.


Грешки в интерфейсите

Неправилно използванеИзвикващата компонента извиква друга компонента и

извършва грешка при използването й, напр. грешен ред на параметрите

Неразбиране на интерфейсаПри написването на извикващата компонента са

направени неправилни предположения за поведението на извикваната компонента.

Грешки на синхронизацияИзвикващата и извикваната компоненти работят с

различни скорости и е предадена неактуална информация.


Насоки при тестването на интерфейсите

Тестовете се проектират така, че параметрите към извикваната процедура да са с гранични стойности

Когато има параметри-указатели се тестват с null Проектират се тестове, които предизвикват срив

на компонентата Използва се стресово тестване при с-ми с обмен

на съобщения При с-ми със споделена памет трябва да се

променя реда на активиране на компонентите.


Проектиране на тестовите случаи

Това са входовете и изходите, използвани да се тества с-мата

Целта е да се създаде набор от тестове, които са ефективни за валидирането и за откриването на дефекти

Подходи в проектирането:• Тестване основано на изисквания• Тестване основано на раздели от данни;• Структурно тестване.


Тестване основано на изисквания

Основен принцип на инженеринга на изискванията е, изискванията да са проверяеми

Това е техника за валидиращо тестване, при което за всяко изискване се извлича набор от тестове.


Изисквания за LIBSYS


Тестове за LIBSYS

Инициира търсене на единици, за които се знае, че са в наличност и за други, за които се знае, че ги няма, когато множеството от БД се състои от една БД.

Инициира търсене на единици, за които се знае, че са в наличност и за други, за които се знае, че ги няма, когато множеството от БД се състои от две БД.

Инициира търсене на единици, за които се знае, че са в наличност и за други, за които се знае, че ги няма, когато множеството от БД се състои от повече от 2 БД.

Избира се една БД от множество БД и се инициира търсене на единици, за които се знае, че са в наличност и за други, за които се знае, че ги няма.

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


Тестване по класове (partitions)

Входните данни и изходните р-тати често попадат в различни класове, в които всички членове на даден клас имат общи х-ки.

Всеки от тези класове се нарича клас на еквивалентност или домейн, като програмата се държи по еквивалентен начин за всеки член на класа.

За всеки клас трябва да бъде избран тестов случай.


Класове на еквивалентност

System

Outputs

Invalid inputs Valid inputs


Класове на еквивалентност

Between 10000 and 99999Less than 10000 More than 99999

999910000 50000

10000099999

Input values

Between 4 and 10Less than 4 More than 10

34 7

1110

Number of input values


Спецификация на подпрограмата за търсене

procedure Search (Key : ELEM ; T: SEQ of ELEM; Found : in out BOOLEAN; L: in out ELEM_INDEX) ;

Pre-condition-- the sequence has at least one elementT’FIRST <= T’LAST

Post-condition-- the element is found and is referenced by L( Found and T (L) = Key)

or -- the element is not in the array( not Found and

not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))


Входове, които отговарят на предусловия Входове, които не отговарят на

предусловия Входове, за които ключът е член на

масива Входове, за които ключът не е член на

масива

Подпрограма за търсене – класове на входа


Насоки за тестване (последователности)

Тествайте с последователности, които имат само 1 стойност

Използвайте последователности с различни размери в различните тестове

Направете тестове, при които се използва първия, последния и средния елемент на последователността.

Тествайте с последователност с дължина 0.


Подпрограма за търсене – класове на входа


Понякога се нарича тестване на “бяла кутия”

Извличане на тестовите случаи според структурата на програмата. Познаването на програмата се използва за определяне на допълнителни случаи.

Целта е да се изпълнят всички оператори на програмата (не всички комбинации на пътищата)

Структурно тестване


Структурно тестване

Componentcode

Testoutputs

Test data

DerivesTests


Удовлетворени предусловия, ключът е в масива Удовлетворени предусловия, ключът не е в

масива Неудовлетворени предусловия, ключът е в

масива Неудовлетворени предусловия, ключът не е в

масива Pre-conditions unsatisfied, key element not in array. Входният масив има една единствена стойност. Входният масив има четен брой стойности. Входният масив има нечетен брой стойности.

Бинарно търсене – класове на еквивалентност


Бинарно търсене – класове на еквивалентност

Mid-point

Elements < Mid Elements > Mid

Equivalence class boundaries


Бинарно търсене – случаи на тестване


Тестване на пътищата

Целта на това тестване е да се всеки път в програмата да се изпълни поне веднъж.

Изходната точка за това тестване е блок-схемата на програмата, която е граф с възли представляващи решенията и дъги – пътят =на предаване на управлението

Операторите с условия са възлите в тази диаграма.


Бинарно търсене – блок схема

elemArray [mid] != key

elemArray [mid] > key elemArray [mid] < key

1

2

3

4

5

6

7

8

9

14 10

11

12 13

bottom > top while bottom <= topbottom > top

elemArray[mid] = key


1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 1, 2, 3, 4, 5, 14 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, … 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, … Случаите на тестване трябва да се подберат

така, че да се изпълнят всички пътища Може да се използва динамичен анализатор на

програми, който да провери, че всички пътища са били изпълнени

Независими пътища


Автоматизиране на тестването

Тестването е скъпа фаза. Тестващите с-ми предлагат серия средства, които съкращават времето и общите разходи за тестване

С-ми като Junit поддържат автоматично изпълнение на тестове

Повечето тестови с-ми са отворени, защото нуждите от тестове са специфични за организацията.

Те са понякога трудни за интегриране със затворени с-ми за проектиране и анализ.


С-ма за тестване

Dynamicanalyser

Programbeing tested

Test resultsTest

predictions

Filecomparator

Executionreport

Simulator

Sourcecode

Testmanager

Test data Oracle

Test datagenerator

Specification

Reportgenerator

Test resultsreport


Адаптиране на с-мите за тестване

Могат да се разработят скриптове за симулатори на потребителски интерфейс и модели за генераторите на тестови данни

За сравнение могат ръчно да се приготвят изходи от тестовете

Могат да се разработят програми за сравнение на файлове със специално предназначение


Обобщение

Тестването може да покаже наличието на грешки в с-мата; то не може да докаже че не са останали такива

За тестването на компонентите са отговорни техните разработчици; за тестването на с-мата отговаря специален екип

Интеграционното тестване тества инкременти на с-мата; тестването на изданието тества с-мата, която трябва да се предаде на клиента.

Трябва да се използват опита и насоките при изработването на тестовите случаи при тестването за дефекти.


Обобщение

Тестването на интерфейси трябва да открива дефекти ф интерфейсите на съставните компоненти

Разделянето на класове на еквивалентност е начина за разкриване на тестови случаи – всички случаи от клас трябва да имат еднакво поведение

Структурният анализ извлича тестове от анализа на програмата.

Автоматизацията на тестовете намалява разходите за тях, като използва редица софтуерни инструменти.

Documents

Тестване на софтуера