Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
124563.rtf
Скачиваний:
33
Добавлен:
26.08.2019
Размер:
1.32 Mб
Скачать
      1. Категории тестов

Опытные тестеры в состоянии сразу же создать оригинальные тесты, так как они думают обо всех вариантах состояний ввода. Вытекающих из категорий тестов. Применение категорий тестов ко всем возможным входным условиям помогает определить тесты. Для каждой категории тестов тестер должен подумать над вопросом: «Каких результатов следует ожидать при данных условиях?» Конечно, не всякая категория применима в любых обстоятельствах.

Категории тестов, рассматриваемые при разработке тестовых примеров, включают следующие ситуации:

- нет данных;

- повторное выполнение;

- верные данные;

- неверные данные;

- сброс;

- потеря мощности;

- создание напряжений в системе;

- тестирование характеристик;[1]

- ошибки, описки и нарушения логики в сообщениях, выдаваемых программой.

  1. Категория тестов «Нет данных».

Возможные вопросы:

- Как можно «подвесить» систему?

- Что случится, если не ввести данные?

- Что означает утаивание данных?

- Каково значение или состояние по умолчанию?

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

Хорошо, что требования определяют ожидаемые результирующие данные. Когда данные отсутствуют, система может повести себя следующим образом:

- отправить сообщение об ошибке;

- установить значение, заданное по умолчанию;

- повторно использовать предыдущие данные или состояние;

- напомнить пользователю об отсутствии данных;

- аннулировать транзакцию;

- прервать выполнение.[1]

В проекте «Библиотека», если пользователь нажал клавишу <ENTER> без введенных данных, приложение расценивает это как неподдерживаемую команду и выводит сообщение «Неподдерживаемая команда».

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

  1. Категория тестов «Повторное выполнение»

Возможные вопросы:

- Что случится, если два раза подряд будут представлены одни и те же данные или же ввод будет сделан дважды?

- Что случится, если повторить предыдущее состояние?

В зависимости от типа приложения дублирование данных может означать повторное введение одних и тех же значений, двойное нажатие клавиши <ENTER> в одной строке, повторную отправку одного и того же пакета данных, запуск одной и той же команды (то есть любого действия, которое выполняется дважды).

Ожидается, что система может повести себя следующим образом:

- отправить сообщение об ошибке;

- перезаписать предыдущее значение или состояние;

- предложить пользователю подтвердить перезапись предыдущего значения или состояния;

- обработать второй запрос как отдельное независимое событие.[1]

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

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

  1. Категория тестов «Верные данные»

Возможные вопросы:

- Что такое верные экземпляры этих данных?

- Каков диапазон верных значений входных данных?

- Каковы граничные значения данных?

- Каков формат верного пакета?

- Какая информация передается при верной транзакции?

Тестовый пример, построенный на основе верных данных, подтверждает, что приложение корректно обрабатывает информацию. Значения неверных данных попадают в категорию «Неверные данные».[1]

В проекте «Библиотека», если пользователь ввел верные данные при добавлении читателя, книги, при выдаче книги, то создаются текстовые документы «readers.txt», «books.txt», «abonement.txt» соответственно. Также из требований известен образец ввода данных, однако какие данные являются верными не указано. Таким образом, требования неполны. Возникают вопросы:

- Какой формат ввода поля «Пол» (м и ж или муж и жен или мужской и женский)?;

- Может ли поле «Автор» содержать числовые значения?;

- Какой формат ввода даты возврата?

При последующей доработке проекта следует в требования добавить уточнения по этим вопросам.

  1. Категория тестов «Неверные данные»

Возможные вопросы:

- Что означает «выход за границы»?

- Каковы будут последствия?

- Что порождает неправильные данные в тестируемом приложении?

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

Примеры неверных данных для числовых полей могут быть следующие

- значения вне допустимого диапазона;

- отрицательные числа;

- десятичные дроби;

- на первой позиции – ноль или пробел;

- буквенно-цифровые сочетания знаков.

Примеры неверных данных для буквенно-числовых полей:

- на первой позиции – пробел;

- отличные от буквенно-цифровых знаки;

- нажатие специфических клавиш.

При неверных условиях система может вести себя следующим образом:

- отправить сообщение об ошибке;

- напомнить пользователь о корректных данных;

- повторно использовать предыдущее верное значение или состояние;

- отменить транзакцию;

- проигнорировать случившееся и попытаться обработать запрос как есть.[1]

В требованиях для рассматриваемого примера о неверных данных ничего не указано. Поэтому остаются без ответов следующие вопросы:

- Что случится, если пользователь введет не буквенные значения в поля «Фамилия», «Имя», «Отчество», «Жанр»?

- Что случится, если поле «Адрес» будет состоять только из числовых значений?

- Что случится, если в поля «Телефон», «Дата возврата», «Идентификатор» пользователь введет не числовые данные, отрицательные или дробные числа?

- Что случится, если пользователь введет в поле «Дата возврата» дату, которая была раньше «Даты выдачи»?

- Что случится, если при вводе значений в любое поле пользователь введет на первую позицию пробел, а для числовых – ноль?

- Что случится, если в поле «Пол», в которое предполагается вводить значения определенного формата, ввести что-либо отличное от данного формата?

- Что случится, если любое из полей будет пустым?

- Сколько читателей и книг можно добавить?

- Есть ли возможность удаления из файлов книг и читателе?

Для достижения должного уровня проекта в требования к данному приложению следует внести ответы на данные вопросы.

  1. Категория тестов « Сброс»

Возможные вопросы:

- Что случится, если пользователь нажмет клавишу <ESCAPE> или другой тип клавиши с функцией «стоп»?

- Что случится, если пользователь активизирует последовательность сброса?

- Что случится, если обработка данных остановиться прежде, чем будет выполнена задача?

- Что случится, если будет выдернут кабель?

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

- Какие этапы необходимы для восстановления системы после её аварийного отключения?

- Останутся ли какие-либо файлы в открытом состоянии?

Восстановление системы может принимать различные формы, например:

- перезагрузка системы;

- повторная инициализация приложения;

- переустановка приложения.[1]

  1. Категория тестов «»Потери мощности»

Возможные вопросы:

- Что случится, если в ходе обработки данных будет отключено питание или произойдет падение напряжения?

- Что случиться, если при запуске или восстановлении последовательности произойдет падение напряжения?

- Какие возможные сбои в аппаратном обеспечении?

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

  1. Категория тестов «Создание напряжений в системе»

Возможные вопросы:

- Что означает для тестируемой системы «слишком много»?

- Как можно перегрузить систему?

- Что случится, когда другие процессы потребуют совместного использования одного и того же ресурса?

- Какие существуют ограничения на обработку данных и на ресурсы?

- Можно ли в фоновом режиме запускать одновременно и другие процессы?

Создать напряжение в системе можно при помощи следующих методов:

- уменьшить доступную область памяти или дискового пространства;

- запустить параллельно несколько экземпляров приложения;

- очень быстро нажимать клавиши;

- выполнить огромное число повторений определенных действий или вводов;

- сгенерировать максимально возможное количество данных.

Реакция системы, в которой возникло экстремальное напряжение, может быть следующей:

- отличия не наблюдаемы;

- медленный ответ;

- выход системы из строя.[1]

  1. Категория тестов «Тестирование характеристик»

Возможные вопросы:

- Как пользователь обычно взаимодействует с системой?

- Как долго может выполняться задача?

- С какой нагрузкой может справиться система?[1]

  1. Категория тестов «Ошибки, описки и нарушение логики в сообщениях, выдаваемых программой»

Возможные вопросы:

- Содержат ли сообщения, которые выводит программа на действия пользователя, орфографические ошибки?

- Содержат ли эти сообщения описки?

- Правильно ли построено сообщение по смыслу?

В проекте «Библиотека» обнаружены следующие ошибки и описки:

- при успешной регистрации выдачи книги, приложение выводит сообщение: «Выдача успешно зарегестирована», где в слове «зарегистрирована» содержится две ошибки;

- при возникновении ошибки во время возврата книги программа выводит сообщение «Ошибка регустрации возвращенной книги. Возможно нет данных по этой книге». Здесь в слове регистрация содержится описка;

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

- если при возврате книги введен номер книги, о которой нет информации в файле «readers.txt», то выводится сообщение «Ошибка регистрации возвращенной книги. Возможно нет данных по этой книге». Во втором предложении данного сообщения содержится пунктуационная ошибка. Однако это предложение вообще использовать не следует, так как данные по книге либо есть в файле «readers.txt», если книга зарегистрирована, либо нет, если книга не была добавлена. Поэтому предположение о существовании книги не уместны.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]