Тестирование в Microsoft Solutions Framework

Если это так, то выполняются следующие действия.

1. Определение, не обнаружена ли аналогичная ошибка, т.е. прежде чем создать новую ошибку, проверить БД системы отслеживания ошибок, и убедиться, что проблема еще не идентифицирована;.если проблема уже была идентифицирована и ошибка обнаружена, обновить форму отслеживания ошибки соответствующим образом; если проблема уже опубликована и ошибка исправлена, изменить состояние рабочего элемента ошибки с "Исправлено" на "Найдено заново"; добавить новую информацию и документировать новые шаги для воспроизведения ошибки; документировать номер сборки, где было идентифицировано некорректное поведение.
2. Регистрация новой ошибки, т.е., если ошибка не опубликована и может быть воспроизведена, ввести шаги для воспроизведения ошибки и детали результатов выполнения этих шагов в рабочем документе; включить столько деталей, сколько возможно, чтобы помочь команде, ответственной за приоритеты ошибок, понять проблему; там, где это применимо, прикрепить тестовые ситуации, результаты, конфигурации, сценарий или требования к качеству к отчету по ошибке.
3. Назначение ошибки, т.е. определение главной области проблемы; если более чем одна область может быть задействована, то выбрать одну из них; назначение ошибки на владельца затронутой области приложения; сохранение ошибки в базе данных отслеживания ошибок.

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

Далее необходимо произвести исследовательское тестирование.

Исследовательское тестирование – систематический способ проверить продукт без предопределенного набора тестов. Существует множество эвристик, которые могут быть применены к проведению исследовательского тестирования. Эти эвристики включают в себя использование ролей, характеристики, переменный анализ, область поиска и тестирование различных состояний. Эвристика, обеспеченная этим руководством, описывает, как продукт протестирован с точки зрения определенной роли с целью создания новых требований. Для того, чтобы выполнить исследовательское тестирование таким образом, необходимо выбрать роль и работать через функциональные возможности системы, пытаясь достичь определённых целей. Если новые цели достигнуты или функциональные возможности не способны удовлетворить потребностей роли, добавить новые или модифицировать существующие сценарии для удовлетворения этих потребностей. Лимит сессий исследовательского тестирования – не более двух часов.

Этот этап производится, если сборка готова к тестированию на новые требования или ошибки и роли опубликованы на портале проекта..

Если это выполнено, то выполняются следующие действия.

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

В результате этих действий новые сценарии и/или требования будут добавлены для отражения нового понимания системы.

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

27.3.3.4.2. Тестирование требований к качеству

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

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

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

Далее необходимо написать тесты на производительность.

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

Если это сделано, то выполняются следующие действия.

1. Понимание цели теста, т.е. цель тестирования должна быть ясно определена (например, не должно быть существенного различия в отклике продукта для пользователей с разной скоростью подключения к Интернету). Выход теста должен быть ясно задокументирован и представлен в виде диапазона значений.
2. Специфицирование тестовых конфигураций, т.е. определение тестовых конфигураций; документирование любых отклонений результатов теста, которые зависят от тестовых конфигураций; документирование внешних условий, которые могут отразиться на времени тестирования.
3. Планирование тестирования, т.е. планирование тестовых условий, включая предпосылки и установленный сценарий; пересмотр сценария, чтобы определить области, где производительность критична, а где – нет.
4. Документирование тестовых шагов, т.е. перечисление тестовых шагов так, чтобы все тестировщики, которые выполняют рабочие тесты, выполняли каждый шаг одним и тем же образом; отказ перечисления тестовых шагов может отразиться в неправильном измерении работы; использование автоматизации для построения тестовых ситуаций там, где это возможно; добавление тестовых ситуаций в папку для требований к качеству и итерационных тестов; регистрирование тестов и обновление рабочего листа подхода к тестированию с любыми тестовыми данными или другими взглядами на тест.

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

Далее необходимо написать тесты безопасности.

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

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

Если это сделано, то выполняются следующие действия.

1. Исследование точки входа, т.е. идентифицирование точки входа системы и функциональности, отвечающей за защиту программы; сбор информации из модели угрозы, для определения ожидаемых направлений нападения; расположение по приоритетам точек входа и задание им уровней доверия.
2. Идентифицирование недостатков, т.е. написание тестовых примеров, использующих прямые и частично случайные тесты, чтобы попытаться обратиться к программе; применение направленных мер, нацеленных на обход определенных мер безопасности; полуслучайные нападения могут манипулировать форматом данных или протокола, чтобы проверить граничные условия или выявить ошибки приложения.
3. Слабости к эксплоитам, т.е.добавление тестовых примеров, эксплуатирующих любые обнаруженные уязвимости, чтобы попытаться обратиться к программе; принятие во внимание количество времени, необходимого для того, чтобы воспользоваться уязвимостью; сохранение этих ручных тестов в соответствующей папке; регистрация их; добавление всех необходимых тестовых данных в документ, описывающий подход к тестированию.

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

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

Далее необходимо провести выявление ошибки аналогично тому, как это делалось при тестировании сценариев.

Далее необходимо произвести исследовательское тестирование аналогично тому, как это делалось при тестировании сценариев.

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

27.3.3.4.3. Стрессовое тестирование

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

27.3.3.4.4. Закрытие ошибок

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

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

Для закрытия ошибки необходимо, чтобы она находилась в открытом состоянии и была указана для текущей версии программы

Сначала необходимо провести исправление ошибки.

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

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

Если это сделано, то выполняются следующие действия.

1. Попытка воспроизводить ошибку, т.е. следовать шагам выполнения, как первоначально сообщено в описании ошибки, чтобы попытаться воспроизвести ошибку.
2. Поиск неожиданного поведения системы, т.е. проводится изучение смежных функциональных возможностей и попытка найти неожиданное поведение системы, связанное с ошибкой (это особенно важно, если задача разработки не была осуществлена полностью).
3. Получение подробной информации об ошибке, т.е., если описание ошибки непонятное, запрашивать у разработчика дополнительную информацию.
4. Переназначение ошибки, т.е., если тестовый пример не выполняется, то ошибка переназначается назад разработчику.

Далее необходимо провести собственно закрытие ошибки.

Для закрытия ошибки необходимо, чтобы сборка с исправленной ошибкой была обнаружена и тест, который обнаружил ошибку, выполнен; было решено не исправлять ошибку из-за ограничений на времени или ошибка была сдублирована и не может быть воспроизведена или будет задержана к другому релизу.

Если это сделано, то выполняются следующие действия.

1. Обновление дубликата ошибки, т.е., если ошибка является дубликатом существующей, необходимо обновить описание.
2. Новая ошибка не будет исправлена, т.е., если ошибка не должна быть исправлена, обновите описание ошибки, указав причину.
3. Ошибка исправлена, т.е., если, после выполнения шагов по воспроизведению ошибки, она не повторилась, закройте ошибку; укажите в описании ошибки сборку, используемую для проверки исправления, чтобы проконтролировать описание ошибки.

В результате закрытия ошибки, она будет закрыта в системе отслеживания ошибки с описанием поведения после исправления или объяснения того, почему ошибка не была устранена.

В результате закрытия ошибка будет закрыта с соответствующим кодом причины.