Глосарій

Автоматизація виконання тестів (test execution automation): Використання програмного забезпечення (наприклад, засобів захоплення / відтворення) для контролю виконання тестів, порівняння отриманих результатів з еталонними, встановлення передумов тестів та інших функцій контролю тестування та організації звітів.

Автоматизація тестування (test automation): Використання програмного забезпечення для здійснення або допомоги у проведенні певних тестових процесів, наприклад, управління тестуванням, проектування тестів, виконання тестів і перевірка результатів.

Автоматизоване тестування (scripted testing):Виконання тестів, що реалізовується за допомогою заздалегідь записаної послідовності тестів.

Автоматизоване тестове забезпечення (automated testware): Тестове забезпечення, що використовується в автоматизованому тестуванні, наприклад, інструментальні сценарії. Автоматизований сценарій тестування (test script): Звичайно стосується специфікації процедури тестування (автоматизованої).

Активація шляхів (path sensitizing): Складання набору вхідних значень для забезпечення виконання певного шляху.

Альтернатива (decision): Точка програми, в якій управління має два або більше альтернативних шляхів. Вузол з двома або більше зв'язками для розділення гілок.

Альфа-тестування (alpha testing): модельований або дійсний експлуатаційне тестування потенційними користувачами / замовниками або незалежної командою тестування на стороні розробників, але поза розробляє організації. Альфа-тестування часто застосовується до коробковому програмного забезпечення в якості внутрішнього приймального тестування.

Аналіз впливу (impact analysis): Оцінка змін до документації розробки та тестування, а також компонентів з метою внесення цих змін до певні вимоги.

Аналіз граничних значень (boundary value analysis): Розробка тестів методом чорного ящика, в якому тестові сценарії проектуються на підставі граничних значень.

Аналіз дерева недоліків (Fault Tree Analysis (FTA)): Метод, який використовується для аналізу причин недоліків (дефектів). Методика візуально моделює для розкриття специфічних недоліків те, як логічні зв'язки між відмовами, людськими помилками і зовнішніми подіями можуть поєднуватися.

Аналіз мутацій (mutation analysis): Метод визначення закінченості набору тестів шляхом вимірювання ступеня, з якою набір тестів може відрізнити програму від її незначних варіацій. Аналіз першопричини (root cause analysis): Аналіз, спрямований на ідентифікацію першопричин дефектів. При застосуванні заходів до усунення першопричини, можна сподіватися на мінімізацію частоти появи дефектів певного типу.

Аналіз покриття (coverage analysis): Вимірювання досягнутого покриття по відношенню до заданого елементу покриття під час виконання тесту відповідно до зумовленими критеріями. Проводиться для визначення, чи необхідно додаткове тестування, і якщо так, то які тестові сценарії потрібні.

Аналіз потоку даних (data flow analysis): Вид статичного аналізу, заснований на визначенні та використанні змінних.

Аналіз потоку керування (control flow analysis): Вид статичного аналізу, заснований на представленні послідовностей подій (шляхів) у процесі виконання компонента або системи.

Аналіз ризиків (risk analysis): Процес оцінки ідентифікованих ризиків для обчислення їх ймовірності та впливу.

Аналіз випадковості (hazard analysis): Метод, який використовується для характеристики елементів ризику. Результат аналізу випадковості визначають методи, використовувані в розробці і тестуванні системи.

Аналіз тестованості (testability review): Детальна перевірка базису тестування з метою визначення, чи є він достатньо якісним, щоб виступати в ролі першоджерела для процесу тестування.

Аналіз тестових точок (Test Point Analysis (TPA)): Метод оцінки витрат на тестування на основі формули, що спирається на аналіз функціональних точок.

Аналіз типів відмов і ефекту (Failure Mode and Effect Analysis (FMEA)): систематичний підхід для визначення та аналізу ризиків ідентифікації можливих типів відмов і спроба їх запобігання. Аналіз типів відмов, ефекту та критичності (Failure Mode, Effect and Criticality Analysis (FMECA)): розширення FMEA; на додаток до основного FMEA, включає аналіз критичності, використовуваний для відображення ймовірності типів відмов по відношенню до критичності їх наслідків. Результат відображає тип відмови з відносно високою вірогідністю і критичністю наслідків, дозволяючи зробити коригувальні дії там, де вони будуть мати найбільшу цінність.

Аналіз функціональних точок (Function Point Analysis (FPA)): Метод, що допомагає при оцінці розміру функціональності інформаційної системи. Оцінка не залежить від технології. Оцінка може бути використана як основа оцінки продуктивності, розрахунку необхідних ресурсів і контролю проекту. Аналізованість (analyzability): Здатність програмного продукту бути перевіреним на відсутність відмов або їх причин, а також частин, які потрібно перевірити внаслідок змін.

Аналітичний звіт про тестування (test evaluation report): Документ, створюваний у кінці процесу тестування та підвідний підсумок тестовим активностей і результатів. Також в ньому міститься оцінка процесу тестування і винесений досвід.

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

Атака (attack): Спрямована і націлена спроба оцінити якість, головним чином надійність, об'єкта тестування за рахунок спроб викликати певні відмови.

Аудит (audit): Незалежна оцінка програмних продуктів або процесів з метою встановлення відповідності стандартам, рекомендаціям, специфікаціям та / або процедур, заснованим на об'єктивних критеріях, що включають документи, як визначають:

(1) . Форму або утримання продуктів для виробництва;

(2) . Процес, згідно з яким продукти будуть зроблені;

(3) . Як буде вимірюватися відповідність стандартам або рекомендаціями.

Аудит конфігурації (configuration auditing): Функція перевірки складу бібліотек елементів конфігурації, наприклад на відповідність стандартам.

Базис тестування (test basis): Документ, на підставі якого визначаються вимоги до компоненту або системі. Документація, на якій базуються тестові сценарії. Якщо правка даного документа може бути здійснена тільки в процесі формальної процедури внесення зміни, то такий базис тестування називається замороженим базисом тестування.

Базова версія (baseline): Специфікація або програмний продукт, який був формально відрецензованих або узгоджений, надалі використовується як базова версія для подальшої розробки, і який може бути змінений тільки в процесі формального контролю процесу змін.

Базовий набір тестів (basis test set): Набір тестових сценаріїв отриманих на підставі внутрішньої структури компонента або специфікації, призначений для переконання в 100% досягненні заданих критеріїв покриття.

Безпека (safety): Здатність програмного продукту при використанні обговореним чином залишатися в рамках прийнятного ризику заподіяння шкоди здоров'ю, бізнесу, програмами, власності або навколишньому середовищу. Бета-тестування (beta testing): Експлуатаційне тестування потенційними та / або існуючими клієнтами / замовниками на зовнішній стороні ніяк не пов'язаними з розробниками, з метою визначення чи дійсно компонент або система задовольняє вимогам клієнта / замовника і вписується у бізнес-процеси. Бета- тестування часто проводиться як форма зовнішнього приймального тестування готового програмного забезпечення для того, щоб отримати відгуки ринку.

Валідація (validation): Доведені об'єктивними результатами дослідження підтвердження того, що вимоги для конкретного певного використання програми були виконані.

Вартість забезпечення якості (cost of quality): Загальна вартість витрат на завдання забезпечення та проблеми якості, часто колективна на вартість запобігання, вартість оцінки, вартість внутрішніх відмов і вартість зовнішніх відмов.

Відлагодження (debugging): Процес пошуку, аналізу, та усунення причин відмов у програмному забезпеченні.

Відмова (failure): Відхилення компонента або системи від очікуваного виконання, експлуатації або результату. Відображення причинно-наслідкових зв'язків (cause-effect graphing): Розробка тестів методом чорного ящика, в якому тестові сценарії розробляються на основі діаграм причинно- наслідкових зв'язків.

Відсоток виявлення дефектів (Defect Detection Percentage (DDP)): Кількість дефектів, виявлених у фазі тестування, поділене на кількість дефектів, знайдених в цій фазі тестування, а також у всіх подальших фазах.

Верифікація (verification): Доведені об'єктивними результатами дослідження підтвердження того, що певні вимоги були виконані. Віха (milestone): Точка протягом часу проекту, до якої заздалегідь визначені (проміжні) поставки і результати повинні бути готові. Відтворюваність тесту (test reproduceability): Атрибут тесту, що показує, що результати тесту однакові при кожному виконанні цього тесту.

Відновлюваність (recoverability): Здатність программного продукту відновлювати необхідний рівень працездатності та робочі дані, що постраждали в результаті помилки. Відстежуваність (traceability): Здатність ідентифікувати зв'язані об'єкти в документації та програмному забезпеченні, наприклад, вимоги з пов'язаними з ними тестами.

Вільне тестування (ad hoc testing): Тестування, яке виконується неформально; без формальної підготовки тестів, формальних методів проектування тестів, визначення очікуваних результатів і керівництва з виконання тестування.

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

Висхідне тестування (bottom-up testing): Послідовний підхід до інтеграційного тестування, при якому компоненти нижнього рівня тестуються першими і потім використовуються для полегшення тестування компонентів більш високого рівня. Цей процес повторюється до тих пір, поки компонент на самому верху ієрархії не буде протестовано.

Вхідний тест (intake test): Спеціальний тип тесту "на дим" для ухвалення рішення, чи готовий компонент або система для подальшого детального тестування. Зазвичай починається на початку фази тестування.

Вхідні дані тесту (test input): Дані, одержувані об'єктом тестування із зовнішнього джерела під час проведення тестування. У ролі зовнішнього джерела може виступати апаратне забезпечення, програмне забезпечення чи людина. Вибіркове тестування (random testing): Розробка тестів методом чорного ящика, в якому тестові сценарії вибираються для відповідності функціональному розрізу, зазвичай за допомогою алгоритму псевдо-випадкового вибору. Цей метод може використовуватися для тестування таких нефункціональних атрибутів, як надійність і продуктивність.

Використання ресурсів (resource utilization): Здатність використання програмним продуктом відповідної кількості ресурсів певного типу (наприклад, обсягу оперативної і пам'яті другого рівня, розміру тимчасових файлів і т.д.) під час роботи за встановлених умов.

Виконання тесту (test execution): Процес запуску тесту на досліджуваному компоненті або системі, що приводить до реальних результатів.

Вимірювання (measurement): Процес присвоєння числа або категорії сутності для опису атрибута цієї сутності.

Вимога (requirement): Умови або можливості, необхідні користувачу для вирішення певних завдань або досягнення певних цілей, які повинні бути досягнуті для виконання контракту, стандартів, специфікації, або інших формальних документів.

Гнучке тестування (agile testing): Спосіб тестування для проектів, що використовують гнучкі методології, такі як екстремальне програмування (XP), що розглядає процес розробки як споживача процесу тестування і робить наголос на парадигму раннього тестування

Головний план тестування (master test plan): План тестування, зазвичай охоплює кілька рівнів тестування.

Граничне значення (boundary value): Вхідне або вихідне значення, яке перебуває на межі еквівалентної області або на найменшому відстані від обох сторін межі, наприклад, мінімальна або максимальне значення області.

Граф потоку керування (control flow graph): Абстрактне представлення всіх можливих послідовностей подій (шляхів) у процесі виконання компонента або системи.

Графік тестування (test schedule): Список завдань, дій або подій у процесі тестування, що визначає дати і / або час їх початку та завершення, і їх взаємозалежності.

Група контролю конфігурації (configuration control board (CCB)): Група людей, відповідальних за оцінку та затвердження або незатвердження запропонованих змін в елементах конфігурації, а також за забезпечення внесення запропонованих змін.

Дерево класифікації (classification tree): Дерево, що показує ієрархічно впорядковані еквівалентні області, яке використовується для розробки тестових сценаріїв у методі дерева класифікації.

Дефект (defect): вилучили в компоненті або системі, що може призвести компонент або систему до неможливості виконати потрібну функцію, наприклад невірний оператор або визначення даних. Дефект, виявлений під час виконання, може призвести до відмов компонента або системи.

Динамічний аналіз (dynamic analysis): Процес оцінки поведінки, наприклад продуктивності пам'яті, завантаження ЦПУ системи або компонента під час виконання.

Динамічне порівняння (dynamic comparison): Порівняння фактичного і очікуваного результатів, вироблене під час роботи програмного забезпечення, наприклад за допомогою інструменту виконання тестів.

Динамічне тестування (dynamic testing): Тестування, проведене під час виконання програмного забезпечення, компонента або системи.

Дослідницьке тестування (exploratory testing): Неформальний метод проектування тестів, при якому тестувальник активно контролює проектування тестів в той час, як ці тести виконуються, і використовує отриману під час тестування інформацію для проектування нових і поліпшених тестів. Доступність (availability): Рівень готовності та доступності компонента або системи при необхідності їх використання. Часто виражається у відсотках.

Евристична оцінка (heuristic evaluation): Статична методика тестування практичності для визначення відповідності інтерфейсу користувача визнаним принципам практичності (також звана ”евристика ”).

Еквівалентна область (equivalence partition): Частина області вхідних або вихідних даних, для якої поведінка компонента або системи, грунтуючись на специфікації, вважається однаковим. Еквівалентне розбиття (equivalence partitioning): Розробка тестів методом чорного ящика, в якій тестові сценарії створюються для перевірки елементів еквівалентної області. Як правило, тестові сценарії розробляються для покриття кожній області як мінімум один раз.

Експлуатаційне приймальне тестування (operational acceptance testing): Експлуатаційне тестування у фазі приймального тестування, зазвичай виконується користувачем і / або адміністратором в середовищі, що імітує реальні умови робочого оточення, фокусуючись на функціональних аспектах. Наприклад, відновлюваність, поведінка ресурсів, і технічне відповідність. Експлуатаційне тестування (operational testing): Тестування, що проводиться для оцінки компонента або системи в його робочому оточенні.

Елемент конфігурації (configuration item): Поєднання апаратного та / або програмного забезпечення, призначене для управління конфігурацією і розглядається в процесі управління конфігурацією як окремий об'єкт.

Елемент покриття (coverage item): Сутність або властивість, що використовуються як базис для тестового покриття, наприклад еквівалентні області або оператори в коді.

Елемент тестування (test item): Окремий елемент, який повинен бути протестований. Зазвичай є один тестовий об'єкт і кілька елементів тестування.

Елементарне порівняльне тестування (elementary comparison testing): Розробка тестів методом чорного ящика, в якому тестові сценарії створюються для перевірки комбінацій вхідних даних, використовуючи концепцію покриття визначень умов.

Емулятор (emulator): пристрій, комп'ютерна програма або система, яка приймає ті ж самі вхідні дані і видає ті ж самі вихідні дані, що й дана система.

Еталонний тест (benchmark test): Стандарт, згідно з яким може здійснюватися вимір або порівняння. Тест, який може використовуватися для порівняння компонентів або систем один з одним або на відповідність стандарту.

Етап вимог (requirements phase): Період в життєвому циклі програмного забезпечення, на протязі якого визначаються і документуються вимоги до програмного продукту.

Ефективність (efficiency): Здатність програмного забезпечення забезпечувати необхідну продуктивність, щодо кількості ресурсів використовуваних при встановлених умовах.

Заблокований тестовий сценарій (blocked test case): Тестовий сценарій, який не може бути виконаний внаслідок невиконання передумов.

Завершення тестування (test closure): Під час фази завершення тестування збираються дані про всі завершених процесах з метою об'єднання досвіду, тестового забезпечення, фактів і чисел. Фаза завершення тестування складається з архівування тестового забезпечення та оцінки процесу тестування, що включає в себе підготовку аналітичного звіту про тестування. Див також процес тестування.

Заглушка (stub): Мінімальна або спеціалізована реалізація програмного компонента. Що використовується для підміни компонента, від якого залежить розробка або тестування іншого компонента системи.

Замінність (replaceability): Здатність програмного продукту до використання його замість іншого програмного продукту для тих же самих цілей і в тому ж самому оточенні.

Заморожений базис тестування (frozen test basis): Документ базису тестування, який може бути змінений тільки за допомогою формального процесу контролю змін.

Засіб захоплення і відтворення (capture / playback tool): Тип інструменту виконання тестів, в якому вхідна інформація записується під час ручного тестування з метою створення автоматизованих тестових сценаріїв, які можуть бути виконані пізніше (тобто повторені). Ці кошти часто використовують для підтримки автоматизованого регресійного тестування.

Засіб перевірки гіперпосилань (hyperlink tool): Інструмент, який застосовується для перевірки наявності на веб-сайті невірних гіперпосилань.

Засіб управління конфігурацією (configuration management tool): Засіб, що забезпечує підтримку ідентифікації та контролю елементів конфігурації, їх статусу в розрізі змін і версій, а також випуску базових версій, що складаються з елементів конфігурації. Захищеність (security): Властивості програмного продукту, що відбивають його здатність не допускати неавторизованому доступу, випадковий або умисний, до програм і даних.

Звіт про дефекти (defect report): Документ, що містить звіт про будь-якому нестачу в компоненті або системі, що може призвести компонент або систему до неможливості виконати потрібну функцію.

Звіт про хід тестування (test progress report): Документ, що підводить підсумок завданням і результатами, що складається з певною періодичністю з метою порівняння прогресу тестування з базовою версією (такими, як вихідний план тестування) та сповіщення про ризики і альтернативи, що вимагають рішення керівництва.

Звіт щодо інциденту (incident report): Документ, що описує подію, що відбулася, наприклад, під час тестування, і яке необхідно дослідити.

Здатність бути зміненим (changeability): Здатність програмного продукту бути зміненим певним чином при необхідності. Здійсненний шлях (feasible path): Шлях, для якого існує набір вхідних значень і передумов, що дозволяють йому бути виконаним.

Зрозумілість (understandability): Здатність програмного продукту надати користувачеві можливість зробити висновок про придатність продукту, і про те, яким чином даний продукт може бути використаний для виконання конкретних завдань.

Ідентифікація конфігурації (configuration identification): Елемент керування конфігурацією, що складається з вибору елементів конфігурації для системи і фіксування їх функціональних та фізичних характеристик у технічній документації.

Ізоляційне тестування (isolation testing): Тестування окремих компонентів в ізоляції від навколишніх компонентів в оточенні компонентів, які при необхідності емулюються заглушками і драйверами.

Імітатор (simulator): пристрій, комп'ютерна програма або система, використовувана в тестуванні, що працює або ведуча себе аналогічно заданої при тих же вхідних даних.

Імітація (simulation): Моделювання обраних поведінкових характеристик одному фізичному або теоретичної системи іншою системою.

Інфраструктура тестування (test infrastructure): Артефакти, необхідні для проведення тестування, такі як тестове оточення, інструменти тестування, офісне оточення та процедури.

Ітеративний модель розробки (iterative development model): Модель життєвого циклу розробки, в якій проект розділено зазвичай на велику кількість ітерацій. Ітерація це повний цикл розробки, що завершується випуском (внутрішнім або зовнішнім) робочого продукту, що є частиною кінцевого розробленого продукту, який розростається від ітерації до ітерації.

Класифікація дефектів (defect taxonomy): Ієрархічна система категорій, розроблена для допомоги в класифікації дефектів.

Код (code): Комп 'ютерні інструкції та визначення даних, виражені програмним мовою або у формі вихідних даних збирача, компілятора чи іншого транслятора.

Компонент (component): Найменший елемент программного забезпечення, який може бути протестований окремо. Компонентне тестування (component testing): Тестування окремих компонентів програмного забезпечення.

Кінцевий автомат (finite state machine): Обчислювальна модель, що складається з обмеженої кількості станів і переходів між цими станами, можливо супутніми діями.

Контроль конфігурації (configuration control): Елемент керування конфігурацією, що складається з оцінки, координації, затвердження або відхилення, а також внесення змін до елементи конфігурації після формального обгрунтування ідентифікації конфігурації.

Контроль ризиків (risk control): Процес, в результаті якого виносяться рішення і приймаються захисні заходи для зменшення ризиків до певного рівня або підтримання ризиків в обумовлених межах.

Контроль тестування (test control): Завдання управління тестуванням, пов'язана з розробкою і застосуванням комплексу коригуючих заходів для повернення тестування проекту в графік при виявленні відхилень від плану.

Конфігурація (configuration): структура компонента або системи, що визначається числом, типом і взаємопов'язаність складових частин.

Концепція тестування (test charter): Виклад цілей тестування і, можливо, ідей щодо процесу тестування. Використовуються в дослідницькому тестуванні.

Координатор (moderator): Лідер і головна особа, відповідальна за інспекцію або інший процес рецензування.

Користувацький тест (user test): Тест, під час якого реальні користувачі включаються у процес оцінки практичності компонента або системи.

Критерії входу (entry criteria): Набір загальних і специфічних умов для продовження процесу з певним завданням, наприклад, фаза тестування. Мета критеріїв входу - запобігання початку завдання, яке може вимагати більше (марних) зусиль, ніж на усунення не пройдених критеріїв входу.

Критерії виходу (exit criteria): Набір загальних і специфічних умов, узгоджених заздалегідь із зацікавленими сторонами, для того, щоб процес міг офіційно вважатися завершеним. Мета критеріїв виходу - запобігання можливості, коли завдання вважається завершеним, проте ще існують окремі незавершені частини завдання. Критерії виходу використовуються для звітності, а також планування того, коли зупинити тестування.

Критерії приймання (acceptance criteria): Критерії виходу, яким повинні відповідати компонент або система, для того, щоб бути прийнятими користувачем, замовником або іншою уповноваженою особою.

Критерій відновлення тестування (resumption criteria): Критерії, виконання яких повинно викликати відновлення тестування після його припинення.

Критерій призупинення (suspension criteria): Умови, при виконанні яких (тимчасово) призупиняється тестування, повністю або частково.

Критерій проходження / непроходження (pass / fail criteria): Правила для визначення того, чи пройшов елемент тестування або властивість тест чи ні.

Критичність (severity): Важливість впливу конкретного дефекту на розробку або функціонування компонента або системи.

Маскування дефектів (defect masking): Випадок, коли один дефект перешкоджає знаходженню іншого.

Масштабованість (scalability): Здатність програмного продукту до модернізації з метою задоволення зростаючого навантаження. Міра (measure): Число або категорія, привласнена атрибуту суті шляхом проведення вимірювання.

Мертвий код (dead code): Див недосяжний код.

Метод білого ящика (white-box technique): Див розробка тестів методом білого скриньки.

Метод виконання тестів (test execution technique): Метод, вибраний для фактичного виконання тестів, ручний або ж автоматизований.

Метод дерева класифікації (classification tree method): Розробка тестів методом чорного ящика, в якій тестові сценарії, описані засобами дерева класифікації, розробляються для перевірки комбінацій вибірок вхідних та / або вихідних підмножин.

Метод проектування тестів (test design technique): Метод, який використовується для створення та / або вибору тестових сценаріїв.

Метод тестування "великий вибух” (big-bang testing): Вид інтеграційного тестування, в якому елементи програмного або апаратного забезпечення, або і те й інше, збираються в компонент або в цілу систему відразу, а не по етапах.

Метод чорного ящика (black box technique): Див розробка тестів методом чорного ящика.

Метод на основі дефектів (defect based technique): Див метод створення тестових сценаріїв на основі дефектів.

Метод на основі досвіду (experienced-based technique): Див метод створення тестів на основі досвіду.

Метод проектування функціональних тестів (functional test design technique): Процедура для отримання та / або вибору тестових сценаріїв, грунтується на аналізі специфікації функціональності компонента або системи без посилання на внутрішню структуру.

Метод створення тестів на основі досвіду (experienced-based test design technique): Процедура отримання та / або вибору тестових сценаріїв, заснована на досвіді, знаннях та інтуїції тестувальника.

Метод створення тестових сценаріїв на основі дефектів (defect based test design technique): Процедура отримання та / або вибору тестових сценаріїв, орієнтованих на одну або більше категорію дефектів, з розробкою тестів виходячи зі знань про певну категорії дефектів.

Метрика (metric): Шкала вимірювань і метод, який використовується для вимірювань.

Модель зрілості процесів розробки програмного забезпечення

(Capability Maturity Model (СММ)): п'ятирівневий система, що описує ключові елементи ефективного процесу розробки програмного забезпечення. Модель зрілості включає в себе передовий досвід планування, проектування та управління процесами розробки та підтримки програмного забезпечення. Модель зрілості Тестування (Test Maturity Model (TMM)): П'ятиступінчаста структура поліпшення процесу тестування, пов'язана з моделлю зрілості процесів програмного забезпечення

(CMM) і описує ключові елементи ефективного процесу тестування.

Модель зростання надійності (reliability growth model): Модель, що показує зростання надійності під час тестування компонента або системи, викликаний виправленням дефектів, що викликали відмови.

Модуль (module, unit): Див компонент.

Модульне тестування (module testing, unit testing): Див Компонентне тестування.

Можливість взаємодії (interoperability): здатність програмного продукту взаємодіяти з одним або більше заданими частини та системами.

Монітор (monitor): Програмний інструмент або апаратний пристрій, запущене паралельно з тестованим компонентом чи системою і здійснює спостереження, запис і / або аналіз поведінки цього компонента або системи.

Моніторинг тестування (test monitoring): Завдання управління тестуванням, пов'язана з періодичною перевіркою статусу тестування проекту. Складаються звіти містять порівняння реального стану із запланованим.

Набір тестів (test suite): Комплект тестових наборів для досліджуваного компонента або системи, в якому зазвичай постусловіе одного тіста використовується в якості передумови для подальшого.

Надійність (reliability): Здатність програмного продукту функціонувати при заданих умовах протягом певного періоду часу, або для певної кількості операцій.

Не пройдений (fail): Тест вважається не пройденим, якщо фактичний результат не відповідає очікуваного результату. Негативне тестування (negative testing): Тестування, націлене на демонстрацію того, що система або компонент не працюють. Негативний тестування відноситься більшою мірою до позиції тестувальника, ніж до певного підходу до тестування або метод проектування тестів, наприклад - тестування з некоректними вхідними значеннями або тестування обробки винятків. Недосяжний код (unreachable code): Код, який не може бути досягнутий і виконаний.

Недосяжний шлях (infeasible path): Шлях, який не може бути перевірений будь-яким набором можливих вхідних значень. Незалежність тестування (independence of testing): Поділ відповідальностей, яке дозволяє виконувати об'єктивне тестування.

Невідповідність (non-conformity): Невиконання певного вимоги. Неформальне рецензування (informal review): Рецензування, яке не грунтується на формальній (документованої) процедурою. Нефункціональне тестування (non-functional testing): Тестування атрибутів компонента або системи, що не відносяться до функціональності, тобто надійність, ефективність, практичність, сопровождаемость і переносимість Нефункціональні вимоги (non-functional requirement): Вимоги, пов'язані не до функціональності, а до таких атрибутів як надійність, ефективність, практичність, сопровождаемость і переносимість.

Нефункціональний метод розробки тестів (non-functional test design techniques): Процедура розробки або вибору тестових сценаріїв для нефункціонального тестування, заснована на аналізі специфікації компонента або системи у відриві від його внутрішньої структури.

Обробка винятків (exception handling): Поведінка компонента або системи у випадку неправильних вхідних даних, введених людиною або від іншої компонента або системи, або із-за внутрішнього відмови.

Об'єкт тестування (test object): Компонент або система, які повинні бути протестовані.

Об'ємне тестування (volume testing): Тестування, при якому система випробовується на великих обсягах даних.

Очікуваний результат (expected result): Поведінка компонента або системи при визначених умовах, яке визначено специфікацією або іншими джерелами.

Оснащення засобами контролю (instrumentation): Вставка додаткового коду в програму для збору інформації про поведінку програми під час виконання. Наприклад, для вимірювання покриття коду.

Оцінка витрат на тестування (test estimation): Розрахована апроксимація (наприклад, витрачені зусилля, дата завершення, пов'язані витрати, число тестових сценаріїв, і т.д.), результати якої можуть використовуватися навіть коли вхідні дані неповні, невизначені або неточні.

Оцінка функціональності (functionality testing): Процес тестування для визначення функціональних можливостей програмного продукту.

Парне програмування (pair programming): Підхід до розробки програмного забезпечення, при якому коду (при розробці або тестуванні) пишеться двома програмістами за одним комп 'ютером. По суті це має на увазі безперервні рецензії коду. Парне тестування (pair testing): Двоє людей (двоє тестувальників, розробник і тестувальник, або кінцевий користувач і тестувальник), що працюють разом над пошуком дефектів. Зазвичай вони працюють за одним комп'ютером, протягом роботи передаючи управління один одному.

Перегляд (walkthrough): Покроковий розбір, що проводиться автором документа для збору інформації та забезпечення однакового розуміння змісту документа.

Першопричина (root cause): Джерело дефекту, при видаленні якого частота подібних дефектів скорочується, або ж подібні дефекти зникають повністю.

Переносимість (portability): Легкість, з якою програмний продукт може бути перенесений з одного апаратного або програмного оточення в інше.

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

План фази тестування (phase test plan): План тестування, зазвичай описує одну фазу тестування.

Планування тестування (test planning): Робота зі складання та підтримання актуальності плану тестування.

Повторне тестування (re-testing): Тестування, під час якого виконуються тестові сценарії, які виявили помилки під час останнього запуску, для підтвердження успішності виправлення цих помилок.

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

Підсумковий звіт про тестування (test summary report): Документ, що підводить підсумок завданням і результатами тестування, що також містить оцінку відповідних об'єктів тестування щодо критеріїв виходу.

Підхід до тестування (test approach): Реалізація стратегії тестування для певного проекту. Зазвичай включає в себе висновки, зроблені на основі цілі (тестування) проекту та аналізу ризиків, стартові точки процесу тестування, що застосовуються методики розробки тестів, критерії виходу, типи тестування, які повинні бути проведені.

Покриття (coverage): Рівень, який виражається у відсотках, на який певний елемент покриття був перевірений набором тестів. Покриття LCSAJ (LCSAJ coverage): Відсоток LCSAJ компонента, які були перевірені набором тестів. 100% покриття LCSAJ передбачає 100% покриття альтернатив.

Покриття N-переходів (N-switch coverage): Відсоток послідовностей N +1 переходів, виконаних набором тестів. Покриття альтернатив (decision coverage): Відсоток результатів альтернативи, який був перевірений набором тестів. Стовідсоткове покриття рішень на увазі стовідсоткове покриття гілок і стовідсоткове покриття операторів.

Покриття граничних значень (boundary value coverage):

Відсоток граничних значень, який був перевірений набором тестів. Покриття коду (code coverage): Метод аналізу, що визначає, які частини програмного забезпечення були перевірені (покриті) набором тестів, а які ні, наприклад, покриття операторів, покриття альтернатив або покриття умов.

Покриття множинних умов (multiple condition coverage): Відсоток комбінацій всіх результатів одиночних умов в рамках одного оператора, який був перевірений набором тестів. Стовідсоткове покриття множинних умов означає стовідсоткове покриття визначень умов.

Покриття операторів (statement coverage): Процентне відношення операторів, виконуваних набором тестів, до їх загальної кількості.

Покриття визначень умов (condition determination coverage): Відсоток всіх одиночних результатів умов, незалежно впливають на результати альтернативи, які були перевірені набором сценаріїв тестування. 100% покриття визначень умов має на увазі 100% покриття умов альтернатив.

Покриття потоку даних (data flow coverage): Відсоток пар "визначення-використання ", який був перевірений набором тестів. Покриття шляхів (path coverage): Відсоток шляхів, які були пройдені в процесі виконання набору тестів. 100% покриття шляхів забезпечує 100% покриття LCSAJ.

Покриття умов (condition coverage): Відсоток результатів умов, які були перевірені набором тестів. 100% покриття умов вимагає, щоб кожне окрема умова в кожному вираженні рішення було підтверджено як Істина і Брехня.

Покриття умов альтернатив (decision condition coverage): відсоток всіх результатів умов і покриттів альтернатив, який був перевірений набором тестів. Стовідсоткове покриття умов вирішення на увазі стовідсоткове покриття умов і стовідсоткове покриття альтернатив.

Покриття еквівалентного розбиття (equivalence partition coverage): Відсоток еквівалентних областей, який був перевірений набором тестів.

Політика тестування (test policy): Документ високого рівня, що описує принципи, підхід і основні цілі організації відносно тестування.

Помилка (error): Дія людини, що призводить до неправильного результату.

Попарне тестування (pairwise testing): Розробка тестів методом чорного ящика, в якій тестові сценарії розробляються таким чином, щоб виконати всі можливі окремі комбінації кожної пари вхідних параметрів.

Постачання (deliverable): Будь-який (робочий) продукт, який повинен бути поставлений кому-небудь, відмінному від автора (робочого) проекту.

Потік даних (data flow): Абстрактне представлення послідовності та можливих змін стану об'єктів даних, при якому стан об'єкта це: створення, використання або знищення.

Потік управління (control flow): Послідовність подій (шляхів) у процесі виконання компонента або системи.

Практичність (usability): Зрозумілість, легкість у вивченні і використанні і привабливість програмного продукту для користувача за умови використання в заданих умовах експлуатації.

Припущення про помилки (error guessing): Метод проектування тестів, коли досвід тестувальника використовується для передбачення того, які дефекти можуть бути в тестованому компоненті або систему у результаті зроблених помилок, а також для розробки тестів спеціально для їх виявлення. Прийнятність (suitability): Здатність програмного продукту надавати відповідний функціонал для певних завдань і цілей кінцевого користувача.

Приймальне тестування (acceptance testing): Формальне тестування по відношенню до потреб, вимог і бізнес процесів користувача, що проводиться з метою визначення відповідності системи критеріям приймання.

Пріоритет (priority): Ступінь важливості, що привласнюється об'єкту. Наприклад, дефекту.

Пристосовність (adaptability): Здатність програмного продукту бути адаптованим до різних заданим оточенням без застосування дій або засобів, крім тих, які призначені для цих цілей для даного програмного продукту.

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

Повне тестування (exhaustive testing): Методика тестування, в якій набір тестів включає в себе всі комбінації вхідних даних і передумов.

Працездатність (operability): Здатність программного забезпечення бути доступним у використанні і управлінні для користувача.

Прогін тесту (test run): Виконання тесту на певній версії об'єкта тестування.

Проектування тесту (test design): Процес перекладу загальних вимог до тестування у конкретні тестові умови і тестові сценарії.

Продуктивність (performance): Ступінь, з якою система або компонент виконує закладені в неї функції у встановлених рамках на час обробки та пропускну здатність.

Пройдено (pass): Тест вважається пройденим, якщо його фактичні результати відповідають очікуваним результатам. Порівняння результатів виконання (post-execution comparison): Порівняння реальних і очікуваних результатів, вироблене після закінчення роботи програмного забезпечення.

Порівняльне тестування (back-to-back testing): Тестування, при якому два або більше варіанти компонента або системи виконані з однаковими вхідними значеннями, а результати порівнюються і проаналізовані в якій існують розбіжності.

Протокол тестування (test log): Хронологічний протокол деталей, що стосуються виконання тестів.

Протоколювання тестування (test logging): Процес запису інформації про виконані тестах у протокол тестування. Профілювання продуктивності (performance profiling): Визначення користувальницьких профілів у тестуванні продуктивності, навантажувальні або стресовому тестуванні. Профілі повинні відображати очікуване або реальне використання, грунтуючись на функціональний розріз компонента або системи і, відповідно, очікуваної робочої навантаження.

Профіль навантаження (load profile): Характеристика навантаження, якої тестуєма система або компонент можуть наразитися у процесі експлуатації. Профіль навантаження визначається кількістю віртуальних користувачів, які виконують певний набір операцій в заданий проміжок часу у відповідності з обраним заздалегідь функціональним розрізом.

Процес тестування (test process): Фундаментальний процес тестування охоплює планування тестування, аналіз та дизайн тестів, впровадження та виконання тестів, оцінку досягнення критеріїв виходу і звітність, а також роботи з завершення тестування.

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

Розробка на основі тестів (test driven development): Прийом розробки програмного забезпечення, при якому спочатку

розробляються тестові сценарії, тестування часто автоматизується, і після цього розробляється те програмне забезпечення, яке буде використовувати ці тестові сценарії. Розробка тестів методом білого ящика (white box test design technique): Процедура розробки або вибору тестових сценаріїв на підставі аналізу внутрішньої структури компонента або системи. Розробка тестів методом чорного ящика (black box test design technique): Процедура створення та / або вибору тестових сценаріїв, заснована на аналізі функціональної або нефункціональній специфікації компонента або системи без знання внутрішньої структури.

Розклад виконання тестів (test execution schedule): Схема виконання тестових процедур. Тестові процедури включаються до розкладу виконання тестів виходячи з контексту тестування й у тому порядку, в якому вони повинні виконуватися.

Реалізація тесту (test implementation): Процес розробки і розстановки пріоритетів процедурам тестування, створення тестових даних і, опціонально, підготовка тестової обв'язки і написання автоматичних процедур тестування.

Реєстрація інцидентів (incident logging): Запис деталей будь- якого інциденту, що стався, наприклад, під час тестування. Регресійне тестування (regression testing): Тестування вже протестованої програми, що проводиться після модифікації для впевненості в тому, що процес модифікації не вніс або не активізував помилки в областях, що не піддавалися змінам. Проводиться після змін в коді програмного продукту або його оточення.

Результат (result): Результат виконання тесту. У результат можуть входити всі види інформації на екрані, зміни у даних, звіти, надіслані повідомлення.

Результат альтернативи (decision outcome): Результат альтернативи (який, таким чином, визначає гілки, які повинні бути обрані).

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

Рецензування (review): Оцінка стану продукту або проекту з метою встановлення розбіжностей із запланованими результатами та для висунення пропозицій щодо поліпшення. Прикладами рецензування можуть служити: управлінське рецензування, неформальне рецензування, технічний аналіз, інспекція і розбір.

Рівень відмов (failure rate): Відношення кількості відмов даної категорії до заданої одиниці виміру, наприклад, відмова в одиницю часу, кількість відмов у транзакціях, кількість відмов до кількості запусків.

Рівень ризику (risk level): Важливість ризику визначається за його характеристиками: вплив і ймовірність. Рівень ризику може бути використаний для визначення інтенсивності тестування. Рівень ризику може бути виражений як якісно (наприклад: високий, середній, низький), так і кількісно.

Рівень тестування (test level): Об'єднана і спільно керована група завдань тестування. Рівень тестування пов'язаний з областями відповідальності у проекті. Прикладами рівнів тестування можуть служити Компонентне тестування, інтеграційне тестування, системне тестування і приймальне тестування. Рівневий план тестування (level test plan): План тестування, зазвичай відноситься до одного рівня тестування.

Ризик (risk): Фактор, який може призвести до негативних наслідків в майбутньому, зазвичай виражається через імовірність і вплив.

Ризик продукту (product risk): Ризик, безпосередньо пов'язаний з об'єктом тестування.

Ризик проекту (project risk): Ризик, що відноситься до управління та контролю проектом або тестуванням у проекті. Наприклад: брак персоналу, жорсткі терміни закінчення, зміни вимог, і т.д. Керівник тестування (test manager): Людина, відповідальний за управління ресурсами і роботами з тестування, а також за експертизу тестового об'єкта. Направляє, контролює, адмініструє, планує і регулює експертизу

Ручна імітація роботи програми (desk checking): Тестування програмного забезпечення або специфікацій допомогою ручної емуляції їх виконання на випробувальному стенді.

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

Сертифікація (certification): Процес підтвердження того, що компонент, система або особа відповідає пропонованим вимогами, наприклад, шляхом здачі іспиту.

Сесія тестування (test session): Безперервний проміжок часу, під час якого виконуються тести. У дослідницькому тестуванні кожна сесія тестування грунтується на концепції тестування, але тестувальники також можуть досліджувати нові можливості або проблеми під час сесії. Тестувальник створює і використовує тестовий сценарій на льоту і записує динаміку. Синтаксичне тестування (syntax testing): Розробка тестів методом чорного ящика, в якій тестові сценарії будуються на основі області визначення вхідних та /або вихідних значень. Система з особливими вимогами до забезпечення безпеки (safety critical system): Система, збій або некоректна робота якої може привести до людської загибелі або збитку здоров'ю, бізнесу, програмами, власності або навколишньому середовищу.

Системне інтеграційне тестування (system integration testing): Тестування інтеграції систем і пакетів програм, тестування інтерфейсів зв'язку із зовнішніми системами (інтернет і т.д.). Системне тестування (system testing): Процес тестування системи в цілому з метою перевірки того, що вона відповідає встановленим вимогам.

Складність (complexity): Рівень, на якому компонент або система спроектовані та / або мають внутрішню структуру складну для розуміючи, підтримки та перевірки.

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

Сопроводжуваність (maintainability): Легкість зміни програмного продукту для виправлення дефектів, для відповідності новим вимогам, з метою полегшення подальшого супроводу або для адаптації до змінених оточенню.

Супровід (maintenance): Модифікація програмного продукту після його постачання з метою виправлення дефектів, поліпшення продуктивності або інших характеристик або для адаптації продукту до змінити оточення.

Співіснування (co-existence): Здатність програмного продукту співіснувати з іншим незалежним програмним забезпеченням у загальному оточенні, розділяючи загальні ресурси.

Специфікація (specification): Документ, що описує вимоги, дизайн, поведінку або інші характеристики компонента або системи. Найчастіше в специфікацію включаються процедури контролю виконання.

Специфікація компонента (component specification): Опис функцій компонента в термінах його вихідних значень для заданих вхідних значень за певних умов, а також необхідного нефункціонального поведінки (наприклад, використання ресурсів).

Специфікація проектування тесту (test design specification): Документ, що описує тестове умова (елементи покриття) для елемента тестування, деталізований підхід до тестування, і що ідентифікує відповідні тестові сценарії високого рівня.

Специфікація процедури тестування (test procedure specification): Документ, що описує послідовність дій при виконанні тесту. Також відомий як ручний сценарій тестування.

Специфікація тесту (test specification): Документ, що складається з специфікації проектування тесту, специфікації тестових сценаріїв та / або специфікації процедури тестування. Специфікація тестових сценаріїв (test case specification): Документ, що описує комплект тестових сценаріїв - мета, входи, тестові операції, очікувані результати та передумови виконання для об'єкта тестування.

Стабільність (stability): Здатність програмного продукту уникати непередбачених наслідків модифікації програмного коду.

Статистичне тестування (statistical testing): Методика розробки тестів, в якій модель статистичного розподілу ймовірності входять значень використовується для створення репрезентативних сценаріїв тестування.

Статичний аналіз (static analysis): Аналіз програмних артефактів, таких як вимоги або програмний код, що проводиться без виконання цих програмних артефактів.

Статичний аналіз коду (static code analysis): Аналіз вихідного коду, вироблений без його виконання.

Статичний аналізатор коду (static code analyzer): Інструмент, що забезпечує статичний аналіз коду. Даний інструмент перевіряє властивості вихідний коду, такі як відповідність стандартам оформлення коду, параметри якості або відхилення потоків даних. Статичне тестування (static testing): Тестування компонента або системи на рівні специфікації або реалізації без виконання коду програмного продукту, наприклад рецензування або статичний аналіз коду.

Стійкість (robustness): Рівень, до якого компонент або система може функціонувати коректно при наявності некоректних вхідних даних або функціонування в стресових умовах.

Стійкість до помилок (error tolerance): Здатність системи або компонента продовжувати нормально функціонувати, незважаючи на присутність неправильних вхідних даних.

Стійкість до недоліків (fault tolerance): Здатність програмного продукту підтримувати певний рівень продуктивності в разі

програмних недоліків (дефектів) або порушенні встановленого інтерфейсу взаємодії.

Стратегія тестування (test strategy): Високорівневі опис рівнів тестування, які повинні бути виконані, і тестування, що входить до ці рівні, для організації або програми з одного чи більше проектів.

Стресове тестування (stress testing): Вид тестування продуктивності, що оцінює систему або компонент на граничних значеннях робочих навантажень або за їх межами, або ж у стані обмежених ресурсів, таких як пам'ять або доступ до сервера. Структурне покриття (structural coverage): Метрики покриття, засновані на внутрішній структурі компонента або системи.

Таблиця рішень (decision table): Таблиця, що відображає комбінації вхідних даних і / або причин з відповідними вихідними даними та / або дій (наслідків), яка може бути використана для проектування тестових сценаріїв.

Таблиця станів (state table): Таблиця, що показує кінцеві переходи для кожного стану внаслідок кожного можливого події, як для коректних, так і для некоректних переходів.

Тест (test): Набір з одного або декількох тестових сценаріїв.

Тест ”на дим” (smoke test): Вибірка із загального числа запланованих тестових сценаріїв, що покриває основну функціональність компонента або системи. Проводиться з метою упевнитися, що базові функції програми в цілому працюють коректно, без поглиблення в деталі. Щоденна збірка і тест "на дим " є передовими практичними методами.

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

Тестування "зверху вниз” (top-down testing): інкрементального підхід до інтеграційного тестування, у якому компоненти з верхнього рівня ієрархії об'єктів тестуються в першу чергу, з використанням заглушок замість компонентів більш низького рівня. Протестовані компоненти використовуються для тестування компонентів більш низького рівня і даний процес повторюється до тих пір, поки не буде протестовано компоненти самого нижчого рівня.

Тестування LCSAJ (LCSAJ testing): Розробка тестів методом білого ящика, в якому тестові сценарії розробляються для перевірки LCSAJ.

Тестування N-переходів (N-switch testing): Вид тестування таблиці переходів, в якому тестові сценарії розробляються для виконання всіх правильних послідовностей N +1 переходів. Тестування безпеки (safety testing): Тестування програмного продукту з метою з метою визначити його безпеку.

Тестування бізнес-циклів (process cycle test): Розробка тестів методом чорного ящика, в якій тестові сценарії розробляються для виконання бізнес-процедур і процесів.

Тестування на витримку навантаження (load test): Тип тестування продуктивності, що проводиться з метою оцінки поведінки компонента або системи при зростаючій навантаженні, наприклад кількості паралельних користувачів і / або операцій, а також визначення яке навантаження може витримати компонент або система.

Тестування відновлюваності (recoverability testing): Процес тестування, який досліджує відновлюваність програмного продукту.

Тестування документації (documentation testing): Тестування якості документації, наприклад керівництва користувача або керівництва по встановленню.

Тестування доступності (accessibility testing): Тестування, яке визначає ступінь легкості, з якою користувачі з обмеженими здібностями можуть використовувати систему або її компоненти.

Тестування захищеності (security testing): Тестування з метою оцінити захищеність програмного продукту.

Тестування інтеграції компонентів (component integration testing): Тестування, яке виконується для виявлення дефектів в інтерфейсах та взаємодію між інтегрованими компонентами. Тестування інтерфейсу (interface testing): Тип інтеграційного тестування, пов'язаний з тестуванням інтерфейсів між компонентами або системами.

Тестування використання ресурсів (resource utilization testing): Процес тестування, який досліджує використання ресурсів програмним продуктом.

Тестування масштабованості (scalability testing): Тестування з метою оцінити масштабованість програмного продукту. Тестування методом білого ящика (white box testing): Тестування, засноване на аналізі внутрішньої структури компонента або системи.

Тестування методом чорного ящика (black box testing): Тестування, функціональне або нефункціональне, без знання внутрішньої структури компонента або системи.

Тестування множинних умов (multiple condition testing): розробка тестів методом білого ящика, в якому тестові сценарії розробляються для перевірки комбінацій результатів одиночних умов (у рамках одного оператора).

Тестування мутацій (mutation testing): Тестування, при якому два або більше варіанти компонента або системи виконані з однаковими вхідними значеннями, а результати порівнюються і проаналізовані в якій існують розбіжності.

Тестування на основі архітектури (design-based testing): Підхід до тестування, в якому тестові сценарії розробляються на основі архітектури та / або докладного проекту компонента або системи (наприклад, тестування інтерфейсів між компонентами або системами).

Тестування на основі бізнес-процесів (business process-based testing): Метод тестування, в якому тестові сценарії проектуються на підставі описів і /або знаннях бізнес-процесів. Тестування на основі даних (data driven testing): методика написання автоматизованих тестових сценаріїв, при якій вхідні тестові дані та очікувані результати зберігаються в таблицях, таким чином, що окремий сценарій може виконати всі тести в таблиці. Тестування на основі даних часто використовується для підтримки засобів виконання тестів, таких як засіб захоплення / відтворення.

Тестування на основі ключових слів (keyword driven testing): Артефакти, що утворюються під час процесу тестування і що вимагаються для планування, розробки і виконання тестів. Наприклад: документація, сценарії, входи, очікувані результати, процедури установки і видалення, файли, бази даних, оточення і будь-яке інше додаткове програмне забезпечення або інструменти, які використовуються в тестуванні.

Тестування на основі вимог (requirements-based testing): Підхід до тестування, при якому тестові сценарії розробляються на основі цілей і умов тестування, що випливають з вимог; тобто тести, що перевіряють певний функціонал або оцінюючі нефункціональні атрибути системи, такі як надійність або практичність. Тестування надійності (reliability testing): Процес тестування, який досліджує надійність програмного продукту.

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

Тестування операторів (statement testing): Розробка тестів методом білого ящика, в якому набори тестів складаються з метою виконання операторів.

Тестування визначень умов (condition determination testing): Розробка тестів методом білого ящика, в якому тестові сценарії розробляються для перевірки одиночних результатів умов, які незалежно впливають на результат альтернатив.

Тестування переносимості (portability testing): Процес тестування з метою визначити переносимість програмного продукту.

Тестування за сценаріями використання (use case testing): Розробка тестів методом чорного ящика, в якому тестові сценарії створюються для виконання сценаріїв використання. Тестування потоків даних (data flow testing): Розробка тестів методом білого ящика, в якому тестові сценарії проектуються для перевірки пари "визначення-використання " для змінних.

Тестування практичності (usability testing): Тестування з метою визначення ступеня зрозумілості, легкості у вивченні і використанні, привабливості програмного продукту для користувача за умови використання в заданих умовах експлуатації.

Тестування продуктивності (performance testing): Процес тестування з метою визначити продуктивність програмного продукту.

Тестування шляхів (path testing): Розробка тестів методом білого ящика, в якому тести створюються для перевірки шляху.

Тестування розробки (development testing): Формальне або неформальне тестування, що проводиться під час реалізації компоненту або системи, зазвичай у середовищі розробників.

Тестування альтернатив (decision testing): Розробка тестів методом білого ящика, в якому тестові сценарії проектуються для перевірки результатів альтернативи.

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

Тестування відповідності (compliance testing): Процес тестування для визначення відповідності компонента або системи.

Тестування таблиці переходів (state transition testing): Розробка тестів методом чорного ящика, в якому сценарії тестування будуються на основі виконання коректних і некоректних переходів станів.

Тестування таблиці рішень (decision table testing): Розробка тестів методом чорного ящика, в якому тестові сценарії проектуються для перевірки комбінацій вхідних даних і / або причин, відображених у таблиці рішень.

Тестування умов (condition testing): Розробка тестів методом білого ящика, в якому тестові сценарії розробляються для перевірки результатів умов.

Тестування умов альтернатив (decision condition testing): Розробка тестів методом білого ящика, в якому тестові сценарії проектуються для результатів умов і результатів альтернатив. Тестування стійкості (robustness testing): Процес тестування, який досліджує стійкість програмного продукту.

Тестування функціонального розрізу (operational profile testing): Статистичне тестування, що використовує модель системних

операцій (короткочасні операції) і ймовірність їх типового використання.

Тестування цілісності бази даних (database integrity testing): Тестування методів і процесів, які застосовуються для доступу і управління даними, для посвідчення в тому, що методи, процеси і правила доступу працюють вірно, а також, що під час доступу до бази даних дані не пошкоджені або несподівано видалені, оновлення або створені.

Тестування ефективності (efficiency testing): Процес тестування для встановлення ефективності програмного продукту.

Тестування, засноване на ризиках (risk-based testing): Підхід до тестування з метою мінімізірованія рівня проектних ризиків та інформування зацікавлених осіб про поточний стан ризиків з початкових стадій проекту. Має на увазі під собою керування процесом тестування, виходячи з ідентифікованих ризиків продукту.

Тестування процесів (procedure testing): Тестування, націлене на підтвердження того, що компонент або система функціонують відповідно до нових або наявними користувацькими бізнес-або технологічними процесами.

Тестувальник (tester): Досвідчений фахівець, що бере участь у тестуванні компонента або системи.

Тестуємість (testability): Здатність програмного продукту щодо можливості для тестування внесених змін.

Тестове забезпечення (testware): Артефакти, що утворюються під час процесу тестування і що вимагаються для планування, розробки і виконання тестів. Наприклад: документація, сценарії, входи, очікувані результати, процедури установки і видалення, файли, бази даних, оточення і будь-яке інше додаткове програмне забезпечення або інструменти, які використовуються у тестуванні.

Тестове оточення (test environment): Оточення, що включає в себе апаратне забезпечення, вимірювальну апаратуру, імітатори, програмний інструментарій та інші інструменти, необхідні для проведення тесту.

Тестова умова (test condition): Об'єкт або подія в компоненті або системі, яка має бути підтверджено одним або кількома тестовими наборами. Наприклад: функція, транзакція, властивість, атрибут якості або структурний елемент.

Тестові дані (test data): Дані, які існують (наприклад, в базі даних) на початок виконання тесту і впливають на роботу, або ж зазнають впливу з боку тестованої системи або компонента. Тестовий компаратор (test comparator): Інструмент тестування, що здійснює автоматичне порівняння реального та очікуваного результату.

Тестовий оракул (test oracle): Джерело, за допомогою якого можна визначити очікувані результати для порівняння з реальними результатами, що видаються тестованої системою. У ролі тестового оракула можуть виступати вже наявна система (для еталонного тестування), керівництво користувача, професійні знання фахівця, однак їм не може бути програмний код. Тестовий сценарій (test case): Набір вхідних значень, передумов виконання, очікуваних результатів і постусловій виконання, розроблений для певної мети або тестового умови, таких як виконання певного шляху програми або ж для перевірки відповідності певним вимогам.

Тестовий сценарій високого рівня (high level test case): Тестовий сценарій без конкретних (рівня реалізації) значень вхідних даних і очікуваних результатів. Використовує логічні оператори, а екземпляри реальних значень ще не визначені і /або доступні. Тестовий сценарій низького рівня (low level test case): Тестовий сценарій з конкретними (рівня реалізації) значеннями вхідних даних та очікуваних результатів. Логічні оператори з тестових сценаріїв високого рівня замінюються реальними значеннями, які відповідають цілям цих логічних операторів.

Технічний аналіз (technical review): Обговорення, яке має на меті виробити єдиний підхід до технічного процесу, і що проводиться рівноправними учасниками.

Тип ризику (risk type): Певна категорія ризиків стосовно до типів тестування, здатним пом'якшити або контролювати це категорію ризиків. Наприклад, ризик неправильного розуміння взаємодії з користувачем може бути пом'якшений за допомогою тестування практичності.

Тип тестування (test type): Група процесів тестування, спрямованих на тестування компонента або системи з певною метою, наприклад, функціональне тестування, тестування практичності, регресійного тестування і т.д. Один і той же тип тестування може зустрічатися в одному або декількох рівнях тестування або фазах тестування.

Точність (accuracy): Здатність програмного продукту забезпечувати правильні або узгоджені результати або дії з необхідним рівнем точності.

Управління дефектами (defect management): Процес розпізнавання, дослідження, прийняття дій і усунення дефектів. Він включає в себе фіксування дефектів, їх класифікацію і виявлення наслідків.

Управління інцидентами (incident management): Процес розпізнавання, дослідження, прийняття дій та усунення інцидентів. Включає в себе протоколювання інцидентів, їх класифікацію і визначення впливу.

Управління конфігурацією (configuration management): Наука, яка застосовує технічне та адміністративне керівництво і контроль для: ідентифікації та документування функціональних і фізичних характеристик елемента конфігурації, контролю змін цих характеристик, записи і звітності про стан процесу впровадження змін, а також перевірки сумісності з заданими вимогами.

Управління ризиками (risk management): Систематичне використання процедур і практик з метою ідентифікації, аналізу, визначення пріоритетів та контролю ризиків.

Управління тестуванням (test management): Планування, оцінка, моніторинг і контроль тестових активностей, зазвичай виконуються керівником тестування.

Управлінське рецензування (management review): Систематична оцінка процесу придбання, підтримки, розробки, експлуатації або супроводу програмного забезпечення, що виконується керівництвом або від імені керівництва, контролюючого хід робіт, що визначає стан планів і графіків, що підтверджує вимоги і їх місце в системі, або що оцінює ефективність управлінських підходів для досягнення цілей.

Удосконалення процесів (process improvement): Програма дій, націлена на поліпшення продуктивності і зрілості організаційних процесів, і результат такої програми.

Удосконалення процесу тестування (Test Process Improvement (TPI)): Безперервна структура вдосконалення процесу тестування, що описує ключові елементи ефективного процесу тестування, фокусуючись в першу чергу на системному та приймальному тестуванні.

Фаза виконання тестів (test execution phase): Період в циклі розробки програмного забезпечення, під час якого програмний продукт або його компоненти запускаються, і програмний продукт оцінюється з точки зору виконання пред'явлених до нього вимог.

Фаза тестування (test phase): Певний набір завдань, об'єднаних в контрольовану фазу проекту, наприклад, завдання виконання рівня тестування.

Фактичний результат (actual result): Спостережуване або генерується поведінку компонента або системи під час тестування.

Формальне рецензування (formal review): Рецензування, що характеризується документовані процедурами та вимогами, наприклад, інспекція.

Функціональна інтеграція (functional integration): Підхід до інтеграції, який об'єднує компоненти або системи для отримання якомога раніше початкової робочої функціональності. Функціональне тестування (functional testing): Тестування, засноване на аналізі специфікації функціональності компонента або системи.

Функціональна вимога (functional requirement): Вимога, що визначає функцію, яку компонент або система повинні виконувати. Функціональність (functionality): Здатність программного продукту забезпечувати функції, які відповідають встановленим і передбачуваним потребам, при використанні ПЗ в певних умовах. Функціональний розріз (operational profile): Подання особливого безлічі завдань, що виконуються компонентом чи системою, можливо спираються на поведінку користувача при взаємодії з компонентом чи системою, із зазначенням ймовірності їхньої появи. Описувані завдання частіше логічні, ніж фізичні, і можуть виконуватися на різних машинах в незалежні періоди часу.

Хаотичне тестування (monkey testing): Тестування випадковим вибором з великого діапазону входів, випадковим натисканням кнопок, без співвіднесення з тим, як в реальності використовуватися система.

Цілісність (consistency): Рівень однорідності, стандартізованності і відсутності суперечливості у документах або частинах компонента або системи.

Мета тестування (test objective, test target): Причина або мета розробки та виконання тесту, набір критеріїв виходу.

Цикл тестування (test cycle): Виконання процесу тестування для однієї однозначно визначається версії тестованого об'єкта. Цикломатична складність (cyclomatic complexity): кількість незалежних шляхів в програмі.

Шлях (path): Послідовність подій (наприклад, виконуваних операторів) в компоненті або системі від точки входу до точки виходу.

Шлях аудиту (audit trail): Шлях, за яким початкова інформація на вході процесу (наприклад, дані) може бути на основі вихідних результатів процесу, беручи вихідні дані процесу в якості стартовою точки. Це полегшує аналіз дефектів і дозволяє провести аудит процесу.

Щільність дефектів (defect density): Кількість дефектів, виявлених в компоненті або системі, поділене на розмір компонента або системи (виражений у стандартних одиницях вимірювання, наприклад рядках коду, зокрема класів або функцій).

Якість програмного забезпечення (software quality): Сума функціональності і властивостей програмного продукту, що впливають на його здатність задовольнити сформульовані або імпліцитне потреби.