Малюнок 11.3.1. Модель V-тестування.

Модулі тестування - тестуються окремі частини, щоб упевнитися в правильності.

Кожен елемент тестується окремо. Модулі тестуються окремо один від одного. Модуль - безліч незалежних компонентів (процедур і функцій).

Тестування цілісності полягає в перевірці інтерфейсів між модулями.

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

Тестування прийнятності системи - останній етап, який виконується перед доставкою системи користувачеві. Система тестується даними користувача, а не розробника.

Перегляди

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

Перегляди можуть бути формальними і неформальними. Формальні: технічний, наскрізний контроль, аудит.

Технічний перегляд

Технічний перегляд - перевірка на відповідність елеметов ПЗ роботі за розкладом (подробиці можна знайти в ANSI/ IEEE Std 1028 -1988 "Стандарти IEEE для переглядів і аудитів").

Наскрізний контроль

Наскрізний контроль - попереднє оцінювання документів, моделей і проектів. Мета - визначити дефекти і надати варіанти рішення. Друге завдання - вирішення проблем із стилем (наприклад, з формою коду, документація, інтерфейсами).

Аудит

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

Команда по оцінці ПЗ

Оцінка ПЗ - дуже важливе питання, яке повинне вирішуватися професіоналами.

Потрібно вибрати команду професіоналів, яка підготує і проведе тести.

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

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

Аудит

Аудит - незалежний перегляд і оцінка ПЗ. Він перевіряє, чи відповідає ПЗ вимогам специфікаціям, рекомендаціям, стандартам, процедурам, умовам контрактів і ліцензіям.

Об'єктивність аудиту вимагає незалежних експертів-професіоналів.

Аудіювання повинне проводитися аудитною групою або персонами з ліцензіями.

Правила визначає стандарт ANSMEEE Std 1028-1988 IEEE - стандарт для переглядів і аудиту.

Аудит проекту розробки ПЗ

Мета аудиту - отримати цілі і інформацію про проекту.

Слід оцінювати ресурси, компетенцію і методи, які важливі для досягнення проміжних і повного успіхів.Ця інформація важлива для ухвалення стратегічних рішень.

Суб'єкти і перспективи аудиту

Суб'єктами аудиту можуть бути процеси або продукти проекту (можуть і обидва).

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

Мета аудиту продукту (проміжного або кінцевого) - перевірити, чи відповідає він вимогам і очікуванням.

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

Інспекції

Інспекція - формальна техніка оцінки персоною або групою персон на наявність помилок у коді, вимогах і проектах, на їх відповідність стандартам і пошук інших проблем в процесі розробки ПЗ [IEEE Std. 729-1983].

Інспекція повинна бути добре спланована і організована. Всі помилки і проблеми повинні бути записані. Супервізори не повинні брати участь в інспекції. Її результати надаються супервізорам у формі звітів, без особистої інформації про інспекторів.Після чого проводиться нарада.

Мета наради - зробити виводи про те, які проблеми повинні бути ліквідовані і які дії зроблені для уникнення проблем в майбутньому.

Малюнок 11.6.1. Процес інспекції.

 

На малюнку 11.6.1 представлені наступні етапи інспекції:

· Ініціація - виклик інспекції і її голови

· Планування - лідер викликає членів, формує управляючі таблиці і план, визначає ретельність контролю

· Ініціююча нарада - формулювання правил, завдань, очікувань, створення документів інспекції

· Інівідуальний контроль - члени інспекції перевіряють документи, використовуючи критерії контролю (для того, щоб знайти максимальну кількість помилок)

· Контрольна нарада (мозкова буря) - збір думок кожного інспектора, які можуть бути "невідповідністю" (потенційною помилкою), "питанням про намір", "пропозицією про удосконалення процесу", пошук інших невідповідностей, залучення до процесу інспекції

· Удосконалення продукту: редактор (зазвичай - автор) проводить перевірку усіх рішеннь і проголошує невідповідності. Реальні невідповідності можуть відрізнятися від записаних. Їх сприймають як помилки, або документ редагується для уникнення неправильної інтерпретації.

· Доопрацювання: лідер перевіряє, чи всі невідповідності виправлені; він перевіряє завершеність, а не правильність.

· Рішення по завершеності: лідер дає оцінку того, чи готовий продукт (чи знаходиться кількість помилок в допустимих межах).

· Розробка документів

· Мета "мозкової бурі" - визначити причину вагомих помилок (не більше десяти помилок) і запропонувати процедури для їх уникнення в майбутньому.

Дослідження показують, що інспекції - найефективніший спосіб (від 50% до 80%; в середньому - 60%; для тестування середній показник - 30%, максимум - 50%). Сам метод і його умови застосовуються рідко і лише до "елітних" систем.

Продуктивність в результаті інспекції збільшується на 30% - 100%, час на розробку проекту зменшується на 10% - 30%, вартість тестування зменшується в 5 - 10 разів (менше помилок, менше регресивних помилок), підтримка - в 10 разів більша. Було відмічено, що інспекції мотивують команди: робота виконується вчасно, а її комфорт збільшується.

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

Інспекції не є частими, оскільки вони вимагають компетентних персон, які правильно працюють. Не потрібно ніяких особливих інструментів. Витрати і наслідки інспекції нелегко оцінити. Ефект може бути зменшений, якщо інспектора будуть недосвідчені. Також інспекція може призвести до самозахисту розробки проекту.

Види тестів

До тестування відносяться два поняття: помилка і невдача.

Помилка - це неправильна будова програми, яка може призвести до помилок в ході її виконання.

Невдача - неправильне функціонування системи під час її роботи.

Помилка може призвести до багатьох невдач. Одна і та ж невдача може відбуватися з різних причин.

Тестування - це процес визначення і усунення помилок, заснований на неправильних виконаннях і інших тестах.

Тести ПЗ можуть класифікуватися з точки зору головної мети або техніки тестування.