- •1.Розробка системи оперативної довідки
- •1.1.Меню Help
- •1.2. Малюнок 1. Вікно довідки. Кнопка Help в екранній формі
- •1.4.Виклик контекстно-залежної довідки кнопкою What's This?
- •1.5. Малюнок 2. Екранна форма, у якій установлена кнопка виклику контекстної довідки. Використання html Help Workshop
- •1.5.1.Створення проекту системи оперативної довідки
- •Малюнок 3. Діалогове вікно New.
- •Малюнок 4. Діалогове вікно Existing Files.
- •1.5.2.Таблиця змісту
- •Малюнок 5. Вікно щойно створеного проекту.
- •Малюнок 6. Заповнення таблиці змісту.
- •1.5.3.Предметний покажчик
- •Малюнок 7. Заповнення контекстного вказівника.
- •1.5.4.Додавання в проект html-файлів розділів довідки
- •1.5.5. Малюнок 8. Заготівля html-файлу, оформлена html Help Workshop. Зв'язки між файлами розділів і url
- •1.6.Додавання і видалення файлів розділів довідки
- •Малюнок 9. Діалогове вікно Topіc Fіles.
- •1.7.Компіляція системи оперативної довідки
- •1.8.Контекстно-залежні розділи довідки
- •Малюнок 10. Діалогове вікно Options.
- •Малюнок 11. Wizard Selection
- •Малюнок 12. Вікно Application Builder.
- •1.8.1.Включення файлу відображення в проект системи оперативної довідки
- •1.8.2. Малюнок 13. Включення файлу відображення в проект системи оперативної довідки. Зв'язування HelpContextіD з html — файлами розділів довідки
- •1.8.3. Малюнок 14. Діалогове вікно для організації зв'язування файлів розділів довідки і HelpContextі у додатку. Розділи довідки, що викликаються кнопкою What's This?
- •Малюнок 15 Екранна форма Visual FoxPro, налаштована на використання довідки What's This?
- •1.9.Поширення готової системи оперативної довідки
- •2.Пошук і обробка помилок, тестування проекту
- •2.1.Проблема помилок у програмному продукті
- •2.2.Пошук помилок у програмному коді
- •2.2.1.Синтаксичні помилки
- •2.2.2.Логічні помилки
- •2.2.3.Виключення
- •2.3.Розбивка коду на модулі для мінімізації помилок
- •2.4.Помилки при передачі параметрів
- •2.5.Використання команд exіt і return
- •2.6.Обробка ушкоджених файлів
- •2.7.Тестування та налагодження додатків
- •2.7.1.Технологія тестування
- •2.7.2.Створення середовища для тестування
- •2.7.3.Створення тестових наборів даних, що забезпечують повноту накриття додатка
- •2.7.4.Документування тестових наборів
- •2.8.Методика перехоплення помилок
- •2.9.Налагоджувальник
- •Малюнок 16. Налагоджувальник Visual FoxPro.
- •2.9.1.Використання вікна Trace
- •Малюнок 17. Панель інструментів налагодження
- •Малюнок 18 Діалогове вікно Breakpoints
- •2.9.2.Використання вікна Locals
- •Малюнок 19. Діалогове вікно Locals
- •2.9.3.Використання вікна Watch
- •Малюнок 20. Діалогове вікно Watch.
- •2.9.4.Діалогове вікно Call Stack
- •2.9.5.Використання вікна Debug Output
- •2.9.6.Діалогове вікно Event Tracking
- •Малюнок 21. Діалогове вікно Event Tracking.
- •2.10.Використання Coverage Profiler
- •Малюнок 22. Додаток Coverage Profiler у режимі відображення покриття.
- •2.11. Малюнок 23. Додаток Coverage Profiler у режимі відображення профілю. Використання процедур обробки помилок
- •2.11.1.Використання методів обробки події error в об'єктах
- •3.Література
- •4.Перелік ілюстрацій
2.7.Тестування та налагодження додатків
Тестування додатка варто розглядати як окремий етап його розробки, якому в загальному графіку виконання робіт повинна бути приділена першорядна увага. При використанні програмних планувальників проекту типу Microsoft Project його потрібно включати в завдання в статусі окремої задачі. Існує безліч методик планування цього етапу. Деякі розроблювачі воліють приступати до тестування тільки після того, як весь програмний код додатка буде написаний. Але для середовища Visual FoxPro, з огляду на його інтерактивну природу, набагато продуктивніше використовувати стратегію паралельного тестування підзадач і компонентів додатку. Але тоді на плечі менеджера проекту лягає інша турбота: як відстежити час, що затрачується на таке паралельне тестування. У цьому розділі ви познайомитеся з різними методиками тестування і спробами проаналізувати за і проти кожної.
Чому віддати перевагу — даним чи логіці?
Тестування програмного продукту переслідує дві мети: перевірку достовірності результатів і перевірку правильності функціонування всіх компонентів програми. Перевірка достовірності результатів (тест достовірності – validity testing) дозволяє судити про те, чи формуються в процесі виконання додатка очікувані результати при заданому наборі вхідних даних. Перевірка правильності функціонування всіх компонентів програми (її часто називають тестом покриття – coverage testing) дозволяє судити про те, чи всі гілки програми функціонують правильно і чи не залишилося в ній “мін уповільненої дії”9. Про тест покриття мова йтиме пізніше, а зараз розглянемо докладніше методику тестування достовірності.
Існує два підходи до тестування достовірності. Перший — пріоритет у виконанні тестування віддається даним у вхідному наборі (його ще для стислості називають data - driven — відомий даними). Суть його полягає в тому, що за допомогою великої кількості варіантів набору вхідних даних (випадкових чи підготовлених заздалегідь) перевіряється достовірність результатів — чи відповідають вони очікуваним. При цьому можна не дуже поглиблюватися в особливості технології обробки цих даних у програмі що тестується.
Другий підхід, навпаки, припускає знання логіки обробки даних, і перевірці піддаються всі можливі логічні гілки програми (для стислості його називають logic - driven — відомий логікою). При цьому також перевіряється реакція програми на вхідні дані за межами відомих із предметної області фізичних обмежень.
Кожна методика має свої переваги і недоліки. Перевага методики, відомої даними, у тім, що вона вільна від свідомого чи підсвідомого прагнення підстроїтись під відому логіку обробки. Часто розроблювачі вважають, що програма ніколи не може одержати деякого набору вхідних даних, і в результаті ситуація що при цьому виникає вислизає від їхньої уваги. Недолік методики в тім, що теоретично неможливо (чи дуже важко при обмеженому часі тестування) перебрати всі можливі набори вхідних даних, гарантуючі, що програма побувала у всіх можливим для неї ситуаціях.
Методика, відома логікою, дозволяє перебороти зазначений недолік. Правильно організоване тестування за цією методикою змушує “спрацювати” кожен оператор у програмі. Звичайно, таке тестування вимагає вдумливої підготовки наборів вхідних даних і займає досить багато часу (вважаючи і підготовку, і власне тестування).