Разработка на качествен софтуер

Слайд 1

СОФТУЕРНО
ИНЖЕНЕРСТВО
РАЗРАБОТКА НА КАЧЕСТВЕН СОФТУЕР

Слайд 2

РАЗРАБОТКА НА КАЧЕСТВЕН СОФТУЕР

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

Теми:
- Разработване базирано на тестове (Test-Driven Development);
- Рефакториране - преработка на съществуващ код (Code Refactoring);
- Защитно програмиране;
- Компонентно тестване (Unit-testing) - Mocks, Stubs;
- Шаблони за дизайн (Design Pattern);
- Техники за дебъгване;
- Софтуерни метрики;
- и др.

Слайд 3

РАЗРАБОТКА НА КАЧЕСТВЕН СОФТУЕР

Един процес може да се контролира само ако може да се измерва по обективни критерии.

Качеството на софтуера може да се измерва, като в софтуерната разработка най-лесният начин е да се измерва в брой открити бъгове.

Качеството на кода може да се разглежда и в неговите най-съществени
характеристики – коректност, леснота за четене и леснота за поддръжка.

Слайд 4

РАЗРАБОТКА НА КАЧЕСТВЕН СОФТУЕР

Качеството на софтуера има два основни аспекта:

- Външно качество – видимото за потребителя
Коректност на софтуера;
Удобство и леснота за работа;
Производителност (скорост на работа).

- Вътрешно качество – вътрешната организация на архитектурата и програмния код - добра организация, добра структура, добра разбираемост и четимост, лесен за поддръжка код
Разбираемост;
Леснота за промяна и добавяне на функционалност (поддръжка);
Простота на реализацията.

Слайд 5

РАЗРАБОТКА НА КАЧЕСТВЕН СОФТУЕР

Характеристики за качество на кода:
Четимост и разбираемост;
Висока свързаност на отговорностите (strong cohesion) на всички нива (модули, класове, методи);
Функционална независимост (loose coupling) на всички нива (модули, класове, методи);
Добро форматиране;
Подходящо именуване на класовете, методите, променливите и останалите елементи;
Абстракция и скриване на информация;
Добра документация, вградена в кода.

Слайд 6

ТЕСТВАНЕ

Тестването е неразделна част от разработката на софтуера. Тестването на софтуера е начин да се контролира качеството му.
Какво е тест? - Тестът е средство за проверка (и оценка) на определена функционалност чрез определен набор от тестове.

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

Има различни видове тестване: Functional testing, Performance testing, Usability testing, Security testing, Unit-testing, Error-Handling testing и много други.

Слайд 7

QUALITY ASSURANCE ИНЖЕНЕР
QA инженерите имат отговорната задача да сведат до минимум грешките в разработвания софтуер, откривайки възможни пропуски в бизнес-логиката на продукта и тествайки възможните сценарии за неговата употреба.
Quality assurance инженерите имат ключова роля за осигуряване максимално качество на софтуера във всички негови аспекти. (съответствие с техническите изисквания и с потребностите на крайните потребители, дизайн, надеждност и издръжливост, бързина, точност, леснота за поддръжка, преносимост, сигурност на информацията и т.н.).
В зависимост от начина на работа на отделните екипи quality assurance инженерите могат да бъдат активна страна във всеки един етап от разработката на софтуера – от първоначалната разработка на изискванията към бъдещия продукт, интеграция на отделни софтуерни компоненти, през цялостното тестване поведението на софтуера и дори до неговата поддръжка.

…

Слайд 8

КОМПОНЕНТНО ТЕСТВАНЕ
Компонентното тестване (Unit testing) е метод за тестване на отделни единици от сорс кода за да се определи дали могат да се използват.
При компонентното тестване на софтуер се взема най-малката самостоятелна единица (unit) от сорс кода, която може да бъде тествана самостоятелно.
Целта е да се проверят и изолират отделните части от кода за да бъдат проверени дали функционират правилно.
Едно от най-важните предимства на този тип тестване е да се открият съответните грешки на ранен етап от разработката на софтуера.

Слайд 9

КОМПОНЕНТНО ТЕСТВАНЕ - СЦЕНАРИЙ
Unit тестовите сценарии се пишат и изпълняват от разработчиците, за да се провери, дали кодът отговаря на заложения дизайн, както и дали се държи според очакванията.

Елементи на примерен тест сценарий:
Име на тестовия сценарий - Името на сценария обикновенно се свързва с функционалността или модула, който се проверява. Съвет: Имената на тестовете е желателно да започват с Test и да съдържат името на модула, функционалността или различни входно изходни данни;
Уникален номер на тестовия сценарий – Всеки сценарий трябва да има уникален номер- идентификатор, който да го различава от останалите тестови сценарии.

Слайд 10

ТЕСТ СЦЕНАРИЙ
- Предусловие - Действия които трябва да бъдат извършени преди за започне изпълнението на тестовия сценарий. Те могат да включват:
навигация до определен етап, избор на даден елемент / параметър преди да започне изпълнението на сценария, създаване или настройка на обект.
- Действия за изпълнение – това е последователността от дейстия, които трябва да се извършат, за да се провери функционалността в сценария.
- Очакван резултат - определя се въз основа на това как е реагирала системата, изпълнявайки всички нужни действия за проверка на дадената функционалност / модул според описаните стъпки. Възможно е наличието на повече от един очакван резултат.
- Pass/Fail статус (бележки) – описва дали системата реагира според описаните параметри във функционалната спецификация.
- Краен очакван резултат - очакваният резултат въз основа на функционалната спецификация

Слайд 11

CODE COVERAGE
Тази стойност се използва за да покаже каква част от редовете в сорс кода са тествани успешно, т.е какъв процент е покрит с тестове.

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

100% code coverage е необходимо, не недостатъчно условие за качеството на софтуера.

Слайд 12

ЗАМЕСТВАНЕ НА ОБЕКТ С ДВОЙНИК
Обикновено всеки тест сценарий на отделните единици (unit) е независим от останалите, за целта се използват имитации - двойниците (test doubles) като stubs, mock или fake обекти, за да се тества дадена единица от кода в изолация.

Двойниците (Test Doubles) са обекти, които заместват други функционални единици, с които е свързан тестовия обект.

Слайд 13

ДВОЙНИК - STUB
Stubbing - Заместването на обект с тестов двойник (Stubs) за да се тества състоянието на системата.

Stub се използва за да замести истински (реален) компонент, от който тестваната система зависи, така че тестът да има контрол върху входните данни от този двойник. Така може да се тестват сценарии с крайни случаи, които иначе системата рядко или никога не достига.

Слайд 14

MOCKING
Заместването на обект с негов двойник, който служи за потвърждение на някакви предварителни очаквания на поведението (например, дали даден метод е бил извикан), се нарича Mocking.
Mock обектите са симулирани обекти, които имитират поведението на реални обекти. Te може да се ползват за потвърждаване на косвения изход от тестваната система.

The Mock Turtle е измислен герой, разработен от Луис Карол от популярната му книга “Алиса в Страната на чудесата”. Името му е взето от популярна английска супа “The Mock Turtle Soup”, която е създадена в средата на 18 век, като по-евтина имитация на зелена костенурска супа.

Слайд 15

MOCKING

Слайд 16

РАЗРАБОТВАНЕ, БАЗИРАНО НА ТЕСТОВЕ
При традиционните подходи за разработване на софтуер етапът на тестване е след написването на кода на приложението. - „Code First” подход

При гъвкавите методологии се налага друга практика на разработка, при която написването на тестовите сценарии предхожда написването на кода. Този метод се нарича – Разработване, базирано на тестове (Test-driven development - TDD). – „Test First“ подход

Слайд 17

РАЗРАБОТВАНЕ, БАЗИРАНО НА ТЕСТОВЕ
ПРЕДИМСТВА:
- Позволява да се изяснят неща относно кода и дизайна още преди кодиране на кода. Предразполага към допускане на по-малко грешки. В случай, че тестовете се пишат накрая е възможно да се пропусне изискване и да се налага връщане и поправка. Ако се използва TDD това е много малко вероятно да се случи.
- Всеки тест проверява малко парче код, което позволява да се разбере къде точно е проблема.
- В началния етап, преди кода да е готов, тестовете описват желания начин на употреба на компонента, за който са написани.
- Повишава се възможностите за автоматизация на тестването, защото продуктът се разработва така, че да премине успешно през определени тестове и следователно е лесен за тестване.

Слайд 18

РАЗРАБОТВАНЕ, БАЗИРАНО НА ТЕСТОВЕ
ПРЕДИМСТВА:
Наличието на предварително написани тестове по време на кодирането подпомага ефективния контрол на качеството на продукта и отстраняване на дефекти в по-ранните етапи на разработка.

Според закона на Боем, показан с кривата на фигурата, цената за фиксиране на дефектите расте във времето.
Колкото на по-късен етап от разработката се установи един дефект, толкова по-скъпо струва.

В резултат на контрола още от началните етапи на разработка, TDD методът
повишава качеството и същевременно понижава цената на продукта.

Слайд 19

РАЗРАБОТВАНЕ, БАЗИРАНО НА ТЕСТОВЕ
“Red, Green, Refactor” цикъл
RED - На първия етап се пишат тестове, които не се компилират (fails), защото нямат създадена логика и това е очакван ефект.

GREEN - На този етап се пише кодът, който трябва да удовлетворява предварително написания тест.

REFACTOR – Етапът, в който кодът се преработва, за да се оправи качеството му без да се променят действията му.

Слайд 20

ПРЕРАБОТКА НА КОД - REFACTORING
При преработката на кода не се променя резултата от работата му.
Променя се структурата на кода. Подобрява се вътрешното качество на кода, без да се счупва самия код. Постъпков процес, при който се променя кода към по-добър.

Слайд 21

REFACTORING И КАЧЕСТВО
Основната цел на рефакторирането е качество. Качеството е важно – прави кода разбираем, прави новата функционалност по-лесна за писане, позволява на нови хора да влязат по-лесно в екипа и дава повече гъвкавост на бизнеса.

Рефакторирането се прави само с добавяне/промяна на функционалност и само на код, който е свързан с нея. Ако рефакторирането не помага на текущата работа, значи не е необходимо!

Рефакторирането е свързано с промяна на възгледите и изграждане на навици за поддържане на качество!

TDD подходът притежава естествен механизъм за проверка на качеството
на софтуера, което подобрява процеса на разработка и повишава качест

Регистрирайте се за пълен достъп