Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Види контролю якості розроблюваного ПЗ

Тема 5.1. Поняття, типи та види тестування.

1. Види контролю якості розроблюваного програмного забезпечення

2. Формування тестових наборів.

3. Ручний контроль програмного забезпечення

 

-1-

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

Процес розробки програмного забезпечення передбачає три стадії тестування:

автономне, комплексне і системне, кожна з яких відповідає завершенню відповідній частині Системи.

Розрізняють два підходи до формування тестів: структурний і функціональний. Кожен з вказаних підходів має свої особливості і сфери застосування.

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

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

На початкових етапах такий контроль здійснюють в основному уручну або з використанням CASE-засобів, на останніх - він набуває форми тестування.

Тестування - це процес виконання програми, метою якого є виявлення помилок.

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

Примітка. Зазвичай на питання про мету тестування початкуючі програмісти відповідають, що метою тестування є «доказ правильності програми». Це абсолютно невірне думка. Г. Майерс [47] пропонує дуже вдалу аналогію для пояснення цього положення.

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

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

• автономне тестування компонентів програмного забезпечення;

• комплексне тестування програмного забезпечення, що розробляється;

• системне або оцінне тестування на відповідність основним критеріям якості.

Для підвищення якості тестування рекомендується дотримувати наступні основні принципи:

• передбачувані результати мають бути відомі до тестування;

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

• необхідно досконально вивчати результати кожного тесту;

• необхідно перевіряти дії програми на невірних даних;

• необхідно перевіряти програму на неочікувані побічні ефекти на невірних даних.

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

-2-

Формування тестових наборів. Відповідно до визначення тестування на початку даного параграфа, вдалим слід рахувати тест, який виявляє хоч би одну помилку.

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

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

Існують два принципово різних підходу до формування тестових наборів:

структурний і функціональний.

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

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

Набори тестів, отримані відповідно до методів цих підходів, зазвичай об'єднують забезпечуючи всестороннє тестування програмного забезпечення.

Детальніший розгляд перерахованих питань почнемо з обговорення методів

ручного контролю.

-3-

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

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

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

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

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

30 до 70 % помилок логічного проектування і кодування. Отже, один або декілька з методів ручного контролю обов'язково повинні використовуватися в кожному програмному проекті.

Основними методами ручного контролю є:

• інспекції вихідного тексту

• скрізні перегляди

• перевірка за столом

• оцінки програм.

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

• учасникам групи заздалегідь видається лістинг програми і специфікація на неї;

• програміст розповідає про логіку роботи програми і відповідає на питання

інспекторів;

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

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

· Контроль звернень до даних

• Чи всі змінні ініціалізували?

• Чи не перевищені максимальні (або реальні) розміри масивів і рядків?

• Чи не переплутані рядки із стовпцями при роботі з матрицями?

• Чи присутні змінні з схожими іменами?

• Чи використовуються файли? Якщо так, то при введенні з файлу чи перевіряється завершення файлу?

• Чи відповідають типи записуваних і читаних значень?

• Чи використані змінні, що не типізуються, відкриті масиви, динамічна пам'ять?

Якщо так, то чи відповідають типи змінних при «накладенні» формату? Чи не виходять індекси за межі масивів?

2. Контроль обчислень

• Чи правильно записані вирази (порядок дотримання операторів)?

• Чи коректно виконані обчислення над неарифметичними змінними?

• Чи коректно виконані обчислення із змінними різних типів (у тому числі з

використанням цілочисельної арифметики)?

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

• Чи відповідають обчислення заданим вимогам точності?

• Чи присутні порівняння змінних різних типів?

3. Контроль передачі управління

• Чи будуть коректно завершені цикли?

• Чи буде завершена програма?

• Чи існують цикли, які не виконуватимуться із-за порушення умови входу?

Чи коректно продовжаться обчислення?

• Чи існують пошукові цикли? Чи коректно відпрацьовуються ситуації «елемент знайдений»

і «елемент не знайдений»?

4. Контроль міжмодульних інтерфейсів

• Чи відповідають списки параметрів і аргументів по порядку, типові, одиницям виміру?

• Чи не змінює підпрограма аргументів, які не повинні змінюватися?

• Чи не відбувається порушення зони дії глобальних і локальних змінних з

однаковими іменами?

Окрім безпосереднього виявлення помилок, результати інспекції дозволяють

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

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

• учасникам групи заздалегідь видають лістинг програми і специфікацію на неї;

• учасникам засідання пропонують декілька тестів;

• учасники засідання в думках виконують кожен тест відповідно до логіки програми, при цьому достаток програми (значення змінних) відстежується на папері або дошці;

• при необхідності програмістові ставлять питання про логіку проектування і прийнятих допущеннях.

У більшості крізних переглядів при виконанні самих тестів знаходять менше помилок чим при опиті програміста.

Перевірка за столом. Історично даний метод ручного тестування з'явився першим оскільки він не вимагає наявності групи фахівців. Це - перевірка вихідного тексту або крізні перегляди, що виконуються однією людиною, яка читає текст програми перевіряє його на наявність можливих помилок за спеціальним списком тих, що часто зустрічаються помилок і «пропускає» через програму тестові дані. Виходячи з принципів тестування перевірку за столом повинна проводити людина, що не є автором програми. Метод найменш результативний, оскільки перевірка є повністю неврегульованою процес, при ній відсутній обмін думками і здорова конкуренція.

Оцінка програм. Цей метод безпосередньо не пов'язаний з тестуванням, але його використання також покращує якість програмування. Його використовують для анонімної оцінки програми в термінах її спільної якості, простоти експлуатації і ясності. Мета методу - забезпечити порівняно об'єктивну оцінку і самооцінку програмістів. Така оцінка виконується таким чином. Вибирається програміст, який повинен виконувати обов'язки адміністратора процесу. Адміністратор набирає групу від шести до 20-ти учасників, які повинні займатися розробкою схожих програм. Кожному учасникові пропонується представити для розгляду дві програми, із його точки зору - якнайкращу і найгіршу. Відібрані програми випадковим чином розподіляються між учасниками. Їм дають по чотири програми -две якнайкращі і дві найгірші, але не говорять які програми погані, а які - хороші. Програміст переглядає ці програми і заповнює анкету, в якій оцінює якість програм за семибалльной шкалою. Після цього результати оцінки звіряють, а перевіряючий дає спільний коментар і рекомендації по поліпшенню програм.

Контрольні питання:

1. Що таке тестування програми?

2.

<== предыдущая лекция | следующая лекция ==>
Фактори, що визначають розмір та швидкість обороту товарних запасів | Транспортування даних
Поделиться с друзьями:


Дата добавления: 2014-01-07; Просмотров: 1526; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.038 сек.