Тестирование способности к восстановлению

↑

▷ Содержание

⇐ ПредыдущаяСтр 2 из 3Следующая ⇒

Регрессионное тестирование – повторные тестирования функционала после внесения изменений и исправлений в приложение.

Тестирование безопасности – проверка, на сколько хорошо система защищена от неавторизованного доступа (внешнего и внутреннего).

Функциональное (динамическое, черного ящика) – проверка функционала.

6. Процесс разработки требований. Свойства и категории требований.

Требование (requirement) – описание того, что способна вып-ить с-ма, а также усл-я, необх-е для ее работы. Треб-я опред-ют то,что д. вып-ить с-ма, а не то, как этого добиться.

Процесс разработки требований состоит из след. этапов:

1. Опрос заказчика для выявл-я требов-й, к-рые он предъявляет к ПО.

2. Подготовка документа, содержащего определения требований.

3. Подготовка спецификаций требований. Спецификация – документ, который описывает требования на специальном языке (для программистов).

4. Подготовка матрицы прослеживаемости требований. Матрица – таблица, которая ставит в соответствие каждому требованию - компоненты кода – компоненты модулей – компоненты тестов.

5. Тестирование требований.

Опрос зак-ка производится в виде вопросов и ответов. Исп-ются слайды, макеты, чертежи, аналогичные проекты. Обмен инфы настолько важен, что затрачиваются значительные усилия и ср-ва на это. Присутствие специалиста по тестир-ю во время интервью позволяет узнать, как зак-к намерен исп-ть этот продукт, для того чтобы провести нужное реальное тест-ние. Для этого исп-ется: 1) метод JAD (join application development) совместная разработка приложений; 2) метод JAR (join application requirement) совместная разработка требований.

В рез-те проведения интервью с зак-ком надо извлечь соглашение относит-но приоритетов треб-й, т.е. каждое треб-е д.б. отнесено к одной из след. категорий:

· наиболее важное требование;

· требования, вып-ние к-рых желательно;

· требования, вып-ние к-рых желательно, но не обязательно.

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

1. Полнота. Набор треб-й счит-ся полным, если все его составные части представлены, и каждая часть выполнена в полном объеме. Треб-я не д. сод-ть выражений типа: и т.д., и прочее, подлежит дальнейшему определению, а также треб-я не д. ссылаться на несущ-вующие доки.

2. Однозначность. Треб-е д. содержать единственное толкование, а также д.б. удобочитаемым.

3. Непротиворечивость. Треб-я не д. противоречить друг другу.

4. Прослеживаемость. Каждое треб-е д.и. уник. идентификатор.

5. Осуществимость. Каждое треб-е д. ставить реально выполнимые задачи, как с функциональной точки зрения, так и с точки зрения времени и затрат ср-в на разработку.

6. Контролепригодность. Треб-я д.б.измеряемыми в приемлемых усл.

Свойства требований

- Каждое требование должно иметь уникальный ID;

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

- Требования д. включать, как функциональные, так и нефункциональные требования. Функциональные – услуги и функции, предоставляемые продуктом. Нефункциональные – описывают ограничения, накладываемые на работу системы и стандарты, которым должна соответствовать программа.

Категории требований.

1. Функциональное средство – набор требований, кот определяет, какие функции д. выполнять данный ПП на системном или пользовательском уровне.

2. Интерфейсы – категория требований описывает входы, получаемые из внешней среды, и выходы, направленные на внешнюю систему. Также указывается, накладываются ли на эти интерфейсы какие-то ограничения, связанные с форматами данных и носителями информации.

3. Данные – описывают входные и выходные данные системы. Какой при этом используется формат, какие данные н. сохранить, какой объем данных поступит из системы, с какой точностью должны выполняться вычисления.

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

5. Польз-ли и чел-ий фактор – описаны треб-я к тем, кто будет раб-ть с прогой, их квалиф-я, опыт, ур-нь удобства и простоты испыт-я.(ск-ко отдел. действий треб-ся для вып-я опер-ии в системе).

6. Физическая среда – где должна функционировать система (температура, влажность).

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

8. Документация – в каком виде д.б. документация (печатном или электронном) и для кого она предназначена.

9. Устранение неисправностей – как система д. реагировать на возникновение сбоя (аварийный сигнал, сообщений) время простоя до зависания.

10. Сопровождение и план поставки версий – как и кем производится поставка новых версий.

Спецификация требований.

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

Спецификация – документ, который описывает требования на специальном языке (понятном для программистов).

7. Хронологический порядок тестирования.

Хронология тестирования:

1. Создаются и тестируются отдельные элементы проги – 1-ая часть модульного тестирования (м-д белого ящика)

2. Эти эл-ты объединяются в одно целое, как подсистемы и тестируются (м-д черного ящика)

3. подсистемы объединяются в систему и тестируются (интеграционное тестирование)

4. Полученная сис-ма помещается в реальное окружение пользователя и подвергаются тестированию (функциональное тестирование).

5. Эти системные тесты сохраняются для повторного выполнения в случае внесения изменений (регресионное тестирование)

Модульное тестирование (пункт 1) – тестированию подвергается внутренние рабочие части программы, элементы или модули, независимо от способа их вызова.

Этапы модульного тестирования.

1. Планирование модульного тестирования;

2. Разработка тестов;

3. Формирование отладочных заданий;

4. Процесс тестирования;

5. Обработка результатов тестирования;

Модульное тестирование и его методы

Юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже написанных и оттестированных местах программы, а также облегчает локализацию и устранение таких ошибок.

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

Методы модульного тестирования:

1) по степени автоматизации: ручные, автоматизированные.

2) по форме представления модуля: тест-е программ, написанных на языке программирования; -//- на машинном коде.

3) по компонентам программы, на которое направлено тестирование: тест-е структуры программы; тест-е преобразования данных.

4) по запускаемости модуля: динамическое, статическое.

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

1) обзор кода

2) тестирование структуры (диаграммы Чейпина, диаграммы Неси-Шнайдермана, ориентированные графы Мак-Кейна).

3) тестирование обработки данных

4) функциональное тестирование

Цикломатическое число графа (метрический показатель сложности программы): G=R(ребра) – V(вершины) + 2 G>=15 недопустимо.

Преимущества:

Поощрение изменений

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

Упрощение интеграции

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

Документирование кода

Юнит-тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера.

Познавательные статьи:



Как правильно слушать собеседника

Типичные ошибки при выполнении бросков в баскетболе

Принятие христианства на Руси и его значение

Средства массовой информации США