Метод Delete

Для видалення існуючих записів використовується метод Delete.

Datal.Recordset.Delete

 

 

Метод Delete використовують для видалення поточного запису з об'єкту Recordset або для видалення об'єктів з сімейств, таких як збережена таблиця в базі даних, збережене поле або збережений індекс в таблиці. Видалений запис залишається поточним записом, хоча його не можна змінити або використати. Після переходу на інший запис зробити видалений запис поточним записом неможливо. Подальші посилання на видалений запис в об'єкті Recordset є недо­пустимими і приводять до помилки. Тому після застосування цього методу слід додатково викликати один з Move-ме­тодів, наприклад MoveFirst.

 

 

Лекція 25. Створення процедур для обробки подій мишки.

 

Додатки Visual Basic можуть реагувати на різноманітні події, викликані

мишею чи клавіатурою. Наприклад, при створенні проектів можна використо-

вувати події MouseDown(Миша вниз), MouseUp(Миша вверх) та MouseMove

(Переміщення миші), щоб дозволити додаткам реагувати на положення курсора

і на стан миші.

MouseDown– відбувається при натисканні будь-якої кнопки миші;

MouseUp– відбувається при відпусканні будь-якої натиснутої кнопки

миші; MouseMove– відбувається при переміщуванні покажчика миші у нову то-

чку екрана.

Зазначені події миші використовують такі параметри:

Button– параметр, що є бітовим полем, в якому три найменш значимі бі-

ти відповідають за стан кнопок миші;

Shift– параметр, що є бітовим полем, в якому три молодших біти відпо-

відають за стан клавіш Shift, Ctrl та Alt;

х, у– розташування покажчика миші в системі

координат об’єкта, який реагує на події миші.

Приклад 1 Використання події MouseDownта

методу Lineдля створення додатка, який при кожно-

му натисканні кнопки миші малює відрізок прямої лі-

нії з останньої намальованої точки в нове положення

покажчика миші – точку з координатами (х, у):

Private Sub Form_MouseDown (Button As Integer, Shift As Integer,X As Single, Y As Single)

Line-(X, Y)

End Sub

Приклад 2. Використання події MouseMoveра-

зом з методом Lineдля малювання неперервних

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

MouseMove розпізнається, тільки-но покажчик ми-

ші змінює своє положення:

Private Sub Form_MouseMove (Button As Integer,_

Shift As Integer, X As Single, Y As Single)

Line-(X, Y)

End Sub

Рисунок 3.2 – Результат

роботи приклада 2

Програмування22 в Visual Basic

Подія MouseUpвідбувається, коли користувач відпускає натиснену раніш

кнопку миші, і є корисним доповненням до подійMouseDownтаMouseMove.

Приклад 3 Використання подій MouseUp, MouseDownта MouseMoveдля

малювання лише за натисненої кнопки миші та припинення режиму малювання

при відпусканні кнопки миші. Події MouseDownта MouseUpповідомляють до-

даткові, коли “вмикати” рисування та коли його “вимикати”. У програмі для цьо-

го оголошують спеціальну логічну змінну DrawNow. Процедура оброблення по-

дії MouseMoveмалює лінію, лише якщо значення змінної DrawNow дорівнює

True, а інакше – вона не виконує жодних дій:

Dim DrawNow As Boolean

Private Sub Form_MouseDown (Button As Integer, Shift As Integer, X As Single, Y As Single)

DrawNow = True

CurrentX = X

CurrentY = Y

End Sub

Private Sub Form_MouseUp (Button As Integer, Shift As Integer, X As Single, Y As Single)

DrawNow = False

End Sub

Private Sub Form_MouseMove (Button As Integer, Shift As Integer, X As Single, Y As Single)

If DrawNow Then Line-(X, Y)

End Sub

Щоразу, коли користувач натискає кнопку миші, виконується процедура

оброблення події MouseDown, яка включає режим рисування. Потім, коли ко-

ристувач утримує кнопку натисненою й переміщує покажчик екраном, з пев-

ною частотою виконується процедура оброблення події MouseMove.

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

лення подій MouseDown, Mouseupта MouseMoveвикористовувати парамет-

ри buttonта shift.Ці параметри дозволяють розрізнювати, яку з кнопок миші

або яку з клавіш <Shift>, <Ctrl> чи <Alt> було натиснено.

Значенням параметра buttonє бітове поле – три молодших біти в ньому

ідентифікують натискання лівої, правої й середньої кнопок миші.

Молодші біти

0 ….. 0 0 M R L – Ліва кнопка

Старші біти

не використовуються Середня кнопка Права кнопка

За замовчуванням значення кожного біта дорівнює 0 (False). Якщо не на-

тиснено жодну кнопку, двійкове значення трьох бітів дорівнює 000. При натис-

канні лівої кнопки значення першого біта, який відповідає лівій кнопці, зміню-

ється з 0 (False) на 1 (True). При цьому двійкове значення шаблона змінюється

на 001 або 1 – у десяткову форматі.

Натискання правої кнопки миші змінює другий біт на 1, тобто встанов-

лює значення шаблона на 010 у двійковому форматі або 2 – в десятковому фор-

маті.

Одночасне натискання лівої та правої кнопок миші генерує десяткове

значення 3 (011). Для трикнопкової миші одночасне натискання всіх кнопок

генерує десяткове значення 7 (111).

Подія MouseMoveрозпізнає натискання двох чи більш кнопок одночас-

но. Також цю подію можна використовувати для визначення, чи було натис-

нено конкретну кнопку, незалежно від того, чи було водночас з нею натисне-

но іншу кнопку.

Подальший приклад перевіряє три стани кнопок (ліву натиснено, праву на-

тиснено або натиснено обидві) та виводить відповідне повідомлення.

Private Sub Form_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)

If Button= 1 Then Print "Ви натиснули ліву кнопку миші"

If Button= 2 Then Print "Ви натиснули праву кнопку миші "

If Button= 3 Then Print "Ви натиснули обидві кнопки"

End Sub

Події миші й клавіатури використовують параметр Shift, щоби визначити

стан клавіш <Shift>, <Ctrl> та <Alt>. Якщо натиснено клавішу <Shift>, значення

параметра Shiftстановить 1; якщо натиснено <Ctrl> – 2, а якщо натиснено

<Alt> – 4. Щоби визначити комбінацію клавіш, слід використовувати суму їхніх

значень. Наприклад, якщо натиснено водночас <Shift> та <Alt>, значення пара-

метра Shiftдорівнює 5 (101).

Три молодші біти параметра Shiftвідповідають клавішам <Shift>, <Ctrl> та

<Alt>.

Молодші біти

0 ….. 0 0 0 А С S – Клавіша <Shift>

Старші біти

не використовуються

Клавіша

<Alt>

Клавіша

<Ctrl>

Private Sub Form_MouseDown(button As Integer, shift As Integer, x As Single, y As Single)

shiftTest = shiftAnd 7

Select Case shiftTest

Case 1 ' vbShiftMask

Print "You're pressed the shift key."

Case 2 ' vbCtrlMask

Print "You're pressed the Ctrl key."

Case 3

Print "You're pressed both shift and Ctrl key."

Case 4 ' vbAltMask

Print "You're pressed the Alt key."

Case 5

Print "You're pressed both shift and Alt key."

Case 6

Print "You're pressed both Ctrl and Alt key."

Case 7

Print "You're pressing the all three key."

End Select

End Sub

 

Лекція 26. Атестація та сертифікація програмних застосувань.

 

Всім, хто коли-небудь працював з програмним забезпеченням виробництва Microsoft, IBM, Novell або інший компанії, доводилося вирішувати проблеми різного ступеня складності, викликані збоями в роботі ПЗ. Виробництво сучасного ПО відбувається на тлі високих вимог, що пред'являються до якості створюваних програм і значною складності виконуваних ними функцій. Для забезпечення надійності програмних продуктів припадає виявляти помилки на всіх етапах проектування, починаючи з етапу аналізу вимог і закінчуючи усуненням помилок на стадії супроводу. І якщо на етапі аналізу вимог прагнуть виключити логічні помилки тієї діяльності, під яку пишеться ПЗ, то на інших етапах від цілого ряду помилок прагнуть позбутися комплексом заходів, починаючи від декомпозицій і закінчуючи "Ідеальною" технологією програмування -- технологія, яка по деякому досить неформального опису об'єкта програмування автоматично генерує текст синтаксично і семантично коректної програми.

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

Способи забезпечення якості програмних продуктів.

Стандартизація.

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

МС ІСО серії 9000 визначають і регламентують створення, розвиток, застосування і сертифікацію систем якості будь-яких підприємств, незалежно від їх призначення. Вони містять і розвивають основне положення, що "постачальник повинен розробити і підтримувати в робочому стані документально оформлену систему якості як засіб, забезпечує відповідність продукції встановленим вимогам замовника ". У них зафіксовано право замовника на інспекцію системи якості підприємства постачальника до укладання контракту на поставку продукції.

В останні роки сформувалася комплексна система управління якістю продукції TQM (Totaly Quality Management), яка концептуально близька до попередньої більш загальній системі на основі стандартів ІСО серії 9000. Система орієнтована на задоволення вимог споживача, на постійне поліпшення процесів виробництва або проектування, на управління процесами з боку керівництва підприємства на основі фактичного стану проекту. Основні досягнення TQM полягають у поглиблення і диференціації вимог споживачів по реалізації процесів, їх взаємодії та забезпечення якості продукції. Системний підхід підтриманий поруч спеціалізованих інструментальних засобів, орієнтованих на управління виробництвом продукції. Тому ця система поки не знаходить застосування в галузі забезпечення якості життєвого циклу програмних засобів.

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

У Росії в галузі забезпечення життєвого циклу і якості складних комплексів програм існує і застосовується дуже невелика група застарілих стандартів серій ГОСТ 19.ХХХ і ГОСТ 34.ХХХ. Підприємства, що виконують державні замовлення при створенні ПС для внутрішнього застосування, змушені використовувати ці стандарти. Однак у експортних замовленнях зарубіжні клієнти вимагають відповідності технології проектування, виробництва та якості продукції сучасним міжнародним стандартам. Це протиріччя особливо загострилося у державні замовлення Міноборони Росії, результати яких одночасно використовуються і всередині, і поза країни.

За вимогами Міноборони Росії для застосування міжнародних стандартів у таких замовленнях їх необхідно перевести на російську мову, адаптувати, юридично затвердити і видати як ГОСТ Р, на що треба кілька років. Однак при поставках за кордон багато стандартів допускається практично застосовувати на мові оригіналу або у вигляді переказу до затвердження Держстандартом Росії, що цілком задовольняє зарубіжних замовників, але не допускається вітчизняними органами сертифікації для продукції всередині країни.

На цей момент ряд вітчизняних керівників переконався, що для забезпечення високої якості, надійності функціонування та безпеки застосування складних комплексів програм доцільно виділяти фахівців, відповідальних за дотримання технології створення і розвитку програм, за забезпечення та контроль якості, а також за надійність і безпека проекту ПС в цілому і його компонентів. Забезпечення якості повинно реалізовуватися фахівцями в ЖЦ програмних засобів на основі використання сучасної методології, технологічного інструментарію, стандартів і нормативних документів. Для систематичної координованої боротьби з погрозами якості необхідно проводити дослідження конкретних факторів, що впливають на якість функціонування та безпека застосування програм зі сторони, реально існуючих і потенційно можливих дефектів у створюваних комплексах програм.

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

Посвідчення досягнутого якості функціонування складних критичних ПС і процесів їхнього життєвого циклу має базуватися на сертифікатах, виданих атестованими проблемно-орієнтованими випробувальними лабораторіями. Сертифікація систем якості підприємств - розробників ПС по МС ІСО серії 9000 - дозволяє замовникам і покупцям вибирати з них найбільш надійних партнерів для реалізації інформаційних систем, здатних гарантувати високу якість поставляються і використовуваних комплексів програм. Застосування сертифікованих систем якості підприємств не тільки гарантує високу, стійке якість проектування та забезпечення життєвого циклу ПС, але дозволяє в багатьох випадках не проводити чи скорочувати сертифікацію кінцевого продукту. Базою такої сертифікації підприємств, які розробляють програмні засоби, може служити комплекс стандартів, нормативних та інструктивних документів, представлених на схемою. Короткий зміст стандартів ІСО викладено в, а повні тексти в.

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

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

Забезпечення надійності на етапі кодування та компіляції програмного забезпечення.

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

Весь час існування програмного засобу від зародження ідеї по його створенню, до завершення його експлуатації, зазвичай визначають як життєвий цикл. Укрупнено можна виділити п'ять найбільш важливих етапів життєвого циклу програмного засобу (ЖЦ ПС): специфікацію (10%), проектування (10%), кодування (10%), налагодження (20%) та супровід (50%). У дужках записані відносні витрати ресурсів на створення ПС.

За витратами часу, людських і машинних ресурсів все це так само не однакові. Найбільш "Дорогими", в цьому сенсі, є етапи, пов'язані з пошуком помилок в програмах. Витрати ресурсів на них можуть бути рівними, або навіть перевершувати сукупні витрати ресурсів на інших етапах. У стандарті DOD-STD-2167-A близько 30% вимог, документів і відповідних їм процесів безпосередньо пов'язані з налагодженням, тестуванням і випробуваннями програм. Даний стандарт є обов'язковим при виконанні замовлень Міністерства оборони США.

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

Ретроспектива розвитку методів і засобів автоматизації програмування в цьому відношенні говорить сама за себе. У модульному програмуванні акцент робиться на розбиття програми на модулі таким чином, щоб дані (оброблювані модулем) були заховані в ньому. Ця доктрина, відома як "принцип обмеження доступу до даних", значною ступеня підвищила модифікованості і ефективність породжуваного коду.

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

У 80-х роках дослідження причин невдач при реалізації великих програмних проектів показало, що число помилок у специфікаціях на програми значно перевищує їх кількість у програмних кодах. Так близько 56% помилок допускаються на етапі формулювання вимог до програмі при цьому витрачається в середньому 82% всіх зусиль, витрачених колективом на усунення помилок проекту. У той час як на етапі кодування програм допускається відповідно до 7% помилок і витрачається 1% зусиль на їх ліквідацію. У цей час формулюється теза про те, що метою програмування є не породження програми як такої, а створення технологічних умов, коли розробляється програмне забезпечення легко адаптується до нових обставин і нового розуміння розв'язуваної задачі. Р. Хеммінга так формулює цю тезу: "Здорова обчислювальна практика вимагає постійного дослідження вивчається завдання не тільки перед організацією обчислень, але також в процесі його розвитку і особливо на тій стадії, коли отримані числа переводяться назад і тлумачаться на мові первісної завдання ".

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

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

Застосування CASE-інструментів дозволяє в значній мірі знизити трудомісткість створення ПС, а в окремих випадках замінити програмування автоматичним синтезом програм.

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

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

Одним з основних факторів підвищення ефективності та на?? НАДІЙНОСТІ програмування можна вважати надання образності формам специфікації даних та опису алгоритму. У цьому сенсі головний недолік існуючих технологій програмування полягає в переважно текстових формах представлення основних компонент програми, що робить програму невиразною і надзвичайно ускладнює її сприйняття людиною.

В даний час принципово змінилася роль інформаційних технологій в суспільстві. З одного боку, програмні продукти являють собою досить дорогий товар. З іншого боку, посилилися вимоги до якості ПС, оскільки останні широко використовуються в таких сферах діяльності людини, які традиційно відносять до групи ризику. Це аерокосмічні технології, енергетика, зв'язок, бізнес і т.д.

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

Висока якість ПС досягається або методами безпомилкового програмування ( "пасивними" методами), або шляхом виявлення та усунення помилок ( "активними" методами).

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

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

- модульна і строгу ієрархію в структурному побудові програм;

- уніфікацію правил проектування, структурної побудови та взаємодії компонент ПС;

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

- поетапний контроль повноти і якості вирішення функціональних завдань.

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

Багато організацій, що займаються створенням програмного забезпечення, до 50% коштів, виділених на розробку програм, витрачають на тестування, що становить мільярди доларів по всьому світу в цілому. І все ж, незважаючи на величезні капіталовкладення, знань про суть тестування явно не вистачає і більшість програмних продуктів неприйнятно ненадійно навіть після «грунтовного тестування».

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

«Тестування - процес, підтверджує правильність програми і демонструє, що помилок в програмі немає. "Основний недолік такого визначення полягає в тому, що воно абсолютно неправильно; фактично це майже визначення антоніма слова «Тестування». Людина з деяким досвідом програмування вже, ймовірно, розуміє, що неможливо продемонструвати відсутність помилок в програмі. Тому визначення описує нездійсненне завдання, а так як тестування найчастіше все ж виконується з успіхом, принаймні з деяким успіхом, то таке визначення логічно некоректно. Правильне визначення тестування таке: Тестування - процес виконання програми з наміром знайти помилки.

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

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

Якщо ваша мета - показати відсутність помилок, ви. їх знайдете не дуже багато. Якщо ж ваша мета - показати наявність помилок, ви знайдете значну їх частину.

Надійність неможливо внести в програму в результаті тестування, вона визначається правильністю етапів проектування. Найкраще рішення проблеми надійності - з самого початку не допускати помилок в програмі. Однак імовірність того, що вдасться бездоганно спроектувати велику програму, нескінченно мала. Роль тестування складається саме в тому, щоб визначити місцезнаходження нечисленних помилок, що залишилися в добре спроектованої програмі. Спроби за допомогою тестування досягти надійності погано спроектованої програми абсолютно безплідні.

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

Ще одна причина, через яку важко говорити про тестування - це той факт, що про нього відомо дуже деяке. Якщо сьогодні ми маємо в своєму розпорядженні 5% тих знанні про проектування та власне програмуванні (кодуванні), які будуть у нас до 2000 р., то про тестуванні нам відомо менше 1%.

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

Тестування (testing), як ми вже з'ясували,-процес виконання програми (або частини програми) з наміром (або метою) знайти помилки.

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

Контроль (verification) - спроба знайти помилки, виконуючи програму в тестовій, або моделюється, середовищі.

Випробування (validation) - спроба знайти помилки, виконуючи програму в заданій реальному середовищі.

Атестація (certification) - авторитетне підтвердження правильності програми, аналогічне атестації електротехнічного обладнання Underwriters Laboratories. При тестуванні з метою атестації виконується порівняння з деяким заздалегідь певним стандартом.

Налагодження (debugging) не є різновидом тестування. Хоча слова «Налагодження» і «тестування» часто використовуються як синоніми, під ними маються на увазі різні види діяльності. Тестування - діяльність, спрямована на виявлення помилок; налагодження спрямована на встановлення точної природи відомої помилки, а потім - на виправлення цієї помилки. Ці два види діяльності пов'язані - результати тестування є вихідними даними для налагодження.

Тестування модуля, або автономне тестування (module testing, unit testing) - контроль окремого програмного модуля, зазвичай у ізольованому середовищі (тобто ізольовано від усіх інших модулів). Тестування модуля іноді включає також математичне доказ.

Тестування сполученні (integration testing) - контроль сполученні між частинами системи (модулями, компонентами, підсистемами).

Тестування зовнішніх функцій (external function testing) - контроль зовнішнього поводження системи, визначеного зовнішніми специфікаціями.

Комплексне тестування (system testing) - контроль та/або випробування системи по відношенню до початкових цілей. Комплексне тестування є процесом контролю, якщо воно виконується в моделюється середовищі, і процесом випробування, якщо виконується в середовищі реальної, життєвої.

Тестування прийнятності (acceptance testing) - перевірка відповідності вимогам програми користувача.

Тестування налаштування (installation testing) - перевірка відповідності кожного конкретного варіанту установки системи з метою виявити будь-які помилки, що виникли в процесі налаштування

Бета - тестування програмного забезпечення.

Інший спосіб перевірки -- бета-тестування. У цьому випадку розробники програмного забезпечення дозволяють користувачам спробувати попередні версії продуктів. Однак більшість розробників, з стверджують, що зовнішні бета-тестери не виявляють такої великої кількості помилок.

Висновки.

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

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

Тільки скоординоване, комплексне застосування в проектах ПС з початку проектування сучасних методів і стандартів дозволяє досягати високої якості, необхідного для використання ПС в розподілених критичних і складних системах обробки інформації. Необхідно переконати керівників проектів, замовників і розробників в тому, що ретельно регламентований і досить повне системне проектування ПС і БД на основі сучасних методів і міжнародних стандартів вигідно з позиції скорочення помилок і підвищення якості складних комплексів програм.