Лекция 1 от курс "Качество на софтуера", проведен в ПУ "Паисий Хилендарски".

1. ОСНОВИ НА
СОФТУЕРНОТО ТЕСТВАНЕ

2. КАКВО СЕ СЪДЪРЖА КУРСА ?
 концепцията на софтуерните тестове – термини, основни
принципи и техники на провеждане на софтуерни тестове
 основни техники при провеждането на whitebox и blackbox
тестовете
 документи заети в процеса на софтуерното тества и
осигуряване на качество на софтуера
 автоматизирани тестове за валидиране на софтуера
 мениджмънт системи
 тестове за ползваемост и UI тестове
 стандарти
 финален тест

3. ОРГАНИЗАЦИИ
 ISTQB
www.istqb.org
 GASQ (Global Association for Software Quality
www.gasq.org
 iSQI (Internation Software Quality Institute)
www.isqi.org
 IEEE Institute of Electrical and Electronic Engineers
www.ieee.org

4. ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ
 Защо тестването става все по-важно ?
- Y2K проблем
- EMU (икономически и паричен съюз)
- eCommerce
- Увеличаване на потребители
- Повишаване на сложността

5. ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ
 Защо се срещат грешки ?
- Няма перфектни неща
- По-голямото напрежение в работата ни
кара да правим повече грешки
- Ограничени бюджет и време
- Лоши практики

6. ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ
 Защо се срещат грешки ?
- Лоша комуникация
- Липса на точни изисквания
- Промяна на изискванията. Липса на
документиране
- Незавършени спецификации

7. РАЗМЕР НА ГРЕШКИТЕ
 Една грешка = милиони
 Проекта тръгва в грешна посока
 Екстремни условия = човешки живот
 Критични системи полежат на задълбочени
тестове

8. ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ
 Например:
- Малко градче в Илинойс, САЩ, получава сметка за ток в
размер на 7мил. Долара през Март 1999. Това е повече от
700 пъти от нормалното. Проблема не се решава до
другата проблема и фирмата се принуждава да я плати
заради Y2K проблема и проблем в софтуера.
- Проблем в банков софтуер, кара системата за изтегли от
сметката на 823 клиента сума в размер на близо 930мил.
Долара. Най-големият банков проблем в историята.

9. ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ
 Защо тестове ?
- Откриване на грешки
намаляване на живите грешки
повишаване на качеството
повишаване на сигурността
редуциране на бъдещи разходи
клиентски изисквания отговарят на реалните функционалности
повишаване на репутацията и доказване на фирмата
- Доставя мерки за качество

10. ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ
 Колко тестове са достатъчни ?
- Как да разберем кога да спрем ?
- Ако спрем прекалено рано с тестовете
рискуваме живота на системата
- Прекалено тестове ще отложат пускането на
продукта на пазара. Губим пари и представяне.

11. ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ
 Ако не можем да тестваме всичко,
какво да правим ?
- Управление и редуциране на риска
- Изследване и анализ на риска в
приложението и ключови моменти
- Приоритизирайте тестовете
- Разбиране на риска от бизнес гледна
точка - функционалност

12. ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ
 Не трябва да спираме да тестваме продукта,
дори да е пуснат на пазара
 Гаранция за откриване на “скрити” дефекти и
грешки

13. ТЕСТВАНЕ И КАЧЕСТВО
 Целта е да намерим най-много
дефекти. Ползата е:
- Намаляване на броя на грешките преди
официалното стартиране на проекта
- Повишаване на качеството
- Повишаване на сигурността

14. КАКВО ТРЯБВА ДА ИЗМЕРВАМЕ
 Коректност
 Надежност
 Ползваемост
 Издръжливост
 Използваемост
 Еквивалентност на изискванията

15. ОБОБЩЕНИЕ
 Целта на тестовете е да открие дефекти
- Грешките могат да бъдат отстранени
- По-добрият софтуер е по-надежден, по-малка
вероятност от грешки
- Тестването е свързано с връзката между
софтуера и изискванията
- Тестовете ни дават възможност да измерваме
качеството на софтуера

16. КАКВО СА СОФТУЕРНИТЕ ТЕСТОВЕ
 Няколко определения:
- “процес на изпълнение на програмата, като се
набляга на нейното качество”
- “процес на изпълнение на програмта, с цел
намиране на грешки”
- “процес на изпълнение на програта с цел
намиране на грешки и потвърждаване на
функционалните и нефункционални
спецификации”

17. ОСНОВНИ ПОНЯТИЯ В SQA
 ISTQB определение
“Процес на последователност от всички действия
в жизнения цикъл на продукта, включващо
статични и динамични действия, концентрирани
върху планирането, подготовката и развитието
на софтуерния продукт и свързан с работата на
самия продукт”

18. ОСНОВНИ ПОНЯТИЯ В SQA
Грешка
“Човешко действие, което предизвиква
некоректен резултат”

19. ОСНОВНИ ПОНЯТИЯ В SQA
Дефект = Дефект= Бъг = Проблем
“Недостатък в компонент или в системата, която
предизвиква некоректно поведение на
компонента или системата”

20. ОСНОВНИ ПОНЯТИЯ В SQA
Неуспех
“Реално отклонение на компнент или системата от
очакваните резултати, услуги или резултати”

21. ОСНОВНИ ПОНЯТИЯ В SQA
Аномалия
“Всяко условие, което се отклонява от
очакванията, които се базират на
функционалните изисквания, документацията,
потребителските изисквания, стандартите”

22. ОСНОВНИ ПОНЯТИЯ В SQA
Аномалия
“Всяко условие, което се отклонява от
очакванията, които се базират на
функционалните изисквания, документацията,
потребителските изисквания, стандартите”

23. ОСНОВНИ ПОНЯТИЯ В SQA
Недостиг
“Липса на нужното качество или елемент или
липса на изпълнение на очаквани резултати”

24. ОСНОВНИ ПОНЯТИЯ В SQA
Маскиране на дефекта
“Явление при което даден дефект предизвиква
друг дефект”

25. ОСНОВНИ ПОНЯТИЯ В SQA
Тест
“Набор от един или няколко тест сценария”
Тест сценарии
“Набор от входящи стойности, изпълнение на
предусловия, очаквани резултати и изпълнение
на предусловията, изпълнение на определени
тест условия, чиято цел е да потвърдят и
сравнят състоянието на системата с описаните в
изискванията”

26. ОСНОВНИ ПОНЯТИЯ В SQA
Маскиране на дефекта
“Явление при което даден дефект предизвиква
друг дефект”

27. ОСНОВНИ ПОНЯТИЯ В SQA
Надежност
“Възможност на софтуерния продукт да
функционира според зададените изисквания под
определени условия и време, или за определени
специфични дейности/операции”

28. ОСНОВНИ ПОНЯТИЯ В SQA
Ползваемост
“Способност на софтуерния продукт да бъде
разбиран, научаван, използван и атрактивен за
потребителите при определени условия”

29. ОСНОВНИ ПОНЯТИЯ В SQA
Производителност
“Способността на софтуерните продукти да
осигурявя подходящо поведение, свързано с
размера на ресурсите използвани при
определени условия”

30. ОСНОВНИ ПОНЯТИЯ В SQA
Поддръжка
“Свободата на софтуерния продукт да бъде
модифициран и да се отстраняват лесно
дефектите, да се изменя според нови
изисквания или при смяна на средата”

31. ОСНОВНИ ПОНЯТИЯ В SQA
Преносимост
“Способността на софтуерния продукт да бъде
пренасян от една хардуерна или софтуерна
среда на друга”

32. ОСНОВНИ ПОНЯТИЯ В SQA
Тестването не създава КАЧЕСТВО на
софтуера, а само определя качеството на
разработвания продукт

33. ОСНОВНИ ПОНЯТИЯ В SQA
Качество на софтуера (QA)
“Всички планирани действия, които се прилагат, за
да се осигури качество на продукта”
Качествен контрол (QC)
“Управление на процеса при създаване на
софтуер, с цел да се осигури, че QA
процедурите и стандартите ще бъдат спазени”

34. ОСНОВИ НА ТЕСТ ПРОЦЕСА
Тест мениджмънт / Управление на процеса
Специфи Изпълне
План кация ние Запис Справк
а
Допълнително управление
Управление на тест средата

35. ТЕСТ ПРОЦЕС
Има 5 основни стъпки:
- Тест планиране и контрол
- Тест анализ и дизайн
- Тест изпълнение
- Оценка на поставените критерии и докладване
- Прекратяване на тестовете

36. ТЕСТ ПЛАНИРАНЕ И КОНТРОЛ
 Тест плана ни дава насоки как да изградим и
изпълним тест стратегията
 Последователност на тестовете
 Какво трябва да се тества, как да се тества,
какви са нужните и др.
 Видове тестове – функционални,
нефункционални, автоматизирани

37. ТЕСТ ПЛАНИРАНЕ И КОНТРОЛ
 Тест контрола ни дава възможност за:
- Измерване и анализ на резултатите
- Наблюдение и документиране на
процеса, обхват на тестовете и критерии
за качество
- Определяне на допълнителни ресурси
- График на тестовете
- Обхват на тест средата

38. ТЕСТ АНАЛИЗ И ДИЗАЙН
Има три основни стъпки:
- Подготовка и анализ
- Изграждане на тест сценарии
- Дефиниране на критериите за успеваемост

39. ПОДГОТОВКА И АНАЛИЗ
 Подготовката на тестове включва:
- Анализ на приложението
- Определяне на тест условията
- Определяне на тест сценариите
- Документация

40. ИЗГРАЖДАНЕ НА ТС
 Всеки един ТС трябва да съдържа информация
за:
- Предусловие
- Входящи данни
- Извършвани действия
- Очаквани ресултати

41. ТЕСТ ДОКЛАД
 Трябва да се включва:
- Версията на софтуера/продукта, който тестваме
- Спецификация, на която се базираме
- Избор на тестове
- Тест резултати
реални резултати
очаквани резултати
- Описание на намерените бъгове

42. КАКВО ПРАВИ ДОБРИЯТ ТЕСТЪР?
 Интелектуални знания
- Поемане на незавършените факти
- Работи с незавършени задачи
- Учи се бързо на много нива
- Добри комуникативни способности
- Може да категоризира и приоритизира
- Самоподготовка

43. КАКВО ПРАВИ ДОБРИЯТ ТЕСТЪР?
 Познания
- Как проекта работи
- Какви са нуждите на системата и бизнеса
- ИТ технологии
- Комерсиални аспекти на ИТ сферата
- Тест техники
- Най-добрите тест практики
- Да мисли в и отвъд спецификацията на
системата

44. КАКВО ПРАВИ ДОБРИЯТ ТЕСТЪР?
 Допълнителни умения
- Способност да открива грешки – планиране,
подготовка и изпълнение
- Способност да разбере системата, с която работи
- Способност да чете и разбира спецификацията
- Способност да отсява ключовите моменти
- Способност да работи надеждно и качествено
- Способност да се фокусира върху важните неща

45. ДОКЛАДВАНЕ НА ГРЕШКИ
 Откритите грешки трябва да се докладват на
- разработчиците, за да могат да ги отстраняват
- Мениджърския екип, за да могат да следят
прогреса
Комуницията между двете групи е жизнено
важна

46. КОМУНИКАЦИЯ С РАЗРАБОТЧИЦИТЕ
 Добрите взаимоотношения са най-важни
 Програмистите, трябва да информират
своевременно QA за всяка една промяна
 QA трябва да информира програмисите за всеки
един бъг, за да може той да бъде остранен

47. КОМУНИКАЦИЯ С МЕНИДЖМЪНТА
 Мениджърите трябва да следят прогреса
на докладваните грешки
 Най-добрия начин е да се използват
следните мерки:
- Брой на планираните и подготвени тестове
- Брой на изпълнените тестове до момента
- Брой на документираните бъгове и брой на корегираните
- Колко време отнема планирането, подготовката и
изпълнението на тестовете

48. МОДЕЛ НА РАЗРАБОТКА
 Има много модели, които се използват:
- V-модел е най-често прилаганият
- Последователен модел (Waterfall)
- Повтарящ се модел
Основните действия в моделите са:
V, V&T – Валидация, Верификация и Тестване

49. МОДЕЛ НА РАЗРАБОТКА
Валидация
“Потвърждаване чрез изследване и осигуряване
на данни/доказателства на обектитеза
коректност при изпълнение на действията от
дадената система”

50. МОДЕЛ НА РАЗРАБОТКА
Верификация
“Потвърждаване чрез изследване и осигуряване
на данни/доказателства за изпълнени
функционални изисквания”

51. МОДЕЛ НА РАЗРАБОТКА
Тестване
“Процеса включва всики действия от жизнения
цикъл на продукта, включително статични и
динамични, концентрирани върху планирането,
подготовката и оценката на софтуерния продукт
и свързан с работата на продукта, за да се
определи дали отговарят на изискванията и
дали функционират коректно, като
същевременно се намират дефекти и бъгове”

52. V-МОДЕЛ
V-Модел
- Най-използвания модел в софтуерните
разработки
- Представя жизнения цикъл на
разработката на проекта
- Показва различни етапи на разработката
и тестването
- Показва връзката между различните
етапи

53. V-MODEL
Тестове за
Бизнес
приемане
изисквания
Тестове за
Техническа интеграция
спецификация
Системни
Функционална тестове
спецификация
Тестове за
Дизайн
интеграция
спецификация
Кодиране Unit тестове