Пояснювальна записка до магістерської дипломної роботи на тему: «визначення якості тестування програмного забезпечення на основі аналізу складу та критичності дефектів»



Pdf просмотр
Сторінка1/3
Дата конвертації24.03.2017
Розмір0.66 Mb.
ТипПояснювальна записка
  1   2   3

МIНIСТЕРСТВО ОСВIТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ
ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ
Факультет економічної інформатики
Кафедра інформаційних систем
Допускаю до захисту:
Завідувач кафедри д. е. н., проф. Пономаренко В. С.
____________________________
―____‖ __________________2011 р.
ПОЯСНЮВАЛЬНА ЗАПИСКА
до магістерської дипломної роботи на тему:
«ВИЗНАЧЕННЯ ЯКОСТІ ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ НА ОСНОВІ АНАЛІЗУ СКЛАДУ ТА
КРИТИЧНОСТІ ДЕФЕКТІВ»
освітньо-кваліфікаційний рівень «магістр» спеціальність 8.080401 – інформаційні управляючі системи і технології
Науковий керівник
к.т.н., доцент кафедри ІС

О. В. Щербаков


Виконавець
Студент 5 курсу 4 групи

Є. С. Луценко
Харків, 2011

1
МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ
ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ
Факультет економічної інформатики
Кафедра інформаційних систем
Галузь знань ―Інформатика та обчислювальна техніка‖
Спеціальність ―Інформаційні управляючі системи і технології‖
«ЗАТВЕРДЖУЮ»
Завідувач кафедри
В. С. Пономаренко
____________________________
« 18 » квітня 2011 р.
ЗАВДАННЯ
ДО ВИКОНАННЯ МАГІСТЕРСЬКОЇ ДИПЛО МНОЇ РОБОТИ
Луценку Євгенію Сергійовичу
1. Тема роботи: Визначення якості тестування програмного збезпечення на основі аналізу складу та критичності дефектів. затверджена наказом ректора № 6-С від «04» січня 2011 р.
2. Термін здачі студентом закінченої роботи: 10 червня 2011 р.
3. Вхідні дані до роботи: використовувати загальновідому структуру звіту про дефекти та звіти систем Jira, Mantis, ChilliProject, Redmine, BugNET, BugTracker.NET,
Bugzilla, Trac.
4. Зміст пояснювальної записки (перелік питань, що підлягають розробленню):
Вступ. 1. Аналіз традиційних систем підтримки прийняття рішень.
2. Розроблення методики обробки даних в персональних системах підтримки прийняття рішень. 3. Розроблення персональної системи підтримки прийняття рішень за розробленою методикою, доведення її ефективності. Висновки.
5. Перелік графічного матеріалу: діаграми життєвого циклу розробки програмного забезпечення; знімки екранів систем відстеження помилок Jira, Mantis, ChilliProject, Redmine,
BugNET, BugTracker.NET, Bugzilla, Trac.

2 6. КАЛЕНДАРНИЙ ПЛАН
№ з/п
Назва етапів виконання магістерської дипломної роботи
Термін виконання етапів роботи
1
Вступ
22.04.2011 2
Аналіз існуючих підходів та методів щодо визначення ефективності тестування.
03.05.2011 3
Аналіз процесу тестування програмного забезпечення з метою виявлення його особливостей щодо визначення ефективності тестування.
12.05.2011 4
Аналіз функціональних можливостей існуючих систем відстеження дефектів.
15.05.2011 5
Аналіз структури звітів найпоширеніших систем відстеження дефектів.
21.05.2011 6
Розробка модифікованої структуру звіту про знайдені дефекти для її використання при визначенні ефективності тестування.
25.05.2011 7
Створення математичної моделі та розробка кількісної методики оцінки ефективності роботи тестувальника на її підставі.
28.05.2011 8
Аналіз результатів дослідження
01.06.2011 9
Підготовка пояснювальної записки
04.06.2011 10
Підготовка презентації та доповіді
04.06.2011 11
Попередній захист роботи
06.06.2011 12
Відзив керівника, рецензування роботи
08.06.2011 13
Нормоконтроль
10.06.2011 14
Допуск до захисту у зав. кафедрою
10.06.2011
Дата видачі завдання 18.04.2011 р.
Завдання підготував
Науковий керівник ___________________ к.т.н., доц. Щербаков О.В.
Завдання одержав
Студент
____________________ Луценко Є. С.

3
РЕФЕРАТ
Пояснювальна записка до магістерської дипломної роботи: 75 стор., 21 рис., 10 таблиць, 45 літературних джерел.
Об’єкт дослідження – контроль якості тестування програмного забезпечення на основі складу та критичності дефектів
Предмет дослідження – засоби визначення якості тестування програмного забезпечення на основі складу та критичності дефектів.
Мета магістерської роботи - аналіз процесу тестування, створення модифікованої структури звіту про дефекти та розробка кількісної методики оцінки ефективності роботи тестувальника, що у цілому необхідно визначення ефективності тестування.
На підставі аналізу структури традиційного звіту про дефекти програмних продуктів, виявлених при тестуванні, створена модифікована структура звіту.
Запропонована структура звіту дозволяє не тільки поліпшити взаємодію розробників та тестувальників програмного забезпечення, а
і використовується як засіб контролю за їх діяльністю. При цьому кожне поле звіту розглядається з точки зору його врахування для оцінки ефективності тестування.
Розроблена методика кількісної оцінки ефективності тестування програмних продуктів на підставі математичної моделі.
Ключові слова:
ТЕСТУВАННЯ,
МЕТОДИКА
ОЦІНКИ
ЕФЕКТИВНОСТІ
ТЕСТУВАЛЬНИКА,
ЗВІТ
ПРО
ПОМИЛКУ,
МОДИФІКОВАНА СТРУКТУРА ЗВІТУ ПРО ПОМИЛКИ, ЗАСІБ
КОНТРОЛЮ ДІЯЛЬНОСТІ ТЕСТУВАЛЬНИКІВ.

4
ABSTRACT
An explanatory message is to magister's work: 75 p., 21 lines, 10 tabl.,
45 references.
A research object is control testing quality by the structure and critically of defects.
The purpose of the magister's work is to make analysis of testing process, creating bug-report modified structure and developing method for estimating effec- tiveness of testers that is whole needed for calculating testing effectiveness.
On the basis of the analysis of the structure of traditional reporting software defects that founded during testing, created a modified structure of the report. The proposed structure of the report can not only improve the interaction of developers and testers of the software, but also as a means of control over their activities. In this report, each field is considered in terms of its accounting for estimate the ef- fectiveness of testing. Within the scope of the article the method of quantitative as- sessment of the effectiveness of software testing based on appropriate mathemati- cal model.
Keywords: TESTING, METHODICS OF ESTIMATING TESTING EFFECTI-
VENESS, BUG REPORT, MODIFIED STRUCTURE OF BUG REPORT, TOOL
FOR CONTROLLING SOWTWARE TESTER ACTIVITIES.

5
ЗМІСТ
ВСТУП ..................................................................................................................... 6
РОЗДІЛ 1
АНАЛІЗ ОСОБЛИВОСТЕЙ ПРОЦЕССУ ВИЗНАЧЕННЯ
ЯКОСТІ ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ НА ОСНОВІ
АНАЛІЗУ СКЛАДУ ТА КРИТИЧНОСТІ ДЕФЕКТІВ ....................................... 8 1.1. Обґрунтування актуальності дослідження визначення якості тестування програмного забезпечення на основі аналізу складу та критичності дефектів. ............................................................................................ 8 1.2. Аналіз найпоширеніших багкрекерів та методів,за допомогою яких можливо визначати якість тестування програмного забезпечення ......... 32
РОЗДІЛ
2
МЕТОДИ
ВИЗНАЧЕННЯ
ЯКОСТІ
ТЕСТУВАННЯ
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ НА ОСНОВІ АНАЛІЗУ СКЛАДУ ТА
КРИТИЧНОСТІ ДЕФЕКТІВ ................................................................................ 49 2.1. Модифікація структури звіту про знайдені дефекти з метою визначення якості тестування програмного забезпечення на основі аналізу складу та критичності дефектів. .......................................................................... 49 2.2. Обґрунтування вибору математичного апарату щодо дослідження ефективності роботи тестувальника. Визначення коефіцієнта ефективності. ......................................................................................................... 60
РОЗДІЛ 3
ПРАКТИЧНЕ ДОСЛІДЖЕННЯ ТА РЕЗУЛЬТАТИ АПРОБАЦІЇ
РОЗРОБЛЕНИХ
МЕТОДІВ
ЩОДО
ВИЗНАЧЕННЯ
ЯКОСТІ
ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ НА ОСНОВІ АНАЛІЗУ
СКЛАДУ ТА КРИТИЧНОСТІ ДЕФЕКТІВ ........................................................ 65 3.1.
Методика визначення якості тестування програмного забезпечення на основі аналізу складу та критичності дефектів. .................... 65 3.2. Результати експериментального дослідження щодо визначення якості тестування програмного забезпечення на основі аналізу складу та критичності дефектів ............................................................................................ 66
ВИСНОВКИ ........................................................................................................... 71
ВИКОРИСТАНА ЛІТЕРАТУРА ......................................................................... 73

6
ВСТУП
Тестування програмного забезпечення відіграє значну роль при створенні програмних продуктів. Цей процес є складним та потребує відповідної перевірки якості його виконання. Традиційні засоби поверхнево визначають якість тестування програмного забезпечення, не враховуючи склад та критичність дефектів, що має наслідком неефективне використання ресурсів тестування та необ’єктивний підхід до оцінки діяльності тестувальників. Завдяки існуючий традиційній структурі звіту про дефекти можливе створення його модифікованої версії, яка б дозволила враховувати відповідні аспекти, що стосуються дефектів при визначенні якості тестування та розробити методику кількісної оцінки роботи тестувальника, засновану на математичному апараті. Модифікована версія звіту та зазначена методика кількісної оцінки розраховуються на покращення якості тестування та якості програмного продукту у цілому.
Мета цієї роботи – визначення якості тестування програмного забезпечення на основі складу та критичності дефектів, що включає створення модифікованої структури звіту про дефекти та розробку кількісної методики оцінки роботи тестувальника.
Для досягнення поставленої мети необхідно вирішити наступні завдання:

виконати огляд літературних джерел;

проаналізувати процес тестування програмного забезпечення;

визначити основні функціональні особливості найпоширеніших систем відстеження дефектів;

проаналізувати структуру звітів про помилки найпоширеніших систем відстеження помилок;

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

розглянути традиційну структуру звіту про знайдені дефекти;

проаналізувати відповідність звітів розглянутих систем багтрекінгу традиційній структурі звіту;

розробити модифіковану структуру звіту про знайдені дефекти;

обґрунтувати наявність кожного поля у модифікованій структурі звіту з точки зору його подальшого використання(застосування) для аналізу ефективності роботи тестувальників;

7

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

розробити методику кількісної оцінки роботи тестувальників для застосування керівництвом проектів з метою оцінки діяльності фахівців;

випробувати розроблену методику у реальному процесі тестування(застосувати розроблену методику при реальному процесі тестування разом з існуючими, порівняти результати).
Об’єкт дослідження – контроль якості тестування програмного забезпечення на основі складу та критичності дефектів
Предмет дослідження – засоби визначення якості тестування програмного забезпечення на основі складу та критичності дефектів.
Методи дослідження: в оглядово-аналітичній та теоретичній частинах дослідження використовуються методи аналізу та порівняння. У науково- дослідній частині дослідження використовуються евристичні методи та звичайні диференціальні моделі.
Наукова новизна:

розроблений підхід щодо визначення якості тестування програмного забезпечення на основі складу та критичності дефектів;

створена модифікована структура баг-репорту заснована на критичності та складу дефектів;

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

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

розроблена кількісна методика оцінки ефективності тестувальників може бути використана у реальних проектах та поліпшити ефективність тестування у цілому внаслідок більш об’єктивної оцінки діяльності тестувальників.
Робота була опробована виступом на ІІ міжнародній науково- практичній конференції «Інформаційні технології та комп’ютерна інженерія»
(ХНЕУ), X ювілейній Всеукраїнській науковій студентській конференції, присвяченій пам’яті проф. В. Ф. Ситника (КНЕУ) та науково-практичній конференції молодих вчених аспірантів та студентів «Актуальні проблеми науки та освіти молоді: теорія, практика, сучасні рішення - 2010» (ХНЕУ).

8
РОЗДІЛ 1
АНАЛІЗ ОСОБЛИВОСТЕЙ ПРОЦЕССУ ВИЗНАЧЕННЯ ЯКОСТІ
ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ НА ОСНОВІ АНАЛІЗУ
СКЛАДУ ТА КРИТИЧНОСТІ ДЕФЕКТІВ
1.1. Обґрунтування актуальності дослідження визначення якості тестування програмного забезпечення на основі аналізу складу та критичності дефектів.
Тестування програмного забезпечення (ПЗ) відіграє значну роль при його розробці, як комплекс заходів для отримання якісного програмного продукту.
Якість ПЗ, створеного розробниками, у значній мірі залежить від роботи тестувальників. Адже тестування займає значну частину усього процесу розробки. Відмова від тестування, його нехтування та неякісне виконання сприяють значним збиткам та краху проекту у цілому. Тому ще на початкових етапах розробки необхідно забезпечити відповідну організацію процесу тестування та контролю якості його виконання.
Для визначення якості тестування програмного забезпечення необхідно для початку потурбуватися, яким чином її забезпечити. Забезпечення якості досягається шляхом впровадження відповідних методологій розробки програмного забезпечення [3]. Кожна з методологій містить у собі окремий розділ, який стосується тестування програмного забезпечення.
Розглянемо складові тестування, а саме визначимо засоби організації процесу тестування. Для цього проаналізуємо зазначені методології тестування ПЗ та визначимо поняття моделі ЖЦ згідно [5,6,7].
1.1.1. Моделі життєвого циклу розробки програмного забезпечення.
Під моделлю ЖЦ розуміється структура, що визначає послідовність виконання та взаємозв'язок процесів, дій, завдань, які виконуються протягом
ЖЦ. Модель ЖЦ залежить від специфіки ІС та специфіки умов, в яких остання створюється та функціонує [4]. Розглянемо ISO/IEC12207 [8], який не пропонує конкретну модель ЖЦ і метод розробки ПЗ. Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки.
Цей стандарт описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, що включені в ці процеси.
Існують наступні основні моделі ЖЦ [9]:
Каскадна (Водопадна) або послідовна модель (70-85 р.р.);

9
Ітеративна, інкрементальна - еволюційна (гібридна, змішана) модель
(86-90 р.р.);
Спіральна модель або модель Боемі (88-90-ті рр.).
У різних джерелах [10,11,12] наводиться різний список моделей та їх
інтерпретація. Наприклад, раніше, інкрементальна модель розумілася як система, що побудована у вигляді послідовності збірок (релізів) та визначена відповідно заздалегідь підготовленому плану і сформульованим незмінним вимогам. Зараз інкрементальний підхід розглядають у контексті поступового нарощування функціональності створюваного продукту.
У спіральній модель найбільша увага приділяється аналізу та попередженню ризиків. Розглянемо кожну з моделей життєвого циклу.
1.1.1.1. Каскадна модель життєвого циклу розробки ПЗ.
На початку існування однорідних ІС кожен додаток був представлений
єдиним цілим, для розробки якого застосовувався каскадний підхід, основною характеристикою якого є розділення усього процесу розробки на етапи, причому перехід з попереднього етапу на наступний відбувається тільки після повного завершення роботи на поточному (рис. 1.1). Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена командою фахівців на наступному етапі.
Позитивні сторони використання каскадного підходу полягають в наступному: на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти та узгодженості; етапи робіт, що виконуються в логічній послідовності дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Каскадного підходу переважно дотримуються при побудові ІС, для яких на початку розробки можливо точно і повно сформулювати всі вимоги та надати розробникам можливість якісної технічної реалізації зазначених вимог. До такої категорії ІС відносять складні розрахункові системи та системи реального часу. Проте, в процесі використання такого підходу виникає ряд проблем, які викликані тим, що при реальному процесі створення ПЗ відсутня можливість повного дотримання зазначеної схеми так як при цьому постійно виникає потреба у поверненні до попередніх етапів та уточненні або перегляду попередньо прийнятих рішень. У результаті реальний процес створення ПЗ приймає вигляд, представлений на рис. 1.2.

10
Аналіз
Проектування
Реалізація
Впровадження
Супровід
Рис. 1.1. Каскадна схема розробки ПЗ
Аналіз
Проектування
Реалізація
Впровадження
Супровід
Рис. 1.2. Реальний процес розробки ПЗ за каскадною схемою
Основним недоліком каскадного підходу є невчасне отримання результатів. Узгодження результатів з користувачами проводиться тільки у точках, що плануються після завершення кожного етапу робіт, тому вимоги до ІС, що представлені у вигляді технічного завдання не можуть бути змінені протягом усього часу створення системи. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над ІС буде повністю завершена. У разі неточного викладення вимог або їх зміни протягом тривалого періоду створення ПЗ, користувачі отримують систему, що не задовольняє їх потреб.
1.1.1.2. Ітеративна та інкрементальна модель.
Для вирішення перелічених проблем каскадної моделі була запропонована ітеративна модель, яка припускає розділення життєвого циклу проекту на послідовність ітерацій, кожна з яких нагадує "міні-проект", який включає всі фази життєвого циклу, що застосовуються для створення менших фрагментів функціональності. Мета кожної ітерації - отримання працюючої версії програмної системи, яка включає функціональність, що визначається інтегрованим змістом усіх попередніх та поточної ітерацій.
Результати фінальної ітерації містять усю необхідну функціональність

11 продукту. Таким чином, із завершенням кожної ітерації, продукт виконує
інкрементальний розвиток.
З точки зору структури життєвого циклу таку модель називають
ітеративною (iterative). З точки зору розвитку продукту – інкрементальною
(incremental). Неможливо розглядати кожен з цих поглядів ізольовано[13], тому таку змішану еволюційну модель прийнято називати ітеративною (у контексті процесу) та інкрементальною (у контексті нарощування функціональності продукту) [14].
При еволюційній моделі окрім збірки версії системи, що працює з точки зору результатів тестування відбувається її розгортання в реальних операційних умовах з аналізом відкликів користувачів для визначення змісту
і планування наступної ітерації.
Класична інкрементальна модель не передбачає розгортання проміжних збірок (релізів) системи - всі ітерації проводяться за заздалегідь визначеним планом нарощування функціональності, а користувачі отримують тільки результат фінальної ітерації як повну версію системи. З
іншого боку, ітеративну розробку називають по-різному: інкрементальною, спіральною, еволюційною та поступовою. Різні ідеологи вкладають у ці терміни різний зміст, але ці відмінності не мають широкого визнання і не так важливі, як протистояння між ітеративним методом та методом водоспаду.
Оскільки при ідеальних умовах результатом кожного кроку є працююча система, ітеративна модель має такі переваги: можливість раннього тестування користувачами; можливість щодо впровадження стратегії розробки відповідно до бюджету, яка в свою чергу повністю захищає від перевитрати часу або коштів, зокрема за рахунок скорочення другорядної функціональності.
Таким чином, значимість еволюційного підходу на основі організації
ітерацій особливо помітне у зниженні ступеню невизначеності із завершенням кожної ітерації, де зниження невизначеності дозволяє зменшити ризики.
Найбільш відомим і поширеним варіантом еволюційної моделі є спіральна модель.
1.1.1.3. Спіральна модель життєвого циклу розробки ПЗ.
Модель була вперше сформульована Баррі Боемі (Barry Boehm) в 1988 році. Відмінною особливістю цієї моделі є виділення ризиків, що впливають на організацію життєвого циклу. Велика частина цих ризиків пов'язана з організаційними аспектами взаємодії фахівців у проектній команді [15].
Спіральна модель ЖЦ зосереджена на початкових етапах: аналізі та

12 проектуванні. На цих етапах реалізація технічних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ, де уточнюються цілі та характеристики проекту, визначається його якість та плануються роботи наступного витка спіралі.
Таким чином, деталі проекту поглиблюються і послідовно конкретизуються, в результаті чого вибирається обґрунтований варіант, що доводиться до реалізації.
Розробка методом ітерацій відражає об'єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап без очікування повного завершення роботи на поточному. При ітеративному способі розробки, роботу, що відсутня можливо виконати на наступній ітерації. Головне завдання полягає у тому щоб якомога швидше показати замовнику працездатний продукт, тим самим активізуючи процес уточнення та доповнення вимог.
Перелічимо основні переваги спіральної моделі: модель приділяє спеціальну увагу передчасному аналізу можливостей повторного використання; модель передбачає можливість еволюції життєвого циклу, розвиток і зміну програмного продукту; модель надає механізми досягнення необхідних параметрів якості як складову частину процесу розробки програмного продукту; модель приділяє спеціальну увагу запобіганню помилок і відкиданню непотрібних, необґрунтованих або незадовільних альтернатив на ранніх етапах проекту; модель дозволяє контролювати проектні роботи та відповідні витрати; у моделі не існує різниці між розробкою нового продукту і розширенням (або супроводом) існуючого; модель дозволяє вирішувати інтегровані завдання системної розробки, що охоплюють як програмну, так і апаратну складові створюваного продукту.
Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її вирішення необхідно вводити тимчасові обмеження на кожен з етапів життєвого циклу [16]. При цьому перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. Такий план складається на основі статистичних даних, отриманих у попередніх проектах, та особистого досвіду розробників. Боемі[17], описуючи створену спіральну модель, звертає увагу на те, що поряд з явними перевагами в порівнянні з іншими моделями життєвого циклу, при використанні


Поділіться з Вашими друзьями:
  1   2   3


База даних захищена авторським правом ©divovo.in.ua 2017
звернутися до адміністрації

войти | регистрация
    Головна сторінка


загрузить материал