Скачано С Www.Sharewood.Biz - Присоединяйся!

Стратегия
тестирования
Цели и задачи стратегии тестирования. Выбор подходящих
техник в зависимости от функционала и особенностей. Учёт
нефункционального тестирования
Стратегия тестирования
Цели и задачи стратегии тестирования
Процесс формирования стратегии
Как описать стратегию тестирования
RUP (Rational Unified Process)
Метод анализа проблем Кепнера и Трего
HTSM (Heuristic Test Strategy Model)
Учёт нефункционального тестирования
Что проверяет нефункциональное тестирование
Как применять нефункциональное тестирование
Домашнее задание
Дополнительные материалы
Используемая литература
СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Стратегия тестирования
У любого тестирования всегда есть цели, иначе сложно понять, каковы результаты тестирования,
насколько они соответствуют ожиданиям. Без цели нельзя двигаться вперёд, не зная, к чему нужно
прийти. А можно ли прийти к цели без плана? Либо нельзя, либо можно, но с большим опозданием.
На большинстве проектов тестирование строго ограничено по времени, поскольку время стоит денег.
Любое опоздание или неверный результат может обойтись дорого.
Составление плана позволяет наметить путь, по которому нужно двигаться к цели. Однако само
наличие плана не гарантирует, что мы действительно к ней придём и придём быстро. Важно
составить оптимальный план, который может дать быстрый и гарантированный результат. К этому
надо стремиться. Хороший тестовый план в итоге должен привести к уменьшению материальных и
временных затрат, а руководство это обязательно оценит.
Цели и задачи стратегии тестирования

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

позволят достигнуть цели тестирования.
Стратегия отвечает на следующие вопросы:
● Каким образом тестирование даст ответ, что тестируемый функционал работает?

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

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

Формирование тестовой стратегии – творческий процесс, состоящий из нескольких шагов.
1. Сбор информации. Источниками информации о продукте могут быть: чтение документации и

изучение других артефактов (например, карт функциональности, тест-кейсов, прототипов и
пр.), общение с заказчиком, аналитиком или менеджером проекта и даже исследовательское
тестирование, цель которого – просто изучить продукт, а не найти в нём баги.
2. Анализ информации. На этом этапе мы отбираем, систематизируем, фильтруем
информацию, оставляя всё самое необходимое. Далее обдумываем и анализируем
полученные данные, создаём целостное представление о ПО, о его особенностях,
© geekbrains.ru 1

уязвимостях. Также можно изучать всевозможные подходы к тестированию, техники, искать

возможные варианты или пути тестирования.
3. Принятие решений. После того, как мы получили сведения о ПО и о потенциальных методах
его тестирования, можно начинать формировать стратегию. Здесь мы принимаем конкретные
решения по поводу того, как будет тестироваться продукт, отбираем техники тестирования,
намечаем этапы, определяем сроки. На основании принятых решений и будем формировать
тестовую стратегию.
4. Презентация. До этого этапа дело доходит не всегда: бывает, что другим участникам проекта
нет никакого дела до того, как мы тестируем. Но если у нас будет что-нибудь, что описывает
стратегию, то его всегда можно будет предоставить любому заинтересованному лицу. Это
может быть как стандартизованный формальный документ, так и презентация, схема, таблица
и т. д. В любом случае надо быть готовым грамотно обосновать, почему была выбрана такая
стратегия и как она отражает текущее состояние тестирования.
5. Доработка. Можно также возвращаться к предыдущим шагам, дорабатывая свою стратегию.
Границы между шагами не всегда должны быть четкими, поскольку разработка стратегии –
это всё-таки творческий процесс.
Как описать стратегию тестирования

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

метод Кепнера и Трего и HTSM. В дальнейшем можно взять любую из них целиком за основу для
формирования собственной стратегии, а можно взять понемногу из каждой. Все перечисленные
методы носят рекомендательный характер.
RUP (Rational Unified Process)

Разработана компанией IBM. В модели RUP стратегия тестирования входит в состав тест-плана и
является его основной частью.
Согласно этой модели тестовая стратегия должна включать в себя:
1. Типы тестирования.
1.1. Тестирование данных и их целостности.
1.2. Функциональное тестирование.
1.3. Тестирование бизнес-процессов.
1.4. Тестирование пользовательского интерфейса.
1.5. Тестирование производительности.
1.6. Тестирование загрузки.
1.7. Стресс-тестирование.
1.8. Объёмное тестирование.
1.9. Тестирование безопасности.
1.10. Тестирование восстановления после сбоев.
1.11. Конфигурационное тестирование.
1.12. Тестирование установки.
Для каждого типа тестирования, который предполагается использовать на проекте, предлагается

заполнить такую таблицу:
Цель тестирования
Техника тестирования
Критерии окончания тестирования
Дополнительные требования
© geekbrains.ru 2

Например:
1.1. Тестирование данных и целостности данных.
Цель Проверить, что методы, работающие с базой данных, работают должным

тестирования образом и не повреждают данные.
Техника Вызов каждого метода, обращающегося к БД, с позитивными и негативными

входными данными.
Нужно также проверить в БД, что результаты выполнения методов были
записаны туда правильно; проверить, что методы, которые считывают данные из
БД, возвращают эти данные правильно.
Критерии Все методы, созданные для обращения к БД, функционируют и не повреждают

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

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

окончания Все баги были исправлены.
Дополнительны Нужно определить и записать всё, что каким-либо образом может повлиять на
е требования реализацию и выполнение функционального тестирования.
1.3. Тестирование бизнес-процессов.
Цель Проверить, насколько бизнес-функции в ПО соответствуют требуемым

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

● тесты, используемые при функциональном тестировании, будут
выполняться несколько раз, имитируя выполнение функции несколькими
пользователями;
● все чувствительные к изменению даты или времени функции будут
© geekbrains.ru 3

проверяться путём ввода действительных/недействительных

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

окончания Все найденные баги исправлены.
Дополнительны Проверка системных дат и событий может потребовать дополнительной

е требования подготовки.
Для проверки бизнес-требований и процедур должна быть предварительно
подготовлена соответствующая модель ПО.
2. Инструментальные средства. Предлагается представить их в виде такой таблицы:
Инструмент Производитель/ Версия

Собственная
разработка
Управление
тестированием
Отслеживание дефектов
Средства
функционального
Средства нагрузочного
Средства управления
тестами
Управление проектом
Средства управления БД
© geekbrains.ru 4

Пример:
Инструмент Производитель/ Версия

Собственная
разработка
Управление Zephyr Zephyr 2.0

тестированием
Отслеживание Jira Atlassian 6.4

дефектов
Средства Visual Studio, Microsoft 2013

функционального Selenium,
тестирования Git
Средства нагрузочного JMeter Apache 3.0

Средства Zephyr Zephyr 2.0

отслеживания
тестового покрытия
Управление проектом Jira Atlassian 6.4
Средства управления MS SQL Server Microsoft 2012

БД
Метод анализа проблем Кепнера и Трего

Чарльз Кепнер (Charles Kepner) и Бенджамин Трего (Benjamin Tregoe) разработали метод анализа
проблем. Они считают, что для того, чтобы принимать правильные решения, необходимо
анализировать проблемы. Они разработали 5 фаз анализа проблемы:
● Определение проблемы. На практике это самая сложная задача. Поскольку на этом

определении будет основываться всё дальнейшее расследование, нужно чётко определить
отклонения от ожидаемого результата.
● Описание проблемы. Для описания того, в чём заключается проблема, используются
следующие пункты:
○ Особенности: что или какая составная часть плохо работает?
○ Местоположение: где возникает проблема?
○ Время: когда возникла проблема? Как часто она возникает?
○ Размеры: каков масштаб проблемы? Сколько составных частей ей затронуто?
Также на этом этапе проводится расследование, какие из составных частей в сходных условиях
функционируют нормально – то есть для каких частей могла бы проявляться та же проблема, но этого
не происходит?
● Выявление возможных причин. Можно сравнить эти две ситуации (когда составная часть
системы функционировала нормально и когда возникала проблема в её функционировании) и
найти отличия. Также можно попытаться выявить прошлые изменения, которые могли бы
стать причиной этих отличий. Вероятнее всего, что этот список изменений и отличий и
© geekbrains.ru 5

содержит причину проблемы. То есть, основываясь на этом списке, можно выделить

вероятные причины.
● Тестирование наиболее вероятной причины. Оценивается, какие из вероятных причин могут
вызывать все симптомы проблемы. Причина, которая может вызвать наибольшее количество
симптомов, считается наиболее вероятной. Далее проверяется эта причина.
● Проверка истинной причины. Нужно также проверить, могут ли оставшиеся причины являться
источником проблемы. Это может быть проверено только на практике, путём внедрения
изменений или замены составной части. Сначала рекомендуется рассмотреть те причины,
которые проверить быстрее и легче.
В этих фазах заключается структурный подход к определению проблемы. Согласно этому методу, все
фазы должны выполняться, то есть это довольно строгая модель исследования. Однако этот подход
может работать, когда времени мало. Усилия и временные ресурсы, в зависимости от специфики
проблемы и других обстоятельств, можно распределить между разными фазами по-разному.
Как этот метод можно применить определению стратегии тестирования?
Например, в организации на определённом проекте есть такая проблема: часто разработчики не

успевают выпустить обновление в срок, и оно запаздывает на день-два, что для пользователей
продукта бывает существенно.
Попробуем описать эту проблему:
1. Что плохо работает? Плохо работает выпуск обновлений.

2. Где возникает проблема? На проекте.
3. Когда проблема возникает и как часто? Проблема возникает в период проверки обновления и
проявляется для каждого второго обновления в среднем.
4. Каков масштаб проблемы? Половина обновлений выпускается с опозданием.
Разберёмся теперь, почему некоторые обновления выпускались в срок, а некоторые опаздывали.
Допустим, мы знаем, что обновление от января включало в себя 5 средних по объёму и сложности
задач, а обновление от февраля включало 6 задач, причём одна из них была очень объёмной, и
февральское обновление было выпущено с опозданием. То есть одной из возможных причин мог
быть большой объём обновления. Также могло быть такое, что разработчики поздно собрали
обновление. А может, тестировщики поздно приступили к тестированию, так как были загружены
другими срочными задачами? Допустим, на этом проекте заведено так, что если требуется
тестирование обновления, то все тестировщики бросают все свои дела и идут проверять обновление.
А менеджер проекта чётко следит за тем, чтобы обновление собиралось вовремя. Тогда последнюю и
предпоследнюю причины можно отбросить.
Мартовское обновление включало в себя 7 задач и было выпущено в срок. Все эти задачи
относились к одному и тому же модулю приложения. Возможно, было мало багов в RC?
Апрельское же обновление состояло из 5 задач, но они все относились к разным модулям, при этом
в обновлении было найдено множество багов, обновление несколько раз перепроверялось вручную
(поскольку на проекте не было автоматизации тестирования). Какие причины могли бы быть у этого
опоздания? Одна из возможных причин была в том, что из-за большого количества багов в
обновлении тестировщикам пришлось много перепроверять. Какая причина у такого большого
количества багов? Может быть, разработчики допустили много багов при сборке обновления? Или
тестировщики пропустили много багов до релиза? Или разработчики, исправляя баги сборки,
допустили другие баги?
Июньское обновление также было выпущено с опозданием. Объём обновления был небольшой, но
в обновлении были найдены баги, из-за чего приходилось несколько раз пересобирать и
перепроверять обновление.
На основании собранной информации составим список возможных причин:
● большой объём обновления;

● пропуск багов тестировщиками до релиза и, как следствие, частая пересборка и
перетестирование обновления;
© geekbrains.ru 6

● допущение ошибок разработчиками как при сборке, так и при исправлениях.
Как думаете, какая причина могла бы быть наиболее вероятной?
Выяснилось, что тестировщики сильно загружены, в том числе на других проектах, поэтому тестируют
только фичи, а на регрессию функционала не остаётся времени. Пока примем эту причину как самую
вероятную. Статистическое исследование показало, что 80% багов, найденных в релизе, относятся не
к задачам обновления, а к ранее разработанному функционалу. То есть, действительно, пропуск
багов ПО из-за того, что регрессия функционала давно не проводится, мог стать причиной задержки
выпуска обновления.
Какой может быть выход из этой ситуации? Можно попробовать автоматизировать регрессионное
тестирование. Если тестировщики сильно загружены, можно переложить эту обязанность, например,
на разработчиков, если у них есть время. Автоматизацию тестирования нужно отразить в тестовой
стратегии, к тому же уже есть готовое обоснование использования этого вида тестирования.
Теперь рассмотрим остальные вероятные причины. Может ли задерживаться обновление из-за

большого количества задач в нём? Эту причину проверить легче всего: достаточно открыть систему
управления проектом и посмотреть, сколько задач включалось в проблемные обновления и сколько
времени закладывалось при этом на тестирование обновления. Допустим, выяснилось, что на
проверку обновления всегда выделяется не более двух дней, при этом обновления с количеством
задач > 5 в 70% случаев не были подготовлены в срок. То есть эта причина также могла повлиять на
время проверки обновления. Следовательно, нужно либо не допускать в обновлении более 5 задач,
либо на тестирование более объёмных обновлений выделять больше времени. Это организационный
вопрос, который решается с менеджером проекта. В стратегии тестирования решение этого вопроса
тоже должно быть отражено в качестве того, когда должно начинаться тестирование обновления.
Следующая причина – допущение ошибок разработчиками как при сборке, так и при исправлениях.
Например, собрали всю команду проекта и расспросили о том, бывают ли такие ситуации и как часто
случаются. Выяснилось, что они случаются почти каждое обновление. Это человеческий фактор, его
можно минимизировать, например, введя юнит-тестирование. Этот вид тестирования также может
быть отражён в тестовой стратегии.
Таким образом, мы рассмотрели, как тестовая стратегия может строиться на основании метода
анализа проблем.
HTSM (Heuristic Test Strategy Model)

Автор этой модели – Джеймс Бах. Тестовая стратегия, построенная по этой модели, состоит из
следующих частей:
© geekbrains.ru 7

● Project Environment (окружение проекта). Здесь перечисляется всё, что окружает проект.
Это окружение может состоять из таких компонентов:
○ Миссия – цель этого проекта, как её понимаете вы и как её понимает заказчик.
○ Информация – информация о продукте или о проекте, которая необходима для
тестирования.
○ Связь с разработчиками – как вы взаимодействуете с программистами.
○ Команда тестирования – все, кто тестирует или поддерживает тестирование на
проекте.
○ Средства тестирования – аппаратное и программное обеспечение, документы,
необходимые для управления тестированием.
○ График – последовательность, длительность и синхронизация событий, происходящих
на проекте.
○ Тестируемые элементы – всё, что требуется протестировать.
○ Результаты – ощутимые результаты тестирования проекта (в основном это тесты,
баги, тестовые спецификации).
● Product Elements (элементы продукта). Это то, из чего состоит сам продукт. Нужно
подумать и выделить составные части проекта:
○ Структура – всё, что физически составляет продукт.
○ Функционал – всё, что продукт делает.
○ Данные – всё, что продукт обрабатывает.
○ Интерфейсы – все способы взаимодействия с продуктом.
○ Платформа – всё, находящееся вне проекта, от чего зависит продукт.
○ Операции – как продукт может быть использован.
○ Время – любые зависимости продукта от времени.
● Quality criteria (критерии качества). Здесь указываются критерии качества, важные для
продукта. Категории критериев:
○ Возможности. Выполняет ли он все требуемые функции?
○ Надёжность. Будет ли он работать стабильно и правильно обрабатывать ошибки во
всех требуемых ситуациях?
○ Удобство использования. Насколько продукт удобен в использовании?
○ Харизма. Насколько привлекателен продукт?
○ Безопасность. Насколько продукт защищён от несанкционированного доступа и
взлома?
○ Масштабируемость. Насколько легко выполнить масштабирование приложения вверх
или вниз?
○ Совместимость. Насколько хорошо ПО взаимодействует со внешними компонентами и
конфигурациями?
○ Производительность. Насколько быстро работает продукт?
© geekbrains.ru 8

○ Способность к установке. Насколько просто он устанавливается на необходимых

платформах?
○ Разработка. Насколько просто его разрабатывать, тестировать и модифицировать?
● Test techniques (техники тестирования). Здесь перечисляются техники тестирования,
которые, на Ваш взгляд, подходят и применимы для тестирования продукта. Например, такие:
○ функциональное тестирование;
○ тестирование требований;
○ доменное тестирование;
○ пользовательское тестирование;
○ стресс-тестирование;
○ тестирование рисков;
○ тестирование потоков;
○ автоматизированное тестирование;
○ тестирование сценариев.
● Perceived Quality (ожидаемое качество). Здесь указывается ожидаемый результат
тестирования, то есть какого уровня качества планируется достигнуть. Получается, что это
аналог критериев окончания тестирования.
Эту модель стратегии удобно представлять в виде интеллект-карты. Майкл Ларсен предложил
следующий вариант описания стратегии: в центре – стратегия тестирования, первым уровнем
декомпозиции являются основные части стратегии:
Окружение проекта на этой схеме представляется следующим образом:
То есть окружение проекта включает в себя практические результаты, тестируемые элементы,

график, инструментальные средства, заказчиков, информацию, связь с разработчиками, команду.
Техники тестирования в этой схеме представлены следующим образом:
© geekbrains.ru 9

Элементы продукта:
Функциональные критерии:
Критерии разработки:
Оригинальную полную карту можно посмотреть тут

.
Например, как может быть представлено окружение какого-либо проекта (объяснить схему):
© geekbrains.ru 10

Техники тестирования:
© geekbrains.ru 11

Элементы продукта:
Учёт нефункционального тестирования

Что проверяет нефункциональное тестирование
Нефункциональные требования – это такие требования, которые не относятся к функциям ПО. Это
могут быть требования к эргономике и эстетике, надёжности, скорости работы и пр.
В первую очередь тестировщики всегда проверяют функциональные требования, т. е. что

приложение правильно выполняет все свои функции. Следующим этапом идёт, как правило, проверка
того, что приложение правильно реагирует на некорректные действия пользователя, при этом не
падает, не повреждает данные, грамотно выводит сообщения об ошибках. И уже в самом конце
уделяется время (если оно вообще остаётся) для того, чтобы проверить всё остальное. Что же
проверяется?
● Скорость работы ПО – насколько быстро выполняются функции в ПО. Дело в том, что
пользователям часто бывает очень важно, чтобы ПО работало быстро, если же это не так,
они могут просто отказаться от использования «тормозного» продукта. При тестировании
скорости работы ПО проверяется:
○ скорость выполнения длительных операций;
○ скорость отклика интерфейса;
○ сколько операций можно выполнить в единицу времени.
● Работа под нагрузкой. Тестирование под нагрузкой применимо только для клиент-серверных
приложений. Для приложений, с которыми может работать онлайн одновременно множество
пользователей, тестировать под нагрузкой до выхода в релиз очень важно. Например,
пользователь очень хотел попасть на портал, чтобы написать сообщение в техподдержку,
потому что у него возникла проблема с использованием программы, и он не может
продолжать свою работу. Но когда он пытается открыть сайт техподдержки, браузер
показывает, что сайт недоступен. Другим способом пользователь не может связаться с
техподдержкой, поэтому его работа стоит, и это его совсем не радует. То же самое, если он
пытается создать сообщение, но при этом портал жутко тормозит. Это особенно неприятно,
если повторяется из раза в раз, и из-за этого невозможно работать с сайтом. Такие проблемы
могут возникать из-за того, что сайт не может поддерживать нужное количество одновременно
подключённых пользователей. Чтобы избежать этих проблем, нужно проверить:
○ максимальное количество одновременных подключений. Проверяется, сколько
пользователей могут одновременно подключиться к сайту и выполнять там какие-либо
действия. Далее следует сравнить это значение с предполагаемым количеством
пользователей, которые одновременно будут подключаться к сайту;
© geekbrains.ru 12

○ скорость работы при большом количестве подключений. Делается замер скорости

выполнения каких-либо популярных операций при максимальном или близком к
максимальному количестве одновременных подключений;
○ количество ошибок и отказов. Считается количество ошибок и отказов во время
работы пользователя при определённой нагрузке и в определённый промежуток
времени.
● Удобство использования – это не только удачное расположение кнопок в приложении. Это
понятие гораздо шире. Например, вот что можно отнести к удобству использования:
○ скорость обучения. Проверяется, насколько быстро пользователи адаптируются к
интерфейсу приложения;
○ скорость использования. Например, в некоторых случаях бывает удобнее для
навигации использовать клавиатуру, а не мышь. Или, например, считыватель
штрих-кода на кассе магазина. Представьте, какие были бы очереди, если бы все
штрих-коды приходилось набирать вручную! Использование считывателя штрих-кодов
значительно ускоряет работу с приложением. Для некоторых приложений это может
быть очень важно – например, для систем поддерживающих процессы, требующие
большой скорости обслуживания (магазин, банк, почта, государственные услуги
и т. д.);
○ количество ошибок. Если в приложении нет критичных ошибок, то есть оно выполняет
свои функции, но встречается множество некритичных, мешающих работе с
приложением, это также может стать причиной недовольства пользователя;
○ эргономика. В приложении может быть плохо продумано расположение элементов
интерфейса. Например, важные и часто используемые функции могут быть
труднодоступными, если спрятаны слишком далеко, а это тоже отнимает время. Из
двух приложений, выполняющих абсолютно одни и те же функции, одно из которых
имеет сложный интерфейс, а другое – очень удобный, пользователи, естественно,
выберут второе;
○ внешний дизайн. Внешний вид также может быть важен. Например, может не
нравиться слишком яркий дизайн, отвлекающий от работы, или от которого быстро
устают глаза.
● Надёжность.Это постоянство, непрерывность работы. ПО делает надёжным:
○ возможность длительной работы без перезагрузки. Для некоторых систем это бывает
действительно важно, например для системы, поддерживающей непрерывное
производство;
○ работа в условиях постоянной и пиковой нагрузки. Проверяется, стабильно ли ПО
работает в условиях постоянной нагрузки – например, когда одновременно работает
50 пользователей. Проверяется также, как приложение ведёт себя в условиях пиковой
нагрузки (например, когда с приложением одновременно работает максимально
возможное количество пользователей), как часто случаются сбои, не повреждаются ли
данные;
○ правильная обработка нестандартных ситуаций. Сюда относятся различного рода
сбои, например сбои оборудования во время работы приложения, внезапное
отключение электричества, интернета, хакерские атаки. Приложение должно
сохранять данные, не повреждать их, кроме того, оно должно уметь восстанавливать
свою работу после сбоя;
○ освобождение ресурсов. Например, в браузере Mozilla Firefox в своё время был такой
баг, что после закрытия вкладок не освобождалась оперативная память. Открывая и
закрывая вкладки браузера, можно было напрочь «повесить» компьютер.
● Совместимость. Проверяется совместимость с различными средами, сторонними
системами:
○ поддержка различных окружений;
○ работа в различных условиях (например, по какой сети мы работаем: кабель, Wi-Fi,
bluetooth и т. д., разное качество приема/передачи данных по сети);
○ совместимость со сторонним ПО и внешними сервисами. Например, два антивируса
не могут правильно работать вместе на одном компьютере, поскольку используют
одни и те же ресурсы.
© geekbrains.ru 13

Как применять нефункциональное тестирование

Нужно ли тестировать все эти вещи – зависит от конкретного приложения, от того, что важно
пользователям этого приложения. Для нераспределенного приложения (например MS Paint)
нагрузочное тестирование не применяют.
Если это сайт рекламного агентства, то важно, чтобы он имел яркий, привлекающий внимание
дизайн. Остальные вещи заказчика могут не волновать, хотя иногда даже для такого сайта может
потребоваться тестирование нагрузки. Если же это банковское ПО, дизайн, наоборот, должен быть
максимально нейтральным, не отвлекающим. При этом должна быть высокая скорость работы с
приложением. Для банковского ПО очень важна также надёжность, то есть защита от некорректных
действий пользователей и хакерских атак. Также может быть важно проверить совместимость,
поскольку часто банковское ПО взаимодействует с другими системами и сервисами, например с
сервисом предоставления информации по кредитным историям или сервисом переводов денежных
средств за рубеж.
Если же это социальная сеть, то заказчику важно привлечь на сайт много людей. Это можно сделать,
например, приятным дизайном, удобством и скоростью работы. А если вы зарегистрировались в
социальной сети и, например, не можете открыть сообщение уже как 5 минут, то, скорее всего, вы
найдёте для себя другую, более быструю сеть. Или если дизайн не нравится, трудно найти кнопку,
чтобы, скажем, загрузить фото, это тоже может стать причиной ухода из этой социальной сети.
Случается такое, что при тестировании ПО очень много времени уделяется некритичным
функциональным багам, таким как, например, появление ошибки при 187-м нажатии на кнопку
«Сохранить». При этом для нефункционального тестирования совсем не остаётся времени. Но
правильно ли это?
Конкуренты могут скопировать функционал приложения, но скопировать дизайн и другие

нефункциональные характеристики очень сложно или почти невозможно. Поэтому приложения с
хорошей скоростью работы, удобным пользовательским интерфейсом, учитывающие особенности
своей области применения и желания пользователя сильно обходят на рынке своих конкурентов: они
как бы находятся на более высоком уровне качества.
Конечно, если это заказная разработка, сколько времени и ресурсов уделить нефункциональному
тестированию, решает заказчик. Тестировщик может только подобрать наиболее подходящие виды
тестирования к данному типу ПО и предложить их заказчику.
Если же всё-таки нефункциональное тестирование будет проводиться, это должно быть отражено в
тестовой стратегии: какие виды нефункционального тестирования будут применяться, как будет
проводиться тестирование, с какой целью, какие инструментальные средства будут использоваться и,
главное, когда начать и когда закончить – всё это нужно продумать заранее.
Таким образом, на этом уроке мы узнали, что такое стратегия тестирования, для чего она нужна,
какие известны способы описания стратегии тестирования, а также зачем нужно нефункциональное
тестирование и какое место оно занимает в стратегии тестирования и научились составлять
стратегию тестирования разными способами.
Домашнее задание
1. Представьте, что вам предстоит протестировать настольное приложение, которое
обрабатывает медиафайлы (любые форматы аудио- и видеофайлов). Это приложение может
их проигрывать (все стандартные функции, такие как остановка, воспроизведение, перемотка,
рандомное воспроизведение треков и пр.), записывать (звук, видео), сохранять записанные
файлы. Есть возможности составления и хранения плейлистов. Нужно попытаться
представить стратегию тестирования такого приложения: описать скоуп тестируемого
функционала, выбрать средства и техники для тестирования. Оформить стратегию можно
любым способом.
© geekbrains.ru 14

2. *Придумать стратегию для тестирования приложения Skype (продумать, какие типы

тестирования можно применить, какие техники тестирования, какие инструменты для этого
использовать). При составлении стратегии можно воспользоваться одним из трёх
рассмотренных методов анализа.
Дополнительные материалы
1. Тренинг Натальи Руколь о нефункциональном тестировании:
https://www.youtube.com/watch?v=ToG0cXXGtVk
2. J. Bach. Heuristic Test Strategy Model.
3. RUP Test Plan – h ttp://tmguru.ru/wp-content/uploads/2015/01/TestPlanTemplate_RUP.pdf
4. Explaining Heuristic Test Strategy Model in Two Minutes? –
https://www.youtube.com/watch?v=SNHWCD2qg3U
5. James Bach on testing in an agile software development team –
https://www.youtube.com/watch?v=vqwyMaHcjQE
6. Схема HTSM (Майкл Ларсен) –
https://drive.google.com/file/d/0B5BXUBD7GPkNSjZPaTVUMGNoT28/view?usp=sharing
Используемая литература
1. http://software-testing.ru/library/5-testing/207-2008-10-06-10-05-53
2. http://software-testing.ru/library/testing/test-management/2047-2015-03-18-07-17-46
3. http://www.luxoft-training.ru/blog/veni_vidi_vickie/511.html
4. http://tmguru.ru/baza-znanij/protsess-testirovaniya/planirovanie/strategiya-testirovaniya/
5. https://www.youtube.com/watch?v=ToG0cXXGtVk
6. http://tmguru.ru/wp-content/uploads/2015/01/TestPlanTemplate_RUP.pdf
7. http://www.satisfice.com/tools/htsm.pdf
8. http://www.slideshare.net/VLDCORP/decision-making-2305
9. http://project.dovidnyk.info/index.php/itil/podderzhkauslug/428-prilozhenie_6b-_analiz_kepnera_i_tre
go
10. http://ya-ann.livejournal.com/23500.html
11. http://www.pmtoday.ru/project-management/other-topics/root-cause-analyze.html
© geekbrains.ru 15

Скачано С Www.Sharewood.Biz - Присоединяйся!

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Скачано С Www.Sharewood.Biz - Присоединяйся!

Загружено:

Авторское право:

Доступные форматы

Стратегия

Цели и задачи стратегии тестирования

Процесс формирования стратегии

Как описать стратегию тестирования

RUP (Rational Unified Process)

Метод анализа проблем Кепнера и Трего

HTSM (Heuristic Test Strategy Model)

Учёт нефункционального тестирования

Что проверяет нефункциональное тестирование

Как применять нефункциональное тестирование