Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Етап тестування
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Комп’ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2011
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Технологія програмування та створення програмних продуктів
Частина тексту файла (без зображень, графіків і формул):
Методичні вказівки
до лабораторної роботи № 5
“Етап тестування”
з дисципліни
“Технологія програмування та створення програмних продуктів”
для студентів базового напрямку підготовки за спеціальністю
“Комп’ютерні науки” (шифр 0804)
Львів 2010 – 2011
Методичні вказівки до лабораторної роботи № 4 “Етап тестування” з дисципліни “Технологія програмування та створення програмних продуктів” для студентів спеціальності - шифр 0804 “Комп’ютерні науки”/ Укл. доц. Ковівчак Я.В.,
Львів: Національний університет “Львівська політехніка”, 2011.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2011 р.
Завідувач кафедрою АСУ ______________ Рашкевич Ю. М.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2011 р.
Лабораторна робота № 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. Приклад дерева несправностей.
Методи зменшення наслідків загрози
Ми можемо зменшити загрози шляхом обережної і уважної реалізації частин системи, які можуть призвести до загроз. Розробку найважливіших частин системи слід доручити досвідченішим програмістам. Також можна написати і порівняти декілька версій важливих частин системи.
Правило повинно враховувати всі ситуації, які можуть призвести до загроз, і прийняти заходи шляхом посилання повідомлень користувачеві.
Чинники успіху, успіх тестування
Неможливо протестувати всі аспекти продукту, тому успіх тестування у більшій мірі залежить від визначення найвимогливіших до надійності частин програми і уважного вибору даних.
Мотивація команди тестувальників також дуже важлива - слід враховувати цінність знаходження найнебезпечніших помилок.
Головними результатами тестування є правильні: код, проект, модель і звіт про проведені тести з їх результатами. Результат також повинен містити оцінку надійності і витрат на підтримку.
2. Приклад реалізації етапу тестування
На цьому етапі було проведено тестування проекту СОСtrial згідно плану розробленого на етапі реалізації.
Було розглянуто основні види тестувань і з них обрано найоптимальніші для даної системи.
Статистичне тестування було опущено оскільки даний проект не передбачає складних операцій обробки даних, в яких можуть виникати помилки.
Метод прозорої скриньки був обраний, оскільки він дозволяє визначити джерело помилки безпосередньо в програмному коді.
Автоматизоване тестування як підвид тестування методом прозорої скриньки було відкинуто, оскільки таке тестування потребує додаткових витрат на написання тестуючого коду, що є недоцільним у випадку невеликих проектів, як наш.
Метод чорної скриньки також був обраний, оскільки він базовим та поростим, і не вимагає заглиблення у принципи функціонування сиситеми.
Статичні тести проводились програмістами в процесі розробки системи. Такі тести базуються на аналізі коду, що є ефективним у випадку невеликих за об’ємом коду систем. Також такі тести є економічно вигідними оскільки виконуються безпосередньо програмістами без участі тестерів.
Метод сіяння помилок не використовувався для тестування даного проекту, оскільки даний проекти не є великим і має добре виражену просту структуру.
Спочатку тестувалися класи модулів: AccountManagerDAL, ReportBuilderDAL і SurveyBuilderDAL (Клієнт 1); і класи модуля: SurveyDAL (Клієнт 2).
Для тестування цих класів використовувались такі методи тестування, як метод чорної скриньки та метод прозорої скриньки. Ті класи у яких було виявлено несправності при тестуванні методом чорної скриньки тестувалися методом прозорої скриньки для визначення джерела помилки. Нижче описаний процес тестування за кожним із обраних методів для Клієнта 1 і Клієнта 2.
Тестування методом чорної скриньки
Клієнт 1:
Модуль AccountManagerDAL:
TUsersDAL. В даному класі тестувались методи необхідні для роботи з користувацькими записами системи: GetRoleId, GetFreeUserId, IsInLogin, IsInUserId, AddUser, UpdateUser, DeleteUser, GetUsers, GetUsersById, GetUsersByName, GetUsersByLogin, GetUsersByPassword, GetUsersByRoleId, GetUsersByGroupId. Нижче детально описаний прцес тестування основних з цих методів:
GetRoleId – цей метод використовується для логування.
Було проведено три тести для перевірки коректності роботи даного методу:
Тест №1. Запуск клієнта, натиснення кнопки SignIn, ввід логіна (‘tester’) і пароля (‘1111’), які невідповідають жодному користувацькому запису в базі (Рис. 1).
Рис. 1.
Після натиснення кнопки Enter (Рис. 1) програма видає повідомлення про некоректні дані логування (Рис. 2):
Рис. 2.
Тест №2. Запуск клієнта, натиснення кнопки SignIn, ввід логіна (‘admin’) і пароля (‘admin’), які відповідають користувацькому запису адміністратора в базі (Рис. 3):
Рис. 3.
Після натиснення кнопки Enter (Рис. 3) відбуваєтся вхід у систему в режимі адміністратора, що супроводжується відповідним повідомленням (Рис. 4):
Рис. 4.
Тест №3. Запуск клієнта, натиснення кнопки SignIn, ввід логіна (‘teacher’) і пароля (‘teacher’), які відповідають користувацькому запису викладача в базі (Рис. 5).
Рис. 5.
Після натиснення кнопки Enter (Рис. 5) відбуваєтся вхід у систему в режимі викладача, що супроводжується відповідним повідомленням (Рис. 6):
Рис. 6.
Висновок: метод працює коректно.
Всі описані нижче тести передбачають такі попередні дії, як запуск клієнта та логування під адміністратором або викладачем.
AddUser – цей метод використовується для додавання нового користувацького запису в базу.
Було проведено простий тест для перевірки коректності роботи цього методу:
Тест. Ввід даних про нового користувача у відповідних полях (User_Id: 6, Full_Name: ela, Login: ela, Password: alo, Role: Student) (Рис. 7):
Рис. 7.
Після натиснення кнопки Add / Edit (Рис. 7) програма видає діалогове вікно для підтвердження виконання операції (Рис. 8):
Рис. 8.
Після натиснення кнопки Yes (Рис. 8) у базу даних буде доданий користувацький запис (Рис. 9):
Рис. 9.
Висновок: метод працює коректно.
UpdateUser – цей метод використовується для зміни користувацького запису в базі.
Було проведено тест для перевірки коректності роботи цього методу:
Тест. Вибір зі списку користувачів запису ID якого рівне ‘1’ (Рис.10):
Рис. 10.
У полі Login зміна логіну з ‘lol’ на ‘nova4ok’ і у комбобоксі Role зміна ролі з ‘Student’ на ‘Teacher’ (Рис. 11):
Рис. 11.
Після натиснення кнопки Add / Edit (Рис. 11) програма видає діалогове вікно для підтвердження виконання операції (Рис. 12):
Рис. 12.
Після натиснення кнопки Yes (Рис. 12) програма видає повідомлення про помилку (Рис. 13) і потрібна операція не виконуєтся:
Рис. 13.
Висновок: Потребує тестування методом прозорої скриньки.
DeleteUser – цей метод призначений для видалення користувацького запису з бази.
Було проведено простий тест для перевірки коректності роботи цього методу:
Тест. Вибір зі списку користувацького запису ID якого дорівнює ‘4’ (Рис. 14):
Рис. 14.
Після натиснення кнопки Delete (Рис. 14) програма видає діалогове вікно для підтвердження виконання операції (Рис. 15):
Рис. 15.
Після натиснення кнопки Yes (Рис. 15) з бази даних буде видалений вибраний користувач (Рис. 16):
Рис. 16.
Висновок: метод працює коректно.
GetUsers – цей метод призначений для завантаження всіх користувацьких записів з бази даних.
Вище описані тести продемонстрували коректну роботу цього методу оскільки на таблиці користувацьких записів були відтворені всі записи бази даних.
Наступні методи, це методи фільтрації даних. Нижче наведена таблиця відтворює всі користувацькі записи бази.
Таблиця 1
GetUsersById – цей метод призначений для пошуку (фільтрації) користувацьких записів за ID.
Нижче наведений тест для перевірки коректності роботи цього методу:
Тест. Вибір типу ключа фільтрування User Id (1), ввід у поле Key значення ‘2’ (2) (Рис. 17):
Рис. 17.
Зразу після вводу числа ‘2’ у поле Key вибиває помилка (3) і пошук користувача не виконується (Рис. 17).
Висновок: Потребує тестування методом прозорої скриньки.
GetUsersByName – цей метод призначений для пошуку (фільтрації) користувацьких записів за повним іменем користувачів.
Нижче наведений тест для перевірки коректності роботи цього методу:
Тест. Запуск клієнта, логування під адміністратором або викладачем, вибір типу
05.10.2016 14:10-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора