|
|
Організація інтеграційного тестування. ⇐ ПредыдущаяСтр 2 из 2 Інтеграційне тестування проводиться після закінчення модульного тестування для всіх інтегрованих модулів але на практиці не завжди так. Іноді інтеграційне тестування застосовується на етапі складання всіх тестованих модулів у єдиний комплекс. Існує 2 методи скаладання модулів: - монолітний – характеризується одночасним об’єднанням усіх модулів в єдиний комплекс. – інкрементний – характеризується покроковим нарощуванням комплексів програм з покроковим тестуванням комплексів, що збирається. Стратегії інтегрованого тестування: 1.висхідне – характеризується тим, що спочатку тестуються всі програмні модулі, що входять до складної системи і тільки тоді вони об’єднуються для інтеграційного тестування. 2.спадне – припускається, що процес інтеграціного тестування слідом за розробленням спочатку тестує тільки найвищий рівень системи без модулів нижніх рівнів. 3. Комбіноване – об’єднує висхідне і спадне тестування. Планування інтеграційного тестування Інтеграція тестування є формальний процес тестування повинен бути ретельно сплановані та погоджені з часу завершення модульного тестування. При розробці плану тестування, ви повинні враховувати наступні фактори: * в тому, яка збирання системи підходу до складання та випробувань; *порядок кожного модуля збірки і підключення до процесу тестування; *розвитку код модуля і графік тестування узгоджується з збірки і випробування послідовності. *якщо під час тесту потрібне спеціальне устаткування;
Завдання і цілі системного тестування Основне завдання системного тестування — у виявленні дефектів, пов’язаних з роботою системи в цілому, таких як: *невірне використання ресурсів системи, *непередбачувані комбінації даних користувальницького рівня, *несумісність із оточенням, *непередбачувані сценарії використання, *відсутня або невірна функціональність, *незручність у застосуванні тощо. Системне тестування тестує інтегровану систему для перевірки відповідності всім вимогам. Перевірка повноти та правильності документації користувача є важливою частиною системного тестування. Всі тестові комбінації повинні розроблятися тільки з використанням документації користувача. Метою системного тестування є виявлення протиріч між розробленою системою та первісними цілями її створення. Компонентами системного тестування є розроблена система ПЗ, кінцеві цілі і вся документація, яка додається до системи. Зовнішні специфікації, що становлять основу функціонального тестування, при системному тестуванні не грають ніякої ролі.
Види системного тестування. Види системного тестування: *функціональне тестування; *тестування продуктивності; *навантажувальне тестування; *стресове тестування; *тестування конфігурації; *тестування безпеки; *тестування надійності і відновлення після збоїв; *тестування зручності використання. Початковою інформацією для проведення перерахованих видів тестування є 2 класи вимог: 1.функціональні – явно описують, що система повинна робити і які виконувати перетворення вхідних даних в вихідні; 2.не функціональні – визначають властивості системи безпосередньо не пов’язані з її функціональністю.
Типи програмних індексів. Міжнародний стандарт ANSI/IEEE-729-83 розділяє інциденти, які виникають під час розробки програм на такі типи: * Джерела дефектів (Банк досвіду, Банк інформації, Переписування, Незрілість проекту, Недогляд); *Вплив на програму (Помилка, Дефект, Відмова, Збій); * Вплив з погляду користувача (Низька якість ПЗ, Незадоволення користувача).
Помилки на етапах процесу розроблення Помилка - це стан програми, при якому генеруються неправильні результати. Причиною помилок є недоліки в операторах програми або в технологічному процесі її розроблення, що призводить до неправильного перетворення вхідної інформації у вихідну Помилки у ПЗ можна класифікувати відповідно до їхнього розподілу за етапами життєвого циклу і джерел їхнього виникнення:*ненавмисне відхилення розробників від робочих стандартів або планів реалізації; *специфікації функціональних та інтерфейсних вимог без дотримання стандартів розроблення; *недосконала організація процесу розроблення. Класифікація помилок та тестів Усі помилки поділяються на такі класи: *Логічні и функціональні помилки; *Помилки Обчислення и годині виконан; *Помилки вводу-виводу и маніпулювання Даними; *Помилки інтерфейсів; *Помилки обсягу даних та ін.1) Логічні помилки - наслідок Порушення логіки алгоритму, внутрішньої непогодженості змінніх и Операторів, а такоже мовних правил програмування. Функціональні помилки - наслідок неправильно визначених функцій, Порушення порядку їхнього! Застосування або відсутності повнотіла їхньої реализации и т.д. 2) Помилки Обчислення вінікають через неточність вхідних Даних и реалізованіх формул, похібок методів, неправильного! Застосування операцій Обчислення. Помилки годині виконан зв'язані з відсутністю необхідної швідкості ОБРОБКИ Запитів, або годині виконан або Відновлення програми. 3) Помилки вводу-виводу и маніпулювання Даними є наслідком неякісної підготовкі Даних для виконан програми, збоїв при занесенні їх у базу даних або при вібірці з неї.4) Помилки інтерфейсу належати до помилок взаємозв'язку окремий елементів одного з одним, что віявляється при передачі даних між ними, а такоже при взаємодії із середовищем Функціонування.5) Помилки обсяги належати до даних и є наслідком того, что реалізовані методи доступу и Розміри баз даних НЕ задовольняють реальні обсяги информации системи або інтенсівності їхньої обробки. 42) Середовище тестування ПЗ Значний об’єм тестування складних систем переважно виконується із використанням інструментальних засобів в напівавтоматичному чи автоматичному режимі. Крім того, тестована система зазвичай розбивається на окремі модулі, кожен з яких тестується спочатку окремо від інших. потім в комплексі. Це означає, що для тестування необхідно створити деяке сховище, яке забезпечить запуск і виконання тестового модуля, передати йому вхідні дані, збере реальні вхідні дані, отримані в результаті роботи системи на заданих вхідних даних. Після цього середовище повинне порівняти реальні вихідні дані з очікуваними і на підставі цього порівняння зробити висновок про відповідність поведінки модуля заданій. Тестове оточення також може виконуватися для відчуження окремих модулів системи від всієї системи. Розподілення модулів системи на ранніх етапах тестування дає змогу точніше локалізувати проблеми, що виникають в їх програмному коді. Для підтримки роботи модуля у відриві від системи тестове оточення повинне моделювати поведінку всіх модулів, до функцій або даних яких звертається тестований модуль.Драйвера та заглушки Тестове оточення для програмного коду на структурних мовах програмування складається з двох компонентів - драйвера, який забезпечує запуск і виконання модуля, що тестується, і заглушок, які моделюють функції, що викликаються з даного модуля. Розробка тестового драйвера являє собою окрему задачу тестування, сам драйвер повинен бути протестований, щоб виключити невірне тестування. Драйвер і заглушки можуть мати різні рівні складності, необхідний рівень складності вибирається залежно від складності тестованого модуля та рівня тестування. Так, драйвер може виконувати наступні функції: 1) Виклик модуля, що тестується. 2) Передача в модуль, що тестується вхідних значень і прийом результатів. 3) Ввисновок вихідних значень. 4) Протоколювання процесу тестування і ключових точок програми. Заглушки можуть виконувати такі функції: 1) Не проводити ніяких дій (такі заглушки потрібні для коректної збірки тестованого модуля). 2) Виводити повідомлення про те, що заглушка була викликана. 3) Виводити повідомлення зі значеннями параметрів, переданих у функцію. 4) Повертати значення, заздалегідь заданий у вхідних параметрах тесту. 5) Виводити значення, заздалегідь заданий у вхідних параметрах тесту. 6) Приймати від тестованого ПО значення і передавати їх в драйвер
Тестові класи. Тестове оточення для об’єктно-орієнтованого ПЗ виконує ті самі функції, що для структурних програм. Проте воно має деякі особливості, пов’язані із застосуванням успадкування та інкапсуляції, воно теж має бути протестоване. Метою тестування тестового оточення є доказ того, що тестове оточення жодним чином не спотворює виконання тестового модуля і адекватно моделює поведінку сиситеми.
Генератори сигналів.
  Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...  Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...  Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...  Система охраняемых территорий в США Изучение особо охраняемых природных территорий(ООПТ) США представляет особый интерес по многим причинам... Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
|