Пример фрагмента процедуры

Типы ошибок.

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

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

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

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

Все ошибки, которые возникают в программах, принято подразделять на следу-ющие классы:

– логические и функциональные ошибки — являются причиной нарушения логики алгоритма, внутренней несогласованности переменных и операторов, а также пра-вил программирования;

– ошибки вычислений и времени выполнения — возникают по причине неточности исходных данных и реализованных формул, погрешностей методов, неправильного применения операций вычислений или операндов;

– ошибки ввода–вывода и манипулирования данными — являются следствием некачественной подготовки данных для выполнения программы, сбоев при занесении их в базах данных или при выборке из нее;

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

– ошибки объема данных и др. — относятся к данным и являются следствием того, что реализованные методы доступа и размеры баз данных не удовлетворяют объемам информации системы или интенсивности ее обработки

Этапы тестирования ПО.

• модульное тестирование – тестируется минимально возможный для тестиро-вания компонент, например, отдельный класс или функция;

• интегрированное тестирование – проверяется, есть ли какие-либо проблемы в интерфейсах и взаимодействии между интегрируемыми компонентами, например, не передается информация, передается некорректная информация;

• системное тестирование – тестируется интегрированная система на соответствие исходным требованиям:

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

Ручное тестирование (manualtesting) — часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно проводится тестировщиками или обычными пользователи путем моделирования возможных сценариев действия пользователя.

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

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

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

Пример фрагмента процедуры

1. Подать на вход три разных целых числа;

2. Запустить тестовое исполнение;

3. Проверить, соответствует ли полученный результат таблице [ссылка на документ1] с учетом поправок [ссылка на документ2];

4. Убедиться в понятности и корректности выдаваемой сопроводительной информации.

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

Что такое тестирование Черного Ящика — это стратегия или метод тестирования, базируется только лишь на тестировании по функциональной спецификации и требованиям, при этом не смотря во внутреннюю структуру кода и без доступа к базе данных.

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

На данный момент такая стратегия является наиболее часто применима в IT компаниях.

Суть заключается в том, что для тестирования черным ящиком чтобы протестировать программу, не заглядывая «внутрь» как же там все работает. Нам достаточно знать, что должно быть при таком-то поведении пользователя и при таких-то наборах данных (зависит от специфики проекта)

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

Пример фрагмента процедуры

Тестирование методом белого ящика (также: прозрачного, открытого, стеклянного ящика; основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

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

Согласно ISTQB:

тестирование белого ящика – это:

– тестирование, основанное на анализе внутренней структуры компонента или системы.

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

Почему «белый ящик»? Тестируемая программа для тестировщика – прозрачный ящик, содержимое которого он прекрасно видит.

Пример:

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

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

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

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

– тестирование может производиться на ранних этапах: нет необходимости ждать создания пользовательского интерфейса;

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

Недостатки:

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

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

Пример фрагмента процедуры

Дмитрий Таль Перцептивная остеопатия 1 Пример лечебной процедуры


Похожие статьи.

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