Учебная работа. Курсовая работа: Тестирование информационных систем

Учебная работа. Курсовая работа: Тестирование информационных систем

Курсовая работа

Тестирование информационных систем

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. ОСНОВЫ ТЕСТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1. понятие «тестирования информационных систем»

1.2. Аспекты тестирования

1.3. Принципы тестирования

ГЛАВА 2. способы ТЕСТИРОВАНИЯ

2.1. Тестирование «белоснежного ящика»

2.2. Тестирование «темного ящика»

ГЛАВА 3. ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ системы «УЧЕБНО-МЕТОДИЧЕСКИЙ РЕСУРС»

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

приложение. ПРИМЕНЕНИЕ СТАНДАРТА IEEE STD 829 ПРИ ПЛАНИРОВАНИИ И ВЫПОЛНЕНИИ ФУНКЦИОНАЛЬНОГО И НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ВВЕДЕНИЕ

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

Главный задачей 90-х годов XX и начала XXI века сделалось улучшение свойства компьютерных приложений, способности которых полностью определяются программным обеспечением (ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств)).

Современный индивидуальный комп имеет производительность большенный ЭВМ (Электронная вычислительная машина — комплекс технических средств, предназначенных для автоматической обработки информации в процессе решения вычислительных и информационных задач) 80-х годов. Сняты фактически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств).

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

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

· наше умение строить программки отстает от требований к новеньким программкам;

· нашим способностям эксплуатировать имеющиеся программки грозит низкое свойство их разработки.

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

· управление проектом в виде координации усилий проектной команды, направленных на достижение целей проекта хорошим методом;

· постановка задачки в виде определения требований и следующих работ с ними;

· управление переменами в проекте: изменение может касаться как конкретно самих требований к системе, так и затрагивать организационную схему процесса, и могут порождаться или самим Заказчиком (бизнес-аналитиком) или являться следствием найденных в ИС изъянов;

· разработка ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств), как конкретное кодирование программной реализации многофункциональных требований и проектирование схем хранения и движения инфы в ИС;

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

· эксплуатация ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств) как сумма задач, направленная на обеспечение технической и технологической поддержки процесса работы ИС, включая поддержку и нужное системное администрирование.

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

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

В согласовании с целью были поставлены последующие задачки
:

1. проанализировать литературу по теме курсовой работы;

2. разглядеть и изучить понятие «тестирование программного обеспечения»;

3. выделить виды тестирования программного обеспечения;

4. изучить главные принципы и аспекты, предъявляемые к тестированию программного обеспечения;

5. изучить главные способы тестирования программного обеспечения;

6. протестировать на базе изученного материала информационную систему «Учебно-методический ресурс».

структура
курсовой работы: работа состоит из введения, 3-х глав, заключения, перечня литературы и 1-го приложения.

1-ая глава посвящена исследованию такового понятия, как «тестирование программного обеспечения».

2-ая глава посвящена исследованию способов тестирования, таковых как способ «белоснежного ящика» и способ «темного ящика».

В третьей главе рассматривается процесс тестирования фрагмента информационной системы «Учебно-методический ресурс».

ГЛАВА 1. ОСНОВЫ ТЕСТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1. понятие «тестирования информационных систем».

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

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

программка – это аналог обыкновенной формулы в арифметике.

Формула для функции f, приобретенной суперпозицией f1, f2, … fn – выражение, описывающее эту суперпозицию.

f=f1*f2*f3*…*fn

Если аналог f1, f2, … fn — операторы языка программирования, то их формула – программка.

Существует два способа обоснования истинности формул:

· Формальный подход

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

· Интерпретационный подход

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

Интерпретационный подход употребляется при экспериментальной
проверке соответствия программки собственной спецификации.

Применение интерпретационного подхода в форме тестов над

исполняемой программкой составляет сущность отладки и тестирования.

Отладка(
debug
,
debugging
)
– процесс поиска, локализации и исправления ошибок в программке. [6, c. 215]

термин «отладка» в российскей литературе употребляется двойственно: для обозначения активности по поиску ошибок (фактически тестирование), по нахождению обстоятельств их возникновения и исправлению, либо активности по локализации и исправлению ошибок.

Тестирование
– это процесс выполнения ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств) системы либо компонента в критериях анализа либо записи получаемых результатов с целью проверки (оценки) неких параметров тестируемого объекта. [11, c. 5]

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

Тестирование
– это контролируемое выполнение программки на конечном огромном количестве тестовых данных и анализ результатов этого выполнения для поиска ошибок. [7, c. 27]

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

Шаги процесса задаются тестами.

Любой тест описывает:

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

· Набор ожидаемых результатов работы программки.

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

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

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

Тестирование обеспечивает:

· Обнаружение ошибок.

· Демонстрацию соответствия функций программки ее предназначению.

· Демонстрацию реализации требований к чертам программки.

· Отображение надежности как индикатора свойства программки.

Тестирование не может показать отсутствие изъянов (оно может демонстрировать лишь присутствие изъянов). Принципиально держать в голове это утверждение при проведении тестирования.

Тестирование – принципиальная часть хоть какой программки контроля свойства, а часто и единственная. Это грустно, потому что различные методики совместной разработки разрешают отыскивать больше ошибок, чем тестирование, и в то же время обходятся наиболее чем в два раза дешевле в расчете на одну обнаруженную ошибку. Любой из отдельных шагов тестирования (блочное тестирование, тестирование компонент и интеграционное тестирование) обычно разрешают отыскать наименее 50% ошибок. Композиция шагов тестирования нередко приводит к обнаружению наименее 60% ошибок.

Если у программера спросить, какой из шагов разработки ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств) наименее всего похож на остальные, он наверное ответит: «Тестирование». По ряду обрисованных ниже обстоятельств большая часть разрабов испытывают при тестировании затруднения.

· Цель тестирования обратна целям остальных шагов разработки. Его целью является нахождение ошибок. Удачным считается тест, нарушающий работу ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств). Все другие этапы разработки ориентированы на предотвращение ошибок и недопущение нарушения работы программки.

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

· Тестирование не увеличивает свойства ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств) – оно показывает на свойство программки, но не влияет на него.

Виды тестирования.

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

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

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

· Интеграционное тестирование
– это совместное выполнение 2-ух либо наиболее классов, пакетов, компонент либо подсистем, сделанных несколькими программерами либо группами.

· Регрессивным тестированием
именуют повторное выполнение тестов, направленное на обнаружение изъянов в программке, уже прошедшей этот набор тестов.

· Тестирование системы
– это выполнение ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств) в его конечной конфигурации, интегрированного с иными программными и аппаратными системами.

Фазы тестирования.

Реализация тестирования делится на три шага:

1. Создание тестового набора (test
suite
) методом ручной разработки либо автоматической генерации для определенной среды тестирования (testing environment).

2. Прогон программки на тестах
, управляемый тестовым монитором (test monitor, test driver) с получением протокола тестирования (test log).

3. Оценка результатов выполнения программки на наборе тестов
с целью принятия решения о продолжении либо остановке тестирования.

1.2. Аспекты тестирования.

Можно выделить требования к безупречному аспекту тестирования:

· Аспект должен быть достаточным, т.е. демонстрировать, когда некое конечное огромное количество тестов довольно для тестирования данной программки.

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

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

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

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

Классы критериев:

· Структурные аспекты
употребляют информацию о структуре программки (аспекты так именуемого «белоснежного ящика»).

· Многофункциональные аспекты
формулируются в описании требований к программному изделию (аспекты так именуемого «темного ящика»).

· Аспекты стохастического тестирования
формулируются в определениях проверки наличия данных параметров у тестируемого приложения, средствами проверки некой статистической теории.

· Мутационные аспекты
нацелены на проверку параметров программного изделия на базе подхода Монте-Карло.

Структурные аспекты (класс

I

).

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

Структурные аспекты базируются на главных элементах УГП, операторах, ветвях и путях.

· Условие аспекта тестирования установок
(аспект С0) – набор тестов в совокупы должен обеспечить прохождение каждой команды не наименее 1-го раза. Это слабенький аспект, употребляется в огромных программных системах, где остальные аспекты применить нереально.

· Условие аспекта тестирования веток
(аспект С1) – набор тестов в совокупы должен обеспечить прохождение каждой ветки не наименее 1-го раза. Это довольно мощный и при всем этом экономный аспект. Данный аспект нередко употребляется в системах автоматизации тестирования.

· Условие аспекта тестирования путей
(аспект С2) – набор тестов в совокупы должен обеспечить прохождение всякого пути не наименее 1-го раза. Если программка содержит цикл (в индивидуальности с неявно данным числом итераций), то число итераций ограничивается константой (нередко – 2, либо числом классов выходных путей).

Структурные аспекты не инспектируют соответствие спецификации, если

оно не отражено в структуре программки.

Многофункциональные аспекты (класс

II

).

Многофункциональный аспект – важный для программной промышленности аспект тестирования. Он обеспечивает, до этого всего, контроль степени выполнения требований заказчика в программном продукте. Так как требования формулируются к продукту в целом, они отражают взаимодействие тестируемого приложения с окружением. При многофункциональном тестировании в большей степени употребляется модель «темного ящика». неувязка многофункционального тестирования – это, до этого всего, трудозатратность; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement Specification, Functional specification и т.п.), обычно, довольно объемны, тем не наименее, соответственная проверка обязана быть всеобъятной.

Ниже приведены личные виды многофункциональных критериев.

· Тестирование пт спецификации
— набор тестов в совокупы должен обеспечить проверку всякого тестируемого пт не наименее 1-го раза. Спецификация требований может содержать сотки и тыщи пт требований к программному продукту и каждое из этих требований при тестировании обязано быть испытано в согласовании с аспектом не наименее чем одним тестом.

· Тестирование классов входных данных
– набор тестов в совокупы должен обеспечить проверку представителя всякого класса входных данных не наименее 1-го раза. при разработке тестов классы входных данных сопоставляются с режимами использования тестируемого компонента либо подсистемы приложения, что приметно уменьшает варианты перебора, учитываемые при разработке тестовых наборов. Следует увидеть, что, перебирая в согласовании с аспектом величины входных переменных (к примеру, разные файлы – источники входных данных), мы обязаны использовать массивные тестовые наборы. Вправду, вместе с ограничениями на величины входных данных, есть ограничения на величины входных данных во различных композициях, в том числе проверка реакций системы на возникновение ошибок в значениях либо структурах входных данных. Учет этого обилия – процесс трудозатратный, что делает трудности для внедрения аспекта.

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

· Тестирование классов выходных данных
– набор тестов в совокупы должен обеспечить проверку представителя всякого выходного класса, при условии, что выходные результаты заблаговременно расклассифицированы, при этом отдельные классы результатов указывают, в том числе ограничения на ресурсы либо на время (time out).
При разработке тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента либо подсистемы, что приметно уменьшает варианты перебора, учитываемые при разработке тестовых наборов.

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

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

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

Стохастические аспекты (класс

III

).

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

· Создать программы-имитаторы случайных поочередных входных сигналов {x}.

· Вычислить независящим методом значения {y} для соответственных входных сигналов {y} и получить тестовый набор {X,Y}.

· Протестировать приложение на тестовом наборе {X,Y}, используя два метода контроля результатов:

1. Детерминированный контроль – проверка соответствия вычисленного значения значению y, приобретенному в итоге прогона теста на наборе {x} – случайной последовательности входных сигналов, сгенерированной имитатором.

2. Стохастический контроль – проверка соответствия огромного количества {}, приобретенного в итоге прогона тестов на наборе значений {x}, заблаговременно известному распределению результатов F(Y). В этом случае огромное количество y непонятно (его вычисление нереально), но известен законраспределения данного огромного количества.

Аспекты стохастического тестирования:

· Статистические способы
окончания тестирования – стохастические способы принятия решений о совпадении гипотез о распределении случайных величин. К ним принадлежат обширно известные: способ Стьюдента (St), способ Хи-квадрат (x2
) и т.п.

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

Мутационный аспект (класс

IV

).

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

Подход базируется на последующих понятиях:

Мутации
– маленькие ошибки в программке.

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

Способ мутационного тестирования
– в разрабатываемую программку P заносят мутации, т.е. искусственно делают программы-мутанты P1, P2…Потом программка P и ее мутанты тестируются на одном и том же наборе тестов {X,Y}.

Если на наборе {X,Y} подтверждается корректность программки P и, не считая того, выделяются все внесенные в программы-мутанты ошибки, то набор тестов (X,Y) соответствует мутационному аспекту, а тестируемая программка объявляется правильной.

Если некие мутанты не выявили всех мутаций, то нужно расширять набор тестов (X,Y) и продолжать тестирование.

1.3. Принципы тестирования

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

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

· Неэффективность имеющихся технологий тестирования.

Обычный подход был кропотливо разработан для пакетных и символьно-ориентированных диалоговых Кобол-приложений, но сейчас системы конструктивно поменялись: произошел переход от цельных программ к фрагментированным модулям на С, С++ и/либо Java. Данный тип разработки наращивает число компонент приложения и сложность их взаимодействия, что понижает эффективность тестирования, основанного на коде.

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

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

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

Обычный подход приводит к выделению половины (а время от времени и наиболее) экономных средств только на тестирование [2]. Недочет ресурсов и плана имеющихся технологий тестирования может сталкиваться с сокращением бюджета и срока разработки, заставляя в худшем случае совершенно отрешаться от тестирования. Эта ситуация довольно небезопасна, если учитывать вырастающую роль программного обеспечения в современном бизнесе. Разрабам нужен новейший подход к тестированию, который отвечал бы требованиям сложных приложений и подразумевал исправление ошибок как можно ранее. Это дает импульс к преобразованию процесса тестирования: от тестирования по окончании кода, к тестированию в протяжении всего процесса разработки.

· Новейший подход к процессу тестирования.

Тестирование обязано посодействовать отыскивать и исправлять ошибки на самой ранешней вероятной стадии. Пересмотр процесса тестирования включает определение концептуальной структуры, организующей разные технологии тестирования. Среда для этого процесса построена на концепции «стадийной локализации» (stage containment), другими словами обнаружении и исправлении ошибок на той стадии, где они и возникли.

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

При новеньком подходе тестирование обязано стать наиболее производительным и действенным. Буквально определенные приемы поддерживают процесс действенного тестирования методом внедрения надежных способов и уменьшения дублирования меж тестами на различных стадиях. Соответствие критерий тестирования специфике его стадий, так же как и фазам разработки, поддерживает высочайшее свойство тестирования тем, что каждое условие проверяется лишь один раз. Результатом внедрения стадийной локализации в процессе тестирования является V-модель, которая описывает структуру мероприятий верификации, утверждения и тестирования на базе спецификаций. Эта структура организует мероприятия разработки – такие, как формальные проверки, обзоры (reviews) и формальное тестирование.

Как практический подход V-модель была испытана и использовалась наиболее 15-ти лет [3]. Эта методика соотносит стадии разработки с отдельными стадиями тестирования. С ее помощью можно буквально найти границы применимости и предназначения всякого теста по его соответственной спецификации. Это помогает избежать неэффективности почти всех приемов тестирования, включая перекрытие тестовых критерий и проведение тех же тестов, но на различных уровнях. V-модель содержит три тестирующих деяния: верификацию (verification), проверку на правильность (validation) и фактически тестирование (testing).

1. Верификация.

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

2. Проверка на правильность.

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

3. Тестирование, основанное на спецификациях.

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

Применимость

V

-модели.

Значимость V-модели была продемонстрирована в проектах, использовавших несколько разных стилей разработки. В случае резвой разработки (rapid development) V-модель помогает найти процесс проверки правильности, который нужно делать для каждой итерации разработки. В предстоящем это наращивает необходимость определения каждой итерации в определениях «тестовых» требований. Для объектной разработки (object development) V-модель обеспечивает базу для организации тестирования на уровнях класса и компонента.

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

1. нужно заблаговременно разрабатывать планы для тестирования.

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

2. Определение стадий разработки и тестирования.

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

3. Определение критериев входа и выхода.

Аспекты хода и выхода определяются для тех моментов, когда стадия начинается и завершается. Руководители работ должны найти их во время планирования проекта. Применение критериев улучшает продвижение проекта со стадии на стадию. Выполнение критериев входа и выхода значит, что проект вправду продвигается вперед, а создатели не попросту «заметают» свои ошибки «под ковер» последующей стадии.

4. нужно найти условия теста как можно ранее.

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

5. Управление метриками тестирования.

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

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

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

7. Вовлечение заказчика в процесс разработки.

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

8. Организация установок в рабочие бригады.

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

9. Определение архитектуры тестирования.

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

10. нужно отлично употреблять инструменты тестирования.

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

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

ГЛАВА 2. способы ТЕСТИРОВАНИЯ.

2.1. Тестирование «белоснежного ящика»

Известна:

внутренняя структура программки.

Исследуются:

внутренние элементы программки и связи меж ними.

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

Индивидуальности тестирования «белоснежного ящика».

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

В этом случае формируются тестовые варианты, в каких:

· Гарантируется проверка всех независящих маршрутов программки.

· Находятся ветки True, False для всех логических решений.

· Производятся все циклы (в границах их границ и диапазонов).

· Анализируется корректность внутренних структур данных.

Недочеты
тестирования «белоснежного ящика»:

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

.

При n=5 и k=20 количество маршрутов m=1014
. Примем, что на разработку, выполнение и оценку теста по одному маршруту расходуется 1 мс. Тогда при работе 24 часа в день 365 дней в году на тестирование уйдет 3170 лет.

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

· В программке могут быть пропущены некие маршруты.

· недозволено найти ошибки, возникновение которых зависит от обрабатываемых данных.

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

· количество ошибок мало в «центре» и очень на «периферии» программки.

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

· При записи метода программного обеспечения в виде текста на языке программирования может быть внесение типовых ошибок трансляции (синтаксических и семантических).

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

Любая из этих обстоятельств является аргументом для проведения тестирования по принципу «белоснежного ящика». Испытания «темного ящика» не сумеют реагировать на ошибки таковых типов.

метод тестирования базисного пути.

Тестирование базисного пути
– это метод, который основан на принципе «белоснежного ящика». Создатель этого метода – Том МакКейб (1976).

метод тестирования базисного пути дает возможность:

· Получить оценку всеохватывающей трудности программки.

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

Тестовые варианты разрабатываются для проверки базисного огромного количества путей (маршрутов) в программке. Они гарантируют однократное выполнение всякого оператора программки при тестировании.

Потоковый граф.

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

· Граф строится отображением управляющей структуры программки. В процессе отображения закрывающие скобки условных операторов и операторов циклов рассматриваются как отдельные (фиктивные) операторы.

· Узлы (верхушки) потокового графа соответствуют линейным участкам программки, включают один либо несколько операторов программки.

· Дуги потокового графа показывают поток управления в программке (передачи управления меж операторами). Дуга – это направленное ребро.

· Различают операторные и предикатные узла. Из операторного узла выходит одна дуга, а из предикатного – две дуги.

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

· Замкнутые области, образованные дугами и узлами, именуют регионами.

· Окружающая граф среда рассматривается как доп регион.

Цикломатическая сложность.

Цикломатическая сложность – метрика программного обеспечения, которая обеспечивает количественную оценку логической трудности программки. В методе тестирования базисного пути цикломатическая сложность описывает:

· количество независящих путей в базисном огромном количестве программки.

· Верхнюю оценку количества тестов, которое гарантирует однократное выполнение всех операторов.

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

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

Характеристики базисного огромного количества:

· Испытания, обеспечивающие его проверку гарантируют:

1. однократное выполнение всякого оператора;

2. выполнение всякого условия по True-ветви и по False-ветви.

· Мощность базисного огромного количества равна цикломатической трудности потокового графа.

Цикломатическая сложность рассчитывается одним из 3-х методов:

· Цикломатическая сложность равна количеству регионов потокового графа.

· Цикломатическая сложность определяется по формуле
V(G)=E – N + 2, где E – количество дуг, N – количество узлов потокового графа.

· Цикломатическая сложность формируется по выражению V(G)=p+1, где p — количество предикатных узлов в потоковом графе G.

Шаги метода тестирования базисного пути.

· На базе текста программки формируется потоковый граф:

1. нумеруются операторы текста.

2. делается отображение пронумерованного текста программки в узлы и верхушки потокового графа.

· Определяется цикломатическая сложность потокового графа – по каждой из 3-х формул.

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

· Подготавливаются тестовые варианты, инициирующие выполнение всякого пути.

Любой тестовый вариант формируется в последующем виде:

Начальные данные (ИД):

Ожидаемые результаты (ОЖ.РЕЗ.):

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

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

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

Методы тестирования критерий.

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

Разглядим применяемую тут терминологию.

Обычное условие – булева переменная либо выражение дела.

Выражение дела имеет вид

E1<оператор дела>E2,

Где E1, E2 – арифметические выражения, а в качестве оператора дела употребляется один из последующих операторов:

Составное условие состоит из нескольких обычных критерий, булевых операторов и круглых скобок. Будем использовать булевы операторы OR, AND (&), NOT. Условия, не содержащие выражений дела, именуют булевыми выражениями.

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

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

· Ошибка булева оператора (наличие неправильных/ отсутствующих/ лишних булевых операторов).

· Ошибка булевой переменной.

· Ошибка оператора дела.

· Ошибка арифметического выражения.

Метод тестирования критерий нацелен на тестирование всякого условия в программке. методика тестирования критерий имеют два плюсы. Во-1-х, довольно просто выполнить измерение тестового покрытия условия. Во-2-х, тестовое покрытие критерий в программке – это фундамент для генерации доп тестов программки.

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

Существует несколько методик тестирования критерий.

Простая методика – тестирование веток. Тут для составного условия С проверяется:

· каждое обычное условие;

· True-ветвь;

· False-ветвь.

Иная методика – тестирование области определения в ней для выражения дела требуется генерация 3-4 тестов. Выражение вида

Е1<оператор дела>Е2

проверяется 3-мя тестами, которые сформировывают

Если оператор дела неправилен, а Е1 и Е2 корректны, то эти три теста гарантируют обнаружение ошибки оператора дела.

Для определения ошибок в Е1 и Е2 тест должен сформировать

метод тестирования потоков данных.

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

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

Пусть имеется потоковый граф программки с управляющими и информационными связями.

Под определением данных
соображают деяния, изменяющие элемент данных.

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

Назовем DU
-цепочкой (цепочкой определения-использования)
систему [x, i, j], где i, j – имена вершин; x определена в i-й верхушке и употребляется в j-й верхушке.

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

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

Шаги метода
DU
-тестирования:

· построение управляющего графа программки;

· построение информационного графа;

· формирование полного набора DU-цепочек;

· формирование полного набора отрезков путей в управляющем графе;

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

· подготовка тестовых вариантов.

Плюсы DU-тестирования:

· простота нужного анализа операционно-управляющей структуры программки;

· простота автоматизации.

Недочет DU-тестирования: трудности в выборе малого количества очень действенных тестов.

Область использования DU-тестирования: программки со вложенными условными операторами и операторами цикла.

Тестирование циклов.

Цикл – более всераспространенная система алгоритмов, применяемых в ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств). Тестирование циклов делается по принципу «белоснежного ящика», при проверке циклов основное внимание обращается на корректность конструкций циклов.

Различают 4 типа циклов: обыкновенные, вложенные, объединенные, неструктурированные.

Обыкновенные циклы.

Для проверки циклов с количеством повторений n может употребляться один из последующих наборов тестов:

· прогон всего цикла;

· лишь один проход цикла;

· два прохода цикла;

· m проходов циклов, где m<n;

· n-1, n, n+1 проходов цикла.

Вложенные циклы.

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

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

· Выбирается самый внутренний цикл. Инсталлируются малые значения характеристик всех других циклов.

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

· Перебегают в последующий по порядку объемлющий цикл. Делают его тестирование. При всем этом сохраняются малые значения характеристик для всех наружных (объемлющих) циклов и типовые значения для всех вложенных циклов.

· Работа длится до того времени, пока не будут протестированы все циклы.

Объединенные циклы.

Если любой из циклов независим от остальных, то употребляется техника тестирования обычных циклов. При наличии зависимости (к примеру, конечное

Неструктурированные циклы.

Неструктурированные циклы тестированию не подлежат. Этот тип циклов должен быть переделан при помощи структурированных программных конструкций.

2.2. Тестирование «темного ящика»

Известны:
функции программки.

Исследуется:
работа каждой функции на всей области определения.

Основное пространство приложения тестов «темного ящика» — интерфейс ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств).

«Темный ящик»

Тестирование «темного ящика»

Эти испытания показывают:

· Как производятся функции программки.

· Как принимаются начальные данные.

· Как вырабатываются результаты.

· Как сохраняется целостность наружной инфы.

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

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

· Выявить такие входные данные, которые с высочайшей вероятностью принадлежат набору IT;

· Сконструировать такие ожидаемые результаты, которые с высочайшей вероятностью являются элементами набора OT.

В почти всех вариантах определение таковых тестовых вариантов основывается

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

Принцип «темного ящика» не альтернативен принципу «белоснежного ящика». Быстрее это дополняющий подход, который обнаруживает иной класс ошибок.

Тестирование «темного ящика» обеспечивает поиск последующих категорий ошибок:

· Неправильных либо отсутствующих функций;

· Ошибок интерфейса;

· Ошибок во наружных структурах данных либо в доступе к наружной базе данных;

· Ошибок черт (нужная емкость памяти и т.д.);

· Ошибок инициализации и окончания.

Подобные группы ошибок методами «белоснежного ящика» не выявляются.

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

Техника «темного ящика» нацелена на решение последующих задач:

· Сокращение нужного количества тестовых вариантов (из-за проверки не статистических, а динамических качеств системы);

· Выявление классов ошибок, а не отдельных ошибок.

метод разбиения по эквивалентности.

Разбиение по эквивалентности – самый пользующийся популярностью метод тестирования «темного ящика».

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

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

Классы эквивалентности могут быть определены по спецификации на программку.

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

Условие ввода может задавать;

· Определенное

· Спектр значений.

· Огромное количество определенных величин.

· Булево условие.

Сформулируем правила формирования классов эквивалентности.

1. если условие ввода задает спектр n…m, то определяется один допустимый и два недопустимых класса эквивалентности.

2. если условие ввода задает конкретное

3. если условие ввода задает огромное количество значений {a,b,c}, то определяется один допустимый и один недопустимый класс эквивалентности.

4. если условие ввода задает булево один недопустимый класс эквивалентности.

Опосля построения классов эквивалентности разрабатываются тестовые варианты.

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

Метод анализа граничных значений.

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

Главные отличия анализа граничных значений от разбиения по эквивалентности:

· тестовые варианты создаются для проверки лишь ребер классов эквивалентности.

· При разработке тестовых вариантов учитывают не только лишь условия ввода, да и область вывода.

Сформулируем правила анализа граничных значений.

1. если условие ввода задает спектр n…m, то тестовые варианты должны быть построены:

1. для значений n и m.

2. для значений чуток левее n и чуток правее m на числовой оси.

2. Если условие ввода задает дискретное огромное количество значений, то создаются тестовые варианты:

1. для проверки малого и наибольшего из значений.

2. для значений чуток меньше минимума и чуток больше максимума.

3. Правила 1 и 2 используются к условиям области вывода.

4. Если внутренние структуры данных программки имеют предписанные границы, то разрабатываются тестовые варианты, повторяющие эти структуры на их границах.

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

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

Метод диаграмм причин-следствий.

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

Шаги метода:

· Для всякого модуля перечисляются предпосылки (условия ввода либо классы эквивалентности критерий ввода) и следствия (деяния либо условия вывода). Каждой причине и следствию присваивается собственный идентификатор.

· Разрабатывается граф причинно-следственных связей.

· Граф преобразуется в таблицу решений.

· Столбцы таблицы решений преобразуются в тестовые варианты.

ГЛАВА 3. ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ системы «УЧЕБНО-МЕТОДИЧЕСКИЙ РЕСУРС»

В качестве практической части нам было предложено протестировать фрагмент информационной системы «Учебно-методический ресурс», а конкретно – регистрацию юзеров. Потому что информационная система «Учебно-методический ресурс» представляет собой WEB-веб-сайт, то также было предложено протестировать и навигацию веб-сайта.

Нами был избран таковой способ тестирования, как способ «темного ящика». Это обосновано тем, что тестированием кода программки занимался конкретно разраб кода. Им был написан файл регистрации reg.php. В итоге работы файла на главной страничке информационной системы возникает последующая форма.

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

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

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

Опосля проведения регистрации мы попадаем на главную страничку веб-сайта и узнаем его содержание и структуру.

Для тестирования фрагмента информационной системы «Учебно-методический ресурс» нами была выбрана возможность сотворения курса лекций 1-го предмета.

На главной страничке указывается количество лекций. В нашем случае их количество – 3. Нажатием клавиши «Лекции» вызывается форма, содержащая пустые поля для ввода наименования лекции и пути, по которому находится файл с конкретно содержанием (текстом) лекции. Файл с лекцией должен быть написан в редакторе текста Microsoft Office Word и сохранен как интернет-страница с фильтром, по другому могут появиться ошибки в формировании конечной странички. В итоге проделанных действий обязана формироваться Интернет-страница, содержащая все лекции, обозначенные юзером. В нашем случае формирование странички происходит удачно, и мы получаем Интернет-страницу с 3-мя лекциями с данными наименованиями и с верным содержимым.

Кроме тестирования Интернет-страниц информационной системы «УМР» выполнялось зрительное тестирование начального кода сценария reg.php. Проверка данного файла осуществлялась с помощью редактора PHP Expert Editor.

файл
сценария
reg.php

<?php

session_start();

// ñîçäàåì íîâóþ ñåññèþ èëè

// âîññòàíàâëèâàåì òåêóùóþ

$err_msg = array(«lname»=>»Ôàìèëèÿ:», «fname»=>»Èìÿ», «oname»=>»Îò÷åñòâî», «pass»=>»Íå âåäåí ïàðîëü