Тестування чорного і білого ящика

У термінології професіоналів тестування (програмного й деякого апаратного забезпечення), фрази «тестування білого ящика» і «тестування чорного ящика» відносяться до того, чи має розробник тестів доступ до вихідного коду ПЗ, що тестується, або ж тестування виконується через інтерфейс користувача або прикладний програмний інтерфейс, наданий модулем, що тестується. При тестуванні білого ящика (англ. white-box testing, також говорять – прозорого ящика), розробник тесту має доступ до вихідного коду й може писати код, що пов'язаний з бібліотеками ПЗ, що тестується. Це типово для юніт-тестування (англ. unit testing), при якому тестуються тільки окремі частини системи. Воно забезпечує те, що компоненти конструкції – працездатні й стійкі до певного ступеня.

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

Якщо «альфа-» і «бета-тестування» відносяться до стадій до випуску продукту (а також, неявно, до обсягу співтовариства, що тестує, й обмеженням на методи тестування), тестування «білого ящика» і «чорного ящика» має відношення до способів, якими тестер досягає цілі.

Бета-тестування в цілому обмежено технікою чорного ящика (хоча постійна частина тестерів звичайно продовжує тестування білого ящика паралельно бета-тестуванню). Таким чином, термін «бета-тестування» може вказувати на стан програми (ближче до випуску чим «альфа»), або може вказувати на деяку групу тестерів і процес, що виконується цією групою. Отже, тестер може продовжувати роботу з тестування білого ящика, хоча ПЗ вже «у беті» (стадія), але в цьому випадку він не є частиною «бета-тестування» (групи/процесу).

 

Шаблони й приклади документів

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

Тест План:

– Тест план IEEE 829.

– Тест план RUP.

– План приймально-здавальних випробувань RUP.

– План проведення навантажувального тестування.

Тест Дизайн специфікації:

– Тест дизайн специфікація [IEEE 829-1998].

Тест Кейс:

– Приклад оформлення тест кейса.

Баг репорт:

– Приклад оформлення баг репорту.

 

Приведемо приклади деяких документів, з перерахованих вище, а саме:

– План проведення навантажувального тестування.

– Приклад оформлення тест кейса.

– Приклад оформлення баг репорту.

ПЛАН НАВАНТАЖУВАЛЬНОГО ТЕСТУВАННЯ

<Тестуємий Проект>

Версія <00.000.00>

ЗМІСТ

1. Історія змін.

2. Термінологія.

3. Цілі тестування.

4. Архітектура тестуємої системи.

5. Модель навантаження.

6. Опис стратегії тестування.

7. Опис критеріїв успішності тесту.

8. Вимоги до тестового середовища.

9. Ресурси.

10. Документи, що підлягають здаванню.

 

Історія змін

Дата Версія Автор Опис змін
<dd/mmm/yy> <x.x> <ім'я> <опис>
       
       

Термінологія

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

– Віртуальний користувач – програмний процес, що циклічно виконує моделюємі операції.

– Ітерація – це один повтор виконуваної одним віртуальним користувачем операції в циклі.

– Інтенсивність виконання операції – інтервал часу між ітераціями.

– Навантаження – сукупне виконання операцій на загальному ресурсі (тр./сек).

– Продуктивність – кількість виконуваних операцій за період часу (N операцій за M годин).

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

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

– Модель навантаження – набір профілів навантаження з усіма навантажувальними точками для кожного профілю.

– Тестування стабільності – це проведення тестування із середнім навантаженням протягом тривалого часу. Виявляє проблеми пов'язані з витоками пам'яті й некоректними настроювання ПЗ. ]

 

Цілі тестування

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

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

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

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


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: