К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Модуль Функції М1. Реєстрація та імпорт Реєстрація документів, їх форм і даних про стан комплексу. Перехід у середовище Excel для опрацювання форм М2. Контроль стану Контроль опрацювання форм. Визначення ступеню повноти завантаження даних з форм за кожним надісланим документом (повністю, не повністю, не виконане) М3. Експорт Завантаження даних з форми до БД (підключення до сервера БД, параметризація збережених процедур, завантаження) М4. Контроль Контроль правильності наданих форм у Excel. Синтаксичний контроль форми (типи та формати даних, коди класифікаторів тощо) та семантичний контроль (непротирічність даних, відповідність обмеженням) М5. Запити до БД Запити до БД з метою виключення можливого дублювання інформації, яка надходить у формах з різних джерел Функції кожного з модулів М1-М5 дійсно є критичними для ПС, оскільки від їх безвідмовної роботи залежить цілісність системи. Для реєстрації часу виконання t та моментів відмов у модулі М1-М5 на час тестування були вбудовані відповідні фрагменти коду, що мали моменти початку та завершення (нормального або аварійного) роботи модуля та їх реєстрація у журналі подій і відмов. Очікуваний час t 0 використання кожного модуля при експлуатації ПС та їхні внески С м визначалися тижневе, місячно, а також – частоти звернення до модулів у кожному сеансі роботи ПК3. Отримані дані про відмови та оцінені параметри моделі надійності наведені в табл. 6.5. Вартість тестування і усунення відмов розраховувалася за такими чинниками: – вартості часу роботи фахівців (тестувальників та розробників); – визначеного реального часу виконання кожного модуля під час тестування та часу, витраченого на усунення дефектів. Таблиця 6.5. Оцінки параметрів моделі надійності для п’яти модулів ПК3 Модуль Кількість дефектів Коефіцієнт пропорційності М1. Реєстрація та імпорт 42.8 0.000082 М2. Контроль стану 43.1 0.000322 М3. Експорт 56.7 0.000076 М4. Контроль 46.6 0.00083 М5. Запити до БД 39.7 0.00017 Для модулів були встановлені значення різних даних з процесу тестування (табл. 6.6.), а саме, – вартість одиниці часу тестування с 1 = 0.8 грн. – вартість усунення дефекту с 2 = 60 грн. У цієї таблиці наведені отримані оцінки з часу функціонування модулів та даних про ризик та оптимальний час тестування. Таблиця 6.6. Оцінки часу використання, внесків, ризику та оптимального часу тестування модулів ПК3 Модуль Час викори- стання t 0 Внесок (грн) Cм(t 0 ) Очікувана кількість відмов µ(t e ) Ризик модуля R (t 0 ) Оцінка t * М1. Реєстрація та імпорт 160 25000 0.58625 14656.14 1699.54 М2. Контроль стану 100 5000 1.367 6835.33 1668.99 М3. Експорт 160 29000 0.685296 19872.61 4341.8 М4. Контроль 160 10000 1.14874 11487.4 3381.91 М5. Запити до БД 100 16000 0.74306 7440.63 488.246 Наведені таблиці з тестування групи програмних компонентів (ПК1–ПК7) демонструють послідовний процес аналізу і оброблення інформації при їхньому тестуванні і оцінюванні результатів. 6.5.3. Інженерія керування тестуванням За функціональні і системні тести несуть відповідальність розробник і замовник, останній більше впливає на складання тестів для випробувань системи [26, 28, 32]. Цей процес реалізує група тестувальників, що не залежать від групи розробників ПС. Її очолює керівник групи, який повинен мати: – досвід в області тестування; – здатність бути лідером і керувати групою тестувальників; – знання з задач предметної області ( і програмного продукту); – знання з інфраструктури (апаратного і системного програмного забезпечення). Рядовий тестувальник повинен знати: – галузь виробництва продуктів/технологій створення ПС; – елементи інфраструктури розроблення ПС; – вимоги до системи і стандарти тестування; – підходи до використання робочих продуктів процесу тестування; – інструменти і стратегії тестування; – вміти аналізувати результати і підбирати нові тестові дані або додавати дані для оцінювання процесу тестування. Деякі члени цієї групи – досвідчені фахівці або навіть професіонали в цій галузі. До них також належать аналітики, програмісти, що працюють в галузі розроблення систем від її початку. Вони мають справу не тільки зі специфікаціями, а й з методами і засобами проектування, тестування, організують створення і Розділ 6 179 виконання тестів. Із самого початку тестувальники складають плани тестування, тестові дані, сценарії, а також графіки виконання тестів. Професійні тестувальники працюють разом із групою керування конфігурацією, щоб забезпечити їх документацією й іншими механізмами для зв'язку між собою тестів і вимог проекту, конфігурації і коду. Вони розробляють методи і процедури тестування. У цю команду включаються додаткові фахівці, що ознайомлені з вимогами системи або з підходами до її розробки. Аналітики входять до складу команди, тому що вони розуміють проблеми визначення специфікацій замовників. Багато фахівців порівнюють тестування системи зі створенням нової системи, у якій аналітики визначають потреби і цілі замовника, працюючи разом із проектувальниками і намагаючись реалізувати ідеї і принципи роботи системи. Проектувальники системи повідомляють групі тестувальників проектні цілі, щоб вони знали декомпозицію системи на підсистеми і її функції, а також принципи роботи. Після проектування тестів група тестувальників проводить аналіз можливостей системи. Оскільки тести і тестові сценарії є прямим відображенням вимог до проекту в цілому, перспективи керування конфігурацією системи визначаються саме цією групою. Зміни, що виявляються в програмі, помилки в системі відбивають у документації, вимогах, проекті, а також в описах вхідних і вихідних даних або в інших розроблюваних артефактах. Внесені зміни в процесі розроблення призводять до модифікації тестових сценаріїв або більшою мірою до зміни планів тестування. Фахівці з керування конфігурацією враховують ці зміни і координують складання тестів з її урахуванням. До групи тестувальників входять також користувачі. Вони оцінюють отримувані результати, зручність використання, а також висловлюють свою думку про принципи роботи системи. Уповноважені замовника планують роботи доти, поки використовується і супроводжується система. При цьому вони можуть привнести деякі зміни в проект через неповноту заданих вимог і сформулювати системні вимоги для проведення верифікації системи і прийняття рішень про її готовність і корисність. Планування тестування. Для проведення тестування розробляється план (Test Plan), у якому описуються стратегії, ресурси і графік тестування окремих компонентів і системи в цілому. У плані визначаються роботи для різних членів команди, що виконують свої ролі в цьому процесі. План містить у собі також визначення ролі тестів у кожнім процесі, ступінь покриття програми тестами і відсоток тестів, що виконуються зі спеціальними даними. Тестові інженери створюють тестові сценарії (Test Cases), кожний з яких перевіряє результат взаємодії між актором і системою на основі перед- і постумов використання таких сценаріїв. Сценарії в основному належать до тестування за типом «білої скриньки» і орієнтовані на перевірку структури й операцій інтеграції компонентів системи. Для проведення тестування тестові інженери пропонують процедури тестування (Test Procedures), що вміщують валідацію об'єктів і верифікацію тестових сценаріїв відповідно до плану графіку. Оцінка тестів (Test Evaluation) полягає в оцінці результатів тестування, ступеня покриття програм сценаріями і статусу отриманих помилок. На рис. 6.6. наведено коло обов'язків інженера- тестувальника. Тестувальник інтегрованої системи перевіряє інтерфейси і дає оцінку виконання відповідних системних тестів, а потім аналізує результати тестування. Рис. 6.6. Схема відповідальності інженера-тестувальника При виконанні цих тестів, як правило, знаходяться дефекти з причини глибоко захованих недоліків у програмах, що виявляються при тривалому тестуванні системи на тестових даних. Керування тестуванням. Усі засоби тестування ПС об’єднуються базою даних, де містяться результати тестування системи, а також компоненти, тестові контрольні дані й інформацію про документування процесу тестування. База даних проекту підтримується спеціальними інструментальними CASE- засобами, що забезпечують ведення аналізу ПрО, збирання даних про їхні об'єкти, потоки даних тощо. База даних проекту зберігає також початкові й еталонні дані, що використовуються для зіставлення даних, накопичених у базі, з даними, що отримані в процесі тестування системи. При тестуванні виконуються різні види обчислень характеристик цього процесу за методами планування і керування. 1. Розрахунок тривалості виконання функцій шляхом збирання середніх показників швидкості виконання операторів без виконання програми на машині. Виявляються компоненти, що вимагають тривалого часу виконання в реальному середовищі. 2.Керування виконанням тестування шляхом підбору тестів перевірки, їхнього виконання, селекції результатів тестування і зіставлення їх з еталонними значеннями. Результати даного процесу відображаються на дисплеї, наприклад, гілки виконання у графічній формі, дані про відмови і помилки або конкретні значення вихідних параметрів програми. Ці дані аналізуються розробниками для формулювання висновків про напрями подальшої перевірки правильності програми або їхньому завершенні. 3. Планування тестування призначене для розподілу термінів робіт з тестування, розподілу тестувальник за окремими видами робіт і складання ними тестів перевірки системи. Визначається стратегія і шляхи тестування. У діалозі запитуються дані про реальні значення процесу виконання системи, структури розгалуження вершин графа і параметрах циклів. Перевірені цикли, як правило, вилучаються зі шляхів виконання програми. При плануванні шляхів виконання створюються відповідні тести, критерії і вхідні значення. 4. Результати тестування документуються відповідно до діючого стандарту ANSI/IEEE 829 і містять у собі: – опис задач, призначення і зміст ПС, а також перелік функцій відповідно до вимог замовника; Розділ 6 181 – технологію розробки системи; – плани тестування різних об'єктів, що відповідають технологічним прийомам проведення тестування; – тести, контрольні приклади, критерії і обмеження, методику оцінки результатів виконання програмного продукту на процесі тестування; – облік процесу тестування, складання звітів про аномальні події, відмови і дефекти в підсумковому документі системи. Висновки. Були розглянуті формальні специфікації програм, методи доведення програм за ними, а також сучасні методи і процеси верифікації та тестування ПС, засновані на понятті програм – «біла скринька» і «чорна скринька». Визначено критерії тестування, типи помилок, що виявляються в програмах, а також відмови і помилки на процесах ЖЦ. Сформульовано методи забезпечення процесів отримання правильних програм за допомогою спеціальних груп фахівців, зокрема тестувальників. Контрольні питання і завдання 1. Назвіть формальні методи перевірки правильності програм. 2. Визначте формальну специфікацію. 3. Визначте основні поняття формальної специфікації VDM і RAISE. 4. Визначте мету і структуру концепторної мови. 5. Визначте поняття передумов і постумов, аксіом і тверджень. 6. Опишіть, як проходить процес доведення специфікованої програми і назвіть проблеми проведення доведення. 7. Які процеси перевірки зафіксовані в стандарті? 8. Назвіть задачі процесів верифікації і валідації програм. 9. Опишіть міжнародний проект з верифікації. 10. Визначте процес тестування та методи тестування. 11. Поясніть значення термінів «чорна скринька» та «біла скринька». 12. Назвіть об'єкти тестування і підходи до їхнього тестування. 13. Яка існує класифікація типів помилок і тестів перевірки програм. 14. Назвіть сутність інфраструктури організації робіт з тестування? Список літератури до розділу 6 1. Марков А.А. Теория алгоритмов // Москва, АН СССР. – 1954. – 231 с. 2. Ляпунов А.А. О логических схемах программ// Проблемы кибернетики.– вып.1. – М.: 1958. 3. Янов Ю.И. О логических схемах алгоритмов// Проблемы кибернетики.– вып.1. – М.: 1958. 4. Hoare C.A.R. Рrof of correctness of data representation // Acta Informatica, 1(4).– 271– 287. – 1972. – P. 214–224. 5. Андерсон Р. Доказательство правильности программ. – М.: Мир, 1982. – 165 с. 6. Abrial I.R., Meyer B. Spesification Language Z. – Boston: Massachusetts Computer Associates Inc., 1979. – 378 p. 7. Biorner D., Jones C.B. The Vienna Development Methods (VDM): The Meta – Language. – Vol. 61 of Lecture Notes in Computer Science. – Springer Verlag, Heiderberg, Germany, 1978. – 215 p. 8. Петренко А.К. Венский метод разработки программ // Программирование.– 2001. – № 1. – С. 3–23. 9. The RAISE Language Group. The RAISE Spesification Language. BCS Practitioner Series. – Prentice Hall, 1982. – 397 p. 10. The RAISE Methods Group. The RAISE Development Methods. BCS Practitioner Series. – Prentice Hall, 1985. – 493p. 11. Агафонов В.Н. Спецификации программ: понятийные средства и их организация.– Новосибирск: Наука, 1987. – 240 с. 12. Непомнящий В.А., Сулимов А.А. Об одном подходе к спецификации и верификации трансляторов. М.: Программирование.– 1983.– № 4. – С. 51– 58. 13. Непомнящий В.А., Шилов Н.В., Бодин Е.В. Спецификация и верификация распределенных систем средствами языка Elementary–real// М.: Программирование.– 1999. – № 4. – С. 54–67. 14. Вудкок Д. Первые шаги к решению проблемы верификации программ// Открытые системы.– 2006.–№8.– С. 36-43. 15. Hoare T., Misra J. Verified software: Theories, Tools, Experiments. Vision of Grant Challenge project.–Microsoft Research Ltd and the University of Texas at Austin, 2005.– 1–43c. 16. Коваль В.Н. Концепторные языки. Доказательное проектирование.– Киев.– Наук. думка, 2001.– 182с. 17. Хоар Ч., Лауер П.Е.Непротиворечивые взаимодополняющие теории семантики языков программирования// М.: Мир, 1980.–C.186–221. 18. Dolores R. Wallase M. Ippolito, Cuthill B.Reference Information for the Software Verification and Validation Process // NIST Special Publication. – 1996 . – 80p. 19. Herhart S.L. Program Verification in the 90’s.// Proc. Conf. on Computing in the 1980’s, 1978.– P.80–89. 20. Fei Xie and James C. Browne. Verified Systems by Composition from Verified Components {feixie, browne}@cs.utexas.edu. 21. Майерс Г. Искусство тестирования программ. – Пер.с англ. M.: Финансы и статистика. – 1982. – 176 с. 22. Иванников В.П., Дышлевый К.В., Мажелей С.Г., Садовская Д.Б., Шебуняев А.Б. Распределенные объектно-ориентированные среды // М.: Труды ИСП РАН, 2000.–с.84–100 23. Липаев В.В. Тестирование программ. – М.: Радио и связь, 1986. – 295 с. 24. Канер С., Фолк Д., Нгуен Е.К. Тестирование программного обеспечения: Пер с англ. – Киев: DiaSoft. – 2000. – 544 с. 25. Weyuker E.J., Ostrand T.J. Theories of program testing and the application of revealing subdomains // IEEE Trans.Soft.Eng. – 1980. – 6. – №. 3, – P. 236– 246. 26. Андон Ф.И., Коваль Г.И., Лаврищева Е.М., Коротун Т.M., Суслов В.Ю, Основы инженерии качества программных систем. – Киев: Академпериодика.–Второе изд.– 2007. – 680с. 27. http://research.microsoft.com/specsharp/ 28. ISO/IEC 12207: 2002. Information technology – Software life cycle processes). Информационные технологи. – Процессы жизненного цикла программного обеспечения. Розділ 6 183 29. Соммервил И. Инженерия программного обеспечения.–6 издание.– Москва–Санкт–Петербург–Киев, 2002.–623 с. 30. CASE–93. Proceeding Sixth Intern. // Workshop on Computer Aided Software Engineering. – Singapure. – 1993. – July 19–23. – 418 p. 31. Лаврищева Е.М., Коротун Т.М. Построение процесса тестирования программных систем // Проблемы программирования.–2002.–№1–2.– С.272–281. 32. Бабенко Л.П., Лавріщева К.М. Основи программноі інженерії. – Киев: Знання, 2001. – 269 с. 33. Коротун Т.М. Модели и методы инженерии тестирования программных систем в условиях ограниченных ресурсов. – Автореф. дис. … канд.-физ.- мат. наук. – Киев: Ин-т кибернетики им. В.М. Глушкова НАН Украины, 2005. – 21 с. 184 Розділ 7. ІНТЕРФЕЙСИ, ВЗАЄМОДІЯ, ЕВОЛЮЦІЯ ПРОГРАМ І ДАНИХ У цьому розділі розглядаються базові поняття з програмної інженерії, які необхідні для виробництва ПС. До них відносять: інтерфейси, засоби їхнього подання; взаємодія різномовних програм за інтерфейсом; перетворення і змінювання програм і даних. Описано різні види інтерфейсів, методи перетворення нееквівалентних типів даних взаємодіючих різномовних програм. Визначено задачі неоднорідності МП, платформ і середовищ, що впливають на зв'язки різномовних програм, сформульовано шляхи їхнього розв’язання. Розглянуто стандарт ISO/IEC 11404 –1996 про незалежні від сучасних МП типів даних і забезпечення універсальним апаратом їхнього перетворення і форматів даних, а також еволюційне змінювання програм. 7.1. Визначення інтерфейсу у програмуванні Інтерфейс – це зв'язок двох окремих сутностей. Види інтерфейсів: мовні, програмні, апаратні, призначені для користувача, цифрові і т.п. Програмний (API) і/або апаратний інтерфейс (port) – це способи перетворення вхідних/вихідних даних під час об'єднання комп'ютера з периферійним обладнанням. У МП – це програма або частина програми, в якій визначаються константи, змінні, параметри і структури даних для передачі іншим. У програмуванні термін інтерфейс містить в собі набір операцій, що забезпечують визначення видів послуг і способів їхнього отримання від програмного об'єкта, що надає ці послуги. На початковому процесі програмування в ролі інтерфейсу виступають оператори звернення до його процедур і функцій програм через формальні параметри. Програми, процедури і функції записувалися в одній МП. Оператори звернення вміщували імена об'єктів (процедур і функцій), що викликаються, список фактичних параметрів з завданням їх значень і параметрів, що одержують результати. Послідовність і число формальних параметрів відповідало фактичним параметрам. Виконання функції в середовищі програми на одній МП не викликало проблем, оскільки типи даних параметрів збігалися. У разі, коли один з елементів (програма, процедура або функція) записаний на різних МП і, крім того, якщо всі ці елементи розташовуються на різних комп'ютерах, то виникають проблеми неоднорідності типів даних в цих МП, структурах пам'яті платформ комп'ютерів і операційних середовищ, де вони виконуються. Поняття інтерфейсу як самостійного об'єкта сформувалося у зв'язку із складанням або об'єднанням різномовних програм і модулів в монолітну систему на великих ЕОМ (mainframes) [1, 2]. Інтерфейс відігравав роль посередника між модулями, що викликаються і викликають. У ньому задавали опис формальних і фактичних параметрів, проводили перевірку відповідності параметрів, що передаються (кількість і порядок розташування), а також їхніх типів даних. Якщо типи даних параметрів виявлялися нерелевантними (наприклад, передається ціле, а результат функції – дійсне або навпаки), то проводилося їхнє пряме і обернене перетворення з урахуванням Розділ 7 185 структури пам'яті комп'ютерів. На рис. 7.1 наведено схему програми С, в якій містяться два виклики – Call A ( ) і Call B ( ) з параметрами, що через інтерфейсні модулі-посередники A’ і B’ здійснюють перетворення даних і їх передачу модулям А і В. Рис. 7.1. Схема зв’язків модулів А і В із С через інтерфейси А’ і B’ Після виконання модулів А і В їхні результати передаються тим же модулями-посередникам, які перетворюють отримані дані до типів даних програми С. |