Курсовая работа
Тестирование информационных систем
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ
ГЛАВА 1. ОСНОВЫ ТЕСТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ
1.1. Понятие «тестирования информационных систем»
1.2. Критерии тестирования
1.3. Принципы тестирования
ГЛАВА 2. МЕТОДЫ ТЕСТИРОВАНИЯ
2.1. Тестирование «белого ящика»
2.2. Тестирование «черного ящика»
ГЛАВА 3. ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ «УЧЕБНО-МЕТОДИЧЕСКИЙ РЕСУРС»
ЗАКЛЮЧЕНИЕ
СПИСОК ЛИТЕРАТУРЫ
ПРИЛОЖЕНИЕ. ПРИМЕНЕНИЕ СТАНДАРТА IEEE STD 829 ПРИ ПЛАНИРОВАНИИ И ВЫПОЛНЕНИИ ФУНКЦИОНАЛЬНОГО И НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ВВЕДЕНИЕ
Известно, что основной задачей первых трех десятилетий компьютерной эры являлось развитие аппаратных компьютерных средств. Это было обусловлено высокой стоимостью обработки и хранения данных. В 80-е годы успехи микроэлектроники привели к резкому увеличению производительности компьютера при значительном снижении стоимости.
Основной задачей 90-х годов XX и начала XXI века стало совершенствование качества компьютерных приложений, возможности которых целиком определяются программным обеспечением (ПО).
Современный персональный компьютер имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.
Чрезвычайно актуальными стали следующие проблемы:
· аппаратная сложность опережает наше умение строить ПО, использующие потенциальные возможности аппаратуры;
· наше умение строить программы отстает от требований к новым программам;
· нашим возможностям эксплуатировать существующие программы угрожает низкое качество их разработки.
Достаточно много материалов посвящено тому, как создаются информационные системы и реализуются проекты по разработке программного обеспечения. Авторы могут придерживаться различных методологий разработки, спорить о преимуществах того или иного подхода а планировании процессов или документировании процедур, а также гибкости последних, однако общая схема создания информационных систем достаточно проста и состоит как правило из одних и тех же модулей и процессов:
· управление проектом в виде координации усилий проектной команды, направленных на достижение целей проекта оптимальным путем;
· постановка задачи в виде определения требований и последующих работ с ними;
· управление изменениями в проекте: изменение может касаться как непосредственно самих требований к системе, так и затрагивать организационную схему процесса, и могут порождаться либо самим Заказчиком (бизнес-аналитиком) либо являться следствием обнаруженных в ИС дефектов;
· разработка ПО, как непосредственное кодирование программной реализации функциональных требований и проектирование схем хранения и движения информации в ИС;
· тестирование ПО – процесс, решающий задачу верификации соответствия требований выдвинутых к ИС и их программной реализации;
· эксплуатация ПО как сумма задач, направленная на обеспечение технической и технологической поддержки процесса работы ИС, включая поддержку и необходимое системное администрирование.
Как видим, процесс разработки ИС состоит из нескольких взаимосвязанных модулей, которыми уже в свою очередь и оперируют авторы методологий и подходов, смещая приоритеты между направлениями или смешивая задачи нескольких направлений (предлагая, к примеру, осуществление задач тестирования в рамках деятельности по непосредственной разработке программной реализации и т.д.). Суть остается прежней – есть технологическая цепочка процессов разработки информационных систем, модули которого взаимозависимы и не могут функционировать в отрыве друг от друга.
Цель
курсовой работы - рассмотреть подробно процесс тестирования как составляющую процесса обеспечения качества разработки ПО, а также теоретически обосновать основные положения данного процесса и проверить их практически на основе разработанной информационной системы «Учебно-методический ресурс».
В соответствии с целью были поставлены следующие задачи
:
1. проанализировать литературу по теме курсовой работы;
2. рассмотреть и изучить понятие «тестирование программного обеспечения»;
3. выделить виды тестирования программного обеспечения;
4. изучить основные принципы и критерии, предъявляемые к тестированию программного обеспечения;
5. изучить основные методы тестирования программного обеспечения;
6. протестировать на основе изученного материала информационную систему «Учебно-методический ресурс».
Структура
курсовой работы: работа состоит из введения, трех глав, заключения, списка литературы и одного приложения.
Первая глава посвящена изучению такого понятия, как «тестирование программного обеспечения».
Вторая глава посвящена изучению методов тестирования, таких как метод «белого ящика» и метод «черного ящика».
В третьей главе рассматривается процесс тестирования фрагмента информационной системы «Учебно-методический ресурс».
ГЛАВА 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% ошибок.
Если у программиста спросить, какой из этапов разработки ПО менее всего похож на другие, он наверняка ответит: «Тестирование». По ряду описанных ниже причин большинство разработчиков испытывают при тестировании затруднения.
· Цель тестирования противоположна целям других этапов разработки. Его целью является нахождение ошибок. Успешным считается тест, нарушающий работу ПО. Все остальные этапы разработки направлены на предотвращение ошибок и недопущение нарушения работы программы.
· Тестирование никогда не доказывает отсутствия ошибок. Отсутствие ошибок может указывать как на безупречность программы, так и на неэффективность или неполноту тестов.
· Тестирование не повышает качества ПО – оно указывает на качество программы, но не влияет на него.
Виды тестирования.
Тестирование – самая популярная методика повышения качества, подкрепленная многими исследованиями и богатым опытом разработки коммерческих приложений. Существует множество видов тестирования: одни обычно выполняют сами разработчики, а другие – специализированные группы. Виды тестирования перечислены ниже:
· Блочным тестированием
называют тестирование полного класса, метода или небольшого приложения, написанного одним программистом или группой, выполняемое отдельно от прочих частей системы.
· Тестирование компонента
– это тестирование класса, пакета, небольшого приложения или другого элемента системы, разработанного несколькими программистами или группами, выполняемое в изоляции от остальных частей системы.
· Интеграционное тестирование
– это совместное выполнение двух или более классов, пакетов, компонентов или подсистем, созданных несколькими программистами или группами.
· Регрессивным тестированием
называют повторное выполнение тестов, направленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов.
· Тестирование системы
– это выполнение ПО в его окончательной конфигурации, интегрированного с другими программными и аппаратными системами.
Фазы тестирования.
Реализация тестирования делится на три этапа:
1. Создание тестового набора (test
suite
) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testing environment).
2. Прогон программы на тестах
, управляемый тестовым монитором (test monitor, test driver) с получением протокола тестирования (test log).
3. Оценка результатов выполнения программы на наборе тестов
с целью принятия решения о продолжении или остановке тестирования.
1.2. Критерии тестирования.
Можно выделить требования к идеальному критерию тестирования:
· Критерий должен быть достаточным, т.е. показывать, когда некоторое конечное множество тестов достаточно для тестирования данной программы.
· Критерий должен быть полным, т.е. в случае ошибки должен существовать тест из множества тестов, удовлетворяющих критерию, который раскрывает ошибку.
· Критерий должен быть надежным, т.е. любые два множества тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы.
· Критерий должен быть легко проверяемым, например, вычисляемым на тестах.
Для нетривиальных классов программ в общем случае не существует полного и надежного критерия, зависящего от программ или спецификаций. Поэтому, как правило, стремятся к идеальному общему критерию через реальные частные.
Классы критериев:
· Структурные критерии
используют информацию о структуре программы (критерии так называемого «белого ящика»).
· Функциональные критерии
формулируются в описании требований к программному изделию (критерии так называемого «черного ящика»).
· Критерии стохастического тестирования
формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической теории.
· Мутационные критерии
ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.
Структурные критерии (класс
I
).
Структурные критерии используют модель программы в виде «белого ящика», что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Структурная информация понятна и доступна разработчикам подсистем и модулей приложения, поэтому данный класс критериев часто используется на этапах модульного и интеграционного тестирования.
Структурные критерии базируются на основных элементах УГП, операторах, ветвях и путях.
· Условие критерия тестирования команд
(критерий С0) – набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, используется в больших программных системах, где другие критерии применить невозможно.
· Условие критерия тестирования ветвей
(критерий С1) – набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий. Данный критерий часто используется в системах автоматизации тестирования.
· Условие критерия тестирования путей
(критерий С2) – набор тестов в совокупности должен обеспечить прохождение каждого пути не менее одного раза. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто – 2, или числом классов выходных путей).
Структурные критерии не проверяют соответствие спецификации, если
оно не отражено в структуре программы.
Функциональные критерии (класс
II
).
Функциональный критерий – важнейший для программной индустрии критерий тестирования. Он обеспечивает, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Поскольку требования формулируются к продукту в целом, они отражают взаимодействие тестируемого приложения с окружением. При функциональном тестировании преимущественно используется модель «черного ящика». Проблема функционального тестирования – это, прежде всего, трудоемкость; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement specification, Functional specification и т.п.), как правило, достаточно объемны, тем не менее, соответствующая проверка должна быть всеобъемлющей.
Ниже приведены частные виды функциональных критериев.
· Тестирование пунктов спецификации
- набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза. Спецификация требований может содержать сотни и тысячи пунктов требований к программному продукту и каждое из этих требований при тестировании должно быть проверено в соответствии с критерием не менее чем одним тестом.
· Тестирование классов входных данных
– набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза. при создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что, перебирая в соответствии с критерием величины входных переменных (например, различные файлы – источники входных данных), мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия – процесс трудоемкий, что создает сложности для применения критерия.
· Тестирование правил
– набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики. Следует заметить, что грамматика должна быть достаточно простой, чтобы трудоемкость разработки соответствующего набора тестов была реальной (вписывалась в сроки и штат специалистов, выделенных для реализации фазы тестирования).
· Тестирование классов выходных данных
– набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов указывают, в том числе ограничения на ресурсы или на время (time out). При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
· Тестирование функций
– набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза. Очень популярный на практике критерий, который, однако, не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту).
Критерий тестирования функций объединяет отчасти особенности структурных и функциональных критериев. Он базируется на модели «полупрозрачного ящика», где явно указаны не только входы и выходы тестируемого компонента, но также состав и структура используемых методов (функций, процедур) и классов.
· Комбинированные критерии для программ и спецификаций
– набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза. При этом все комбинации непротиворечивых условий надо подтвердить, а условия противоречий следует обнаружить и ликвидировать.
Стохастические критерии (класс
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-ветви.
· Мощность базового множества равна цикломатической сложности потокового графа.
Значение второго свойства трудно переоценить – оно дает априорную оценку количества независимых путей, которое имеет смысл искать в графе.
Цикломатическая сложность вычисляется одним из трех способов:
· Цикломатическая сложность равна количеству регионов потокового графа.
· Цикломатическая сложность определяется по формуле V(G)=E – N + 2, где E – количество дуг, N – количество узлов потокового графа.
· Цикломатическая сложность формируется по выражению V(G)=p+1, где p - количество предикатных узлов в потоковом графе G.
Шаги способа тестирования базового пути.
· На основе текста программы формируется потоковый граф:
1. нумеруются операторы текста.
2. производится отображение пронумерованного текста программы в узлы и вершины потокового графа.
· Определяется цикломатическая сложность потокового графа – по каждой из трех формул.
· Определяется базовое множество независимых линейных путей.
· Подготавливаются тестовые варианты, инициирующие выполнение каждого пути.
Каждый тестовый вариант формируется в следующем виде:
Исходные данные (ИД):
Ожидаемые результаты (ОЖ.РЕЗ.):
Исходные данные должны выбираться так, чтобы предикатные вершины обеспечивали нужные переключения – запуск только тех операторов, которые перечислены в конкретном пути, причем в требуемом порядке.
Реальные результаты каждого тестового варианта сравниваются с ожидаемыми результатами. После выполнения всех тестовых вариантов гарантируется, что все операторы программы выполнены по меньшей мере один раз.
Важно отметить, что некоторые независимые пути не могут проверяться изолированно. Такие пути должны проверяться при тестировании другого пути (как часть другого тестового варианта).
Способы тестирования условий.
Цель этого семейства способов тестирования – строить тестовые варианты для проверки логических условий программы. При этом желательно обеспечить охват операторов из всех ветвей программы.
Рассмотрим используемую здесь терминологию.
Простое условие – булева переменная или выражение отношения.
Выражение отношения имеет вид
E1<оператор отношения>E2,
Где E1, E2 – арифметические выражения, а в качестве оператора отношения используется один из следующих операторов:
Составное условие состоит из нескольких простых условий, булевых операторов и круглых скобок. Будем применять булевы операторы OR, AND (&), NOT. Условия, не содержащие выражений отношения, называют булевыми выражениями.
Таким образом, элементами условия являются: булев оператор
Если условие некорректно, то некорректен по меньшей мере один из элементов условия. Следовательно, в условии возможны следующие типы ошибок:
· Ошибка булева оператора (наличие некорректных/ отсутствующих/ избыточных булевых операторов).
· Ошибка булевой переменной.
· Ошибка оператора отношения.
· Ошибка арифметического выражения.
Способ тестирования условий ориентирован на тестирование каждого условия в программе. Методика тестирования условий имеют два достоинства. Во-первых, достаточно просто выполнить измерение тестового покрытия условия. Во-вторых, тестовое покрытие условий в программе – это фундамент для генерации дополнительных тестов программы.
Целью тестирования условий является определение не только ошибок в условиях, но и других ошибок в программах. Если набор тестов для программы A эффективен для обнаружения ошибок в условиях, содержащихся в A, то вероятно, что это набор также эффективен для обнаружения других ошибок в A. Кроме того, если методика тестирования эффективна для обнаружения ошибок в условиях, то вероятно, что эта методика будет эффективна для обнаружения ошибок в программе.
Существует несколько методик тестирования условий.
Простейшая методика – тестирование ветвей. Здесь для составного условия С проверяется:
· каждое простое условие;
· True-ветвь;
· False-ветвь.
Другая методика – тестирование области определения в ней для выражения отношения требуется генерация 3-4 тестов. Выражение вида
Е1<оператор отношения>Е2
проверяется тремя тестами, которые формируют значение Е1 большим, чем Е2, равным Е2 и меньшим, чем Е2.
Если оператор отношения неправилен, а Е1 и Е2 корректны, то эти три теста гарантируют обнаружение ошибки оператора отношения.
Для определения ошибок в Е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).
Любой способ тестирования «черного ящика» должен:
· Выявить такие входные данные, которые с высокой вероятностью принадлежат набору IT;
· Сформулировать такие ожидаемые результаты, которые с высокой вероятностью являются элементами набора OT.
Во многих случаях определение таких тестовых вариантов основывается
на предыдущем опыте инженеров тестирования. Они используют свое знание и понимание области определения для идентификации тестовых вариантов, которые эффективно обнаруживают дефекты. Тем не менее систематический подход к выполнению тестовых данных может использоваться как полезное дополнение к эвристическому знанию.
Принцип «черного ящика» не альтернативен принципу «белого ящика». Скорее это дополняющий подход, который обнаруживает другой класс ошибок.
Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:
· Некорректных или отсутствующих функций;
· Ошибок интерфейса;
· Ошибок во внешних структурах данных или в доступе к внешней базе данных;
· Ошибок характеристик (необходимая емкость памяти и т.д.);
· Ошибок инициализации и завершения.
Подобные категории ошибок способами «белого ящика» не выявляются.
В отличие от тестирования «белого ящика», которое выполняется на ранней стадии процесса тестирования, тестирование «черного ящика» применяют на поздних стадиях тестирования. При тестировании «черного ящика» пренебрегают управляющей структурой программы. Здесь внимание концентрируется на информационной области определения программной системы.
Техника «черного ящика» ориентирована на решение следующих задач:
· Сокращение необходимого количества тестовых вариантов (из-за проверки не статистических, а динамических аспектов системы);
· Выявление классов ошибок, а не отдельных ошибок.
Способ разбиения по эквивалентности.
Разбиение по эквивалентности – самый популярный способ тестирования «черного ящика».
В этом способе входная область данных программы делится на классы эквивалентности. Для каждого класса эквивалентности разрабатывается один тестовый вариант.
Класс эквивалентности – набор данных с общими свойствами. Обрабатывая разные элементы класса, программа должна вести себя одинаково. Иначе говоря, при обработке любого набора из класса эквивалентности в программе задействуется один и тот же набор операторов (и связей между ними).
Классы эквивалентности могут быть определены по спецификации на программу.
Класс эквивалентности включает множество значений данных, допустимых или недопустимых по условиям ввода.
Условие ввода может задавать;
· Определенное значение.
· Диапазон значений.
· Множество конкретных величин.
· Булево условие.
Сформулируем правила формирования классов эквивалентности.
1. если условие ввода задает диапазон n…m, то определяется один допустимый и два недопустимых класса эквивалентности.
2. если условие ввода задает конкретное значение a, то определяется один допустимый и два недопустимых класса эквивалентности.
3. если условие ввода задает множество значений {a,b,c}, то определяется один допустимый и один недопустимый класс эквивалентности.
4. если условие ввода задает булево значение, например true,то определяется один допустимый и один недопустимый класс эквивалентности.
После построения классов эквивалентности разрабатываются тестовые варианты.
Тестовый вариант выбирается так, чтобы проверить сразу наибольшее количество свойств класса эквивалентности.
Способ анализа граничных значений.
Как правило, большая часть ошибок происходит на границах области ввода, а не в центре. Анализ граничных значений заключается в получении тестовых вариантов, которые анализируют граничные значения. Данный способ тестирования дополняет способ разбиения по эквивалентности.
Основные отличия анализа граничных значений от разбиения по эквивалентности:
· тестовые варианты создаются для проверки только ребер классов эквивалентности.
· При создании тестовых вариантов учитывают не только условия ввода, но и область вывода.
Сформулируем правила анализа граничных значений.
1. если условие ввода задает диапазон n…m, то тестовые варианты должны быть построены:
1. для значений n и m.
2. для значений чуть левее n и чуть правее m на числовой оси.
2. Если условие ввода задает дискретное множество значений, то создаются тестовые варианты:
1. для проверки минимального и максимального из значений.
2. для значений чуть меньше минимума и чуть больше максимума.
3. Правила 1 и 2 применяются к условиям области вывода.
4. Если внутренние структуры данных программы имеют предписанные границы, то разрабатываются тестовые варианты, повторяющие эти структуры на их границах.
5. Если входные или выходные данные программы являются упорядоченными множествами (например, последовательным файлом, линейным списком, таблицей), то надо тестировать обработку первого и последнего элементов этих множеств.
Большинство разработчиков используют этот способ интуитивно. При применении описанных правил тестирование этих границ будет более полным, в связи с чем возрастет вероятность обнаружения ошибки.
Способ диаграмм причин-следствий.
Диаграммы причинно-следственных связей – способ проектирования тестовых вариантов, который обеспечивает формальную запись логических условий соответствующих действий. Используется автоматный подход к решению задачи.
Шаги способа:
· Для каждого модуля перечисляются причины (условия ввода или классы эквивалентности условий ввода) и следствия (действия или условия вывода). Каждой причине и следствию присваивается свой идентификатор.
· Разрабатывается граф причинно-следственных связей.
· Граф преобразуется в таблицу решений.
· Столбцы таблицы решений преобразуются в тестовые варианты.
ГЛАВА 3. ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ «УЧЕБНО-МЕТОДИЧЕСКИЙ РЕСУРС»
В качестве практической части нам было предложено протестировать фрагмент информационной системы «Учебно-методический ресурс», а именно – регистрацию пользователей. Так как информационная система «Учебно-методический ресурс» представляет собой WEB-сайт, то также было предложено протестировать и навигацию сайта.
Нами был выбран такой метод тестирования, как метод «черного ящика». Это обусловлено тем, что тестированием кода программы занимался непосредственно разработчик кода. Им был написан файл регистрации reg.php. В результате работы файла на главной странице информационной системы появляется следующая форма.
Нами были заполнены все обязательные и необязательны поля формы, но в поле «Подтверждение» нами был указан неверный пароль, в результате чего появилось следующее сообщение.
Появление вышеуказанного сообщения свидетельствует о верной работе файла регистрации в том случае, если неверно введено значение поля «Подтверждение».
Далее по ссылке «назад» мы попадаем на страницу регистрации. В очищенную после указанных действий форму мы вводим данные, не забывая указать верное подтверждение пароля, в результате чего осуществляется вход в информационную систему «Учебно-методический ресурс».
После проведения регистрации мы попадаем на главную страницу сайта и узнаем его содержание и структуру.
Для тестирования фрагмента информационной системы «Учебно-методический ресурс» нами была выбрана возможность создания курса лекций одного предмета.
На главной странице указывается количество лекций. В нашем случае их количество – 3. Нажатием кнопки «Лекции» вызывается форма, содержащая пустые поля для ввода названия лекции и пути, по которому находится файл с непосредственно содержанием (текстом) лекции. Файл с лекцией должен быть написан в текстовом редакторе Microsoft Office Word и сохранен как веб-страница с фильтром, иначе могут возникнуть ошибки в формировании конечной страницы. В результате проделанных действий должна формироваться веб-страница, содержащая все лекции, указанные пользователем. В нашем случае формирование страницы происходит успешно, и мы получаем веб-страницу с тремя лекциями с заданными названиями и с верным содержимым.
Помимо тестирования веб-страниц информационной системы «УМР» производилось визуальное тестирование исходного кода сценария reg.php. Проверка данного файла осуществлялась при помощи редактора PHP Expert Editor.
Файл
сценария
reg.php
<?php
session_start();
// ñîçäàåì íîâóþ ñåññèþ èëè
// âîññòàíàâëèâàåì òåêóùóþ
$err_msg = array("lname"=>"Ôàìèëèÿ:", "fname"=>"Èìÿ", "oname"=>"Îò÷åñòâî", "pass"=>"Íå âåäåí ïàðîëü","repass"=>"Íå ïîäòâåðæäåí ïàðîëü", "error"=>"Ïàðîëü íå ñîâïàäàåò ñ ïîäòâåðæäåíèåì",
"login"=>"Ïîëüçîâàòåëü ñ òàêèì ïñåâäîíèìîì óæå ñóùåñòâóåò");
//print_r($err_msg);
/*-------Âñïîìîãàòåëüíûå ôóíêöèè-------*/
function Check($var, $val=""){
if (!isset($var))
return $val;
else
return $var;
}
//Ôóíêöèÿ äëÿ ïðîâåðêè ÔÈÎ
//function FIO_OK($str){
// return ereg("^[À-ßà-ÿ' -]{l,25}$", $str);
//}
function LOGIN_OK($str){
$conn=mysql_connect("localhost","root");// óñòàíàâëèâàåì ñîåäèíåíèå
$database = "users";
$table_name = "pass";
mysql_select_db($database); // âûáèðàåì áàçó äàííûõ
//ïðîâåðêà óíèêàëüíîñòè ïñåâäîíèìà
$sql = "SELECT login FROM $table_name WHERE `login` = "."'".$str."'";
$result=mysql_query($sql);
mysql_close($conn);
return mysql_num_rows($result);
}
//Ôóíêöèÿ äëÿ ïðîâåðêè email
function email_OK($str){
return preg_match("/^w+([.w]+)*w@w((.w)*w+)*.w{2,3}$/",$str);
}
//Ôóíêöèÿ äëÿ ïðîâåðêè òåëåôîíà
function telefon_OK($str){
return preg_match("/d{3}-d{2}-d{2}/",$str);
}
//Ôóíêöèÿ äëÿ ïðîâåðêè ôîðìû
function Form_OK(){
//Ìàññèâ îøèáîê è ñîîòâåòñòâóþùèõ ñîîáùåíèé
global $errors, $err_msg;
/* if(!FIO_OK($_POST["fname"])){
$errors["fname"] = 1;
$_POST["fname"] ="";
}
if(!FIO_OK($_POST["oname"])){
$errors["oname"] = 1;
$_POST["oname"] ="";
}
if(!FIO_OK($_POST["lname"])){
$errors["lname"] = 1;
$_POST["lname"] ="";
}
*/
if(LOGIN_OK($_POST["login"])){
$errors["login"] = 1;
$_POST["login"] ="";
}
//ïðîâåðêà ñîâïàäåíèÿ ïàðîëÿ è ïîäòâåðæäåíèÿ
if(strcmp($_POST["pass"],$_POST["repass"])!=0){
$errors["error"]=1;
$_POST["repass"]="";
}
if(!$_POST["pass"]) {
$errors["pass"]=1;
$_POST["repass"]="";
}
if(!$_POST["repass"]) $errors["repass"]=1;
if(sizeof($errors)>0){
//Åñëè ñóùåñòâóþò îøèáêè, âûâîäÿòñÿ ñîîòâåòñòâóþùèå ñîîáùåíèÿ, è ôîðìà îòîáðàæàåòñÿ çàíîâî
echo "<html><body><div align='center' style='font-size: 18'><b>ÎØÈÁÊÀ</b></div>";
echo "<div align='center' style='font-size: 14, color:red'>Îáíàðóæåíû ñëåäóþùèå îøèáêè:<br>";
foreach($errors as $key=>$value){
echo "<b>".$err_msg [$key]."</b><br>";
}
echo "</div>";
ShowForm();
echo "</body></html>";
}
else {
//Åñëè îøèáêè îòñóòñòâóþò, âûâîäèòñÿ ñîîòâåòñòâóþùåå ñîîáùåíèå
echo "<h2 align='center'>Óâàæàåìûé(àÿ) ".$_POST["lname"]." ".$_POST['fname']."!</h2><br> <h3 align='center'>
Ðåãèñòðàöèÿ ïðîøëà óñïåøíî</h3>";
$_SESSION['login']=$_POST['login'];
// ðåãèñòðèðóåì ïåðåìåííóþ login
//$_SESSION['pass']=$_POST['pass'];
// ðåãèñòðèðóåì ïåðåìåííóþ pass
// òåïåðü ëîãèí è ïàðîëü - ãëîáàëüíûå
// ïåðåìåííûå äëÿ ýòîé ñåññèè
echo "<center><a href =main_form.php>OK</a></center>";
//âíîñèì äàííûå â áàçó
$conn=mysql_connect("localhost","root");// óñòàíàâëèâàåì ñîåäèíåíèå
$database = "users";
$table_name = "pass";
mysql_select_db($database); // âûáèðàåì áàçó äàííûõ
//ïðîâåðêà óíèêàëüíîñòè ïñåâäîíèìà
$list_f = mysql_list_fields($database,$table_name);// ïîëó÷àåì ñïèñîê ïîëåé â áàçå
$n = mysql_num_fields($list_f); // ÷èñëî ñòðîê â ðåçóëüòàòå ïðåäûäóùåãî çàïðîñà
// ñîñòàâèì îäèí çàïðîñ ñðàçó äëÿ âñåõ ïîëåé òàáëèöû
$sql = "INSERT INTO $table_name SET "; // íà÷èíàåì ñîçäàâàòü çàïðîñ, ïåðåáèðàåì âñå ïîëÿ òàáëèöû
for($i=0;$i<$n; $i++){
$name_f = mysql_field_name ($list_f,$i); // âû÷èñëÿåì èìÿ ïîëÿ
$value = $_POST[$name_f]; // âû÷èñëÿåì çíà÷åíèå ïîëÿ
$j = $i + 1;
$sql = $sql . $name_f." = '$value'"; // äîïèñûâàåì â ñòðîêó $sql ïàðó èìÿ=çíà÷åíèå
if ($j <> $n) $sql = $sql . ", "; // åñëè ïîëå íå ïîñëåäíåå â ñïèñêå, òî ñòàâèì çàïÿòóþ
}
// ïåðåä òåì êàê çàïèñûâàòü ÷òî-òî â áàçó,
// ìîæíî ïîñìîòðåòü, êàêîé çàïðîñ ïîëó÷èëñÿ
//echo $sql;
$result = mysql_query($sql,$conn); // îòïðàâëÿåì çàïðîñ âûâîäèì ñîîáùåíèå óñïåøíî ëè âûïîëíåí çàïðîñ
if (!$result) echo "Can't add ".$table_name;
else echo "Success!<br>";
mysql_close($conn);
}}
function ShowForm(){
echo $_SERVER['PHP_SELF'];
echo "
<h3 align="center">Ðåãèñòðàöèÿ</h3>
<form action="{$_SERVER['PHP_SELF']}" method="POST">
<h4 align="center"><b><font face="Courier New, Courier, mono">Ïîæàëóéñòà, çàïîëíèòå
ôîðìó, ïðèâåäåííóþ íèæå. Ñïàñèáî!</font></b></h4>
<h4 align="center"><font face="Courier New, Courier, mono"><i><font size="2">Íå
îáÿçàòåëüíûå ïîëÿ ïîìå÷åíû *</font></i></font></h4>
<div align="center">
<table width="250" border="0">
<tr>
<td>
<div align="right">Ôàìèëèÿ</div>
</td>";
if (!isset($_POST['lname'])) $value="";
else $value=Check($_POST["lname"]);
echo "
<td>
<input type=text name="lname" maxlength="25" value="$value">
</td>
</tr>
<tr>
<td>
<div align="right">Èìÿ</div>
</td>";
if (!isset($_POST['fname'])) $value="";
else $value=Check($_POST['fname']);
echo "
<td>
<input type="text" name="fname" maxlength="25" value="$value">
</td>
</tr>
<tr>
<td>
<div align="right">Îò÷åñòâî</div>
</td>";
if (!isset($_POST['oname'])) $value="";
else $value=Check($_POST['oname']);
echo "
<td>
<input type="text" name="oname" maxlength="25" value="$value">
</td>
</tr>
<tr>
<td>
<div align="right">*Çâàíèå</div>
</td>";
if (!isset($_POST['rank'])) $value="";
else $value=Check($_POST['rank']);
echo "
<td>
<input type="text" name="rank" maxlength="25" value="$value">
</td>
</tr>
<tr>
<td>
<div align="right">*Äîëæíîñòü</div>
</td>";
if (!isset($_POST['post'])) $value="";
else $value=Check($_POST['post']);
echo "
<td>
<input type="text" name="post" maxlength="25" value="$value">
</td>
</tr>
<tr>
<td>
<div align="right">*Òåëåôîí</div>
</td>";
if (!isset($_POST['telefon'])) $value="";
else $value=Check($_POST['telefon']);
echo "
<td>
<input type="text" name="telefon" maxlength="10" value="$value">
</td>
</tr>
<tr>
<td>
<div align="right">*E-mail</div>
</td>";
if (!isset($_POST['email'])) $value="";
else $value=Check($_POST['email']);
echo "
<td>
<input type="text" name="email" maxlength="25" value="$value">
</td>
</tr>
<tr>
<td>
<div align="right">Ïñåâäîíèì</div>
</td>";
if (!isset($_POST['login'])) $value="";
else $value=Check($_POST['login']);
echo "
<td>
<input type="text" name="login" maxlength="15" value="$value">
</td>
</tr>
<tr>
<td>
<div align="right">Ïàðîëü</div>
</td>";
if (!isset($_POST['pass'])) $value="";
else $value=Check($_POST['pass']);
echo "
<td>
<input type="password" name="pass" maxlength="10" value="$value">
</td>
</tr>
<tr>
<td>
<div align="right">Ïîäòâåðæäåíèå</div>
</td>";
if (!isset($_POST['repass'])) $value="";
else $value=Check($_POST['repass']);
echo "
<td>
<input type="password" name="repass" maxlength="10" value="$value">
</td>
</tr>
</table>
<input type="submit" name="ok" value="OK">
</div>
</form>";
}
if (!isset($_POST['ok'])){
echo "
<html>
<head>
<title>Registration</title>
<meta http-equiv="Ñîäåðæèìîå-Òèï" content="text/html; charset=windows-1251">
</head>
<body background=..ris1.jpg text="#000000">";
ShowForm();
echo "
</body>
</html>
";}
else Form_OK();
?>
ЗАКЛЮЧЕНИЕ
В ходе анализа литературы, посвященной теме курсовой работы, нам удалось изучить основные понятия тестирования программного обеспечения в общем и информационных систем в частности, и мы пришли к выводу, что наиболее оптимальным определением тестирования будет следующее:
Тестирование – это процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований.
Далее были рассмотрены виды тестирования:
· Блочное тестирование;
· Тестирование компонента;
· Интеграционное тестирование;
· Регрессивное тестирование;
· Тестирование системы.
Выделены основные критерии и принципы тестирования, а также методы тестирования программного обеспечения, такие как:
· Метод «белого ящика».
· Метод «черного ящика».
Практической частью курсовой работы было тестирование фрагмента информационной системы «Учебно-методический ресурс».
Таким образом, задачи, сформулированные во введении, решены, а цель достигнута.
СПИСОК ЛИТЕРАТУРЫ
1. Липаев В.В.
Отладка сложных программ: Методы, средства, технология.
М.: Энергоатомиздат, 1993, 384 с.
2. Майерс Г.
Искусство тестирования программ.
М.: Финансы и статистика, 1982, 176 с.
3. Технологии разработки программного обеспечения: Учебник для
вузов. 3-е из
д./ С.А. Орлов. – СПб.: Питер, 2004. – 527 с.: ил.
4. Макгрегор Дж., Сайкс Д.
Тестирование объектно-ориентированного программного обеспечения
К.: Диасофт, 2002. – 432 с.
5. Липаев В.В.
Тестирование программ
М.: Радио и связь, 1986. – 296 с.
6. Канер С., Фолк ДЖ., Нгуен Енг.
Тестирование программного обеспечения
К.: Диасофт, 2000 – 544 с.
7. Шимаров В.А.
Тестирование программ: цели и особенности инструментальной поддержки
//Программное обеспечение ЭВМ / АН БССР. Институт математики.
Минск, 1994. – Вып. 100 – с.19 – 43
8. Борзов Ю.В., Уртанг Г.Б., Шимаров В.А.
Выбор путей программы для построения тестов
УСиМ. – 1989. – N.6 – с.29-36
9. Boehm, Barry W.
«A Spiral Model of Software Development and Enhancement»
IEEE Computer, Vol. 21, no. 5 (May 1988), pp 61-72.
10. Humphrey, Watts S.
Managing the Software Process.
Reading, MA: Addison-Wesley, 1989.
11. Marks, David M.
Testing Very Big Systems.
New-York: Bellcore (McGraw-Hill), 1992.
12. Карлбертсон Р., Браун К., Кобб Г.
Быстрое тестирование
Изд. Вильямс 2002, 216 с.
13. Дастин Э., Рэшка Дж., Пол Дж.
Автоматизированное тестирование программного обеспечения
Изд. Лори 2003, 310 с.
ПРИЛОЖЕНИЕ. ПРИМЕНЕНИЕ СТАНДАРТА
IEEE STD 829 ПРИ ПЛАНИРОВАНИИ И ВЫПОЛНЕНИИ ФУНКЦИОНАЛЬНОГО И НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Стандарт IEEE
829
Software
Test
Documentation
– «задает планку» для индустрии ИТ по организации процесса тестирования. Этот стандарт разрабатывался с 1977 года и был утвержден в 1983 году, а затем вновь подтвержден в 1991 и 1998 годах. Несмотря на свою зрелость, он актуален и в 21-м веке. Стандарт «ложится» как на каскадную, так и на спиральную, итерационную модель жизненного цикла (ЖЦ) разработки и сопровождения программного обеспечения, а также стандарт не противоречит идеологии объектно-ориентированного подхода. IEEE STD 829 предлагает основу – достаточный набор документов для того, чтобы:
· упорядочить работы по этапам, стадиям;
· разделить ответственность и объем работ;
· унифицировать документы в проекте или в организации.
Место и роль процесса тестирования в жизненном цикле разработки и сопровождения ПО описаны во многих стандартах, в том числе и в стандарте ГОСТ Р ИСО/МЭК 12207.
При тестировании на этапах «белого», «серого» и «черного ящиков» могут быть разные исполнители в рамках одного проекта, различная структура процессов, но перечень документов сохраняется. Тестирование «белого» и «серого ящиков» подразумевает полное или частичное тестирование кода программного обеспечения, подобное тестирование модулей (компонент) обычно рекомендуется выполнять силами программистов-авторов. Функциональное тестирование («черного ящика») – это системное тестирование на соответствие функциональным требованиям к разрабатываемому ПО. В системном тестировании выделяют нагрузочное тестирование – испытание производительности системы, которое может включать калибровочные испытания, стрессовое тестирование, тестирование на больших объемах данных, тестирование производительности при растущей нагрузке на систему и т.п.
Данный стандарт относится к динамическому тестированию, т.е. с выполнением кода ПО, и не относится к менее популярному статическому тестированию.
Состав документов, рекомендованных в стандарте
IEEE
STD
829:
план тестирования, проект теста, спецификация тестового сценария, спецификация тестовой процедуры, отчет о ходе тестирования, протокол тестирования, отчет о найденных ошибках, итоговый отчет о тестировании.
Рекомендованный состав плана тестирования:
название, введение, тестируемые элементы, перечень тестируемых свойств системы, нетестируемые свойства системы, подходы к тестированию, критерии успеха/неудачи тестов, критерии остановки и требования для возобновления, выходные тестовые материалы, тестовые задачи, необходимое окружение, ответственности персонала, требования по квалификации персонала и необходимость обучения, график работ, риски и действия по их снижению, согласование.
Спецификация сценария теста:
Название, тестируемые элементы, спецификации входных и выходных данных, необходимая среда тестирования, специальные требования к процедуре, взаимосвязи.
Спецификация тестовой процедуры:
Название, цель, специальные требования, шаги выполнения процедуры.
Использование стандарта
IEEE
STD
829 в реальных проектах.
За последние три года данный стандарт эффективно использовался Центром тестирования департамента консалтинга компании АйТи в следующих проектах: нагрузочное тестирование биллинговых систем, функциональное тестирование CRM-системы, внедрение стандарта предприятия для учреждения Банк. Большой эффект экономии ресурсов и средств дает использование отработанных, адаптированных шаблонов документов, перечисленных в стандарте. Для каждого проекта можно определить степень стандартизации – создание СТП, методики или простое использование шаблона.
По практике данных работ видно, что стандарт можно дополнить, например, если используется объектно-ориентированное проектирование (ООП), то можно добавить следующие документы: описание тестовых классов, тестовых пакетов. Экономия при использовании шаблонов не только в том, что есть образец, но и в том, что логика и состав документа тщательно продуманы и проработаны, как оп смыслу, так и по оформлению, т.е. не нужно «изобретать велосипед». А для случаев, когда выполняется заказная работа, эти шаблоны готовы для рассмотрения и согласования с Заказчиком с первых дней и часов с начала работ. Для больших и/или достаточно формализованных проектов (RUP) требуется полный или расширенный список документов, а для малых проектов, которые очень распространены в последнее время в связи с популярностью аутсортинга, методологий RAD, XP – список документов может быть сокращен или упрощен.
Плюсы внедрения стандарта – унификация (ускорение работ, единая корпоративная структура), смысловая полнота.
Минусы – бюрократизация работ – требуется соблюдать трудовую дисциплину, что не всегда и не всеми приветствуется в коллективах.
Конечно, в стандарте не используются подходы и стратегии тестирования, например, тестирование по критериям «Риск», «Надежность», «Производительность», хотя начало тестирования с самых критичных сценариев дает большой, в том числе экономический, эффект, так как стоимость исправления ошибки на поздних стадиях возрастает в сотни и тысячи раз по сравнению с ранними этапами разработки ПО.
Подчеркнем, что кроме планирования для тестирования важными процессами являются управление требованиями, управление ошибками, управление версиями (конфигурациями), управление изменениями, в том числе отслеживание ошибок.
Рассматриваемый стандарт рекомендуется использовать не только для планирования и выполнения работ по тестированию, но и для разработки стандарта предприятия, программы и методики испытаний, а также для создания методик по отдельным видам тестирования (функциональному, нагрузочному, стрессовому, приемочному и т.п.). В этом случае можно также использовать ГОСТ 19.301-79 Программы и методики испытаний. Стандарты предприятий рекомендовано создавать для разработчиков ПО, для служб сопровождения (тиражные системы). Программы и методики испытаний – для служб эксплуатации систем (биллинг, ERP, CRM).
Ресурсные затраты на разработку одинакового типа шаблона могут отличаться для разных организаций: создание в первый раз – от 8 часов, при наличие подходящего образца и опыта, до нескольких дней; адаптация отработанного шаблона для нового проекта – от 1 часа до 1дня. Некоторые методологии и пакеты инструментальных средств предлагают наборы типовых шаблонов по разным процессам, в том числе и для тестирования.
Как известно простое использование стандарта не является залогом успеха. Да и процесс тестирования является, в достаточной мере, творческим процессом. Каждое новое тестирование своеобразно, всегда требуется индивидуальный подход не только к решению задач, но и в целом к процессу. Поэтому в основном ограничиваются стандартизацией документирования данного процесса – это не так уж и мало.