Тестування Web-застосувань

Тестирование web-приложений имеет много общего с тестированием операционных систем для настольных компьютеров. Вам необходимо протестировать стандартную функциональность, конфигурацию и совместимость, а также выполнить все остальные стандартные виды тестов. Но тестирование web-приложений — это более сложный процесс, потому как трудности приумножены всеми распределенными компонентами системы, взаимодействующими с приложением. Когда мы видим ошибку в сетевой среде, то зачастую сложно точно указать, где именно она произошла, и потому режим работы, или же сообщение об ошибке, которое мы получаем, может быть результатом ошибок, случившихся в разных частях сетевой системы. В таком случае исправление ошибки будет проблематичным. Існюють 3 рівні тестування Web-застосування:

-модульное тестирование;

-интеграционное тестирование;

-системное тестирование;

50.Тестування та визначення дефектів.

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

Ø Виявлення дефектів спонтанно

Ø Виявлення дефектів на основі контрольних списків

Ø Виявлення дефектів на основі сценаріїв

51. Метрики підрахунку дефектів.

- Плотность дефектов (500 = Число дефектов / Размер юода)

- Плотность дефектов после поставки (РООО = Число дефектов

после поставки / Размер кода)

- Доля отклоненных дефектов (ВПК = Число отклоиеииых

дефектов / Число дефектов)

- «Убойность» тестов (ОР = Число дефектов / Число тестов)

- Эффективность тестирования (ТЕ = Число дефектов / Трудозатраты тестирования)

- Доля покрытия требований (КСК = Число требований,

покрытых тестами / Число требований)

- Плотность покрытия требований (КСО = Число тестов / Число

требований)

- доля повторно открытых дефектов (КОК = Число повторно

открытых дефектов / Число дефектов)

- И много-много других

° Lifetime - распределение дефектов по их продолжительности жизни в проекте

° Detection time - распределение дефектов по времени их обнаружения

в жизненном цикле проекта, релиза или программного продукта.

° Submitted vs Resolved - временное распределение количества

дефектов со статусом Submitted и со статусом Resolved

° Resolved vs Validated - временное распределение количества

дефектов со статусом Resolved и со статусом Validated

° Reopened - временное распределение количества дефектов со

статусом Reopened

° Zero-defects data - прогноз даты, к которой идентифицированные при системном тестировании дефекты будут закрыты.

Проблеми оракула.

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

53. Обмеження при проведенні тестування.

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

Ø Найвідоміші цитати в цьому відношенні є афоризми Дейкстри що “тестування програм може використовуватися для демонстрації наявності помилок, але не для демонстрації їх відсутності.”

Ø Очевидна причина в тому, що повне тестування не є можливим в справжньому ПЗ. Через це, тестування повинно визначатися в залежності від ризику, і може розглядатися як стратегія управління ризиками.

54. Тести, що базуються на блок-схемі.

Тесты, базирующиеся на блок-схеме (Control-flow-based criteria)

Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов.

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

55. Тестування інсталяцій.

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

56. Зв’язок тестування з іншими видами діяльності по розробці.

Ø Тестування ПЗ пов’язане, але відрізняється від, технік керування якістю ПЗ, доведень коректності, відладки та програмування.

Ø Тим не менше, воно є інформаційним з точки зору аналітиків якості ПЗ та центрів сертифікації

Ø Тестування vs. Статистика технік керування якістю ПЗ

Ø Тестування vs. Доведення коректності та Формальна верифікація

Ø Тестування vs. Відладка.

Ø Тестування vs. Програмування.

Ø Тестування та Сертифікація.

57. Метод білої скриньки.

¨ Знання про програмний компонент/структуру

¤ Контрольний список виразів чи компонентів

¤ Тестування шляхів у коді (потік управління)

¤ Тестування залежності по даним (потоки даних)

¨ Застосування

¤ Тестування на ранніх стадіях

¤ Подвійна роль програміста – тестувальника

¨ Критерій зупинки

¤ В основному задачі покриття

¤ Інколи інші задачі по якості та надійності

58. Рівні тестування (послідовність).