22. Жизненный цикл ошибки. Системы документирования ошибок.
ЖЦ ошибки нач-ся с ее обнаружения и присвоение ей статуса – «найдено» (submitted), затем ошибка направляется к разработчику и ей присваивается статус – «присвоена» (assigned), после исправления - статус «исправлена» (fixed), затем исправленная ошибка направляется тестировщику (как правило, в новой версии ПП), и если она не повторяется, то получает статус – «проверена» (verified).
Возможны также следующие случаи:
когда исправленная ошибка повторяется снова, тогда тестировщик присваивает статус – «повторить» (reopen).
когда задокументированная ошибка не воспроизводится, тогда - статус «не воспроизводится» (declired).
когда задокументированная ошибка не может быть исправлена в текущей версии ПП или ее не следует исправлять вообще. В 1-ом случае ошибка, возможно, сама собой исчезнет в последующей версии ПП. Во 2-ом случае ошибка была не точно определена в требованиях, тогда ошибку откладывают и статус – «отложить» (deffered)
Для автоматического пр-сса документирования ошибок существуют системы документирования и отслеживания ошибок (bug tracking system).
Назначение таких систем состоит в следующем:
Повышение взаимодействия между сотрудниками;
Ни одна ошибка не должна остаться неисправленной из-за прихоти разработчика;
Как можно меньше проблем д. остаться из-за проблем между сотрудниками.
В пр-ссе документирования ошибка проходит след путь:
найденная ошибка вносится в систему;
руководитель просматривает все отчеты об ошибках и назначает разработчика для исправления ошибки;
ошибка исправляется и обозначается, как исправленная
тестир проверяет, действительно ли исправлена;
если ошибка исправлена, то она закрывается, если нет – переходит на шаг 1;
возможны случаи, когда ошибка не воспроизводится, либо б. исправлена позже, либо не будет исправлена совсем.
Выбор системы документирования осуществляется по следующим пунктам:
Устойчивость системы на различных платформах;
Наличие клиент-серверного приложения;
Поддержка работы с различными БД;
Интегрирование в различные информационные стеды;
Стоимость и схема лицензирования;
Гибкость настройки системы, а так же элементарная поддержка событий и формирования отчетов.
В качестве примера можно привести следующие системы: Rational Clear Quest, Seapine Test track Pro, SoftWare PR-Tracker, Bugzilla.
23. Специфика и ограничения тестирования Web-приложений.
Два ключевых момента:
1) 1. Проверка на совместимость на уровне браузера
2. Совместимость на уровне ОС
3. БД, используемые в проекте и тестировании
4. Веб-сервера, используемые в проекте и тестировании
5. Сервера приложений, используемые в проекте и тестировании.
Результаты используются для создания матрицы тестирования.
2) 1. Языки и технологии разработки веб-приложений. Различия между статическими сайтами и динамическими.
2. Удобства использования: дружественность (навигация, таблицы, фреймы, шрифты, звук, видео)
3. Производительность( вр. загрузки, отклика, кол-во одновр-х польз-й)
4. повр-е ссылки и отсут-е страницы
5. защитный режим работы с сайтом