|
|
Критерії коректної роботи програмиСтр 1 из 2Следующая ⇒ Проблеми надійності ПЗ. Пз розробляється понад 50 років і за цей час змінилась складність пз та їх джерела несправностей. На даний час актуальність розробки якісного підтримується економічним чинником. Фактори які впливають: 1) розвиток обчислюваної інфоструктури; 2)хаотичний період розвитку пз;3)організація та управління процесом виробництва є окремою гілкою;4) з 90х років спроба перетворити розробку пз в інженерну дисципліну;5)створення сучасних прог. Систем має враховувати технології проектування UML, RUP
Тест та тестування Тест це контрольна задача для перевірки коректності функціонування системи та ПЗ. Тестування це процес керованого експериментування продуктів за допомогою тестів з метою виявлення помилок. Вдалим тестом вважається тест при якому виконання програми закінчилося з помилкою. Тест відбувається на протязі всього ЖЦ. Виконує дві основні задачі: демонстрація якості функціонування пз; знаходження та усунення помилок пз.
Критерії коректної роботи програми Визначають 5 критеріїв:1)Отримавши коректні дані програма надає правильний результат.2)Отримавши некоректні дані програма їх відхиляє.3)Програма не зависає і не вилітає приймаючи коректні і некоректні дані.4)Програма функціонує нормально стільки часу скільки потрібно.5)Програма працює без збоїв і виконує необхідні функції в повному обсязі.
Види помилок Помилка це хибне з-ння величини на виході системи і викликана несправністю або збоями які в свою чергу можуть викликати відмову. Види помилок: 1)Помилка; 2)дефект, несправність(невелика-баг, велика – дефект); 3)збій; 4)відмова;
Особливості тестування Тестування – процес аналізу пз з метою виявлення відмінностей між стореним станом пз та станом зазначеним при експеременталній перевірці відповідної функції вимог. Якість – ступінь відповідності системи заданим, очікуванням користувача. Метрика – кількісна міра ступеня наявності атрибута системи(надійність, готовність.) Безпека – відповідає за відсутність катастрофічних наслідків системи. Конфіденційність – відповідає за несанкціонований доступ до інформації. Цілісність - відповідає за відсутність появ в системі невідповідної інф. Ремонтна придатність – здатність системи до ремонту та розвитку. Зручність роботи – за зручність, рівень зусиль навчання підготовки, вхід та обробка вихідних даних. Перевірка на вагітність – дозволяє визначити на скільки точно з позиції користувача представляє задану суть. Варифікація – процес який дозволяє визначити реальний опис системи.
Класифікація методів тестування Метод забезпечення якості – досягнення показників якості при застосуванні відповідних технік. Метод контролю – дозволяє переконатися що певні х-ки якості пз досягнуті. Групи методів: Метод та техніка пов’язані з аналізом властивості пз під час його роботи. Метод та техніка визначення показників якості на основі симуляції роботи пз за допомогою модулів. Методи та техніка які націлені на виявлення порушень формалізованих правил початкового коду пз, проектних модулей та документації. Методи та техніки звичайного або формалізованого аналізу проектних документації і початкового коду для виявлення їх властивостей.
Види та рівні тестування Існують такі рівні тестування: 1)Поблочне тестування-контроль окремого програмного модуля. 2)Інтеграційне(перевірка взаємодій)-контроль взаємодії між частинами системи. 3)Системне-контроль/випробування всього пз як повної системи. Види тестуванні: Альфа - вик. готового продукту штатними програмістами. Бета-тест. за допомого майбутніх користувачів з метою виявлення максимальної кількості помилок. Тест за вимогами-тест. кожного припущення з певного документу. Регресійне тест – спільна назва для всх видів тестування пз мета якого є виявлення помилок у вже протестованих ділянках початкового коду. Тест чорна скринька – тестування має доступ до пз тільки через ті самі інтерфейси що і користувач. Тест біла скринька - розробник тесту має доступ до початкового коду.
Техніка тестування Ручне тест-тестування людьми з наперед визначеним для кожного випробування тест даними. Автоматизоване тест- тест спеціальними інструментами або спеціальними процесами і можуть повторюватися. Регресивне тест. Дослідницьке тест-тест спрямований на швидку перевірку базової функціональності. Димове тест-тест що вик за відсутністю специфікацій. Стрес тест-тести призначені для перевірки стійкості до надмірного навантаження. Мавп’яче тест- тест що не мають під собою певної системи «швидка атака» програми тестером. Тест навантаження-тест вик при різних рівнях навантаження. Тест продуктивності – для перевірки поточної продуктивності з розрахованою. Тест інсталяції-тест встановлення програми на різних платформах. Тест довгими використаннями-тест вик довготривало з метою виявлення помилок які неможливо виявити при короткому використанні.
Умови некоректної роботи пз. 1)пз не робить те що воно повинно робити відповідно до специфікації.2)пз робить те що воно повинно робити відповідно для специфікації.3)програма робить те що не нагадує специфікацію.4)пз не робить чогось що в його специфікації але повинно.5)пз важко зрозуміти важко використовувати воно повільне на думку тестерів або буде сприйняте користувачами як явно неправильним.
Причини виникнення помилок Більшість помилок виникають не через помилки програмістів а через специфікації. Якщо цей етап пропущено або здійснено некоректно то помилки надалі будуть виникати. Неправильно розроблена архітектура пз може мати величезні наслідки. Помилки в коді виникають через складність пз, щільність графіка, бідність документації. При не правильном тестуванні пз має всі типи помилок.
Відомості про аксіоми. З моменту появи першого багу, тестування пз пройшло великий шлях до виявлення цього багу. Визначають: Перша аксіома-неможливо повністю протестувати програму; Друга аксіома-тестування це процес що містить ризики; Третя аксіома-тестування не може показати що помилки немає; Четверта аксіома-чим більше помилок знаходится тестером тим більше їх існує; П’ята аксіома-парадокс пестицидів; Шоста аксіома-не всі знайдені помилки будуть виправлені; Сьома-іноді складно сказати чи є помилка-помилкою;Восьма аксіома- специфікація розробки ніколи незавершуєтся.
Характеристика аксіом Існують такі аксіоми і їх характеристика: * Неможливо повністю протестувати програму (Початківець у сфері тестування може вважати, що можна обробити ПЗ, повністю протестувати його і знайшовши всі помилки підсумувати що ПЗ ідеальна. Нажаль це не можливо навіть для найпростіших ПЗ); * Тестування – процес, що містить ризик (Якщо приймається рішення не тестувати всі можливі сценарії, то вибирається деякий ризик, оскільки перебрати всі варіанти неможливо і треба чимось нехтувати, існує імовірність того, що програміст зробив помилку, яка впливає на цю ситуацію, ця помилка може коштувати дорого, оскільки вона буде знайдена коли ПЗ вийде в експлуатацію, а тому на вилучення і заміну даної версії мають бути витрачені деякі зусилля); * Тестування не може довести, що помилок немає (Дана аксіома була запропонована в 1972р. Дейкстрой); *Чим більше помилок знаходить тестер, чим більше їх існує (Причина такої тенденції: -Бувають невдалі дні, -Програміст досить часто робить ті ж самі помилки, -Деякі помилки є вершинами айсберга); * Парадокс пестицидів (Чим більше тестує ПЗ, тим більше воно стає невразливим до тестування, в результаті тестери повинні писати нові тести); * Не всі знайдені помилки будуть виправлені (Причини: -Недостатньо часу, -Занадто ризиковане виправлення, -Це просто не варто виправляти, -Це насправді не полика, а властивість); * Іноді складно сказати, чи є помилка – помилкою (Іноді помилка являється не помилкою, а властивістю програми); * Спеціалізація розробки ніколи не завершується (Тестер ПЗ повинен засвоїти, що специфікація буде змінюватися. Тестери ПЗ є не самими популярними членами розробки програм)
Процес тестування ПЗ Тестування ПЗ один з дорогих етапів життєвого циклу ПЗ. На нього відводиться до 60% загальних витрат. У галузі тестування відчувається недостача CASE-засобів і більшість зусиль витрачається на ручне тестування. Тестування може здійснюватися за наступними методиками: *Функціональне тестування (Чорна скринька – вихідний код програми не доступний. Мета: перевірка відповідності поведінки програми згідно з її зовнішніми специфікаціями); *Структурне тестування (Біла скринька – текст програми відкритий для аналізу перевірки внутрішньої логіки ПЗ).
Критерії покриття умов Існують наступні критерії покриття умов та умов-рішень. * Простий критерій покриття умов – кожна з атомарних умов повинна бути протестована на свої правильні та помилкові значення хоча б один раз. Даний критерій забезпечує тільки перевірку того факту чи можливо прийняти атомарними умовами правильних та помилкових умов. * Критерій покриття умов-рішень – (те ж саме що і попереднє +кожна гілка алгоритму повинна бути пройдена хоча б один раз. * Модифікований критерій покриття умов/рішень – кожна атомарна умова, що має вплив на істинність загального виразу-умови, має бути протестована, при цьому тести повинні бути незалежні від інших умов. * Комбінаторний критерій - всі комбінації істинних значень кожного з атомарних предикатів, що входять в умову, мають бути протестовані. Це найбільш ресурсномісткий критерій покриття умов.
Планування інтеграційного тестування Інтеграція тестування є формальний процес тестування повинен бути ретельно сплановані та погоджені з часу завершення модульного тестування. При розробці плану тестування, ви повинні враховувати наступні фактори: * в тому, яка збирання системи підходу до складання та випробувань; *порядок кожного модуля збірки і підключення до процесу тестування; *розвитку код модуля і графік тестування узгоджується з збірки і випробування послідовності. *якщо під час тесту потрібне спеціальне устаткування;
Види системного тестування. Види системного тестування: *функціональне тестування; *тестування продуктивності; *навантажувальне тестування; *стресове тестування; *тестування конфігурації; *тестування безпеки; *тестування надійності і відновлення після збоїв; *тестування зручності використання. Початковою інформацією для проведення перерахованих видів тестування є 2 класи вимог: 1.функціональні – явно описують, що система повинна робити і які виконувати перетворення вхідних даних в вихідні; 2.не функціональні – визначають властивості системи безпосередньо не пов’язані з її функціональністю.
Типи програмних індексів. Міжнародний стандарт ANSI/IEEE-729-83 розділяє інциденти, які виникають під час розробки програм на такі типи: * Джерела дефектів (Банк досвіду, Банк інформації, Переписування, Незрілість проекту, Недогляд); *Вплив на програму (Помилка, Дефект, Відмова, Збій); * Вплив з погляду користувача (Низька якість ПЗ, Незадоволення користувача).
Драйвера та заглушки Тестове оточення для програмного коду на структурних мовах програмування складається з двох компонентів - драйвера, який забезпечує запуск і виконання модуля, що тестується, і заглушок, які моделюють функції, що викликаються з даного модуля. Розробка тестового драйвера являє собою окрему задачу тестування, сам драйвер повинен бути протестований, щоб виключити невірне тестування. Драйвер і заглушки можуть мати різні рівні складності, необхідний рівень складності вибирається залежно від складності тестованого модуля та рівня тестування. Так, драйвер може виконувати наступні функції: 1) Виклик модуля, що тестується. 2) Передача в модуль, що тестується вхідних значень і прийом результатів. 3) Ввисновок вихідних значень. 4) Протоколювання процесу тестування і ключових точок програми. Заглушки можуть виконувати такі функції: 1) Не проводити ніяких дій (такі заглушки потрібні для коректної збірки тестованого модуля). 2) Виводити повідомлення про те, що заглушка була викликана. 3) Виводити повідомлення зі значеннями параметрів, переданих у функцію. 4) Повертати значення, заздалегідь заданий у вхідних параметрах тесту. 5) Виводити значення, заздалегідь заданий у вхідних параметрах тесту. 6) Приймати від тестованого ПО значення і передавати їх в драйвер
Тестові класи. Тестове оточення для об’єктно-орієнтованого ПЗ виконує ті самі функції, що для структурних програм. Проте воно має деякі особливості, пов’язані із застосуванням успадкування та інкапсуляції, воно теж має бути протестоване. Метою тестування тестового оточення є доказ того, що тестове оточення жодним чином не спотворює виконання тестового модуля і адекватно моделює поведінку сиситеми.
Генератори сигналів.
Типи тестових випадків.
Проблеми надійності ПЗ. Пз розробляється понад 50 років і за цей час змінилась складність пз та їх джерела несправностей. На даний час актуальність розробки якісного підтримується економічним чинником. Фактори які впливають: 1) розвиток обчислюваної інфоструктури; 2)хаотичний період розвитку пз;3)організація та управління процесом виробництва є окремою гілкою;4) з 90х років спроба перетворити розробку пз в інженерну дисципліну;5)створення сучасних прог. Систем має враховувати технології проектування UML, RUP
Тест та тестування Тест це контрольна задача для перевірки коректності функціонування системи та ПЗ. Тестування це процес керованого експериментування продуктів за допомогою тестів з метою виявлення помилок. Вдалим тестом вважається тест при якому виконання програми закінчилося з помилкою. Тест відбувається на протязі всього ЖЦ. Виконує дві основні задачі: демонстрація якості функціонування пз; знаходження та усунення помилок пз.
Критерії коректної роботи програми Визначають 5 критеріїв:1)Отримавши коректні дані програма надає правильний результат.2)Отримавши некоректні дані програма їх відхиляє.3)Програма не зависає і не вилітає приймаючи коректні і некоректні дані.4)Програма функціонує нормально стільки часу скільки потрібно.5)Програма працює без збоїв і виконує необхідні функції в повному обсязі.
Види помилок Помилка це хибне з-ння величини на виході системи і викликана несправністю або збоями які в свою чергу можуть викликати відмову. Види помилок: 1)Помилка; 2)дефект, несправність(невелика-баг, велика – дефект); 3)збій; 4)відмова;
Особливості тестування Тестування – процес аналізу пз з метою виявлення відмінностей між стореним станом пз та станом зазначеним при експеременталній перевірці відповідної функції вимог. Якість – ступінь відповідності системи заданим, очікуванням користувача. Метрика – кількісна міра ступеня наявності атрибута системи(надійність, готовність.) Безпека – відповідає за відсутність катастрофічних наслідків системи. Конфіденційність – відповідає за несанкціонований доступ до інформації. Цілісність - відповідає за відсутність появ в системі невідповідної інф. Ремонтна придатність – здатність системи до ремонту та розвитку. Зручність роботи – за зручність, рівень зусиль навчання підготовки, вхід та обробка вихідних даних. Перевірка на вагітність – дозволяє визначити на скільки точно з позиції користувача представляє задану суть. Варифікація – процес який дозволяє визначити реальний опис системи.
  Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычислить, когда этот...  ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...  Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...  Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор... Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
|