Montagpena.ru

Строительство и Монтаж
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Русские Блоги

введение

Программный дефект (дефект): также известен как ошибка. Это функциональная проблема, которая не соответствует нормальной работе компьютерного программного обеспечения, программ и веб-приложений. Это также ошибка, скрытый функциональный дефект, который вызывает недовольство пользователей.
Внутренние дефекты продукта — это ошибки, дефекты и другие проблемы при разработке или сопровождении программных продуктов;
Снаружи продукта дефект — это сбой или нарушение определенной функции, которую система должна реализовать.

Определение отчета о дефектах

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

Процесс обработки дефектов, принятый совместной компанией в проекте, выглядит следующим образом

В процессе тестирования программного обеспечения отчет о дефектах действует как распоряжение о передаче, которое помогает разработчикам и тестировщикам более эффективно общаться, а также повышает скорость и качество устранения дефектов. В то же время качество тестируемого программного обеспечения также можно оценить, подсчитав количество ошибок. Например, план тестирования может быть составлен на основе среднего количества ошибок на тысячу строк в предыдущем проекте. Для аналогичных продуктов, особенно продуктов того же процесса разработки, эти значения Не должно быть слишком большой разницы.Если разница более чем на порядок, мы почти можем сказать, что существует либо проблема QA, либо проблема разработки. Кроме того, количество ошибок перехода на более раннюю версию также является важным эталонным стандартом для оценки качества программного обеспечения. Ошибка перехода на более раннюю версию означает, что новая ошибка возникает из-за исправления ошибки. Слишком много ошибок перехода на более раннюю версию означает, что текущий продукт становится все хуже и хуже.

Отчет о дефектах — это самое главное, что можно отправить во время тестирования. Цель написания отчета о дефектах — помочь программистам найти проблемы в программе, чтобы помочь проанализировать причины ошибок, найти ошибки и изменить проблемы. Его важность не меньше, чем план тестирования, и он оказывает большее влияние на качество продукта, чем другие выходные документы в процессе тестирования. Таким образом, основные требования к составлению отчетов о дефектах — краткие, точные, полные и стандартизированные. Эффективные отчеты о дефектах смогут: уменьшить количество вторичных дефектов отдела разработки, увеличить скорость разработки и модификации дефектов, повысить доверие к отделу тестирования и улучшить сотрудничество между отделами тестирования и разработки. Поэтому при отправке отчета о дефектах нам необходимо предоставить простой и понятный отчет о дефектах, который легко понять и найти проблемы.
Контрольные точки на каждом этапе тестирования

модульный тест: Для каждого модульного теста, чтобы убедиться, что каждый модуль может работать нормально.
Интеграционное тестирование: Соберите протестированные модули и проведите интеграционные тесты. Цель состоит в том, чтобы изучить вопросы структуры программы, связанные с проектированием программного обеспечения.
Системный тест: Проверьте, может ли программный продукт координироваться с другими частями системы (например, с оборудованием, базой данных и обслуживающим персоналом).
Вступительный тест: Последний процесс проверки качества программных продуктов. В основном подчеркивайте роль пользователей, в то время как разработчики программного обеспечения также должны иметь определенную степень участия. Приемочное тестирование можно разделить на альфа-тестирование и бета-тестирование.
Альфа-тест: Тест, сделанный пользователем в среде разработки
Бета-тестирование: Тест проводится пользователем в пользовательской среде.

Состав отчета о дефектах

Информация отчета

НумерацияИнформацияописание
1название программного обеспеченияКакому программному обеспечению принадлежит отчет о дефектах.
2НумерацияДля дефектов, возникших во время выполнения этого варианта использования, номер варианта использования равен номеру дефекта.
3номер версииБыл ли изменен этот дефект. Создано как 1.0.
4ТестерыАвтор отчета.
5ДатаДата написания.
6Назначенный процессорКакой разработчик исправляет этот дефект.
7БраузерБраузер должен быть заполнен для веб-приложений.
8операционная системаОперационная система, использованная при тестировании этого проекта.
9строгостьСерьезность дефекта [S0, S1, S2, S3] самая высокая S0 → S1 → S2 → S3 самая низкая.
10приоритетПриоритет исправления дефектов [P0, P1, P2] Самый высокий P0 → P1 → P2 — самый низкий.

Информация о дефекте

НумерацияИнформацияописание
1Обзор дефектовКраткое описание дефекта.
2Модуль-владелецК какому модулю относится дефект.
3Предварительные условияКакие предварительные условия необходимы для воспроизведения дефекта.
4Действия по воспроизведениюДля воспроизведения дефектов требуются особые действия. (Укажите фактические исходные данные)
5Ожидаемые результатыВ соответствии с «заводскими условиями» и «этапами воспроизведения» после реализации нормальных результатов работы.
6фактические результатыВ соответствии с «заранее подготовленными условиями» и «этапами воспроизведения» после фактических результатов работы.
7Дефектный URLВеб-приложение должно указать URL-адрес дефекта; клиентская программа заполняет путь.
8Скриншот дефектаЕсли в программном обеспечении есть дефекты, если позволяют условия, необходимы снимки экрана, чтобы облегчить разработчикам поиск проблем.

Информация о ремонте

НумерацияИнформацияописание
1результат процессаРезультаты устранения дефекта: успешно, с задержкой, исправить невозможно.
2ОбработчикНазвание процессора.
3Дата обработкиДата обработки.
4Изменить записьПрокомментируйте комментарии встречного и устраните дефекты.
5Результат бэктестаОбратный результат теста: прошел, не прошел.
6ТестерИмя человека, возвращающегося на тест
7Дата тестированияДата тестирования
8Запись бэктестаОценка ремонта дефекта.

Жизненный цикл дефекта

Диаграмма

Примечания:
Розовый: цикл работы тестера;
светло-зеленый: цикл работы начальника отдела или тестировщика;
голубой: рабочий цикл разработчика системы;

Детальное объяснение:

Нумерацияанглийскийкитайский языкВступление
1NEWНовыйКогда дефект отправляется впервые, его статус — «Новый». Это означает, что дефект не подтвержден, действительно ли это дефект.
2OPENвключитьПосле того, как тестировщик представит дефект, когда начальник отдела подтвердит, что это действительно дефект, он установит статус «открыт».
3ASSIGNНазначитьКак только начальник отдела устанавливает дефект как «открытый», он передает дефект соответствующему разработчику или группе разработчиков. Статус дефекта теперь изменен на «выделенный».
4REPAIRремонтКогда разработчик исправит дефект, он отправит дефект группе тестирования для нового раунда тестирования. Прежде чем разработчик объявит о программе, которая исправила дефект, он установит статус дефекта на «ремонт». Это показывает, что дефект был исправлен и передан группе тестирования.
5VERIFIEDподтвердитьКак только дефект будет исправлен, он будет установлен на «исправление», и тестер выполнит тест. Если дефект больше не появляется, это означает, что дефект был устранен и его статус установлен на «закрытый».
6DEFERREDрасширениеСтатус дефекта «Отложено» означает, что дефект будет исправлен в следующей версии. Есть много причин для определения дефектов как «отложенных». Некоторые из-за низкого приоритета дефектов, некоторые из-за нехватки времени, а некоторые из-за дефектов, которые не оказывают большого влияния на программное обеспечение.
7REOPENEDСнова открытьЕсли дефект все еще существует после исправления разработчиком, тестировщик установит статус дефекта на «повторно открыть». Дефект собирается снова пересечь свой жизненный цикл.
8DUPLICATEповторениеЕсли один и тот же дефект представлен повторно или два дефекта указывают на одно и то же значение, то статус дефекта будет установлен на «дублировать».
9REJECTEDОтказыватьсяЕсли разработчик не считает это дефектом, он не примет это. Он установит статус дефекта на «отклонено».
10CLOSEDнеисправностьКак только дефект будет устранен, тестер подтвердит его. Если тестировщик считает, что дефекта не существует, он установит статус дефекта на «закрытый» и запишет дефект. Этот статус означает, что дефект исправлен, тест пройден и подтверждено, что это так.

Анализ риска

Проблема: Неполное описание дефектов при написании отчета;

  • Решение: при написании отчета укажите конкретные этапы работы, данные о работе и снимки экрана с дефектами.

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

  • Решение: запишите дефект и уведомите других тестировщиков, чтобы помочь найти причину дефекта.

Проблема: разработчик не может воспроизвести дефект после отправки.

  • Решение: Помогите разработчикам воспроизвести дефекты.

Проблема: неоднократное представление дефектов

  • Решение: используйте инструменты управления дефектами. Дефекты в группе подает один человек. Дубликаты обнаруживаются и отправляются после сравнения.

Приложение: Шаблон отчета о дефектах

Я не могу загрузить форму, вот вам скриншот!

Серьезность и Приоритет Дефекта

Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый в эти поля. Все знают такой баг-трекер, как Atlassian JIRA. В нем, начиная с какой-то версии вместо одновременного использования полей Severity и Priority, оставили только Priority, которое собрало в себе свойства обоих полей: Originally, JIRA did have both a Priority and a Severity field. The Severity field was removed for a number of reasons. Таким образом, те кто привык работать с JIRA не всегда понимают разницу между этими понятиями, так как не имели опыта их совместного использования. Исходя из личного опыта, я настаиваю на разделении этих понятий, а точнее на использовании обоих полей Severity и Priority, так как смысл, вкладываемый в них, различный:

Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.

Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.

Градация Серьезности дефекта (Severity)

S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.

S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.

S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Градация Приоритета дефекта (Priority)

P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.

P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Порядок исправления ошибок по их приоритетам:

High -> Medium -> Low

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

Хотим предложить вам следующий подход к определению требований к количеству открытых багов:

  • Наличие открытых дефектов P1, P2 и S1, S2, считается неприемлемым для проекта. Все подобные ситуации требуют срочного решения и идут под контроль к менеджерам проекта.
  • Наличие строго ограниченного количества открытых ошибок P3 и S3, S4, S5 не является критичным для проекта и допускается в выдаваемом приложении. Количество же открытых ошибок зависит от размера проекта и установленных критериев качества.

Все требования к открытым ошибкам оговариваются и документируются на этапе принятия решения о качестве разрабатываемого продукта. Как пример документирования подобных требований — это пункт Критерии окончания тестирования в плане тестирования.

Серьезность и приоритет дефекта: в чем различие?

У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.

  • P1 – Высокий (High) – требуется исправить в первую очередь;
  • P2 – Средний(Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом;
  • P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.

Серьезность (Severity) – это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется тестировщиком или техническим специалистом, который может оценить степень влияния дефекта на работу системы.

  • S1 – Блокирующий (Blocker) – дефект полностью блокирует выполнение функционала, нет никакого способа его обойти. Если провести аналогию с закрытым помещением и дверью – то дверь закрыта, у вас нет никакой возможности её открыть и покинуть помещение. Окон нет, ключ к двери не подходит.
  • S2 – Критический (Critical) – дефект блокирует часть функциональности, но есть альтернативный путь для его обхода. По аналогии с помещением и дверью: вы можете покинуть помещение через окно, хотя дверь по-прежнему закрыта и ключ к ней не подходит.
  • S3 – Значительный (Major) – дефект, указывающий на некорректную работу части функциональности. Зачастую связан не с тем, что функция не работает, а с тем, что она работает неправильно. В любом случае, существует более одной точки входа для инициации нужной функциональности. Так, вы можете покинуть помещение без использования ключа (дыра в безопасности), через вентиляцию (другая точка входа) или дверь открывается не в ту сторону (как следствие, упирается в угол и открывается только частично – некорректная реализация). Наиболее часто встречаются дефекты, которые можно отнести именно к этому уровню серьезности.
  • S4 – Незначительный (Minor) – дефект, не относящийся к функциональности системы. Обычно серьезность Minor проставляется для тех дефектов, которые относятся к удобству использования или интерфейсу. По аналогии с помещением и дверью – на двери написано «От себя», хотя она открывается на себя, неудобное расположение замочной скважины и т.д.
  • S5 – Тривиальный (Trivial) – дефект, не затрагивающий функциональность системы, а также оказывающий минимальное влияние на общее качество системы. Часто неотличим от уровня «minor». Обычно это грамматические дефекты в сопроводительной документации к системе. Иногда дефект относится к «невидимым» проблемам с точки зрения пользователя или пользовательского интерфейса и рассматривает сторонние библиотеки или сервисы, не относящиеся к самой разработанной системе. По аналогии с помещением и дверью – замок и ключ не одного производителя, в помещении слышится шум сверху (не относится к самому помещению) и т.д.

Но зачем нужно это деление, разве нельзя обойтись только одним атрибутом, например, серьезностью? Предположим, в некой системе не работает модуль отчетности. Это –дефект с уровнем серьезности «Блокирующий». Однако этот модуль потребуется только в конце отчетного периода (перед Новым Годом). Если сейчас лето, то данная функциональность не будет использоваться еще несколько месяцев. Как следствие, руководитель проекта или лицо, принимающее решение, может проставить низкий приоритет исправления.

Обратная ситуация: на лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании). Данный дефект способен сильно ударить по доверию пользователей к продукции, которую им предлагают: потенциальные клиенты могут подумать, что качество услуг весьма сомнительно, раз даже в названии компании присутствует дефект – и отказаться от использования продукта. С точки зрения подхода к качеству, даже нефункциональные дефекты с уровнем серьезности «Тривиальный» способны отрицательно повлиять на репутацию Компании. Поэтому такому дефекту может быть проставлен высокий приоритет исправления.

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

На основании чего определяется скорость исправления дефекта

Події

Тестирование веб-проектов: основные этапы и советы.


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

Этапы тестирования веб-проектов:
Подготовительный этап и изучение документации.
В данный этап входит анализ технического задания; изучение конечных макетов;тест кейсов;матрицы соответствия (для валидации покрытия требований по продукту тестами) и составление плана тестирования.

Тестирование верстки.
  • неверное отображение блоков, составляющих интерфейса, не состыковки цветовой гаммы;
  • тестирование локализованных версий (перевод сайта);
  • соответствие макету (слои в PhotoShop);
  • при уменьшении/увеличении масштабов (75–150%) без визуальных недочетов;
  • подсвечивание полей с ошибками;
  • проверка в разрешениях (+прокрутка);

Проверить можно так: FirefoxMenu –> Инструменты –> Веб-разработчик –> Адаптивный дизайн или Resolution Test Plugin в Chrome.

Доступность и отсутствие JS ошибок:

  • нажимаются ли кликабельные элементы (внутренние/внешние ссылки, ссылки на электронную почту, кнопки, иконки);
  • при наведении на кликабельные изменяется курсор, иначе – нет;
  • подсказки на непонятных кликабельных элементах;
  • при отключении изображений должны быть подписи небольшим серым цветом (в Web Developer –> Images –> Replace Image With Alt Attributes);
  • работоспособность при выключенном JS. Критические функции должны быть доступны без JS (в Web Developer –> Disable –> Disable JS –> All JS)

Корректная работа, надежная верстка:

  • проверка работы с данными (введение большого и малого количества текста в форму; блоки с контентом меняются местами (Firebug (HTML –> Edit)));
  • проверка работы стилей (введение текста с заголовками, с абзацем и без, с картинками).

404-е запросы:

  • нет ли 404-х ошибок (Firefox –> Tools –> Validate links)
Функциональное тестирование.

Вид тестирования, при котором выявляется некорректная/неправильная работа функционала программы.

Необходимыми проверками являются:

  • корректность работы главных функций сайта;
  • переход по ссылкам;
  • проверка пользовательских форм (валидация полей, обязательные/необязательные поля, уведомления об ошибках при неверном вводе, добавление комментариев в блог, обратная связь);
  • поиск и покупка товара, оформление заказа;
  • сверка переданного заказчиком контента с имеющимся на сайте;
  • проверка возможной авторизации/регистрации;
  • добавление, удаление и редактирование данных пользователей, товаров и заказов.

Ad-hock тестирование — импровизационное тестирование без подготовки.
Помогает понять: понятно ли назначение форм;

  1. отмечены ли обязательные поля и все ли обязательные поля отмечены;
  2. встроена ли обязательная проверка заполненных форм;
  3. происходит ли проверка правильности ввода контактных данных.

Из достоинств данного тестирования можно выделить:

  1. достаточно быстрое знакомство с системой;
  2. специфические неисправности;
  3. массу вопросов и предложений;
  4. экономию времени.

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

Эквивалентные тесты – это тесты, которые приводят к одному и тому же результату. Группа тестов представляет собой класс эквивалентности, при выполнении следующих условий:

  • все тесты написаны для выявления одной ошибки;
  • если один из тестов выявит ошибку, то остальные тоже ее выявят;
  • обратное тоже верно.

Эквивалентная область – часть области входных или выходных данных, для которых поведение компонентов или систем, основываясь на спецификации, считаются одинаковыми.

Exploratory testing, также называется интуитивным тестированием, подразумевает под собой одновременно проектирование, выполнение тестов и обучение продукту.

Usability тестирование (User Experience).

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

  • Навигационное тестирование сайта. Все ли страницы, кнопки и поля на них, понятны в использовании, доступ к главной странице и меню со всех остальных страниц возможен, навигация проста и интуитивно понятна.
  • Тестирование контента. Отсутствие грамматических/орфографических ошибок, контент информативен и структурированный, изображения и заголовки имеют подходящие размеры и размещены правильно.
  • Удобство использования. Понятна ли структура веб-приложения, какое впечатление производит и есть ли лишние компоненты на страницах.
  • Тестирование UI (User Interface). Соответствие стандартам графических интерфейсов и элементов дизайна, правильность локализованных версий, тестирования с различными разрешениями, на смартфонах и планшетах.
Тестирование совместимости (конфигурационное тестирование).

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

  • Кросс-платформенное тестирование сайта. Некоторые функции могут иметь проблемы с определенными операционными системами, поэтому необходимо проверять работу приложения в различных версиях Windows, Unix, Mac, Linux, Solaris и др.
  • Кросс-браузерное тестирование сайта. Также корректная работа зависит от типа браузера. Верстка должна быть кроссбраузерной, чтобы обеспечить одинаковую визуальную часть, доступность, функциональность и дизайн во всех браузерах. Необходимо проверять масштабируемость, расширяемость, рамки для элементов в фокусе, отсутствие JS ошибок (левый нижний угол страницы). Проверять работу необходимо в таких браузерах, как: Internet Explorer, Firefox, Chrome, Safari, Opera, Edge разных версий.
  • Просмотр на мобильных устройствах. Несмотря на проверку работы веб-приложений в различных разрешениях на компьютере, зачастую ошибки на мобильных устройствах остаются не замечены. Следовательно, настоятельно рекомендуется проверять корректное отображение и работу вашего веб-приложения на мобильных устройствах разных операционных устройств, а также на планшетах.
  • Тестирование БД. Необходимо проверить правильность осуществления связи с сервером, проверить совместимость сервера с ПО, аппаратными средствами, базой данных и сетью. Также нужно проверить что происходит при прерывании какого-либо действия, при повторном подключении к серверу во время выполнения операций.
Тестирование производительности.

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

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

  • Подход нагрузочного тестирования:
  • Оценить критерии приемлемости производительности
  • Определить критические сценарии
  • Модель рабочей нагрузки
  • Определите целевые уровни нагрузки
  • Дизайн тестов
  • Выполнить тесты
  • Проанализируйте результаты

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

Стресс-тестирование (Stress Testing) проверяет систему на ее устойчивость и обработку ошибок в условиях чрезвычайно высокой нагрузки (оценивает как система работает в экстремальных условиях, за пределами ограничений и лимитов). Стресс-тестирование проводится, чтобы убедиться, что система не будет аварийно завершать работу в критических ситуациях.

Тестирование стабильности/надежности (Stability/Reliability Testing) – тип тестирования программного обеспечения, который проверяет, может ли программное обеспечение выполнять безотказную работу в течение определенного периода времени в указанной среде.

Объемное тестирование (Volume Testing) – тип тестирования программного обеспечения, проводится для анализа производительности системы за счет увеличения объема данных в базе данных.

Тестирование параллелизма (Parallel Testing) – тип тестирования программного обеспечения, который проверяет несколько приложений или подкомпонентов одного приложения одновременно, чтобы сократить время тестирования. При параллельном тестировании тестировщик запускает две разные версии программного обеспечения одновременно с одним и тем же вводом. Цель состоит в том, чтобы выяснить, ведут ли себя прежняя система и новая система одинаково или по-разному.

Тестирование безопасности.

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

Аспекты безопасности программного обеспечения:

  • Функциональное программное обеспечение не должно создавать опасностей (например: управление современным самолетом НЕ должно направляться в океан).
  • Системы мониторинга должны работать без сбоев (например: резервный компьютер должен запускаться автоматически при сбое основного).

Цели в тестировании безопасности:

  • в сложных системах, где задействовано много взаимодействий, критически важные для безопасности функции должны быть идентифицированы и тщательно проанализированы;
  • ошибки определены и устранены;
  • количество критических ошибок поддерживается на низком уровне, чтобы избежать неработоспособности системы;
  • атрибуты безопасности должны рассматриваться как часть всех уровней тестирования ПО.

Дополнительную информацию по безопасности приложений можно посмотреть тут: CHECK, ISACA, NIST Guideline, OSSTMM, OWASP Guide.

Принципы безопасности:

  1. Конфиденциальность (ограничение или предоставление доступа к информации).
  2. Целостность (возможность восстановить данные в полном объеме при их повреждении; доступ на изменение информации только определенной категории пользователей).
  3. Доступность (иерархия уровней доступа и четкое их соблюдение).

Обработка ошибок и регрессионное тестирование.
После завершения разработки веб-приложения следует провести оценку и анализ выявленных ошибок для дальнейшего предотвращение их повтора. А также выполнить регрессионное тестирование.

Регрессионное тестирование

Использует технику тестирования черного ящика (повторное выполнение тестов), на которые влияют изменения кода. Эти тесты должны выполняться как можно чаще в течение всего ЖЦПО при изменениях кода для исправления дефектов или для улучшения работы веб-приложения.

Практические советы вам:

  • Перед тем, как приступить к тестированию необходимо обсудить все важные детали с командой (BA, PM, разработчики).
  • Использовать обширный подход с применением техник тест-анализа и набора методик тест-дизайна.
  • Определить виды тестирования, которые необходимо провести.
  • Определить цели и ключевых пользователей веб-приложения.
  • Списки устройств, ОС и браузеров, на которых необходимо провести тестирование.
  • Доступ для разных ролей посетителей.
  • Необходимость составления и передачи документации.

Хотим вам напомнить, что рабочий процесс – это не рутина, а творческий процесс, определяющий широту полета вашей мысли. Относитесь к вашей работе как к новому челленджу, и вы определенно начнете получать не только удовольствие, но и вдохновение и желание развиваться. Задачи тестировщика очень многогранны: им необходимо понять задачу веб-приложения, понять как оно должно работать, какие задачи решать, какую пользу приносить пользователям и затем перепроверить все по несколько раз, чтобы выпустить проект в мир. Им нужно быть собранными и дерзать, чтобы выпускать проекты за которые вся команда сможет гордиться =)

голоса
Рейтинг статьи
Читайте так же:
Пайка медных труб с азотом
Ссылка на основную публикацию
Adblock
detector