6 Тестування програмного засобу

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

• продемонструвати розробникам і замовникам, що програма відповідає вимогам;

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

Рівні тестування діляться на:

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

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

• Системне тестування - тестується інтегрована система на її відповідність вимогам.

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

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

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

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

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

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

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

Переваги тестування «чорного ящика».

Існуючі технології були досліджені і проаналізовані. З перерахованих вище методів обраний метод «чорного ящика».

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

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

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

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

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

• Тестувальник сайтів або ПЗ не потрібні знання будь-яких спеціальних мов програмування,

• тестування є об'єктивним, так як дизайнер і тестувальник ПЗ незалежні один від одного,

• тест кейсиможуть бути розроблені відразу після підготовки специфікацій.

Щоб створити новий проект, потрібно клікнути на кнопку «Schema» далі натиснути на кнопку «New», після чого з'явиться вікно «New Schema» з полями «Title» «Database» і кнопкою «Create New Schema».

Мал. 6.1 -Створення нового проекту

Після створення нового проекту з'являється головна сторінка, з пунктами меню «Schema», «Edit», «Insert», «View», «Export», «Help». Для того щоб створити нову таблицю потрібно клікнути на робочу область правою кнопкою миші, і натиснути на кнопку «Table».

Мал. 6.2 -Головна сторінка зі створеною новою таблицею

Для створення атрибута потрібно натиснути на кнопку «Add field». З'являється вікно з поля для введення «Name», «Type», «Size», «Default» і кнопками «Save» і «Cancel».

Мал. 6.3 -Створення нового атрибута

Редагування кожного атрибута буде здійснюватися після натискання на відповідну кнопку праворуч від типу атрибута.

Мал. 6.4 -редагування атрибута

Для того щоб створити зв'язок потрібно натиснути на відповідну кнопку праворуч від типу атрибута і вибрати пункт «Foreign Key» після чого з'явиться два списки «Ref. Table »і« Ref Field », потрібно вибрати потрібну таблицю і необхідний атрибут і натиснути на кнопку« Update ».

Мал. 6.5 -створення зв'язку

Після чого з'являється головна сторінка з вже створеними зв'язками між таблицями.

Мал. 6.6 -Головна сторінка з зв'язками між таблицями

ВИСНОВКИ

При виконані курсового проекту, БУВ проведень огляд CASE-ЗАСОБІВ, булу Розглянуто логічна модель Даних и ее представлення у виде ER-діаграмі.

В процесі проектування CASE-засоби для реалізації методу «Логічне моделювання Даних», результатом роботи котрого є ER-Діаграма.

Навчально-робоча група булу розділена на 3 роли, Які іменувалися як Користувачі, менеджери, розробник. У процесі Вивчення предметної області були визначені всі вимоги до CASE-засоби з боку Користувачів. З боку менеджера відбувалося управління процесом проектування, а з боку розробників були запропоновані и спроектовані оптимальні вимоги до CASE-засоби, а також БУВ спроектованій інтерфейс майбутнього, схема бази даних и узагальнена UseCase Діаграма.

Подальша розробка булу розділена на п'ять під задач, таких як:

а) проектування базової архітектури;

б) розробка дизайну и тестування;

в) управління розробка ПЗ.

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

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

ПЕРЕЛІК ПОСИЛАНЬ

1. Теорія "Моделювання потоків даних (процесів)" [Електронний ресурс] / Теорія "Моделювання потоків даних (процесів)". - Режим доступу: www / URL: http: //www.infosystem.ru/designing/methodology/dfd/dfd_theory_dfd.html#TopText

2. Теорія "Моделювання потоків даних (процесів)" [Електронний ресурс] / Теорія "Моделювання потоків даних (процесів)". - Режим доступу: www / URL: http://www.info-system.ru/designing/methodology/dfd / dfd _theory_dfd.html # TopText

3. CIT Forum [Електронний ресурс] / Загальне уявлення про інформаційну систему. - Режим доступу: www / URL: http://citforum.ru/cfin /prcorpsys/infsistpr_02.shtml

4. CIT Forum [Електронний ресурс] / Проектування і розробка корпоративних систем. - Режим доступу: www / URL: http://citforum.ru/cfin / prcorpsys /

5. BCG [Електронний ресурс] / Моделювання потоків даних. - Режим доступу: www / URL: http://bc-group.ru/?page_id=103

6. Методології функціонального моделювання [Електронний ресурс] / Діаграми потоків даних. Нотація Йордана - Де Марко. - Режим доступу: www / URL:http://www.mstu.edu.ru/study/materials/zelenkov/ch_5_3.html

7. Проектування [Електронний ресурс] / Проектування. - Режим доступу: www / URL: https://ru.wikipedia.org/wiki/Проектирование