В настоящее время в области информационных технологий и построения программ все большее место занимает построение крупномасштабных программных средств, обладающих мощными интеллектуальными возможностями. Соответственно росту сложности программ возрастает количество выявляемых и остающихся в них дефектов и ошибок.
С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных к установить соответствие различных свойств и характеристик приложения заказанным свойствам. Как одна из основных фаз процесса разработки программного продукта (Дизайн приложения – Разработка кода – Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 40–20–40 %, из чего следует, что наибольший эффект в снижении трудоемкости может быть получен прежде всего на фазах Design и Testing. Задачей ближайшего будущего является движение в сторону такого распределения трудоемкости (60–20–20 %), чтобы суммарная цена обнаружения большинства дефектов стремилась к минимуму за счет обнаружения преимущественного числа ошибок программы на наиболее ранних фазах разработки программного продукта.
Ошибки моделирования бизнес процессов в нотации BPMN
Тестирование осуществляется на заданном заранее множестве входных данных X и множестве предполагаемых результатов Yэт – (X, Yэт), которые задают график желаемой функции. Определяется соответствуют ли выходные данные – Yвых (вычисленные по входным данным – X) желаемым результатам – Yэт, т.е. принадлежит ли каждая вычисленная точка (x,yвых) графику желаемой функции (X, Yэт). При выявлении (x,yвых) не принадлежащей (X, Yэт) запускается процедура исправления ошибки, которая заключается во внимательном анализе (просмотре) протокола промежуточных вычислений, приведших к (x, yвых).
Тестирование программного обеспечения представляет собой процесс или последовательность процессов, целью которых является нахождение ошибок в программе. Программа должна вести себя предсказуемо. Не следует, однако, думать, что целью тестирования является демонстрация того, что программа не содержит ошибок.
Практически любая программа (кроме самых простых) содержит ошибки, и если тест их не выявил, то такой тест можно считать неудачным. Наоборот, целью тестирования является выявление ошибок в предположении, что они в программе есть. Однако, выявить с помощью тестирования все ошибки, особенно в сложной системе, практически нереально.
Тестирование в случае программ предполагает, что программа выполняется для некоторых исходных данных (тестового набора), и выходные данные сравниваются с эталонными. Если они не совпадают, в программе присутствует ошибка, и ее уже можно найти, так как мы знаем набор исходных данных, который ее провоцирует. На первый взгляд все кажется простым, однако вскоре возникает вопрос о том, как же выбирать тестовые наборы. Решение этой проблемы сильно зависит от тестируемой программы и от целей ее разработки. Желательно, чтобы выбираемые тестовые наборы давали наибольшую вероятность обнаружения ошибки.
SDLС — Жизненный цикл разработки программного обеспечения. Подробный разбор этапов разработки.
Основная проблема тестирования – определение достаточности множества тестов для истинности вывода о правильности реализации программы, а также нахождения множества тестов, обладающего этим свойством. Задача о выборе конечного набора тестов (X, Yэт) для проверки программы в общем случае неразрешима. Поэтому для решения практических задач остается искать частные случаи решения этой задачи.
В настоящей работе рассмотрены подходы к автоматизации решения различных задач тестирования программных систем, причем основное внимание уделено структурному тестированию на граф-моделях программ, выполняемому на ранних стадиях жизненного цикла (модульному тестированию и интеграционному дизайн-тестированию).
Рассмотрены следующие проблемы:
— Выбор множества тестовых путей, обеспечивающего заданное тестовое покрытие.
— Автоматическая оценка полноты тестирования.
— Инструментирование и динамический анализ программ.
— Генерация тестовых воздействий на основе алгебраических моделей программ и символьного выполнения.
В первой главе рассматриваются существующие методы верификации программного обеспечения, их достоинства, недостатки и применимость. В сравнении приводятся функциональный и структурный подходы к тестированию программ.
Вторая глава посвящена тестированию программ на основе граф – моделей. Приведены используемые в рамках структурного тестирования граф-модели программ, основанные на них критерии полноты тестирования и методы выбора тестовых путей и тестовых воздействие, особое внимание уделено минимальным покрытиям управляющим графам и их использованию с целью выбора минимально грубого множества тестов.
В третьей главе рассматривается проблема определения полноты тестирования на различных его этапах – как при тестировании на этапе разработки, так и при верификационном тестировании. Приводятся существующие подходы к оценке полноты тестирования, основанные на инструментировании тестируемой программной системы.
В четвертой главе рассматриваются технические аспекты автоматизации тестирования – состав систем автоматизации, методы выбора тестовых воздействий.
В пятой и шестой главах рассматривается авторский подход к автоматизации модульного и дизайн-тестирования программных систем, основанный на алгебраической модели программы и динамическом символьном выполнении.
Книга предназначена для студентов направления «Информатика и вычислительная техника», магистрантов, обучающихся по программе «Диагностические и информационно-поисковые системы», аспирантов и специалистов в области разработки и обеспечения качества программного обеспечения.
Источник: expeducation.ru
Тестирование программных продуктов
Двоичные файлы, хранят данные в том же виде, в котором они представлены в оперативной памяти, т.е. во внутренней форме представления. Выходной поток BinaryWriter. т.е. имеется возможность выполнять запись в произвольную позицию, двоичного файла. Двоичный файл открывается на основе базового потока в качестве которого чаще всего FileStream. Наиболее важные элементы класса BinaryWriter.
BaseStream – базовый поток с которым работает объект BinaryWriter.
Flush – отчистить буфер
Seek – установить позицию, в текущем потоке
Write – записать значение в текущий поток
Наиболее важные элементы класса BinaryReader
BaseStream — базовый поток с которым работает объект BinaryReader.
Close – закрыть поток
PeekChar – возвратить следующий символ без перемещения внутреннего указателя в потоке
Read – считать поток байтов или символов и сохранить в массиве передаваемом как входной параметр
ReadXXXX – считать из потока данные определенного типа
При создании базового потока в него передается объект базового потока. В указателе текущей позиции в файле учитывается длина значения определенного типа.
Тестирование это процесс выполнения программы, целью которого является выявление ошибок. Никакое тестирование не может доказать отсутствие ошибок в сложном программном продукте. Соблюдение основных правил тестирования, и научно обоснованный подбор тестов, может уменьшить их количество. Процесс разработки программного обеспечения, предполагает 3 стадии тестирования:
1) автономное тестирование компонентов программного обеспечения
2) комплексное тестирование разрабатываемого программного обеспечения
3) системное или оценочное тестирование на соответствие основным критериям качества
Для повышения качества тестирования, рекомендуется соблюдать следующие принципы:
1) Следует избегать тестирования программ автором
2) Предполагаемые результаты должны быть известны до тестирования
3) Необходимо досконально изучать результата каждого теста
4) Необходимо проверять действие программы на неверных данных
5) Необходимо проверять программу на неожиданные побочные эффекты на неверных данных
Формирование тестовых наборов
Существует два принципиально различных подхода к формированию тестовых наборов:
Структурный и функциональный
Наборы тестов, полученные в соответствии с методами этих подходов обычно объединяют, обеспечивая всестороннее, тестирование программного обеспечения.
Структурное тестирование называется так же тестированием по маршруту, так как тестовые наборы в этом случае, формируют путем анализов маршрутов предусмотренных алгоритмом. Под маршрутами понимают последовательность операторов программы, которые выполняются при конкретном варианте исходных данных.
При структурном тестировании нужно предусмотреть, максимально полное тестирование всех маршрутов программы. Считается, что программа проверена полностью, если с помощью тестов удается осуществлять выполнение программы по всем возможным маршрутам передач управления. Структурный подход к тестированию имеет ряд недостатков. Тестовые наборы, построенные в соответствии со структурным подходом, не обнаруживают пропущенных маршрутов, не обнаруживают ошибок, зависящих от обрабатываемых данных, и не дают гарантий, что программа правильна. Если вместо сортировки по убыванию реализована сортировка по возрастанию.
Формирование тестовых наборов может осуществляться по критерию, покрытие операторов, покрытие решений, покрытие условий, комбинаторное покрытие условий.
Функциональное тестирование это тестирование по управлению по данным или по принципу «черного ящика». Программа рассматривается как черный ящик, и целью тестирования является выяснение обстоятельств, в которых поведение программы не соответствуют спецификации. Функциональное тестирование не дает гарантий отсутствия отклонений от спецификаций. При функциональном тестировании различают, следующие методы формирования тестовых наборов:
1) Эквивалентное разбиение
2) Анализ граничных значений
3) Анализ причинно-следственных связей
4) Предположение об ошибке
Эквивалентное разбиение – область всех возможных наборов входных данных программы, по каждому параметру, разбивают, на конечное число групп, классов эквивалентности. Наборы данных такого класса объединяют по признаку обнаружения одних и тех же ошибок. Если набор, какого либо класса, обнаруживает некоторую ошибку, то предполагается что все другие тесты этого класса эквивалентности тоже обнаружат эту ошибку и наоборот. Разработка тестов методом эквивалентного разбиения осуществляют в 2 этапа:
На первом выделяют классы эквивалентности
На втором формируют тесты
В отдельные классы эквивалентности выделяют наборы, содержащие допустимые и недопустимые значения, некоторого параметра, при этом существует ряд правил:
Если некоторый параметр X принимает значения, в промежутке [1, 999] то выделяется один правильный класс, 1999 и X
Если входное условие определяет диапазон значений порядкового типа «В автомобиле могут ехать от 1 до 6 человек», то выделяется правильный класс и два не правильных
Если входное условие описывает множество входных значений и каждое значение программист трактует особо, например: Типы графических файлов: BMP, jpeg, PNG… То определяют правильный класс для каждого значения и один не правильный класс (txt).
Если входное условие описывает ситуацию должно быть например, первым символом идентификатора должна быть буква, то определяется один правильный класс эквивалентности 1-й символ буква, и один не правильный 1-й символ не буква.
Если есть основание считать, что различные элементы класса эквивалентности трактуются программой неодинаково, то данный класс разбивается на меньшие классы эквивалентности.
Источник: studopedia.su
Отладка и тестирование
Тестирование — это процесс выполнения программы, целью которого является выявление ошибок. Никакое тестирование не может доказать отсутствие ошибок в сложном ПО, поскольку выполнение полного тестирования становится невозможным и имеется вероятность, что остались не выявленные ошибки. Соблюдение основных правил тестирования и научно обоснованный подбор тестов может уменьшить их количество. Процесс разработки согласно современной модели жизненного цикла ПО предполагает три стадии тестирования: автономное тестирование компонентов ПО; комплексное тестирование разрабатываемого ПО; системное или оценочное тестирование на соответствие основным критериям качества. Для повышения качества тестирования рекомендуется соблюдать следующие основные принципы:
1) предполагаемые результаты должны быть известны до тестирования;
2) следует избегать тестирования программы автором;
3) необходимо досконально изучать результаты каждого теста;
4) необходимо проверять действия программы на неверных данных;
5) необходимо проверять программу на неожиданные побочные эффекты на неверных данных.
Вероятность наличия необнаруженных ошибок в части программы пропорциональна количеству ошибок уже найденных в этой части. Удачным считают тест, который обнаруживает хотя бы одну ошибку. Формирование набора тестов имеет большое значение, поскольку тестирование является одним из наиболее трудоемких этапов создания ПО. Доля стоимости тестирования в общей стоимости разработки возрастает при увеличении сложности ПО и повышении требований к их качеству.
Существуют два принципиально различных подхода к формированию тестовых наборов: структурный и функциональный. Структурный подход базируется на том, что известна структура тестируемого ПО, в том числе его алгоритмы («стеклянный ящик»). Тесты строятся для проверки правильности реализации заданной логики в коде программы.
Функциональный подход основывается на том, что структура ПО не известна («черный ящик»). В этом случае тесты строят, опираясь на функциональные спецификации. Этот подход называют также подходом, управляемым данными, так как при его использовании тесты строят на базе различных способов декомпозиции множества данных. Наборы тестов, полученные в соответствии с методами этих подходов, объединяют, обеспечивая всестороннее тестирование ПО.
Ручной контроль используют на ранних этапах разработки. Все проектные решения анализируются с точки зрения их правильности и целесообразности как можно раньше, пока их можно легко пересмотреть. Различают статический и динамический подходы к ручному контролю.
При статическом подходе анализируют структуру, управляющие и информационные связи программы, ее входные и выходные данные. При динамическом- выполняют ручное тестирование (вручную моделируют процесс выполнения программы на заданных исходных данных). Исходными данными для таких проверок являются: техническое задание, спецификации, структурная и функциональная схемы программного продукта, схемы отдельных компонентов, а для более поздних этапов — алгоритмы и тексты программ, а также тестовые наборы. Доказано, что ручной контроль способствует существенному увеличению производительности и повышению надежности программ и с его помощью можно находить от 30 до 70 % ошибок логического проектирования и кодирования. Основными методами ручного контроля являются: инспекции исходного текста, сквозные просмотры, проверка за столом, оценки программ.
В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов, предусмотренных алгоритмом (последовательности операторов программы, выполняемых при конкретном варианте исходных данных). Недостатки: построенные тестовые наборы не обнаруживают пропущенных маршрутов и ошибок, зависящих от заложенных данных; не дают гарантии, что программа правильна.
Другим способом проверки программ является функциональное тестирование: программа рассматривается как «черный ящик», целью тестирования является выяснение обстоятельств, когда поведение программы не соответствует спецификации. Для обнаружения всех ошибок необходимо выполнить исчерпывающее тестирование (при всех возможных наборах данных), что для большинства случаев невозможно. Поэтому обычно выполняют «разумное» или «приемлемое» тестирование, ограничивающееся прогонами программы на небольшом подмножестве всех возможных входных данных. При функциональном тестировании различают следующие методы формирования тестовых наборов: эквивалентное разбиение; анализ граничных значений; анализ причинно-следственных связей; предположение об ошибке.
При комплексном тестировании используют тесты, построенные по методам эквивалентных классов, граничных условий и предположении об ошибках, поскольку структурное тестирование для него не применимо. Одним из самых сложных является вопрос о завершении тестирования, так как невозможно гарантировать, что в программе не осталось ошибок. Часто тестирование завершают потому, что закончилось время, отведенное на его выполнение. Его сворачивают, обходясь минимальным тестированием, которое предполагает: тестирование граничных значений, тщательную проверку руководства, тестирование минимальных конфигураций технических средств, возможности редактирования команд и повторения их в любой последовательности, устойчивости к ошибкам пользователя.
После завершения комплексного тестирования приступают к оценочному тестированию, целью которого является поиск несоответствий техническому заданию. Оценочное тестирование включает тестирование: удобства использования, на предельных объемах, на предельных нагрузках, удобства эксплуатации, защиты, производительности, требований к памяти, конфигурации оборудования, совместимости, удобства установки, удобства обслуживания, надежности, восстановления, документации, процедуры.
Отладка — это процесс локализации (определения оператора программы, выполнение которого вызвало нарушение вычислительного процесса) и исправления ошибок, обнаруженных при тестировании ПО. Для исправления ошибки необходимо определить ее причину. Отладка требует от программиста глубоких знаний специфики управления используемыми техническими средствами, операционной системы, среды и языка программирования, реализуемых процессов, природы и специфики ошибок, методик отладки и соответствующих программных средств; психологически дискомфортна (нужно искать собственные ошибки в условиях ограниченного времени); оставляет возможность взаимовлияния ошибок в разных частях программы. Четко сформулированные методики отладки отсутствуют. Различают:
1) синтаксические ошибки – сопровождаются комментарием с указанием их местоположения, фиксируются компилятором (транслятором) при выполнении синтаксического и частично семантического анализа;
2) ошибки компоновки — обнаруживаются компоновщиком (редактором связей) при объединении модулей программы;
3) ошибки выполнения — обнаруживаются аппаратными средствами, операционной системой или пользователем при выполнении программы, проявляются разными способами и в свою очередь делятся на группы:
а) ошибки определения исходных данных (ошибки передачи, ошибки преобразования, ошибки перезаписи и ошибки данных);
б) логические ошибки проектирования (неприменимый метод, неверный алгоритм, неверная структура данных, другие) и кодирования (ошибки некорректного использования переменных, вычислений, межмодульного интерфейса, реализации алгоритма, другие);
в) ошибки накопления погрешностей результатов вычислений (игнорирование ограничений разрядной сетки и способов уменьшения погрешности).
Отладка программы в любом случае предполагает обдумывание и логическое осмысление всей имеющейся информации об ошибке. Большинство ошибок можно обнаружить по косвенным признакам посредством тщательного анализа текстов программ и результатов тестирования без получения дополнительной информации с помощью следующих методов:
1) ручного тестирования (при обнаружении ошибки нужно выполнить тестируемую программу вручную, используя тестовый набор, при работе с которым была обнаружена ошибка);
2) индукции (основан на тщательном анализе симптомов ошибки, которые могут проявляться как неверные результаты вычислений или как сообщение об ошибке);
3) дедукции (вначале формируют множество причин, которые могли бы вызвать данное проявление ошибки, а затем анализируя причины, исключают те, которые противоречат имеющимся данным);
4) обратного прослеживания (для точки вывода неверного результата строится гипотеза о значениях основных переменных, которые могли бы привести к получению данного результата, а затем, исходя из этой гипотезы, делают предположения о значениях переменных в предыдущей точке).
Для получения дополнительной информации об ошибке выполняют добавочные тесты и используют специальные методы и средства: отладочный вывод; интегрированные средства отладки; независимые отладчики.
Источник: dzen.ru