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

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

2. Цели • Да се обсъди разликата м/у валидиращо тестване и тестване за дефекти • Да опише принципите на тестването на с-ма и компонента • Да опише стратегиите за генериране на тестови случаи за с-мата • Да се разберат основните х-ки на средствата използвани за автоматизиране на тестовете.

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

4. Процес на тестване • Тестване на компонентите • Тестване на индивидуални програмни компоненти • Обикновено разработчикът е отговорен за него (освен за някои критични с-ми) • Тестовете се извличат от опита на разработчика. • Тестване на с-мата • Тестване на групи от компоненти интегрирани да съдадат с-ма или подс-ма. • За него е отговорен независим екип за тестване. • Тестовете се основават на с-мната спецификация

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

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

7. Цели на тестовия процес • Валидиращо тестване • Да демонстрира на разработчика и на клиента, че софтуерът отговаря на изискванията му. • Успешен тест е този, който показва, че с-мата действа, както е замислена • Тестване за дефекти • Да открие грешки или дефекти в софтуера, където поведението е неправилно или има несъответствие със спецификацията; • Успешен тест е този, който предизвиква неправилно действие или разкрива дефект.

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

9. Политики за тестване • Само пълното тестване може да покаже,че програмата няма дефекти. Обаче пълното тестване е невъзможно. • Политиките дефинират подхода, който се използва при избор на тестовете на с-мата • Трябва да се тестват всички функции извиквани от меню • Трябва да се тестват комбинациите от функции викани от едни също меню • Когато се очаква вход от потребителя, трябва да се тестват всички функции с правилни и неправилни данни.

10. Тестване на с-мата • Извършва интегрирането на компоненти за създаване на с-ма или подс-ма • Може да включва тестването на инкременти, които се предават на клиента. • Две фази: • Интеграционно тестване.Екипът има достъп до сорс кода на с-мата. С-мата се тества с интегрирането на компонентите. • Тестване на изданието.Екипът тества готовата за издаване с-ма като черна кутия.

11. Интеграционно тестване • Включва изграждането на с-мата от и тестването й за проблеми, които могат да възникнат от взаимодействието на компонентите. • Интегриране отгоре-надолу Разработва се скелета на с-мата и се запълва с компоненти • Интегриране отдолу нагоре Интегрират се инфраструктурните компоненти и след това функционалните • С-мите трябва да се изграждат инкрементално, за да се опрости локализацията на грешките

12. Инкрементално интеграционно тестване A T1 T1 A T1 T2 A B T2 T2 T3 B T3 B C T3 T4 C T4 D T5 Test sequence 1 Test sequence 2 Test sequence 3

13. Подходи за тестването • Валидиране на архитектурата Интегриращото “отгоре-надолу” тестване е по-добро при откриване на грешки в с-мната архитектура • Демонстрация на с-мата Интегриращото “отгоре-надолу” тестване позволява ограничена демонстрация в ранен етап на разработката • Осъществяване на теста Често е по-лесно с интегриращото “отдолу-нагоре” тестване • Наблюдение на тестовете Проблеми и при 2-та подхода. Може да се изисква допълнителен код за наблюдение на тестовете

14. Тестване на изданието • Това е процесът на тестване на изданието, което ще се достави на клиентите • Основна цел да се повиши увереността на доставчика, че с-мата отговаря на изискванията. • То обикновено е “черна кутия” или функционално тестване • Основава се само на спецификацията; • Тестващите нямат представа от осъществяването.

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

16. Насоки за тестването Това са съвети за тестващия екип, за да им помогнат да изберат тестове, които ще открият дефекти в с-мата • Избери входни данни, които карат с-мата да генерира всички съобщения за грешки. • Проектирай входа така, че буферите да се препълнят • Повтори един и същ вход или последователност от входове няколко пъти • Предизвикай невалиден изход; • Предизвикай много големи или много малки резултати от изчисленията.

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

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

19. Случаи на използване (Use cases) • Случаите на използване могат да са база за извличане на тестове. Те помагат да се определят операциите, които трябва да се тестват и да се проектират тестваните случаи. • От съответна диаграма на последователностите (sequence diagram) могат да се определят входовете и изходите, които да се тестват.

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

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

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

23. Тестване на компоненти • Това е процес на тестване на изолирани индивидуални компоненти • Това е процес на тестване за дефекти • Компонентата може да е: • Отделна функция или метод на обект • Класове от обекти с по няколко атрибута и методи • Съставни компоненти с дефиниран интерфейс за достъп до функциите й.

24. Тестване на клас от обекти • Пълното тестване на клас включва: • Тестване на всички операции асоциирани с един обект • Даване на стойност на атрибутите и достъп до тях • преминаване на обекта през всички възможни състояния • Наследяването усложнява проектирането на тестовете за класове, защото информацията за проверка не е локализирана.

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

26. Тестване на клас Метео-станция • Нужно е да се дефинират тестовите случаи за reportWeather, calibrate, test, startup и shutdown. • Като се използва моделът на състоянията, трябва да се определят последователностите от промени на състоянията и последователностите от събития предизвикващи тези състояния • Например: Waiting -> Calibrating -> Testing -> Transmitting -> Waiting

27. Тестване на интерфейсите • Целите са да открият грешки в интерфейсите или неверни предположения за интерфейсите. • Особено важно за обектно ориентираната разработка, където обектите са дефинирани чрез интерфейсите си.

28. Тестване на интерфейсите Test cases A B C

29. Типове интерфейси • Параметричен интерфейс Данните предадени от една процедура на друга • Интерфейси със споделена памет Блок памет, който е общ за процедури и/или функции • Процедурен интерфейс Под-с-ма капсулира напор от процедури, които могат да бъдат извиквани от друга под-с-ма • Интерфейс чрез предаване на съобщения Под-с-ма иска услуга от друга под-с-ма.

30. Грешки в интерфейсите • Неправилно използване Извикващата компонента извиква друга компонента и извършва грешка при използването й, напр. грешен ред на параметрите • Неразбиране на интерфейса При написването на извикващата компонента са направени неправилни предположения за поведението на извикваната компонента. • Грешки на синхронизация Извикващата и извикваната компоненти работят с различни скорости и е предадена неактуална информация.

31. Насоки при тестването на интерфейсите • Тестовете се проектират така, че параметрите към извикваната процедура да са с гранични стойности • Когато има параметри-указатели се тестват с null • Проектират се тестове, които предизвикват срив на компонентата • Използва се стресово тестване при с-ми с обмен на съобщения • При с-ми със споделена памет трябва да се променя реда на активиране на компонентите.

32. Проектиране на тестовите случаи • Това са входовете и изходите, използвани да се тества с-мата • Целта е да се създаде набор от тестове, които са ефективни за валидирането и за откриването на дефекти • Подходи в проектирането: • Тестване основано на изисквания • Тестване основано на раздели от данни; • Структурно тестване.

33. Тестване основано на изисквания • Основен принцип на инженеринга на изискванията е, изискванията да са проверяеми • Това е техника за валидиращо тестване, при което за всяко изискване се извлича набор от тестове.

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

35. Тестове за LIBSYS

36. Тестване по класове (partitions) • Входните данни и изходните р-тати често попадат в различни класове, в които всички членове на даден клас имат общи х-ки. • Всеки от тези класове се нарича клас на еквивалентност или домейн, като програмата се държи по еквивалентен начин за всеки член на класа. • За всеки клас трябва да бъде избран тестов случай.

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

38. 3 1 1 4 7 1 0 Less than 4 Betw een 4 and 1 0 Mor e than 1 0 Number of input v alues 9999 1 00000 1 0000 5 0000 99999 Less than 1 0000 Betw een 1 0000 and 99999 Mor e than 99999 Input v alues Класове на еквивалентност

39. Спецификация на подпрограмата за търсене 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 element T’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 ))

40. Подпрограма за търсене – класове на входа • Входове, които отговарят на предусловия • Входове, които не отговарят на предусловия • Входове, за които ключът е член на масива • Входове, за които ключът не е член на масива

41. Насоки за тестване (последователности) • Тествайте с последователности, които имат само 1 стойност • Използвайте последователности с различни размери в различните тестове • Направете тестове, при които се използва първия, последния и средния елемент на последователността. • Тествайте с последователност с дължина 0.

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

43. Структурно тестване • Понякога се нарича тестване на “бяла кутия” • Извличане на тестовите случаи според структурата на програмата. Познаването на програмата се използва за определяне на допълнителни случаи. • Целта е да се изпълнят всички оператори на програмата (не всички комбинации на пътищата)

44. Структурно тестване Test data T ests Deri v es Component Test code outputs

45. Бинарно търсене – класове на еквивалентност • Удовлетворени предусловия, ключът е в масива • Удовлетворени предусловия, ключът не е в масива • Неудовлетворени предусловия, ключът е в масива • Неудовлетворени предусловия, ключът не е в масива • Pre-conditions unsatisfied, key element not in array. • Входният масив има една единствена стойност. • Входният масив има четен брой стойности. • Входният масив има нечетен брой стойности.

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

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

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

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

50. Независими пътища • 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, … • Случаите на тестване трябва да се подберат така, че да се изпълнят всички пътища • Може да се използва динамичен анализатор на програми, който да провери, че всички пътища са били изпълнени