Тестування 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. Рівні тестування (послідовність).