Умови тестування програмного забезпечення - повний глосарій

software testing terms complete glossary

Щоб уникнути двозначності в різних термінах тестування програмного забезпечення, я додаю a глосарій тестування програмного забезпечення тут.

Усі умови тестування програмного забезпечення включені до цього глосарію. Якщо ви відчуваєте, що знаєте визначення будь-якого терміна краще, ніж згадане тут, ви можете використати це Контактний формуляр надіслати мені визначення. Під час огляду я включу їх до цього списку глосарію.

Щоб знати основні визначення тестування програмного забезпечення та забезпечення якості, це найкращий глосарій, складений Ерік ван Венендаал . Також для кожного визначення є посилання на IEEE або ISO, згадані в дужках.

ДО

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

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

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

точність: Здатність програмного продукту забезпечувати правильні або узгоджені результати чи ефекти з необхідним ступенем точності. (ISO 9126) Див. Також тестування функціональності.

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

спеціальне тестування: Тестування проводиться неофіційно; не проводиться офіційна підготовка до тесту, не використовується визнана техніка проектування тесту, немає очікувань на результати та випадковість керує діяльністю виконання тесту.

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

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

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

аналітичність: Можливість діагностування програмного продукту на предмет недоліків або причин несправностей у програмному забезпеченні або для виявлення деталей, що підлягають модифікації. (ISO 9126) Див. Також тестування на ремонтопридатність.

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

привабливість: Здатність програмного продукту бути привабливим для користувача. (ISO 9126)

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

(1) форма або зміст продукції, що виробляється

(2) процес виробництва продукту

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

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

автоматизоване програмне забезпечення: Тестове програмне забезпечення, що використовується в автоматизованому тестуванні, наприклад, скрипти інструментів.

наявність: Ступінь функціонування компонента або системи та доступності, коли це потрібно для використання. Часто виражається у відсотках. (IEEE 610)

B

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

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

основний блок: Послідовність одного або декількох послідовних виконуваних операторів, що не містять гілок.

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

поведінка: Реакція компонента або системи на набір вхідних значень та передумов.

контрольний тест: (1) Стандарт, за яким можна проводити вимірювання або порівняння. (2) Тест, який використовується для порівняння компонентів або систем між собою або зі стандартом, як у (1). (Після IEEE 610)

програмне забезпечення на замовлення: Програмне забезпечення, розроблене спеціально для набору користувачів або клієнтів. Навпаки - готове програмне забезпечення.

найкраща практика: Вищий метод або інноваційна практика, що сприяє поліпшенню ефективності діяльності організації в певному контексті, яку зазвичай визнають 'найкращою' інші організації-партнери.

бета-тестування: Оперативне тестування потенційними та / або існуючими користувачами / клієнтами на зовнішньому сайті, який не пов'язаний з розробниками, з метою визначення того, відповідає компонент або система потребам користувачів / клієнтів чи вписується в бізнес-процеси. Бета-тестування часто застосовується як форма зовнішнього приймального тестування з метою отримання зворотного зв'язку з ринком.

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

тестування чорної скриньки: Тестування, функціональне чи нефункціональне, без посилання на внутрішню структуру компонента або системи.

техніка проектування тестів чорної скриньки: Документована процедура виведення та відбору тестових випадків на основі аналізу специфікації, функціональної чи нефункціональної, компонента чи системи без посилання на її внутрішню структуру.

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

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

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

аналіз граничного значення: Техніка проектування тестів чорної скриньки, при якій тестові кейси розробляються на основі граничних значень.

охоплення граничного значення: Відсоток граничних значень, які були використані набором тестів.

відділення: Основний блок, який можна вибрати для виконання на основі конструктора програми, в якому доступний один із двох або більше альтернативних шляхів програми, наприклад випадок, стрибок, перехід до, якщо-ще.

охоплення філій: Відсоток гілок, які були використані набором тестів. 100% охоплення філій передбачає як 100% покриття рішень, так і 100% висвітлення.

тестування галузі: Техніка проектування тестів на білу скриньку, в якій тестові кейси призначені для виконання гілок.

тестування на основі бізнес-процесів: Підхід до тестування, в якому тестові кейси розробляються на основі описів та / або знань про бізнес-процеси.

C.

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

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

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

СПРАВА: Скорочення від Computer Aided Software Engineering.

АКТЕРИ: Скорочення від Computer Aided Software Testing. Див. Також автоматизацію тестування.

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

графік причинно-наслідкових наслідків: Техніка проектування тестів чорної скриньки, в якій тестові кейси розробляються на основі графіків причинно-наслідкових наслідків. (BS 7925/2)

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

мінливість: Можливість програмного продукту забезпечити можливість впровадження певних модифікацій. (ISO 9126) Див. Також ремонтопридатність.

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

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

співіснування: Здатність програмного продукту співіснувати з іншим незалежним програмним забезпеченням у загальному середовищі, спільно використовуючи спільні ресурси. (ISO 9126) Див. Тестування на портативність.

складність: Ступінь, в якій компонент або система має конструкцію та / або внутрішню структуру, яку важко зрозуміти, підтримати та перевірити. Див. Також цикломатичну складність.

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

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

компонент: Мінімальний елемент програмного забезпечення, який можна перевірити ізольовано.

тестування інтеграції компонентів: Випробовування для виявлення дефектів інтерфейсів та взаємодії між інтегрованими компонентами.

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

тестування компонентів: Тестування окремих програмних компонентів. (Після IEEE 610)

складний стан: Дві або більше одинарних умов, об’єднаних за допомогою логічного оператора (AND, OR або XOR), наприклад „A> B І C> 1000“.

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

хвороба: Логічний вираз, який можна оцінити як True або False, напр. A> B. Див. Також стан тесту.

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

Покриття визначення стану: Відсоток усіх результатів одиничних станів, які незалежно впливають на результат рішення, який застосовувався набором тестових випадків. 100% покриття умови визначення передбачає 100% покриття умови прийняття рішень.

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

тестування стану: Техніка дизайну тестів білих коробок, в якій тестові кейси призначені для виконання результатів стану.

результат стану: Оцінка стану як істинного чи хибного.

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

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

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

610)

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

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

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

консистенція: Ступінь однорідності, стандартизованості та позбавлення від суперечностей між документами чи частинами компонента чи системи. (IEEE 610)

управління потоком: Абстрактне представлення всіх можливих послідовностей подій (шляхів) у виконанні через компонент або систему.

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

ЛІГИ: Скорочення від комерційного програмного забезпечення.

охоплення: Ступінь, виражена у відсотках, до якої визначений предмет покриття був використаний набором тестів.

аналіз охоплення: Вимірювання досягнутого покриття до певного елементу охоплення під час виконання тесту, посилаючись на заздалегідь визначені критерії, щоб визначити, чи потрібно додаткове тестування, і якщо так, то які тестові випадки потрібні.

пункт покриття: Суб’єкт або властивість, що використовується як основа для тестового покриття, напр. розділи еквівалентності або оператори коду.

інструмент охоплення: Інструмент, який забезпечує об’єктивні виміри того, які структурні елементи, напр. твердження, гілки були здійснені набором тестів.

цикломатична складність: Кількість незалежних шляхів через програму. Цикломатична складність визначається як: L - N + 2P, де -L = кількість ребер / посилань у графіку -N = кількість вузлів у графіку - P = кількість від'єднаних частин графіка (наприклад, викликаючий графік і підпрограма). (Після Маккейба)

D

визначення даних: Виконуваний оператор, де змінної присвоюється значення.

тестування на основі даних: Техніка сценаріїв, яка зберігає вхідні дані тесту та очікувані результати в таблиці або таблиці, так що один скрипт управління може виконувати всі тести в таблиці. Тестування на основі даних часто використовується для підтримки застосування інструментів виконання тестів, таких як інструменти збору / відтворення. (Fewster and Graham) Див. Також тестування на основі ключових слів.

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

аналіз потоку даних: Форма статичного аналізу на основі визначення та використання змінних.

охоплення потоку даних: Відсоток пар використання визначення, які були використані набором тестових кейсів.

перевірка потоку даних: Техніка проектування тестів білого поля, в якій тестові кейси призначені для виконання визначення та використання пар змінних.

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

інструмент налагодження: Інструмент, що використовується програмістами для відтворення несправностей, дослідження стану програм та пошуку відповідного дефекту. Налагоджувачі дозволяють програмістам виконувати програми поетапно, зупиняти програму в будь-якому програмному операторі та встановлювати та досліджувати змінні програми.

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

Покриття умови прийняття рішення: Відсоток усіх результатів стану та результатів рішення, які були використані набором тестів. 100% охоплення рішень передбачає як 100% покриття умов, так і 100% покриття рішень.

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

висвітлення рішення: Відсоток результатів рішень, здійснених набором тестів. 100% охоплення рішень передбачає як 100% покриття філій, так і 100% висвітлення.

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

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

тестування рішень: Техніка проектування білих скриньок, при якій тестові кейси призначені для виконання результатів рішення.

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

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

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

Відсоток виявлення дефектів (DDP): кількість дефектів, виявлених фазою випробування, поділена на кількість виявлених фазою випробувань та будь-якими іншими засобами після.

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

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

маскування дефектів: Поява, при якій один дефект перешкоджає виявленню іншого. (Після IEEE 610)

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

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

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

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

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

тестування документації: Перевірка якості документації, напр. посібник користувача чи посібник із встановлення.

домен: Набір, з якого можна вибрати дійсні вхідні та / або вихідні значення.

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

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

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

динамічне тестування: Тестування, що передбачає виконання програмного забезпечення компонента або системи.

Є

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

тестування ефективності: Процес тестування для визначення ефективності програмного продукту.

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

емулятор: Пристрій, комп’ютерна програма або система, яка приймає однакові входи та виробляє ті самі виходи, що і дана система. (IEEE 610) Див. Також симулятор.

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

точка входу: Перший виконуваний оператор усередині компонента.

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

покриття розділу еквівалентності: Відсоток розділів еквівалентності, які були здійснені набором тестів.

розділення еквівалентності: Техніка проектування тестів чорної скриньки, в якій тестові кейси призначені для виконання представників із розділів еквівалентності. В принципі тестові кейси призначені для охоплення кожного розділу принаймні один раз.

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

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

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

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

обробка винятків: Поведінка компонента або системи у відповідь на помилкове введення або від користувача користувача, або від іншого компонента чи системи, або на внутрішню несправність.

виконуваний оператор: Оператор, який під час компіляції перекладається в об'єктний код і виконується процедурно під час запуску програми і може виконувати дію над даними.

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

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

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

точка виходу: Останній виконуваний оператор усередині компонента.

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

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

F

Помилка: Тест вважається невдалим, якщо його фактичний результат не відповідає очікуваному.

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

режим відмови: Фізичний або функціональний прояв невдачі. Наприклад, система в режимі відмови може характеризуватися повільною роботою, неправильними виходами або повним припиненням виконання.

Аналіз режиму несправності та ефекту (FMEA): Систематичний підхід до виявлення ризиків та аналізу виявлення можливих способів відмов та спроби запобігти їх виникненню.

коефіцієнт відмов: Відношення кількості відмов даної категорії до даної одиниці виміру, напр. відмови за одиницю часу, відмови за кількість транзакцій, відмови за кількість запусків комп'ютера. (IEEE 610)

відмовостійкість: Здатність програмного продукту підтримувати заданий рівень продуктивності у випадках несправностей (дефектів) програмного забезпечення або порушень зазначеного інтерфейсу. (ISO 9126) Див. Також надійність.

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

можливий шлях: Шлях, для якого існує набір вхідних значень та передумов, що призводить до його виконання.

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

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

офіційний огляд: Огляд, що характеризується задокументованими процедурами та вимогами, напр. перевірка.

заморожена основа тесту: Документ на основі випробувань, який може бути змінений лише офіційним контролем змін. Див. Також базовий рівень.

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

функціональна інтеграція: Інтеграційний підхід, який поєднує компоненти або системи з метою отримання базової функціональної можливості на ранній стадії. Див. Також інтеграційне тестування.

функціональна вимога: Вимога, яка визначає функцію, яку повинен виконувати компонент або система. (IEEE 610)

техніка проектування функціонального тесту: Документована процедура виведення та відбору тестових випадків на основі аналізу специфікації функціональності компонента чи системи без посилання на її внутрішню структуру. Див. Також техніку проектування тестів чорних ящиків.

функціональне тестування: Тестування на основі аналізу специфікації функціональності компонента або системи. Див. Також тестування чорних ящиків.

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

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

G

тестування скляної коробки: Див. Тестування білого ящика.

H

евристична оцінка: Метод статичного тестування на зручність використання для визначення відповідності користувальницького інтерфейсу визнаним принципам юзабіліті (так звана «евристика»).

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

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

Я

аналіз впливу: Оцінка змін до рівнів розробницької документації, випробувальної документації та компонентів, з метою впровадження даної зміни до визначених вимог.

поступова модель розвитку: Життєвий цикл розробки, коли проект розбивається на ряд кроків, кожен з яких забезпечує частину функціональних можливостей у загальних вимогах проекту. Вимоги визначені пріоритетними та доставляються у пріоритетному порядку з відповідним кроком. У деяких (але не у всіх) версіях цієї моделі життєвого циклу кожен підпроект слідує за «міні-V-моделлю» зі своїм етапом проектування, кодування та тестування.

додаткове тестування: Випробування, де компоненти або системи інтегровані та тестуються по одній або декількох за раз, поки всі компоненти або системи не будуть інтегровані та випробувані.

інцидент: Будь-яка подія, що трапляється під час тестування, що вимагає розслідування. (Після IEEE 1008)

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

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

звіт про інцидент: Документ, що повідомляє про будь-яку подію, яка відбувається під час тестування, що вимагає розслідування. (Після IEEE 829)

незалежність: Поділ обов’язків, що спонукає до об’єктивного тестування. (Після DO-178b)

нездійсненний шлях: Шлях, який не може бути здійснений будь-яким набором можливих вхідних значень.

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

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

вхідний домен: Набір, з якого можна вибрати дійсні вхідні значення. Див. Також домен.

вхідне значення: Екземпляр введення. Див. Також введення.

огляд: Тип огляду, який покладається на візуальний огляд документів для виявлення дефектів, наприклад порушення стандартів розробки та невідповідність документації вищого рівня. Найбільш офіційна техніка перегляду, і тому завжди базується на задокументованій процедурі. (Після IEEE 610, IEEE 1028)

можливість встановлення: Можливість встановлення програмного продукту у визначеному середовищі (ISO 9126). Див. Також портативність.

тестування на встановлення: Процес перевірки встановленості програмного продукту. Див. Також тестування на портативність.

керівництво по установці: Надані інструкції на будь-якому підходящому носії, який проводить програму встановлення через процес встановлення. Це може бути посібник з експлуатації, покрокова процедура, майстер встановлення або будь-який інший подібний опис процесу.

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

контрольно-вимірювальні прилади: Вставка додаткового коду в програму для збору інформації про поведінку програми під час виконання.

інструменти: Програмний засіб, що використовується для проведення контрольно-вимірювальних робіт.

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

інтеграція: Процес об'єднання компонентів або систем у великі вузли.

інтеграційне тестування: Тестування, яке проводиться для виявлення дефектів інтерфейсів та взаємодії між інтегрованими компонентами або системами. Див. Також тестування інтеграції компонентів, тестування системної інтеграції.

тестування інтерфейсу: Тип інтеграційного тесту, який займається тестуванням інтерфейсів між компонентами або системами.

сумісність: Здатність програмного продукту взаємодіяти з одним або кількома зазначеними компонентами або системами. (Після ISO 9126) Див. Також функціональність.

тестування на сумісність: Процес тестування для визначення сумісності програмного продукту. Див. Також тестування функціональності.

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

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

ДО

тестування за ключовими словами: Техніка сценаріїв, яка використовує файли даних, щоб містити не тільки тестові дані та очікувані результати, але також ключові слова, пов’язані з тестуваною програмою. Ключові слова інтерпретуються за допомогою спеціальних допоміжних сценаріїв, які викликаються контрольним сценарієм для тесту. Див. Також тестування на основі даних.

L

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

c ++ перетворити char на int

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

Тестування LCSAJ: Техніка проектування тестів на білу скриньку, в якій тестові кейси призначені для виконання LCSAJ.

навчальність: Здатність програмного продукту дозволити користувачеві вивчити його застосування. (ISO 9126) Див. Також зручність використання.

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

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

М

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

тестування на технічне обслуговування: Тестування змін операційної системи або впливу зміненого середовища на операційну систему.

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

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

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

зрілість: (1) Спроможність організації щодо ефективності та результативності її процесів та робочої практики. Див. Також Модель зрілості можливостей, Тест зрілості. (2) Здатність програмного продукту уникати несправностей внаслідок дефектів програмного забезпечення. (ISO 9126) Див. Також надійність.

міра: Номер або категорія, присвоєні атрибуту сутності шляхом проведення вимірювань (ISO 14598).

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

шкала вимірювання: Шкала, яка обмежує тип аналізу даних, який можна на ньому виконати. (ISO 14598)

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

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

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

модератор: Керівник та головна особа, відповідальна за перевірку чи інший процес перевірки.

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

охоплення кількома умовами: Відсоток комбінацій усіх окремих умоврезультати в межах одного твердження, які були використані набором тестів. 100% кратнапокриття умови передбачає 100% покриття визначення стану.

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

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

N

Покриття N-перемикача: Відсоток послідовностей переходів N + 1, які були здійснені набором тестів. (Чау)

Тестування N-перемикача: Форма тестування переходу стану, в якому тестові кейси призначені для виконання всіх дійсних послідовностей переходів N + 1. (Чау) Див. Також тестування на перехід стану.

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

невідповідність: Невиконання зазначеної вимоги. (ISO 9000)

нефункціональна вимога: Вимога, яка стосується не функціональності, а таких характеристик, як надійність, ефективність, зручність використання, ремонтопридатність та портативність.

нефункціональне тестування: Тестування атрибутів компонента або системи, які не стосуються функціональності, наприклад надійність, ефективність, зручність використання, ремонтопридатність та портативність.

техніка проектування нефункціональних тестів: Методи, що використовуються для розробки або вибору тестів для нефункціонального тестування.

АБО

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

працездатність: Можливість програмного продукту дозволити користувачеві керувати ним. (ISO 9126) Див. Також зручність використання.

робоче середовище: Апаратні та програмні продукти, встановлені на сайтах користувачів або споживачів, де буде використовуватися тестований компонент або система. Програмне забезпечення може включати операційні системи, системи управління базами даних та інші програми.

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

експлуатаційні випробування: Тестування проводиться для оцінки компонента або системи в робочому середовищі. (IEEE 610)

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

вихідний домен: Набір, з якого можна вибрати дійсні вихідні значення. Див. Також домен.

вихідне значення: Екземпляр виводу. Див. Також вихідні дані.

P

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

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

Пропуск: Тест вважається успішним, якщо його фактичний результат відповідає очікуваному.

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

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

охоплення шляху: Відсоток шляхів, які були здійснені набором тестів. 100% покриття шляху означає 100% покриття LCSAJ.

сенсибілізуючий шлях: Вибір набору вхідних значень для примусового виконання заданого шляху.

тестування шляху: Техніка дизайну тестів білих коробок, в якій тестові кейси призначені для виконання шляхів.

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

показник ефективності: Високий рівень метрики ефективності та / або ефективності, що використовується для керівництва та контролю прогресивного розвитку, наприклад Відсоток виявлення дефектів (DDP) для тестування. (CMMI)

тестування продуктивності: Процес тестування для визначення продуктивності програмного продукту. Див. Тестування ефективності.

інструмент тестування продуктивності: Інструмент для підтримки тестування продуктивності, який зазвичай має дві основні функції: генерацію навантаження та тестування вимірювання транзакцій. Генерація навантаження може імітувати або декількох користувачів, або великі обсяги вхідних даних. Під час виконання вимірювання часу відгуку беруться з вибраних транзакцій, і вони реєструються. Засоби тестування продуктивності зазвичай надають звіти на основі журналів тестів та графіків навантаження щодо часу відгуку.

план фазового випробування: План випробувань, який зазвичай стосується одного рівня випробувань.

портативність: Легкість передачі програмного продукту з одного апаратного чи програмного середовища на інше. (ISO 9126)

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

післяумова: Екологічні та державні умови, які повинні виконуватися після виконання випробування або процедури випробування.

порівняння після виконання: Порівняння фактичних та очікуваних результатів, проведених після завершення роботи програмного забезпечення.

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

Пріоритет: Рівень (ділової) важливості, що присвоюється предмету, напр. дефект.

тест циклу процесу: Техніка проектування тестів чорної скриньки, в якій тестові кейси призначені для виконання ділових процедур та процесів. (TMap)

процес: Сукупність взаємопов’язаних видів діяльності, які перетворюють вхідні дані у вихідні. (ISO 12207)

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

план тесту проекту: План випробувань, який зазвичай стосується декількох рівнів випробувань.

псевдовипадкові: Серія, яка видається випадковою, але насправді генерується згідно з якоюсь заздалегідь узгодженою послідовністю.

Питання

якість: Ступінь, наскільки компонент, система або процес відповідає визначеним вимогам та / або потребам та очікуванням користувачів / клієнтів. (Після IEEE 610)

гарантія якості: Частина управління якістю зосереджена на забезпеченні впевненості у тому, що вимоги до якості будуть виконані. (ISO 9000)

атрибут якості: Функція або характеристика, що впливає на якість товару. (IEEE 610)

Управління якістю: Координована діяльність з управління та контролю організації щодо якості. Напрям та контроль щодо якості, як правило, включає встановлення політики щодо якості та цілей щодо якості, планування якості, контроль якості, забезпечення якості та поліпшення якості. (ISO 9000)

Р.

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

відновлюваність: Можливість програмного продукту відновити заданий рівень продуктивності та відновити дані, на які це безпосередньо впливає у разі відмови. (ISO 9126) Див. Також надійність.

тестування на відновлення: Процес тестування для визначення можливості відновлення програмного продукту. Див. Також тестування надійності.

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

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

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

перевірка надійності: Процес тестування для визначення надійності програмного продукту.

заміна: Можливість використання програмного продукту замість іншого зазначеного програмного продукту з тією ж метою в тому ж середовищі. (ISO 9126) Див. Також портативність.

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

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

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

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

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

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

результат: Наслідок / результат виконання тесту. Він включає виходи на екрани, зміни даних, звітів та повідомлень, що розсилаються. Дивіться також фактичний результат, очікуваний результат.

критерії відновлення: Тестування, яке необхідно повторити, коли тестування починається після зупинення. (Після IEEE 829)

повторне тестування: Тестування, яке запускає тестові випадки, які не вдалися востаннє, коли вони були запущені, щоб перевірити успішність коригувальних дій.

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

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

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

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

тестування на основі ризику: Тестування, орієнтоване на вивчення та надання інформації про товарні ризики. (Після Джеррарда)

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

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

управління ризиками: Систематичне застосування процедур та практик до завдань виявлення, аналізу, встановлення пріоритетів та контролю ризиків.

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

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

S

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

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

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

тестування масштабованості: Тестування для визначення масштабованості програмного продукту.

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

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

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

тестування безпеки: Тестування для визначення безпеки програмного продукту.

тяжкість: Ступінь впливу дефекту на розвиток або роботу компонента або системи. (Після IEEE 610)

моделювання: Представлення обраних поведінкових характеристик однієї фізичної або абстрактної системи іншою системою. (ISO 2382/1)

симулятор: Пристрій, комп’ютерна програма або система, що використовуються під час тестування, які поводяться або працюють як дана система, якщо забезпечені набором контрольованих входів. (Після IEEE 610, DO178b) Див. Також емулятор.

тест на дим: Підмножина всіх визначених / запланованих тестових випадків, які охоплюють основну функціональність компонента або системи, для встановлення того, що найважливіші функції програми працюють, але не турбуючись про більш дрібні деталі. Щоденний тест на збірку та дим - одна з найкращих галузевих практик. Див. Також тест на прийом.

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

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

техніка проектування випробувань на основі специфікації: Див. Техніку проектування тестів чорних ящиків.

вказаний вхід: Вхід, для якого специфікація передбачає результат.

стабільність: Здатність програмного продукту уникати несподіваних наслідків модифікацій програмного забезпечення. (ISO 9126) Див. Також ремонтопридатність.

Діаграма стану: Діаграма, що зображує стани, які може сприйняти компонент або система, і показує події чи обставини, що спричиняють та / або є наслідком зміни одного стану в інший. (IEEE 610)

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

державний перехід: Перехід між двома станами компонента або системи.

тестування державного переходу: Техніка проектування тестів чорної скриньки, в якій тестові кейси призначені для виконання дійсних та недійсних переходів стану. Див. Також тестування N-перемикача.

заява: Сутність на мові програмування, яка, як правило, є найменшою неподільною одиницею виконання.

висвітлення: Відсоток виконуваних операторів, які були використані набором тестів.

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

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

статичний аналізатор: Інструмент, що проводить статичний аналіз.

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

статичний аналізатор коду: Інструмент, який здійснює статичний аналіз коду. Інструмент перевіряє вихідний код на наявність деяких властивостей, таких як відповідність стандартам кодування, метрики якості або аномалії потоку даних.

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

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

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

Стрес-тестування: Випробування, що проводяться для оцінки системи або компонента в межах або за межі встановлених вимог. (IEEE 610)

структурне покриття: Заходи охоплення, засновані на внутрішній структурі компонента.

техніка проектування структурних випробувань: Див. Техніку проектування тестів білих коробок.

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

підпуть: Послідовність виконуваних операторів всередині компонента.

Критерії призупинення: Критерії, що використовуються для (тимчасового) припинення всіх або частини випробувальної діяльності на тестових завданнях. (Після IEEE 829)

придатність: Здатність програмного продукту забезпечувати відповідний набір функцій для певних завдань та цілей користувача. (ISO 9126) Див. Також функціональність.

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

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

система: Колекція компонентів, організованих для виконання певної функції або набору функцій. (IEEE 610)

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

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

Т

технічний огляд: Діяльність дискусійних груп, яка зосереджується на досягненні консенсусу щодо технічного підходу, який слід застосувати. Технічний огляд також відомий як експертний огляд. (Гілб і Грем, IEEE 1028)

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

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

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

тестовий приклад: Набір вхідних значень, передумов виконання, очікуваних результатів та післяумов виконання, розроблених для певної мети або умови тесту, таких як здійснення певного програмного шляху або перевірка відповідності конкретній вимозі. (Після IEEE 610)

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

тестовий статут: Виклад цілей тесту та, можливо, ідей тесту. Статути випробувань є серед інших, що використовуються в дослідницьких випробуваннях. Див. Також дослідницьке тестування.

тестовий компаратор: Тестовий інструмент для автоматизованого порівняння тестів.

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

умова тесту: Елемент або подія компонента або системи, які можуть бути перевірені одним або кількома тестовими кейсами, наприклад функція, транзакція, атрибут якості або структурний елемент.

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

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

специфікація проекту тесту: Документ, що визначає умови тестування (елементи охоплення) для тестового елемента, детальний підхід до тестування та виявлення відповідних тестових випадків високого рівня. (Після IEEE 829)

інструмент проектування тестів: Інструмент, що підтримує проектну діяльність тестування, генеруючи тестові вхідні дані із специфікації, яка може зберігатися у сховищі інструментів CASE, наприклад інструменту управління вимогами або з визначених умов випробування, що містяться в самому інструменті.

техніка проектування тесту: Метод, що використовується для виведення або відбору тестових випадків.

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

звіт про оцінку тесту: Документ, підготовлений наприкінці тестового процесу, який підсумовує всі дії та результати тестування. Він також містить оцінку процесу тестування та отриманих уроків.

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

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

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

графік виконання тесту: Схема виконання тестових процедур. Процедури тестування включені до графіка виконання тесту в їх контексті та у тому порядку, в якому вони повинні виконуватися.

техніка виконання тесту: Метод, що використовується для фактичного виконання тесту,або вручну, або автоматизовано.

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

тестовий джгут: Тестове середовище, що складається з заглушок та драйверів, необхідних для проведення тесту.

тестова інфраструктура: Організаційні артефакти, необхідні для проведення тестування, що складаються з тестових середовищ, інструментів тестування, офісного середовища та процедур.

тестовий предмет: Індивідуальний елемент, що перевіряється. Зазвичай є один тестовий об’єкт і багато тестових завдань. Див. Також тестовий об'єкт.

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

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

тестування журналу: Процес запису інформації про тести, що виконуються, в журнал тестів.

керівник тесту: Особа, відповідальна за тестування та оцінку об’єкта тестування. Особа, яка керує, контролює, адмініструє плани та регулює оцінку тестового об'єкта.

управління тестами: Планування, оцінка, моніторинг та контроль випробувальної діяльності, як правило, здійснюється керівником випробувань.

Модель тестової зрілості (TMM): П’ятирівнева поетапна структура для вдосконалення тестового процесу, пов’язана із Моделью зрілості можливостей (CMM), яка описує ключові елементи ефективного тестового процесу.

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

тестовий об'єкт: Випробовуваний компонент або система. Див. Також тестовий пункт.

мета тесту: Причина або мета для розробки та виконання тесту.

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

показник ефективності тесту: Показник, загалом високий рівень, який вказує, наскільки певне цільове значення або критерій дотримано. Часто пов’язане з цілями вдосконалення процесу тестування, наприклад Відсоток виявлення дефектів (DDP).

фаза випробування: Певний набір тестових заходів, зібраних у керовану фазу проекту, наприклад виконання заходів тестового рівня. (Після Джеррарда)

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

планування тесту: Діяльність із створення або оновлення плану випробувань.

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

аналіз контрольної точки (TPA): Метод оцінки тесту на основі формули, заснований на аналізі функціональної точки. (TMap)

процедура випробування: Див. Специфікацію процедури випробування.

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

процес випробування: Основний процес випробувань включає планування, специфікацію, виконання, запис і перевірку на завершення. (BS 7925/2)

повторюваність тесту: Атрибут тесту, який вказує, чи отримуються однакові результати при кожному виконанні тесту.

тестовий запуск: Виконання тесту на конкретній версії об'єкта тесту.

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

специфікація тесту: Документ, який складається із специфікації проекту випробування, специфікації тестового випадку та / або специфікації процедури випробування.

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

тестовий пакет: Набір з декількох тестів для випробовуваного компонента або системи, де умова відпрацювання одного тесту часто використовується як передумова наступного.

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

тестова мета: Набір критеріїв виходу.

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

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

тестованість: Можливість програмного продукту дозволити тестувати модифіковане програмне забезпечення. (ISO 9126) Див. Також ремонтопридатність.

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

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

тестер: Технічно кваліфікований фахівець, який бере участь у випробуванні компонента чи системи.

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

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

тестування ниток: Версія тестування інтеграції компонентів, де прогресивна інтеграція компонентів слід за реалізацією підмножин вимог, на відміну від інтеграції компонентів за рівнями ієрархії.

простежуваність: Можливість ідентифікувати пов’язані елементи в документації та програмному забезпеченні, наприкладвимоги з відповідними тестами. Див. Також горизонтальна простежуваність, вертикальна простежуваність.

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

U

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

недосяжний код: Код, до якого неможливо дістатись, а тому неможливо виконати.

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

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

тестування випадків використання: Техніка тестування чорного ящика, в якій тестові кейси призначені для виконання сценаріїв користувача.

тест користувача: Тест, за допомогою якого реальні користувачі залучаються для оцінки зручності використання компонента чи системи.

V

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

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

змінна: Елемент пам’яті в комп’ютері, до якого програма може отримати доступ, посилаючись на нього за іменем.

перевірка: Підтвердження шляхом експертизи та надання об’єктивних доказів того, що визначені вимоги виконані. (ISO 9000)

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

об'ємне тестування: Тестування, де система піддається великим обсягам даних. Див. Також тестування використання ресурсів.

В

покрокове керівництво: Покрокова презентація автором документа з метою збору інформації та встановлення загального розуміння її змісту. (Фрідман і В.einberg, IEEE 1028)

техніка проектування тесту на білу коробку: Документована процедура виведення та відбору тестових випадків на основі аналізу внутрішньої структури компонента або системи.

тестування білої скриньки: Тестування на основі аналізу внутрішньої структури компонента чи системи.

Широкосмуговий Delphi: Техніка оцінки тестів на основі експертів, яка спрямована на точну оцінку, використовуючи колективну мудрість членів команди.

Зв'яжіться зі мною якщо ви хочете додати більше визначень у цьому глосарії.

Довідково: http://www.istqb.org/downloads/glossary-1.0.pdf

Рекомендована література

• Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
• Тестування програмного забезпечення QA Assistant Job
• Курс тестування програмного забезпечення: до якого інституту тестування програмного забезпечення слід приєднатися?
• Вибір тестування програмного забезпечення як вашу кар’єру
• Тестування програмного забезпечення Технічний вміст Writer Фрілансер Робота
• Керівництво з контролю якості аутсорсингу: Тестування програмного забезпечення аутсорсингових компаній
• Деякі цікаві питання для тестування програмного забезпечення
• Відгуки та відгуки про курси тестування програмного забезпечення