ЛЕКЦІЯ №1

Тема: Місце і роль процесу тестування в життєвому циклі програмного забезпечення

План

1. Ролі членів команди розроблювачів ПЗ

2. Етапи життєвого циклу ПЗ

3. Тестування на етапі планування

4. Тестування на етапі проектування

5. Тестування на етапі кодування

6. Тестування на етапі тестування

7. Тестування на етапі супроводження ПП.

Ролі членів команди розроблювачів ПЗ

Програмний продукт розробляється командою розроблювачів (development team), де кожен співробітник має свою роль:

Керівник проекту (project manager) – відповідає за якість ПП, за планування робіт і складання бюджету розробки. Всі звіти проектувальників і розробників передаються безпосередньо йому.

Проектувальники (designers) ПП. Серед них:

Розроблювач архітектури (architect) визначає загальну внутрішню структуру коду і даних, принципи обміну даними між зв’язаними програмами, а також стратегію розробки модулів, що використовуються багаторазово. Він може також складати план тестування так званого «білої скриньки», аналізувати технічні обзори всіх специфікацій і розробляти тести для прийому ПП.

Спеціаліст по аналізу предметної області (software analyst) повинен розуміти, чого хочуть користувачі і як це відобразити в термінах, зрозумілих розроблювачам.

Спеціаліст по аналізу людського фактору, або спеціаліст з ергономіки, має психологічну освіту і знає як спроектувати програму, щоб вона була зручною і корисною, і як тестувати продукт на відповідність цим якостям.

Програміст користувацького інтерфейсу, спеціалізується на створенні користувацького інтерфейсу програм. Частіше за все – це професійний програміст, який знається у віконній архітектурі, комп’ютерній графіці. Тощо.

Ведучі програмісти (lead programmers) займаються розробкою тої частини специфікації, яка відноситься до внутрішньої структури продукту

Менеджер з маркетингу відповідає за відповідність продукту довгостроковій стратегії і іміджу своєї компанії, а також за маркетингову діяльність, яка продовжується після випуску продукції

Представник групи технічної підтримки – це член, або керівник групи, що безпосередньо контактує з користувачами. На етапі створення продукту вони беруть участь в проектуванні програми і розробці документації.

Технічні письменники – це члени групи документування, що розробляють «Руководство пользователя» і ітерактивну довідку.

Тестувальники (testers)

Етапи життєвого циклу ПЗ

В ЖЦПП багато етапів. Звичайно їх описують послідовно, ніби вони йдуть один за одним, але насправді вони в значній мірі перекриваються.

П’ять основних етапів ЖЦПП:

• Планування

• Проектування

• Кодування і написання документації

• Тестування та виправлення недоліків

• Супровід і вдосконалення.

На першому місці за вартістю – супровід і вдосконалення, а на другому – тестування.

Практично на кожному етапі ЖЦПП продукт тестують і виправляють. І чим далі просувається робота, тим швидше зростає вартість тестування.

Тестування на етапі планування

Стадії планування

Визначення цілей. Формування загального бачення ПП. Може бути описаний користувацький інтерфейс, вимоги до надійності ПП і його продуктивності. Визначаються витрати на розробку.

Аналіз вимог. Вимоги мають функціональний характер, а як їх реалізувати практично – це вирішують розробники. Перелік вимог може охоплювати і вартість майбутнього проекту, його продуктивність, надійність, деякі елементи користувацького інтерфейсу.

Визначення функціональних характеристик ПП

Тобто перелік функцій майбутнього ПП і опис вхідних та вихідних документів.

На цьому етапі тестуються не програми – тестуються ідеї. До їх аналізу долучаються спеціалісти по маркетингу, керівники проекту, головні конструктори і спеціалісти з аналізу людського фактору. Члени групи тестування не беруть участі. Група аналітиків читає чернетки проектних документів, збирає інформацію, яка може надати допомогу в їх оцінюванні і подальшому плануванні. Для цього існує декілька стандартних способів: порівняльний аналіз, дискусійні групи і обстеження об’єкту.

При аналізі вимог до ПП і його функціональних характеристик спеціалісти намагаються з’ясувати наступне:

• Чи є ці вимоги адекватними? Чи дійсно саме такий ПП компанія хоче створити?

• Чи є вони повними? Чи не пропустили які-небудь корисні і навіть життєво необхідні функції?

• Чи є ці вимоги сумісними між собою?

• Чи можуть ці вимоги бути виконаними? Може треба інше апаратне забезпечення?

• Чи є вони розумними?

• Чи можуть вони бути протестованими?

Порівняльний аналіз існуючих ПП

Для такого аналізу необхідні робочі копії конкуруючих продуктів, або демоверсії, описи. Складається перелік функцій, перелік сильних та слабких сторон.

Дискусійні групи

Аналітик вибирає невелику групу людей, які є найбільш типовими представниками певного сегменту ринку. Члени групи не знають один одного. Аналітик пропонує їм обговорити певну тему.

Обстеження об’єкта

Кожен ПП призначається для повної або часткової автоматизації діяльності людини. Аналатик обстежує – як люди виконують певну роботу без цього ПП, яка послідовність їх дій, що саме особливо уповільнює дії людей тощо.

Тестування на етапі проектування

Стадії проектування

На етапі проектування група відповідних спеціалістів вирішує, як будуть реалізовані заплановані можливості ПП. Вони розробляють зовнішній дизайн ПП і його внутрішню структуру. Обидві ці складові тісно взаємопов’язані і проектуються одночасно. Розробляючи проект, спеціалісти спираються на вимоги до ПП. За класичною моделлю розробки ПП кодування починається тільки по завершенні проектування.

Зовнішній дизайн

Опис зовнішнього дизайну ПП включає в себе повний опис його користувацького інтерфейсу, а саме всі екранні та печатні форми. В процесі розробки ПП його зовн дизайн може багаторазово змінюватися.

Внутрішня структура

Опис внутрішньої структури ПП визначає набір майбутніх програмних модулів (програмну архітектуру), структуру, взаємозв’язки і принципи зберігання та обробки даних (організацію даних) і алгоритми роботи програми.

Проектування програмної архітектури

Як правило, кожну задачу можна розбити на чіткі під задачі, які у свою чергу, також можна розбити на ще менші елементи і т.д. Це –так звана модульна декомпозиція, і вона виконується доти, доки не будуть виділені досить самостійні елементи, які можна реалізувати у вигляді окремих програмних модулів або процедур. Зазвичай складні ПП реалізуються у вигляді системи – набору зв’язаних між собою повноцінних програм. Такі програми часто називають процесами, особливо якщо вони працюють паралельно. Хоча процеси можуть працювати і незалежно, як правило вони взаємодіють між собою. Наприклад, вони можуть використовувати одні й ті ж самі дані.

Документація, що визначає принципи і правила взаємодії процесів системи, називається протоколом.

Проектування організації даних

Розроблювач структури даних повинен дати відповіді на наступні принципіальні питання:

Які дані обробляє програма і яка їх структура? (Чи це прості змінні, чи це масиви, які організуються в бази даних)

Як відбувається доступ до даних? (Чи просто по імені, чи через спеціально написані для цього функції, чи вони є загальнодоступними, чи доступ до них строго регулюється)

Які принципи іменування даних? (Чи використовується в даній розробці угода про імена?)

Як зберігаються дані? (У якому форматі? Які потрібні додаткові програмні засоби?)

Опис алгоритмів

Проектування ПП не закінчується описом програмних модулів і організації даних. Ще треба подумати як саме реалізовуватимуться поставлені задачі? Звичайно це роблять програмісти. Вони вибирають оптимальні алгоритми і описують послідовність логічних кроків, необхідних для виконання кожної задачі.

Моделювання

Щоб краще представити собі майбутній ПП, на етапі проектування може бути розроблено його прототип – програмна модель всього продукту або його частини. Як правило, прототип створюється для оцінки функціональності майбутнього ПП і її користувацького інтерфейсу.

На етапі проектування, як і на етапі планування, коду ще немає, тому тестуються тільки ідеї. Але ідеї на цьому етапі описані набагато детальніше і набагато формалізованіше. Тестуванням займаються аналітики, а тестувальники присутні пасивно. У центрі уваги повинні бути такі питання:

• Чи дійсно проект гарний? Чи буде на його основі створено ефективний, компактний, легкий у супроводі і модернізації продукт, і до того ж чи добре він тестується?

• Чи відповідає проект вимогам? Проект повинен бути формалізованим виразом вимог, представлених в документації на етапі планування?

• Чи є проект повним? Чи описує проект всі взаємозв’язки між модулями і даними, передачу даних між модулями, умови роботи кожного модуля тощо.

• Чи є він реалістичним? Чи задовольняють системні ресурси вимогам проекту? Чи зможе ПП працювати швидко?

• Чи добре описана в проекті підсистема обробки помилок? Дуже важливо правильно визначити рівень, на якому обробляється кожна з помилок, щоб її виникнення в одному модулі не призвело до помилок в інших.

Наради аналітиків

Звичайно метою нарад, які проводяться при аналізі проектних документів, є не рішення проблем, а саме їх виявлення. В нараді бере участь група співробітників біля 7 . В цю групу не повинні входити автори проекту/ Проект перероблюється доти, доки він не буде схвалений групою аналітиків. Наради цієї групи можуть бути трьох типів:

Оглядові, інспекційні і рецензійні.

Оглядова нарада. Проектувальники демонструють модель програми. Крок за кроком вони демонструють, що робить програма з тестовими даними, запропонованими аналітиками. Така демонстрація дозволяє побачити, як взаємодіють між собою різні частини системи, виявити недоліки: незручні режими, надлишковість функцій, пропущені деталі.

Інспекційна нарада. Аналізується детально кожний елемент проекту або його окремий аспект: обробка помилок, відповідність стандартам тощо.

Рецензійна нарада. Готується список питань, що виникли. Виділяються сумнівні елементи проекту. Мета цієї наради – скласти список проблем і впевнитися, що проектувальники правильно зрозуміли кожну з них. Нарада записується.