Метод покриття операторів
Метою цього методу тестування є виконання кожного оператора програми хоча б один раз.
Метод покриття рішень (покриття переходів)
Згідно з методом покриття рішень кожен напрямок переходу має бути реалізовано, по крайней мере, один раз. Цей метод включає в себе критерій покриття операторів, так як при виконанні всіх напрямків переходів виконуватися всі оператори, що знаходяться на цих напрямках.
Метод покриття умов
Цей метод може дати кращі результати в порівнянні з попередніми. Відповідно до методу покриття умов записується число тестів, достатню для того, щоб всі можливі результати кожної умови в рішенні виконувалися, по крайней мере, один раз.
Метод покриття рішень / умов
Критерій покриття рішень / умов вимагає такого достатнього набору тестів, щоб всі можливі результати кожної умови виконувалися принаймні один раз, все результати кожного рішення виконувалися принаймні один раз і, крім того, кожній точці входу передавалося управління по крайней мере один раз.
не завжди можна перевірити всі умови;
неможливо перевірити умови, які приховані іншими умовами;
недостатня чутливість до помилок в логічних виразах.
Метод комбинаторного покриття умов
Критерій комбинаторного покриття умов задовольняє також і критеріями покриття рішень, покриття умов і покриття рішень / умов.
Цей метод вимагає створення такого числа тестів, щоб всі можливі комбінації результатів умови в кожному рішенні виконувалися принаймні один раз. За цим критерієм в даному прикладі повинні бути покриті тестами наступні вісім комбінацій:
Порядок виконання роботи
Спроектувати тести за принципом «білого ящика» для програми, розробленої в лабораторній роботі № 4. Використовувати схеми алгоритмів, розроблені і уточнені в лабораторних роботах № 2, 3.
Вибрати кілька алгоритмів для тестування і позначити буквами або цифрами гілки цих алгоритмів.
Виписати шляху алгоритму, які повинні бути перевірені тестами для обраного методу тестування.
Записати тести, які дозволять пройти шляхами алгоритму.
Протестувати розроблену вами програму. Результати оформити у вигляді таблиць.
Перевірити всі види тестів і зробити висновки про їх ефективність.
Захист звіту з лабораторної роботи
Звіт з лабораторної роботи повинен складатися з:
Таблиць тестування програми.
Висновків за результатами тестування (не забувайте, що метою тестування є виявлення помилок в програмі).
Охарактеризуйте етап реалізації і тестування програмного продукту.
Які існують види тестування?
Назвіть критерії вибору тестів.
Перерахуйте властивості тестів.
Наведіть критерії надійності програм.
У чому полягає оцінка надійності програм
Лабораторна робота № 5. Проектування програмної системи при об'єктному підході до програмування
Мета роботи: познайомити студентів з методом проектування системи шляхом CRC-карт.
Важливим етапом створення програмного забезпечення є проектування. На цьому кроці закладається архітектура системи.
Одним із способів проектування є метод CRC- карток. Цей метод проектування є складовою UML-проектування.
Крок перший. Для початкового розуміння структури програми будується діаграма варіантів використання: виявляються актори (люди або системи, між якими відбувається взаємодія), прецеденти системи (дії, що виконуються системою для реалізації спілкування акторів).
Діаграма варіантів використання для прикладу «Банкомат» приведена на рис. 1.
Насправді прецедентів може бути дуже багато. Припустимо: перевірити пароль, контролювати транзакції передачі даних, видати інформацію на екран і т. Д.
Ця діаграма дає зрозуміти, що буде робити система, як вона функціонуватиме. Діаграма використання буває також дуже корисна для спілкування з замовником - вона дозволяє показати найбільш значущі дії системи і перевірити, чи правильно ви зрозуміли замовника і значимість окремих функцій для нього.
Крок другий. На цьому етапі виявляють класи, які необхідно буде створити в програмі для реалізації системи. У разі банкомату це: клієнт, банк, служба безпеки банку. сам банкомат і т. д.
Придумати можна багато (таймер, лічильник купюр, картка і т. Д.).
Далі оформляються CRC-карти. Це листки паперу 10 х 15. Вони розділені на три частини і виглядають наступним чином - рис. Л8.2.
На прикладі того ж банкомату - рис. Л8.3.
Мал. Л8.3. Приклади CRC-карт
Крок третій. Для перевірки достатності або надмірності придуманих класів, а також коректності їх взаємодії будується діаграма взаємодії (рис. Л8.4).
Мал. J18.4. діаграма взаємодії
Метод CRC-карток дозволяє провести також інсценізацію роботи системи. Для цього достатньо роздати картки з класами учасникам проекту. Після цього почати рольову гру. Перший учасник встає і читає дія, що здійснюється його класом. Інші учасники, виходячи зі своїх карток, повідомляють про реакцію інших класів. Якщо в якийсь момент реакції не буде, то це ознака недосконалості проекту системи. Така гра може підказати і про надмірності проекту.
Порядок виконання роботи
Відповідно до варіанта завдання, запропонованим викладачем, визначити дійових осіб (акторів) системи.
Визначити варіанти використання системи та описати їх у короткій або повній формі.
Побудувати діаграму варіантів використання системи (використовувати MS Office або MS Visio).
Визначити класи проектованої системи.
Створити CRC-карти для всіх класів системи (використовувати MS Office або MS Visio).
Побудувати діаграму взаємодії (використовувати MS Office або MS Visio).
Здати і захистити роботу.
Захист звіту з лабораторної роботи
Звіт з лабораторної роботи повинен складатися з:
Описи дійових осіб і прецедентів системи.
Захист звіту з лабораторної роботи полягає в пред'явленні викладачеві отриманих результатів (на екрані монітора), демонстрації отриманих навичок і відповідях на питання викладача.
Охарактеризуйте проектування ПО при об'єктному підході.
У чому полягає моделювання предметної області при проектуванні ПО?
Мова іМ1_. Його призначення, переваги і недоліки.
Опишіть варіанти використання ПЗ.
Перерахуйте діаграми в мові їм (_.
Наведіть приклад діаграми прецедентів.
7 Наведіть приклад діаграми взаємодії.
В чому полягає призначення і використання СРС-карт?
Замовлення квитків в аеропорту.
Система охорони приватного будинку.
Система безпеки в'язниці.
Система безпеки польоту літака.
Лабораторні роботи № 1-5 виконуються для одного і того ж варіанту.
Розробити програмний модуль «Облік успішності студентів». Програмний модуль призначений для оперативного обліку успішності студентів в сесію деканом, заступниками декана і співробітниками деканату. Відомості про успішність студентів повинні зберігатися протягом всього терміну їх навчання і використовуватися при складанні довідок про прослухані курси та додатків до диплому.
Розробити програмний модуль «Особові справи студентів». Програмний модуль призначений для отримання відомостей про студентів співробітниками деканату, профкому і відділу кадрів. Відомості повинні зберігатися протягом всього терміну навчання студентів і використовуватися при складанні довідок і звітів.
Розробити програмний модуль «Рішення комбинаторно-оптимізаційних задач». Модуль повинен містити алгоритми пошуку циклу мінімальної довжини (завдання комівояжера), пошуку найкоротшого шляху і пошуку мінімального зв'язує дерева.
Розробити додаток Windows «Калькулятор». Додаток призначений для будь-яких користувачів і повинно містити всі арифметичні операції (з дотриманням пріоритетів) і бажано (але не обов'язково) кілька математичних функцій.
Розробити програмний модуль «Кафедра», який містить відомості про співробітників кафедри (ПІБ, посада, науковий ступінь, дисципліни, навантаження, громадська робота, сумісництво та ін.). Модуль призначений для використання співробітниками відділу кадрів і деканату.
Розробити програмний модуль «Лабораторія», який містить відомості про співробітників лабораторії (ПІБ, стать, вік, сімейний стан, наявність дітей, посада, науковий ступінь). Модуль призначений для використання співробітниками профкому і відділу кадрів.
Розробити програмний модуль «Автосервіс». При записи на обслуговування заповнюється заявка, в якій вказуються ПІБ власника, марка автомобіля, вид роботи, дата прийому замовлення і вартість ремонту. Після виконання робіт роздруковується квитанція.
Розробити програмний модуль «Облік порушень правил дорожнього руху». Для кожної автомашини (і її власника) в базі зберігається список порушень. Для кожного порушення фіксується дата, час, вид порушення і розмір штрафу. При оплаті всіх штрафів машина видаляється з бази.
Розробити програмний модуль «Картотека агентства нерухомості», призначений для використання працівниками агентства. У базі містяться відомості про квартирах (кількість кімнат, поверх, метраж та ін.). При надходженні заявки на обмін (куплю, продаж) проводиться пошук відповідного варіанту. Якщо такого немає, клієнт заноситься в клієнтську базу і оповіщається, коли варіант з'являється.
Розробити програмний модуль «Авіакаса», що містить відомості про наявність вільних місць на авіамаршрути. У базі повинні міститися відомості про номер рейсу, екіпаж, тип літака, дату і час вильоту, а також вартості авіаквитків (різного класу). При надходженні заявки на квитки програма здійснює пошук відповідного рейсу.
Розробити програмний модуль «Автостоянка». У програмі міститься інформація про марку автомобіля, його власника, дату і час в'їзду, вартості стоянки, знижки, заборгованості по оплаті і ін.
Розробити програмний модуль «Кадрове агентство", що містить відомості про вакансії і резюме. Програмний модуль призначений як для пошуку співробітника, що відповідає вимогам керівників фірми, так і для пошуку підходящої роботи.
Примітка. При розробці програми не обмежуватися функціями, наведеними в варіанті, додати кілька своїх функцій. Обов'язкове використання структурного та модульного підходів до програмування. Бажано використання об'єктного підходу
Вельбицький І. В. Технологія програмування. Київ, 1984.
Gause, Weinberg. Exploring Requirements: Quality Before Design, 1989
Boehm A. Spiral Model of Software Development and Enhancement // Computer. 1988. Vol. 21. № 5. P. 61-72.
Алістер Коуберн, Лорі Вільямс. Парне програмування: переваги і недоліки.
Ожегов С. І. Словник російської мови. М. Радянська Енциклопедія, 1975.
Радянський енциклопедичний словник. М. Радянська Енциклопедія, 1979.
Політехнічний словник / Гол. ред. акад. А. Ю. Ішлінський.
е изд. М. Радянська Енциклопедія, 1980.
McCabe T.J.fButler Ch. W Design complexity measurement and testing Communications of the ACM. 32, 12 (Dec. 1989). P. 1415-1425.
Уолш Б. Програмування на Бейсике. М. Радио и связь, 1988.
Х'юзДж. Мічтом Дж. Структурний підхід до програмування. М. Світ, 1980. С. 29-71.
Жоголєв Е. А. Технологічні основи модульного програмування // Програмування. 1980. № 2. С. 44-49.
Holt R.С. Structure of Computer Programs: A Survey // Proceedings of the IEEE. 1975. 63 (6). P. 879-893.
Зелковец М. Шоу А. Геннон Дж. Принципи розробки програмного забезпечення. М. Світ, 1982. С. 65-71.
Дав У. Дейкстра Е. Хоор К. Структурний програмування. М. Світ, 1975. С. 7-19.
Object Management Group Inc. Специфікація уніфікованої мови моделювання OMG версія 1.5. документ номер
Боем Б. Інженерне проектування програмного забезпечення. М. Радио и связь, 1985.
Visual C ++ 6. Керівництво розробника.