Етап тестування.
Лабораторна робота № 4
Міністерство
Освіти
і
Науки України
Національний
університет “Львівська
політехніка”
Кафедра
автоматизованих систем управління
Методичні вказівки
до лабораторної роботи № 4
“Етап тестування”
з дисципліни
“Технологія програмування та створення програмних продуктів”
для студентів базового напрямку підготовки по спеціальності
“Комп’ютерні науки” (шифр 0804)
Львів-2008
Методичні вказівки до лабораторної роботи № 4 “Етап тестування” з дисципліни “Технологія програмування та створення програмних продуктів” для студентів спеціальності - шифр 0804 “Комп’ютерні науки”/ Укл. доц. Ковівчак Я.В.,
Львів: Національний університет “Львівська політехніка”, 2008.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2008 р.
Завідувач кафедрою АСУ ______________ Рашкевич Ю. М.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2008 р.
Лабораторна робота № 4
Етап тестування
Мета: Ознайомлення з основними задачами, які необхідно розв’язати під час виконання етапу тестування
Завдання: Навчитись реалізовувати етап тестування програмного продукту комп’ютерних систем
Теоретична частина
Основні теоретичні відомості
Мета тестування полягає в тому, щоб виявити і виправити помилки. Цей процес допомагає розпізнавати алгоритмічні помилки і помилкове виконання системою своїх функцій. Під алгоритмічною помилкою ми розуміємо конструкцію, яка розроблена неправильно. Одна помилка може викликати безліч неправильних виконань програми. Також помилки можуть бути наслідком інших помилок, це потрібно враховувати при їх аналізі.
Тестування це:
Сертифікація - наприклад, перевірка відповідності системи вимогам клієнта;
Перевірка - наприклад, перевірка відповідності системи вимогам з етапу формування вимог.
Тести призначені для виявлення, і подальшого усунення, максимальної кількості помилок, розрахунку статистики помилок а також - оцінки надійності всієї системи.
Розрізняються тести:
Динамічні - які порівнюють результати роботи програми з правильними результатами.
Статичні - засновані на аналізі коду.
Існують наступні фази тестування:
Тестування модулів виконується після їх реалізації і зборки.
Тестування системи виконується після її інтеграції. Воно охоплює тестування системи і всіх її модулів.
Приймальне випробування. Системи, які розроблені для клієнта доставляються йому для перевірки. Такі тести називають альфа-тестами. Системи, які розроблені для ринку, доставляються деяким представницьким користувачам (бета тестувальникам) і перевіряється ними. Такі тести називають бета-тестами.
Основні чинники успіху етапу тестування: визначення спеціальних вимог надійності частин системи і мотивація відповідальних за тестування людей. Оскільки тестуючий персонал найчастіше представляє нижчий рівень в ієрархії службовців, рекомендується призначити для тестування людей, які займаються програмуванням і проектуванням даної системи.
Головні результати етапу тестування:
Покращені код, проект, модель і, можливо, специфікація вимог.
Звіт про тести.
Оцінка надійності системи.
В процесі тестування розрізняють два поняття:
Перевірка – тестування на предмет відповідності ПЗ вимогам, описаним на етапі формулювання вимог.
Затвердження – оцінка того, чи є система або її компоненти відповідної якості. Затвердження проводиться під час або після розробки.
рис 1.1. Етап тестування.
Перевірка
Методи перевірки:
Перегляди, інспекція, тестування, ревізія, порівняння і інші методи перевірки відповідності компонентів, процесів, документів вимогам.
Перевірка повинна оцінювати, чи відповідає продукт на даній стадії розробки вимогам, встановленим на початку етапу.
В ході перевірки виконуються наступні дії:
Технічні перегляди і інспекції ПЗ;
Порівняння вимог користувача і ПЗ;
Перевірка відповідності компонентів ПЗ вимогам;
Тестування модулів програми;
Тестування цілісності;
Ревізія.
Фази проекту мають своє відображення на етапі тестування. Рис 1.2. показує їх зв'язки і відносини.
Як показано нижче, кожен з обговорюваних на попередніх лабораторних роботах етапів відповідає своїм типам тестування.
рис 1.2. Модель V-тестування.
Модулі тестування
Для тестування достатньо великих проектів, їх розбивають на певну кількість окремих модулів так, щоб вони якомога менше залежали один від одного. Модуль – набір логічно зв’язаних функціональностей. Кожен модуль тестується окремо - це зроблено для полегшення локалізації джерела помилки. Після тестування всіх модулів, їх збирають в єдину систему або підсистему і тестують разом – це допомагає виявити помилки залежностей і взаємодій між ними. Цей процес називають тестуванням цілісності. Також він допомагає визначити відповідність системи вимогам.
Тестування прийнятності системи - останній етап, який проводиться перед доставкою системи користувачеві. Він полягає в тому, що система тестується даними користувача, а не розробника.
Перегляди
Перегляд - процес або зустріч, на якій продукт оцінюється персоналом, супервізорами, користувачами, клієнтами і рештою осіб, що мають до нього відношення. Їх думки і рішення визначать майбутнє проекту.
Перегляди можуть бути формальними і неформальними. Формальні це наприклад: технічний перегляд, наскрізний контроль, аудит.
Технічний перегляд
Технічний перегляд - перевірка на відповідність елементів ПЗ плану розробки (деталі можна знайти в ANSI/ IEEE Std 1028 -1988 "Стандарт для переглядів програмного забезпечення".
Наскрізний контроль
Наскрізний контроль - попереднє оцінювання документів, моделей і всього проекту. Мета наскрізного контролю - визначити дефекти і запропонувати варіанти їх вирішення. Вторинне завдання - вирішення проблем із стилем (наприклад, з формою коду, документація, інтерфейсами).
Аудит
Аудит - це вид наскрізного контролю, який використовується для перевірки відповідності ПЗ вимогам, специфікаціям, рекомендаціям, стандартам, процедурам, умовам контрактів і ліцензіям. Об'єктивність аудиту вимагає незалежних експертів-професіоналів. Аудити повинні проводитися аудитною групою або персонами з відповідними ліцензіями. Правила визначаються стандартом ANSMEEE Std 1028-1988 IEEE - стандарт для переглядів програмного забезпечення.
Команда по оцінці ПЗ
Оцінка ПЗ - дуже важливе завдання, яке повинне вирішуватися професіоналами.
Для вирішення цієї задачі потрібно сформувати команду професіоналів, яка підготує і проведе тести.
У тестуванні приймають участь наступні персони: супервізор, секретар, члени команди, серед яких є представники користувачів, супервізор проекту розробки ПЗ, розробники ПЗ, персонал гарантії якості проекту, незалежний персонал перевірки і незалежні експерти.
Супервізори команд мають наступні завдання: номінування членів команди, організація зустрічей, процесів оцінювання, організація роботи, редагування кінцевих документів і, можливо, інші завдання.
Аудит проекту розробки ПЗ
Мета аудиту - отримати цілісну інформацію про проекту.
Слід оцінювати ресурси, компетенцію і методи, які важливі для досягнення проміжних і кінцевого результатів, оскільки ця інформація важлива для ухвалення стратегічних рішень.
Суб'єкти і перспективи аудиту
Суб'єктами аудиту можуть бути процеси і/або продукти проекту.
Мета аудиту процесу - перевірити, чи правильно виконується робота, її відповідність принципам і стандартам.
Мета аудиту продукту (проміжного або кінцевого) - перевірити, чи відповідає він вимогам і очікуванням.
Команда аудиту може застосовувати різні способи перевірки. Технічні аспекти, наприклад, можуть перевірятися для оцінки технічних рішень і того, як вони застосовані, аспекти менеджменту можуть пройти аудит для того, щоб перевірити, чи достатньо добре виконується менеджмент.
Інспекціювання
Інспекціювання - формальна техніка оцінки персоною, або групою персон, проекту на наявність помилок у коді і вимогах, його відповідність стандартам а також пошуку інших проблем в процесі розробки ПЗ [IEEE Std. 729-1983].
Інспекціювання повинне бути добре сплановане і організоване. Всі помилки і проблеми повинні бути відмічені. Супервізори не повинні брати участь в інспекції - її результати надаються супервізорам у формі звітів, без особистої інформації про інспекторів.
Нарада після інспекції - справжня мозкова буря тих, хто приймали участь в ній.
Мета наради - зробити висновки про те, які проблеми повинні бути усунені і які дії виконані для уникнення проблем в майбутньому.
рис 1.3. Процес інспекції.
На рис. 1.3. представлені наступні етапи інспекції:
Ініціація – визначення членів інспекції і її голови.
Планування - голова викликає членів, формує план і визначає ретельність контролю.
Ініціююча нарада - формулювання завдань, очікувань, створення документів.
Індивідуальний контроль - члени інспекції перевіряють документи, використовуючи критерії контролю (для того, щоб знайти максимальну кількість помилок).
Контрольна нарада (мозкова буря) - збір думок кожного інспектора, які можуть допомогти виявити невідповідність (потенціальну помилку), визначити шляхи удосконалення процесу, допомогти виявити можливі джерела інших невідповідностей.
Удосконалення продукту: редактор (зазвичай - автор) висуває рішення про усунення невідповідностей. Невідповідності між результатом і вимогами, сприймають як помилки і усуваються, або документ з вимогами редагується для уникнення неправильної інтерпретації.
Доопрацювання: голова перевіряє, чи всі невідповідності виправлені; він перевіряє завершеність а не правильність.
Рішення про завершеність: голова інспекції дає оцінку того, чи готовий продукт (чи знаходиться кількість помилок у допустимих межах).
Розробка документів.
Дослідження показують, що інспекції - найефективніший спосіб. Сам метод і його умови застосовуються рідко і лише до "елітних" систем.
Продуктивність в результаті інспекції збільшується на 30% - 100%, час на розробку проекту зменшується на 10% - 30%, вартість тестування зменшується в 5 - 10 разів (менше помилок, менше регресивних помилок), підтримка - в 10 разів. Було зазначено, що інспекції мотивують команди: робота виконується вчасно, а її якість збільшується. Продукт оцінюється з більшою компетентністю. Витрати стають меншими, оскільки не потрібно маскувати низьку якість продукту.
Але витрати і наслідки інспекції тяжко оцінити. Ефект може бути незначним, якщо інспектори будуть недосвідчені. Також інспекції не є частими, оскільки вони вимагають компетентних персон.
Види тестів
До тестування відносяться два поняття: помилка і невдача.
Помилка - це неправильна побудова програми, яка може призвести до помилок в ході її виконання.
Невдача - неправильне функціонування системи під час її роботи.
Помилка може призвести до багатьох невдач. Одна і та ж невдача може відбуватися з різних причин.
Отже: тестування - це процес визначення і усунення помилок, заснований на неправильних виконаннях і інших тестах.
Тести ПЗ можуть класифікуватися з точки зору головної мети або техніки тестування.
Класифікація з точки зору техніки тестування.
Існують наступні тести:
статичні тести, засновані тільки на аналізі коду. Вони здійснюються програмістами.
динамічні тести, які складаються з виконання різних частин коду і порівняння їх результатів з правильними.
Процес тестування
Різні частини ПЗ тестуються на різних етапах розробки. Типові елементи показаний в таблиці 1.1.
Тестований елемент |
Опис тестування |
Продуктивність |
Тестується продуктивність програми і її функцій. |
Інтерфейс |
Тестуються інтерфейси на відповідність вимогам. |
Властивості організації |
Тестується: логіка, організація, зручність використання, складність вхідних інструкцій, вивід на екран, якість повідомлень, якість повідомлень про помилки, рівень якості допоміжних файлів. |
Використання ресурсів |
Тестуються використання одиниць пам'яті: оперативна пам'ять, місце яке програма використовує на жорсткому диску. |
Безпека |
Тестується гнучкість, конфіденційність, цілісності даних, доступності. Тестуються паролі, доступ до файлів, захищеність від атак ззовні. |
Переносимість |
Тестується можливість роботи у різних середовищах, з різними бібліотеками, графічними режимами, на різних версіях Windows та Unix. |
Надійність |
Вимірюється середній час між помилками. |
Підтримування |
Вимірюється середній час відновлення програми після помилки, тобто проміжок часу, починаючи з виникнення помилки і закінчуючи відновленням робочого стану програми. |
Безпечність ПЗ |
Оптимізація наслідків збою, наприклад, втрати електроенергії. |
Можливість модифікації |
Аналіз можливого розширення ПЗ. |
Навантаження на ПЗ |
Тестується робота програми в екстремальних умовах: з максимальною кількістю користувачів, великими файлами, скриптами, базами даних. Тривалість тестування не є важливим. Найважливіше - можливість програми працювати в екстремальних умовах. |
Масштабованість програми |
Відповідність вимогам (серед інших - вимогам часу) зі збільшенням навантаження. |
Повнота вимог |
Тестуються формулювання вимог |
Прийнятність програми |
Тестування ступеню задоволення кінцевого користувача |
Якість документації |
Тестування якості документації. |
Таблиця 1.1. Типові елементи ПЗ, які тестуються.
Динамічні тести
Статистичне тестування елементів
Статистичне тестування засноване на випадкових даних. Правильна робота програми перевіряється, порівнянням вихідних даних з очікуваними вихідними даними. Таке тестування проводиться циклічно , поки не буде досягнуто позитивного результату.
Такі тести проводяться відповідно до чітко визначеного плану:
генерування випадкових ввідних даних, які відповідають обраним правилам
визначення очікуваних результатів роботи системи.
запуск системи і порівняння її результатів з очікуваними.
Статистичні тести легко виконувати без участі людей. Якщо початкові обмеження вірні і визначена початкова продуктивність системи, тестування може виконуватися автономно.
Недолік - висновки про надійність, що ґрунтуються на цих результатах, можуть бути невірні. Причина часто полягає в неправильних обмеженнях даних - вони можуть не відповідати реальним.
Заходи надійності, засновані на статистиці помилок:
Вірогідність невдачі транзакції
Частота невдачі - кількість помилок за проміжок часу. Застосовується до систем без транзакцій
Середній час між виконаннями
Доступність - вірогідність того, що система у будь-який момент часу буде доступна користувачеві. Обчислюється відношенням часу, впродовж якого система була доступна, до часу тестування.
Статистичне тестування вимагає наявність даних, які відображають реальні результати. Але їх іноді не можливо отримати отже цей тип тестування не є універсальним.
Перевагою статистичного тестування полягає в можливості його автономної роботи, що дає провести багатократне тестування.
Тестування методом прозорої скриньки
Тестування методом прозорої скриньки використовуються при умові, що тестувальник має в наявності код програми і може переглядати логіку поведінки програми під час її виконання. Він вводить данні а потім переглядає (трасує) логіку виконання покроково, таким чином визначаючи джерело помилки. Це дозволяє програмістам пропускати цей етап і концентруватись тільки на розробці.
Вхідні дані для таких тестів визначаються свідомо, так, щоб привести програму в найбільш складний стан.
Зазвичай програмісти самі пишуть код для тестування програм – це називається автоматизоване тестування.
Дані і код такого тестування повинні бути приготовані заздалегідь і повинні бути спроектовані таким чином, щоб кожна програмна функція перевірялася хоч би один раз. Існує методика розробки ПЗ, яка передбачає написання автоматизованих тестів до початку розробки проекту. Це дозволяє оцінювати працездатність окремих модулів и класів системи до їх інтегрування з іншими компонентами. Така методика написання тестів до початку процесу написання коду програми, має назву test-driven development.
Тестування методом чорного ящика
Робота програми перевіряється по припущенню того, що тестувальнику невідомі ніякі внутрішні деталі, і особливості логіки. Тестувальник користується програмою так, ніби він є кінцевим користувачем продукту, але він використовує вхідні дані які на його думку можуть привести до помилки. Перевага такого тестування в тому, що людина яка тестує програму не мислить стереотипами логіки яка склалась у людей які цю програму розробили, отже тестувальник може використовувати нестандартні і не логічні дані, які можуть призводити до помилки.
Тестування надійності
Надійність є дуже важлива. Але як її вимірювати? Як порівняти два продукти з точки зору надійності?
Необхідно визначити міри надійності. Без цього вимагати надійності від проекту не має сенсу.
Нижче ми наводимо деякі приклади вимірювань надійності:
Міра 1
Мірою є вірогідність помилки при виконанні транзакції. Кожна помилка аварійно припиняє транзакцію. Формальна міра - частота таких помилок.
Міра 2
Міра - частота операцій з помилками за одиницю часу. Вона використовується в системах, де немає транзакцій. Наприклад, 0.1/год означає, що на годину кількість очікуваних помилок дорівнює 0.1, тобто 1 помилка за 10 годин.
Міра 3
Мірою вірогідністі, що в конкретний момент часу система доступна для виконання завдання. Вона обчислюється як відношення часу, коли система доступна, до часу, необхідного системі для відновлення від помилки (від появи до усунення помилки). Міра враховує помилкові операції і витрачений на них час.
Оцінка надійності
Рівень надійності (значення якоїсь міри) визначається вимогами клієнта. Але це у великій мірі відображається в якісній формі, що робить перевірку складною.
Оцінка важлива навіть якщо клієнт не зазначив її у вимогах. Наприклад, зусилля, необхідні для підтримки, можуть значно зменшитись, якщо надійність враховуватиметься при проектуванні системи.
Надійність дозволяє зменшити витрати на обслуговування: персонал, телефонні дзвінки, загальну вартість послуг.
Оцінка надійності дозволяє оцінити і покращити процес розробки з точки зору мінімізації витрат на виробництво, підтримку, успіху на ринку і репутації компанії.
Підвищення надійності ПЗ
Мета знаходження помилок полягає в їх виправленні. Якщо цей процес не додасть нових помилок, надійність підвищується. У разі статистичних тестів, покращення визначається по формулі:
Надійність = Надійність_початкова * e (-C * Кількість_тестів)
Міра надійності - частота помилок в операціях. Константа C залежить від системи. Для знаходження C, ґрунтуючись на надійності спостережень, можна використати метод найменших квадратів. Надійність також можна підвищити якщо вибирати тестові дані які не були протестовані раніше.
Типи тестів на знаходження помилок
Динамічні тести класифікують як:
Функціональні тести - (тестування методом чорного ящика) враховують тільки вимоги.
Структурні тести - (тестування методом прозорого ящика) враховують механізми реалізації.
Функціональні тести
Зазвичай вважається, що якщо функція працює при одних даних, то вона працюватиме при всіх, але це твердження зазвичай приводить до помилки.
Повне тестування системи неможливе, оскільки кількість можливих комбінацій вхідних даних дуже велика. Це справедливо навіть для маленьких систем, на тестування яких за таким методом пішли б роки. Тому дані групуються відповідно до логічної схожості між ними Наприклад:
Рахунок, менший 1000 грн. повинен бути схвалений супервізором.
Рахунок, більший 1000 грн. повинен бути схвалений президентом.
Така вимога розділяє дані на два класи. Однак тестування, одного значення для кожного класу недостатньо. Граничні умови теж слід перевірити.
Приклад демонструє, що тестування повинно проводитися, принаймні, п'ятьма значеннями: 0, 500, 1000, 1500 і максимальним. Якщо кількість таких значень дуже велика, ми застосовуємо комбінаторний вибух для тестових значень. Дані діляться на класи еквівалентності, які враховують елементарні умови. Наприклад, якщо ці умови доповнюються наступними:
Супервізор може схвалити місячний рахунок в 10000 грн. Кожен рахунок, що перевищує цю суму, повинен схвалюватися президентом. Наступні класи також можуть бути враховані в даних, що вводяться: рахунок до 1000 грн., що не перевищує 10000 грн.; рахунок до 1000 грн., що перевищує 10000 грн.; рахунок більше 1000 грн., що не перевищує 10000 грн.; рахунок більше 1000 грн., що перевищує 10000 грн.;
Врахування цих граничних випадків приводить до збільшення випадків тестування: (0,500,1000, 1500, max) x (<10000, 10000, >10000).
На практиці тестування всіх граничних значень (навіть обмежених типовими і крайніми) неможливе. Повинні бути обрані характерні випадки. Рекомендується враховувати наступне:
Вірогідність виконання функції важливіша за її якість.
Функції попередньої версії важливіші, ніж нові. Користувачі будуть незадоволені, якщо функція в новій версії перестане працювати.
Типові ситуації важливіші, ніж виняткові випадки, - помилка у перших буде більш значуща, ніж в останніх.
Структурні тести
Для структурних тестів дані вибираються на основі аналізу структури системи, і їх критерії є такі:
Критерій покриття всіх функцій. Відповідно до цього критерію, вибір вхідних даних, повинен дати виконатися функціям хоча б один раз. Для задоволення критерію розробникам не потрібна велика кількість тестів.
if x > 0 then begin end; y:=ln(x);
Критерій покриття всіх виключень умов. Вхідні дані, повинні вибиратися так, щоб кожна умова по разу виконалася і не виконалася. Граничні умови також слід перевірити. У даному прикладі ця вимога дозволяє знайти помилку у випадках
if x=0 or x<0.
Тестування програм з циклами
Критерій вибору даних ґрунтується на наступних припущеннях:
Дані повинні бути такими, щоб виконалося 0 циклів, мінімальна кількість циклів, максимальна і середня.
Програми-інструменти
Відлагоджувачі
Відлагоджувачі можуть бути корисні для внутрішнього і зовнішнього тестування. Методом тестування в якому вони використовуються це метод прозорого ящика.
Відлагоджувачі показують значення змінних і те як вони змінюються в процесі виконання програми. За їх допомогою можна ставити контрольні точка і переглядати реальні значення змінних.
Аналізатори швидкодії (профайлери)
Це програми, які дозволяють визначити, яка частина програми була задіяна в даний момент. Це дозволяє визначати місця коду, які є недостатньо оптимізованими і потребують покращення. Також профайлери дозволяють визначати об’єм необхідної оперативної пам’яті, місця на жорсткому диску і таке інше.
Найновіші профайлери порівнюють дані з декількох запусків (для різних вхідних даних) для полегшення знаходження поганих частин коду, показують контрольні графи, моніторингу виконання, надають інформацію про покриття, що дозволяє робити ще складніші тести.
Компаратор
Компаратори - інструменти програмування, які дозволяють порівнювати дві програми, файли і масиви даних для визначення схожостей і відмінностей. Компаратори чітко показують різницю між реальним і очікуваним результатом. Порівняння зображень наприклад, може бути корисне для тестування інтерфейсу, зокрема, графічного.
Ринок пропонує широку різноманітність компараторів, які можна використовувати на різних етапах розробки ПЗ.
Статичні тести
Статичний тест - аналіз коду без його виконання. Це, зазвичай, перевірка коректності або неформальні методи.
Перевірки коректності непрактичні для реальних програм і, більшою мірою, виведені вченими в комп'ютерній техніці. Їх застосування до сучасних великих програм не має сенсу, хоч Academia все ще наполягає на розробці цих методів.
Неформальні статичні тести складаються з трасування програми програмістом і знаходження помилок. Їх, зазвичай недооцінюють, хоча вони можуть бути дуже ефективними.
Типовими помилками, які виявляються статичними тестами, є:
не проініціалізовані змінні,
порівняння змінних з плаваючою крапкою,
адреси пам’яті , що перевищують межі,
помилки з вказівниками,
помилки в умовних командах,
нескінченні цикли,
помилки в межах (наприклад > замість >=),
неправильне використання круглих дужок,
неправильне використання даних.
Стратегія неформальних тестів
Неформальні статичні тести зазвичай проводяться програмістом, який написав модуль. Програміст аналізує код. Якщо все гаразд, його аналізує досвідчений програміст. Якщо той знайде помилки - програма повертається програмістові. Якщо модуль важливий - його перевіряє декілька досвідчених програмістів.
Підрахунок кількості помилок
Помилки в програмі не обов'язково роблять її ненадійною. Проте, оцінка помилок дуже важлива, оскільки вона визначає вартість підтримки. Компанії, що продають продукт одному або декільком клієнтам, використовують оцінювання.
Вартість підтримки обчислюється з кількості помилок і їх середньому коефіцієнті виникання. Розрізняють декілька методів оцінки помилок.
Метод сіяння помилок
Метод полягає у введенні в програму помилок, схожих з тими, що вже існують. Виявлення проводить інша група програмістів.
Нехай:
N – кількість посіяних помилок, M - загальна кількість виявлених помилок, X - кількість виявлених помилок з числа посіяних.
Ми можемо підрахувати очікуване число помилок перед тестуванням:
(M-X)*N/X
Очікуване число помилок після їх виправлення буде таким:
(M-X)*(N/X-1)
Оцінка може бути помилковою якщо посіяні помилки сильно відрізнятимуться від справжніх. Метод також дозволяє тестувати сам себе. Дуже мале значення X/N означає необхідність виправлення методу.
Тестування системи
Тестування всієї системи може відбуватися двома способами: згори вниз і знизу вгору.
Тестування знизу вгору відбувається шляхом тестування, в першу чергу, конкретних модулів, після чого відбувається їх злиття і тестування більших модулів, аж до найвищого рівня. Застосування цього підходу не завжди можливо через взаємозв'язки модулів. Для вирішення цієї проблеми використовуються модулі-заглушки.
Тестування згори вниз починається з перевірки найвищого рівня. Модулі нижчих рівнів замінюються заглушками. Протестовані модулі високого рівня інтегруються з нижчими, після чого процес продовжується. Це відбувається до тих пір, поки система не буде повністю протестована.
Стресове тестування
Стресове тестування проводиться для того, щоб оцінити надійність і продуктивність в стресових умовах. Це застосовується, в основному, до мережевих систем і систем масового доступу.
Стресове тестування перевіряє продуктивність у разі несподіваних подій, таких як: відключення електрики, велика завантаженість системи, введення невірних даних або неправильної послідовності команд.
Безпека ПЗ
Деякі системи вважаються критично важливими для безпеки людини. До них відносяться: медичне устаткування, устаткування контролю літаком і т.д. Загроза може бути також і непрямою, як у випадку з прийняттями рішень в медицині.
Слід зазначити, що безпека і надійність - не одне і те ж. Ненадійна система може бути безпечна, якщо наслідки помилок не небезпечні.
Вимоги до системи можуть бути неповними і не описувати всіх випадків. Це відноситься до вхідних даних. Для системи важливо продовжувати працювати правильно навіть у разі введення невірних даних. Помилки ПЗ повинні брати до уваги помилки апаратури, такі як збій електропостачання у сервера баз даних наприклад. Безпека повинна враховувати обидва аспекти.
Безпека ПЗ повинна враховувати, в першу чергу, з точки зору таких загроз, як смерть, втрата здоров'я, фінансові втрати, невідповідність юридичним нормам і т.д.
Наприклад, в програмі податкової декларації можуть трапитися наступні помилки:
неправильний підрахунок податку,
нестача податкових декларацій,
податкові декларації, що дублюються.
Кожна загроза повинна бути оцінена і класифікована. Для кожної з них повинне бути ухвалене рішення з розглядом найбільших можливих наслідків, а ризик повинен бути мінімізований.
Дерево несправностей
Дерево несправностей - один з інструментів, який використовують в оцінці потенційних помилок. Корінь такого дерева - одна з небезпечних ситуацій. Його вузли - проміжні ситуації, які ведуть до вузла вищого рівня.
Приклад дерева несправностей зображений на рис 1.4.
рис 1.4. Приклад дерева несправностей.
Методи зменшення наслідків загрози
Ми можемо зменшити загрози шляхом обережної і уважної реалізації частин системи, які можуть призвести до загроз. Розробку найважливіших частин системи слід доручити досвідченішим програмістам. Також можна написати і порівняти декілька версій важливих частин системи.
Правило повинно враховувати всі ситуації, які можуть призвести до загроз, і прийняти заходи шляхом посилання повідомлень користувачеві.
Чинники успіху, успіх тестування
Неможливо протестувати всі аспекти продукту, тому успіх тестування сильно залежить від визначення найвимогливіших до надійності частин програми і уважного вибору даних.
Мотивація команди тестувальників також дуже важлива - слід враховувати цінність знаходження найнебезпечніших помилок.
Головними результатами тестування є правильні: код, проект, модель і звіт про проведені тести з їх результатами. Результат також повинен містити оцінку надійності і витрат на підтримку.